データレコードのセグメント更新方法及びその装置
【課題】異なるバージョンを有するデータパケットの受信が時間的に重複するセグメントの異なるバージョン間での前後への変化が、結果として回避されるようにする。
【解決手段】バージョン番号の現行値に基づき、バージョン番号の値の範囲を範囲「古い」及び「新しい」に分割する。値の範囲が進む周期性が考慮され、範囲「古い」又は「新しい」は、値の範囲内の最高値から最低値へジャンプして良い。新たな受信データレコードのバージョン番号が、範囲「新しい」にある場合、新しいデータレコードは、現行データレコードとして受け付けられ、そうでない場合は拒否される。
【解決手段】バージョン番号の現行値に基づき、バージョン番号の値の範囲を範囲「古い」及び「新しい」に分割する。値の範囲が進む周期性が考慮され、範囲「古い」又は「新しい」は、値の範囲内の最高値から最低値へジャンプして良い。新たな受信データレコードのバージョン番号が、範囲「新しい」にある場合、新しいデータレコードは、現行データレコードとして受け付けられ、そうでない場合は拒否される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチメディアサービスに関する。本発明は、例えば音声又はビデオ放送又はソフトウェア更新のための追加情報の項目のような、データ記録の更新の技術分野に関する。特に、本発明の技術分野は、例えばビデオ又は音声コンテンツのインターネットを介した伝送のような、ビデオコンテンツを、放送システムを介して伝送する分野に関連する。
【背景技術】
【０００２】
インターネットテレビ又はビデオオンデマンドのようなインターネット上でのビデオコンテンツの伝送では、知られているＤＶＢシステム（デジタルビデオブロードキャスト）との関連で、このようなデジタルビデオコンテンツがインターネットを介して伝送され得る伝送プロトコルを定める規格が作成された。規格は、策定中のＤＶＢ−ＩＰＩ（デジタル・ビデオ・ブロードキャスト・インターネット・プロトコル・インフラストラクチャー）で知られている。この規格は、とりわけ、ＸＭＬ文書形式の音声／ビデオデータストリーム（ＡＶストリームとも称される）の記述及び選択に関する情報の符号化を記載している。規格では、この情報はまた、「サービス・ディスカバリー・アンド・セレクション」情報と表される（ＳＤ＆Ｓに対応する）。ＤＶＢ−ＩＰＩ規格の正確な意味は、非特許文献１に記載されている。
【０００３】
ＳＤ＆Ｓデータは、サービスプロバイダー自身に関する情報及びサービスプロバイダーの種々のサービス提供に関する情報（生放送、オンデマンドコンテンツ、トリックモードを有するＡＶストリーミング）を有する。この場合、データは次の様に構成される。つまり、ＳＤ＆Ｓデータの型は、所謂ペイロードＩＤにより示される。サービスプロバイダーのペイロードＩＤに属するデータは、所謂ＳＤ＆Ｓデータレコードと表される。ＳＤ＆Ｓデータレコードは、標準的に、可能な変化の影響を可能な限り少ないセグメントに限定するために、所謂ＳＤ＆Ｓセグメントと称される複数の独立セグメントに分割される。しかしながら、データレコードはまた、単一のセグメントを有して良い。サービスプロバイダーの各ＳＤ＆Ｓセグメントは、ペイロードＩＤ及びセグメントＩＤの組により識別される。セグメントの変化を伝達可能にするため、各セグメントは、追加で、バージョン番号、所謂セグメントバージョン番号を有する。セグメントのデータが変化した場合、変化を示すため及びこの特定のバージョンの検索を可能にするため、セグメントのバージョン番号がインクリメントされなければならない。ＤＶＢ−ＩＰＩ規格では、ＳＤ＆Ｓデータの伝送のために、２つの異なる伝送モードが記載されている。所謂「プルモード」としても参照されるＨＴＴＰ（ハイパーテキスト転送プロトコル）によるＳＤ＆Ｓデータの検索に加え、ＤＶＢ−ＩＰＩは、伝送プロトコルＤＶＢ−ＳＴＰを定める。ＤＶＢ−ＳＴＰにより、サービスプロバイダーのＳＤ＆Ｓサーバーのデータは、ＵＤＰ（マルチキャスト）により全ての対象の受信機へ周期的に送信される。このモードは、「プッシュモード」と表される。ＵＤＰは、インターネット技術で知られている「ユーザー・データグラム・プロトコル」に対応する。記載されるべき発明は、原則として「プッシュモード」で利用される。このモードでは、ＳＤ＆Ｓセグメントは、所謂ＳＤ＆Ｓセクションに任意的に更に細分化され、そしてＤＶＢ−ＳＴＰヘッダーを設けられる。このようなセクションは、マルチキャストによりＵＤＰパケットとして周期的に送出される。
【０００４】
ＩＰマルチキャストアドレスから自動的に導出された又は明示的に指定されたサービスプロバイダーＩＤ、ペイロードＩＤ、セグメントＩＤ及びセグメントバージョン番号に基づき、受信機は、個々のセクションからセグメントを再び結合し、そして、例えば電子番組表を表示可能にするため、含まれているＳＤ＆Ｓデータを処理する。受信機は、変化したセグメントバージョン番号からセグメントの変化を識別し、そしてその結果、古いデータを新しいデータで置き換え得る。しかしながら、どのデータが古いデータであり、どれが新しいかに関する決定は、ＵＤＰによる伝送の信頼性が低いという理由で、当初に考えられたほど自明ではない。
【非特許文献１】トランスポート・オブ・ディー・ブイ・ビー・サービス・オーバー・アイ・ピー（Ｔｒａｎｓｐｏｒｔ ｏｆ ＤＶＢ Ｓｅｒｖｉｃｅｓ ｏｖｅｒ ＩＰ）、ディー・ブイ・ビー・ドキュメントＡ０８６（ＤＶＢ Ｄｏｃｕｍｅｎｔ Ａ０８６）、（発行国）、デジタル・ビデオ・ブロードキャスティング（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ （ＤＶＢ））、２００４年７月
【発明の開示】
【発明が解決しようとする課題】
【０００５】
規格は、セグメントが変更された場合、セグメントバージョン番号をインクリメントすることを定めているが、「新しいセグメントバージョン番号＝古いセグメントバージョン番号＋１」の形式で最新の検証を簡易に実施する場合、以下の問題が存在する。信頼性の低いＵＤＰ伝送によると、ＤＶＢ−ＳＴＰパケットは、何時でも損失し得る。従って、急激な連続したセグメント変化が生じる場合、中程度の範囲のセグメントバージョン番号を有するＤＶＢ−ＳＴＰパケットは、決して受信機に到達しない。しかしながら、これは、最近のデータはもはや厳格なインクリメントルールに従わないので、最近のデータもまた無視されることを意味する。第二に、規格は、ＤＶＢ−ＳＴＰ送信機が少なくとも１つのＤＶＢ−ＳＴＰパケットをセグメントバージョン毎に実際に送信しなければならないことを明示的に定めない。急激な連続したセグメント変化が生じた場合に、考えられることは、従って、最初の刷新の対応するＤＶＢ−ＳＴＰパケットが実際に送信される前に、直ぐに新しいバージョンにより置き換えられるべきＤＶＢ−ＳＴＰ送信機の新しいセグメントバージョンに対し、受信ＤＶＢ−ＳＴＰパケットのセグメントバージョン番号内のジャンプは、受信機と同様に生じ得ることである。そして、データパケットは、厳格なインクリメントルールに従い、検証中に無視され得る。
【０００６】
「新しいセグメントバージョン番号が古いセグメントバージョン番号と等しくない」又は「新しいセグメントバージョン番号＞古いセグメントバージョン番号である」の形式の考え得る最新の検証はまた、問題を有する。ルールと等しくないことは簡単に実施されるが、現行と考えられるＳＤ＆Ｓセグメントのバージョンの安定性に関する重大な不利点を有する。これは、低信頼性のＵＤＰ伝送がＤＶＢ−ＳＴＰパケットが送信機から送出された時と同一の順序で受信機に到着することを保証しないためである。これは、セグメント変化が生じた場合、より新しいセグメントバージョンを有するＤＶＢ−ＳＴＰパケットが、より古いバージョンを有するパケットに、伝送経路上で追いつくという影響を有し得る。ルールと等しくないアプリケーションでは、この場合の古いバージョンから起こった受信機は、最初に新しいセグメントバージョンを検討し、そして次に再度、現行となるべき古いセグメントバージョンを検討する。新しいセグメントバージョンの繰り返し伝送が受信された場合のみ、受信機は前記新しいセグメントバージョンを現行として識別する。これは、個々のＳＤ＆Ｓセグメントが所定の時間内にリフレッシュされない場合、特定の時間間隔で且つセグメントは無効であると見なされなければならないと定める規格の範囲内で、何度も繰り返されるからである。不規則に受信されたＤＶＢ−ＳＴＰパケット数により、現行のセグメントバージョンはまた、更に頻繁に変更して良い。結果として生じる望ましくないセグメントの「前後への切り替え」は、実際には現行であるセグメントの受け取りを不必要に遅延させ得る。これは、最初の受信が既に受け取られている場合でも、受け入れられる新しいセグメントバージョンの第ｎ番目の受信だけが可能であるからである。
【０００７】
望ましくない影響は、ユーザーには明らかであり、場合によってユーザーを混乱する。例として、ＳＤ＆Ｓデータから生成される電子番組表は、チャネル内の番組変更が生じた場合、場合によって、前の放送及び現行の放送の表示の間で前後に変更する。
【課題を解決するための手段】
【０００８】
本発明は、以下の方法でこの問題を解決する。
【０００９】
セグメントが変化した場合の最新検査では、比較と等しくない又は厳格なインクリメントルールの代わりに、「新しいセグメントバージョン番号＞古いセグメントバージョン番号」の形式である、同時にバージョン番号のインクリメント時のモジュロ動作を考慮するルールが実行されるべきである。例として、８ビット値は、ＤＶＢ−ＩＰＩ規格のセグメントバージョン番号のために提供される。バージョン番号の値の範囲は、従って、０乃至２５５の範囲に対応する。この範囲の最後の値に到達した場合、更なるインクリメントが行われ、そして値の範囲は、再び始めから新しく繰り返される。その結果として、比較より大きい数は、セグメントバージョン番号に適用され得ない。むしろ、本発明は、現行と考えられるバージョン番号から続けて、バージョン番号の値の範囲を「古い」及び「新しい」範囲に分類することを提案する。この場合、２つの範囲の１つは、値２５５から値０への「桁あふれ」を有して良い。２つの範囲は、この場合、現行のバージョン番号から同様にシフトされる。範囲は、異なる大きさを有するよう選択され得る。「古い」範囲が大きいほど、実際に廃止されたセグメントバージョンが現行として受け取られる可能性は低い。他方、「古い」範囲が拡大されると、伝送路の比較的長い障害及び多数のセグメント変化が生じた場合、又は関連するＤＶＢ−ＳＴＰパケットを送信せずに送信端で頻繁にセグメント変化が実行された場合、実際に現行のセグメントバージョンが廃止されたとして無視される可能性は増大する。これらの理由から、２つの範囲の何れもセグメントバージョン番号の値の範囲の大部分を網羅しないことは、有利である。
【００１０】
本発明の利点は、場合によって廃止されたバージョンのセグメントが無視されることである。また本発明の利点は、異なるバージョンを有するデータパケットの受信が時間的に重複するセグメントの異なるバージョン間での前後への変化が、結果として回避されることである。本発明を実施する際の追加費用は、比較的低い。現行セグメントのバージョン番号が「古い」範囲内から来るのを完全に防ぐことができないが、特に非常に頻繁な変化、又はセグメントバージョン番号に大きなジャンプが生じる場合、この場合は、滅多に生じない。更に、ＤＶＢ−ＩＰＩの場合、セグメントをリフレッシュする規定は、不正に現行であると見なされたセグメントバージョンが、標準的には６０秒後に任意のバージョン番号を有する新しく受信されたバージョンと再び入れ替えられることを保証する。
【００１１】
更なる向上及び発展は、特許請求の範囲に示された手段を利用することにより可能である。また、変化したバージョン番号により明示的に伝達されないセグメントの変化を解明可能にするために、新しく受信されたセグメントの更なるデータが、現行と考えられるセグメントのデータと更に比較される場合に、新しく受信されたセグメントのバージョン番号が現行セグメントのバージョン番号と一致する場合、本発明は有利である。受信セグメントは、比較データが一致した場合のみ、現行と考えられるセグメントの有効なリフレッシュとして受け付けられる。従って、例として、ＤＶＢ−ＩＰＩシステムの場合、ＤＶＢ−ＳＴＰヘッダー内の全ての他の表示及びデータパケット内の実際のペイロードデータは、事前に受信されたデータと比較されて良い。これは、ＳＤ＆Ｓデータレコードを異なる方法でＤＶＢ−ＳＴＰパケット内で送信することを可能にする。ＣＲＣ検査符号を用いた誤り保護は、従って、セグメントデータに対し任意である。セクションへの細分化は、同様に種々の方法で実行されて良い。更に、ＤＶＢ−ＳＴＰヘッダー内のエントリーはまた、圧縮の利用及び現時点では詳細に指定されていない暗号化方法を指定可能な方法を利用し、表される。規格は、これら送信パラメータの変化が、変化したセグメントバージョン番号により同様に伝達されることを要求しないので、受信機は、同一のセグメントバージョン番号を有する別個に符号化されたＤＶＢ−ＳＴＰパケットを受信することができ、及びこれら可能な互換性のないパケットから誤りのある出力結果のみを生じるＳＤ＆Ｓセグメントを不正に組み立てる可能性がある。これは、記載された手段により防止される。
【００１２】
更に、現行と考えられるセグメントと一致しない内容を有し、及び同一バージョン番号を有するＤＶＢ−ＳＴＰパケットは、異なる方法で扱われ得る。第一に、これらのパケットは、単に無視され得る。ＤＶＢ−ＩＰＩ規格の場合、これは、送信機により場合によって故意に変化されたセグメントデータが、リフレッシュがないために現行と見なされたセグメントが拒否された後まで、受け入れられないという影響を有する。なぜなら、不一致パケットは、現行セグメントのリフレッシュとして取り扱われるべきでないからである。しかしながら、手順は、最大６０秒を要する。他方、これらのパケットは、現行と見なされたセグメントの新しいバージョンと関連付けられると考えられる。この場合、現行と見なされたセグメントは、直ちに拒否される。そして新たに受信されたデータを有するセグメントが構築される。しかしながら、同一のセグメントバージョン番号のため、最新の検証はもはや可能ではないので、現行と見なされたセグメントの内容は、セグメントの両方のバージョンと関連したＤＶＢ−ＳＴＰパケットが依然として受信されている限り、前後に繰り返しジャンプする。不一致パケットが無視されるか又は直接受け取られるかに関する決定は、例えば、ＳＤ＆Ｓデータの安定性又は最新性のどちらが受信機にとってより重要であるかに従い、受信機内に設定可能な方法で設計され得る。更に、この設定は、受信した不一致ＤＶＢ−ＳＴＰパケットの数に動的に適応することが可能である。
【００１３】
「古い」及び「新しい」範囲への動的な範囲の分類はまた、有利である。特に、セグメントの観察された変化頻度が、動的範囲分類を実行するために用いられる場合、本発明による方法の更なる向上が可能である。伝送路における知られている又は推測された伝搬時間の差を変化頻度の解明のために用いることはまた、動的範囲分類に有利である。本発明による方法を実施する本発明による装置は、請求項１３乃至１６に記載されている。
【００１４】
例として、本発明の実施例が図示され、以下に詳細に説明される。
【発明を実施するための最良の形態】
【００１５】
図１は、イーサネット（登録商標）技術に基づくホームネットワークを示す。図１では、種々のホームネットワーク装置が、イーサネット（登録商標）ケーブルによりＤＳＬルーター１０と接続されている。この場合、参照符号１１は、デジタルビデオデータのデコーダーを有するＴＶセットのような、デジタルＴＶセットを示す。参照符号１２は、デジタルビデオレコーダーを示す。そして、参照符号１３は、パーソナルコンピューターを示す。参照符号１４は、携帯用パーソナルコンピューター、例えばラップトップ又はノートブックコンピューターを示す。後者は、ＤＳＬルーター１０と無線で接続される。この目的のために、ＩＥＥＥ８０２．１１ｘ規格の１つに対応する慣例の無線イーサネット（登録商標）接続技術の１つが利用されて良い。ＤＳＬルーター１０は、電話接続を介してインターネット１５と接続される。同様に図は、サービスプロバイダー１６がＤＳＬルーター１０によりインターネット１５を介して選択され得ることを示す。インターネット１５からは、デジタルビデオコンテンツが、インターネットＴＶサービス又はビデオオンデマンドサービスの何れかの形式で要求され得る。
【００１６】
図２は、インターネットへの接続の別の可能性を示す。この図では、参照符号１８は、ＴＶセットを示す。ＴＶセットは、ビデオデコーダー１７と接続される。ビデオデコーダー１７はまた、ＩＰセットトップボックスとして示される。前記ビデオデコーダー１７は、電話接続に直接接続され、つまり、統合されたＤＳＬモデムを有する。更に、図は、同様に、接続が確立され得るサービスプロバイダー１６を示す。これらの例である実施例では、ＤＶＢ−ＩＰＩ規格は、インターネットを介したビデオコンテンツの伝送のために用いられる。言い換えると、ＤＳＬルーター１０及びデジタルビデオデコーダー１７は、両方とも、ＤＶＢ−ＩＰＩ規格に記載されたプロトコルを実装していなければならない。
【００１７】
図３に示されるプロトコルは、本発明に全て関連しないので、従って詳細に説明されない。これらプロトコルに関するより詳細な情報は、慣例的文献又は関連する規格を参照のこと。前述のように、ＳＤ＆Ｓプロトコルは、サービス加入者に、利用可能になったサービスに関する必要な情報及びそのサービスで提供されるコンテンツを利用可能にするよう機能する。この場合、「サービス・ディスカバリー」は、加入者にインターネットでＤＶＢサービスを発見させる機構である。この機構は、結果として、ユーザーに伝達されているサービス提供のリストを生じる。従って、ユーザーは、ユーザーが利用したいどのサービスを選択するかの可能性を有する。選択自体は、後で行われ、ＳＤ＆Ｓ機構に関連した選択サービスに関連する。
【００１８】
加入者にＳＤ＆Ｓ情報を届けるために利用可能にされる伝送モードは、２つある。ＤＶＢ−ＩＰＩ規格では、１つの伝送モードは、「プッシュモード」、及び他方は「プルモード」として表される。「プルモード」では、ＳＤ＆Ｓデータは、ＨＴＴＰプロトコルを利用して受信機へ送信される。ＨＴＴＰ（ハイパーテキスト転送プロトコル）の場合、受信局が所望のデータを要求する（ＨＴＴＰ−Ｇｅｔ）か、又は自身の部分の送信局が、ＨＴＴＰ−Ｐｏｓｔを利用し加入者局にデータを利用可能にする。図３に示されるように、ＨＴＴＰプロトコルは、ＴＣＰプロトコル（通信制御プロトコルに対応する）の上に配置される。知られているように、ＴＣＰプロトコルは、保護された送信プロトコルである。ＴＣＰプロトコルでは、個々の送信されたデータパケットは、受信端で確認されなければならない。従って、送信端は、受信確認が示されない場合、失敗したパケットを再送する。
【００１９】
ＳＤ＆Ｓ情報の送信の第二の可能性は、同様に図３に示される。図３は、サービス情報をマルチキャストにより複数の加入者へ同時に送出するために利用される、所謂「プッシュモード」を有する。ＤＶＢ−ＳＴＰプロトコルは、この目的のために利用される。ＤＶＢ−ＳＴＰプロトコルは、ＳＤ＆Ｓ情報を通信する特別なトランスポート・プロトコルを有する。
【００２０】
ＳＤ＆Ｓ情報は、ＸＭＬ文書にコンパイルされる。これらは、基本的にテキストデータ、つまり文字コードを有する。サービスプロバイダーに特有の種類の全ての番組情報は、ＳＤ＆Ｓデータレコード内に格納されて良い。従って、サービスプロバイダーが複数のテレビジョン番組を提供する場合、この複数の番組の全ての番組情報は、従って、このデータレコードのＸＭＬ文書内に格納され得る。従って、文書は、数キロバイト又は数１０キロバイトのかなりの大きさに達し得る。番組情報は最近の動向に対応しなければならないので、ＤＶＢ−ＩＰＩ規格は、それぞれデータレコードの部分を有する独立のＸＭＬ文書である複数のセグメントに細分化されたデータレコードの送信を許可する。これは、番組プロバイダーにより番組変更が生じた場合、データレコードの全データを有する１つの文書が再び送信される必要がなく、むしろ番組変更が、適切な場合、データレコードの１つのセグメントのみに影響する状況を許容する。
【００２１】
図４は、ＳＤ＆Ｓデータレコードの細分化を示す。ＤＶＢ−ＩＰＩ規格は、種々の種類のＸＭＬ文書を許可する。これらは、所謂ペイロードＩＤにより識別される。「サービスプロバイダー発見」情報、「ブロードキャスト発見」情報、「コンテントオンデマンド発見」情報、「他のサービスプロバイダーからのサービス」に関する情報、「パッケージ発見」情報、及び「ユーザープライベート」情報がある。
【００２２】
データレコードは、複数のセグメントに分類され得る。複数のセグメントの部分は、セグメントＩＤ及びバージョン番号により識別される。バージョン番号は、規格では８ビット値として定められる。新しいセグメントバージョンがサービスプロバイダーにより提供される度に、前記セグメントのバージョン番号は、インクリメントされる。バージョン番号が８ビットの数として設計されるので、セグメントバージョンの値の範囲は、０乃至２５５に定められる。最も高い値２５５に到達した場合、更にインクリメントが実施され、そして値の範囲は、再び０から２５５まで通して進む。更に、個々のセグメントを所謂セクションに更に細分化することが許可される。これは、図４に同様に示される。この目的のため、それぞれのセクション番号は、セクションに割り当てられる。関連するセグメントの最も生じ易いセクション番号は、更に指定される。このように細かく分割されたセグメントのＸＭＬ文書は、ＵＤＰプロトコルに従い部分的に送信される。それぞれの場合で、ＵＤＰデータパケットは、セクションのデータを有する。
【００２３】
図５は、関連するＵＤＰデータパケットのフォーマットを示す。このパケットの個々のフィールドは、ＤＶＢ−ＩＰＩ規格で定められる。示されるように、２番目の４バイト分のデータは、ペイロードＩＤ、セグメントＩＤ及びセグメントバージョン番号を有する。ペイロードＩＤ及びセグメントバージョン番号は、８ビットの数である。セグメントＩＤは、１６ビットの数である。このようなデータパケット内には、以下により詳細に議論される任意フィールドもある。
【００２４】
説明されたように、ＵＤＰプロトコルは、セクション内のセグメントの送信に利用される。しかしながら、知られているように、ＵＤＰプロトコルは、如何なる受信確認メッセージも提供されない信頼性の低い伝送プロトコルである。これらＵＤＰパケットをインターネットを介して送信する間、全パケットが失われる、早い時期に送信されたパケットが後に送信されたパケットより実際には遅く受信機に到着する、等が起こり得る。混乱は、特に、伝送路に無線伝送がある場合、一時的に生じ得る。従って、全セグメント又は全ＳＤ＆Ｓデータレコードも、比較的長時間では失われ得る。
【００２５】
図６は、問題をより詳細に示す。送信端におけるＳＤ＆Ｓデータレコードのセグメントのブロードキャストは、上部の時間軸に示される。数字の表記は、それぞれの場合に、セグメントバージョン番号に関連する。ブロードキャストセグメントが受信機に到達した瞬間は、図の下部に示される。ＤＶＢ−ＩＰＩ規格は、種々のセグメントを周期的にリフレッシュさせる。全体に、３０秒の最大時間期間は、ＳＤ＆Ｓ情報の送信を超えてはならない。情報は、継続的に繰り返されないので、それぞれの場合に３０秒後にリフレッシュがある。「プッシュモード」で６０秒以内に如何なるリフレッシュも到着しない場合、個々の受信機は、関連するセグメントが削除されたと見なす。それらは、次に、廃止されたセグメントを削除しなければならない。その結果、続いて受信された、任意のセグメントバージョン番号を有するセグメントは、現行と考えられる。図６では、バージョン番号４８を有するセグメントは、それぞれの場合、最初の３個のブロードキャストで送信される。図の下部は、関連するセグメントが受信機に到着した時を示す。バージョン番号４８を有するセグメントの３番目のブロードキャストは、示されるように大幅に遅れる。特に、バージョン番号５６を有するセグメントは、その間に受信機に連続して２回到着している。バージョン番号４９乃至５５を有する全ての他のセグメントがブロードキャストされたが、それらは、伝送路で失われた。従って、受信機が、バージョン番号４８を有する到着したセグメントを新しいとして受け付けるか、又は事前に到着したバージョン番号５６を有するセグメントのままにするかを決定することは、困難である。単に比較と等しくないことは、バージョン番号４８を有するセグメントを受け付ける結果になる。単に比較より大きいことは、バージョン番号４８を有するセグメントを無視する結果になる。バージョン番号５６を有するセグメントは、続いて再び受信されるので、このセグメントに関して、前後へのジャンプが起こり得る。
【００２６】
続いて図６は、セグメントバージョン番号７８を有するセグメントが送信及び受信されたことを示す。間に置かれた番号５７乃至７７を有するセグメントは、サービスプロバイダーによってもブロードキャストされない。第一の理由として、それらのセグメントは、ブロードキャストされないような短時間の間に連続した変化として生じるからである。同じ状況は、バージョン番号７８の後にバージョン番号２５５が続く場合に説明される。セグメントバージョン番号２５５から開始値０への切り替えはまた、示された区間の端に示される。受信機がどのセグメントをより現行であると見なすべきかに関する受信機の決定は、単に比較より大きいことによると、困難になる。
【００２７】
起こり得る「バージョンのピンポン」を有する以上の問題を回避するため、本発明は、バージョン番号表示の値の範囲の範囲分類に基づき、比較より大きい又は比較より小さい実行を提供する。
【００２８】
図７は、関連する範囲分類を説明する。バージョン番号表示の値の範囲０乃至２５５は、図７ａの場合に示される。これは、図６による、現在受信されたセグメントバージョン番号が値５６に関連する場合を考慮している。この現行の値に基づき、値の範囲は、２つの範囲「古い」及び「新しい」に分類される。この場合、範囲「新しい」は、現行のバージョン番号表示＋１の値から、現行のバージョン番号表示＋１２７の値までの範囲に対応する。範囲「新しい」は、従って５７乃至１８３に亘る。範囲「古い」は、反対に、現行のバージョン番号表示−１から現行のバージョン番号表示−１２８の範囲に関連する。従って、２つに分割される。２つの範囲「古い」及び「新しい」は、殆ど等しい大きさである。この範囲分類に関して複雑な点は、バージョン番号表示の周期性を考慮する必要があることである。従って、計算は、５６−１２８を計算する時に値１８４が得られるように、０乃至２５５の値の範囲内で循環的に実行されなければならない。
【００２９】
現行値に基づく範囲分類の後、本発明により、どの範囲が新たな受信セグメントのバージョン番号を有するかに関する分析が実行される。図示された場合のように、現行値５６は、次に値４８が続く場合、図７ａによると、範囲「古い」に存在する。従って、このセグメントは、本発明による検証の後、受信機内でセグメントの受け付けに至らない。同様に図６に示されたように、現行値５６の次にバージョン番号７８が続く状況の場合、値７８が図７ａによる範囲「新しい」に存在することが解明され、そしてセグメントは、受け付けられる。反対に、現行バージョン番号表示７８が現れ、そして値２５５が続いてバージョン番号表示として到着した場合、図７ａの範囲分類では値２５５は依然として「古い」範囲にあるので、値２５５は受け付けに至らない。
【００３０】
バージョン番号２５５が複数の反復の後に受け入れられる場合、値２５５から値０へ変化する場合に、値０が代わって「新しい」範囲にあるので、受け付けが生じる。
【００３１】
図７ｂは、バージョン番号表示の値の範囲の別の分類を示す。ここで再び同じ原理が利用される。但し、現行値７８から進行し、値の範囲のかなりの部分が範囲「新しい」に割り当てられるように、範囲分類が実行される場合を除く。「新しい」範囲は、値７９から値２５５まで、及びその上、値２７まで延在する。「古い」範囲は、値２８から値７７までにのみ延在する。この範囲分類では、後に続くバージョン番号表示２５５は、依然として範囲「新しい」にあり、セグメントは受け付けられる。
【００３２】
「古い」範囲が大きいほど、実際に廃止されたセグメントバージョンが現行として受け取られる可能性は低い。他方、「古い」範囲が拡大されると、伝送路の比較的長い混乱及び多数のセグメント変化が生じた場合、又はＤＶＢ−ＳＴＰパケットを送信せずにＤＶＢ−ＳＴＰサーバーで頻繁にセグメント変化が実行された場合、実際に現行のセグメントバージョンが廃止されたとして無視される可能性は増大する。これらの理由から、２つの範囲の何れもセグメントバージョン番号の値の範囲の大部分を網羅しないことは、有利である。１つの可能な分割は、例えば、セグメントバージョン番号を、３分の２までを「新しい」範囲に、及び３分の１を「古い」範囲に割り当てることである。
【００３３】
別の実施例は、「古い」及び「新しい」範囲の大きさを動的に変化することを目的とする。これは、例えば、データストリーム内のＳＤ＆Ｓ情報の観察された変化頻度に基づき実施されて良い。頻繁に変化が生じる場合、例えばより多くの廃止されたセグメントバージョンを差し止めるため、「古い」範囲の大きさは増大させられる。
【００３４】
起こり得る「バージョンのピンポン」の主な理由は、伝送路におけるＵＤＰパケットの伝搬時間差である。伝送路の最大伝搬時間差が知られている又は測定可能である又は推定可能である場合、「古い」範囲の大きさは、便宜上の最小値及び最大値の関係で、この時間期間内に観察され得るセグメント変化の数を定め得る。
【００３５】
廃止されたバージョンの完全な差し止めは、基本的に達成できない。しかしながら、システムは、セグメントが継続的にリフレッシュされるよう設計され、従って誤って現行として見なされたセグメントバージョンは、一時的に生じるだけであり、標準的に６０秒後にＤＶＢ−ＳＴＰ受信機により拒否され、その後新しく受信された、任意のバージョン番号を有するセグメントのバージョンは、説明されたように再び受け付けられるので、廃止されたバージョンの完全な差し止めは絶対的に必要ではない。
【００３６】
図８は、本発明による、受信セグメントの最新特性を検査する過程の、比較より大きい場合の可能な実施を示す。関連するプログラムの開始は、参照符号２０により示される。判定２１では、受信バージョン番号表示が現在の有効バージョン番号表示に一致するか否かを決定するための検査が行われる。真ならば、プログラムは、プログラムステップ２３へ枝分かれする。ステップ２３では、新たな受信セグメントは、知られているセグメントの有効なリフレッシュとして受け付けられる。新たな受信バージョン番号が、現行バージョン番号と等しくない場合、プログラムステップ２２で更なる判定が行われる。ステップ２２では、受信バージョン番号が、現行バージョン番号＋値１から現行バージョン番号＋値１２７の範囲内にあるか決定するために検査が行われる。この場合、しかしながら、この比較は、バージョン番号を割り当てる時、モジュロ２５６の動作を考慮する。これは、図８中にＣプログラム言語の文法で示される。検査されたバージョン番号がこの条件を満たす場合、受信バージョン番号が範囲「新しい」内に有ることは明らかである。そして、プログラムステップ２４では、受信セグメントの受け付けが続いて起こる。そして現行バージョン番号のバージョン番号表示も変更され、受信セグメントの値に設定される。プログラムは、プログラムステップ２５で終了する。プログラムステップ２２の判定条件が適用できない場合、受信データパケットのバージョン番号は、範囲「古い」に割り当てられる。その結果、対応するセグメントは、受け付けられない。そして現行セグメントのバージョン番号表示はまた、不変のままである。受信データパケットは、同様に、現行セグメントの有効なリフレッシュとして受け付けられない。代わりに、プログラムは、再びプログラムステップ２５で終了する。
【００３７】
ＤＶＢ−ＩＰＩ規格では、ＳＤ＆Ｓデータへの各変化が生じる時に、セグメントのバージョン番号表示はまた、１だけ増加されなければならない。最新の検証では、規格は、単に「サービスプロバイダーＩＤ」、「ペイロードＩＤ」、「セグメントＩＤ」及びセグメントバージョンの比較を要求するだけである。これは、常に満たされる必要がないことが示される。なぜなら、規格は、１つの同一のセグメントを異なる方法で符号化する種々の可能性を提供するからである。これを考慮し、再び図５を参照する。例として、ＣＲＣ符号に基づく誤り保護は、セグメントデータに対し任意的に指定される。誤り保護は、従って、必ずしも利用される必要はない。セグメントのセクションへの細分化は、任意の部分で実施されて良い。また、パケットのヘッダーは、圧縮の利用及び現時点では詳細に指定されていない暗号化方法を指定可能なエントリーを更に有する。 これに関連し、最初の４バイト分のデータの５及び６番目に２ビットのＥＮＣがある。また、３ビットのＣＯＭＰＲは、３番目の４バイト分のデータ内にある。しかしながら、ＤＶＢ−ＳＴＰパケットの実際のペイロードが変更されないので、規格は、これら送信パラメータの変化が、同様に、変更されたセグメントバージョン番号により伝達されなければならないことを要求しない。同一のセグメントバージョン番号を有する、別個に符号化されたＤＶＢ−ＳＴＰパケットを受信した受信機が、それらパケットから再びＳＤ＆Ｓ情報を組み立てる場合、それらパケット中に位置するデータは互換性を有さず符号化され又は配置されるので、誤りが生じ得る。更に、ＳＤ＆Ｓデータの多数の変化及び伝送ネットワークに比較的長い混乱が生じる場合、セグメントのより新しいバージョンが、論理的に同一セグメントバージョン番号をセグメントのより古いバージョンとして取得することは、受信機が更新を識別可能でなくても、論理的に可能である。
【００３８】
従って、規格により要求されたような「サービスプロバイダーＩＤ」、「ペイロードＩＤ」、「セグメントＩＤ」及びセグメントバージョン番号の比較に加え、改善されたＤＶＢ−ＳＴＰ受信機はまた、受信パケットのＤＶＢ−ＳＴＰヘッダー内の更なる表示、及び更に、任意的に、現行セグメントの事前に受信されたパケットを有するパケットの実際のペイロードデータを比較する。これは、不注意に不正にコンパイルされたＳＤ＆Ｓ情報の生成を防止する。これらの手段は、最新の検査に加え、現行値に基づく範囲分類を有するバージョン番号表示に基づき、又は他に独立して、つまり範囲分類との比較無しに実施されて良い。この追加の検証は、図８の任意のステップとして破線により示される。追加の判定は、参照符号２６を有する。プログラムステップ２３で、受信ＤＶＢ−ＳＴＰパケットが、知られているセグメントの有効なリフレッシュとして受け付けられるのは、同じＤＶＢ−ＳＴＰヘッダー及び同一セグメントデータの場合だけである。
【００３９】
プログラムステップ２６の判定で、ＤＶＢ−ＳＴＰヘッダー又はセグメントデータは変更されたこと判明した場合、更に任意のプログラムステップが続いて良い。プログラムステップ２７では、受信された、一致しないパケットが無視されるべきか否かを決定するため、検査が行われる。パケットが無視される場合、プログラムは、プログラムステップ２５で直接終了する。その他の場合、現行セグメントは、プログラムステップ２８で拒否される。そして新たな受信データを有するセグメントが、構築される。後は、プログラムがプログラムステップ２５で終了するだけである。
【図面の簡単な説明】
【００４０】
【図１】ＤＳＬルーターを介してインターネットと接続されたホームネットワークを示す。
【図２】インターネットへの接続可能性を有するビデオデコーダー及び接続されたテレビジョンセットを示す。
【図３】ＤＶＢ−ＩＰＩ規格に従い設計された装置のプロトコル図を示す。
【図４】ＳＤ＆Ｓデータレコードのセグメント及びセクションへの細分化を示す。
【図５】ＤＶＢ―ＳＴＰパケットのフォーマットを示す。
【図６】一連の送信されたＤＶＢ−ＳＴＰデータパケット及びこれらデータパケットの受信時に変更された順序を示す。
【図７】本発明による、バージョン番号の値の範囲の、「古い」及び「新しい」範囲への分類を示す。
【図８】セグメントのバージョン番号に基づき、最新検査を実施するために用いられるプログラムのフローチャートを示す。
【符号の説明】
【００４１】
１０ ＤＳＬルーター
１１ デジタルＴＶセット
１２ デジタルビデオレコーダー
１３ パーソナルコンピューター
１４ 携帯用パーソナルコンピューター
１５ インターネット
１６ サービスプロバイダー
１７ ビデオデコーダー
１８ ＴＶセット
【技術分野】
【０００１】
本発明は、マルチメディアサービスに関する。本発明は、例えば音声又はビデオ放送又はソフトウェア更新のための追加情報の項目のような、データ記録の更新の技術分野に関する。特に、本発明の技術分野は、例えばビデオ又は音声コンテンツのインターネットを介した伝送のような、ビデオコンテンツを、放送システムを介して伝送する分野に関連する。
【背景技術】
【０００２】
インターネットテレビ又はビデオオンデマンドのようなインターネット上でのビデオコンテンツの伝送では、知られているＤＶＢシステム（デジタルビデオブロードキャスト）との関連で、このようなデジタルビデオコンテンツがインターネットを介して伝送され得る伝送プロトコルを定める規格が作成された。規格は、策定中のＤＶＢ−ＩＰＩ（デジタル・ビデオ・ブロードキャスト・インターネット・プロトコル・インフラストラクチャー）で知られている。この規格は、とりわけ、ＸＭＬ文書形式の音声／ビデオデータストリーム（ＡＶストリームとも称される）の記述及び選択に関する情報の符号化を記載している。規格では、この情報はまた、「サービス・ディスカバリー・アンド・セレクション」情報と表される（ＳＤ＆Ｓに対応する）。ＤＶＢ−ＩＰＩ規格の正確な意味は、非特許文献１に記載されている。
【０００３】
ＳＤ＆Ｓデータは、サービスプロバイダー自身に関する情報及びサービスプロバイダーの種々のサービス提供に関する情報（生放送、オンデマンドコンテンツ、トリックモードを有するＡＶストリーミング）を有する。この場合、データは次の様に構成される。つまり、ＳＤ＆Ｓデータの型は、所謂ペイロードＩＤにより示される。サービスプロバイダーのペイロードＩＤに属するデータは、所謂ＳＤ＆Ｓデータレコードと表される。ＳＤ＆Ｓデータレコードは、標準的に、可能な変化の影響を可能な限り少ないセグメントに限定するために、所謂ＳＤ＆Ｓセグメントと称される複数の独立セグメントに分割される。しかしながら、データレコードはまた、単一のセグメントを有して良い。サービスプロバイダーの各ＳＤ＆Ｓセグメントは、ペイロードＩＤ及びセグメントＩＤの組により識別される。セグメントの変化を伝達可能にするため、各セグメントは、追加で、バージョン番号、所謂セグメントバージョン番号を有する。セグメントのデータが変化した場合、変化を示すため及びこの特定のバージョンの検索を可能にするため、セグメントのバージョン番号がインクリメントされなければならない。ＤＶＢ−ＩＰＩ規格では、ＳＤ＆Ｓデータの伝送のために、２つの異なる伝送モードが記載されている。所謂「プルモード」としても参照されるＨＴＴＰ（ハイパーテキスト転送プロトコル）によるＳＤ＆Ｓデータの検索に加え、ＤＶＢ−ＩＰＩは、伝送プロトコルＤＶＢ−ＳＴＰを定める。ＤＶＢ−ＳＴＰにより、サービスプロバイダーのＳＤ＆Ｓサーバーのデータは、ＵＤＰ（マルチキャスト）により全ての対象の受信機へ周期的に送信される。このモードは、「プッシュモード」と表される。ＵＤＰは、インターネット技術で知られている「ユーザー・データグラム・プロトコル」に対応する。記載されるべき発明は、原則として「プッシュモード」で利用される。このモードでは、ＳＤ＆Ｓセグメントは、所謂ＳＤ＆Ｓセクションに任意的に更に細分化され、そしてＤＶＢ−ＳＴＰヘッダーを設けられる。このようなセクションは、マルチキャストによりＵＤＰパケットとして周期的に送出される。
【０００４】
ＩＰマルチキャストアドレスから自動的に導出された又は明示的に指定されたサービスプロバイダーＩＤ、ペイロードＩＤ、セグメントＩＤ及びセグメントバージョン番号に基づき、受信機は、個々のセクションからセグメントを再び結合し、そして、例えば電子番組表を表示可能にするため、含まれているＳＤ＆Ｓデータを処理する。受信機は、変化したセグメントバージョン番号からセグメントの変化を識別し、そしてその結果、古いデータを新しいデータで置き換え得る。しかしながら、どのデータが古いデータであり、どれが新しいかに関する決定は、ＵＤＰによる伝送の信頼性が低いという理由で、当初に考えられたほど自明ではない。
【非特許文献１】トランスポート・オブ・ディー・ブイ・ビー・サービス・オーバー・アイ・ピー（Ｔｒａｎｓｐｏｒｔ ｏｆ ＤＶＢ Ｓｅｒｖｉｃｅｓ ｏｖｅｒ ＩＰ）、ディー・ブイ・ビー・ドキュメントＡ０８６（ＤＶＢ Ｄｏｃｕｍｅｎｔ Ａ０８６）、（発行国）、デジタル・ビデオ・ブロードキャスティング（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ （ＤＶＢ））、２００４年７月
【発明の開示】
【発明が解決しようとする課題】
【０００５】
規格は、セグメントが変更された場合、セグメントバージョン番号をインクリメントすることを定めているが、「新しいセグメントバージョン番号＝古いセグメントバージョン番号＋１」の形式で最新の検証を簡易に実施する場合、以下の問題が存在する。信頼性の低いＵＤＰ伝送によると、ＤＶＢ−ＳＴＰパケットは、何時でも損失し得る。従って、急激な連続したセグメント変化が生じる場合、中程度の範囲のセグメントバージョン番号を有するＤＶＢ−ＳＴＰパケットは、決して受信機に到達しない。しかしながら、これは、最近のデータはもはや厳格なインクリメントルールに従わないので、最近のデータもまた無視されることを意味する。第二に、規格は、ＤＶＢ−ＳＴＰ送信機が少なくとも１つのＤＶＢ−ＳＴＰパケットをセグメントバージョン毎に実際に送信しなければならないことを明示的に定めない。急激な連続したセグメント変化が生じた場合に、考えられることは、従って、最初の刷新の対応するＤＶＢ−ＳＴＰパケットが実際に送信される前に、直ぐに新しいバージョンにより置き換えられるべきＤＶＢ−ＳＴＰ送信機の新しいセグメントバージョンに対し、受信ＤＶＢ−ＳＴＰパケットのセグメントバージョン番号内のジャンプは、受信機と同様に生じ得ることである。そして、データパケットは、厳格なインクリメントルールに従い、検証中に無視され得る。
【０００６】
「新しいセグメントバージョン番号が古いセグメントバージョン番号と等しくない」又は「新しいセグメントバージョン番号＞古いセグメントバージョン番号である」の形式の考え得る最新の検証はまた、問題を有する。ルールと等しくないことは簡単に実施されるが、現行と考えられるＳＤ＆Ｓセグメントのバージョンの安定性に関する重大な不利点を有する。これは、低信頼性のＵＤＰ伝送がＤＶＢ−ＳＴＰパケットが送信機から送出された時と同一の順序で受信機に到着することを保証しないためである。これは、セグメント変化が生じた場合、より新しいセグメントバージョンを有するＤＶＢ−ＳＴＰパケットが、より古いバージョンを有するパケットに、伝送経路上で追いつくという影響を有し得る。ルールと等しくないアプリケーションでは、この場合の古いバージョンから起こった受信機は、最初に新しいセグメントバージョンを検討し、そして次に再度、現行となるべき古いセグメントバージョンを検討する。新しいセグメントバージョンの繰り返し伝送が受信された場合のみ、受信機は前記新しいセグメントバージョンを現行として識別する。これは、個々のＳＤ＆Ｓセグメントが所定の時間内にリフレッシュされない場合、特定の時間間隔で且つセグメントは無効であると見なされなければならないと定める規格の範囲内で、何度も繰り返されるからである。不規則に受信されたＤＶＢ−ＳＴＰパケット数により、現行のセグメントバージョンはまた、更に頻繁に変更して良い。結果として生じる望ましくないセグメントの「前後への切り替え」は、実際には現行であるセグメントの受け取りを不必要に遅延させ得る。これは、最初の受信が既に受け取られている場合でも、受け入れられる新しいセグメントバージョンの第ｎ番目の受信だけが可能であるからである。
【０００７】
望ましくない影響は、ユーザーには明らかであり、場合によってユーザーを混乱する。例として、ＳＤ＆Ｓデータから生成される電子番組表は、チャネル内の番組変更が生じた場合、場合によって、前の放送及び現行の放送の表示の間で前後に変更する。
【課題を解決するための手段】
【０００８】
本発明は、以下の方法でこの問題を解決する。
【０００９】
セグメントが変化した場合の最新検査では、比較と等しくない又は厳格なインクリメントルールの代わりに、「新しいセグメントバージョン番号＞古いセグメントバージョン番号」の形式である、同時にバージョン番号のインクリメント時のモジュロ動作を考慮するルールが実行されるべきである。例として、８ビット値は、ＤＶＢ−ＩＰＩ規格のセグメントバージョン番号のために提供される。バージョン番号の値の範囲は、従って、０乃至２５５の範囲に対応する。この範囲の最後の値に到達した場合、更なるインクリメントが行われ、そして値の範囲は、再び始めから新しく繰り返される。その結果として、比較より大きい数は、セグメントバージョン番号に適用され得ない。むしろ、本発明は、現行と考えられるバージョン番号から続けて、バージョン番号の値の範囲を「古い」及び「新しい」範囲に分類することを提案する。この場合、２つの範囲の１つは、値２５５から値０への「桁あふれ」を有して良い。２つの範囲は、この場合、現行のバージョン番号から同様にシフトされる。範囲は、異なる大きさを有するよう選択され得る。「古い」範囲が大きいほど、実際に廃止されたセグメントバージョンが現行として受け取られる可能性は低い。他方、「古い」範囲が拡大されると、伝送路の比較的長い障害及び多数のセグメント変化が生じた場合、又は関連するＤＶＢ−ＳＴＰパケットを送信せずに送信端で頻繁にセグメント変化が実行された場合、実際に現行のセグメントバージョンが廃止されたとして無視される可能性は増大する。これらの理由から、２つの範囲の何れもセグメントバージョン番号の値の範囲の大部分を網羅しないことは、有利である。
【００１０】
本発明の利点は、場合によって廃止されたバージョンのセグメントが無視されることである。また本発明の利点は、異なるバージョンを有するデータパケットの受信が時間的に重複するセグメントの異なるバージョン間での前後への変化が、結果として回避されることである。本発明を実施する際の追加費用は、比較的低い。現行セグメントのバージョン番号が「古い」範囲内から来るのを完全に防ぐことができないが、特に非常に頻繁な変化、又はセグメントバージョン番号に大きなジャンプが生じる場合、この場合は、滅多に生じない。更に、ＤＶＢ−ＩＰＩの場合、セグメントをリフレッシュする規定は、不正に現行であると見なされたセグメントバージョンが、標準的には６０秒後に任意のバージョン番号を有する新しく受信されたバージョンと再び入れ替えられることを保証する。
【００１１】
更なる向上及び発展は、特許請求の範囲に示された手段を利用することにより可能である。また、変化したバージョン番号により明示的に伝達されないセグメントの変化を解明可能にするために、新しく受信されたセグメントの更なるデータが、現行と考えられるセグメントのデータと更に比較される場合に、新しく受信されたセグメントのバージョン番号が現行セグメントのバージョン番号と一致する場合、本発明は有利である。受信セグメントは、比較データが一致した場合のみ、現行と考えられるセグメントの有効なリフレッシュとして受け付けられる。従って、例として、ＤＶＢ−ＩＰＩシステムの場合、ＤＶＢ−ＳＴＰヘッダー内の全ての他の表示及びデータパケット内の実際のペイロードデータは、事前に受信されたデータと比較されて良い。これは、ＳＤ＆Ｓデータレコードを異なる方法でＤＶＢ−ＳＴＰパケット内で送信することを可能にする。ＣＲＣ検査符号を用いた誤り保護は、従って、セグメントデータに対し任意である。セクションへの細分化は、同様に種々の方法で実行されて良い。更に、ＤＶＢ−ＳＴＰヘッダー内のエントリーはまた、圧縮の利用及び現時点では詳細に指定されていない暗号化方法を指定可能な方法を利用し、表される。規格は、これら送信パラメータの変化が、変化したセグメントバージョン番号により同様に伝達されることを要求しないので、受信機は、同一のセグメントバージョン番号を有する別個に符号化されたＤＶＢ−ＳＴＰパケットを受信することができ、及びこれら可能な互換性のないパケットから誤りのある出力結果のみを生じるＳＤ＆Ｓセグメントを不正に組み立てる可能性がある。これは、記載された手段により防止される。
【００１２】
更に、現行と考えられるセグメントと一致しない内容を有し、及び同一バージョン番号を有するＤＶＢ−ＳＴＰパケットは、異なる方法で扱われ得る。第一に、これらのパケットは、単に無視され得る。ＤＶＢ−ＩＰＩ規格の場合、これは、送信機により場合によって故意に変化されたセグメントデータが、リフレッシュがないために現行と見なされたセグメントが拒否された後まで、受け入れられないという影響を有する。なぜなら、不一致パケットは、現行セグメントのリフレッシュとして取り扱われるべきでないからである。しかしながら、手順は、最大６０秒を要する。他方、これらのパケットは、現行と見なされたセグメントの新しいバージョンと関連付けられると考えられる。この場合、現行と見なされたセグメントは、直ちに拒否される。そして新たに受信されたデータを有するセグメントが構築される。しかしながら、同一のセグメントバージョン番号のため、最新の検証はもはや可能ではないので、現行と見なされたセグメントの内容は、セグメントの両方のバージョンと関連したＤＶＢ−ＳＴＰパケットが依然として受信されている限り、前後に繰り返しジャンプする。不一致パケットが無視されるか又は直接受け取られるかに関する決定は、例えば、ＳＤ＆Ｓデータの安定性又は最新性のどちらが受信機にとってより重要であるかに従い、受信機内に設定可能な方法で設計され得る。更に、この設定は、受信した不一致ＤＶＢ−ＳＴＰパケットの数に動的に適応することが可能である。
【００１３】
「古い」及び「新しい」範囲への動的な範囲の分類はまた、有利である。特に、セグメントの観察された変化頻度が、動的範囲分類を実行するために用いられる場合、本発明による方法の更なる向上が可能である。伝送路における知られている又は推測された伝搬時間の差を変化頻度の解明のために用いることはまた、動的範囲分類に有利である。本発明による方法を実施する本発明による装置は、請求項１３乃至１６に記載されている。
【００１４】
例として、本発明の実施例が図示され、以下に詳細に説明される。
【発明を実施するための最良の形態】
【００１５】
図１は、イーサネット（登録商標）技術に基づくホームネットワークを示す。図１では、種々のホームネットワーク装置が、イーサネット（登録商標）ケーブルによりＤＳＬルーター１０と接続されている。この場合、参照符号１１は、デジタルビデオデータのデコーダーを有するＴＶセットのような、デジタルＴＶセットを示す。参照符号１２は、デジタルビデオレコーダーを示す。そして、参照符号１３は、パーソナルコンピューターを示す。参照符号１４は、携帯用パーソナルコンピューター、例えばラップトップ又はノートブックコンピューターを示す。後者は、ＤＳＬルーター１０と無線で接続される。この目的のために、ＩＥＥＥ８０２．１１ｘ規格の１つに対応する慣例の無線イーサネット（登録商標）接続技術の１つが利用されて良い。ＤＳＬルーター１０は、電話接続を介してインターネット１５と接続される。同様に図は、サービスプロバイダー１６がＤＳＬルーター１０によりインターネット１５を介して選択され得ることを示す。インターネット１５からは、デジタルビデオコンテンツが、インターネットＴＶサービス又はビデオオンデマンドサービスの何れかの形式で要求され得る。
【００１６】
図２は、インターネットへの接続の別の可能性を示す。この図では、参照符号１８は、ＴＶセットを示す。ＴＶセットは、ビデオデコーダー１７と接続される。ビデオデコーダー１７はまた、ＩＰセットトップボックスとして示される。前記ビデオデコーダー１７は、電話接続に直接接続され、つまり、統合されたＤＳＬモデムを有する。更に、図は、同様に、接続が確立され得るサービスプロバイダー１６を示す。これらの例である実施例では、ＤＶＢ−ＩＰＩ規格は、インターネットを介したビデオコンテンツの伝送のために用いられる。言い換えると、ＤＳＬルーター１０及びデジタルビデオデコーダー１７は、両方とも、ＤＶＢ−ＩＰＩ規格に記載されたプロトコルを実装していなければならない。
【００１７】
図３に示されるプロトコルは、本発明に全て関連しないので、従って詳細に説明されない。これらプロトコルに関するより詳細な情報は、慣例的文献又は関連する規格を参照のこと。前述のように、ＳＤ＆Ｓプロトコルは、サービス加入者に、利用可能になったサービスに関する必要な情報及びそのサービスで提供されるコンテンツを利用可能にするよう機能する。この場合、「サービス・ディスカバリー」は、加入者にインターネットでＤＶＢサービスを発見させる機構である。この機構は、結果として、ユーザーに伝達されているサービス提供のリストを生じる。従って、ユーザーは、ユーザーが利用したいどのサービスを選択するかの可能性を有する。選択自体は、後で行われ、ＳＤ＆Ｓ機構に関連した選択サービスに関連する。
【００１８】
加入者にＳＤ＆Ｓ情報を届けるために利用可能にされる伝送モードは、２つある。ＤＶＢ−ＩＰＩ規格では、１つの伝送モードは、「プッシュモード」、及び他方は「プルモード」として表される。「プルモード」では、ＳＤ＆Ｓデータは、ＨＴＴＰプロトコルを利用して受信機へ送信される。ＨＴＴＰ（ハイパーテキスト転送プロトコル）の場合、受信局が所望のデータを要求する（ＨＴＴＰ−Ｇｅｔ）か、又は自身の部分の送信局が、ＨＴＴＰ−Ｐｏｓｔを利用し加入者局にデータを利用可能にする。図３に示されるように、ＨＴＴＰプロトコルは、ＴＣＰプロトコル（通信制御プロトコルに対応する）の上に配置される。知られているように、ＴＣＰプロトコルは、保護された送信プロトコルである。ＴＣＰプロトコルでは、個々の送信されたデータパケットは、受信端で確認されなければならない。従って、送信端は、受信確認が示されない場合、失敗したパケットを再送する。
【００１９】
ＳＤ＆Ｓ情報の送信の第二の可能性は、同様に図３に示される。図３は、サービス情報をマルチキャストにより複数の加入者へ同時に送出するために利用される、所謂「プッシュモード」を有する。ＤＶＢ−ＳＴＰプロトコルは、この目的のために利用される。ＤＶＢ−ＳＴＰプロトコルは、ＳＤ＆Ｓ情報を通信する特別なトランスポート・プロトコルを有する。
【００２０】
ＳＤ＆Ｓ情報は、ＸＭＬ文書にコンパイルされる。これらは、基本的にテキストデータ、つまり文字コードを有する。サービスプロバイダーに特有の種類の全ての番組情報は、ＳＤ＆Ｓデータレコード内に格納されて良い。従って、サービスプロバイダーが複数のテレビジョン番組を提供する場合、この複数の番組の全ての番組情報は、従って、このデータレコードのＸＭＬ文書内に格納され得る。従って、文書は、数キロバイト又は数１０キロバイトのかなりの大きさに達し得る。番組情報は最近の動向に対応しなければならないので、ＤＶＢ−ＩＰＩ規格は、それぞれデータレコードの部分を有する独立のＸＭＬ文書である複数のセグメントに細分化されたデータレコードの送信を許可する。これは、番組プロバイダーにより番組変更が生じた場合、データレコードの全データを有する１つの文書が再び送信される必要がなく、むしろ番組変更が、適切な場合、データレコードの１つのセグメントのみに影響する状況を許容する。
【００２１】
図４は、ＳＤ＆Ｓデータレコードの細分化を示す。ＤＶＢ−ＩＰＩ規格は、種々の種類のＸＭＬ文書を許可する。これらは、所謂ペイロードＩＤにより識別される。「サービスプロバイダー発見」情報、「ブロードキャスト発見」情報、「コンテントオンデマンド発見」情報、「他のサービスプロバイダーからのサービス」に関する情報、「パッケージ発見」情報、及び「ユーザープライベート」情報がある。
【００２２】
データレコードは、複数のセグメントに分類され得る。複数のセグメントの部分は、セグメントＩＤ及びバージョン番号により識別される。バージョン番号は、規格では８ビット値として定められる。新しいセグメントバージョンがサービスプロバイダーにより提供される度に、前記セグメントのバージョン番号は、インクリメントされる。バージョン番号が８ビットの数として設計されるので、セグメントバージョンの値の範囲は、０乃至２５５に定められる。最も高い値２５５に到達した場合、更にインクリメントが実施され、そして値の範囲は、再び０から２５５まで通して進む。更に、個々のセグメントを所謂セクションに更に細分化することが許可される。これは、図４に同様に示される。この目的のため、それぞれのセクション番号は、セクションに割り当てられる。関連するセグメントの最も生じ易いセクション番号は、更に指定される。このように細かく分割されたセグメントのＸＭＬ文書は、ＵＤＰプロトコルに従い部分的に送信される。それぞれの場合で、ＵＤＰデータパケットは、セクションのデータを有する。
【００２３】
図５は、関連するＵＤＰデータパケットのフォーマットを示す。このパケットの個々のフィールドは、ＤＶＢ−ＩＰＩ規格で定められる。示されるように、２番目の４バイト分のデータは、ペイロードＩＤ、セグメントＩＤ及びセグメントバージョン番号を有する。ペイロードＩＤ及びセグメントバージョン番号は、８ビットの数である。セグメントＩＤは、１６ビットの数である。このようなデータパケット内には、以下により詳細に議論される任意フィールドもある。
【００２４】
説明されたように、ＵＤＰプロトコルは、セクション内のセグメントの送信に利用される。しかしながら、知られているように、ＵＤＰプロトコルは、如何なる受信確認メッセージも提供されない信頼性の低い伝送プロトコルである。これらＵＤＰパケットをインターネットを介して送信する間、全パケットが失われる、早い時期に送信されたパケットが後に送信されたパケットより実際には遅く受信機に到着する、等が起こり得る。混乱は、特に、伝送路に無線伝送がある場合、一時的に生じ得る。従って、全セグメント又は全ＳＤ＆Ｓデータレコードも、比較的長時間では失われ得る。
【００２５】
図６は、問題をより詳細に示す。送信端におけるＳＤ＆Ｓデータレコードのセグメントのブロードキャストは、上部の時間軸に示される。数字の表記は、それぞれの場合に、セグメントバージョン番号に関連する。ブロードキャストセグメントが受信機に到達した瞬間は、図の下部に示される。ＤＶＢ−ＩＰＩ規格は、種々のセグメントを周期的にリフレッシュさせる。全体に、３０秒の最大時間期間は、ＳＤ＆Ｓ情報の送信を超えてはならない。情報は、継続的に繰り返されないので、それぞれの場合に３０秒後にリフレッシュがある。「プッシュモード」で６０秒以内に如何なるリフレッシュも到着しない場合、個々の受信機は、関連するセグメントが削除されたと見なす。それらは、次に、廃止されたセグメントを削除しなければならない。その結果、続いて受信された、任意のセグメントバージョン番号を有するセグメントは、現行と考えられる。図６では、バージョン番号４８を有するセグメントは、それぞれの場合、最初の３個のブロードキャストで送信される。図の下部は、関連するセグメントが受信機に到着した時を示す。バージョン番号４８を有するセグメントの３番目のブロードキャストは、示されるように大幅に遅れる。特に、バージョン番号５６を有するセグメントは、その間に受信機に連続して２回到着している。バージョン番号４９乃至５５を有する全ての他のセグメントがブロードキャストされたが、それらは、伝送路で失われた。従って、受信機が、バージョン番号４８を有する到着したセグメントを新しいとして受け付けるか、又は事前に到着したバージョン番号５６を有するセグメントのままにするかを決定することは、困難である。単に比較と等しくないことは、バージョン番号４８を有するセグメントを受け付ける結果になる。単に比較より大きいことは、バージョン番号４８を有するセグメントを無視する結果になる。バージョン番号５６を有するセグメントは、続いて再び受信されるので、このセグメントに関して、前後へのジャンプが起こり得る。
【００２６】
続いて図６は、セグメントバージョン番号７８を有するセグメントが送信及び受信されたことを示す。間に置かれた番号５７乃至７７を有するセグメントは、サービスプロバイダーによってもブロードキャストされない。第一の理由として、それらのセグメントは、ブロードキャストされないような短時間の間に連続した変化として生じるからである。同じ状況は、バージョン番号７８の後にバージョン番号２５５が続く場合に説明される。セグメントバージョン番号２５５から開始値０への切り替えはまた、示された区間の端に示される。受信機がどのセグメントをより現行であると見なすべきかに関する受信機の決定は、単に比較より大きいことによると、困難になる。
【００２７】
起こり得る「バージョンのピンポン」を有する以上の問題を回避するため、本発明は、バージョン番号表示の値の範囲の範囲分類に基づき、比較より大きい又は比較より小さい実行を提供する。
【００２８】
図７は、関連する範囲分類を説明する。バージョン番号表示の値の範囲０乃至２５５は、図７ａの場合に示される。これは、図６による、現在受信されたセグメントバージョン番号が値５６に関連する場合を考慮している。この現行の値に基づき、値の範囲は、２つの範囲「古い」及び「新しい」に分類される。この場合、範囲「新しい」は、現行のバージョン番号表示＋１の値から、現行のバージョン番号表示＋１２７の値までの範囲に対応する。範囲「新しい」は、従って５７乃至１８３に亘る。範囲「古い」は、反対に、現行のバージョン番号表示−１から現行のバージョン番号表示−１２８の範囲に関連する。従って、２つに分割される。２つの範囲「古い」及び「新しい」は、殆ど等しい大きさである。この範囲分類に関して複雑な点は、バージョン番号表示の周期性を考慮する必要があることである。従って、計算は、５６−１２８を計算する時に値１８４が得られるように、０乃至２５５の値の範囲内で循環的に実行されなければならない。
【００２９】
現行値に基づく範囲分類の後、本発明により、どの範囲が新たな受信セグメントのバージョン番号を有するかに関する分析が実行される。図示された場合のように、現行値５６は、次に値４８が続く場合、図７ａによると、範囲「古い」に存在する。従って、このセグメントは、本発明による検証の後、受信機内でセグメントの受け付けに至らない。同様に図６に示されたように、現行値５６の次にバージョン番号７８が続く状況の場合、値７８が図７ａによる範囲「新しい」に存在することが解明され、そしてセグメントは、受け付けられる。反対に、現行バージョン番号表示７８が現れ、そして値２５５が続いてバージョン番号表示として到着した場合、図７ａの範囲分類では値２５５は依然として「古い」範囲にあるので、値２５５は受け付けに至らない。
【００３０】
バージョン番号２５５が複数の反復の後に受け入れられる場合、値２５５から値０へ変化する場合に、値０が代わって「新しい」範囲にあるので、受け付けが生じる。
【００３１】
図７ｂは、バージョン番号表示の値の範囲の別の分類を示す。ここで再び同じ原理が利用される。但し、現行値７８から進行し、値の範囲のかなりの部分が範囲「新しい」に割り当てられるように、範囲分類が実行される場合を除く。「新しい」範囲は、値７９から値２５５まで、及びその上、値２７まで延在する。「古い」範囲は、値２８から値７７までにのみ延在する。この範囲分類では、後に続くバージョン番号表示２５５は、依然として範囲「新しい」にあり、セグメントは受け付けられる。
【００３２】
「古い」範囲が大きいほど、実際に廃止されたセグメントバージョンが現行として受け取られる可能性は低い。他方、「古い」範囲が拡大されると、伝送路の比較的長い混乱及び多数のセグメント変化が生じた場合、又はＤＶＢ−ＳＴＰパケットを送信せずにＤＶＢ−ＳＴＰサーバーで頻繁にセグメント変化が実行された場合、実際に現行のセグメントバージョンが廃止されたとして無視される可能性は増大する。これらの理由から、２つの範囲の何れもセグメントバージョン番号の値の範囲の大部分を網羅しないことは、有利である。１つの可能な分割は、例えば、セグメントバージョン番号を、３分の２までを「新しい」範囲に、及び３分の１を「古い」範囲に割り当てることである。
【００３３】
別の実施例は、「古い」及び「新しい」範囲の大きさを動的に変化することを目的とする。これは、例えば、データストリーム内のＳＤ＆Ｓ情報の観察された変化頻度に基づき実施されて良い。頻繁に変化が生じる場合、例えばより多くの廃止されたセグメントバージョンを差し止めるため、「古い」範囲の大きさは増大させられる。
【００３４】
起こり得る「バージョンのピンポン」の主な理由は、伝送路におけるＵＤＰパケットの伝搬時間差である。伝送路の最大伝搬時間差が知られている又は測定可能である又は推定可能である場合、「古い」範囲の大きさは、便宜上の最小値及び最大値の関係で、この時間期間内に観察され得るセグメント変化の数を定め得る。
【００３５】
廃止されたバージョンの完全な差し止めは、基本的に達成できない。しかしながら、システムは、セグメントが継続的にリフレッシュされるよう設計され、従って誤って現行として見なされたセグメントバージョンは、一時的に生じるだけであり、標準的に６０秒後にＤＶＢ−ＳＴＰ受信機により拒否され、その後新しく受信された、任意のバージョン番号を有するセグメントのバージョンは、説明されたように再び受け付けられるので、廃止されたバージョンの完全な差し止めは絶対的に必要ではない。
【００３６】
図８は、本発明による、受信セグメントの最新特性を検査する過程の、比較より大きい場合の可能な実施を示す。関連するプログラムの開始は、参照符号２０により示される。判定２１では、受信バージョン番号表示が現在の有効バージョン番号表示に一致するか否かを決定するための検査が行われる。真ならば、プログラムは、プログラムステップ２３へ枝分かれする。ステップ２３では、新たな受信セグメントは、知られているセグメントの有効なリフレッシュとして受け付けられる。新たな受信バージョン番号が、現行バージョン番号と等しくない場合、プログラムステップ２２で更なる判定が行われる。ステップ２２では、受信バージョン番号が、現行バージョン番号＋値１から現行バージョン番号＋値１２７の範囲内にあるか決定するために検査が行われる。この場合、しかしながら、この比較は、バージョン番号を割り当てる時、モジュロ２５６の動作を考慮する。これは、図８中にＣプログラム言語の文法で示される。検査されたバージョン番号がこの条件を満たす場合、受信バージョン番号が範囲「新しい」内に有ることは明らかである。そして、プログラムステップ２４では、受信セグメントの受け付けが続いて起こる。そして現行バージョン番号のバージョン番号表示も変更され、受信セグメントの値に設定される。プログラムは、プログラムステップ２５で終了する。プログラムステップ２２の判定条件が適用できない場合、受信データパケットのバージョン番号は、範囲「古い」に割り当てられる。その結果、対応するセグメントは、受け付けられない。そして現行セグメントのバージョン番号表示はまた、不変のままである。受信データパケットは、同様に、現行セグメントの有効なリフレッシュとして受け付けられない。代わりに、プログラムは、再びプログラムステップ２５で終了する。
【００３７】
ＤＶＢ−ＩＰＩ規格では、ＳＤ＆Ｓデータへの各変化が生じる時に、セグメントのバージョン番号表示はまた、１だけ増加されなければならない。最新の検証では、規格は、単に「サービスプロバイダーＩＤ」、「ペイロードＩＤ」、「セグメントＩＤ」及びセグメントバージョンの比較を要求するだけである。これは、常に満たされる必要がないことが示される。なぜなら、規格は、１つの同一のセグメントを異なる方法で符号化する種々の可能性を提供するからである。これを考慮し、再び図５を参照する。例として、ＣＲＣ符号に基づく誤り保護は、セグメントデータに対し任意的に指定される。誤り保護は、従って、必ずしも利用される必要はない。セグメントのセクションへの細分化は、任意の部分で実施されて良い。また、パケットのヘッダーは、圧縮の利用及び現時点では詳細に指定されていない暗号化方法を指定可能なエントリーを更に有する。 これに関連し、最初の４バイト分のデータの５及び６番目に２ビットのＥＮＣがある。また、３ビットのＣＯＭＰＲは、３番目の４バイト分のデータ内にある。しかしながら、ＤＶＢ−ＳＴＰパケットの実際のペイロードが変更されないので、規格は、これら送信パラメータの変化が、同様に、変更されたセグメントバージョン番号により伝達されなければならないことを要求しない。同一のセグメントバージョン番号を有する、別個に符号化されたＤＶＢ−ＳＴＰパケットを受信した受信機が、それらパケットから再びＳＤ＆Ｓ情報を組み立てる場合、それらパケット中に位置するデータは互換性を有さず符号化され又は配置されるので、誤りが生じ得る。更に、ＳＤ＆Ｓデータの多数の変化及び伝送ネットワークに比較的長い混乱が生じる場合、セグメントのより新しいバージョンが、論理的に同一セグメントバージョン番号をセグメントのより古いバージョンとして取得することは、受信機が更新を識別可能でなくても、論理的に可能である。
【００３８】
従って、規格により要求されたような「サービスプロバイダーＩＤ」、「ペイロードＩＤ」、「セグメントＩＤ」及びセグメントバージョン番号の比較に加え、改善されたＤＶＢ−ＳＴＰ受信機はまた、受信パケットのＤＶＢ−ＳＴＰヘッダー内の更なる表示、及び更に、任意的に、現行セグメントの事前に受信されたパケットを有するパケットの実際のペイロードデータを比較する。これは、不注意に不正にコンパイルされたＳＤ＆Ｓ情報の生成を防止する。これらの手段は、最新の検査に加え、現行値に基づく範囲分類を有するバージョン番号表示に基づき、又は他に独立して、つまり範囲分類との比較無しに実施されて良い。この追加の検証は、図８の任意のステップとして破線により示される。追加の判定は、参照符号２６を有する。プログラムステップ２３で、受信ＤＶＢ−ＳＴＰパケットが、知られているセグメントの有効なリフレッシュとして受け付けられるのは、同じＤＶＢ−ＳＴＰヘッダー及び同一セグメントデータの場合だけである。
【００３９】
プログラムステップ２６の判定で、ＤＶＢ−ＳＴＰヘッダー又はセグメントデータは変更されたこと判明した場合、更に任意のプログラムステップが続いて良い。プログラムステップ２７では、受信された、一致しないパケットが無視されるべきか否かを決定するため、検査が行われる。パケットが無視される場合、プログラムは、プログラムステップ２５で直接終了する。その他の場合、現行セグメントは、プログラムステップ２８で拒否される。そして新たな受信データを有するセグメントが、構築される。後は、プログラムがプログラムステップ２５で終了するだけである。
【図面の簡単な説明】
【００４０】
【図１】ＤＳＬルーターを介してインターネットと接続されたホームネットワークを示す。
【図２】インターネットへの接続可能性を有するビデオデコーダー及び接続されたテレビジョンセットを示す。
【図３】ＤＶＢ−ＩＰＩ規格に従い設計された装置のプロトコル図を示す。
【図４】ＳＤ＆Ｓデータレコードのセグメント及びセクションへの細分化を示す。
【図５】ＤＶＢ―ＳＴＰパケットのフォーマットを示す。
【図６】一連の送信されたＤＶＢ−ＳＴＰデータパケット及びこれらデータパケットの受信時に変更された順序を示す。
【図７】本発明による、バージョン番号の値の範囲の、「古い」及び「新しい」範囲への分類を示す。
【図８】セグメントのバージョン番号に基づき、最新検査を実施するために用いられるプログラムのフローチャートを示す。
【符号の説明】
【００４１】
１０ ＤＳＬルーター
１１ デジタルＴＶセット
１２ デジタルビデオレコーダー
１３ パーソナルコンピューター
１４ 携帯用パーソナルコンピューター
１５ インターネット
１６ サービスプロバイダー
１７ ビデオデコーダー
１８ ＴＶセット
【特許請求の範囲】
【請求項１】
データレコードのセグメント更新方法であって、データレコードを単一のセグメントで構成可能であり、前記セグメントは、バージョン番号により識別され、前記バージョン番号のために限られた値の範囲が利用可能であり、及び前記値の範囲は、周期的に進み、
−前記値の範囲が進む周期性を考慮し、現行バージョン番号に基づき、前記バージョン番号の前記値の範囲を範囲「古い」及び「新しい」に分類する段階、
−新たな受信セグメントのバージョン番号が存在する範囲を検査する段階、
−前記検査が、前記新たな受信セグメントのバージョン番号は前記範囲「新しい」に存在すると判明した場合、前記新たな受信セグメントを、現行セグメントとして受け付ける段階、
−前記検査が、前記新たな受信セグメントのバージョン番号は前記範囲「古い」に存在すると判明した場合、前記新たな受信セグメントを拒否する段階、
を特徴とする、データレコードのセグメント更新方法。
【請求項２】
前記範囲「古い」及び「新しい」への範囲分類は、動的に適応される、請求項１記載の方法。
【請求項３】
前記動的な範囲分類は、前記範囲「古い」及び「新しい」が観察されたセグメントの変化頻度に基づき、増大又は減少されるよう、実施される、請求項２記載の方法。
【請求項４】
前記変化頻度の観察時間期間は、伝送路の知られている又は推定された／測定された伝搬時間差により予め定められる、請求項３記載の方法。
【請求項５】
−前記新たな受信セグメントのバージョン番号が、現行有効セグメントのバージョン番号と一致する場合、前記新たな受信セグメントの更なるデータを前記現行有効セグメントのデータと比較する段階、
−前記更なるデータの比較が、前記比較されたデータは一致すると判明した場合、前記新たな受信セグメントを有効なリフレッシュとして受け付ける段階、
を更に特徴とする、請求項１乃至４の何れか１項記載の方法。
【請求項６】
−前記更なるデータの比較が、前記比較されたデータは一致しないと判明した場合、前記新たな受信セグメントを無視する段階、
を更に特徴とする、請求項５項記載の方法。
【請求項７】
−前記更なるデータの比較が、前記比較されたデータは一致しないと判明した場合、前記新たな受信セグメントを現行セグメントとして受け付ける段階、
を更に特徴とする、請求項５項記載の方法。
【請求項８】
セグメントは、ヘッダー部分及びペイロードデータ部分を有する１つ又は複数のデータパケットの形式で送信される、請求項１乃至７の何れか１項記載の方法。
【請求項９】
前記ヘッダー部分内の前記データの一致は、更なるデータの比較として検査される、請求項８項記載の方法。
【請求項１０】
現行セグメントは、所定の時間内にリフレッシュされない場合、無効であるとして拒否される、請求項１乃至９の何れか１項記載の方法。
【請求項１１】
セグメントの前記データは、信頼性の低いデータリンクを介して、「ユーザー・データグラム・プロトコル」に従い、特に１つ又は複数のＵＤＰパケットの形式で送信される、前記請求項の何れか１項記載の方法。
【請求項１２】
前記データレコードは、ＤＶＢ−ＩＰＩ規格によるＳＤ＆Ｓデータに対応し、ＤＶＢ−ＩＰＩは、デジタル・ビデオ・ブロードキャスティング・「トランスポート・オブ・ディー・ブイ・ビー・サービシーズ・オーバー・アイ・ピー」の略であり、及びＳＤ＆Ｓは、「サービス・ディスカバリー・アンド・セレクション」の略である、前記請求項の何れか１項記載の方法。
【請求項１３】
前記請求項の何れか１項記載の方法を実行する装置であって、データを受信／送信する通信インターフェースを有し、前記通信インターフェースを介し受信されたデータレコードのセグメントを更新する手段を有し、前記セグメントは、バージョン番号により識別され、
前記セグメントを更新する手段は、前記値の範囲が周期的に進むことを考慮し、現行バージョン番号に基づき、前記バージョン番号の値の範囲を、範囲「古い」及び「新しい」に分類し、
前記セグメントを更新する手段は、新たな受信セグメントのバージョン番号が存在する範囲に関する検査を実行し、
前記セグメントを更新する手段は、前記検査が、前記新たな受信セグメントのバージョン番号は前記範囲「新しい」に存在すると判明した場合、前記新たな受信セグメントを、現行セグメントとして受け付け、及び
前記セグメントを更新する手段は、前記検査が、前記新たな受信セグメントのバージョン番号は前記範囲「古い」に存在すると判明した場合、前記新たな受信セグメントを拒否する、
ことを特徴とする、装置。
【請求項１４】
前記セグメントを更新する手段は、前記新たな受信セグメントのバージョン番号が、前記現行セグメントのバージョン番号と一致する場合、前記新たな受信セグメントの更なるデータを前記現行セグメントのデータと比較し、及び
前記セグメントを更新する手段は、前記更なるデータの比較が、前記比較されたデータは一致すると判明した場合、前記新たな受信セグメントを前記現行セグメントの有効なリフレッシュとして受け付ける、
ことを特徴とする、請求項１３記載の装置。
【請求項１５】
前記セグメントを更新する手段は、前記更なるデータの比較が、前記比較されたデータは一致しないと判明した場合、前記新たな受信セグメントを無視する、
ことを更に特徴とする、請求項１４項記載の装置。
【請求項１６】
前記セグメントを更新する手段は、前記更なるデータの比較が、前記比較されたデータは一致しないと判明した場合、前記新たな受信セグメントを現行セグメントとして受け付ける、
ことを更に特徴とする、請求項１４項記載の装置。
【請求項１】
データレコードのセグメント更新方法であって、データレコードを単一のセグメントで構成可能であり、前記セグメントは、バージョン番号により識別され、前記バージョン番号のために限られた値の範囲が利用可能であり、及び前記値の範囲は、周期的に進み、
−前記値の範囲が進む周期性を考慮し、現行バージョン番号に基づき、前記バージョン番号の前記値の範囲を範囲「古い」及び「新しい」に分類する段階、
−新たな受信セグメントのバージョン番号が存在する範囲を検査する段階、
−前記検査が、前記新たな受信セグメントのバージョン番号は前記範囲「新しい」に存在すると判明した場合、前記新たな受信セグメントを、現行セグメントとして受け付ける段階、
−前記検査が、前記新たな受信セグメントのバージョン番号は前記範囲「古い」に存在すると判明した場合、前記新たな受信セグメントを拒否する段階、
を特徴とする、データレコードのセグメント更新方法。
【請求項２】
前記範囲「古い」及び「新しい」への範囲分類は、動的に適応される、請求項１記載の方法。
【請求項３】
前記動的な範囲分類は、前記範囲「古い」及び「新しい」が観察されたセグメントの変化頻度に基づき、増大又は減少されるよう、実施される、請求項２記載の方法。
【請求項４】
前記変化頻度の観察時間期間は、伝送路の知られている又は推定された／測定された伝搬時間差により予め定められる、請求項３記載の方法。
【請求項５】
−前記新たな受信セグメントのバージョン番号が、現行有効セグメントのバージョン番号と一致する場合、前記新たな受信セグメントの更なるデータを前記現行有効セグメントのデータと比較する段階、
−前記更なるデータの比較が、前記比較されたデータは一致すると判明した場合、前記新たな受信セグメントを有効なリフレッシュとして受け付ける段階、
を更に特徴とする、請求項１乃至４の何れか１項記載の方法。
【請求項６】
−前記更なるデータの比較が、前記比較されたデータは一致しないと判明した場合、前記新たな受信セグメントを無視する段階、
を更に特徴とする、請求項５項記載の方法。
【請求項７】
−前記更なるデータの比較が、前記比較されたデータは一致しないと判明した場合、前記新たな受信セグメントを現行セグメントとして受け付ける段階、
を更に特徴とする、請求項５項記載の方法。
【請求項８】
セグメントは、ヘッダー部分及びペイロードデータ部分を有する１つ又は複数のデータパケットの形式で送信される、請求項１乃至７の何れか１項記載の方法。
【請求項９】
前記ヘッダー部分内の前記データの一致は、更なるデータの比較として検査される、請求項８項記載の方法。
【請求項１０】
現行セグメントは、所定の時間内にリフレッシュされない場合、無効であるとして拒否される、請求項１乃至９の何れか１項記載の方法。
【請求項１１】
セグメントの前記データは、信頼性の低いデータリンクを介して、「ユーザー・データグラム・プロトコル」に従い、特に１つ又は複数のＵＤＰパケットの形式で送信される、前記請求項の何れか１項記載の方法。
【請求項１２】
前記データレコードは、ＤＶＢ−ＩＰＩ規格によるＳＤ＆Ｓデータに対応し、ＤＶＢ−ＩＰＩは、デジタル・ビデオ・ブロードキャスティング・「トランスポート・オブ・ディー・ブイ・ビー・サービシーズ・オーバー・アイ・ピー」の略であり、及びＳＤ＆Ｓは、「サービス・ディスカバリー・アンド・セレクション」の略である、前記請求項の何れか１項記載の方法。
【請求項１３】
前記請求項の何れか１項記載の方法を実行する装置であって、データを受信／送信する通信インターフェースを有し、前記通信インターフェースを介し受信されたデータレコードのセグメントを更新する手段を有し、前記セグメントは、バージョン番号により識別され、
前記セグメントを更新する手段は、前記値の範囲が周期的に進むことを考慮し、現行バージョン番号に基づき、前記バージョン番号の値の範囲を、範囲「古い」及び「新しい」に分類し、
前記セグメントを更新する手段は、新たな受信セグメントのバージョン番号が存在する範囲に関する検査を実行し、
前記セグメントを更新する手段は、前記検査が、前記新たな受信セグメントのバージョン番号は前記範囲「新しい」に存在すると判明した場合、前記新たな受信セグメントを、現行セグメントとして受け付け、及び
前記セグメントを更新する手段は、前記検査が、前記新たな受信セグメントのバージョン番号は前記範囲「古い」に存在すると判明した場合、前記新たな受信セグメントを拒否する、
ことを特徴とする、装置。
【請求項１４】
前記セグメントを更新する手段は、前記新たな受信セグメントのバージョン番号が、前記現行セグメントのバージョン番号と一致する場合、前記新たな受信セグメントの更なるデータを前記現行セグメントのデータと比較し、及び
前記セグメントを更新する手段は、前記更なるデータの比較が、前記比較されたデータは一致すると判明した場合、前記新たな受信セグメントを前記現行セグメントの有効なリフレッシュとして受け付ける、
ことを特徴とする、請求項１３記載の装置。
【請求項１５】
前記セグメントを更新する手段は、前記更なるデータの比較が、前記比較されたデータは一致しないと判明した場合、前記新たな受信セグメントを無視する、
ことを更に特徴とする、請求項１４項記載の装置。
【請求項１６】
前記セグメントを更新する手段は、前記更なるデータの比較が、前記比較されたデータは一致しないと判明した場合、前記新たな受信セグメントを現行セグメントとして受け付ける、
ことを更に特徴とする、請求項１４項記載の装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２００７−１４３１５６（Ｐ２００７−１４３１５６Ａ）
【公開日】平成１９年６月７日（２００７．６．７）
【国際特許分類】
【出願番号】特願２００６−３０９２８０（Ｐ２００６−３０９２８０）
【出願日】平成１８年１１月１５日（２００６．１１．１５）
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】４６ Ｑｕａｉ Ａ． Ｌｅ Ｇａｌｌｏ， Ｆ−９２１００ Ｂｏｕｌｏｇｎｅ−Ｂｉｌｌａｎｃｏｕｒｔ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
【公開日】平成１９年６月７日（２００７．６．７）
【国際特許分類】
【出願日】平成１８年１１月１５日（２００６．１１．１５）
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】４６ Ｑｕａｉ Ａ． Ｌｅ Ｇａｌｌｏ， Ｆ−９２１００ Ｂｏｕｌｏｇｎｅ−Ｂｉｌｌａｎｃｏｕｒｔ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
[ Back to top ]