(57)【要約】パケット・ストリーム・チャネルの処理をスケジュールするための方法であって、少なくとも１つのパケット・ストリーム・チャネルが処理可能状態のメディア・フレームを含んでいるか否かを判定すること（２１０）、少なくとも１つのパケット・ストリーム・チャネルが処理可能状態のメディア・フレームを含んでいる場合に、最も高い優先度の処理可能状態のメディア・フレームを確認し（２３０）、確認した最も高い優先度のメディア・フレームを処理のためにスケジュールすること（２４０）を含む方法。本方法は、処理可能状態のメディア・フレームに、メディア・フレーム有効時間と各メディア・フレームに対する推定処理時間との少なくとも一方に基づいて優先順位をつけることをさらに含む。
2011501600.tif 000002
【特許請求の範囲】
【請求項１】
パケット・ストリーム・チャネルの処理をスケジュールする方法であって、
少なくとも１つのパケット・ストリーム・チャネルが処理可能状態のフレームを含んでいるか否かを判定すること（２１０）、
少なくとも１つのパケット・ストリーム・チャネルが処理可能状態のフレームを含んでいる場合に、最も高い優先度の処理可能状態のフレームを確認し（２３０）、確認した最も高い優先度のフレームを処理のためにスケジュールすること（２４０）
を含み、処理可能状態のフレームに、少なくともフレーム有効時間と各フレームに対する推定処理時間とに基づいて優先順位をつけることを特徴とする方法。
【請求項２】
処理可能状態のフレームのフレーム有効時間を、前記処理可能状態のフレームを完成させるデータ・パケットの最も古い到着時刻として算出することをさらに特徴とする請求項１に記載の方法。
【請求項３】
フレームに優先順位をつけることが、（前記フレーム有効時間と現在時刻との間の差）−（前記フレームを処理するのに必要な時間の長さの推定値）を計算することを含むことをさらに特徴とする請求項１または請求項２に記載の方法。
【請求項４】
フレームを処理のためにスケジュールすること（２４）の前に、そのフレームの待ち時間を推定し、前記フレームの待ち時間が待ち時間閾値を超えた場合に、優先度がより高いフレームを処理することをさらに特徴とする請求項１乃至３のいずれか一項に記載の方法。
【請求項５】
処理可能状態のフレームにさらに、
（ｉ）それらのフレームに対するチャネル履歴と、
（ｉｉ）それらのフレームに対するデータ・コンテンツと、
（ｉｉｉ）それらのフレームに対するフレーム・タイプと、
（ｉｖ）チャネル内のフレームをより高い優先度で処理する頻度と
のうちの少なくとも１つに基づいて優先順位をつけることをさらに特徴とする請求項１乃至４のいずれか一項に記載の方法。
【請求項６】
少なくとも１つのパケット・ストリーム・チャネルが処理可能状態のフレームを含んでいるか否かを判定すること（２１０）が、複数のチャネル・バッファ（１２０）をポーリングして少なくとも１つのパケット・チャネル・フレームのステータスを得ることを含むことをさらに特徴とする請求項１乃至５のいずれか一項に記載の方法。
【請求項７】
請求項１乃至６のいずれか一項に記載のパケット・ストリーム・チャネルの処理をスケジュールするように構成された通信ユニット。
【請求項８】
パケット・ストリーム・チャネルの処理をスケジュールするための集積回路（１０５）であって、
少なくとも１つのパケット・ストリーム・チャネルが処理可能状態のフレームを含んでいるか否かを判定する論理回路であって、少なくとも１つのパケット・ストリーム・チャネルが処理可能状態のフレームを含んでいる場合に、最も高い優先度の処理可能状態のフレームを確認する前記論理回路と、
前記判定する論理回路に動作可能に結合され、確認した最も高い優先度のフレームを処理するためにスケジュールするように構成されたスケジューラ論理回路と
を備え、前記スケジューラ論理回路は、処理可能状態のフレームに少なくともフレーム有効時間と各フレームに対する推定処理時間とに基づいて優先順位をつけるように構成されていることを特徴とする集積回路（１０５）。
【請求項９】
前記スケジューラ論理回路は、処理可能状態のフレームのフレーム有効時間を、前記処理可能状態のフレームを完成させるデータ・パケットの最も古い到着時刻として算出するように構成されていることをさらに特徴とする請求項８に記載の集積回路（１０５）。
【請求項１０】
前記スケジューラ論理回路は、処理可能状態のフレームに、（前記フレーム有効時間と現在時刻との間の差）−（前記フレームを処理する時間の長さの推定値）を計算することによって優先順位をつけるように構成されていることをさらに特徴とする請求項８または請求項９に記載の集積回路（１０５）。
【請求項１１】
前記スケジューラ論理回路は、フレームをスケジュールする前にそのフレームの待ち時間を推定し、前記フレームの待ち時間が待ち時間閾値を超えた場合により高い優先度のフレームを処理するように構成されていることをさらに特徴とする請求項８乃至１０のいずれか一項に記載の集積回路（１０５）。
【請求項１２】
スケジューラ論理回路は、処理可能状態のフレームにさらに、
（ｉ）それらのフレームに対するチャネル履歴と、
（ｉｉ）それらのフレームに対するデータ・コンテンツと、
（ｉｉｉ）それらのフレームに対するフレーム・タイプと、
（ｉｖ）チャネル内のフレームをより高い優先度で処理する頻度と
のうちの少なくとも１つに基づいて優先順位をつけるように構成されていることをさらに特徴とする請求項８乃至１１のいずれか一項に記載の集積回路（１０５）。
【請求項１３】
データ・パケットを受信して記憶するように構成された複数のチャネル・バッファ（１２０）をさらに備え、前記スケジューラ論理回路は、少なくとも１つのパケット・ストリーム・チャネルが処理可能状態のフレームを含んでいるか否かを、複数のチャネル・バッファ（１２０）をポーリングして少なくとも１つのパケット・チャネル・フレームのステータスを得ることによって判定するように構成されていることをさらに特徴とする請求項８乃至１２のいずれか一項に記載の集積回路（１０５）。
【請求項１４】
請求項８乃至１３のいずれか一項に記載の集積回路を備える通信ユニット。
【請求項１５】
パケット・ストリーム・チャネルの処理をスケジュールする方法を実行するようにコンピュータをプログラムするためのコンピュータ読取可能なコードが記憶されたコンピュータ読取可能な記憶要素であって、前記方法は、
少なくとも１つのパケット・ストリーム・チャネルが処理可能状態のフレームを含んでいるか否かを判定すること（２１０）、
少なくとも１つのパケット・ストリーム・チャネルが処理可能状態のフレームを含んでいる場合に、最も高い優先度の処理可能状態のフレームを確認し（２３０）、確認した最も高い優先度のフレームをスケジュールすること（２４０）
を含み、処理可能状態のフレームに、少なくともフレーム有効時間と各フレームに対する推定処理時間とに基づいて優先順位をつけることを特徴とするコンピュータ読取可能な記憶要素。
【請求項１６】
前記コンピュータ読取可能な記憶要素が、ハード・ディスク、ＣＤ−ＲＯＭ、光学記憶装置、磁気記憶装置、ＲＯＭ（読み出し専用メモリ）、ＰＲＯＭ（プログラマブル読み出し専用メモリ）、ＥＰＲＯＭ（消去可能なプログラマブル読み出し専用メモリ）、ＥＥＰＲＯＭ（電子的に消去可能なプログラマブル読み出し専用メモリ）、およびフラッシュ・メモリのうちの少なくとも１つを含むことをさらに特徴とする請求項１５に記載のコンピュータ読取可能な記憶要素。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の分野は、パケット・ストリーム・チャネルの処理をスケジュールするための方法、集積回路、および通信ユニットに関し、より詳細には、メディア（たとえばビデオ）ストリーム・チャネルの処理をスケジュールするための方法、集積回路、および通信ユニットに関する。
【背景技術】
【０００２】
ビデオおよび他のタイプのメディアが、インターネットおよび他のネットワーク上で配信されることがますます多くなっている。配信は、標準化されたパケット・フォーマットを利用したメディア・ストリームの形態で行なわれる。たとえばインターネット技術タスクフォース（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ：ＩＥＴＦ）によって開発され、ＲＦＣ３５５０において規定されるリアルタイム転送プロトコル（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ：ＲＴＰ）である。ＲＴＰによって、リアル・タイム・データ（たとえばオーディオ、ビデオ、または模擬（ｓｉｍｕｌａｔｉｎｇ）データ）をマルチキャストまたはユニキャスト・ネットワーク・サービス上で送信する用途に適した端末間ネットワーク転送機能が得られる。ＲＴＰは、制御プロトコル（リアルタイム制御プロトコル（Ｒｅａｌ−ｔｉｍｅ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ：ＲＴＣＰ）と呼ばれる）によって増強されて、データ配信のモニタリングを、大きなマルチキャスト・ネットワークに拡張可能な方法で行なうことができるとともに、最小限の制御および確認機能が得られる。
【０００３】
メディア・サービス（たとえばビデオ・ストリーミングなど）が、モバイル・デバイス（たとえば携帯電話送受話器）からデスクトップ・コンピュータなどに及ぶ異なるタイプのメディア端末に提供されることが良く知られている。当業者であれば分かるように、メディア端末およびそれらの対応する通信経路の能力および要求が様々であるため、通常は移動端末ごとにメディア要求が異なる。ビデオ・ストリーミングに対してこのように異なるメディア要求の例としては、たとえば、エンコード要求、フレーム・レート要求、ビット・レート要求、フレーム・サイズ要求などを挙げても良い。
【０００４】
メディア要求が異なる様々なメディア端末へのメディア・サービスの提供を、メディア要求のすべての組み合わせに対して各サービスの複製を提供する必要なく可能にするために、メディア端末がメディア・サービスにアクセスする際に通る場合があるゲートウェイなどの装置を用いることが知られている。こうして、ゲートウェイは、受信したメディア・ストリームを処理して、ゲートウェイを通してメディア・サービスにアクセスする各メディア端子に対して要求されるフォーマットに変換する。
【０００５】
そのため、ゲートウェイは、複数の同時メディア・ストリームであって、各ストリームには非同期的に到着するデータのパケットが含まれる同時メディア・ストリームを処理できることが要求される。さらに、ゲートウェイは、処理するメディア・フレームに対するチャネル密度を最大にする一方で、ゲートウェイを通るメディア・ストリームの待ち時間を最小限にして、各パケットの処理および結果出力が行なわれる時間が遅延閾値を下回るようにすることが要求される。
【０００６】
メディア・コンテンツの処理を改善するために、メディア・フレームの処理の優先順位づけを、それらの処理が要求されるそれらの期限に基づいて行なうことが知られている。メディア・フレームとしては一般的に、それらの処理が要求される期限が最も切迫しているものが最初に処理される。通常、このような期限は、フレームの最初のデータ・パケットを受信した後にそのフレームの処理が要求される制限時間に基づく。こうして、メディア・フレームがそれらの期限までに処理されない結果落とされるメディア・フレームが少なくなる傾向があり、その結果、受信したメディア・ストリームのチャネル密度が向上する。
【０００７】
米国特許６，９７５、６２９第号明細書、タイトル「期限間隔に基づくパケット処理」では、第１および第２のデータ・パケットに各データ・パケットの期限間隔を用いて優先順位をつけるメカニズムについて説明している。この特許では、期限が最も近いデータ・パケットを最初にスケジュールするメカニズムについて教示している。
【０００８】
しかしこのような既知の技術では、データ・タイプ、処理要求などの他の考慮すべき事柄が考慮されていない。その結果、このような既知の技術では、各メディア・ストリームに対するチャネル密度を最適化する一方で、ゲートウェイを通るメディア・ストリームの待ち時間を最小限にすることには至っていない。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
したがって、パケット・ストリーム・チャネル（たとえばメディア・ストリーム・チャネルなど）の処理をスケジュールするための方法および装置の改善が求められている。
【課題を解決するための手段】
【００１０】
本発明の態様によれば、添付の請求項において規定されるようなパケット・ストリーム・チャネル（たとえばメディア・ストリーム・チャネル）の処理をスケジュールするための方法および装置が提供される。
【００１１】
従属請求項において特定の実施形態が記載されている。
次に、本発明の代表的な実施形態について、添付の図面を参照して、単に一例として説明する。
【図面の簡単な説明】
【００１２】
【図１】本発明のいくつかの実施形態により構成されたゲートウェイを備える通信ユニットを例示する図である。
【図２】本発明の実施形態によりメディア・ストリーム・チャネルをスケジュールする方法のフローチャートを例示する図である。
【図３】本発明の代替的な実施形態によりメディア・ストリーム・チャネルをスケジュールする方法のフローチャートを例示する図である。
【図４】本発明の実施形態によるスケジューラおよび処理エンジンの主機能を実行する信号プロセッサに対する時系列と処理エンジンが用いる位置に対するメモリ位置作用とを例示する図である。
【図５】本発明の実施形態によるスケジューラの割り込み機能の例のフローチャートを例示する図である。
【図６】本発明の実施形態によるスケジューラおよび処理エンジンの主機能および割り込み機能を実行する信号プロセッサに対する時系列と処理エンジンが用いるメモリ位置に対するメモリ位置作用とを例示する図である。
【発明を実施するための形態】
【００１３】
本発明の実施形態を、パケット・ストリーム・チャネル（たとえばメディア・ストリーム・チャネル）の処理をスケジュールするための方法および装置に関して説明する。本発明の実施形態を、メディア・ゲートウェイ、たとえばインターネット・プロトコル（ＩＰ）マルチメディア・サブ・システム（ＩＭＳ）内でのメディア資源機能プロセッサ（ＭＲＦＰ）に関して説明するが、当然のことながら、本明細書で説明する本発明の考え方は、複数のパケット・ストリーム・チャネルを処理することが要求される任意の装置において具体化しても良い。
【００１４】
要約すれば、本発明の考え方において提案するのは、パケット・ストリーム・チャネルの処理をスケジュールするための方法および装置であって、少なくとも１つのパケット・ストリーム・チャネルが処理可能状態のフレーム（ｆｒａｍｅ  ｒｅａｄｙ  ｆｏｒ  ｐｒｏｃｅｓｓｉｎｇ）を含んでいるか否かを判定すること、少なくとも１つのパケット・ストリーム・チャネルが処理可能状態のフレームを含んでいる場合に、最も高い優先度の処理可能状態のフレームを確認し、確認した最も高い優先度のパケット・ストリーム・チャネルを処理のためにスケジュールすることを含む方法および装置である。本方法はさらに、優先順位をつけることを含んでおり、装置はさらに、処理可能状態のフレームに、少なくともフレーム有効時間と各フレームに対する推定処理時間とに基づいて優先順位をつけるように構成されている。
【００１５】
次に図１を参照して、本発明のいくつかの実施形態によりゲートウェイ１０５として機能するように構成された集積回路を備える通信ユニット１００を例示する。ゲートウェイ１０５は、スケジューラ１１０、少なくとも１つのメディア混雑バッファ（例示した実施形態では、複数のビデオ混雑バッファ（ｖｉｄｅｏ  ｃｏｎｇｅｓｔｉｏｎ  ｂｕｆｆｅｒ：ＶＣＢ）１２０の形態）、および処理エンジン１３０を備える。
【００１６】
ゲートウェイ１０５は、複数の実質的に同時のメディア・ストリームを受信するように構成されている。メディア・ストリームは、たとえばビデオおよびオーディオ・ストリームの少なくとも一方であっても良く、またたとえば動いている場面を示す画像列を発生させて人間が知覚できる形態で出力することができるビデオ・フレームのストリームからなっていても良い。一例として、ゲートウェイ１０５は、インターネット・プロトコル（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｐｃｏｌ：ＩＰ）マルチメディア・サブ・システム（ＩＭＳ）内でのメディア資源機能プロセッサ（ＭＲＦＰ）を備えていても良い。ＩＭＳは、ＩＰマルチメディアをモバイル・ユーザに配信するためのアーキテクチャ・フレームワークである。それは、当初、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）と言われる無線標準化団体によってデザインされ、グローバル・システム・モバイル通信（Ｇｌｏｂａｌ  Ｓｙｓｔｅｍ  Ｍｏｂｉｌｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎ：ＧＳＭ）と言われる第２世代の無線通信を越えてモバイル・ネットワークを発展させる構想の一部である。
【００１７】
例示した実施形態の場合は、ゲートウェイ１０５は、メディア・ストリームを、１つまたは複数のリアル・タイム転送プロトコル（ＲＴＰ）データ・パケットを含むメディア・フレームの形態で受信する。当業者であれば分かるように、データ・パケットは通常、同期して到達する。その結果、メディア・フレームに関係するＲＴＰデータ・パケットの到達は、順序が狂っていること、および種々の遅延を伴っていることがある。
【００１８】
ゲートウェイ１０５は、各メディア・ストリーム・チャネルに対するＶＣＢ１２０を備えている。各ＶＣＢ１２０は、その対応するメディア・ストリーム・チャネルに対する受信データ・パケットを記憶するように、また受信データ・パケットをソートして順番に並べてそれらの対応するフレーム内に入れるように、構成されている。例示した実施形態の場合は、データ・パケット（ＲＴＰデータ・パケットの形態）をコントローラ１５０が受信して、適切なＶＣＢ１２０に転送する。
【００１９】
スケジューラ１１０は、主機能または処理をサポートするスケジューラ論理回路を備える。スケジューラ論理回路は、実質的に連続的に実行されるように、またメディア・ストリームをスケジュールするように構成されている。図２に、本発明の実施形態によりメディア・ストリーム・チャネルをスケジュールする方法のフローチャート２００を例示する。フローチャート２００は、スケジューラ１１０のスケジューラ論理機能によって行なわれる。
【００２０】
図２における方法の開始は、たとえば図１のスケジューラ１１０、またはより詳細にはスケジューラ論理回路を、たとえば、ゲートウェイ１０５のオペレーティング・システム（ＯＳ）１４０または他のマネージメント制御コンポーネントが開始した後に行なわれる。スケジューラ１１０は次に、少なくとも１つのメディア・ストリーム・チャネルが処理可能状態のフレームを含んでいるか否かの判定を、たとえばＶＣＢ１２０をポーリングして複数のメディア・チャネル・フレームのステータスを取得することによって行なう（ステップ２１０）。
【００２１】
次に図２のステップ２２０において、少なくとも１つのメディア・ストリーム・チャネルが処理可能状態のフレームを含んでいる場合、スケジューラ論理回路が、最も高い優先度の処理可能状態のフレームを確認する。これをステップ２３０に例示する。処理可能状態のフレームがない場合は、スケジューラ論理回路は、一巡してステップ２１０に戻り、引き続いてＶＣＢのポーリングを、少なくとも１つの受信フレームが処理可能状態であるまで行なう。
【００２２】
一旦複数のフレームから最も高い優先度の特定のフレームが確認されると、本方法はステップ２４０に移る。そこでは、スケジューラ論理回路が、確認したフレームを、処理エンジン（たとえば処理エンジン１３０）による処理に対してスケジュールする。次にステップ２５０では、スケジューラ論理回路は、処理エンジンを呼び出して、スケジュールしたフレームを処理する。本方法は次に、一巡してステップ論理に戻り、スケジュール２１０はＶＣＢ１３０をポーリングして、処理可能状態のさらなるフレームを探す。
【００２３】
図１を再び参照して、また本発明のいくつかの実施形態によれば、スケジューラ論理回路１１０は、フレームの処理のためのスケジューリングを、フレームの処理に対する資源を初期化することによって行なう。フレームの処理に対する資源を初期化することには、たとえば、直接メモリ・アクセス（ＤＭＡ）ユニット（図示せず）に、たとえばＯＳ１４０を介して指示を出して、フレーム・データを処理エンジン１３０に対するメモリ内にロードさせることが含まれていても良い。このようにして、ＤＭＡを用いて、フレーム・データを、たとえば比較的遅いが大きい外部メモリから比較的速いが小さい内部メモリへ転送しても良い。フレーム・データの処理は、データが内部メモリ内にあるときに行なわれる。フレーム・データをその後、一旦処理されたら、外部メモリ内に再び保存しても良い。
【００２４】
ＤＭＡによってメモリ内にロードされるフレーム・データには、処理エンジンに対する永続データ（フレームが関係するチャネルのコンテキストに関係するデータを含む）が含まれていても良い。たとえば、処理エンジン１３０は、ビデオ・フレームを処理するためのビデオ・トランスコーダを備えていても良い。このようなビデオ・トランスコーダでは、そのチャネルに対して処理される最後のフレームに関係するデータを、そのチャネルに対する新しいフレームを「トランスコード」するために必要とする場合がある。
【００２５】
当業者であれば分かるように、ＤＭＡユニットは、同じ信号処理システム内でプロセッサの実行と並行して実行することができる。したがって、また本発明のいくつかの実施形態によれば、２つのメモリ位置を使用し、そこから得られるフレームを処理するために処理エンジン１３０が構成されていても良い。このようにして、処理エンジン１３０は、第１のメモリ位置から得られるフレーム・データを用いてフレームを処理している一方で、ＤＭＡは、処理すべき後続のフレームに対するフレーム・データを第２のメモリ位置内にロードする。
【００２６】
次に図３を参照して、フローチャート３００によって、本発明の代替的な実施形態によりメディア・ストリーム・チャネルをスケジュールする方法を例示する。
図２の方法の場合と同じ仕方で、本方法の開始は、たとえば、スケジューラ論理回路を、たとえば図１のゲートウェイ１０５のオペレーティング・システム（ＯＳ）１４０または他のコンポーネントが開始した後に行なう。スケジューラ論理回路は次に、ＶＣＢをポーリングして、メディア・チャネル・フレームのステータスを取得するとともに、特に、任意のメディア・ストリーム・チャネルが処理可能状態のフレームを含むか否かを判定する。これをステップ３１０に示す。
【００２７】
次にステップ３２０において、少なくとも１つのメディア・ストリーム・チャネルが処理可能状態のフレームを含む場合には、スケジューラ論理回路１１０はステップ３３０に進んで、最も高い優先度の処理可能状態のフレームを確認する。処理可能状態のフレームがない場合には、スケジューラ論理回路は一巡してステップ３１０に戻り、引き続いてＶＣＢ１２０のポーリングを、少なくとも１つのフレームが処理可能状態となるまで行なう。代替的な実施形態においては、処理可能状態のフレームがない場合に、スケジューラは他の機能（たとえばロギング（ｌｏｇｇｉｎｇ）、タイマ（ｔｉｍｅｒｓ）など）を、一巡してステップ３１０に戻ってＶＣＢ１２０を再びポーリングする前に、行なっても良い。
【００２８】
一旦最も高い優先度のフレームが確認されたら、本方法はステップ３４０に移る。そこでは、スケジューラ論理回路が、確認したフレームを、処理エンジン（たとえば、図１の処理エンジン１３０）による処理に対してスケジュールする。たとえば、スケジューラ論理回路は、確認したフレームに対するフレーム・データ（たとえばフレームのチャネルの永続データ）が、処理のために内部メモリ内にロードされたかどうかを確かめるためにチェックする。確認したフレームに対するフレーム・データがメモリ内にロードされている場合には、スケジューラ論理回路はＤＭＡユニットに指示を出して、フレーム・データをメモリ内にロードさせる。次にステップ３５０において、スケジューラ論理回路は、さらなるフレームが処理可能状態であるか否かを判定する。
【００２９】
１つまたは複数のさらなるフレームが処理可能状態である場合には、本方法はステップ３６０に移る。そこでは、スケジューラ論理回路が、次に高い優先度のさらなる処理可能状態フレームを確認する。次にステップ３７０において、スケジューラ論理回路はＤＭＡユニットに指示を出して、確認したさらなるフレームに対するフレーム・データをメモリ内にロードさせてフレームの処理に備える。スケジューラ論理回路は次に、処理エンジン（たとえば図１の処理エンジン１３０）を呼び出して（ステップ３８０）、処理エンジンが、最も高い優先度の処理すべきフレームと確認された（ステップ３３０）フレームを処理するようにする。
【００３０】
再びステップ３５０を参照して、さらなる処理可能状態のフレームがない場合には、本方法は、直接ステップ３８０に移り、そこで、スケジューラ論理回路は処理エンジンを呼び出して、処理エンジンが、最も高い優先度のフレームと確認された（ステップ３３０）フレームを処理するようにする。
【００３１】
次に図４を参照して、たとえば、図１のスケジューラ論理回路１１０および処理エンジン１３０が用いる信号処理動作に対する時系列４００のグラフ表示を例示する。スケジューラ論理回路１１０および処理エンジン１３０は、ゲートウェイ・プロセッサ４１０によって実行される。時系列４００はまた、本発明の実施形態による図１のゲートウェイ処理エンジンが用いるメモリ位置４１５、４２０に対するメモリ位置作用を示す。
【００３２】
例示した時系列は時間Ｔ０で開始し、スケジューリング（ＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ））がスケジューラ論理回路によって実行される。前述したように、図１のスケジューラ論理回路が用いるＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ）サブ・ルーチンが、ＶＣＢをポーリングして、処理可能状態であるフレームを探す。一旦１つまたは複数のフレームが処理可能状態であるならば、ＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ）サブ・ルーチンは確認して、最も高い優先度の処理可能状態であると確認されたフレーム（フレームＷ）を処理するためにスケジュールする。ＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ）サブ・ルーチンは次に、さらなるフレームが処理可能状態であるか否かを判定し、そうである場合には、スケジューラ論理回路はＤＭＡユニットに指示を出して、確認したさらなるフレーム（フレームＸ）に対するフレーム・データをメモリ内にロードさせる。
【００３３】
時間Ｔ１において、ＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ）サブ・ルーチンは、処理エンジン（たとえば図１の処理エンジン１３０）を呼び出して、処理エンジンが、処理すべき最も高い優先度のフレームであると確認されたフレーム（フレームＷ）４０５を処理するようにする。
【００３４】
信号プロセッサは、処理エンジンを、ＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ）サブ・ルーチンよりも高い優先度で実行するように構成されている。こうして、ＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ）が処理エンジンを呼び出すと、信号プロセッサは、ＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ）サブ・ルーチンの実行を停止して、処理エンジンを実行する。処理エンジンは、スケジュールされたフレーム（フレームＷ４０５）の処理を、適切なメモリ位置にロードされたフレーム・データに基づいて行なう。適切なメモリ位置は、時系列におけるその場合では、メモリ位置「２」４２０である。処理エンジンは、スケジュールされたフレームを処理する前に、コントローラ（たとえば図１におけるコントローラ１５０）を呼び出して、スケジュールされたフレームが関係する特定のチャネルに対する制御および構成メッセージを取り込んでも良い。あるいは、ＳＣＨ＿ｍａｉｎ（メイン）＿サブ・ルーチンが、このような制御および構成メッセージの呼び出しおよび取り込みを、フレームの処理のためのスケジューリングの一部として行なって、メッセージを処理エンジンに送っても良い。
【００３５】
前述したように、ＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ）サブ・ルーチンは、さらなるフレームが処理可能状態であるか否かを判定し、そうである場合には、ＤＭＡユニットに指示を出して、確認したさらなるフレーム（フレームＸ）に対するフレーム・データをメモリ内にロードさせた。こうして、図４に例示したように、処理エンジンはフレームＷを位置「２」４２０から処理する一方で、ＤＭＡユニットは、既存のデータをメモリ位置「１」４１５から記憶し（妥当なデータであった場合）、次のフレーム（フレームＸ）に対するフレーム・データをメモリ位置「１」４１５内にロードする。
【００３６】
処理エンジンがフレームＷの処理を終了するとすぐに、時間Ｔ２において、信号プロセッサはＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ）サブ・ルーチンの実行を再開する。そしてＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ）サブ・ルーチンは一巡して戻り、処理は次のフレーム（フレームＸ）に対して再び開始する等である。
【００３７】
当業者であれば分かるように、先行するフレームが処理されている間に、フレーム・データをメモリ内に予めロードしてフレームの処理に備えることによって、フレーム・データがロードされている間に処理エンジン１３０のフレーム処理が遅れるようなことはない。こうして、処理可能状態であるフレームに処理に対する優先順位をつけることを、少なくともフレーム有効時間と各フレームに対する推定処理時間とに基づいて行なう。たとえば、本発明の一実施形態においては、処理可能状態のフレームの優先度は、次式に基づいても良いことが考えられる。
Ｐｆ＝ｆｒａｍｅ＿ｄｅｌａｙ（フレーム遅延）−ｃｈａｎｎｅｌ＿ｐｒｏｃｅｓｓｉｎｇ＿ｌｅｎｇｔｈ（チャネル処理長さ）
ここで、ｆｒａｍｅ＿ｄｅｌａｙ（フレーム遅延）は、スケジューラ論理回路によって測定されるものであり、実質的にフレーム有効時間と現在時刻との間の差に相当する。たとえば、前述したように、フレームには１つまたは複数のデータ・パケットが含まれる。受信データ・パケットは、ソートされて待ち行列またはバッファ（ＶＣＢ）に入れられ、本発明の一実施形態における各チャネルにはその独自のバッファがある。データ・パケットをゲートウェイが受信すると、その到着時刻がデータ・パケットとともに記憶される。フレームを構成するすべてのデータ・パケットが受信されたときに、フレームは「有効」であるとみなされる。有効性は、フレームを構成するデータ・パケットの最も古い到着時刻（ｏｌｄｅｓｔ  ａｒｒｉｖａｌ  ｔｉｍｅ）として算出される。
【００３８】
本発明の一実施形態においては、ゲートウェイは、フレームが「有効」となった時点から現在時刻までの経過時間を測定しなければならない。これは、以下の方法のうちの１つを用いて行なっても良いと考えられる。
（ｉ）各チャネルが参照するグローバル・タイマを用いる、
（ｉｉ）チャネルごとに専用タイマを有する。
【００３９】
この実施形態においては、タイマを用いて、パケットの受信時点を記憶し、そこからのフレーム遅延を算出しても良い。
これに対する例外は、データ・パケットが失われてフレームが未完成のときであっても良い。フレームが完成するまでの待ち時間が満了した後、フレームは、たとえ未完成であっても、「処理可能状態である」とみなされる。待ち時間が満了する時点を、未完成なフレームに対する有効時間とみなしても良い。
【００４０】
「ｃｈａｎｎｅｌ＿ｐｒｏｃｅｓｓｉｎｇ＿ｌｅｎｇｔｈ（チャネル処理長さ）」値は、フレームを処理するのに必要な時間の長さの推定であり、あらゆるフレーム処理転置に対してメモリ内に記憶される情報に基づくものである。たとえば、あらゆるフレーム処理転置に対する処理時間を、ある時間に渡って測定しても良く、各転置に対する平均値をメモリ内に記憶しても良い。そのフレームに対して要求される処理に対応する転置を、メモリから取り込む。平均処理時間を継続的に更新して、できるだけ正確な値を「ｃｈａｎｎｅｌ＿ｐｒｏｃｅｓｓｉｎｇ＿ｌｅｎｇｔｈ（チャネル処理長さ）」に対して維持しても良い。種々の転置がパラメータに関して異なっていても良い。パラメータはたとえば、ビデオ・メディアの場合には、入力および出力ビデオ規格、画像サイズなどである。こうして、フレーム処理の優先順位づけを、フレームがどれくらい長く処理可能状態であるかに関連して（したがって、処理すべき期限に関連して）だけでなく、どのくらい迅速にフレームを処理できるかに関して行なう。
【００４１】
こうして、少量の処理のみを必要とするフレームの優先順位を、大量の処理を必要とするフレームの前につける。結果として、少量の処理を必要とするフレームが、大量の処理を必要とするフレームによって遅れることはなく、その結果、チャネル密度が大きくなる一方で、ゲートウェイを通るメディア・ストリームの待ち時間が減る。
【００４２】
当業者であれば分かるように、フレームの処理には、一例として、以下のうちの少なくとも１つが含まれていても良い。
（ｉ）フレーム／データ・パケットのエンコードを１つの規格から別の規格へと変えること。たとえば、入力ビデオ・メディア・ストリームの場合に、エンコードをＨ．２６３などのビデオ・コーデック規格からＨ．２６４などのビデオ・コーデック規格へ変えること、
（ｉｉ）入力メディア・ストリームに対するフレーム・レートを変えること、
（ｉｉｉ）入力メディア・ストリームに対するビット・レートを変えること、および／または
（ｉｖ）入力メディア・ストリームのフレーム・サイズを変えること。たとえば、共通中間フォーマット（Ｃｏｍｍｏｎ  Ｉｎｔｅｒｍｅｄｉａｔｅ  Ｆｏｒｍａｔ：ＣＩＦ）（ビデオ信号におけるＹＣｂＣｒシーケンス（ビデオおよびデジタル写真システムで用いられる色空間のファミリ）の画素における水平方向および垂直方向解像度を標準化するために用いられる）などのフォーマットからクォータＣＩＦ（ＱＣＩＦ）などのフォーマットへ変えること。
【００４３】
本発明の代替的な実施形態によれば、スケジュールされたフレームを処理する前に、そのフレームの待ち時間を推定しても良い。この実施形態においては、待ち時間が待ち時間閾値を超える場合、たとえば、スケジュールされたフレームの処理が、スケジュールされたフレームを処理する必要がある期限後に終了するような場合には、フレームを「緊急」モードで処理する。
【００４４】
一例として、処理エンジンは、トランスコーダを備えていても良い。トランスコーダは、デコーダおよびエンコーダを備え、これらは結合されている。たとえば、フレームの処理をそれが有効になってから５０ｍｓｅｃ未満に行なうことが要求されているが、スケジューラ論理回路が、これは、フレームを完全に処理してしまうと実現されないだろうと決定した場合には、スケジューラ論理回路は、処理エンジンに指示を出してフレームを「緊急」モードで処理させても良い。「緊急」モードでは、トランスコーダのデコーダ部分のみを実行に対して構成しても良い。したがって、このような場合には、トランスコーダは、受信データ・ストリームのデコードを行なって、ソースと同期したままである。しかしトランスコーダは、データ・ストリームのエンコードは行なわない。したがって、出力されるフレームはないが、フレームの「省略」はある。トランスコーダのデコーダ部分のみが実行されるため、チャネルが必要とする処理は少なくなり、より速く終了し、プロセッサをより早く開放して、他のチャネルの処理に備える。したがって、混雑時間が、いずれにしても消える運命にあるチャネルを犠牲にすることによって解消される。なぜならば、そのようなチャネルは、処理の終了が遅すぎるであろうし、したがって処理能力を無駄にするだけであるからである。
【００４５】
送り先では、知覚品質のわずかな低下が、フレーム省略に起因して起こる。しかしこの品質低下は、トランスコーダがソースとの同期を失う場合よりも小さい。このようにして、システムが過負荷状態になったときは優雅な劣化がもたらされる。さらに、処理を「緊急」モードで終了させる時間が短くなるため、フレームの処理が、要求される制限時間（たとえば、フレームが有効になってから５０ｍｓｅｃ）内で終了する場合があり、したがってチャネルは、そのチャネルに対する入力メディア・ストリームと同期したままである。
【００４６】
本発明の一実施形態においては、ビデオ・エンコードを、連続するフレーム間の差のみをエンコードすることによって部分的に行なう。たとえば、フレーム「１」の完全なエンコードを（参照する状況なく）行ない、次にフレーム「２」のエンコードを参照フレーム「１」を用いて行ない、なんらかの差を測定しても良い。このシナリオでは、２つのフレーム間の差のみをエンコードする。その後、フレーム「３」のエンコードをフレーム「２」を参照して行なっても良い等である。しかしフレーム「２」がデコードされていない場合には、フレーム「３」を正しく再現することはできない。この状況では、トランスコーダは事実上、ビデオ・ソースとの同期を失う。このエラーは、ビデオ・ソースが新しい「Ｉ」フレームを送るまで伝搬する。
【００４７】
前に示したように、エンコードが与えられないときにデコードを行なうことは、やはりユーザにとって有用である。たとえば、フレーム「２」が緊急モードで実行される場合を考えると、したがってそれはエンコードされず、フレーム「３」が通常通りに実行されると、したがってそれは正しくデコードされ（なぜならば、フレーム「２」がデコードされていて、トランスコーダ内に存在するから）、したがってエンコードされる。ユーザにとっての利益は、たとえ「フレーム２」のトランスコードが見えなくても、フレーム３および後続するすべてのフレームが通常通りに見えることである。
【００４８】
さらに、フレームのさらなる優先順位づけを、それらのフレームに対するチャネル履歴に基づいて、たとえばチャネル内のフレームを「緊急」モードで処理した頻度に基づいて、行なっても良いことが考えられる。たとえば、処理可能状態のフレームの優先度を、次式から与えても良い。
Ｐｆ＝ｆｒａｍｅ＿ｄｅｌａｙ（フレーム遅延）−ｃｈａｎｎｅｌ＿ｐｒｏｃｅｓｓｉｎｇ＿ｌｅｎｇｔｈ（チャネル処理長さ）＋ｕｒｇｅｎｔ＿ｃｎｔ（緊急ｃｎｔ）
ここで、「ｕｒｇｅｎｔ＿ｃｏｕｎｔ（緊急カウント）」には、フレーム・チャネルの統計値（たとえば、そのチャネルのフレームを緊急モードで処理した回数）が含まれる。
【００４９】
こうして、チャネルの履歴（特定のチャネルのフレームを緊急モードで処理した回数の形態である）を考慮することができる。こうして、緊急モードで処理したフレームは、ビデオ・フレームの場合には見えない場合があるため、どれか一つの特定のチャネルのフレームを、必要以上に頻繁に緊急モードで処理することは望ましくない。したがって、フレームの優先順位づけの中にチャネル履歴因子を取り入れることによって、緊急モードでのフレームの処理が、すべてのチャネルに渡ってより一様に広がり、その結果、チャネルの処理がより公平になる場合がある。
【００５０】
本発明のさらなる実施形態によれば、スケジューラ論理回路は、処理すべきフレームの優先順位づけを、フレームのデータ・コンテンツに基づいて、たとえばメディア・タイプに基づいて行なっても良い。当業者であれば分かるように、ビデオ・メディアの場合、フレームは通常、フレームの３つのクラス、Ｉフレーム、Ｐフレーム、およびＢフレームのうちの１つに属する。
【００５１】
この点に関して、「Ｉ」フレームは空間情報のみを用いてエンコードする。このエンコードによって、フレーム自体からのわずかな冗長な情報もなくすことが試みられる。たとえば、絵（フレーム）の領域として、たとえば空を含むものがあった場合、おそらくその領域内のすべての点は実質的に同じであるため、その領域に対する情報を大幅に圧縮することができる。このような圧縮は、単にフレーム内の情報に基づいているため、Ｉフレームを、以前または後続のフレームに関する情報を必要とすることなくデコードすることができる。
【００５２】
また「Ｐ」フレームは、空間および時間情報を用いてエンコードする。空間情報は「Ｉ」フレームの場合と同じ方法で用いる。しかし時間情報は、先行のフレームから得られる情報を参照する。たとえば、連続的な絵（フレーム）に現れる画像は、たとえ異なる位置に現れているとしても、先行のフレームを参照することによってエンコードすることができる。このように、「Ｐ」フレームをデコードできるのは、参照する先行のフレームも利用できる場合のみであり、「Ｐ」フレームのみが独りで存在する場合ではないことがあり得る。
【００５３】
「Ｂ」フレームは、一般的に支持されている傾向にはない。しかし念のために、「Ｂ」フレームでは、参照として、先行するフレームおよび後続するフレームの両方を、エンコードを目的として用いている。したがって、「Ｂ」フレームをデコードできるのは、参照する先行および後続するフレームの両方も利用できる場合のみであり得る。
【００５４】
このように、本発明のこの実施形態においては、処理可能状態のフレームの優先度を次式から与えても良い。
Ｐｆ＝ｆｒａｍｅ＿ｄｅｌａｙ（フレーム遅延）−ｃｈａｎｎｅｌ＿ｐｒｏｃｅｓｓｉｎｇ＿ｌｅｎｇｔｈ（チャネル処理長さ）＋Δｆｒａｍｅ＿ｔｙｐｅ
ここで、Δｆｒａｍｅ＿ｔｙｐｅは、フレーム・タイプを表わすパラメータであり、フレームの優先度をフレームのタイプに基づいて上げることができるものである。たとえば「Ｉ」フレームに「Ｐ」フレームよりも高い優先度を与えることを、「Ｉ」フレームに対するΔｆｒａｍｅ＿ｔｙｐｅ（フレーム・タイプ）パラメータを、「Ｐ」フレームに対するΔｆｒａｍｅ＿ｔｙｐｅ（フレーム・タイプ）パラメータよりも高く設定することによって行なっても良い。この実施形態においては、Δｆｒａｍｅ＿ｔｙｐｅ（フレーム・タイプ）パラメータは、一定であっても良いし、あるいは動的に変わっても良いことが考えられる。たとえば、Δｆｒａｍｅ＿ｔｙｐｅ（フレーム・タイプ）パラメータは、トラフィック混雑に応じて変わっても良い。こうして、混雑が限られているかまたは無い場合には、Δｆｒａｍｅ＿ｔｙｐｅ（フレーム・タイプ）パラメータをすべてのフレーム・タイプに対して実質的に同じに設定して、すべてのフレームが実質的に同等に処理されるようにしても良い。しかし混雑の量が多い場合には、Ｉフレームに対するΔｆｒａｍｅ＿ｔｙｐｅ（フレーム・タイプ）パラメータを、たとえば、Ｐフレームに対するものよりも高く設定して、Ｉフレームに与える優先度の方を高くしても良い。したがって、あるチャネルに他のチャネルを上回る品質が要求される場合、このチャネルに対するΔを、他のチャネルが用いるΔよりも大きくなるように構成しても良い（たとえば、このチャネル上のＰフレームを、別のチャネルのＩおよびＰフレームよりも大きい優先度となるように構成する）。
【００５５】
当業者であれば分かるように、スケジューラ論理回路は、処理すべきフレームの優先順位づけを、前述の基準のいずれかに基づいて、単独でまたはそれらの任意の組み合わせで行なっても良い。このようにして、処理可能状態のフレームの優先度を、次式から与えても良い。
Ｐｆ＝ｆｒａｍｅ＿ｄｅｌａｙ（フレーム遅延）−ｃｈａｎｎｅｌ＿ｐｒｏｃｅｓｓｉｎｇ＿ｌｅｎｇｔｈ（チャネル処理長さ）＋ｕｒｇｅｎｔ＿ｃｎｔ（緊急ｃｎｔ）＋Δｆｒａｍｅ＿ｔｙｐｅ
本発明の代替的な実施形態によれば、スケジューラ論理回路はさらに、ＯＳ１４０が周期的に呼んでも良い割り込み論理回路を備えていても良い。この実施形態においては、割り込み論理回路は、周期的に呼ばれることによって、メディア処理に対する高速コンテキスト・スイッチを与えても良い。さらに、割り込み論理回路は、メディア・チャネルに対するコマンドなどを取り扱っても良い。また、信号プロセッサによって実行されるという点に関して、割り込み論理回路の方に、スケジューラ論理回路および処理エンジンの両方より高い優先度を与えても良い。
【００５６】
図１を再び参照して、例示した実施形態に対して前述したように、ゲートウェイ１００はコントローラ１５０を備えている。コントローラ１５０を、受信した制御データ・パケットを記憶するように構成しても良い。一例として、制御データ・パケットは次のうちの少なくとも１つを含んでいても良い。スケジューラ論理回路１１０に対するコマンド、チャネルに対するコマンド、およびリアル・タイム制御プロトコル（ＲＴＣＰ）データ・パケットである。
【００５７】
したがって、コントローラ１５０は、別個のコマンド待ち行列（図示せず）を備えていても良い。一例として、コントローラ１５０は、スケジューラ論理回路１１０（または各スケジューラ論理回路１１０）に対する待ち行列、各チャネルに対するチャネル・コマンド待ち行列、および各チャネルに対するＲＴＣＰ待ち行列を備えていても良い。スケジューラ論理回路１１０に対するコマンドは、単に一例として、「開チャネル」コマンド、「閉チャネル」コマンド、「変更チャネル・ステータス」コマンドなどを含んでいても良い。チャネルに対するコマンドは、カスタマイズされたフォーマットで発生させても良く、および／または、単に一例として、構成メッセージたとえば「設定トランスコーディング・タイプ」および／または「設定ＶＣＢ構成」、ステータス・メッセージたとえば「入手ＶＣＢ統計データ」などを含んでいても良い。
【００５８】
図５に、割り込み論理回路の動作例に対するフローチャート５００を例示する。フローチャートは、たとえば図１のＯＳ１４０に呼ばれたときに開始し、割り込み論理回路がフレーム処理に割り込んだ否か判定する（ステップ５１０）。フレーム処理が割り込まれていない場合（ステップ５１０）、フローチャートは終了する。他方で、割り込み論理回路がフレーム処理に割り込んでいた場合、割り込み論理回路はステップ５２０に移って、そこで任意の懸案事象を取り扱う。たとえば、前述したように、ゲートウェイは、受信した制御パケットを記憶するコントローラを備えていても良い。その結果、ステップ５２０において、割り込み論理回路はこの場合、コントローラが以前に記憶した任意の受信した制御データ・パケットを処理しても良い。
【００５９】
任意の懸案事象を取り扱ったら（ステップ５２０）、割り込み論理回路の動作はステップ５３０に移って、そこで、何らかのフレームが処理可能状態であるか否かを判定する（処理が割り込まれたフレーム以外）。処理可能状態のフレームがない場合には、フローチャート、したがって割り込み論理回路の動作は終了する。
【００６０】
本発明の任意的な実施形態において、何らかのフレームが処理可能状態であるか否かを判定する（ステップ５３０）前に、割り込み論理回路が、フレーム・データがすでにメモリ内にロードされて処理に備えているか否かを判定しても良い（処理が割り込まれたフレームの場合以外）。これをステップ５２５に示す。そうである場合には、割り込み論理回路は終了してチャネル選択は行なわない（ステップ５２８）。
【００６１】
１つまたは複数のフレームが処理可能状態である場合には（ステップ５３０）、割り込み論理回路の動作はステップ５４０に移って、そこで、最も高い優先度の処理可能状態のフレームを確認する。次にステップ５５０において、割り込み論理回路はＤＭＡユニットに指示を出して、確認したフレームに対するフレーム・データをメモリ内にロードさせ、その後にフローチャートおよび割り込み論理回路の動作は終了する。
【００６２】
次に図６を参照して、たとえば、図１のスケジューラ論理回路１１０および処理エンジン１３０が用いる信号処理動作に対する時系列６００を例示する。スケジューラ論理回路１１０および処理エンジン１３０はゲートウェイ・プロセッサ６１０によって実行される。図６にはＤＭＡのローディングのみを示しているが、ＤＭＡの記憶も存在すると考えられる。たとえば、フレーム「Ｗ」の処理が終了した後で、フレーム「Ｗ」データを外部メモリに記憶して、フレーム「Ｙ」に対するデータを（１つのＤＭＡチェーンにおける）内部メモリにロードする。
【００６３】
時系列６００はまた、本発明の実施形態による図１のゲートウェイ処理エンジン１３０が用いるメモリ位置６１５、６２０に対するメモリ位置作用を示す。特に、Ｔ３において、メモリ位置「２」に、フレーム「Ｙ」を処理するためのデータをロードする。次にメモリ位置に、フレーム「Ｚ」に対するデータをロードするのは図示した通りである。このフレーム「Ｚ」データのローディングによって、フレーム「Ｙ」に対するデータが上書きされる。したがって、Ｔ６において、フレーム「Ｙ」を処理するためのデータは無い。
【００６４】
例示した時系列は時間Ｔ０で開始し、ＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ）サブ・ルーチンを実行するスケジューラ論理回路の主な機能は、ゲートウェイ・プロセッサ６１０によって実行される。前述したように、ＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ）サブ・ルーチンはＶＣＢをポーリングして、処理可能状態のフレームを探す。一旦１つまたは複数のフレームが処理可能状態であるならば、スケジューラ論理回路は、最も高い優先度の処理可能状態のフレーム（フレームＷ）を確認して、それを処理するためにスケジュールする。ＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ）サブ・ルーチンは次に、さらなるフレームが処理可能状態であるか否かを判定し、そうである場合には、ＤＭＡユニットに指示を出して、確認したさらなるフレーム（フレームＸ）に対するフレーム・データをメモリ内にロードさせる。
【００６５】
本発明の一実施形態においては、メインのスケジューラ・ループ（ＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ）サブルーチン）を、システムからの最も低い割り込みとして実施しても良い。この実施形態においては、ＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ）サブ・ルーチンは、決して存在しない無限ループを含んでいても良い。その結果、この実施は、オペレーティング・システムの最も低いソフトウェア割り込みを使用し、システムが起動したときに一度トリガされる。本発明の代替的な実施形態においては、オペレーティング・システムを用いない場合、その機能をサブ・ルーチン・ループとして直接実施しても良いことが考えられる。
【００６６】
時間Ｔ１において、ＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ）サブ・ルーチンは、処理エンジン（たとえば図１の処理エンジン１３０）を呼び出して、処理エンジンが、処理すべき最も高い優先度のフレームであると確認されたフレーム（フレームＷ）を処理するようにする。
【００６７】
本発明の一実施形態においては、処理エンジン・モジュールを、スケジューラのメイン・ループ（すなわち、ＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ）サブ・ルーチン）が呼び出しても良い。本発明の一実施形態においては、処理エンジン・モジュールは、スケジューラのメイン・ループと同じ優先度であっても良い。しかし本発明の代替的な実施形態においては、処理エンジン・モジュールをより高い優先度を有するとして実施しても良いことが考えられる。こうして、ＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ）サブ・ルーチンが処理エンジンを呼び出したときに、信号プロセッサがＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ）サブ・ルーチンの実行を停止して、処理エンジンを実行する。処理エンジンは、スケジュールされたフレーム（フレームＷ）の処理を、適切なメモリ位置にロードされたフレーム・データに基づいて行なう。適切なメモリ位置は、時系列におけるその場合では、メモリ位置「２」６２０である。
【００６８】
やはり前述したように、ＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ）サブ・ルーチンは、さらなるフレームが処理可能状態であるか否かを判定して、そうである場合には、ＤＭＡユニットに指示を出して、確認したさらなるフレーム（フレームＸ）に対するフレーム・データをメモリ内にロードさせた。こうして、図６に例示したように、処理エンジンはフレームＷをメモリ位置「２」６２０から処理する一方で、ＤＭＡユニットは、既存のデータをメモリ位置「１」６１５から記憶し（妥当なデータであった場合）、次のフレーム（フレームＸ）に対するフレーム・データをメモリ位置「１」６１５内にロードする。
【００６９】
処理エンジンがフレームＷの処理を終了するとすぐに、時間Ｔ２において、信号プロセッサはＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ）サブ・ルーチンの実行を再開する。そしてＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ）サブ・ルーチンは一巡して戻り、処理は次のフレーム（フレームＸ）に対して再び開始する等。
【００７０】
図６に例示した実施形態の場合、処理エンジンがフレームＸを処理している間に、スケジューラ論理回路の割り込み論理回路（ＳＣＨ＿ｉｎｔ）を、時間Ｔ４において、たとえば図１のＯＳ１４０が呼び出す。前述したように、信号プロセッサによって実行されるという点に関して、ＳＣＨ＿ｉｎｔサブ・ルーチンの方が高い優先度で動作する。このように、ＳＣＨ＿ｉｎｔサブルーチンが呼び出されると、信号プロセッサは、処理エンジンの実行を停止して、ＳＣＨ＿ｉｎｔサブ・ルーチンを実行する。
【００７１】
ＳＣＨ＿ｉｎｔサブ・ルーチンは、任意の懸案事象（たとえば図１のコントローラ１５０が記憶した任意のコマンド）を取り扱った後に、何らかのフレームが処理可能状態であるか否かを判定する（フレームＸ以外）。たとえば、図６に例示したように、ＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ）サブルーチンが以前に、フレーム「Ｙ」を、処理可能状態にある次のフレームであると確認した。しかしＳＣＨ＿ｉｎｔサブ・ルーチンは、フレーム「Ｚ」を最も高い優先度の処理可能状態のフレームであると確認する。その理由はたとえば、フレーム「Ｚ」が、ＳＣＨ＿ｍａｉｎ＿ｌｏｏｐ（メイン・ループ）サブ・ルーチンの最後の実行以後に有効になっているからである。したがって、ＳＣＨ＿ｉｎｔサブ・ルーチンはＤＭＡユニットに指示を出して、フレーム「Ｚ」に対するフレーム・データをメモリ内にロードさせる。そしてＳＣＨ＿ｉｎｔサブ・ルーチンは終了し、信号プロセッサは処理エンジン１３０の実行を再開する。
【００７２】
本発明の代替的な実施形態によれば、何らかのフレームが処理可能状態であるか否かを判定する前に（例示した実施形態の場合はフレームＸ以外）、ＳＣＨ＿ｉｎｔサブ・ルーチンは、フレーム・データがすでにメモリ内（たとえば、例示した実施形態の場合はメモリ位置「２」）にロードされているか否かを判定しても良い。フレーム・データがすでに、次の処理すべきフレームに対してメモリ内にロードされている場合には、ＳＣＨ＿ｉｎｔサブ・ルーチンは終了する。こうして、図６に例示した実施形態の場合には、ＳＣＨ＿ｉｎｔサブ・ルーチンは、フレーム「Ｙ」データがメモリ位置「２」内にロードされていたことを確認して、何らかのフレーム（たとえば、フレーム「Ｚ」）が処理可能状態であるか否かを判定することなく、終了したであろう。
【００７３】
当業者であれば分かるように、スケジューラの割り込み論理回路を周期的に呼び出すことによって、メディア処理に対する高速コンテキスト・スイッチを与えても良い。さらに、本メカニズムは、受信したコマンドを周期的に処理する方法も提供する等である。
【００７４】
当然のことながら、メディア・ストリーム・チャネルの処理をスケジュールするための方法および装置は、前述したように、以下の優位性のうちの少なくとも１つまたは複数を提供することを目的とする。
（ｉ）処理すべきフレームの優先順位づけを改善することによって、ゲートウェイを通るメディア・ストリームの待ち時間を減らす一方で、より大きいチャネル密度、
（ｉｉ）周期的または非周期割り込み動作を通してのフレーム処理に対する高速コンテキスト・スイッチング、
（ｉｉｉ）システムが過負荷状態になったときのフレームの「緊急」モード処理を通しての優雅な劣化、
（ｉｖ）処理すべきフレームの優先順位づけの間にチャネル履歴を含めることを介してのチャネルのより公平な処理。
【００７５】
当然のことながら、異なる機能または論理ユニットまたはコントローラまたはメモリ要素の間での機能性の任意の好適な分配を、本明細書で説明した本発明の考え方を損なうことなく用いても良い。したがって、特定の機能デバイスまたは論理要素に言及することは、厳密な論理または物理構造または組織を示すものではなく、単に、記載した機能性を提供するための好適な手段への言及であると考えるべきものである。
【００７６】
本発明の態様は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの任意の組み合わせを含む任意の好適な形態で実施しても良い。本発明の実施形態の要素および構成部品は、任意の好適な方法で物理的、機能的、および論理的に実施しても良い。実際には、機能性は、単一のユニットもしくはＩＣで、複数のユニットもしくはＩＣで、または他の機能ユニットの一部として、実施しても良い。
【００７７】
当然のことながら、本発明のいくつかの実施形態では、１つもしくは複数の汎用もしくは専用プロセッサ、または「処理装置」、たとえばマイクロプロセッサ、デジタル・シグナル・プロセッサ、カスタマイズされたプロセッサもしくはフィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）が含まれていても良く、固有の記憶されたプログラム命令によって１つまたは複数のプロセッサを制御して、前述したメディア・ストリーム・チャネルの処理をスケジュールするための方法および装置の機能の一部または全部を実施しても良いことが考えられる。
【００７８】
また、本発明の実施形態を、コンピュータ読取可能なコードが記憶されたコンピュータ読取可能な記憶要素として実施して、本明細書で説明および請求した方法を行なうように処理装置をプログラムすることを図っても良いことが考えられる。このようなコンピュータ読取可能な記憶要素の例としては（これらに限定されないが）、以下のものが挙げられる。ハード・ディスク、ＣＤ−ＲＯＭ、光学記憶装置、磁気記憶装置、ＲＯＭ（読み出し専用メモリ）、ＰＲＯＭ（プログラマブル読み出し専用メモリ）、ＥＰＲＯＭ（消去可能なプログラマブル読み出し専用メモリ）、ＥＥＰＲＯＭ（電気的にプログラム可能な読み出し専用メモリ）、およびフラッシュ・メモリである。
【００７９】
本発明の実施形態をいくつかの実施形態と関連して説明してきたが、本明細書で述べた特定の形態に限定することは意図されていない。むしろ本発明の範囲は、添付の請求項のみによって限定される。さらに加えて、特徴を特定の実施形態と関連して説明したように見える場合があるが、当業者であれば分かるように、説明した実施形態の種々の特徴を本発明に従って組み合わせても良い。請求項では、用語「備える」は、他の要素またはステップの存在を除外するものではない。
【００８０】
さらに、個々の特徴を異なる請求項に含めても良いが、これらを優位に組み合わせることができる場合があり、異なる請求項に含めることには、異なる請求項の組において特徴を組み合わせることが実現可能および／または優位ではないという意味は含まれてはいない。また、１つのカテゴリの請求項に特徴を含めることには、そのカテゴリに限定するという意味は含まれておらず、むしろ、必要に応じて、特徴が他の請求項カテゴリに同等に適用可能であることを示す。
【００８１】
さらに、請求項における特徴の順序には、特徴を実行しなければならない何らかの特定の順序という意味は含まれていない。特に、方法の請求項における個々のステップの順序には、ステップをこの順序で実行しなければならないという意味は含まれていない。むしろ、ステップは任意の好適な順序で実行しても良い。加えて、単数形での言及は複数を除外するものではない。したがって、「第１」、「第２」などへの言及は、複数を排除するものではない。
【００８２】
以上、デコーダを備える改善されたデータ通信ユニット、データ通信ネットワーク、およびデコード方法について説明してきたが、従来技術の構成に付随する前述した不利点は実質的に軽減されている。
【図１】
2011501600.tif 000003
【図２】
2011501600.tif 000004
【図３】
2011501600.tif 000005
【図５】
2011501600.tif 000006
【図４】
2011501600.tif 000007
【図６】
2011501600.tif 000008
【手続補正書】
【提出日】平成22年10月25日(2010.10.25)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
パケット・ストリーム・チャネルの処理をスケジュールするための集積回路（１０５）であって、
少なくとも１つのパケット・ストリーム・チャネルが処理可能状態のフレームを含んでいるか否かを判定する論理回路であって、少なくとも１つのパケット・ストリーム・チャネルが処理可能状態のフレームを含んでいる場合に、最も高い優先度の処理可能状態のフレームを確認する前記論理回路と、
前記判定する論理回路に動作可能に結合され、確認した最も高い優先度のフレームを処理するためにスケジュールするように構成されたスケジューラ論理回路と
を備え、前記スケジューラ論理回路は、処理可能状態のフレームに少なくともフレーム有効時間と各フレームに対する推定処理時間とに基づいて優先順位をつけるように構成されていることを特徴とする集積回路（１０５）。
【請求項２】
前記スケジューラ論理回路は、処理可能状態のフレームのフレーム有効時間を、前記処理可能状態のフレームを完成させるデータ・パケットの最も古い到着時刻として算出するように構成されていることをさらに特徴とする請求項１に記載の集積回路（１０５）。
【請求項３】
前記スケジューラ論理回路は、処理可能状態のフレームに、（前記フレーム有効時間と現在時刻との間の差）−（前記フレームを処理する時間の長さの推定値）を計算することによって優先順位をつけるように構成されていることをさらに特徴とする請求項１または請求項２に記載の集積回路（１０５）。
【請求項４】
前記スケジューラ論理回路は、フレームをスケジュールする前にそのフレームの待ち時間を推定し、前記フレームの待ち時間が待ち時間閾値を超えた場合により高い優先度のフレームを処理するように構成されていることをさらに特徴とする請求項１乃至３のいずれか一項に記載の集積回路（１０５）。
【請求項５】
スケジューラ論理回路は、処理可能状態のフレームにさらに、
（ｉ）それらのフレームに対するチャネル履歴と、
（ｉｉ）それらのフレームに対するデータ・コンテンツと、
（ｉｉｉ）それらのフレームに対するフレーム・タイプと、
（ｉｖ）チャネル内のフレームをより高い優先度で処理する頻度と
のうちの少なくとも１つに基づいて優先順位をつけるように構成されていることをさらに特徴とする請求項１乃至４のいずれか一項に記載の集積回路（１０５）。
【請求項６】
データ・パケットを受信して記憶するように構成された複数のチャネル・バッファ（１２０）をさらに備え、前記スケジューラ論理回路は、少なくとも１つのパケット・ストリーム・チャネルが処理可能状態のフレームを含んでいるか否かを、複数のチャネル・バッファ（１２０）をポーリングして少なくとも１つのパケット・チャネル・フレームのステータスを得ることによって判定するように構成されていることをさらに特徴とする請求項１乃至５のいずれか一項に記載の集積回路（１０５）。
【請求項７】
パケット・ストリーム・チャネルの処理をスケジュールする方法を実行するようにコンピュータをプログラムするためのコンピュータ読取可能なコードが記憶されたコンピュータ読取可能な記憶要素であって、前記方法は、
少なくとも１つのパケット・ストリーム・チャネルが処理可能状態のフレームを含んでいるか否かを判定すること（２１０）、
少なくとも１つのパケット・ストリーム・チャネルが処理可能状態のフレームを含んでいる場合に、最も高い優先度の処理可能状態のフレームを確認し（２３０）、確認した最も高い優先度のフレームをスケジュールすること（２４０）
を含み、処理可能状態のフレームに、少なくともフレーム有効時間と各フレームに対する推定処理時間とに基づいて優先順位をつけることを特徴とするコンピュータ読取可能な記憶要素。
【国際調査報告】
2011501600.tif 000009
2011501600.tif 000010