JP6894167B2 - 通信装置及び通信方法 - Google Patents

Description

本発明は、通信装置及び通信方法に関する。

インターネット通信においてＱｏＳ（Quality of Service）を保証する代表的な手法にＤｉｆｆＳｅｒｖ（Differentiated Services）がある（非特許文献１等参照）。ＤｉｆｆＳｅｒｖは、通信フローをいくつかのクラスに分類し、クラス毎に優先順位をつけて制御を行う手法である。優先制御手法としては、例えばＰＱ（PriorityQueuing）、ＷＦＱ（Weighted Fair Queuing）、ＬＬＱ（Low Latency Queuing）などがある。これらは、優先度の高いクラスのパケットを優先的に処理、又は帯域保証を行うことでＱｏＳを保証する。

また、ルータなどでパケットの過剰なバッファリングによって大きな遅延が生じるＢｕｆｆｅｒｂｌｏａｔを回避する手法として、動的にパケット交換装置のキューサイズを変更する様々なＡＱＭ（Active Queue Management）の方式が提案されている。ＡＱＭとは、キューにバッファできる最大のパケット量やパケット破棄率を動的に変更することでパケットのバッファ量を制御する手法である。ＡＱＭの一つに、通信フロー間の公平性が高く、キューイング遅延を低減するＦＱ＿ＣｏＤｅｌ（Flow Queue Control Delay）がある（非特許文献２等参照）。ＦＱ＿ＣｏＤｅｌは、通信フロー毎にキューを分類し、それぞれのキューはＣｏＤｅｌというＡＱＭ方式によってキュー管理がなされる。ＣｏＤｅｌは、パケットがキューに入ってから出るまでの滞在時間が、ある閾値を一定時間超えた場合にキューの先頭からパケットを破棄、又はマーキングする手法である。各キューからのパケット排出スケジューリングには、パケット単位ではなく、データ量単位で順番にパケットを取り出すＤＲＲ（Deficit Round Robin）という手法を用いるため、通信フロー間の公平性が高く、キューイング遅延が閾値を超えることを防ぐ。ＣｏＤｅｌ同様にキューイング遅延に応じて制御を行うＡＱＭアルゴリズムであるＰＩＥ（Proportional Integral controller Enhanced）は、パケットの排出量と現在のキュー長から、キューイング遅延を計算し、キューイング遅延の増加によってパケット破棄率を上昇させるＲＥＤ（Random Early Detection）を実施する（非特許文献３等参照）。

cisco systems, "DIFFSERV-THE SCALABLE END-TO-END QUALITY OF SERVICE MODEL," 2005, [online], [平成27年7月6日検索], インターネット<URL:http://www.cisco.com/en/US/technologies/tk543/tk766/technologies_white_paper09186a00800a3e2f.pdf> T. Hoeiland-Joergensen et al., "The FlowQueue-CoDel Packet Scheduler and Active Queue Management Algorithm draft-ietf-aqm-fq-codel-06," IETF Internet-Draft （work in progress）, Mar. 2016, [online], [平成27年7月6日検索], インターネット<URL:https://tools.ietf.org/html/draft-ietf-aqm-fq-codel-06> R. Pan et al., "Proportional Integral Controller Enhanced （PIE）: A Lightweight Control Scheme to Address the Bufferbloat Problem", IETF RFC 8033, Feb. 2017, [online], [平成27年7月6日検索], インターネット<URL:https://tools.ietf.org/html/rfc8033#ref-HPSR-PIE>

近年、３ＧＰＰ（The3rdGenerationPartnershipProject）にて５Ｇ（第５世代移動体通信システム）の標準化が進んでいる。３ＧＰＰでは、最大スループット２０Ｇｂｐｓ、平均スループット１００Ｍｂｐｓを５Ｇの要求条件としている。５Ｇでは高速通信を実現するために２８ＧＨｚ帯などの周波数帯の利用を想定しており、既存のＬＴＥ（Long Term Evolution）と比較して、電波の直進性が高く、面的なエリア構築が困難という特徴がある。したがって、５Ｇ普及の初期段階では、ＬＴＥサービスと併用し、高速通信の需要の高いエリアにスポット的に５Ｇサービスが展開されると想定される。

ＬＴＥセルから５Ｇセルへハンドオーバした場合、通信帯域は数十Ｍｂｐｓから数Ｇｂｐｓと大きく変動する。また、５Ｇではこれまでより高い周波数帯を利用するため、遮蔽物があると急激にスループットが低下することが想定される。このように５Ｇではこれまでのモバイルアクセスネットワークよりも急激な帯域、遅延などの変動が生じる。このような通信品質の変動においても、１Ｇｂｐｓ以上の通信速度を提供するためには、基地局やモバイルコアノードにおいて十分なパケットバッファを確保することが求められる。

一方で、バッファの増大は通信遅延の増加を招くため、Ｗｅｂ閲覧、ＩＰ電話、ライブストリーミングなど、リアルタイム性が要求されるアプリケーションでは、バッファは小さい方が望ましい。特に前述の１Ｇｂｐｓ以上の高速通信と低遅延を要求する通信が同じボトルネックリンクを共有する場合、ルータなどで過剰にパケットがバッファされ、遅延が大きく悪化するＢｕｆｆｆｅｒｂｌｏａｔが生じることが知られている。従って高スループットを要求するアプリケーションと低遅延を要求するアプリケーションを共存させる仕組みが求められる。

現在のインターネット通信ではほとんどがベストエフォートで運用されており、また近年インターネット通信の暗号化が進んでいるため、通信種別を容易に判定することが困難となっている。ＤＰＩ（Deep Packet Inspection）によりパケットのペイロード部を識別、又は、通信種別ごとのパケット送信間隔や、パケット長などをパターン認識して通信を判別する手法があるが、ベストエフォートトラヒック内で特定の通信を優遇することになり、通信フロー毎の公平性が損なわれる。通信パターンで通信を判別する場合は判別の誤りにより、通信事業者の意図していない通信制御を行う可能性もある。また、暗号化された通信の解析は通信の秘密に抵触する恐れもある。

本発明は上記事情に鑑みてなされたものであり、その目的とするところは、通信フローに応じて、より効率的にパケットを転送することのできる通信装置及び通信方法を提供することにある。

上記目的を達成するために、本願発明に係る通信装置は、受受信したパケットを、端末及びサーバ並びにアプリケーションの何れかによるキュー要求に関するキュー要求情報に基づいて、いずれかのキューに振り分けるキュー分類部と、前記キュー毎に異なる条件により、前記キューに蓄積された前記パケットの破棄又は輻輳マーキングするかどうかの遅延判定を行うキュー管理部と、所定の計測間隔の間にキューに追加された通信フローの種類をフロー数として算出するとともに、各キューの通信フロー数から算出される重みに基づいて、いずれのキューに蓄積されたパケットを排出するかどうかを決定するスケジューリング部と、を備え、前記異なる条件は、許容キューイング遅延の条件、及び最大キューサイズの条件のいずれかであることを特徴とする。

また、本願発明に係る通信方法は、受信したパケットを、端末及びサーバ並びにアプリケーションの何れかによるキュー要求に関するキュー要求情報に基づいて、いずれかのキューに振り分けるステップと、前記キュー毎に異なる条件により、前記キューに蓄積された前記パケットの破棄又は輻輳マーキングするかどうかの遅延判定を行うステップと、所定の計測間隔の間にキューに追加された通信フローの種類をフロー数として算出するとともに、各キューの通信フロー数から算出される重みに基づいて、いずれのキューに蓄積されたパケットを排出するかどうかを決定するステップと、を備え、前記異なる条件は、許容キューイング遅延の条件、及び最大キューサイズの条件のいずれかであることを特徴とする。

本発明によれば、通信フローに応じて、より効率的にパケットを転送することができる。

本実施形態に係る通信システムの構成について示す概略図 通信装置の機能を示すブロック図 通信装置におけるパケットの処理を説明するための概略図 キュー分類部の機能の詳細を示すブロック図 キュー分類部を利用した通信システムの処理を示すシーケンス図 ＩＰパケットの構成例について示す図 オプション領域に保存されるキュー要求情報の一例を示す図 オプション領域に保存されるキュー要求情報の一例を示す図 キュー要求データベースの構成の一例について示す図 キュー要求データベースの構成の一例について示す図 キュー分類部の第１変形例の機能構成について示すブロック図 キュー分類部の第１変形例を用いた通信システムの処理を示すシーケンス図 通信システムの変形例の構成について示す概略図 キュー分類部の第２変形例の機能構成を示すブロック図 通信システムの変形例に係る処理を示すシーケンス図 キュー管理部の機能構成の一例を示すブロック図 キュー管理部の処理を示すフローチャート ハッシュテーブルの例を示す図 スケジューリング部の処理の一例を示すフローチャート 重みを更新する処理について示すフローチャート 重みを更新する処理により算出された重みの例を示す表 スケジュールされたパケット排出順について示す図 キュー管理部の第１変形例の機能構成を示すブロック図 キュー管理部の第２変形例の機能構成を示すブロック図 キュー管理部の第３変形例の機能構成を示すブロック図 キュー管理部の第３変形例の処理を示すフローチャート キューイング遅延の例について示すグラフ 端末及び通信装置の機能を示すブロック図

以下に、本発明の実施形態について図面を参照しつつ説明する。説明において同様の要素には同一の符号を付して、重複する説明を適宜省略する。

＜通信システム及び通信装置の概要＞
図１は、本実施形態に係る通信システム１０の構成について示す概略図である。この図に示されるように、通信システム１０は、サーバ装置１１と、インターネット１２と、モバイルコアネットワーク１３と、通信装置１００と、無線基地局１４と、端末５０とにより構成されている。サーバ装置１１、通信装置１００、無線基地局１４及び端末５０は、それぞれ、主に半導体装置で構成され、ＣＰＵ（Central Processing Unit）、ＲＡＭ（Random Access Memory）等の揮発性記憶装置、ハードディスクやフラッシュメモリ等の不揮発性記憶装置、及び外部との通信のための接続を行う通信インターフェースを有する、いわゆる情報処理機器として構成されていてもよい。

モバイルコアネットワーク１３は、例えば携帯電話等が利用する移動体通信網とすることができる。モバイルコアネットワーク１３及びインターネット１２は、通信ネットワークであり、例えばＴＣＰ（Transmission Control Protocol）／ＩＰ（Internet Protocol）プロトコルにより通信接続を行う通信ネットワークとすることができる。

端末５０は無線基地局１４、通信装置１００、モバイルコアネットワーク１３を経由して、インターネット１２上のサーバと通信を行う。通信装置１００の配置場所は、無線基地局１４とモバイルコアネットワーク１３の間に限られず、例えば無線基地局１４またはモバイルコアネットワーク１３のノード（例えばＬＴＥにおけるＥＰＣのＳ／Ｐ−ＧＷなど）と統合する場合、モバイルコアネットワーク１３とインターネット１２の間に配置することとしてもよい。通信システム１０は図１の構成に限られず、サーバ装置１１及び端末５０等の通信端末間を通信装置１００を介して通信接続される構成であればよい。

図２は、通信装置１００の機能を示すブロック図である。通信装置１００は、パケット受信部１０１、キュー分類部１１０、キュー管理部１３０、スケジューリング部１６０及びパケット送信部１０２を有している。パケット受信部１０１は、例えばモバイルコアネットワーク１３又は無線基地局１４からの通信パケットを受信する。キュー分類部１１０は、受信したパケットのキュー要求に関するキュー要求情報に基づいて、パケットをいずれかのキューに振り分ける。キュー管理部１３０は、キュー毎に異なる条件により、キューに蓄積されたパケットの破棄又は輻輳マーキングするかどうかの遅延判定を行う。異なる条件は、許容キューイング遅延の条件や最大キューサイズの条件等とすることができる。スケジューリング部１６０は、キューに蓄積されたパケットを排出するかどうかを決定する。パケット送信部１０２は、排出が決定されたキューから、例えば無線基地局１４又はモバイルコアネットワーク１３にパケットを送信する。

図３は、通信装置１００におけるパケットの処理を説明するための概略図である。この図に示されるように、パケット受信部１０１が受信したパケットをキュー分類部１１０が、端末５０、サーバ装置１１やアプリケーションなどのキュー要求に応じてパケットをキューに振り分ける。それぞれのキューはキュー毎に異なる許容キューイング遅延パラメータや最大キューサイズを有し、キュー管理部１３０はそれぞれのキューを独立に管理する。スケジューリング部１６０は、どのキューからどれだけのパケットを排出するかを決定する。各キューからのパケット排出量は、各キューを利用する通信フロー数に比例してパケット排出量を多くする。排出が決定したパケットは、パケット送信部１０２により送信される。

キュー管理部１３０は、通信フロー毎のキュー要求（低遅延、高スループット等）に応じて異なるキューを提供し、キューに応じた許容キューイング遅延の違いによってパケット処理方法を変えることができる。例えば低遅延を要求する通信フローに対応するキューは、許容キューイング遅延を小さくし、輻輳時でも、積極的にパケットをドロップまたは輻輳通知のマーキングを行うことで、スループットを犠牲にして低遅延を維持することができる。高スループットを要求する通信フローに対応するキューは、許容キューイング遅延を大きくすることで、輻輳時にパケットがキューに溜り、遅延の悪化を招くが、輻輳解消時にキューに溜まったパケットが送信されるため、高スループット通信を可能とする。

各キューからのパケット送信量に関し、例えば、各キューを利用する通信フロー数に基づいて重み付けをすることで、通信フロー間で公平にパケットをキューから排出することができる。これにより、通信フロー数に応じて、より効率的にパケットを転送することができる。また、同一優先度のパケットが混在する通信システム１０において、特定の通信を優先、帯域保証などの優遇を行うことなく、通信フロー毎のキュー要求に沿ったパケット処理が可能となる。

＜キュー分類部＞
図４は、キュー分類部１１０の機能の詳細を示すブロック図である。この図に示されるように、キュー分類部１１０は、オプション確認部１１１及び要求確認部１１３を有している。通信装置１００は、更にキュー分類部１１０と通信するキュー要求データベース１１２を有していてもよい。キュー要求データベース１１２は、通信フロー情報とキュー要求情報との対応付けを記憶する。オプション確認部１１１は、パケットのオプション領域にキュー要求情報が付加されているかどうかを判定し、キュー要求情報が付加されている場合にはキュー要求データベース１１２に登録し、対応するキューにパケットを送信する。要求確認部１１３は、通信フローが登録されているかどうかを参照し、登録されている場合には対応するキューにパケットを送信する。つまり、キュー分類部１１０は、受信したパケットに保存されたキュー要求情報に基づいて、パケットをいずれかのキューに振り分けることができる。また、キュー分類部１１０は、キュー要求データベース１１２に保存された情報に基づいて、通信フロー情報に対応するパケットを振り分けることができる。

サーバ装置１１又は端末５０は、通信フローのキュー要求であるキュー要求情報をＴＣＰ又はＩＰパケットのオプション領域に付加し、パケットを送信する。キュー要求情報が付加されたＩＰパケットは、通信装置１００のキュー分類部１１０にてキュー要求情報の判定が行われる。

図５は、キュー分類部１１０を利用した通信システム１０の処理を示すシーケンス図である。この図に示されるように、まず、ステップＳ１１において、サーバ装置１１がキューのキュー要求情報をＩＰパケットに付加し、ステップＳ１２において、インターネット１２及びモバイルコアネットワーク１３を介して、通信装置１００に送信する。ＩＰパケットは、図６に示されるように、例えばＩＰヘッダ部のオプション領域２１やＴＣＰヘッダのオプション領域２２を有している。図７及び８は、オプション領域２１又は２２に保存されるキュー要求情報の一例をそれぞれ示す図である。図７に示すように、オプション領域２１又は２２は、オプション番号及びオプション領域長さを保存する領域を有し、更に予め定められた、例えば低遅延向け、広帯域向け、標準等の要求クラスを指定する領域を有していてもよい。また図８に示すように、オプション番号及びオプション領域長さを保存する領域を有すると共に、最大キュー長、許容キューイング遅延、遅延測定間隔等のキューイング方式又はキューイング方式毎のパラメータを直接指定することとしてもよい。

図５に戻り、ＩＰパケットを受信した通信装置１００のオプション確認部１１１は、ステップＳ１３において、オプション領域２１又は２２にキュー要求情報が付加されているかどうかを判定し、キュー要求情報が付加されている場合には、ステップＳ１４において、キュー要求データベース１１２に登録する。つまり、キュー分類部１１０は、キューに振り分けられるパケット内に保存された情報に基づいてキュー要求データベース１１２を更新する。

図９及び１０は、キュー要求データベース１１２の構成の一例について示す図である。図９に示されるようにキュー要求データベース１１２は、送信ＩＰ、宛先ＩＰ、送信ポート、宛先ポート、プロトコル、キュー制御及び最新パケット到着時刻を有することができる。ここで送信ＩＰ、宛先ＩＰ、送信ポート、宛先ポート及びプロトコルは５ｔｕｐｌｅといい、これにより通信フローを特定する。図１０は、キュー要求データベース１１２が、５ｔｕｐｌｅの個別の項目の代わりに、５ｔｕｐｌｅのハッシュ値を登録して通信フローを特定することとしてもよい。ハッシュ値を用いることでデータベース参照の計算量が軽減され、高速に処理可能となる。本実施形態における「通信フロー」の用語は、５ｔｕｐｌｅが同一であるパケットのグループを示すものとしてもよい。また、５ｔｕｐｌｅのハッシュ値が同一であるパケットのグループを示すものとしてもよい。またキュー要求データベース１１２にはパケット到達時のタイムスタンプ値を登録しておき、一定時間、通信フローからの要求がない、またはパケットが送られてこない場合には、キュー要求データベース１１２からその通信フローの登録を削除してもよい。

図５に戻り、ステップＳ１５において、オプション確認部１１１が、対応するキューにパケットを送信する。ステップＳ１７において、ＩＰパケットは、対応するキューがスケジューリング部１６０によりスケジュールされた際に、許容キューイング遅延未満であれば端末５０に送信される。

次にステップＳ１９において、サーバ装置１１が、オプション領域２１又は２２にキュー要求情報が付加されていない、同一通信フローのＩＰパケットを送信する。ＩＰパケットを受信したオプション確認部１１１は、ステップＳ２１において、オプション領域２１又は２２に要求が付加されているかどうかを判定し、要求が付加されてない場合には、ステップＳ２２において、要求確認部１１３に要求の有無を確認する。要求確認部１１３は、ステップＳ２３において、キュー要求データベース１１２を参照し、通信フローが登録されているかどうかを確認する。通信フローが登録されている場合には、ステップＳ２４において、通信フローに対応する要求キューにＩＰパケットを送信する。ステップＳ２５において、ＩＰパケットは、対応するキューがスケジューリング部１６０によりスケジュールされた際に、許容キューイング遅延未満であれば端末５０に送信される。

ステップＳ２６において、サーバ装置１１が、要求解除の情報を、例えばＩＰパケットのオプション領域２１又は２２に付加し、ステップＳ２７においてＩＰパケットを送信する。ＩＰパケットを受信したオプション確認部１１１は、ステップＳ２８においてオプション領域２１又は２２の内容を確認し、要求解除である情報であることを判定すると、ステップＳ２９においてキュー要求データベース１１２に対して、対応する通信フローと要求キューの登録の削除を要求する。キュー要求データベース１１２では対応する登録の削除を行う。上述のシーケンスでは、通信フローの初めだけ要求通知を行えばよいが、全てのパケットについてデータベース参照を行うこととなるため、オーバーヘッドが生じる。

＜キュー分類部の第１変形例＞
図１１は、キュー分類部１１０の第１変形例の機能構成について示すブロック図である。この図に示されるようにキュー分類部１１０の第１変形例はオプション確認部１１１を有している。オプション確認部１１１は、パケットのオプション領域２１又は２２のキュー要求情報を確認し、対応するキューにパケットを振り分ける。つまり、キュー分類部１１０は、受信したパケットに保存されたキュー要求情報に基づいて、パケットをいずれかのキューに振り分けることができる。

図１２は、図１１のキュー分類部１１０の第１変形例を利用した通信システム１０の処理を示すシーケンス図である。この図に示されるように、まず、ステップＳ３１において、サーバ装置１１がキュー要求情報をＩＰパケットに付加し、ステップＳ３２においてインターネット１２及びモバイルコアネットワーク１３を介して、通信装置１００に送信する。次にＩＰパケットを受信した通信装置１００のオプション確認部１１１は、ステップＳ３３において、オプション領域２１又は２２のキュー要求情報を確認し、ステップＳ３５において、対応するキューにパケットを送信する。ステップＳ３６において、ＩＰパケットは、対応するキューがスケジューリング部１６０によりスケジュールされた際に、許容キューイング遅延未満であれば端末５０に送信される。

このように、図１１及び図１２に示されるキュー分類部１１０の第１変形例では、全てのパケットにキュー要求情報を付加し、キュー分類部１１０では、パケットのオプション領域を見て要求キューへの振り分けが行われる。この変形例では、全てのパケットにキュー要求情報を付加する必要があるが、データベース参照のオーバーヘッドがなく、処理の効率化を図ることができる。

＜キュー分類部の第２変形例＞
図１３は、通信システム１０の変形例の構成について示す概略図である。この通信システム１０の変形例の構成は、図１の構成と比較して、インターネット１２及びモバイルコアネットワーク１３に接続された通信管理装置２００を更に有する点で異なっている。他の構成については図１の構成と同様であるため、重複する説明を省略する。通信管理装置２００は、主に半導体装置で構成され、ＣＰＵ、ＲＡＭ等の揮発性記憶装置、ハードディスクやフラッシュメモリ等の不揮発性記憶装置、及び外部との通信のための接続を行う通信インターフェースを有する、いわゆる情報処理機器として構成されていてもよい。通信管理装置２００は、例えば端末５０又はサーバ装置１１からの要求により、通信装置１００のキュー要求データベース１１２を更新する。

図１４は、キュー分類部１１０の第２変形例の機能構成を示すブロック図である。キュー分類部１１０の第２変形例は、例えば図１３の通信システム１０の変形例に適用される構成である。この図に示されるように、キュー分類部１１０は、オプション確認部１１１及びキュー要求データベース１１２を有している。オプション確認部１１１及びキュー要求データベース１１２の詳細については、図４とその対応する説明で示したものと同様であるため、重複する説明を省略する。このような構成により、キュー分類部１１０は、受信したパケットに保存されたキュー要求情報に基づいて、パケットをいずれかのキューに振り分けることができる。

図１５は、図１３に示した通信システム１０の変形例に係る処理を示すシーケンス図である。この図に示されるように、まず、ステップＳ４１において、サーバ装置１１が、通信管理装置２００にキュー要求情報を含むサービス要求を送信する。サービス要求を受信した通信管理装置２００は、ステップＳ４２において、通信装置１００のキュー要求データベース１１２に、サービス要求のキュー要求情報の反映を要求し、キュー要求データベース１１２はサービス要求のキュー要求情報を反映する。

次に、サーバ装置１１が、ステップＳ４３においてインターネット１２及びモバイルコアネットワーク１３を介して、通信装置１００にＩＰパケットを送信する。ＩＰパケットを受信した通信装置１００の要求確認部１１３は、ステップＳ４４において、キュー要求データベース１１２を参照し、通信フローが登録されているかどうかを確認する。通信フローが登録されている場合には、ステップＳ４５において、通信フローに対応する要求キューにＩＰパケットを送信する。ステップＳ４６において、ＩＰパケットは、対応するキューがスケジューリング部１６０によりスケジュールされた際に、許容キューイング遅延未満であれば端末５０に送信される。

このように、図１３及び図１４に示した通信システム１０の変形例の処理では、端末５０又はサーバ装置１１が直接パケットにキュー要求情報を付加するのではなく、インターネット１２にアクセス可能な通信管理装置２００にキュー要求情報を通知する。通知を受けた通信管理装置２００は、端末５０−サーバ装置１１間の通信装置１００のキュー要求データベース１１２を更新する。つまり、キュー分類部１１０は、いずれのキューにも振り分けられないパケットに保存された情報に基づいてキュー要求データベース１１２を更新する。端末５０がどの通信装置１００の配下にいるか、通信管理装置２００はわからないため、キュー要求データベース１１２の更新方法としては、図５のシーケンスのように、キュー要求情報を付加したＩＰパケットを通信管理装置２００が送信する方法が考えられる。端末５０宛に送信したＩＰパケットは、必ず端末５０上位の通信装置１００を通過するため、端末５０の利用する通信装置１００のキュー要求データベース１１２を更新することが可能である。ＬＴＥではＩＰパケットはＧＴＰ（GPRS Tunneling Protocol）によりカプセル化されるが、ＧＴＰヘッダからヘッダ長が判るため、カプセル化されているＩＰパケットの通信フローを識別することは容易である。

ＩＰパケットを用いてキュー要求データベース１１２の更新を行わない場合、例えば端末５０の利用する基地局ＩＤ（Cell ID）などを用いて端末５０の利用する通信装置１００を特定することが考えられる。予め、通信装置１００配下の基地局情報を通信装置１００に登録しておき、要求のあった端末５０が利用する基地局ＩＤを取得して通信装置１００を特定する。この通信システム１０の変形例では、通信管理装置２００のＡＰＩを公開し、特定のアプリケーション起動時や、端末５０からの設定によって通信装置１００の制御を変更することを想定している。

＜キュー管理部＞
図１６は、キュー管理部１３０の機能構成の一例を示すブロック図である。この図に示されるように、キュー管理部１３０は、タイムスタンプ部１３１と、通信フロー数計測部１３２と、キューｑ１〜ｑ５と、キュー滞在時間判定部１３４と、パケット破棄部１３５と、輻輳マーキング部１３６と、を有している。タイムスタンプ部１３１は、受信したパケットのパケット到達時刻のタイムスタンプ値を記憶させる。通信フロー数計測部１３２は、キューｑ１〜ｑ５の種類の数だけあり、例えばそれぞれのキューｑ１〜ｑ５を利用する通信フローの数を計測する。キューｑ１〜ｑ５は、キュー毎に設定された処理規則に基づいてパケットを蓄積及び排出する。キュー滞在時間判定部１３４は、許容キューイング遅延の時間を超えているかどうかを判定する。パケット破棄部１３５はパケットを破棄する。輻輳マーキング部１３６はパケットにマーキングを行う。キューｑ１〜ｑ５は、それぞれ目的の異なる複数クラスが独立して管理される。例えば、低遅延の処理を行う低遅延通信キュー、高スループットの処理を行う高スループットキュー、高ジッタに対応した処理を行う高ジッタキュー、通常の処理を行うデフォルトキュー等のクラスに分けることができる。各キューは、それぞれ目的に合わせて異なる許容キューイング遅延とキューイング遅延計測間隔とが定められている。

図１７は、図１６のキュー管理部１３０の処理を示すフローチャートである。このフローチャートに示されるように、まずステップＳ５１においてタイムスタンプ部１３１がパケット到達時刻のタイムスタンプ値を記憶して、ステップＳ５２において、キューｑ１〜ｑ５のうち、キュー分類部１１０にて振り分けられたキューにパケットを送信する。各パケットでは、まず通信フロー数算出更新処理Ｓ５３を実行する。

通信フロー数算出更新処理Ｓ５３の一例について説明する。各通信フローは、いつ通信が終了したかを通信装置１００で判定することは困難であるため、キューを利用する通信フローを厳密に算出することは難しい。そこでフロー計測間隔Ｔ＿ｆｌｏｗの間にキューに追加された通信フロー（パケットの５ｔｕｐｌｅ）の種類を通信フロー数とする。具体的な手順としては以下の通りである。
１．パケットの５ｔｕｐｌｅをハッシュ化し、ハッシュテーブルを参照。ハッシュテーブルにはフローの有無を示す１ビットと、タイムスタンプ値が保存される。
２．ハッシュテーブルのタイムスタンプ値を更新し、通信フローが無ければ、フラグを立て、通信フロー数に１を加算する。
３．一定時間タイムスタンプ値の更新がない場合、通信フロー数から１を減算し、フラグを０に戻す。
４．Ｔ＿ｆｌｏｗ経過時の通信フロー数をキューを利用する通信フロー数とする。

図１８は、ハッシュテーブルの例が示されている。この図に示されるようにハッシュテーブルは、５ｔｕｐｌｅハッシュ値と、フロー有無と、タイムスタンプ値とのフィールドで構成されている。

図１７に戻り、通信フロー数算出更新処理Ｓ５３が終了すると、ステップＳ５４において、パケットは要求されたキューの末尾に挿入される。次に、ステップＳ５５において、キューの先頭パケットのタイムスタンプ値からキュー滞在時間Ｔｓｔａｙを算出し、ステップＳ５６において算出されたキュー滞在時間Ｔｓｔａｙと最小キューイング時間Ｔｍｉｎとを比較する。キュー滞在時間Ｔｓｔａｙが最小キューイング時間Ｔｍｉｎより小さい場合には、ステップＳ５７において最小キューイング時間Ｔｍｉｎをキュー滞在時間Ｔｓｔａｙで更新し、ステップＳ５８に移行する。キュー滞在時間Ｔｓｔａｙが最小キューイング時間Ｔｍｉｎ以上の場合には、ステップＳ５８に移行する。

次にステップＳ５８において、現在時が前回計測時からキューイング遅延計測間隔を超えたか否か、すなわち許容キューイング遅延時間を超えている時間がキューイング遅延計測間隔を超えたか否かを判定する。前記計測時からキューイング遅延計測間隔を超えていない場合には、ステップＳ６５に移行する。一方、前記計測時からキューイング遅延計測間隔を超えている場合には、ステップＳ５９に移行する。次にステップＳ５９において、最小キューイング時間Ｔｍｉｎと許容キューイング遅延とを比較する。最小キューイング時間Ｔｍｉｎが、許容キューイング遅延以上の場合、すなわち最小キューイング時間Ｔｍｉｎがキューイング遅延計測間隔の間に渡って許容キューイング遅延を超えた場合には、ステップＳ６０においてキューイング遅延計測間隔を短縮し、ステップＳ６１において、ＥＣＮ（Explicit Congestion Notification）対応パケットであるかどうかを判定する。ＥＣＮ対応パケットでない場合には、ステップＳ６２においてパケットを破棄し、ステップＳ５１の処理に戻る。ＥＣＮに対応したパケットであれば、ステップＳ６３において輻輳マーキングを行い、引き続きステップＳ６５においてパケットをキューから排出する。最小キューイング時間Ｔｍｉｎが許容キューイング遅延以上であっても、許容キューイング遅延時間を超えている時間がキューイング遅延計測間隔未満であれば、ステップＳ６０の処理は行わず、パケットをキューから排出する（前記ステップＳ５８参照）。前記ステップＳ５９において最小キューイング遅延時間Ｔｍｉｎがキューイング遅延計測間隔にわたって許容キューイング遅延より小さい場合には、ステップＳ６４においてキューイング遅延計測間隔をリセットし、ステップＳ６５においてパケットをキューから排出する。なお、図１７の例では、キューイング遅延計測時間におけるキューイング遅延の最小値を用いたが、平均値、最大値、平坦化した遅延などを用いても良い。

上述のように、各キューは独立にパケット処理を行うため、許容キューイング遅延の短いキューは輻輳時にパケット破棄されやすく、遅延の増大を防ぎ、許容キューイング遅延の長いキューは輻輳時でもパケット破棄が行われにくいため、遅延の悪化を招くが、転送レートの低下を防ぐことができる。

図１９は、スケジューリング部１６０の処理の一例を示すフローチャートである。スケジューリング部１６０は、各キューの通信フロー数から算出される重みに基づいて、いずれのキューに蓄積されたパケットを排出するかどうかを決定することとしてもよい。このフローチャートに示されるように、スケジューリング部１６０は、まずステップＳ７１において通信フロー数に更新がないかどうかを判定する。通信フロー数に更新がない場合には、ステップＳ７３に移行し、通信フロー数に更新があった場合には、ステップＳ８０において重みＷｉを更新し、ステップＳ７３に移行する。

図２０は、重みＷｉを更新する処理Ｓ９０について示すフローチャートである。このフローチャートに示されるように、重みＷｉを更新する処理Ｓ９０は、ステップＳ９１においてｉに１を設定し、ステップＳ９２において、通信フロー数が最大のキューｑｍａｘにおける通信フロー数ｆｍａｘをキューｑｉの通信フロー数ｆｉで除した値を代入する。ステップＳ９３においてｉがｎに達している場合には、処理Ｓ９０を終了し、ｎに達していない場合には、ステップＳ９１に戻り、ｉに１を加算して、処理を繰り返す。

図２１は、重みＷｉを更新する処理Ｓ９０により算出された重みＷｉの例を示す表である。この表に示されるように、４つのキューｑｉのうち、キューｑ１が最大通信フロー数ｆｍａｘ＝１００であるため、キューｑｍａｘとなり、他のキューｑｉの重みＷｉ＝ｆｍａｘ／ｆｉは表に示される通りとなる。

ステップＳ７３では、通信フロー数が最大のキューｑｍａｘから最小パケット排出量をスケジューリングする。ステップＳ７４においてｉに１を代入し、ステップＳ７５においてＣｉに１を加算する。Ｃｉは、キューｑｉにおいて、通信フロー数が最大のキューｑｍａｘからスケジューリングされた最小パケット排出量のカウント数（初期値０）である。つまり、キューｑｉから排出される最小パケット排出量の数である。

ステップＳ７６において重みＷｉとＣｉとを比較し、重みＷｉがＣｉ以上の場合にはステップＳ７９に移行する。重みＷｉがＣｉより小さい場合には、ステップＳ７７において、ｑｉから最小パケット排出量をスケジューリングする。引き続き、ＣｉをＣｉ−Ｗｉで更新し、ステップＳ７９に移行する。ステップＳ７９では、ｉがキューの数ｎであるかを判定し、ｎでない場合には、ステップＳ７４に戻り、ｉに１を加算して処理を繰り返す。

ｉがキューの数ｎである場合には、ステップＳ８０において、すべてのキューにパケットが存在しないかどうかを判定し、肯定的な判定の場合には処理を終了する。否定的な判定の場合には、ステップＳ７１に戻り処理を繰り返す。このように、各キューからのパケット排出量は、キュー毎の通信フロー数によって重み付けしてスケジューリングされることとしてもよい。キュー毎の通信フロー数の偏りによるキューイング遅延のジッタを低減するため、キューの選出はラウンドロビンではなく、最小パケット排出値（例えばＭＴＵサイズ、パケット単位）をキュー毎の通信フロー数に比例した頻度で等間隔に排出することができる。

上述のように、通信フロー数が最大のキューを基準に、最大の通信フロー数ｆｍａｘを各キューの通信フロー数ｆｉで割った値×最小パケット排出値のパケットを通信フロー数が最大のキューｑｍａｘから排出した際に各キューからパケットが排出されるようにスケジューリングを行うこととしてもよい。スケジューリング部１６０の処理は、図１９のフローチャートに限られず、その他の通信フロー数によって重み付けによる処理や重み付けを行わないその他の処理を用いることができる。

図２２は、上述のスケジューリング部１６０の処理によりスケジュールされたパケット排出順について示す図である。同じ塗りつぶし又はハッチングは同じキューｑｉからの排出を示している。この図に示されるように、キューｑｍａｘであるキューｑ１は、毎回スケジュールされ、他のキューｑｉは、重みＷｉの値が大きくなるにつれて、スケジュールされる頻度が減っているのが分かる。

＜キュー管理部の第１変形例＞
図２３は、キュー管理部１３０の第１変形例の機能構成を示すブロック図である。この図に示されるように、キュー管理部１３０は、タイムスタンプ部１３１と、端末識別部１３７と、通信フロー識別部１３８と、キューｑ１〜ｑ４と、キュー滞在時間判定部１３４と、パケット破棄部１３５と、輻輳マーキング部１３６と、を有している。タイムスタンプ部１３１、キュー滞在時間判定部１３４、パケット破棄部１３５及び輻輳マーキング部１３６は、図１６及びその対応する説明で説明したものと同様であるため、重複する説明を省略する。

端末識別部１３７は、いずれの端末５０と送受信されるパケットであるかを識別する。端末５０の識別方法はＬＴＥであれば、例えば、端末５０毎に決定されるＧＴＰプロトコルヘッダ内のＴＥＩＤによって識別可能である。通信フロー識別部１３８は、端末５０内での異なる通信フローを識別する。通信フローの識別には、上述した５ｔｕｐｌｅ等を用いることができる。

キューｑ１〜ｑ４は端末５０毎に設けられ、更にその中で通信フロー別に管理されることとしてもよい。例えば、キューｑ１〜ｑ４は端末Ａ〜Ｄの通信のためのキューとすることができる。つまり、キューｑｉの１つは、一の端末５０の通信に対して割り当てられる。キュー毎の制御は図１６及び１７に示されるキュー管理部１３０の説明と同様である。各キューからのパケット排出量を決定するスケジューリングは、端末５０間の重みＷｉを等しくすることで、端末５０毎に公平に帯域を割当てることができる。

図１６に示されるキュー管理部１３０の実施形態のようにクラス別にキューを分ける場合、フロー毎には帯域を公平に割り当てるが、一つの端末５０が多数の通信を行う場合、通信数が少ない端末５０に割当てる帯域が減ってしまう恐れがある。また端末５０別に異なるキュー制御を実施する場合や、特定アプリケーションの通信のみ異なるキュー制御を実施するといったことが、図２３に示されるキュー管理部１３０では容易に実現できる。一方で端末数や通信フロー数が多い場合、キュー管理の処理負荷が高くなってしまう、小規模なネットワークに適している。

＜キュー管理部の第２変形例＞
図２４は、キュー管理部１３０の第２変形例の機能構成を示すブロック図である。この図に示されるように、キュー管理部１３０は、タイムスタンプ部１３１と、端末識別部１３７と、通信フロー識別部１３８と、通信フロー数計測部１３２と、キューｑ１〜ｑ４と、キュー滞在時間判定部１３４と、パケット破棄部１３５と、輻輳マーキング部１３６と、を有している。タイムスタンプ部１３１、通信フロー数計測部１３２、キュー滞在時間判定部１３４、パケット破棄部１３５及び輻輳マーキング部１３６は、図１６のキュー管理部１３０の実施形態で説明したものと同様であるため、重複する説明を省略する。端末識別部１３７及び通信フロー識別部１３８については、図２３のキュー管理部１３０の第１変形例において説明したものと同様であるため、重複する説明を省略する。

キュー管理部１３０の第２変形例では、特定の端末５０及び特定の通信フローのみを個別にキュー管理し、その他の端末５０及びその他の通信フローは同じキュー（例えば、デフォルトキューｑ１）で管理する。複数の通信フローが混在するデフォルトキューのみパケット排出量の重みＷｉを決定するため、通信フロー数の計測を行うこととしてもよい。キュー管理数の最大値を設けることで、キュー管理の負荷を低減しつつ特定の端末５０及び通信フローごとの制御が可能となる。

＜キュー管理部の第３変形例＞
図２５は、キュー管理部１３０の第３変形例の機能構成を示すブロック図である。キュー管理部１３０の第３変形例では、送信スループットに基づいて最大キューサイズを決定することとすることができる。この図に示されるように、キュー管理部１３０は、パケット破棄部１３５と、輻輳マーキング部１３６と、通信フロー数計測部１３２、キューｑ１及びｑ２と、パケット排出量計測部１５１と、キューサイズ算出部１５２と、を有している。パケット破棄部１３５、輻輳マーキング部１３６及び通信フロー数計測部１３２は、図１６のキュー管理部１３０の実施形態で説明したものと同様であるため、重複する説明を省略する。

パケット排出量計測部１５１は、各キューｑｉにおけるパケット排出量を計測する。キューサイズ算出部１５２は、パケット排出量計測部１５１が計測したパケット排出量に基づいて最大キューサイズを決定する。

このキュー管理部１３０の第３変形例では、パケット到達時刻のタイムスタンプ記憶及び、キュー滞在時間の計測を行わないこととしている。その代わりにパケット排出量計測部１５１によって算出した送信スループットに基づいて、キューサイズ算出部１５２が、各キューの許容キューイング遅延に対応する最大キューサイズを決定する。最大キューサイズを超えてパケットがキューイングされる場合、パケットは破棄、又は輻輳マーキングが実施される。

パケット排出量は、以下の式（１）で計算される。

従って、通信フローが平等にパケットを排出する場合の各キューの平均パケット排出量は、式（２）のようになる。

これにより、各キューの最大サイズは、以下の式（３）で計算される。

また最大キューサイズに満たない場合でも、キューのパケット充填度に応じてランダムにパケットを破棄するＲＥＤなどのＡＱＭアルゴリズムを適用してもよい。

図２６は、図２５のキュー管理部１３０の第３変形例の処理を示すフローチャートである。このフローチャートに示されるように、まずステップＳ１０１において、キューｑｉのうち、キュー分類部１１０にて振り分けられたキューにパケットを送信する。次にステップＳ１０２において、現在キューにバッファしているデータ量とキューサイズを比較する。現在キューにバッファしているデータ量がキューサイズ以上である場合には、ステップＳ１０３に移行し、ＥＣＮ対応パケットであるかどうかを判定する。ＥＣＮ対応パケットでない場合には、ステップＳ１０４においてパケットを破棄する。ＥＣＮに対応したパケットであれば、ステップＳ１０５において輻輳マーキングを行い、ステップＳ１０６に移行する。

一方、現在キューにバッファしているデータ量がキューサイズ未満の場合には、ステップＳ１０６に移行に移行し、キューの通信フロー数を更新する。引き続きステップＳ１０７において、キューの末尾にパケットを挿入し、ステップＳ１０８においてパケットをキューから排出して、処理を終了する。このようなフローチャートの処理とすることにより、パケット処理の負荷を低減することができる。

なお、キュー管理及びスケジューリングを無線アクセス品質に基づいて行うこととしてもよい。この場合には、端末５０の保持する無線アクセス情報（端末カテゴリ、利用基地局（Cell ID）、利用周波数帯、ＣＱＩ（Channel Quality Indicator）、ＭＣＳ（Modulation and channel Coding Scheme）等）を通信装置１００や通信管理装置２００に送信する。

次に例えば、端末カテゴリの最大送受信スループット及び利用基地局、周波数帯の提供可能な最大送受信スループットに基づいて、端末５０毎のキューにおけるパケット排出量の重みを決定する。重みの例としては、４Ｇアクセス利用端末より５Ｇ利用端末のパケット排出量を多くする等がある。

＜無線アクセス情報を利用する例＞
また、別の例としては、無線アクセス情報を受信した通信装置１００や通信管理装置２００は、ＭＣＳの変動量を測定し、変動が大きいほど電波受信品質の変動が大きいことを示すため、該当キューの遅延測定間隔、または最大キューサイズの拡張を行い、無線アクセス区間の遅延揺らぎによるパケットロスを削減することとしてもよい。図２７は、この方法により制御した場合のキューイング遅延の例について示すグラフである。このグラフに示されるように測定間隔Ａでは、遅延は常に許容キューイング遅延未満なのでパケット破棄されない。測定間隔Ｂでは、許容キューイング遅延を一度超えているが、キューイング遅延の平均値は許容キューイング遅延未満なのでパケットは破棄されない。測定間隔Ｃでは、常に許容キューイング遅延を上回るため、パケットは破棄される。測定間隔Ｄでは平均値が許容キューイング遅延を超えているため、パケットは破棄される。測定間隔Ｅでは、測定間隔を拡張したことで、平均値が許容キューイング遅延を下回り、パケットは破棄されない。つまり、キューイング遅延の測定間隔を延長することで、一時的なキューイング遅延の増加が生じても輻輳による恒常的な遅延の増加が生じなければパケットが破棄されにくくなる。このように端末５０の無線アクセス情報に基づいて遅延判定が行われる間隔を変更することにより、より効率的にパケットを転送することができる。

各測定間隔におけるキューイング遅延は、この例では各計測区間のキューイング遅延の平均値を用いたが、各区間のキューイング遅延最小値、最大値、または平坦化した遅延（前回測定間隔におけるキューイング遅延×α＋今回測定間隔におけるキューイング遅延×（１−α））などを用いてもよい。

無線アクセス品質情報を通信装置１００へ送信する方法は例えば以下の３つがある。
１．インターネットアクセス可能な通信管理装置２００に送信する。
２．通信装置１００にて品質情報パケットを取り出すローカルブレイクアウト処理を行う。
３．ＬＴＥにおけるＲｘインターフェースを用い、ＰＣＲＦから通信装置１００へポリシー情報を送る。

１の場合には、図１３〜図１５に示した通信システム１０の変形例の処理と同様の処理により通信管理装置２００に送信することができる。

図２８は、上記２の場合について説明するための、端末５０及び通信装置１００の機能を示すブロック図である。通信装置１００は、図２と比較して、ローカルブレイクアウト判定部１０５及び端末品質管理部１０６を更に有している点で異なっている。ローカルブレイクアウト判定部１０５は、通常のパケットを受信した場合には、キュー分類部１１０にパケットを送信し、品質情報パケットを受信した際には端末品質管理部１０６に送信する。端末品質管理部１０６は、品質情報パケットに基づいて、キュー管理部１３０又はスケジューリング部１６０に対して、キュー制御のパラメータを変更する等の要求を行う。端末５０は品質情報を送信する際にローカルブレイクアウト用ＩＰアドレス、ポート番号を指定し、通信装置１００は、その情報から品質情報であることを検知し、通信装置１００内にパケットを取り込むことができる。

以上説明したように、本実施形態の通信装置１００及び通信方法では、通信フローに応じて、より効率的にパケットを転送することができる。

また、ＤｉｆｆＳｅｒｖをＰＱやＬＬＱのように優先処理、帯域確保を行うのではなく、許容キューイング遅延または最大キューサイズの違いによって分類し、各キューを利用する通信フローの数に比例して各キューからのパケット送信量の重み付けを行うことで、同一優先度のトラヒック（ベストエフォート等）においても、特定の通信が他の通信フローの帯域や遅延を悪化させることなく低遅延、高スループットなど目的に適したパケット処理ができる。これにより５Ｇの急激な帯域変動においても低遅延通信と高スループット通信を共存させることができる。

例えば許容キューイング遅延を小さくすることで輻輳時に直ぐにパケット破棄を行うため、スループットは低下するが、遅延の悪化を防ぐことができる。反対に許容キューイング遅延を大きくすると、輻輳時に遅延が増大するが、パケットロスが生じず、特にＴＣＰ通信のスループットが低下することを防ぐ。輻輳解消時には、キューに溜まっているパケットが送信されるため、即座に高スループット通信が可能となる。

ＤｉｆｆＳｅｒｖで用いられるＩＰパケットのＤＳＣＰ値は、通信キャリアやＩＳＰ間で独自に運用されているため、異なる事業者を跨いでパケット処理の要求を通知することが困難であるが、ＩＰパケットのオプション領域を用いる、又はインターネット１２アクセス可能な通信管理装置２００に要求通知を行うことで端末５０の通信品質要求を別事業者網を経由しても指定の通信装置１００にサービス要求を反映できる。

また、無線アクセス区間の通信品質情報をキュー管理に反映させることで、例えば遅延の変動が大きい無線品質の不安定な端末５０には、キューイング遅延の測定間隔を長くすることで、一時的にキューイング遅延が増加してもパケット破棄が生じない制御に変更することで、過剰なパケットロスやスループットの低下を低減することが可能となる。

１０…通信システム
１１…サーバ装置
１２…インターネット
１３…モバイルコアネットワーク
１４…無線基地局
５０…端末
１００…通信装置
１０１…パケット受信部
１０２…パケット送信部
１０５…ローカルブレイクアウト判定部
１０６…端末品質管理部
１１０…キュー分類部
１１１…オプション確認部
１１２…キュー要求データベース
１１３…要求確認部
１３０…キュー管理部
１３１…タイムスタンプ部
１３２…通信フロー数計測部
１３４…キュー滞在時間判定部
１３５…パケット破棄部
１３６…輻輳マーキング部
１３７…端末識別部
１３８…通信フロー識別部
１５１…パケット排出量計測部
１５２…キューサイズ算出部
１６０…スケジューリング部
２００…通信管理装置

Claims (6)

1. 受信したパケットを、端末及びサーバ並びにアプリケーションの何れかによるキュー要求に関するキュー要求情報に基づいて、いずれかのキューに振り分けるキュー分類部と、
   前記キュー毎に異なる条件により、前記キューに蓄積された前記パケットの破棄又は輻輳マーキングするかどうかの遅延判定を行うキュー管理部と、
   所定の計測間隔の間にキューに追加された通信フローの種類をフロー数として算出するとともに、各キューの通信フロー数から算出される重みに基づいて、いずれのキューに蓄積されたパケットを排出するかどうかを決定するスケジューリング部と、を備え、
   前記異なる条件は、許容キューイング遅延の条件、及び最大キューサイズの条件のいずれかである
   ことを特徴とする通信装置。
2. 前記キュー管理部は、端末から取得したＭＣＳ（Modulation and channel Coding Scheme）の変動を測定し、前記ＭＣＳの変動が大きい場合には前記遅延判定が行われる間隔を長くする
   ことを特徴とする請求項１記載の通信装置。
3. 前記キュー管理部は、送信スループットに基づいて最大キューサイズを決定する
   ことを特徴とする請求項１乃至２のいずれか一項に記載の通信装置。
4. 前記キュー分類部は、受信したパケットに保存された前記キュー要求情報に基づいて、前記パケットをいずれかのキューに振り分ける
   ことを特徴とする請求項１乃至３のいずれか一項に記載の通信装置。
5. 通信フロー情報とキュー要求情報との対応付けを記憶したキュー要求データベースを更に備え、
   前記キュー分類部は、前記キュー要求データベースに保存された情報に基づいて、前記通信フロー情報に対応するパケットを振り分ける
   ことを特徴とする請求項１乃至４のいずれか一項に記載の通信装置。
6. 受信したパケットを、端末及びサーバ並びにアプリケーションの何れかによるキュー要求に関するキュー要求情報に基づいて、いずれかのキューに振り分けるステップと、
   前記キュー毎に異なる条件により、前記キューに蓄積された前記パケットの破棄又は輻輳マーキングするかどうかの遅延判定を行うステップと、
   所定の計測間隔の間にキューに追加された通信フローの種類をフロー数として算出するとともに、各キューの通信フロー数から算出される重みに基づいて、いずれのキューに蓄積されたパケットを排出するかどうかを決定するステップと、を備え、
   前記異なる条件は、許容キューイング遅延の条件、及び最大キューサイズの条件のいずれかである
   ことを特徴とする通信方法。

Images