JP2007520937A - ネットワークを介したデジタルサービスの送信方法及び当該方法を実現する装置 - Google Patents

Abstract

ＩＰネットワークを介しＤＶＢサービスを配信することに関して、提供されるサービスとネットワークを記述するシグナリング情報をサービス自体から分離することがトレンドである。このシグナリングは、ＨＴＴＰサーバ上で利用可能なＸＭＬファイルを介し端末に利用可能とされる。このアプローチと対照的に、本発明は、双方向ネットワークに接続されるレシーバによる双方向ネットワーク上のデジタルサービスを認識する方法に関し、当該方法は、レシーバが第１ストリームと接続するステップと、レシーバが一方ではサービスのコンテンツを搬送するストリームと、他方では当該サービスを記述する情報を搬送する別のストリームとのネットワーク上の位置に関するストリーム情報から抽出するステップと、レシーバが当該サービスに関する情報を取得するため、サービス記述情報を搬送するストリームの少なくとも一部に接続するステップと、レシーバがネットワーク上で利用可能なサービスのおそらく単一のリストを構成するため、当該情報を利用するステップとから構成される。

Description

発明の詳細な説明

本発明は、デジタルサービスの送信に関し、より詳細には、ＤＶＢ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ）規格に準拠するサービスに関する。ＤＶＢは、通常の放送タイプ（地上波、ケーブル又は衛星）のネットワークだけでなく、近年ではＩＰタイプネットワーク、言い換えると、インターネットプロトコル（ＩＰ）をサポートするネットワークを介し、「スケジュールの一部として配信可能な放送局の制御による番組シーケンス」としてサービスを規定している。このＩＰの仕様は、ナンバー７９１の下、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）により維持されるＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔｓ）資料に見つけることができる。

ネットワークにより提供されるデジタルサービスの認識は、衛星、ケーブル又はデジタル地上波送信ネットワークに関してＤＶＢにより規格化されている。この規格は、ナンバーＥＴＳＩ ＥＮ ３００ ４６８の下、ＥＴＳＩ（Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｅ）により公開された資料“Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ）；Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｆｏｒ Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ（ＳＩ） ｉｎ ＤＶＢ Ｓｙｓｔｅｍｓ”に記載されている。この資料は、ネットワーク、サービスを有するデータストリームが送信される周波数、提供されるサービスなどに関する情報を含むテーブル群を記載している。読者はまた、トランスポートストリームフォーマットの規定については資料“ＭＰＥＧ−２ ｓｙｓｔｅｍ−ＩＳＯ ＩＥＣ １３８１８−１”を参照することができる。トランスポートストリームは、音声データ、映像データ、エレメンタリストリームの形式によるサブタイトル、テレテキスト、インタラクティブアプリケーションなどの補助データ、ネットワーク上の他のトランスポートストリームが検出されることを可能にするＮＩＴ（Ｎｅｔｗｏｒｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）、ＰＡＴ（Ｐｒｏｇｒａｍ Ａｓｓｏｃｉａｔｉｏｎ Ｔａｂｌｅ）、ＰＭＴ（Ｐｒｏｇｒａｍ Ｍａｐ Ｔａｂｌｅ）など、コンテンツを構成するのに使用される最小限のシグナリングテーブルを含む。これらのテーブルは、トランスポートストリームにおいて多重化され、レシーバは、それがこれらのテーブルを受信し、そのコンテンツからネットワークにより提供されるサービスのリスト及びそれらを受信するのに必要な接続データを含むデータベースを構築することを可能にする第１ストリームに接続するのに必要なデータにより構成される。

デジタル双方向データネットワーク、特にインターネットと、高速サービスの公開の拡大に従って、このタイプのネットワークを介しオーディオビジュアルデジタルサービスを送信する技術的機能が、現在利用可能である。また、プライベート高ビットレートＩＰネットワークが、企業用及び家庭用の両方について開発されている。これに関して、ＤＶＢは、ＩＰネットワークを介したＤＶＢサービスの配信を標準化するため作業を行っている。ＤＶＢ−ＩＰＩ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）と呼ばれるワーキンググループは、ＩＰネットワークを介したＤＶＢデジタルサービスの伝送に関する仕様、より詳細には、これらのサービスの認識を決定している最中である。現在考えられているような提案は、リファレンスＩＰＩ２００３−２２７の下、資料“ＤＶＢ−ＩＰ Ｐｈａｓｅ １ Ｈａｎｄｂｏｏｋ”に記載されている。ワーキンググループにより現在考えられているような解決手段は、一方における単一のＤＶＢサービスを含むトランスポートストリームの形式によるサービスの配信と、例えば、リクエストにより端末にアクセス可能なＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ファイルの形式により利用可能なサービスを記述する情報との間の分離に関するものである。ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）は、例えば、これらのファイルを抽出するのに利用可能である。この解決手段は、例えば、衛星送信と対照的にＩＰ接続の双方向性を利用しているため、当然なものであるかもしれない。実際、ＤＶＢなどの規格は、レシーバにとって有用である可能性が高いすべての情報が持続的に送信されることを要求する一方向の送信ネットワークの観点から設計されたものである。検討されているネットワークの双方向性は、オーディオビジュアルサービスを復号するのに有用な情報と、サービス説明情報との区別が可能であるということを意味する。ＤＶＢストリームに従来含まれていた上記２つのタイプの情報は、レシーバによって同時に使用されるものではない。従って、ネットワークを介したそれらの送信は分離可能であり、このため、シグナリング情報が音声映像チャネルにおいて持続的でなく、リクエストに応じて送信されるという事実により、帯域幅を節約することが可能となる。さらに、ＸＭＬデータファイルの形式によるＨＴＴＰサーバを介したＩＰタイプネットワークに関する情報の提供は、当該タイプのネットワークのついて広く採用される支配的な解決手段である。

しかしながら、この解決手段は、ＸＭＬフォーマットにより上記シグナリング情報を提供するサーバを構成及び管理するためのツールセットを開発することが必要となる。実際、現在、コンテンツプロバイダは、衛星又はケーブルを介しＭＰＥＧ−２ ＤＶＢサービスを送信するための制御されたインフラを有している。この新たなシグナリングシステムの採用は、既存のシステムとパラレルに新たなツールが開発される必要があることを意味するため、オペレータは投資を行い、リスクをとる必要がある。さらに、端末は現在、ＸＭＬアナライザなど、当該情報を解析するのに必要とされるツールを搭載していない。安価なレシーバにこのようなツールを搭載することは、プロセッサパワーやメモリなどの利用可能なハードウェアリソースに応じて、困難であり、不可能ですらあるとわかるかもしれない。

本発明は、双方向データネットワークを介しデジタルサービスを送信する方法を提供し、より詳細には、レシーバによるネットワークを介し提供されるサービスの認識を提供する。本方法は、ＤＶＢに関連して利用され、衛星又はケーブル用のＤＶＢサービスについて現在利用される生成チェーンの大部分が再利用されることを可能にする。本方法はまた、サービス認識のため情報を配信するのに使用される帯域幅が制限されることを可能にすべきである。

本発明は、双方向ネットワークに接続されるレシーバによる双方向ネットワーク上のデジタルサービスを認識する方法に関し、当該方法は、レシーバが第１ストリームと接続するステップと、レシーバが一方ではサービスのコンテンツを搬送するストリームと、他方では当該サービスを記述する情報を搬送する別のストリームとのネットワーク上の位置に関するストリーム情報から抽出するステップと、レシーバが当該サービスに関する情報を取得するため、サービス記述情報を搬送するストリームの少なくとも一部に接続するステップと、レシーバがネットワーク上で利用可能なサービスのおそらく単一のリストを構成するため、当該情報を利用するステップとから構成される。

本発明の実施例によると、サービスに関するすべてのシグナリングテーブルは、当該サービスのコンテンツを搬送するストリーム以外の少なくとも１つのストリームに含まれる。

本発明の実施例によると、本方法は、識別子を有するテーブルが当該ストリームにおいて利用可能であるか判断するのに使用されるストリームの記述子に含まれるフィルタと識別子との間のマッピングをテストするステップを有する。

本発明の実施例によると、第１配信ＩＰアドレスと第１ポート番号は、ユーザにより入力される。

本発明の実施例によると、第１ＩＰアドレスと第１ポート番号は、レシーバによりネットワークから取得される。

本発明の実施例によると、ストリームは単一のＤＶＢサービスのみを含む。

本発明の実施例によると、サービスのリストは、第１ポート上の第１配信ＩＰアドレスにおいて利用可能なストリームに含まれるＮＩＴに含まれる。

本発明はまた、ＩＰネットワークと接続する手段を介し配信ＩＰアドレスと接続する手段と、前記配信ＩＰアドレスに配信されるＤＶＢストリームを復号する手段とを有する装置であって、前記ＤＶＢストリームを復号する手段は、前記ＩＰネットワークに適したネットワーク記述子を有し、前記ストリームから抽出されるＮＩＴを解析し、前記ＮＩＴに記述される各配信ＩＰアドレスと接続し、好ましくは、上述の方法の何れかに従って、その中のＤＶＢストリームを読み出し、それから前記ネットワーク上で提供されるサービスに関する情報を抽出することが可能であることを特徴とする装置に関する。

本発明はまた、ＮＩＴに含めるため、ＤＶＢストリームを配信するサービスの記述子であって、ストリームサーバの配信ＩＰアドレスと、前記サーバがＩＰタイプネットワークを介しサービスのコンテンツを搬送するＤＶＢストリームを配信するポート番号とを有し、少なくとも１つの記述子は、ストリームサーバの配信ＩＰアドレスと、前記サーバが、該サーバに関するシグナリング情報を搬送するＤＶＢストリームを配信するポート番号とを有することを特徴とする記述子に関する。

本発明の実施例によると、ストリームサーバの配信ＩＰアドレスと、該サーバが前記サーバに関するシグナリング情報を搬送するＤＶＢストリームを配信するポート番号とを有することを前記１以上の記述子は、識別子とフィルタとの間のマッピングをテストする手段を有する。

本発明はより良好に理解され、他の特徴及び効果は、添付した図面を参照しながら、以下の説明を読むことにより明らかとなるであろう。

本発明の実施例は、ＩＰネットワークを介したＤＶＢサービスの送信に関するが、双方向データネットワークを介しデジタルサービスを送信する他の任意のシステムに適用可能である。

ＩＰタイプネットワークを介したサーバとの接続は、ＩＰマルチキャストプロトコルを用いて実現可能である、このようなプロトコルの一例は、ＲＦＣ２２３６に規定されるＩＧＭＰ（Ｉｎｔｅｒｎｅｔ Ｇａｔｅｗａｙ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）である。当該プロトコルでは、マルチキャストサーバは、関連付けされたマルチキャストアドレスを有する。このアドレスは、このために確保されたドメインにおけるＩＰアドレスのフォーマットを有するが、ネットワークを介しアクセス可能なマシーンのＩＰアドレスに対応するものではない。このサーバに接続することを所望するレシーバは、当該マルチキャストＩＰアドレスを含むリクエストをネットワークを介し送信する。このリクエストは、それが当該配信用のサーバに到達するまでネットワーク内を中継され、その後、当該レシーバを配信クライアントとして登録する。その後、サーバとレシーバとの間のパス上のルータは、ストリームを構成するＩＰパケットを配信を契約している端末に中継することが可能となる。マルチキャストＩＰアドレスに加えて、サーバマシーンのＩＰアドレスを知ることにより、当該プロトコルのエンハンストバージョンは、契約リクエストによりとられるルートを、それをネットワーク全体に配信する代わりに、対象サーバに直接ルーティングすることによって、ルートを最適化することができる。このエンハンストバージョンは、ＳＳＭ（Ｓｏｕｒｃｅ Ｓｐｅｃｉｆｉｃ Ｍｕｌｔｉｃａｓｔ）とい名称により知られている。従って、それはデジタルデータ配信との契約に基づくシステムである。サーバは、ネットワークを介しパケット形式によりデジタルデータを配信する。レシーバがこの配信と契約しない限り、実際にパケットは送信されない。レシーバが契約を行うと、パケットがサーバとクライアントとの間のルートに従ってネットワークを介しルーティングされることにより送信される。プロトコルは、パケットが当該配信を実際に契約しているレシーバに導かれるネットワークのルートしか利用しないことを保証する。レシーバが契約を解約すると、当該レシーバへのパケットの実際の送信は停止される。プロトコルはまた、当該配信を契約している複数のレシーバに導かれるネットワークのルート部分を介しパケットが重複しないことを保証する。

サービスを構成するデータの送信はまた、ＩＰユニキャストプロトコルを利用して実行することが可能である。このようなプロトコルの一例は、ＲＦＣ２３２６に規定されるＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）である。このプロトコルは、ＩＰを介するストリームの配信を制御するのに利用されるため、ＲＴＰなどの適切な配信プロトコルと結合して動作するよう設計され、マルチキャストシステムとの主要な相違点は、ストリームとの接続を所望する各クライアントについて、サーバはそれ自体とクライアントとの間のポイント・ツー・ポイント配信を開始するということである。明らかに、この解決手段はマルチキャストベースの解決手段より帯域幅を使用する。実際、この解決手段では、いくつかのレシーバに導くネットワークのルート部分を移動するデータパケットは、契約しているレシーバが存在するのと同程度の回数だけ複製される。この解決手段は、少数の端末のみがストリームに接続される可能性がある制限されたネットワークに関して検討することができる。

衛星やケーブルなどの他の送信キャリアを介しこのタイプのサービスをすでに提供している配信者により使用されるサービス生成チェーンになされる変更を制限しながら、ＩＰネットワークを介しＤＶＢサービスを配信するのに使用される帯域幅を制限するため、以下のようなサービスを構成するデータの構成を採用する。一方、いわゆるインストレーションストリームは、ＤＶＢ ＮＩＴから詳細に求められたネットワークに関する情報テーブルを含み、ＤＶＢ ＮＩＴと同一のシンタックスを有するが、特定の記述子を含むという意味において変更されたＮＩＴと呼ばれる当該テーブルのみが、ＩＰを介したＤＶＢサービスの配信に適合される。さらに、サービスはエレメンタリ音声、映像、サブタイトル及び他のサービスストリームを合成すると共に、ＰＡＴやＰＭＴなどの上記エレメンタリストリームを構成するのに利用される最小シグナリングをも合成するコンテンツストリームと、サービス記載情報のみを含む記述ストリームとに分離される。コンテンツストリームのみが、ＭＰＥＧ−２により規定されるようなトランスポートストリームフォーマットを維持する。インストレーション及び記述ストリームは、インストレーションストリームについてはＮＩＴなどのテーブルから、また記述ストリームについてはＳＤＴや他のテーブルから直接的に構成される。これらのテーブルは、ＭＰＥＧ−２セクションのシンタックスを利用する。実際、サービス記述情報へのアクセスは、音声及び映像コンテンツを復号する必要性とは関係のない１つ限りの要件である。ＩＰを介した現在の帯域幅と、ネットワーク上の帯域幅を制限する必要は、各サービスについてストリームが生成されることを可能にするが、１つのストリーム上へのいくつかのサービスの多重化が、本発明の範囲内において可能である。

ＩＰネットワーク上で利用するのにＮＩＴを採用するため、ＩＰネットワーク上にストリームを配備するのに適した記述子が、定義されねばならない。マルチキャストの仕様に適した記述子が、以下に与えられる。

“Ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇ”フィールドは、この新しいタイプの記述子に対応する識別子である。

“Ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈ”フィールドは、当該記述子の長さを与える。

“Ｃｏｎｔｅｎｔ＿ｍｕｌｔｉｃａｓｔ＿ａｄｄｒｅｓｓ”フィールドは、コンテンツストリームが利用可能なサーバのマルチキャストＩＰアドレスである。

“Ｃｏｎｔｅｎｔ＿ｍｕｌｔｉｃａｓｔ＿ｐｏｒｔ＿ｎｕｍｂｅｒ”フィールドは、レシーバがコンテンツストリームを受信するため接続しなければならないサーバのポート番号である。

“Ｃｏｎｔｅｎｔ＿ｍｕｌｔｉｃａｓｔ＿ｐｒｏｔｏｃｏｌ＿ｍａｐｐｉｎｇ”フィールドは、当該アドレスに配信される当該又は各サービスの符号化プロトコルを特定するフィールドである。このプロトコルは、ＭＰＥＧ−２、ＭＰＥＧ−４、ＭＨＰ等とすることが可能である。この任意的なフィールドは、レシーバが復号可能なサービスのみを維持するため、コンテンツタイプによりフィルタリングするのに利用可能である。

“Ｃｏｎｔｅｎｔ＿ｓｏｕｒｃｅ＿ａｄｄｒｅｓｓ”フィールドは、ＳＳＭプロトコルに従うマルチキャストサーバへの接続リクエストの効率的なルーティングを提供するサーバの実際のＩＰアドレスである。

記述子に関するループは、サービスに関する当該又は各記述ストリームの位置記述子を管理するのに使用され、そのコンテンツは、以前に規定されたアドレスに配信される。

ユニキャストの使用に適した記述子の他の例の定義は、以下のようなものである。

“Ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇ”フィールドは、この新しいタイプの記述子に対応する識別子である。

“Ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈ”フィールドは、当該記述子の長さを与える。

“Ｃｏｎｔｅｎｔ＿ｕｎｉｃａｓｔ＿ａｄｄｒｅｓｓ”フィールドは、コンテンツを搬送するストリームが利用可能なサーバのユニキャストＩＰアドレスである。

“Ｃｏｎｔｅｎｔ＿ｕｎｉｃａｓｔ＿ｐｏｒｔ＿ｎｕｍｂｅｒ”フィールドは、レシーバがコンテンツを搬送するストリームを受信するため接続する必要があるサーバのポート番号である。

“Ｃｏｎｔｅｎｔ＿ｕｎｉｃａｓｔ＿ｐｒｏｔｏｃｏｌ＿ｍａｐｐｉｎｇ”フィールドは、当該アドレスに配信される当該又は各サービスの符号化プロトコルを特定するフィールドである。このプロトコルは、ＭＰＥＧ−２、ＭＰＥＧ−４、ＭＨＰ等とすることが可能である。この任意的なフィールドは、レシーバが復号可能なサービスのみを維持するため、コンテンツタイプによりフィルタリングするのに利用可能である。

記述子に関するループは、サービスに関する当該又は各記述ストリームの位置記述子を管理するのに使用され、そのコンテンツは、以前に規定されたアドレスに配信される。

ＤＶＢ ＮＩＴと変更されたＮＩＴの構造において、トランスポートストリームに関するループが存在することを確認することができ、そのことは、配信者のネットワーク全体を構成するすべてのトランスポートストリームが当該ループに記述可能であるということを意味する。このように、レシーバはＩＰネットワークを介し配信されるブロードバンドテレビのすべてのトランスポートストリームのマルチキャスト又はユニキャストＩＰアドレスを有するリストを構成することが可能である。サービス記述子のリストは、レシーバインストレーション段階を迅速化するため、変更されたＮＩＴに任意的に含めることが可能である。

同じネットワークに存在するマルチキャスト及びユニキャストストリームサーバもまた、含めることが可能である。

他のより高度な実現形態では、送信されるサービスに関する情報記述ストリームの位置記述子は、例えば、以下の形式を採用することが可能である。

ここで、マルチキャストモードによりＩＰを介し配信されるストリームを位置決定する記述子の従来のフィールドが確認できる。“Ｆｉｌｔｅｒ＿ｌｅｎｇｔｈ”と“Ｆｉｌｔｅｒ＿ｄｅｓｃｒｉｐｔｏｒ”フィールドのみが、説明される必要がある。実際、本発明の例示された実施例に関して、サービス記述情報は、コンテンツ情報と分離され、１つの異なるストリームにより伝搬される。しかしながら、このシグナリング情報、すなわち、上記テーブルを複数のストリームにより伝送することが可能である。それは正確に、“Ｉｐ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒ”記述子がループを含むという可能性を考慮している。しかしながら、この記述子がスキャンされると、記述子のループ内の何れのストリームが、当該記述子により影響を受けるサービスについて求められる所与のテーブルを含んでいるか必ずしも知られている必要はない。当該記述子に“Ｆｉｌｔｅｒ＿ｌｅｎｇｔｈ”と“Ｆｉｌｔｅｒ＿ｄｅｓｃｒｉｐｔｏｒ”フィールドを導入することは、ループの各ストリームにどのテーブルが含まれるか確認するため、記述子情報に格納する手段を実現することを可能にする。この情報を符号化する１つの方法は、例えば、上記テーブルをフィルタリングするようデマルチプレクサをプログラムするのに使用されるビット列を、当該“Ｆｉｌｔｅｒ＿ｄｅｓｃｒｉｐｔｏｒ”フィールドに配置することが可能である。各テーブルタイプは与えられた識別子を有するため、当該フィルタは、ストリームに含まれるテーブルの識別子を表すビット列によりプログラムすることが可能である。ストリーム内にいくつかのテーブルを有することを可能にすることが所望される場合、デマルチプレクサのフィルタをプログラムするのに利用される当該方法が、採用可能である。第１ビット列はフィルタリング対象となる識別子を示し、同じ長さの第２ビット列は、第１ビット列の各ビットについて、当該値が規定されているか否か示す。このため、第２ビット列の対応するビットが一致する当該識別子の各ビットについて、第１ビット列の対応するビットが同じ値を有する場合、与えられた識別子がフィルタに対応することとなる。例えば、０ｂ１０１の値を有する第１ビット列と、０ｂ１１０の値を有する第２ビット列など、３ビットに関するビット列が考えられる場合、このフィルタに対応する識別子は、０ｂ１０１と０ｂ１００の値を有することとなる。この方法は、デマルチプレクサがそれらを抽出するようプログラムされるものと同様にして、ストリームに含まれるテーブルを規定するのに利用可能である。

他のよりシンプルな実現形態では、配信サービスに関する情報記述ストリームの位置記述子は、例えば、以下の形式をとることが可能である。

ここで、マルチキャストモードによりＩＰを介し配信されるストリームを配置するのに使用される記述子の従来のフィールドを確認することができる。“ＮｂＯｆＴａｂｌｅＤｓ”と“ＴａｂｌｅＩＤＬｉｓｔ”フィールドのみが、説明される必要がある。

“ＴａｂｌｅＩＤＬｉｓｔ”フィールドは、対応するストリームに含まれるテーブル識別子のリストに対応し、“ＮｂＯｆＴａｂｌｅＩＤｓ”フィールドは、リストされたテーブル識別子の個数を表す。従って、テーブル識別子が０ｘ４Ｅである現在ストリームの現在及び以降のイベントに関するシグナリング情報に関する情報と、テーブル識別子が０ｘ４Ｆであるその他のストリームの現在及び以降のイベントに関するシグナリング情報の両方を含むストリームが、“ＮｂＯｆＴａｂｌｅＤｓ”については２の値を、“ＴａｂｌｅＩＤＬｉｓｔ”フィールドについては０ｘ４Ｅと０ｘ４Ｆの値を有する記述子を有することとなる。

シグナリング情報を含むストリームの配信を実現する他の可能性は、マルチキャストプロトコルの代わりに、送信者とレシーバとの間のシンプルなファイル転送プロトコルを選択することであるかもしれない。このようなプロトコルは、例えば、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）とすることが可能である。このプロトコルは、特にサーバからファイルを取得するため、“ＧＥＴ”を実行可能な形態に限定される場合、実現するのがシンプルである。このプロトコルは、導入部にて説明されたＸＭＬファイル処理より管理するのがはるかにシンプルである。この場合、それを含むファイルのＵＲＬ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）である与えられた識別子テーブルについて、リンクするのに使用される以下の記述子などの他の記述子を有することが重要である。

しかしながら、この方法は、本発明の好適な実施例ではない。なぜなら、これらのシグナリングテーブルのユニキャスト送信と同様に、ＨＴＴＰによる配信は、インストールされることを所望する各レシーバについて、ネットワーク上のデータストリームの複製を伴うためである。しかしながら、それはドメスティックネットワークなどの多数のレシーバを有しないネットワークついて考慮することが可能な実施例である。

図１は、衛星配信に関するＭＰＥＧ−２ ＤＶＢサービス生成チェーンの一般的アーキテクチャを説明する。当該チェーンのスタートにおいて、配信される音声及び映像コンテンツ１．１が存在する。このコンテンツは、エレメンタリ音声／映像ストリーム１．５を生成するため、エンコーダ１．２においてＭＰＥＧ−２規格により符号化される。音声及び映像コンテンツの符号化とパラレルに、通常は、配信されるべきサービスを記述する情報を含むデータベースから得られるシグナリング情報１．３が生成される。この情報は、シグナリングストリーム１．６の形式により生成される。他のモジュール１．４は、サブタイトルストリーム１．７の生成を処理する。また、インタラクティブアプリケーションストリーム１．８を有することが可能であり、その生成チェーンについてはここでは詳細にされない。必要に応じて、他の音声及び映像コンテンツ、関連する又は他のシグナリングを搬送する他のストリームを有する上記すべてのエレメンタリストリームは、変調／変換装置１．１０により選ばれる周波数に変調及び変換されるＭＰＥＧ−２トランスポートストリームを生成するため、マルチプレクサ１．９において多重化される。このタイプのストリームセットは、送信ステーション１．１２を介した衛星１．１３への送信のため、ミキサ１．１１によりミキシングすることが可能である。この場合、シグナリング情報の同期処理が、各ストリームを記述するテーブルにその他のストリームに関する情報を含めるため、各種ストリーム間において必要となる。このとき、これらのプログラムは、セットトップボックスにより復号され、テレビ上に表示されるように、アンテナ１．１４を介しユーザの家で受信可能である。このシステムは、配信者の能力の範囲内で良好に機能する。

図２は、本発明の実施例による一例となるストリームアーキテクチャを表す。この例では、インストレーションストリームと呼ばれる第１ストリーム２．１が示される。このインストレーションストリームは、音声又は映像コンテンツではなく、ネットワークを情報を含む変更されたＮＩＴ２．４のみを有する。このインストレーションストリームは、ＭＰＥＧ−２セクションのシンタックスを直接利用することが可能であり、データはＩＰネットワークを介し直接送信されるという事実により、トランスポートストリームの形式によるカプセル化を特徴とする必要はない。

この変更されたＮＩＴは、各サービスを含むいくつかのストリームを記述する。図６において、ＤＶＢにより規定されるようなＮＩＴの標準的な構成が与えられる。送信手段に関係なく、ストリームはいくつかのＤＶＢサービスを含むことが可能であるが、１つのＤＶＢサービスのみ含むストリームのみが、帯域幅の理由のため、ＩＰを介した配信に関して初期的に使用される可能性がある。図２に示される例は、このケースを反映したものである。しかしながら、本発明がストリームに１つのＤＶＢサービスのみを含むストリームの使用に限定されるものではないということは明らかである。このため、変更されたＮＩＴ２．４には、３つのサービス２．５、２．６及び２．７の記述を有する。あるサービスの記述は、サービス２．３に関連する記述を含むストリームだけでなく、コンテンツストリーム２．２を位置決めする記述子２．８と２．９を含むであろう。コンテンツストリーム２．２は、ＰＭＴ（Ｐｒｏｇｒａｍ Ｍａｐ Ｔａｂｌｅ）から構成されるサービスに関するコンテンツを指定するＰＡＴ（Ｐｒｏｇｒａｍ Ａｓｓｏｃｉａｔｉｏｎ Ｔａｂｌｅ）を含むであろう。従って、記述ストリーム２．３は先行するものとは別のストリームである。このストリームは、ＭＰＥＧ−２トランスポートストリームのフォーマットではなく、ＭＰＥＧ−２セクションのシンタックスを有するテーブルを直接有する。この分離は、記述情報にアクセスする必要があるときに限って、クライアントが当該ストリームに接続することを可能にし、これにより、当該情報の持続的な送信のための帯域幅の使用を回避することが可能となる。従って、この帯域幅の使用が向上する。留意しなければならないのは、ＩＰを介した配信では、レシーバが配信からの契約を解除されると、当該レシーバへのネットワークを介したパケットの実際の送信が停止されるということである。この例では、記述ストリームは、電子番組ガイドが構成可能となるように、現在のイベント、次のイベント、及び必要に応じて完全なイベントカレンダーに関する情報など、イベント２．１４に関する情報を含む。それはまた、ＳＤＴ（Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｔａｂｌｅ）などのサービス２．１３に関する情報を含む。

図３は、本発明の実施例による他のストリームアーキテクチャの例である。この例は、図２に表されるような先のものと大変類似している。実際その相違は、このケースでは、イベントに関する記述情報とサービスに関する情報とが、２つのストリームにより搬送されるという点にある。従ってこのケースは、サービス１３．５について、コンテンツストリーム３．２、サービス情報ストリーム３．３及びイベント情報ストリーム３．１５を指定する先の２つのものの代わりに、３つのスクリーン記述子３．８、３．９及び３．１０を有する。従って、ネットワーク帯域幅を管理するための使用及び利用可能なテーブルに従って異なるストリーム上にシグナリング情報を構成する各テーブルを分割することが可能である。また、同じ更新頻度を有するテーブルをグループ化することによって、サービス管理制約を考慮することが可能である。

図４は、ネットワーク上に存在するサービスを認識する段階を説明するプレーヤーを示す図を表す。当該エンティティは、一方では、ユーザのレシーバを視聴するシステムのユーザ、レシーバ及びインストレーション、サービスコンテンツ及びサービス記述ストリームを表す。他のサービスに関する他のストリームは、ネットワークに存在するか、図面には示されていない。まず、ユーザはユーザのレシーバをオンする。その後、レシーバはインストレーションストリームと接続する。レシーバは、マルチキャスト又はユニキャストＩＰアドレスに初期的に接続することを可能にするパラメータを有する。最もシンプルな解決手段は、この配信ＩＰアドレスが設定メニューに手動により入力されることを仮定することである。この配信ＩＰアドレスはまた、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）又はＰＰＰ（Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）などのプロトコルを介し接続段階においてレシーバに割り当てられる。しかしながら、この第１ＩＰアドレスを決定する他の何れかの方法が可能である。このアドレスは、マルチキャスト又はユニキャストＩＰアドレス及び対応するポート番号から構成される。インストレーションストリームは、このアドレスに配信される。

レシーバがインストレーションストリームに接続されると、変更されたＮＩＴを復号し、それに含まれる情報を読む。従って、レシーバは、ネットワーク上で利用可能なサービスのリストを生成することが可能である。このリストをスキャンニングすることは、ネットワークを介し配信される記述ストリームとコンテンツストリームの配信アドレスへのアクセスを提供する。従って、当該レシーバは、各サービスの名称を含むサービスに関する情報を収集するため、これらのストリームに接続することが可能である。このことは、レシーバがサービスのリストをユーザに提供することが可能であるということを意味する。その後、ユーザは、視聴することを所望するサービスを選択肢、レシーバは選択されたサービスの変更されたＮＩＴにおいて確認されるコンテンツストリームの記述子を利用し、選択されたサービスのコンテンツストリームと接続する。その後、選択されたサービスの復号化及び表示を開始することが可能である。ユーザが現在のイベント又は次のイベントに関する情報にアクセスすることを所望する場合、ユーザは当該効果に対するリクエストを送信し、レシーバは再び変更されたＮＩＴに含まれる記述子を利用して、イベントに関する情報を含む記述ストリームのネットワーク上の位置を検出する。この情報は、図２及び３に説明されるような別のストリームに、又はサービス記述情報と同じストリームに含まれるようにしてもよい。その後、レシーバは、このストリームに接続詞、当該情報をユーザに表示することが可能になるように、イベントに関する情報を抽出する。

レシーバは、例えば、ＩＧＭＰを介しストリームに接続可能である。通常、このトランスポートストリームは、ＩＰ／ＵＤＰ／ＲＴＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ，Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）を利用したＩＰタイプを介しカプセル化されたＭＰＥＧ−２を有するが、それはまたＭＰＥＧ−４、ＭＨＰ又は他のタイプのストリームとすることができる。

図５は、本発明によるストリーム生成チェーンを表す。まず、生の音声及び映像コンテンツ５．１が、エレメンタリ音声及び映像ストリーム５．７を提供するため、エンコーダ５．４により符号化される。データベース５．２は、イベントに関する情報とサービスの全体的記述を含む。この情報によりシグナリングテーブル５．８を構成するため、モジュール５．５が使用される。シグナリング情報５．８、音声及び映像コンテンツストリーム５．７及びインタラクティブ又は他のアプリケーション５．６などの他の任意的情報が、コンテンツストリーム５．１０を構成するため多重化５．９される。第１フォーマティングモジュール５．１１は、必要に応じてデータベース５．２に含まれる情報及び他のサービス５．３に関する追加的情報から構成されるシグナリングテーブル５．８を利用して、記述ストリーム５．１２を構成する。第２フォーマティングモジュール５．１３は、ネットワークサービス５．３に関する追加的情報を利用して、アクセスを提供するアドレスによりネットワーク上で利用可能なすべてのストリームの記述を含むインストレーションストリーム５．１４を構成する。従来のＤＶＢサービス生成チェーンには存在しない主要なモジュールは、これらのフォーマティングモジュール５．１１及び５．１３である。しかしながら、これらのモジュールは、それらがシグナリングモジュール５．５によりすでに構成されたものなどのシグナリングテーブルを含むストリームを構成するため、構成することが簡単である。このストリームがマルチキャスト又はユニキャストモードにより送信されるか、又はＨＴＴＰなどのファイル転送プロトコルを介し利用可能であるかに関係なく、ＩＰネットワーク上のストリームを位置決めするのに適した記述子を使用することから生ずる新規性を得ることができる。いったん構成されると、これらのストリーム５．１０、５．１２及び５．１４は、ＩＰネットワークのサーバに送信可能である。

図７は、デジタル地上波デコーダなどの従来のデコーダのアーキテクチャを説明する。デコーダ７．１は、スクリーン７．３を有する。ユーザ７．２は、スクリーン７．３上に表示されるブラウザアプリケーション７．４を介しやりとりする。すべてのデコーダ機能は、ミドルウェア７．５と従来呼ばれる管理アプリケーションにより駆動される。この管理アプリケーションは、ハードウェアモジュール、すなわち、チューナー７．８、デマルチプレクサ７．７及びデコーダ７．６を駆動する。チューナーは、アンテナ７．９により受信されるＤＶＢストリームを受信するためのものである。このストリームはデマルチプレクサにより逆多重化され、言い換えると、デマルチプレクサは、音声、映像及び補助データ（サブタイトル、テレテキスト又はインタラクティブアプリケーションなど）又は特定のシグナリングテーブルなどのＤＶＢトランスポートストリームを構成する異なるエレメンタリストリームを再構成することが可能である。ＤＶＢストリームでは、各エレメンタリストリームは識別子により識別され、デマルチプレクサは、受信される完全なストリームから関心のあるエレメンタリストリームをフィルタリングするようプログラムすることができる。少なくとも音声及び映像ストリームが、それらが含む情報を圧縮及び／又は暗号化するよう符号化され、デコーダは音声及び映像コンテンツをユーザに復元するよう上記ストリームを解凍及び／又は解読する。

図８は、ＩＰネットワークを介しＤＶＢストリームを受信するよう構成されるＩＰデコーダを説明する。このアーキテクチャは、チューナーがＩＰネットワーク８．１１と接続されるネットワークインタフェース８．１０と置換されているという事実を除いて、従来のデコーダのケースと全く同じである。

図９は、ネットワーク上のサービスを認識する各ステップを詳述する。第１ステップは、インストレーションストリーム９．１を取得することから構成される。このストリームは、ネットワーク上で利用可能である。このストリームを利用可能にする方法は多数あり、そのうちの少なくとも３つが引用可能であり、当該ストリームはマルチキャストモードにより送信可能であり、またユニキャストモードにより送信可能であり、又はＨＴＴＰなどのファイル転送プロトコルを介し利用可能である。このインストレーションストリームがネットワークを介しどのように配信されるかに関係なく、デコーダはそれを抽出可能であることが必要であり、このため、アドレス及び当該ストリームと接続するための接続パラメータを知る必要がある。この第１アドレスは、装置のＲＯＭに備えることが可能であり、又はＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）又はＰＰＰ（Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）など、パラメータを取得可能にする接続プロトコルを介したネットワークを介しサーバ又はユーザにより装置と通信することが可能とされる。レシーバは、インストレーションストリーム９．２に接続され、その後それから変更されたＮＩＴ９．３を検索する。この変更されたＮＩＴが検出されると、この変更されたＮＩＴにおいて、それのトランスポートストリーム識別子（ＴＳＩＤ）及び元のネットワーク識別子（ＯＮＩＤ）９．４により特徴付けされる第１トランスポートストリームの記述を読み出す。その後、トランスポートストリームがいくつかのサービスを含むことが可能であるため、レシーバはトランスポートストリームに含まれるサービスの記述の読み出しを開始する。各サービスについて、レシーバは、サービス識別子とコンテンツストリーム９．５を特定するデータを読み出すことによって開始する。各サービスについて、当該サービスに関する情報は、複数のサービス記述ストリームに含めることが可能である。これら複数の記述ストリームの位置は、いま読み出された連続する記述子９．６及び９．７に規定される。その後、各サービスについて、トランスポートストリーム識別子、元のネットワーク識別子、サービス識別子、サービスのコンテンツ搬送するストリームの位置記述子（“Ｃｏｎｔｅｎｔ Ｓｔｒｅａｍ Ｌｏｃａｔｏｒ”を表すＣＳＬ）と共に、ＳＤＳＬ（Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｓｔｒｅａｍ Ｌｏｃａｔｏｒ）９．８のテーブルが格納される。これらの処理は、トランスポートストリームに含まれる各サービスと共に、各トランスポートストリーム９．９及び９．１０について繰り返される。このように、ネットワーク上で利用可能なすべてのサービスのリストが、コンテンツ及びコンテンツ記述情報の両方について配信するストリームの記述子と共に取得される。

図１０は、図９に説明されるような変更されたＮＩＴをスキャンすることによって、サービスのリストが構成されると、サービスに関する情報を復元することを可能にする方法の一例を詳述する。ネットワーク上で提供される各種サービスに関する情報を復元するため、レシーバは各サービスのＳＤＴ（Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｔａｂｌｅ）を検出しなければならない。これを行うため、それは第１サービス１０．１の記述子を読み出すことにより開始する。その後、それは第１のＳＤＳＬ（Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｓｔｒｅａｍ Ｌｏｃａｔｏｒ）を読み出す。その後、このＳＤＳＬが、指定されたストリームがＳＤＴを含むか否かに関する情報を提供する“Ｆｉｌｔｅｒ＿ｌｅｎｇｔｈ”と“Ｆｉｌｔｅｒ＿ｄｅｓｃｒｉｐｔｏｒ”フィールドを含まない場合、それはストリーム１０．９に接続し、テーブル識別子が０ｘ４２となるＳＤＴの検索において、当該ストリームからセクション１０．１０、１０．１１及び１０．１２を読み出す。“Ｆｉｌｔｅｒ＿ｌｅｎｇｔｈ”及び“Ｆｉｌｔｅｒ＿ｄｅｓｃｒｉｐｔｏｒ”フィールドが存在する場合、これらの情報アイテムを利用して、ストリーム１０．３にＳＤＴが存在するかチェックする。存在しない場合、それは次の記述子１０．１３をテスト１０．１４し、ＳＤＴを検出することができないサービスをリストから削除することによって終了１０．１５する。それがＳＤＴを含むストリームを検出すると、このテーブル１０．５を読み出し、その中からサービス及びサービスプロバイダの名称を検出し、メモリ１０．６に格納する。この処理が、サービス１０．１６のリストの終わりまですべてのサービス１０．７に対して繰り返される。

本発明は、配信者、特にマルチプレクサが既存の生成チェーンの大部分を再利用することを可能にする。必要とされる唯一の開発は、シグナリングテーブルのみ、そのすべて又は一部を含むストリームを構成し、必要に応じて、それらをトランスポートストリームにカプセル化しないフォーマティングモジュールに関するものである。この開発は最小限のものである。本発明はまた、デコーダ上で実行されるソフトウェアになされる変更を限定する。実際、衛星又はケーブル受信インタフェースの代わりに、ＩＰインタフェースを管理する部分が主として追加される必要があり、インストレーションを管理するアプリケーションの部分はわずかしか変更される必要はない。当該装置の残りの動作のすべては、標準的なデコーダについてのものと同一である。同様に、アクセス制御が同じように再利用可能である。従って、本発明は、ネットワーク上の利用可能な帯域幅の使用及び配信者の投資及びリスクを最小限にしながら、ブロードバンドＩＰネットワークを介したＤＶＢサービスの配信を採用することを可能にする。

図１は、従来の衛星配信に関するＤＶＢサービス生成チェーンの図を表す。 図２は、本発明の一実施例に関するＤＶＢデータストリームアーキテクチャの一例を表す。 図３は、本発明の一実施例に関するＤＶＢデータストリームアーキテクチャの一例を表す。 図４は、本発明の一実施例に関するレシーバの動作を表す。 図５は、本発明の一実施例に関するＤＶＢサービス生成チェーンの図を表す。 図６は、ＤＶＢ規格によるＮＩＴ（Ｎｅｔｗｏｒｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）の構成を表す。 図７は、地上波受信の場合などの標準的デジタルデコーダの構成を表す。 図８は、ＩＰを介した受信に適したデジタルデコーダの構成を表す。 図９は、サービス認識段階のフロー図を表す。 図１０は、サービス情報読み出し段階のフロー図を表す。

Claims (10)

1. 双方向ネットワークに接続されるレシーバによって、前記双方向ネットワーク上のデジタルサービスを認識する方法であって、
   前記レシーバが、第１ストリームと接続するステップと、
   前記レシーバが、一方では前記サービスのコンテンツを搬送するストリームと、他方では前記サービスを記述する情報を搬送する別のストリームの前記ネットワーク上の位置に関する情報を前記ストリームから抽出するステップと、
   前記レシーバが、前記サービスに関する情報を取得するため、前記サービス記述情報を搬送する前記ストリームの少なくとも一部と接続するステップと、
   前記レシーバは、当該情報を利用して前記ネットワーク上で利用可能なサービスのおそらく単一のリストを構成するステップと、
   から少なくとも構成されることを特徴とする方法。
2. 請求項１記載の方法であって、
   サービスに関するすべてのシグナリングテーブルは、前記サービスのコンテンツを搬送するストリーム以外の少なくとも１つのストリームに含まれることを特徴とする方法。
3. 請求項２記載の方法であって、さらに、
   識別子を有するテーブルが前記ストリームにおいて利用可能であるか判断するのに利用されるストリームの記述子に含まれるフィルタと前記識別子との間のマッピングをテストするステップを有することを特徴とする方法。
4. 請求項１乃至３何れか一項記載の方法であって、
   第１配信ＩＰアドレスと第１ポート番号が、ユーザにより入力されることを特徴とする方法。
5. 請求項１乃至３何れか一項記載の方法であって、
   第１ＩＰアドレスと第１ポート番号が、前記レシーバにより前記ネットワークから取得されることを特徴とする方法。
6. 請求項１乃至５何れか一項記載の方法であって、
   前記ストリームは、１つのＤＶＢサービスのみ含むことを特徴とする方法。
7. 請求項１乃至６何れか一項記載の方法であって、
   前記サービスのリストは、第１ポートの第１配信ＩＰアドレスにおいて利用可能なストリームに含まれるＮＩＴに含まれることを特徴とする方法。
8. ＩＰネットワークと接続する手段を介し配信ＩＰアドレスと接続する手段と、前記配信ＩＰアドレスに配信されるＤＶＢストリームを復号する手段とを有する装置であって、
   前記ＤＶＢストリームを復号する手段は、前記ＩＰネットワークに適したネットワーク記述子を有し、前記ストリームから抽出されるＮＩＴを解析し、前記ＮＩＴに記述される各配信ＩＰアドレスと接続し、好ましくは、請求項１乃至７記載の方法の何れかに従って、その中のＤＶＢストリームを読み出し、それから前記ネットワーク上で提供されるサービスに関する情報を抽出することが可能であることを特徴とする装置。
9. ＮＩＴに含めるため、ＤＶＢストリームを配信するサービスの記述子であって、
   ストリームサーバの配信ＩＰアドレスと、前記サーバがＩＰタイプネットワークを介しサービスのコンテンツを搬送するＤＶＢストリームを配信するポート番号とを有し、
   少なくとも１つの記述子は、ストリームサーバの配信ＩＰアドレスと、前記サーバが、該サーバに関するシグナリング情報を搬送するＤＶＢストリームを配信するポート番号とを有することを特徴とする記述子。
10. 請求項９記載の記述子であって、
    ストリームサーバの配信ＩＰアドレスと、該サーバが前記サーバに関するシグナリング情報を搬送するＤＶＢストリームを配信するポート番号とを有することを前記１以上の記述子は、識別子とフィルタとの間のマッピングをテストする手段を有することを特徴とする記述子。

Images