JP5711143B2 - 高信頼マルチキャスト・ストリーミングを行う方法および装置 - Google Patents

Description

本発明は、ネットワーク伝送に関し、特に、ＷＬＡＮにおいてマルチキャスト・オーバ・ユニキャスト（ｍｕｌｔｉｃａｓｔ−ｏｖｅｒ−ｕｎｉｃａｓｔ）伝送方式を用いる方法および装置に関する。

アクセス・ポイント（ＡＰ）やブリッジ、ルータなど、移動装置およびその他のネットワークへのアクセスを提供する中間装置を定義するＩＥＥＥ８０２．１１標準に基づく無線ローカル・エリア・ネットワークすなわちＷＬＡＮでは、ビデオ伝送、とりわけ実時間伝送を行うのに、ブロードキャスト／マルチキャスト伝送が必要である。しかし、ブロードキャスト／マルチキャスト伝送には、誤り訂正機構を本質的に欠いているという問題がある。一群の受信側に対してデータ・パケットを送信（ブロードキャスト／マルチキャスト）するときに、伝送側が各受信側の再送プロトコルを管理することは、不可能とまでは言えないが、極めて困難である。

具体的には順方向誤り訂正（ＦＥＣ）やマルチキャスト自動再送要求（ＡＲＱ）など、データ・パケット喪失を克服するための機構はいくつかある。しかし、これらの機構には例外なく、一部のネットワークにおいて複雑さと制限事項が大きく増加するという問題がある。例えば、アクセス・ポイント（ＡＰ）やブリッジなど一部のＷＬＡＮ中間装置では、マルチキャストの品質は例えば受信状態が最悪の移動端末などクライアントによる制限を受けるという前提の下、ＷＬＡＮマルチキャスト・データ・パケットの伝送速度に本質的な制限がある。なお、本明細書では、ブリッジおよび／またはＡＰという用語は、ルータおよび／またはブルータ、あるいはそれらと同等の機能を有する任意の装置も含むものとして使用している。また、全てのマルチキャスト・パケットを、マルチキャスト・オーバ・ユニキャスト方式を用いて伝送する機構もあるが、この方式は、当然、スケーラビリティの問題を生じる。帯域幅に制限があるために、全てのマルチキャスト・パケットをマルチキャスト・オーバ・ユニキャスト方式を用いて伝送した場合に、それらのマルチキャスト・パケットを同時に受信することができる端末の数も、帯域幅によって制限されることになるからである。

第１の特徴では、ネットワーク中で第１のパケット・セットを含むパケット・ストリームを伝送する方法を提供する。この方法は、第１のストリーム中でマルチキャスト・モードで前記第１のパケット・セットを受信し、第２のストリーム中でマルチキャスト・モードで第２のパケット・セットを受信するステップであり、前記第２のパケット・セットが、前記第１のパケット・セットのパケットのサブセットであり、前記パケットの重要度に基づいて復号のために選択されるステップと、前記第１のパケット・セットを少なくとも１つの受信側にマルチキャスト・モードで送信し、前記第２のパケット・セットを前記少なくとも１つの受信側のうちの１つまたは複数の受信側にユニキャスト・モードで送信するステップと、を含む。

詳細には、第１のパケット・セットは、マルチキャスト・グループのマルチキャストＩＰアドレスおよび対応するマルチキャストＭＡＣアドレスを有するマルチキャスト・パケットにカプセル化され、第２のパケット・セットを少なくとも１つの受信側に送信するときには、第２のパケット・セットに含まれるマルチキャストＭＡＣアドレスが、前記少なくとも１つの受信側のＭＡＣアドレスに変更される。

さらに、第２のパケット・セットは、前記１つまたは複数の受信側から送信される前記第２のパケット・セットのマルチキャスト・グループへの加入を求める要求に応答して、前記１つまたは複数の受信側に伝送される。

さらに、第２のパケット・セットは、第１のパケット・セットのペイロード・データを復号するために重要度に基づいて選択される。

上記の方法では、前記第２のパケット・セットは、ビデオ・ストリームのＩフレームまたはベース・レイヤ・パケットを復号するために必要なパケットである。

第２の特徴では、ネットワーク中で第１のパケット・セットを含むパケット・ストリームを受信する方法について述べる。この方法は、第１のパケット・セットをマルチキャスト・モードで受信するステップと、第１のパケット・セットのパケットのサブセットであり、復号のために前記パケットの重要度に基づいて選択された第２のパケット・セットを、ユニキャスト・モードで受信するステップと、第２のパケット・セットのパケットを用いて、第１のパケット・セットの、喪失した、または訂正不可能なパケットを置換するステップと、を含む。

第２の特徴の方法では、第１のパケット・セットは、マルチキャスト・グループのマルチキャストＩＰアドレスおよび対応するマルチキャストＭＡＣアドレスを有するマルチキャスト・パケットにカプセル化され、第２のパケット・セットが送信されるときには、第２のパケット・セットに含まれるマルチキャストＭＡＣアドレスが、ユニキャストＭＡＣアドレスに変更される。

さらに、第２の特徴は、第１のパケット・セットに対応するマルチキャスト・グループに加入するステップと、第２のパケット・セットのユニキャスト伝送をトリガするために、第２のマルチキャスト・グループに加入するステップとをさらに含む。

さらに、前記パケットのサブセットは、ビデオ・ストリームのＩフレームまたはベース・レイヤ・パケットを復号するために必要なパケットである。

本発明のネットワーク・システムの実施例を示す図である。 イーサネット(登録商標)フレームの例示的なフォーマットを示す図である。 マルチキャスト・パケットの例示的なフォーマットを示す図である。 マルチキャスト・オーバ・ユニキャスト機構を用いる図２ｂのマルチキャスト・パケットの例示的なフォーマットを示す図である。 本発明のネットワーク・システムのプロセスを示す流れ図である。 本発明のネットワーク・システム中のＱｏＳサーバにおけるプロセスを示す流れ図である。 本発明のネットワーク・システム中のＱｏＳエージェントを有するＡＰにおけるプロセスを示す流れ図である。 ネットワーク・システムの構造を示すブロック図である。

図１は、本発明の実施例による、無線ローカル・エリア・ネットワーク（ＷＬＡＮ）を含むネットワーク・システムを示すブロック図である。図１に示すように、メディア・サーバ１、複数の移動局２、ＱｏＳ（サービス品質）サーバ３、ＱｏＳエージェント５を内部に備えたＡＰ（アクセス・ポイント）４、およびルータ６がある。メディア・サーバ１およびＱｏＳサーバ３は、例えばＩＥＥＥ８０２．３ＬＡＮなどのＬＡＮ内にある。複数のＭＳ２は、例えばＩＥＥＥ８０２．１１無線ＬＡＮなどのＷＬＡＮ内にあり、ＡＰ４を介してＬＡＮに接続される。

図１の例では、マルチキャスト・メディア・ストリームは、ビデオ・ストリームＡである。メディア・サーバ１では、最初にビデオ・ストリームＡがＩＰパケットにカプセル化され、その後、これらのＩＰパケットが、イーサネット（登録商標）ＭＡＣフレーム・フォーマットにカプセル化される。図２ａは、ＩＥＥＥ８０２．３プロトコルによるイーサネット（登録商標）ＭＡＣフレーム・フォーマットを示す図である。イーサネット（登録商標）ＭＡＣヘッダを付加された各ＩＰパケット（「データ」フィールド）を、イーサネット（登録商標）ＭＡＣフレームと呼ぶ。ＩＰパケット中では、「宛先ＩＰアドレス」フィールドは、パケットが経路指定された宛先ＩＰアドレスである。「ソースＩＰアドレス」は、パケットがどこから来たかを示している。マルチキャスト伝送では、宛先ＩＰアドレスは、マルチキャストＩＰアドレスである。ＭＡＣヘッダに含まれる「宛先ＭＡＣアドレス」フィールドは、ＩＰパケットが経路指定されることになる宛先を特定するために使用される。なお、一般的なマルチキャスト・パケットでは、この含まれる宛先ＭＡＣアドレスは、マルチキャストＩＰアドレスに対応するマルチキャストＭＡＣアドレスである。そのため、ビデオ・ストリームＡについては、マルチキャスト・グループはＡ１、マルチキャスト・グループの宛先ＭＡＣアドレスはＡ２（０１−００−５ｅ−０１−０１−０１）、およびマルチキャスト・グループの宛先ＩＰアドレスはＡ２’（例えば２３０．１．１．１）である。ソースＭＡＣアドレスは、メディア・サーバ１のＭＡＣアドレスであり、ソースＩＰアドレスは、メディア・サーバ１のＩＰアドレスである。

例えばマルチキャスト・ビデオ・ストリームＡなどのマルチキャスト伝送の前に、メディア・サーバ１は、セッション記述を含む適当なアナウンスメントを行う。標準的なセッション記述は、インターネット技術タスク・フォースのドラフトＲＦＣ２３２７に定義されるように、セッション記述プロトコル（ＳＤＰ）を用いて生成される。ＳＤＰは、実時間マルチメディア・セッションおよびそれらに関連するスケジューリング情報を記述するために使用される、単純なＡＳＣＩＩテキスト・ベースのプロトコルである。ＳＤＰメッセージは、マルチキャスト・セッションの各メディア・ストリームについての情報を搬送して、受信者がセッションに加入することができるようにする。ＳＤＰ情報に含まれるメディア情報は、メディアのタイプ（例えばビデオ、オーディオなど）、トランスポート・プロトコル（例えばＲＴＰ、ＵＤＰまたはＩＰなど）、メディアのフォーマット（例えばＭＰＥＧビデオなど）、メディアのマルチキャスト・アドレス、メディアのトランスポート・ポートなどを含む。メディアのマルチキャスト・アドレスは、マルチキャスト・ストリームの宛先アドレスおよび宛先ポートである。送信されているアドレスＳＤＰ情報は２２４．２．２．２であり、ＵＤＰポートは４０００である。マルチキャスト・セッションのことを知りたいホストは、この特別なマルチキャスト・セッションに加入し、ＳＤＰ情報を受信することができる。メディア・サーバ１におけるマルチキャスト・ビデオ・ストリームＡについては、ストリームＡのマルチメディア・アドレスは、マルチキャストＩＰアドレスＡ２’（２３０．１．１．１）、および対応するＭＡＣアドレスＡ２（０１−００−５ｅ−０１−０１−０１）である。

ＳＤＰ（サービス記述プロトコル）情報を解析することにより、ＱｏＳ（サービス品質）サーバ３は、マルチキャスト・グループＡ１にマルチキャストすべきメディア・コンテンツＡがメディア・サーバ１に存在することを知り、ルータ６に要求を送信し、マルチキャスト・グループＡ１に加入する意志を示す。この要求は、例えば、ＩＧＭＰ（インターネット・グループ管理プロトコル）に従って送信される。インターネット・グループ管理プロトコル（ＩＧＭＰ）は、インターネット・プロトコル・マルチキャスト・グループのメンバシップを管理するために使用される通信プロトコルである。ＩＧＭＰは、ＩＰホスト（例えばＱｏＳサーバ３または移動局２）および近接するマルチキャスト・ルータが、マルチキャスト・グループ・メンバシップを確立するために使用する。ＱｏＳサーバ３は、マルチキャスト・ビデオ・ストリームＡのマルチキャスト・グループＡ１に加入することを求めて、ＩＧＭＰルータであるルータ６に対してメッセージ（ＪＯＩＮ）を発行する。ルータ６は、このＪＯＩＮメッセージに対してＱＵＥＲＹメッセージで応答して、当該ＱｏＳサーバがそのメンバとなるグループを決定する。ＱｏＳサーバは、メンバシップ報告とともにこの問合せをフィードバックして、当該ＱｏＳサーバがマルチキャスト・グループＡ１に加入したい旨を通知する。ＱｏＳサーバ３は、マルチキャスト・ビデオ・ストリームＡを受信することができる。

ＱｏＳサーバ３は、マルチキャスト・ビデオ・ストリームＡを捉えると、当該ビデオ・ストリーム中の全てのＲＴＰ／ＩＰパケットの例えばフレーム・フォーマットを解析し、ビデオ・ストリームＡから複製／コピーした重要なパケットのいくつかしか含まない別のマルチキャストＱｏＳストリームＢを再構築する。図２ｂに示すように、再構築されたＱｏＳストリームＢは、マルチキャストＭＡＣアドレスＢ２（０１−００−５ｅ−０１−０１−０２）および対応するマルチキャストＩＰアドレスＢ２’（２３０．１．１．２）を有するマルチキャスト・グループＢ１にマルチキャストされる。

例えば、ＱｏＳサーバ３は、ビデオ・ストリームＡ中の全てのＲＴＰ／ＩＰパケットのフレーム・フォーマットを解析し、（例えばＭＰＥＧ−２符号化ビデオ・ストリームの）Ｉフレームを含むこれらのパケットを複製し、これらを記憶する。これは、ＭＰＥＧ−２ストリームでは、ＢフレームおよびＰフレームがＩフレームに対して生成されるからである。パケットが、Ｉフレームだけでなく、例えばＢフレームおよび／またはＰフレームなどその他のフレームも含む場合には、このパケットは、依然として重要なパケットであると見なされ、ＱｏＳサーバ３で記憶される。別の例で、空間的にスケーラブルなビデオ・ストリームでは、重要なパケットがベース・レイヤ・パケットである場合もある。これは、スケーラブルな符号化／復号ストリームでは、ベース・レイヤが低解像度画像に関係し、このベース・レイヤから、高解像度画像に関係する少なくとも１つのエンハンスメント・レイヤが符号化／復号されるからである。ＱｏＳサーバ３は、ルータ６を介してビデオ・サーバ１にも要求を送信して、ビデオ・ストリームＡのＳＤＰ情報を更新することを要求する。更新されたＳＤＰ情報は、ビデオ・ストリームＡの宛先マルチキャスト・アドレスＡ２およびＡ２’と、補足ビデオ・ストリームＢの宛先マルチキャスト・アドレスＢ２およびＢ２’を示すようになる。ビデオ・ストリームＡは、ビデオ・ストリームのパケットも含む。さらに、ＱｏＳサーバ３は、ビデオ・サーバ１と一体化されていても、本明細書に示すようにビデオ・サーバ１から分離していてもよい。

例えばＩＰアドレスが１０．１１．７２．６４、ＭＡＣアドレスが００−１ｃ−２３−３Ｂ−８３−５ＡであるＭＳ_１など、ＷＬＡＮ中の移動局２は、ビデオ・サーバ１にＳＤＰ情報を求める要求を発行すると、ビデオ・ストリームＡに関係するＳＤＰ（サービス記述プロトコル）情報をビデオ・サーバ１から受信することになる。このＳＤＰ情報を解析することにより、移動局２は、マルチキャストＭＡＣアドレスＡ２（０１−００−５ｅ−０１−０１−０１）およびマルチキャストＩＰアドレスＡ２’（２３０．１．１．１）を有するマルチキャスト・グループＡ１に加入すれば元のビデオ・ストリームＡを入手することができ、マルチキャストＭＡＣアドレスＢ２（０１−００−５ｅ−０１−０１−０２）およびマルチキャストＩＰアドレスＢ２’（２３０．１．１．２）を有するマルチキャスト・グループＢ１に加入すれば補足ＱｏＳビデオ・ストリームＢを入手することができることを学習する。

無線アクセス・ポイント（ＡＰ）４のＱｏＳエージェント５は、移動局２からストリームＡおよび／またはＢのパケットを求める要求を受けるまで、ビデオ・サーバ１からのマルチキャスト・ストリームＡおよびＱｏＳサーバ３からの補足ＱｏＳビデオ・ストリームＢのパケットを遮断する。移動局２から送信される要求は、ＩＧＭＰ（インターネット・マルチキャスト・プロトコル）ＪＯＩＮメッセージである。

移動局２が、例えばＩＧＭＰ（インターネット・グループ管理プロトコル）ＪＯＩＮメッセージなどのメッセージをＡＰ４を介してルータ６に送信することによってマルチキャスト・グループＡ１またはマルチキャスト・グループＢ１に加入すると、マルチキャスト・ビデオ・ストリームＡおよび／またはビデオ・ストリームＢが、ＡＰ４を介して移動局２に転送される。

無線アクセス・ポイント（ＡＰ）４は、移動局２から送信されるＩＧＭＰメッセージをモニタリングする。ＭＳ_１などの移動局２からマルチキャスト・グループＡ１に加入することを求めるＩＧＭＰ ＪＯＩＮ要求を受信すると、ＡＰ４は、元のマルチキャスト・ビデオ・ストリームＡをＭＳ_１にそのまま転送する。ビデオ・ストリームＡが以前に送信されており、移動局２がそのコンテンツを既に入手している場合には、移動局２は、このビデオ・ストリームを再度求めることはない。ＡＰ４がマルチキャスト・グループＢ１に加入することを求めるＩＧＭＰ要求を受信した場合には、ＱｏＳエージェント５は、マルチキャスト・ストリームＢ中のＩＰマルチキャスト・データ・パケットを、受信したＩＧＭＰパケットのソース・アドレスに対応する宛先ＭＡＣアドレス、すなわちこの場合にはＭＳ_１のＭＡＣアドレス（００−１ｃ−２３−３Ｂ−８３−５Ａ）を有するユニキャストＩＥＥＥ８０２．１１フレームにカプセル化し、これをマルチキャスト・オーバ・ユニキャスト方式を用いて送信する。図２ｃに示すように、ＩＰマルチキャスト・データ・パケットは、変更されていないＩＰマルチキャスト・グループ・アドレスＢ２’（２３０．１．１．２）を含む。通常は、各ＩＰパケットは、イーサネット（登録商標）ＭＡＣフレームと呼ばれるイーサネット（登録商標）ＭＡＣヘッダを有する。「宛先ＭＡＣアドレス」フィールドは、ＭＡＣヘッダに含まれ、ＩＰパケットが経路指定される宛先を特定する。なお、一般的なマルチキャスト・パケットでは、含まれる宛先ＭＡＣアドレスは、グループ・アドレスに対応するマルチキャストＭＡＣアドレスであることに留意されたい。マルチキャスト・オーバ・ユニキャストを実施するために、含まれる「宛先ＭＡＣアドレス」は特定のホストＭＡＣアドレスに変更するが、その他のフィールドは、一般的なマルチキャスト・パケットと同じままである。この例では、特定のホストＭＡＣアドレスは、ＭＳ_１のアドレス（００−１ｃ−２３−３Ｂ−８３−５Ａ）である。マルチキャスト・オーバ・ユニキャスト伝送方式を使用することにより、ＭＡＣレイヤ再送機構を用いることなく元のビデオ・ストリームＡをマルチキャスト・ストリームで移動局２に伝送しながら、これらの最も重要なパケットを、移動局２に確実に送達することができる。実施態様によって、ストリームＢは、移動局の一部に送信することもできるし、全ての移動局に送信することもできる。

例えばＭＳ_１などの移動局２は、マルチキャスト・ストリームＡと、マルチキャスト・ストリームＢがカプセル化されたマルチキャスト・オーバ・ユニキャスト・ストリームとを、連続的に受信する。移動局２は、受信したマルチキャスト・ストリームＡのＲＴＰパケットを記憶し、解析し、ＲＴＰヘッダ中のシーケンス番号フィールドをカウントすることによってマルチキャスト・ストリームＡ中でＲＴＰパケットが喪失していることを発見した場合には、受信したマルチキャスト・オーバ・ユニキャスト・ストリームのＲＴＰパケット待ち行列中で同じシーケンス番号を有するＲＴＰパケットを探す。受信したマルチキャスト・オーバ・ユニキャスト・ストリームのＲＴＰパケット待ち行列中に、受信したマルチキャスト・ストリームＡのＲＴＰパケット待ち行列中の喪失したＲＴＰパケットと同じシーケンス番号を有するＲＴＰパケットがある場合には、移動局２は、マルチキャスト・オーバ・ユニキャスト・ストリームのバッファ８中の待ち行列の対応するＲＴＰパケットを、バッファ７中のマルチキャスト・ストリームＡの待ち行列にコピーまたは移動する。その後、移動局２は、マルチキャスト・ストリームＡの待ち行列中のこれらのＲＴＰパケットを使用して、当該ビデオのフレームを構成し、これらのフレームを復号し、これを再生する。

このプロセスの間、ＡＰ４は、移動局２から送信されるＩＧＭＰメッセージを常にモニタリングしており、移動局２がＩＧＭＰ離脱メッセージを発行することによってマルチキャスト・グループＢを抜けたことを検出したときには、マルチキャスト・オーバ・ユニキャスト・ストリームＢの移動局２への伝送を停止する。

図３は、この実施例によるネットワークにおけるプロセスを示す流れ図である。このプロセスは、ステップ３１０で開始される。ステップ３２０で、メディア・サーバ１は、マルチキャスト・ストリームＡを、マルチキャストＭＡＣアドレスＡ２およびマルチキャストＩＰアドレスＡ２’を有するマルチキャスト・グループＡ１に送信する。ステップ３３０で、例えばビデオ・ストリームＡに関係するＳＤＰ情報を解析した後で、ＱｏＳサーバ３は、マルチキャスト・グループＡ１に加入し、マルチキャスト・ストリームＡを取り込む。その後、ＱｏＳサーバ３は、マルチキャストＱｏＳストリームＢを生成する。このＱｏＳストリームＢは、マルチキャスト・ストリームＡからコピー／複製した重要なパケットを含む。移動局（ユーザ）２は、ステップ３４０でマルチキャスト・ストリームＡを申し込むと、マルチキャストＭＡＣアドレスＡ２（０１−００−５ｅ−０１−０１−０１）およびマルチキャストＩＰアドレスＡ２’（２３０．１．１．１）を有するマルチキャスト・グループＡ１に加入すれば元のストリームＡを入手することができ、マルチキャストＭＡＣアドレスＢ２（０１−００−５ｅ−０１−０１−０２）およびマルチキャストＩＰアドレスＢ２’（２３０．１．１．２）を有するマルチキャスト・グループＢ１に加入すれば補足ＱｏＳビデオ・ストリームＢを入手することができることを知る。ステップ３５０で、ＱｏＳエージェント５を有するＡＰ４は、マルチキャスト・グループＢ１に加入し、ＱｏＳビデオ・ストリームＢをユニキャストＩＥＥＥ８０２．１１フレームにカプセル化し、それらをマルチキャスト・オーバ・ユニキャスト方式を用いて移動局２に送信する。このプロセスは、ステップ３６０で終了する。従って、ＡＰ４から移動局２にＱｏＳビデオ・ストリームＢを伝送するときには、ユニキャスト・セッションを確立して、ＱｏＳビデオ・ストリームＢに含まれるマルチキャスト・パケットを伝送する。

図４は、ＱｏＳサーバ３におけるプロセスの詳細を示す流れ図である。このプロセスは、ステップ４１０で開始される。ステップ４２０で、ビデオ・サーバ１からの新たなパケットが到着しているかどうかを判定する。到着している場合には、プロセスはステップ４３０に進んで、ＱｏＳサーバ３が受信した新たなパケットを解析し、ステップ４４０で、受信した新たなパケットが重要なパケットであるか否かを判定する。一例では、重要なパケットは、Ｉフレームに関するデータを含むパケットとして判定される。受信した新たなパケットが重要なパケットである場合には、ステップ４５０で、受信した新たなパケットのコピーをマルチキャスト・オーバ・ユニキャスト・ストリームに挿入し、移動局に伝送する。

図５は、ＡＰ４におけるプロセスの詳細を示す流れ図である。ステップ５１０で、プロセスが開始される。次いで、ステップ５２０で、新たなパケットが到着しているかどうかを判定する。到着していると判定された場合には、プロセスはステップ５３０に進み、この新たなパケットがＱｏＳストリームのパケットであるかどうかを、そのマルチキャスト宛先アドレスＢ１およびＢ１’によってさらに判定する。ＱｏＳストリームのパケットである場合には、ステップ５５０で、マルチキャスト・オーバ・ユニキャスト方法を用いてこの新たなパケットを伝送する。その後、ステップ５６０で、このプロセスは終了する。ステップ５３０で、ＱｏＳストリームのパケットではないと判定された場合、それは、パケットに含まれる宛先アドレスを解析することにより、当該パケットがマルチキャストＭＡＣアドレスＡ１およびＩＰアドレスＡ１’を有するマルチキャスト・グループＡに向けられたものであり、ＱｏＳストリームのパケットではないということになるので、プロセスはステップ５４０に進み、この新たなパケットを通常のマルチキャスト・パケットとして伝送する。同じメディア・コンテンツ（ペイロード）でも、ＱｏＳストリームに含まれているときと、元のメディア・ストリームに含まれているときとでは、マルチキャスト・アドレスが異なるので、前者の場合にはマルチキャスト・オーバ・ユニキャスト方式で移動局２に伝送され、後者の場合にはそのままマルチキャスト方式で移動局２に伝送される。その後、ステップ５６０で、このプロセスは終了する。

図６は、ネットワークの構造およびネットワーク中の装置を示すブロック図である。上記のプロセスを実施するためには、図６に示すように、ＱｏＳサーバ３は、メディア・サーバ１からマルチキャスト・パケットを受信するための入力３１と、受信したマルチキャスト・パケットが重要なパケットであるか否かの解析および判定を行うプロセッサ３２とを含む。受信したマルチキャスト・パケットが、例えばＩフレームに関するパケットなど、重要なパケットである場合には、プロセッサ３２は、これらの重要なパケットを複製し、新たなマルチキャスト・パケットに再構築する。その後、この再構築された重要なパケットが、出力３３を介してＡＰ４に伝送される。

従って、ＡＰ４には、ＱｏＳサーバ３およびメディア・サーバ１からパケットを受信するための入力４１がある。また、受信したパケットがメディア・サーバ１からのパケットであるか、ＱｏＳサーバ３からのＱｏＳストリームのパケットであるかを解析するＱｏＳエージェント５もある。受信したパケットがメディア・サーバ１からのパケットである場合には、このパケットは、出力４３を介して、そのままマルチキャストで移動局２に送信される。受信したパケットがＱｏＳサーバ３からのＱｏＳストリームのパケットである場合には、このパケットは、出力４３を介して、マルチキャスト・オーバ・ユニキャスト・モードで移動局２に送信される。

上記の説明では、メディア・サーバ１およびＱｏＳサーバ３の装置を別々に配置しているが、これらの装置は、一緒に配置することもできる。さらに、システム全体または特定の装置におけるプロセスについて上記では順番に説明したが、これは、本発明の原理を制限するものと解釈すべきではなく、これらの順序は変更することもできる。

いくつかの実施態様について説明した。ただし、様々な修正を加えることができることは理解されるであろう。さらに、当業者なら、開示の構造およびプロセスをその他の構造およびプロセスで置換することができること、ならびに、その結果得られた実施態様が、開示の実施態様と少なくとも実質的には同じである１つまたは複数の機能を、少なくとも実質的には同じである１つまたは複数の方法で実行して、少なくとも実質的には同じである１つまたは複数の結果をもたらすことを理解するであろう。従って、本願は、上記の実施態様およびその他の実施態様を企図するものであり、それらの実施態様は、以下の特許請求の範囲に含まれるものとする。

Claims (10)

1. ネットワーク中で第１のパケット・セットを含むパケット・ストリームを伝送する方法であって、
   ビデオ・サーバから第１のストリーム中の前記第１のパケット・セットをマルチキャスト・モードで受信し、ＱｏＳサーバから第２のストリーム中の第２のパケット・セットをマルチキャスト・モードで受信するステップであり、前記第２のパケット・セットが、前記第１のパケット・セットのパケットのサブセットであり、前記ＱｏＳサーバが、前記第１のストリームに接続して前記第１のパケット・セットをキャッシュし、キャッシュされた第１のパケット・セットから前記第２のパケット・セットを、復号のための前記パケットの重要度に基づいて選択する、前記ステップと、
   前記第１のパケット・セットを少なくとも１つの受信側にマルチキャスト・モードで送信し、前記第２のパケット・セットを前記少なくとも１つの受信側のうちの１つまたは複数の受信側にユニキャスト・モードで送信するステップと、を含む、前記方法。
2. 前記第１のパケット・セットが、マルチキャスト・グループのマルチキャストＩＰアドレスおよび対応するマルチキャストＭＡＣアドレスを有するマルチキャスト・パケットにカプセル化され、前記第２のパケット・セットを少なくとも１つの受信側に送信するときに、前記第２のパケット・セットに含まれるマルチキャストＭＡＣアドレスが、前記少なくとも１つの受信側のＭＡＣアドレスに変更される、請求項１に記載の方法。
3. 前記第２のパケット・セットが、前記１つまたは複数の受信側から送信される前記第２のパケット・セットのマルチキャスト・グループへの加入を求める要求に応答して、前記１つまたは複数の受信側に伝送される、請求項１または２に記載の方法。
4. 前記第２のパケット・セットが、前記第１のパケット・セットのペイロード・データを復号するために重要度に基づいて選択される、請求項１に記載の方法。
5. 前記第２のパケット・セットが、ビデオ・ストリームのＩフレームまたはベース・レイヤ・パケットを復号するために必要なパケットである、請求項４に記載の方法。
6. ネットワーク中で第１のパケット・セットを含むパケット・ストリームを受信する方法であって、受信側で、
   ビデオ・サーバから第１のストリーム中の前記第１のパケット・セットをマルチキャスト・モードで受信するステップと、
   アクセス・デバイスから第２のストリーム中の第２のパケット・セットをユニキャスト・モードで受信するステップであり、前記第２のパケット・セットが、前記第１のパケット・セットのパケットのサブセットであり、ＱｏＳサーバが、前記第１のストリームに接続して前記第１のパケット・セットをキャッシュし、キャッシュされた第１のパケット・セットから前記第２のパケット・セットを、復号のための前記パケットの重要度に基づいて選択し、前記第２のパケット・セットをマルチキャスト・モードで送信し、前記アクセス・デバイスが、前記第２のパケット・セットをマルチキャスト・モードで受信し、前記第２のパケット・セットをユニキャスト・モードで送信する、前記ステップと、
   前記第２のパケット・セットのパケットを用いて、前記第１のパケット・セットの、喪失した、または訂正不可能なパケットを置換するステップと、を含む、前記方法。
7. 前記第１のパケット・セットが、マルチキャスト・グループのマルチキャストＩＰアドレスおよび対応するマルチキャストＭＡＣアドレスを有するマルチキャスト・パケットにカプセル化され、前記第２のパケット・セットが送信されるときに、前記第２のパケット・セットに含まれるマルチキャストＭＡＣアドレスが、ユニキャストＭＡＣアドレスに変更される、請求項６に記載の方法。
8. 前記第２のパケット・セットが、前記第１のパケット・セットのペイロード・データを復号するために重要度に基づいて選択される、請求項６に記載の方法。
9. サービス記述プロトコル情報を受信するステップであり、前記ＱｏＳサーバが前記第１のストリームに接続して前記第２のパケット・セットの送信を開始した後に、前記サービス記述プロトコル情報が更新される、前記ステップと、
   前記第１のパケット・セットに対応するマルチキャスト・グループに加入するステップと、
   前記第２のパケット・セットのユニキャスト伝送をトリガするために、第２のマルチキャスト・グループに加入するステップと、をさらに含む、請求項７に記載の方法。
10. 前記パケットのサブセットが、ビデオ・ストリームのＩフレームまたはベース・レイヤ・パケットを復号するために必要なパケットである、請求項８に記載の方法。

Images