JP3871661B2

JP3871661B2 - Multimedia content receiving apparatus and multimedia content receiving method

Info

Publication number: JP3871661B2
Application number: JP2003202125A
Authority: JP
Inventors: 剛永井
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2003-07-25
Filing date: 2003-07-25
Publication date: 2007-01-24
Anticipated expiration: 2023-07-25
Also published as: JP2005045469A

Description

【０００１】
【発明の属する技術分野】
本発明は符号化された動画像、音声や静止画像を含むマルチメディアコンテンツをISDNやインターネット等の有線通信網、あるいは携帯電話や無線LAN等の無線通信網を用いて伝送する情報伝送方式およびその方法が適用されるマルチメディアコンテンツ受信装置及びマルチメディアコンテンツ受信方法に関する。
【０００２】
【従来の技術】
近年、動画像、静止画像、音声等のマルチメディアコンテンツを始めとする各種情報のディジタル符号化技術および広帯域ネットワーク技術の進展により、これらを利用したアプリケーションの開発が盛んになっており、圧縮符号化した画像などを、通信網を利用して伝送するシステムが開発されている。
【０００３】
特に近年、インターネット・イントラネットの普及により、データをパケット化して送受信するアプリケーションやシステムが増加してきている。パケット化は通信路の帯域を効率よく複数のユーザで共有するための非常に有効な手段となっている。インターネット・イントラネットでパケットデータを送受信するプロトコルとしてTCP/IPやUDP/IPなどが存在する。TCP/IPは再送などの枠組みが組み込まれていることから誤りなどに強く、多少時間がかかっても正しくデータを受信したいダウンロード型のアプリケーションで有効である。これに対し、UDP/IPは再送の枠組みがない反面、再送などにかかる遅延がなく、リアルタイム性を求められるアプリケーションには非常に有効である。
【０００４】
通常の動画像通信の場合、画像データは非常に膨大なデータ量であり、ネットワークの帯域に収まらない場合がほとんどである。その場合、画像データを符号化し、データ量を小さくしてから伝送するという手法が用いられる。動画像信号の圧縮符号化技術としては動き補償、離散コサイン変換(DCT)、サブバンド符号化、ピラミッド符号化、可変長符号化等の技術やこれらを組み合わせた方式が開発されている。動画像符号化の国際標準方式としてはISO MPEG-1, MPEG-2, ITU-T H.261, H.262, H.263が存在し、また動画像、音声・オーディオ信号を圧縮した符号列や他のデータを多重化する国際標準方式としてはISO MPEGシステム、ITU-T H.221, H.223が存在する。
【０００５】
インターネット等は無数のネットワークを介して繋がっており、どのネットワークがどういう状況になっているかわからないのが普通である。また、そこに流れているデータ量が時々刻々と変動するため、どのくらいのデータがリアルタイムで通信できるかを判定する仕組みが必要である。そこで、UDP/IPを利用したリアルタイムアプリケーションからさらに一歩進み、パケットに時間情報等を付加して伝送するRTPというパケットフォーマットを使用するアプリケーションが増えてきている。RTPを利用することで、パケットに時間情報およびパケット番号が付加され、受信側では正しい時間情報を用いて音声や画像を表示することが出来たり、ネットワークで順番が入れ替わったパケットなどを判定したり、パケット番号を見ることでパケットが損失していることを検出すること等が出来るようになった。しかも、RTPには送信側や受信側から補足情報としてジッタやパケット損失率などを通知する仕組み(RTCP)も備わっている。さらに、RTPパケットの再送を行う仕組み等も現在議論されている。この提案の中では、パケットの再送方式を提案している他、パケットに優先順位等を付加し、全てを再送しないようトラフィックの制御ができるような機能が加えられている。但し、この利用法についても特に規定がなされているわけではない。
【０００６】
また、IETFでは上記のような画像通信を確立するための送信端末・受信端末間のセッション管理プロトコルとしてRTSPが、さらに画像コンテンツの内容を記述するための言語仕様であるSDPが規定されている。これにより、サーバ・クライアント間ではRTSPによりセッションの開始や、マルチメディアコンテンツの送信開始、一時停止やセッションの終了等の制御が可能となる。
【０００７】
このような状況の中、画像をインターネット・イントラネットで伝送する場合、ネットワークの帯域では生の画像伝送分の帯域を確保できないことから、前述のように画像信号をMPEGなどの符号化方式で圧縮をして送る必要がある。これはデータ量の減少には効果があるが、逆に不安定なインターネットにデータを流すことでのパケット損失や誤りの混入に対して非常にもろくなる。これは動画像符号化方式が前のフレームとの差分のみを送信することから、データの一部が欠落することが非常に大きな問題になる。UDPやRTPを使った場合、基本的にデータの再送は行われないことからこの問題に対する対策が必要となる。
【０００８】
これに対応する目的で、RTPの再送に関しての規格制定がIETF(The Internet Engineering Task Force)で行われている。簡単に記述すると、AVPFというプロトコルを使い、受信できなかったパケット番号を送信側にNACKというコマンドで通知を行うようにする。送信側ではこのNACKから消失したパケットを特定し、RTP再送の規格に準じてヘッダを構成し、受信側へ送信する。さらに、RTPは主にリアルタイム通信に利用されることから、再送しても表示に間に合わないパケットは再送しないような制御を行ったりする技術も提案されている。
【０００９】
特許文献１に開示された受信装置の構成例を示す。送信側から送信されたパケットデータは受信部１６０１で受信されパケット解析部１６０２でパケットヘッダ等を読み取りパケット番号、タイムスタンプ等が取得される。この情報１６３２は通信路状態算出部１６０３でパケットロスや遅延量などが計算され通信路状態情報送信部１６０４によりRTCP等を利用して送信側へ送信される。また、パケット解析情報１６３２と通信路状態情報１６３４は再送判定部１６０５に入力され、再送要求するかどうかの判定が行われる。パケットロスが発生したパケット番号等から前述したようなNACK信号１６３５を生成し、再送要求送信部１６０６で送信側へ通知する。一方受信されたパケットデータ１６３６はパケットバッファ部１６０７へ一時保管され、再送等で送られてくるパケットと併せて順番を調整した後、復号化部１６０８へ送られデータに応じた復号処理を行い、表示部１６０９で再生を行う。
【００１０】
しかし特許文献１に開示された構成においては、ネットワークの誤り率が高いときや、伝送遅延が大きいときに再送要求や再送応答自身が誤ってしまい、再送による誤り復帰の確率があまり高くならないという問題があった。
【００１１】
また、再送パケットが到着するまでに遅延があり、リアルタイム再生に間に合わない可能性があるため、再送を記録用途に利用することも提案されている。その際は、再送パケットをリアルタイムと同じ信頼性の低いUDPで伝送するのではなく、信頼性のあるTCPで伝送するようにする等の工夫がなされているものの、効率が悪いという問題があった。
【００１２】
【特許文献１】
特開２００２−８４３３８公報
【００１３】
【発明が解決しようとする課題】
従来の技術では、ネットワークのプロトコルとして、RTPのフィードバック情報(RTCP)や、再送制御(RTP Retransmission)等が提案され規格化されてきたが、RTCPや再送をどのように使用すべきかが提示されてこなかった。再送要求の発行の方法としては、従来例で示したように、リアルタイム再生に間に合わない再送パケットは伝送しないようにする工夫などがあるが、基本的に届かなかったパケットに対し再送要求を発行するというスタンスであった。
【００１４】
しかし、これでは、ネットワークの誤り率が高いときや、伝送遅延が大きいときに再送要求や再送応答自身が誤ってしまい、再送による誤り復帰の確率があまり高くならないという問題がある。
【００１５】
【課題を解決するための手段】
本願発明においては、パケット化されたマルチメディアコンテンツデータを受信する受信手段と、前記受信手段で受信したパケットデータの受信状態を解析する解析手段と、前記解析手段により解析された結果から再送を要求すべきパケットデータがあるかどうか判定して当該パケットデータの再送要求信号を出力する再送制御手段と、前記再送制御手段により判定された結果を保持しておく再送リスト手段と、前記再送制御手段により出力された再送要求情報を送信側に送信する送信手段と、前記受信手段で受信されたパケットデータを一時的に保持するバッファ手段とを有することを特徴とするマルチメディアコンテンツ受信装置を提供する。
【００１６】
また本願発明のマルチメディアコンテンツ受信装置において、前記バッファ手段に保持されたパケットデータを復号する復号化手段と、復号されたマルチメディアコンテンツを出力する出力手段とを有することを特徴とする。
【００１７】
また本願発明のマルチメディアコンテンツ受信装置において、前記再送制御手段は、前回の再送要求信号を送信した時刻からパケットの往復時間を経過した後、当該再送要求に対する応答が得られない場合に、再度再送要求信号を出力するよう制御することを特徴とする。
【００１８】
また本願発明のマルチメディアコンテンツ受信装置において、前記再送制御手段は、最大再送回数を保持し、最大再送回数を越えないように、繰り返し再送要求信号を出力するよう制御することを特徴とする。
【００１９】
また本願発明のマルチメディアコンテンツ受信装置において、前記再送制御手段は、保持された最大再送回数と前記バッファ手段におけるパケットデータのバッファリング時間とから決定される再送要求間隔に基づいて再送要求信号を出力することを特徴とする。
【００２０】
また本願発明においては、パケット化されたマルチメディアコンテンツデータを受信するステップと、受信したパケットデータの受信状態を解析するステップと、解析された結果から再送を要求すべきパケットデータがあるかどうか判定して当該パケットデータの再送要求信号を出力するステップと、前記再送要求信号出力ステップにより判定された結果を保持しておくステップと、前記再送要求情報を送信側に送信するステップと、前記受信されたパケットデータをバッファに一時的に保持するステップとを有することを特徴とするマルチメディアコンテンツ受信方法を提供する。
【００２１】
また本願発明のマルチメディアコンテンツ受信方法において、前記バッファに保持されたパケットデータを復号するステップと、復号されたマルチメディアコンテンツを出力するステップとを有することを特徴とする。
【００２２】
また本願発明のマルチメディアコンテンツ受信方法において、前記再送要求信号出力ステップは、前回の再送要求信号を送信した時刻からパケットの往復時間を経過した後、当該再送要求に対する応答が得られない場合に、再度再送要求信号を出力する。
【００２３】
また本願発明のマルチメディアコンテンツ受信方法において、前記再送要求信号出力ステップは、最大再送回数を保持し、最大再送回数を越えないように、繰り返し再送要求信号を出力することを特徴とする。
【００２４】
また本願発明のマルチメディアコンテンツ受信方法において、前記再送要求信号出力ステップは、保持された最大再送回数と前記バッファ手段におけるパケットデータのバッファリング時間とから決定される再送要求間隔に基づいて再送要求信号を出力することを特徴とする。
【００２５】
【発明の実施の形態】
（第１の実施形態）
図１は本発明の第１の実施形態に係るマルチメディアコンテンツ受信装置の基本構成図である。インターネット等の有線回線または携帯電話、ＰＨＳ、無線LAN等の無線回線を経由して送信側から送信されてきた映像（動画、静止画）、音声、文字（テキストデータ）等のマルチメディアコンテンツデータは受信部１０１で受信される。受信データ１３１は、解析部１０２に入力され、受信されたマルチメディアコンテンツデータの種類、パケットヘッダなどを解析し、正しく受信できたか等を検証する。次にパケットヘッダ等の伝送上必要だった情報を取り除いたデータ１３２は、バッファ部１０３に送られ、その後、復号化部１０７で画像、音声等のデータが復号され、画像表示部や音声出力部を含む出力部１０８に出力される。
【００２６】
ここで、解析部１０２でパケット解析された結果、パケットの順序の不連続により、受信されるべきパケットが受信されなかった場合、特に受信されるべきパケットが消失している場合（パケットロス）には、再送制御部１０４に消失したパケット情報１３４を渡す。再送制御部１０４では、消失したパケット情報１３４から、消失したパケットの再送要求１３７を生成し、送信部１０６から伝送回線を経由して送信側に再送要求を送り出す。再送制御部１０４での再送情報１３５は、リスト部１０５に送られ、保存・管理される。再送制御部１０４では、リスト部１０５に保存された再送情報１３６を読み出し、新たに再送要求１３７を生成するかどうかの判断を行う。
【００２７】
本発明の特徴は、受信したパケットを解析する解析部を具備するだけでなく、消失パケットの情報、発行した再送要求情報、受信した再送パケットの情報などのうち少なくとも一つを保持するリスト部１０５を有していることにある。このリスト部１０５に蓄積された情報１３６を再送制御部１０４が読み出すことにより、再送要求を発行するかどうかの判断及び再送要求を発行するタイミング等を制御することができる。
【００２８】
第１の実施形態では、解析部１０２でパケットロスが発生したことを検出した場合に、その情報１３４を再送制御部１０４が受け取り再送要求１３７を作成し、送信側に送信する方式を説明したが、これとは異なり、伝送路でパケットロスが発生し、受信側でこれを検出した場合でも、再送制御部１０４で直ちに再送要求１３７を生成するのではなく、一旦リスト部１０５へ送り、リスト部からの出力１３６にだけ従って再送制御部１０４で再送要求１３７を作成する方法も可能である。一旦リスト部にパケットロスの情報を蓄えることで、再送要求を発行する時間間隔や、再送要求を送出する際に使用する伝送帯域を制御しやすくすることが可能となる。
【００２９】
また第１の実施形態において、解析部１０２でパケットの受信状態を観測することにより通信路の状態を推定、算出する機能を具備しても良い。この場合には受信側で推定、算出した伝送路の状態を、再送制御部１０４に転送し、送信部１０６から送信側へ伝えることも可能である。これにより送信側では、伝送路の状態を考慮してパケットの送信制御を行なうことができる。
【００３０】
ここで受信側から再送要求を送出する場合や、再送要求に応答して送信側から消失パケットの再送が行なわれる場合に、途中の伝送路、通信ネットワークの状況により更に再送されたパケットを受信することができず（パケットロス）、受信側で再送を要求したパケットを受信できない場合があります。そこで改良された受信側では、複数回再送要求を発行することをサポートする。
【００３１】
この機能を持つ再送制御部１０４の構成図を図２に示す。解析部１０２の受信パケットの解析結果情報１３４は、再送間隔算出部２０１に入力され、現在のネットワークの状態から再送要求を発行する時間間隔（△Ｔ）２３１を算出します。この値２３１は再送判定部２０２に入力され、リスト部１０５に蓄えられているパケットロス情報１３６と比較して、再送要求が再度必要かどうか判定を行なう。判定結果２３１を使い、再送要求生成部２０３で再送要求１３７を作成し、送信部１０６へ送る。
【００３２】
この再送制御部１０４の構成は、例であり解析情報１３４を再送判定部２０２にだけ入力し再送判定部２０２から再送間隔算出部２０１にデータを渡し再送間隔を計算するような構成も可能である。再送制御部で、パケットロスしたパケット情報とネットワークの遅延や、パケットロス率といった品質情報とから再送要求するかどうか判定する機能が実現できれば、本発明の効果を得るのにどのような構成でも可能である。
【００３３】
再送判定部２０２で行う再送要求を行うかどうかの判定方法の基本方法を示したフローチャートを図３に示す。
【００３４】
ステップ３０１では、リスト部１０５から得たパケットロスしたパケットの情報１３６（具体的には、パケットロスしたパケットのＩＤ（識別番号）、前回再送要求をしたときの時刻情報など）を取得する。次にステップ３０２により、現在の時刻から前回再送要求した時刻を引いたものが再送間隔算出部２０１で算出された再送間隔△Ｔより大きいかどうか判定する。時間間隔が大きい場合には、前回受信側から送信された再送要求が途中の伝送路の誤りにより送信側に届かなかったか、もしくは受信側からの再送要求は送信側に届いたものの、送信側から再送されたパケットが伝送路の混み具合、伝送路品質の劣化等により、受信側に届かず、再びパケットロスしたと判断する。そしてステップ３０３により再度再送要求を行う。一方、ステップ３０２の判定が偽の場合は、送信側からの再送応答が来るのを待つこととし、まだ所定の時間間隔△Ｔを経過するまで、受信側から再送要求は行わないよう制御する。
【００３５】
前回（１回目）の受信側からの再送要求や送信側からの応答がネットワーク等の誤りにより破棄され受信側に応答が帰ってこないと判断した後、受信側で再度（２回目の）再送要求を発行する場合、この判断する時間間隔の設定の仕方によっては、再度（２回目の）再送要求を行った後に、前回（１回目）の再送要求に対する応答が受信側に到達する場合も生じうる。その場合には、最後（２回目以降）の再送要求は無駄な要求になってしまう。この状況を示したタイムチャートを図４に示す。
【００３６】
例えば、送信側から送信したパケット＃ｎが受信側で受信できなかった場合を想定する。受信側では、パケット＃ｎ−１を受信後に、一定時間を経過してもパケット＃ｎを受信しなかったり、パケット＃ｎを受信する前にパケット＃ｎ＋１を受信してしまったりした場合に、パケット＃ｎが「消失した」と判定する。そして「パケット＃ｎを受信しなかったので再送して欲しい」旨の通知（再送要求）を送信側に通知する。ここで再送要求を送信後、パケット＃ｎを受信できないからといって、有意の時間を経過する前に再度再送要求を送信したのでは、送信側から再送されたパケット＃ｎと入れ違いになり、再度（２回目）の再送要求が無駄になる恐れがある。
【００３７】
このような場合にも、パケットの往復時間を推定して再送時間間隔△Ｔを制御することで、無駄なパケットの再送要求を抑制することが可能である。この方式を示した図を図５に示す。
【００３８】
通信プロトコルや特定のアプリケーションで、伝送路の行き来するパケットの往復時間を取得することができる場合がある。その場合には、これを利用し往復時間以上の時間を再送時間間隔△Ｔと設定することで実現することができる。例えばRTPのようなプロトコルの場合、RTCPを利用することで送信側ではパケット往復時間を計算することが可能であるが、パケットデータを受信するだけの受信側端末では、通常はパケットの往復時間の情報を取得できない。
【００３９】
そのため、送信側から別途パケット往復時間の情報を伝送してもらうか、パケットを送信していない状態でもRTCPの送信者情報（Sender Report：SR）を送りその応答を使ってパケット往復時間を算出する等の対応を行い、パケット往復時間を取得することが必要となる。これ以外の方法では、例えばRTP等のパケットに付加されている時刻情報（タイムスタンプ）と受信側で受け取った際の受信時刻の差からパケットの片道伝送時間を算出し、その２倍をパケット往復時間と仮定して往復時間を推定して、これを使用する方法も適用可能である。ネットワークによっては、往復の時間が異なる場合（上り下りの通信路の伝送速度が非対称の場合）もあり、その場合は２倍ではなく、ネットワークに適した値を使い往復時間の設定を調節することで対応可能である。
【００４０】
その他、パケット往復時間だけでなく、送信側で再送要求を受け取り、再送応答を送信するまでの処理遅延を考慮し、再送間隔を算出することも可能である。
【００４１】
この再送間隔の算出は、ネットワークの遅延時間が予め分かっている場合や、通信開始時点において最初に算出した値を固定的に使用することもできるが、ネットワークの状態が時間的に変動する場合には、パケットの受信毎に現在の状態を解析し、その時点にあった再送間隔を算出しなおすことにより、動的に再送間隔を決定する方式を採用することも可能である。算出するタイミングは、パケット受信毎でも、ある間隔単位で行うことも可能である。また、局所的な変動に強く左右されないように、以前のネットワークの状態を考慮した算出方法を採用することも可能である。
【００４２】
（第２の実施形態）
送信側から受信側に至るまでのネットワーク状態の解析から誤り率やパケットロス率が得られる場合、そのようなネットワーク情報に基づいて必要な再送回数を求めるようにする方式も可能である。これにより、再送後の品質をある程度要求仕様に沿った形にすることが可能となる。
【００４３】
かかる方式に対応した再送制御部１０４の基本構成図を図６に示す。本方式では、図６の構成では、図２の再送間隔算出部２０１に代わり再送回数算出部６０１を有するところが特徴となる。この再送回数算出部６０１は、解析部１０２によるパケットロスに関する解析結果情報１３４から、コンテンツの品質を保証するのに必要な再送要求の回数を算出する。必要再送回数情報６３１は再送判定部２０２に送られ、リスト部１０５にあるパケットロス情報１３６から再送要求判断２３２を行い、再送要求生成部２０３により再送要求１３７を生成し、送信部１０６から送信する。
【００４４】
更に再送間隔を決定する手段を同時に持つことで、算出された再送間隔に基づき、必要回数の再送を行うことが可能となる。この方式の基本構成図を図７に示す。
【００４５】
本方式では、再送間隔算出部２０１と再送回数算出部６０１が共存しており、夫々の出力である再送間隔情報２３１と再送回数情報６３１が再送判定部２０２に送られ、再送要求を行うかどうかの判定が行われる。
【００４６】
複数回の再送を行う際の送信側、受信側の手続の流れを図８に示す。この例では、送信側で送出したｎ番目のパケットが伝送路上でパケットロスしたと想定し、それに対する再送要求を送信する場合について説明する。一旦（１回目の）＃ｎパケットデータの再送早急信号を受信側から送出し、その後、受信側では推定された再送間隔の間待機して＃ｎのパケットデータの到着を待つ。そして推定された再送時間間隔を経過した後も＃ｎのパケットデータが受信されなかった場合には、＃ｎのパケットデータが未着であり、再度受信側に送信するよう２回目の再送要求信号を送信側に向けて送出する。更にこの例では、送信側から送出された２回目の再送応答（＃ｎのパケットデータ）も受信側において受信できず、再度（３回目）の再送要求を送信側に向けて送信し、これに対して送信側から送信された＃ｎのパケットデータを再送応答として受信している様子を示している。
【００４７】
通常、バッファ部１０３で受信されたデータを一旦蓄え、一定時間後に後段の復号化部１０７や出力部１０８に出力する。上記の方式は基本的に、このバッファ部１０３でデータを蓄えている時間（バッファリング時間）が（再送回数）×（再送間隔）よりも大きい（十分に長い時間）場合に有効である。もしも、この再送回数×再送間隔の値がバッファリング時間よりも大きい場合、そのままでは後ろの再送要求は復号や表示に間に合わず、受信できても使えない無駄なパケットとなってしまう。この例を図９に示す。受信側から２回に渡って再送要求をしたが送信側からの応答（＃ｎのパケットデータ）は受信側に到達せず、更に受信側からの３回目の再送要求に応答する形で送信された＃ｎのパケットデータは受信側に到達したものの、受信側で定めたバッファリング時間を超えて受信されたため、復号されることなく廃棄されたものである。
【００４８】
この問題を解決するために、バッファリング時間を考慮した再送間隔を制御する方式を次に説明する。本方式の基本構成図は図１０に示す。
【００４９】
解析部１０２からの消失パケットデータの解析結果情報１３４は再送間隔算出部２０１および再送回数算出部６０１に入力される。再送回数算出部６０１で算出された必要再送回数情報１０３１は再送間隔算出部２０１に入力される。再送間隔算出部２０１では、再送回数情報１０３１と解析部から得られたネットワークの状態情報１３４および本受信装置のバッファリング時間情報から再送間隔を算出する。例えば、数式１のような式により求めることができる。
（再送間隔）＝（バッファリング時間）／（再送回数）…数式１
この方式では、ネットワークの状態情報とは無関係に再送間隔の時間長さが設定されるが、必要な回数の再送をバッファリング時間内に行うことを保障することが可能となる。
さらに、最後の再送要求の応答がバッファリング時間内に戻ってくる必要があるため、この式を発展させ、数式２を用いることも出来る。
（再送間隔）＝（バッファリング時間−パケット往復時間）／（再送回数）…数式２
ここで、パケット往復時間としては前述したように、実際に計測された値のほかに、送信側の処理時間を含めた値、片道のパケット伝送時間から推定した値等を利用することができる。このようにバッファリング時間を考慮して再送間隔を制御する方式の例を図１１に示す。
【００５０】
図１１では、＃ｎのパケットデータが消失して受信できなかった場合に、受信側のバッファリング時間内に＃ｎが到着するように、伝送路状態が悪い場合を想定して最大３回まで再送要求を送信側に向けて送信することができるように、１回目、２回目の再送要求信号に対する応答を待つことなく（到着するか否かに拘わらず）、３回に分けてバッファリング時間内で均等に再送要求を送信する例を示す。
【００５１】
さらに、何度目の再送要求かによって再送間隔を変える方式も適応可能である。この方式を実現する基本構成図を図１２に示す。
【００５２】
再送間隔算出部２０１では、再送回数情報１０３１と解析部から得られたネットワークの状態情報１３４及び本受信装置のバッファリング時間情報に加え、何度目の再送要求であるか、伝送路誤りが無い場合の（正常な）パケット受信からの経過時間、現在バッファ部１０３から出力されているデータの時刻情報やパケット番号情報等の値のうち再送間隔算出に必要な値１２３１を受け取る。これにより、その時点のネットワークの状態に最も適している再送間隔を算出することができ、無駄な再送要求等を少なくすることが可能となる。
【００５３】
再送制御部１０４、特に再送判定部での動作フローチャートを図１３に示す。ステップ１３０１では、解析部１０２で解析された受信パケットデータに関するネットワーク状態情報（例えば受信されたパケットデータの受信時間、受信できなかったパケットデータのＩＤ：識別番号など）、特にパケットロス率（消失したパケットデータの比率）を利用して必要な再送回数を算出する。
【００５４】
ステップ１３０２では、算出された必要な再送回数から再送間隔△Ｔを求める。その際、上記で説明したように、伝送路の状態に拘わらず時間間隔を算出することも可能であるし、受信側で許容できる遅れ時間や受信側のバッファリング時間、再送要求パケットを受信側が送出してからその要求したパケットデータが届くまでに通常かかる時間（パケット往復時間）などを考慮して算出することも可能である。
【００５５】
ステップ１３０３では、リスト部１０５からリスト部に消失パケットデータに関するパケットロス情報が存在するかどうか判定する。パケットロス情報がある場合、ステップ１３０４でパケット情報をリストから取得する。リスト部１０５にパケットロス情報が無い場合には、再送要求処理を終了する。
【００５６】
ステップ１３０５では、現在時刻と前回再送要求時刻との差が再送要求間隔△Ｔより大きいかどうかの判定を行う。ステップ１３０５が真と判定された場合（現在時刻と前回再送要求時刻との差が再送要求間隔△Ｔより大きい場合）は、ステップ１３０６により再度再送要求を行う。ステップ１３０５で偽（現在時刻と前回再送要求時刻との差が再送要求間隔△Ｔより大きくない）と判定された場合はそのままこの単位での処理が終了し、必要に応じて次の再送判定処理を行なう。
【００５７】
本フローチャートで示した処理の他にも、これ以外の方法、例えばパケットロスがあるかどうかの判定を行うステップ１３０３をこの処理の先頭で行い、パケットロスが無ければ何もせずに次の判定にうつるなどの判定方法も可能である。
【００５８】
この判定方法についてはそのほかの変形例として、予め再送回数または再送間隔の少なくともどちらか一方に最大値、最小値のうち少なくともどちらか一方の値を決めておき、算出結果がこの範囲を超えた場合には、その値に強制的に設定しなおす方法がある。これにより、極端な再送回数や再送間隔を防ぎ、システムが安定的に動作するのを保証することが可能になる。
【００５９】
本発明で行っている再送回数の算出方法としては、ネットワークの誤り率を計測し、再送後の目標誤り率にするために何回再送すればよいか計算することで求める方法が有効である。これにより、バッファ部１０３から出力されるデータの品質を保つことが可能となる。
【００６０】
再送間隔については、前述したように数式１や数式２を使った固定間隔方法が利用しやすい。しかし、周期的に誤りが入る環境や、パケット往復時間より短い再送間隔になってしまった場合に、効果が上がらなかったり、無駄な再送要求が多くなってしまったりする可能性がある。そこで、再送要求間隔を非等間隔にする方式を用いることも可能である。
【００６１】
再送間隔を非等間隔にする方式として、乱数を乗算し再送間隔を求める方法がある。例えば、求めた再送間隔に対し、０．５から１．５の間の乱数を乗算した値を再送間隔として利用する方法である。
【００６２】
これ以外に、最初（再送要求の回数が少ない）の方の再送要求の時間間隔を長めに設定し、後ろ（再送要求の回数が多い、バッファリング時間の終了直前）における再送要求の時間間隔を短くする方式も効果的である。本方式の再送間隔算出方法例を図１４のフローチャートで示す。
【００６３】
ある時点において、あるパケットがバッファ部１０３に受け入れられてから出力されるまでの時間をそのパケットのバッファ残留時間と呼ぶとすると、まずステップ１４０１において「バッファ残留時間とパケット往復時間との差」がパケット往復時間よりも大きいかどうか判定する。バッファ残留時間とパケット往復時間との差がパケット往復時間よりも大きい場合は、ステップ１４０２に進みます。ステップ１４０２では、再送間隔としてパケット往復時間を利用します。これによりパケット往復時間（平均的に再送要求を送信してからその要求したパケットデータが受信側に到達するまでの時間）を待って、新たな再送要求を行なうことができるので、受信側に到着する可能性のあるパケットデータの到着を確認してから再送要求を実施することができる。よって無駄な再送要求を回避することができるというメリットがある。
【００６４】
一方、ステップ１４０１において、バッファ残留時間とパケット往復時間との差がパケット往復時間よりも短い場合には、バッファ残留時間をその時点で送出されていない、残りの必要な再送要求の回数で割った時間を再送要求の時間間隔として設定します。この再送間隔算出方法の動作を示した図を図１５に示します。
【００６５】
図１５図によれば、バッファリング時間の当初や再送要求の回数が少ない時点では、可能な限りパケット往復時間を用いて再送間隔を制御すると共に、パケット往復時間で制御できなくなった時点（すなわちパケット往復時間を待っているとバッファリング時間を過ぎて受信されるべきパケットデータが利用されなくなってしまう場合）で、残りの必要な再送回数分の再送要求をまとめて発行する。この方法により最終的な誤り率を目標値まで下げながら、再送要求当初における無駄な再送要求を減らし、ネットワーク全体として伝送帯域を無駄に使用しないようにすることが可能となる。
【００６６】
これを一般化した場合を以下に示す。ｎ回目の再送要求時の誤り率をe(n)、最終的な誤り率の目標値をefinalとした場合の必要最大再送回数をNrtxと定義する。オリジナルのパケット数を１とした場合の再送要求パケット率は、数式３で求めることができる。
【００６７】
【数１】

【００６８】
再送による冗長量を最小に抑えるためには、この数式３の再送要求パケット率を最小にする必要がある。ここで、n回目の再送要求時の誤り率e(n)は、時刻tによって変化する値とみることができる。そのため、数式３の再送要求パケット率を最小にするtの値を各再送要求に対し算出することで、最小の冗長量で目標とする最終誤り率を得ることが可能となる。
【００６９】
本発明の第１の実施例および第２の実施例では、RTPにおけるRTCPのような制御信号も受信部１０１で受信を行い、解析部１０２で判別を行ってネットワークの状態判定に用いているが、データの受信と制御信号の受信を別々に行ったり、データの解析を別々の解析手段に行ったりするなどの変形も可能である。
【００７０】
【発明の効果】
本発明を用いることにより、パケットロスなどの誤りに対し再送を使ってデータを復元するシステムにおいて、再送要求や再送応答が誤った場合にも、複数回の再送により対応可能なシステムが提供可能となる。また、再送要求間隔や再送回数を制御することで、冗長を抑えて品質を確保する再送対応マルチメディアコンテンツ配信システムを提供することが可能となる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態におけるマルチメディアコンテンツ受信装置基本構成図
【図２】本発明の第１の実施形態における再送制御部の基本構成図
【図３】本発明の第１の実施形態における再送判定部の判定例を説明するフローチャート図
【図４】無駄な再送要求が発生する場合の例
【図５】本発明の再送間隔算定方法として再送間隔にパケット往復時間を利用する場合の図
【図６】本発明の第２の実施形態における再送制御部の基本構成図
【図７】本発明の第２の実施形態における再送制御部に対し再送間隔制御機能を追加した方式の構成図
【図８】本発明により複数回の再送要求を実施した場合の動作を示す図
【図９】複数回の再送要求とバッファリング時間の関係を表す図
【図１０】本発明の第２の実施形態における再送制御部に対し再送間隔制御機能を追加した方式の構成図２
【図１１】本発明によるバッファリング時間内で必要再送回数を実現する方式を示した図
【図１２】本発明の第２の実施形態における再送制御部に対し再送間隔制御機能を追加した方式の構成図３
【図１３】本発明の第２の実施形態における再送判定部の判定例を説明するフローチャート図
【図１４】本発明の第２の実施形態における再送間隔算出部での冗長量を考慮した再送間隔算出方法を説明するフローチャート図
【図１５】本発明の第２の実施形態における再送間隔算出部での冗長量を考慮した再送間隔算出方法による動作を示す図
【図１６】従来の再送制御に対応したマルチメディアコンテンツ受信装置基本構成図
【符号の説明】
１０１…受信部
１０２…解析部
１０３…バッファ部
１０４…再送制御部
１０５…リスト部
１０６…送信部
１０７…復号化部
１０８…出力部[0001]
BACKGROUND OF THE INVENTION
The present invention relates to an information transmission method for transmitting multimedia contents including encoded moving images, audio and still images using a wired communication network such as ISDN or the Internet, or a wireless communication network such as a mobile phone or a wireless LAN, and the like. The present invention relates to a multimedia content receiving apparatus and a multimedia content receiving method to which the method is applied.
[0002]
[Prior art]
In recent years, with the advancement of digital encoding technology for various information including multimedia contents such as moving images, still images, and voices, and the development of broadband network technology, the development of applications using these has become active. A system has been developed for transmitting a captured image or the like using a communication network.
[0003]
In particular, in recent years, with the spread of the Internet and intranet, applications and systems that packetize and transmit / receive data are increasing. Packetization is a very effective means for efficiently sharing the bandwidth of a communication path among a plurality of users. TCP / IP and UDP / IP exist as protocols for transmitting and receiving packet data on the Internet / Intranet. TCP / IP is robust against errors because it incorporates a framework such as retransmission, and is effective for download-type applications that want to receive data correctly even if it takes some time. On the other hand, UDP / IP does not have a re-transmission framework, but has no delay for re-transmission, etc., and is very effective for applications that require real-time performance.
[0004]
In the case of normal moving image communication, the image data has a very large amount of data, and in most cases does not fit in the network bandwidth. In that case, a method of encoding image data and transmitting the data after reducing the data amount is used. As compression coding techniques for moving image signals, techniques such as motion compensation, discrete cosine transform (DCT), subband coding, pyramid coding, variable length coding, etc., and methods combining these techniques have been developed. There are ISO MPEG-1, MPEG-2, ITU-T H.261, H.262, and H.263 as international standard systems for moving picture coding, and code strings that compress moving pictures and audio / audio signals. There are ISO MPEG systems, ITU-T H.221 and H.223 as international standard systems for multiplexing data and other data.
[0005]
The Internet and the like are connected through a myriad of networks, and it is normal not to know which network is in what state. In addition, since the amount of data flowing there fluctuates from moment to moment, a mechanism for determining how much data can be communicated in real time is necessary. Therefore, an application that uses a packet format called RTP, which advances one step further from a real-time application using UDP / IP, adds time information to a packet and transmits the packet, is increasing. By using RTP, time information and packet number are added to the packet, and the receiving side can display the voice and image using the correct time information, or judge the packet whose order has been changed on the network. It is now possible to detect lost packets by looking at the packet number. In addition, the RTP has a mechanism (RTCP) for notifying the jitter, the packet loss rate, and the like as supplementary information from the transmission side and the reception side. Furthermore, a mechanism for resending RTP packets is currently being discussed. Among these proposals, in addition to proposing a packet retransmission method, a function for adding priority to packets and controlling traffic so as not to retransmit all packets is added. However, there is no specific provision for this usage.
[0006]
The IETF also defines RTSP as a session management protocol between a transmission terminal and a reception terminal for establishing image communication as described above, and SDP, which is a language specification for describing the contents of image content. As a result, it is possible to control the start of the session, the start of transmission of multimedia contents, the suspension, the end of the session, and the like by RTSP between the server and the client.
[0007]
Under these circumstances, when images are transmitted over the Internet / Intranet, the bandwidth of the raw image transmission cannot be secured in the network bandwidth, so the image signal is compressed with an encoding method such as MPEG as described above. It is necessary to send it. This is effective in reducing the amount of data, but on the other hand, it becomes very fragile against packet loss and mixing errors caused by flowing data over the unstable Internet. This is because a moving image encoding method transmits only a difference from the previous frame, and a part of the data is lost. When UDP or RTP is used, data is not retransmitted basically, so countermeasures against this problem are required.
[0008]
For the purpose of responding to this, the establishment of a standard for retransmission of RTP has been carried out by the IETF (The Internet Engineering Task Force). In short, the protocol called AVPF is used, and the packet number that could not be received is notified to the sending side with a command called NACK. The transmitting side identifies the packet lost from this NACK, constructs a header according to the RTP retransmission standard, and transmits it to the receiving side. Furthermore, since RTP is mainly used for real-time communication, a technique has been proposed in which a packet that cannot be displayed in time even if it is retransmitted is controlled.
[0009]
The structural example of the receiver disclosed by patent document 1 is shown. The packet data transmitted from the transmission side is received by the receiving unit 1601 and the packet analysis unit 1602 reads the packet header and the like to obtain the packet number, time stamp, and the like. The communication path state calculation unit 1603 calculates packet loss, delay amount, and the like of this information 1632 and the communication path state information transmission unit 1604 transmits the information 1632 to the transmission side using RTCP or the like. Further, the packet analysis information 1632 and the communication path state information 1634 are input to the retransmission determination unit 1605, and it is determined whether or not to request retransmission. The NACK signal 1635 as described above is generated from the packet number or the like where the packet loss has occurred, and the retransmission request transmission unit 1606 notifies the transmission side. On the other hand, the received packet data 1636 is temporarily stored in the packet buffer unit 1607, and after adjusting the order together with the packet sent by retransmission or the like, the packet data 1636 is sent to the decoding unit 1608 to perform decoding processing according to the data, Playback is performed on the display unit 1609.
[0010]
However, in the configuration disclosed in Patent Document 1, when the network error rate is high or when the transmission delay is large, the retransmission request or the retransmission response itself is erroneous, and the probability of error recovery due to retransmission is not so high. was there.
[0011]
In addition, since there is a delay until the retransmission packet arrives and there is a possibility that it may not be in time for real-time reproduction, it has been proposed to use retransmission for recording purposes. In that case, there was a problem that the efficiency was poor, although it was devised to transmit the retransmitted packet by using reliable TCP instead of transmitting it by the same low reliability UDP as in real time. .
[0012]
[Patent Document 1]
JP 2002-84338 A
[0013]
[Problems to be solved by the invention]
In the prior art, RTP feedback information (RTCP), retransmission control (RTP Retransmission), etc. have been proposed and standardized as network protocols, but how RTCP and retransmission should be used is presented. There wasn't. As a method of issuing a retransmission request, as shown in the conventional example, there is a contrivance not to transmit a retransmission packet that is not in time for real-time reproduction, but basically a retransmission request is issued for a packet that has not arrived. It was a stance.
[0014]
However, this has a problem that when the network error rate is high or when the transmission delay is large, the retransmission request or the retransmission response itself is erroneous, and the probability of error recovery by retransmission does not increase so much.
[0015]
[Means for Solving the Problems]
In the present invention, the receiving means for receiving the packetized multimedia content data, the analyzing means for analyzing the reception state of the packet data received by the receiving means, and requesting retransmission from the result analyzed by the analyzing means A retransmission control unit that determines whether there is packet data to be transmitted and outputs a retransmission request signal of the packet data, a retransmission list unit that holds a result determined by the retransmission control unit, and a retransmission control unit There is provided a multimedia content receiving apparatus comprising transmission means for transmitting output retransmission request information to a transmission side and buffer means for temporarily holding packet data received by the reception means.
[0016]
The multimedia content receiving apparatus of the present invention is characterized by comprising decoding means for decoding the packet data held in the buffer means and output means for outputting the decoded multimedia content.
[0017]
Also, in the multimedia content receiving apparatus of the present invention, the retransmission control means resends again when a response to the retransmission request cannot be obtained after a round-trip time of the packet has elapsed from the time when the previous retransmission request signal was transmitted. Control is performed to output a request signal.
[0018]
In the multimedia content receiving apparatus according to the present invention, the retransmission control means controls to hold a maximum number of retransmissions and repeatedly output a retransmission request signal so as not to exceed the maximum number of retransmissions.
[0019]
In the multimedia content receiving apparatus of the present invention, the retransmission control means outputs a retransmission request signal based on a retransmission request interval determined from the held maximum number of retransmissions and a buffering time of packet data in the buffer means. It is characterized by doing.
[0020]
In the present invention, the step of receiving packetized multimedia content data, the step of analyzing the reception state of the received packet data, and determining whether there is packet data to be retransmitted from the analyzed result Outputting a retransmission request signal of the packet data, holding a result determined by the retransmission request signal output step, transmitting the retransmission request information to a transmitting side, and receiving the received data And a step of temporarily storing the packet data in a buffer.
[0021]
The multimedia content receiving method according to the present invention includes a step of decoding the packet data held in the buffer and a step of outputting the decoded multimedia content.
[0022]
Also, in the multimedia content receiving method of the present invention, the retransmission request signal output step, when a response to the retransmission request cannot be obtained after the round-trip time of the packet has elapsed from the time when the previous retransmission request signal was transmitted, The retransmission request signal is output again.
[0023]
In the multimedia content receiving method of the present invention, the retransmission request signal output step holds the maximum number of retransmissions and outputs a repeated retransmission request signal so as not to exceed the maximum number of retransmissions.
[0024]
Also, in the multimedia content receiving method of the present invention, the retransmission request signal output step includes a retransmission request signal based on a retransmission request interval determined from a held maximum number of retransmissions and a packet data buffering time in the buffer means. Is output.
[0025]
DETAILED DESCRIPTION OF THE INVENTION
(First embodiment)
FIG. 1 is a basic configuration diagram of a multimedia content receiving apparatus according to the first embodiment of the present invention. Multimedia content data such as video (video, still image), audio, text (text data) transmitted from the sender via a wired line such as the Internet or a wireless line such as a mobile phone, PHS, and wireless LAN Received by the receiving unit 101. The reception data 131 is input to the analysis unit 102, and the type of the received multimedia content data, the packet header, and the like are analyzed to verify whether the reception has been correctly performed. Next, the data 132 from which information necessary for transmission such as a packet header is removed is sent to the buffer unit 103, and then the data such as image and sound is decoded by the decoding unit 107, and the image display unit and the audio output unit Is output to the output unit 108 including
[0026]
Here, as a result of packet analysis by the analysis unit 102, when a packet to be received is not received due to discontinuity of the packet order, particularly when a packet to be received is lost (packet loss). Passes the lost packet information 134 to the retransmission control unit 104. The retransmission control unit 104 generates a lost packet retransmission request 137 from the lost packet information 134 and sends a retransmission request from the transmission unit 106 to the transmission side via the transmission line. The retransmission information 135 in the retransmission control unit 104 is sent to the list unit 105 and stored / managed. The retransmission control unit 104 reads the retransmission information 136 stored in the list unit 105 and determines whether or not to newly generate a retransmission request 137.
[0027]
A feature of the present invention is that it includes not only an analysis unit that analyzes received packets, but also a list unit 105 that holds at least one of lost packet information, issued retransmission request information, received retransmission packet information, and the like. It is in having. When the retransmission control unit 104 reads out the information 136 stored in the list unit 105, it is possible to determine whether or not to issue a retransmission request, control the timing for issuing the retransmission request, and the like.
[0028]
In the first embodiment, when the analysis unit 102 detects that a packet loss has occurred, the retransmission control unit 104 receives the information 134, creates a retransmission request 137, and transmits it to the transmission side. Unlike this, even if a packet loss occurs on the transmission line and this is detected on the receiving side, the retransmission control unit 104 does not immediately generate the retransmission request 137 but sends it to the list unit 105 once. A method of creating a retransmission request 137 by the retransmission control unit 104 according to only the output 136 from is also possible. Once the packet loss information is stored in the list part, it becomes possible to easily control the time interval for issuing the retransmission request and the transmission band used when the retransmission request is transmitted.
[0029]
In the first embodiment, the analysis unit 102 may observe a packet reception state to have a function of estimating and calculating a communication path state. In this case, the state of the transmission path estimated and calculated on the receiving side can be transferred to the retransmission control unit 104 and transmitted from the transmitting unit 106 to the transmitting side. Thereby, on the transmission side, packet transmission control can be performed in consideration of the state of the transmission path.
[0030]
Here, when a retransmission request is sent from the reception side, or when a lost packet is retransmitted from the transmission side in response to the retransmission request, a further retransmitted packet is received depending on the state of the transmission path and communication network on the way. Cannot be received (packet loss), and a packet requested for retransmission on the receiving side may not be received. Therefore, the improved receiving side supports issuing multiple retransmission requests.
[0031]
A block diagram of the retransmission control unit 104 having this function is shown in FIG. The analysis result information 134 of the received packet of the analysis unit 102 is input to the retransmission interval calculation unit 201, and calculates a time interval (ΔT) 231 for issuing a retransmission request from the current network state. This value 231 is input to the retransmission determination unit 202, and compared with the packet loss information 136 stored in the list unit 105, it is determined whether a retransmission request is necessary again. Using the determination result 231, the retransmission request generation unit 203 creates a retransmission request 137 and sends it to the transmission unit 106.
[0032]
The configuration of the retransmission control unit 104 is an example, and it is also possible to input the analysis information 134 only to the retransmission determination unit 202 and pass data from the retransmission determination unit 202 to the retransmission interval calculation unit 201 to calculate the retransmission interval. . Any configuration can be used to obtain the effect of the present invention as long as the retransmission control unit can realize a function for determining whether or not to request retransmission from packet information lost in packet and quality information such as network delay and packet loss rate. It is.
[0033]
FIG. 3 is a flowchart showing a basic method for determining whether or not to perform a retransmission request performed by the retransmission determination unit 202.
[0034]
In step 301, the packet loss packet information 136 obtained from the list unit 105 (specifically, the packet loss packet ID (identification number), time information at the time of the previous retransmission request, etc.) is acquired. Next, in step 302, it is determined whether or not the value obtained by subtracting the previous retransmission request time from the current time is larger than the retransmission interval ΔT calculated by the retransmission interval calculation unit 201. If the time interval is large, the previous retransmission request sent from the receiving side did not reach the sending side due to an error in the transmission path, or the receiving side sent the retransmission request to the sending side, but the sending side It is determined that the retransmitted packet did not reach the receiving side due to the congestion of the transmission path, the quality of the transmission path, etc., and the packet was lost again. In step 303, a retransmission request is made again. On the other hand, if the determination in step 302 is false, it waits for a retransmission response from the transmission side, and controls so that no retransmission request is made from the reception side until a predetermined time interval ΔT has elapsed.
[0035]
After determining that the previous (first) retransmission request from the receiving side or the response from the transmitting side is discarded due to an error in the network or the like and the response is not returned to the receiving side, the receiving side again (second time) Depending on how this time interval is determined, there may be a case where a response to the previous (first) retransmission request arrives at the receiving side after a second (second) retransmission request is made. . In that case, the last (second and subsequent) retransmission request becomes a useless request. A time chart showing this situation is shown in FIG.
[0036]
For example, it is assumed that packet #n transmitted from the transmission side cannot be received on the reception side. On the receiving side, after receiving packet # n-1, if packet #n is not received even after a certain time has passed, or packet # n + 1 is received before receiving packet #n, It is determined that packet #n is “lost”. Then, the notification (retransmission request) is notified to the transmitting side that “the packet #n has not been received and is retransmitted”. If the packet #n cannot be received after the retransmission request is transmitted here, if the retransmission request is transmitted again before a significant time elapses, the packet #n is retransmitted from the transmission side. There is a possibility that the second (second) retransmission request is wasted.
[0037]
Even in such a case, it is possible to suppress useless packet retransmission requests by estimating the round trip time of the packet and controlling the retransmission time interval ΔT. A diagram illustrating this scheme is shown in FIG.
[0038]
In some cases, the round-trip time of packets traveling on the transmission path can be acquired by a communication protocol or a specific application. In that case, it can be realized by using this and setting a time longer than the round trip time as the retransmission time interval ΔT. For example, in the case of a protocol such as RTP, it is possible to calculate the round trip time of the packet on the sending side by using RTCP. However, the round trip time of the packet is usually used in the receiving side terminal that only receives packet data. Information cannot be obtained.
[0039]
Therefore, send the packet round-trip time information separately from the sender or send the RTCP sender information (Sender Report: SR) even when the packet is not sent, and calculate the packet round-trip time using the response Thus, it is necessary to obtain the packet round trip time. In other methods, for example, the one-way transmission time of a packet is calculated from the difference between the time information (time stamp) added to the packet, such as RTP, and the reception time when it is received on the receiving side, and twice the packet round-trip time is calculated. It is also possible to apply a method of estimating the round trip time on the assumption of time and using it. Depending on the network, the round trip time may be different (when the transmission speed of the upstream / downstream communication path is asymmetric), in which case the round trip time setting should be adjusted using a value suitable for the network, not twice. It is possible to cope with.
[0040]
In addition, it is possible to calculate the retransmission interval in consideration of not only the packet round-trip time but also the processing delay until the retransmission side receives the retransmission request and transmits the retransmission response.
[0041]
This retransmission interval can be calculated when the delay time of the network is known in advance, or when the value initially calculated at the start of communication can be used fixedly. It is also possible to adopt a method of dynamically determining the retransmission interval by analyzing the current state every time a packet is received and recalculating the retransmission interval at that time. The calculation timing can be performed every time a packet is received or at intervals. It is also possible to employ a calculation method that takes into consideration the previous network state so that it is not strongly influenced by local fluctuations.
[0042]
(Second Embodiment)
When the error rate and packet loss rate can be obtained from the analysis of the network state from the transmission side to the reception side, a method for obtaining the necessary number of retransmissions based on such network information is also possible. As a result, it is possible to make the quality after the retransmission conform to the required specifications to some extent.
[0043]
FIG. 6 shows a basic configuration diagram of the retransmission control unit 104 corresponding to such a method. The present system is characterized in that the configuration of FIG. 6 includes a retransmission number calculation unit 601 instead of the retransmission interval calculation unit 201 of FIG. The retransmission number calculation unit 601 calculates the number of retransmission requests necessary to guarantee the content quality from the analysis result information 134 regarding the packet loss by the analysis unit 102. The necessary retransmission number information 631 is sent to the retransmission determination unit 202, performs retransmission request determination 232 from the packet loss information 136 in the list unit 105, generates a retransmission request 137 by the retransmission request generation unit 203, and transmits it from the transmission unit 106. .
[0044]
Furthermore, by having a means for determining the retransmission interval at the same time, it is possible to perform the required number of retransmissions based on the calculated retransmission interval. A basic configuration diagram of this method is shown in FIG.
[0045]
In this method, the retransmission interval calculation unit 201 and the retransmission number calculation unit 601 coexist, and whether the retransmission interval information 231 and the retransmission number information 631, which are the respective outputs, are sent to the retransmission determination unit 202 and whether a retransmission request is made. Is determined.
[0046]
FIG. 8 shows a flow of procedures on the transmission side and the reception side when performing retransmission a plurality of times. In this example, a case will be described in which it is assumed that the n-th packet transmitted on the transmission side has lost a packet on the transmission path, and a retransmission request for the packet is transmitted. Once (the first) #n packet data retransmission urgent signal is sent from the receiving side, and then the receiving side waits for the estimated retransmission interval and waits for the arrival of #n packet data. If #n packet data is not received even after the estimated retransmission time interval has elapsed, the second retransmission request signal is sent so that the packet data of #n has not arrived and is transmitted to the receiving side again. Is sent to the sending side. Further, in this example, the second retransmission response (#n packet data) sent from the transmission side cannot be received by the reception side, and the (third) retransmission request is transmitted to the transmission side again. On the other hand, a state in which #n packet data transmitted from the transmission side is received as a retransmission response is shown.
[0047]
Normally, the data received by the buffer unit 103 is temporarily stored, and is output to the subsequent decoding unit 107 and output unit 108 after a certain time. The above method is basically effective when the time (buffering time) in which data is stored in the buffer unit 103 is longer than the (number of retransmissions) × (retransmission interval) (a sufficiently long time). If the value of the number of retransmissions times the retransmission interval is longer than the buffering time, the subsequent retransmission request will not be in time for decoding or display, and will be a useless packet that cannot be used even if it can be received. An example of this is shown in FIG. The reception side requested retransmission twice, but the response from the transmission side (#n packet data) did not reach the reception side and was sent in response to the third retransmission request from the reception side. Although the packet data of #n has reached the receiving side, it has been received beyond the buffering time defined on the receiving side, and is discarded without being decoded.
[0048]
In order to solve this problem, a method for controlling the retransmission interval in consideration of the buffering time will be described below. A basic configuration diagram of this system is shown in FIG.
[0049]
Analysis result information 134 of lost packet data from the analysis unit 102 is input to the retransmission interval calculation unit 201 and the retransmission count calculation unit 601. The necessary retransmission number information 1031 calculated by the retransmission number calculation unit 601 is input to the retransmission interval calculation unit 201. The retransmission interval calculation unit 201 calculates the retransmission interval from the retransmission number information 1031, the network state information 134 obtained from the analysis unit, and the buffering time information of the receiving apparatus. For example, it can be obtained by an equation such as Equation 1.
(Retransmission interval) = (Buffering time) / (Number of retransmissions) ... Equation 1
In this method, the time length of the retransmission interval is set regardless of the network state information, but it is possible to ensure that the necessary number of retransmissions are performed within the buffering time.
Further, since it is necessary to return the response of the last retransmission request within the buffering time, this equation can be developed and Equation 2 can be used.
(Retransmission interval) = (Buffering time−Packet round-trip time) / (Retransmission count)
Here, as described above, in addition to the actually measured value, a value including the processing time on the transmission side, a value estimated from the one-way packet transmission time, and the like can be used as the packet round-trip time. An example of a method for controlling the retransmission interval in consideration of the buffering time is shown in FIG.
[0050]
In FIG. 11, when packet data of #n is lost and cannot be received, #n arrives within the buffering time on the receiving side, assuming that the transmission line condition is bad, up to 3 times The buffering time is divided into three times without waiting for a response to the first and second retransmission request signals (regardless of arrival) so that the retransmission request can be transmitted to the transmission side. An example in which retransmission requests are transmitted equally within the network is shown.
[0051]
Furthermore, a method of changing the retransmission interval depending on the number of retransmission requests is also applicable. A basic configuration diagram for realizing this method is shown in FIG.
[0052]
In the retransmission interval calculation unit 201, in addition to the retransmission number information 1031 and the network status information 134 obtained from the analysis unit and the buffering time information of the receiving device, the number of retransmission requests or when there is no transmission path error Among the values such as the time elapsed since the reception of the (normal) packet and the time information and the packet number information of the data currently output from the buffer unit 103, a value 1231 required for retransmission interval calculation is received. This makes it possible to calculate a retransmission interval that is most suitable for the network state at that time, and to reduce unnecessary retransmission requests and the like.
[0053]
FIG. 13 shows an operation flowchart in the retransmission control unit 104, particularly the retransmission determination unit. In step 1301, network state information (for example, reception time of received packet data, ID of packet data that could not be received: identification number) related to the received packet data analyzed by the analysis unit 102, especially packet loss rate (disappeared) The required number of retransmissions is calculated using the packet data ratio).
[0054]
In step 1302, a retransmission interval ΔT is obtained from the calculated required number of retransmissions. At that time, as described above, it is possible to calculate the time interval regardless of the state of the transmission path, and the receiving side can accept the delay time acceptable on the receiving side, the buffering time on the receiving side, It is also possible to calculate in consideration of the time (packet round-trip time) that normally takes until the requested packet data arrives after transmission.
[0055]
In step 1303, it is determined whether there is packet loss information regarding lost packet data from the list unit 105 to the list unit. If there is packet loss information, the packet information is acquired from the list in step 1304. If there is no packet loss information in the list unit 105, the retransmission request process is terminated.
[0056]
In step 1305, it is determined whether or not the difference between the current time and the previous retransmission request time is larger than the retransmission request interval ΔT. If step 1305 is determined to be true (if the difference between the current time and the previous retransmission request time is greater than the retransmission request interval ΔT), a retransmission request is made again at step 1306. If it is determined in step 1305 that it is false (the difference between the current time and the previous retransmission request time is not larger than the retransmission request interval ΔT), the processing in this unit is terminated as it is, and the next retransmission determination processing is performed as necessary. To do.
[0057]
In addition to the processing shown in this flowchart, other methods, for example, step 1303 for determining whether there is a packet loss is performed at the beginning of this processing, and if there is no packet loss, the next determination is made without doing anything. A determination method such as depression is also possible.
[0058]
As another modification of this determination method, when the maximum or minimum value is determined in advance for at least one of the number of retransmissions or the retransmission interval, and the calculation result exceeds this range There is a method of forcibly resetting the value. As a result, it is possible to prevent an extreme number of retransmissions and a retransmission interval and to ensure that the system operates stably.
[0059]
As a method for calculating the number of retransmissions performed in the present invention, a method is effective in which the error rate of the network is measured and the number of retransmissions is calculated to calculate the target error rate after retransmission. As a result, the quality of data output from the buffer unit 103 can be maintained.
[0060]
As for the retransmission interval, the fixed interval method using Equation 1 or Equation 2 is easy to use as described above. However, in an environment where errors occur periodically or when the retransmission interval is shorter than the packet round-trip time, there is a possibility that the effect will not be improved or there will be many unnecessary retransmission requests. Therefore, it is also possible to use a method in which the retransmission request interval is set at non-equal intervals.
[0061]
As a method of setting the retransmission interval to be non-uniform, there is a method of multiplying a random number to obtain the retransmission interval. For example, a method of using a value obtained by multiplying the obtained retransmission interval by a random number between 0.5 and 1.5 as the retransmission interval.
[0062]
In addition to this, set the time interval of the retransmission request in the first (the number of retransmission requests is small) longer, and set the time interval of the retransmission request in the back (the number of retransmission requests is large, just before the end of the buffering time). A shortening method is also effective. An example of the retransmission interval calculation method of this method is shown in the flowchart of FIG.
[0063]
Assuming that the time from when a packet is received by the buffer unit 103 until it is output at a certain point in time is called the buffer remaining time of the packet, first, in step 1401, the “difference between the buffer remaining time and the packet round-trip time” is It is determined whether or not it is larger than the packet round-trip time. If the difference between the buffer remaining time and the packet round-trip time is larger than the packet round-trip time, go to Step 1402. In step 1402, the packet round trip time is used as the retransmission interval. As a result, it is possible to wait for the packet round-trip time (on average, the time from when the retransmission request is transmitted until the requested packet data arrives at the receiving side), so that a new retransmission request can be made. It is possible to make a retransmission request after confirming the arrival of packet data that may be transmitted. Therefore, there is a merit that a useless retransmission request can be avoided.
[0064]
On the other hand, if the difference between the buffer remaining time and the packet round-trip time is shorter than the packet round-trip time in step 1401, the buffer remaining time is divided by the number of remaining required retransmission requests that have not been sent at that time. Set the time as the time interval between retransmission requests. Figure 15 shows the operation of this retransmission interval calculation method.
[0065]
According to FIG. 15, at the beginning of the buffering time or when the number of retransmission requests is small, the retransmission interval is controlled using the packet round-trip time as much as possible, and the point when the packet round-trip time cannot be controlled (that is, the packet When waiting for the round-trip time, the packet data that should be received after the buffering time is not used), and the retransmission requests for the remaining necessary number of retransmissions are issued together. With this method, it is possible to reduce the wasteful retransmission request at the beginning of the retransmission request while reducing the final error rate to the target value, so that the entire network does not waste the transmission band.
[0066]
The case where this is generalized is shown below. The required maximum number of retransmissions is defined as Nrtx when the error rate at the n-th retransmission request is e (n) and the final target error rate is final. The retransmission request packet rate when the number of original packets is 1 can be obtained by Equation 3.
[0067]
[Expression 1]

[0068]
In order to minimize the amount of redundancy due to retransmission, it is necessary to minimize the retransmission request packet rate of Equation 3. Here, the error rate e (n) at the time of the n-th retransmission request can be regarded as a value that changes with time t. Therefore, by calculating the value of t that minimizes the retransmission request packet rate in Equation 3 for each retransmission request, it is possible to obtain the target final error rate with the minimum amount of redundancy.
[0069]
In the first and second embodiments of the present invention, a control signal such as RTCP in RTP is also received by the receiving unit 101 and discriminated by the analyzing unit 102 and used for determining the network status. Modifications such as receiving data and receiving control signals separately, or analyzing data to different analyzing means are also possible.
[0070]
【The invention's effect】
By using the present invention, it is possible to provide a system that can cope with an error such as a packet loss by resending data in response to a plurality of retransmissions even if a retransmission request or a retransmission response is incorrect. Become. In addition, by controlling the retransmission request interval and the number of retransmissions, it is possible to provide a retransmission-compatible multimedia content distribution system that secures quality while suppressing redundancy.
[Brief description of the drawings]
FIG. 1 is a basic configuration diagram of a multimedia content receiving apparatus according to a first embodiment of the present invention.
FIG. 2 is a basic configuration diagram of a retransmission control unit in the first embodiment of the present invention.
FIG. 3 is a flowchart for explaining a determination example of a retransmission determination unit according to the first embodiment of the present invention.
FIG. 4 shows an example when a useless retransmission request occurs.
FIG. 5 is a diagram when a packet round-trip time is used for a retransmission interval as a retransmission interval calculation method according to the present invention.
FIG. 6 is a basic configuration diagram of a retransmission control unit in the second embodiment of the present invention.
FIG. 7 is a configuration diagram of a scheme in which a retransmission interval control function is added to the retransmission control unit in the second embodiment of the present invention.
FIG. 8 is a diagram illustrating an operation when a plurality of retransmission requests are performed according to the present invention.
FIG. 9 is a diagram showing the relationship between multiple retransmission requests and buffering time
FIG. 10 is a configuration diagram of a scheme in which a retransmission interval control function is added to the retransmission control unit in the second embodiment of the present invention.
FIG. 11 is a diagram showing a method for realizing the required number of retransmissions within the buffering time according to the present invention.
FIG. 12 is a configuration diagram of a scheme in which a retransmission interval control function is added to the retransmission control unit in the second embodiment of the present invention.
FIG. 13 is a flowchart for explaining a determination example of a retransmission determination unit according to the second embodiment of the present invention.
FIG. 14 is a flowchart for explaining a retransmission interval calculation method considering a redundancy amount in a retransmission interval calculation unit according to the second embodiment of the present invention.
FIG. 15 is a diagram illustrating an operation according to a retransmission interval calculation method considering a redundancy amount in a retransmission interval calculation unit according to the second embodiment of the present invention.
FIG. 16 is a basic configuration diagram of a multimedia content receiving apparatus corresponding to conventional retransmission control.
[Explanation of symbols]
101: Receiver
102 ... analysis unit
103: Buffer part
104 ... retransmission control unit
105 ... List section
106: Transmitter
107: Decoding unit
108: Output unit

Claims

パケット化されたマルチメディアコンテンツデータを受信する受信手段と、
前記受信手段で受信したパケットデータの受信状態を解析する解析手段と、
前記受信手段で受信されたパケットデータを一時的に保持するバッファ手段と
前記解析手段により解析された結果から再送を要求すべきパケットデータがあるかどうか判定して当該パケットデータの再送要求信号を、最大再送回数および前記バッファ手段におけるパケットデータのバッファリング時間から決定される再送要求間隔に基づいて、前記最大再送回数を越えないように繰り返し出力する再送制御手段と、
前記再送制御手段により判定された結果を保持しておく再送リスト手段と、
前記再送制御手段により出力された再送要求情報を送信側に送信する送信手段と、
を有することを特徴とするマルチメディアコンテンツ受信装置。Receiving means for receiving packetized multimedia content data;
Analyzing means for analyzing the reception state of the packet data received by the receiving means;
A retransmission request signal of the packet data to determine whether there is packet data to be requested to retransmit the results analyzed by the buffer means and said analyzing means for temporarily holding the received packet data in the receiving means, Based on a retransmission request interval determined from the maximum number of retransmissions and the buffering time of packet data in the buffer unit, retransmission control means for repeatedly outputting so as not to exceed the maximum number of retransmissions ;
Retransmission list means for holding the result determined by the retransmission control means;
Transmitting means for transmitting the retransmission request information output by the retransmission control means to the transmitting side;
A multimedia content receiving apparatus comprising:

前記バッファ手段に保持されたパケットデータを復号する復号化手段と、
復号されたマルチメディアコンテンツを出力する出力手段と、
を有することを特徴とする請求項１記載のマルチメディアコンテンツ受信装置。Decoding means for decoding the packet data held in the buffer means;
An output means for outputting the decrypted multimedia content;
The multimedia content receiving apparatus according to claim 1, further comprising:

前記再送制御手段は、前回の再送要求信号を送信した時刻からパケットの往復時間を経過した後、当該再送要求に対する応答が得られない場合に、再度再送要求信号を出力するよう制御する
ことを特徴とする請求項１または２記載のマルチメディアコンテンツ受信装置。The retransmission control means controls to output a retransmission request signal again when a response to the retransmission request is not obtained after a round-trip time of the packet has elapsed from the time when the previous retransmission request signal was transmitted. The multimedia content receiving apparatus according to claim 1 or 2.

パケット化されたマルチメディアコンテンツデータを受信するステップと、
受信したパケットデータの受信状態を解析するステップと、
前記受信されたパケットデータをバッファに一時的に保持するステップと、
解析された結果から再送を要求すべきパケットデータがあるかどうか判定して当該パケットデータの再送要求信号を、最大再送回数と前記バッファ手段におけるパケットデータのバッファリング時間とから決定される再送要求間隔に基づいて、前記最大再送回数を越えないように繰り返し出力するステップと、
前記再送要求信号出力ステップにより判定された結果を保持しておくステップと、
前記再送要求情報を送信側に送信するステップと、
を有することを特徴とするマルチメディアコンテンツ受信方法。Receiving packetized multimedia content data; and
Analyzing the reception status of the received packet data;
Temporarily holding the received packet data in a buffer;
Based on the analyzed result, it is determined whether there is packet data to be requested for retransmission, and a retransmission request signal for the packet data is determined based on the maximum number of retransmissions and the packet data buffering time in the buffer means. And repeatedly outputting so as not to exceed the maximum number of retransmissions ,
Holding the result determined by the retransmission request signal output step;
Transmitting the retransmission request information to a transmission side;
A multimedia content receiving method comprising:

前記バッファに保持されたパケットデータを復号するステップと、
復号されたマルチメディアコンテンツを出力するステップと、
を有することを特徴とする請求項４記載のマルチメディアコンテンツ受信方法。Decoding packet data held in the buffer;
Outputting the decrypted multimedia content;
The multimedia content receiving method according to claim 4, further comprising:

前記再送要求信号出力ステップは、前回の再送要求信号を送信した時刻からパケットの往復時間を経過した後、当該再送要求に対する応答が得られない場合に、再度再送要求信号を出力する
ことを特徴とする請求項４または５記載のマルチメディアコンテンツ受信方法。The retransmission request signal output step outputs the retransmission request signal again when a response to the retransmission request cannot be obtained after the round-trip time of the packet has elapsed from the time when the previous retransmission request signal was transmitted. The multimedia content receiving method according to claim 4 or 5.

コンピュータを、
パケット化されたマルチメディアコンテンツデータを受信する受信手段と、
前記受信手段で受信したパケットデータの受信状態を解析する解析手段と、
前記受信手段で受信されたパケットデータを一時的に保持するバッファ手段と
前記解析手段により解析された結果から再送を要求すべきパケットデータがあるかどうか判定して当該パケットデータの再送要求信号を、最大再送回数および前記バッファ手段におけるパケットデータのバッファリング時間から決定される再送要求間隔に基づいて、前記最大再送回数を越えないように繰り返し出力する再送制御手段と、
前記再送制御手段により判定された結果を保持しておく再送リスト手段と、
前記再送制御手段により出力された再送要求情報を送信側に送信する送信手段と、
を有するマルチメディアコンテンツ受信装置として機能させるためのプログラム。Computer
Receiving means for receiving packetized multimedia content data;
Analyzing means for analyzing the reception state of the packet data received by the receiving means;
Buffer means for temporarily holding the packet data received by the receiving means, and determining whether there is packet data that should be retransmitted from the result analyzed by the analyzing means, a retransmission request signal for the packet data, Based on a retransmission request interval determined from the maximum number of retransmissions and the buffering time of packet data in the buffer unit, retransmission control means for repeatedly outputting so as not to exceed the maximum number of retransmissions;
Retransmission list means for holding the result determined by the retransmission control means;
Transmitting means for transmitting the retransmission request information output by the retransmission control means to the transmitting side;
A program for causing a multimedia content receiving apparatus to function.

前記バッファ手段に保持されたパケットデータを復号する復号化手段と、
復号されたマルチメディアコンテンツを出力する出力手段と、
を有することを特徴とする請求項７記載のプログラム。Decoding means for decoding the packet data held in the buffer means;
An output means for outputting the decrypted multimedia content;
The program according to claim 7, comprising:

前記再送制御手段は、前回の再送要求信号を送信した時刻からパケットの往復時間を経過した後、当該再送要求に対する応答が得られない場合に、再度再送要求信号を出力するよう制御する
ことを特徴とする請求項７または８記載のプログラム。The retransmission control means controls to output a retransmission request signal again when a response to the retransmission request is not obtained after a round-trip time of the packet has elapsed from the time when the previous retransmission request signal was transmitted. The program according to claim 7 or 8.