送信側ネットワークと放送システム
【課題】受信側にあるＧｉｇａｂｉｔイーサーネットを用いた伝送で支障をきたすことなく、ユーザー端末装置に対して情報の欠落なく送信する放送システムを提供する。
【解決手段】コンテンツを配信するコンテンツ配信装置からのコンテンツデータをコンテナ化する送信側ネットワークであって、コンテンツ配信装置から配信されたコンテンツデータを所定のバイト数以下になるようにコンテナ化するコンテナ化部と、コンテナ化部がコンテナ化したコンテナを伝送路上の信号形式に変換するために特定のフォーマットに多重する多重化部と、多重化部で多重化された信号を伝送路に出力するために変調する変調部とを備え、コンテナのバイトサイズを制限することにより、Ｇｉｇａｂｉｔイーサーネットを用いた伝送で支障をきたさなくする。
【解決手段】コンテンツを配信するコンテンツ配信装置からのコンテンツデータをコンテナ化する送信側ネットワークであって、コンテンツ配信装置から配信されたコンテンツデータを所定のバイト数以下になるようにコンテナ化するコンテナ化部と、コンテナ化部がコンテナ化したコンテナを伝送路上の信号形式に変換するために特定のフォーマットに多重する多重化部と、多重化部で多重化された信号を伝送路に出力するために変調する変調部とを備え、コンテナのバイトサイズを制限することにより、Ｇｉｇａｂｉｔイーサーネットを用いた伝送で支障をきたさなくする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、高度化ＩＳＤＢ−Ｓ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｂｒｏａｄｃａｓｔｉｎｇ−Ｓａｔｅｌｌｉｔｅ）、つまり、高度化衛星放送の規格で運用されることが考えられている、ＴＬＶ（Ｔｙｐｅ Ｌｅｎｇｔｈ Ｖａｌｕｅ）伝送技術に関するもので、放送コンテンツを伝送する単位であるＴＬＶコンテナの個数あるいはバイト数を制限することで、Ｇｉｇａｂｉｔイーサーネット出力した際の伝送の破綻を防ぐことを可能にするものである。
【背景技術】
【０００２】
従来の放送システムでは、リアルタイム放送システムに適した信号フォーマットとして固定長パケットのＭＰＥＧ２−ＴＳを使用して伝送する方法が一般的である。図７に従来の放送システムであるＭＰＥＧ２−ＴＳを使用した構成の放送システムを示す。コンテンツ配信者からエンドユーザにコンテンツを送信するとき、コンテンツ配信装置６００から送信側ネットワーク７００、伝送路、受信側ネットワーク８００、表示装置９００への順番に送信する。
【０００３】
コンテンツ配信装置６００は映像や音声、その制御信号をＭＰＥＧ２−ＴＳのパケット形式にエンコードして、送信側ネットワーク７００に出力する。
【０００４】
送信側ネットワーク７００は、多重化部７１０、変調部７２０で構成され、多重化部７１０はコンテンツ配信装置６００から入力されたＭＰＥＧ２−ＴＳのパケット形式の信号を伝送路の信号フォーマットに合わせた形式に多重化して、変調部７２０は多重化部７１０で多重化された信号を伝送路に変調して出力する。
【０００５】
受信側ネットワーク８００は、復調部８１０、デコーダ８２０で構成され、復調部８１０は伝送路から入力された変調信号を復調し多重分離して、デコーダ８２０でＭＰＥＧ２−ＴＳ形式の信号をコンテンツデータにデコードして、表示装置９００へ出力する。
【０００６】
表示装置９００は、受信側ネットワーク８００からコンテンツデータを受け、コンテンツデータの映像や音声を表示する。
【０００７】
一方、コンテンツデータを受信機に蓄積し、受信後にストリームを復元・表示する蓄積型放送サービスの実現に向けた、衛星などの既存の伝送路とＧｉｇａｂｉｔイーサーネットなどの通信網の組み合わせた放送システムが考えられており、高度化ＩＳＤＢ−Ｓで検討されているＴＬＶ伝送技術が期待されている。ＴＬＶ伝送技術は、ｔｙｐｅフィールドによりデータの種類を示し、ｌｅｎｇｔｈフィールドによりデータのサイズを示すことで、Ｖａｌｕｅフィールドに任意の可変長データを格納可能である。このＴＬＶ伝送技術では、パケット種別として、４種類のデータタイプを割り当ててＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）パケットの伝送を可能としている。(非特許文献１)
【非特許文献１】情報通信審議会 諮問第２０２３号 「放送システムに関する技術的条件」のうち「衛星デジタル放送の高度化に関する技術的条件」答申書 総務省 平成２０年７月２９日 ２９頁
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、高度化ＩＳＤＢ−Ｓの運用で検討されているＴＬＶ伝送技術においては、ＴＬＶコンテナのサイズは４バイト以上での運用が考えられており、上記従来の方法ではコンテンツデータを含んだＴＬＶコンテナのパケットサイズがＧｉｇａｂｉｔイーサーネットで制限される５１２バイトよりも短い場合、短いパケットが連続して入力されると、ＭＡＣフレーム変換するブロックのメモリバッファがオーバーフローを起こし、ＧｂＥ出力の破綻となって、データの欠落が発生するという課題があった。
【０００９】
本発明は以上の課題を解決することを目的とするものであり、受信側でＧｂＥ出力する際のバッファメモリのオーバーフローを回避するために、受信側にあるＧｉｇａｂｉｔイーサーネットを用いた伝送で支障をきたすことなく、ユーザー端末装置に対して情報の欠落なく送信するＴＬＶ伝送対応の放送システムを提供することである。
【課題を解決するための手段】
【００１０】
前記従来の課題を解決するために、本発明の送信側ネットワークは、コンテンツを配信するコンテンツ配信装置からのコンテンツデータをコンテナ化する送信側ネットワークであって、コンテンツ配信装置から配信されたコンテンツデータを所定のバイト数以下になるようにコンテナ化するコンテナ化部と、コンテナ化部がコンテナ化したコンテナを伝送路上の信号形式に変換するために特定のフォーマットに多重する多重化部と、多重化部で多重化された信号を伝送路に出力するために変調する変調部とを備え、コンテナのバイトサイズを制限する。
【発明の効果】
【００１１】
高度化ＩＳＤＢ−Ｓの運用で検討されているＴＬＶ伝送するシステムにおいて、送信側で送るコンテナのバイト数を制限することで、受信側にあるＧｉｇａｂｉｔイーサーネットを用いた伝送で支障をきたすことなく、ユーザー端末装置に対して情報の欠落なく送信することができる。
【発明を実施するための最良の形態】
【００１２】
以下本願発明の実施の形態について図面を用いて説明する。
【００１３】
（実施の形態１）
まず、本発明の実施の形態３に係るＴＬＶ対応の放送システムの概要について説明する。図１は本発明の実施の形態３に係るＴＬＶ対応の放送システムの構成図を示す。ＴＬＶ対応の放送システムは、コンテンツ配信者からエンドユーザにコンテンツを送信するとき、コンテンツ配信装置１００から送信側ネットワーク２００、伝送路、受信側ネットワーク３００、ユーザー端末装置４００への順番に送信する。本発明の放送システムは、主に衛星放送での使用を主としている。そのため、伝送路は衛星から送信された電波が通過する空間を想定している。また、図１ではユーザー端末装置４００を１台のみ記載しているが、受信側ネットワーク３００には複数台のユーザー端末装置４００が接続されている。
【００１４】
コンテンツ配信装置１００は、映像や音声、文字情報などのデータをコンテンツとして送信側ネットワーク２００へ出力する。なおコンテンツ配信装置１００は、受信側ネットワーク３００やユーザー端末装置４００などで使用されるＭＡＣアドレス情報を含ませることも可能である。
【００１５】
送信側ネットワーク２００は、データを伝送路に出力するために、コンテンツ配信装置１００から入力されたコンテンツデータをＴＬＶコンテナ化するＴＬＶコンテナ化部２１０と、ＴＬＶコンテナ化部２１０でコンテナ化されたＴＬＶコンテナを伝送路上の信号形式に変換するために特定のフォーマットに多重化する多重化部２２０と、多重化部２２０で多重化された信号を伝送路で出力するために変調する変調部２３０で構成されている。特に、変調部２３０は、多重化されたデータを変調する機能に加え、伝送路の最小単位である固定長のスロット期間の中でデータ範囲を示す情報や、スロットに多重されているデータの種類を示す情報をＴＭＣＣデータとして変調する機能を有している。
【００１６】
ここで、ＴＬＶコンテナとは、ＴｙｐｅデータとＬｅｎｇｔｈデータとＶａｌｕｅデータの３つのデータから構成されており、Ｖａｌｕｅデータはコンテンツ配信装置１００から送信するコンテンツなどのデータで、ＬｅｎｇｔｈデータはＴＬＶコンテナのサイズ情報を含んだデータで、ＴｙｐｅデータはＴＬＶコンテナの種類の情報を含んだデータである。
【００１７】
受信側ネットワーク３００は、送信側ネットワーク２００からデータを受信し、ユーザー端末装置４００へＧｉｇａｂｉｔイーサーネットの形式で出力するものである。そのために、受信側ネットワーク３００は、伝送路から入力した変調波を復調し、伝送路上の信号形式からデータを多重分離する復調部３１０と、復調部３１０で多重分離したデータからＴＬＶコンテナのＶａｌｕｅデータを抜き出すＴＬＶデコンテナ化部３２０と、ＴＬＶデコンテナ化部３２０で抜き出されたデータをＧｉｇａｂｉｔイーサーネット形式のデータに変換するＭＡＣフレーム変換部３３０と、ＭＡＣフレーム変換部３３０で変換されたデータを外部のユーザー端末装置４００のＧｂＥ＿Ｉ／Ｆに出力するＧｂＥ＿Ｉ／Ｆ３４０で構成される。特に、復調部３１０は、変調された変調信号から、まずＴＭＣＣデータを復調し、多重化されたデータを復調する際には、ＴＭＣＣデータからスロットに含まれているデータ範囲を認識して復調している。また、復調部３１０は、多重化されたデータを多重分離する際にも、ＴＭＣＣデータから多重されているデータの種類を認識して多重分離している。
【００１８】
ここで、ＭＡＣフレーム変換部３３０は、ＴＬＶデコンテナ化部３２０で抜き出されたＴＬＶコンテナのＶａｌｕｅデータ、つまり、コンテンツ配信装置１００から送信されたコンテンツとユーザー端末装置４００などで使用されるＭＡＣアドレス情報をＭＡＣフレームに変換する。このとき、ＭＡＣフレームのヘッダーに特定のＭＡＣアドレスのみを付加したり、複数のＭＡＣアドレスを付加したりすることが可能である。また、ヘッダーに付加するＭＡＣアドレスは、ＭＡＣフレーム変換部３３０が保有しているＭＡＣアドレスを使用したり、コンテンツ配信装置１００から送信されてきたＭＡＣアドレスを使用したりすることができる。
【００１９】
ユーザー端末装置４００は、コンテンツデータを映像表示するために、受信側ネットワーク３００から入力したＧｉｇａｂｉｔイーサーネット形式のデータを受け取り、コンテンツデータを出力する情報端末部４１０と、情報端末部４１０が出力したコンテンツデータを映像表示する表示部４２０で構成される。
【００２０】
情報端末部４１０は、ＭＡＣフレーム変換部３３０で宛先としてＭＡＣアドレスがヘッダーに付加された場合、コンテンツデータを受け取ることができる。また、ＭＡＣフレーム変換部３３０で複数の宛先のＭＡＣアドレスが付加された場合、宛先に対応する複数の情報端末部４１０でそれぞれデータを受け取ることが可能である。また、情報端末部４１０はモニタにリアルタイムで出力する必要はなく、ハードディスクなどの記録部を接続、或いは、内蔵することで、コンテンツデータを蓄積することが可能となる。
【００２１】
次に、本発明の実施の形態３に係るＴＬＶ対応の放送システムの受信側ネットワークについて詳細を説明する。受信側ネットワーク３００は、送信側ネットワーク２００から伝送路経由で受信したＴＬＶコンテナのデータを外部機器であるユーザー端末装置４００にＧｉｇａｂｉｔイーサーネットで出力するＭＡＣフレームに変換する機能を有している。まず、ＴＬＶコンテナをＧｉｇａｂｉｔイーサーネットで出力するためのＴＬＶコンテナのＭＡＣフレームについて説明する。図２は、本発明の実施の形態３に係るＭＡＣフレームの構成図である。
【００２２】
ＴＬＶコンテナのデータフォーマット変換後のＭＡＣフレームは、Ｇｉｇａｂｉｔイーサーネットの規格であるＩＥＥＥ Ｓｔａｎｄａｒｄ ８０２．３に基づいている。図２に示すように、宛先ＭＡＣアドレスからＣａｒｒｉｅｒ Ｅｘｔｅｎｄまでのサイズは最小で５１２バイトとなっているため、ＴＬＶコンテナのサイズが４６６バイト以下の場合、Ｃａｒｒｉｅｒ Ｅｘｔｅｎｄのデータサイズを調整することで最小サイズ５１２バイトにしている。そして、ＴＬＶコンテナのＭＡＣフレーム変換は、プリアンブルとＩＦＧを更に付加することで、最小サイズ５３２バイトとなっている。
【００２３】
さらに、ＭＡＣフレーム変換部３３０がＴＬＶコンテナをこのＭＡＣフレームにＭＡＣフレーム変換することについて説明する。図３は、本発明の実施の形態３に係るＭＡＣフレーム変換部３３０の概要図である。ＭＡＣフレーム変換部３３０は、入力されたＴＬＶコンテナをバッファメモリ３３１で一旦蓄積し、ヘッダー付加部３３２でＴＬＶコンテナにＵＤＰｈｅａｄｅｒを付加した後、ＩＰｖ４ｈｅａｄｅｒを付加して、ＩＰｖ４パケットの形式にする。さらに、宛先ＭＡＣアドレス、送信元ＭＡＣアドレス、タイプ、ＦＣＳを付加することで、ＭＡＣフレームとし、そのＭＡＣフレームのサイズが５１２バイト未満の場合、ＭＡＣフレームのサイズと合わせて５１２バイトになるようにＣａｒｒｉｅｒ Ｅｘｔｅｎｄのデータを最後尾に付加する。そして先頭を示すプリアンブルやパケット間の間を示すＩＦＧの期間を加えたサイズのパケットをＧｂＥ＿Ｉ／Ｆ３４０に出力する。
【００２４】
ＭＡＣフレーム変換部３３０への入力速度は、受信ネットワーク３００のデータ処理の動作周波数になり、バイトクロック周波数１８．５ＭＨｚとしている。一方、ＭＡＣフレーム変換部３３０の出力速度は、ＧｂＥ＿Ｉ／Ｆの動作モードで決まり、ＧＭＩＩの動作モードで１２５ＭＨｚである。入力速度より出力速度が６．７倍と速いため、パケットサイズであるＴＬＶコンテナサイズが７９バイト（５３２バイトの１／６．７）以上であれば、バッファメモリのオーバーフローを理論上起こすことはない。しかし、ＴＬＶコンテナサイズが７８バイト未満になると、ヘッダーのオーバーヘッドが増加し、結果として出力のスループットが低下する現象が生じる。
【００２５】
ＭＡＣフレーム変換部３３０の出力のスループットの低下の様子の例としてＴＬＶコンテナのＭＡＣフレーム変換部３３０の内部動作として、入力に対するヘッダー付加後の出力の処理を示す。図４は本発明のＭＡＣフレーム変換部３３０の内部動作概要図である。
【００２６】
ＭＡＣフレーム変換部３３０は、伝送路の最小単位である固定長のスロット期間を処理範囲として、ＭＡＣフレームにおけるヘッダーの割合が最も大きくなる最小バイトサイズ（４バイト）のコンテナＮ個と、５０４９バイトからＮ個の最小コンテナのバイト数の合計を引いた余りバイト数サイズをもつコンテナ１個を入力している。そして、ＭＡＣフレーム変換部３３０は、図２で示す最小ＭＡＣフレームサイズ（５３２バイト）のＭＡＣフレームＮ個を出力することになり、出力期間が入力期間よりも長くなったときに出力のスループットが低下する。出力期間が入力期間よりも長い状態が続くと、コンテナデータがバッファメモリに蓄積され続け、いずれバッファメモリからコンテナデータがオーバーフローを起こすことになる。
【００２７】
次に送信側ネットワーク２００について詳細を説明する。送信側ネットワーク２００では受信側ネットワーク３００で起きるコンテナデータのオーバーフローを回避するために、ＴＬＶコンテナ化部２１０でＴＬＶコンテナのサイズを解析し、２つのコンテナを１つにまとめることでコンテナのサイズを調整する機能を有している。コンテナのサイズを調整する手段として、図５に本発明の実施の形態３に係るＴＬＶコンテナ化部２１０の内部動作概要図示す。
【００２８】
図５に示すように、ＴＬＶコンテナ化部２１０は、バッファメモリ２１１と、データ解析部２１２と、ヘッダー作成部２１３と、ＴＬＶコンテナ生成部２１４と、バッファメモリ２１５と、コンテナ解析部２１６と、重複ヘッダー作成部２１７と、ＴＬＶコンテナ再生成部２１８と、ヘッダー情報データ化部２１９で構成されている。
【００２９】
バッファメモリ２１１は、コンテンツ配信装置１００から入力したコンテンツデータを蓄積する。
【００３０】
データ解析部２１２は、ＴＬＶコンテナ化部２１０に入力されるデータのサイズと種類を解析し、ヘッダー作成部２１３にその情報を出力する。
【００３１】
ヘッダー作成部２１３はデータのサイズと種類からＬｅｎｇｔｈデータとＴｙｐｅデータを作成し、ＴＬＶコンテナ生成部２１４に出力する
ＴＬＶコンテナ生成部２１４は、バッファメモリ２１１に蓄積されたコンテンツデータをＶａｌｕｅデータとして読み出し、このＶａｌｕｅデータにヘッダー作成部２１３から入力されたＬｅｎｇｔｈデータとＴｙｐｅデータを結合することで、ＴＬＶコンテナを生成する。
【００３２】
バッファメモリ２１５は、ＴＬＶコンテナ生成部２１４から出力されたＴＬＶコンテナを蓄積する。
【００３３】
コンテナ解析部２１６は、ＴＬＶコンテナ生成部２１４から出力されたＴＬＶコンテナのＬｅｎｇｔｈデータとＴｙｐｅデータとＶａｌｕｅデータを解析し、その解析結果を重複ヘッダー作成部２１７に出力する。
【００３４】
重複ヘッダー２１７は、コンテナ解析部２１６から得た解析結果、つまり、バッファメモリ２１５に蓄積されたＴＬＶコンテナのＬｅｎｇｔｈデータが所定サイズ未満であった場合、コンテナ解析部２１６から入力された次にバッファメモリ２１５に入力されるＴＬＶコンテナの解析結果と合せて、２つのＴＬＶコンテナのＶａｌｕｅデータを結合した場合のＬｅｎｇｔｈデータとそれを認識するためのＴｙｐｅデータを新たに作成する。また、結合する２つのＴＬＶコンテナのＶａｌｕｅデータのサイズが異なる場合は、そのサイズの差分データもＴＬＶコンテナ再生成部２１８に出力する。コンテナ解析部２１６から得た解析結果、つまり、バッファメモリ２１５に蓄積されたＴＬＶコンテナのＬｅｎｇｔｈデータが所定サイズ以上であった場合、コンテナ解析部２１６はコンテナ解析部２１６から得たＬｅｎｇｔｈデータとＴｙｐｅデータをそのままＴＬＶコンテナ再生成部２１８へ出力する。
【００３５】
また、コンテナ解析部２１６は、２つのＴＬＶコンテナを結合させてもＴＬＶコンテナのサイズが所定サイズに満たないときは、所定サイズに達するまでの複数個のＴＬＶコンテナを結合し、Ｌｅｎｇｔｈデータとそれを認識するためのＴｙｐｅデータを新たに作成する。
【００３６】
ＴＬＶコンテナ再生成部２１８は、バッファメモリ２１５からＴＬＶコンテナを呼び出し、重複ヘッダー作成部２１５から入力されたＴｙｐｅデータと異なっていた場合、つまり、重複ヘッダー作成部２１５が新たに作成したＴｙｐｅデータであった場合、次のＴＬＶコンテナと結合すると認識し、バッファメモリ２１５に蓄積されている次のＴＬＶコンテナも呼び出し、それぞれＶａｌｕｅデータを抜き出して結合し、重複ヘッダー作成部２１５から入力した新たなＴｙｐｅデータとＬｅｎｇｔｈデータを結合して新たなＴＬＶコンテナとして多重化部２２０へ出力する。
【００３７】
ところで、Ｖａｌｕｅデータ同士を結合する際は、重複ヘッダー作成部２１７から入力される差分データから、その差分を埋めるための無関係なデータ（ヌルデータ）をＶａｌｕｅデータのサイズが小さい方のＶａｌｕｅデータ末尾に挿入する。そのため、Ｌｅｎｇｔｈデータは、挿入されるヌルデータのサイズ分も追加した値になる。
【００３８】
ヘッダー情報データ化部２１９は、ＴＬＶコンテナ再生成部２１８で結合された新たなＴＬＶコンテナを、受信側ネットワーク３００で処理可能にするために、ヌルデータのサイズや重複ヘッダー作成部２１７で作成されたＴｙｐｅデータの意味を示すデータを作成し、変調部２３０で作成されるＴＭＣＣデータに追加するデータとして新たなＴＬＶコンテナに付加するようにＴＬＶコンテナ再生成部２１８へ出力する。
【００３９】
例えば、ＴＬＶコンテナ再生成部２１８がＴＬＶコンテナ生成部２１４からバッファ２１５を経由して、５２バイト、９６バイトのサイズのＴＬＶコンテナを入力したときを説明する。コンテナ解析部２１６で、バッファ２１５に蓄積される各ＴＬＶコンテナのサイズと種類をそれぞれＬｅｎｇｔｈデータとＴｙｐｅデータから解析する。重複ヘッダー作成部２１７は、設けた所定サイズ（７６バイト）よりコンテナ解析部２１０６で解析したＴＬＶコンテナのサイズが小さいかどうかを判断し、大きい場合はそのＴＬＶコンテナのＬｅｎｇｔｈデータをそのまま出力し、小さい場合はこのＴＬＶコンテナと次のＴＬＶコンテナのＶａｌｕｅデータのサイズを加算したＬｅｎｇｔｈデータを出力する。５２バイトのＴＬＶコンテナが入力されると制限サイズより小さいので、それぞれのＴＬＶコンテナのサイズである５２バイト、９６バイトからＴｙｐｅデータとＬｅｎｇｔｈデータの合計バイト数である４バイトを差し引いた４８バイト、９２バイトを加算して、１４０(＝４８＋９２)バイトのＬｅｎｇｔｈデータをＴＬＶコンテナ再生成部２１９に出力する。
【００４０】
そして、ＴＬＶコンテナ再生成部２１８が、バッファ２１５に蓄積されているＴＬＶコンテナを呼び出し、重複ヘッダー作成部２１７から得たＬｅｎｇｔｈデータとのサイズを比較し、５２バイトと１４０バイトが一致しないので、次に蓄積されている９６バイトのＴＬＶコンテナをバッファ２１５から呼び出し、それぞれＶａｌｕｅデータを抜き出し、９６バイトと５２バイトの差分である、４４バイトのヌルデータを４８バイトのＶａｌｕｅデータの末尾に結合し、９２バイトのＶａｌｕｅデータと結合して、合計１８４バイトのＶａｌｕｅデータを作成する。この１８４バイトのＶａｌｕｅデータをＴＬＶコンテナ化するために、ヌルデータと２つのＶａｌｕｅデータが結合されていることを示すＴｙｐｅデータを作成し、重複ヘッダー作成部２１７で作られたＬｅｎｇｔｈデータを使用する。重複ヘッダー作成部２１７で作成されたＴｙｐｅデータは、ヘッダー情報データ化部２１９にも送られ、ＴＭＣＣデータに格納されるＴｙｐｅ情報としてデータ化される。
【００４１】
ここで特定の制限サイズ（７６バイト）について、詳細を以下に述べる。図６は、本発明のコンテナの特定の制限サイズを求める式を示す図である。特定の制限サイズの値は、受信側ネットワーク３００でオーバーフローを必ず起こさない値が考えられる。高度化ＩＳＤＢ−Ｓの規格においては、変調方式が３２ＡＰＳＫで、符号化率９／１０の運用時にスロットのデータバイト数が最も大きくなり、スロットのデータバイト数は５０４９バイトになる。出力クロックは、シンボルレート３２．５９４１ＭＨｚから導かれたバイトクロックである。オーバーフローを起こさない最小コンテナサイズとして、スロット単位あたりで処理可能な最小サイズのコンテナ数Ｎ個が考えられ、計算される値は最小ＧｂＥ(Ｇｉｇａｂｉｔイーサーネットの出力サイズ）×Ｎ≧スロット期間であり、図６のように計算するとＮ≦６７となる。そして、スロットのデータバイト数５０４９から処理可能な最小サイズのコンテナ数６７を割った値より大きい整数値で最小コンテナサイズは７６バイトとなる。
【００４２】
かかる構成によれば、送信側ネットワークの多重化部においてスロット内のコンテナの個数を制限個数以下にすることにより、受信側のＭＡＣフレーム変換部でのＭＡＣフレーム変換でオーバーフローを起すことがなくなりＧｉｇａｂｉｔイーサーネットを用いた伝送で支障をきたすことなく、ユーザー端末装置に対して情報の欠落なく送信することができる。
【００４３】
なお、本実施の形態において、ＧｂＥ＿Ｉ／Ｆ３４０としてギガビットイーサーネットを想定しているが、１０００Ｍｂｐｓ未満のイーサーネットでも運用は可能である。その場合は、ＭＡＣフレーム変換部３３０のＭＡＣフレーム変換がその１０００Ｍｂｐｓ未満のイーサーネットの規格に沿ったデータ転送速度で動作するものとする。
【００４４】
なお、本実施の形態において、ＴＬＶデコンテナ化部３２０は、Ｖａｌｕｅデータのみを抜き出すとしたが、Ｖａｌｕｅデータと、Ｔｙｐｅデータと、Ｌｅｎｇｔｈデータの全て含むＴＬＶコンテナを抜き出し、そのデータをＭＡＣフレーム変換した後、ＧｂＥ＿Ｉ／Ｆ３４０に出力するとしても良い。その場合は、情報端末部４１０でＴＬＶコンテナのＶａｌｕｅデータを抜き出し、コンテンツデータを表示部４２０に出力する構成とする。
【００４５】
なお、本実施の形態において、復調部３１０で復調されたＴＭＣＣデータから２つのＶａｌｕｅデータが結合されたＴＬＶコンテナの情報データを、ＭＡＣフレーム変換部３３０でＭＡＣフレーム変換し、ＧｂＥ＿Ｉ／Ｆ３４０に出力することも可能である。その場合は、情報端末部４１０で結合されたＴＬＶコンテナの情報データから、結合されたＶａｌｕｅデータを分割し、コンテンツデータを復元して表示部４２０に出力する構成とする。
【産業上の利用可能性】
【００４６】
受信側の機能制限による、送信側のコンテンツ配信の制限や複雑なレート調整を行う必要がなくなり、市場における不具合を事前に回避する利点がある。そのため、高度化ＩＳＤＢ−Ｓの伝送路規格として成り立つ可能性がある。
【図面の簡単な説明】
【００４７】
【図１】本発明の実施の形態１に係るＴＬＶ伝送対応の放送システムの構成図
【図２】本発明の実施の形態１に係るＭＡＣフレーム構成図
【図３】本発明の実施の形態１に係るＭＡＣフレーム変換部３３０の概要図
【図４】本発明のＭＡＣフレーム変換部３３０の内部動作概要図
【図５】本発明の実施の形態３に係るＴＬＶコンテナ化部２１０の内部動作概要図
【図６】本発明のコンテナの制限サイズを求める式を示す図
【図７】従来の放送システムの構成図
【符号の説明】
【００４８】
１００ コンテンツ配信装置
２００ 送信側ネットワーク
２１０ ＴＬＶコンテナ化部
２１１ バッファメモリ
２１２ データ解析部
２１３ ヘッダー作成部
２１４ ＴＬＶコンテナ生成部
２１５ バッファメモリ
２１６ コンテナ解析部
２１７ 重複ヘッダー作成部
２１８ ＴＬＶコンテナ再生成部
２１９ ヘッダー情報データ化部
２２０ 多重化部
３００ 受信側ネットワーク
３１０ 復調部
３２０ ＴＬＶデコンテナ化部
３３０ ＭＡＣフレーム変換部
３３１ バッファメモリ
３３２ ヘッダー付加部
３４０ ＧｂＥ＿Ｉ／Ｆ
４００ ユーザー端末装置
４１０ 情報端末部
４２０ 表示部
【技術分野】
【０００１】
本発明は、高度化ＩＳＤＢ−Ｓ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｂｒｏａｄｃａｓｔｉｎｇ−Ｓａｔｅｌｌｉｔｅ）、つまり、高度化衛星放送の規格で運用されることが考えられている、ＴＬＶ（Ｔｙｐｅ Ｌｅｎｇｔｈ Ｖａｌｕｅ）伝送技術に関するもので、放送コンテンツを伝送する単位であるＴＬＶコンテナの個数あるいはバイト数を制限することで、Ｇｉｇａｂｉｔイーサーネット出力した際の伝送の破綻を防ぐことを可能にするものである。
【背景技術】
【０００２】
従来の放送システムでは、リアルタイム放送システムに適した信号フォーマットとして固定長パケットのＭＰＥＧ２−ＴＳを使用して伝送する方法が一般的である。図７に従来の放送システムであるＭＰＥＧ２−ＴＳを使用した構成の放送システムを示す。コンテンツ配信者からエンドユーザにコンテンツを送信するとき、コンテンツ配信装置６００から送信側ネットワーク７００、伝送路、受信側ネットワーク８００、表示装置９００への順番に送信する。
【０００３】
コンテンツ配信装置６００は映像や音声、その制御信号をＭＰＥＧ２−ＴＳのパケット形式にエンコードして、送信側ネットワーク７００に出力する。
【０００４】
送信側ネットワーク７００は、多重化部７１０、変調部７２０で構成され、多重化部７１０はコンテンツ配信装置６００から入力されたＭＰＥＧ２−ＴＳのパケット形式の信号を伝送路の信号フォーマットに合わせた形式に多重化して、変調部７２０は多重化部７１０で多重化された信号を伝送路に変調して出力する。
【０００５】
受信側ネットワーク８００は、復調部８１０、デコーダ８２０で構成され、復調部８１０は伝送路から入力された変調信号を復調し多重分離して、デコーダ８２０でＭＰＥＧ２−ＴＳ形式の信号をコンテンツデータにデコードして、表示装置９００へ出力する。
【０００６】
表示装置９００は、受信側ネットワーク８００からコンテンツデータを受け、コンテンツデータの映像や音声を表示する。
【０００７】
一方、コンテンツデータを受信機に蓄積し、受信後にストリームを復元・表示する蓄積型放送サービスの実現に向けた、衛星などの既存の伝送路とＧｉｇａｂｉｔイーサーネットなどの通信網の組み合わせた放送システムが考えられており、高度化ＩＳＤＢ−Ｓで検討されているＴＬＶ伝送技術が期待されている。ＴＬＶ伝送技術は、ｔｙｐｅフィールドによりデータの種類を示し、ｌｅｎｇｔｈフィールドによりデータのサイズを示すことで、Ｖａｌｕｅフィールドに任意の可変長データを格納可能である。このＴＬＶ伝送技術では、パケット種別として、４種類のデータタイプを割り当ててＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）パケットの伝送を可能としている。(非特許文献１)
【非特許文献１】情報通信審議会 諮問第２０２３号 「放送システムに関する技術的条件」のうち「衛星デジタル放送の高度化に関する技術的条件」答申書 総務省 平成２０年７月２９日 ２９頁
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、高度化ＩＳＤＢ−Ｓの運用で検討されているＴＬＶ伝送技術においては、ＴＬＶコンテナのサイズは４バイト以上での運用が考えられており、上記従来の方法ではコンテンツデータを含んだＴＬＶコンテナのパケットサイズがＧｉｇａｂｉｔイーサーネットで制限される５１２バイトよりも短い場合、短いパケットが連続して入力されると、ＭＡＣフレーム変換するブロックのメモリバッファがオーバーフローを起こし、ＧｂＥ出力の破綻となって、データの欠落が発生するという課題があった。
【０００９】
本発明は以上の課題を解決することを目的とするものであり、受信側でＧｂＥ出力する際のバッファメモリのオーバーフローを回避するために、受信側にあるＧｉｇａｂｉｔイーサーネットを用いた伝送で支障をきたすことなく、ユーザー端末装置に対して情報の欠落なく送信するＴＬＶ伝送対応の放送システムを提供することである。
【課題を解決するための手段】
【００１０】
前記従来の課題を解決するために、本発明の送信側ネットワークは、コンテンツを配信するコンテンツ配信装置からのコンテンツデータをコンテナ化する送信側ネットワークであって、コンテンツ配信装置から配信されたコンテンツデータを所定のバイト数以下になるようにコンテナ化するコンテナ化部と、コンテナ化部がコンテナ化したコンテナを伝送路上の信号形式に変換するために特定のフォーマットに多重する多重化部と、多重化部で多重化された信号を伝送路に出力するために変調する変調部とを備え、コンテナのバイトサイズを制限する。
【発明の効果】
【００１１】
高度化ＩＳＤＢ−Ｓの運用で検討されているＴＬＶ伝送するシステムにおいて、送信側で送るコンテナのバイト数を制限することで、受信側にあるＧｉｇａｂｉｔイーサーネットを用いた伝送で支障をきたすことなく、ユーザー端末装置に対して情報の欠落なく送信することができる。
【発明を実施するための最良の形態】
【００１２】
以下本願発明の実施の形態について図面を用いて説明する。
【００１３】
（実施の形態１）
まず、本発明の実施の形態３に係るＴＬＶ対応の放送システムの概要について説明する。図１は本発明の実施の形態３に係るＴＬＶ対応の放送システムの構成図を示す。ＴＬＶ対応の放送システムは、コンテンツ配信者からエンドユーザにコンテンツを送信するとき、コンテンツ配信装置１００から送信側ネットワーク２００、伝送路、受信側ネットワーク３００、ユーザー端末装置４００への順番に送信する。本発明の放送システムは、主に衛星放送での使用を主としている。そのため、伝送路は衛星から送信された電波が通過する空間を想定している。また、図１ではユーザー端末装置４００を１台のみ記載しているが、受信側ネットワーク３００には複数台のユーザー端末装置４００が接続されている。
【００１４】
コンテンツ配信装置１００は、映像や音声、文字情報などのデータをコンテンツとして送信側ネットワーク２００へ出力する。なおコンテンツ配信装置１００は、受信側ネットワーク３００やユーザー端末装置４００などで使用されるＭＡＣアドレス情報を含ませることも可能である。
【００１５】
送信側ネットワーク２００は、データを伝送路に出力するために、コンテンツ配信装置１００から入力されたコンテンツデータをＴＬＶコンテナ化するＴＬＶコンテナ化部２１０と、ＴＬＶコンテナ化部２１０でコンテナ化されたＴＬＶコンテナを伝送路上の信号形式に変換するために特定のフォーマットに多重化する多重化部２２０と、多重化部２２０で多重化された信号を伝送路で出力するために変調する変調部２３０で構成されている。特に、変調部２３０は、多重化されたデータを変調する機能に加え、伝送路の最小単位である固定長のスロット期間の中でデータ範囲を示す情報や、スロットに多重されているデータの種類を示す情報をＴＭＣＣデータとして変調する機能を有している。
【００１６】
ここで、ＴＬＶコンテナとは、ＴｙｐｅデータとＬｅｎｇｔｈデータとＶａｌｕｅデータの３つのデータから構成されており、Ｖａｌｕｅデータはコンテンツ配信装置１００から送信するコンテンツなどのデータで、ＬｅｎｇｔｈデータはＴＬＶコンテナのサイズ情報を含んだデータで、ＴｙｐｅデータはＴＬＶコンテナの種類の情報を含んだデータである。
【００１７】
受信側ネットワーク３００は、送信側ネットワーク２００からデータを受信し、ユーザー端末装置４００へＧｉｇａｂｉｔイーサーネットの形式で出力するものである。そのために、受信側ネットワーク３００は、伝送路から入力した変調波を復調し、伝送路上の信号形式からデータを多重分離する復調部３１０と、復調部３１０で多重分離したデータからＴＬＶコンテナのＶａｌｕｅデータを抜き出すＴＬＶデコンテナ化部３２０と、ＴＬＶデコンテナ化部３２０で抜き出されたデータをＧｉｇａｂｉｔイーサーネット形式のデータに変換するＭＡＣフレーム変換部３３０と、ＭＡＣフレーム変換部３３０で変換されたデータを外部のユーザー端末装置４００のＧｂＥ＿Ｉ／Ｆに出力するＧｂＥ＿Ｉ／Ｆ３４０で構成される。特に、復調部３１０は、変調された変調信号から、まずＴＭＣＣデータを復調し、多重化されたデータを復調する際には、ＴＭＣＣデータからスロットに含まれているデータ範囲を認識して復調している。また、復調部３１０は、多重化されたデータを多重分離する際にも、ＴＭＣＣデータから多重されているデータの種類を認識して多重分離している。
【００１８】
ここで、ＭＡＣフレーム変換部３３０は、ＴＬＶデコンテナ化部３２０で抜き出されたＴＬＶコンテナのＶａｌｕｅデータ、つまり、コンテンツ配信装置１００から送信されたコンテンツとユーザー端末装置４００などで使用されるＭＡＣアドレス情報をＭＡＣフレームに変換する。このとき、ＭＡＣフレームのヘッダーに特定のＭＡＣアドレスのみを付加したり、複数のＭＡＣアドレスを付加したりすることが可能である。また、ヘッダーに付加するＭＡＣアドレスは、ＭＡＣフレーム変換部３３０が保有しているＭＡＣアドレスを使用したり、コンテンツ配信装置１００から送信されてきたＭＡＣアドレスを使用したりすることができる。
【００１９】
ユーザー端末装置４００は、コンテンツデータを映像表示するために、受信側ネットワーク３００から入力したＧｉｇａｂｉｔイーサーネット形式のデータを受け取り、コンテンツデータを出力する情報端末部４１０と、情報端末部４１０が出力したコンテンツデータを映像表示する表示部４２０で構成される。
【００２０】
情報端末部４１０は、ＭＡＣフレーム変換部３３０で宛先としてＭＡＣアドレスがヘッダーに付加された場合、コンテンツデータを受け取ることができる。また、ＭＡＣフレーム変換部３３０で複数の宛先のＭＡＣアドレスが付加された場合、宛先に対応する複数の情報端末部４１０でそれぞれデータを受け取ることが可能である。また、情報端末部４１０はモニタにリアルタイムで出力する必要はなく、ハードディスクなどの記録部を接続、或いは、内蔵することで、コンテンツデータを蓄積することが可能となる。
【００２１】
次に、本発明の実施の形態３に係るＴＬＶ対応の放送システムの受信側ネットワークについて詳細を説明する。受信側ネットワーク３００は、送信側ネットワーク２００から伝送路経由で受信したＴＬＶコンテナのデータを外部機器であるユーザー端末装置４００にＧｉｇａｂｉｔイーサーネットで出力するＭＡＣフレームに変換する機能を有している。まず、ＴＬＶコンテナをＧｉｇａｂｉｔイーサーネットで出力するためのＴＬＶコンテナのＭＡＣフレームについて説明する。図２は、本発明の実施の形態３に係るＭＡＣフレームの構成図である。
【００２２】
ＴＬＶコンテナのデータフォーマット変換後のＭＡＣフレームは、Ｇｉｇａｂｉｔイーサーネットの規格であるＩＥＥＥ Ｓｔａｎｄａｒｄ ８０２．３に基づいている。図２に示すように、宛先ＭＡＣアドレスからＣａｒｒｉｅｒ Ｅｘｔｅｎｄまでのサイズは最小で５１２バイトとなっているため、ＴＬＶコンテナのサイズが４６６バイト以下の場合、Ｃａｒｒｉｅｒ Ｅｘｔｅｎｄのデータサイズを調整することで最小サイズ５１２バイトにしている。そして、ＴＬＶコンテナのＭＡＣフレーム変換は、プリアンブルとＩＦＧを更に付加することで、最小サイズ５３２バイトとなっている。
【００２３】
さらに、ＭＡＣフレーム変換部３３０がＴＬＶコンテナをこのＭＡＣフレームにＭＡＣフレーム変換することについて説明する。図３は、本発明の実施の形態３に係るＭＡＣフレーム変換部３３０の概要図である。ＭＡＣフレーム変換部３３０は、入力されたＴＬＶコンテナをバッファメモリ３３１で一旦蓄積し、ヘッダー付加部３３２でＴＬＶコンテナにＵＤＰｈｅａｄｅｒを付加した後、ＩＰｖ４ｈｅａｄｅｒを付加して、ＩＰｖ４パケットの形式にする。さらに、宛先ＭＡＣアドレス、送信元ＭＡＣアドレス、タイプ、ＦＣＳを付加することで、ＭＡＣフレームとし、そのＭＡＣフレームのサイズが５１２バイト未満の場合、ＭＡＣフレームのサイズと合わせて５１２バイトになるようにＣａｒｒｉｅｒ Ｅｘｔｅｎｄのデータを最後尾に付加する。そして先頭を示すプリアンブルやパケット間の間を示すＩＦＧの期間を加えたサイズのパケットをＧｂＥ＿Ｉ／Ｆ３４０に出力する。
【００２４】
ＭＡＣフレーム変換部３３０への入力速度は、受信ネットワーク３００のデータ処理の動作周波数になり、バイトクロック周波数１８．５ＭＨｚとしている。一方、ＭＡＣフレーム変換部３３０の出力速度は、ＧｂＥ＿Ｉ／Ｆの動作モードで決まり、ＧＭＩＩの動作モードで１２５ＭＨｚである。入力速度より出力速度が６．７倍と速いため、パケットサイズであるＴＬＶコンテナサイズが７９バイト（５３２バイトの１／６．７）以上であれば、バッファメモリのオーバーフローを理論上起こすことはない。しかし、ＴＬＶコンテナサイズが７８バイト未満になると、ヘッダーのオーバーヘッドが増加し、結果として出力のスループットが低下する現象が生じる。
【００２５】
ＭＡＣフレーム変換部３３０の出力のスループットの低下の様子の例としてＴＬＶコンテナのＭＡＣフレーム変換部３３０の内部動作として、入力に対するヘッダー付加後の出力の処理を示す。図４は本発明のＭＡＣフレーム変換部３３０の内部動作概要図である。
【００２６】
ＭＡＣフレーム変換部３３０は、伝送路の最小単位である固定長のスロット期間を処理範囲として、ＭＡＣフレームにおけるヘッダーの割合が最も大きくなる最小バイトサイズ（４バイト）のコンテナＮ個と、５０４９バイトからＮ個の最小コンテナのバイト数の合計を引いた余りバイト数サイズをもつコンテナ１個を入力している。そして、ＭＡＣフレーム変換部３３０は、図２で示す最小ＭＡＣフレームサイズ（５３２バイト）のＭＡＣフレームＮ個を出力することになり、出力期間が入力期間よりも長くなったときに出力のスループットが低下する。出力期間が入力期間よりも長い状態が続くと、コンテナデータがバッファメモリに蓄積され続け、いずれバッファメモリからコンテナデータがオーバーフローを起こすことになる。
【００２７】
次に送信側ネットワーク２００について詳細を説明する。送信側ネットワーク２００では受信側ネットワーク３００で起きるコンテナデータのオーバーフローを回避するために、ＴＬＶコンテナ化部２１０でＴＬＶコンテナのサイズを解析し、２つのコンテナを１つにまとめることでコンテナのサイズを調整する機能を有している。コンテナのサイズを調整する手段として、図５に本発明の実施の形態３に係るＴＬＶコンテナ化部２１０の内部動作概要図示す。
【００２８】
図５に示すように、ＴＬＶコンテナ化部２１０は、バッファメモリ２１１と、データ解析部２１２と、ヘッダー作成部２１３と、ＴＬＶコンテナ生成部２１４と、バッファメモリ２１５と、コンテナ解析部２１６と、重複ヘッダー作成部２１７と、ＴＬＶコンテナ再生成部２１８と、ヘッダー情報データ化部２１９で構成されている。
【００２９】
バッファメモリ２１１は、コンテンツ配信装置１００から入力したコンテンツデータを蓄積する。
【００３０】
データ解析部２１２は、ＴＬＶコンテナ化部２１０に入力されるデータのサイズと種類を解析し、ヘッダー作成部２１３にその情報を出力する。
【００３１】
ヘッダー作成部２１３はデータのサイズと種類からＬｅｎｇｔｈデータとＴｙｐｅデータを作成し、ＴＬＶコンテナ生成部２１４に出力する
ＴＬＶコンテナ生成部２１４は、バッファメモリ２１１に蓄積されたコンテンツデータをＶａｌｕｅデータとして読み出し、このＶａｌｕｅデータにヘッダー作成部２１３から入力されたＬｅｎｇｔｈデータとＴｙｐｅデータを結合することで、ＴＬＶコンテナを生成する。
【００３２】
バッファメモリ２１５は、ＴＬＶコンテナ生成部２１４から出力されたＴＬＶコンテナを蓄積する。
【００３３】
コンテナ解析部２１６は、ＴＬＶコンテナ生成部２１４から出力されたＴＬＶコンテナのＬｅｎｇｔｈデータとＴｙｐｅデータとＶａｌｕｅデータを解析し、その解析結果を重複ヘッダー作成部２１７に出力する。
【００３４】
重複ヘッダー２１７は、コンテナ解析部２１６から得た解析結果、つまり、バッファメモリ２１５に蓄積されたＴＬＶコンテナのＬｅｎｇｔｈデータが所定サイズ未満であった場合、コンテナ解析部２１６から入力された次にバッファメモリ２１５に入力されるＴＬＶコンテナの解析結果と合せて、２つのＴＬＶコンテナのＶａｌｕｅデータを結合した場合のＬｅｎｇｔｈデータとそれを認識するためのＴｙｐｅデータを新たに作成する。また、結合する２つのＴＬＶコンテナのＶａｌｕｅデータのサイズが異なる場合は、そのサイズの差分データもＴＬＶコンテナ再生成部２１８に出力する。コンテナ解析部２１６から得た解析結果、つまり、バッファメモリ２１５に蓄積されたＴＬＶコンテナのＬｅｎｇｔｈデータが所定サイズ以上であった場合、コンテナ解析部２１６はコンテナ解析部２１６から得たＬｅｎｇｔｈデータとＴｙｐｅデータをそのままＴＬＶコンテナ再生成部２１８へ出力する。
【００３５】
また、コンテナ解析部２１６は、２つのＴＬＶコンテナを結合させてもＴＬＶコンテナのサイズが所定サイズに満たないときは、所定サイズに達するまでの複数個のＴＬＶコンテナを結合し、Ｌｅｎｇｔｈデータとそれを認識するためのＴｙｐｅデータを新たに作成する。
【００３６】
ＴＬＶコンテナ再生成部２１８は、バッファメモリ２１５からＴＬＶコンテナを呼び出し、重複ヘッダー作成部２１５から入力されたＴｙｐｅデータと異なっていた場合、つまり、重複ヘッダー作成部２１５が新たに作成したＴｙｐｅデータであった場合、次のＴＬＶコンテナと結合すると認識し、バッファメモリ２１５に蓄積されている次のＴＬＶコンテナも呼び出し、それぞれＶａｌｕｅデータを抜き出して結合し、重複ヘッダー作成部２１５から入力した新たなＴｙｐｅデータとＬｅｎｇｔｈデータを結合して新たなＴＬＶコンテナとして多重化部２２０へ出力する。
【００３７】
ところで、Ｖａｌｕｅデータ同士を結合する際は、重複ヘッダー作成部２１７から入力される差分データから、その差分を埋めるための無関係なデータ（ヌルデータ）をＶａｌｕｅデータのサイズが小さい方のＶａｌｕｅデータ末尾に挿入する。そのため、Ｌｅｎｇｔｈデータは、挿入されるヌルデータのサイズ分も追加した値になる。
【００３８】
ヘッダー情報データ化部２１９は、ＴＬＶコンテナ再生成部２１８で結合された新たなＴＬＶコンテナを、受信側ネットワーク３００で処理可能にするために、ヌルデータのサイズや重複ヘッダー作成部２１７で作成されたＴｙｐｅデータの意味を示すデータを作成し、変調部２３０で作成されるＴＭＣＣデータに追加するデータとして新たなＴＬＶコンテナに付加するようにＴＬＶコンテナ再生成部２１８へ出力する。
【００３９】
例えば、ＴＬＶコンテナ再生成部２１８がＴＬＶコンテナ生成部２１４からバッファ２１５を経由して、５２バイト、９６バイトのサイズのＴＬＶコンテナを入力したときを説明する。コンテナ解析部２１６で、バッファ２１５に蓄積される各ＴＬＶコンテナのサイズと種類をそれぞれＬｅｎｇｔｈデータとＴｙｐｅデータから解析する。重複ヘッダー作成部２１７は、設けた所定サイズ（７６バイト）よりコンテナ解析部２１０６で解析したＴＬＶコンテナのサイズが小さいかどうかを判断し、大きい場合はそのＴＬＶコンテナのＬｅｎｇｔｈデータをそのまま出力し、小さい場合はこのＴＬＶコンテナと次のＴＬＶコンテナのＶａｌｕｅデータのサイズを加算したＬｅｎｇｔｈデータを出力する。５２バイトのＴＬＶコンテナが入力されると制限サイズより小さいので、それぞれのＴＬＶコンテナのサイズである５２バイト、９６バイトからＴｙｐｅデータとＬｅｎｇｔｈデータの合計バイト数である４バイトを差し引いた４８バイト、９２バイトを加算して、１４０(＝４８＋９２)バイトのＬｅｎｇｔｈデータをＴＬＶコンテナ再生成部２１９に出力する。
【００４０】
そして、ＴＬＶコンテナ再生成部２１８が、バッファ２１５に蓄積されているＴＬＶコンテナを呼び出し、重複ヘッダー作成部２１７から得たＬｅｎｇｔｈデータとのサイズを比較し、５２バイトと１４０バイトが一致しないので、次に蓄積されている９６バイトのＴＬＶコンテナをバッファ２１５から呼び出し、それぞれＶａｌｕｅデータを抜き出し、９６バイトと５２バイトの差分である、４４バイトのヌルデータを４８バイトのＶａｌｕｅデータの末尾に結合し、９２バイトのＶａｌｕｅデータと結合して、合計１８４バイトのＶａｌｕｅデータを作成する。この１８４バイトのＶａｌｕｅデータをＴＬＶコンテナ化するために、ヌルデータと２つのＶａｌｕｅデータが結合されていることを示すＴｙｐｅデータを作成し、重複ヘッダー作成部２１７で作られたＬｅｎｇｔｈデータを使用する。重複ヘッダー作成部２１７で作成されたＴｙｐｅデータは、ヘッダー情報データ化部２１９にも送られ、ＴＭＣＣデータに格納されるＴｙｐｅ情報としてデータ化される。
【００４１】
ここで特定の制限サイズ（７６バイト）について、詳細を以下に述べる。図６は、本発明のコンテナの特定の制限サイズを求める式を示す図である。特定の制限サイズの値は、受信側ネットワーク３００でオーバーフローを必ず起こさない値が考えられる。高度化ＩＳＤＢ−Ｓの規格においては、変調方式が３２ＡＰＳＫで、符号化率９／１０の運用時にスロットのデータバイト数が最も大きくなり、スロットのデータバイト数は５０４９バイトになる。出力クロックは、シンボルレート３２．５９４１ＭＨｚから導かれたバイトクロックである。オーバーフローを起こさない最小コンテナサイズとして、スロット単位あたりで処理可能な最小サイズのコンテナ数Ｎ個が考えられ、計算される値は最小ＧｂＥ(Ｇｉｇａｂｉｔイーサーネットの出力サイズ）×Ｎ≧スロット期間であり、図６のように計算するとＮ≦６７となる。そして、スロットのデータバイト数５０４９から処理可能な最小サイズのコンテナ数６７を割った値より大きい整数値で最小コンテナサイズは７６バイトとなる。
【００４２】
かかる構成によれば、送信側ネットワークの多重化部においてスロット内のコンテナの個数を制限個数以下にすることにより、受信側のＭＡＣフレーム変換部でのＭＡＣフレーム変換でオーバーフローを起すことがなくなりＧｉｇａｂｉｔイーサーネットを用いた伝送で支障をきたすことなく、ユーザー端末装置に対して情報の欠落なく送信することができる。
【００４３】
なお、本実施の形態において、ＧｂＥ＿Ｉ／Ｆ３４０としてギガビットイーサーネットを想定しているが、１０００Ｍｂｐｓ未満のイーサーネットでも運用は可能である。その場合は、ＭＡＣフレーム変換部３３０のＭＡＣフレーム変換がその１０００Ｍｂｐｓ未満のイーサーネットの規格に沿ったデータ転送速度で動作するものとする。
【００４４】
なお、本実施の形態において、ＴＬＶデコンテナ化部３２０は、Ｖａｌｕｅデータのみを抜き出すとしたが、Ｖａｌｕｅデータと、Ｔｙｐｅデータと、Ｌｅｎｇｔｈデータの全て含むＴＬＶコンテナを抜き出し、そのデータをＭＡＣフレーム変換した後、ＧｂＥ＿Ｉ／Ｆ３４０に出力するとしても良い。その場合は、情報端末部４１０でＴＬＶコンテナのＶａｌｕｅデータを抜き出し、コンテンツデータを表示部４２０に出力する構成とする。
【００４５】
なお、本実施の形態において、復調部３１０で復調されたＴＭＣＣデータから２つのＶａｌｕｅデータが結合されたＴＬＶコンテナの情報データを、ＭＡＣフレーム変換部３３０でＭＡＣフレーム変換し、ＧｂＥ＿Ｉ／Ｆ３４０に出力することも可能である。その場合は、情報端末部４１０で結合されたＴＬＶコンテナの情報データから、結合されたＶａｌｕｅデータを分割し、コンテンツデータを復元して表示部４２０に出力する構成とする。
【産業上の利用可能性】
【００４６】
受信側の機能制限による、送信側のコンテンツ配信の制限や複雑なレート調整を行う必要がなくなり、市場における不具合を事前に回避する利点がある。そのため、高度化ＩＳＤＢ−Ｓの伝送路規格として成り立つ可能性がある。
【図面の簡単な説明】
【００４７】
【図１】本発明の実施の形態１に係るＴＬＶ伝送対応の放送システムの構成図
【図２】本発明の実施の形態１に係るＭＡＣフレーム構成図
【図３】本発明の実施の形態１に係るＭＡＣフレーム変換部３３０の概要図
【図４】本発明のＭＡＣフレーム変換部３３０の内部動作概要図
【図５】本発明の実施の形態３に係るＴＬＶコンテナ化部２１０の内部動作概要図
【図６】本発明のコンテナの制限サイズを求める式を示す図
【図７】従来の放送システムの構成図
【符号の説明】
【００４８】
１００ コンテンツ配信装置
２００ 送信側ネットワーク
２１０ ＴＬＶコンテナ化部
２１１ バッファメモリ
２１２ データ解析部
２１３ ヘッダー作成部
２１４ ＴＬＶコンテナ生成部
２１５ バッファメモリ
２１６ コンテナ解析部
２１７ 重複ヘッダー作成部
２１８ ＴＬＶコンテナ再生成部
２１９ ヘッダー情報データ化部
２２０ 多重化部
３００ 受信側ネットワーク
３１０ 復調部
３２０ ＴＬＶデコンテナ化部
３３０ ＭＡＣフレーム変換部
３３１ バッファメモリ
３３２ ヘッダー付加部
３４０ ＧｂＥ＿Ｉ／Ｆ
４００ ユーザー端末装置
４１０ 情報端末部
４２０ 表示部
【特許請求の範囲】
【請求項１】
コンテンツを配信するコンテンツ配信装置からのコンテンツデータをコンテナ化する送信側ネットワークであって、
前記コンテンツ配信装置から配信されたコンテンツデータを所定のバイト数以下になるようにコンテナ化するコンテナ化部と、前記コンテナ化部がコンテナ化したコンテナを伝送路上の信号形式に変換するために特定のフォーマットに多重する多重化部と、前記多重化部で多重化された信号を伝送路に出力するために変調する変調部とを備えることを特徴とする送信側ネットワーク。
【請求項２】
前記コンテナ化部は、
前記コンテンツ配信装置が出力したデータのサイズと種類を解析するデータ解析部と、
前記データ解析部が算出したデータのサイズと種類からヘッダーを作成するヘッダー作成部と、
前記ヘッダー作成部が作成したヘッダーとデータを結合してＴＬＶコンテナを生成するＴＬＶコンテナ生成部と、
前記ＴＬＶコンテナ生成部が生成したＴＬＶコンテナからＴＬＶコンテナの種類とサイズを解析するコンテナ解析部と、
前記コンテナ解析部が解析したＴＬＶコンテナのサイズが所定サイズより小さい場合、前記ＴＬＶコンテナ生成部が生成する次のスロットのＴＬＶコンテナのデータ部分と結合したときのサイズを出力する重複ヘッダー作成部と、
前記重複ヘッダー作成部が出力したサイズと前記ＴＬＶコンテナ生成部が出力したＴＬＶコンテナのサイズを比較し、一致しなかった場合、一致しなかったＴＬＶコンテナのデータ部分と前記ＴＬＶコンテナ生成部が次に出力したＴＬＶコンテナのデータ部分を結合し、前記重複ヘッダー作成部が出力したヘッダーをつけて、新たなＴＬＶコンテナを作成するＴＬＶコンテナ再生成部とを備えることを特徴とする請求項１に記載の送信側ネットワーク。
【請求項３】
コンテンツを配信するコンテンツ配信装置と、前記コンテンツ配信装置が配信するコンテンツデータをコンテナ化する送信側ネットワークと、前記送信側ネットワークがコンテナ化したコンテナをＭＡＣフレームに変換する受信側ネットワークと、前記受信側ネットワークが変換したＭＡＣフレームを受信するユーザー端末装置からなる放送システムであって、
前記送信側ネットワークは、前記コンテンツ配信装置から配信されたコンテンツデータを所定のバイト数以下になるようにコンテナ化するコンテナ化部と、前記コンテナ化部がコンテナ化したコンテナを伝送路上の信号形式に変換するために特定のフォーマットに多重する多重化部と、前記多重化部で多重化された信号を伝送路に出力するために変調する変調部とを備えることを特徴とする放送システム。
【請求項１】
コンテンツを配信するコンテンツ配信装置からのコンテンツデータをコンテナ化する送信側ネットワークであって、
前記コンテンツ配信装置から配信されたコンテンツデータを所定のバイト数以下になるようにコンテナ化するコンテナ化部と、前記コンテナ化部がコンテナ化したコンテナを伝送路上の信号形式に変換するために特定のフォーマットに多重する多重化部と、前記多重化部で多重化された信号を伝送路に出力するために変調する変調部とを備えることを特徴とする送信側ネットワーク。
【請求項２】
前記コンテナ化部は、
前記コンテンツ配信装置が出力したデータのサイズと種類を解析するデータ解析部と、
前記データ解析部が算出したデータのサイズと種類からヘッダーを作成するヘッダー作成部と、
前記ヘッダー作成部が作成したヘッダーとデータを結合してＴＬＶコンテナを生成するＴＬＶコンテナ生成部と、
前記ＴＬＶコンテナ生成部が生成したＴＬＶコンテナからＴＬＶコンテナの種類とサイズを解析するコンテナ解析部と、
前記コンテナ解析部が解析したＴＬＶコンテナのサイズが所定サイズより小さい場合、前記ＴＬＶコンテナ生成部が生成する次のスロットのＴＬＶコンテナのデータ部分と結合したときのサイズを出力する重複ヘッダー作成部と、
前記重複ヘッダー作成部が出力したサイズと前記ＴＬＶコンテナ生成部が出力したＴＬＶコンテナのサイズを比較し、一致しなかった場合、一致しなかったＴＬＶコンテナのデータ部分と前記ＴＬＶコンテナ生成部が次に出力したＴＬＶコンテナのデータ部分を結合し、前記重複ヘッダー作成部が出力したヘッダーをつけて、新たなＴＬＶコンテナを作成するＴＬＶコンテナ再生成部とを備えることを特徴とする請求項１に記載の送信側ネットワーク。
【請求項３】
コンテンツを配信するコンテンツ配信装置と、前記コンテンツ配信装置が配信するコンテンツデータをコンテナ化する送信側ネットワークと、前記送信側ネットワークがコンテナ化したコンテナをＭＡＣフレームに変換する受信側ネットワークと、前記受信側ネットワークが変換したＭＡＣフレームを受信するユーザー端末装置からなる放送システムであって、
前記送信側ネットワークは、前記コンテンツ配信装置から配信されたコンテンツデータを所定のバイト数以下になるようにコンテナ化するコンテナ化部と、前記コンテナ化部がコンテナ化したコンテナを伝送路上の信号形式に変換するために特定のフォーマットに多重する多重化部と、前記多重化部で多重化された信号を伝送路に出力するために変調する変調部とを備えることを特徴とする放送システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２０１０−２１９９９６（Ｐ２０１０−２１９９９６Ａ）
【公開日】平成２２年９月３０日（２０１０．９．３０）
【国際特許分類】
【出願番号】特願２００９−６５７５５（Ｐ２００９−６５７５５）
【出願日】平成２１年３月１８日（２００９．３．１８）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成２２年９月３０日（２０１０．９．３０）
【国際特許分類】
【出願日】平成２１年３月１８日（２００９．３．１８）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]