JP5325557B2 - サービスガイドのメタデータサイズを管理する方法 - Google Patents

Description

本発明は通信分野に関し、より詳細にはサービスガイドメタデータのサイズ管理に関する。

最新技術によれば、ＥＰＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｐｒｏｇｒａｍ（ｍｅ） Ｇｕｉｄｅ）もしくはＩＰＧ（Ｉｎｔｅｒａｃｔｉｖｅ Ｐｒｏｇｒａｍ（ｍｅ） Ｇｕｉｄｅ）またはＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）、ＳＧ（Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）またはＢＣＧ（Ｂｒｏａｄｃａｓｔ Ｃｏｎｔｅｎｔ Ｇｕｉｄｅ）は、スケジュールされた放送テレビ番組またはビデオ／音楽カタログに対するオンスクリーンガイドである。これらによって、視聴者はリモコンまたは他の入力装置を使用することで時刻、タイトル、チャンネル、ジャンル等によってコンテンツをナビゲートし、選択しおよび発見することができる。サービスガイドを含むデータは一般にメタデータ、すなわちデータに関するデータと呼ばれ、この場合はオーディオおよび／またはビデオデータに関するデータである。サービスガイドメタデータに対する標準の例として、「非特許文献１」で入手可能なＴＶ−Ａｎｙｔｉｍｅ標準がある。当該分野の他の関連標準の中では「非特許文献２」、「非特許文献３」、「非特許文献４」は言及する価値がある。

以下では、サービスガイドという用語を使用して、これらの種類のメタデータブラウザの全てを示すこととする。

従来は、放送テレビ番組およびメタデータサイズを伴うように設計したサービスガイドは、関連するオーディオおよび／またはビデオデータと比較すると相対的に小規模であった。しかし、インターネットプロトコルを用いるブロードバンド送信のような技術の出現により、今なお限定はされているがより多くの帯域幅がメタデータに対して利用可能となった。また、リターンチャネル、リアルＶｏＤ（Ｖｉｄｅｏ−ｏｎ−Ｄｅｍａｎｄ）が利用可能となると、利用可能なビデオまたは音楽のカタログをユーザに提供することが必要となった。サービスガイドメタデータを包むための最新技術は、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を使用する傾向にあるようである。この形式の冗長性は、送信データ量に及ぼす影響の点から無視することはできない。帯域幅は有限でコストの高いリソースであるので、サービスガイドの送信に必要なメタデータのサイズの削減を支援するソリューションが想定されてきた。

このように、サービスガイドメタデータのサイズは、最初にサービスガイドが導入されて以来、継続的に増加し続けている。

ＥＴＳＩ ＴＳ １０２ ８２２−１ ＥＴＳＩ ＴＳ １０２ ５３９：「ＤＶＢ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ）；ＩＰ上でのＢＣＧ（Ｂｒｏａｄｂａｎｄ Ｃｏｎｔｅｎｔ Ｇｕｉｄｅ）情報の伝送」 ＥＴＳＩ ＴＳ １０２ ４７１：「ＩＰ Ｄａｔａｃａｓｔ ｏｖｅｒ ＤＶＢ−Ｈ：ＥＳＧ」 ＥＴＳＩ ＴＳ １０２ ３２３：「ＤＶＢ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ）；ＤＶＢトランスポートストリームでのＴＶ−Ａｎｙｔｉｍｅ情報の伝送および信号送信」 ＥＴＳＩ ＥＮ ３０２ ３０４ 文書「ＩＰ Ｄａｔａｃａｓｔ ｏｖｅｒ ＤＶＢ−Ｈ：ＥＳＧの実装ガイドライン」（ドラフトＴＳ １０２ ５９２ Ｖ１．１．１） ＩＳＯ／ＩＥＣ ２３００１−１ ＥＴＳＩ ＴＳ １０２ ０３４ ＩＳＯ／ＩＥＣ １３８１８−２ ＩＳＯ／ＩＥＣ １４４９６−１０ ＥＳＴＩ ＥＮ ３００ ４６８ ＥＳＴＩ ＴＲ １０１ ２１１ ＥＳＴＩ ＥＮ ３０１ １９２ ＩＳＯ／ＩＥＣ １３８１８−１ 「Ｍｏｂｉｌｅ Ｂｒｏａｄｃａｓｔ Ｓｅｒｖｉｃｅｓ− サービスガイドフラグメントに対するＸＭＬスキーマ」

一方で、携帯電話のようなポータブル装置に対するブロードバンドメディア配信が開発されてきた。これらのポータブル装置は今ではマルチメディア対応となった。従って、オーディオおよび／またはビデオストリームならびにサービスガイドを受信することができる。サービスガイドの送信を含むＤＶＢ−Ｈ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ−Ｈａｎｄｈｅｌｄ、「特許文献５」）のような主流の標準がモバイル放送に対して出現している。その中にはＤＶＢ−ＩＰＤＣ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ−Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｃａｓｔｉｎｇ、「特許文献６」）およびＯＭＡ ＢＣＡＳＴ（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ−Ｍｏｂｉｌｅ Ｂｒｏａｄｃａｓｔ Ｓｅｒｖｉｃｅｓ Ｅｎａｂｌｅｒ Ｓｕｉｔｅ）がある。ＯＭＡ ＢＣＡＳＴは現在（２００７年１２月）、その１．０仕様を仕上げている。

現在の最新技術によると、異なる技術を使用してサービスガイドメタデータのサイズを削減する。これらの技術の１つには、「特許文献７」で規定されるＸＭＬに対するバイナリＭＰＥＧフォーマット（Ｂｉｎａｒｙ ＭＰＥＧ ｆｏｒｍａｔ ｆｏｒ ＸＭＬ）（ＢｉＭ）のような、サービスガイドメタデータを送信前に圧縮することが含まれ、サービスガイドを通信チャネル上で送信するのに必要な帯域幅において興味深い進歩を得ることができる。この圧縮方式はＤＶＢ−ＩＰ標準（「特許文献８」）により、サービスガイドメタデータの送信に対して、オプション機能として受け入れられてきた。しかし、圧縮を使用すると、処理負担の大きい圧縮と解凍アルゴリズムの不利な点がもたらされる。

本発明は、上述の先行技術の不都合な点を軽減することを目的とする。

より具体的には、本発明により、オーディオおよび／またはビデオストリームを含むストリーム、シグナリングストリーム、およびサービスガイドストリームの組合せが占める帯域幅の管理に関わるサービスガイドサイズ管理の複雑さを軽減することができる。

本発明は、より詳細には、コントリビューションネットワーク（ｃｏｎｔｒｉｂｕｔｉｏｎ ｎｅｔｗｏｒｋ）のデバイス部分によりサービスガイドのメタデータサイズを管理する方法に関し、コントリビューションネットワークは入力としてオーディオおよび／またはビデオデータならびにサービスガイドデータ受け取るプロトコルエンカプスレータと、サービスガイドサーバとを備え、オーディオおよび／またはビデオストリームを含むストリーム、シグナリングストリーム、およびサービスガイドストリームの組合せが占める帯域幅の管理に関わるサービスガイドサイズ管理の複雑さを軽減する。従って、本発明を用いるプロトコルエンカプスレータはサービスガイドメタデータの最大サイズをプロトコルエンカプスレータの充填レベルの関数として決定し、そのサービスガイドメタデータの最大サイズを含むメッセージを、コントリビューションネットワークに接続されたサービスガイドサーバに送信し、サービスガイドサーバはサービスガイドメタデータをプロトコルエンカプスレータに配信し、そのサービスガイドメタデータのサイズは最大サイズ以下である。

本発明の特定の実施形態によれば、サービスガイドメタデータをＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）フォーマットでプロトコルエンカプスレータに提供する。

本発明の特定の実施形態によれば、サービスガイドメタデータを、ＸＭＬメタデータツリー形式でサービスガイドサーバに格納する。

本発明の特定の実施形態によれば、サービスガイドサーバは、ＸＭＬメタデータツリーを枝刈りすることにより最大メタデータサイズを順守する。

本発明の特定の実施形態によれば、サービスガイドサーバは、サービスガイドメタデータの日単位の期間を変化させて最大メタデータサイズを順守する。

本発明の特定の実施形態によれば、サービスガイドサーバは、メタデータツリーの枝刈り、またはサービスガイドメタデータの日単位の期間を変化させることの何れかによって、最大メタデータサイズを順守する。

本発明の特定の実施形態によれば、サービスガイドサーバは、メタデータツリーの枝刈り、およびサービスガイドメタデータの日単位の期間を変化させることにより、最大メタデータサイズを順守する。

本発明の特定の実施形態によれば、最大サービスガイドメタデータサイズを含むメッセージを、時間遅延の期限終了時に送信する。

本発明の特定の実施形態によれば、最大サービスガイドメタデータサイズを含むメッセージを、エンカプスレータの充填レベルの所定最大値を超えたら送信する。

本発明の特定の実施形態によれば、最大サービスガイドメタデータサイズを含むメッセージを、時間遅延の期限終了時、およびエンカプスレータの充填レベルの所定最大値を超えたら送信する。

本発明により、オーディオおよび／またはビデオストリームを含むストリーム、シグナリングストリーム、およびサービスガイドストリームの組合せが占める帯域幅の管理に関わるサービスガイドサイズ管理の複雑さを軽減することができる。

先行技術によるコントリビューションネットワークの一部を示す図である。 本発明の第１の実施形態によるコントリビューションネットワークの一部を示す図である。 第１の実施形態によるコントリビューションネットワークの２つのコンポーネントをより詳細に示す図である。 本発明を実装するコントリビューションネットワークの一部であるプロトコルエンカプスレータの充填レベルを管理するアルゴリズムを示す図である。 本発明の第１の実施形態によるサービスガイドサーバの詳細な図である。 本発明の第１の実施形態によるサービスガイドサーバ内部のサービスガイドメタデータサイズを削減する方法を示す図である。 本発明の第１の実施形態によるサービスガイドサーバ内部のサービスガイドメタデータサイズを削減する方法を示す別の図である。 本発明の第１の実施形態によるサービスガイドサーバが用いるアルゴリズムを示す図である。 本発明の第２の実施形態によるコントリビューションネットワークの一部を示す図である。 第２の実施形態によるコントリビューションネットワークの２つのコンポーネントをより詳細に示す図である。 本発明の第２の実施形態によるサービスガイドサーバの詳細な図である。 本発明の第２の実施形態によるサービスガイドサーバ内部でのサービスガイドメタデータサイズ削減方法を示す図である。 本発明の第２の実施形態によるサービスガイドサーバ内部でのサービスガイドメタデータサイズ削減方法を示す別の図である。 本発明の第２の実施形態によるサービスガイドサーバが使用するアルゴリズムを示す図である。 本発明の主要な特徴によるアルゴリズムを示す図である。

本発明のさらなる利点は、本発明の特定の非限定的な実施形態の説明を通して明らかになるであろう。これらの実施形態を、以下、付属の図面を参照しながら説明する。

図１は、先行技術によるコントリビューションネットワークの一部を示す。例として、ネットワークは、１組のオーディオ／ビデオエンコーダまたは複数のＡ／Ｖエンコーダ１０２、１０７、１１２、１１６を備える。それらは、ＣＨ１、ＣＨ２、ＣＨ３およびＣＨ４の名前を有するビデオまたはオーディオチャンネル（それぞれ、入力１０１、１０５、１１０、１１１）のコンテンツを、ＭＰＥＧ２またはＨ．２６４のような特定のフォーマットでエンコードする。これらのエンコーダの出力１０４、１０８、１１３、１１５は、プロトコルエンカプスレータ１０６に入る。プロトコルエンカプスレータ１０６は、Ａ／Ｖデータとは別に、サービスガイドサーバ１１８からサービスメタデータ出力１１４も受信する。このサーバは、入力１１７、１１９、１２０、１２１から、それぞれチャネルＣＨ１からＣＨ４に対して、メタデータ入力を受信する。最後に、プロトコルエンカプスレータの出力１０９はＲＦ変調器１０３に入り、アンテナ１００を用いて変調信号が送信される。

図２は、本発明の第１の実施形態によるコントリビューションネットワークの一部を示す。図面の複雑さを減らすため４つの入力のみを示してあるが、本発明によるプロトコルエンカプスレータは、１、２、３、１０または２０といった４つを超える入力を有することができる。ネットワークは１組のオーディオ／ビデオエンコーダまたは複数のＡ／Ｖエンコーダ１０２、１０７、１１２、１１６を備える。それらは、ＣＨ１、ＣＨ２、ＣＨ３およびＣＨ４の名前を有するビデオまたはオーディオチャンネル（それぞれ、入力１０１、１０５、１１０、１１１）のコンテンツを、ＭＰＥＧ２ビデオ（「非特許文献９」標準として知られている）またはＨ．２６４ビデオ（「非特許文献１０」）のような特定のフォーマットでエンコードする。これらのエンコーダの出力１０４、１０８、１１３、１１５はプロトコルエンカプスレータ２００に入る。プロトコルエンカプスレータ２００は、Ａ／Ｖデータの他に、サービスガイドサーバ２０１からサービスガイドメタデータ出力２０２も受信する。このサーバは、入力１１７、１１９、１２０、１２１から、それぞれチャネルＣＨ１からＣＨ４に対してメタデータ入力を受信する。図面の複雑さ減らすため、４つの入力のみを示してあるが、本発明によるサービスガイドサーバは、１、２、３、１０または２０といった任意数の入力を有することができる。プロトコルエンカプスレータ２００は、フィードバック信号２０３をサービスガイドサーバ２０１に出力し、それによりプロトコルエンカプスレータは入力２０２上で受信する出力メタデータのサイズを制御することができる。最後に、プロトコルエンカプスレータの出力２０４はＲＦ変調器１０３に入り、アンテナ１００を用いて変調信号が送信される。

図３は、本発明の第１の実施形態によるプロトコルエンカプスレータの動作を示す図である。プロトコルエンカプスレータの主な役割は、変調器が受け入れる特定の出力フォーマットに入力データを適合させることである。プロトコルエンカプスレータ２００はその入力上でサービスガイドメタデータストリームならびにオーディオおよび／またはビデオデータストリームを受信し、ＡＳＩ（非同期シリアルインタフェース）型の出力上の送信に対して、これらをＤＶＢ−Ｈ変調器に適合させる。一般に、本発明によるプロトコルエンカプスレータは、複数のＡ／Ｖストリームおよび１つのサービスガイドストリーム、および場合によってはＤＶＢ−ＳＩ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ−Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ）のような幾つかの信号送信データを扱うことができる。（「非特許文献１１」および「非特許文献１２」）を参照）このプロトコルエンカプスレータは、それぞれの入力１０１、１０５、１１０、１１１、２０２に対するバッファ３０１、３０２、３０３、３０４、３０５で入力データ３００をバッファする機能を備える。ここでは例として「非特許文献１３」標準によるマルチプロトコルカプセル化としてのＭＰＥという名前で示したプロトコルエンカプスレータ機能３０６と、多重化／時分割機能３１３とを備える。カプセル化法としてはＭＰＥ以外の方法が可能であり、本発明により何ら限定をしない。エンカプスレータ機能３０６は、（例えばＩＰのような）パケット指向プロトコルをＭＰＥＧ―２トランスポートストリーム（ＴＳ）上で伝送する手段を提供する。エンカプスレータ機能３０６は、バッファ３０１からバッファ３０５の全ての出力に対して、それぞれ別々のカプセル化機能３０７からカプセル化機能３１１を備える。これらのカプセル化機能の出力は、多重化／時分割機能３１３に入力される。多重化機能３１３を使用して、複数の入力ストリームを１つの単一トランスポートストリーム（ＴＳ、「非特許文献１４」標準で規定）に結合する。ポータブル受信機のバッテリ節約に対して時分割を使用することができ、上記の時分割機能はタイムスロットまたは帯域幅の観点から伝送リンク上で利用可能な空間を分割することを含むことができる。多重化／時分割機能３１３の出力信号を、ＲＦ変調器に対する出力２０４上に持ってくる。

プロトコルエンカプスレータ２００はさらに、接続３１４を介してバッファ３０５の充填レベルを監視する充填レベル監視機能３１５を備える。本発明の特定の実施形態によると、監視機能３１５は多重化／時分割３１３からの充填レベル信号を使用する。従って充填レベル監視を多重化／時分割データに必要な帯域幅全体に関連付ける。本発明の特定の実施形態によると、サービスガイドメタデータバッファ３０５からの信号３１４の代わりに、この信号を充填レベル監視機能３１５により使用する。本発明の特定の実施形態によると、信号３１４と関連して信号３１６を充填レベル監視機能により使用する。監視機能３１５はサービスガイドメタデータの最大サイズをエンカプスレータの充填レベルの関数として決定する。監視機能３１５は、サービスガイドメタデータの最大サイズを含むメッセージ２０３をサービスガイドサーバ２０１に送信することを決定して、サービスガイドサーバ２０１が送信するメタデータの最大サイズを制御することができる。サービスガイドサーバ２０１は、チャンネルＣＨ１からＣＨ４に対するメタデータを含む入力データを、それぞれ入力１１７、１１９、１２０、１２１上で受信し、配信されるメタデータのサイズがプロトコルエンカプスレータからのメッセージが示す最大サイズ以下であることを保証しながら、サービスガイドメタデータをプロトコルエンカプスレータに配信する。

図４は、本発明の特定の実施形態による、プロトコルエンカプスレータの充填レベルを管理するアルゴリズムを示す。このアルゴリズムは、ステップ４００で開始する。ステップ４００には、アルゴリズムの初期化が含まれ、その間に変数を初期化する。充填レベルをステップ４０１で決定する。決定ステップ４０２で、この充填レベルを所定の最大レベルと比較する。充填レベルが所定の最大レベルを超える場合、分岐４０３を経てステップ４０４に至る。ステップ４０４には、サービスガイドメタデータの最大サイズを示すメッセージのサービスガイドサーバへの送信が含まれる。ステップ４０４の後、ステップ４０１が再度実行される。他方、充填レベルが所定の最大レベルを超えない場合、分岐４０５に移り、ステップ４０１が再度実行される。本発明の特定の実施形態によれば、アルゴリズムはステップ４０２を含まず、ステップ４０４をステップ４０１の直後に実行し、次いでステップ４０１を時間遅延の期限終了後に再度実行する。これはサービスガイドサーバを充填レベルの状態に関する定期更新情報で更新するのに有利であり、高い充填レベルを予測するのに使用できる。従って結果としてサービスガイドメタデータサイズをより良く調整することができる。本発明の特定の実施形態によると、アルゴリズムはステップ４０２を含み、決定ステップ４０２の条件が肯定的に評価されるとステップ４０４を実行する。上記のアルゴリズムは、時間遅延の期限終了後にステップ４０４を実行することも含む。これは、サービスガイドサーバを充填レベル値で定期的に更新する間にサービスガイドサーバにメタデータサイズが所定の最大サイズを超過することを警告してサービスガイドサーバが充填レベルの増大傾向を決定することを可能とする。かつ、サービスガイドサーバがサービスガイドメタデータをより良く予測し、従って配信されるメタデータがプロトコルエンカプスレータからのメッセージが示す最大サイズ以下であることを保証しながらサービスガイドメタデータをプロトコルエンカプスレータに配信することができるという、複合的な利点を有する。

図５は、本発明の第１の実施形態によるサービスガイドサーバの詳細な図を示す。サービスガイドサーバ２０１は、入力１１７、１１９、１２０、１２１上のＸＭＬフォーマットで入って来るサービスガイドメタデータを、接続５０４によりデータベース５０７に格納することができる機能５００を備える。次いで、機能５０１は、データベース内のＸＭＬメタデータツリーを辿り、ノードおよびリーフを除外するのに利用可能なオプションを決定し、それぞれのオプションのデータサイズを計算し、データベース内のメタデータツリーノードおよびリーフをそれぞれのオプションおよびその対応サイズの仕様で注釈付けすることにより、サービスガイドサーバを準備する。機能５０１は、接続５０５を使用してデータベースにアクセスする。

メタデータサイズマネージャである機能５０６は、プロトコルエンカプスレータ２００からのメッセージをリッスンする。そのメッセージは、サービスガイドサーバ２０１が接続２０２上で送信できるメタデータの最大値を示す。メタデータサイズマネージャ機能５０６に対する入力であるこの種のメッセージは、接続２０３上で受信される。このマネージャ機能５０６は、接続５０８でデータベースにアクセスする。さらに、サービスガイドサーバは、機能５１１を備える。機能５１１により、このサーバはサービスガイドをカルーセル形式でプロトコルエンカプスレータ２００に送信することができる。マネージャ機能５０６は、プロトコルエンカプスレータに送信されるカルーセルに含めるために、格納したＸＭＬメタデータツリーの一部またはＸＭＬメタデータツリーの要素をカルーセルスケジューラ５１１により除外しなければならないかどうかを決定する。このメタデータツリーの一部を除外する方法を、以降「枝刈り（ｐｒｕｎｉｎｇ）」という言葉でも指定する。従って、マネージャ機能５０６は、除外しなければならないオプションのメタデータツリー部分をマーク付けするか、または以前にマーク付けしていたツリー部分をマーク解除するステップを含む。それを行うため、マネージャ機能５０６はデータベースに格納したＸＭＬメタデータツリーを辿り、以前に機能５０１によりツリーに追加したオプションとサイズの注釈付けを使用する。マネージャ機能５０６がプロトコルエンカプスレータからのメッセージで受信したメタデータサイズ制限に依存して、マネージャ機能５０６は除外すべきメタデータツリーの一部をマーク付けするか、または以前にマーク付けした部分をマーク解除する。次いで、カルーセルスケジューラ５１１は新規データ収集を開始し、その後、マネージャ機能５０６により除外とマーク付けしたメタデータを含まない新規のメタデータカルーセルを構築する。最後に、カルーセルスケジューラ５１１は接続２０２により、ＸＭＬフォーマットでメタデータカルーセルをプロトコルエンカプスレータ２００に送信する。

図６および図７によって、メタデータツリーの一部を除外する方法を説明する。図６は、サービスガイドメタデータツリーの一部を示す。要素６００をノードと称することができ、要素６０１から６１１をリーフまたはリーフノードと称することができる。点線の要素はオプションであり、メタデータツリーをなお有効なＸＭＬ文書に保ちつつ、メタデータサイズマネージャ５０６が行った決定に従って出力２０２上で送信されるメタデータカルーセルの点線の要素を除外することができる。有効なＸＭＬ文書は、その構文がスキーマに従う文書である。そのスキーマには、例えばＯＭＡ ＢＣＡＳＴ「非特許文献１５」により定義されるサービスガイドに対するＸＭＬスキーマがある。

図７は、オプション要素を除外したメタデータツリーの一部を示した図である。

図８は、本発明の第１の実施形態によるサービスガイドサーバが用いるアルゴリズムを示す。第１のステップ８００は、使用する変数の初期化を含む。次に、ステップ８０１は、入力上の入って来るメタデータをデータベースに格納する。次いで、ステップ８０２の間に、データベースに以前に格納したメタデータツリー内でメタデータのサイズおよびオプションを決定し注釈付けする。次いで、ステップ８０４で、メタデータサイズマネージャは、サービスガイドサーバが出力できるメタデータの最大サイズを示すメッセージをプロトコルエンカプスレータ２００から受信する状態にある。分岐８０３に続いて、上記メッセージを受信しない限りステップ８０４を繰り返す。しかしながら、上記メッセージを実際に受信すると、分岐８０５に移りステップ８０６に至る。そこでメタデータサイズマネージャは、必要ならばデータベース内のメタデータツリーのどのオプション部分を除外すべきかを決定する。次いで、ステップ８０７で、必要ならば、メタデータサイズマネージャは除外すべきデータをマーク付けし、および／またはステップ８０４から８１０への以前の繰り返しで既に除外とマーク付けしたデータをマーク解除する。次のステップ８０８として、カルーセルスケジューラはマーク付けしていないデータをデータベースからフェッチし、ステップ８０９で新規カルーセルを集めてそのカルーセルをプロトコルエンカプスレータに送信する。最後に、アルゴリズムはステップ８０４に戻り、プロトコルエンカプスレータからの別のメッセージを待つ。

図９は本発明の第２の実施形態によるコントリビューションネットワークの一部を示す。図面の複雑さを減らすため、４つの入力のみを示してあるが、本発明によるプロトコルエンカプスレータは４つを超える入力を有することができる。ネットワークは１組のオーディオ／ビデオエンコーダまたは複数のＡ／Ｖエンコーダ１０２、１０７、１１２、１１６を備える。それらは、ＣＨ１、ＣＨ２、ＣＨ３、ＣＨ４の名前を有するビデオまたはオーディオチャンネル（それぞれ、入力１０１、１０５、１１０、１１１）のコンテンツを、ＭＰＥＧ２またはＨ．２６４のような特定のフォーマットでエンコードする。これらのエンコーダの出力１０４、１０８、１１３、１１５はプロトコルエンカプスレータ２００に入る。プロトコルエンカプスレータ２００は、Ａ／Ｖデータの他に、サービスガイドサーバ９０１からサービスガイドメタデータ出力９００も受信する。このサーバは、入力１１７、１１９、１２０、１２１から、それぞれチャネルＣＨ１からＣＨ４に対してメタデータ入力を受信する。プロトコルエンカプスレータ２００はフィードバック信号２０３をサービスガイドサーバ９０１に出力し、それによりプロトコルエンカプスレータは接続９００上で受信するメタデータのサイズを制御することができる。最後に、プロトコルエンカプスレータの出力２０４はＲＦ変調器１０３に入り、アンテナ１００を用いて変調信号が送信される。

図１０は、本発明の第２の実施形態によるプロトコルエンカプスレータ２００の動作を示す図である。プロトコルエンカプスレータの主な役割は、入力データを、変調器が受け入れる特定の出力フォーマットに適合させることである。プロトコルエンカプスレータ２００は、その入力上でサービスガイドメタデータストリームならびにオーディオおよび／またはビデオデータストリームを受信し、ＡＳＩ（非同期シリアルインタフェース）型の出力上の送信に対して、これらをＤＶＢ−Ｈ変調器に適合させることができる。一般に、本発明によるプロトコルエンカプスレータは、複数のＡ／Ｖ入力ストリームおよび１つのサービスガイドストリーム、および場合によってはＤＶＢ−ＳＩ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ−Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ）のような信号送信データに対する入力を扱うことができる。図１０は、４つのＡ／Ｖ入力ストリームと１つのＳＧストリームとを扱うことができる本発明の第２の実施形態によるプロトコルエンカプスレータの例を示す。このプロトコルエンカプスレータは、それぞれの入力１０１、１０５、１１０、１１１および入力９００に対するバッファ３０１、３０２、３０３、３０４およびバッファ３０５で入力データ３００をバッファする機能、ここではマルチプロトコルカプセル化としてのＭＰＥという名前で示したプロトコルエンカプスレータ機能３０６と、および多重化／時分割機能３１３とを備える。エンカプスレータ機能３０６は、バッファ３０１からバッファ３０５の全ての出力に対して、それぞれ別々のカプセル化機能３０７からカプセル化機能３１１を備える。これらのカプセル化機能の出力は多重化／時分割機能３１３に入力される。多重化機能を使用して複数の入力を１つの単一のトランスポートストリームに結合することができる。ポータブル受信機のバッテリ節約に関して時分割を使用することができ、上記の時分割機能は、タイムスロットまたは帯域幅の観点から伝送リンク上で利用可能な空間を分割することを含むことができる。多重化／時分割機能３１３の出力信号を、ＲＦ変調器に対する出力２０４に持ってくる。プロトコルエンカプスレータ２００はさらに、接続３１４を介してバッファ３０５の充填レベルを監視する充填レベル監視機能３１５を備える。本発明の特定の実施形態によると、監視機能は多重化／時分割３１３からの充填レベル信号を使用し、従って充填レベル監視を多重化／時分割データに必要な帯域幅全体に関連付ける。

本発明の特定の実施形態によると、サービスガイドメタデータバッファ３０５からの信号３１４の代わりに、この信号を充填レベル監視機能３１５により使用する。本発明の特定の実施形態によると、信号３１４とともに信号３１６を充填レベル監視機能により使用する。監視機能３１５はサービスガイドメタデータの最大サイズを、充填レベルに関して取得した情報の関数として決定する。監視機能３１５は、サービスガイドメタデータの最大サイズを含むメッセージ２０３をサービスガイドサーバ９０１に送信することを決定して、そのサービスガイドサーバが送信するメタデータの最大サイズを制御することができる。サービスガイドサーバ９０１は、チャンネルＣＨ１からＣＨ４に対するメタデータを含む入力データを、それぞれ入力１１７から入力１２１上で受信する。

図１１は、図９および図１０の本発明の第２の実施形態によるサービスガイドサーバの詳細な図を示す。サービスガイドサーバ９０１は、入力１１７、１１９、１２０、１２１上に入って来るサービスガイドメタデータを、接続１１０５によりデータベース１１０８に格納することができる機能１１０１を備える。次いで、イベントカレンダサイズの決定と名付けられた機能１１０２が、接続１１０６により、格納されるメタデータの日単位のサイズを決定し、この情報をデータベースに格納する。サービスガイドサーバは、さらに機能１１１２を備える。機能１１１２により、このサーバはサービスガイドをカルーセル形式でプロトコルエンカプスレータ２００に送信することができる。プロトコルエンカプスレータにより可能な最大メタデータサイズ値に従って、マネージャ機能１１０７は、カルーセルに含めるためにスケジューラ１１１２が取るメタデータの日単位の期間を削減しなければならないかどうか、不変のままにすることができるかどうか、または増やすことができるかどうかを決定する。これを行うため、マネージャ機能１１０７は、データベース内で、その加算されたメタデータサイズがメッセージにより示される最大許容メタデータサイズ以下である日単位の期間を探索する。次いで、マネージャ機能１１０７は除外しなければならないメタデータをマーク付けするか、または再度含めることが可能な以前に除外したメタデータをマーク解除する。次いで、カルーセルスケジューラ１１１２は新規データ収集を開始し、その間に、除外とマーク付けしたメタデータを除く全てのメタデータを含む新規メタデータカルーセルを構築する。最後に、スケジューラは、新規メタデータカルーセルを接続９００上でプロトコルエンカプスレータ２００に送信する。

この第２の実施形態の方法は、サービスガイドサーバ内部でのサービスガイドメタデータサイズ削減方法を示す図１２および図１３によって最も良く説明される。

図１２は、週日（ウィークデー）のイベントカレンダとして表したサービスガイドメタデータを示す。横軸はその週の異なる日（例えば、月曜日、火曜日等）を表す。縦軸は１日の時刻（即ち、００：００−２３：５９）を表す。点線１２０３、１２０４、１２０５はそれぞれ、月曜日、火曜日および日曜日に対する他の図示していないイベントを表す。点線１２０９は他の図示していない日、水曜日、木曜日、金曜日および土曜日を表す。それぞれのイベントを、イベント日、開始時刻および終了時刻を含む長方形で表す。例えば長方形１２１０は、００：００で始まり０１：００で終わる、月曜日に対するイベントを表す。長方形１２０８は、００：１２で始まり００：１５で終わる、日曜日に対するイベントを表す、等である。

図１３は、本発明の第２の実施形態によるサービスガイドメタデータサイズの削減を示す。図１２に対するように、サービスガイドメタデータを週日のイベントカレンダとして表す。横軸はその週の異なる日、月曜日および火曜日を表す。縦軸は１日の時刻（即ち、００：００−２３：５９）を表す。点線１２０３および１２０４はそれぞれ、月曜日および火曜日に対する他の図示していないイベントを表す。それぞれのイベントを、イベント日、開始時刻および終了時刻を含む長方形で表す。例えば、長方形１２１０は、００：００で始まり０１：００で終わる月曜日に対するイベントを表す。長方形１２０７は、００：５０で始まり０１：３５で終わる火曜日に対するイベントを表す、等である。図１２を図１３と比較すると、２つの図面の間の差異が、本発明の第２の実施形態による週日のイベントカレンダ期間の削減を表すことが分かる。

図１４は、本発明の第２の実施形態による、サービスガイドサーバが使用するアルゴリズムを示す。第１のステップ１４００で、変数を初期化する。次いでステップ１４０１で、入って来るメタデータをデータベースに格納する。次いでステップ１４０２で、メタデータのサイズを週日単位の期間の関数として決定する。例えば、メタデータのサイズを３日間の週日、月曜日から水曜日に対して、または７日間の週日、月曜日から日曜日に対して決定する。次いで、ステップ１４０４で、メタデータサイズマネージャはサービスガイドサーバが出力できるメタデータの最大サイズを示すメッセージをプロトコルエンカプスレータ２００から受信する状態にある。分岐１４０３に続いて、上記メッセージを受信しない限りステップ１４０４を繰り返す。しかしながら、上記メッセージを実際に受信すると、分岐１４０５を経てステップ１４０６に至る。そこでメタデータサイズマネージャは、必要ならばどの週日を除外すべきかを決定する。次いで、ステップ１４０７で、必要ならば、メタデータサイズマネージャは除外すべきデータをマーク付けし、および／またはステップ１４０４から１４１０への以前の繰り返しで既に除外とマーク付けしたデータをマーク解除する。次のステップ１４０８として、カルーセルスケジューラはマーク付けしていないデータをデータベースからフェッチし、ステップ１４０９で新規カルーセルを集めてそのカルーセルをプロトコルエンカプスレータに送信する。最後に、アルゴリズムはステップ１４０４に戻り、プロトコルエンカプスレータからの別のメッセージを待つ。

図１５は、本発明によるアルゴリズムを示す。そのアルゴリズムはステップ１５００で開始し、その間に本方法で使用する別の変数を初期化する。次いで、ステップ１５０１で、サービスガイドメタデータの最大サイズをプロトコルエンカプスレータの充填レベルの関数として決定する。次いで、ステップ１５０２で、サービスガイドメタデータの最大サイズを含むメッセージを、コントリビューションネットワークに接続したサービスガイドサーバに送信する。次に、ステップ１５０３で、サービスガイドサーバはサービスガイドメタデータをプロトコルエンカプスレータに配信する。この場合、サービスガイドメタデータのサイズは、決定した最大サイズ以下である。

本発明の特定の実施形態では、説明した第１の実施形態および第２の実施形態を排他的な方法で組み合わせて、サービスガイドメタデータをエンカプスレータの充填レベルにより良く適合させることができる。このように、メタデータツリーの枝狩り、またはサービスガイドメタデータの日単位の期間を変化させることのいずれかによって、サービスガイドメタデータの最大サイズを順守することができる。

本発明の特定の実施形態では、説明した第１の実施形態および第２の実施形態を排他的でない方法で組み合わせて、サービスガイドメタデータをエンカプスレータの充填レベルにより良く適合させることができる。このソリューションは非常に柔軟であるという利点を有する。

もちろん、本発明は上述の実施形態には限定されない。

本明細書で説明した本発明の例示的な実施形態は、本発明の適用分野を説明したネットワークの種類および装置の種類に限定されず、本発明は説明した装置のアーキテクチャにも制限されない。サービスガイドメタデータのサイズをプロトコルエンカプスレータの充填レベルに適合することを求める場合、本発明を他種のネットワーク、装置内部または異なるアーキテクチャを有する装置内部で使用することができる。

例として、本発明を、コントリビューションネットワーク上に置いた制約とは異なる特定の地理的制約を有する分散ネットワークに適用することができる。

例として、本発明を実装する装置を衛星送信（例えば、ＤＶＢ−Ｓ）のようなＩＰベースとは異なる種類のネットワークに適用するとき、およびサービスガイドデータがＪＳＯＮ（Ｊａｖａｓｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）またはＳＯＸ（Ｓｉｍｐｌｅ Ｏｎｌｉｎｅ ＸＭＬ）のようなＸＭＬとは異なる種類のフォーマットを使用するとき、本発明をＭＰＥエンカプスレータおよびＸＭＬサービスガイドサーバと異なる種類の装置に適用することができる。

例として、本発明により説明したような装置では、衛星上の送信に関して時分割機能がないような別のアーキテクチャを使用することができる。および／または本発明は、誤り耐性符号化、ＤＶＢ−ＳＩテーブル再生成、またはすでに多重化されたストリームを受け取るオーディオおよび／またはビデオストリームに対する入力のような、本文書で説明していない他の機能を含むことができる。

本発明は、本発明は通信分野に関し、より詳細にはサービスガイドメタデータのサイズ管理に利用できる。

１０２、１０７、１１２、１１６ Ａ／Ｖエンコーダ
１０３ ＲＦ変調器
２００ プロトコルエンカプスレータ
２０１、９０１ サービスガイドサーバ

Claims (10)

1. コントリビューションネットワークのデバイス部分によりサービスガイドのメタデータサイズを管理する方法であって、前記コントリビューションネットワークは、少なくとも１つのオーディオおよび／またはビデオ入力データストリームならびにサービスガイド入力データストリームを受け取るように構成されたプロトコルエンカプスレータと、サービスガイドサーバとを含み、前記プロトコルエンカプスレータは、入力データバッファと、マルチプル入力ストリームからのデータを１つの単一のトランスポートストリームに多重化するように構成された多重化器とを含む、方法であって、前記方法は、
   サービスガイドメタデータの最大サイズをプロトコルエンカプスレータの充填レベルの関数として決定するステップであって、前記プロトコルエンカプスレータの充填レベルは、入力データバッファの充填レベル、および、前記多重化されたデータに必要な帯域幅に依存する、ステップと、
   前記コントリビューションネットワークに接続されたサービスガイドサーバ宛ての前記サービスガイドメタデータの前記最大サイズを含むメッセージを送信するステップと、
   前記サービスガイドサーバにより、前記サービスガイドメタデータを前記プロトコルエンカプスレータに配信するステップであって、前記サービスガイドメタデータのサイズは前記最大サイズ以下または前記最大サイズに等しい、ステップと
   を備えることを特徴とする方法。
2. 前記サービスガイドメタデータは、拡張マークアップ言語形式で前記プロトコルエンカプスレータに提供されることを特徴とする請求項１に記載の方法。
3. 前記サービスガイドメタデータは、拡張マークアップ言語のメタデータツリー形式で前記サービスガイドサーバに格納されることを特徴とする請求項１または２に記載の方法。
4. 前記サービスガイドサーバは、前記ＸＭＬメタデータツリーの枝刈りによって、前記最大メタデータサイズを順守することを特徴とする請求項３に記載の方法。
5. 前記サービスガイドサーバは、前記最大メタデータサイズとするために、前記サービスガイドメタデータの日単位の期間を変化させることを特徴とする請求項１乃至４のいずれか１項に記載の方法。
6. 前記サービスガイドサーバは、前記メタデータツリーの枝刈り、または前記サービスガイドメタデータの日単位の期間を変更させることの何れかによって、前記最大メタデータサイズを順守することを特徴とする請求項３乃至５のいずれか１項に記載の方法。
7. 前記サービスガイドサーバは、前記メタデータツリーの枝刈り、および前記サービスガイドメタデータの日単位の期間を変更させることによって、前記最大メタデータサイズを順守することを特徴とする請求項４または５に記載の方法。
8. 前記メッセージは、前記最大サービスガイドメタデータサイズを含み、時間遅延の期限終了時に送信されることを特徴とする請求項１乃至７のいずれか１項に記載の方法。
9. 前記メッセージは、前記最大サービスガイドメタデータサイズを含み、前記エンカプスレータの充填レベルの所定最大値を超えると送信されることを特徴とする請求項１乃至７のいずれか１項に記載の方法。
10. 前記メッセージは、前記最大サービスガイドメタデータサイズを含み、前記エンカプスレータの充填レベルの所定最大値を超えると送信されることを特徴とする請求項８に記載の方法。

Images