JP2004007361A - データ送信制御方法及びこの方法のプログラム並びにこれを用いるデータ送信装置 - Google Patents
データ送信制御方法及びこの方法のプログラム並びにこれを用いるデータ送信装置 Download PDFInfo
- Publication number
- JP2004007361A JP2004007361A JP2002298469A JP2002298469A JP2004007361A JP 2004007361 A JP2004007361 A JP 2004007361A JP 2002298469 A JP2002298469 A JP 2002298469A JP 2002298469 A JP2002298469 A JP 2002298469A JP 2004007361 A JP2004007361 A JP 2004007361A
- Authority
- JP
- Japan
- Prior art keywords
- route
- distribution ratio
- packet
- quality information
- path
- 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.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】ネットワークの負荷集中や輻輳を回避してデータを送信可能にする。
【解決手段】ネットワークにおいて送信元ノード11は一連のシーケンス番号が付けられたパケットを複数の経路31,32に決められた分配比率で送出し、送信先ノード12はそれぞれの経路31,32から受信されたパケットをシーケンス番号順に並べ、それぞれの経路のパケット損失、パケット間隔ジッタ、などを測定し、測定結果を経路の品質情報として受信者レポートRTCP−RRに書き込んで送信元ノード11に送信し、送信元ノード11は受信者レポートRTCP−RRから得たそれぞれの経路についての品質情報に基づいて適応的にそれらの経路への分配比率を変更する。
【選択図】図10
【解決手段】ネットワークにおいて送信元ノード11は一連のシーケンス番号が付けられたパケットを複数の経路31,32に決められた分配比率で送出し、送信先ノード12はそれぞれの経路31,32から受信されたパケットをシーケンス番号順に並べ、それぞれの経路のパケット損失、パケット間隔ジッタ、などを測定し、測定結果を経路の品質情報として受信者レポートRTCP−RRに書き込んで送信元ノード11に送信し、送信元ノード11は受信者レポートRTCP−RRから得たそれぞれの経路についての品質情報に基づいて適応的にそれらの経路への分配比率を変更する。
【選択図】図10
Description
【0001】
【発明の属する技術分野】
本発明は、インターネットのようなベストエフォート型サービスのネットワークにおいて、ネットワークの負荷集中や輻輳による伝送遅延揺らぎやパケット損失を回避するのに好適に利用可能なデータ送信制御方法及びこの方法のプログラム並びにこれを用いるデータ送信装置に関する。
【0002】
【従来の技術】
インターネットの経路選択アルゴリズムが選択する経路は、通常、ノード間における最短経路の一つだけであるため、従来のインターネットでは、その一つの経路のみを用いる通信が行われている。
一方で、こうした従来のインターネットをマルチパスに適応させる試みも行われている。例えば、ルーティングアルゴリズムにOSPF(Open Shortest PathFirst)を利用している場合には、メトリックスが等しい複数経路に対してトラヒックの等価負荷分散をサポートし、IGRP(Interior Gateway Routing Protocol)を利用している場合には、メトリックスが必ずしも等しくない複数経路に対してトラヒックをメトリックに比例して不等分に分配する機能を実装したルータが知られている。
【0003】
しかしながら、1経路のみを用いて通信を行う現在のインターネットでは、通信を行っているネットワークにおける障害・輻輳は避けられず、こうしたネットワークの障害・輻輳によるデータの損失や大幅な遅延が生じた場合、輻輳制御によりその経路へ転送するトラヒックを抑えることになり、所望のスループットが得られないという問題がある。
また、ルータにおいて経路のメトリック値に基づいてデータの分配比率を決定する従来の複数経路データ分配方式は、上記メトリック値には、刻々と変化する経路状態が反映されないため、各経路の状態を考慮した最良な分配方式とは言えない。この方式では、状態の悪化した一部の経路に引きずられて、全経路でのスループットが低下するという問題がある。
【0004】
EdgeStream社はネットワークの異なる経路上に同一コンテンツを互いに同期して送信可能な配信サーバを複数設け、一方の配信サーバからユーザへのコンテンツ送信経路のトラヒック量が規定値以上になった場合、他方の配信サーバに切り替えてコンテンツを送信することにより、所定の伝送レート以上による動画品質を保障した配信システムを提案している。この方法は、複数のサーバを必要とするため、それだけコストが高くなる欠点がる。しかも、この方法は経路の切り替え時に再生画面が途切れる可能性がある。
【0005】
特許文献1にはネットワーク上の各ルータが伝送路のトラヒック状態を監視し、予め測定した伝送経路のスループットを超えるトラヒックの集中が生じるとその経路を回避するように経路を切り替える方式が示されている。しかしながら、この方法は各経路のスループットを予め測定し、それに基づいてネットワーク上の全てのルータのルーティングテーブルの作成を行う必要があり、現実性に乏しい。
【0006】
【特許文献1】
日本国特許出願公開公報第2000−216817号、公開日:平成12年8月4日
【0007】
【発明が解決しようとする課題】
本発明はこのような事情を考慮してなされたものであって、その目的とするところは、インターネットのようなベストエフォート型サービスのネットワークにおいて、ネットワークの負荷集中や輻輳による伝送遅延揺らぎやパケット損失を回避するのに好適に利用可能なデータ送信制御方法及びこの方法のプログラム並びにこれを用いるデータ送信装置を提供することにある。
【0008】
【課題を解決するための手段】
この発明による、ネットワーク上の送信元ノードから送信先ノードへデータを送信するための送信元ノードのデータ送信制御方法は、以下のステップを含む:
(a) 上記送信元ノードと上記送信先ノード間の複数の経路の品質情報を上記送信先ノードから取得し、
(b) 上記複数の経路の上記品質情報に基づいて上記複数の経路へのデータの分配比率を適応的に変更する。
【0009】
この発明によれば、ネットワーク上の送信元ノードから送信先ノードへ通信経路を複数設定し、データを分配送信する送信装置は、上記経路の品質情報を上記送信先ノードから取得する手段と、上記品質情報取得手段により取得した上記経路の品質情報に基づいて、上記複数の経路へのデータの分配比率を適応的に変更する分配制御手段とを含むように構成される。
【0010】
【発明の実施の形態】
以下、本発明の実施の形態を、図面に示す好適実施例に基づいて、詳細に説明する。なお、以下の説明では、わかりやすくするために、効果が顕著である実時間型のデータ転送を例にとって、ネットワーク品質を監視する仕組みを備えているRTP/RTCP(Realtime Transport Protocol/Real Time Control Protocol)を利用しているが、本発明はもちろんこれに限らない。これ以外にも、ネットワーク品質を監視する手段を備えた各種のデータ配信方式も本発明の範疇である。
発明の基本原理
図1は本発明によるデータ送信制御方法を適用する基本的ネットワーク構成を示すブロック図であり、図2は、図1のネットワーク構成における送受信ノード間のRTP/RTCPを用いたマルチメディアのデータ配信システムのコネクション構成図である。RTPは映像や音声データのパケット配信をサポートするために開発されたプロトコルであり、リアルタイムのアプリケーションにおけるフレーム化する機能を有している。
【0011】
図1に示すように、この発明が適用されるネットワーク構成は、既存のネットワーク30と、それにエッジルータ21,22を介して接続されたノード11,12を有している。この発明によれば、例えば、送信元ノード11から送出されたデータパケットは、エッジルータ21において1つ又は複数の経路、例えば31,32に分配され、それぞれの経路を経てエッジルータ22から送信先ノード12に到達する。ここでは2つの経路31,32のみを示しているが、多数の経路がある場合もあり、従って、各エッジルータ21,22(ルータ22は必ずしもエッジである必要はない)は少なくとも経路の数以上のポートP0, P1, P2を有している。
【0012】
この発明によるデータ送信制御方法の基本原理は、1つの送信元ノード11から1つの送信先ノード12へ1つ又は複数の経路31、32にトランスポートプロトコルを使ってパケットを分配して送信し、送信先ノード12は受信したパケットに基づいて、例えばパケット損失率、パケットのパケット間隔ジッタ、パケット片道伝送時間などの1つ又は複数を求め、経路の品質を表す情報(経路の品質情報)として受信者レポートに書き込んで送信元に返送する。送信元は、受信した受信者レポート中の経路の品質情報に基づいて複数経路へのパケットの分配比率を変更することを、受信者レポートを受ける毎に繰り返すことにより適応的に分配比率を決める。
【0013】
図2に示すように、トランスポートプロトコルとしてRTPを用いたデータ配信システムでは、RTSP(Real Time Streaming Protocol)のTCP(Transport Control Protocol)チャンネル101とRTPのUDP(User Datagram Protocol)チャンネル102により送信元ノード11と送信先ノード12の間で接続が確立される。RTCPによる制御チャネル103はRTPのデータ伝送を制御するために使用され、上述のようにデータ配信の品質についてアプリケーションに情報提供する機能を備えている。
各経路の品質を測定する手段として、例えば後述の実施例のようにRTP/RTCPのセッションを各経路に張り、上位アプリケーションにおいて複数経路に分配して送出する全パケットに対し統一されたシーケンス番号を付与し、送信先ノードではこのシーケンス番号を基に複数経路を通して同一送信元から受信したパケットをシーケンス番号順に並び替えを行う。
【0014】
図3及び図4には、IETF(Internet Engineering Task Force)の仕様によるRTPヘッダ6Hのフォーマット及びRTCPを使用した受信者レポート(以下、RTCP−RRと表す)のパケット70のフォーマットを示す。図3に示すようにRTPヘッダ6Hは、バージョン情報V、パッディングP,拡張ビットX,関係送信者数CC、マーカービットM,ペイロードタイプPT、シーケンス番号SN、タイムスタンプTS、同期送信者識別子SSRC、関係送信者識別子CSRCを有し、ペイロード63が付加される。この発明によるデータ送信制御方法に直接関連するものは、パケットのシーケンス番号(SN)61、送出時刻を示すタイムスタンプ(TS)62,同期送信者識別子SSRC、データを収容するペイロード(PL)63などである。
【0015】
図4に示すように、受信者レポート(RTCP−RR)70は、バージョン情報V,パッディングP、受信者レポートカウントRRC、パケットタイプPT、メッセージ長ML、送信者の同期ソース識別子SSRC、送信者1の同期ソース識別子、パケット損失率71、累積損失パケット数(NPL)、パケット間隔ジッタ(J)72、最新送信者レポート時刻LSR、送信者レポート経過時間DLSRを有している。これらのうち、この発明によるデータ送信制御方法に直接関係するものは、同期送信者識別子SSRC、パケット損失率71、パケット間隔ジッタ72、最新送信者レポート時刻73、送信者レポート経過時間DLSR74などである。
【0016】
送信先ノード12では、受信したRTPパケット60中のシーケンス番号61とタイムスタンプ62を基に、パケット損失率及び送信元ノード11から送信先ノード12への片方向伝送時間のジッタ(伝送パケット間隔ジッタ、以下、単にジッタと呼ぶ)Jを算出することが可能である。一方、送信元ノードでは、受信者レポートRTCP−RRからパケット損失率71と片方向伝送時間のジッタ72を得ることができる。更に、送信元ノードから送信先ノード送信されるRTCPを使用した送信者レポート(以下RTCP−SRと表す)の送信時刻と、受信者レポートRTCP−RRの受信時刻とRTCP−RRに書き込まれている最新送信者レポート時刻LSR及び送信者レポート経過時間DLSRとからRTCPのパケット往復時間RTTを算出することが可能である。
【0017】
図5はRTCPを使用した送信者レポート(RTCP−SR)の構成を示す。この構成の、受信者レポートRTCP−RRと異なる点は、送信者情報としてNTP timestamp81と、RTP timestamp82と、送信パケット累計数SPC83などが更に追加されている点である。
図6はIPヘッダ4Hの構成を示す。IPヘッダはバージョン情報Vと、ヘッダ長IHL(Internet Header Length)と、TOS(Type Of Service)41と、IP全パケット長(LEN)42と、データグラム識別子ID43と、フラグメント制御フィールドFRAGMENT44と、送信者アドレスSOURCE ADDRESS45と、宛先アドレスDESTINATION ADDRESS46とを含んでいる。
【0018】
図7はUDP(User Datagram Protocol)50の構成を示す。UDPはUDP送信ポート番号51と、UDP宛先ポート番号52と、全UDPデータグラムのバイト数を表すLENGTH53などを含むヘッダ5Hと、データ54とから構成されている。
RTPパケットは図8Aに示すように、IPヘッダ4H、UDPヘッダ5H、RTPヘッダ6H、RTPデータ(ペイロード)63から構成されている。又、RTCPパケットは図8Bに示すように、IPヘッダ4H、UDPヘッダ5H、RTCPメッセージ7Mから構成されている。IPヘッダ4Hには図6に示したようにTOSフィールドが設けられており、またUDPヘッダ5Hには図7に示したように宛先ポート番号フィールドが設けられている。
【0019】
図1に示したネットワーク30上の各エッジルータ21、22はパケットのルーティングをどのように行うかそのポリシーを予め設定し、それに従ってルーティングを行うポリシールーティング機能を有しているものも一般に存在する。例えば、ノードに接続されたポート0番から入力されたパケットに対してはIPヘッダ4HのTOS41の値(以下、単にTOS値と呼ぶ)によりどのポートに出力するかを決め、ポート0番以外のポートに入力したパケットに対してはIPヘッダの宛先アドレス46によりどのポートに出力するかを決めることができる。従って、送信元ノード11のアプリケーションにより、所望の分配比率で複数のポートP1, P2にパケットを分配するように各パケットのIPヘッダ4HのTOS値を順次決めることができる。
【0020】
あるいは、アプリケーションにより図7に示したUDPの宛先ポート番号52によりポート番号を指定し、ルータ21はこの宛先ポート番号52に従ってパケットを指定されたポートに出力するように設定してもよい。従来のend−to−end connectionではアプリケーションはTOS値を一定値に固定し、ルータはIPヘッダ4Hの宛先アドレス46に対応するポートをルーティングテーブルに従って選択し、パケットを出力するのが一般的な設定である。
図9は送信元ノード11と送信先ノード12間のパケット転送シーケンスの例を示している。送信元ノード11はRTPによりパケットデータを1つ又は複数の経路から送出し、更に一定時間δT(例えば数秒)毎に送信者レポートRTCP−SRを送出する。送信元ノード11と送信先ノード12間の矢印はパケットを表し、記号xは経路上で喪失したパケットを表している。送信先では送信元からそれぞれの経路を通して受信されたパケットをRTPヘッダ6H中のパケットシーケンス番号61(図3)順に並べて、どの番号が欠落しているか調べ、パケット損失率を計算する。
【0021】
送信先ノード12は送信元ノード11と同じ一定時間δT(必ずしも同じである必要はない)ごとにRTCP−RRを送信元ノード11に送る。このとき、送信先ノード12はこのRTCP−RRにパケット損失率と、パケット間隔ジッタJと、直前に受信したRTCP−SR(図5)のタイムスタンプ81と、最新送信者レポートRTCP−SRからの経過時間DLSR(Delay since Last)とを経路品質情報としてRTCP−RRのフィールド71〜74(図4)に書き込んで送信元に送る。DLSRは図9に示すように最新送信者レポートRTCP−SRの受信時刻Ciと受信者レポートRTCP−RR作成時点の時刻TiからDLSR=Ti−Ciにより求める。
【0022】
RTPパケットのパケット間隔ジッタJは、受信した順にn−1番目とn番目のRTPパケットの受信時刻Rn−1, RnとそれらのRTP内のタイムスタンプTSn−1, TSnから例えば次式
D(n, n−1) =(Rn−TSn)−(Rn−1−TSn−1) (1)
J = J+[|D(n, n−1)|−J]/16 (2)
により定義されている。
送信元ノード11は送信先ノード12から受信したRTCP−RRから経路品質情報を取り出し、パケット間隔ジッタJに基づいてそれぞれの経路へのRTPパケットの分配比率を決める。あるいは、送出したRTCP−SRに対する受信者レポートRTCP−RRの受信時刻TRから、RTCPの往復時間RTTを
RTT=TR−DISR−LSR (3)
により求め、経路の品質情報として使用してもよい。
【0023】
このように、送信元ノードでは経路のトラヒック状態(品質)を知ることができるため、経路の状態を考慮して各経路へのパケットデータの分配比率を適応的に増減することが可能になる。本実施例の特徴とするところは、データ配信される経路品質を随時測定し、この品質情報に基づいて各経路へのパケットの分配比率を決定するところにある。
図10はこの発明によるデータ送信制御方法の基本原理による送信元ノード及び送信先ノードの処理手順を示す。
【0024】
送信元ノードにおいては、
ステップS11:複数の経路に対し分配比率の初期値を任意に決める。
ステップS12:決定した分配比率でRTPパケットを分配転送する。又、一定時間ごとに送信報告RTCP−SRを送信する。
ステップS13:送信先ノードから受信者レポートRTCP−RRが受信されたかチェックし、受信されてなければステップS12に戻る。
ステップS14:送信先から受信者レポートが受信されていれば、受信した受信者レポートRTCP−RRから経路品質情報を取得、または算出する。
ステップS15:得られた品質情報に応じて複数の経路に対する分配比率を更新し、ステップS12に戻り、更新した分配比率でRTPパケットを転送する。
【0025】
送信先ノードにおいては、
ステップS21:RTPパケットを受信する。
ステップS22:送信元ノードから送信者レポートRTPC−SRが受信されたかチェックし、受信されてなければステップS21に戻る。
ステップS23:受信したRTPパケット及び/又は送信者レポートRTPC−SRから経路の品質情報を算出又は取得する。
ステップS24:経路品質情報を受信者レポートRTCP−RRに書き込んで送信元に送信し、ステップS21に戻る。
経路の品質情報としては、前述のように、データ配信される各経路のパケット損失率、ラウンドトリップタイム、ジッタのいずれか1つまたは複数を使用することができ、その品質情報に基づいて各経路へのデータの分配比率を変更する。
【0026】
第1実施例
この実施例においては、上述の経路品質情報に基づいて複数の経路への分配比率を変更する方法として、送信先ノードにおいて、それぞれの経路を通して受信したRTPパケット及びRTCP−SRから各経路の品質情報をそれぞれ求めて送信元に送信し、送信元はそれぞれの経路の品質情報に基づいて各経路に対する分配比率を変更する。各受信RTPパケットのIPヘッダ4HのTOS値(図6)又はUDPヘッダ5Hの宛先ポート番号52(図7)からそのパケットが出力された経路を知ることができるので、経路毎にパケット損失率、パケット間隔ジッタを求めることができる。
例えば、パケット損失率が大きい経路では、持続的な輻輳が起きている可能性があるため、この経路へのデータの分配比率を大幅に下げ、代りにパケット損失率の小さい経路への分配比率を上げるように制御する。
【0027】
また、パケット往復時間及びジッタJが大きい経路では、一時的な輻輳が起きている可能性があるため、その経路へのデータの分配比率を所定値だけ下げ、代りにラウンドトリップタイム及びジッタJが小さい経路への分配比率を所定値だけ上げるように制御する。
送信元ノードによる分配比率の変更方法としては、図10の送信元ノードの処理において、例えばRTCP−RRを受信する毎にステップS14でそれぞれの経路の品質値(品質の高さ)を互いに比較し、最も品質値の小さい経路に対し所定値だけ分配比率を減らすと共に、最も品質値の大きい経路に対する分配比率を所定値だけ増加させることを繰り返すことにより、適応的に分配比率を変更する。
図11は経路品質情報としてジッタJを使用する場合の送信元ノードの処理手順を示す。
ステップS1:複数の経路に対し分配比率の初期値を任意に設定する。
ステップS2:それぞれの経路に設定された分配比率でパケットを送信する。
ステップS3:受信したRTCP−RRからそれぞれの経路のジッタJを取得する。
ステップS4:それぞれのジッタJを互いに比較する。
ステップS5:ジッタJが最も小さい経路への分配比率を所定値だけ増加し、最もジッタ値の小さい経路への分配比率を所定値だけ減少させステップS2に戻る。
図11の処理は経路品質情報としてジッタを使う場合を示したが、ジッタの代わりに受信者レポートRTCP−RRから取得したパケット損失率を使ってもよいし、RTCP−RRから取得したLSR, DLSRと、RTCP−RRの受信時刻TRとから求めた往復時間RTTを使用してもよい。
【0028】
ところで、第1実施例において複数経路に対する分配比率の適応的変更を繰り返していくと、ある経路に対する分配比率が極端に小さくなってしまうことがある。そのような場合、その経路からは他の経路と比べて非常に長い間隔でパケットを送出することになる。ところが、図12に示すように、パケットの間隔δが長くなると、その経路の実際のトラヒック量と関係なく、パケット間隔のジッタが急激に大きくなってしまうことが発明者らのシミュレーションにより分かった。そこで、より実態に即したジッタ値が送信先で測定されるように、送信元ノードは、図11のステップS2において、各経路へ送信するパケットの送信間隔が等しくなるように送信タイミングや送信順序を調整してもよい。
【0029】
例えば、各経路へは少なくとも2つ以上連続してパケットを送出し、連続するパケットの間隔は等しくする。即ち、図1の例のように経路が31,32の2つであり、それらに対する分配比率を1:9とすると、経路31に連続して10個のパケットを等間隔で送出し、次に経路32に連続して90個のパケットを等間隔で送出する。この場合、経路31でのパケット間隔と経路32でのパケット間隔は必ずしも等しくなくてもよい。
【0030】
第2実施例
第2実施例では、送信先ノードは図10のステップS21において複数経路から受信されたパケットを経路で区別せずに扱い、受信パケット全体としてパケット損失率やパケット間隔ジッタを算出する。即ち、上記複数の組の経路を1つの仮想経路とみなして受信パケットを処理する。得られた経路情報をステップS22でLSR, DLSRと共にRTCP−RRに挿入して送信元ノードに送る。
【0031】
送信元ノードは、ステップS13で受信者レポートRTCP−RRから得た経路品質情報に基づいてステップS14で適応的に複数の経路に対する分配比率を変更する。例えば、任意に選択した1つの経路に対し分配比率を所定値だけ増加させ、その結果、次に受信したRTCP−RRから得られた仮想経路の品質情報が向上したことを示していれば、上記1つの経路に対して更に所定値だけ分配比率を増加させ、逆に経路品質情報が品質低下を示していれば上記1つの経路に対する分配比率を所定値だけ下げ、他の1つの経路に対し分配比率を所定値だけ増加させる。このように、各経路に対する分配比率を変更し、その結果得られた仮想経路の品質情報の変化をフィードバックすることにより適応的にそれぞれの経路に対する分配比率を決めることができる。品質情報としては、例えばジッタ、パケット往復時間、パケット損失率などを使用することができる。
【0032】
第3実施例
上述の各実施例では送信元ノードは常に複数の経路へ分配比率に従ってパケットを送出する場合を示したが、第3実施例では、通常は複数経路のうちの1つを予めデフォルト経路として決めておき、そのデフォルト経路のみによりパケットを送信し(即ち、他の経路への分配比率を0%とする)、デフォルト経路の品質が許容レベルより低下した場合に他の経路への分配比率を増加させ、デフォルト経路の品質が許容レベル以上に回復した場合は、再びデフォルト経路への分配比率を100%とするように制御する。
【0033】
図13は第3実施例の送信元ノードの処理手順を示す。
ステップS1:予めデフォルト経路を決め、初期値としてその経路への分配比率を100%に設定する。
ステップS2:デフォルト経路に分配比率100%でパケットを送出する。
ステップS3:受信者レポートRTCP−RRからデフォルト経路の品質情報を取得し、またはそのRTCP−RRの受信時刻TRとLSR, DLSRからパケット往復時間を品質情報として算出する。
ステップS4:デフォルト経路の品質を許容レベルと比較する。
ステップS5:経路品質が許容レベルより小であれば、RTCP−RRから他経路の品質情報を取得する。
ステップS6:他経路の品質が許容レベルより大であれば、デフォルト経路の分配比率を所定値だけ減らし、経路品質に応じて他の経路の分配比率を増加し、ステップS2に戻る。ただし、デフォルト経路への分配比率が100%となっている場合は他経路の品質情報が得られないので他経路への分配比率を均等に増加する。
ステップS7:ステップS4で経路品質が許容レベル以上であれば、デフォルト経路への分配比率を所定値だけ増加し、他の使用経路の分配比率を所定値ずつ下げ、ステップS2に戻る。デフォルト経路への分配比率がすでに100%となっている場合は、そのまま変更しない。
【0034】
第4実施例
上述の第3実施例では通常使用する経路として1つのデフォルト経路を決めた場合を示したが、この第4実施例では複数経路のうち通常使用する経路として任意の1つの経路を選択して使用し、その経路の品質が許容レベルより下がった場合に、他の経路への分配比率を与える。
図14は第4実施例の送信元ノードの処理手順を示す。
ステップS1:任意に選択した1つの経路に分配比率100%を初期値として設定する。
ステップS2:設定されている分配比率に従ってパケット転送を行う。
ステップS3:受信者レポートRTCP−RRから経路の品質情報を取得、または算出する。
ステップS4:品質が許容レベル以上の経路があるか判定する。
ステップS5:品質が許容レベル以上の経路が存在する場合は、それらの経路にのみ分配比率を所定値増加させてステップS2に戻る。
ステップS6:経路の品質が許容レベル以上の経路がなかった場合は経路の品質に応じて分配比率を制御し、ステップS2に戻る。
【0035】
図14実施例により、ステップS4で経路の品質が許容レベル以下に悪化したと判定された場合、トラヒックの一部を他の経路へ分配し、各経路の品質を比較して、品質の良い方の経路への分配比率を徐々に上げていく。どちらか一方の経路のみを用いても品質が許容レベルを満足すると判断できた場合には、この経路のみを用いて通信を行うように制御することができる。
【0036】
第5実施例
前述のように送信元ノードにおいて複数経路に対する分配比率を適応的に変更することにより、単一経路のみに100%の分配比率が設定され、その他の経路には0%の分配比率が設定されてしまうことがある。その場合は、その1つの経路のみからパケットが送信されることになるので、送信元ノードでは、受信者レポートから他の経路についての品質情報が得られないため、複数経路により通信していた場合とは得られる品質情報が異なる。このように、複数経路に対する分配比率を変更することにより、1経路のみで通信を行う状態と、複数経路により通信を行う状態が起こりえる。そこでこの実施例では、この1経路通信状態と、複数経路通信状態とでは異なる分配比率の制御方法を採用する。
【0037】
図15は第5実施例による送信元ノードの処理手順を示す。
ステップS1:複数の経路に対し任意に決めた分配比率の初期値を設定する。
ステップS2:設定された分配比率によりRTPパケットをそれぞれの経路に送出する。
ステップS3:受信者レポートRTC−RRからそれぞれの経路の品質情報を取得、または算出する。
ステップS4:現在1経路通信状態か否かを判定する。
ステップS5:1経路通信状態の場合、1経路通信状態に対して予め決めた方法により複数経路に対し分配比率を決定し、ステップS2に戻る。
ステップS6:複数経路通信状態の場合、複数経路通信状態に対して予め決めた方法により複数経路に対し分配比率を決定し、ステップS2に戻る。
【0038】
1経路のみにより通信を行っている場合、上記ステップS3において、経路ごとに経路品質情報を取得することは不可能である。ある経路において輻輳が起き始める直前にパケット往復時間が急激に増加する現象が起きることが発明者らのシミュレーションによりわかった。図16A,16B,16Cは1つの経路において時間経過とともにトラヒック量ρが単調に増加した場合のジッタ、パケット往復時間、パケット損失の変化をシミュレーションにより求めた結果を示す。図16Cに示すように、トラヒックの増加によりある時点からパケット損失が急増し、輻輳が発生したことを示している。図16Aのジッタは輻輳状態の開始時点でピークとなるような緩やかな変化を示している。これに比べて図16Bはパケット往復時間が輻輳の生じる直前に急激に増加し、その後あまり変化しないことを示している。
【0039】
そこでステップS5において例えば、通信に使用している経路でパケット損失が大きくなった場合には、持続的な輻輳が起きている可能性があるため、この経路へのパケットの分配比率を大幅に下げ、代わりに他の経路への分配比率を大幅に上げるよう制御する。あるいは、パケット損失が設定水準より小であった場合でも、例えば通信に使用している経路でパケット往復時間RTTが大きくなった場合には、輻輳が起きる可能性があるため、この経路へのパケットの分配比率を所定値だけ下げ、他の経路への分配比率を所定値だけ上げるよう制御する。
【0040】
複数経路により通信を行っている場合、各経路へ送出したRTPパケットから経路ごとのパケット損失をRTCP−RRから取得することが可能である。例えばパケット損失が大きい経路では、持続的な輻輳が起きている可能性があるため、上記ステップS6においてこの経路へのパケットの分配比率を大幅に下げ、代わりにパケット損失が小さい経路への分配比率を他の経路のパケット損失率に基づいて大幅に上げるように制御する。同様に、複数経路を同時に使用して通信を行っている場合、各経路へ送信したRTPパケットから経路ごとのジッタ情報を収集することが可能である。例えば、ジッタが大きい経路では、一時的な輻輳が起きている可能性があるため、この経路へのパケットの分配比率を少し下げ、代わりにジッタが小さい経路への分配比率をそれらの経路のジッタに基づいて上げるように上記ステップS6において制御する。
【0041】
複数の経路へパケットを送出する場合は、前述のようにパケットの送出間隔が経路間でほぼ等しいようにパケットの送出タイミングや送出順序を調整することにより、ジッタの測定値の信頼性を高めることができる。
図17は図15におけるステップS5の実施例を示す。
1経路による通信時に品質情報としてパケット損失とパケット往復時間をモニタし、パケット損失が設定水準を超えて増加した場合はその経路への分配比率を大きく下げ、他経路への分配比率を均等に増加させ、パケット往復時間が設定水準を超えた場合は、図16A,16B,16Cで説明したようにその経路へのトラヒックが集中して輻輳が起こる状態にあると推定し、その経路への分配比率を100%から所定値だけ下げ、その下げた分を他の経路へ例えば均等に分配する。以下、図15におけるステップS5の実施例を図17を参照して説明する。
ステップS51:現使用1経路のパケット損失率を予め決めた設定水準PLSと比較し、損失率がPLS以上であるか判定する。
ステップS52:パケット損失率がPLS以上の場合は、パケット損失率がPLS以下の経路への分配比率を所定値だけ増加させる。
ステップS53:パケット往復時間RTTが予め決めた設定水準RTTS以上か判定し、RTTS以上であれば、そのまま図15のステップS2に戻る。
ステップS54:パケット往復時間RTTが RTTS以上でなければ所定値δRTTSだけ設定水準RTTSを下げてステップS2に戻る。
ステップS55:ステップS51でパケット損失率が設定水準PLS以上でなければ、パケット往復時間RTTが設定水準RTTS以上であるか判定し、否であればステップS2に戻る。
ステップS56:パケット往復時間RTTがRTTS以上であれば、前述のように、その経路で輻輳が起きることが予測されるので現経路への分配比率を所定値だけ下げ、他の経路への分配比率を所定値だけ増加し、ステップS2に戻る。
【0042】
このように、第5実施例においては、複数経路からパケットを送信している場合と、1経路のみからパケットを送信している場合とで、異なる経路品質情報に基づいて分配比率を決めることができる。
図17の処理手順において、パケット損失率の代わりにジッタを使用してもよい。例えば、ジッタが大きい経路では、一時的な輻輳が起きている可能性があるため、この経路へのデータの分配比率を所定値だけ下げ、代わりにジッタが小さい経路への分配比率を所定値だけ上げるように制御する。
【0043】
第6実施例
上述した各実施例において、経路の品質情報の1つとしてパケット往復時間RTTを使用することとができることを述べたが、往復時間RTTは送信先ノードから送信元ノードへの方向の経路の状態の影響を受けるため、送信先ノードの受信状態を示す指標として的確でない。むしろ、経路の品質情報をより正確に表すものとして、パケットの片道所要時間が有効である。
第6実施例は、経路の品質情報としてこの片道所要時間を使用する。しかしながら、片道所要時間を正確に測定するには送信元ノードと送信先ノードのクロックが互いに同期している必要がある。この実施例では、GPS(geographical positioning system)を利用して両ノード間のクロックを同期させ、片道所要時間を測定する場合を示す。
【0044】
図18は第6実施例を適用するネットワーク構成を、図1の構成と同様なものに同じ参照番号をつけて示す。このネットワーク構成で特徴的なことは、各ノード11、12にGPS受信機11G、12Gが設けられ、衛星90からのGPS信号を受信してそれぞれのノードのクロック(コンピュータ内のクロック)が同じGPS信号の示す時刻に同期している。
この実施例で使用する片道所要時間TTは、例えば送信元ノードがそれぞれの経路に送出するRTPパケットのRTPヘッダ(図3)に書き込んだタイムスタンプ(TS)62と、送信先ノードがそれぞれの経路からそれらのRTPパケットを受信した時刻Rnとから、TT=Rn−TSにより算出し、RTCP−RRの適当なフィールドに書き込んで送信元ノードに送る。送信元ノードは受信者レポートRTCP−RRから取得したそれぞれの経路での片道所要時間TTを前述した各実施例において品質情報として使用する。例えば、それら複数経路の片道所要時間TTの逆数の比を分配比率としてそれぞれの経路に設定することができる。
【0045】
片道所要時間の場合のみならず、ジッタやパケット損失率の場合も、このようにそれぞれの経路の品質情報に対応してそれぞれの経路の分配比率を設定することにより、送信元ノードから送信先ノードへの伝送速度を最大にすることができる。
送信先ノードにおける片道所要時間の測定は、それぞれの経路から受信した送信者レポートRTCP−SRの受信時刻Ciを測定して使用してもよい。その場合、各経路からのRTCP−SRの受信時刻Ciと、そのRTCP−SR中のタイムスタンプから片道所要時間TTを求めてもよい。
【0046】
送信先ノードの処理手順
図19A,19B及び19Cは、上述した各実施例において、送信先ノードが行う処理手順を示す。
図19Aの処理は各経路の品質情報を取得する処理を示す。
ステップS11:それぞれの経路からのRTPパケットを受信する。
ステップS12:各RTPパケットの受信時刻Rnを取得する。
ステップS13:受信RTPパケットからその送信時刻を示すタイムスタンプTS(図3)を取得する。
ステップS14:各経路についてパケット間隔ジッタJを前述した式(1), (2)から算出する。
ステップS15:受信RTPパケットのシーケンス番号SNに基づいてパケット損失を検出し、各経路についてのパケット損失率を算出する。
ステップS16:受信RTPパケットを受信バッファに格納する。
【0047】
受信RTPパケットからペイロード部のデータがアプリケーションにより取り出され、使用される。
図19Bは送信者レポートRTCP−SRの受信処理を示す。
ステップS21:送信者レポートRTCP−SR(図5)を受信する。
ステップS22:RTCP−SRの受信時刻Ciを保存する。
ステップS23:RTCP−SRからNTPタイムスタンプを取り出し、保存する。
図19Cは受信者レポートの送信処理を示す。
ステップS31:間隔δTごとのタイミングを与えるタイマーを起動する。
ステップS32:受信者レポートRTCP−RRのパケットを作成する。
ステップS33:現時刻Tiを取得する。
ステップS34:最新の送信者レポートRTCP−SRを受信した時刻Ci(図19BのステップS22,S23)と現時刻Tiから経過時間DLSR=Ti−Ciを算出する。
ステップS35:図19AのステップS14、S15で得たジッタJ、パケット損失率及び経過時間DLSR、RTCP−SR中のNTPタイムスタンプをRTCP−RRに挿入する。
ステップS36:受信者レポートRTCP−RRを送信する。
【0048】
上記各実施例に係るデータ送信制御方法は、これをコンピュータ制御によって行わせることが好ましく、本発明の権利範囲には、このようなデータ送信制御方法をコンピュータ制御により実行するためのプログラムをも含むものであることは前述の通りである。
上述の各実施例の説明から明らかなように、この発明のデータ送信制御方法を実行する送信元ノード11を構成するデータ送信装置は、送信先ノードから経路の品質情報を取得する品質情報取得手段と、その品質情報に基づいて複数の経路へのデータの分配比率を適応的に変更する分配制御手段を有している。図20はこのデータ送信装置の構成例を示す。この基本構成は一般のコンピュータと同様であり、CPU(中央演算処理装置)11Aと、RAM(ランダムアクセスメモリ)11Bと、大容量記憶装置としてのハードディスク11Cと、ディスプレイ11Eとを有しており、更に、エッジルータ21に接続されたネットワークインタフェースカード11Dを有している。送信元ノード11が実行する前述したこの発明のデータ送信制御の処理手順を記述したプログラムは例えばハードディスク11Cに格納されており、通信の実行時にプログラムをRAM11Bに読み出してCPU11Aがそのプログラムを実行する。したがって、この発明の送信装置11における品質情報取得手段及び分配制御手段は、プログラムを実行することによりコンピュータにより実施される。
【0049】
上記各実施例はいずれも本発明の一例を示すものであり、本発明はこれらに限定されるべきものではなく、本発明の要旨を変更しない範囲内において、適宜の変更,改良を行ってもよいことはいうまでもない。
【0050】
【発明の効果】
以上、詳細に説明したように、本発明によれば、ベストエフォート型サービスのインターネット網において、データの送受信を行う二地点間で複数の経路を設定し、その経路へのデータの分配比率を刻々と変化する経路状態に対応して迅速に変更することで、ネットワークの障害や輻輳によるデータの損失や遅延を避け、スループットの向上を図ることが可能になるという顕著な効果を奏するものである。
【図面の簡単な説明】
【図1】この発明が適用されるネットワークの構成を示す図。
【図2】図1における送信元ノードと送信先ノード間の接続を示す図。
【図3】RTPヘッダの構成を示す図。
【図4】受信者レポートRTCP−RRのパケット構成を示す図。
【図5】送信者レポートRTCP−SRのパケット構成を示す図。
【図6】IPパケットの構成を示す図。
【図7】UDPプロトコルの構成を示す図。
【図8】AはRTPパケットの構成を示す図、BはRTCPパケットの構成を示す図。
【図9】送信元ノードと送信先ノード間の通信シーケンスを示す図。
【図10】この発明の送信制御方法の原理的な処理手順を示す図。
【図11】この発明の第1実施例による送信元ノードの処理手順を示す図。
【図12】パケット間隔と測定されるジッタの関係を示す図。
【図13】この発明の第3実施例による送信元ノードの処理手順を示す図。
【図14】この発明の第4実施例による送信元の処理手順を示す図。
【図15】この発明の第5実施例による送信元の処理手順を示す図。
【図16】Aは輻輳の発生とジッタの変化を示すグラフ、Bは輻輳の発生とパケット往復時間の変化を示すグラフ、Cは輻輳の発生とパケット損失の変化を示すグラフ。
【図17】図15におけるステップS5の実施例を示す図。
【図18】この発明の第6実施例が適用されるネットワークの構成を示す図。
【図19】Aはこの発明の各実施例において送信先ノードが行う経路品質情報を取得する処理手順を示す図、Bは送信先ノードが送信者レポートから情報を取得する処理を示す図、Cは送信先ノードが受信者レポートを作成する処理を示す図。
【図20】この発明の実施する送信元ノードを構成するデータ送信装置の構成を示すブロック図。
【発明の属する技術分野】
本発明は、インターネットのようなベストエフォート型サービスのネットワークにおいて、ネットワークの負荷集中や輻輳による伝送遅延揺らぎやパケット損失を回避するのに好適に利用可能なデータ送信制御方法及びこの方法のプログラム並びにこれを用いるデータ送信装置に関する。
【0002】
【従来の技術】
インターネットの経路選択アルゴリズムが選択する経路は、通常、ノード間における最短経路の一つだけであるため、従来のインターネットでは、その一つの経路のみを用いる通信が行われている。
一方で、こうした従来のインターネットをマルチパスに適応させる試みも行われている。例えば、ルーティングアルゴリズムにOSPF(Open Shortest PathFirst)を利用している場合には、メトリックスが等しい複数経路に対してトラヒックの等価負荷分散をサポートし、IGRP(Interior Gateway Routing Protocol)を利用している場合には、メトリックスが必ずしも等しくない複数経路に対してトラヒックをメトリックに比例して不等分に分配する機能を実装したルータが知られている。
【0003】
しかしながら、1経路のみを用いて通信を行う現在のインターネットでは、通信を行っているネットワークにおける障害・輻輳は避けられず、こうしたネットワークの障害・輻輳によるデータの損失や大幅な遅延が生じた場合、輻輳制御によりその経路へ転送するトラヒックを抑えることになり、所望のスループットが得られないという問題がある。
また、ルータにおいて経路のメトリック値に基づいてデータの分配比率を決定する従来の複数経路データ分配方式は、上記メトリック値には、刻々と変化する経路状態が反映されないため、各経路の状態を考慮した最良な分配方式とは言えない。この方式では、状態の悪化した一部の経路に引きずられて、全経路でのスループットが低下するという問題がある。
【0004】
EdgeStream社はネットワークの異なる経路上に同一コンテンツを互いに同期して送信可能な配信サーバを複数設け、一方の配信サーバからユーザへのコンテンツ送信経路のトラヒック量が規定値以上になった場合、他方の配信サーバに切り替えてコンテンツを送信することにより、所定の伝送レート以上による動画品質を保障した配信システムを提案している。この方法は、複数のサーバを必要とするため、それだけコストが高くなる欠点がる。しかも、この方法は経路の切り替え時に再生画面が途切れる可能性がある。
【0005】
特許文献1にはネットワーク上の各ルータが伝送路のトラヒック状態を監視し、予め測定した伝送経路のスループットを超えるトラヒックの集中が生じるとその経路を回避するように経路を切り替える方式が示されている。しかしながら、この方法は各経路のスループットを予め測定し、それに基づいてネットワーク上の全てのルータのルーティングテーブルの作成を行う必要があり、現実性に乏しい。
【0006】
【特許文献1】
日本国特許出願公開公報第2000−216817号、公開日:平成12年8月4日
【0007】
【発明が解決しようとする課題】
本発明はこのような事情を考慮してなされたものであって、その目的とするところは、インターネットのようなベストエフォート型サービスのネットワークにおいて、ネットワークの負荷集中や輻輳による伝送遅延揺らぎやパケット損失を回避するのに好適に利用可能なデータ送信制御方法及びこの方法のプログラム並びにこれを用いるデータ送信装置を提供することにある。
【0008】
【課題を解決するための手段】
この発明による、ネットワーク上の送信元ノードから送信先ノードへデータを送信するための送信元ノードのデータ送信制御方法は、以下のステップを含む:
(a) 上記送信元ノードと上記送信先ノード間の複数の経路の品質情報を上記送信先ノードから取得し、
(b) 上記複数の経路の上記品質情報に基づいて上記複数の経路へのデータの分配比率を適応的に変更する。
【0009】
この発明によれば、ネットワーク上の送信元ノードから送信先ノードへ通信経路を複数設定し、データを分配送信する送信装置は、上記経路の品質情報を上記送信先ノードから取得する手段と、上記品質情報取得手段により取得した上記経路の品質情報に基づいて、上記複数の経路へのデータの分配比率を適応的に変更する分配制御手段とを含むように構成される。
【0010】
【発明の実施の形態】
以下、本発明の実施の形態を、図面に示す好適実施例に基づいて、詳細に説明する。なお、以下の説明では、わかりやすくするために、効果が顕著である実時間型のデータ転送を例にとって、ネットワーク品質を監視する仕組みを備えているRTP/RTCP(Realtime Transport Protocol/Real Time Control Protocol)を利用しているが、本発明はもちろんこれに限らない。これ以外にも、ネットワーク品質を監視する手段を備えた各種のデータ配信方式も本発明の範疇である。
発明の基本原理
図1は本発明によるデータ送信制御方法を適用する基本的ネットワーク構成を示すブロック図であり、図2は、図1のネットワーク構成における送受信ノード間のRTP/RTCPを用いたマルチメディアのデータ配信システムのコネクション構成図である。RTPは映像や音声データのパケット配信をサポートするために開発されたプロトコルであり、リアルタイムのアプリケーションにおけるフレーム化する機能を有している。
【0011】
図1に示すように、この発明が適用されるネットワーク構成は、既存のネットワーク30と、それにエッジルータ21,22を介して接続されたノード11,12を有している。この発明によれば、例えば、送信元ノード11から送出されたデータパケットは、エッジルータ21において1つ又は複数の経路、例えば31,32に分配され、それぞれの経路を経てエッジルータ22から送信先ノード12に到達する。ここでは2つの経路31,32のみを示しているが、多数の経路がある場合もあり、従って、各エッジルータ21,22(ルータ22は必ずしもエッジである必要はない)は少なくとも経路の数以上のポートP0, P1, P2を有している。
【0012】
この発明によるデータ送信制御方法の基本原理は、1つの送信元ノード11から1つの送信先ノード12へ1つ又は複数の経路31、32にトランスポートプロトコルを使ってパケットを分配して送信し、送信先ノード12は受信したパケットに基づいて、例えばパケット損失率、パケットのパケット間隔ジッタ、パケット片道伝送時間などの1つ又は複数を求め、経路の品質を表す情報(経路の品質情報)として受信者レポートに書き込んで送信元に返送する。送信元は、受信した受信者レポート中の経路の品質情報に基づいて複数経路へのパケットの分配比率を変更することを、受信者レポートを受ける毎に繰り返すことにより適応的に分配比率を決める。
【0013】
図2に示すように、トランスポートプロトコルとしてRTPを用いたデータ配信システムでは、RTSP(Real Time Streaming Protocol)のTCP(Transport Control Protocol)チャンネル101とRTPのUDP(User Datagram Protocol)チャンネル102により送信元ノード11と送信先ノード12の間で接続が確立される。RTCPによる制御チャネル103はRTPのデータ伝送を制御するために使用され、上述のようにデータ配信の品質についてアプリケーションに情報提供する機能を備えている。
各経路の品質を測定する手段として、例えば後述の実施例のようにRTP/RTCPのセッションを各経路に張り、上位アプリケーションにおいて複数経路に分配して送出する全パケットに対し統一されたシーケンス番号を付与し、送信先ノードではこのシーケンス番号を基に複数経路を通して同一送信元から受信したパケットをシーケンス番号順に並び替えを行う。
【0014】
図3及び図4には、IETF(Internet Engineering Task Force)の仕様によるRTPヘッダ6Hのフォーマット及びRTCPを使用した受信者レポート(以下、RTCP−RRと表す)のパケット70のフォーマットを示す。図3に示すようにRTPヘッダ6Hは、バージョン情報V、パッディングP,拡張ビットX,関係送信者数CC、マーカービットM,ペイロードタイプPT、シーケンス番号SN、タイムスタンプTS、同期送信者識別子SSRC、関係送信者識別子CSRCを有し、ペイロード63が付加される。この発明によるデータ送信制御方法に直接関連するものは、パケットのシーケンス番号(SN)61、送出時刻を示すタイムスタンプ(TS)62,同期送信者識別子SSRC、データを収容するペイロード(PL)63などである。
【0015】
図4に示すように、受信者レポート(RTCP−RR)70は、バージョン情報V,パッディングP、受信者レポートカウントRRC、パケットタイプPT、メッセージ長ML、送信者の同期ソース識別子SSRC、送信者1の同期ソース識別子、パケット損失率71、累積損失パケット数(NPL)、パケット間隔ジッタ(J)72、最新送信者レポート時刻LSR、送信者レポート経過時間DLSRを有している。これらのうち、この発明によるデータ送信制御方法に直接関係するものは、同期送信者識別子SSRC、パケット損失率71、パケット間隔ジッタ72、最新送信者レポート時刻73、送信者レポート経過時間DLSR74などである。
【0016】
送信先ノード12では、受信したRTPパケット60中のシーケンス番号61とタイムスタンプ62を基に、パケット損失率及び送信元ノード11から送信先ノード12への片方向伝送時間のジッタ(伝送パケット間隔ジッタ、以下、単にジッタと呼ぶ)Jを算出することが可能である。一方、送信元ノードでは、受信者レポートRTCP−RRからパケット損失率71と片方向伝送時間のジッタ72を得ることができる。更に、送信元ノードから送信先ノード送信されるRTCPを使用した送信者レポート(以下RTCP−SRと表す)の送信時刻と、受信者レポートRTCP−RRの受信時刻とRTCP−RRに書き込まれている最新送信者レポート時刻LSR及び送信者レポート経過時間DLSRとからRTCPのパケット往復時間RTTを算出することが可能である。
【0017】
図5はRTCPを使用した送信者レポート(RTCP−SR)の構成を示す。この構成の、受信者レポートRTCP−RRと異なる点は、送信者情報としてNTP timestamp81と、RTP timestamp82と、送信パケット累計数SPC83などが更に追加されている点である。
図6はIPヘッダ4Hの構成を示す。IPヘッダはバージョン情報Vと、ヘッダ長IHL(Internet Header Length)と、TOS(Type Of Service)41と、IP全パケット長(LEN)42と、データグラム識別子ID43と、フラグメント制御フィールドFRAGMENT44と、送信者アドレスSOURCE ADDRESS45と、宛先アドレスDESTINATION ADDRESS46とを含んでいる。
【0018】
図7はUDP(User Datagram Protocol)50の構成を示す。UDPはUDP送信ポート番号51と、UDP宛先ポート番号52と、全UDPデータグラムのバイト数を表すLENGTH53などを含むヘッダ5Hと、データ54とから構成されている。
RTPパケットは図8Aに示すように、IPヘッダ4H、UDPヘッダ5H、RTPヘッダ6H、RTPデータ(ペイロード)63から構成されている。又、RTCPパケットは図8Bに示すように、IPヘッダ4H、UDPヘッダ5H、RTCPメッセージ7Mから構成されている。IPヘッダ4Hには図6に示したようにTOSフィールドが設けられており、またUDPヘッダ5Hには図7に示したように宛先ポート番号フィールドが設けられている。
【0019】
図1に示したネットワーク30上の各エッジルータ21、22はパケットのルーティングをどのように行うかそのポリシーを予め設定し、それに従ってルーティングを行うポリシールーティング機能を有しているものも一般に存在する。例えば、ノードに接続されたポート0番から入力されたパケットに対してはIPヘッダ4HのTOS41の値(以下、単にTOS値と呼ぶ)によりどのポートに出力するかを決め、ポート0番以外のポートに入力したパケットに対してはIPヘッダの宛先アドレス46によりどのポートに出力するかを決めることができる。従って、送信元ノード11のアプリケーションにより、所望の分配比率で複数のポートP1, P2にパケットを分配するように各パケットのIPヘッダ4HのTOS値を順次決めることができる。
【0020】
あるいは、アプリケーションにより図7に示したUDPの宛先ポート番号52によりポート番号を指定し、ルータ21はこの宛先ポート番号52に従ってパケットを指定されたポートに出力するように設定してもよい。従来のend−to−end connectionではアプリケーションはTOS値を一定値に固定し、ルータはIPヘッダ4Hの宛先アドレス46に対応するポートをルーティングテーブルに従って選択し、パケットを出力するのが一般的な設定である。
図9は送信元ノード11と送信先ノード12間のパケット転送シーケンスの例を示している。送信元ノード11はRTPによりパケットデータを1つ又は複数の経路から送出し、更に一定時間δT(例えば数秒)毎に送信者レポートRTCP−SRを送出する。送信元ノード11と送信先ノード12間の矢印はパケットを表し、記号xは経路上で喪失したパケットを表している。送信先では送信元からそれぞれの経路を通して受信されたパケットをRTPヘッダ6H中のパケットシーケンス番号61(図3)順に並べて、どの番号が欠落しているか調べ、パケット損失率を計算する。
【0021】
送信先ノード12は送信元ノード11と同じ一定時間δT(必ずしも同じである必要はない)ごとにRTCP−RRを送信元ノード11に送る。このとき、送信先ノード12はこのRTCP−RRにパケット損失率と、パケット間隔ジッタJと、直前に受信したRTCP−SR(図5)のタイムスタンプ81と、最新送信者レポートRTCP−SRからの経過時間DLSR(Delay since Last)とを経路品質情報としてRTCP−RRのフィールド71〜74(図4)に書き込んで送信元に送る。DLSRは図9に示すように最新送信者レポートRTCP−SRの受信時刻Ciと受信者レポートRTCP−RR作成時点の時刻TiからDLSR=Ti−Ciにより求める。
【0022】
RTPパケットのパケット間隔ジッタJは、受信した順にn−1番目とn番目のRTPパケットの受信時刻Rn−1, RnとそれらのRTP内のタイムスタンプTSn−1, TSnから例えば次式
D(n, n−1) =(Rn−TSn)−(Rn−1−TSn−1) (1)
J = J+[|D(n, n−1)|−J]/16 (2)
により定義されている。
送信元ノード11は送信先ノード12から受信したRTCP−RRから経路品質情報を取り出し、パケット間隔ジッタJに基づいてそれぞれの経路へのRTPパケットの分配比率を決める。あるいは、送出したRTCP−SRに対する受信者レポートRTCP−RRの受信時刻TRから、RTCPの往復時間RTTを
RTT=TR−DISR−LSR (3)
により求め、経路の品質情報として使用してもよい。
【0023】
このように、送信元ノードでは経路のトラヒック状態(品質)を知ることができるため、経路の状態を考慮して各経路へのパケットデータの分配比率を適応的に増減することが可能になる。本実施例の特徴とするところは、データ配信される経路品質を随時測定し、この品質情報に基づいて各経路へのパケットの分配比率を決定するところにある。
図10はこの発明によるデータ送信制御方法の基本原理による送信元ノード及び送信先ノードの処理手順を示す。
【0024】
送信元ノードにおいては、
ステップS11:複数の経路に対し分配比率の初期値を任意に決める。
ステップS12:決定した分配比率でRTPパケットを分配転送する。又、一定時間ごとに送信報告RTCP−SRを送信する。
ステップS13:送信先ノードから受信者レポートRTCP−RRが受信されたかチェックし、受信されてなければステップS12に戻る。
ステップS14:送信先から受信者レポートが受信されていれば、受信した受信者レポートRTCP−RRから経路品質情報を取得、または算出する。
ステップS15:得られた品質情報に応じて複数の経路に対する分配比率を更新し、ステップS12に戻り、更新した分配比率でRTPパケットを転送する。
【0025】
送信先ノードにおいては、
ステップS21:RTPパケットを受信する。
ステップS22:送信元ノードから送信者レポートRTPC−SRが受信されたかチェックし、受信されてなければステップS21に戻る。
ステップS23:受信したRTPパケット及び/又は送信者レポートRTPC−SRから経路の品質情報を算出又は取得する。
ステップS24:経路品質情報を受信者レポートRTCP−RRに書き込んで送信元に送信し、ステップS21に戻る。
経路の品質情報としては、前述のように、データ配信される各経路のパケット損失率、ラウンドトリップタイム、ジッタのいずれか1つまたは複数を使用することができ、その品質情報に基づいて各経路へのデータの分配比率を変更する。
【0026】
第1実施例
この実施例においては、上述の経路品質情報に基づいて複数の経路への分配比率を変更する方法として、送信先ノードにおいて、それぞれの経路を通して受信したRTPパケット及びRTCP−SRから各経路の品質情報をそれぞれ求めて送信元に送信し、送信元はそれぞれの経路の品質情報に基づいて各経路に対する分配比率を変更する。各受信RTPパケットのIPヘッダ4HのTOS値(図6)又はUDPヘッダ5Hの宛先ポート番号52(図7)からそのパケットが出力された経路を知ることができるので、経路毎にパケット損失率、パケット間隔ジッタを求めることができる。
例えば、パケット損失率が大きい経路では、持続的な輻輳が起きている可能性があるため、この経路へのデータの分配比率を大幅に下げ、代りにパケット損失率の小さい経路への分配比率を上げるように制御する。
【0027】
また、パケット往復時間及びジッタJが大きい経路では、一時的な輻輳が起きている可能性があるため、その経路へのデータの分配比率を所定値だけ下げ、代りにラウンドトリップタイム及びジッタJが小さい経路への分配比率を所定値だけ上げるように制御する。
送信元ノードによる分配比率の変更方法としては、図10の送信元ノードの処理において、例えばRTCP−RRを受信する毎にステップS14でそれぞれの経路の品質値(品質の高さ)を互いに比較し、最も品質値の小さい経路に対し所定値だけ分配比率を減らすと共に、最も品質値の大きい経路に対する分配比率を所定値だけ増加させることを繰り返すことにより、適応的に分配比率を変更する。
図11は経路品質情報としてジッタJを使用する場合の送信元ノードの処理手順を示す。
ステップS1:複数の経路に対し分配比率の初期値を任意に設定する。
ステップS2:それぞれの経路に設定された分配比率でパケットを送信する。
ステップS3:受信したRTCP−RRからそれぞれの経路のジッタJを取得する。
ステップS4:それぞれのジッタJを互いに比較する。
ステップS5:ジッタJが最も小さい経路への分配比率を所定値だけ増加し、最もジッタ値の小さい経路への分配比率を所定値だけ減少させステップS2に戻る。
図11の処理は経路品質情報としてジッタを使う場合を示したが、ジッタの代わりに受信者レポートRTCP−RRから取得したパケット損失率を使ってもよいし、RTCP−RRから取得したLSR, DLSRと、RTCP−RRの受信時刻TRとから求めた往復時間RTTを使用してもよい。
【0028】
ところで、第1実施例において複数経路に対する分配比率の適応的変更を繰り返していくと、ある経路に対する分配比率が極端に小さくなってしまうことがある。そのような場合、その経路からは他の経路と比べて非常に長い間隔でパケットを送出することになる。ところが、図12に示すように、パケットの間隔δが長くなると、その経路の実際のトラヒック量と関係なく、パケット間隔のジッタが急激に大きくなってしまうことが発明者らのシミュレーションにより分かった。そこで、より実態に即したジッタ値が送信先で測定されるように、送信元ノードは、図11のステップS2において、各経路へ送信するパケットの送信間隔が等しくなるように送信タイミングや送信順序を調整してもよい。
【0029】
例えば、各経路へは少なくとも2つ以上連続してパケットを送出し、連続するパケットの間隔は等しくする。即ち、図1の例のように経路が31,32の2つであり、それらに対する分配比率を1:9とすると、経路31に連続して10個のパケットを等間隔で送出し、次に経路32に連続して90個のパケットを等間隔で送出する。この場合、経路31でのパケット間隔と経路32でのパケット間隔は必ずしも等しくなくてもよい。
【0030】
第2実施例
第2実施例では、送信先ノードは図10のステップS21において複数経路から受信されたパケットを経路で区別せずに扱い、受信パケット全体としてパケット損失率やパケット間隔ジッタを算出する。即ち、上記複数の組の経路を1つの仮想経路とみなして受信パケットを処理する。得られた経路情報をステップS22でLSR, DLSRと共にRTCP−RRに挿入して送信元ノードに送る。
【0031】
送信元ノードは、ステップS13で受信者レポートRTCP−RRから得た経路品質情報に基づいてステップS14で適応的に複数の経路に対する分配比率を変更する。例えば、任意に選択した1つの経路に対し分配比率を所定値だけ増加させ、その結果、次に受信したRTCP−RRから得られた仮想経路の品質情報が向上したことを示していれば、上記1つの経路に対して更に所定値だけ分配比率を増加させ、逆に経路品質情報が品質低下を示していれば上記1つの経路に対する分配比率を所定値だけ下げ、他の1つの経路に対し分配比率を所定値だけ増加させる。このように、各経路に対する分配比率を変更し、その結果得られた仮想経路の品質情報の変化をフィードバックすることにより適応的にそれぞれの経路に対する分配比率を決めることができる。品質情報としては、例えばジッタ、パケット往復時間、パケット損失率などを使用することができる。
【0032】
第3実施例
上述の各実施例では送信元ノードは常に複数の経路へ分配比率に従ってパケットを送出する場合を示したが、第3実施例では、通常は複数経路のうちの1つを予めデフォルト経路として決めておき、そのデフォルト経路のみによりパケットを送信し(即ち、他の経路への分配比率を0%とする)、デフォルト経路の品質が許容レベルより低下した場合に他の経路への分配比率を増加させ、デフォルト経路の品質が許容レベル以上に回復した場合は、再びデフォルト経路への分配比率を100%とするように制御する。
【0033】
図13は第3実施例の送信元ノードの処理手順を示す。
ステップS1:予めデフォルト経路を決め、初期値としてその経路への分配比率を100%に設定する。
ステップS2:デフォルト経路に分配比率100%でパケットを送出する。
ステップS3:受信者レポートRTCP−RRからデフォルト経路の品質情報を取得し、またはそのRTCP−RRの受信時刻TRとLSR, DLSRからパケット往復時間を品質情報として算出する。
ステップS4:デフォルト経路の品質を許容レベルと比較する。
ステップS5:経路品質が許容レベルより小であれば、RTCP−RRから他経路の品質情報を取得する。
ステップS6:他経路の品質が許容レベルより大であれば、デフォルト経路の分配比率を所定値だけ減らし、経路品質に応じて他の経路の分配比率を増加し、ステップS2に戻る。ただし、デフォルト経路への分配比率が100%となっている場合は他経路の品質情報が得られないので他経路への分配比率を均等に増加する。
ステップS7:ステップS4で経路品質が許容レベル以上であれば、デフォルト経路への分配比率を所定値だけ増加し、他の使用経路の分配比率を所定値ずつ下げ、ステップS2に戻る。デフォルト経路への分配比率がすでに100%となっている場合は、そのまま変更しない。
【0034】
第4実施例
上述の第3実施例では通常使用する経路として1つのデフォルト経路を決めた場合を示したが、この第4実施例では複数経路のうち通常使用する経路として任意の1つの経路を選択して使用し、その経路の品質が許容レベルより下がった場合に、他の経路への分配比率を与える。
図14は第4実施例の送信元ノードの処理手順を示す。
ステップS1:任意に選択した1つの経路に分配比率100%を初期値として設定する。
ステップS2:設定されている分配比率に従ってパケット転送を行う。
ステップS3:受信者レポートRTCP−RRから経路の品質情報を取得、または算出する。
ステップS4:品質が許容レベル以上の経路があるか判定する。
ステップS5:品質が許容レベル以上の経路が存在する場合は、それらの経路にのみ分配比率を所定値増加させてステップS2に戻る。
ステップS6:経路の品質が許容レベル以上の経路がなかった場合は経路の品質に応じて分配比率を制御し、ステップS2に戻る。
【0035】
図14実施例により、ステップS4で経路の品質が許容レベル以下に悪化したと判定された場合、トラヒックの一部を他の経路へ分配し、各経路の品質を比較して、品質の良い方の経路への分配比率を徐々に上げていく。どちらか一方の経路のみを用いても品質が許容レベルを満足すると判断できた場合には、この経路のみを用いて通信を行うように制御することができる。
【0036】
第5実施例
前述のように送信元ノードにおいて複数経路に対する分配比率を適応的に変更することにより、単一経路のみに100%の分配比率が設定され、その他の経路には0%の分配比率が設定されてしまうことがある。その場合は、その1つの経路のみからパケットが送信されることになるので、送信元ノードでは、受信者レポートから他の経路についての品質情報が得られないため、複数経路により通信していた場合とは得られる品質情報が異なる。このように、複数経路に対する分配比率を変更することにより、1経路のみで通信を行う状態と、複数経路により通信を行う状態が起こりえる。そこでこの実施例では、この1経路通信状態と、複数経路通信状態とでは異なる分配比率の制御方法を採用する。
【0037】
図15は第5実施例による送信元ノードの処理手順を示す。
ステップS1:複数の経路に対し任意に決めた分配比率の初期値を設定する。
ステップS2:設定された分配比率によりRTPパケットをそれぞれの経路に送出する。
ステップS3:受信者レポートRTC−RRからそれぞれの経路の品質情報を取得、または算出する。
ステップS4:現在1経路通信状態か否かを判定する。
ステップS5:1経路通信状態の場合、1経路通信状態に対して予め決めた方法により複数経路に対し分配比率を決定し、ステップS2に戻る。
ステップS6:複数経路通信状態の場合、複数経路通信状態に対して予め決めた方法により複数経路に対し分配比率を決定し、ステップS2に戻る。
【0038】
1経路のみにより通信を行っている場合、上記ステップS3において、経路ごとに経路品質情報を取得することは不可能である。ある経路において輻輳が起き始める直前にパケット往復時間が急激に増加する現象が起きることが発明者らのシミュレーションによりわかった。図16A,16B,16Cは1つの経路において時間経過とともにトラヒック量ρが単調に増加した場合のジッタ、パケット往復時間、パケット損失の変化をシミュレーションにより求めた結果を示す。図16Cに示すように、トラヒックの増加によりある時点からパケット損失が急増し、輻輳が発生したことを示している。図16Aのジッタは輻輳状態の開始時点でピークとなるような緩やかな変化を示している。これに比べて図16Bはパケット往復時間が輻輳の生じる直前に急激に増加し、その後あまり変化しないことを示している。
【0039】
そこでステップS5において例えば、通信に使用している経路でパケット損失が大きくなった場合には、持続的な輻輳が起きている可能性があるため、この経路へのパケットの分配比率を大幅に下げ、代わりに他の経路への分配比率を大幅に上げるよう制御する。あるいは、パケット損失が設定水準より小であった場合でも、例えば通信に使用している経路でパケット往復時間RTTが大きくなった場合には、輻輳が起きる可能性があるため、この経路へのパケットの分配比率を所定値だけ下げ、他の経路への分配比率を所定値だけ上げるよう制御する。
【0040】
複数経路により通信を行っている場合、各経路へ送出したRTPパケットから経路ごとのパケット損失をRTCP−RRから取得することが可能である。例えばパケット損失が大きい経路では、持続的な輻輳が起きている可能性があるため、上記ステップS6においてこの経路へのパケットの分配比率を大幅に下げ、代わりにパケット損失が小さい経路への分配比率を他の経路のパケット損失率に基づいて大幅に上げるように制御する。同様に、複数経路を同時に使用して通信を行っている場合、各経路へ送信したRTPパケットから経路ごとのジッタ情報を収集することが可能である。例えば、ジッタが大きい経路では、一時的な輻輳が起きている可能性があるため、この経路へのパケットの分配比率を少し下げ、代わりにジッタが小さい経路への分配比率をそれらの経路のジッタに基づいて上げるように上記ステップS6において制御する。
【0041】
複数の経路へパケットを送出する場合は、前述のようにパケットの送出間隔が経路間でほぼ等しいようにパケットの送出タイミングや送出順序を調整することにより、ジッタの測定値の信頼性を高めることができる。
図17は図15におけるステップS5の実施例を示す。
1経路による通信時に品質情報としてパケット損失とパケット往復時間をモニタし、パケット損失が設定水準を超えて増加した場合はその経路への分配比率を大きく下げ、他経路への分配比率を均等に増加させ、パケット往復時間が設定水準を超えた場合は、図16A,16B,16Cで説明したようにその経路へのトラヒックが集中して輻輳が起こる状態にあると推定し、その経路への分配比率を100%から所定値だけ下げ、その下げた分を他の経路へ例えば均等に分配する。以下、図15におけるステップS5の実施例を図17を参照して説明する。
ステップS51:現使用1経路のパケット損失率を予め決めた設定水準PLSと比較し、損失率がPLS以上であるか判定する。
ステップS52:パケット損失率がPLS以上の場合は、パケット損失率がPLS以下の経路への分配比率を所定値だけ増加させる。
ステップS53:パケット往復時間RTTが予め決めた設定水準RTTS以上か判定し、RTTS以上であれば、そのまま図15のステップS2に戻る。
ステップS54:パケット往復時間RTTが RTTS以上でなければ所定値δRTTSだけ設定水準RTTSを下げてステップS2に戻る。
ステップS55:ステップS51でパケット損失率が設定水準PLS以上でなければ、パケット往復時間RTTが設定水準RTTS以上であるか判定し、否であればステップS2に戻る。
ステップS56:パケット往復時間RTTがRTTS以上であれば、前述のように、その経路で輻輳が起きることが予測されるので現経路への分配比率を所定値だけ下げ、他の経路への分配比率を所定値だけ増加し、ステップS2に戻る。
【0042】
このように、第5実施例においては、複数経路からパケットを送信している場合と、1経路のみからパケットを送信している場合とで、異なる経路品質情報に基づいて分配比率を決めることができる。
図17の処理手順において、パケット損失率の代わりにジッタを使用してもよい。例えば、ジッタが大きい経路では、一時的な輻輳が起きている可能性があるため、この経路へのデータの分配比率を所定値だけ下げ、代わりにジッタが小さい経路への分配比率を所定値だけ上げるように制御する。
【0043】
第6実施例
上述した各実施例において、経路の品質情報の1つとしてパケット往復時間RTTを使用することとができることを述べたが、往復時間RTTは送信先ノードから送信元ノードへの方向の経路の状態の影響を受けるため、送信先ノードの受信状態を示す指標として的確でない。むしろ、経路の品質情報をより正確に表すものとして、パケットの片道所要時間が有効である。
第6実施例は、経路の品質情報としてこの片道所要時間を使用する。しかしながら、片道所要時間を正確に測定するには送信元ノードと送信先ノードのクロックが互いに同期している必要がある。この実施例では、GPS(geographical positioning system)を利用して両ノード間のクロックを同期させ、片道所要時間を測定する場合を示す。
【0044】
図18は第6実施例を適用するネットワーク構成を、図1の構成と同様なものに同じ参照番号をつけて示す。このネットワーク構成で特徴的なことは、各ノード11、12にGPS受信機11G、12Gが設けられ、衛星90からのGPS信号を受信してそれぞれのノードのクロック(コンピュータ内のクロック)が同じGPS信号の示す時刻に同期している。
この実施例で使用する片道所要時間TTは、例えば送信元ノードがそれぞれの経路に送出するRTPパケットのRTPヘッダ(図3)に書き込んだタイムスタンプ(TS)62と、送信先ノードがそれぞれの経路からそれらのRTPパケットを受信した時刻Rnとから、TT=Rn−TSにより算出し、RTCP−RRの適当なフィールドに書き込んで送信元ノードに送る。送信元ノードは受信者レポートRTCP−RRから取得したそれぞれの経路での片道所要時間TTを前述した各実施例において品質情報として使用する。例えば、それら複数経路の片道所要時間TTの逆数の比を分配比率としてそれぞれの経路に設定することができる。
【0045】
片道所要時間の場合のみならず、ジッタやパケット損失率の場合も、このようにそれぞれの経路の品質情報に対応してそれぞれの経路の分配比率を設定することにより、送信元ノードから送信先ノードへの伝送速度を最大にすることができる。
送信先ノードにおける片道所要時間の測定は、それぞれの経路から受信した送信者レポートRTCP−SRの受信時刻Ciを測定して使用してもよい。その場合、各経路からのRTCP−SRの受信時刻Ciと、そのRTCP−SR中のタイムスタンプから片道所要時間TTを求めてもよい。
【0046】
送信先ノードの処理手順
図19A,19B及び19Cは、上述した各実施例において、送信先ノードが行う処理手順を示す。
図19Aの処理は各経路の品質情報を取得する処理を示す。
ステップS11:それぞれの経路からのRTPパケットを受信する。
ステップS12:各RTPパケットの受信時刻Rnを取得する。
ステップS13:受信RTPパケットからその送信時刻を示すタイムスタンプTS(図3)を取得する。
ステップS14:各経路についてパケット間隔ジッタJを前述した式(1), (2)から算出する。
ステップS15:受信RTPパケットのシーケンス番号SNに基づいてパケット損失を検出し、各経路についてのパケット損失率を算出する。
ステップS16:受信RTPパケットを受信バッファに格納する。
【0047】
受信RTPパケットからペイロード部のデータがアプリケーションにより取り出され、使用される。
図19Bは送信者レポートRTCP−SRの受信処理を示す。
ステップS21:送信者レポートRTCP−SR(図5)を受信する。
ステップS22:RTCP−SRの受信時刻Ciを保存する。
ステップS23:RTCP−SRからNTPタイムスタンプを取り出し、保存する。
図19Cは受信者レポートの送信処理を示す。
ステップS31:間隔δTごとのタイミングを与えるタイマーを起動する。
ステップS32:受信者レポートRTCP−RRのパケットを作成する。
ステップS33:現時刻Tiを取得する。
ステップS34:最新の送信者レポートRTCP−SRを受信した時刻Ci(図19BのステップS22,S23)と現時刻Tiから経過時間DLSR=Ti−Ciを算出する。
ステップS35:図19AのステップS14、S15で得たジッタJ、パケット損失率及び経過時間DLSR、RTCP−SR中のNTPタイムスタンプをRTCP−RRに挿入する。
ステップS36:受信者レポートRTCP−RRを送信する。
【0048】
上記各実施例に係るデータ送信制御方法は、これをコンピュータ制御によって行わせることが好ましく、本発明の権利範囲には、このようなデータ送信制御方法をコンピュータ制御により実行するためのプログラムをも含むものであることは前述の通りである。
上述の各実施例の説明から明らかなように、この発明のデータ送信制御方法を実行する送信元ノード11を構成するデータ送信装置は、送信先ノードから経路の品質情報を取得する品質情報取得手段と、その品質情報に基づいて複数の経路へのデータの分配比率を適応的に変更する分配制御手段を有している。図20はこのデータ送信装置の構成例を示す。この基本構成は一般のコンピュータと同様であり、CPU(中央演算処理装置)11Aと、RAM(ランダムアクセスメモリ)11Bと、大容量記憶装置としてのハードディスク11Cと、ディスプレイ11Eとを有しており、更に、エッジルータ21に接続されたネットワークインタフェースカード11Dを有している。送信元ノード11が実行する前述したこの発明のデータ送信制御の処理手順を記述したプログラムは例えばハードディスク11Cに格納されており、通信の実行時にプログラムをRAM11Bに読み出してCPU11Aがそのプログラムを実行する。したがって、この発明の送信装置11における品質情報取得手段及び分配制御手段は、プログラムを実行することによりコンピュータにより実施される。
【0049】
上記各実施例はいずれも本発明の一例を示すものであり、本発明はこれらに限定されるべきものではなく、本発明の要旨を変更しない範囲内において、適宜の変更,改良を行ってもよいことはいうまでもない。
【0050】
【発明の効果】
以上、詳細に説明したように、本発明によれば、ベストエフォート型サービスのインターネット網において、データの送受信を行う二地点間で複数の経路を設定し、その経路へのデータの分配比率を刻々と変化する経路状態に対応して迅速に変更することで、ネットワークの障害や輻輳によるデータの損失や遅延を避け、スループットの向上を図ることが可能になるという顕著な効果を奏するものである。
【図面の簡単な説明】
【図1】この発明が適用されるネットワークの構成を示す図。
【図2】図1における送信元ノードと送信先ノード間の接続を示す図。
【図3】RTPヘッダの構成を示す図。
【図4】受信者レポートRTCP−RRのパケット構成を示す図。
【図5】送信者レポートRTCP−SRのパケット構成を示す図。
【図6】IPパケットの構成を示す図。
【図7】UDPプロトコルの構成を示す図。
【図8】AはRTPパケットの構成を示す図、BはRTCPパケットの構成を示す図。
【図9】送信元ノードと送信先ノード間の通信シーケンスを示す図。
【図10】この発明の送信制御方法の原理的な処理手順を示す図。
【図11】この発明の第1実施例による送信元ノードの処理手順を示す図。
【図12】パケット間隔と測定されるジッタの関係を示す図。
【図13】この発明の第3実施例による送信元ノードの処理手順を示す図。
【図14】この発明の第4実施例による送信元の処理手順を示す図。
【図15】この発明の第5実施例による送信元の処理手順を示す図。
【図16】Aは輻輳の発生とジッタの変化を示すグラフ、Bは輻輳の発生とパケット往復時間の変化を示すグラフ、Cは輻輳の発生とパケット損失の変化を示すグラフ。
【図17】図15におけるステップS5の実施例を示す図。
【図18】この発明の第6実施例が適用されるネットワークの構成を示す図。
【図19】Aはこの発明の各実施例において送信先ノードが行う経路品質情報を取得する処理手順を示す図、Bは送信先ノードが送信者レポートから情報を取得する処理を示す図、Cは送信先ノードが受信者レポートを作成する処理を示す図。
【図20】この発明の実施する送信元ノードを構成するデータ送信装置の構成を示すブロック図。
Claims (22)
- ネットワーク上の送信元ノードから送信先ノードへデータを送信するための送信元ノードのデータ送信制御方法であり、以下のステップを含む:(a) 上記送信元ノードと上記送信先ノード間の複数の経路の品質情報を上記送信先ノードから取得し、
(b) 上記複数の経路の上記品質情報に基づいて上記複数の経路へのデータの分配比率を適応的に変更する。 - 請求項1に記載のデータ送信制御方法において、上記ステップ(b) は、上記データをパケットとし、シーケンス番号をつけて上記分配比率でそれぞれの経路に送出するステップを含む。
- 請求項2に記載のデータ送信制御方法において、上記ステップ(a) は、上記複数の経路についてそれぞれ上記品質情報を取得するステップを含み、上記ステップ(b) は、上記品質情報に基づいて上記分配比率を変更し、分配比率に従ってパケットを送出するステップを含む。
- 請求項3に記載のデータ送信制御方法において、上記ステップ(b) は、品質のよい経路に対する分配比率を上げ、品質の悪い経路に対する分配比率を下げるステップを含む。
- 請求項4に記載のデータ送信制御方法において、上記ステップ(a) は上記品質情報として上記送信先ノードから各経路のパケット間隔ジッタを取得するステップを含み、上記ステップ(b) は、上記複数の経路のパケット間隔ジッタを比較し、ジッタの小さい経路の分配比率を上げ、ジッタの大きい経路の分配比率を下げるステップを含む。
- 請求項3に記載のデータ送信制御方法において、上記ステップ(b) は上記各経路の品質情報に基づいて各経路への分配比率を変更するステップを含む。
- 請求項6に記載のデータ送信制御方法において、上記ステップ(a) は上記経路の品質情報として各経路の片道所要時間を上記送信先ノードから取得するステップを含み、上記ステップ(b) は、上記片道所要時間の逆数に対応して分配比率を決めるステップを含む。
- 請求項2に記載のデータ通信制御方法において、上記ステップ(a) は上記複数の経路の全体としての品質を得るステップを含み、上記ステップ(b) は上記全体としての品質に基づいて上記分配比率を変更するステップを含む。
- 請求項8に記載のデータ通信制御方法において、上記ステップ(b) は、前回の分配比率の変更により状態が改善された場合は、更にその変更方向に分配比率を更に変更し、前回より悪化した場合は、前回と逆方向に分配比率を変更するステップを含む。
- 請求項2に記載のデータ通信制御方法において、上記ステップ(b) は、通常、予め決めた1つのデフォルト経路へのみパケットを送出するステップと、上記デフォルト経路の品質が許容レベルを超えて悪化した場合に、他の経路への分配比率を増加させて複数経路にパケットを送出するステップと、上記デフォルト経路の品質が回復した時点で上記デフォルト経路へのみパケットを送出するステップとを含む。
- 請求項2に記載のデータ通信制御方法において、上記ステップ(b) は、通常任意に選択した1つの経路へのみパケットを送出するステップと、上記1つの経路の品質が許容レベルを超えて悪化した場合に、他の経路への分配比率を増加させて複数経路にパケットを送出するステップと、任意の経路の品質が許容レベル以下に回復した時点で上記任意の経路へのみパケットを送出するステップ、とを含む。
- 請求項11に記載のデータ送信制御方法において、上記ステップ(a) は上記品質情報としてパケット往復時間と、上記送信先から各経路のパケット損失率とを取得するステップを含み、上記ステップ(b) は、各経路のパケット損失率を予め決めた水準より大きいか否か判定し、大きければ上記経路品質情報に応じて予め決めた手法により各経路への分配比率を変更するステップを含む。
- 請求項11に記載のデータ送信制御方法において、上記ステップ(a) は上記品質情報としてパケット往復時間と、上記送信先から各経路のジッタとを取得するステップを含み、上記ステップ(b) は、各経路のジッタを予め決めた水準より大きいか否か判定し、大きければ上記経路品質情報に応じて予め決めた手法により各経路への分配比率を変更するステップを含む。
- 請求項1に記載のデータ通信制御方法において、上記ステップ(b) は1経路のみによる通信中か複数経路による通信中かを判定し、その判定結果に応じて適応的に分配比率の決定方法を変更するステップを含む。
- 請求項2に記載のデータ通信制御方法において、上記ステップ(a) は各経路へ連続して2つ以上のパケットをほぼ同じパケット間隔で送出するステップを含む。
- 請求項1乃至15のいずれかに記載のデータ通信制御方法において、上記データは動画像データ、音声データなどの実時間データである。
- 請求項1乃至15のいずれかに記載のデータ送信制御方法をコンピュータに実行させるためのプログラム。
- ネットワーク上の送信元ノードから送信先ノードへ通信経路を複数設定し、データを分配送信する送信装置であって、
上記送信元ノードは上記経路の品質情報を上記送信先ノードから取得する手段と、上記品質情報取得手段により取得した上記経路の品質情報に基づいて、上記複数の経路へのデータの分配比率を適応的に変更する分配制御手段とを含む。 - 請求項18に記載の送信装置において、上記分配制御手段による上記各経路へのデータの分配は、上記品質情報取得手段による上記各経路の品質情報に基づいて、品質の良い経路へのデータの分配比率を上げ、品質の悪い経路へのデータの分配比率を下げるものであ。
- 請求項18に記載の送信装置において、上記品質情報取得手段は上記品質情報として上記各経路での往復伝送時間あるいは上記送信元ノードから上記送信先ノードへの片方向伝送時間を取得し、上記分配制御手段は上記各経路の伝送時間の逆数の比を分配比率として分配を行うものである。
- 請求項18に記載の送信装置において、上記経路の品質情報は、上記複数の経路全体としての品質を表す情報であり、上記分配制御手段は、上記経路全体としての品質情報に基づいて、上記各経路へのデータの分配比率を適応的に変更するものである。
- 請求項21に記載の送信装置において、上記分配制御手段による上記各経路へのデータの分配は、上記品質情報取得手段による前回の上記複数の経路に対する分配比率の変更により今回取得された品質情報が複数経路全体としての品質の向上を示していた場合には、前回分配比率を上げた経路に対しては更に上げ、前回分配比率を下げた経路に対しては更に下げ、上記今回取得した品質情報が複数経路全体としての品質劣化を示していた場合には、分配比率を上げた経路に対しては下げ、分配比率を下げた経路に対しては上げる。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002298469A JP2004007361A (ja) | 2001-10-11 | 2002-10-11 | データ送信制御方法及びこの方法のプログラム並びにこれを用いるデータ送信装置 |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001313490 | 2001-10-11 | ||
JP2002120058 | 2002-04-23 | ||
JP2002298469A JP2004007361A (ja) | 2001-10-11 | 2002-10-11 | データ送信制御方法及びこの方法のプログラム並びにこれを用いるデータ送信装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2004007361A true JP2004007361A (ja) | 2004-01-08 |
Family
ID=30449040
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002298469A Pending JP2004007361A (ja) | 2001-10-11 | 2002-10-11 | データ送信制御方法及びこの方法のプログラム並びにこれを用いるデータ送信装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2004007361A (ja) |
Cited By (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2005221657A (ja) * | 2004-02-04 | 2005-08-18 | Yamaha Corp | 通信端末 |
JP2006005942A (ja) * | 2004-06-18 | 2006-01-05 | Avaya Technology Corp | インターネット・プロトコル電話の高速な障害検出および復旧 |
JP2006352357A (ja) * | 2005-06-14 | 2006-12-28 | Fujitsu Ltd | 通信制御装置および通信制御方法 |
JP2007019786A (ja) * | 2005-07-07 | 2007-01-25 | Yokogawa Electric Corp | ネットワーク品質評価装置 |
JP2007116430A (ja) * | 2005-10-20 | 2007-05-10 | Oki Electric Ind Co Ltd | 交換装置 |
JP2008509602A (ja) * | 2004-08-03 | 2008-03-27 | ヒューレット−パッカード デベロップメント カンパニー エル.ピー. | 複数のパスを使用してデータネットワーク上でデータを転送するためのシステム及び方法 |
JP2008524934A (ja) * | 2004-12-17 | 2008-07-10 | テルケミー、インコーポレイテッド | リアルタイム・マルチメディア・セッションの品質を改善するためのシステム及び方法 |
JP2008211567A (ja) * | 2007-02-27 | 2008-09-11 | Nec Corp | トラフィック経路変更方法及びシステム |
JP2009522883A (ja) * | 2006-04-21 | 2009-06-11 | ▲ホア▼▲ウェイ▼技術有限公司 | Hsdpaにおけるライセンスの制御方法及びhsdpaにおけるライセンス制御を実現する基地局 |
JP2012009960A (ja) * | 2010-06-22 | 2012-01-12 | Anritsu Corp | 遅延測定システム及び遅延測定方法 |
US8149704B2 (en) | 2004-08-23 | 2012-04-03 | Nec Corporation | Communication apparatus and data communication method |
JP2012134582A (ja) * | 2010-12-20 | 2012-07-12 | Nec Corp | パケット中継装置 |
JP2014183356A (ja) * | 2013-03-18 | 2014-09-29 | Fujitsu Ltd | 通信制御方法 |
JP2016197866A (ja) * | 2011-06-08 | 2016-11-24 | クゥアルコム・インコーポレイテッドQualcomm Incorporated | マルチパスレート適応 |
JP2017530584A (ja) * | 2014-07-29 | 2017-10-12 | クゥアルコム・インコーポレイテッドQualcomm Incorporated | ビデオ電話における遅延の低減 |
JP2018098470A (ja) * | 2016-12-16 | 2018-06-21 | 大日本印刷株式会社 | パターン形成方法及びレプリカモールドの製造方法 |
JP2018129707A (ja) * | 2017-02-09 | 2018-08-16 | オムロン株式会社 | 通信システム、通信装置および通信方法 |
JP2021022838A (ja) * | 2019-07-28 | 2021-02-18 | 株式会社フェアーウェイ | データ伝送装置およびプログラム |
-
2002
- 2002-10-11 JP JP2002298469A patent/JP2004007361A/ja active Pending
Cited By (29)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2005221657A (ja) * | 2004-02-04 | 2005-08-18 | Yamaha Corp | 通信端末 |
JP2006005942A (ja) * | 2004-06-18 | 2006-01-05 | Avaya Technology Corp | インターネット・プロトコル電話の高速な障害検出および復旧 |
US7782787B2 (en) | 2004-06-18 | 2010-08-24 | Avaya Inc. | Rapid fault detection and recovery for internet protocol telephony |
JP4625377B2 (ja) * | 2004-06-18 | 2011-02-02 | アバイア インコーポレーテッド | インターネット・プロトコル電話の高速な障害検出および復旧 |
JP2008509602A (ja) * | 2004-08-03 | 2008-03-27 | ヒューレット−パッカード デベロップメント カンパニー エル.ピー. | 複数のパスを使用してデータネットワーク上でデータを転送するためのシステム及び方法 |
US7965626B2 (en) | 2004-08-03 | 2011-06-21 | Hewlett-Packard Development Company, L.P. | System and method for transferring data on a data network using multiple paths |
US8149704B2 (en) | 2004-08-23 | 2012-04-03 | Nec Corporation | Communication apparatus and data communication method |
JP4704443B2 (ja) * | 2004-12-17 | 2011-06-15 | テルケミー、インコーポレイテッド | リアルタイム・マルチメディア・セッションの品質を改善するためのシステム及び方法 |
JP2008524934A (ja) * | 2004-12-17 | 2008-07-10 | テルケミー、インコーポレイテッド | リアルタイム・マルチメディア・セッションの品質を改善するためのシステム及び方法 |
JP2006352357A (ja) * | 2005-06-14 | 2006-12-28 | Fujitsu Ltd | 通信制御装置および通信制御方法 |
JP4699099B2 (ja) * | 2005-06-14 | 2011-06-08 | 富士通株式会社 | 通信制御装置および通信制御方法 |
JP2007019786A (ja) * | 2005-07-07 | 2007-01-25 | Yokogawa Electric Corp | ネットワーク品質評価装置 |
JP2007116430A (ja) * | 2005-10-20 | 2007-05-10 | Oki Electric Ind Co Ltd | 交換装置 |
JP2009522883A (ja) * | 2006-04-21 | 2009-06-11 | ▲ホア▼▲ウェイ▼技術有限公司 | Hsdpaにおけるライセンスの制御方法及びhsdpaにおけるライセンス制御を実現する基地局 |
JP4938026B2 (ja) * | 2006-04-21 | 2012-05-23 | ▲ホア▼▲ウェイ▼技術有限公司 | Hsdpaにおけるライセンスの制御方法及びhsdpaにおけるライセンス制御を実現する基地局 |
JP2008211567A (ja) * | 2007-02-27 | 2008-09-11 | Nec Corp | トラフィック経路変更方法及びシステム |
JP2012009960A (ja) * | 2010-06-22 | 2012-01-12 | Anritsu Corp | 遅延測定システム及び遅延測定方法 |
JP2012134582A (ja) * | 2010-12-20 | 2012-07-12 | Nec Corp | パケット中継装置 |
JP2016197866A (ja) * | 2011-06-08 | 2016-11-24 | クゥアルコム・インコーポレイテッドQualcomm Incorporated | マルチパスレート適応 |
JP2014183356A (ja) * | 2013-03-18 | 2014-09-29 | Fujitsu Ltd | 通信制御方法 |
JP2017530584A (ja) * | 2014-07-29 | 2017-10-12 | クゥアルコム・インコーポレイテッドQualcomm Incorporated | ビデオ電話における遅延の低減 |
JP2018139407A (ja) * | 2014-07-29 | 2018-09-06 | クゥアルコム・インコーポレイテッドQualcomm Incorporated | ビデオ電話における遅延の低減 |
JP2018098470A (ja) * | 2016-12-16 | 2018-06-21 | 大日本印刷株式会社 | パターン形成方法及びレプリカモールドの製造方法 |
JP2018129707A (ja) * | 2017-02-09 | 2018-08-16 | オムロン株式会社 | 通信システム、通信装置および通信方法 |
WO2018146892A1 (ja) * | 2017-02-09 | 2018-08-16 | オムロン株式会社 | 通信システム、通信装置および通信方法 |
KR20190096428A (ko) * | 2017-02-09 | 2019-08-19 | 오므론 가부시키가이샤 | 통신 시스템, 통신 장치 및 통신 방법 |
KR102281617B1 (ko) * | 2017-02-09 | 2021-07-26 | 오므론 가부시키가이샤 | 통신 시스템, 통신 장치 및 통신 방법 |
JP7073624B2 (ja) | 2017-02-09 | 2022-05-24 | オムロン株式会社 | 通信システム、通信装置および通信方法 |
JP2021022838A (ja) * | 2019-07-28 | 2021-02-18 | 株式会社フェアーウェイ | データ伝送装置およびプログラム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7327676B2 (en) | Data transmission control method, program therefor and data transmission unit using the same | |
US8171123B2 (en) | Network bandwidth detection and distribution | |
JP2004007361A (ja) | データ送信制御方法及びこの方法のプログラム並びにこれを用いるデータ送信装置 | |
Sisalem et al. | LDA+ TCP-friendly adaptation: A measurement and comparison study | |
US7756032B2 (en) | Method and apparatus for communicating data within measurement traffic | |
EP1122931B1 (en) | Real-time media content synchronization and transmission in packet network apparatus and method | |
US7702006B2 (en) | Adjustment of transmission data rate based on data errors and/or latency | |
EP1382219B1 (en) | Method and device for robust real-time estimation of bottleneck bandwidth | |
JP3590044B2 (ja) | Rtpおよびrtcpプロトコルを用いる動的なデータパケット送信方法 | |
EP1507369A1 (en) | Protocol, information processing system and method, information processing device and method, recording medium, and program | |
JP4772053B2 (ja) | 送信装置および送信レート制御方法 | |
JP4687538B2 (ja) | 受信装置、送信装置およびその通信方法 | |
Papageorge et al. | Passive aggressive measurement with MGRP | |
JPWO2007026604A1 (ja) | マルチキャストノード装置とマルチキャスト転送方法ならびにプログラム | |
JP5820238B2 (ja) | データ送信装置およびデータ受信装置 | |
Papadimitriou et al. | A rate control scheme for adaptive video streaming over the internet | |
Ahlgren et al. | ICN congestion control for wireless links | |
WO2002033893A2 (en) | Method and apparatus for communicating data within measurement traffic | |
Hsiao et al. | Streaming video over TCP with receiver-based delay control | |
Arthur et al. | The effects of packet reordering in a wireless multimedia environment | |
CN109716683B (zh) | 实时内容分发系统中的时间同步 | |
Loula | Congestion Control Supported Dual-Mode Video Transfer | |
Kjevik | Active Queue Management for window based applications in Named Data Networking | |
Nguyen | Path diversity media streaming over best effort packet switched networks | |
Vihervaara et al. | Congestion Control Supported Dual-Mode Video Transfer |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20041129 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041207 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050204 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20050621 |