JP2007097099A

JP2007097099A - データ伝送装置

Info

Publication number: JP2007097099A
Application number: JP2005287150A
Authority: JP
Inventors: Takuo Kamiya; 拓郎神谷
Original assignee: Hitachi Kokusai Electric Inc
Current assignee: Hitachi Kokusai Electric Inc
Priority date: 2005-09-30
Filing date: 2005-09-30
Publication date: 2007-04-12

Abstract

【課題】パケットロス情報を利用して伝送レートを制御し、ネットワークを介してデータの伝送を効果的に行うデータ伝送装置を提供する。
【解決手段】ネットワークを介してデータを伝送するデータ伝送装置は、受信装置側から伝送されるパケットロス情報を受信するパケットロス情報受信手段と、受信したパケットロス情報が所定時間以上連続してパケットロスゼロとなった場合に、データの伝送レートを上げる伝送レート制御手段と、を備えるように構成される。
【選択図】図６

Description

本発明は、データ伝送装置に関し、特に、ネットワークを介してデータを伝送するデータ伝送装置に関する。

ネットワークを介して接続される画像復号化装置から画像符号化装置に対して回線容量を知らせる適当な手段がない場合、画像符号化装置自身が最適なビットレートを見つけ出し、画像データをネットワークに送信することは不可能であった。例えば、図１に示すように画像伝送装置（画像符号化装置２０１）は、ネットワーク１０３の回線容量を知ることができずに画像受信装置（画像復号化装置１０２）に対して回線容量よりも大きいビットレートで配信してしまう場合がある。

このとき、経由するルータ等がパケットをバッファリングする場合には、遅延が発生する。また、バッファリングしない場合にはパケットロスが発生し、ＲＴＰ（Real-time Transport Protocol）／ＵＤＰ（User Datagram Protocol）での通信では画像データが抜けてしまい、その期間正しく映像が表示されない。また、例えば、図２に示すように、ネットワーク１０３の回線容量よりも小さいビットレートで配信する場合は、ネットワーク１０３の回線を有効に使っているとはいえず、出せるべき伝送レートよりも小さな値を出すことになってしまい、パフォーマンスの低下という結果をもたらす。

一方、図３に示すように、画像復号化装置１０２から画像符号化装置２０１にパケットロス情報（例えば、パケット破棄率）を知らせるＲＴＣＰ（RTP Control Protocol）のＲｅｃｅｉｖｅｒＲｅｐｏｒｔを送信することによって、画像符号化装置２０１はネットワーク１０３の回線容量に対して、どれだけ余分なデータ量を送っているのかを伺い知ることが可能になる。そのパケットロス値によって配信する画像データを調整することが可能である（例えば、特許文献１参照。）。逆に、パケットロスの値がゼロである時は、回線容量と配信データ量が釣り合っているか、もしくは回線容量に比べて配信データ量の方が少ないため、画像符号化装置２０１から配信するデータ量を増やすことによって調整を図ることが可能である。
特開２００５−０１２７８０号公報

しかしながら、従来のＲｅｃｅｉｖｅｒＲｅｐｏｒｔを用いた画像伝送装置では、ネットワーク内の各機器（例えば、ルータやスイッチ等）にデータがバッファリングされて、伝送回線に対する溢れ（パケットロス）がバッファで吸収されるような状態について考慮されていないという問題があった。

本発明は、このような従来の事情に鑑み為されたもので、ネットワークを介してデータの伝送を効果的に行うデータ伝送装置を提供することを目的とする。

上記目的を達成するため、本発明に係るデータ伝送装置は、ネットワークを介してデータを伝送するデータ伝送装置であって、受信装置側から伝送されるパケットロス情報を受信するパケットロス情報受信手段と、受信したパケットロス情報が所定時間以上連続してパケットロスゼロとなった場合に、データの伝送レートを上げる伝送レート制御手段と、を備えるように構成される。

以上説明したように、本発明に係るデータ伝送装置によると、受信装置側から伝送されるパケットロス情報を受信するパケットロス情報受信手段と、受信したパケットロス情報が所定時間以上連続してパケットロスゼロとなった場合に、データの伝送レートを上げる伝送レート制御手段と、を備えるようにしたため、ネットワークを介してデータの伝送を効果的に行うことができる。

以下、本発明の実施の形態について、図面を参照しながら説明する。
本発明の一実施例に係る画像伝送システムは、図３に示した構成例とほぼ同様であるため、説明は省略する。ただし、図３に示した構成例の画像符号化装置２０１の代わりに画像符号化装置１０１が用いられる点で相違する。

図４には、本発明の一実施例に係る画像符号化装置１０１の構成例を示してある。
本実施例の画像符号化装置１０１は、画像符号化部１０１−１と、画像バッファ部１０１−２と、パケット配信部１０１−３と、伝送レート演算部１０１−４と、ＲｅｃｅｉｖｅｒＲｅｐｏｒｔパケット受信部１０１−５と、ＬＡＮ（Local Area Network）インタフェイス部１０１−６から構成される。

画像符号化部１０１−１は、外部の撮像装置等から入力されたＮＴＳＣ信号をＭＰＥＧ（Moving Picture Experts Group）などの形式で圧縮し、圧縮された画像データを画像バッファ部１０１−２に一時的に蓄える。パケット配信部１０１−３は、画像バッファ部１０１−２から圧縮された画像データを取り出して、伝送レート演算部１０１−４から与えられた伝送レートでＬＡＮインタフェイス部１０１−６を介して画像パケットをネットワーク１０３に配信する。

伝送レート演算部１０１−４は、ＲｅｃｅｉｖｅｒＲｅｐｏｒｔパケット受信部１０１−５からパケット破棄率を受け取り、伝送レートを演算して、パケット配信部１０１−３に対して伝送レートの指示を行う。なお、伝送レート演算部１０１−４の詳細な処理については後述する。ＲｅｃｅｉｖｅｒＲｅｐｏｒｔパケット受信部１０１−５は、ネットワーク１０３からＬＡＮインタフェイス部１０１−６を介してＲＴＣＰのＲｅｃｅｉｖｅｒＲｅｐｏｒｔパケットを受け取り、ＲｅｃｅｉｖｅｒＲｅｐｏｒｔに含まれるパケット破棄率を伝送レート演算部１０１−４に出力する。

図５には、本発明の一実施例に係る画像復号化装置１０２の構成例を示してある。
本実施例の画像復号化装置１０２は、画像復号化部１０２−１と、画像バッファ部１０２−２と、ＲｅｃｅｉｖｅｒＲｅｐｏｒｔパケット送信部１０２−３と、パケット破棄率演算部１０２−４と、パケット受信部１０２−５と、ＬＡＮインタフェイス部１０２−６から構成される。

パケット受信部１０２−５は、ネットワーク１０３からＬＡＮインタフェイス部１０２−６を介して画像パケットを受信し、受信した画像パケットをパケット破棄率演算部１０２−４に出力する。パケット破棄率演算部１０２−４は、ＲＴＰのシーケンス番号からパケット破棄率を計算することが可能であり、計算したパケット破棄率と画像データをＲｅｃｅｉｖｅｒＲｅｐｏｒｔパケット送信部１０２−３に出力する。

ＲｅｃｅｉｖｅｒＲｅｐｏｒｔパケット送信部１０２−３は、ＬＡＮインタフェイス部１０２−６を介してパケット破棄率を含むＲｅｃｅｉｖｅｒＲｅｐｏｒｔパケットをネットワーク１０３に配信する。また、ＲｅｃｅｉｖｅｒＲｅｐｏｒｔパケット送信部１０２−３は、画像データを画像バッファ部１０２−２に出力し、一時的に蓄える。画像復号化部１０２−１は、画像バッファ部１０２−２から圧縮された画像データを取り出して伸張し、ＮＴＳＣ信号をモニタ（不図示）に出力する。

次に、画像符号化装置１０１内部の伝送レート演算部１０１−４がどのように伝送レートを演算するのかについて説明する。
まず、伝送レートを現在よりも下げる場合について説明する。送信する画像パケットの１パケット当たりのサイズの平均がａ（ｂｉｔ）、現在の伝送レートをｂ（ｂｐｓ）とする。ここで、ＲＴＣＰのＲｅｃｅｉｖｅｒＲｅｐｏｒｔを受信してパケット破棄率がｃ（％）であった時、伝送レートを次のように変更する。
ｂ’＝ｂ＊（１００−ｃ）／１００
この時、この伝送レートｂ’を実現するためには、平均サイズａ（ｂｉｔ）のパケットを１（ｓ）間にｂ’／ａ個送信する必要がある。つまり、送信間隔ｄ（ｓ）をｄ＝ａ／ｂ’と設定することで、１（ｓ）間にｂ’／ａ個のパケットを送信することが可能となる。すなわち、ｄ＝ａ＊１００／（ｂ＊（１００−ｃ））という式で送信間隔ｄ（ｓ）を計算して求めれば、ＲＴＣＰのＲｅｃｅｉｖｅｒＲｅｐｏｒｔパケットから伝送レートを調整することができる。

ここで注意すべきは、ＲＴＣＰのＲｅｃｅｉｖｅｒＲｅｐｏｒｔのパケット破棄率が回線容量に対する伝送レートの余剰率と一致しない場合がある点である。それには二つの要因が挙げられ、一つ目が回線容量と配信データ量の不均衡に依存しない回線内の物理的な特性によってパケットが破棄される場合、二つ目がネットワーク機器でのバッファがオールクリアされる場合である。

前者に関しては、仮にパケットロス総数Ｌ、回線容量と伝送レートの不均衡によって生じるパケットロス数をＬ１、前者に依存しない回線の物理的特性によるパケットロス数をＬ２とすると、Ｌ＝Ｌ１＋Ｌ２と表すことができる。配信データ量を調整することによって、前者のパケットロス数（Ｌ１）を減少させることはできるが、後者のパケットロス数（Ｌ２）を減少させることはできない。すなわち、後者のパケットロスの値の影響を考慮しない必要がある。

つまり、回線固有のパケット破棄率（仮にこれをｅ（％）とすると）が事前に分かっていれば、パケット破棄率ｃ％を用いるのではなく、固有の破棄率を引いた値、ｃ’＝ｃ−ｅを用いることで、この問題を解消できる。

また、ネットワーク機器内のバッファがオールクリアされるような場合は、伝送レートが回線容量に比べて余剰にデータを送信している割合よりもパケット破棄率ｃがはるかに大きくなるので、適当な上限値ｃ”（％）を設けて、ｃ＞ｃ”の時は、ｃ＝ｃ”
などと設定する方が望ましい。仮に伝送レートが回線容量よりもはるかに大きい場合であっても、ＲＴＣＰのＲｅｃｅｉｖｅｒＲｅｐｏｒｔは３（ｓ）〜５（ｓ）間隔で画像符号化装置１０１に到達するため複数回の伝送レート減少によって、回線容量と釣り合った伝送レートの実現が可能となる。

次に、伝送レートを現在よりも上げる場合について説明する。伝送レート演算部１０１−４で伝送レートを上げる場合にもＲＴＣＰのＲｅｃｅｉｖｅｒＲｅｐｏｒｔに含まれるパケット破棄率をもとに行う。伝送レートを上げる割合を「伝送レート上昇率」と呼ぶことにし、この値はユーザが任意に設定することが可能とする。データ伝送上昇率を仮にｆ（％）とした時に、パケット送信間隔ｄ（ｓ）を前述の１パケット当たりの平均パケットサイズをａ（ｂｉｔ）、現在のビットレートをｂ（ｂｐｓ）として計算すると、ｄ＝ａ＊１００／（ｂ＊（１００＋ｆ））となる。

次に、どのタイミングで伝送レートを上昇させるのかについて説明する。ＲＴＣＰパケットを受信し、パケット破棄率が０％であった時には、回線容量と伝送レートの関係には、
Ａ：回線容量＝伝送レート、
Ｂ：回線容量＞伝送レート、
Ｃ：回線容量＜伝送レート、
の３つのケースがある。

Ｃのケースは、伝送レートが回線容量よりも大きくても、ネットワーク内の各機器にバッファリングされて、回線に対する溢れがバッファで吸収されるような状態である。この場合は、一定時間待てば、その間にバッファの溢れが起こるので、一つのＲＴＣＰのＲｅｃｅｉｖｅｒＲｅｐｏｒｔではなく、一定期間のＲＴＣＰのＲｅｃｅｉｖｅｒＲｅｐｏｒｔを見て判断すればよい。

ただし、一定期間ＲＴＣＰのＲｅｃｅｉｖｅｒＲｅｐｏｒｔのパケット破棄率が０％であった場合でも、画像符号化装置１０１は回線容量と伝送レートの関係がＡのケースかＢのケースかを判断することはできないが、必ず伝送レートは上げるものとする。もしＡのケースであれば、その後ＲＴＣＰのＲｅｃｅｉｖｅｒＲｅｐｏｒｔ破棄率がゼロより大きい値になって、上述した方法によって伝送レートを下げることにより、回線容量と伝送レートが釣り合っていくことになる。

ここで、ＲＴＣＰのＲｅｃｅｉｖｅｒＲｅｐｏｒｔのパケット破棄率をチェックする時間を「待機間隔」とする。この「待機間隔」内でＲＴＣＰのＲｅｃｅｉｖｅｒＲｅｐｏｒｔのロス値がゼロであった場合には、伝送レートを上げるものとし、この値「待機間隔」と上述した「伝送レート上昇率」はユーザが任意に設定できるものである。

図６は、画像伝送装置１０１の伝送レート演算部１０１−４の処理の手順の一例を示す。
まず、ＲｅｃｅｉｖｅｒＲｅｐｏｒｔパケット受信部１０１−５からパケット破棄率を受け取る（ステップＳ６ａ）。次に、パケット破棄率はゼロか否かを判定する（ステップＳ６ｂ）。パケット破棄率がゼロでない場合（ステップＳ６ｂでＮｏ）、上述した計算式に基いて、送信間隔ｄを調整して伝送レートを下げる（ステップＳ６ｃ）。そして、待機時間（前回伝送レートを調整してからの経過時間）をカウントする待機時間タイマーをリセットする（ステップＳ６ｄ）。

一方、パケット破棄率がゼロである場合（ステップＳ６ｂでＹｅｓ）、待機時間が設定された待機間隔を超えたか否かが判定される（ステップ６ｅ）。待機間隔を超えていない場合（ステップＳ６ｅでＮｏ）、そのままステップＳ６ａに移行する。つまり、伝送レートは上昇させずに、時間が経過するのを待つ。これは、Ｃのケースのような状態を考えて、ネットワーク１０３上の各機器に画像パケットがバッファリングされていることを想定しているからである。

一方、待機間隔を超えている場合（ステップＳ６ｅでＹｅｓ）、Ｃのケースの可能性は低いとして、伝送レートを上げて（ステップＳ６ｆ）、待機時間タイマーをリセットする（ステップＳ６ｇ）。

ここで、図７に示すように、ネットワーク１０３の回線容量の変動の周期が短い場合、ＲＴＣＰのＲｅｃｅｉｖｅｒＲｅｐｏｒｔのパケット破棄率がゼロであった時にはＢのケースである可能性が高いため、伝送レートもそれに伴って上昇させる必要がある。よって、待機間隔を小さく、伝送レート上昇率を大きくする必要がある。

逆に、図８に示すように、ネットワーク１０３の回線容量の変動の周期が長い場合、ＲＴＣＰのＲｅｃｅｉｖｅｒＲｅｐｏｒｔの破棄率がゼロであった時にＡのケースである可能性が高いため、伝送レートを頻繁に上昇させることを避ける必要がある。よって、待機間隔を長く、伝送レート上昇率を小さくする必要がある。

このように本実施例によれば、ネットワーク１０３の回線の性質やユーザの用途等によって設定値を適当なものに指定することができる。
なお、上述した実施例では、伝送するデータとして画像を用いる構成を示したが、他の構成例として、例えば、音声等、種々なデータを用いる構成が用いられてもよい。

また、本実施例の画像符号化装置１０１では、ＲｅｃｅｉｖｅｒＲｅｐｏｒｔパケット受信部１０１−５やＬＡＮインタフェイス部１０１−６の機能によりパケットロス情報受信手段が構成されており、伝送レート演算部１０１−４の機能により伝送レート制御手段が構成されている。

ここで、本発明に係る画像符号化装置などの構成としては、必ずしも以上に示したものに限られず、種々な構成が用いられてもよい。例えば、画像符号化装置と撮像装置とが一体化したＷｅｂカメラ等の構成が用いられてもよい。また、本発明は、例えば、本発明に係る処理を実行する方法或いは方式や、このような方法や方式を実現するためのプログラムや当該プログラムを記録する記録媒体などとして提供することも可能であり、また、種々な装置やシステムとして提供することも可能である。

また、本発明の適用分野としては、必ずしも以上に示したものに限られず、本発明は、種々な分野に適用することが可能なものである。
また、本発明に係る画像符号化装置などにおいて行われる各種の処理としては、例えばプロセッサやメモリ等を備えたハードウエア資源においてプロセッサがＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）に格納された制御プログラムを実行することにより制御される構成が用いられてもよく、また、例えば当該処理を実行するための各機能手段が独立したハードウエア回路として構成されてもよい。

また、本発明は上記の制御プログラムを格納したフロッピー（登録商標）ディスクやＣＤ（ＣｏｍｐａｃｔＤｉｓｃ）−ＲＯＭ等のコンピュータにより読み取り可能な記録媒体や当該プログラム（自体）として把握することもでき、当該制御プログラムを当該記録媒体からコンピュータに入力してプロセッサに実行させることにより、本発明に係る処理を遂行させることができる。

伝送レートと回線容量の関係を説明するための図である。伝送レートと回線容量の関係を説明するための図である。画像伝送システムの構成例を示す図である。本発明の一実施例に係る画像符号化装置の構成例を示す図である。本発明の一実施例に係る画像復号化装置の構成例を示す図である。本発明の一実施例に係る画像符号化装置の処理の手順の一例を示す図である。本発明の一実施例に係る回線の変動周期と待機間隔と伝送レート上昇率の関係を説明するための図である。本発明の一実施例に係る回線の変動周期と待機間隔と伝送レート上昇率の関係を説明するための図である。

符号の説明

１０１：画像符号化装置、１０２：画像復号化装置、１０３：ネットワーク、２０１：画像符号化装置。

Claims

ネットワークを介してデータを伝送するデータ伝送装置であって、
受信装置側から伝送されるパケットロス情報を受信するパケットロス情報受信手段と、
前記受信したパケットロス情報が所定時間以上連続してパケットロスゼロとなった場合に、前記データの伝送レートを上げる伝送レート制御手段と、
を備えることを特徴とするデータ伝送装置。