JP2006513663A - さまざまな輻輳要因を知らせる、パケットネットワークにおける輻輳通知のための方法及び装置 - Google Patents

さまざまな輻輳要因を知らせる、パケットネットワークにおける輻輳通知のための方法及び装置 Download PDF

Info

Publication number
JP2006513663A
JP2006513663A JP2004567274A JP2004567274A JP2006513663A JP 2006513663 A JP2006513663 A JP 2006513663A JP 2004567274 A JP2004567274 A JP 2004567274A JP 2004567274 A JP2004567274 A JP 2004567274A JP 2006513663 A JP2006513663 A JP 2006513663A
Authority
JP
Japan
Prior art keywords
congestion
data
unit
information
data unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2004567274A
Other languages
English (en)
Other versions
JP4174054B2 (ja
Inventor
ヘニング ヴィーマン,
ハネス エクシュトローム,
Original Assignee
テレフオンアクチーボラゲット エル エム エリクソン(パブル)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by テレフオンアクチーボラゲット エル エム エリクソン(パブル) filed Critical テレフオンアクチーボラゲット エル エム エリクソン(パブル)
Publication of JP2006513663A publication Critical patent/JP2006513663A/ja
Application granted granted Critical
Publication of JP4174054B2 publication Critical patent/JP4174054B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163In-band adaptation of TCP data exchange; In-band control procedures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

Abstract

ネットワーク内でデータユニットをルーティングする装置及び、ネットワーク内でデータユニットをルーティングする装置を制御する方法であって、装置1がルーティングデバイスにおける1つ以上の輻輳原因を特定可能であり、かつ1つ以上の転送されるデータユニットに輻輳原因情報を設定可能である。

Description

データユニットベースの通信ネットワークは広く知られている。データユニットベースの通信ネットワークの一例はいわゆるインターネットである。データユニットベースの通信において、送信側は送信データを複数の部分に分割し、これら部分をデータユニットに収納して、データユニットをネットワークへ送信する。データユニットは使用される通信プロトコルによって規定される構成を有し、かつ、ネットワークが各データユニットを所望の宛先、すなわち、送信側がそのデータの送信を所望する受信側へ転送可能なように、アドレス又はルーティング情報を含む。これは当技術分野において周知であるため、これ以上の詳細は説明しない。
様々な既知の通信プロトコルにおいては、このようなデータユニットはパケット、フレーム、セグメント、プロトコルデータユニット(PDU)等と呼ばれることもある。
本明細書及び特許請求の範囲において、”データユニット”という単語は、データユニット単位の通信ネットワークにおいて伝送に用いられる、そのような任意のデータ構成を総称するために用いられる。
通信ネットワークは一般に、複数のデータユニットを受信し、各データユニットに含まれるアドレス又はルーティング情報に従ってそれらを転送するように構成された複数のデバイスを有する。このようなデバイスは、ネットワークの形式及び用いられる通信プロトコルに応じて、ルータ、スイッチ等といった様々な名称を有する。本明細書及び特許請求の範囲において用いられる”ルーティングデバイス”又は”転送デバイス”という単語は、データユニットに含まれるルーティング又はアドレス情報に従って、そのデータユニットを受信し、転送する能力を有する任意のデバイスを総称するために用いられる。
そのような、データに基づく通信ネットワーク内において、輻輳という現象がよく知られている。輻輳は、データユニットの転送デバイスが、データユニットの過負荷に見舞われ、受信したデータユニットと同数のデータユニットを送信できないことを意味する。データ転送デバイスは通常、転送するデータユニットをバッファリングするためのバッファを有している。バッファのオーバフローは、輻輳発生原因の一例である。
既に述べたように、インターネットはデータユニットベースの通信ネットワークの一例である。インターネットにおいてデータユニットの伝送を規定するプロトコルはいわゆるトランスミッションコントロールプロトコル(TCP)及びインターネットプロトコル(IP)であり、これらを併せてTCP/IPと呼ぶ。TCP/IPによって管理される通信において、送信側はネットワークを介して受信側にデータユニットを送信し、受信側は送信されたデータユニットの受領に関する受領確認メッセージを返送する。これら受領確認メッセージに基づき、送信側はその制御手順を適応させることができる。
例えば、送信側がスライディングウィンドウベースの手法に従ってフロー制御を行う場合、ウィンドウの大きさ及び移動は、受信した受領確認メッセージに従って調整される。別の例として、送信側がレートベースのフロー制御を行っている場合、そのレートが受信した受領確認メッセージに基づいて調整される。
TCP/IPベースのネットワークは、その基本的な設計として、輻輳の送信側に、ルーティングデバイスがデータユニットを破棄(drop)したことを間接的な手段により通知する。換言すれば、ある特定のルーティングデバイスがバッファ過負荷に見舞われると、過剰なデータユニットが破棄される。これは、破棄されたデータユニットが受信側には絶対に到達しないことを意味する。
そのため、対応する受領確認メッセージ(又はその欠如)により、送信側はデータユニットの損失を知ることができる。TCPによれば、その後送信側は、対応する応答手順、例えばスロースタート(slow-start)として知られる方法を実行する。これらの応答手順は、よく知られたものであるため、これ以上の説明は不要である。
TCP/IPネットワークにおける輻輳に対処する改良された機構の1つとして、RFC3168は明示的輻輳通知(ECN)のコンセプトを提案する。ECNの基本的なアイデアは、転送されるデータユニットに明示的なマークを追加することにより、ネットワーク中のルーティングデバイスに、輻輳を送信側に通知させるものである。このような輻輳通知は、送信側から受信側へ送信されるデータユニット及び、受信側から送信側に送信される受領確認メッセージの少なくとも一方に加えることができることが理解されよう。マークされたデータユニットが順方向(送信側から受信側)に送信されるとすると、輻輳通知はそのデータユニットに対応する受領確認メッセージにおいても反映される。輻輳通知情報セットとともにデータユニットが送信側に到達すると、送信側は予め定められた手順に従って対処する。RFC3168において、IPヘッダ中のECNフィールドは2ビットで指定され、4つの、所謂ECNコードポイント(00,01,10及び11)を規定する。10及び01は、エンドポイント(送信側及び受信側)がECNに対応していることを示す。00はECNが使用されていないことを示す。11は、輻輳をエンドノードに通知するため、所謂CE(輻輳検出)コードポイントとしてルーティングデバイスがセットする情報である。
[本願の目的]
本願の目的は、データユニットベースの通信において、輻輳に対処する改良されたコンセプトを提供することにある。なお、上述の説明ではTCP/IPを一例として述べたが、本願の目的は、ある種の輻輳通知が用いられる任意のデータユニットベースの通信システムに対して適用可能である。
上述の目的は、独立請求項に記載される構成により達成される。好適な実施形態は従属項に記述される。
本発明の一見地によれば、輻輳が発生した場合、転送されるデータユニットに輻輳原因情報(輻輳の本質を特定する情報)を追加できるよう、データユニットをルーティングするためのデバイスが輻輳の1つ以上の原因を特定可能であることを特徴とする、データユニットをルーティングするためのデバイス及びその制御方法が提供される。
すなわち、従来技術は輻輳の存在有無を通知することのみを教示していたが、本発明では少なくとも2つの異なる輻輳原因を識別すること及び、原因に対応する輻輳原因情報を、転送されるデータユニットに付加することを提案する。これにより、通信の送信側及び受信側が、輻輳の存在だけでなく、その1つ以上の原因、すなわち発生している輻輳の本質をも理解することを可能にする。
従って、第2の見地によれば、本発明はデータユニットを送信するための通信装置及びその制御方法に関し、送信装置が、輻輳原因情報に従ってデータユニットの送信を制御する動作を適合させるため、ネットワークから受信したメッセージ中に含まれる、輻輳原因情報を抽出するように構成される。
なお、輻輳原因情報は任意の好適な方法又は所望の方法により提供されうる点に留意されたい。例えば、輻輳原因情報は、n個の輻輳原因の存在有無を識別するため、nビット(n>2)であってよい。明示的輻輳通知及び輻輳原因情報のコンセプトは、輻輳原因情報自体がまた輻輳通知情報として機能する方法や、それら別個とする方法により、組み合わせることができる。後者の場合、データユニット中の1つ以上の指定ビットが、輻輳通知情報として機能し、他の指定ビットが輻輳原因情報として機能する。また、前者の場合、同一の指定ビットセットが、輻輳通知情報及び輻輳原因情報の両方として機能する。
本発明のコンセプトを用いることで、輻輳への対応をその原因に応じて具体的に調整することができ、これは従来技術に対して大幅な改善である。換言すれば、従来技術は単に通信の送信側及び受信側に輻輳の存在を知らせるだけであったが、本発明はさらに送信側及び受信側に輻輳の原因を知らせる。そのため、送信側は1つ以上の特定される原因に特に対処するために設計された特定の対策を講じることが可能になる。
例えば、ルーティングデバイスが2つの異なる輻輳原因、処理制限(processing limitation)及び帯域制限(bandwidth limitation)を識別可能に構成されているとする。処理制限は、ルーティングデバイスが、時間単位当たりの到来パケット数の処理に問題を有している状況を示す。換言すれば、ルーティングデバイスが、単位時間当たりに到来するデータユニット数を処理するのに十分な性能を有しないため、データユニットがバッファに累積していることを示す。帯域制限は、単位時間当たりに転送されるべき量のデータを処理するに際して、1つ以上の出力リンクが問題を有している状況を示す。換言すれば、1つ以上の出力リンクの帯域が、帯域制限は、単位時間当たりに転送されるべき量のデータを処理するのに不足しているということである。
従来のシステムでは、ルーティングデバイスは、通信のエンドポイントに輻輳が発生していることを通知する輻輳検出(CE)ビットをセットすることのみは可能であったであろう。しかし、おそらく原因に関する情報はなかった。それと対照的に、本発明のコンセプトは、ルーティングデバイスが輻輳原因情報、例えば処理制限が起こっているのか、帯域制限が起こっているのか、或いはその両方が起こっているのかを示す情報を付加することを可能にする。このような情報に基づいて、データユニットの送信側は、遙かに適切に対応することができる。
この点について、例に基づいて説明する。送信側における、例えばボイスオーバIP(VoIP)のようなデータレートベースのアプリケーションを想定したとすると、処理制限と帯域制限とで異なる対処を行なうために有用である。つまり、処理制限への対処では、パケットサイズを増加して、送信側から単位時間当たりに出力されるデータユニット数を削減することが好ましいが、帯域制限への対処においては、単位時間当たりに出力されるデータユニット数は維持しながら、総データ量、すなわちデータレートを削減することが好ましい。帯域制限及び処理制限の両方が発生した場合、送信側は単位時間当たりのデータユニット数削減と、単位時間当たりに送信する総データ量削減の両方を同時に行なうことにより対処することが可能である。
以下、本発明の実施形態を図面を参照して説明する。
以下の本発明の好ましい実施形態においては、一例としてTCP/IPに関して言及している箇所があるが、本発明は決してTCP/IPに限定されず、輻輳通知が用いられる任意のデータユニットベースの通信に関連して適用可能である。従って、本明細書及び特許請求の範囲における“輻輳通知”とは一般的な意味で用いられており、RFC3168に規定されるECNに限定して解釈されるべきものではない。
図1は、本発明の一実施形態に係る、ネットワーク内でデータユニットをルーティングするための装置を示す図である。ルーティングデバイスは1で示される。ルーティングデバイス1は、自身が一部を構成するネットワークへのコネクションを表すライン20,21,22,23,24,25に接続される。ライン20〜25は単なる例であり、ルーティングデバイスは自ネットワークへの任意の数のコネクションを有しうる。これらのコネクションは、物理的なものであっても、論理的なものであっても、その両方であっても良い。10はネットワークからデータユニットを受信する受信器、12はネットワークへデータユニットを出力する出力ユニットである。ルーティングデバイス1はさらに、バッファ111及び制御ユニット110を備える処理部11を有する。制御ユニット110はルーティングデバイス1の動作を制御するように構成されている。この目的に照らし、制御ユニット110は、ハードウェア、ソフトウェア又はハードウェア及びソフトウェアの任意の適切な組み合わせからなる制御エレメントを有するであろう。
バッファ111は受信器10が受信したデータユニットをバッファするように構成される。出力ユニット10は、バッファされたデータユニットを、転送されるデータユニットに含まれるルーティング情報に基づいてネットワークへ出力する。
受信器10におけるデータユニットの受信、バッファ111におけるデータユニットのバッファ及び出力ユニット12を介したデータユニットの出力の制御に加え、制御ユニット110は、ルーティングデバイス1が所定の輻輳条件を満たすかどうかを監視するための輻輳モニタ(例えば、制御ユニット110により実行される適切なコンピュータプログラム又はソフトウェア要素)を備える。制御ユニット(コントローラ)110は、さらに、上述の輻輳モニタが輻輳条件を満たすと判断した場合に、出力ユニット12が出力する1つ以上のデータユニットに輻輳通知情報をセットするための輻輳通知ユニット(例えばコントローラ110で実行される適切なソフトウェア要素)を有する。
輻輳モニタにより監視される特定の輻輳条件は、好適なもの又は望ましいものを選択することができる。例えば、ルーティングデバイス1の1つ以上のリソースのうち、少なくとも1つの利用率が所定の条件を満たしたならば、輻輳条件が満たされたものと判断することができる。また、所定の閾値を超えることが、条件を満足したことであっても良い。輻輳状況が生じたかどうかを判断するために監視可能なリソースの例としては、バッファ容量及びデータユニット処理能力がある。例えば、バッファ111内のデータ量が所定の閾値を超えたならば、輻輳状況が発生したものと判定することができる。この場合、所定の閾値は、輻輳を示す任意の方法で調整を行なうことが可能であり、すなわち、バッファ111のオーバフロー限界よりも小さくしても良い。実際、バッファオーバフローよりも前に輻輳通知が生じることで、バッファオーバフローも一緒に回避されるであろから、閾値はオーバフロー限界よりも低く選択した方がよい。
バッファ利用率の監視に加え、或いはその代わりとして監視可能な他のリソースとしては、制御ユニット110が受信器と出力ユニットの間の転送においてデータユニットを処理するために用いる処理能力の量がある。例えば、コントローラ110がプロセッサであれば、処理能力の利用率を観測するために、データユニットの処理に割り当てられるプロセッサタイムの総量を監視することが可能である。
図1に示す実施形態では、ルーティングデバイス1が図2に示す手順を実施するように構成されている。すなわち、制御ユニット110は、輻輳モニタが輻輳条件が満たされたことを検出した1つ以上の原因を特定するため、少なくとも2つの異なる輻輳原因を識別可能な輻輳原因特定ユニットを(例えば制御ユニット110で実行されるソフトウェアプログラムの形態で)有する。
図2において、これは制御動作全体のフロー(図2の左側に垂直な点線で示されている)のうちのステップS21として示されており、ここで所定の輻輳条件が満たされているかどうかを判定する。もし輻輳条件が満たされていなければ、通常の制御ルーチン(本発明の主眼ではない)が継続される。しかし、ステップS21において、輻輳条件が満たされていると判定されたならば、手順はステップS22へ分岐し、そこで輻輳原因特定ユニットが輻輳の原因を特定する。
さらに、輻輳通知ユニットが、図2に示すステップS23を実行するように構成されている。つまり、輻輳原因特定ユニットがステップS22で特定した1つ以上の原因に基づき、輻輳原因情報をセットする。この情報は、輻輳通知情報がセットされる1つ以上のデータユニットにセットされる。
なお、ルーティングデバイス1は、例えばデータユニットにセット可能な輻輳原因の各々に対して1つの輻輳通知ユニットを持つといったように、複数の輻輳通知ユニットを有することが可能である。例えば、処理制限を示すビットをセットする輻輳通知ユニットと、帯域制限を示すビットをセットする輻輳通知ユニットが存在して良い。
輻輳通知及び輻輳原因情報は、所望の、或いは好適な任意のデータユニットにセットすることができる。例えば、これらの情報は指定された送信元情報(送信者を示す)又は指定された宛先情報(受信者を示す)を含むデータユニットだけにセットすることができる。好ましくは、輻輳条件が満たされている限り、出力ユニット12から出力される全てのデータユニットに輻輳原因情報がセットされる。
ステップS22を実行するように操作される輻輳原因特定ユニットは、少なくとも2つの異なる輻輳原因を識別する能力を有する。ステップS23でセットされる輻輳原因情報は、この少なくとも2つの異なる輻輳原因のうち、0、1又は2つが存在することの指標を提供する。
輻輳原因特定ユニットは好適な、或いは所望の任意の方法で動作することが可能である。例えば、異なる輻輳原因を識別し、その原因を特定するための機構は、ルーティングデバイス1の2つ以上のリソースの利用率の観測と、観測された利用率に基づく1つ以上の原因の特定によって達成できる。上述の例と同様、観測されるリソースは、例えばバッファ容量及びデータ処理能力であってよい。なお、複数のバッファ容量及び複数のデータユニット処理能力を観測することができる。例えば、ルーティングデバイス1を、受信器による受信に応答してデータユニットをバッファするため、受信器に関連付けられているバッファ容量を観測したり、出力するデータユニットをバッファするために出力ユニットに関連付けられたバッファ容量を観測したりするように構成することができる。これらのバッファ容量は、両方を1つの物理的なバッファ(例えば図1に示すバッファ111)から得ることが可能であるが、複数の物理的なバッファ、例えば受信器10に設けられる1つのバッファと、出力ユニット12に設けられるいくつかの出力バッファとから得ることも可能である。例えば、個々の出力ライン23〜25がそれぞれの出力バッファを有しても良い。或いは、これらのバッファ容量を、バッファ111が論理的に管理する個別の論理キュー、例えば受信器10に関する入力キュー及び出力ユニット12に関する複数の出力キューによって表しても良い。
監視可能な複数の処理能力としては、例えば受信器から出力ユニットへのデータユニット転送を制御するための処理能力や、出力ユニット12からのデータユニット出力を制御するための処理能力であってよい。この処理能力は、例えば、一般に所望の制御機能を提供するために所定のソフトウェアを実行するプロセッサである、制御ユニット110から得ることが可能である。従って、処理能力の利用は、例えば個々のタスクに割り当てられたプロセッサ能力の量を監視することによって監視可能である。つまり、受信器10から出力ユニット12へのデータユニット転送を制御するための処理能力は、この転送を制御するために使用されたプロセッサ時間の量を観測することにより監視可能である。また、出力ユニット12からのデータユニット出力を制御するための処理能力は、出力ユニット12から出力ライン23〜25へのデータユニット出力を制御するために使用されたプロセッサ時間の量を観測することにより監視可能である。
上述したとおり、輻輳原因特定ユニットはルーティングデバイス1の2つ以上のリソースの利用率を観測することにより、輻輳の異なる原因を識別することが可能である。この識別は、好ましくは、リソースを1つ以上の第1のリソースと、1つ以上の第2のリソースとにグループ化し、輻輳原因特定ユニットを、第1のリソースの利用率に基づいて第1の原因を特定し、第2のリソースの利用率に基づいて第2の原因を特定するように構成することにより実現できる。例えば、第1のリソースは受信器10に関するバッファ容量であってよく、この入力バッファ容量の利用率(例えば、入力バッファ中データ量)が観測される。そして、入力バッファ中のデータ量が処理の閾値を超えている場合には、処理制限が第1の原因として判定される。第2のリソースとして、個々の出力ライン23〜25に出力されるデータユニットのバッファリングに関連した1つ以上の出力バッファ容量を監視することが可能であり、これら出力バッファ容量の1つ以上が、所定の閾値を超えて使用された場合、帯域制限が第2の輻輳原因として特定可能である。
図1の例に関し、要素10を受信器又は受信エンティティとして、また要素12を出力ユニット又は出力エンティティとして説明した。しかし、これは説明をわかりやすくする目的によるものであり、一般には、ルーティングデバイスは、エンティティ10が転送されるべきデータユニットを出力する能力をも有し、また同時にエンティティ12がネットワークからデータユニットを受信する能力を有するように構成されるであろう。さらに、バッファ111及び制御ユニット110もまた、エンティティ10に接続されるラインから受信されたデータユニットを、エンティティ10に同様に接続されている別のラインへ転送する制御や、あるラインからエンティティ12で受信したデータユニットを、エンティティ12に接続される他のラインへ転送する制御をも行なうように構成されるであろう。このようにして、ルーティングデバイスは、複数のネットワークコネクションが接続された1つの受信/出力ユニットを有するものとして構成することが可能である。そして、バッファ及び制御ユニットは、(入力リンクとして振る舞う)1つのネットワークコネクションから、(出力リンクとして振る舞う)他のネットワークコネクションへの、データユニットの移動及び転送を制御するため、この入力/出力ユニットに接続される。このような実施形態において、受信器10及び出力ユニット12は1つの物理的エンティティである。
データユニットへの輻輳原因情報のセットは、任意の好適な方法、或いは所望の方法により実施することができる。例えば、データユニットの指定部分(例えばヘッダ)に、所定のビットセットを輻輳原因情報の伝送用に予約しておくことができる。これは、データユニットを示す図4において模式的に示されている。データユニットは、データユニットの開始と終了を明確にするデリミタ51及び52を有している。また、56はヘッダを、57はペイロードをそれぞれ表している。ヘッダ56は、セクション53はデータユニットのタイプを示し、セクション54はこのデータユニットをルーティングするためのルーティング情報を含み、セクション55はエラー訂正情報(例えば巡回冗長検査データ)のような様々な制御情報を含むといったように、例えば特定の情報を有する様々なセクションに分割することが可能である。
図4の例において、データユニットの制御セクション55はさらに、輻輳制御情報がセットされる指定セクション550を有している。単純なケースでは、輻輳原因情報は2ビットで構成することができる。この構成では4通りの組み合わせが得られ、第1の組み合わせ(例えば00)は輻輳無し、第2の組み合わせ(例えば10)は第1の輻輳原因が存在、第3の組み合わせ(例えば01)は第2の輻輳原因が存在、第4の組み合わせ(例えば11)は第1及び第2の輻輳原因の両方が存在することを示す。もちろん、輻輳原因情報は、輻輳原因の2個の組み合わせを提供するため、任意数であるnのビットを含みうる。
なお、図4に模式的に示したデータユニットは単なる一例であり、例えばヘッダに代えて、或いは追加してトレーラを用いるなど、他のデータ構成もあり得る。
既に述べたように、輻輳原因情報は輻輳通知情報と構造上同一であって良い。これは上述の例で示されており、00が輻輳なしを、他の組み合わせが輻輳を表している。さらに、輻輳原因情報を輻輳通知情報の付加情報として実装することも十分あり得る。例えば、TCP/IPを用いる場合、RFC3168に規定されるECNメカニズムは維持しながら、追加の輻輳原因情報を搬送する追加ビットセットを単に規定することが可能である。輻輳通知情報と輻輳原因情報とを別個とすることの利点は、輻輳通知情報の処理能力はあるが、輻輳原因情報の処理能力を持たないようなシステムとの下位互換性が得られることである。
次に、本発明の別の見地、すなわちデータユニットをネットワークに送信する通信装置による、輻輳原因情報の利用について説明する。これは図3に模式的に示される。
参照数字3はネットワークであり、ルーティングデバイス又は転送デバイス33−44を含んでいる。様々なルーティングデバイス33−44は相互接続されており、さらに点線で示されるように、図3に示されない他のルーティングデバイスとも接続されている。図3はさらに、ネットワーク3に接続され、送信側通信装置として振る舞う第1の通信装置31と、やはりネットワーク3に接続され、受信側通信装置として振る舞う第2の通信装置32を示している。より具体的には、送信側通信装置31はデータユニットをルーティングデバイス33を介してネットワーク3へ送信する。通信装置3とルーティングデバイス33との間のコネクションは、任意の所望の方法又は好適な方法により確立することが可能であり、例えば固定有線回線であっても、無線回線であっても良い。通信装置31によりネットワーク3に送信されたデータユニットは、ネットワーク3がデータユニットを所望の宛先32へ転送することが可能なように、ルーティング情報又はアドレス情報を有する。この基本的なコンセプトは、本技術分野において周知であるため、これ以上の詳細については説明を要しない。
本発明によれば、ルーティングデバイス33−44の1つ以上が、図1に関連して説明したように構成される。すなわち、本発明に従って動作するルーティングデバイスは、輻輳の発生有無を監視する能力のみならず、輻輳の原因を特定し、適切な情報を、適切な対応するデータユニットにセットする能力を有する。好ましくは、輻輳条件が満たされている限り、出力ユニット12(図1参照)から出力される全てのデータユニットに輻輳原因情報がセットされる。
転送されたデータユニットは受信側通信装置32によって受信され、受信側通信装置32はネットワーク3へ受領確認メッセージを送信するように構成される。受領確認メッセージはそのメッセージを送信側通信装置31に導くルーティング情報又はアドレス情報を含んでいる。受領確認メッセージはデータユニットの受領に関する受信情報を含む。さらに、1つ以上のルーティングデバイスにより、転送されたデータユニット中にセットされた輻輳通知情報及び輻輳原因情報がおそらく含まれる。すなわち、受信側通信装置32は、受信したデータユニットに含まれていた輻輳通知情報及び/又は輻輳原因情報を、そのまま反映(mirror)するように構成されている。送信側通信装置からのデータユニットの受信に応答して、受領確認メッセージを送信する基本的な手順は、ARQ(自動再送要求)として本技術分野において周知であるため、これ以上の説明は省略する。
そして、受領確認メッセージはネットワーク3により、送信側通信装置31へ転送される。このように、本発明のコンセプトに従って動作するルーティングデバイスは、輻輳通知情報及び輻輳原因情報を順方向(送信側通信装置31から受信側通信装置32)に送信されるデータユニット中にセットできる能力を有するだけでなく、逆方向(受信側通信装置32から送信側通信装置31)に送信される受領確認メッセージに対して輻輳通知情報及び輻輳原因情報をセットする能力を有する。なお、受領確認メッセージもまたデータユニットであり、例えば図4に示したような構成を有する。
本発明に係る送信側通信装置31は、図5のフローチャートによって模式的に示される方法を実行可能なように構成される。すなわち、通信装置31の全体的な制御手順中に存在するステップS61において、受信した受領確認メッセージ中に輻輳原因情報が存在するかどうかを調べる。もし存在しなければ、通常の制御手順を継続する。一方、輻輳原因情報が受信した受領確認メッセージ中に存在する場合には、手順はステップS62へ分岐し、そこで輻輳原因情報が抽出される。そして、引き続くステップS63で、制御手順は抽出した輻輳原因に従って適合される。既に述べたように、輻輳原因情報はnの異なる輻輳原因に関して存在有無を表すように指定されうる。そのため、個々の受領確認メッセージは、2の異なる輻輳原因の組み合わせの1つを含むことができる。本発明に従って動作する通信装置31は、例えば、単に、受領確認メッセージ中の指定されたフィールド(すなわち、輻輳原因フィールド)で輻輳原因の組み合わせ(例えば特定のビット組み合わせ)を特定し、特定された輻輳原因の組み合わせに対応する対処手順を実行する様に構成することができる。一例として、通信装置31が、可能性のある輻輳原因の組み合わせ(例えば、各々のビットパターン)のレコード又はテーブルであって、個々の輻輳原因情報が関連する対処手順にリンクされているレコード又はテーブルを保持することが可能である。なお、輻輳原因の組み合わせの各々が異なる対処手順にリンクされていても、いくつかの異なる輻輳原因の組み合わせが同じ対処手順にリンクされていても良い。これは、個々のシステムに依存した事項であり、適切なもの、又は所望のものを選択すればよい。
好ましい実施形態によれば、通信装置31は第1及び第2の輻輳原因情報を抽出するように構成される。なお、第1の輻輳原因情報は、ネットワークを介して送られてくるデータユニット数を処理できないこと(すなわち、処理制限)に帰因した輻輳に関するものであり、第2の輻輳原因情報は、送信しようとするデータ量を処理できないこと(すなわち、帯域制限)に帰因した輻輳に関するものである。そして、通信装置31は好ましくは、第1の輻輳原因情報の抽出に対しては単位時間当たりにネットワークへ出力するデータユニット数を削減することによって、また第2の輻輳原因情報の抽出に対しては単位時間当たりにネットワークへ出力するデータ量を削減することによって対応するように構成される。
予め定められたnビット中の各ビットにより輻輳原因情報をセットするに関し、コネクション中に存在する複数のルーティングデバイスが個々の輻輳原因に対応する1つ以上のビットをセット可能である場合には、連続するルーティングデバイスが各々の輻輳状態に応じて異なるビットを設定可能であることに留意されたい。一例として、輻輳原因情報が2つの原因に区別される(すなわち、2ビットが用いられる)ものとすると、第1のルーティングデバイスが第1ビットを1にセットし(これにより、例えば処理制限が示される)、第2のルーティングデバイス(例えば図3の36)が第2ビットを1にセットする(これにより、帯域制限が示される)可能性がある。このようにして、輻輳原因情報が受信側通信装置32から送信される受領確認メッセージにそのまま反映された後、送信側通信装置31はネットワーク3に第1の輻輳原因(例えば処理制限)と、第2の輻輳原因(例えば帯域制限)の両方が存在することを知る。
送信側通信装置の変更と関連する上述のコンセプトは、好ましくはレートベースの送信アプリケーションに適用される。一例として、1音声フレームを所定期間内に出力するコーデックを用いるボイスオーバIP(VoIP)アプリケーションを想定することが可能である。例えば、AMR(適応マルチレート)コーデックは、1音声フレームを20ms毎に出力する。このコーデックは複数の符号化レートを使用可能であり、フレーム単位で符号化レートの切替が可能である。例えば、AMRコーデックは4.75〜12.2kbpsの範囲で8通りの符号化レートを切り替えることが可能である。コーデックから出力される音声フレームは、ネットワーク上で送信可能なデータユニットに埋め込まれる。例えば、音声フレームは実時間送信プロトコル(RTP)データユニット、データグラム輻輳制御プロトコル(DCCP)データユニット及びインターネットプロトコル(IP)データユニットへ連続的に埋め込みされうる。
本発明の好ましい実施形態によれば、輻輳原因情報は2ビットに符号化され、第1の組み合わせ(例えば00)は輻輳無し、第2の組み合わせ(例えば10)は処理制限が存在、第3の組み合わせ(例えば01)は帯域制限が存在、第4の組み合わせ(例えば11)は処理制限及び帯域制限の両方が存在することを示す。
フィードバック(すなわち、受領確認メッセージ)をネットワークから受信すると、VoIPアプリケーションは、00が対応せず(図5に示す例におけるステップS61の”no”出力に対応)、10が対応オプション1、01が対応オプション2、11が対応オプション3にそれぞれリンクされる、適切な判定テーブルを用いることが可能であろう。
そして、対応オプション1は、データユニット当たりの音声フレーム数を増加させ、アプリケーションが出力するデータユニットの数を削減することであってよい。この結果、ネットワークが受信する、単位時間当たりに処理すべきデータユニットの数が削減されるため、この対応は処理制限への適切な対応である。VoIPアプリケーションから見れば、この対応は遅延を増加させる。
対応オプション2は、データユニット当たりの音声フレーム数はそのままとし、代わりに符号化レートを削減することであってよい。この結果、データユニット数は変わらないが、個々のデータユニットが小さくなる。従って、ネットワークに到来するデータ量(すなわち、バイト数)が減少するので、帯域制限に対する適切な対応である。アプリケーションからすれば、品質の低下という代償が必要となる。
対応オプション3は、オプション1及び2の両方、すなわち、符号化レートの削減と、データユニット当たりの音声フレーム数の増加の実行であって良い。アプリケーションからすれば、この対応は品質低下と遅延増加に繋がる。
以上の例から、従来のシステムと比較した本願発明の利点は直ちに理解可能である。すなわち、従来技術では輻輳の存在有無のみを示していたのに対し、本発明では輻輳原因を識別することを可能としている。これは、上述のVoIPアプリケーションの場合であれば、従来技術においては輻輳原因がわからないため、輻輳通知に対してオプション3が強制的に実施される得ないことを意味する。原因が分らなければ、可能性のある全ての原因、例えば処理制限及び帯域制限を軽減可能な対応を取らざるを得ない。そのため、輻輳が起きた場合には、常に品質の低下と遅延の増加を伴うことになる。
それに対し、本発明は輻輳の原因が識別可能であり、送信側通信装置において正しい対応を採ることが可能であるため、本当に必要なだけの性能低下を容認すればよい。すなわち、処理制限が生じた場合には、品質を犠牲にすることなく、遅延の増加のみを許容すればよい。また、帯域制限が生じた場合には、遅延増加を受けることなく、品質低下のみを許容すればよい。
なお、上述の例はVoIPに関するものであるが、本発明による同様の有利な効果は、ストリーミング、モバイル環境におけるゲーム(mobile gaming) といった輻輳フィードバックを用いる他の任意のアプリケーション及び、輻輳制御にTFEC(TCP Friendly Rate Control)及び/又はTFEC−PS(TCP Friendly Rate Control Packet Size)を用いる任意のアプリケーションにおいても実現される。もちろん、個々の応答オプションは、具体的なアプリケーション及びそれに付随した個別の要求に依存するであろう。
本発明の実施形態はハードウェア、ソフトウェア又はハードウェア及びソフトウェアの何らかの適当な組み合わせの形態で提供されうる。本発明はまた、本発明に係る方法を実行可能なコンピュータプログラムを格納するデータ記録媒体の形式においても実施可能である。
本発明を例示によって説明してきたが、これらの例は大局的な理解を与えるためのものであり、本発明を限定する意図はない。むしろ、本発明の範囲は添付の特許請求の範囲によって定まるものである。さらに、特許請求の範囲における参照数字は、請求範囲の読解を容易にすることのみを目的としたものであり、本発明を限定するものではない。
本発明による、データユニットをルーティングするための装置の実施形態を示す図である。 本発明の方法を説明するフローチャートである。 データユニットの送信側及び受信側並びにルーティングデバイスを有するネットワークを模式的に表す図である。 本発明によるデータユニットを模式的に表す図である。 本発明の実施形態に係る、送信通信装置の制御方法を説明するフローチャートである。

Claims (25)

  1. ネットワーク(3)内のデータユニットをルーティングする装置(1)であって、
    前記ネットワークからデータユニットを受信する受信器(10)と、
    前記受信器が受信したデータユニットをバッファするバッファ(111)と、
    バッファされたデータユニットを、前記データユニットに含まれるルーティング情報に基づいて前記ネットワークへ出力する出力ユニット(12)と、
    前記装置が所定の輻輳条件を満たすか否かを監視する輻輳モニタ(110)と、
    前記輻輳モニタが前記輻輳条件が満たされていると判定した場合、前記出力ユニットが出力する1つ以上のデータユニットに輻輳通知情報をセットする輻輳通知ユニット(110)とを有し、
    さらに、
    少なくとも2つの異なる輻輳原因を識別可能であり、前記輻輳モニタにより前記輻輳条件が満たされたと判定した1つ以上の原因を特定する輻輳原因特定ユニット(110)を有するとともに、
    前記輻輳通知ユニットが、前記輻輳原因特定ユニットが特定した前記1つ以上の原因に基づいて、輻輳原因情報を前記輻輳通知情報がセットされている1つ以上のデータユニットにセットするように構成されることを特徴とする装置。
  2. 前記輻輳モニタが、前記装置の1つ以上のリソースの利用率を監視し、前記1つ以上のリソースのうち、少なくとも1つの前記利用率が所定の条件を満たしたならば、前記輻輳条件が満たされたものと判断することを特徴とする請求項1記載の装置。
  3. 前記所定の条件が、所定の閾値の超過であることを特徴とする請求項2記載の装置。
  4. 前記輻輳原因特定ユニットが、前記装置の2つ以上のリソースの利用率を観測し、前記観測された利用率に基づいて前記1つ以上の原因を特定することを特徴とする請求項1乃至請求項3のいずれか1項に記載の装置。
  5. 前記リソースが、バッファ容量とデータユニット処理能力を含むことを特徴とする請求項2乃至請求項4のいずれか1項に記載の装置。
  6. 前記リソースが1つ以上の第1のリソースと、1つ以上の第2のリソースとにグループ化され、前記輻輳原因特定ユニットが、前記第1のリソースの前記利用率に基づいて第1の原因を特定し、前記第2のリソースの前記利用率に基づいて第2の原因を特定するように構成されることを特徴とする請求項4又は請求項5に記載の装置。
  7. 前記第1のリソースが、
    −前記受信器による受信に応答してデータユニットをバッファするため、前記受信器に関連付けされたバッファ容量と、
    −前記受信器から前記出力ユニットへのデータユニット転送を制御するための処理能力
    の少なくとも一方を含み、
    前記第2のリソースが、
    −出力するデータユニットをバッファするために前記出力ユニットに関連付けされたバッファ容量と、
    −前記出力ユニットからのデータユニット出力を制御するための処理能力
    の少なくとも一方を含むことを特徴とする、請求項6記載の装置。
  8. ネットワーク内のデータユニットをルーティングする装置を制御する方法であって、
    前記ネットワークからデータユニットを受信するステップと、
    前記受信器が受信したデータユニットをバッファするステップと、
    バッファされたデータユニットを、前記データユニットに含まれるルーティング情報に基づいて前記ネットワークへ出力するステップと、
    所定の輻輳条件が満たされているか否かを監視するステップと、
    前記輻輳条件が満たされている場合、出力される1つ以上のデータユニットに輻輳通知情報をセットするステップとを有し、
    さらに、
    前記輻輳条件が満たされていると判定された1つ以上の原因を特定するステップ(S22)と、
    前記特定した1つ以上の原因に基づいて、輻輳原因情報を、輻輳通知情報がセットされている1つ以上のデータユニットにセットするステップ(S23)とを有することを特徴とする方法。
  9. 前記装置の1つ以上のリソースの利用率が監視され、前記1つ以上のリソースのうち、少なくとも1つの前記利用率が所定の条件を満たした場合に前記輻輳条件が満たされたと判断されることを特徴とする請求項8記載の方法。
  10. 前記所定の条件が、所定の閾値の超過であることを特徴とする請求項9記載の方法。
  11. 前記装置の2つ以上のリソースの前記利用率が観測され、前記観測された前記利用率に基づいて前記1つ以上の原因を特定されることを特徴とする請求項8乃至請求項10のいずれか1項に記載の方法。
  12. 前記リソースが、バッファ容量とデータユニット処理能力を含むことを特徴とする請求項9乃至請求項11のいずれか1項に記載の方法。
  13. 前記リソースが1つ以上の第1のリソースと、1つ以上の第2のリソースとにグループ化され、第1の原因が前記第1のリソースの前記利用率に基づいて特定され、第2の原因が前記第2のリソースの前記利用率に基づいて特定されることを特徴とする請求項11又は請求項12に記載の方法。
  14. 前記第1のリソースが、
    −前記受信器による受信に応答してデータユニットをバッファするため、前記受信器に関連付けされたバッファ容量と、
    −前記受信器から前記出力ユニットへのデータユニット転送を制御するための処理能力
    の少なくとも一方を含み、
    前記第2のリソースが、
    −出力するデータユニットをバッファするために前記出力ユニットに関連付けされたバッファ容量と、
    −前記出力ユニットからのデータユニット出力を制御するための処理能力の少なくとも一方を含むことを特徴とする、請求項13記載の方法。
  15. ネットワーク中のデータユニットをルーティングする装置で動作させた際に、請求項8乃至請求項14のいずれか1項に記載の方法を実行するコンピュータプログラム。
  16. 請求項15に記載のコンピュータプログラムを格納するデータ記録媒体。
  17. ネットワーク(3)を介して受信側通信装置(32)へデータユニットを送信する通信装置(31)であり、
    前記受信側データ通信装置から、送信済みデータユニットの受領に関する受領情報及び前記ネットワークにおける輻輳に関する輻輳通知情報とを含む受領確認メッセージを受信し、
    前記受領確認メッセージに対し、前記受領確認メッセージに含まれる前記情報に従ってデータユニットの送信を制御する動作を適合させることにより対応するように構成されるとともに、
    前記受領確認メッセージに含まれる輻輳原因情報を抽出し、前記データユニットの送信を制御する動作を前記輻輳原因情報に従って適合させるように構成されることを特徴とする通信装置。
  18. 前記輻輳原因情報は、受領確認メッセージ中の前記輻輳原因情報がn(nは整数)の異なる輻輳原因の存在有無を通知可能なように、かつ個々の受領確認メッセージが2の異なる輻輳原因の組み合わせの1つを含むように指定され、前記送信する通信装置が、受領確認メッセージ中に含まれる前記輻輳原因の組み合わせを特定し、当該特定された輻輳原因の組み合わせに対応する対処手順を実行するように構成されることを特徴とする請求項17記載の装置。
  19. 前記送信する通信装置が、少なくとも第1及び第2の輻輳原因情報を抽出するように構成され、前記第1の輻輳原因情報は、送信される数のデータユニットを処理できないことに帰因した輻輳に関するものであり、前記第2の輻輳原因情報は、送信される量のデータを処理できないことに帰因した輻輳に関するものであるとともに、
    前記送信する通信装置が、前記第1の輻輳原因情報の抽出に対しては単位時間当たりに出力するデータユニット数を削減することによって、また前記第2の輻輳原因情報の抽出に対しては単位時間当たりに出力するデータ量を削減することによって対応するように構成されることを特徴とする請求項17又は請求項18記載の装置。
  20. ネットワークを介して受信側通信装置へデータユニットを送信する送信側通信装置を制御する方法であって、
    前記受信側データ通信装置から、送信済みデータユニットの受領に関する受領情報及び前記ネットワークにおける輻輳に関する輻輳通知情報とを含む受領確認メッセージを受信するステップと、
    前記受領確認メッセージに対し、前記受領確認メッセージに含まれる前記情報に従ってデータユニットの送信を制御する動作を適合させることにより対応するステップとを含み、
    前記送信側通信装置において、前記受領確認メッセージに含まれる輻輳原因情報を抽出するステップ(S62)と、
    前記データユニットの送信を制御する動作を前記輻輳原因情報に従って適合させるステップ(S63)とをさらに有することを特徴とする方法。
  21. 前記輻輳原因情報は、受領確認メッセージ中の前記輻輳原因情報がn(nは整数)の異なる輻輳原因の存在有無を通知可能なように、かつ個々の受領確認メッセージが2の異なる輻輳原因の組み合わせの1つを含むように指定され、前記方法が、受領確認メッセージ中に含まれる前記輻輳原因の組み合わせを特定するステップと、当該特定された輻輳原因の組み合わせに対応する対処手順を実行するステップとを更に有することを特徴とする請求項20記載の方法。
  22. 前記送信側通信装置が、少なくとも第1及び第2の輻輳原因情報を抽出するように構成され、前記第1の輻輳原因情報は、送信される数のデータユニットを処理できないことに帰因した輻輳に関するものであり、前記第2の輻輳原因情報は、送信される量のデータを処理できないことに帰因した輻輳に関するものであるとともに、
    前記方法が、前記第1の輻輳原因情報の抽出に対し、単位時間当たりに出力するデータユニット数を削減することによって対応するステップと、前記第2の輻輳原因情報の抽出に対し、単位時間当たりに出力するデータ量を削減することによって対応するステップとをさらに有することを特徴とする請求項20又は請求項21記載の方法。
  23. ネットワークを介してデータユニットを送信する装置で動作させた際に、請求項20乃至請求項22のいずれか1項に記載の方法を実行するコンピュータプログラム。
  24. 請求項23に記載のコンピュータプログラムを格納するデータ記録媒体。
  25. ネットワーク(3)を介してデータユニットを送信する方法であって、
    前記ネットワークに接続された送信側通信装置(31)から、前記ネットワークへデータユニットを送信するステップと、
    前記ネットワークの1つ以上のルーティングデバイス(33−44)中の前記データユニットを、前記ネットワークに接続された受信側通信装置(32)へ転送するステップであり、
    各ルーティングデバイスが前記ネットワークから受信したデータユニットをバッファし、バッファされたデータユニットを前記データユニットに含まれるルーティング情報に基づいて前記ネットワークへ出力し、所定の輻輳条件が満たされているかどうかを監視し、前記輻輳条件が満たされている場合には1つ以上の出力データユニットに輻輳通知情報をセットし、前記輻輳条件が満たされたことの1つ以上の原因を特定し、前記1つ以上の特定された原因に基づいて、前記輻輳通知情報がセットされている前記1つ以上のデータユニットに輻輳原因情報をセットする各ステップを含むステップと、前記転送されたデータユニットを前記受信側通信装置で受信するステップであり、前記受信側通信装置が前記ネットワークへ、前記転送されたデータユニットとの受領に関する受領情報並びに、前記1つ以上のルータが前記転送されたデータユニットにセットした輻輳通知情報及び輻輳原因情報とを含む受領確認メッセージを送信するステップを含むステップと、
    前記受領確認メッセージを前記ネットワークを通じて前記送信側通信装置に転送するステップと、
    前記受領確認メッセージを前記受信側通信装置で受信し、前記受領確認メッセージに含まれる前記情報に従って、データユニットの送信を制御する動作を適合させることにより、前記受領確認メッセージに対応するステップであり、
    前記送信側通信装置において、前記受領確認メッセージに含まれる前記輻輳原因情報を抽出し、前記抽出された前記輻輳原因情報に従って、前記データユニットの送信を制御する前記動作を適合させるステップを含むステップ、
    とを有することを特徴とする方法。
JP2004567274A 2003-01-28 2003-01-28 さまざまな輻輳要因を知らせる、パケットネットワークにおける輻輳通知のための方法及び装置 Expired - Fee Related JP4174054B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2003/000850 WO2004068800A1 (en) 2003-01-28 2003-01-28 Method and device for congestion notification in packet networks indicating several different congestion causes

Publications (2)

Publication Number Publication Date
JP2006513663A true JP2006513663A (ja) 2006-04-20
JP4174054B2 JP4174054B2 (ja) 2008-10-29

Family

ID=32798691

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004567274A Expired - Fee Related JP4174054B2 (ja) 2003-01-28 2003-01-28 さまざまな輻輳要因を知らせる、パケットネットワークにおける輻輳通知のための方法及び装置

Country Status (7)

Country Link
US (1) US20060253622A1 (ja)
EP (1) EP1588526A1 (ja)
JP (1) JP4174054B2 (ja)
CN (1) CN100438484C (ja)
AU (1) AU2003202593A1 (ja)
CA (1) CA2508833A1 (ja)
WO (1) WO2004068800A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008219280A (ja) * 2007-03-01 2008-09-18 National Institute Of Information & Communication Technology 携帯ip電話輻輳制御方法
JP2013157742A (ja) * 2012-01-27 2013-08-15 Fujitsu Ltd 監視装置、プログラム及び監視方法

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4235507B2 (ja) * 2003-08-14 2009-03-11 株式会社エヌ・ティ・ティ・ドコモ 中継装置、送信装置、受信装置およびプログラム
KR100612437B1 (ko) * 2003-08-20 2006-08-16 삼성전자주식회사 이더넷 망의 혼잡 여부를 알려주는 장치 및 방법
JP2005295457A (ja) * 2004-04-05 2005-10-20 Fujitsu Ltd P2pトラフィック対応ルータ及びそれを用いたp2pトラフィック情報共有システム
US7830920B2 (en) * 2004-12-21 2010-11-09 Sony Ericsson Mobile Communications Ab System and method for enhancing audio quality for IP based systems using an AMR payload format
DE112006001591T5 (de) * 2005-06-15 2008-04-30 Telefonaktiebolaget Lm Ericsson (Publ) Adaptiver Mobiltelefonie-Sprachtransport über ein Internetprotokollnetz
US7633940B1 (en) * 2005-06-27 2009-12-15 The Board Of Trustees Of The Leland Stanford Junior University Load-balanced routing
US8670309B2 (en) * 2005-09-30 2014-03-11 Alcatel Lucent Method and apparatus for preventing activation of a congestion control process
US8578046B2 (en) * 2005-10-20 2013-11-05 Qualcomm Incorporated System and method for adaptive media bundling for voice over internet protocol applications
US8964560B2 (en) * 2007-10-11 2015-02-24 Nokia Solutions And Networks Oy Apparatus, method, computer program product and system for requesting acknowledgment of transmitted data packets
US8774005B2 (en) 2008-09-26 2014-07-08 Telefonaktiebolaget L M Ericsson (Publ) Congestion control method and devices
KR101680868B1 (ko) * 2009-11-18 2016-11-30 삼성전자주식회사 무선통신시스템에서의 데이터 전송 제어장치 및 방법
US9282352B2 (en) * 2010-11-23 2016-03-08 Verizon Patent And Licensing Inc. Under-the-bottom time-shifted delivery of video content
CN103283275B (zh) * 2011-01-05 2017-03-08 瑞典爱立信有限公司 数据的负载平衡
US9674090B2 (en) * 2015-06-26 2017-06-06 Microsoft Technology Licensing, Llc In-line network accelerator
US20220360644A1 (en) * 2019-07-03 2022-11-10 Telefonaktiebolaget Lm Ericsson (Publ) Packet Acknowledgment Techniques for Improved Network Traffic Management

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI946011A0 (fi) * 1994-12-21 1994-12-21 Nokia Telecommunications Oy Foerfarande foer att till ett FR-naet ange en blockeringssituation i trafiken i ett ATM-naet
JP2820073B2 (ja) * 1995-08-22 1998-11-05 日本電気株式会社 Inにおけるサービス制御ノードの輻輳制御処理方法とその方式
US5673253A (en) * 1996-02-29 1997-09-30 Siemens Business Communication Systems Dynamic allocation of telecommunications resources
JPH11355342A (ja) * 1998-06-08 1999-12-24 Kokusai Electric Co Ltd ルータ
US6862622B2 (en) * 1998-07-10 2005-03-01 Van Drebbel Mariner Llc Transmission control protocol/internet protocol (TCP/IP) packet-centric wireless point to multi-point (PTMP) transmission system architecture
CA2301435C (en) * 1999-04-16 2006-10-10 At&T Corp. Method for reducing congestion in packet-switched networks
GB2364615B (en) * 1999-04-27 2004-03-31 Nokia Corp Overload control method for a packet-switched network
US7058723B2 (en) * 2000-03-14 2006-06-06 Adaptec, Inc. Congestion control for internet protocol storage
US6741555B1 (en) * 2000-06-14 2004-05-25 Nokia Internet Communictions Inc. Enhancement of explicit congestion notification (ECN) for wireless network applications
CA2355473A1 (en) * 2000-09-29 2002-03-29 Linghsiao Wang Buffer management for support of quality-of-service guarantees and data flow control in data switching
US7394764B2 (en) * 2001-12-14 2008-07-01 Sasken Communication Technologies Limited Technique for improving transmission control protocol performance in lossy networks
US7327678B2 (en) * 2002-10-18 2008-02-05 Alcatel Lucent Metro ethernet network system with selective upstream pause messaging

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008219280A (ja) * 2007-03-01 2008-09-18 National Institute Of Information & Communication Technology 携帯ip電話輻輳制御方法
JP2013157742A (ja) * 2012-01-27 2013-08-15 Fujitsu Ltd 監視装置、プログラム及び監視方法

Also Published As

Publication number Publication date
CN100438484C (zh) 2008-11-26
US20060253622A1 (en) 2006-11-09
CA2508833A1 (en) 2004-08-12
JP4174054B2 (ja) 2008-10-29
WO2004068800A1 (en) 2004-08-12
AU2003202593A1 (en) 2004-08-23
EP1588526A1 (en) 2005-10-26
CN1736063A (zh) 2006-02-15

Similar Documents

Publication Publication Date Title
JP4174054B2 (ja) さまざまな輻輳要因を知らせる、パケットネットワークにおける輻輳通知のための方法及び装置
JP4163613B2 (ja) データ・ユニットの処理方法およびシステム
CN110661723B (zh) 一种数据传输方法、计算设备、网络设备及数据传输系统
JP4658142B2 (ja) 通信装置およびフレーム制御方法
CN107204931B (zh) 通信装置和用于通信的方法
JP5325231B2 (ja) パケット交換データネットワークの輻輳の制御
JP5544430B2 (ja) 通信装置および通信システム
JP3882187B2 (ja) フロー制御システムおよび方法
KR101143172B1 (ko) 웹 서비스를 위한 신뢰성 있는 메시징 프로토콜을 이용한메시지의 효율적인 전송
KR101746629B1 (ko) 통신 장치 및 통신 방법
US7649909B1 (en) Adaptive tunnel transport protocol
JP2009147786A (ja) 通信装置、データフレームの送信制御方法及びプログラム
US20120063493A1 (en) Transmission rate control method, transmission unit, and communication system
EP2604000A1 (en) Load distribution architecture for processing tunnelled internet protocol traffic
WO2001041397A1 (en) Method and apparatus for packet delay reduction using scheduling and header compression
JP2007534194A (ja) パケットを再配列する際のtcp性能の改善
WO2005088917A1 (ja) 制御局装置、基地局装置、端末装置、パケット通信システム及びパケット通信方法
WO2012121635A1 (en) Hybrid congestion control
JP2007215182A (ja) ネットワークにおける輻輳発生予告システム及びその方法
US8838782B2 (en) Network protocol processing system and network protocol processing method
JP2006262417A (ja) 通信速度制御方法及びその装置
JP3767862B2 (ja) 非対称ネットワーク環境下でのtcpデータ伝送効率の向上方法及び通信システム
JP2008118281A (ja) 通信装置
RU2313915C2 (ru) Способ и устройство уведомления о перегруженности в сетях пакетной передачи с указанием нескольких различных причин перегруженности
WO2002051101A1 (fr) Systeme de reseau tcp/ip

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20060117

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20080128

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080201

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080501

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20080718

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20080815

R150 Certificate of patent or registration of utility model

Ref document number: 4174054

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110822

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110822

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120822

Year of fee payment: 4

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120822

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130822

Year of fee payment: 5

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees