JP4873045B2

JP4873045B2 - 送信側ネットワークと放送システム

Info

Publication number: JP4873045B2
Application number: JP2009118308A
Authority: JP
Inventors: 功上田; 禎明長水; 誠關藤; 聖貴山口
Original assignee: Panasonic Corp; Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Corp; Panasonic Holdings Corp
Priority date: 2009-05-15
Filing date: 2009-05-15
Publication date: 2012-02-08
Anticipated expiration: 2029-05-15
Also published as: JP2010268260A

Description

本発明は、高度化ＩＳＤＢ−Ｓ（ＩｎｔｅｇｒａｔｅｄＳｅｒｖｉｃｅｓＤｉｇｉｔａｌＢｒｏａｄｃａｓｔｉｎｇ−Ｓａｔｅｌｌｉｔｅ）、つまり、高度化衛星放送の規格で運用されることが考えられている、ＴＬＶ（ＴｙｐｅＬｅｎｇｔｈＶａｌｕｅ）伝送技術に関するもので、放送コンテンツを伝送する単位であるＴＬＶコンテナの個数あるいはバイト数を制限することで、Ｇｉｇａｂｉｔイーサーネット出力した際の伝送の破綻を防ぐことを可能にするものである。

従来の放送システムでは、リアルタイム放送システムに適した信号フォーマットとして固定長パケットのＭＰＥＧ２−ＴＳを使用して伝送する方法が一般的である。図１２に従来の放送システムであるＭＰＥＧ２−ＴＳを使用した構成の放送システムを示す。コンテンツ配信者からエンドユーザにコンテンツを送信するとき、コンテンツ配信装置６００から送信側ネットワーク７００、伝送路、受信側ネットワーク８００、表示装置９００への順番に送信する。

コンテンツ配信装置６００は映像や音声、その制御信号をＭＰＥＧ２−ＴＳのパケット形式にエンコードして、送信側ネットワーク７００に出力する。

送信側ネットワーク７００は、多重化部７１０、変調部７２０で構成され、多重化部７１０はコンテンツ配信装置６００から入力されたＭＰＥＧ２−ＴＳのパケット形式の信号を伝送路の信号フォーマットに合わせた形式に多重化して、変調部７２０は多重化部７１０で多重化された信号を伝送路に変調して出力する。

受信側ネットワーク８００は、復調部８１０、デコーダ８２０で構成され、復調部８１０は伝送路から入力された変調信号を復調し多重分離して、デコーダ８２０でＭＰＥＧ２−ＴＳ形式の信号をコンテンツデータにデコードして、表示装置９００へ出力する。

表示装置９００は、受信側ネットワーク８００からコンテンツデータを受け、コンテンツデータの映像や音声を表示する。

一方、コンテンツデータを受信機に蓄積し、受信後にストリームを復元・表示する蓄積型放送サービスの実現に向けた、衛星などの既存の伝送路とＧｉｇａｂｉｔイーサーネットなどの通信網の組み合わせた放送システムが考えられており、高度化ＩＳＤＢ−Ｓで検討されているＴＬＶ伝送技術が期待されている。ＴＬＶ伝送技術は、ｔｙｐｅフィールドによりデータの種類を示し、ｌｅｎｇｔｈフィールドによりデータのサイズを示すことで、Ｖａｌｕｅフィールドに任意の可変長データを格納可能である。このＴＬＶ伝送技術では、パケット種別として、４種類のデータタイプを割り当ててＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）パケットの伝送を可能としている。(非特許文献１)

情報通信審議会諮問第２０２３号「放送システムに関する技術的条件」のうち「衛星デジタル放送の高度化に関する技術的条件」答申書総務省平成２０年７月２９日２９頁

しかしながら、高度化ＩＳＤＢ−Ｓの運用で検討されているＴＬＶ伝送技術においては、ＴＬＶコンテナのサイズは４バイト以上での運用が考えられており、上記従来の方法ではコンテンツデータを含んだＴＬＶコンテナのパケットサイズがＧｉｇａｂｉｔイーサーネットで制限される５１２バイトよりも短い場合、短いパケットが連続して入力されると、ＭＡＣフレーム変換するブロックのメモリバッファがオーバーフローを起こし、ＧｂＥ出力の破綻となって、データの欠落が発生するという課題があった。

本発明は以上の課題を解決することを目的とするものであり、受信側でＧｂＥ出力する際のバッファメモリのオーバーフローを回避するために、受信側にあるＧｉｇａｂｉｔイーサーネットを用いた伝送で支障をきたすことなく、ユーザー端末装置に対して情報の欠落なく送信するＴＬＶ伝送対応の放送システムを提供することである。

前記従来の課題を解決するために、本発明のコンテンツ配信装置は、コンテンツをスロットに構成する送信側ネットワークに配信するコンテンツ配信装置であって、配信するコンテンツを記録するコンテンツ記録部と、コンテンツ記録部からコンテンツを読み出し、コンテンツのバイト数を解析するコンテンツ解析部と、コンテンツ解析部で解析したコンテンツのバイト数に基づいて、コンテンツを分割し、分割後のコンテンツをＩＰパケット化するコンテンツデータ制御部とを備え、コンテンツデータ制御部は、送信側ネットワークから受信したスロット内の分割したコンテンツを収納したコンテンツの情報により、１つのスロットに構成されるコンテンツのバイト数、或いは、コンテンツの個数を計算し、コンテンツのバイト数、或いは、コンテンツの個数が所定の値以上のとき、ヌルデータを出力する。

本構成によって、送信側ネットワークで構成されるスロット内のコンテンツの個数とバイト数を制御することができる。

高度化ＩＳＤＢ−Ｓの運用で検討されているＴＬＶ伝送するシステムにおいて、送信側で送るコンテナの個数やバイト数を制限することで、受信側にあるＧｉｇａｂｉｔイーサーネットを用いた伝送で支障をきたすことなく、ユーザー端末装置に対して情報の欠落なく送信することができる。

本発明の実施例１に係るＴＬＶ伝送対応の放送システムの構成図本発明の実施例１に係るＭＡＣフレーム構成図本発明の実施例１に係るＭＡＣフレーム変換部３３０の概要図本発明のＭＡＣフレーム変換部３３０の内部動作概要図本発明の実施例１に係るコンテンツ配信装置１００と送信側ネットワーク２００の概要図本発明の実施例１に係るコンテンツ配信装置１００の動作説明図本発明の実施例１に係るフィードバック補正制御におけるコンテンツ配信装置１００の動作説明図本発明のコンテナの制限サイズを求める式を示す図本発明の実施例２に係るコンテンツ配信装置１００と送信側ネットワーク２００の概要図本発明の実施例２に係るフィードバック補正制御におけるコンテンツ配信装置１００の動作説明図本発明のスロット単位あたりのコンテナ数の制限個数を求める式を示す図従来の放送システムの構成図

以下本願発明の実施例について図面を用いて説明する。

まず、本発明の実施例１に係るＴＬＶ対応の放送システムの概要について説明する。図１は本発明の実施例１に係るＴＬＶ対応の放送システムの構成図を示す。ＴＬＶ対応の放送システムは、コンテンツ配信者からエンドユーザにコンテンツを送信するとき、コンテンツ配信装置１００から送信側ネットワーク２００、伝送路、受信側ネットワーク３００、ユーザー端末装置４００への順番に送信する。本発明の放送システムは、主に衛星放送での使用を主としている。そのため、伝送路は衛星から送信された電波が通過する空間を想定している。また、図１ではユーザー端末装置４００を１台のみ記載しているが、受信側ネットワーク３００には複数台のユーザー端末装置４００が接続されている。

コンテンツ配信装置１００は、映像や音声、文字情報などのデータをコンテンツとして送信側ネットワーク２００へ出力する。なおコンテンツ配信装置１００は、受信側ネットワーク３００やユーザー端末装置４００などで使用されるＭＡＣアドレス情報を含ませることも可能である。

送信側ネットワーク２００は、データを伝送路に出力するために、コンテンツ配信装置１００から入力されたコンテンツデータをＴＬＶコンテナ化するＴＬＶコンテナ化部２１０と、ＴＬＶコンテナ化部２１０でコンテナ化されたＴＬＶコンテナを伝送路上の信号形式に変換するために特定のフォーマットに多重化する多重化部２２０と、多重化部２２０で多重化された信号を伝送路で出力するために変調する変調部２３０で構成されている。特に、変調部２３０は、多重化されたデータを変調する機能に加え、伝送路の最小単位である固定長のスロット期間の中でデータ範囲を示す情報や、スロットに多重されているデータの種類を示す情報をＴＭＣＣデータとして変調する機能を有している。

ここで、ＴＬＶコンテナとは、ＴｙｐｅデータとＬｅｎｇｔｈデータとＶａｌｕｅデータの３つのデータから構成されており、Ｖａｌｕｅデータはコンテンツ配信装置１００から送信するコンテンツなどのデータで、ＬｅｎｇｔｈデータはＴＬＶコンテナのサイズ情報を含んだデータで、ＴｙｐｅデータはＴＬＶコンテナの種類の情報を含んだデータである。

受信側ネットワーク３００は、送信側ネットワーク２００からデータを受信し、ユーザー端末装置４００へＧｉｇａｂｉｔイーサーネットの形式で出力するものである。そのために、受信側ネットワーク３００は、伝送路から入力した変調波を復調し、伝送路上の信号形式からデータを多重分離する復調部３１０と、復調部３１０で多重分離したデータからＴＬＶコンテナのＶａｌｕｅデータを抜き出すＴＬＶデコンテナ化部３２０と、ＴＬＶデコンテナ化部３２０で抜き出されたデータをＧｉｇａｂｉｔイーサーネット形式のデータに変換するＭＡＣフレーム変換部３３０と、ＭＡＣフレーム変換部３３０で変換されたデータを外部のユーザー端末装置４００のＧｂＥ＿Ｉ／Ｆに出力するＧｂＥ＿Ｉ／Ｆ３４０で構成される。特に、復調部３１０は、変調された変調信号から、まずＴＭＣＣデータを復調し、多重化されたデータを復調する際には、ＴＭＣＣデータからスロットに含まれているデータ範囲を認識して復調している。また、復調部３１０は、多重化されたデータを多重分離する際にも、ＴＭＣＣデータから多重されているデータの種類を認識して多重分離している。

ここで、ＭＡＣフレーム変換部３３０は、ＴＬＶデコンテナ化部３２０で抜き出されたＴＬＶコンテナのＶａｌｕｅデータ、つまり、コンテンツ配信装置１００から送信されたコンテンツとユーザー端末装置４００などで使用されるＭＡＣアドレス情報をＭＡＣフレームに変換する。このとき、ＭＡＣフレームのヘッダーに特定のＭＡＣアドレスのみを付加したり、複数のＭＡＣアドレスを付加したりすることが可能である。また、ヘッダーに付加するＭＡＣアドレスは、ＭＡＣフレーム変換部３３０が保有しているＭＡＣアドレスを使用したり、コンテンツ配信装置１００から送信されてきたＭＡＣアドレスを使用したりすることができる。

ユーザー端末装置４００は、コンテンツデータを映像表示するために、受信側ネットワーク３００から入力したＧｉｇａｂｉｔイーサーネット形式のデータを受け取り、コンテンツデータを出力する情報端末部４１０と、情報端末部４１０が出力したコンテンツデータを映像表示する表示部４２０で構成される。

情報端末部４１０は、ＭＡＣフレーム変換部３３０で宛先としてＭＡＣアドレスがヘッダーに付加された場合、コンテンツデータを受け取ることができる。また、ＭＡＣフレーム変換部３３０で複数の宛先のＭＡＣアドレスが付加された場合、宛先に対応する複数の情報端末部４１０でそれぞれデータを受け取ることが可能である。また、情報端末部４１０はモニタにリアルタイムで出力する必要はなく、ハードディスクなどの記録部を接続、或いは、内蔵することで、コンテンツデータを蓄積することが可能となる。

次に、本発明の実施例１に係るＴＬＶ対応の放送システムの受信側ネットワークについて詳細を説明する。受信側ネットワーク３００は、送信側ネットワーク２００から伝送路経由で受信したＴＬＶコンテナのデータを外部機器であるユーザー端末装置４００にＧｉｇａｂｉｔイーサーネットで出力するＭＡＣフレームに変換する機能を有している。まず、ＴＬＶコンテナをＧｉｇａｂｉｔイーサーネットで出力するためのＴＬＶコンテナのＭＡＣフレームについて説明する。図２は、本発明の実施例１に係るＭＡＣフレームの構成図である。

ＴＬＶコンテナのデータフォーマット変換後のＭＡＣフレームは、Ｇｉｇａｂｉｔイーサーネットの規格であるＩＥＥＥＳｔａｎｄａｒｄ８０２．３に基づいている。図２に示すように、宛先ＭＡＣアドレスからＣａｒｒｉｅｒＥｘｔｅｎｄまでのサイズは最小で５１２バイトとなっているため、ＴＬＶコンテナのサイズが４６６バイト以下の場合、ＣａｒｒｉｅｒＥｘｔｅｎｄのデータサイズを調整することで最小サイズ５１２バイトにしている。そして、ＴＬＶコンテナのＭＡＣフレーム変換は、プリアンブルとＩＦＧを更に付加することで、最小サイズ５３２バイトとなっている。

さらに、ＭＡＣフレーム変換部３３０がＴＬＶコンテナをこのＭＡＣフレームにＭＡＣフレーム変換することについて説明する。図３は、本発明の実施例１に係るＭＡＣフレーム変換部３３０の概要図である。ＭＡＣフレーム変換部３３０は、入力されたＴＬＶコンテナをバッファメモリ３３１で一旦蓄積し、ヘッダー付加部３３２でＴＬＶコンテナにＵＤＰｈｅａｄｅｒを付加した後、ＩＰｖ４ｈｅａｄｅｒを付加して、ＩＰｖ４パケットの形式にする。さらに、宛先ＭＡＣアドレス、送信元ＭＡＣアドレス、タイプ、ＦＣＳを付加することで、ＭＡＣフレームとし、そのＭＡＣフレームのサイズが５１２バイト未満の場合、ＭＡＣフレームのサイズと合わせて５１２バイトになるようにＣａｒｒｉｅｒＥｘｔｅｎｄのデータを最後尾に付加する。そして先頭を示すプリアンブルやパケット間の間を示すＩＦＧの期間を加えたサイズのパケットをＧｂＥ＿Ｉ／Ｆ３４０に出力する。

ＭＡＣフレーム変換部３３０への入力速度は、受信ネットワーク３００のデータ処理の動作周波数になり、バイトクロック周波数１８．５ＭＨｚとしている。一方、ＭＡＣフレーム変換部３３０の出力速度は、ＧｂＥ＿Ｉ／Ｆの動作モードで決まり、ＧＭＩＩの動作モードで１２５ＭＨｚである。入力速度より出力速度が６．７倍と速いため、パケットサイズであるＴＬＶコンテナサイズが７９バイト（５３２バイトの１／６．７）以上であれば、バッファメモリのオーバーフローを理論上起こすことはない。しかし、ＴＬＶコンテナサイズが７８バイト未満になると、ヘッダーのオーバーヘッドが増加し、結果として出力のスループットが低下する現象が生じる。

ＭＡＣフレーム変換部３３０の出力のスループットの低下の様子の例としてＴＬＶコンテナのＭＡＣフレーム変換部３３０の内部動作として、入力に対するヘッダー付加後の出力の処理を示す。図４は本発明のＭＡＣフレーム変換部３３０の内部動作概要図である。

ＭＡＣフレーム変換部３３０は、伝送路の最小単位である固定長のスロット期間を処理範囲として、ＭＡＣフレームにおけるヘッダーの割合が最も大きくなる最小バイトサイズ（４バイト）のコンテナＮ個と、５０４９バイトからＮ個の最小コンテナのバイト数の合計を引いた余りバイト数サイズをもつコンテナ１個を入力している。そして、ＭＡＣフレーム変換部３３０は、図２で示す最小ＭＡＣフレームサイズ（５３２バイト）のＭＡＣフレームＮ個を出力することになり、出力期間が入力期間よりも長くなったときに出力のスループットが低下する。出力期間が入力期間よりも長い状態が続くと、コンテナデータがバッファメモリに蓄積され続け、いずれバッファメモリからコンテナデータがオーバーフローを起こすことになる。

次にコンテナ配信装置１００と送信側ネットワーク２００について詳細を説明する。コンテナ配信装置１００と送信側ネットワーク２００では受信側ネットワーク３００で起きるコンテナデータのオーバーフローを回避する。そのために、コンテナデータの中身であるコンテンツデータを出力するコンテナ配信装置１００が、コンテンツを解析し、送信側ネットワーク２００のＴＬＶコンテナ化部２１０からのフィードバック補正信号からコンテンツデータの長さを制御することで、コンテナのサイズを調整する。コンテンツデータの長さを変化する手段として、図５に本発明の実施例１に係るコンテンツ配信装置１００と、送信側ネットワーク２００の概要図を示す。

図５に示すように、コンテンツ配信装置１００は、コンテンツ記録部１０１と、コンテンツ解析部１０２と、コンテンツデータ制御部１０３で構成されている。送信側ネットワーク２００のＴＬＶコンテナ化部２１０は、バッファメモリ２１１と、データ解析部２１２と、ヘッダー作成部２１３と、ＴＬＶコンテナ生成部２１４と、コンテナ長解析部２１５で構成されている。そして、送信側ネットワーク２００の多重化部２２０は、バッファメモリ２２１と、スロット構成部２２２で構成されている。

コンテンツ記録部１０１は、ユーザー端末装置４００に配信し出画するコンテンツであるコンテンツソースを記録している。

コンテンツ解析部１０２は、コンテンツ記録部１０１からコンテンツソースを読み出し、映像や音声などのコンテンツソースの種類やコンテンツソースの長さを解析する。

コンテンツデータ制御部１０３は、コンテンツ解析部１０２で解析したコンテンツソースの種類や長さから、コンテンツソースの分割後のデータの長さを決定し、分割したコンテンツデータを結合するのに必要な制御データを付加し、ユーザー端末装置４００や他の情報端末装置へ送るために分割後のデータをＩＰパケット化することで、ＴＬＶコンテナのＶａｌｕｅデータ単位となるコンテンツデータを生成する。また、ＴＬＶコンテナ化部２１０からのコンテナの長さ情報から、３つのコンテナの平均コンテナ長が特定の長さ以下になるように、ヌルデータを追加してコンテンツデータを制御するフィードバック補正機能も有している。

バッファメモリ２１１は、コンテンツ配信装置１００から入力したコンテンツデータを蓄積する。

データ解析部２１２は、コンテンツ配信装置１００から入力したコンテンツデータのサイズと種類を解析し、ヘッダー作成部２１３にその解析情報を出力する。

ヘッダー作成部２１３は、データ解析部２１２から入力した解析結果であるコンテンツデータのサイズと種類からＬｅｎｇｔｈデータとＴｙｐｅデータを作成し、ＴＬＶコンテナ生成部２１４に出力する
ＴＬＶコンテナ生成部２１４は、バッファメモリ２１１に蓄積されたコンテンツデータをＶａｌｕｅデータとして読み出し、このＶａｌｕｅデータにヘッダー作成部２１３から入力されたＬｅｎｇｔｈデータとＴｙｐｅデータをヘッダーとして結合することで、ＴＬＶコンテナを生成する。

コンテナ長解析部２１５は、ＴＬＶコンテナ生成部２１４から出力されたＴＬＶコンテナのコンテナ長を解析し、その解析結果をコンテンツ配信部１００のコンテンツデータ制御部１０３に出力する。

バッファメモリ２２１は、ＴＬＶコンテナ化部２１０のＴＬＶコンテナ生成部２１４から入力したＴＬＶコンテナを蓄積する。

スロット構成部２２２は、バッファメモリ２２１からＴＬＶコンテナを読み出し伝送路の信号形式である固定長のスロット単位に変換し、変調部２３０へ出力する。

ここで、コンテンツ配信装置１００の内部動作の詳細について、コンテンツデータをコンテナのＶａｌｕｅデータとして出力する様子で説明する。図６は、本発明の実施例１に係るコンテンツ配信装置１００の動作説明図である。図６にコンテンツ配信装置１００の構成図と処理過程を示す。コンテンツ記録部１０１は、配信されるコンテンツが蓄積しており、配信するコンテンツが決定すると、コンテンツ解析部１０２によって、配信するコンテンツを読み出される。そして、コンテンツ解析部１０２は、読み出したコンテンツ内のコンテンツソースが映像データか音声データかを解析し、そのコンテンツソースの長さも解析する。

コンテンツデータ制御部１０３は、解析されたコンテンツソースを複数のデータに分割し、コンテンツ解析部１０２の解析結果や分割データの情報を制御データとして生成する。この制御データは、分割された複数のデータを後に統合するために必要となる。コンテンツデータ制御部１０３は、制御データを分割されたデータのヘッダーに付加し、更にＩＰｖ４ヘッダーを付加してＩＰパケット化を行い、ＴＬＶコンテナのＶａｌｕｅデータとして出力する。ＩＰｖ４ヘッダーを付加することは、ユーザー端末装置４００や他の情報端末装置に送信可能とするために必要である。図６では、コンテンツ解析部１０２がコンテンツソースとして映像データを解析し、コンテンツデータ制御部１０３が１つの映像データを８０３２個に分割し、制御データとＩＰｖ４ヘッダーをヘッダーに付加してＩＰパケット化することで、８０３２個のＴＬＶコンテナのＶａｌｕｅデータが作成される。

次に、コンテンツデータ制御部１０３が送信側ネットワーク２００のＴＬＶコンテナ化部２１０からのフィードバック補正制御信号をもとにコンテンツデータにヌルデータを追加して構成を変更した様子を説明する。図７は、本発明の実施例１に係るフィードバック補正制御におけるコンテンツ配信装置１００の動作説明図である。例えば、コンテンツデータ制御部１０３がコンテンツ解析部１０２から、１００メガバイトの映像コンテンツソースを入力したときのコンテンツソースの一部の３００バイトのデータをＩＰｖ４パケット形式のＩＰパケット化で処理したときを説明する。

コンテンツ解析部１０２で、コンテンツ記録部１０１に蓄積されているコンテンツソースのサイズと種類を解析し、コンテンツの種類は映像データ、コンテンツソースのサイズは１００メガバイトとして解析している。コンテンツデータ制御部１０３は、コンテンツ解析部１０２で解析されたコンテンツソースの種類とサイズの情報や送信側ネットワーク２００のＴＬＶコンテナ化部２１０からのフィードバック補正制御信号をもとにコンテンツデータの構成を決定する。

ここで、解析された映像コンテンツソースの一部である３００バイトを２４バイト、２３４バイト、４２バイトの３つのデータに分割したとする。フィードバック補正制御信号がない場合、分割された各映像コンテンツデータは、１０バイトの制御データをヘッダーとして付加され、加えて２０バイトのＩＰｖ４ヘッダーが付加され、それぞれ５４バイト、２６４バイト、７２バイトとなり、ＴＬＶコンテナのＶａｌｕｅデータとして出力される。そして、出力されたＴＬＶコンテナのＶａｌｕｅデータは、ＴＬＶコンテナ化部２１０のＴＬＶコンテナ生成部２１４で２バイトのＴｙｐｅデータと２バイトのＬｅｎｇｔｈデータが付加され、５８バイト、２６８バイト、７６バイトのＴＬＶコンテナにそれぞれなる。

一方、フィードバック補正制御信号がある場合、コンテナ長解析部２１５では、設けた特定の制限サイズ（７６バイト）よりＴＬＶコンテナのサイズが小さいかどうかを判断し、小さい場合はコンテンツデータ制御部１０３に７６バイト以上になるように差分データを送る。つまり、図７の場合は、コンテンツデータ制御部１０３は、ＴＬＶコンテナ化部２１０からフィードバック補正制御信号として差分データを受け取り、出力した７６バイト以下のデータである５８バイト（ヘッダーの付加前は２４バイト）のデータに差分データである１８（＝７６−５８）バイトを付加する必要があることを認識する。そこで、受信側ネットワーク３００で処理に無関係で、バイト数の分オーバーフローを回避することに貢献するヌルデータを付加する。

ここで、平均処理しない場合と３つのコンテナの平均処理した場合の２通りを説明する。まず平均処理しない場合、上述から１８バイトを付加する必要があるため、コンテンツデータ制御部１０３は、先ほど出力した３００バイトのデータに１８バイトのヌルデータを追加して出力することで、ＴＬＶコンテナサイズ７６バイト以上にするために最小の分割データサイズ（２４バイト）に１８バイトのヌルデータを追加して４２バイトと同様になるように出力することができる。初めに出力された３００バイトのデータはバッファ２２１で保存されており、そこにヌルデータを追加するように保存される。これにより、ＴＬＶコンテナサイズは７６バイト以上の条件と同等とみなすことができる。

また３つのコンテナの平均処理した場合、コンテンツデータ制御部１０３は、３つのコンテナ長の平均でヌルデータを付加するか判断する。２４バイトのデータを７６バイト以上のコンテナ長にするには１８バイトのヌルコンテナが必要だが、３つのコンテナの平均コンテナ長は１３０バイト(＝５４バイト＋２４６バイト＋７２バイト)になる。つまり、３つのコンテナ長の平均サイズにおいて７６バイト以上の制限を満たしているため、コンテンツデータ制御部１０３は、ヌルデータを追加する必要がないと判断し、ヌルデータは追加されずに処理される。

ＴＬＶコンテンツでヌルコンテナを出力する判断をもつとする。
２４バイトのコンテンツデータを出力して、フィードバック補正が必要とするのが、だいたい２００バイト後としている。

ここで特定の制限サイズ（７６バイト）について、詳細を以下に述べる。図８は、本発明のコンテナの特定の制限サイズを求める式を示す図である。特定の制限サイズの値は、受信側ネットワーク３００でオーバーフローを必ず起こさない値が考えられる。高度化ＩＳＤＢ−Ｓの規格においては、変調方式が３２ＡＰＳＫで、符号化率９／１０の運用時にスロットのデータバイト数が最も大きくなり、スロットのデータバイト数は５０４９バイトになる。出力クロックは、シンボルレート３２．５９４１ＭＨｚから導かれたバイトクロックである。オーバーフローを起こさない最小コンテナサイズとして、スロット単位あたりで処理可能な最小サイズのコンテナ数Ｎ個が考えられ、計算される値は最小ＧｂＥ(Ｇｉｇａｂｉｔイーサーネットの出力サイズ）×Ｎ≧スロット期間であり、図８のように計算するとＮ≦６７となる。そして、スロットのデータバイト数５０４９から処理可能な最小サイズのコンテナ数６７を割った値より大きい整数値で最小コンテナサイズは７６バイトとなる。

かかる構成によれば、コンテンツ配信装置１００で生成される３個のコンテンツデータのサイズを平均し、その平均値と制限サイズを比較して平均値が制限サイズ以下であるときにヌルパケットを送信することにより、受信側ネットワーク３００で起こるオーバーフローを回避することができる。

なお、本実施例において、ＩＰパケット化としてＩＰｖ４ヘッダーを例にしたが、ＩＰｖ６ヘッダーや圧縮ＩＰヘッダー、無ＩＰとしても良い。この場合、ＩＰパケットの種類がランダムに変更されても、フィードバックにより制限を守ることができるという利点がある。

なお、本実施例において、フィードバック補正信号による補正に関して３個のコンテナの平均コンテナ長を例にしたが、平均対象個数を３個に限定するものではなく、例えば１スロット期間の個数としてもよい。オーバーフローを起こす受信側ネットワーク３００のＭＡＣフレーム変換部３３０のバッファメモリの容量を大きくすることで、平均対象個数を多くすることができ、無駄なヌルデータを付加する必要を最小限に抑えることができるという利点がある。

つぎに、本発明の実施例２に係るＴＬＶ対応の放送システムの概要について説明する。本発明の実施例２に係るＴＬＶ対応の放送システムの構成図は図１に示す実施例１と同様である。実施例２では、送信側ネットワークの構成が実施例１と異なっている。そこで、コンテナ配信装置１００と送信側ネットワーク２００について詳細を説明する。コンテナ配信装置１００と送信側ネットワーク２００では受信側ネットワーク３００で起きるコンテナデータのオーバーフローを回避する。そのために、コンテナデータの中身であるコンテンツデータを出力するコンテナ配信装置１００が、コンテンツを解析し、送信側ネットワーク２００の多重化部２２０からのフィードバック補正信号からコンテンツデータの長さを制御することで、コンテナのサイズを調整する。コンテンツデータの長さを変化する手段として、図９に本発明の実施例１に係るコンテンツ配信装置１００と、送信側ネットワーク２００の概要図を示す。

図９に示すように、コンテンツ配信装置１００は、コンテンツ記録部１０１と、コンテンツ解析部１０２と、コンテンツデータ制御部１０３で構成されている。送信側ネットワーク２００のＴＬＶコンテナ化部２１０は、バッファメモリ２１１と、データ解析部２１２と、ヘッダー作成部２１３と、ＴＬＶコンテナ生成部２１４で構成されている。そして、送信側ネットワーク２００の多重化部２２０は、バッファメモリ２２１と、スロット構成部２２２と、コンテナ解析部２２３と、バッファメモリ２２４で構成されている。

コンテンツデータ制御部１０３は、コンテンツ解析部１０２で解析したコンテンツソースの種類や長さから、コンテンツソースの分割後のデータの長さを決定し、分割したコンテンツデータを結合するのに必要な制御データを付加し、ユーザー端末装置４００や他の情報端末装置へ送るために分割後のデータをＩＰパケット化することで、ＴＬＶコンテナのＶａｌｕｅデータ単位となるコンテンツデータを生成する。また、多重化部２２０からのスロット内のコンテナ情報から、スロット内のコンテナ数が特定の個数以下になるように、ヌルデータを追加してコンテンツデータを制御するフィードバック補正機能も有している。

バッファメモリ２２１は、ＴＬＶコンテナ化部２１０のＴＬＶコンテナ化部２１０から入力したＴＬＶコンテナを蓄積する。

スロット構成部２２２は、バッファメモリ２２１からＴＬＶコンテナを読み出し伝送路の信号形式である固定長のスロット単位に変換する。

コンテナ解析部２２３は、スロット構成部２２２から出力されたスロットデータから各スロット内のＴＬＶコンテナ数をカウントし、そのカウント結果をコンテンツ配信部１００のコンテンツデータ制御部１０３に出力する。

バッファメモリ２２４は、１フレーム１２０スロット分のデータを蓄積できるメモリを持ち、コンテナ解析部２２３の補正フィードバックがある場合に、ヌルコンテナを各スロットの末尾に挿入できるようにスロット単位でデータを蓄積している。

ここで、コンテンツ配信装置１００の内部動作は実施例１の図６と同じであるため、説明は省略する。

次に、コンテンツデータ制御部１０３が送信側ネットワーク２００の多重化部２１０からのフィードバック補正制御信号をもとにコンテンツデータにヌルデータを追加して構成を変更した様子を説明する。図１０は、本発明の実施例２に係るフィードバック補正制御におけるコンテンツ配信装置１００の動作説明図である。例えば、コンテンツデータ制御部１０３が、コンテンツ解析部１０２から映像コンテンツソースを入力したとき、１スロットあたり１３２個のＴＬＶコンテナが多重されるようなコンテンツソースの分割で、コンテンツソースの一部の４バイト程度のコンテンツデータをＩＰｖ４パケット形式のＩＰパケット化で処理したときを説明する。

コンテンツ解析部１０２で、コンテンツ記録部１０１に蓄積されているコンテンツソースのサイズと種類を解析し、コンテンツの種類は映像データとして解析している。コンテンツデータ制御部１０３は、コンテンツ解析部１０２で解析されたコンテンツソースの種類とサイズの情報や送信側ネットワーク２００の多重化部２２０からのフィードバック補正制御信号をもとにコンテンツデータの構成を決定する。

ここで、まず初めに解析された映像コンテンツソースの一部であるコンテンツデータを４バイト程度に分割して出力したとする。フィードバック補正制御信号がない場合、分割された各映像コンテンツデータは、１０バイトの制御データをヘッダーとして付加され、加えて２０バイトのＩＰｖ４ヘッダーが付加され、３４バイト程度のＴＬＶコンテナのＶａｌｕｅデータとして出力される。そして、出力されたＴＬＶコンテナのＶａｌｕｅデータは、ＴＬＶコンテナ化部２１０のＴＬＶコンテナ生成部２１４で２バイトのＴｙｐｅデータと２バイトのＬｅｎｇｔｈデータが付加され、３８バイト程度のＴＬＶコンテナになる。次にスロット構成部２２２で１スロットあたり５０４９バイトのスロットに多重されていくことで、１スロットあたり１３２個のＴＬＶコンテナが多重される。

一方、フィードバック補正制御信号がある場合、多重化部２２０のコンテナ解析部２２３は、スロットに多重される先頭のＴＬＶコンテナのコンテナ情報をコンテンツデータ制御部１０３に送る。コンテンツデータ制御部１０３は、コンテナ解析部２２３からのフィードバックにより、すでに出力したコンテンツデータの中のどのコンテンツデータがスロット構成部２２２でスロットの先頭に多重されたことを認識する。

また、コンテンツデータ制御部１０３は、出力するコンテンツデータに制御データ１０バイトとＩＰｖ４ヘッダー２０バイトを付加することで、ＴＬＶコンテナのＶａｌｕｅデータとし、ＴＬＶコンテナのＶａｌｕｅデータにＴｙｐｅデータ２バイトとＬｅｎｇｔｈデータ２バイトを付加することで、ＴＬＶコンテナとすることを認識している。これにより、コンテンツデータ制御部１０３は、出力しているコンテンツデータに３４バイト(＝１０＋２０＋２＋２)を付加したサイズをＴＬＶコンテナ一個分と算出でき、フィードバック補正信号から得たスロットの先頭に多重されたコンテンツ番号から、現在出力を予定しているコンテンツデータのコンテンツ番号までのＴＬＶコンテナの合計個数と合計バイト数を算出する。

そして、コンテンツデータ制御部１０３は、現在出力を予定しているコンテンツデータにより、スロットに多重されるＴＬＶコンテナの合計個数がスロット内のコンテナ数を特定の制限個数（５８個）であるかどうか、或いは、スロットに多重されるＴＬＶコンテナの合計バイトがスロットサイズ（５０４９バイト）以上であるかどうかの計算を行う。

現在出力を予定しているコンテンツデータが制限個数（５８個）以下、かつ、スロットに多重されるＴＬＶコンテナの合計バイトがスロットサイズ（５０４９バイト）未満である場合、コンテンツデータ制御部１０３は現在出力を予定しているコンテンツデータをそのまま出力する。

また、現在出力を予定しているコンテンツデータが制限個数（５８個）以下、かつ、スロットに多重されるＴＬＶコンテナの合計バイトがスロットサイズ（５０４９バイト）以上である場合、コンテンツデータ制御部１０３は、コンテンツデータの出力を一時的に止め、スロットサイズ（５０４９バイト）から直前のコンテンツデータまでのスロットに多重されるＴＬＶコンテナの合計バイトを差し引いたバイト数（差分データ）をヌルデータとして出力する。その後、現在出力を予定しているコンテンツデータを次のスロットの先頭になるコンテンツデータとして出力する。

また、現在出力を予定しているコンテンツデータが制限個数（５８個）、かつ、スロットに多重されるＴＬＶコンテナの合計バイトがスロットサイズ（５０４９バイト）未満である場合、コンテンツデータの出力を一時的に止め、スロットサイズ（５０４９バイト）から直前のコンテンツデータまでのスロットに多重されるＴＬＶコンテナの合計バイトを差し引いたバイト数（差分データ）をヌルデータとして出力する。その後、現在出力を予定しているコンテンツデータを次のスロットの先頭になるコンテンツデータとして出力する。

図１０の場合、コンテンツデータ制御部１０３は、多重化部２２０のコンテナ解析部２２３からスロットの先頭コンテナである『映像１』のコンテンツデータを認識し、コンテンツデータ制御部１０３から出力する『映像５９』のコンテンツデータをスロット内のコンテナ数の制限(５８個)をオーバーすることを認識する。そこで、コンテンツ解析部１０２からのコンテンツデータの出力を一時的に止めて、差分データである２８４５(＝５０４９−２２０４)バイトのヌルデータを、１スロット目の末尾のデータとして出力する。

つぎに、コンテンツデータ制御部１０３は、『映像５９』〜『映像１１６』までのコンテンツデータを含むＴＬＶコンテナは２番目のスロットに多重することを認識し、同様に差分データである２８４５（＝５０４９−２２０４）バイトのヌルデータを、２スロット目の末尾のデータとして出力し、３番目のスロットも同様に４４０８（＝５０４９−６４１）バイトのヌルデータを、３スロット目の末尾のデータとして出力する。

つまり、１スロットあたり１３２個に分割された映像コンテンツデータは、フィードバック補正制御信号のない時では１３２個のＴＬＶコンテナとして１スロットに多重されていたが、フィードバック補正制御信号のある時では、１スロットあたり５８個までのＴＬＶコンテナとして多重され、残り５９個目以降のＴＬＶコンテナは次のスロットに多重され、１３２個のＴＬＶコンテナが多重されるまで繰り返される。また、スロットあたり５９個目以上になるスロットデータ部分はヌルデータに置き換えられる。上記のことが繰り返されることで、スロット内のコンテナ数は５８個以下に制限される。

ここで特定の制限個数（５８個）について、詳細を以下に述べる。図１１は、本発明のスロット単位あたりのコンテナ数の特定の制限個数を求める式を示す図である。特定の制限個数の値は、受信側ネットワーク３００でオーバーフローを必ず起こさない値が考えられる。高度化ＩＳＤＢ−Ｓの規格においては、変調方式が３２ＡＰＳＫで、符号化率９／１０の運用時にスロットのデータバイト数が最も大きくなり、スロットのデータバイト数は５０４９バイトになる。出力クロックは、シンボルレート３２．５９４１ＭＨｚから導かれたバイトクロックである。オーバーフローを起こさないぎりぎりのパターン（ワーストパターン）として、最もオーバーヘッドの割合が高くなる最小コンテナである４バイトのコンテナ数Ｎ個が考えられ、計算される値は（スロットバイト数−４×Ｎ）＋ヘッダー＋（最小コンテナサイズ＋ヘッダー）×Ｎ≧スロット期間であり、Ｎ≦５７である。つまり、最小コンテナのときコンテナ最大個数は５７個となり、余りバイト数のサイズをもつコンテナ１個を加えてスロット単位あたり５８個までとなる。

かかる構成によれば、コンテンツ配信装置１００において現在出力を予定しているコンテンツデータのコンテンツ番号までのＴＬＶコンテナの合計個数と合計バイト数を算出することにより、受信側のＭＡＣフレーム変換部でのＭＡＣフレーム変換でオーバーフローを起すことがなくなりＧｉｇａｂｉｔイーサーネットを用いた伝送で支障をきたすことなく、ユーザー端末装置に対して情報の欠落なく送信することができる。

なお、本実施例において、コンテンツデータ制御部１０３でコンテンツ解析部１０２の解析結果や分割データの情報を制御データとして生成するとしたが、コンテンツ解析部１０２の解析結果や分割データの情報に加え、ＴＬＶコンテナを情報端末に送るためのＩＰパケット情報を含ませるとしてもよい。（制御データにＩＰ＿ｖ４ヘッダーを付加することで、ユーザー端末装置４００などの情報端末に送信できるが、）制御データにさらにＩＰパケット情報を含ませることで、一定の条件を満たした場合に、さらに他の情報端末装置に送ることができるなど、受信側の状況により、情報端末装置に自動的にアクセスできるなど、フレキシブルな使用方法が可能という利点がある。

なお、本実施例において、ＧｂＥ＿Ｉ／Ｆ３４０としてギガビットイーサーネットを想定しているが、１０００Ｍｂｐｓ未満のイーサーネットでも運用は可能である。その場合は、ＭＡＣフレーム変換部３３０のＭＡＣフレーム変換がその１０００Ｍｂｐｓ未満のイーサーネットの規格に沿ったデータ転送速度で動作するものとする。

なお、本実施例において、ＴＬＶデコンテナ化部３２０は、Ｖａｌｕｅデータのみを抜き出すとしたが、Ｖａｌｕｅデータと、Ｔｙｐｅデータと、Ｌｅｎｇｔｈデータの全て含むＴＬＶコンテナを抜き出し、そのデータをＭＡＣフレーム変換した後、ＧｂＥ＿Ｉ／Ｆ３４０に出力するとしても良い。その場合は、情報端末部４１０でＴＬＶコンテナのＶａｌｕｅデータを抜き出し、コンテンツデータを表示部４２０に出力する構成とする。

なお、本実施例において、復調部３１０で復調されたＴＭＣＣデータから２つのＶａｌｕｅデータが結合されたＴＬＶコンテナの情報データを、ＭＡＣフレーム変換部３３０でＭＡＣフレーム変換し、ＧｂＥ＿Ｉ／Ｆ３４０に出力することも可能である。その場合は、情報端末部４１０で結合されたＴＬＶコンテナの情報データから、結合されたＶａｌｕｅデータを分割し、コンテンツデータを復元して表示部４２０に出力する構成とする。

受信側の機能制限による、送信側のコンテンツ配信の制限や複雑なレート調整を行う必要がなくなり、市場における不具合を事前に回避する利点がある。そのため、高度化ＩＳＤＢ−Ｓの伝送路規格として成り立つ可能性がある。

１００コンテンツ配信装置
１０１コンテンツ記録部
１０２コンテンツ解析部
１０３コンテンツデータ制御部
２００送信側ネットワーク
２１０ＴＬＶコンテナ化部
２１１バッファメモリ
２１２データ解析部
２１３ヘッダー作成部
２１４ＴＬＶコンテナ生成部
２１５コンテナ長解析部
２２０多重化部
２２１バッファメモリ
２２２スロット構成部
２２３コンテナ解析部
２２４バッファメモリ
３００受信側ネットワーク
３１０復調部
３２０ＴＬＶデコンテナ化部
３３０ＭＡＣフレーム変換部
３３１バッファメモリ
３３２ヘッダー付加部
３４０ＧｂＥ＿Ｉ／Ｆ
４００ユーザー端末装置
４１０情報端末部
４２０表示部

Claims

コンテンツをスロットに構成する送信側ネットワークに配信するコンテンツ配信装置であって、
配信するコンテンツを記録するコンテンツ記録部と、
前記コンテンツ記録部からコンテンツを読み出し、コンテンツのバイト数を解析するコンテンツ解析部と、
前記コンテンツ解析部で解析したコンテンツのバイト数に基づいて、コンテンツを分割し、分割後のコンテンツをＩＰパケット化するコンテンツデータ制御部とを備え、
前記コンテンツデータ制御部は、前記送信側ネットワークから受信したスロット内の分割したコンテンツを収納したコンテンツの情報により、１つのスロットに構成されるコンテンツのバイト数、或いは、コンテンツの個数を計算し、コンテンツのバイト数、或いは、コンテンツの個数が所定の値以上のとき、ヌルデータを出力することを特徴とするコンテンツ配信装置。
前記コンテンツデータ制御部は、
分割後の連続する複数のコンテンツのバイト数の平均値を求め、前記平均値が所定の値よりも小さいとき、ヌルデータを出力することを特徴とする請求項１に記載のコンテンツ配信装置。
前記コンテンツデータ制御部は、
１つのスロットを構成するコンテンツの合計のバイト数が所定値以下で、かつ、所定の個数であるとき、ヌルデータを出力することを特徴とする請求項１に記載のコンテンツ配信装置。