JP2023551520A - Ｒ－ｍａｃｐｈｙデバイスを使用した部分的なビデオ非同期サポート - Google Patents

Abstract

Ｒ－ＭＡＣＰＨＹデバイスが非同期モードで動作しながらビデオコアからビデオデータを受信する際に、Ｒ－ＭＡＣＨＰＨＹデバイスからビデオコアに対してタイミング情報を提供するためのシステムおよび方法。いくつかの実施形態では、Ｒ－ＭＡＣＰＨＹデバイスは、同期モードと非同期モードとの間にわたって切り替わるよう、動作モードを切り替えて選択的に構成し得るとともに、非同期モードへと切り替わる時にはタイミング情報をビデオコアに対して提供してもよい。【選択図】図１

Description

関連出願の相互参照
この出願は、２０２１年３月３０日付けで出願された米国仮特許出願第６３／１６８，０３２号明細書、および２０２０年１２月１日付けで出願された米国仮特許出願第６３／１１９，９５４号明細書の優先権を主張するものであり、両方の文献は、それらの全体が参照により本明細書に援用される。

この出願の主題は、一般に、ハイブリッドＣＡＴＶネットワークの分散型アクセスアーキテクチャ（ＤＡＡ）を使用したビデオコンテンツの配信に関し、より詳細には、ケーブルモデム終端システムの機能を、コアと、リモートＰＨＹデバイスまたはリモートＭＡＣＰＨＹデバイスなどのリモートデバイスでありかつコアに対して同期したリモートデバイスと、の間にわたって分散させるアーキテクチャに関する。

ケーブルテレビジョン（ＣＡＴＶ）ネットワークは、元々は、専用のＲＦ伝送システムを使用して長距離にわたって加入者に対してコンテンツを配信していたけれども、現在のＣＡＴＶ伝送システムは、ＲＦ伝送経路の多くをより効率的な光ネットワークによって置き換えることで、ケーブルコンテンツが同軸ケーブル上でＲＦ信号として終端するもののコンテンツ提供者と加入者との間における大部分の距離にわたって光信号を使用して伝送されるハイブリッド伝送システムを構築した。具体的には、ＣＡＴＶネットワークは、コンテンツ提供者のところに、コンテンツの多くのチャネルを表す信号を受信するための、そして、それら信号を多重化するための、さらに、光ファイバネットワークに沿って、加入者グループに対してそれぞれ近接した一つまたは複数のノードに対してそれら信号を分配するための、ヘッドエンドを含む。その後、ノードは、受信した光信号を多重化解除することで、ＲＦ信号へと変換し、これにより、視聴者が受信し得るものとする。ヘッドエンド内における、加入者に対してビデオチャネルを提供するシステムは、典型的には、ＨＦＣネットワーク上へと出力される前に結合されて多重化されることとなる異なる周波数帯域で動作する複数のＥｄｇｅＱＡＭユニットを含む。

歴史的に、ヘッドエンドは、また、ケーブル加入者に対して、ビデオ、ケーブルインターネット、ボイスオーバーインターネットプロトコル、等の高速データサービスを提供するために使用される別個のケーブルモデム終端処理システム（ＣＭＴＳ）も含んでいた。典型的には、ＣＭＴＳは、イーサネット（登録商標）インターフェース（または、他のより従来的な高速データインターフェース）と、ＲＦインターフェースと、の両方を含むこととなり、これにより、インターネットから来るトラフィックは、イーサネット（登録商標）インターフェースを通して、ＣＭＴＳを通して、次いでケーブル会社のハイブリッドファイバ同軸（ＨＦＣ）システムに対して接続された光ＲＦインターフェース上へと、ルーティング（または、ブリッジ）することができる。ダウンストリームトラフィックは、ＣＭＴＳから加入者宅のケーブルモデムへと配信され、他方、アップストリームトラフィックは、加入者宅のケーブルモデムからＣＭＴＳへと戻るように配信される。多くの現在のＨＦＣ ＣＡＴＶシステムは、コンバージドケーブルアクセスプラットフォーム（ＣＣＡＰ）と称される単一のプラットフォームにおいて、ＣＭＴＳの機能を、ビデオ配信システム（ＥｄｇｅＱＡＭ）と組み合わせてきた。

ネットワークが拡大し、それに応じてヘッドエンドが機器でますます混み合うようになるにつれて、多くのコンテンツ提供者は、近年、分散型アーキテクチャを使用することにより、ＣＭＴＳ／ＣＣＡＰの機能をネットワーク全体に広げてきている。この分散型アーキテクチャは、ケーブルのデータおよびビデオ信号を可能な限りデジタル形式で保持し、ＣＭＴＳ／ＣＣＡＰを超えてネットワークの深部にまでデジタル信号を拡張してから、デジタル信号をＲＦへと変換する。このことは、ヘッドエンドとアクセスネットワークとの間におけるアナログリンクを、デジタルファイバ（イーサネット（登録商標）／ＰＯＮ）接続によって置き換えることによって、行われる。

このような分散型アーキテクチャの一つは、リモートＰＨＹ（Ｒ－ＰＨＹ）分散型アクセスアーキテクチャであり、これは、従来的なＣＭＴＳまたはＣＣＡＰの物理層（ＰＨＹ）を、ネットワークのファイバノードに対して押し込むことにより、再配置するものである。よって、ＣＭＴＳ／ＣＣＡＰ内のコアが、上位層の処理を実行する一方で、ノード内のＲ－ＰＨＹデバイスは、コアが送信したダウンストリームデータを、無線周波数で伝送されるようデジタルからアナログへと変換するとともに、ケーブルモデムが送信したアップストリームＲＦデータを、コアに対して光学的に伝送されるようアナログからデジタル形式へと変換する。別の分散型アクセスアーキテクチャは、リモートＭＡＣ ＰＨＹ（Ｒ－ＭＡＣＰＨＹ）であり、このＲ－ＭＡＣＰＨＹは、従来的なＣＭＴＳの物理層をネットワーク内へと押し込むだけでなく、輸送ストリームのデータリンク層を構成する二つの層の一つをなすメディアアクセス制御（ＭＡＣ）層の機能を、リモートＭＡＣＰＨＹデバイス（ＲＭＤ）と称されるネットワーク内の一つまたは複数のノードに対して割り当てることも行う。

しかしながら、ＣＭＴＳ／ＣＣＡＰの機能が、ヘッドエンドのコアとネットワーク全体の様々なＰＨＹデバイスまたはＭＡＣＰＨＹデバイスとの間で分割されると、ネットワーク全体を通して通信される再構成済みビデオデータのタイミングを正確に保存するために、プロトコルが確立されなければならない。通信されるビデオデータのタイミングを正確に保存するための一つの典型的な構成は、ネットワーク内の様々なデバイスのクロックが同期していることを確保することである。図１は、例えば、ＣＣＡＰコア１４と、一つまたは複数の「顧客構内機器（ＣＰＥ）」デバイス１８に対して接続されているＲＰＤ１６と、の間における同期を提供する例示的なトポロジ１０を示しているけれども、例えばコアとＲＭＤとの間において同様のトポロジを使用し得ることに留意されたい。タイミンググランドマスタデバイス１２は、ＣＣＡＰコア１４とＲＰＤ１６との両方に対して、タイミング情報を提供する。具体的には、タイミンググランドマスタ１２は、ＣＣＡＰコア１４内のスレーブクロック２２に対して接続された第一マスタポート２０ａと、ＲＰＤ１６内のスレーブクロック２４に対して接続された第二マスタポート２０ｂと、を有しているけれども、代替的には、ＣＣＡＰコア１４およびＲＰＤ１６のそれぞれのスレーブクロックが、両方とも、タイミンググランドマスタデバイス１２内の単一のマスタポートに対して接続されてもよい。ＣＣＡＰコア１４は、一つまたは複数のスイッチ２６を介してタイミンググランドマスタ１２に対して接続されてもよく、他方、ＲＰＤ１６は、一つまたは複数のスイッチ２８を介してタイミンググランドマスタ１２に対して接続されてもよい。図１は、タイミンググランドマスタ１２に対して接続されたただ一つのＲＰＤ１６を示しているけれども、多数のそのようなＲＰＤが、同時にグランドマスタ１２に対して接続されてもよく、その場合、各ＲＰＤは、グランドマスタクロック１２内のポート２０ｂからタイミング情報を受信するスレーブクロック２４を有している。

コア１４とＲＰＤ１６との両方がタイミンググランドマスタ１２に対してロックされている間は、大きな問題は発生しないけれども、ＲＰＤ１６またはコア１４のいずれかがタイミンググランドマスタ１２に対しての接続を失った時には、問題が発生することとなる。一方または両方のデバイスがグランドマスタ１２のタイミングクロックに対して接続されていないそのようなホールドオーバー期間では、接続されていないデバイスは、タイミンググランドマスタ１２から、および他方のデバイスから、周波数と位相とに関してドリフトすることとなる。そのドリフトの大きさは、ホールドオーバー期間の長さ、温度変動、内部発振器の性能、等を含めて、多くの要因に依存することとなる。例えば、典型的なＴＣＸＯ発振器を搭載したＲＰＤでは、一時間以内であっても、位相が１ｍｓにわたってドリフトすることがあり得る。コアは、通常はより優れた発振器を有していて、温度管理された環境にあることのために、典型的には、ＲＰＤのドリフトは、コアのドリフトよりも悪化する。ドリフトが発生するホールドオーバー期間が充分な持続時間であれば、ビデオの品質が、許容し得ないレベルにまで低下することとなる。

代替可能な非同期アーキテクチャは、コアと、ＲＰＤｓおよびＲＭＤｓなどのダウンストリームデバイスと、の間の同期に依存するものではないけれども、これらのアーキテクチャは、より複雑な処理を伴うものであるとともに、データパケットの低下をもたらすことが多い。

したがって、分散型アクセスアーキテクチャで伝送されるビデオデータに関連したタイミング情報を正確に保存するための、改良されたアーキテクチャおよび改良された方法が要望されている。

本発明をより良好に理解するために、また、本発明がどのように実施され得るかを示すために、以下では、例示として添付図面を参照することとする。

図１は、ＣＣＡＰコアとそのＲＰＤとの両方が外部グランドマスタクロック（ＧＭ）のタイミングスレーブである例示的なＲ－ＰＨＹシステムを示している。

図２は、ビデオコアが同期モードでＲＰＤに対してビデオデータを伝送するアーキテクチャを示している。

図３は、図２のビデオコアが非同期モードで図２のＲＰＤに対してビデオデータを伝送するアーキテクチャを示している。

図４は、図２および図３のアーキテクチャが同期モードと非同期モードとの間にわたって動的に移行するための例示的な方法を示している。

図５は、部分的に非同期モードで動作する例示的なＲＭＡＣＰＨＹアーキテクチャを示している。

上述したように、ビデオコンテンツを配信するための分散型アクセスアーキテクチャでは、ビデオ処理に関する二つのモードが、すなわち同期モードおよび非同期モードが、使用され得る。典型的には、ネットワークデバイスは、いずれかのモードで動作可能なハードウェアを有しており、その場合、ビデオチャネルを設定する際に、ビデオコア自体が、および接続されたダウンストリームデバイスが、それらモードのいずれかへと切り替えるように構成することを可能とし得るソフトウェアが設けられている。同期（ｓｙｎｃ）モードでは、ＲＰＤ（またはＲＭＤ）と、そのビデオコアとは、同じ基準クロックに対して、時間的に同期している。この同期モードでは、ＲＰＤは、レイヤー２トンネリングプロトコルｖ．３（Ｌ２ＴＰｖ３）のシーケンス番号モニタリングを使用して、失われたビデオパケットを検出するとともに、各欠落パケットに対してＭＰＥＧヌルパケットを挿入すること、だけが必要である。これは、ビデオストリームに何らの追加的な修正を加える必要がない比較的単純な実装である。

図２は、例えば、ビデオコア１０２が共通のグランドマスタタイミングサーバ１０６を使用して同期モードでＲＰＤ１０４に対して通信している第一構成１００におけるシステムを示している。タイミングサーバ１０６は、ビデオコア１０２内のクロック１０８とＲＰＤ１０４内のクロック１１０との両方に対して、同一のタイミングロック（すなわち、周波数および位相）を維持している。ビデオコア１０２は、Ｌ２ＴＰｖ３を使用してダウンストリーム外部ＰＨＹインターフェース（ＤＥＰＩ）を介してＲＰＤ１０４に対してビデオデータパケットを転送するビデオストリーマ１１２を有している。ビデオコア１０２からＲＰＤ１０４へと送信されたビデオパケットは、典型的には、プログラム識別子（ＰＩＤｓ）、プログラムクロックリファレンス（ＰＣＲ）データ、等の、パケット化されたエレメンタリビデオ輸送ストリームを復号するのに必要なすべての情報を、含むこととなる。

ＲＰＤ１１０は、次に、処理デバイス１１４のデジッタバッファ１１６内に、ビデオコア１０８から送信されたビデオパケットを受信する。デジッタバッファ１１６は、受信したパケットデータの異なる経路に起因する、またはビデオコアとＲＰＤとの間におけるネットワーク遅延を変動させる他のソースに起因する、ネットワークジッタを除去する速度で、パケットデータを受信して出力する。ビデオストリーマ１１２が送信したいくつかのパケットが、ＲＰＤ１０４に対する輸送時に失われたりまたは誤配置されたりし得ることのために、デジッタバッファ１１６から出力されたパケットは、好ましくは、同期モードの場合に伝送されたビデオの適切なタイミング速度を維持するようそれら失われたパケットを考慮してデータストリーム内にヌルパケットを挿入するモジュール１１８へと、転送されてもよい。ヌルパケットが適宜に挿入された状態での輸送ストリームは、その後、ＰＨＹデバイス１２０へと転送され、このＰＨＹデバイス１２０は、セットトップボックスなどの顧客構内機器が予想するフォーマットでＱＡＭ変調済みデータを出力することによるエンドユーザに対してのダウンストリーム配信のために、パケット化されたエレメンタリストリームを、復号済みビデオフレームからなるシーケンスへと、復号してもよい。代替的には、ＰＨＹデバイスは、コンピュータ、タブレット、携帯電話、等のユーザ機器による復号のために、パケット化されたデータを復号することなく、例えばケーブルモデムに対して、パケット化されたデータを転送するだけでもよい。

代替的には、ここで説明したシステムは、非同期（ａｓｙｎｃ）モードで動作するように構成されてもよい。非同期モードでは、ＲＰＤ１０４と、そのビデオコア１０２とは、同じ基準クロックに対して、時間的に同期していない。その代わりに、ＲＰＤ１０４は、自身のクロック１１０とビデオコア１０２のクロック１０８との間の差を検出する必要があるとともに、予想されるＭＰＥＧビットレートを維持するために必要に応じてＭＰＥＧパケットを挿入したり除去したりすることが可能である必要があり、さらに、ＭＰＥＧパケットの除去／挿入に基づくＭＰＥＧ ＰＣＲ値を調整する必要がある。

図３は、例えば、代わりに非同期モードで動作するように構成された図２のハードウェアを示している。この構成１０１では、ビデオコア１０２のクロック１０８と、ＲＰＤ１０４のクロック１１０とは、同期しておらず、そのため、互いに対してドリフトする可能性がある。ビデオコア１０２のビデオストリーマ１１２は、パケット化されたビデオデータエレメンタリストリームのパケットを、ＲＰＤ１０４へと転送し、ＲＰＤ１０４は、この場合にも、デジッタバッファ１１６内にデータを受信するとともに、上述したように、ネットワークジッタを除去する。しかしながら、図２の構成とは異なり、デジッタバッファ１１６から出力されたパケットは、デジッタバッファ１１６から受信したデータのビットレートを適正にかつ一定に維持するよう、必要に応じてヌルパケットを追加することと、必要に応じてパケットをドロップすることと、の両方を行うモジュール１１８へと、転送される。さらに、必要に応じてパケットが追加／ドロップされた後に、ＰＣＲモジュール１１９は、ＭＰＥＧパケットの除去／挿入に基づいて更新されたＰＣＲｓによってデータパケットを再スタンプし、その後、再スタンプされたパケットを、ＰＨＹデバイス１２０へと転送する。

図２および図３２に示すシステム１００および１０１は、例示の目的のために、ビデオコア１０２に対して接続されたＲＰＤ１０４を使用して示されているけれども、当業者であれば、ＲＭＤｓも、また、ビデオコア１０２に対して接続され得ること、および、ＲＰＤ１０４に関して示したものと同じ構成要素を、ＲＰＤ１０４と同じ態様で動作させ得ることは、理解されよう。

同期での動作モードと非同期での動作モードとのそれぞれには、利点および欠点が存在する。非同期モードに関して、主要な利点は、ビデオコア１１２とＲＰＤ１１４との間におけるクロック同期に依存しないことであり、そのため、ＲＰＤ１１４は、それらのクロック差を検出するとともに、それに応じてＭＰＥＧ出力を「修正」することとなる。非同期モードの主要な欠点は、このモードが、同期モード時にＲＰＤ１１４内で発生するビデオ処理に関してより複雑であることであり、また、タイミングの不一致を修正する目的で、ＲＰＤ１１４が、入力ストリームからＭＰＥＧパケットを時々ドロップする必要があることである。この悪影響は、ビデオコアがストリームに対してヌルパケットを追加することでＲＰＤがパケットをドロップする必要がある時にＲＰＤがヌルパケットを手元に置くようにするのであれば軽減され得るけれども、この選択肢は、データストリームに対して不要な帯域幅を追加するものであり、および／またはビデオ品質に対して悪影響を与えるものであり、多くの場合、ビデオコアは、データ搬送パケットのドロップの必要性を完全に排除するほどには充分なヌルパケットを追加することがない。

同期モードの場合、主要な利点は、ＲＰＤが入力ビデオストリームと内部クロックとの間における変化を追跡する必要がなく、検出された入力パケットの欠落の場合にＭＰＥＧヌルパケットを追加することによって出力のところで一定のビットレートを維持すること以外には、ＭＰＥＧ修正を何ら適用する必要がないため、ＲＰＤのビデオ処理が単純であることである。同期モードの主要な欠点は、ＲＰＤとビデオコアとの間におけるクロック同期に依存していることである。ビデオコアおよび／またはＲＰＤがグランドマスタクロックに対する接続を失うことが多くはないため、この仮定は、通常は有効ではあるけれども、そのような接続が失われる場合も存在し、そうではない場合でも、例えばグランドマスタクロックに対するタイミングメッセージにおけるネットワーク遅延の相違に基づいて、あるいは、コアまたはＲＰＤのいずれかに関する内部問題に基づいて、コアとＲＰＤとのクロックどうしが充分に同期されない場合があり得る。これらの実例のいずれにおいても、同期モードのＲＰＤが、ＭＰＥＧ ＰＣＲｓを何ら調整しないこととなるので、クロック差は、ＲＰＤの不正なＭＰＥＧストリームアウトを引き起こし得るものであり、ビデオ品質に関する観察可能な劣化をもたらす可能性がある。

いくつかの好ましい実施形態では、図２および図３に図示したシステムは、デジッタバッファ１１６から取得された情報に基づいて、ＲＰＤ１０４を、同期モードから非同期モードへと、動的にシフトさせてもよい。そのような実施形態では、ＲＰＤは、条件付きイベントがトリガされるまで、初期設定で図２に示すような同期モードで動作するように構成されてもよく、その後、ＲＰＤ１０４は、図３に示すような非同期モードへと切り替わる。ＲＰＤ１０４は、その後、第二条件付きイベントが検出されるまで非同期モードのままであることとなり、その後、ＲＰＤ１０４は、図２に示すような同期動作へと復帰するように変化することとなる。

いくつかの実施形態では、（一つまたは複数の）条件付きイベントは、デジッタバッファ１１６の状態に関する測定に基づいてもよい。よって、例えば、ＲＰＤ１０４は、好ましくは、測定に基づく第一閾値を実装してもよく、それを超えると、ビデオストリームが同期していないと見なされる。閾値は、多くの異なる方法で定義することができる。例えば、適切な第一閾値は、事前定義された標準動作レベルからの、バッファの満杯状態における最大平均変化（プラスまたはマイナス）とすることができる。したがって、ＲＰＤ１０４は、バッファの満杯状態を測定してもよく、いくつかの実施形態では、任意選択的にそれを平均化してもよく、あるいは、ネットワークジッタの一時的なスパイクを除去するためのフィルタを適用してもよく、測定値が変化の事前定義された第一閾値を超える場合には、ストリームは、同期していないと見なされる。好ましい実施形態における例示的なそのような第一閾値は、±２５％であってもよい。いくつかの好ましい実施形態では、この第一閾値は、設定可能であってもよい。

代替可能な閾値は、バッファが満杯になる／空になる速度を測定した値であってもよい。ＲＰＤ１０４は、ネットワークジッタに基づく一過性の変化を除去するためにこの場合にも任意選択的にフィルタリングすることによって、そのようなメトリックを測定してもよい。変化率が事前定義された閾値を超えた場合、ビデオストリームは、同期していないと見なされる。

ＲＰＤ１０４は、また、好ましくは、非同期モードから同期モードへと戻るよう動的に移行するための、第二閾値を実装してもよい。いくつかの実施形態では、第二閾値は、非同期モードへと移行するための第一閾値と同じであってもよいけれども、他の実施形態では、第一閾値と第二閾値とは、異なる。異なる閾値が使用される場合、第二閾値は、好ましくは、第一閾値と比較して、より厳格である。例えば、ＲＰＤが同期モードから非同期モードに動的に移行する限界として、±２５％の第一閾値が設定される上記の例を使用した場合、同期モードへと戻るよう動的に移行するために、±１５％の第二閾値が使用されてもよい。この場合にも、いくつかの好ましい実施形態では、第二閾値は、設定可能であってもよい。

いくつかの実施形態では、ＲＰＤ１０４が非同期モードで動作している時には、ヌルパケットが利用できない場合に「重要な」ＭＰＥＧパケットをドロップする確率を低減する目的で、ＲＰＤ１０４は、ドロップされるべきパケットの優先リスト（この場合、ヌルパケットは、ドロップされるべき優先順位で最初であり、次に、ＰＩＤ値のセット（例えば、ＳＩ ＰＩＤｓ、ＣＡＴ ＰＩＤ、等）である）を実装してもよい。不可欠なＭＰＥＧパケットをドロップする確率を低減するために、ＰフレームおよびＢフレームよりもＩフレームを優先すること、ＢフレームよりもＰフレームを優先すること、などの、他の方法を適用してもよい。代替可能な実装では、プログラム関連テーブル（ＰＡＴ）データまたはプログラムマッピングテーブル（ＰＭＴ）データなどのプログラム特定情報（ＰＳＩ）からなるビットストリームにおけるパケット速度を、ＭＰＥＧ標準によって許容される最小速度にまで動的に低減するための、優先順位ベースのアプローチが使用されてもよい。

非同期モードへの切り替わりが、バッファ状態が公称値または最適値から閾値の分だけ逸脱した後に行われることから、いくつかの実施形態では、ＲＰＤ１０４は、ジッタヘッドルームを維持する目的で、同期モードへと再び切り替わる前に、キューをその公称深さまたは最適深さへと「引き戻す」ことを決定してもよい。これは、例えば、第一閾値が低遅延のために小さな値に設定される場合に、適切であり得る。

図４は、ＲＰＤ１０４を同期モードと非同期モードとの間にわたって動的に切り替わり得る例示的な方法を示している。ステップ１３２では、ＲＰＤは、同期モードで動作するように構成される。ステップ１３４では、ＲＰＤ１０４の処理モードは、「同期」に設定される。決定ステップ１３６では、バッファ状態が、上述したように、第一閾値を超えているかどうかが決定される。答えが「いいえ」である場合には、方法は、ステップ１３８へと進み、ＲＰＤ１０４は、ビデオストリームを「同期」モードで処理し、次に、ステップ１４０へと進み、データが固定速度でバッファ１１６から出るかどうかが決定され、ステップ１４２へと進んで、ＰＨＹ１２０へと入る固定ビットレートを維持するために、必要に応じてヌルパケットが追加される。その後、手順は、ステップ１３６へと戻り、バッファ状態が第一閾値を超えているかどうかが、再び決定される。

ステップ１３６で、バッファ状態が第一閾値を超えていることが決定された場合には、方法は、次にステップ１４４へと進み、ＲＰＤ処理モードが、「非同期」に設定される。次に、ステップ１４６で、ヌルパケットが追加されあるいはパケットが削除され、さらに、ステップ１４８で、パケットに関するＰＣＲスタンプが、追加されたおよび削除されたパケットに基づいて、調整される。ステップ１４８では、パケットは、固定ビットレートでＰＨＹへと入る。

決定ステップ１５２では、バッファ１１６の状態が第二閾値を超えているかどうかが決定される。超えていない場合には、手順は、ステップ１４４へと戻る。超えている場合には、手順は、任意選択的なステップ１５４および１５６へと進み得る。決定ステップ１５４では、バッファを最適深さまたは公称深さへと戻す必要性があるかどうかが決定される。答えがいいえである場合には、システムは、ステップ１３４へと戻り、ＲＰＤ１０４の処理モードが、「同期」に設定される。答えが「はい」である場合には、ステップ１５６で、バッファがその公称深さまたは最適深さへと引き戻されるまで非同期モードが継続され、その後、手順は、上述したように、ステップ１３４へと戻る。

当業者であれば、図２～図４に関して説明したシステムおよび方法が、ＲＰＤに対して接続されたビデオコアを使用して例示されているけれども、上記の開示が、また、ビデオコアとＲＭＤとの間における通信に対しても適用されることは、理解されよう。しかしながら、ＲＰＤは、通常、そのタイミング情報を提供するために外部ソースに依存しなければならないけれども、ＲＭＤは、典型的には、ＲＭＤ内の独立したクロックを動作させるための独自の発振器を有したハードウェア構成要素を含む。よって、上述したようなものなどのネットワークが、一つまたは複数のＭＡＣＰＨＹデバイスを含む場合には、本出願は、いくつかの実施形態では上記のシステムおよび方法と組み合わせて使用し得るような、あるいは代替可能な実施形態では、ＲＭＤｓおよびＲＰＤｓなどのリモートデバイスが同期モードと非同期モードの間にわたって動的に切り替えられないシステムあるいは方法において使用し得るような、追加的なかつ部分的な非同期モードを開示している。

具体的には、非同期モードで動作するＲＰＤまたはＲＭＤなどのダウンストリームネットワークデバイスは、理論的には自身とコアとの間におけるクロック差を検出するとともに、それに応じてＭＰＥＧ出力を「修正」するけれども、これが機能するためには、ビデオコアとＲＭＤとの両方が、ＭＰＥＧ準拠クロック（約３０ＰＰＭ精度および約１０ＰＰＭ／時間ドリフト）を維持するのに充分な品質の発振器を有していなければならない。ＲＭＤｓは、ハードウェアで構築されたプラットフォームであるため、ＭＰＥＧビデオ配信よりも厳格なクロック要件を有したデータオーバーケーブルサービスインターフェース仕様（ＤＯＣＳＩＳ）動作のために、これらの要件を満たす発振器を有することが一般的である。しかしながら、ビデオコアは、オフザシェルフ（ＯＴＳ）サーバ内に内蔵された発振器を使用して単にソフトウェアベースで実装されている場合が多く、必要な精度をサポートし得ない。このような場合、ビデオコアは、そのクロックのために依存する外部ＧＭを必要とするため、非同期モードで動作することの利点が、排除される。

したがって、図５を参照すると、システム２００は、一つまたは複数のＲＭＤｓ２０４ａ、２０４ｂ、２０４ｃ、等に対して接続されたビデオコア２０２を含んでもよく、ＲＭＤｓのそれぞれは、好ましくは、ＲＰＤ１０４に関して図３に示した構成要素を有して構成されてもよく、すなわち、一つまたは複数のＲＭＤｓのそれぞれには、デジッタバッファ２１６と、ヌルパケット挿入／パケット除去およびＰＣＲ調整をそれぞれ提供するためのモジュール１１８および１１９と、ダウンストリームＰＨＹ２２０と、クロック２１０と、が設けられてもよい。また、図５には、ＲＭＤｓだけが示されているけれども、当業者であれば、システム２００が、また、一つまたは複数のＲＰＤｓを含み得ることは、理解されよう。

上述したように、いくつかの実施形態では、ビデオコア２０２がタイミンググランドマスタに対する接続を失った時に、ＲＭＤｓ２０４ａ、２０４ｂ、および２０４ｃ（ならびに、ネットワーク内の任意のＲＰＤｓ１０４）は、好ましくは、ビデオコア２０２から受信したビデオパケットの処理を継続するよう、上述したように非同期モードで動作するように構成されてもよい。しかしながら、非同期モードで信頼性高く動作するためには、コア２０２は、適切な内部クロックを必要とするけれども、それが設けられていないことがあり得る。そのような実例では、コア２０２は、ＲＭＤｓ２０４ａ、２０４ｂ、または２０４ｃの一つを、指定されたグランドマスタとして使用することで、自身のクロックが生成し得るものと比較して、より信頼性の高いタイミング情報を提供してもよく、それは、ＲＭＤｓには、典型的には、ＭＰＥＧビデオ符号化および伝送のための要件を満たす発振器が設けられているからである。図５では、例えば、ＲＭＤ２０４ａのクロック２１０が、指定されたグランドマスタとして作用しており、クロック同期メッセージ２２２を、コア２０２に対して送信している。好ましい実施形態における同期メッセージは、ＲＭＤ２０４ａのクロック２１０から、ビデオコアのクロック２０８へと、送信される。好ましくは、各ＲＭＤ２０４ａ、２０４ｂ、２０４ｃ、等は、例えば、ビデオコア２０２と、指定されたグランドマスタとして以前に作用していた任意のＲＭＤと、の間の接続が失われた場合に、指定されたグランドマスタとして作用することができる。

この「部分的非同期」モードでは、ビデオコア２０２は、好ましくは、任意の「通常の」グランドマスタタイマに対するように指定ＲＭＤ２０４ａに対してロックを実行し、そのＭＰＥＧクロックおよびＰＣＲを、指定ＲＭＤ２０４ａから基礎付ける。指定ＲＭＤ２０４ａは、好ましくは、ビデオコアのクロック２０８を、自身のクロック２１０に対して同期させるだけでもよいけれども、その他の場合には、すべての他のＲＭＤｓ２０４ｂ、２０４ｃ、等と同様に、およびネットワーク内の任意のＲＰＤｓ１０４と同様に、非同期モードで動作することとなる。指定ＲＭＤ２０４ａとビデオコア２０２との間におけるクロック同期の唯一の目的は、ビデオコア２０２に対して、信頼性の高いＭＰＥＧ準拠クロックを提供することであり、他のＲＭＤｓ２０４ｂ、２０４ｃ、等が好ましくは非同期モードで動作することのために、それら他のＲＭＤｓをそのクロックに対してロックする必要はない。また、指定ＲＭＤ２０４ａは、それ自身の発振器に依存し得るため、それ自身のクロックをロックするために、指定ＲＭＤ２０４ａに対して、他の外部クロック基準を提供する必要もない。

非同期モード時にビデオコア２０２に関するタイミング情報の指定ソースとして機能するＲＭＤを選択するために、任意の適切な方法が使用されてもよい。一例として、専用のプロビジョニングサーバが、ビデオコア２０２をそれが指定するＲＭＤに対して接続するように、構成されてもよい。代替的には、各ＲＭＤｓ２０４ａ、２０４ｂ、２０４ｃ、等は、ビデオコア２０２に対してそのタイミング情報を送信するように非同期モードで構成されてもよく、ビデオコア２０２は、それ自体が、例えばベストマスタクロックアルゴリズム（ＢＭＣＡ）を使用して、指定されたグランドマスタとして使用するストリームを指定することとなる。

指定されたグランドマスタとして動作するためのＲＭＤを指定するためにどの方法が使用されるかにかかわらず、ビデオコア２０２のためのタイミングソースとして指定されたＲＭＤは、外部クロックにロックされていないため、例えば、指定ＲＭＤがリセットされたり、あるいは、オフラインになって別のＲＭＤをトリガして指定グランドマスタとして作用させたり、する場合には、ビデオコア２０２に対して送信される情報のタイミングベースは、突発的に変化することがあり得る。これは、それがＭＰＥＧストリーム内へと挿入するＰＣＲｓを「ジャンプ」させることとなり、ひいては、ＭＰＥＧストリームを受信するデコーダに問題を引き起こし得る。したがって、いくつかの好ましい実施形態では、ビデオ２０２コアは、タイムベースが変化したことを検出した時には、最初のＰＣＲパケット適応フィールド上に、適切な「不連続性インジケータ」フラグを設定してもよい。ＲＭＤｓ（または、ＲＰＤｓ）は、これにより、不連続性を除去するためにビデオストリームを再スタンプするＰＣＲを、調整してもよい。

非同期モードで動作しながらタイミング情報をビデオコアに対して送信するＲ－ＭＡＣＰＨＹデバイスに関する上記の開示は、同期モードまたは非同期モードで動作するようにＲ－ＭＡＣＰＨＹデバイスがそれ自体を動的に構成し得るシステムという文脈で説明したけれども、当業者であれば、図５の実施形態が他の状況でも同様に使用され得ることは、理解されよう。例えば、上記で注記したように、多くの場合、ＲＰＤｓおよびＲＭＤｓは、非同期モードおよび同期モードのいずれか一方に構成することができ、ビデオコアまたは他のネットワークデバイスは、単に、接続されたＲＰＤｓおよびＲＭＤｓを常に非同期モードで動作させるように構成し得る。このような状況であっても、図５に示すシステムは、有益であり得る。例えば、リモート接続されたデバイスが非同期モードで動作するように構成されつつも、ビデオコアが、外部グランドマスタからタイミング情報を受信していない場合には、一時的に接続を失うことのために、あるいは、単に外部グランドマスタからそのような情報を受信するように構成されていないことのために、自身の内部クロックが提供するものと比較して、ＲＭＤからより信頼性の高いタイミング情報を受信するという利点は、明らかである。

本発明が、説明した特定の実施形態に対して限定されるものではないこと、ならびに、その文字通りの範囲を超えて特許請求の範囲の実施可能範囲を拡大する均等論またはその他のいずれの原理を含む現行法の原則に従って解釈されるように、添付の特許請求の範囲で定義された本発明の範囲から逸脱することなくその変形がなされ得ることは、理解されよう。文脈が別の指示を示さない限り、構成要素の実例の数に対する特許請求の範囲の参照は、それが一つの実例への参照であろうと、または二つ以上の実例への参照であろうと、少なくとも記載された数の構成要素の実例を必要とするが、記載されているよりも多くの構成要素の実例を有した構造または方法を特許請求の範囲から除外することを意図するものではない。特許請求の範囲において使用された場合、「含む」という用語は、またはその派生語は、特許請求される構造または方法における他の構成要素またはステップの存在を除外することを意図するものではない非排他的な意味で使用される。

Claims (40)

1. リモートＭＡＣＰＨＹ（Ｒ－ＭＡＣＰＨＹ）デバイスであって、
   クロック、および、ビデオコアからビデオパケットを受信するデジッタバッファと、
   前記デジッタバッファから受信したビデオパケットを調整し得る少なくとも一つのモジュールであり、調整が、前記Ｒ－ＭＡＣＰＨＹデバイスが同期モードまたは非同期モードで動作するように構成されているかどうかに基づいて変更するものとされている、少なくとも一つのモジュールと、を含み、
   前記クロックは、タイミング情報を他のデバイスに対して選択的に出力するように構成可能であり、前記Ｒ－ＭＡＣＰＨＹデバイスが非同期モードで動作している時には、タイミング情報を他のデバイスに対して出力することを選択することが、選択的に発生するように構成されている、リモートＭＡＣＰＨＹ（Ｒ－ＭＡＣＰＨＹ）デバイス。
2. 前記少なくとも一つのモジュールは、非同期モードでは、前記デジッタバッファから受信したパケットを選択的にドロップする、請求項１に記載のデバイス。
3. 前記少なくとも一つのモジュールは、非同期モードでは、前記パケットに対してプログラムクロック基準（ＰＣＲ）値を選択的に再スタンプする、請求項１に記載のデバイス。
4. 前記ＰＣＲ値を再スタンプするためにオフセット値を選択的に使用するように構成されている、請求項３に記載のデバイス。
5. 前記他のデバイスは、前記ビデオコアである、請求項１に記載のデバイス。
6. 前記他のデバイスは、プロビジョニングサーバである、請求項１に記載のデバイス。
7. ビデオコアであって、
   少なくとも一つのリモートデバイスに対してビデオパケットを送信するように構成されたビデオストリーマであり、第一デバイスを含むビデオストリーマと、
   前記第一デバイスから同期情報を受信するように構成されているとともに前記同期情報を使用することで前記ビデオストリーマが前記複数のパケットを前記少なくとも一つのリモートデバイスに対して送信する速度を制御するように構成されている第一入力を有したクロックと、を含み、
   前記コアは、前記同期情報を前記少なくとも一つのリモートデバイスに送信することがなく、前記ビデオパケットは、ＰＣＲｓを含み、前記ビデオストリーマは、前記ＰＣＲｓに関連したオフセット値を送信するように構成されている、ビデオコア。
8. 複数の同期していない前記リモートデバイスから受信した同期情報の中から、前記第一デバイスからの同期情報を選択するように構成されている、請求項７に記載のビデオコア。
9. 複数の同期していない前記リモートデバイスのうち、プロビジョニングサーバによって選択された一つのデバイスから、情報を受信するように構成されている、請求項７に記載のビデオコア。
10. 通信ネットワーク内のデバイスであるとともに、ビデオコアから受信したＭＰＥＧ準拠輸送ストリームを受信して選択的に修正するデバイスであり、さらに、その後に前記輸送ストリームを顧客構内機器（ＣＰＥ）に対してダウンストリーム方向に送信するデバイスであって、前記デバイスは、前記デバイスと前記ビデオコアとの間における同期量を決定するように構成されているとともに、決定した前記同期量に基づいて同期モードと非同期モードとの選択的な一方へと自身を切り替えるように構成されている、デバイス。
11. リモート物理デバイス（ＲＰＤ）を含む、請求項１０に記載のデバイス。
12. リモートＭＡＣＰＨＹデバイス（ＲＭＤ）を含む、請求項１０に記載のデバイス。
13. 共通タイミングソースからタイミング情報を受信するように構成可能とされるとともに、前記タイミング情報を前記ビデオコアに対して提供することもしており、前記デバイスは、前記デバイスと前記ビデオコアとの少なくとも一方が前記共通タイミングソースに対するロックを失った時には、同期モードから非同期モードへと切り替わる、請求項１０に記載のデバイス。
14. 前記デバイスは、前記デバイスと前記ビデオコアとの、前記共通タイミングソースに対するロックを失った前記少なくとも一方が、前記共通タイミングソースに対するロックを回復した時には、非同期モードから同期モードへと切り替わる、請求項１３に記載のデバイス。
15. 共通タイミングソースからタイミング情報を受信するように構成可能とされるとともに、前記タイミング情報を前記ビデオコアに対して提供することもしており、前記デバイスは、前記デバイスと前記ビデオコアとの両方が前記共通タイミングソースに対するロックを維持している時には、同期モードから非同期モードへと一度に切り替わることができる、請求項１０に記載のデバイス。
16. デジッタバッファを有しており、前記デバイスは、前記デジッタバッファの出力に基づいて前記ＭＰＥＧ準拠輸送ストリームを修正する、請求項１０に記載のデバイス。
17. 前記デバイスは、前記デジッタバッファの出力を使用することで、前記同期量を決定する、請求項１６に記載のデバイス。
18. 前記デバイスは、決定された同期量に基づいて同期モードから非同期モードへと変化するように構成されているとともに、決定された同期量に基づいて非同期モードから同期モードへと変化するように構成されている、請求項１０に記載のデバイス。
19. 決定された前記同期量と、前記デバイス内のジッタバッファの、満杯の所定量からの満杯度合いに関する決定されたオフセットと、を使用して、非同期モードから同期モードに変化することができる、請求項１８に記載のデバイス。
20. システムであって、
    コアクロックとビデオストリーマとを有したビデオコアと、
    前記ビデオコアクロックに対して通信しているクロックと、前記ビデオストリーマからビデオパケットを受信するデジッタバッファと、前記デジッタバッファから受信したビデオパケットを調整し得る少なくとも一つのモジュールであり、調整が、前記Ｒ－ＭＡＣＰＨＹデバイスが同期モードまたは非同期モードで動作するように構成されているかどうかに基づいて変更するものとされている、少なくとも一つのモジュールと、を有したリモートＭＡＣＰＨＹ（Ｒ－ＭＡＣＰＨＹ）デバイスと、を含み、
    前記リモートクロックは、前記Ｒ－ＭＡＣＰＨＹデバイスが非同期モードで動作している際には、前記コアクロックに対してタイミング情報を選択的に提供する、システム。
21. 前記少なくとも一つのモジュールは、非同期モードでは、前記デジッタバッファから受信したパケットを選択的にドロップする、請求項２０に記載のシステム。
22. 前記少なくとも一つのモジュールは、非同期モードでは、前記パケットに対してプログラムクロック基準（ＰＣＲ）値を選択的に再スタンプする、請求項２０に記載のシステム。
23. 前記コアクロックは、前記Ｒ－ＭＡＣＰＨＹデバイスに対してオフセット値を選択的に送信するように構成されている、請求項２０に記載のシステム。
24. 方法であって、
    Ｒ－ＭＡＣＰＨＹデバイス内のリモートクロックから、ビデオコア内のコアクロックに対して、同期情報を送信することと、
    前記ビデオコア内のビデオストリーマから、前記ビデオコアからダウンストリーム側の少なくとも一つの物理（ＰＨＹ）デバイスでありかつ前記Ｒ－ＭＡＣＰＨＹデバイスを含む少なくとも一つのＰＨＹデバイスに対して、ビデオデータを送信することと、
    前記Ｒ－ＭＡＣＰＨＹデバイスを含めて前記少なくとも一つのＰＨＹデバイスを、非同期モードで動作させることと、を含む、方法。
25. 前記コアクロックは、前記Ｒ－ＭＡＣＰＨＹデバイスに対してオフセット値を選択的に送信するように構成されている、請求項２４に記載の方法。
26. 前記ビデオコアは、前記Ｒ－ＭＡＣＰＨＹデバイスから前記ビデオストリーマに対して前記同期情報を提供することで、前記ビデオストリーマからパケットが送信される速度を制御する、請求項２４に記載の方法。
27. 前記少なくとも一つの他のデバイスは、別のＲ－ＭＡＣＰＨＹデバイスを含む、請求項２６に記載の方法。
28. 前記Ｒ－ＭＡＣＰＨＹデバイスからのタイミング情報は、前記ビデオコアが前記ビデオストリーマに送信するための前記別のＲ－ＭＡＣＰＨＹデバイスからの前記タイミング情報よりも優先的に選択される、請求項２７に記載の方法。
29. 前記Ｒ－ＭＡＣＰＨＹデバイスからのタイミング情報の選択は、前記ビデオコアによって行われる、請求項２７に記載の方法。
30. 前記Ｒ－ＭＡＣＰＨＹデバイスからのタイミング情報の選択は、プロビジョニングサーバによって行われる、請求項２７に記載の方法。
31. 通信ネットワーク内のデバイスでありかつビデオコアからビデオデータを受信するデバイスに関して、同期モードと非同期モードとの間にわたって動作モードを動的に交互に切り替えるための方法であって、
    同期モードで動作するように前記デバイスを初期化することと、
    前記デバイスと前記ビデオコアとの間における同期強度を決定することと、
    決定された同期量に基づいて非同期モードへと選択的に変化させることと、を含む、方法。
32. リモート物理デバイス（ＲＰＤ）によって実行される、請求項３１に記載の方法。
33. リモートＭＡＣＰＨＹデバイス（ＲＭＤ）によって実行される、請求項３１に記載の方法。
34. 決定された第二同期強度に基づいて、非同期モードから同期モードへと戻るように選択的に変化させるステップを含む、請求項３１に記載の方法。
35. 前記同期強度を、前記デバイス内のデジッタバッファの状態を測定することによって決定するとともに、前記デバイスを非同期モードへと戻るように変化させる前に前記デジッタバッファの満杯度合いを所定レベルへと復帰させるステップを含む、請求項３４に記載の方法。
36. 決定される前記第二同期強度を、決定される前記第一同期強度とは異なるものとする、請求項３４に記載の方法。
37. 決定される前記第二同期強度を、決定される前記第一同期強度よりも小さいものとする、請求項３６に記載の方法。
38. 前記同期強度を、前記デバイス内のデジッタバッファの状態を測定することによって決定する、請求項３１に記載の方法。
39. 前記デジッタバッファの測定される前記状態を、前記デジッタバッファの満杯状態、および、前記デジッタバッファの前記満杯状態の変化率、とする、請求項３８に記載の方法。
40. 前記デジッタバッファの測定される前記状態を、前記デジッタバッファの満杯状態の変化率とする、請求項３８に記載の方法。