JP2007300498A - Repeating apparatus and repeating method - Google Patents
Repeating apparatus and repeating method Download PDFInfo
- Publication number
- JP2007300498A JP2007300498A JP2006127895A JP2006127895A JP2007300498A JP 2007300498 A JP2007300498 A JP 2007300498A JP 2006127895 A JP2006127895 A JP 2006127895A JP 2006127895 A JP2006127895 A JP 2006127895A JP 2007300498 A JP2007300498 A JP 2007300498A
- Authority
- JP
- Japan
- Prior art keywords
- time
- packet
- data flow
- transmission
- 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
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Synchronisation In Digital Transmission Systems (AREA)
Abstract
Description
本発明は、映像や音声などのマルチメディアデータを中継して伝送する中継装置及び中継方法に関し、特に、複数のマルチメディアデータを中継し、同期させて伝送する中継装置及び中継方法に関する。 The present invention relates to a relay apparatus and a relay method for relaying and transmitting multimedia data such as video and audio, and more particularly to a relay apparatus and a relay method for relaying and transmitting a plurality of multimedia data in synchronization.
近年、ネットワークの急速な発展に伴って、テレビ会議やネットワークゲーム、遠隔地への講義の配信などにおいて、映像や音声、発表資料画面などの複数のマルチメディアデータを、ネットワークを介して複数の受信端末に対して同時に伝送するマルチキャスト通信が行われている。 With the rapid development of networks in recent years, multiple multimedia data such as video, audio, and presentation data screens are received via the network for video conferences, network games, and distribution of lectures to remote locations. Multicast communication for simultaneous transmission to terminals is performed.
マルチキャスト通信において、各受信端末は、受信する各マルチメディアデータ間の同期をとる必要がある。例えば、送信端末が、音声とその話者の画像とを別々のストリームとしてネットワークを介して伝送する。受信端末は、この別々のストリームのそれぞれを受信して再生する場合、音声とその話者の画像とがずれないようにこの２つのストリームの再生タイミングを合わせて、同時にスピーカとディスプレイとに出力する必要がある。 In multicast communication, each receiving terminal needs to synchronize each received multimedia data. For example, the transmitting terminal transmits the voice and the image of the speaker as separate streams over the network. When the receiving terminal receives and plays back each of the separate streams, the playback timings of the two streams are matched and output to the speaker and the display at the same time so that the voice and the image of the speaker are not shifted. There is a need.
一般に、複数のストリームの同期処理を実現する技術として、送信端末が、ストリームを構成するパケットにタイムスタンプを刻印し、受信端末が、パケットに刻印されたタイムスタンプを用いて、複数のストリームに対応するマルチメディアデータの再生タイミングを揃える処理が知られている。 In general, as a technique for realizing the synchronization processing of multiple streams, the sending terminal stamps the time stamps on the packets that make up the stream, and the receiving terminal supports multiple streams using the time stamps stamped on the packets. Processing for aligning the reproduction timing of multimedia data to be performed is known.
パケットにタイムスタンプを刻印して送信する方法として、ＲＦＣ１８８９で規定されるＲＴＰ（real-time transport protocol）がある。ＲＴＰでは、ＲＴＰヘッダの３２ビットのタイムスタンプ欄に、送信端末のアプリケーションがパケットの送信時刻（以下「タイムスタンプ」という）を刻印する。同時刻に再生すべき複数のストリームがある場合には、それぞれのストリームを構成するパケットに対して別々にタイムスタンプが刻印される。このとき、ＲＴＰヘッダの３２ビットの空間に、どのような時刻粒度でタイムスタンプを刻印するかは、送信端末のアプリケーションにより決定される。例えば、１秒間に３０枚の画像を再生する画像ストリームのように高速で多量のパケットを送信する場合には、１０００マイクロ秒の時刻粒度で、音声のように１０ｍｓ毎にパケットを送信する場合には、１０マイクロ秒の時刻粒度でタイムスタンプを刻印する。このように、異なる時刻粒度でそれぞれタイムスタンプを刻印するということは、送信端末のアプリケーション毎に決定することができる。 As a method of transmitting a time stamp on a packet, there is a real-time transport protocol (RTP) defined by RFC1889. In RTP, an application of a transmission terminal stamps a packet transmission time (hereinafter referred to as “time stamp”) in a 32-bit time stamp field of an RTP header. When there are a plurality of streams to be reproduced at the same time, time stamps are individually stamped on the packets constituting each stream. At this time, it is determined by the application of the transmitting terminal at what time granularity the time stamp is imprinted in the 32-bit space of the RTP header. For example, when a large number of packets are transmitted at high speed, such as an image stream that reproduces 30 images per second, when packets are transmitted every 10 ms, such as voice, at a time granularity of 1000 microseconds. Stamps a time stamp with a time granularity of 10 microseconds. Thus, imprinting time stamps with different time granularities can be determined for each application of the transmitting terminal.
このことは、送受信端末の送受信アプリケーションは、ＲＴＰヘッダへのタイムスタンプの刻印の時刻粒度を知っているが、ルータやスイッチなどのネットワークの中間ノードは、パケットを解析してもこのタイムスタンプの刻印の時刻粒度を知ることができないということを意味する。 This means that the transmission / reception application of the transmission / reception terminal knows the time granularity of the time stamp imprinting on the RTP header, but the intermediate node of the network such as a router or switch can also imprint the time stamp even if the packet is analyzed. It means that the time granularity of cannot be known.
複数のマルチメディアデータ（ストリーム）を同期させるために用いることができるプロトコルは、ＲＴＰに限られない。例えば、アプリケーションの設計者が複数のマルチメディアデータを多重伝送する方式を決定し、決定された方式に従って、送信端末が複数のストリームを伝送し、受信端末が、先に受信したストリームのパケットを一時蓄積して後に受信したストリームのパケットと合わせて再生することにより、同期処理を実現することもできる。 A protocol that can be used to synchronize a plurality of multimedia data (streams) is not limited to RTP. For example, an application designer determines a method for multiplexing and transmitting a plurality of multimedia data, and according to the determined method, a transmitting terminal transmits a plurality of streams, and a receiving terminal temporarily transmits a packet of the previously received stream. Synchronizing processing can also be realized by accumulating and playing back together with packets of a stream received later.
このような同期処理を実現する技術として、例えば、特許文献１に記載されているものがある。
As a technique for realizing such synchronization processing, for example, there is one described in
特許文献１には、受信端末で、多重メディアストリーム記述方式と表現される記述方式に従って伝送される複数のメディアストリームを適宜バッファリングし、再生することにより、同期処理を実現する方式が開示されている。
図１４は、特許文献１に記載されている同期処理を説明するための図である。
FIG. 14 is a diagram for explaining the synchronization processing described in
図１４において、受信機１０は、複数の多重記述ビットストリームを受信して、ビットストリーム毎に区別して複数のバッファ１２やバッファ１４に格納する。多重記述復号器１６は、多重メディアストリーム記述方式に従って、バッファ１２やバッファ１４に格納されたストリームを取り出して再生する。
In FIG. 14, the
一方、複数のストリームのバッファリング処理をルータのような中継ノードが行うことにより同期処理を実現する技術として、例えば、特許文献２に記載されているものがある。
On the other hand, as a technique for realizing synchronization processing by performing buffering processing of a plurality of streams by a relay node such as a router, for example, there is one described in
特許文献２には、中継ノードで、各送信端末から送信された複数のストリームを一旦蓄積し、蓄積された複数のストリームを受信端末へ転送する間隔を制御することにより、同期処理を実現する技術が開示されている。
図１５は、特許文献２に記載されている同期処理を説明するための図である。
FIG. 15 is a diagram for explaining the synchronization processing described in
図１５において、送信端末２０ａ，２０ｂ，２０ｃは、それぞれ、音声や動画などのストリームを別々に送信する。このとき、各送信端末は、ストリームを構成するパケットのＲＴＰヘッダのタイムスタンプ欄に、パケットの送信時刻を刻印する。同期ノード３０は、各送信端末から複数のストリームを受信すると、タイムスタンプ欄に刻印された情報を用いて複数のストリームのパケットの送出順序を決定し、その順序に従って、複数のストリームを受信端末４０ａ，４０ｂ，４０ｃへ転送する。同期ノード３０は、複数のストリームの転送時に、それぞれのストリームのパケットの送信間隔を再現するため、各送信端末からのパケットの送信時刻を推定して得られたパケットの送信間隔でストリームを転送するようにパケットの転送間隔を制御する。
In FIG. 15, the
このように、送信端末と受信端末との間の中継ノードで同期処理を行う場合、送信端末と受信端末との間で、帯域を推定し、適切な流量のストリームを送信する流量制御が行われることがある。帯域を推定する方法としては、例えば、ＲＦＣ３４４８で規定されるＴＦＲＣ（tcp friendly rate control）がある（非特許文献１）。 As described above, when synchronization processing is performed at the relay node between the transmission terminal and the reception terminal, flow rate control is performed between the transmission terminal and the reception terminal to estimate the bandwidth and transmit an appropriate flow rate stream. Sometimes. As a method for estimating the bandwidth, for example, there is TFRC (tcp friendly rate control) defined by RFC3448 (Non-Patent Document 1).
ＴＦＲＣとは、送信端末と受信端末との間のパケットの往復時間（ＲＴＴ：round trip time）を計測し、パケットの損失率を用いて算出される損失イベント率（ｐ）を計算し、ＲＴＴとｐとを用いて、送受信端末間で利用可能な帯域を推定する方式である。ＴＦＲＣにおいて、ＲＴＴは、以下のようにして計測される。まず、送信端末が、タイムスタンプを刻印したパケットを受信端末に送信し、パケットを受信した受信端末が、即座にそのタイムスタンプ欄を応答パケットに転記して送信端末に返送する。そして、送信端末は、受信端末からの応答パケットを受信した時刻と応答パケット中に転記してある送信時刻との差を計算してＲＴＴとする。ＲＴＴは、送信端末と受信端末との間の同一経路でＴＣＰ接続をした場合の往復時間と同じ時間が計測されることが望ましい。 TFRC measures the round trip time (RTT) between a transmitting terminal and a receiving terminal, calculates a loss event rate (p) calculated using the packet loss rate, This is a method for estimating a usable bandwidth between transmitting and receiving terminals using p. In TFRC, RTT is measured as follows. First, the transmitting terminal transmits a packet stamped with a time stamp to the receiving terminal, and the receiving terminal that has received the packet immediately transcribes the time stamp field into a response packet and returns it to the transmitting terminal. Then, the transmitting terminal calculates the difference between the time when the response packet is received from the receiving terminal and the transmission time transcribed in the response packet to obtain RTT. As for RTT, it is desirable to measure the same time as the round-trip time when TCP connection is made on the same route between the transmission terminal and the reception terminal.
また、ＴＦＲＣでは、送受信端末間で利用可能な帯域推定値は、次の式（１）で与えられる。式（１）より、ＴＦＲＣでは、計測されたＲＴＴの値が大きくなると、帯域推定値は、それに比例して小さくなる。 In TFRC, a band estimation value that can be used between transmitting and receiving terminals is given by the following equation (1). According to Equation (1), in TFRC, when the measured RTT value increases, the band estimation value decreases in proportion thereto.
なお、送信端末と受信端末との間で行われる帯域推定方法としては、ＴＦＲＣ以外の方法も採用されうる。ＴＦＲＣ以外の帯域推定方法においても、ＲＴＴを用いて帯域の推定を行うこと、及びＲＴＴの計測値が高くなるにつれて帯域推定値が低くなることは、ＴＦＲＣと共通する。
しかしながら、特許文献１記載の技術にあっては、受信端末で、受信した一部のストリームを、同期処理すべき別のストリームを受信するまで蓄積する記憶領域を確保する必要があるという問題がある。すなわち、本来同期すべき複数のストリームのいずれか１つが遅れて到着する場合、受信端末で、先に受信したストリームを蓄積するための多量の記憶領域が消費されるという問題がある。
However, the technique described in
この点、特許文献２記載の技術では、中継ノードによる同期処理を用いているため、受信端末でバッファリングする必要がなくなり、受信端末でのバッファリング用の記憶領域を削減することができるが、以下の問題がある。
In this regard, since the technique described in
特許文献２記載の技術にあっては、送信端末と受信端末との間で帯域の推定を行っている場合、パケットが中継ノードで蓄積されるため、帯域推定値が不必要に低く算出されてしまい、伝送性能が悪化するという問題がある。すなわち、帯域の推定において、送信端末と受信端末との間のパケットの往復時間（ＲＴＴ）を計測する場合、パケットが中継ノードで一時蓄積された分だけ、ＲＴＴが多く算出される。このとき、ＲＴＴは、送信端末と受信端末との間の同一経路でＴＣＰ接続をした場合の往復時間と同じ時間とはならない。上記のように、帯域推定値は、計測されたＲＴＴの値が大きくなるに従って小さくなるため、ＲＴＴの計測値の増加により、推定帯域値が小さく算出されて伝送性能の悪化につながる。
In the technique described in
特許文献１及び特許文献２の上記問題点は、特に、マルチキャスト通信において、同期させるべき複数のストリームが複数の送信端末から送信される場合や階層符号化を利用したマルチキャスト通信において、中継装置がパケットの分割や複製を行って伝送する場合に顕著に現れる。
The above-mentioned problems of
本発明は、かかる点に鑑みてなされたものであり、送信端末からの関連する複数のストリームが異なる経路で受信端末に伝送される場合であっても、受信端末の無駄な記憶領域を省略し、かつ、不必要に低い帯域推定を行うことなく受信端末で複数のストリームから高品質なデータを再生することができる中継装置及び中継方法を提供することを目的とする。 The present invention has been made in view of such a point, and even when a plurality of related streams from the transmission terminal are transmitted to the reception terminal through different paths, the useless storage area of the reception terminal is omitted. And it aims at providing the relay apparatus and the relay method which can reproduce | regenerate high quality data from a some stream in a receiving terminal, without performing a low band estimation unnecessarily.
本発明の中継装置は、複数のデータフローの中から１つのセッションにおいて同期されるべき特定のデータフロー群を識別する識別部と、前記特定のデータフロー群の一部のデータフローの送信を遅延させる遅延部と、前記遅延させたデータフローに刻印されたタイムスタンプを、前記遅延部により遅延させた時間分だけ補正する補正部と、前記特定のデータフロー群を送信する送信部と、を有する構成を採る。 The relay apparatus of the present invention delays transmission of an identification unit that identifies a specific data flow group to be synchronized in one session from among a plurality of data flows, and a part of the specific data flow group A delay unit for correcting the time stamp stamped on the delayed data flow by a time delayed by the delay unit, and a transmission unit for transmitting the specific data flow group. Take the configuration.
本発明によれば、送信端末からの関連する複数のストリームが異なる経路で受信端末に伝送される場合であっても、複数のストリームを同期させて受信端末に伝送することが可能となり、受信端末におけるバッファのための記憶領域の消費を節約することができる。また、送信端末と受信端末との間で階層符号化を用いたストリームの伝送が行われ、その伝送で帯域推定が行われている場合であっても、不必要に低い帯域を推定することを防止することができ、受信端末で複数のストリームから高品質なデータを再生することができる。 According to the present invention, even when a plurality of related streams from a transmitting terminal are transmitted to a receiving terminal through different paths, it is possible to synchronize and transmit the plurality of streams to the receiving terminal. It is possible to save the consumption of the storage area for the buffer. In addition, even when a stream transmission using hierarchical coding is performed between a transmission terminal and a reception terminal and band estimation is performed in the transmission, it is necessary to estimate an unnecessarily low band. Therefore, it is possible to reproduce high quality data from a plurality of streams at the receiving terminal.
以下、本発明の実施の形態について、図面を参照して詳細に説明する。 Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.
（実施の形態１）
図１は、本発明の実施の形態１に係る中継装置を含む通信システムの全体構成を示すブロック図である。
(Embodiment 1)
FIG. 1 is a block diagram showing an overall configuration of a communication system including a relay device according to
図１の通信システムは、送信端末１００、ルータ１１０，１２０、中継装置１３０、中継装置１４０、及び受信端末１５０を備えて構成される。
The communication system in FIG. 1 includes a
中継装置１４０は、識別部１４２、遅延部１４３、補正部１４６、及び送信部１４８を備える。
The
なお、中継装置１３０と中継装置１４０とは、同一の構成及び機能をとりうるが、ここでは、中継装置１３０は、単にルータ１１０からのストリームを中継してルータ１２０へ出力するものとして説明する。
Although the
送信端末１００は、映像や音声などのマルチメディアデータの複数のストリームを受信端末１５０に対して送信する。また、送信端末１００は、ストリームの送信時に、各ストリームを構成するパケットに対して、そのストリームの送信時刻であるタイムスタンプを刻印する。タイムスタンプの刻印の時刻粒度は、送信端末１００のアプリケーションにより、自由に変更することができる。また、送信端末１００から送信される複数のストリームは、同期して再生可能であれば、その内容や数は限定されず、例えば、階層符号化された複数のストリームであってもよい。
The
ルータ１１０，１２０は、ストリームのパケットに含まれる送信先アドレス情報に基づいてルーティングを行う。すなわち、ルータ１１０，１２０は、受信したストリームのパケットの分割・複製を行い、分割・複製されたストリームのパケットを、送信先アドレス情報に基づいて転送する。
The
識別部１４２は、送信端末１００からの複数のストリームのパケットの中に記述されているヘッダを解析することにより、これらのストリームのうち、互いに関連がある複数のストリームを識別する。ここで、「互いに関係がある複数のストリーム」とは、例えば、テレビ会議における音声と画像のように、１つのセッションにおいて同期されるべき複数のデータのストリームを意味する。したがって、識別部１４２は、受信したパケットが属する通信のセッション及びそのセッションに含まれる複数のフローを識別する。
The
具体的には、識別部１４２による識別は、以下のようにして行われる。まず、識別部１４２は、ヘッダに記述された各ストリームの宛先アドレスや送信元アドレス、宛先ポート番号、送信元ポート番号などを解析する。この解析により、通信のセッションを特定し、次いで、特定されたセッションに含まれる複数のフローを識別する。
Specifically, identification by the
遅延部１４３は、識別部１４２により識別された、１つのセッションに含まれる複数のフローに対して一時蓄積遅延処理を行う。すなわち、遅延部１４３は、１つのセッションに含まれる複数のフローのパケットを送信すべき時刻を特定し、特定された時刻まで、そのセッションに含まれる複数のフローを蓄積することによりパケットの送信を遅延させる。ここで、「パケットを送信すべき時刻」は、各パケットに刻印されたタイムスタンプと、各パケットの遅延部１４３への到着時刻とにより決定されるが、詳細については、後の動作説明で説明する。
The
また、遅延部１４３は、パケット単位で、タイムスタンプが刻印されたパケットそのものを示す情報と、パケットの遅延部１４３への到着時刻と、そのパケットが属するセッションのパケットを送信すべき時刻とを対応付けて格納する記憶部１４４を有している。また、遅延部１４３は、記憶部１４４に格納されるこれらの情報を更新するための最大フロー数管理表、及び差分時間管理表を保持している。これらの詳細については、後の動作説明で、図３乃至図５を用いて説明する。
Further, the
また、遅延部１４３は、１つのセッションに含まれる複数のフローのパケット、これらのパケットの遅延部１４３への到着時刻、及びパケットを送信すべき時刻を含むデータを、遅延部１４３の内部に保持する送信待ちキュー１４５に格納する。
The
補正部１４６は、送信待ちキュー１４５に格納されたデータに基づいて、１つのセッションに含まれる各パケットについて、これらのパケットが遅延部１４３で一時蓄積された時間の分だけタイムスタンプを補正する。具体的には、補正部１４６は、各パケットについて、各パケットを送信すべき時刻から各パケットの到着時刻を減算して、各パケットが遅延部１４３に一時蓄積された時間を計算し、この一時蓄積された時間の分だけ、各パケット中のタイムスタンプ欄に記述された時刻を足し上げる。
Based on the data stored in the
送信部１４８は、遅延部１４３の送信待ちキュー１４５に格納されたすべての情報について走査し、受信端末１５０に対してパケットを送信する。このとき、送信部１４８は、上記パケットを送信すべき時刻を含む情報と現在時刻とを比較して、これらの時刻が一致した場合、またはパケットを送信すべき時刻が現在時刻よりも経過している場合に、受信端末１５０に対してパケットを送信する。
The
送信部１４８から送信された各パケットは、同期処理が実現されているのみならず、遅延部１４３で一時蓄積された時間の分だけタイムスタンプが補正されている。したがって、タイムスタンプを用いて送信端末１００と受信端末１５０との間の往復時間を計測する場合、遅延部１４３での一時蓄積時間を除いた時間が計測される。
Each packet transmitted from the
受信端末１５０は、中継装置１４０の送信部１４８からの１つのセッションに含まれる複数のフローのパケットを受信して再生する。
The receiving
以下、上述のように構成された通信システムの動作について詳細に説明する。 Hereinafter, the operation of the communication system configured as described above will be described in detail.
まず、送信端末１００から、映像や音声などのマルチメディアデータの複数のストリームが受信端末１５０に対して送信される。ここでは、送信端末１００から受信端末１５０に対して送信されるストリームは、音声情報である第１のストリームと動画情報である第２のストリームとの２つであり、これらのストリームは時刻Ｔ０に同時に送信端末１００から送信されるものとして説明する。第１のストリーム及び第２のストリームのパケットには、これらのストリームが受信端末１５０で同期して再生可能なように、送信時刻であるタイムスタンプがそれぞれ刻印されている。
First, a plurality of streams of multimedia data such as video and audio are transmitted from the
なお、ここでは、第１のストリームを音声情報、第２のストリームを動画情報としたが、本発明に適用できるストリームは、これに限定されない。例えば、階層符号化された複数のストリームであってもよいし、３以上の複数のストリームであってもよい。すなわち、同期して再生する複数のストリームであれば、その内容及び数は限定されない。 Although the first stream is audio information and the second stream is moving image information here, the stream applicable to the present invention is not limited to this. For example, it may be a plurality of hierarchically encoded streams or a plurality of three or more streams. That is, the content and number of streams are not limited as long as they are a plurality of streams that are reproduced in synchronization.
送信端末１００から送信された第１のストリーム及び第２のストリームは、それぞれ異なる経路で中継装置１４０に配送される。ここでは、その一例として、第１のストリームが、ルータ１１０→中継装置１３０→ルータ１２０→中継装置１４０の順で配送されて時刻Ｔ１に中継装置１４０に到着するものとする。第２のストリームは、ルータ１１０→ルータ１２０→中継装置１４０の順で配送されて時刻Ｔ２に中継装置１４０に到着するものとする。また、第２のストリームは、第１のストリームよりもＴ秒遅く中継端末１４０に到着するものとして説明する。すなわち、Ｔ２−Ｔ１＝Ｔが成り立つ。
The first stream and the second stream transmitted from the
なお、本発明は、Ｔが正の数である場合のみならず、Ｔが負の数、つまり、第１のストリームが第２のストリームよりもＴ秒遅く中継端末１４０に到着する場合にも適用可能である。すなわち、第１のストリームの到着時刻と第２のストリームの到着時刻とに差があるすべての場合について適用可能である。
The present invention is applicable not only when T is a positive number, but also when T is a negative number, that is, when the first stream arrives at the
識別部１４２は、第１のストリームに記述されているヘッダ、及び第１のストリームよりＴ秒遅く到着した第２のストリームに記述されているヘッダをそれぞれ解析して、第１のストリームと第２のストリームとが互いに関連があるストリームであることを識別する。すなわち、音声情報である第１のストリーム及び動画情報である第２のストリームは、１つのセッションにおいて同期されるべきストリームであるかどうかが識別される。
The
ここで、識別部１４２による識別動作について、図２を用いて説明する。図２は、ストリームのパケットに記述されているヘッダ構造の一例を示す図である。
Here, the identification operation by the
ヘッダ１６０は、ネットワークヘッダ部１６１、トランスポートヘッダ部１６２、ＲＴＰヘッダ１６３、及びペイロード１６４からなる。ネットワークヘッダ部１６１は、宛先アドレス１６５及び送信元アドレス１６６を含む。トランスポートヘッダ部１６２は、宛先ポート番号１６７、送信元ポート番号１６８、データタイプ１６９、データクラス１７０、タイムスタンプ１７１、及び通番１７２を含む。
The header 160 includes a
宛先アドレス１６５及び送信元アドレス１６６は、ＩＰｖ４やＩＰｖ６などのネットワーク上のアドレスである。ネットワークヘッダ部１６１には、ＩＰヘッダを抽象的に表したＩＰｖ４やＩＰｖ６で定義されているＩＰヘッダに含まれる項目が含まれてもよいし、ホップバイホップ（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.）で知られているＸＣＡＳＴのヘッダが含まれてもよい。
The
宛先ポート番号１６７及び送信元ポート番号１６８は、例えば、ＵＤＰ（User Define Protocol）などのトランスポートプロトコルの宛先ポート番号及び送信元ポート番号である。データタイプ１６９は、そのパケットがストリームを構成するデータの一部なのか、制御パケットなのかを区別するための領域である。データタイプ１６９は、トランスポートプロトコルによって、例えば、ビットフラグや数など、その実現方法が変わりうる。
The
データクラス１７０は、複数のストリームの複数のデータフローを多重化する領域である。データクラス１７０には、そのデータフローを含むセッションが有しているデータフローの数が記述されており、データクラス１７０に記述されている最大値が１つの通信のセッションの中のフローの数を表す。タイムスタンプ１７１は、パケットの送信端末１００からの送信時刻を記録する領域である。通番１７２は、データフローを構成するパケット毎に付与された番号である。
The
ＲＴＰヘッダ１６３は、アプリケーションがストリームを再生するために必要な情報を格納する。アプリケーションがストリームを再生するために必要な情報には、例えば、アプリケーションでの音声や動画などの再生タイミングを規定するためのタイムスタンプや通番といった情報が含まれる。ペイロード１６４は、音声や画像などの送信したいデータ本体である。
The
なお、ヘッダ１６０の構成順序は、図２の並びに限定されない。例えば、データクラス１７０が、ＲＴＰヘッダ１６３の後に出現してもよいし、宛先ポート番号１６７の位置と送信元ポート番号１６８の位置とが逆転してもよい。
Note that the configuration order of the header 160 is not limited to that shown in FIG. For example, the
まず、識別部１４２は、ヘッダ１６０に記述された宛先アドレス１６５、送信元アドレス１６６、宛先ポート番号１６７、及び送信元ポート番号１６８を解析して通信のセッションを特定する。次いで、識別部１４２は、データクラス１７０により、特定されたセッションに含まれる複数のフローを識別する。このようにして、識別部１４２では、パケットのヘッダ１６０を解析することにより、通信のセッション及びそのセッションに含まれる複数のフローが識別される。上記の例では、先に到着した第１のストリームのヘッダを解析することにより、第１のストリームのフローと第２のストリームのフローとの２つのフローからなるセッションが存在することが識別される。
First, the
なお、通信のセッションの識別には、上記の他にも以下のような方法を用いることができる。例えば、宛先アドレス１６５のみを用いてもよいし、宛先ポート番号１６７及び送信元ポート番号１６８のかわりに、ＲＴＰヘッダ１６３に含まれるＳＳＲＣ（送信元識別子）を用いてもよい。また、ＩＰｖ６ヘッダのトラフィッククラスやオプションヘッダ中の特定のチャネル識別子を用いてもよい。
In addition to the above, the following method can be used for identifying a communication session. For example, only the
また、セッションに含まれる複数のフローを特定するには、上記の他にも以下のような方法を用いることができる。例えば、ＩＰｖ６ヘッダのフローラベルを用いてもよいし、独自に定義したヘッダを追加して用いてもよい。また、送信元アドレス１６６、宛先ポート番号１６７及び送信元ポート番号１６８を用いることも可能であるし、ＶＬＡＮ番号やＭＰＬＳのラベルなど下位層の仮想回線を多重化するための識別子を用いることも可能である。
In addition to the above, the following method can be used to identify a plurality of flows included in a session. For example, an IPv6 header flow label may be used, or a uniquely defined header may be added and used. It is also possible to use a
識別部１４２の機能を実現する方法としては、上記説明で用いられていないヘッダ１６０の領域またはその領域の一部を用いて、通信のセッションを識別し、そのセッションの中の複数のフローを識別しうる。換言すれば、識別部１４２の機能は、トランスポートプロトコル毎に様々な方式で実現することができる。
As a method of realizing the function of the
遅延部１４３では、識別部１４２により識別された、１つのセッションに含まれる複数のフローに対して一時蓄積遅延処理が行われる。すなわち、遅延部１４３では、１つのセッションに含まれる複数のフローのパケットを送信すべき時刻を特定し、特定された時刻まで、そのセッションに含まれる複数のフローを蓄積することによりパケットの送信を遅延させる。
The
具体的には、遅延部１４３では、まず、通信のセッション毎に各フローのパケットのタイムスタンプ１７１が検査され、各フローのパケットのタイムスタンプの値が記憶される。このとき、遅延部１４３は、データクラス１７０の値によって、１つのセッションにおいていくつのフローが存在するか知ることができる。また、遅延部１４３では、各フローのパケットのタイムスタンプの値と遅延部１４３が保持する時刻情報との差分から、どのフローのパケットが最も遅く到着し、どのフローのパケットが最も早く到着しているかが判定される。
Specifically, the
そして、遅延部１４３では、１つのセッションに含まれる最も遅いフローが到着し、そのセッションに含まれる複数のフローを送信すべき時刻まで、既に遅延部１４３に到着している他のフローの各パケットが一時蓄積される。「フローを送信すべき時刻」は、最も遅いフローが到着したタイミング、または最も遅いフローが到着した後のタイミングで設定される。上記の例では、第１のストリームは、第２のストリームよりもＴ秒早く中継端末１４０に到着するので、第１のストリームのパケットは、遅延部１４３でＴ秒又はＴ秒以上一時蓄積されることになる。
Then, in the
ところで、１つのセッションに含まれる最も遅いフローが到着するまでに既に到着した各パケットは、すべてが同時に遅延部１４３に到着するわけではない。すなわち、１つのセッションに含まれる各パケットが遅延部１４３に一時蓄積される時間は、パケット毎に異なりうる。したがって、遅延部１４３では、１つのセッションに含まれるパケット単位で、タイムスタンプや遅延部１４３への到着時刻などの情報を管理して、これらを送信すべき時刻を特定する必要がある。以下、この動作について説明する。
By the way, all the packets that have already arrived by the arrival of the latest flow included in one session do not all arrive at the
上記のように、遅延部１４３の記憶部１４４は、パケット単位で、タイムスタンプが刻印されたパケットそのものを示す情報と、パケットの遅延部１４３への到着時刻と、そのパケットが属するセッションのパケットを送信すべき時刻とを対応付けて格納する。
As described above, the
図３は、記憶部１４４がパケット毎に管理するデータの構造を示す図である。
FIG. 3 is a diagram illustrating a data structure managed by the
図３において、パケット１８０は、パケットそのものを示す情報であり、パケットが送信端末１００から送信された時刻を記述するタイムスタンプ欄が含まれている。到着時刻記憶領域１８２は、パケットの到着時刻を記録する領域である。送信時刻記憶領域１８４は、そのパケットのセッションに含まれる複数のフローのパケットを送信すべき時刻を記録する領域である。送信時刻記憶領域１８４への時刻の記録方法については、後に詳細に説明する。パケット１８０と、到着時刻記憶領域１８２と、送信時刻記憶領域１８４とは、リスト構造で結合されて管理されることで互いに関連付けて記録される。
In FIG. 3, a
遅延部１４３は、通信のセッションの各フローのパケットを受信すると、すべてのパケットについて、到着時刻記憶領域１８２にパケットの到着時刻を記録する。また、遅延部１４３は、パケットを受信する毎に、遅延部１４３が保持する最大フロー数管理表を更新する。
When receiving a packet of each flow of the communication session, the
図４は、最大フロー数管理表のデータ構造を示す図である。 FIG. 4 is a diagram illustrating a data structure of the maximum flow number management table.
図４において、通信のセッション欄１９０には、識別部１４２によりセッション毎に割り当てられた識別子が記述される。最大フロー数欄１９２には、通信のセッション欄１９０に記述されたセッションに対応するフローの数が記述される。また、最大フロー数欄１９２に記述されるフロー数は、例えば、階層符号化マルチキャスト通信における流量制御が行われる場合には、更新されうる。
In FIG. 4, an identifier assigned for each session by the
遅延部１４３では、パケットを受信する毎に、ヘッダ１６０中のデータクラス１７０の最大値を検査することにより、そのパケットを含むセッションに対応する最大フロー数欄１９２が更新される。データクラス１７０の最大値と最大フロー数欄１９２に記述された数とが同一になることは、セッションに含まれるすべてのパケットが受信されたことを意味する。すなわち、遅延部１４３の更新により、送信時刻記憶領域１８４に記録される時刻の更新が完了し、そのセッションに含まれるすべてのパケットを送信すべき時刻を確定することができる。以下、パケットを送信すべき時刻の確定処理について説明する。
Each time the
遅延部１４３では、受信したパケット１８０の中のタイムスタンプ欄に記述されている時刻と到着時刻記憶領域１８２に記述されているパケットの到着時刻との差分時間が計算され、遅延部１４３が保持する差分時間管理表が更新される。
The
図５は、差分時間管理表のデータ構造を示す図である。 FIG. 5 is a diagram illustrating a data structure of the differential time management table.
図５において、通信のセッション欄１９４には、識別部１４２によりセッション毎に割り当てられた識別子が記述される。フロー欄１９６には、セッションに含まれる各フローのナンバーがセッション毎に記述される。通信のセッション欄１９４とフロー欄１９６との組み合わせは、キー項目であり、上記最大フロー数管理表の最大フロー数欄１９２の更新にあわせて、これらのキー項目が設定される。例えば、図４の最大フロー数欄１９２が更新されて“２”となった場合、図５の通信のセッション欄１９４及びフロー欄１９６には、それぞれ２行の領域が確保される。差分時間欄１９８には、パケット１８０の中のタイムスタンプ欄に記述されている時刻と到着時刻記憶領域１８２に記述されているパケットの到着時刻との差分時間が記述される。
In FIG. 5, an identifier assigned to each session by the
なお、差分時間欄１９８に記述される差分時間は、上記のように、パケット１８０の中のタイムスタンプ欄に記述されている時刻と到着時刻記憶領域１８２に記述されているパケットの到着時刻との差分時間により、単純に毎回更新してもよいし、例えば、過去Ｎ回分の差分時間を加重平均したものにより更新してもよい。
Note that the difference time described in the
遅延部１４３は、受信したパケットに対応する差分時間管理表を更新すると同時に、既に受信しているパケットを一時蓄積して遅延させるべき時間、つまり、パケットを送信すべき時刻を決定する。
The
具体的には、まず、遅延部１４３は、通信のセッションのフロー毎に、差分時間欄１９８に記述されている時間を比較して、そのセッションの中で最も遅く到着しているフローを特定する。次に、遅延部１４３は、セッションの中で最も遅く到着しているフローの差分時間欄１９８に記述されている値をＤＭＡＸとして、そのセッションの他のフローの差分時間欄１９８に記述されている値（Ｄｉ）のそれぞれについて、ＤＭＡＸ−Ｄｉを計算する。ＤＭＡＸ−Ｄｉで表される値は、そのパケットを一時蓄積して遅延させるべき時間を示している。そして、遅延部１４３は、ＤＭＡＸ−Ｄｉの値から、パケットを送信すべき時刻を決定して、送信時刻記憶領域１８４に記述する。具体的には、遅延部１４３は、各パケットについて、到着時刻記憶領域１８２に記述されたパケットの到着時刻とＤＭＡＸ−Ｄｉで示される値とを加算した時刻を、パケットを送信すべき時刻として送信時刻記憶領域１８４に記述する。また、パケットを一時蓄積して遅延させる時間は、ＤＭＡＸ−Ｄｉに限定されない。例えば、パケットを一時蓄積して遅延させる時間は、ＤＭＡＸ−Ｄｉに任意の係数α（αは１．０以上の数）をかけ、α（ＤＭＡＸ−Ｄｉ）としても良い。このように、１つのセッションに含まれる最後のパケットが到着したタイミング、又は前記最後のパケットが到着してから所定の時間が経過したタイミングを、パケットを送信すべき時刻として送信時刻記憶領域１８４に記述することができる。
Specifically, first, the
例えば、図５において、セッションＢに含まれるフローが、フローＢ１〜フローＢ３であるとする。このとき、ＤＭＡＸ＝３０５なので、フローＢ２を一時蓄積する時間は、３０５−２１５＝９０であり、フローＢ３を一時蓄積すべき時間は、３０５−１２５＝１８０である。 For example, in FIG. 5, it is assumed that the flows included in the session B are the flow B1 to the flow B3. At this time, since D MAX = 305, the time for temporarily storing the flow B2 is 305-215 = 90, and the time for temporarily storing the flow B3 is 305-125 = 180.
遅延部１４３では、１つのセッションに含まれるすべてのパケットが受信されるまで上記一連の動作が繰り返されることにより、そのセッションに含まれるすべてのパケットを同時に送信すべき時刻が決定され、各パケットの送信時刻記憶領域１８４に記述される。
The
また、遅延部１４３は、１つのセッションに含まれるすべてのパケットを受信すると、図３に示すすべてのデータ（パケット１８０、到着時刻記憶領域１８２に記述されたパケットの到着時刻、及び送信時刻記憶領域１８４に記述されたパケットを送信すべき時刻）を、遅延部１４３の内部に保持する送信待ちキュー１４５に格納する。
When the
補正部１４６では、送信待ちキュー１４５に格納されたデータに基づいて、１つのセッションに含まれる各パケットについて、これらのパケットが遅延部１４３で一時蓄積された時間の分だけタイムスタンプが補正される。具体的には、補正部１４６は、各パケットについて、各パケットを送信すべき時刻から各パケットの到着時刻を減算して、各パケットが遅延部１４３に一時蓄積された時間を計算し、この一時蓄積された時間の分だけ、各パケット中のタイムスタンプ欄に記述された時刻を足し上げる。上記の例では、第１のストリームのパケットに刻印されたタイムスタンプに記述された時刻Ｔ０に、第１のストリームが蓄積された時間であるＴだけ足しあげて、Ｔ０＋Ｔに補正する。
Based on the data stored in
なお、中継装置１４０の上流（又は下流）の中継装置における一時蓄積処理により、タイムスタンプ欄に記述された時間にこれらの中継装置での一時蓄積時間が加算（又は減算）されている場合には、これらの一時蓄積時間を相殺するようなタイムスタンプの補正を行うことも可能である。例えば、タイムスタンプの補正は、第１のストリームのパケットに刻印されたタイムスタンプに記述された時刻Ｔ０に、第１のストリームが蓄積された時間であるＴにβを乗じた時間を足しあげて、Ｔ０＋βＴ（βは正の任意の係数）に補正することもできる。
When the temporary storage process in the relay device upstream (or downstream) of the
ここで、補正部１４６は、タイムスタンプを補正するために、タイムスタンプの刻印粒度を知る必要がある。タイムスタンプの刻印粒度は、補正部１４６が予め知っていてもよいし、中継装置１４０が推定してもよい。中継装置１４０におけるタイムスタンプの刻印粒度の推定は、例えば、以下のようにして実現されうる。
Here, the
すなわち、中継装置１４０で、通信のセッションのそれぞれのフロー毎にフローキューと呼ばれるキューを設ける。識別部１４２では、受信したパケットをそれぞれのフローキューに格納する。このとき、フローキューに格納された前後のパケットの通番１７２を比較し、通番１７２に隔たりがない場合、この２つのパケットの到達時刻記憶領域に記録されている時間の差を計算してＤｇａｐとし、この２つのパケットのタイムスタンプの差を計算してＤｔｓとする。ＤｇａｐとＤｔｓとの比を検査することにより、タイムスタンプの刻印粒度を推定することができる。すなわち、同一経路で受信した連番のパケットの到着時刻の差Ｄｇａｐとタイムスタンプの値の間隔Ｄｔｓとの比（Ｄｇａｐ／Ｄｔｓ）を求め、この比の平均値やばらつきから、送信端末におけるタイムスタンプの刻印粒度の信頼性を確認する。このようにして、送信端末から時々刻々と送信されるストリーミングの送信間隔、つまり、これらのストリーミングのパケットに刻印されたタイムスタンプの刻印粒度を推定することができる。なお、この推定方式の、Ｄｇａｐ及びＤｔｓの算出には、例えば、これらの過去Ｍ回分の平均を用いるようにしてもよい。
That is, the
補正部１４６がタイムスタンプの刻印粒度を知るためには、送信端末１００からの制御パケットを受信する必要があるので、中継装置１４０がタイムスタンプの刻印粒度を推定することにより、タイムスタンプからの刻印粒度を知らせるための制御パケットを削減することができる。
In order for the
送信部１４８では、遅延部１４３の送信待ちキュー１４５に格納されたすべてのデータが走査され、受信端末１５０に対してパケットが送信される。このとき、送信部１４８では、上記パケットを送信すべき時刻を含む情報と現在時刻とを比較して、これらの時刻が一致した場合、またはパケットを送信すべき時刻が現在時刻よりも経過している場合に、受信端末１５０に対してパケットを送信する。
The
ここで、送信待ちキューに格納されたすべてのパケットを送信すべき時刻は、厳密には、上述したタイムスタンプの刻印粒度により異なりうる。送信部１４８によるこれらのパケットの具体的な送信処理は、例えば、マルチタスクをサポートするＯＳ上の１つのタスクを用いて、以下のように実現可能である。
Here, strictly speaking, the time at which all the packets stored in the transmission waiting queue should be transmitted may differ depending on the time stamping granularity described above. The specific transmission process of these packets by the
まず、送信部１４８は、遅延部１４３の送信待ちキュー１４５に格納されたすべてのデータについて走査し、送信時刻記憶領域１８４に記憶されている領域が最も近いもの（最も近い未来に送信すべきと記憶されているもの）を選択する。そして、このパケットをＰＮＥＸＴ、ＰＮＥＸＴの送信時刻をＴＮＥＸＴ、現在時刻をＴＮＯＷとして、ＴＮＥＸＴ−ＴＮＯＷ≧０を満たした後に、送信部１４８は、ＰＮＥＸＴの送信処理を行う。次いで、送信部１４８は、送信時刻記憶領域１８４に記憶されている領域がＰＮＥＸＴの次に近いパケットについて、同様の送信処理を行う。このような処理を繰り返し行うことで、全ての送信待ちキュー１４５に格納されたすべてのデータが順次送信され、送信部１４８の処理を連続的に無矛盾に実行可能となる。
First, the
送信部１４８から送信された各パケットは、同期処理が実現されているのみならず、遅延部１４３で一時蓄積された時間の分だけタイムスタンプが補正されている。したがって、タイムスタンプを用いて送信端末１００と受信端末１５０との間の往復時間を計測する場合、遅延部１４３での一時蓄積時間を除いた時間が計測される。
Each packet transmitted from the
受信端末１５０では、中継装置１４０の送信部１４８からの１つのセッションに含まれる複数のフローのパケットが受信され、再生される。
The receiving
以上説明したように、本実施の形態によれば、遅延部１４３が、同期して送信すべき１つのセッションに含まれる複数のパケットを、送信すべき時刻まで一時蓄積してパケット遅延させ、補正部１４６が、一時蓄積した各パケットについて、一時蓄積された時間の分だけ、各パケット中のタイムスタンプ欄を補正するようにした。これにより、送信端末からの関連する複数のストリームのパケットが異なる経路で受信端末に伝送される場合であっても、受信端末の無駄な記憶領域を省略するとともに、複数のストリームを同期させて受信端末に伝送することができる。
As described above, according to the present embodiment, the
また、送信端末と受信端末との間で階層符号化を用いたストリームの伝送が行われ、その伝送で帯域推定が行われている場合であっても、不必要に低い帯域を推定することを防止することができ、受信端末で複数のストリームから高品質なデータを再生することができる。 In addition, even when a stream transmission using hierarchical coding is performed between a transmission terminal and a reception terminal and band estimation is performed in the transmission, it is necessary to estimate an unnecessarily low band. Therefore, it is possible to reproduce high quality data from a plurality of streams at the receiving terminal.
すなわち、識別部１４２、遅延部１４３、補正部１４６、及び送信部１４８が、上記のような処理を行うことにより、中継装置１４０における同期処理を実現することができる。このとき、同期される各パケット中のタイムスタンプが、遅延部１４３で一時蓄積された時間の分だけ補正されているので、送信端末１００と受信端末１５０との間でタイムスタンプを用いてパケットの往復時間の計測を行っても、不必要にパケットの往復時間を多く計測してしまうことがない。結果として、送信端末１００と受信端末１５０との間で、このパケットの往復時間を用いた帯域推定値を利用した流量制御が行われている場合でも、送信速度が不必要に低下することがなくなる。
That is, the
また、補正部１４６のタイムスタンプ補正においては、タイムスタンプの刻印粒度をパケットの送信間隔から推定した結果を元にタイムスタンプを補正する。また、送信部１４８では、このタイムスタンプを元に再度送信を行うので、例外的にジッタを伴いながら到着時刻がずれて到着するパケットが存在する場合でも、送信端末が刻印したタイムスタンプの時刻に従って正確に再送信することができる。
In the time stamp correction by the
（実施の形態２）
実施の形態２は、階層符号化とマルチキャスト通信とを組み合わせて利用する伝送方式に本発明を適用した例である。本実施の形態では、そのような伝送方式の中でも、特に、後述するＳＩＣＣ（Sender Initiated Congestion Control）と呼ばれる伝送方式に対して本発明を適用した場合について説明する。すなわち、本実施の形態は、実施の形態１の中継装置を、ＳＩＣＣ伝送方式の中継装置に適用した例である。そこで、まず本実施の形態の前提となるＳＩＣＣについて説明した後に本発明の適用例を説明することにする。
(Embodiment 2)
The second embodiment is an example in which the present invention is applied to a transmission scheme that uses a combination of hierarchical coding and multicast communication. In the present embodiment, a case will be described in which the present invention is applied to a transmission method called SICC (Sender Initiated Congestion Control) described later, among such transmission methods. That is, the present embodiment is an example in which the relay device of the first embodiment is applied to a relay device of the SICC transmission method. Therefore, an application example of the present invention will be described after describing SICC which is a premise of the present embodiment.
階層符号化とは、例えば、映像信号や音声信号などから、基本階層と基本階層以外の１つ以上の差分階層とからなる階層化されたデータを作成することをいう。作成された階層化データは、複数の受信端末に対して送信されるが、各受信端末は、基本階層のデータに加え、自端末の性能や通信環境、希望する受信データの品質などに応じた差分階層のデータを受信する。一般的に、受信端末は、受信する差分階層のデータを増やすことで、より高品質の映像を再生することができる。 Hierarchical coding refers to, for example, creating hierarchized data consisting of a base layer and one or more difference layers other than the base layer from video signals, audio signals, and the like. The created layered data is transmitted to multiple receiving terminals. Each receiving terminal, in addition to the basic layer data, depends on its own terminal performance and communication environment, desired received data quality, etc. Receive the data of the difference hierarchy. Generally, the receiving terminal can reproduce higher quality video by increasing the data of the difference layer to be received.
このような階層符号化とマルチキャスト通信とを組み合わせて利用する伝送方式としては、例えば、文献（L. Vicisano, L. Rizzo, J. Crowcroft, “TCP-like congestion control for layered multicast data transfer”, Proc. IEEE ONFOCOM'98, Mar. 1998.）に示される方式がある。この方式による送信端末は、異なる符号化レートでエンコードされた複数のストリームを、それぞれ複数の異なるマルチキャストグループを用いて送信し、受信端末は、複数のストリームを受信し、同期して再生する。 As a transmission method using a combination of such hierarchical coding and multicast communication, for example, literature (L. Vicisano, L. Rizzo, J. Crowcroft, “TCP-like congestion control for layered multicast data transfer”, Proc IEEE ONFOCOM '98, Mar. 1998.) A transmitting terminal according to this method transmits a plurality of streams encoded at different encoding rates using a plurality of different multicast groups, and a receiving terminal receives the plurality of streams and reproduces them in synchronization.
このとき、それぞれのマルチキャストグループの配送経路が異なる場合や中継装置で特定のマルチキャストグループの優先制御が行われている場合には、複数のストリームが受信端末に到着するタイミングがずれることがある。その場合、中継装置又は受信端末で同期処理を行う必要がある。 At this time, when the delivery routes of the respective multicast groups are different, or when priority control of a specific multicast group is performed in the relay device, the timing at which a plurality of streams arrive at the receiving terminal may be shifted. In that case, it is necessary to perform synchronization processing at the relay device or the receiving terminal.
複数の端末に対して、複数のストリームを流量制御しながら伝送する方式として、文献（村本衛一、米田孝弘、鈴木史章、鈴木良宏、中村敦司，“送信者起動マルチキャストにおける輻輳制御方法の提案”，インターネットカンファレンス ２００３論文集 ｐ５〜ｐ１０，２００３年１０月）で知られているＳＩＣＣ（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）を利用する。 As a method for transmitting a plurality of streams to a plurality of terminals while controlling the flow rate, literature (Eiichi Muramoto, Takahiro Yoneda, Fumiaki Suzuki, Yoshihiro Suzuki, Junji Nakamura, “Congestion control method in sender-initiated multicast” There is a SICC (Sender Initiated Congestion Control) known from “Proposal”, Internet Conference 2003 Proceedings, p5 to p10, October 2003). In SICC, literature (Y. Imai, M. Shin and Y. Kim, “XCAST6: eXplict Multicast on IPv6”, IEEE / IPSJ SAINT2003 Workshop4, IPv6 and Applications, Orland, Jan. XCAST known in 2003) is used, and TFRC (TCP friendly rate control) defined by RFC3448 described above is used as a band estimation method.
まず、ＸＣＡＳＴについて説明する。ＸＣＡＳＴとは、送信端末が、グループに属する全受信端末の宛先アドレスを、パケット内のオプションヘッダ又はペイロードに格納することにより、送信端末がパケットを配信する全受信端末を明示的に指定する明示的マルチキャスト方式の代表的な方式である。 First, XCAST will be described. XCAST is an explicit specification in which the transmitting terminal explicitly specifies all the receiving terminals to which the transmitting terminal distributes the packet by storing the destination addresses of all the receiving terminals belonging to the group in the option header or payload in the packet. This is a typical multicast method.
ＸＣＡＳＴでは、中継装置（ルータなど）がＸＣＡＳＴに対応していない場合、パケットは、未配送の１台の受信端末に届けられる。受信端末は、パケット中に未配送の受信端末が残っている場合、パケットをその未配送の受信端末に対して送信し直す。受信端末がこの動作を繰り返すことで、すべての受信端末にパケットが配送される。 In XCAST, when a relay device (such as a router) does not support XCAST, the packet is delivered to one undelivered receiving terminal. When there is an undelivered receiving terminal in the packet, the receiving terminal retransmits the packet to the undelivered receiving terminal. When the receiving terminal repeats this operation, the packet is delivered to all the receiving terminals.
図６は、ＸＣＡＳＴを説明するための通信ネットワークの構成の一例を示す図である。 FIG. 6 is a diagram illustrating an example of a configuration of a communication network for explaining XCAST.
図６の通信システムは、送信端末２００、３台の中継装置２１０〜２１４、及び５台の受信端末２２０〜２２８を備えて構成される。なお、中継装置の台数及び受信端末の台数は特に限定されず、これらを接続する方法も任意である。
The communication system of FIG. 6 includes a
送信端末２００は、入力した原データを階層符号化して階層化データを作成し、作成した各階層化データに対して送信先アドレスなどの情報を付与したパケットを生成する。また、送信端末２００は、生成した各パケットを通信ネットワーク上に送信する。中継装置２１０〜２１４は、パケットに含まれる送信先アドレス情報に基づいてルーティングを行う。受信端末２２０〜２２８は、送信端末２００が配信したパケットを受信する。また、受信端末２２０〜２２８は、受信したデータをデコードし、基本階層のデータと差分階層のデータとを合成する。
The
送信端末２００が生成して送信するパケットについて、図７を用いて説明する。
A packet generated and transmitted by the
図７（Ａ）〜図７（Ｅ）は、ＸＣＡＳＴ方式のパケットの一例を示す図である。なお、図７（Ａ）〜図７（Ｅ）は、パケットとしてＸＣＡＳＴ方式によるＩＰｖ６パケットを用いた場合の例である。 FIG. 7A to FIG. 7E are diagrams illustrating an example of an XCAST packet. FIGS. 7A to 7E show an example in which an IPv6 packet based on the XCAST method is used as a packet.
図７（Ａ）〜図７（Ｅ）において、ＩＰｖ６パケット２３０は、ユニキャストヘッダ２３２、ルーティングヘッダ２３４、及び映像データなどの送信したいデータ本体であるペイロード２３６を有する。
7A to 7E, an
ユニキャストヘッダ２３２は、宛先アドレス及び送信元アドレスをそれぞれ１つずつ記述する領域である。例えば、図７（Ａ）では、宛先アドレスとして受信端末（Ｒ１）２２０のアドレスが（dst=R1）、送信元アドレスとして送信端末（Ｓ）２００のアドレスがそれぞれ記述されている。ユニキャストヘッダ２３２に記述される宛先アドレスは、ルーティングヘッダ２３４に記述される未配送のアドレスの中の最上位のアドレスである。このように、ユニキャストヘッダ２３２に受信端末のアドレスを１つ記述しておくことで、経路上の中継装置がＸＣＡＳＴに未対応の場合でも、この中継装置は、ＸＣＡＳＴ方式のＩＰｖ６パケット２３０をユニキャスト方式のパケットとして認識し、ユニキャストヘッダ２３２に記述された宛先アドレスが指し示す受信端末へ向けてパケットを転送することができる。
The
ルーティングヘッダ２３４は、送信先となる受信端末のアドレスリスト、及びアドレスリストに記述された各受信端末に対してパケットを配信済みか未配送かを示すフラグを記述する領域である。例えば、図７（Ａ）では、受信端末（Ｒ１）２２０、受信ノード（Ｒ３）２２４、及び受信ノード（Ｒ４）２２６が記述されている。アドレスリストに記述される宛先アドレスには順序があり、図７（Ａ）では、左側に位置するＲ１が最上位、右側に位置するＲ４が最下位である。前述の通り、ルーティングヘッダ２３４の未配送かつ最上位の宛先アドレスが、ユニキャストヘッダ２３２に記述される。
The
図６の通信システムにおいて、送信端末２００が、受信端末（Ｒ１）２２０、受信端末（Ｒ３）２２４、及び受信端末（Ｒ４）２２６に図７（Ａ）のパケットを送信する場合における各中継装置２１０〜２１４の動作を説明する。ここでは、中継装置２１０〜２１４がＸＣＡＳＴに対応している場合について説明する。
In the communication system of FIG. 6, each
送信端末２００から中継装置２１０に、図７（Ａ）のパケットが送信されると、中継装置２１０は、受信したパケットを分割・複製する。具体的には、図７（Ａ）のパケットは、受信端末（Ｒ３）２２４及び受信端末（Ｒ４）２２６の宛先アドレスを配送済みにした受信端末（Ｒ１）２２０宛てのパケット（図７（Ｂ）参照）と、受信端末（Ｒ１）２２０の宛先アドレスを配送済みにし、ユニキャストヘッダ２３２に受信端末（Ｒ３）２２４の宛先アドレスが記述された受信端末（Ｒ３）２２４及び受信端末（Ｒ４）２２６宛てのパケット（図７（Ｃ）参照）とに分割・複製される。図７（Ｂ）のパケットは、受信端末（Ｒ１）２２０に転送され、図７（Ｃ）のパケットは、中継装置２１２に転送される。
When the packet in FIG. 7A is transmitted from the
中継装置２１２は、図７（Ｃ）のパケットを、受信端末（Ｒ４）２２６の宛先アドレスを配送済みにした受信端末（Ｒ３）２２４宛てのパケット（図７（Ｄ）参照）と、受信端末（Ｒ３）２２４の宛先アドレスを配送済みにし、ユニキャストヘッダ２３２に受信端末（Ｒ４）２２６の宛先アドレスが記述された受信端末（Ｒ４）２２６宛てのパケット（図７（Ｅ）参照）とに分割・複製する。図７（Ｄ）のパケットは、受信端末（Ｒ３）２２４に転送される。また、図７（Ｅ）のパケットは、中継装置２１４に転送され、受信端末（Ｒ４）２２６にさらに転送される。
The
このように、各中継装置は、通信システム内の各中継装置がＸＣＡＳＴに対応している場合、受信したパケット内のアドレスリストを参照して、パケットの分割・複製、及び転送を行いながら、各受信端末に対してパケットを効率的に配送する。 As described above, when each relay device in the communication system is compatible with XCAST, each relay device refers to the address list in the received packet while performing packet division / duplication and transfer. Efficiently deliver packets to receiving terminals.
次に、中継装置２１０〜２１４のすべてがＸＣＡＳＴに未対応の場合における中継装置及び受信端末の動作を説明する。ここでも、図６の通信システムにおいて、送信端末２００が、受信端末（Ｒ１）２２０、受信端末（Ｒ３）２２４、及び受信端末（Ｒ４）２２６に図７（Ａ）のパケットを送信する場合における各中継装置２１０〜２１４の動作を説明する。
Next, operations of the relay apparatus and the receiving terminal when all of the
送信端末２００から中継装置２１０に、図７（Ａ）のパケットが送信されると、中継装置２１０は、図７（Ａ）のパケットを、ユニキャストヘッダ２３２に記述された宛先である受信端末（Ｒ１）２２０に転送する。
When the packet in FIG. 7A is transmitted from the
受信端末（Ｒ１）２２０は、図７（Ａ）のパケットを受信すると、アドレスリストに記述されているアドレスを参照して新たなパケット図７（Ｃ）を生成する。図７（Ｃ）のパケットは、受信端末（Ｒ１）２２０の宛先アドレスを配送済みにし、ユニキャストヘッダ２３２に受信端末（Ｒ３）２２４の宛先アドレスが記述された中継装置２１０宛てのパケットである。このパケットは、中継装置２１０及び中継装置２１２を経由して、受信端末（Ｒ３）２２４に転送される。
Receiving terminal (R1) 220, when receiving the packet of FIG. 7A, refers to the address described in the address list and generates a new packet FIG. 7C. The packet in FIG. 7C is a packet addressed to the
受信端末（Ｒ３）２２４は、図７（Ｃ）のパケットを受信すると、アドレスリストに記述されているアドレスを参照して新たなパケット図７（Ｅ）を生成する。図７（Ｅ）のパケットは、受信端末（Ｒ３）２２４の宛先アドレスを配送済みにし、ユニキャストヘッダ２３２に受信端末（Ｒ４）２２６の宛先アドレスが記述された中継装置２１２宛てのパケットである。このパケットは、中継装置２１２及び中継装置２１４を経由して、受信端末（Ｒ４）２２６に転送される。
When the receiving terminal (R3) 224 receives the packet of FIG. 7C, the receiving terminal (R3) 224 refers to the address described in the address list and generates a new packet FIG. 7E. The packet in FIG. 7E is a packet addressed to the
このように、中継装置２１０〜２１４がＸＣＡＳＴに未対応の場合、各中継装置は、パケットの分割・複製を行わず、ユニキャストヘッダ２３２に記述された宛先アドレスの受信端末に向けて転送する。ユニキャストヘッダ２３２に記述される宛先アドレスは、ルーティングヘッダ２３４に記述されたアドレスリストの順序に従う。したがって、送信されたパケットの受信端末間の配送順序は、送信端末２００がルーティングヘッダ２３４に記述したアドレスリストの順序に依存する。
As described above, when the
以上説明したように、ＸＣＡＳＴにおいては、通信システム内の中継装置がＸＣＡＳＴに対応している場合のみならず、通信システム内にＸＣＡＳＴに未対応の中継装置がある場合であっても、パケットの配送を実現することができる。 As described above, in XCAST, not only when a relay device in the communication system supports XCAST, but also when there is a relay device that does not support XCAST in the communication system, packet delivery Can be realized.
上記のように、ＳＩＣＣは、ＸＣＡＳＴにおいて、ＴＦＲＣを利用した流量制御を実現する方式である。以下、ＴＦＲＣを利用した流量制御について説明する。 As described above, SICC is a method for realizing flow rate control using TFRC in XCAST. Hereinafter, flow control using TFRC will be described.
ＳＩＣＣにおいて、送信端末は、ＸＣＡＳＴパケットを送信する受信端末を、各受信端末の性能や通信環境に基づいた複数のクラスに分類し、分類されたクラス毎に異なるレートのＸＣＡＳＴパケットを送信する。クラスの分類（送信端末から受信端末への送信可能レートの推定）は、ＴＦＲＣを利用して各受信端末について行われ、各受信端末のクラスは、逐次更新されうる。また、それぞれのＸＣＡＳＴパケットは、分類されたクラスに対応する受信者のアドレスに配送される。 In SICC, a transmitting terminal classifies receiving terminals that transmit XCAST packets into a plurality of classes based on the performance and communication environment of each receiving terminal, and transmits XCAST packets at different rates for each classified class. Class classification (estimation of the transmittable rate from the transmitting terminal to the receiving terminal) is performed for each receiving terminal using TFRC, and the class of each receiving terminal can be updated sequentially. Each XCAST packet is delivered to the address of the recipient corresponding to the classified class.
このように、分類されたＳＩＣＣのクラス毎に、階層符号化でエンコードされた複数のストリームを送信することにより、利用可能な帯域が大きい受信端末（群）には、高詳細な動画を送信し、利用可能な帯域が小さい受信端末（群）には、粗い動画を送信するといった適応流量制御が可能となる。 In this way, by transmitting a plurality of streams encoded by hierarchical encoding for each classified SICC class, a high-detail video is transmitted to a receiving terminal (group) having a large available bandwidth. Thus, adaptive flow rate control such as transmitting a coarse moving image to a receiving terminal (group) having a small available bandwidth becomes possible.
次に、図６の通信システムに本発明の中継装置の同期方式（一時蓄積及びタイムスタンプの補正）を適用した動作について説明する。図６の例では、中継装置２１０〜２１４が、同期して送信すべき階層符号化された複数のストリームを一時蓄積するとともに、一時蓄積された各ストリームのパケットに記述されたタイムスタンプの値を補正する。
Next, an operation in which the synchronization method (temporary storage and time stamp correction) of the relay apparatus of the present invention is applied to the communication system of FIG. 6 will be described. In the example of FIG. 6, the
図６において、中継装置２１０〜２１４は、それぞれ図１の中継装置１４０と同一の機能を有している。すなわち、中継装置２１０〜２１４は、１つのセッションにおいて同期されるべき複数のストリームを識別する。また、中継装置２１０〜２１４は、これらのストリームがすべて到着するまで、先に到着したストリームに対して一時蓄積遅延処理を行う。さらに、中継装置２１０〜２１４は、一時蓄積遅延処理を行った各ストリームに対して、一時蓄積した時間だけタイムスタンプの値を補正する。
In FIG. 6, the
例えば、中継装置２１４が送信端末２００から時刻Ｔａに送信された上位階層のストリーム及び下位階層のストリームを同期して受信端末２２８に送信する場合について考える。ここで、上位階層のストリームが、中継装置２１０→中継装置２１２→受信端末２２２→中継装置２１２→中継装置２１４の順に伝送され時刻Ｔｂに中継装置２１４に到着し、下位階層のストリームが、中継装置２１０→受信端末２２０→中継装置２１０→中継装置２１２→受信端末２２２→中継装置２１２→中継装置２１４の順に伝送され時刻Ｔｃに中継装置２１４に到着するものとする。また、上位階層のストリームは、下位階層のストリームよりもＴｄだけ早く中継装置２１４に到着するものとする（つまり、Ｔｃ−Ｔｂ＝Ｔｄ）。
For example, consider a case where the
中継装置２１４は、上位階層のストリームを受信すると、受信した上位階層のストリームは、後で到着する下位階層のストリームと同期させて受信端末２２８に送信すべきストリームであることを識別する。そして、中継装置２１４は、先に到着した上位階層のストリームを、下位階層のストリームが到着するまで一時蓄積する。この一時蓄積時間は、例えば、Ｔｄである。最後に、中継装置２１４は、上位階層のストリーム及び下位階層のストリームを同期させて、下位階層のストリームが到着したタイミング、又は下位階層のストリームが到着した後のタイミングで受信端末２２８に送信する。
When receiving the upper layer stream, the
このとき、中継装置２１４は、先に到着した上位階層のストリームのタイムスタンプに記述された値Ｔａを補正する。このタイムスタンプの補正は、具体的には、上位階層のストリームのタイムスタンプに記述された値Ｔａに、上位階層のストリームの中継装置２１４での一時蓄積時間を加算することにより行われる。例えば、一時蓄積時間がＴｄであれば、上位階層のストリームのタイムスタンプに記述される値は、ＴａからＴａ＋Ｔｄに補正される。
At this time, the
このように、ＳＩＣＣを用いた伝送方式においても、中継装置２１０〜２１４が上述した同期処理を行うことにより、ＲＴＴを不必要に大きく算出することなく、階層化された複数のストリームを同期させることができる。
As described above, also in the transmission method using SICC, the
ここで、本実施の形態の階層符号化されたストリームのＸＣＡＳＴパケットに記述されているヘッダ構造と、実施の形態１のストリームのパケットに記述されているヘッダ構造（図２）とを比較して説明する。 Here, the header structure described in the XCAST packet of the hierarchically encoded stream of the present embodiment is compared with the header structure described in the stream packet of the first embodiment (FIG. 2). explain.
図８は、本発明の実施の形態２の階層符号化されたストリームのＸＣＡＳＴパケットに記述されているヘッダ構造を示す図である。 FIG. 8 is a diagram illustrating a header structure described in the XCAST packet of the hierarchically coded stream according to the second embodiment of the present invention.
ヘッダ２５０は、ネットワークヘッダ部２５１、トランスポートヘッダ部２５２、ＲＴＰヘッダ２５３、及びペイロード２５４からなる。ネットワークヘッダ部２５１は、ＩＰｖ６ヘッダ２５５と、パケットがＸＣＡＳＴ対応パケットであることを示すＸＣＡＳＴ６ヘッダ２５６とを含む。また、トランスポートヘッダ部２５２は、ＳＩＣＣヘッダ２６０を含む。
The
ＳＩＣＣヘッダ２６０は、宛先ポート２６１、送信元ポート２６２、バージョン２６３、タイプ２６４、ヘッダ長２６５、シーケンス番号２６６、クラス２６７、タイムスタンプ２６８、ＲＴＴ通知欄２６９、フラグ２７０、予備領域２７１、通番２７２、ＡＤＵ通番２７３、パケット長２７４、パケット数２７５、及びパケット通番２７６を含む。
The
次に、図８のヘッダ構造と図２のヘッダ構造との対応関係を説明する。 Next, the correspondence between the header structure of FIG. 8 and the header structure of FIG. 2 will be described.
ネットワークヘッダ部２５１は、図２のネットワークヘッダ部１６１に相当する。具体的には、ＩＰｖ６ヘッダ２５５の中の宛先アドレス及び送信元アドレスは、宛先アドレス１６５及び送信元アドレス１６６に対応する。
The
トランスポートヘッダ部２５２のＳＩＣＣヘッダ２６０は、図２のトランスポートヘッダ部１６２に相当する。具体的には、宛先ポート２６１は、宛先ポート番号１６７に対応し、送信元ポート２６２は、送信元ポート番号１６８に対応する。バージョン２６３及びタイプ２６４の組み合わせは、データタイプ１６９に対応する。クラス２６７は、データタイプ１６９に対応する。タイムスタンプ２６８は、タイムスタンプ１７１に対応する。通番２７２は、通番１７２に対応する。
The
なお、ヘッダ長２６５、シーケンス番号２６６、ＲＴＴ通知欄２６９、フラグ２７０、予備領域２７１、ＡＤＵ通番２７３、パケット長２７４、パケット数２７５、及びパケット通番２７６は、送信端末と受信端末との間のＳＩＣＣ処理に特有のものであるか、または、本実施例には直接関係のないものであるため、その説明を省略する。
The
以上説明したように、階層符号化されたストリームのＸＣＡＳＴパケットのヘッダ構造２５０は、実施の形態１のヘッダ構造１６０に対応付けられる。したがって、本実施の形態の中継装置は、実施の形態１の中継装置と同様に、通信のセッションを識別でき、通信のセッション毎に含まれるフローを特定でき、同期処理を行うためにパケットを一時蓄積し、パケット往復時間に一時蓄積時間が加算されないようにタイムスタンプを補正することができる。
As described above, the
このように、本実施の形態によれば、ＳＩＣＣに代表される階層符号化とマルチキャスト通信とを組み合わせて利用する伝送方式においても、受信端末の無駄な記憶領域を省略し、かつ、不必要に低い帯域の推定を防止することができる。 As described above, according to this embodiment, even in a transmission scheme that uses a combination of hierarchical coding represented by SICC and multicast communication, a useless storage area of the receiving terminal is omitted and unnecessary. Low band estimation can be prevented.
すなわち、ＸＣＡＳＴパケットが受信端末で数珠繋ぎに転送される場合や上流の中継装置（ＸＣＡＳＴ対応）においてパケットの転送が行われる場合に、上流の受信端末又は中継装置が同期処理を行うことにより、下流の受信端末のバッファ領域を多量に消費することを防止することができる。また、送信端末と受信端末との間で流量制御が行われる場合に、その性質を不必要に低下させることなく複数のストリームを同期処理することができる。 That is, when the XCAST packet is transferred in a daisy chain at the receiving terminal or when the packet is transferred in the upstream relay device (XCAST compatible), the upstream receiving terminal or the relay device performs the synchronization process, so that the downstream It is possible to prevent a large amount of the buffer area of the receiving terminal from being consumed. Further, when flow control is performed between the transmission terminal and the reception terminal, a plurality of streams can be synchronously processed without unnecessarily degrading the property.
例えば、図９に示すように、ＳＩＣＣにおいて、階層符号化された上位階層のストリームおよび下位階層のストリームが載せられたＸＣＡＳＴパケットがそれぞれ異なる経路で受信端末２４２〜２４６を伝送される場合であっても、受信端末間に設けられた中継装置（図示せず）が、必要に応じて、先に到着したストリームを一時蓄積して同期させた上で２つのストリームを下流の受信端末に送信する。これにより、この下流の受信端末のバッファリング領域の消費を防止することができる。また、これらのストリームがさらに下流の受信端末に伝送される場合であっても、さらに下流の受信端末または中継装置によるバッファリング処理の負荷を低減することができる。
For example, as shown in FIG. 9, in SICC, XCAST packets carrying a layer-encoded upper layer stream and a lower layer stream are transmitted to receiving
さらに、同期処理を施した中継装置は、一時蓄積したストリームのパケットに記述されたタイムスタンプを、その一時蓄積時間の分だけ足し上げることにより補正する。すなわち、従来の中継装置において一時蓄積時間ＴＳ２を含めて計測されていたＲＴＴの計測値（ＴＳ３−ＴＳ１）は、この計測値から一時蓄積時間ＴＳ２を除いた理想的なＲＴＴの計測値（ＴＳ３−ＴＳ１−ＴＳ２）となるように補正される（図１０参照）。これにより、ＲＴＴを不必要に多く計測することなく、好適な帯域推定による流量制御を実現することができる。 Further, the relay apparatus that has performed the synchronization process corrects the time stamp described in the packet of the temporarily accumulated stream by adding the amount of the temporarily accumulated time. That is, the RTT measurement value (TS3-TS1) measured in the conventional relay apparatus including the temporary accumulation time TS2 is an ideal RTT measurement value (TS3-TS1) obtained by removing the temporary accumulation time TS2 from this measurement value. TS1-TS2) (see FIG. 10). As a result, it is possible to realize flow rate control by suitable band estimation without measuring an unnecessarily large number of RTTs.
以上まとめると、本実施の形態によれば、実施の形態１で説明したタイムスタンプの補正技術をＳＩＣＣ伝送方式に適用して、ＳＩＣＣ伝送方式の能力を向上させることができる。 In summary, according to the present embodiment, it is possible to improve the capability of the SICC transmission scheme by applying the time stamp correction technique described in the first embodiment to the SICC transmission scheme.
（実施の形態３）
本実施の形態は、実施の形態１又は実施の形態２において、下流の中継装置や受信端末から上流の中継装置や送信端末に対して、同期処理を依頼する場合である。このようなケースとしては、下流の中継装置や受信端末が、自端末が保持するバッファリング領域では同期処理が不可能となった場合などが考えられる。以下、図面を参照して詳細に説明する。
(Embodiment 3)
The present embodiment is a case where the synchronization processing is requested from the downstream relay device or receiving terminal to the upstream relay device or transmitting terminal in the first embodiment or the second embodiment. As such a case, a case where a downstream relay device or a receiving terminal becomes unable to perform synchronization processing in the buffering area held by the terminal itself can be considered. Hereinafter, it will be described in detail with reference to the drawings.
図１１は、本発明の実施の形態３に係る中継装置を含む通信システムの全体構成の一例を示すブロック図である。
FIG. 11 is a block diagram showing an example of the overall configuration of a communication system including a relay device according to
中継装置３００は、図１の中継装置１４０の構成において、バッファリング要求受付部３１０、及びバッファリング要求部３２０をさらに備える。中継装置３３０は、中継装置３００と同一の構成をとり、中継装置３００の下流に接続されている。中継装置３５０は、中継装置３００と同一の構成をとり、中継装置３００の上流に接続されている。ここでは、説明の簡略化のため、中継装置３３０については、バッファリング要求部３４０のみを図示し、中継装置３５０については、バッファリング要求受付部３６０のみを図示する。
The
なお、中継装置３００は、音声動画などのストリームを再生する受信端末の機能を有していてもよい。また、中継装置３３０は、中継装置３００の下流に接続されたバッファリング要求部を備える受信端末であってもよいし、中継装置３５０は、中継装置３００の上流に接続されたバッファリング要求部を備える送信端末であってもよい。
Note that the
バッファリング要求受付部３１０は、下流の中継装置又は受信端末から送信されたバッファリング要求パケットを受信して、バッファリング要求部３２０に出力する。バッファリング要求パケットには、同期処理を要求する端末の宛先情報、同期処理を行うセッションに含まれるパケットの数や長さ、各パケットを一時蓄積する時間などの情報が記述される。
The buffering
バッファリング要求部３２０は、バッファリング要求受付部３１０から入力されたバッファリング要求パケットを参照して、バッファリング要求パケットに記述された同期処理を中継装置３００で行うかどうかを判断する。バッファリング要求部３２０は、その判断の結果、同期処理を行うと判断した場合には、識別部１４２、遅延部１４３、及び補正部１４６に対して、自端末で同期処理を行う旨の指示を出す。一方、同期処理を行わないと判断した場合には、上流の中継装置又は送信端末に対してバッファリング要求パケットを送信する。なお、中継装置３００で同期処理を行うかどうかの判断方法は、後の動作説明で詳細に説明する。
The
以下、上述のように構成された通信システムの動作について詳細に説明する。ここでは、図１１に即して、中継装置３００が、中継装置３３０のバッファリング要求部３４０からのバッファリング要求パケットを受信し、同期処理を行うかどうかを判断して、同期処理を行わないと判断した場合に、中継装置３５０のバッファリング要求受付部３６０に対してバッファリング要求パケットを送信する例について説明する。
Hereinafter, the operation of the communication system configured as described above will be described in detail. Here, in accordance with FIG. 11, the
まず、中継装置３００のバッファリング要求受付部３１０は、中継装置３３０のバッファリング要求部３４０から送信されたバッファリング要求パケットを受信してバッファリング要求部３２０に出力する。
First, the buffering
バッファリング要求部３２０は、バッファリング要求受付部３１０から入力されたバッファリング要求パケットを参照して、バッファリング要求パケットに記述された同期処理を中継装置３００で行うかどうかを判断する。この判断は、中継装置３００でバッファリング可能な最大量と、バッファリング要求パケットに記述された同期処理を行うときに自端末で必要となるバッファリングの総量とを比較することにより行われる。以下、具体的に説明する。
The
バッファリング要求部３２０は、遅延部１４３が保持する送信待ちキューの長さを参照することにより、中継装置３００でバッファリング可能な最大量を逐次把握している。ここでは、中継装置３００でバッファリング可能な最大量をＢｍａｘとする。Ｂｍａｘは、静的に設定してもよいし、他のメモリ資源との競合状態などを加味して動的に設定してもよい。
The
バッファリング要求部３２０は、バッファリング要求受付部３１０からバッファリング要求パケットが入力されると、遅延部１４３が保持する差分時間管理表（図５）を参照し、一時蓄積を行うべきフローを特定する。そして、バッファリング要求部３２０は、特定したフローの一時蓄積処理に必要なメモリの量を、バッファリング要求部３２０が保持するバッファリング量管理表を用いて管理する。
When a buffering request packet is input from the buffering
図１２は、バッファリング量管理表のデータ構造を示す図である。 FIG. 12 is a diagram illustrating a data structure of the buffering amount management table.
図１２において、通信のセッション欄３７０には、識別部１４２によりセッション毎に割り当てられた識別子が記述される。フロー欄３７２には、セッションに含まれる各フローのナンバーがセッション毎に記述される。通信のセッション欄３７０とフロー欄３７２との組み合わせは、キー項目であり、図５の差分時間管理表の通信のセッション欄１９４とフロー欄１９６との組み合わせと同じものが記述される。受信間隔欄３７４には、それぞれのフローのパケットを受信する時間間隔が記述される。受信間隔欄３７４に記述される受信間隔は、新しいフローのパケットを受信する度に毎回更新してもよいし、例えば、過去Ｌ回のパケットの受信間隔を加重平均したものにより更新してもよい。レコード長３７６には、それぞれのフローのパケットの記憶領域の長さが記述される。それぞれのフローのパケット長が大きくなれば、それに従ってレコード長も大きい数値となる。レコード長３７６に記述される記憶領域は、例えば、過去Ｋ回のパケットの最大長を用いて更新することができる。
In FIG. 12, an identifier assigned for each session by the
バッファリング要求部３２０は、上記バッファリング量管理表と図５の差分時間管理表とを用いて、バッファリング要求パケットに記述された同期処理を行うときに自端末で必要となるバッファリングの総量を計算し、Ｂｎｅｅｄとする。
The
そして、バッファリング要求部３２０は、ＢｍａｘとＢｎｅｅｄとを比較する。そして、Ｂｍａｘ＞Ｂｎｅｅｄであれば、バッファリング要求部３２０は、識別部１４２、遅延部１４３、及び補正部１４６に対して、自端末で同期処理を行う旨の指示を出し、識別部１４２、遅延部１４３、及び補正部１４６は、実施の形態１で説明した同期処理を行う。一方、Ｂｍａｘ≦Ｂｎｅｅｄであれば、上流の中継装置３５０のバッファリング要求受付部３６０に対してバッファリング要求パケットを送信する。なお、Ｂｍａｘ≦Ｂｎｅｅｄであっても、例えば、階層符号化された複数のストリームの一部の階層のみを同期処理し、他の部分の同期処理を上流の中継装置３５０に依頼することもできる。
Then, the
中継装置３５０は、中継装置３００からのバッファリング要求パケットを受信すると、中継装置３００と同様に、同期処理を行うかどうかの判断を行う。そして、中継装置３５０は、同期処理を行うと判断した場合、実施の形態１で説明した同期処理を行う。一方、中継装置３５０は、同期処理を行わないと判断した場合、図示しないさらに上流の中継端末にバッファリング要求パケットを送信して同期処理を依頼する。
When the
ここで、上流の中継装置又は送信端末が複数ある場合には、これらの装置や端末の中から、バッファリング要求パケットの送信先を決定する必要が生じる。バッファリング要求パケットの宛先は、例えば、次のような方法で決定されうる。 Here, when there are a plurality of upstream relay apparatuses or transmission terminals, it is necessary to determine the transmission destination of the buffering request packet from these apparatuses and terminals. The destination of the buffering request packet can be determined by the following method, for example.
［宛先選択方式１］
通信のセッションに含まれるフローのパケットの送信元アドレスに対して送信する。
[Destination selection method 1]
It transmits to the source address of the packet of the flow included in the communication session.
［宛先選択方式２］
通信のセッションに含まれるフローのパケットのＸＣＡＳＴヘッダ中に記述されている宛先アドレスのリストから選択した上流の端末のＩＰアドレスに対して送信する。
[Destination selection method 2]
The packet is transmitted to the IP address of the upstream terminal selected from the list of destination addresses described in the XCAST header of the flow packet included in the communication session.
［宛先選択方式３］
まず、通信のセッションに含まれるフローのパケットのＸＣＡＳＴヘッダ中に記述されている宛先アドレスのリストから、自端末のアドレスより上流に記述されている宛先アドレスの部分リストを抽出する。そして、抽出した部分リストの先頭に送信元アドレス（送信端末のアドレス）を追加したリストを作成し、その並び順を反転させたアドレスリストが記述されたＸＣＡＳＴヘッダを持つ端末に対して送信する。
[Destination selection method 3]
First, a partial list of destination addresses described upstream from the address of the own terminal is extracted from a list of destination addresses described in the XCAST header of a flow packet included in the communication session. Then, a list in which the source address (the address of the transmission terminal) is added to the head of the extracted partial list is created, and the list is transmitted to the terminal having the XCAST header in which the address list in which the arrangement order is reversed is described.
次に、バッファリング要求パケットについて、図１３を用いて説明する。 Next, the buffering request packet will be described with reference to FIG.
図１３は、バッファリング要求パケットの形式の一例を示す図である。 FIG. 13 is a diagram illustrating an example of a format of a buffering request packet.
図１３のバッファリング要求パケットは、ＩＰｖ６ヘッダ３８１、ＸＣＡＳＴ６ヘッダ３８２、送信元アドレス３８３、宛先ポート番号３８４、送信元ポート番号３８５、データクラス３８６、及び蓄積時間３８７からなる。
The buffering request packet in FIG. 13 includes an
ＩＰｖ６ヘッダ３８１の宛先アドレスには、上記宛先選択方式１〜３のいずれかにより決定されたバッファリング要求パケットの宛先アドレスが記述される。ＸＣＡＳＴ６ヘッダ３８２には、上記宛先選択方式３で宛先を決定した場合、宛先選択方式３で作成したアドレスリストが記述される。上記宛先選択方式１〜２で宛先を決定した場合、ＸＣＡＳＴ６ヘッダ３８２には何も記述されず、又はＸＣＡＳＴ６ヘッダ３８２は付与されない。送信元アドレス３８３は、ＩＰｖ４やＩＰｖ６などのネットワーク上のアドレスである。宛先ポート番号３８４及び送信元ポート番号３８５は、例えば、ＵＤＰなどのトランスポートプロトコルの宛先ポート番号及び送信元ポート番号である。データクラス３８６には、そのデータフローを含むセッションが有しているデータフローの数が記述される。蓄積時間３８７は、差分時間管理表を元に算出したフローを蓄積させるべき時間が記述される。
In the destination address of the
なお、本実施の形態のバッファリング要求部３２０は、中継装置３００でバッファリング可能な最大量とバッファリング要求パケットに記述された同期処理を行うときに自端末で必要となるバッファリングの総量とを比較することにより同期処理を行うかどうかを判断したが、バッファリング要求部３２０の判断基準は、これに限定されない。例えば、中継装置３００において、同期処理が実現されたかどうかの判定などのタスクを消費するＣＰＵ資源が足りない場合にも、上流の中継装置に同期処理を依頼することが想定される。このように、バッファリング要求パケットを受けたバッファリング要求部の判断基準としては、種々の形態が考えられる。
Note that the
また、本実施の形態のバッファリング要求部３２０は、バッファリング要求パケットに記述された同期処理を中継装置３００で行うかどうかを判断したが、本発明はこれに限定されない。例えば、バッファリング要求受付部３１０が、バッファリング要求パケットに記述された同期処理を中継装置３００で行うかどうかを判断してもよい。
Moreover, although the buffering request |
また、バッファリング要求パケットが、通信システムの最上流である送信端末まで転送された場合、送信端末は、パケットの送信自体を明示的に遅らせるようにしてもよい。 Further, when the buffering request packet is transferred to the transmitting terminal which is the most upstream in the communication system, the transmitting terminal may explicitly delay the packet transmission itself.
このように、本実施の形態によれば、実施の形態１及び実施の形態２の効果に加えて、中継装置が何らかの理由でパケットの一時蓄積及びタイムスタンプの補正による同期処理を行うことができない場合であっても、上流の中継装置に同期処理を依頼するので、通信システムのうちのいずれかのポイントで同期処理を行うことができ、ＲＴＴの増加による不必要に低い帯域の推定を防止することができる。 Thus, according to the present embodiment, in addition to the effects of the first and second embodiments, the relay apparatus cannot perform synchronization processing by temporarily storing packets and correcting time stamps for some reason. Even in such a case, since the synchronization processing is requested to the upstream relay device, the synchronization processing can be performed at any point in the communication system, and the estimation of an unnecessarily low bandwidth due to an increase in RTT is prevented. be able to.
以上詳細に説明したように、上記各実施の形態によれば、送信端末と受信端末との間で流量制御を行いながら同期する必要がある複数のストリームを送信する場合に、本発明を中継装置、又はパケットを中継する受信端末に適用することで、受信端末で同期処理のための多量のメモリを必要とすることなしに、また、送信端末と受信端末との間の流量制御において不必要に性能劣化が起こることなしに、同期処理及び流量制御を行うことができる。 As described above in detail, according to each of the above embodiments, the present invention is applied to a relay apparatus when transmitting a plurality of streams that need to be synchronized while performing flow rate control between a transmission terminal and a reception terminal. Or by applying to a receiving terminal that relays a packet, without requiring a large amount of memory for synchronization processing at the receiving terminal, and unnecessary in flow control between the transmitting terminal and the receiving terminal Synchronous processing and flow control can be performed without performance degradation.
なお、上記各実施の形態では、中継装置が同期処理を行うようにしたが、本発明はこれに限定されない。例えば、必要に応じて、パケットの一時蓄積やタイムスタンプの補正を行う機能を有する受信端末が同期処理を行うようにしてもよい。この場合、受信端末のバッファリング領域は消費するが、不必要に低い帯域推定を防止することができ、受信品質の向上に一定の効果を得ることができる。 In each of the above embodiments, the relay apparatus performs the synchronization process, but the present invention is not limited to this. For example, a receiving terminal having a function of temporarily storing packets and correcting time stamps may perform synchronization processing as necessary. In this case, although the buffering area of the receiving terminal is consumed, an unnecessarily low bandwidth estimation can be prevented, and a certain effect can be obtained in improving reception quality.
本発明に係る中継装置及び中継方法は、送信端末からの関連する複数のストリームが異なる経路で受信端末に伝送される場合であっても、受信端末の無駄な記憶領域を省略し、かつ、不必要に低い帯域推定を行うことなく受信端末で複数のストリームから高品質なデータを再生することができる効果を有し、例えば、複数のマルチメディアデータを中継し、同期させて伝送する中継装置及び中継方法として有用である。 The relay apparatus and the relay method according to the present invention eliminates a wasteful storage area of the receiving terminal even when a plurality of related streams from the transmitting terminal are transmitted to the receiving terminal through different paths, and is not necessary. A relay device that has an effect that high-quality data can be reproduced from a plurality of streams at a receiving terminal without performing necessary low bandwidth estimation, for example, a relay device that relays a plurality of multimedia data and transmits them in synchronization It is useful as a relay method.
１００ 送信端末
１１０、１２０ ルータ
１３０、１４０、３００、３３０、３５０ 中継装置
１４２ 識別部
１４３ 遅延部
１４４ 記憶部
１４５ 送信待ちキュー
１４６ 補正部
１４８ 送信部
１５０ 受信端末
３１０、３６０ バッファリング要求受付部
３２０、３３０ バッファリング要求部
100
Claims (10)
前記特定のデータフロー群の一部のデータフローの送信を遅延させる遅延部と、
前記遅延させたデータフローに刻印されたタイムスタンプを、前記遅延部により遅延させた時間分だけ補正する補正部と、
前記特定のデータフロー群を送信する送信部と、
を有する中継装置。 An identifier for identifying a specific group of data flows to be synchronized in one session among a plurality of data flows;
A delay unit for delaying transmission of a part of the specific data flow group;
A correction unit that corrects the time stamp imprinted on the delayed data flow by the time delayed by the delay unit;
A transmission unit for transmitting the specific data flow group;
A relay device.
請求項１記載の中継装置。 The specific data flow group includes a plurality of multimedia data flows.
The relay apparatus according to claim 1.
請求項１記載の中継装置。 The specific data flow group includes a plurality of hierarchically encoded data flows.
The relay apparatus according to claim 1.
前記データフローのヘッダに記述された宛先アドレス、送信元アドレス、宛先ポート番号、送信元ポート番号、及びクラス番号の少なくとも１つを用いて前記特定のデータフロー群を識別する、
請求項１記載の中継装置。 The identification unit is
Identifying the specific data flow group using at least one of a destination address, a source address, a destination port number, a source port number, and a class number described in the header of the data flow;
The relay apparatus according to claim 1.
前記特定のデータフロー群の一部のデータフローを蓄積することにより送信を遅延させる、
請求項１記載の中継装置。 The delay unit is
Delaying transmission by accumulating some data flows of the specific data flow group;
The relay apparatus according to claim 1.
前記遅延させたデータフローが前記遅延部に蓄積された時間を前記タイムスタンプに記述された時刻に加算することにより、前記遅延させたデータフローに刻印されたタイムスタンプを補正する、
請求項５記載の中継装置。 The correction unit is
Correcting the time stamp imprinted on the delayed data flow by adding the time accumulated in the delay unit to the time described in the time stamp by the delayed data flow.
The relay device according to claim 5.
前記特定のデータフロー群に含まれる各データフローに刻印されたタイムスタンプの刻印粒度を、前記特定のデータフロー群に含まれる各データフローが到着した時間の間隔から推定し、推定したタイムスタンプの刻印粒度を用いて前記遅延させたデータフローに刻印されたタイムスタンプを補正する、
請求項１記載の中継装置。 The correction unit is
The time stamping granularity of each time stamp included in each data flow group included in the specific data flow group is estimated from the time interval at which each data flow included in the specific data flow group arrives. Correct the time stamp stamped in the delayed data flow using the stamp granularity;
The relay apparatus according to claim 1.
前記遅延要求を受入れるかどうかを判断し、前記遅延要求を受入れる場合には、前記識別部に対して前記遅延要求が示すデータフローを前記特定のデータフローとして通知し、前記遅延要求を受入れない場合には、前記遅延要求を上流に接続される他のネットワーク端末に対して送信する遅延要求処理部と、
をさらに有する請求項１記載の中継装置。 A delay request receiving unit that receives a delay request for data flow from another network terminal connected downstream;
When determining whether to accept the delay request and accepting the delay request, when notifying the data flow indicated by the delay request to the identification unit as the specific data flow and not accepting the delay request Includes a delay request processing unit that transmits the delay request to another network terminal connected upstream;
The relay apparatus according to claim 1, further comprising:
前記遅延要求が示すデータフローを蓄積した場合の蓄積量と前記遅延部が蓄積可能なデータフローの最大量とを比較することにより、前記遅延要求を受入れるかどうかを判断する、
請求項８記載の中継装置。 The delay request processing unit
Determining whether to accept the delay request by comparing the accumulated amount when the data flow indicated by the delay request is accumulated with the maximum amount of data flow that can be accumulated by the delay unit;
The relay device according to claim 8.
前記特定のデータフロー群の一部のデータフローの送信を遅延させるステップと、
前記遅延させたデータフローに刻印されたタイムスタンプを、前記遅延ステップで遅延させた時間分だけ補正するステップと、
前記特定のデータフロー群を送信するステップと、
を有する中継方法。 Identifying a particular group of data flows to be synchronized in a session from a plurality of data flows;
Delaying transmission of some data flows of the particular group of data flows;
Correcting the time stamp imprinted on the delayed data flow by the time delayed in the delay step;
Transmitting the specific data flow group;
A relay method.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2006127895A JP4653011B2 (en) | 2006-05-01 | 2006-05-01 | Relay device and relay method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2006127895A JP4653011B2 (en) | 2006-05-01 | 2006-05-01 | Relay device and relay method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2007300498A true JP2007300498A (en) | 2007-11-15 |
| JP4653011B2 JP4653011B2 (en) | 2011-03-16 |
Family
ID=38769601
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2006127895A Expired - Fee Related JP4653011B2 (en) | 2006-05-01 | 2006-05-01 | Relay device and relay method |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4653011B2 (en) |
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2010147806A (en) * | 2008-12-18 | 2010-07-01 | Fujitsu Ltd | Delay measurement method and communication device |
| JP2010171697A (en) * | 2009-01-22 | 2010-08-05 | Hitachi Ltd | Video delivering system, video delivering device, and synchronization correcting processing device |
| WO2011105621A1 (en) * | 2010-02-24 | 2011-09-01 | Ricoh Company, Limited | Transmission system |
| KR20110105200A (en) * | 2010-03-18 | 2011-09-26 | 에스케이 텔레콤주식회사 | Apparatus and method for synchronizing micro base station in asymmetric communication links |
| JP2011530954A (en) * | 2008-08-11 | 2011-12-22 | クゥアルコム・インコーポレイテッド | Method and apparatus for providing a modified timestamp in a communication system |
| JP2012080527A (en) * | 2010-09-06 | 2012-04-19 | Ricoh Co Ltd | Transmission terminal, program for transmission terminal, program provision system and maintenance system |
| JP2012156744A (en) * | 2011-01-26 | 2012-08-16 | Nec Corp | Synchronization system |
| JP2013518495A (en) * | 2010-01-27 | 2013-05-20 | コニンクリーケ・ケイピーエヌ・ナムローゼ・フェンノートシャップ | Method, system and apparatus for synchronization of media streams |
| JP2014522609A (en) * | 2011-06-08 | 2014-09-04 | クゥアルコム・インコーポレイテッド | Multipath rate adaptation |
| AT515441A1 (en) * | 2014-02-26 | 2015-09-15 | Frequentis Ag | Voice transmission in redundant systems |
| JP2016521494A (en) * | 2013-04-12 | 2016-07-21 | クアルコム，インコーポレイテッド | Method for distribution of a flow of objects through a broadcast / multicast capable network |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH08130540A (en) * | 1994-10-28 | 1996-05-21 | Matsushita Electric Ind Co Ltd | Device and method for synchronously transmitting stream data |
| JPH09507628A (en) * | 1994-01-12 | 1997-07-29 | サイエンテイフイク−アトランタ・インコーポレーテツド | Time stamp correction in ATM network |
| JPH11239179A (en) * | 1998-02-23 | 1999-08-31 | Toshiba Corp | Device and method for repeating multimedia data |
| JP2001094576A (en) * | 1999-09-24 | 2001-04-06 | Nec Corp | Isochronous packet transfer method, recording medium for transfer control program, bridge and packet transfer control lsi |
| JP2001230796A (en) * | 2000-02-16 | 2001-08-24 | Fujitsu Ltd | Data communication system |
| JP2004072720A (en) * | 2002-06-14 | 2004-03-04 | Matsushita Electric Ind Co Ltd | Media transmission method, transmitting apparatus and receiving apparatus therefor |
| JP2006094130A (en) * | 2004-09-24 | 2006-04-06 | Nippon Telegr & Teleph Corp <Ntt> | Packet transmission controller, and its method and program |
-
2006
- 2006-05-01 JP JP2006127895A patent/JP4653011B2/en not_active Expired - Fee Related
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH09507628A (en) * | 1994-01-12 | 1997-07-29 | サイエンテイフイク−アトランタ・インコーポレーテツド | Time stamp correction in ATM network |
| JPH08130540A (en) * | 1994-10-28 | 1996-05-21 | Matsushita Electric Ind Co Ltd | Device and method for synchronously transmitting stream data |
| JPH11239179A (en) * | 1998-02-23 | 1999-08-31 | Toshiba Corp | Device and method for repeating multimedia data |
| JP2001094576A (en) * | 1999-09-24 | 2001-04-06 | Nec Corp | Isochronous packet transfer method, recording medium for transfer control program, bridge and packet transfer control lsi |
| JP2001230796A (en) * | 2000-02-16 | 2001-08-24 | Fujitsu Ltd | Data communication system |
| JP2004072720A (en) * | 2002-06-14 | 2004-03-04 | Matsushita Electric Ind Co Ltd | Media transmission method, transmitting apparatus and receiving apparatus therefor |
| JP2006094130A (en) * | 2004-09-24 | 2006-04-06 | Nippon Telegr & Teleph Corp <Ntt> | Packet transmission controller, and its method and program |
Cited By (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2011530954A (en) * | 2008-08-11 | 2011-12-22 | クゥアルコム・インコーポレイテッド | Method and apparatus for providing a modified timestamp in a communication system |
| JP2010147806A (en) * | 2008-12-18 | 2010-07-01 | Fujitsu Ltd | Delay measurement method and communication device |
| JP2010171697A (en) * | 2009-01-22 | 2010-08-05 | Hitachi Ltd | Video delivering system, video delivering device, and synchronization correcting processing device |
| JP2013518495A (en) * | 2010-01-27 | 2013-05-20 | コニンクリーケ・ケイピーエヌ・ナムローゼ・フェンノートシャップ | Method, system and apparatus for synchronization of media streams |
| US8839340B2 (en) | 2010-01-27 | 2014-09-16 | Koninklijke Kpn N.V. | Method, system and device for synchronization of media streams |
| US9210375B2 (en) | 2010-02-24 | 2015-12-08 | Ricoh Company, Limited | Transmission system and transmitting method |
| WO2011105621A1 (en) * | 2010-02-24 | 2011-09-01 | Ricoh Company, Limited | Transmission system |
| KR20110105200A (en) * | 2010-03-18 | 2011-09-26 | 에스케이 텔레콤주식회사 | Apparatus and method for synchronizing micro base station in asymmetric communication links |
| KR101629448B1 (en) * | 2010-03-18 | 2016-06-22 | 에스케이 텔레콤주식회사 | Apparatus and Method for Synchronizing Micro Base Station in Asymmetric Communication Links |
| JP2012080527A (en) * | 2010-09-06 | 2012-04-19 | Ricoh Co Ltd | Transmission terminal, program for transmission terminal, program provision system and maintenance system |
| JP2012156744A (en) * | 2011-01-26 | 2012-08-16 | Nec Corp | Synchronization system |
| JP2014522609A (en) * | 2011-06-08 | 2014-09-04 | クゥアルコム・インコーポレイテッド | Multipath rate adaptation |
| US9736548B2 (en) | 2011-06-08 | 2017-08-15 | Qualcomm Incorporated | Multipath rate adaptation |
| JP2016521494A (en) * | 2013-04-12 | 2016-07-21 | クアルコム，インコーポレイテッド | Method for distribution of a flow of objects through a broadcast / multicast capable network |
| AT515441B1 (en) * | 2014-02-26 | 2016-01-15 | Frequentis Ag | Voice transmission in redundant systems |
| AT515441A1 (en) * | 2014-02-26 | 2015-09-15 | Frequentis Ag | Voice transmission in redundant systems |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4653011B2 (en) | 2011-03-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4653011B2 (en) | Relay device and relay method | |
| US6778493B1 (en) | Real-time media content synchronization and transmission in packet network apparatus and method | |
| US8223807B2 (en) | Synchronizing data transmission over wireless networks | |
| JP4430660B2 (en) | Method and apparatus for multimedia streaming | |
| US7760728B2 (en) | System and method for efficient broadcast of information over a network | |
| CN101939967B (en) | Communications method | |
| Matsuzono et al. | Low latency low loss streaming using in-network coding and caching | |
| US7782779B2 (en) | Apparatus and method for transmitting a multimedia data stream | |
| US20080095159A1 (en) | Communication quality management and apparatus | |
| JP4969342B2 (en) | Receiving terminal and receiving method | |
| US20110058554A1 (en) | Method and system for improving the quality of real-time data streaming | |
| JP2001197104A (en) | Device and method for streaming multimedia object on time base | |
| WO2003105421A1 (en) | Digital content delivery system, digital content delivery method, program for executing the method, computer-readable recording medium storing thereon the program, and server and client for it | |
| US20050018615A1 (en) | Media transmitting method, media receiving method, media transmitter and media receiver | |
| WO2006047732A2 (en) | Network architecture for real time delivery of video over lossy networks from remote locations | |
| CN102859950A (en) | Method of estimating congestion | |
| US20110085551A1 (en) | Staggercasting method and apparatus using type of service (tos) information | |
| JP2000228676A (en) | Data transmission method | |
| US9184928B2 (en) | Communications terminal, communications method, and program and integrated circuit for controlling a reproduction delay time in distributing a stream | |
| JP3933555B2 (en) | DATA DISTRIBUTION SYSTEM, DATA DISTRIBUTION DEVICE, DATA DISTRIBUTION METHOD, DATA DISTRIBUTION PROGRAM, AND RECORDING MEDIUM CONTAINING THE PROGRAM | |
| JP2002314595A (en) | Communication repeater and jitter suppression method | |
| Lucas et al. | Distributed Error Recovery for Continuous Media Data in Wide-Area Multicast | |
| JP2006211233A (en) | Ip communication apparatus | |
| JP2009206998A (en) | Communications device | |
| JP2009260888A (en) | Communication apparatus |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20081128 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20100806 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100824 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20101022 |
|
| 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: 20101124 |
|
| 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: 20101216 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4653011 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: 20131224 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |