JP3946465B2

JP3946465B2 - Ｉｐネットワークでのｍｐｅｇフロー識別

Info

Publication number: JP3946465B2
Application number: JP2001197616A
Authority: JP
Inventors: ピー．ハーンジョン; エヌ．マシューズキム; シー．ユークリストファー
Original assignee: ルーセントテクノロジーズインコーポレーテッド
Priority date: 2000-06-30
Filing date: 2001-06-29
Publication date: 2007-07-18
Anticipated expiration: 2021-06-29
Also published as: EP1175098B1; DE60100204T2; CA2345314A1; JP2002084323A; EP1175098A1; US7200670B1; CA2345314C; AU5411501A; DE60100204D1

Description

【０００１】
【発明の属する技術分野】
本発明は、インターネットプロトコル（ＩＰ）ネットワークを介してリアルタイム制約付き情報を伝送する分野に関し、特に、ＭＰＥＧ（Motion Picture Expert Group）−２符号化を用いて符号化されたビデオなどのリアルタイム制約付き情報の特定のストリームを識別し、それを適切な処理処置に与えられるようにすることに関する。
【０００２】
【従来の技術】
インターネットプロトコル（ＩＰ）ネットワークを介してリアルタイム制約付き情報を含むパケットを伝送する分野における問題は、各タイプの情報に適切な処理を与える必要があることである。これを行うために、ネットワークを通過する際に、パケットを処理する各ポイントにおいて、各パケットが含む情報のタイプを知る必要がある。特に、ＭＰＥＧ（Motion Picture Expert Group）−２符号化等を用いたビデオは、パケットドロップに対する耐性がない。したがって、ＭＰＥＧ−２ビデオを含むパケットストリームの処理に当たり、パケットドロップに対する敏感性が低い、または耐性のある他のストリームよりも、あらゆるＭＰＥＧ−２ビデオストリームを優先する必要がある。
【０００３】
従来技術では、たとえばパケットの内容を調べることにより、パケットが実際にＭＰＥＧ−２ビデオを含むか否かを実際に確かめることなく、予め定義された基準に基づいてパケットを優先させる。たとえば、パケットフローを定義し、そのフロー内のすべてのパケットがＭＰＥＧ−２パケットであるものと仮定し、そのフローからのパケットを、それぞれの実際の内容に関係なく、あたかもＭＰＥＧ−２パケットを含むかのように処理する。フローは、その発信ＩＰアドレスおよび宛先ＩＰアドレスを特定するか、またはその発信／宛先ポートアドレスを特定することで、定義されることが多い。
【０００４】
パケットを優先させるために用いられる別の従来技術は、ＩＰパケットヘッダの一部である、いわゆる「サービスタイプ（ＴＯＳ：Type - of - Service）に基づく。ＴＯＳを用いて粗い優先化（coarse prioritization）を示すことができ、それによりたとえば、ＴＯＳバイトが予め定義された値を有するか、あるいはＴＯＳバイトの値が少なくとも予め定義された値であるあらゆるパケットがＭＰＥＧ−２ビデオを含み、それに従って処理されると仮定する。
【０００５】
こういった従来技術は、本当にパケットがＭＰＥＧ−２ビデオを含んでいるか否かについて、パケットの内容を実際に調べないため、ＭＰＥＧ−２ビデオを含まないパケットを、あたかもＭＰＥＧ−２ビデオを含むかのように処理することが起こりうる。処理システムに十分な帯域幅がある場合には、こういった非ＭＰＥＧ−２パケットすなわちこういった偽のＭＰＥＧ−２パケットを本当に実際のＭＰＥＧ−２パケットであるかのように処理しても問題にはならない。しかし、帯域幅が限られている場合には（帯域幅の制限がないシステムとは、一体全体どんなシステムなのか）、こういった偽のＭＰＥＧ−２パケットをドロップすることのできない実際のＭＰＥＧ−２パケットとして処理すると、不必要にシステムの資源を消費することになる。さらに、こういった従来技術による優先化構成は、実際にはＭＰＥＧ−２ビデオではないのに、ＭＰＥＧ−２ビデオ送信中と示すようフローまたはＴＯＳバイトを設定する不謹慎なユーザにより悪用される可能性がある。
【０００６】
加えて、ＩＰネットワークでのフローセットアップ（フローは固定ポートを特定する静的構成である）では、フローを変更する必要がある、すなわち、ａ）ポイントツーポイント接続がポートの１つを変更するとき、ｂ）新しい接続を行ったとき、またはｃ）それと同様のことが発生したときに、その都度、管理および／または再構成する必要がある。フローを変更する必要があるときはその都度、ＭＰＥＧ−２ビデオストリームが流れる際に通る各交換機または処理ユニットを新しいフロー識別情報で更新しなければならないことに留意する。したがって、結果生じるフロー撹拌により、常に管理負担が存在する。
【０００７】
ＴＯＳバイトを用いてフローがＭＰＥＧ−２ビデオを含むと定義する従来技術の構成において生じる別の問題は、フローが通過するすべての交換機または処理ユニットが、ＭＰＥＧ−２ビデオを示す共通のＴＯＳバイト値、または該値のセットに同意する必要があることである。そうしないと、交換機または処理ユニットによっては、ＭＰＥＧ−２パケットを適宜処理しない、例えばＭＰＥＧ−２パケットをドロップするものがでてくる可能性がある。特に、フローが複数のネットワークを移行する場合、このような同意を調停することは実際には困難である。
【０００８】
【課題を解決するための手段】
従来技術に伴う問題を、従来技術で行われていたように、ＭＰＥＧ−２ビデオを含むか否かについての情報を含むと仮定される予め定義されたストリームまたは優先レベルを用いるのではなく、実際にパケットがＭＰＥＧ−２ビデオを含むか否かを決定することで、本発明の原理に従って克服できることが認められている。より具体的に、本発明の一態様によれば、ＭＰＥＧ−２の「同期」バイトがＩＰパケットペイロード内で検索され、同期バイトを示すパターンが見つかった場合には同期バイトを識別し、そのパケットがＭＰＥＧ−２ビデオを含むと決定する。同期バイトは、テレビ受像器がＭＰＥＧ−２トランスポートストリームパケットを同期できるようにするために、地上無線放送（over-the-air broadcasting）の場合にＭＰＥＧ−２において定義されたものである。ＭＰＥＧ−２ビデオ、たとえばＭＰＥＧ−２トランスポートストリームパケットは、ＩＰパケットに組み込まれる前に、リアルタイムプロトコル（ＲＴＰ）パケット内に組み込まれても、または組み込まれなくてもよいことに留意する。
【０００９】
【発明の実施の形態】
以下は、本発明の原理を単に説明するものである。したがって、当業者は、本明細書に明示的に記載または図示されていなくとも、本発明の原理を具現するとともに本発明の精神および範囲内に包含される各種構成を考案しうることが分かろう。さらに、本明細書に記載のすべての例および条件語は根本的に、読み手による本発明の原理および本発明者が捧げる概念の理解を助けて当分野を発展させる教示目的のみを意図するとともに、このように具体的に記載する例および条件に制限されないものと考慮される。さらに、本発明の原理、態様、および実施形態を本明細書において記述するすべての文、ならびにその特定例は、構造的同等物および機能的同等物の双方を包含するものと意図される。加えて、このような同等物には、現在知られている同等物、ならびに将来開発される同等物の双方、すなわち、開発される、構造に関係なく同一機能を実施するあらゆる要素が含まれるものと意図される。
【００１０】
したがって、たとえば、当業者は、本明細書におけるブロック図は、本発明の原理を具現する例示的な回路の概念図を表すことが分かろう。同様に、あらゆるフローチャート、流れ図、状態遷移図、擬似コードなどは、コンピュータまたはプロセッサが明示的に図示されているか否かに関わらず、実質的にコンピュータ読み取り可能媒体において表現し、かつコンピュータまたはプロセッサにより実行可能な各種プロセスを表すことも分かろう。
【００１１】
「プロセッサ」とラベル付けられた機能ブロックを含め、図示する各種要素の機能は、専用ハードウェアならびに適切なソフトウェアに関連するソフトウェアを実行可能なハードウェアの使用を通して提供することができる。プロセッサによって提供される場合、単一の専用プロセッサにより、単一の共有プロセッサにより、またはいくつかが共有される場合もある複数の個々のプロセッサにより、機能を提供しうる。さらに、「プロセッサ」または「コントローラ」という語の明示的な使用は、ソフトウェアを実行可能なハードウェアを排他的に指すものと解釈すべきではなく、制限なしでデジタル信号プロセッサ（ＤＳＰ）ハードウェア、ソフトウェアを格納するための読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、および不揮発性記憶装置を暗黙的に含みうる。従来のハードウェアおよび／またはカスタムハードウェアの他のハードウェアもまた含まれうる。同様に、図に示すあらゆる交換機は、概念のみのものである。それら交換機の機能は、プログラム論理の動作、専用論理、プログラム制御と専用論理の相互作用を通して、さらには手動で実行可能であり、文脈からより具体的に理解するにつれ、実施者が特定の技術を選択可能である。
【００１２】
本発明の特許請求の範囲において、特定の機能を実行する手段として表現される任意の要素は、その機能を実行する任意の方法を包含するものと意図され、たとえば、ａ）その機能を実行する回路素子の組み合わせ、またはｂ）任意の形態のソフトウェア（よって、ファームウェア、マイクロコードなどを含む）とそのソフトウェアを実行して該機能を行う適切な回路との組み合わせ、が含まれる。このような特許請求の範囲によって定義される本発明は、実際、記載される各種手段によって提供される機能性を組み合わせ、特許請求の範囲が要求する様式で寄せ集めることに存在する。したがって、出願人は、これらの機能性を提供可能なあらゆる手段を本明細書に示すものの同等物と見なす。
【００１３】
本明細において別記しない限り、図面は一定の比率で描画されたものではない。
【００１４】
図１は、本発明の原理に従い、パケットのＩＰデータペイロードのみに基づいて、ＭＰＥＧ−２ビデオを含むか否かについての決定を行うことができる、一般的なタイプのインターネットプロトコル（ＩＰ）パケット１０１である。より具体的に、本発明の一態様によれば、パケット１０１のＩＰパケットデータペイロード内のＭＰＥＧ−２ストリームの「同期」バイトを検索する。同期バイトを示すパターンが見つかると、そのパケットがＭＰＥＧ−２ビデオを含むものと決定する。見つからない場合には、そのパケットがＭＰＥＧ−２ビデオではない情報を含むものと決定する。
【００１５】
パケット１０１は、ＩＰデータペイロード１１１に先行する一連のヘッダを有する。特に、パケット１０１は、２０バイト長のＩＰヘッダ１０５と、８バイト長の、信頼性のないデータグラムプロトコル／伝送制御プロトコル（ＵＤＰ／ＴＣＰ）ヘッダ１０７と、を含む。従来のＩＰヘッダ１０５およびＵＤＰ／ＴＣＰヘッダ１０７は、従来通り共にグループ化され、ＩＰパケットのヘッダと呼ばれることに留意する。説明を明確にする目的および教示目的のためにのみ、これらを図１において別個に示している。
【００１６】
ＩＰパケット１０１は、図示のように、ＵＤＰパケットであることに留意する。これは、現時点で、ＴＣＰがエンドツーエンド通信を必要とすることから、ＵＤＰが通常リアルタイムストリーミングに用いられるためである。したがって、本発明について、本明細書ではＩＰにおけるＵＤＰパケットに関して説明する。しかし、当業者は、本発明の原理をＴＣＰパケットに適用する方法を容易に認識しよう。
【００１７】
ＵＤＰ／ＴＣＰヘッダ１０７の後には、ＩＰデータペイロード１１１が続く。ＩＰデータペイロード１１１内に含まれるバイト数は０以上の範囲と柔軟性があるが、イーサネットなど特定の伝送構成では他の制限が課される場合がある。オプションのリアルタイムプロトコル（ＲＴＰ）ヘッダ１０９は、存在する場合、１２バイト長であり、ＩＰデータペイロード１１１内にある。
【００１８】
図２は、ＩＰデータペイロード１１１を拡張したものを示し、これは、パケット１０１がＵＤＰパケットであるように、ＵＤＰデータペイロードである。図２は、ＵＤＰデータペイロード１１１がＭＰＥＧ−２ビデオを搬送する一例を示している。上述したように、ＲＴＰヘッダ１０９はＵＤＰデータペイロード１１１内のＭＰＥＧ−２ビデオに先行しうる。
【００１９】
課される任意のサイズ制限に準拠して、ＵＤＰデータペイロード１１１は、あらゆる任意の数のＭＰＥＧ−２トランスポートストリームパケット２０１を搬送することができる。ＭＰＥＧ−２トランスポートストリームパケット２０１はそれぞれ、１８８バイト長である。ＭＰＥＧ−２トランスポートレイヤの定義により、各ＭＰＥＧ−２トランスポートストリームパケット２０１の最初のバイトは常にいわゆる「同期」バイト２０３であり、これは０×４７の値を有する。
【００２０】
本発明の原理によれば、同期バイトの間隔は規則的であるため、ＭＰＥＧ−２ビデオの予期されるパターン、すなわちＵＤＰデータペイロード１１１の（任意のオプションとしてのＲＴＰヘッダの後の）、最初のバイトが同期バイトであり、その後に１８８の倍数であるＵＤＰデータペイロード１１１における各バイト位置に同期バイトがあるパターンの存在について、ＵＤＰデータペイロード１１１を検索することが可能である。同期バイトをＵＤＰデータペイロード１１１の（任意のオプションのＲＴＰヘッダの後の）最初のバイトとして見つけることは、そのＩＰパケットがＭＰＥＧ−２ビデオを含むことを強く示唆するとともに、最初のバイトがＭＰＥＧ−２ビデオを含むパケットである同期バイト値を有する、長さ１８８のＵＤＰデータペイロードの場合、好ましくは潜在的な各同期バイト位置をチェックすべきであるものと仮定される。これは、ＭＰＥＧ−２ビデオが実際に発見される信頼度が、各位置が実際に同期バイト値を含む場合にかなり高くなるからである。
【００２１】
予期される位置の殆どが同期バイトを含むが、１つまたは複数の位置が同期バイトを含まない場合、そのパケットをＭＰＥＧ−２ビデオを含むものとして宣言するか否かは、システムの設計時または構成時に実施者により決定される。たとえば、同期バイトであると予期される位置のうちのたった１つが同期バイトではなく、かつＩＰパケットが伝送エラーを有すると示されている場合、実施者は、システムに依然としてそのパケットをＭＰＥＧ−２ビデオを含むものとして処理させるよう決定することができる。
【００２２】
図３は、本発明の原理に従い、ＩＰパケットを処理してＭＰＥＧ−２ビデオを含むか否かを決定する例示的なプロセスをフローチャートの形態で示す。本プロセスは、ＩＰパケットを受信したときに、ステップ３０１において開始される。次に、ステップ３０３において、パケットを処理し、パケット内のＵＤＰデータペイロードをポイントするポインタ、すなわちパケット内をポイントするポインタがＵＤＰデータペイロードをポイントするよう増分する。その後、条件分岐点３０５でテストを行い、ＵＤＰデータペイロードの長さが１８８の倍数であるか否かを決定する。ステップ３０５におけるテスト結果が「イエス」である場合、これはＲＴＰヘッダがなく、かつＵＤＰデータペイロードの長さがＭＰＥＧ−２トランスポートストリームパケットの長さの倍数に対応することを示し、制御が条件分岐点３０７に渡り、ここでテストを行い、ポインタがポイントするＵＤＰデータペイロードのバイトが同期バイトの値、たとえば０×４７であるか否かを決定する。
【００２３】
ステップ３０７におけるテスト結果がイエスである場合、制御はステップ３０９に渡り、ここでポインタを１８８バイト、すなわちＭＰＥＧ−２トランスポートストリームパケットの長さだけ増分する。この結果、ポインタがａ）ＵＤＰデータペイロードが実際にＭＰＥＧ−２ビデオを含んでいる場合には、次のＭＰＥＧ−２トランスポートストリームパケットの冒頭、またはパケットの末端でもあるＵＤＰデータペイロードの末端を、あるいはｂ）ＵＤＰデータペイロードが実際にはＭＰＥＧ−２ビデオを含んでいない場合には、単なる無作為のバイトをポイントする。その後、制御は条件分岐点３１１に渡り、ここでテストを行い、ＩＰパケットの末端に達したか否かを決定する。ステップ３１１におけるテスト結果がノーである場合、これは処理するＵＤＰデータペイロードのさらなる部分がまだ残っていることを示し、制御がステップ３０７に戻り、パケットの残りを上述したように処理する。ステップ３１１におけるテスト結果がイエスである場合、制御はステップ３１３に渡り、本発明の一態様に従って、そのＩＰパケットがＭＰＥＧ−２ビデオを含むと宣言する。次に、該ＩＰパケットをそれに応じてさらに処理しうる。本プロセスは、ステップ３１５において終了する。
【００２４】
ステップ３０７におけるテスト結果がノーである場合、これは１８８の倍数位置の最初のバイトまたは別のバイトが同期バイトの値ではないことを示し、制御はステップ３１５に渡り、本プロセスが終了する。
【００２５】
ステップ３０５におけるテスト結果がノーである場合、制御は条件分岐点３１７に渡り、ここでテストを行い、ＵＤＰデータペイロードの長さが１８８にＲＴＰヘッダの長さを足したものの倍数に等しいか否かを決定する。ステップ３１７におけるテスト結果がイエスである場合、これはＵＤＰデータペイロードがＲＴＰヘッダを含み、したがってＭＰＥＧ−２トランスポートストリームパケットでありうることを示し、制御がステップ条件分岐点３１９に渡ってテストを行い、長さがＲＴＰヘッダに対応するＵＤＰデータペイロードの最初のバイトがＲＴＰヘッダの特徴を有しているか否か、たとえば、ペイロードタイプフィールドがあると予期される場所にビデオインジケータがあるか否かを決定する。より具体的に、ペイロードタイプフィールドは７ビットであり、ＭＰＥＧ−２トランスポートストリームデータについての定義は０×２１である。
【００２６】
ステップ３１９におけるテスト結果がノーである場合、これはＲＴＰヘッダがない、またはヘッダがビデオを示すものではないことを示し、制御はステップ３１５に渡り、ＩＰパケットをＭＰＥＧ−２ビデオを含むものであると宣言せずに、本プロセスが終了する。ステップ３１９におけるテスト結果がイエスである場合、これはビデオ用のＲＴＰヘッダが見つかったことを示し、制御がステップ３２１に渡り、ここでポインタをＲＴＰヘッダの後の最初のバイトをポイントするよう増分する。次に、制御は条件分岐点３０７に渡り、本プロセスが上述したように継続する。
【００２７】
ステップ３１７におけるテスト結果がノーである場合、これはＩＰパケットが整数のＭＰＥＧ−２ビデオトランスポートストリームパケットを含まないことを示し、制御がステップ３２３に渡り、ここでＵＤＰデータペイロードへのオフセットとして用いるカウンタ変数ＣＯＵＮＴを０に設定する。次に、条件分岐点３２５において、ＣＯＵＮＴが１８８とＲＴＰヘッダの長さの和に等しいか否かを決定する。ステップ３２５におけるテスト結果がイエスである場合、これはＵＤＰデータペイロードにおいて最初のＭＰＥＧ−２ビデオトランスポートストリームパケットの同期バイトを潜在的に含みうるすべての位置をテストし、かつ同期バイトが見つからなかったことを示し、本プロセスはステップ３１５において終了する。すなわち、パケットはＭＰＥＧ−２ビデオを含んでいると宣言されない。ステップ３２５におけるテスト結果がノーである場合、これはＵＤＰデータペイロードにおいて最初のＭＰＥＧ−２ビデオトランスポートストリームパケットの同期バイトを潜在的に含みうる位置をすべてはテストしていないことを示し、制御が条件分岐点３２７に渡り、ここで別のポインタＰＡＣＫＴＰＴをＣＯＵＮＴの値に設定する。
【００２８】
その後、ステップ３２９において、ＵＤＰデータペイロード内の、ＰＡＣＫＴＰＴがポイントするバイトをテストして、該バイトが同期バイトの値を有するか否かを決定する。ステップ３２９におけるテスト結果がノーである場合、これはＰＡＣＫＴＰＴが現在ポイントしているバイトが同期バイトではないことを示し、制御がステップ３３１に渡り、ここでＣＯＵＮＴがＵＤＰデータペイロードにおける次のバイトをポイントするようにＣＯＵＮＴを増分する。次に、制御はステップ３２５に戻り、本プロセスが上述したように継続する。
【００２９】
ステップ３２９におけるテスト結果がイエスである場合、これはＰＡＣＫＴＰＴが現在ポイントしているバイトが本当に同期バイトの値を有することを示し、制御が条件分岐点３３３に渡ってテストを行い、ＣＯＵＮＴがポイントしている場所からパケットにおける残りの数のバイトが１８８未満であるか否かを決定する。ステップ３３３におけるテスト結果がイエスである場合、これはＭＰＥＧ−２ビデオトランスポートストリームパケット全体をＵＤＰデータペイロード内に含むことは不可能なことを示し、制御がステップ３１５に渡り、本プロセスが終了する。すなわち、パケットは、ＭＰＥＧ−２ビデオを含むと宣言されない。ステップ３３３におけるテスト結果がノーである場合、これはＭＰＥＧ−２ビデオトランスポートストリームパケット全体をＵＤＰデータペイロード内に含むことが可能なことを示し、制御はステップ３３５に渡り、ここでＰＡＣＫＴＰＴを１８８だけ増分する。
【００３０】
この時点で、ＵＤＰデータペイロードが実際にＭＰＥＧ−２ビデオを含み、かつＣＯＵＮＴが現在ポイントしているバイトが同期バイトである場合、ＰＡＣＫＴＰＴがポイントしているバイトも同期バイトの値を有するか、またはパケットの末端または末端を越えた場所にあるはずである。このために、条件分岐点３３７において、テストを行い、パケットの末端に達しているか、または末端を越えているか否かを決定する。ステップ３３７におけるテスト結果がノーである場合、これはＰＡＣＫＴＰＴがＵＤＰデータペイロード内のバイトをポイントしていることを示し、制御がステップ３２９に戻り、本プロセスが上述したように継続する。ステップ３３７におけるテスト結果がイエスである場合、これはＰＡＣＫＴＰＴがパケットの末端または末端を越えた場所をポイントしていることを示し、制御がステップ３１３に渡り、本プロセスが上述したように継続する。
【００３１】
ＩＰに関する明細書の説明は、本出願を作成する時点において本質的に広く使用されているＩＰバージョン４を指すことに留意する。当業者は、本発明の原理を後に開発されたＩＰバーション、たとえば、実施されるはずの提案されているバージョン６などに容易に適用できよう。
【図面の簡単な説明】
【図１】本発明の原理に従い、パケットのＩＰデータペイロードのみに基づいてＭＰＥＧ−２を含むか否かについて決定を行うことができる、一般的なタイプのインターネットプロトコル（ＩＰ）パケットを示す。
【図２】図１に示すパケットの一部を拡大したものを示す。
【図３】本発明の原理に従い、ＩＰパケットを処理してＭＰＥＧ−２ビデオを含むか否かを決定する例示的なプロセスをフローチャートの形態で示す。

Claims

インターネットプロトコル（IP）パケット（１０１、１１１）を処理する方法であって、前記パケットがMPEG（Motion Picture Expert Group）―２ビデオを含むことを、IPデータペイロード内のリアルタイムプロトコル（RTP）ヘッダ情報を除く前記IPパケットの前記IPデータペイロード（１１１）の内容のみに基づいて識別するステップを含み、
前記識別ステップは、前記ＩＰデータペイロード内に、ＭＰＥＧ−２ビデオの存在を示すＭＰＥＧ−２同期バイトの少なくとも１つの予期されるパターンがあるか否かを決定することで該識別を行っている方法。
前記識別ステップにおいて、前記パケットがＭＰＥＧ−２ビデオを含むと識別された場合、該ＭＰＥＧ−２ビデオを含むパケットに割り当てられた優先度を用いて、前記ＩＰパケットを処理するステップをさらに含む、請求項１記載の方法。
前記決定は、
前記ＩＰデータペイロードの、リアルタイムプロトコル（ＲＴＰ）ヘッダ後の最初のバイトをＭＰＥＧ−２同期バイトの値と比較するステップと、
該比較ステップの結果が、前記ＩＰデータペイロードの前記最初のバイトがＭＰＥＧ−２同期バイトと同じ値であるという場合、前記ＩＰパケットをＭＰＥＧ−２パケットであるとするステップと、
からなるものである請求項１記載の方法。
前記決定は、
前記ＩＰデータペイロードの、ＲＴＰヘッダ後の最初のバイトをＭＰＥＧ−２同期バイトの値と比較するステップと、
該比較ステップの結果が、前記ＩＰデータペイロードの前記最初のバイトがＭＰＥＧ−２同期バイトであり、かつＲＴＰヘッダ後の前記ＩＰデータペイロードの長さがＭＰＥＧ−２トランスポートストリームパケットの長さと同じである場合、前記ＩＰパケットをＭＰＥＧ−２パケットであるとするステップとからなるものである請求項１記載の方法。
前記決定は、
前記ＩＰデータペイロードの長さまたは前記ＩＰデータペイロードからＲＴＰヘッダの長さを引いたものが、ＭＰＥＧ−２トランスポートストリームパケットの長さの整数倍ではない場合に、前記方法を終了し、前記予期されるパターンが前記パケットに存在しないことを示し、
ポインタを前記ＩＰデータペイロード内のあるバイトにポイントさせるステップであって、前記ＩＰデータペイロードの前記長さがＭＰＥＧ−２トランスポートストリームパケットの長さの整数倍である場合、前記バイトは前記ＩＰデータペイロードにおける最初のバイトであり、そして前記ＩＰデータペイロードからＲＴＰヘッダの長さを引いたものがＭＰＥＧ−２トランスポートストリームパケットの長さの整数倍である場合、前記バイトは前記ＩＰデータペイロードにおける、リアルタイムプロトコル（ＲＴＰ）ヘッダの長さの後の最初のバイトである、ポイントさせるステップと、
ポイントされている前記バイトと、ＭＰＥＧ−２同期バイトの値との比較を実行し、最新の比較結果において、前記ＩＰデータペイロードの前記ポイントされたバイトがＭＰＥＧ−２同期バイトと同じ値であるという場合、前記ＩＰパケットをＭＰＥＧ−２パケットの候補であると宣言する比較実行ステップと、
ＭＰＥＧ−２トランスポートストリームパケットの長さだけ前記ＩＰパケットの末端に向けてオフセットした、前記ＩＰデータペイロード内のバイトをポイントするよう前記ポインタを調整するステップと、
最新の前記比較実行が前記ＩＰパケットをＭＰＥＧ−２パケットの候補であると宣言し、かつ前記調整ステップで前記ＩＰデータペイロードの末端にまだ達していない間は、前記比較実行ステップおよび前記調整ステップを繰り返すステップと、
前記調整ステップの実行を試みる間に前記ＩＰデータペイロードの末端に達し、かつ前記最新の比較の実行ステップが前記ＩＰパケットをＭＰＥＧ−２パケットの候補であると宣言した場合、前記パケットをＭＰＥＧ−２パケットであるとするステップと、
をさらに含む、請求項１記載の方法。
前記決定は、リアルタイムプロトコルヘッダの長さおよび１つのＭＰＥＧ−２トランスポートストリームパケットの長さに渡る検索により、同期バイトがあるところから１つのＭＰＥＧ−２トランスポートストリームの長さだけオフセットしたところに別の同期バイトがある場合に、前記ＩＰパケットをＭＰＥＧ−２パケットであるとする、請求項１記載の方法。
前記決定は、リアルタイムプロトコルヘッダの長さおよび１つのＭＰＥＧ−２トランスポートストリームパケットの長さに渡る検索により、前記ＩＰパケットの末端に達するか、または末端を越えるまで、同期バイトの値があるところから１つのＭＰＥＧ−２トランスポートストリームパケットの長さのそれぞれ整数倍だけオフセットしたところに同期バイトの値が見つかる場合、前記ＩＰパケットをＭＰＥＧ−２パケットであるとする、請求項１記載の方法。
前記決定ステップは、リアルタイムプロトコルヘッダの長さおよび１つのＭＰＥＧ−２トランスポートストリームパケットの長さに渡る検索により、パケットの末端があるところから１つのＭＰＥＧ−２トランスポートストリームパケットの長さだけオフセットしたところに同期バイトの値が見つかる場合、前記ＩＰパケットをＭＰＥＧ−２パケットであるとする、請求項１記載の方法。
前記少なくとも１つの予期されるパターンは、ａ）前記ＩＰデータペイロードのリアルタイムプロトコル（ＲＴＰ）ヘッダ（１０９）の長さ後の最初のバイトがＭＰＥＧ−２同期バイトの値であり、かつ前記ＲＴＰヘッダの長さ後の前記ＩＰデータペイロードが１８８バイトの長さを有するパターン、ｂ）前記ＩＰペイロードのリアルタイムプロトコル（ＲＴＰ）ヘッダの長さ後の最初のバイト、およびその後前記ＩＰデータペイロードの末端まで１８８バイト毎に、ＭＰＥＧ−２同期バイトの値があるパターン、ｃ）前記ＩＰデータペイロードの最初のバイト、およびその後前記ＩＰデータペイロードの末端まで１８８バイト毎にＭＰＥＧ−２同期バイトの値があるパターン、ｄ）前記ＩＰデータペイロードの最初のバイトがＭＰＥＧ−２同期バイトの値であり、かつ前記ＩＰデータペイロードが１８８バイトの長さを有するパターン、からなるパターンセットのうちの少なくとも１つである請求項１記載の方法。