JP4653011B2 - 中継装置及び中継方法 - Google Patents

Description

本発明は、映像や音声などのマルチメディアデータを中継して伝送する中継装置及び中継方法に関し、特に、複数のマルチメディアデータを中継し、同期させて伝送する中継装置及び中継方法に関する。

近年、ネットワークの急速な発展に伴って、テレビ会議やネットワークゲーム、遠隔地への講義の配信などにおいて、映像や音声、発表資料画面などの複数のマルチメディアデータを、ネットワークを介して複数の受信端末に対して同時に伝送するマルチキャスト通信が行われている。

マルチキャスト通信において、各受信端末は、受信する各マルチメディアデータ間の同期をとる必要がある。例えば、送信端末が、音声とその話者の画像とを別々のストリームとしてネットワークを介して伝送する。受信端末は、この別々のストリームのそれぞれを受信して再生する場合、音声とその話者の画像とがずれないようにこの２つのストリームの再生タイミングを合わせて、同時にスピーカとディスプレイとに出力する必要がある。

一般に、複数のストリームの同期処理を実現する技術として、送信端末が、ストリームを構成するパケットにタイムスタンプを刻印し、受信端末が、パケットに刻印されたタイムスタンプを用いて、複数のストリームに対応するマルチメディアデータの再生タイミングを揃える処理が知られている。

パケットにタイムスタンプを刻印して送信する方法として、ＲＦＣ１８８９で規定されるＲＴＰ（real-time transport protocol）がある。ＲＴＰでは、ＲＴＰヘッダの３２ビットのタイムスタンプ欄に、送信端末のアプリケーションがパケットの送信時刻（以下「タイムスタンプ」という）を刻印する。同時刻に再生すべき複数のストリームがある場合には、それぞれのストリームを構成するパケットに対して別々にタイムスタンプが刻印される。このとき、ＲＴＰヘッダの３２ビットの空間に、どのような時刻粒度でタイムスタンプを刻印するかは、送信端末のアプリケーションにより決定される。例えば、１秒間に３０枚の画像を再生する画像ストリームのように高速で多量のパケットを送信する場合には、１０００マイクロ秒の時刻粒度で、音声のように１０ｍｓ毎にパケットを送信する場合には、１０マイクロ秒の時刻粒度でタイムスタンプを刻印する。このように、異なる時刻粒度でそれぞれタイムスタンプを刻印するということは、送信端末のアプリケーション毎に決定することができる。

このことは、送受信端末の送受信アプリケーションは、ＲＴＰヘッダへのタイムスタンプの刻印の時刻粒度を知っているが、ルータやスイッチなどのネットワークの中間ノードは、パケットを解析してもこのタイムスタンプの刻印の時刻粒度を知ることができないということを意味する。

複数のマルチメディアデータ（ストリーム）を同期させるために用いることができるプロトコルは、ＲＴＰに限られない。例えば、アプリケーションの設計者が複数のマルチメディアデータを多重伝送する方式を決定し、決定された方式に従って、送信端末が複数のストリームを伝送し、受信端末が、先に受信したストリームのパケットを一時蓄積して後に受信したストリームのパケットと合わせて再生することにより、同期処理を実現することもできる。

このような同期処理を実現する技術として、例えば、特許文献１に記載されているものがある。

特許文献１には、受信端末で、多重メディアストリーム記述方式と表現される記述方式に従って伝送される複数のメディアストリームを適宜バッファリングし、再生することにより、同期処理を実現する方式が開示されている。

図１４は、特許文献１に記載されている同期処理を説明するための図である。

図１４において、受信機１０は、複数の多重記述ビットストリームを受信して、ビットストリーム毎に区別して複数のバッファ１２やバッファ１４に格納する。多重記述復号器１６は、多重メディアストリーム記述方式に従って、バッファ１２やバッファ１４に格納されたストリームを取り出して再生する。

一方、複数のストリームのバッファリング処理をルータのような中継ノードが行うことにより同期処理を実現する技術として、例えば、特許文献２に記載されているものがある。

特許文献２には、中継ノードで、各送信端末から送信された複数のストリームを一旦蓄積し、蓄積された複数のストリームを受信端末へ転送する間隔を制御することにより、同期処理を実現する技術が開示されている。

図１５は、特許文献２に記載されている同期処理を説明するための図である。

図１５において、送信端末２０ａ，２０ｂ，２０ｃは、それぞれ、音声や動画などのストリームを別々に送信する。このとき、各送信端末は、ストリームを構成するパケットのＲＴＰヘッダのタイムスタンプ欄に、パケットの送信時刻を刻印する。同期ノード３０は、各送信端末から複数のストリームを受信すると、タイムスタンプ欄に刻印された情報を用いて複数のストリームのパケットの送出順序を決定し、その順序に従って、複数のストリームを受信端末４０ａ，４０ｂ，４０ｃへ転送する。同期ノード３０は、複数のストリームの転送時に、それぞれのストリームのパケットの送信間隔を再現するため、各送信端末からのパケットの送信時刻を推定して得られたパケットの送信間隔でストリームを転送するようにパケットの転送間隔を制御する。

このように、送信端末と受信端末との間の中継ノードで同期処理を行う場合、送信端末と受信端末との間で、帯域を推定し、適切な流量のストリームを送信する流量制御が行われることがある。帯域を推定する方法としては、例えば、ＲＦＣ３４４８で規定されるＴＦＲＣ（tcp friendly rate control）がある（非特許文献１）。

ＴＦＲＣとは、送信端末と受信端末との間のパケットの往復時間（ＲＴＴ：round trip time）を計測し、パケットの損失率を用いて算出される損失イベント率（ｐ）を計算し、ＲＴＴとｐとを用いて、送受信端末間で利用可能な帯域を推定する方式である。ＴＦＲＣにおいて、ＲＴＴは、以下のようにして計測される。まず、送信端末が、タイムスタンプを刻印したパケットを受信端末に送信し、パケットを受信した受信端末が、即座にそのタイムスタンプ欄を応答パケットに転記して送信端末に返送する。そして、送信端末は、受信端末からの応答パケットを受信した時刻と応答パケット中に転記してある送信時刻との差を計算してＲＴＴとする。ＲＴＴは、送信端末と受信端末との間の同一経路でＴＣＰ接続をした場合の往復時間と同じ時間が計測されることが望ましい。

また、ＴＦＲＣでは、送受信端末間で利用可能な帯域推定値は、次の式（１）で与えられる。式（１）より、ＴＦＲＣでは、計測されたＲＴＴの値が大きくなると、帯域推定値は、それに比例して小さくなる。

ここで、Ｒはラウンドトリップタイム（秒）、ｐは損失率、ｓはパケットサイズ（ｂｙｔｅ）、ｂはＴＣＰの肯定応答単位（例えば１）、Ｔ＿ＲＴＯはＴＣＰのタイムアウト値（４^＊Ｒ）である。

なお、送信端末と受信端末との間で行われる帯域推定方法としては、ＴＦＲＣ以外の方法も採用されうる。ＴＦＲＣ以外の帯域推定方法においても、ＲＴＴを用いて帯域の推定を行うこと、及びＲＴＴの計測値が高くなるにつれて帯域推定値が低くなることは、ＴＦＲＣと共通する。
特表２００４−５３８０９０号公報 特開２００４−３２０２５１号公報 M. Handley et al., "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448

しかしながら、特許文献１記載の技術にあっては、受信端末で、受信した一部のストリームを、同期処理すべき別のストリームを受信するまで蓄積する記憶領域を確保する必要があるという問題がある。すなわち、本来同期すべき複数のストリームのいずれか１つが遅れて到着する場合、受信端末で、先に受信したストリームを蓄積するための多量の記憶領域が消費されるという問題がある。

この点、特許文献２記載の技術では、中継ノードによる同期処理を用いているため、受信端末でバッファリングする必要がなくなり、受信端末でのバッファリング用の記憶領域を削減することができるが、以下の問題がある。

特許文献２記載の技術にあっては、送信端末と受信端末との間で帯域の推定を行っている場合、パケットが中継ノードで蓄積されるため、帯域推定値が不必要に低く算出されてしまい、伝送性能が悪化するという問題がある。すなわち、帯域の推定において、送信端末と受信端末との間のパケットの往復時間（ＲＴＴ）を計測する場合、パケットが中継ノードで一時蓄積された分だけ、ＲＴＴが多く算出される。このとき、ＲＴＴは、送信端末と受信端末との間の同一経路でＴＣＰ接続をした場合の往復時間と同じ時間とはならない。上記のように、帯域推定値は、計測されたＲＴＴの値が大きくなるに従って小さくなるため、ＲＴＴの計測値の増加により、推定帯域値が小さく算出されて伝送性能の悪化につながる。

特許文献１及び特許文献２の上記問題点は、特に、マルチキャスト通信において、同期させるべき複数のストリームが複数の送信端末から送信される場合や階層符号化を利用したマルチキャスト通信において、中継装置がパケットの分割や複製を行って伝送する場合に顕著に現れる。

本発明は、かかる点に鑑みてなされたものであり、送信端末からの関連する複数のストリームが異なる経路で受信端末に伝送される場合であっても、受信端末の無駄な記憶領域を省略し、かつ、不必要に低い帯域推定を行うことなく受信端末で複数のストリームから高品質なデータを再生することができる中継装置及び中継方法を提供することを目的とする。

本発明の態様の一つに係る中継装置は、複数のデータフローの中から１つのセッションにおいて同期されるべき特定のデータフロー群を識別する識別部と、前記特定のデータフロー群の一部のデータフローの送信を遅延させる遅延部と、前記遅延させたデータフローに刻印されたタイムスタンプを、前記遅延部により遅延させた時間分だけ補正する補正部と、前記特定のデータフロー群を送信する送信部と、を有する構成を採る。

本発明によれば、送信端末からの関連する複数のストリームが異なる経路で受信端末に伝送される場合であっても、複数のストリームを同期させて受信端末に伝送することが可能となり、受信端末におけるバッファのための記憶領域の消費を節約することができる。また、送信端末と受信端末との間で階層符号化を用いたストリームの伝送が行われ、その伝送で帯域推定が行われている場合であっても、不必要に低い帯域を推定することを防止することができ、受信端末で複数のストリームから高品質なデータを再生することができる。

以下、本発明の実施の形態について、図面を参照して詳細に説明する。

（実施の形態１）
図１は、本発明の実施の形態１に係る中継装置を含む通信システムの全体構成を示すブロック図である。

図１の通信システムは、送信端末１００、ルータ１１０，１２０、中継装置１３０、中継装置１４０、及び受信端末１５０を備えて構成される。

中継装置１４０は、識別部１４２、遅延部１４３、補正部１４６、及び送信部１４８を備える。

なお、中継装置１３０と中継装置１４０とは、同一の構成及び機能をとりうるが、ここでは、中継装置１３０は、単にルータ１１０からのストリームを中継してルータ１２０へ出力するものとして説明する。

送信端末１００は、映像や音声などのマルチメディアデータの複数のストリームを受信端末１５０に対して送信する。また、送信端末１００は、ストリームの送信時に、各ストリームを構成するパケットに対して、そのストリームの送信時刻であるタイムスタンプを刻印する。タイムスタンプの刻印の時刻粒度は、送信端末１００のアプリケーションにより、自由に変更することができる。また、送信端末１００から送信される複数のストリームは、同期して再生可能であれば、その内容や数は限定されず、例えば、階層符号化された複数のストリームであってもよい。

ルータ１１０，１２０は、ストリームのパケットに含まれる送信先アドレス情報に基づいてルーティングを行う。すなわち、ルータ１１０，１２０は、受信したストリームのパケットの分割・複製を行い、分割・複製されたストリームのパケットを、送信先アドレス情報に基づいて転送する。

識別部１４２は、送信端末１００からの複数のストリームのパケットの中に記述されているヘッダを解析することにより、これらのストリームのうち、互いに関連がある複数のストリームを識別する。ここで、「互いに関係がある複数のストリーム」とは、例えば、テレビ会議における音声と画像のように、１つのセッションにおいて同期されるべき複数のデータのストリームを意味する。したがって、識別部１４２は、受信したパケットが属する通信のセッション及びそのセッションに含まれる複数のフローを識別する。

具体的には、識別部１４２による識別は、以下のようにして行われる。まず、識別部１４２は、ヘッダに記述された各ストリームの宛先アドレスや送信元アドレス、宛先ポート番号、送信元ポート番号などを解析する。この解析により、通信のセッションを特定し、次いで、特定されたセッションに含まれる複数のフローを識別する。

遅延部１４３は、識別部１４２により識別された、１つのセッションに含まれる複数のフローに対して一時蓄積遅延処理を行う。すなわち、遅延部１４３は、１つのセッションに含まれる複数のフローのパケットを送信すべき時刻を特定し、特定された時刻まで、そのセッションに含まれる複数のフローを蓄積することによりパケットの送信を遅延させる。ここで、「パケットを送信すべき時刻」は、各パケットに刻印されたタイムスタンプと、各パケットの遅延部１４３への到着時刻とにより決定されるが、詳細については、後の動作説明で説明する。

また、遅延部１４３は、パケット単位で、タイムスタンプが刻印されたパケットそのものを示す情報と、パケットの遅延部１４３への到着時刻と、そのパケットが属するセッションのパケットを送信すべき時刻とを対応付けて格納する記憶部１４４を有している。また、遅延部１４３は、記憶部１４４に格納されるこれらの情報を更新するための最大フロー数管理表、及び差分時間管理表を保持している。これらの詳細については、後の動作説明で、図３乃至図５を用いて説明する。

また、遅延部１４３は、１つのセッションに含まれる複数のフローのパケット、これらのパケットの遅延部１４３への到着時刻、及びパケットを送信すべき時刻を含むデータを、遅延部１４３の内部に保持する送信待ちキュー１４５に格納する。

補正部１４６は、送信待ちキュー１４５に格納されたデータに基づいて、１つのセッションに含まれる各パケットについて、これらのパケットが遅延部１４３で一時蓄積された時間の分だけタイムスタンプを補正する。具体的には、補正部１４６は、各パケットについて、各パケットを送信すべき時刻から各パケットの到着時刻を減算して、各パケットが遅延部１４３に一時蓄積された時間を計算し、この一時蓄積された時間の分だけ、各パケット中のタイムスタンプ欄に記述された時刻を足し上げる。

送信部１４８は、遅延部１４３の送信待ちキュー１４５に格納されたすべての情報について走査し、受信端末１５０に対してパケットを送信する。このとき、送信部１４８は、上記パケットを送信すべき時刻を含む情報と現在時刻とを比較して、これらの時刻が一致した場合、またはパケットを送信すべき時刻が現在時刻よりも経過している場合に、受信端末１５０に対してパケットを送信する。

送信部１４８から送信された各パケットは、同期処理が実現されているのみならず、遅延部１４３で一時蓄積された時間の分だけタイムスタンプが補正されている。したがって、タイムスタンプを用いて送信端末１００と受信端末１５０との間の往復時間を計測する場合、遅延部１４３での一時蓄積時間を除いた時間が計測される。

受信端末１５０は、中継装置１４０の送信部１４８からの１つのセッションに含まれる複数のフローのパケットを受信して再生する。

以下、上述のように構成された通信システムの動作について詳細に説明する。

まず、送信端末１００から、映像や音声などのマルチメディアデータの複数のストリームが受信端末１５０に対して送信される。ここでは、送信端末１００から受信端末１５０に対して送信されるストリームは、音声情報である第１のストリームと動画情報である第２のストリームとの２つであり、これらのストリームは時刻Ｔ_０に同時に送信端末１００から送信されるものとして説明する。第１のストリーム及び第２のストリームのパケットには、これらのストリームが受信端末１５０で同期して再生可能なように、送信時刻であるタイムスタンプがそれぞれ刻印されている。

なお、ここでは、第１のストリームを音声情報、第２のストリームを動画情報としたが、本発明に適用できるストリームは、これに限定されない。例えば、階層符号化された複数のストリームであってもよいし、３以上の複数のストリームであってもよい。すなわち、同期して再生する複数のストリームであれば、その内容及び数は限定されない。

送信端末１００から送信された第１のストリーム及び第２のストリームは、それぞれ異なる経路で中継装置１４０に配送される。ここでは、その一例として、第１のストリームが、ルータ１１０→中継装置１３０→ルータ１２０→中継装置１４０の順で配送されて時刻Ｔ_１に中継装置１４０に到着するものとする。第２のストリームは、ルータ１１０→ルータ１２０→中継装置１４０の順で配送されて時刻Ｔ_２に中継装置１４０に到着するものとする。また、第２のストリームは、第１のストリームよりもＴ秒遅く中継端末１４０に到着するものとして説明する。すなわち、Ｔ_２−Ｔ_１＝Ｔが成り立つ。

なお、本発明は、Ｔが正の数である場合のみならず、Ｔが負の数、つまり、第１のストリームが第２のストリームよりもＴ秒遅く中継端末１４０に到着する場合にも適用可能である。すなわち、第１のストリームの到着時刻と第２のストリームの到着時刻とに差があるすべての場合について適用可能である。

識別部１４２は、第１のストリームに記述されているヘッダ、及び第１のストリームよりＴ秒遅く到着した第２のストリームに記述されているヘッダをそれぞれ解析して、第１のストリームと第２のストリームとが互いに関連があるストリームであることを識別する。すなわち、音声情報である第１のストリーム及び動画情報である第２のストリームは、１つのセッションにおいて同期されるべきストリームであるかどうかが識別される。

ここで、識別部１４２による識別動作について、図２を用いて説明する。図２は、ストリームのパケットに記述されているヘッダ構造の一例を示す図である。

ヘッダ１６０は、ネットワークヘッダ部１６１、トランスポートヘッダ部１６２、ＲＴＰヘッダ１６３、及びペイロード１６４からなる。ネットワークヘッダ部１６１は、宛先アドレス１６５及び送信元アドレス１６６を含む。トランスポートヘッダ部１６２は、宛先ポート番号１６７、送信元ポート番号１６８、データタイプ１６９、データクラス１７０、タイムスタンプ１７１、及び通番１７２を含む。

宛先アドレス１６５及び送信元アドレス１６６は、ＩＰｖ４やＩＰｖ６などのネットワーク上のアドレスである。ネットワークヘッダ部１６１には、ＩＰヘッダを抽象的に表したＩＰｖ４やＩＰｖ６で定義されているＩＰヘッダに含まれる項目が含まれてもよいし、ホップバイホップ（Hop-by-Hop）オプションヘッダや宛先オプションヘッダが含まれてもよい。また、ネットワークヘッダ部１６１には、例えば、文献（Y. Imai, M. shin and Y. Kim, “XCAST6 : eXplict Multicast on IPv6”, IEEE/IPSJ SAINT2003 Workshop 4, IPv6 and Applications, Orland, Jan. 2003.）で知られているＸＣＡＳＴのヘッダが含まれてもよい。

宛先ポート番号１６７及び送信元ポート番号１６８は、例えば、ＵＤＰ（User Define Protocol）などのトランスポートプロトコルの宛先ポート番号及び送信元ポート番号である。データタイプ１６９は、そのパケットがストリームを構成するデータの一部なのか、制御パケットなのかを区別するための領域である。データタイプ１６９は、トランスポートプロトコルによって、例えば、ビットフラグや数など、その実現方法が変わりうる。

データクラス１７０は、複数のストリームの複数のデータフローを多重化する領域である。データクラス１７０には、そのデータフローを含むセッションが有しているデータフローの数が記述されており、データクラス１７０に記述されている最大値が１つの通信のセッションの中のフローの数を表す。タイムスタンプ１７１は、パケットの送信端末１００からの送信時刻を記録する領域である。通番１７２は、データフローを構成するパケット毎に付与された番号である。

ＲＴＰヘッダ１６３は、アプリケーションがストリームを再生するために必要な情報を格納する。アプリケーションがストリームを再生するために必要な情報には、例えば、アプリケーションでの音声や動画などの再生タイミングを規定するためのタイムスタンプや通番といった情報が含まれる。ペイロード１６４は、音声や画像などの送信したいデータ本体である。

なお、ヘッダ１６０の構成順序は、図２の並びに限定されない。例えば、データクラス１７０が、ＲＴＰヘッダ１６３の後に出現してもよいし、宛先ポート番号１６７の位置と送信元ポート番号１６８の位置とが逆転してもよい。

まず、識別部１４２は、ヘッダ１６０に記述された宛先アドレス１６５、送信元アドレス１６６、宛先ポート番号１６７、及び送信元ポート番号１６８を解析して通信のセッションを特定する。次いで、識別部１４２は、データクラス１７０により、特定されたセッションに含まれる複数のフローを識別する。このようにして、識別部１４２では、パケットのヘッダ１６０を解析することにより、通信のセッション及びそのセッションに含まれる複数のフローが識別される。上記の例では、先に到着した第１のストリームのヘッダを解析することにより、第１のストリームのフローと第２のストリームのフローとの２つのフローからなるセッションが存在することが識別される。

なお、通信のセッションの識別には、上記の他にも以下のような方法を用いることができる。例えば、宛先アドレス１６５のみを用いてもよいし、宛先ポート番号１６７及び送信元ポート番号１６８のかわりに、ＲＴＰヘッダ１６３に含まれるＳＳＲＣ（送信元識別子）を用いてもよい。また、ＩＰｖ６ヘッダのトラフィッククラスやオプションヘッダ中の特定のチャネル識別子を用いてもよい。

また、セッションに含まれる複数のフローを特定するには、上記の他にも以下のような方法を用いることができる。例えば、ＩＰｖ６ヘッダのフローラベルを用いてもよいし、独自に定義したヘッダを追加して用いてもよい。また、送信元アドレス１６６、宛先ポート番号１６７及び送信元ポート番号１６８を用いることも可能であるし、ＶＬＡＮ番号やＭＰＬＳのラベルなど下位層の仮想回線を多重化するための識別子を用いることも可能である。

識別部１４２の機能を実現する方法としては、上記説明で用いられていないヘッダ１６０の領域またはその領域の一部を用いて、通信のセッションを識別し、そのセッションの中の複数のフローを識別しうる。換言すれば、識別部１４２の機能は、トランスポートプロトコル毎に様々な方式で実現することができる。

遅延部１４３では、識別部１４２により識別された、１つのセッションに含まれる複数のフローに対して一時蓄積遅延処理が行われる。すなわち、遅延部１４３では、１つのセッションに含まれる複数のフローのパケットを送信すべき時刻を特定し、特定された時刻まで、そのセッションに含まれる複数のフローを蓄積することによりパケットの送信を遅延させる。

具体的には、遅延部１４３では、まず、通信のセッション毎に各フローのパケットのタイムスタンプ１７１が検査され、各フローのパケットのタイムスタンプの値が記憶される。このとき、遅延部１４３は、データクラス１７０の値によって、１つのセッションにおいていくつのフローが存在するか知ることができる。また、遅延部１４３では、各フローのパケットのタイムスタンプの値と遅延部１４３が保持する時刻情報との差分から、どのフローのパケットが最も遅く到着し、どのフローのパケットが最も早く到着しているかが判定される。

そして、遅延部１４３では、１つのセッションに含まれる最も遅いフローが到着し、そのセッションに含まれる複数のフローを送信すべき時刻まで、既に遅延部１４３に到着している他のフローの各パケットが一時蓄積される。「フローを送信すべき時刻」は、最も遅いフローが到着したタイミング、または最も遅いフローが到着した後のタイミングで設定される。上記の例では、第１のストリームは、第２のストリームよりもＴ秒早く中継端末１４０に到着するので、第１のストリームのパケットは、遅延部１４３でＴ秒又はＴ秒以上一時蓄積されることになる。

ところで、１つのセッションに含まれる最も遅いフローが到着するまでに既に到着した各パケットは、すべてが同時に遅延部１４３に到着するわけではない。すなわち、１つのセッションに含まれる各パケットが遅延部１４３に一時蓄積される時間は、パケット毎に異なりうる。したがって、遅延部１４３では、１つのセッションに含まれるパケット単位で、タイムスタンプや遅延部１４３への到着時刻などの情報を管理して、これらを送信すべき時刻を特定する必要がある。以下、この動作について説明する。

上記のように、遅延部１４３の記憶部１４４は、パケット単位で、タイムスタンプが刻印されたパケットそのものを示す情報と、パケットの遅延部１４３への到着時刻と、そのパケットが属するセッションのパケットを送信すべき時刻とを対応付けて格納する。

図３は、記憶部１４４がパケット毎に管理するデータの構造を示す図である。

図３において、パケット１８０は、パケットそのものを示す情報であり、パケットが送信端末１００から送信された時刻を記述するタイムスタンプ欄が含まれている。到着時刻記憶領域１８２は、パケットの到着時刻を記録する領域である。送信時刻記憶領域１８４は、そのパケットのセッションに含まれる複数のフローのパケットを送信すべき時刻を記録する領域である。送信時刻記憶領域１８４への時刻の記録方法については、後に詳細に説明する。パケット１８０と、到着時刻記憶領域１８２と、送信時刻記憶領域１８４とは、リスト構造で結合されて管理されることで互いに関連付けて記録される。

遅延部１４３は、通信のセッションの各フローのパケットを受信すると、すべてのパケットについて、到着時刻記憶領域１８２にパケットの到着時刻を記録する。また、遅延部１４３は、パケットを受信する毎に、遅延部１４３が保持する最大フロー数管理表を更新する。

図４は、最大フロー数管理表のデータ構造を示す図である。

図４において、通信のセッション欄１９０には、識別部１４２によりセッション毎に割り当てられた識別子が記述される。最大フロー数欄１９２には、通信のセッション欄１９０に記述されたセッションに対応するフローの数が記述される。また、最大フロー数欄１９２に記述されるフロー数は、例えば、階層符号化マルチキャスト通信における流量制御が行われる場合には、更新されうる。

遅延部１４３では、パケットを受信する毎に、ヘッダ１６０中のデータクラス１７０の最大値を検査することにより、そのパケットを含むセッションに対応する最大フロー数欄１９２が更新される。データクラス１７０の最大値と最大フロー数欄１９２に記述された数とが同一になることは、セッションに含まれるすべてのパケットが受信されたことを意味する。すなわち、遅延部１４３の更新により、送信時刻記憶領域１８４に記録される時刻の更新が完了し、そのセッションに含まれるすべてのパケットを送信すべき時刻を確定することができる。以下、パケットを送信すべき時刻の確定処理について説明する。

遅延部１４３では、受信したパケット１８０の中のタイムスタンプ欄に記述されている時刻と到着時刻記憶領域１８２に記述されているパケットの到着時刻との差分時間が計算され、遅延部１４３が保持する差分時間管理表が更新される。

図５は、差分時間管理表のデータ構造を示す図である。

図５において、通信のセッション欄１９４には、識別部１４２によりセッション毎に割り当てられた識別子が記述される。フロー欄１９６には、セッションに含まれる各フローのナンバーがセッション毎に記述される。通信のセッション欄１９４とフロー欄１９６との組み合わせは、キー項目であり、上記最大フロー数管理表の最大フロー数欄１９２の更新にあわせて、これらのキー項目が設定される。例えば、図４の最大フロー数欄１９２が更新されて“２”となった場合、図５の通信のセッション欄１９４及びフロー欄１９６には、それぞれ２行の領域が確保される。差分時間欄１９８には、パケット１８０の中のタイムスタンプ欄に記述されている時刻と到着時刻記憶領域１８２に記述されているパケットの到着時刻との差分時間が記述される。

なお、差分時間欄１９８に記述される差分時間は、上記のように、パケット１８０の中のタイムスタンプ欄に記述されている時刻と到着時刻記憶領域１８２に記述されているパケットの到着時刻との差分時間により、単純に毎回更新してもよいし、例えば、過去Ｎ回分の差分時間を加重平均したものにより更新してもよい。

遅延部１４３は、受信したパケットに対応する差分時間管理表を更新すると同時に、既に受信しているパケットを一時蓄積して遅延させるべき時間、つまり、パケットを送信すべき時刻を決定する。

具体的には、まず、遅延部１４３は、通信のセッションのフロー毎に、差分時間欄１９８に記述されている時間を比較して、そのセッションの中で最も遅く到着しているフローを特定する。次に、遅延部１４３は、セッションの中で最も遅く到着しているフローの差分時間欄１９８に記述されている値をＤ_ＭＡＸとして、そのセッションの他のフローの差分時間欄１９８に記述されている値（Ｄ_ｉ）のそれぞれについて、Ｄ_ＭＡＸ−Ｄ_ｉを計算する。Ｄ_ＭＡＸ−Ｄ_ｉで表される値は、そのパケットを一時蓄積して遅延させるべき時間を示している。そして、遅延部１４３は、Ｄ_ＭＡＸ−Ｄ_ｉの値から、パケットを送信すべき時刻を決定して、送信時刻記憶領域１８４に記述する。具体的には、遅延部１４３は、各パケットについて、到着時刻記憶領域１８２に記述されたパケットの到着時刻とＤ_ＭＡＸ−Ｄ_ｉで示される値とを加算した時刻を、パケットを送信すべき時刻として送信時刻記憶領域１８４に記述する。また、パケットを一時蓄積して遅延させる時間は、Ｄ_ＭＡＸ−Ｄ_ｉに限定されない。例えば、パケットを一時蓄積して遅延させる時間は、Ｄ_ＭＡＸ−Ｄ_ｉに任意の係数α（αは１．０以上の数）をかけ、α（Ｄ_ＭＡＸ−Ｄ_ｉ）としても良い。このように、１つのセッションに含まれる最後のパケットが到着したタイミング、又は前記最後のパケットが到着してから所定の時間が経過したタイミングを、パケットを送信すべき時刻として送信時刻記憶領域１８４に記述することができる。

例えば、図５において、セッションＢに含まれるフローが、フローＢ１〜フローＢ３であるとする。このとき、Ｄ_ＭＡＸ＝３０５なので、フローＢ２を一時蓄積する時間は、３０５−２１５＝９０であり、フローＢ３を一時蓄積すべき時間は、３０５−１２５＝１８０である。

遅延部１４３では、１つのセッションに含まれるすべてのパケットが受信されるまで上記一連の動作が繰り返されることにより、そのセッションに含まれるすべてのパケットを同時に送信すべき時刻が決定され、各パケットの送信時刻記憶領域１８４に記述される。

また、遅延部１４３は、１つのセッションに含まれるすべてのパケットを受信すると、図３に示すすべてのデータ（パケット１８０、到着時刻記憶領域１８２に記述されたパケットの到着時刻、及び送信時刻記憶領域１８４に記述されたパケットを送信すべき時刻）を、遅延部１４３の内部に保持する送信待ちキュー１４５に格納する。

補正部１４６では、送信待ちキュー１４５に格納されたデータに基づいて、１つのセッションに含まれる各パケットについて、これらのパケットが遅延部１４３で一時蓄積された時間の分だけタイムスタンプが補正される。具体的には、補正部１４６は、各パケットについて、各パケットを送信すべき時刻から各パケットの到着時刻を減算して、各パケットが遅延部１４３に一時蓄積された時間を計算し、この一時蓄積された時間の分だけ、各パケット中のタイムスタンプ欄に記述された時刻を足し上げる。上記の例では、第１のストリームのパケットに刻印されたタイムスタンプに記述された時刻Ｔ_０に、第１のストリームが蓄積された時間であるＴだけ足しあげて、Ｔ_０＋Ｔに補正する。

なお、中継装置１４０の上流（又は下流）の中継装置における一時蓄積処理により、タイムスタンプ欄に記述された時間にこれらの中継装置での一時蓄積時間が加算（又は減算）されている場合には、これらの一時蓄積時間を相殺するようなタイムスタンプの補正を行うことも可能である。例えば、タイムスタンプの補正は、第１のストリームのパケットに刻印されたタイムスタンプに記述された時刻Ｔ_０に、第１のストリームが蓄積された時間であるＴにβを乗じた時間を足しあげて、Ｔ_０＋βＴ（βは正の任意の係数）に補正することもできる。

ここで、補正部１４６は、タイムスタンプを補正するために、タイムスタンプの刻印粒度を知る必要がある。タイムスタンプの刻印粒度は、補正部１４６が予め知っていてもよいし、中継装置１４０が推定してもよい。中継装置１４０におけるタイムスタンプの刻印粒度の推定は、例えば、以下のようにして実現されうる。

すなわち、中継装置１４０で、通信のセッションのそれぞれのフロー毎にフローキューと呼ばれるキューを設ける。識別部１４２では、受信したパケットをそれぞれのフローキューに格納する。このとき、フローキューに格納された前後のパケットの通番１７２を比較し、通番１７２に隔たりがない場合、この２つのパケットの到達時刻記憶領域に記録されている時間の差を計算してＤ_ｇａｐとし、この２つのパケットのタイムスタンプの差を計算してＤ_ｔｓとする。Ｄ_ｇａｐとＤ_ｔｓとの比を検査することにより、タイムスタンプの刻印粒度を推定することができる。すなわち、同一経路で受信した連番のパケットの到着時刻の差Ｄ_ｇａｐとタイムスタンプの値の間隔Ｄ_ｔｓとの比（Ｄ_ｇａｐ／Ｄ_ｔｓ）を求め、この比の平均値やばらつきから、送信端末におけるタイムスタンプの刻印粒度の信頼性を確認する。このようにして、送信端末から時々刻々と送信されるストリーミングの送信間隔、つまり、これらのストリーミングのパケットに刻印されたタイムスタンプの刻印粒度を推定することができる。なお、この推定方式の、Ｄ_ｇａｐ及びＤ_ｔｓの算出には、例えば、これらの過去Ｍ回分の平均を用いるようにしてもよい。

補正部１４６がタイムスタンプの刻印粒度を知るためには、送信端末１００からの制御パケットを受信する必要があるので、中継装置１４０がタイムスタンプの刻印粒度を推定することにより、タイムスタンプからの刻印粒度を知らせるための制御パケットを削減することができる。

送信部１４８では、遅延部１４３の送信待ちキュー１４５に格納されたすべてのデータが走査され、受信端末１５０に対してパケットが送信される。このとき、送信部１４８では、上記パケットを送信すべき時刻を含む情報と現在時刻とを比較して、これらの時刻が一致した場合、またはパケットを送信すべき時刻が現在時刻よりも経過している場合に、受信端末１５０に対してパケットを送信する。

ここで、送信待ちキューに格納されたすべてのパケットを送信すべき時刻は、厳密には、上述したタイムスタンプの刻印粒度により異なりうる。送信部１４８によるこれらのパケットの具体的な送信処理は、例えば、マルチタスクをサポートするＯＳ上の１つのタスクを用いて、以下のように実現可能である。

まず、送信部１４８は、遅延部１４３の送信待ちキュー１４５に格納されたすべてのデータについて走査し、送信時刻記憶領域１８４に記憶されている領域が最も近いもの（最も近い未来に送信すべきと記憶されているもの）を選択する。そして、このパケットをＰ_ＮＥＸＴ、Ｐ_ＮＥＸＴの送信時刻をＴ_ＮＥＸＴ、現在時刻をＴ_ＮＯＷとして、Ｔ_ＮＥＸＴ−Ｔ_ＮＯＷ≧０を満たした後に、送信部１４８は、Ｐ_ＮＥＸＴの送信処理を行う。次いで、送信部１４８は、送信時刻記憶領域１８４に記憶されている領域がＰ_ＮＥＸＴの次に近いパケットについて、同様の送信処理を行う。このような処理を繰り返し行うことで、全ての送信待ちキュー１４５に格納されたすべてのデータが順次送信され、送信部１４８の処理を連続的に無矛盾に実行可能となる。

送信部１４８から送信された各パケットは、同期処理が実現されているのみならず、遅延部１４３で一時蓄積された時間の分だけタイムスタンプが補正されている。したがって、タイムスタンプを用いて送信端末１００と受信端末１５０との間の往復時間を計測する場合、遅延部１４３での一時蓄積時間を除いた時間が計測される。

受信端末１５０では、中継装置１４０の送信部１４８からの１つのセッションに含まれる複数のフローのパケットが受信され、再生される。

以上説明したように、本実施の形態によれば、遅延部１４３が、同期して送信すべき１つのセッションに含まれる複数のパケットを、送信すべき時刻まで一時蓄積してパケット遅延させ、補正部１４６が、一時蓄積した各パケットについて、一時蓄積された時間の分だけ、各パケット中のタイムスタンプ欄を補正するようにした。これにより、送信端末からの関連する複数のストリームのパケットが異なる経路で受信端末に伝送される場合であっても、受信端末の無駄な記憶領域を省略するとともに、複数のストリームを同期させて受信端末に伝送することができる。

また、送信端末と受信端末との間で階層符号化を用いたストリームの伝送が行われ、その伝送で帯域推定が行われている場合であっても、不必要に低い帯域を推定することを防止することができ、受信端末で複数のストリームから高品質なデータを再生することができる。

すなわち、識別部１４２、遅延部１４３、補正部１４６、及び送信部１４８が、上記のような処理を行うことにより、中継装置１４０における同期処理を実現することができる。このとき、同期される各パケット中のタイムスタンプが、遅延部１４３で一時蓄積された時間の分だけ補正されているので、送信端末１００と受信端末１５０との間でタイムスタンプを用いてパケットの往復時間の計測を行っても、不必要にパケットの往復時間を多く計測してしまうことがない。結果として、送信端末１００と受信端末１５０との間で、このパケットの往復時間を用いた帯域推定値を利用した流量制御が行われている場合でも、送信速度が不必要に低下することがなくなる。

また、補正部１４６のタイムスタンプ補正においては、タイムスタンプの刻印粒度をパケットの送信間隔から推定した結果を元にタイムスタンプを補正する。また、送信部１４８では、このタイムスタンプを元に再度送信を行うので、例外的にジッタを伴いながら到着時刻がずれて到着するパケットが存在する場合でも、送信端末が刻印したタイムスタンプの時刻に従って正確に再送信することができる。

（実施の形態２）
実施の形態２は、階層符号化とマルチキャスト通信とを組み合わせて利用する伝送方式に本発明を適用した例である。本実施の形態では、そのような伝送方式の中でも、特に、後述するＳＩＣＣ（Sender Initiated Congestion Control）と呼ばれる伝送方式に対して本発明を適用した場合について説明する。すなわち、本実施の形態は、実施の形態１の中継装置を、ＳＩＣＣ伝送方式の中継装置に適用した例である。そこで、まず本実施の形態の前提となるＳＩＣＣについて説明した後に本発明の適用例を説明することにする。

階層符号化とは、例えば、映像信号や音声信号などから、基本階層と基本階層以外の１つ以上の差分階層とからなる階層化されたデータを作成することをいう。作成された階層化データは、複数の受信端末に対して送信されるが、各受信端末は、基本階層のデータに加え、自端末の性能や通信環境、希望する受信データの品質などに応じた差分階層のデータを受信する。一般的に、受信端末は、受信する差分階層のデータを増やすことで、より高品質の映像を再生することができる。

このような階層符号化とマルチキャスト通信とを組み合わせて利用する伝送方式としては、例えば、文献（L. Vicisano, L. Rizzo, J. Crowcroft, “TCP-like congestion control for layered multicast data transfer”, Proc. IEEE ONFOCOM'98, Mar. 1998.）に示される方式がある。この方式による送信端末は、異なる符号化レートでエンコードされた複数のストリームを、それぞれ複数の異なるマルチキャストグループを用いて送信し、受信端末は、複数のストリームを受信し、同期して再生する。

このとき、それぞれのマルチキャストグループの配送経路が異なる場合や中継装置で特定のマルチキャストグループの優先制御が行われている場合には、複数のストリームが受信端末に到着するタイミングがずれることがある。その場合、中継装置又は受信端末で同期処理を行う必要がある。

複数の端末に対して、複数のストリームを流量制御しながら伝送する方式として、文献（村本衛一、米田孝弘、鈴木史章、鈴木良宏、中村敦司，“送信者起動マルチキャストにおける輻輳制御方法の提案”，インターネットカンファレンス ２００３論文集 ｐ５〜ｐ１０，２００３年１０月）で知られているＳＩＣＣ（Sender Initiated Congestion Control）がある。ＳＩＣＣでは、複数の端末にパケットを届ける方法として、文献（Y. Imai, M. Shin and Y. Kim, “XCAST6:eXplict Multicast on IPv6”, IEEE/IPSJ SAINT2003 Workshop4, IPv6 and Applications, Orland, Jan. 2003）で知られているＸＣＡＳＴを利用し、帯域推定方式として、上述したＲＦＣ３４４８で規定されるＴＦＲＣ（TCP friendly rate control）を利用する。

まず、ＸＣＡＳＴについて説明する。ＸＣＡＳＴとは、送信端末が、グループに属する全受信端末の宛先アドレスを、パケット内のオプションヘッダ又はペイロードに格納することにより、送信端末がパケットを配信する全受信端末を明示的に指定する明示的マルチキャスト方式の代表的な方式である。

ＸＣＡＳＴでは、中継装置（ルータなど）がＸＣＡＳＴに対応していない場合、パケットは、未配送の１台の受信端末に届けられる。受信端末は、パケット中に未配送の受信端末が残っている場合、パケットをその未配送の受信端末に対して送信し直す。受信端末がこの動作を繰り返すことで、すべての受信端末にパケットが配送される。

図６は、ＸＣＡＳＴを説明するための通信ネットワークの構成の一例を示す図である。

図６の通信システムは、送信端末２００、３台の中継装置２１０〜２１４、及び５台の受信端末２２０〜２２８を備えて構成される。なお、中継装置の台数及び受信端末の台数は特に限定されず、これらを接続する方法も任意である。

送信端末２００は、入力した原データを階層符号化して階層化データを作成し、作成した各階層化データに対して送信先アドレスなどの情報を付与したパケットを生成する。また、送信端末２００は、生成した各パケットを通信ネットワーク上に送信する。中継装置２１０〜２１４は、パケットに含まれる送信先アドレス情報に基づいてルーティングを行う。受信端末２２０〜２２８は、送信端末２００が配信したパケットを受信する。また、受信端末２２０〜２２８は、受信したデータをデコードし、基本階層のデータと差分階層のデータとを合成する。

送信端末２００が生成して送信するパケットについて、図７を用いて説明する。

図７（Ａ）〜図７（Ｅ）は、ＸＣＡＳＴ方式のパケットの一例を示す図である。なお、図７（Ａ）〜図７（Ｅ）は、パケットとしてＸＣＡＳＴ方式によるＩＰｖ６パケットを用いた場合の例である。

図７（Ａ）〜図７（Ｅ）において、ＩＰｖ６パケット２３０は、ユニキャストヘッダ２３２、ルーティングヘッダ２３４、及び映像データなどの送信したいデータ本体であるペイロード２３６を有する。

ユニキャストヘッダ２３２は、宛先アドレス及び送信元アドレスをそれぞれ１つずつ記述する領域である。例えば、図７（Ａ）では、宛先アドレスとして受信端末（Ｒ１）２２０のアドレスが（dst=R1）、送信元アドレスとして送信端末（Ｓ）２００のアドレスがそれぞれ記述されている。ユニキャストヘッダ２３２に記述される宛先アドレスは、ルーティングヘッダ２３４に記述される未配送のアドレスの中の最上位のアドレスである。このように、ユニキャストヘッダ２３２に受信端末のアドレスを１つ記述しておくことで、経路上の中継装置がＸＣＡＳＴに未対応の場合でも、この中継装置は、ＸＣＡＳＴ方式のＩＰｖ６パケット２３０をユニキャスト方式のパケットとして認識し、ユニキャストヘッダ２３２に記述された宛先アドレスが指し示す受信端末へ向けてパケットを転送することができる。

ルーティングヘッダ２３４は、送信先となる受信端末のアドレスリスト、及びアドレスリストに記述された各受信端末に対してパケットを配信済みか未配送かを示すフラグを記述する領域である。例えば、図７（Ａ）では、受信端末（Ｒ１）２２０、受信ノード（Ｒ３）２２４、及び受信ノード（Ｒ４）２２６が記述されている。アドレスリストに記述される宛先アドレスには順序があり、図７（Ａ）では、左側に位置するＲ１が最上位、右側に位置するＲ４が最下位である。前述の通り、ルーティングヘッダ２３４の未配送かつ最上位の宛先アドレスが、ユニキャストヘッダ２３２に記述される。

図６の通信システムにおいて、送信端末２００が、受信端末（Ｒ１）２２０、受信端末（Ｒ３）２２４、及び受信端末（Ｒ４）２２６に図７（Ａ）のパケットを送信する場合における各中継装置２１０〜２１４の動作を説明する。ここでは、中継装置２１０〜２１４がＸＣＡＳＴに対応している場合について説明する。

送信端末２００から中継装置２１０に、図７（Ａ）のパケットが送信されると、中継装置２１０は、受信したパケットを分割・複製する。具体的には、図７（Ａ）のパケットは、受信端末（Ｒ３）２２４及び受信端末（Ｒ４）２２６の宛先アドレスを配送済みにした受信端末（Ｒ１）２２０宛てのパケット（図７（Ｂ）参照）と、受信端末（Ｒ１）２２０の宛先アドレスを配送済みにし、ユニキャストヘッダ２３２に受信端末（Ｒ３）２２４の宛先アドレスが記述された受信端末（Ｒ３）２２４及び受信端末（Ｒ４）２２６宛てのパケット（図７（Ｃ）参照）とに分割・複製される。図７（Ｂ）のパケットは、受信端末（Ｒ１）２２０に転送され、図７（Ｃ）のパケットは、中継装置２１２に転送される。

中継装置２１２は、図７（Ｃ）のパケットを、受信端末（Ｒ４）２２６の宛先アドレスを配送済みにした受信端末（Ｒ３）２２４宛てのパケット（図７（Ｄ）参照）と、受信端末（Ｒ３）２２４の宛先アドレスを配送済みにし、ユニキャストヘッダ２３２に受信端末（Ｒ４）２２６の宛先アドレスが記述された受信端末（Ｒ４）２２６宛てのパケット（図７（Ｅ）参照）とに分割・複製する。図７（Ｄ）のパケットは、受信端末（Ｒ３）２２４に転送される。また、図７（Ｅ）のパケットは、中継装置２１４に転送され、受信端末（Ｒ４）２２６にさらに転送される。

このように、各中継装置は、通信システム内の各中継装置がＸＣＡＳＴに対応している場合、受信したパケット内のアドレスリストを参照して、パケットの分割・複製、及び転送を行いながら、各受信端末に対してパケットを効率的に配送する。

次に、中継装置２１０〜２１４のすべてがＸＣＡＳＴに未対応の場合における中継装置及び受信端末の動作を説明する。ここでも、図６の通信システムにおいて、送信端末２００が、受信端末（Ｒ１）２２０、受信端末（Ｒ３）２２４、及び受信端末（Ｒ４）２２６に図７（Ａ）のパケットを送信する場合における各中継装置２１０〜２１４の動作を説明する。

送信端末２００から中継装置２１０に、図７（Ａ）のパケットが送信されると、中継装置２１０は、図７（Ａ）のパケットを、ユニキャストヘッダ２３２に記述された宛先である受信端末（Ｒ１）２２０に転送する。

受信端末（Ｒ１）２２０は、図７（Ａ）のパケットを受信すると、アドレスリストに記述されているアドレスを参照して新たなパケット図７（Ｃ）を生成する。図７（Ｃ）のパケットは、受信端末（Ｒ１）２２０の宛先アドレスを配送済みにし、ユニキャストヘッダ２３２に受信端末（Ｒ３）２２４の宛先アドレスが記述された中継装置２１０宛てのパケットである。このパケットは、中継装置２１０及び中継装置２１２を経由して、受信端末（Ｒ３）２２４に転送される。

受信端末（Ｒ３）２２４は、図７（Ｃ）のパケットを受信すると、アドレスリストに記述されているアドレスを参照して新たなパケット図７（Ｅ）を生成する。図７（Ｅ）のパケットは、受信端末（Ｒ３）２２４の宛先アドレスを配送済みにし、ユニキャストヘッダ２３２に受信端末（Ｒ４）２２６の宛先アドレスが記述された中継装置２１２宛てのパケットである。このパケットは、中継装置２１２及び中継装置２１４を経由して、受信端末（Ｒ４）２２６に転送される。

このように、中継装置２１０〜２１４がＸＣＡＳＴに未対応の場合、各中継装置は、パケットの分割・複製を行わず、ユニキャストヘッダ２３２に記述された宛先アドレスの受信端末に向けて転送する。ユニキャストヘッダ２３２に記述される宛先アドレスは、ルーティングヘッダ２３４に記述されたアドレスリストの順序に従う。したがって、送信されたパケットの受信端末間の配送順序は、送信端末２００がルーティングヘッダ２３４に記述したアドレスリストの順序に依存する。

以上説明したように、ＸＣＡＳＴにおいては、通信システム内の中継装置がＸＣＡＳＴに対応している場合のみならず、通信システム内にＸＣＡＳＴに未対応の中継装置がある場合であっても、パケットの配送を実現することができる。

上記のように、ＳＩＣＣは、ＸＣＡＳＴにおいて、ＴＦＲＣを利用した流量制御を実現する方式である。以下、ＴＦＲＣを利用した流量制御について説明する。

ＳＩＣＣにおいて、送信端末は、ＸＣＡＳＴパケットを送信する受信端末を、各受信端末の性能や通信環境に基づいた複数のクラスに分類し、分類されたクラス毎に異なるレートのＸＣＡＳＴパケットを送信する。クラスの分類（送信端末から受信端末への送信可能レートの推定）は、ＴＦＲＣを利用して各受信端末について行われ、各受信端末のクラスは、逐次更新されうる。また、それぞれのＸＣＡＳＴパケットは、分類されたクラスに対応する受信者のアドレスに配送される。

このように、分類されたＳＩＣＣのクラス毎に、階層符号化でエンコードされた複数のストリームを送信することにより、利用可能な帯域が大きい受信端末（群）には、高詳細な動画を送信し、利用可能な帯域が小さい受信端末（群）には、粗い動画を送信するといった適応流量制御が可能となる。

次に、図６の通信システムに本発明の中継装置の同期方式（一時蓄積及びタイムスタンプの補正）を適用した動作について説明する。図６の例では、中継装置２１０〜２１４が、同期して送信すべき階層符号化された複数のストリームを一時蓄積するとともに、一時蓄積された各ストリームのパケットに記述されたタイムスタンプの値を補正する。

図６において、中継装置２１０〜２１４は、それぞれ図１の中継装置１４０と同一の機能を有している。すなわち、中継装置２１０〜２１４は、１つのセッションにおいて同期されるべき複数のストリームを識別する。また、中継装置２１０〜２１４は、これらのストリームがすべて到着するまで、先に到着したストリームに対して一時蓄積遅延処理を行う。さらに、中継装置２１０〜２１４は、一時蓄積遅延処理を行った各ストリームに対して、一時蓄積した時間だけタイムスタンプの値を補正する。

例えば、中継装置２１４が送信端末２００から時刻Ｔａに送信された上位階層のストリーム及び下位階層のストリームを同期して受信端末２２８に送信する場合について考える。ここで、上位階層のストリームが、中継装置２１０→中継装置２１２→受信端末２２２→中継装置２１２→中継装置２１４の順に伝送され時刻Ｔｂに中継装置２１４に到着し、下位階層のストリームが、中継装置２１０→受信端末２２０→中継装置２１０→中継装置２１２→受信端末２２２→中継装置２１２→中継装置２１４の順に伝送され時刻Ｔｃに中継装置２１４に到着するものとする。また、上位階層のストリームは、下位階層のストリームよりもＴｄだけ早く中継装置２１４に到着するものとする（つまり、Ｔｃ−Ｔｂ＝Ｔｄ）。

中継装置２１４は、上位階層のストリームを受信すると、受信した上位階層のストリームは、後で到着する下位階層のストリームと同期させて受信端末２２８に送信すべきストリームであることを識別する。そして、中継装置２１４は、先に到着した上位階層のストリームを、下位階層のストリームが到着するまで一時蓄積する。この一時蓄積時間は、例えば、Ｔｄである。最後に、中継装置２１４は、上位階層のストリーム及び下位階層のストリームを同期させて、下位階層のストリームが到着したタイミング、又は下位階層のストリームが到着した後のタイミングで受信端末２２８に送信する。

このとき、中継装置２１４は、先に到着した上位階層のストリームのタイムスタンプに記述された値Ｔａを補正する。このタイムスタンプの補正は、具体的には、上位階層のストリームのタイムスタンプに記述された値Ｔａに、上位階層のストリームの中継装置２１４での一時蓄積時間を加算することにより行われる。例えば、一時蓄積時間がＴｄであれば、上位階層のストリームのタイムスタンプに記述される値は、ＴａからＴａ＋Ｔｄに補正される。

このように、ＳＩＣＣを用いた伝送方式においても、中継装置２１０〜２１４が上述した同期処理を行うことにより、ＲＴＴを不必要に大きく算出することなく、階層化された複数のストリームを同期させることができる。

ここで、本実施の形態の階層符号化されたストリームのＸＣＡＳＴパケットに記述されているヘッダ構造と、実施の形態１のストリームのパケットに記述されているヘッダ構造（図２）とを比較して説明する。

図８は、本発明の実施の形態２の階層符号化されたストリームのＸＣＡＳＴパケットに記述されているヘッダ構造を示す図である。

ヘッダ２５０は、ネットワークヘッダ部２５１、トランスポートヘッダ部２５２、ＲＴＰヘッダ２５３、及びペイロード２５４からなる。ネットワークヘッダ部２５１は、ＩＰｖ６ヘッダ２５５と、パケットがＸＣＡＳＴ対応パケットであることを示すＸＣＡＳＴ６ヘッダ２５６とを含む。また、トランスポートヘッダ部２５２は、ＳＩＣＣヘッダ２６０を含む。

ＳＩＣＣヘッダ２６０は、宛先ポート２６１、送信元ポート２６２、バージョン２６３、タイプ２６４、ヘッダ長２６５、シーケンス番号２６６、クラス２６７、タイムスタンプ２６８、ＲＴＴ通知欄２６９、フラグ２７０、予備領域２７１、通番２７２、ＡＤＵ通番２７３、パケット長２７４、パケット数２７５、及びパケット通番２７６を含む。

次に、図８のヘッダ構造と図２のヘッダ構造との対応関係を説明する。

ネットワークヘッダ部２５１は、図２のネットワークヘッダ部１６１に相当する。具体的には、ＩＰｖ６ヘッダ２５５の中の宛先アドレス及び送信元アドレスは、宛先アドレス１６５及び送信元アドレス１６６に対応する。

トランスポートヘッダ部２５２のＳＩＣＣヘッダ２６０は、図２のトランスポートヘッダ部１６２に相当する。具体的には、宛先ポート２６１は、宛先ポート番号１６７に対応し、送信元ポート２６２は、送信元ポート番号１６８に対応する。バージョン２６３及びタイプ２６４の組み合わせは、データタイプ１６９に対応する。クラス２６７は、データタイプ１６９に対応する。タイムスタンプ２６８は、タイムスタンプ１７１に対応する。通番２７２は、通番１７２に対応する。

なお、ヘッダ長２６５、シーケンス番号２６６、ＲＴＴ通知欄２６９、フラグ２７０、予備領域２７１、ＡＤＵ通番２７３、パケット長２７４、パケット数２７５、及びパケット通番２７６は、送信端末と受信端末との間のＳＩＣＣ処理に特有のものであるか、または、本実施例には直接関係のないものであるため、その説明を省略する。

以上説明したように、階層符号化されたストリームのＸＣＡＳＴパケットのヘッダ構造２５０は、実施の形態１のヘッダ構造１６０に対応付けられる。したがって、本実施の形態の中継装置は、実施の形態１の中継装置と同様に、通信のセッションを識別でき、通信のセッション毎に含まれるフローを特定でき、同期処理を行うためにパケットを一時蓄積し、パケット往復時間に一時蓄積時間が加算されないようにタイムスタンプを補正することができる。

このように、本実施の形態によれば、ＳＩＣＣに代表される階層符号化とマルチキャスト通信とを組み合わせて利用する伝送方式においても、受信端末の無駄な記憶領域を省略し、かつ、不必要に低い帯域の推定を防止することができる。

すなわち、ＸＣＡＳＴパケットが受信端末で数珠繋ぎに転送される場合や上流の中継装置（ＸＣＡＳＴ対応）においてパケットの転送が行われる場合に、上流の受信端末又は中継装置が同期処理を行うことにより、下流の受信端末のバッファ領域を多量に消費することを防止することができる。また、送信端末と受信端末との間で流量制御が行われる場合に、その性質を不必要に低下させることなく複数のストリームを同期処理することができる。

例えば、図９に示すように、ＳＩＣＣにおいて、階層符号化された上位階層のストリームおよび下位階層のストリームが載せられたＸＣＡＳＴパケットがそれぞれ異なる経路で受信端末２４２〜２４６を伝送される場合であっても、受信端末間に設けられた中継装置（図示せず）が、必要に応じて、先に到着したストリームを一時蓄積して同期させた上で２つのストリームを下流の受信端末に送信する。これにより、この下流の受信端末のバッファリング領域の消費を防止することができる。また、これらのストリームがさらに下流の受信端末に伝送される場合であっても、さらに下流の受信端末または中継装置によるバッファリング処理の負荷を低減することができる。

さらに、同期処理を施した中継装置は、一時蓄積したストリームのパケットに記述されたタイムスタンプを、その一時蓄積時間の分だけ足し上げることにより補正する。すなわち、従来の中継装置において一時蓄積時間ＴＳ２を含めて計測されていたＲＴＴの計測値（ＴＳ３−ＴＳ１）は、この計測値から一時蓄積時間ＴＳ２を除いた理想的なＲＴＴの計測値（ＴＳ３−ＴＳ１−ＴＳ２）となるように補正される（図１０参照）。これにより、ＲＴＴを不必要に多く計測することなく、好適な帯域推定による流量制御を実現することができる。

以上まとめると、本実施の形態によれば、実施の形態１で説明したタイムスタンプの補正技術をＳＩＣＣ伝送方式に適用して、ＳＩＣＣ伝送方式の能力を向上させることができる。

（実施の形態３）
本実施の形態は、実施の形態１又は実施の形態２において、下流の中継装置や受信端末から上流の中継装置や送信端末に対して、同期処理を依頼する場合である。このようなケースとしては、下流の中継装置や受信端末が、自端末が保持するバッファリング領域では同期処理が不可能となった場合などが考えられる。以下、図面を参照して詳細に説明する。

図１１は、本発明の実施の形態３に係る中継装置を含む通信システムの全体構成の一例を示すブロック図である。

中継装置３００は、図１の中継装置１４０の構成において、バッファリング要求受付部３１０、及びバッファリング要求部３２０をさらに備える。中継装置３３０は、中継装置３００と同一の構成をとり、中継装置３００の下流に接続されている。中継装置３５０は、中継装置３００と同一の構成をとり、中継装置３００の上流に接続されている。ここでは、説明の簡略化のため、中継装置３３０については、バッファリング要求部３４０のみを図示し、中継装置３５０については、バッファリング要求受付部３６０のみを図示する。

なお、中継装置３００は、音声動画などのストリームを再生する受信端末の機能を有していてもよい。また、中継装置３３０は、中継装置３００の下流に接続されたバッファリング要求部を備える受信端末であってもよいし、中継装置３５０は、中継装置３００の上流に接続されたバッファリング要求部を備える送信端末であってもよい。

バッファリング要求受付部３１０は、下流の中継装置又は受信端末から送信されたバッファリング要求パケットを受信して、バッファリング要求部３２０に出力する。バッファリング要求パケットには、同期処理を要求する端末の宛先情報、同期処理を行うセッションに含まれるパケットの数や長さ、各パケットを一時蓄積する時間などの情報が記述される。

バッファリング要求部３２０は、バッファリング要求受付部３１０から入力されたバッファリング要求パケットを参照して、バッファリング要求パケットに記述された同期処理を中継装置３００で行うかどうかを判断する。バッファリング要求部３２０は、その判断の結果、同期処理を行うと判断した場合には、識別部１４２、遅延部１４３、及び補正部１４６に対して、自端末で同期処理を行う旨の指示を出す。一方、同期処理を行わないと判断した場合には、上流の中継装置又は送信端末に対してバッファリング要求パケットを送信する。なお、中継装置３００で同期処理を行うかどうかの判断方法は、後の動作説明で詳細に説明する。

以下、上述のように構成された通信システムの動作について詳細に説明する。ここでは、図１１に即して、中継装置３００が、中継装置３３０のバッファリング要求部３４０からのバッファリング要求パケットを受信し、同期処理を行うかどうかを判断して、同期処理を行わないと判断した場合に、中継装置３５０のバッファリング要求受付部３６０に対してバッファリング要求パケットを送信する例について説明する。

まず、中継装置３００のバッファリング要求受付部３１０は、中継装置３３０のバッファリング要求部３４０から送信されたバッファリング要求パケットを受信してバッファリング要求部３２０に出力する。

バッファリング要求部３２０は、バッファリング要求受付部３１０から入力されたバッファリング要求パケットを参照して、バッファリング要求パケットに記述された同期処理を中継装置３００で行うかどうかを判断する。この判断は、中継装置３００でバッファリング可能な最大量と、バッファリング要求パケットに記述された同期処理を行うときに自端末で必要となるバッファリングの総量とを比較することにより行われる。以下、具体的に説明する。

バッファリング要求部３２０は、遅延部１４３が保持する送信待ちキューの長さを参照することにより、中継装置３００でバッファリング可能な最大量を逐次把握している。ここでは、中継装置３００でバッファリング可能な最大量をＢ_ｍａｘとする。Ｂ_ｍａｘは、静的に設定してもよいし、他のメモリ資源との競合状態などを加味して動的に設定してもよい。

バッファリング要求部３２０は、バッファリング要求受付部３１０からバッファリング要求パケットが入力されると、遅延部１４３が保持する差分時間管理表（図５）を参照し、一時蓄積を行うべきフローを特定する。そして、バッファリング要求部３２０は、特定したフローの一時蓄積処理に必要なメモリの量を、バッファリング要求部３２０が保持するバッファリング量管理表を用いて管理する。

図１２は、バッファリング量管理表のデータ構造を示す図である。

図１２において、通信のセッション欄３７０には、識別部１４２によりセッション毎に割り当てられた識別子が記述される。フロー欄３７２には、セッションに含まれる各フローのナンバーがセッション毎に記述される。通信のセッション欄３７０とフロー欄３７２との組み合わせは、キー項目であり、図５の差分時間管理表の通信のセッション欄１９４とフロー欄１９６との組み合わせと同じものが記述される。受信間隔欄３７４には、それぞれのフローのパケットを受信する時間間隔が記述される。受信間隔欄３７４に記述される受信間隔は、新しいフローのパケットを受信する度に毎回更新してもよいし、例えば、過去Ｌ回のパケットの受信間隔を加重平均したものにより更新してもよい。レコード長３７６には、それぞれのフローのパケットの記憶領域の長さが記述される。それぞれのフローのパケット長が大きくなれば、それに従ってレコード長も大きい数値となる。レコード長３７６に記述される記憶領域は、例えば、過去Ｋ回のパケットの最大長を用いて更新することができる。

バッファリング要求部３２０は、上記バッファリング量管理表と図５の差分時間管理表とを用いて、バッファリング要求パケットに記述された同期処理を行うときに自端末で必要となるバッファリングの総量を計算し、Ｂ_ｎｅｅｄとする。

そして、バッファリング要求部３２０は、Ｂ_ｍａｘとＢ_ｎｅｅｄとを比較する。そして、Ｂ_ｍａｘ＞Ｂ_ｎｅｅｄであれば、バッファリング要求部３２０は、識別部１４２、遅延部１４３、及び補正部１４６に対して、自端末で同期処理を行う旨の指示を出し、識別部１４２、遅延部１４３、及び補正部１４６は、実施の形態１で説明した同期処理を行う。一方、Ｂ_ｍａｘ≦Ｂ_ｎｅｅｄであれば、上流の中継装置３５０のバッファリング要求受付部３６０に対してバッファリング要求パケットを送信する。なお、Ｂ_ｍａｘ≦Ｂ_ｎｅｅｄであっても、例えば、階層符号化された複数のストリームの一部の階層のみを同期処理し、他の部分の同期処理を上流の中継装置３５０に依頼することもできる。

中継装置３５０は、中継装置３００からのバッファリング要求パケットを受信すると、中継装置３００と同様に、同期処理を行うかどうかの判断を行う。そして、中継装置３５０は、同期処理を行うと判断した場合、実施の形態１で説明した同期処理を行う。一方、中継装置３５０は、同期処理を行わないと判断した場合、図示しないさらに上流の中継端末にバッファリング要求パケットを送信して同期処理を依頼する。

ここで、上流の中継装置又は送信端末が複数ある場合には、これらの装置や端末の中から、バッファリング要求パケットの送信先を決定する必要が生じる。バッファリング要求パケットの宛先は、例えば、次のような方法で決定されうる。

［宛先選択方式１］
通信のセッションに含まれるフローのパケットの送信元アドレスに対して送信する。

［宛先選択方式２］
通信のセッションに含まれるフローのパケットのＸＣＡＳＴヘッダ中に記述されている宛先アドレスのリストから選択した上流の端末のＩＰアドレスに対して送信する。

［宛先選択方式３］
まず、通信のセッションに含まれるフローのパケットのＸＣＡＳＴヘッダ中に記述されている宛先アドレスのリストから、自端末のアドレスより上流に記述されている宛先アドレスの部分リストを抽出する。そして、抽出した部分リストの先頭に送信元アドレス（送信端末のアドレス）を追加したリストを作成し、その並び順を反転させたアドレスリストが記述されたＸＣＡＳＴヘッダを持つ端末に対して送信する。

次に、バッファリング要求パケットについて、図１３を用いて説明する。

図１３は、バッファリング要求パケットの形式の一例を示す図である。

図１３のバッファリング要求パケットは、ＩＰｖ６ヘッダ３８１、ＸＣＡＳＴ６ヘッダ３８２、送信元アドレス３８３、宛先ポート番号３８４、送信元ポート番号３８５、データクラス３８６、及び蓄積時間３８７からなる。

ＩＰｖ６ヘッダ３８１の宛先アドレスには、上記宛先選択方式１〜３のいずれかにより決定されたバッファリング要求パケットの宛先アドレスが記述される。ＸＣＡＳＴ６ヘッダ３８２には、上記宛先選択方式３で宛先を決定した場合、宛先選択方式３で作成したアドレスリストが記述される。上記宛先選択方式１〜２で宛先を決定した場合、ＸＣＡＳＴ６ヘッダ３８２には何も記述されず、又はＸＣＡＳＴ６ヘッダ３８２は付与されない。送信元アドレス３８３は、ＩＰｖ４やＩＰｖ６などのネットワーク上のアドレスである。宛先ポート番号３８４及び送信元ポート番号３８５は、例えば、ＵＤＰなどのトランスポートプロトコルの宛先ポート番号及び送信元ポート番号である。データクラス３８６には、そのデータフローを含むセッションが有しているデータフローの数が記述される。蓄積時間３８７は、差分時間管理表を元に算出したフローを蓄積させるべき時間が記述される。

なお、本実施の形態のバッファリング要求部３２０は、中継装置３００でバッファリング可能な最大量とバッファリング要求パケットに記述された同期処理を行うときに自端末で必要となるバッファリングの総量とを比較することにより同期処理を行うかどうかを判断したが、バッファリング要求部３２０の判断基準は、これに限定されない。例えば、中継装置３００において、同期処理が実現されたかどうかの判定などのタスクを消費するＣＰＵ資源が足りない場合にも、上流の中継装置に同期処理を依頼することが想定される。このように、バッファリング要求パケットを受けたバッファリング要求部の判断基準としては、種々の形態が考えられる。

また、本実施の形態のバッファリング要求部３２０は、バッファリング要求パケットに記述された同期処理を中継装置３００で行うかどうかを判断したが、本発明はこれに限定されない。例えば、バッファリング要求受付部３１０が、バッファリング要求パケットに記述された同期処理を中継装置３００で行うかどうかを判断してもよい。

また、バッファリング要求パケットが、通信システムの最上流である送信端末まで転送された場合、送信端末は、パケットの送信自体を明示的に遅らせるようにしてもよい。

このように、本実施の形態によれば、実施の形態１及び実施の形態２の効果に加えて、中継装置が何らかの理由でパケットの一時蓄積及びタイムスタンプの補正による同期処理を行うことができない場合であっても、上流の中継装置に同期処理を依頼するので、通信システムのうちのいずれかのポイントで同期処理を行うことができ、ＲＴＴの増加による不必要に低い帯域の推定を防止することができる。

以上詳細に説明したように、上記各実施の形態によれば、送信端末と受信端末との間で流量制御を行いながら同期する必要がある複数のストリームを送信する場合に、本発明を中継装置、又はパケットを中継する受信端末に適用することで、受信端末で同期処理のための多量のメモリを必要とすることなしに、また、送信端末と受信端末との間の流量制御において不必要に性能劣化が起こることなしに、同期処理及び流量制御を行うことができる。

なお、上記各実施の形態では、中継装置が同期処理を行うようにしたが、本発明はこれに限定されない。例えば、必要に応じて、パケットの一時蓄積やタイムスタンプの補正を行う機能を有する受信端末が同期処理を行うようにしてもよい。この場合、受信端末のバッファリング領域は消費するが、不必要に低い帯域推定を防止することができ、受信品質の向上に一定の効果を得ることができる。

本発明に係る中継装置及び中継方法は、送信端末からの関連する複数のストリームが異なる経路で受信端末に伝送される場合であっても、受信端末の無駄な記憶領域を省略し、かつ、不必要に低い帯域推定を行うことなく受信端末で複数のストリームから高品質なデータを再生することができる効果を有し、例えば、複数のマルチメディアデータを中継し、同期させて伝送する中継装置及び中継方法として有用である。

本発明の実施の形態１に係る中継装置を含む通信システムの全体構成の一例を示すブロック図 ストリームのパケットに記述されているヘッダ構造の一例を示す図 遅延部の記憶部がパケット毎に管理するデータの構造を示す図 最大フロー数管理表のデータ構造を示す図 差分時間管理表のデータ構造を示す図 ＸＣＡＳＴを説明するための通信ネットワークの構成の一例を示す図 （Ａ）ＸＣＡＳＴ方式のパケットの一例を示す図、（Ｂ）ＸＣＡＳＴ方式のパケットの他の例を示す図、（Ｃ）ＸＣＡＳＴ方式のパケットのさらに他の例を示す図、（Ｄ）ＸＣＡＳＴ方式のパケットのさらに他の例を示す図、（Ｅ）ＸＣＡＳＴ方式のパケットのさらに他の例を示す図 本発明の実施の形態２の階層符号化されたストリームのＸＣＡＳＴパケットに記述されているヘッダ構造を示す図 異なる経路で複数の受信端末を転送される階層符号化された２つのストリームを示す図 送信パケットが一時蓄積された場合のＲＴＴの算出を示す図 本発明の実施の形態３に係る中継装置を含む通信システムの全体構成の一例を示すブロック図 バッファリング量管理表のデータ構造を示す図 バッファリング要求パケットの形式の一例を示す図 従来の同期処理の一例を説明するための図 従来の同期処理の他の例を説明するための図

符号の説明

１００ 送信端末
１１０、１２０ ルータ
１３０、１４０、３００、３３０、３５０ 中継装置
１４２ 識別部
１４３ 遅延部
１４４ 記憶部
１４５ 送信待ちキュー
１４６ 補正部
１４８ 送信部
１５０ 受信端末
３１０、３６０ バッファリング要求受付部
３２０、３３０ バッファリング要求部

Claims (7)

1. 送信装置から受信装置へ、データストリームを転送する中継装置であって、
   前記送信装置からの送信時刻が記録されたタイムスタンプをトランスポートヘッダ部に有するデータストリーム群から、所定のセッションにおいて同期される複数のデータストリームを識別する識別部と、
   前記複数のデータストリームの到着時刻のうち最も遅い時刻以降の所定の時刻まで、前記複数のデータストリームを一時蓄積する遅延部と、
   前記所定の時刻と前記到着時刻との差分に基づいて、前記複数のデータストリームの前記タイムスタンプを補正する補正部と、
   前記複数のデータストリームを前記所定の時刻以降に送信する送信部と、
   を有する中継装置。
2. 前記送信装置は、送受信間のパケット往復時間に基づいてデータストリームの流量を制御する送信装置であって、
   前記パケット往復時間は、前記補正部において補正されたタイムスタンプに基づいて算出される請求項１に記載の中継装置。
3. 前記識別部は、前記データストリーム群のヘッダに記述された宛先アドレス、送信元アドレス、宛先ポート番号、および送信元ポート番号を解析することによって前記複数のデータストリームを識別する請求項１に記載の中継装置。
4. 前記補正部は、前記所定の時刻と前記到着時刻との差分を、前記複数のデータストリームの前記タイムスタンプに加算することによって、前記タイムスタンプを補正する請求項１に記載の中継装置。
5. 前記補正部は、前記複数のデータストリームの前記到着時刻の間隔に基づいて前記複数のデータストリームの前記タイムスタンプの刻印粒度を推定し、推定された前記刻印粒度に基づいて前記複数のデータストリームの前記タイムスタンプを補正する請求項１に記載の中継装置。
6. 下流に接続される他の中継装置または受信装置から、データストリームのバッファリング要求パケットを受信するバッファリング要求受付部と、
   前記バッファリング要求を受入れるか否かを判断し、前記バッファリング要求を受入れる場合には、前記識別部に対して前記バッファリング要求パケットが示すデータストリームを前記データストリーム群として通知し、前記バッファリング要求を受入れない場合には、前記バッファリング要求パケットを上流に接続される他の中継装置または送信装置へ送信するバッファリング要求部と、
   をさらに有する請求項１に記載の中継装置。
7. 送信装置から受信装置へ、データストリームを転送する中継方法であって、
   識別部は、前記送信装置からの送信時刻が記録されたタイムスタンプをトランスポートヘッダ部に有するデータストリーム群から、所定のセッションにおいて同期される複数のデータストリームを識別し、
   遅延部は、前記複数のデータストリームの到着時刻のうち最も遅い時刻以降の所定の時刻まで、前記複数のデータストリームを一時蓄積し、
   補正部は、前記所定の時刻と前記到着時刻との差分に基づいて、前記複数のデータストリームの前記タイムスタンプを補正し、
   送信部は、前記複数のデータストリームを前記所定の時刻以降に送信する中継方法。

Images