JP6519304B2 - データ配信装置 - Google Patents

Description

本明細書で言及する実施例は、データ配信装置およびデータ配信方法に関する。

従来、例えば、監視カメラ等で撮影した映像(動画：ビデオ)および音声(オーディオ)等を、ネットワークに送出することが行われている。このとき、送信側のデータ配信装置(ネットワークインタフェース)は、最大の伝送速度でデータを送出するが、受信側の制御端末の処理能力を上回るデータ量をバースト的に送信すると、受信側端末でデータの欠落が発生することになる。

そこで、例えば、送信要求を受けたデータ種別の優先度を判定し、さらに、生成したパケットのデータサイズと設定された送信負荷(例えば、ビットレート)から、同じデータ種別の次パケットの送信時間を算出するネットワークインタフェースが研究されている。ここで、送信時間を算出するようなネットワークインタフェースは、例えば、ディスクリプタ型ネットワークインタフェースを用いることで実現することができる。

ディスクリプタ型ネットワークインタフェースでは、例えば、ビデオとオーディオといった異なるデータ種別間の送信優先度と送信タイミングは制御できるが、例えば、高画質と低画質のビデオといった同一データ種別で異なる負荷のデータ送信は不得手である。

ところで、従来、ネットワークのデータ配信装置およびデータ配信方法としては、様々なものが提案されている。

特開２００７−０７４２４３号公報 特開２００７−０７４７４０号公報 国際公開第２００４／０７５５６８号 特開２００６−２７３２６１号公報 特開２００７−１９４７３２号公報

上述したように、従来、ディスクリプタ型ネットワークインタフェースが研究されているが、例えば、高画質ビデオと低画質ビデオといった同一データ種別で異なる負荷のデータ送信を行う場合、どちらか一方の送信負荷に引きずられて適切な送信が困難であった。

このような問題は、画像データの配信に限定されるものではなく、他の様々なデータ配信においても、同様である。なお、本明細書では、主として、高画質動画(高画質Video)と低画質動画データ(低画質Video)を例として説明するが、本実施例の適用は、それに限定されるものではない。

また、本明細書において、チャネルとは、同一データ種別(例えば、動画データ)における異なる設定のデータ(例えば、解像度が異なる高画質Videoと低画質Video)として定義される。

一実施形態によれば、データ格納部からのデータを受け取ってＤＭＡ転送を行うＤＭＡ部と、前記ＤＭＡ部からの送信データを受け取ってパケットを生成すると共に、前記パケットのデータ種別を判定するパケット処理部と、を含むデータ配信装置が提供される。前記データ配信装置は、優先度判定部と、送信時間管理部と、処理開始判定部と、現在時間検出部と、送信時間比較部と、送信タイミング算出部と、パケットデータサイズ算出部と、を有し、生成された前記パケットをネットワークに送信する。

前記優先度判定部は、前記データ種別を受け取って、最も優先度の高い最優先データ種別を判定し、前記送信時間管理部は、前記最優先データ種別を受け取って、各送信データにおける、同一データ種別における異なる設定のデータであるチャネルを識別するためのチャネルＩＤと各チャネルの送信時間を管理する。前記処理開始判定部は、前記送信時間管理部の出力を受け取って、前記パケット処理部が対応するパケット処理を開始するかどうかを判定する。前記現在時間検出部は、現在時間を検出し、前記送信時間比較部は、前記現在時間と現パケット送信時間を比較し、前記送信タイミング算出部は、送信タイミングを算出し、そして、前記パケットデータサイズ算出部は、パケットデータのサイズを算出する。前記送信時間管理部は、前記最優先データ種別から、最優先チャネルＩＤの現パケット送信時間を前記送信時間比較部に出力すると共に、チャネルＩＤを前記処理開始判定部に出力し、前記送信タイミング算出部の計算結果に基づいて、該当チャネルＩＤの現パケット送信時間を更新する。前記処理開始判定部は、前記送信時間比較部からの比較結果、および、前記送信時間管理部からの送信する送信チャネルＩＤを受け取り、前記送信チャネルＩＤの送信処理を開始するかどうかを判定し、その判定結果および前記送信チャネルＩＤを前記パケット処理部に通知し、前記ＤＭＡ部および前記パケットデータサイズ算出部に送信処理を開始するチャネルＩＤを通知する。

開示のデータ配信装置およびデータ配信方法は、送信データバッファの増大を招くことなく、チャネル毎に送信タイミング制御をすることができるという効果を奏する。

図１は、監視カメラシステムの一例を説明するための図である。 図２は、図１に示す監視カメラシステムにおける、関連技術のディスクリプタ型ネットワークインタフェースの一例を示すブロック図である。 図３は、図２に示すネットワークインタフェースの動作の一例を説明するためのフローチャートである。 図４は、図２に示すネットワークインタフェースにおけるＤＭＡ部を説明するための図である。 図５は、図２に示すネットワークインタフェースによるデータ送信の様子を模式的に示す図である。 図６は、ネットワークインタフェースの第１実施例を示すブロック図である。 図７は、図６に示すネットワークインタフェースの動作の一例を説明するためのフローチャートである。 図８は、図６に示すネットワークインタフェースによるデータ送信の様子を模式的に示す図である。 図９は、関連技術および第１実施例のネットワークインタフェースにおける送信時間管理テーブルを比較して説明するための図である。 図１０は、図６に示すネットワークインタフェースにおける処理開始判定部の動作を説明するための図である。 図１１は、パケットフォーマットの一例を説明するための図である。 図１２は、データ格納部とＤＭＡ部の送信データバッファの動作を、関連技術と第１実施例との差異を示しつつ説明するための図である。 図１３は、ネットワークインタフェースの第２実施例を示すブロック図である。 図１４は、図１３に示すネットワークインタフェースの変形例を示すブロック図である。 図１５は、処理するチャネルＩＤの数が増加した場合の課題を説明するための図である。 図１６は、ネットワークインタフェースの第３実施例の要部を示すブロック図である。 図１７は、ネットワークインタフェースの第４実施例の要部を示すブロック図である。

まず、本実施例のデータ配信装置およびデータ配信方法を詳述する前に、図１〜図５を参照して、関連技術としてのデータ配信装置およびデータ配信方法、並びに、その問題点を、監視カメラシステムを例として説明する。

図１は、監視カメラシステムの一例を説明するための図である。図１に示されるように、監視カメラシステムは、例えば、ユーザ400が制御端末300を操作することで、ネットワーク200を介して、監視カメラ100からのデータ配信を受け取る。

ここで、監視カメラ100からのデータとしては、例えば、高画質の動画(Video High)，低画質の動画(Video Low)，音声(Audio)，高画質の静止画(JPEG High)，低画質の静止画(JPEG Low)および制御情報(メタデータ)等が含まれる。なお、監視カメラシステムでは、例えば、複数の監視カメラ100からのデータを、それぞれネットワーク200を経由して制御端末300に集約し、それをユーザ400が利用する。

監視カメラ100は、例えば、カメラモジュール110，エンコーダ120，プロセッサ130，メモリ140およびネットワークインタフェース150を含む。カメラモジュール110は、監視カメラ100が設置された周囲(例えば、３６０°の全周囲)を撮影(さらに、音声を収集)し、エンコーダ120は、カメラモジュール110からの映像(音声)データを符号化する。

メモリ140は、エンコーダ120により符号化されたデータおよび制御情報を格納し、ネットワークインタフェース150は、メモリ140からデータおよび制御情報を読み出し、ネットワーク200を介して、制御端末300に送信(配信)する。ここで、エンコーダ120，メモリ140およびネットワークインタフェース150は、プロセッサ130により制御される。

ネットワークインタフェース150は、ＤＭＡ(Direct Memory Access)部１，パケット処理部２およびＰＨＹ(PHYsical layer)部３を含む。ＤＭＡ部１は、例えば、エンコーダ120が符号化して格納した画像データや制御情報(メタデータ)等のデータをメモリ140から読み出して、パケット処理部２に転送する。

パケット処理部２は、ＤＭＡ部１から転送されたデータを受け取り、例えば、イーサネット（登録商標）等のネットワーク規格に従ったフレーム(パケット)を生成して、ＰＨＹ部３に出力する。ＰＨＹ部３は、パケット処理部２からのパケットを、実際に送出する信号形式に変換して、ネットワーク200に出力する。

ところで、例えば、ネットワークインタフェース150において、ＤＭＡ部１，パケット処理部２およびＰＨＹ部３は、いずれも送信優先度の判定や送信タイミングの制御を行う機能は有していない。

そのため、監視カメラ100からネットワーク200を介して制御端末300に送られるビデオ，オーディオおよび制御情報等の転送データが、例えば、受信側の制御端末300の処理能力を上回ると、制御端末300でデータの欠落(例えば、図１中のデータＤa0)が発生する。

そこで、例えば、送信要求を受けたデータ種別の優先度を判定し、生成したパケットのデータサイズと設定された送信負荷から、同じデータ種別の次パケットの送信時間を算出するディスクリプタ型ネットワークインタフェースが研究／開発されている。

図２は、図１に示す監視カメラシステムにおける、関連技術のディスクリプタ型ネットワークインタフェースの一例を示すブロック図である。

図２に示されるように、ネットワークインタフェース(データ配信装置)150は、ＤＭＡ部１，パケット処理部２，ＰＨＹ部３，送信時間管理部４１，現在時間検出部４２，送信時間比較部４３，優先度判定部４４および送信タイミング算出部４５を含む。ここで、ＤＭＡ部１は、ディスクリプタ型ＤＭＡとして形成される。

上述したように、ＤＭＡ部１は、例えば、メモリ(データ格納部)140から画像データや制御情報等のデータを読み出してパケット処理部２に転送するもので、送信データバッファ(#0〜#n)１１および送信データ情報格納部(#0〜#n)１２を含む。

ここで、送信データバッファ１１および送信データ情報格納部１２は、それぞれのデータ種別毎(例えば、動画データ，音声データ，静止画データ等)に設けられている。

パケット処理部２は、ＤＭＡ部１から転送されたデータを受け取り、ネットワークの規格に従ったパケットを生成してＰＨＹ部３に出力するもので、送信要求検出部２１およびパケット生成部２２を含む。

図３は、図２に示すネットワークインタフェースの動作の一例を説明するためのフローチャートであり、図２および図３を参照して、関連技術のネットワークインタフェース150を説明する。なお、図１および図２において、各処理(ステップＳＴ10〜ＳＴ19)は、それぞれ対応するものを示している。

図２および図３に示されるように、データ格納部(メモリ)140が送信データ情報を設定して送信要求を行うと、ＤＭＡ部１は、データ格納部140から送信要求のあったデータ種別のデータを内部に搭載されているデータ種別毎の送信データバッファ１１に転送する。

すなわち、データ格納部140から読み出した送信データを、内部バッファ(送信データバッファ１１および送信データ情報格納部１２)に格納する(ＳＴ１)。そして、送信データバッファ１１(内部バッファ)へのデータ格納が完了すると、パケット処理部２に対して送信要求を実施する。

まず、ＤＭＡ部１は、送信(格納)データサイズ，データ種別およびその他制御情報等の送信データ情報をパケット処理部２に通知し(ＳＴ10)、パケット処理部２は、ＤＭＡ部１から通知された送信要求があるデータ種別を優先度判定部４４に通知する(ＳＴ11)。

優先度判定部４４は、パケット処理部２から通知されたデータ種別の優先度を判定し(ＳＴ２)、最も優先度の高い最優先データ種別を、送信時間管理部４１およびパケット処理部２に通知する(ＳＴ12)。

送信時間管理部４１は、通知された最優先データ種別の現パケット送信時間を送信時間比較部４３に通知し(ＳＴ13)、また、現在時間検出部４２は、現在時間を送信時間比較部４３および送信タイミング算出部４５に出力する(ＳＴ13)。

送信時間比較部４３は、現パケット送信時間と現在時間を比較し、送信時間に到達しているかどうかを判定し(ＳＴ３)、比較結果を優先度判定部４４およびパケット処理部２に通知する(ＳＴ14)。ここで、送信時間が未達であった場合(ＳＴ３：未達)、優先度判定部４４に対して優先度判定処理要求を通知し、優先度判定部４４は、次の優先度判定処理を実施する。

一方、送信時間に到達していた場合(ＳＴ３：到達)、パケット処理部２は、ＳＴ12で通知されたデータ種別のパケット生成処理を開始する。パケット処理部２は、ＳＴ10で通知された送信データ情報から、送信負荷情報を送信タイミング算出部４５に通知する(ＳＴ15)。

ＤＭＡ部１は、通知されたデータ種別に該当する送信データバッファ１１から送信データをパケット処理部２に出力する(ＳＴ16)。パケット処理部２は、パケット生成処理を行い(ＳＴ４)、パケット生成処理中に次パケットの送信タイミングを算出するために、生成パケットデータサイズを送信タイミング算出部４５に通知する(ＳＴ17)。

送信タイミング算出部４５は、ＳＴ13で通知された現在時間，ＳＴ15で通知された送信負荷およびＳＴ17で通知された生成パケットデータサイズから次パケット送信時間を算出し(ＳＴ５)、送信時間管理部４１に通知する(ＳＴ18)。パケット処理部２は、パケット生成処理を終了した後、ＰＨＹ部３に対して送信データを出力する(ＳＴ19)。

図４は、図２に示すネットワークインタフェースにおけるＤＭＡ部を説明するための図である。図４に示されるように、ＤＭＡ部１は、送信データバッファ１１(Video用バッファ，Audio用バッファおよびJPEG用バッファ)、並びに、送信データ情報格納部１２(制御情報用バッファ)を含む。

メモリ(データ格納部)140には、エンコーダ120により符号化されたデータ(Vide(高画質)，Vide(低画質)，Audio，JPEG(高画質)およびJPEG(低画質))並びに制御情報(メタデータ)が格納されている。

そして、メモリ140に格納されたデータおよび制御情報が読み出されて、ネットワークインタフェース150におけるＤＭＡ部１の送信データバッファ１１および送信データ情報格納部１２に格納される。

ここで、例えば、参照符号ＰＰ１で示されるように、Vide(高画質：高画質の動画データ)とVide(低画質：低画質の動画データ)の同一データ種別でありながら異なる設定のデータ(異なるチャネルのデータ)は、同じ送信データバッファ(１１)を共用している。

また、参照符号ＰＰ２で示されるように、JPEG(高画質：高画質の静止画データ)とVide(低画質：低画質の静止画データ)の異なるチャネルのデータも、同じ送信データバッファ(１１)を共用している。なお、チャネルとは、同一データ種別(例えば、動画データや静止画データ)における異なる設定(例えば、異なる解像度)のデータを示す。

図５は、図２に示すネットワークインタフェースによるデータ送信の様子を模式的に示す図である。図５において、参照符号ａは、過去の(前回送信した)低画質の動画(映像：Video)データを示し、ｂは、前回送信した高画質Videoデータを示す。

また、参照符号ｃ，ｅ，ｆ，ｈは、これから送信する低画質Videoデータを示し、ｄ，ｇ，ｉ，ｊは、これから送信する高画質Videoデータを示す。さらに、参照符号Ｉ11は、ａのデータサイズから算出した送信間隔、Ｉ12は、ｂのデータサイズから算出した送信間隔、そして、Ｉ13は、ｆのデータサイズから算出した送信間隔を示す。ここで、例えば、低画質Videoデータｆのサイズが低画質Videoデータａのサイズより大きいと、Ｉ13は、Ｉ11よりも長くなる。

図５に示されるように、メモリ140には、例えば、エンコーダ120の処理が終わった順番にデータが格納され、すなわち、データは、ｃ，ｄ，ｅ，ｆ，ｇ，ｈ，ｉの順に格納される。また、ＤＭＡ部１の内部バッファ(送信データバッファ１１)には、例えば、プロセッサから通知される送信要求の順番に従って、メモリ140からデータを読み出して格納される。

すなわち、ＤＭＡ部１における送信データバッファ１１には、メモリ140に格納されたのと同じｃ，ｄ，ｅ，ｆ，ｇ，ｈ，ｉの順に格納される。ここで。例えば、参照符号Ｘｇで示されるように、例えば、高画質Videoデータｇが低画質Videoデータｅと重なり合うと、高画質Videoデータの本来の送信間隔を守ることが困難になる。また、高画質Videoデータの間に低画質Videoデータが大量に格納されていると、高画質Videoデータの送信間隔がフレーム間隔よりも長くなって、再生が停止する虞がある。

すなわち、一般的に、低画質Videoデータの送信ビットレートは、低い値が設定され、逆に、高画質Videoデータの送信ビットレートは、高い値が設定される。そのため、同じデータサイズの場合、低画質Videoデータであれば、送信間隔は長くなり、高画質Videoデータであれば、送信間隔は短くなる。

図２および図３を参照して説明した関連技術のネットワークインタフェースでは、同一のデータ種別で異なるチャネルのデータを送信する場合、データ格納部(メモリ)140やＤＭＡ部１では、チャネル毎の優先順位や送信タイミングを認識するのが困難である。

メモリ140では、エンコード処理が終了したデータから、ＤＭＡ部１に対して送信要求を実施し、ＤＭＡ部１は、メモリ140に格納された順番でデータを内部の送信データバッファ１１に格納する。

図４を参照して説明したように、ＤＭＡ部１では、データ種別毎のバッファとなっているため、データ種別毎(例えば、動画，音声，静止画等)の送信順は制御可能であるが、バッファを共用しているチャネル間の送信順を制御するのは困難である。

すなわち、図５に示されるような、同じ動画(Video)のデータ種別における高画質Videoと低画質Videoといったチャネル間の送信順を制御するデータのソーティングを行うのは困難となっている。

また、パケット処理部２は、ＤＭＡ１部における送信データバッファ１１に格納された順番にデータを送信するだけであり、送信データバッファ１１を共用した場合は、異なるチャネル毎に送信タイミングを制御することは困難である。

そのため、例えば、高画質Videoデータが想定している送信間隔よりも送信間隔が広がって、映像のフレーム間隔よりも広くなると、次のフレームデータが受信されるまで再生画面が停止することになる。

また、例えば、低画質Videoデータは、想定している送信間隔よりも短い間隔で送信されてくるため、受信側(制御端末300)の処理能力を上回るデータ量をバースト的に送信すると、制御端末300でデータの欠落が発生することになる。

以下、データ配信装置およびデータ配信方法の実施例を、添付図面を参照して詳述する。図６は、ネットワークインタフェースの第１実施例を示すブロック図である。

図６に示されるように、第１実施例のネットワークインタフェース(データ配信装置)250は、ＤＭＡ部１，パケット処理部２，ＰＨＹ部３，現在時間検出部４２，送信時間比較部４３，優先度判定部４４および送信タイミング算出部４５を含む。

さらに、ネットワークインタフェース250は、チャネルＩＤフィールドを追加した送信時間管理部４６，パケットデータサイズ算出部４７および処理開始判定部４８を含む。ここで、ＤＭＡ部１は、ディスクリプタ型ＤＭＡとして形成される。

前述したように、ＤＭＡ部１は、例えば、メモリ(データ格納部)140から画像データや制御情報等のデータを読み出してパケット処理部２に転送するもので、送信データバッファ１３および送信データ情報格納部１４を含む。

ここで、本第１実施例における送信データバッファ１３および送信データ情報格納部１４は、図２を参照して説明した関連技術における送信データバッファ１１および送信データ情報格納部１２のように、それぞれのデータ種別に対応する#0〜#nを設けなくてもよい。

パケット処理部２は、ＤＭＡ部１から転送されたデータを受け取り、ネットワークの規格に従ったパケットを生成してＰＨＹ部３に出力するもので、送信要求検出部２１およびパケット生成部２２を含む。

なお、図６と、前述した図２の比較から明らかなように、パケット生成部２２には、パケットデータサイズ算出部４７から、１パケットを生成するためのデータサイズが入力される。

すなわち、本第１実施例のネットワークインタフェース250において、送信時間管理部４６は、優先度判定部４４から通知される最優先データ種別からチャネルＩＤを選択する機能が追加されている。

また、処理開始判定部４８は、送信時間管理部４６から通知されるチャネルＩＤと送信時間比較部４３から通知される比較結果に基づいて、通知されたチャネルＩＤの送信処理を開始するかどうかの判定を行う機能を有する。さらに、処理開始判定部４８は、その判定結果とチャネルＩＤをパケット処理部２に通知し、チャネルＩＤをパケットデータサイズ算出部４７に通知する機能を有する。

パケットデータサイズ算出部４７は、処理開始判定部４８からのチャネルＩＤにより１パケットを生成するためのデータサイズを算出する機能を有し、算出した１パケット生成するためのデータサイズとチャネルＩＤをパケット処理部２に通知する。なお、ＤＭＡ部１に搭載されるデータ種別毎の送信データバッファ１３および送信データ情報格納部１４は、１つずつ設けられている。

図７は、図６に示すネットワークインタフェースの動作の一例を説明するためのフローチャートであり、図６および図７を参照して、第１実施例のネットワークインタフェース250を説明する。なお、図６および図７において、各処理(ステップＳＴ20〜ＳＴ31)は、それぞれ対応するものを示している。

図６および図７に示されるように、データ格納部(メモリ)140が送信データ情報を設定して送信要求を行う。図２および図３を参照して説明した関連技術のネットワークインタフェース150は、ＤＭＡ部１が送信要求を受けると、データ格納部140から送信要求のあったデータ種別のデータをＤＭＡ内１に搭載されたデータ種別毎の送信データバッファ１１に転送する。

これに対して、第１実施例のネットワークインタフェース250において、ＤＭＡ部１は、どのデータ種別の送信要求があったかだけをパケット処理部２に通知する。すなわち、まず、パケット処理部２は、ＤＭＡ部１から通知された送信要求があるデータ種別を優先度判定部４４に通知する(ＳＴ20)。

優先度判定部４４は、パケット処理部２から通知されたデータ種別の優先度を判定(ＳＴ２)し、送信時間管理部４６に最優先データ種別を通知する(ＳＴ21)。送信時間管理部４６は、優先度判定部４４から通知された最優先データ種別から、最優先チャネルＩＤを判定し、処理開始判定部４８にチャネルＩＤを通知し(ＳＴ22)、送信時間比較部４３に該当チャネルの現パケット送信時間を通知する(ＳＴ22)。また、現在時間検出部４２は、現在時間を送信時間比較部４３と送信タイミング算出部４５に通知する(ＳＴ22)。

送信時間比較部４３は、送信時間管理部４６から通知された現パケット送信時間と、現在時間検出部４２から通知された現在時間を比較し、送信時間に到達しているかどうかを判定する(ＳＴ３)。

そして、送信時間比較部４３は、その比較結果を処理開始判定部４８と優先度判定部４４に通知する(ＳＴ23)。送信時間が未達であった場合(ＳＴ３：未達)、優先度判定処理(ＳＴ２)に戻り、次の最優先データ種別を判定する。

一方、送信時間に到達していた、若しくは、超過していた場合(ＳＴ３：到達)、処理開始判定部４８は、送信時間管理部４６から通知されたチャネルＩＤ(ＳＴ22)をパケットデータサイズ算出部４７とパケット処理部２に通知する(ＳＴ24)。さらに、処理開始判定部４８は、パケット処理部２に処理開始の判定結果を通知し(ＳＴ24)、パケット生成処理開始を要求する。

パケットデータサイズ算出部４７は、処理開始判定部４８から通知されたチャネルＩＤから、そのチャネルのデータ種別で１パケット生成するためのデータサイズを算出し(ＳＴ６)、ＤＭＡ部とパケット処理部に通知する(ＳＴ25)。さらに、処理開始判定部４８から通知されたチャネルＩＤを、ＤＭＡ部１に通知する(ＳＴ25)。

ＤＭＡ部１は、パケットデータサイズ算出部４７から通知されたデータサイズ分だけをデータ格納部140からＤＭＡ部１の内部バッファに格納(送信データバッファ１３)に格納する(ＳＴ７)。そして、格納したデータサイズとその他の制御情報(送信データ情報格納部１４の情報)をパケット処理部２に通知する(ＳＴ26)。

パケット処理部２は、送信負荷を送信タイミング算出部４５に通知し(ＳＴ27)、ＤＭＡ部１は、送信データをパケット処理部に転送する(ＳＴ28)。パケット処理部２は、パケット生成処理を開始し(ＳＴ４)、その際、算出した生成パケットデータサイズを送信タイミング算出部４５に通知する(ＳＴ29)。

送信タイミング算出部４５は、現在時間検出部４２から通知された現在時間ＳＴ23)と、パケット処理部２から通知された送信負荷(ＳＴ27)と、パケット処理部２から通知された生成パケットデータサイズ(ＳＴ29)から次パケットの送信時間を算出する(ＳＴ５)。

さらに、送信タイミング算出部４５は、次パケットの送信時間を送信時間管理部４６に通知する(ＳＴ30)。送信時間管理部４６は、送信するチャネルＩＤの送信時間を送信タイミング算出部４５から通知された次パケット送信時間に更新する。そして、パケット処理部２は、生成したパケットの送信データをＰＨＹ部３に出力する。

このように、第１実施例のネットワークインタフェースによれば、パケットデータサイズ算出部４７は、送信するチャネルＩＤと１パケットを生成するのためのデータサイズをＤＭＡ部１に通知する。

ＤＭＡ部１は、指定されたチャネルＩＤのデータを通知されたデータサイズ分だけメモリ(データ格納部)140から取得することにより、ＤＭＡ部１の内部に設ける送信データバッファ１３の数(容量)を増加させることなく、チャネル毎に送信タイミング制御をすることができるようになる。

図８は、図６に示すネットワークインタフェースによるデータ送信の様子を模式的に示す図であり、前述した図５に相当する図である。図８において、参照符号ａは、過去の(前回送信した)低画質の動画(映像：Video)データを示し、ｂは、前回送信した高画質Videoデータを示す。

また、参照符号ｃ，ｅ，ｆ，ｈは、これから送信する低画質Videoデータを示し、ｄ，ｇ，ｉ，ｊは、これから送信する高画質Videoデータを示す。さらに、参照符号Ｉ21は、ａのデータサイズから算出した低画質Videoの送信間隔、Ｉ22は、高画質Videoのｂのデータサイズから算出した送信間隔、そして、Ｉ23は、ｇのデータサイズから算出した高画質Videoの送信間隔を示す。ここで、Ｉ23は、ｇのデータサイズが大きいので、Ｉ22よりも長くなる。

そして、参照符号Ｉ24は、ｅのデータサイズから算出した低画質Videoの送信間隔、Ｉ25は、fのデータサイズから算出した低画質Videoの送信間隔を示す。ここで、Ｉ24は、ｅのずらした時間を考慮すると、Ｉ24が小さくなってしまい、受信側(制御端末300)の負荷が一時的に大きくなるので、ｅを送信した時間を新基準時間とし、ｆの送信時間を定める。また、Ｉ25は、ｆのデータサイズが大きいので、Ｉ24よりも長くなる。

図８に示されるように、メモリ140には、例えば、エンコーダ120の処理が終わった順番にデータが格納され、すなわち、データは、ｃ，ｄ，ｅ，ｆ，ｇ，ｈ，ｉの順に格納される。

しかしながら、本実施例において、ＤＭＡ部１の内部バッファ(送信データバッファ１３)には、例えば、プロセッサから通知される送信要求の順番ではなく、パケット処理部２から通知される順番に従って、メモリ140からデータを読み出して格納される。

すなわち、ＤＭＡ部１における送信データバッファ１３には、メモリ140に格納されたのとは異なり、ｄ，ｃ，ｇ，ｉ，ｅ，ｊ，ｆ，ｈの順に格納される。ここで。例えば、参照符号Ｘｅで示されるように、例えば、低画質Videoデータｅが高画質Videoデータｉと送信時間が衝突した場合は、例えば、新た締め定められた優先度に従って処理の順番を決定する。

すなわち、低画質Videoデータｅの処理を、高画質Videoデータｉの処理を待って行う。これにより、ＤＭＡ部１の内部に設ける送信データバッファ１３の数を増加させることなく、チャネル毎に送信タイミング制御をすることが可能になる。

図９は、関連技術および第１実施例のネットワークインタフェースにおける送信時間管理テーブルを比較して説明するための図である。

ここで、図９(a)は、前述した図２に示す関連技術のネットワークインタフェース150における送信時間管理部４１の送信時間管理テーブル(送信時間管理部４１)を示す。また、図９(b)は、前述した図６に示す第１実施例のネットワークインタフェース250における送信時間管理テーブル(チャネルＩＤフィールドを追加した送信時間管理部４６)を示す。

図９(a)に示されるように、関連技術の送信時間管理テーブルには、データ種別(Video，Audio，JPEG，制御，…)と、それに対応した次パケット送信時間(Ｔvideo，Ｔaudio，Ｔjpeg，Ｔctrl，…)が格納されるのみである。換言すると、関連技術の送信時間管理テーブルでは、ＤＭＡ部１の中間バッファ毎(送信データバッファ１１のデータ種別毎)に送信時間を管理するだけである。

すなわち、関連技術のネットワークインタフェース150では、優先度判定部４４(或いは、テーブルアドレス生成部)から最優先データ種別情報を取得し、該当するデータ種別の次パケット送信時間を送信時間比較部４３に出力する。さらに、送信するパケットを生成した後、該当するデータ種別の次パケット送信時間を、送信タイミング算出部４５から取得した次パケット送信時間に更新する。

これに対して、図９(b)に示されるように、第１実施例の送信時間管理テーブル(第１送信時間管理テーブル４６)には、チャネルＩＤフィールドが追加されている。ここで、チャネルＩＤは、例えば、同じデータ種別であっても同じ値が使用されることはない。なお、図９(b)は、単なる例であり、チャネルＩＤ毎に送信時間が管理されていれば、様々な変形および変更が可能なのはいうまでもない。

すなわち、本第１実施例のネットワークインタフェース250において、送信時間管理テーブルには、データ種別と、チャネルＩＤ(０，１，２，…)と、チャネルＩＤに対応した次パケット送信時間(Ｔvideo_0，Ｔvideo_1，Ｔvideo_2，…)が格納されている。

そして、本第１実施例のネットワークインタフェース250では、優先度判定部４４(或いは、テーブルアドレス生成部)から最優先データ種別情報を取得し、該当するデータ種別に属するチャネルＩＤの中から最も高いチャネルＩＤの次パケット送信時間を選択する。さらに、優先度判定部４４は、最も高いチャネルＩＤの次パケット送信時間を送信時間比較部４３に出力し、チャネルＩＤを処理開始判定部４８に出力する。

さらに、送信するパケットを生成した後、該当するチャネルＩＤの次パケット送信時間を、送信タイミング算出部４５から取得した次パケット送信時間に更新する。なお、チェナルＩＤの個数、或いは、どのチャネルＩＤがどのデータ種別に属するかは、例えば、システムで予め決められている。また、チャネルＩＤ間の優先度に関しては、システムにより予め決定することもできるが、同一優先度としてもよい。

図１０は、図６に示すネットワークインタフェースにおける処理開始判定部の動作を説明するための図である。図１０に示されるように、処理開始判定部４８は、送信時間管理テーブル(チャネルＩＤフィールドを追加した送信時間管理部４６)からチャネルＩＤを取得する。

さらに、処理開始判定部４８は、送信時間比較部４３から送信時間と現在時間の比較結果(送信時間比較結果)を受け取る。ここで、送信時間比較結果が、現在時間≧次パケット送信時間が成立する場合は、パケット処理部２に対して、チャネルＩＤと共に、パケット処理開始の判定結果を通知する。

一方、送信時間比較結果が、現在時間＜次パケット送信時間が成立する場合は、未だ送信時間に達していないため、送信時間比較部４３が優先度判定部４４に対して、次の優先度判定を実施する比較結果を通知する。なお、現在時間と次パケット送信時間の比較は、例えば、カウンタを使用し、カウンタ値を比較することにより行うことができる。

図１１は、パケットフォーマットの一例を説明するための図であり、一般的なパケットフォーマットの一例を示すものである。図１１に示されるように、１つのパケットＰＦは、例えば、ＰＦ１〜ＰＦ４を含む。

ここで、ＰＦ１は、データ種別に関係なくほぼ固定サイズの部分であり、ＰＦ２は、データ種別により大きさが変化する部分である。ＰＦ１は、例えば、イーサネット（登録商標）におけるＩＰ(Internet Protocol)，ＴＣＰ(Transmission Control Protocol)／ＵＤＰ(User Data Protocol)ヘッダおよびＲＴＰ(Real-time Transport Protocol)ヘッダを含む。また、ＰＦ２は、例えば、データ種別ごとの特殊ヘッダである。

さらに、ＰＦ３は、ペイロード(Payload)を示し、例えば、パケットの総サイズのうち、宛先アドレスや発信元アドレスなどの管理情報(ヘッダ情報)を除いたデータのことである。なお、ＣＲＣ(Cyclic Redundancy Check)は、データ種別に関係なく固定長であり、例えば、データ転送などに伴う誤り検出に使用される。

このように、パケットフォーマットには、データ種別によらず一定サイズのヘッダと、データ種別により異なるサイズのヘッダが存在する。また、１パケットのデータサイズの上限は、システムにより決定されているため、ペイロード部分(ＰＦ３)の大きさは、データ種別により変化するのが分かる。

図１２は、データ格納部とＤＭＡ部の送信データバッファの動作を、関連技術と第１実施例との差異を示しつつ説明するための図である。ところで、例えば、図２を参照して説明した関連技術のように、パケットデータサイズ算出部４７が設けられていないと、ＤＭＡ部１は、データ格納部140から通知されたデータサイズ分だけ、送信データバッファ１１(１３)にデータを格納する。

そして、送信データサイズ≦ペイロードサイズのとき、データ格納部140に格納されているデータを全て送信してもパケットデータサイズ上限を超えないので、ＤＭＡ部１の送信データバッファ１１(１３)に残留データはない。

しかしながら、送信データサイズ＞ペイロードサイズのとき、データ格納部140に格納されているデータを全て送信する前にパケットデータサイズ上限に達するため、ＤＭＡ部１の送信データバッファ１１(１３)にデータが残留してしまう。

すなわち、ＤＭＡ部１の送信データバッファ１１(１３)が空にならないと、次のチャネルのデータを転送することができず、送信タイミングを制御していることから、次の送信時間にならないと、送信データバッファ１１(１３)から送信データを取得することが困難になる。

このように、データサイズがそのチャネルが属するデータ種別のペイロードデータサイズよりも大きいと、パケット処理部が１パケットを生成する際、ＤＭＡ部の送信データバッファにデータが残留している状態でパケットデータサイズの上限値に達してしまう。

このように、ＤＭＡ部１の送信データバッファ１１(１３)にデータが残留している状態では、データ格納部140に格納されている他のチャネルの送信データを処理することが困難になる。結果として、ＤＭＡ部１の送信データバッファ１１(１３)に格納されている残留データが処理され、ＤＭＡ部１の送信データバッファ１１(１３)が空になるまでは、完全に送信が止まってしまう。

そして、例えば、この完全に送信が止まってしまう時間が動画の１フレーム時間よりも長い場合、受信側では次のフレームのデータが受信されないことになるので、動画の再生が止まってしまうことになる。すなわち、受信側(制御端末300)においては、期待したタイミングデータが到達しないため、例えば、動画の再生が停止するといった問題が発生することになる。

これに対して、図６を参照して説明したように、本第１実施例のネットワークインタフェース250には、パケットデータサイズ算出部４７が設けられている。そして、ペイロードＰＦ３の大きさは、例えば、チャネルＩＤからデータ種別を判定し、パケットデータサイズ算出部４７により算出されるようになっている。

すなわち、本第１実施例において、パケットデータサイズ算出部４７は、処理開始判定部４８から通知されたチャネルＩＤによりデータ種別を判定し、１パケットを生成するデータサイズの上限値を算出する。

換言すると、パケットデータサイズ算出部４７は、図１１におけるペイロードＰＦ３の部分のデータサイズを算出し、その算出結果を、パケット処理部２およびＤＭＡ部１に通知する。

このように、本第１実施例によれば、パケットデータサイズ算出部４７では、パケット処理部２が１パケットを処理した後に、ＤＭＡ部１の送信データバッファ１３に残留送信データが残らないように制御する。

すなわち、パケットデータサイズ算出部４７は、通知されたチャネルＩＤから１パケットを生成するためのデータサイズを算出し、ＤＭＡ部１とパケット処理部２に通知する。

これによりＤＭＡ部１は、１パケットを生成するためのデータサイズ分だけをＤＭＡ部１の送信データバッファ１３にデータを格納することができ、１パケット生成後にＤＭＡ部１の送信データバッファ１３に送信データが残留しないようにすることができる。

ところで、上述した第１実施例では、パケットデータサイズ算出部４７がＤＭＡ部１に送信すべきチャネルＩＤを通知するが、例えば、処理の関係でそのチャネルＩＤの送信データが存在しない場合が考えられる。

その場合、ＤＭＡ部１は、通知されたチャネルＩＤの送信データがデータ格納部140に格納されるまで待つことになり、通知されたチャネルＩＤの送信データがデータ格納部140に格納されるまで送信が止まる虞がある。なお、送信が止まることによる影響は、前述した通りである。

図１３は、ネットワークインタフェースの第２実施例を示すブロック図であり、通知されたチャネルＩＤの送信データがデータ格納部140に格納されるまで送信が止まるのを防止するようにしたものである。

図１３と、前述した図６の比較から明らかなように、本第２実施例のネットワークインタフェース350では、ＤＭＡ部１にチャネルＩＤ走査部(第１チャネルＩＤ走査部)１５が設けられている。チャネルＩＤ走査部１５は、パケットデータサイズ算出部４７から通知されたチャネルＩＤの送信データが、送信データ情報格納部１４に格納された送信データ情報により送信要求されているかどうかを走査(調査)する。

すなわち、チャネルＩＤ走査部１５は、パケットデータサイズ算出部４７からのチャネルＩＤの通知を受け取り(ＳＴ25)、該当チャネルＩＤが存在するかどうかをＤＭＡ部１の送信データ情報格納部１４の情報を走査(スキャン)する。さらに、チャネルＩＤ走査部１５は、走査結果を処理開始判定部４８に通知する(ＳＴ32)。

処理開始判定部４８は、ＤＭＡ部１のチャネルＩＤ走査部１５の走査結果から、送信すべきチャネルＩＤのデータの送信要求があれば、パケット処理部２に対してチャネルＩＤとパケット生成処理を開始する判定結果を通知する(ＳＴ24)。

なお、処理開始判定部４８は、チャネルＩＤ走査部１５の走査結果から、送信するチャネルＩＤのデータの送信要求がなければ、優先度判定部４４に対して次の優先度判定を開始する判定結果を通知する(ＳＴ33)。

図１４は、図１３に示すネットワークインタフェースの変形例を示すブロック図であり、図１３におけるＤＭＡ部１に設けたチャネルＩＤ走査部(第１チャネルＩＤ走査部)１５を、チャネルＩＤ走査部(第２チャネルＩＤ走査部)１６としたものである。

図１４と、上述した図１３の比較から明らかなように、本変形例のネットワークインタフェース450において、ＤＭＡ部１は、データ格納部140から送信要求を通知されると、該当チャネルＩＤが存在するかどうか、送信データ情報格納部１４の情報を走査する。

すなわち、チャネルＩＤ走査部１６は、送信データ情報格納部１４の走査結果を踏まえて送信要求をパケット処理部２に通知すると共に、データ格納部140に格納されている全チャネルＩＤ(格納チャネルＩＤ)を通知する。

パケット処理部２(パケット生成部２２)は、通知された格納チャネルＩＤを優先度判定部４４に通知し(ＳＴ20)、優先度判定部４４は、通知された格納チャネルＩＤから最優先データ種別のチャネルＩＤを選択し、送信時間管理部４６に通知する(ＳＴ21)。

このように、図１３に示すネットワークインタフェース(データ配信装置)の第２実施例、並びに、図１４に示すその変形例によれば、通知されたチャネルＩＤの送信データがデータ格納部に格納されるまで送信が止まるのを防止することが可能になる。

図１５は、処理するチャネルＩＤの数が増加した場合の課題を説明するための図であり、図１５(a)は、チャネルＩＤが＃０〜＃３のデータを処理する様子を示し、図１５(b)は、チャネルＩＤが＃０〜＃４のデータを処理する様子を示す。

図１５(a)に示されるように、データ＃０〜＃３が重なり合うことがない状況では、優先度に関わらず、チャネルＩＤが＃０〜＃３の全て周期のデータＤ01〜D31，Ｄ02〜D32，Ｄ03〜D33は、順番に送信されることになる。

これに対して、図１５(b)に示されるように、チャネルＩＤが＃４の優先度が最も低いデータが増えると、例えば、１周期目のD41が２周期目のＤ02と衝突し、また、２周期目のD42が３周期目のＤ03と衝突する。

この場合、チャネルＩＤが＃０のデータＤ02，Ｄ03の方が、チャネルＩＤが＃４のデータＤ41，Ｄ42よりも優先度が高いため、データの衝突が生じた個所では、それぞれ優先度の高いデータＤ02およびＤ03が送信されることになる。

そして、優先度の低いデータＤ41およびＤ42は送信されずに待たされ、高優先度のデータが全てなくなったタイミング、すなわち、本来、データＤ43を送信するタイミングになって、初めてデータＤ41を送信することができるようになる。

すなわち、図１５(b)に示す例では、処理するチャネルＩＤの数が増加すると、例えば、優先度の低いチャネルＩＤのデータ(＃４)は送信され難くなり、送信されない虞も生じることになる。

図１６は、ネットワークインタフェースの第３実施例の要部を示すブロック図であり、上述した優先度の低いチャネルＩＤのデータ(＃４)は送信されないといった問題を解決するためのものである。

図１６に示されるように、第３実施例のネットワークインタフェース550は、優先度判定部４４と送信時間管理部４６の間に、優先度変更部４９を挿入するようになっている。なお、他の構成は、前述した図６に示す第１実施例、或いは、図１３に示す第２実施例をそのまま適用することができる。

優先度変更部４９は、データ種別とスキップ回数の関係が予め決められているスキップ回数設定テーブル491、および、優先度判定部４４からの最優先データ種別とパケット処理部２からのデータ種別を受け取るスキップ回数制御部492を含む。

すなわち、スキップ回数制御部492は、パケット処理部２から送信要求のかけられているデータ種別を取得すると共に、優先度判定部４４から最優先データ種別を取得する。そして、スキップ回数設定テーブル491に設定されたデータ種別(Video，Audio，JPEG，制御情報)毎のスキップ回数(Skip_cnt_v，Skip_cnt_a，Skip_cnt_j，Skip_cnt_c)を参照して、スキップ回数制御を行う。

ここで、スキップ回数とは、データ種別毎に最優先データ種別として選択されなかった回数を示す。そして、スキップ回数制御部492は、スキップ回数が予め定められた規定数に達した場合には、優先度判定部４４が選択したデータ種別ではなく、スキップ回数が規定数に達したデータ種別を変更後最優先データ種別として、送信時間管理部４６に通知する。

これにより、優先度の低いチャネルＩＤのデータ(＃４)であっても、スキップ回数が規定数に達した場合には、送信データとして優先的に出力されることになる。

図１７は、ネットワークインタフェースの第４実施例の要部を示すブロック図であり、図１６と同様に、前述した優先度の低いチャネルＩＤのデータ(＃４)は送信されないといった問題を解決するためのものである。

図１７に示されるように、第４実施例のネットワークインタフェース650において、送信時間管理部４６には、送信時間管理テーブル(第２送信時間管理テーブル)461およびチャネルＩＤ選択部462が設けられている。

送信時間管理テーブル461は、図９(b)を参照して説明した送信時間管理テーブルにおいて、さらに、次パケット送信時間限界値(Ｔvideo_0_lim，Ｔvideo_1_lim，…，Ｔvideo_13_lim)フィールドが追加されている。

送信時間管理部４６には、例えば、送信タイミング算出部４５から次パケット送信時間と共に、次パケット送信時間限界値が通知され、この次パケット送信時間限界値により各チャネルの次パケット送信時間限界値のフィールドが更新される。

ここで、次パケット送信時間限界値は、例えば、動画であれば、その時間までに送信をしないと受信側で動画の再生が止まってしまう時間に相当する。また、次パケット送信時間限界値と次パケット送信時間の間には、次パケット送信時間限界値≧次パケット送信時間の関係が成立する。

なお、本第４実施例のネットワークインタフェース650では、例えば、図６に示す第１実施例のネットワークインタフェース250における送信時間比較部４３を削除することができる。

そして、送信時間比較部４３の代わりとして、チャネルＩＤ選択部462をも受け、現在時間と、各チャネルの次パケット送信時間および次パケット送信時間限界値との比較を行い、送信処理を開始するチャネルＩＤを選択する。

なお、チャネルＩＤ選択部462では、現在時間＞次パケット送信時間限界値が成立するチャネルが存在する場合、そのチャネルＩＤを最優先で送信するように制御する。そのため、チャネルＩＤ選択部462は、処理開始判定部４８に対して、現在時間＞次パケット送信時間限界値が成立しているチャネルＩＤ、並びに、削除した送信時間比較部４３の代わりに比較結果を通知する。

また、例えば、次パケット送信時間限界値に達しているチャネルＩＤが複数存在する場合は、予めシステムで定められたチャネルＩＤの優先度に従って、送信するチャネルＩＤを選択する。

さらに、例えば、現在時間が次パケット送信時間限界値を超過しているチャネルＩＤは存在しないが、次パケット送信時間を超過しているチャネルＩＤが存在する場合は、そのチャネルＩＤおよび比較結果を処理開始判定部４８に通知する。

また、現在時間が次パケット送信時間限界値を超過しているチャネルＩＤは存在しないが、次パケット送信時間を超過しているチャネルＩＤが複数存在する場合は、予めシステムで定められたチャネルＩＤの優先度に従って、送信するチャネルＩＤを選択する。

そして、次パケット送信時間限界値にも次パケット送信時間にも達しているチャネルＩＤが１つも存在しない場合は、処理開始判定部４８に対して、処理を開始しないことを意味する比較結果を通知する。

上述したように、本実施例によれば、例えば、同一データ種別で異なる送信負荷が設定されるような場合でも、受信側が期待するタイミングで期待するデータ種別およびチャネルＩＤのデータを送信することが可能になる。さらに、受信側(制御端末)は、自身の処理能力を上回るデータを受信することを避けることができ、その結果、データの欠落を防止することができる。

このように、本実施例のネットワークインタフェース(データ配信装置)は、要望される機能に応じて、様々な変形および変更を行うことができる。なお、上述した本実施例のデータ配信装置およびデータ配信方法は、主として監視カメラ等で撮影した動画(Video)、音声(Audio)および静止画(JPEG)等を例として説明したが、本実施例は、様々なデータの配信に対して幅広く適用することが可能である。

以上、実施形態を説明したが、ここに記載したすべての例や条件は、発明および技術に適用する発明の概念の理解を助ける目的で記載されたものであり、特に記載された例や条件は発明の範囲を制限することを意図するものではない。また、明細書のそのような記載は、発明の利点および欠点を示すものでもない。発明の実施形態を詳細に記載したが、各種の変更、置き換え、変形が発明の精神および範囲を逸脱することなく行えることが理解されるべきである。

以上の実施例を含む実施形態に関し、さらに、以下の付記を開示する。
（付記１）
データ格納部からのデータを受け取ってＤＭＡ転送を行うＤＭＡ部と、前記ＤＭＡ部からの送信データを受け取ってパケットを生成すると共に、前記パケットのデータ種別を判定するパケット処理部と、を含み、生成された前記パケットをネットワークに送信するデータ配信装置であって、
前記データ種別を受け取って、最も優先度の高い最優先データ種別を判定する優先度判定部と、
前記最優先データ種別を受け取って、各送信データにおけるチャネルを識別するためのチャネルＩＤと各チャネルの送信時間を管理する送信時間管理部と、
前記送信時間管理部の出力を受け取って、前記パケット処理部が対応するパケット処理を開始するかどうかを判定する処理開始判定部と、を有する、
ことを特徴とするデータ配信装置。

（付記２）
さらに、
現在時間を検出する現在時間検出部と、
前記現在時間と現パケット送信時間を比較する送信時間比較部と、
送信タイミングを算出する送信タイミング算出部と、を有し、
前記送信時間管理部は、前記最優先データ種別から、最優先チャネルＩＤの現パケット送信時間を前記送信時間比較部に出力すると共に、チャネルＩＤを前記処理開始判定部に出力し、前記送信タイミング算出部の計算結果に基づいて、該当チャネルＩＤの現パケット送信時間を更新する、
ことを特徴とする付記１に記載のデータ配信装置。

（付記３）
さらに、
パケットデータのサイズを算出するパケットデータサイズ算出部を有し、
前記処理開始判定部は、前記送信時間比較部からの比較結果、および、前記送信時間管理部からの送信する送信チャネルＩＤを受け取り、前記送信チャネルＩＤの送信処理を開始するかどうかを判定し、その判定結果および前記送信チャネルＩＤを前記パケット処理部に通知し、前記ＤＭＡ部および前記パケットデータサイズ算出部に送信処理を開始するチャネルＩＤを通知する、
ことを特徴とする付記２に記載のデータ配信装置。

（付記４）
前記パケットデータサイズ算出部は、前記処理開始判定部から入力される送信チャネルＩＤから、１パケットを生成するのに要するデータサイズを算出し、その算出結果を前記ＤＭＡ部および前記パケット処理部に通知する、
ことを特徴とする付記３に記載のデータ配信装置。

（付記５）
前記ＤＭＡ部は、
前記データ格納部から、前記パケットデータサイズ算出部から通知されたデータサイズ分だけ読み出して格納する送信データバッファと、
前記送信データバッファ格納したデータサイズおよび制御情報を格納する送信データ情報格納部と、を含む、
ことを特徴とする付記３または付記４に記載のデータ配信装置。

（付記６）
前記ＤＭＡ部は、さらに、
前記パケットデータサイズ算出部から通知されたチャネルＩＤの送信データが、前記送信データ情報格納部に格納された送信データ情報により送信要求されているかどうかを走査する第１チャネルＩＤ走査部を含む、
ことを特徴とする付記５に記載のデータ配信装置。

（付記７）
前記ＤＭＡ部は、さらに、
前記データ格納部から送信要求を通知されると、該当チャネルＩＤが存在するかどうか、前記送信データ情報格納部を走査する第２チャネルＩＤ走査部を含む、
ことを特徴とする付記５に記載のデータ配信装置。

（付記８）
前記送信時間管理部は、
データ種別、次パケット送信時間およびチャネルＩＤが対応付けられた第１送信時間管理テーブルを含む、
ことを特徴とする付記１乃至付記７のいずれか１項に記載のデータ配信装置。

（付記９）
前記送信時間管理部は、
データ種別、次パケット送信時間、チャネルＩＤおよび次パケット送信時間限界値が対応付けられた第２送信時間管理テーブルと、
前記現在時間を受け取り、前記第２送信時間管理テーブルに基づいてチャネルＩＤを選択するチャネルＩＤ選択部と、を含む、
ことを特徴とする付記１乃至付記７のいずれか１項に記載のデータ配信装置。

（付記１０）
さらに、
前記優先度判定部と前記送信時間管理部の間に設けられ、データ種別とスキップ回数の関係が予め決められているスキップ回数設定テーブル、並びに、前記優先度判定部からの最優先データ種別と前記パケット処理部からのデータ種別を受け取るスキップ回数制御部を含む、
ことを特徴とする付記１乃至付記７のいずれか１項に記載のデータ配信装置。

（付記１１）
前記ＤＭＡ部は、ディスクリプタ型ＤＭＡである、
ことを特徴とする付記１乃至付記１０のいずれか１項に記載のデータ配信装置。

（付記１２）
さらに、
前記パケット処理部により生成された前記パケットを前記ネットワークに送信するＰＨＹ部を有する、
ことを特徴とする付記１乃至付記１１のいずれか１項に記載のデータ配信装置。

（付記１３）
前記データ格納部に格納されるデータは、カメラで撮影された映像データを含み、前記映像データは、異なるチャネルに相当する、異なる解像度の動画像データまたは静止画像データを含む、
ことを特徴とする付記１乃至付記１２のいずれか１項に記載のデータ配信装置。

（付記１４）
前記カメラは、複数の監視カメラを含み、
前記データ配信装置は、前記複数のカメラにより得られたデータを、前記ネットワークを介して制御端末に転送するネットワークインタフェースである、
ことを特徴とする付記１乃至付記１３のいずれか１項に記載のデータ配信装置。

（付記１５）
データ格納部からのデータを受け取ってＤＭＡ転送を行うＤＭＡ部と、前記ＤＭＡ部からの送信データを受け取ってパケットを生成すると共に、前記パケットのデータ種別を判定するパケット処理部と、を含み、生成された前記パケットをネットワークに送信するデータ配信方法であって、
前記データ種別を受け取って、最も優先度の高い最優先データ種別を判定し、
前記最優先データ種別を受け取って、各送信データにおけるチャネルを識別するためのチャネルＩＤと各チャネルの送信時間を管理し、
前記最優先データ種別，前記チャネルＩＤおよび前記各チャネルの送信時間に基づいて、前記パケット処理部が対応するパケット処理を開始するかどうかを判定する、
ことを特徴とするデータ配信方法。

１ ＤＭＡ部
２ パケット処理部
３ ＰＨＹ部
１１，１３ 送信データバッファ
１２，１４ 送信データ情報格納部
１５ チャネルＩＤ走査部(第１チャネルＩＤ走査部)
１６ チャネルＩＤ走査部(第２チャネルＩＤ走査部)
２１ 送信要求検出部
２２ パケット生成部
４１ 送信時間管理部
４２ 現在時間検出部
４３ 送信時間比較部
４４ 優先度判定部
４５ 送信タイミング算出部
４６ 送信時間管理部(チャネルＩＤフィールドを追加した送信時間管理部，送信時間管理部テーブル，第１送信時間管理部テーブル)
４７ パケットデータサイズ算出部
４８ 処理開始判定部
４９ 優先度変更部
100 監視カメラ
110 カメラモジュール
120 エンコーダ
130 プロセッサ
140 データ格納部(メモリ)
150，250，350，450，550，650 ネットワークインタフェース
200 ネットワーク
300 制御端末
400 ユーザ
461 送信時間管理テーブル(第２送信時間管理テーブル)
462 チャネルＩＤ選択部
491 スキップ回数設定テーブル
492 スキップ回数制御部

Claims (8)

1. データ格納部からのデータを受け取ってＤＭＡ転送を行うＤＭＡ部と、前記ＤＭＡ部からの送信データを受け取ってパケットを生成すると共に、前記パケットのデータ種別を判定するパケット処理部と、を含み、生成された前記パケットをネットワークに送信するデータ配信装置であって、
   前記データ種別を受け取って、最も優先度の高い最優先データ種別を判定する優先度判定部と、
   前記最優先データ種別を受け取って、各送信データにおける、同一データ種別における異なる設定のデータであるチャネルを識別するためのチャネルＩＤと各チャネルの送信時間を管理する送信時間管理部と、
   前記送信時間管理部の出力を受け取って、前記パケット処理部が対応するパケット処理を開始するかどうかを判定する処理開始判定部と、
   現在時間を検出する現在時間検出部と、
   前記現在時間と現パケット送信時間を比較する送信時間比較部と、
   送信タイミングを算出する送信タイミング算出部と、
   パケットデータのサイズを算出するパケットデータサイズ算出部と、を有し、
   前記送信時間管理部は、前記最優先データ種別から、最優先チャネルＩＤの現パケット送信時間を前記送信時間比較部に出力すると共に、チャネルＩＤを前記処理開始判定部に出力し、前記送信タイミング算出部の計算結果に基づいて、該当チャネルＩＤの現パケット送信時間を更新し、
   前記処理開始判定部は、前記送信時間比較部からの比較結果、および、前記送信時間管理部からの送信する送信チャネルＩＤを受け取り、前記送信チャネルＩＤの送信処理を開始するかどうかを判定し、その判定結果および前記送信チャネルＩＤを前記パケット処理部に通知し、前記ＤＭＡ部および前記パケットデータサイズ算出部に送信処理を開始するチャネルＩＤを通知する、
   ことを特徴とするデータ配信装置。
2. 前記パケットデータサイズ算出部は、前記処理開始判定部から入力される送信チャネルＩＤから、１パケットを生成するのに要するデータサイズを算出し、その算出結果を前記ＤＭＡ部および前記パケット処理部に通知する、
   ことを特徴とする請求項１に記載のデータ配信装置。
3. 前記ＤＭＡ部は、
   前記データ格納部から、前記パケットデータサイズ算出部から通知されたデータサイズ分だけ読み出して格納する送信データバッファと、
   前記送信データバッファ格納したデータサイズおよび制御情報を格納する送信データ情報格納部と、を含む、
   ことを特徴とする請求項１または請求項２に記載のデータ配信装置。
4. 前記ＤＭＡ部は、さらに、
   前記パケットデータサイズ算出部から通知されたチャネルＩＤの送信データが、前記送信データ情報格納部に格納された送信データ情報により送信要求されているかどうかを走査する第１チャネルＩＤ走査部を含む、
   ことを特徴とする請求項３に記載のデータ配信装置。
5. 前記ＤＭＡ部は、さらに、
   前記データ格納部から送信要求を通知されると、該当チャネルＩＤが存在するかどうか、前記送信データ情報格納部を走査する第２チャネルＩＤ走査部を含む、
   ことを特徴とする請求項３に記載のデータ配信装置。
6. 前記送信時間管理部は、
   データ種別、次パケット送信時間およびチャネルＩＤが対応付けられた第１送信時間管理テーブルを含む、
   ことを特徴とする請求項１乃至請求項５のいずれか１項に記載のデータ配信装置。
7. 前記送信時間管理部は、
   データ種別、次パケット送信時間、チャネルＩＤおよび次パケット送信時間限界値が対応付けられた第２送信時間管理テーブルと、
   前記現在時間を受け取り、前記第２送信時間管理テーブルに基づいてチャネルＩＤを選択するチャネルＩＤ選択部と、を含む、
   ことを特徴とする請求項１乃至請求項５のいずれか１項に記載のデータ配信装置。
8. さらに、
   前記優先度判定部と前記送信時間管理部の間に設けられ、データ種別とスキップ回数の関係が予め決められているスキップ回数設定テーブル、並びに、前記優先度判定部からの最優先データ種別と前記パケット処理部からのデータ種別を受け取るスキップ回数制御部を含む、
   ことを特徴とする請求項１乃至請求項５のいずれか１項に記載のデータ配信装置。

Images