(57)【要約】【課題】  従来、従来のストリーミングデータ伝送装置及び伝送方法は、伝送時のパケットロスを防ぐためには再送制御を必要とするが、逆にリアルタイム性を追求することが困難になるという問題を抱えていた。【解決手段】  上記課題を解決するべく、ストリーミングデータを送信バッファメモリ４に蓄積し、再送制御によって送信データの品質を保証する第１の送信プロトコル及び再送制御を行なわない第２の送信プロトコルのいずれかに基づいて前記バッファメモリ４に蓄積されたデータをネットワーク装置６から送信する。この場合、前記バッファメモリ４の空き容量をＣＰＵ７で検出し、検出されたバッファメモリ４の空き容量に応じて前記ネットワーク装置６の送信プロトコルをＣＰＵ７により切り換えるようにした。【選択図】  図１
2005167780.tif 000002
【特許請求の範囲】
【請求項１】
ストリーミングデータを蓄積するためのバッファメモリと、再送制御によって送信データの品質を保証する第１の送信プロトコル及び再送制御を行なわない第２の送信プロトコルのいずれかに基づいて前記バッファメモリに蓄積されたデータを送信する送信手段と、前記メモリの空き容量を検出する手段と、この検出手段で検出されたメモリの空き容量に応じて前記送信手段の送信プロトコルを切り換える手段とを具備したことを特徴とするストリーミングデータ伝送装置。
【請求項２】
請求項１記載のストリーミングデータ伝送装置において、前記送信プロトコル切換手段は、前記バッファメモリの空き容量に余裕がある場合は前記第１の送信プロトコルを選択し、前記バッファメモリの空き容量に余裕がない場合は前記第２の送信プロトコルを選択するよう前記送信手段の送信プロトコルを切り換えるよう構成されたことを特徴とするストリーミングデータ伝送装置。
【請求項３】
請求項１または２記載のストリーミングデータ伝送装置において、前記バッファメモリから出力されるデータパケットに対して連続番号を付加する手段を具備したことを特徴とするストリーミングデータ伝送装置。
【請求項４】
請求項１または２記載のストリーミングデータ伝送装置において、前記メモリ空き容量検出手段は、１つのパケットデータが前記送信手段から送信される毎に前記メモリの空き容量を検出するよう構成されたことを特徴とするストリーミングデータ伝送装置。
【請求項５】
ストリーミングデータをバッファメモリに蓄積するステップと、前記バッファメモリの空き容量を検出するステップと、この検出ステップで検出された前記バッファメモリの空き容量に応じ、再送制御によって送信データの品質を保証する第１の送信プロトコル及び再送制御を行なわない第２の送信プロトコルのいずれかを選択して前記バッファメモリに蓄積されたデータを送信するステップとを具備したことを特徴とするストリーミングデータ伝送方法。
【請求項６】
請求項５記載のストリーミングデータ伝送方法において、前記バッファメモリから出力されるデータパケットに対して第１、第２の送信プロトコルによらない連続番号を付加するステップを具備したことを特徴とするストリーミングデータ伝送方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストリーミングデータ伝送装置及び伝送方法に関する。
【背景技術】
【０００２】
ネットワークを利用して音楽や映像等のデータを配信し、受信側にて受信データをリアルタイムに再生するストリーミング伝送が広まりつつある。これは、配信されたデータを全て受信し終わるまで再生が出来ないということがなく、非常に便利である（例えば、特許文献１を参照）。
【０００３】
ところで、ストリーミング伝送では、伝送時のパケットロスを防ぐためには再送制御を必要とするが、逆にリアルタイム性を追求することが困難になるという相反した状況が生じていた。
【特許文献１】特開２００２−７７２５１号公報（第２頁乃至第６頁、図１）
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上述したように、従来のストリーミングデータ伝送装置及び伝送方法は、伝送時のパケットロスを防ぐためには再送制御を必要とするが、逆にリアルタイム性を追求することが困難になるという問題を抱えていた。
【０００５】
本発明はこのような点に鑑みてなされたもので、伝送時のパケットロスを減少させることが出来、かつリアルタイムにデータを送ることが可能なストリーミングデータ伝送装置及び伝送方法を提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記目的を達成するために、請求項１にかかるストリーミングデータ伝送装置は、ストリーミングデータを蓄積するためのバッファメモリと、再送制御によって送信データの品質を保証する第１の送信プロトコル及び再送制御を行なわない第２の送信プロトコルのいずれかに基づいて前記バッファメモリに蓄積されたデータを送信する送信手段と、前記メモリの空き容量を検出する手段と、この検出手段で検出されたメモリの空き容量に応じて前記送信手段の送信プロトコルを切り換える手段とを具備したことを特徴とするものである。
【０００７】
また、請求項２にかかるストリーミングデータ伝送装置は、請求項１記載のストリーミングデータ伝送装置において、前記送信プロトコル切換手段は、前記バッファメモリの空き容量に余裕がある場合は前記第１の送信プロトコルを選択し、前記バッファメモリの空き容量に余裕がない場合は前記第２の送信プロトコルを選択するよう前記送信手段の送信プロトコルを切り換えるよう構成されたことを特徴とするものである。
【０００８】
さらに、請求項３にかかるストリーミングデータ伝送装置は、  請求項１または２記載のストリーミングデータ伝送装置において、前記バッファメモリから出力されるデータパケットに対して連続番号を付加する手段を具備したことを特徴とするものである。
【０００９】
請求項４にかかるストリーミングデータ伝送装置は、請求項１または２記載のストリーミングデータ伝送装置において、前記メモリ空き容量検出手段は、１つのパケットデータが前記送信手段から送信される毎に前記メモリの空き容量を検出するよう構成されたこと
を特徴とするものである。
【００１０】
請求項５にかかるストリーミングデータ伝送方法は、ストリーミングデータをバッファメモリに蓄積するステップと、前記バッファメモリの空き容量を検出するステップと、この検出ステップで検出された前記バッファメモリの空き容量に応じ、再送制御によって送信データの品質を保証する第１の送信プロトコル及び再送制御を行なわない第２の送信プロトコルのいずれかを選択して前記バッファメモリに蓄積されたデータを送信するステップとを具備したことを特徴とするものである。
【００１１】
請求項６にかかるストリーミングデータ伝送方法は、請求項５記載のストリーミングデータ伝送方法において、前記バッファメモリから出力されるデータパケットに対して第１、第２の送信プロトコルによらない連続番号を付加するステップを具備したことを特徴とするものである。
【発明の効果】
【００１２】
本発明によれば、伝送時のパケットロスを減少させることが出来、かつリアルタイムにデータを送ることが可能なストリーミングデータ伝送装置及び伝送方法を提供することが出来る。
【発明を実施するための最良の形態】
【００１３】
以下、本発明になるストリーミングデータ伝送装置及び伝送方法の実施の形態について、図面を参照して説明する。
【００１４】
図１は本発明になるストリーミングデータ伝送装置の一実施の形態を示す回路ブロック図である。
【００１５】
図中、１は送信側機器であり、２は受信側機器である。送信側機器１は、映像や音声などが入力として与えられ、これをデジタルのストリーミングデータとして出力するエンコーダ３、エンコーダ３からのストリーミングデータを一旦保存する送信バッファメモリ４、このバッファメモリ４からデータを読み出してネットワーク５を介して受信側機器２にデータを送信するネットワーク装置６、メモリ４の残り容量を確認すると共にネットワーク装置６を制御するＣＰＵ（中央演算処理装置）７から構成されている。なお、ネットワーク５の形態や経路はどのようなものであっても良く、要は受信側機器２にデータが届けば良い。また、伝送路は有線でも無線でも良い。
【００１６】
受信側機器２は、ネットワーク５を介して送信されたデータを受信するネットワーク装置８、このネットワーク装置８で受信されたデータが記憶される受信バッファメモリ９、このバッファメモリ９に保存されたデータを読み込んでデコード処理を行いディスプレイ装置などに出力するデコーダ１０、ネットワーク装置８及びバッファメモリ９を制御するＣＰＵ（中央演算処理装置）１１から構成されている。
【００１７】
次に図２も用いて、図１の装置の動作について説明する。図２は送信バッファメモリ４内に記憶されているデータ量を模式的に示す図で、同図（Ａ）は記憶データ２１（ハッチング部）の量が少ない場合を、同図（Ｂ）は記憶データ２２の量が多い場合を示す。２３、２４は空き記憶領域を示す。
【００１８】
最初に、エンコーダ３にてエンコードされたストリーミングデータは、送信バッファメモリ４に一旦保存される。バッファメモリ４の残り容量に余裕がある場合（図２（Ａ）参照）は、ＴＣＰ／ＩＰプロトコルにてネットワーク装置６から受信側機器２に送信を行なう。ＴＣＰ／ＩＰプロトコルでは、データの再送を行うことで確実にデータを送ることが
出来るため、受信側にて完全な映像を再生することが出来る。しかしながら送信エラーが連続して発生し再送が頻繁に起こると、送信レートが下がり送信バッファメモリ４内のデータが増加していく。そこでバッファメモリ４の残り容量が少なくなった場合（図２（Ｂ）参照）には、送信プロトコルをＵＤＰ／ＩＰプロトコルに切り換えてバッファメモリ４のオーバーフローが発生するのを防ぐ。
【００１９】
エンコーダ３から送られてくるデータ送信レートは、以下の式（１）を満足している必要がある。
【００２０】
（数１）
データ送信レート  ＜  ＴＣＰ／ＩＰプロトコルで再送が発生しなかった場合の転送レート  （１）
上記式（１）を満たしている場合は、ＴＣＰ／ＩＰプロトコルで送信していても、再送が発生しない限り送信バッファメモリ４が一杯となることがない。また転送レートは、以下の式（２）を満足している。
【００２１】
（数２）
ＴＣＰ／ＩＰプロトコルでの転送レート  ＜  ＵＤＰ／ＩＰプロトコルでの転送レート
（２）
従って、ＵＤＰ／ＩＰプロトコルに基づき送信している場合には、送信バッファメモリ４に空きが出来る仕組みである。
【００２２】
図３に送信側のプロセスフローを示した。以下、図３に基づき送信プロセスをさらに詳細に説明する。
【００２３】
送信が開始されるとエンコーダ３から送信バッファメモリ４にデータが送られてくる。そこで送信バッファメモリ４のチェックを行い（ステップＳ１）、送信すべきデータがバッファメモリ４内にあるか否かをチェックする（ステップＳ２）。バッファメモリ４内にデータがなければ（ステップＳ２でＮＯ）、データが来るまで待つべくステップＳ１に戻る。バッファメモリ４内にデータがあれば（ステップＳ２でＹＥＳ）、次にバッファメモリ４内の空き容量は十分か否かのチェックを行う（ステップＳ３）。この判断基準としては、例として記憶されているデータ量が全バッファメモリ容量の８０％以内の場合には空きがあるなどと決めておく。一般的には、送信実験などをしてもっとも効率のよい値を設定する。
【００２４】
バッファメモリ４の空き容量が十分である場合（ステップＳ３でＹＥＳ）は、ＣＰＵ７はネットワーク装置６に対してＴＣＰ／ＩＰプロトコルに基づきデータ転送を行うよう制御し、ネットワーク装置６はＴＣＰ／ＩＰプロトコルに基づきデータ転送を行う（ステップＳ４）。バッファメモリ４に空き容量が少ない場合（ステップＳ３でＮＯ）は、ＣＰＵ７はネットワーク装置６に対してＵＤＰ／ＩＰプロトコルに基づきデータ転送を行うよう制御し、ネットワーク装置６はＵＤＰ／ＩＰプロトコルに基づき送信を行う（ステップＳ５）。
【００２５】
上記バッファメモリ４の空き容量が十分であるかどうかの判断は送信時にパケット毎に行われる。ＵＤＰ／ＩＰプロトコルでは送信確認をアクノレッジ信号（ＡＣＫ）等により行わないため、一度の送信で動作が完了する。一方、ＴＣＰ／ＩＰプロトコルでは、受信側からのＡＣＫによりパケットが正常に受信できたかどうかのチェックが行われる（ステップＳ６）。
【００２６】
受信が正常になされた場合（ステップＳ６でＹＥＳ）は、送信動作は完了となる。受信
が正常に行われなかった際は（ステップＳ６でＮＯ）、非アクノレッジ信号（ＮＡＣＫ）が来るかタイムアウトが発生した場合には、再度同じパケットを送信するのであるが、再送処理中においてもエンコーダ３からバッファメモリ４内へデータが送られてくるため、バッファメモリ４がオーバーフローする危険性がある。そのため、再送中においても、バッファメモリ４内の残り容量が十分かどうかをチェックし（ステップＳ７）、少なくなった場合（ステップＳ７でＮＯ）には再送を打ち切る必要がある。
【００２７】
また、バッファメモリ４の残り容量が十分であっても（ステップＳ７でＹＥＳ）、再送回数が規程回数Ｎ未満かどうかをチェックして（ステップＳ８）、規定回数Ｎ以上の再送が行われた場合（ステップＳ８でＮＯ）は、同様に再送を打ち切る。再送回数が規程回数Ｎ未満であれば（ステップＳ８でＹＥＳ）、ステップＳ４に戻り、ＴＣＰ／ＩＰプロトコルに基づき再びデータ転送を行うことになる。
【００２８】
ステップＳ７及びＳ８で再送が打ち切られたパケットは、ＵＤＰ／ＩＰプロトコルに基づき一度のみ送られる（ステップＳ５）。なお、この処理は、オプションであり、必ずしも必要ではない。再送を打ち切った場合にパケットを破棄しても問題ない。ここでは最後にＵＤＰ／ＩＰプロトコルに基づき送信しているが、これはプロトコルを変更することでヘッダー量が減少し、少しでも送信できる可能性が高くなるだろうという考えからである。
【００２９】
送信が完了すると、次のパケットを送信するために再び送信処理に戻り、バッファメモリ４のチェックを再び行う（ステップＳ１）。以降、同じ処理の繰り返しとなる。
【００３０】
上記実施の形態によれば、伝送時のパケットロスを減少させることが出来、かつリアルタイムにデータを送ることが可能となる。
【００３１】
なお、上記実施の形態では、ＣＰＵ７にて送信バッファメモリ４の空き容量をチェックしているが、記憶されているデータ量を確認すれば空き容量が分かることから、記憶されているデータ量をチェックしても良く、どちらをチェックしても実質的に変わらないものである。
【００３２】
ところで、異なるプロトコルで送信した場合に問題となるのが、受信側機器２でのデータの再構築である。ＴＣＰ／ＩＰとＵＤＰ／ＩＰの両プロトコルではヘッダーサイズの違いや再送の有り無し等により、送信側での送り出しタイミングと異なる順序にて受信側に届く可能性がある。このことは、特に無線環境においては注意が必要である。これを防ぐための手段として、パケット毎にシーケンス番号を付加する方法がある。一般的なパケットのシーケンス番号と違うのは、ＵＤＰ／ＩＰプロトコルだけで閉じたシーケンス番号、及びＴＣＰ／ＩＰプロトコルだけで閉じたシーケンス番号で送るのではなく、ＵＤＰ／ＩＰとＴＣＰ／ＩＰの２つのプロトコルで一括してシーケンス番号を管理することである。シーケンス番号はプロトコルに関係なく送信バッファ４内から送り出される順に付加される。一方、受信側機器２では、受信パケットのシーケンス番号の部分を参照してデータの並べ替えを行う。
【００３３】
以下、図４も参照して詳細を説明する。図４は、受信側機器２で受信したパケットが受信バッファメモリ９内にて送信バッファメモリ４から送り出された順に並べ替えられる様子を示す図である。図中、３１及び３２はＵＤＰ／ＩＰプロトコルに基づきネットワーク装置６から送信されているパケットであり、３３はＴＣＰ／ＩＰプロトコルに基づきネットワーク装置６から送信されているパケットである。また、３４乃至３６はそれぞれ上記パケット３１乃至３３に付加されたシーケンス番号にかかるデータである。ここで、パケット３１乃至３３は、送信バッファメモリ４からパケット３１、３３、３２の順番で送り
出されたものである。
【００３４】
上記パケットデータ３１乃至３３は、シーケンス番号データに基づきＣＰＵ１１からの制御により、受信バッファメモリ９内で送信順に並べ替えられることになる（図４を参照／図中、右側が先頭位置である）。
【００３５】
シーケンス番号は、データ部分の先頭に付加するのがもっとも簡単であるが、ＲＴＰプロトコルにあるシーケンス番号をそのまま利用しても良い。シーケンス番号が付加されることにより、受信側にてパケットロスを感知することも可能となる。
【図面の簡単な説明】
【００３６】
【図１】本発明になるストリーミングデータ伝送装置の一実施の形態を示すブロック図。
【図２】図１の装置の送信バッファメモリ内のデータ量を説明するための図。
【図３】同じく図１の装置の動作を説明するためのフローチャート。
【図４】本発明になるストリーミングデータ伝送装置の他の実施の形態におけるデータ伝送を説明するための図。
【符号の説明】
【００３７】
１：  送信側機器
２：  受信側機器
３：  エンコーダ
４：  送信バッファメモリ
５：  ネットワーク
６：  ネットワーク装置
７：  ＣＰＵ（中央演算処理装置）
８：  ネットワーク装置
９：  受信バッファメモリ
１０：  デコーダ
１１：  ＣＰＵ（中央演算処理装置）
【図１】
2005167780.tif 000003
【図２】
2005167780.tif 000004
【図３】
2005167780.tif 000005
【図４】
2005167780.tif 000006