ネットワークを通じてソースから複数の受信機へデータパケットを送信する方法およびシステム
ネットワークを通じてソースから複数の受信機へデータパケットを送信する方法を提供する。ネットワーク要素（５）がソース（２）と複数の受信機（３ａ，３ｂ）との間に設けられ、送信されたデータパケットがネットワーク要素（５）を経由するようにされ、複数の受信機（３ａ，３ｂ）によって経験されたデータパケット損失がネットワーク要素（５）に報告され、報告された損失データパケットがネットワーク要素（５）によって符号化され再送される。また、対応するシステムが開示される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを通じてソースから複数の受信機へデータパケットを送信する方法およびシステムに関する。
【背景技術】
【０００２】
ソースからマルチキャストツリーを形成する複数の受信機へのデータパケットの送信は、特にマルチメディアコンテンツ配信に関連して、ますます重要性が高まっている。マルチメディア配信ネットワークでは、データパケットの損失は、マルチメディアコンテンツを利用するユーザの体感品質（Quality of Experience, ＱｏＥ）に悪影響を及ぼすおそれがある。マルチメディアストリームの符号化に応じて、パケット損失がコンテンツの品質に及ぼす影響は大きくも小さくもなり得ることが知られている。
【０００３】
多くのアプリケーションでは、マルチメディアコンテンツが受信機側で直ちに再生されるわけではない、と仮定するのは正しい。マルチメディアコンテンツはリアルタイムデータを含むので、データはある限られた時間内に受信されなければならないが、一般に、データパケットが受信機でバッファリングされる短い期間が存在し、その後にそのバッファを用いてメディアの再生や表示が行われる。この短い期間中に、欠落パケットに対処しそれらを回復しようとすることには意味がある。
【０００４】
マルチキャストツリーの共通部分で起こるパケット損失については、すべてのホストが同じパケットを失っているので、再送が比較的効率が高い。しかし、各ホストに固有のリンク上で起こる損失については、異なるホストは一般に異なるパケットを損失するので、パケットを再送するのは効率が低い。例えば、光アクセスネットワークでは損失はまれであるが、相異なるクラスのトラフィックに対する優先順位付けをしないこともある無線リンク等を用いたホームネットワークや、ＵＭＴＳあるいはＬＴＥのような広域無線ネットワークでは、損失はより起こりやすい。
【０００５】
マルチキャスト配信の信頼性は、従来のファイル転送のためだけでなく、特にＩＰＴＶに対して高い体感品質を提供するために重要である。ＩＰＴＶに対する現在の商業的関心は、ＩＰマルチキャストに対する真に新しい関心を引き起こしている。しかし、上記のように、一般にはパケットを失っている多くのユーザが存在し、パケットの損失および遅延特性は関与するユーザの間で様々なので、効率的かつスケーラブルな形でマルチキャストをパケット損失に対して堅牢にすることは困難である。
【０００６】
マルチキャストにおけるパケット損失の問題に対処するいくつかの解決法がある。しかし、従来技術において知られている手法は、さまざまな側面で不都合なことがわかっている。例えば、ルータに配置されたビデオエラー修復機能を提供することが知られている（例えば非特許文献１に記載）。しかし、提案されているエラー修復機能は、比較的大きな帯域幅を要するため、かなり非効率的である。
【０００７】
別の手法によれば、ＭＢＭＳ（非特許文献２に記載）のような一部のマルチキャストシステムでは、強力なＦＥＣ（前方誤り訂正）符号化を用いて信頼性を改善している。残念ながら、この解決法は大きい遅延を生じるので、リアルタイムあるいは準リアルタイムのアプリケーションには適しない手法になってしまう。
【０００８】
一般に、何らかのマルチキャスト（ＩＰマルチキャストおよびアプリケーションマルチキャストを含む）を通じてサービスされる多数のクライアントを有するノードを含むシステムでは、記憶容量が、パケット再送のための追加的な伝送帯域幅とともに、問題となる。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】Cisco whitepaper, "Delivering Video Quality in Your IPTV Development", URL: http://www.cisco.com/en/US/netsol/ns610/networking_solutions_white_paper0900aecd8057f290.shtml
【非特許文献２】3GPP, "TS 26.346, Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs (Release 7)", URL: http://www.3gpp.org/ftp/Specs/html-info/26346.htm
【非特許文献３】M. Xiao, M. Medard, and T. Aulin, "A Binary Coding Approach for Combination Networks and General Erasure Networks", In Proc. IEEE International Symposium on Information Theory (ISIT2007), URL: http://www.ce.chalmers.se/~mxiao/NC_isit_2007.pdf
【非特許文献４】J. Ott et al., "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July, 2006
【発明の概要】
【発明が解決しようとする課題】
【００１０】
したがって、本発明の目的は、頭書のような方法およびシステムにおいて、実施の容易なメカニズムを使用することにより、パケット損失に対する信頼性および堅牢性に関する改善が、高い帯域効率で達成されるように、改良を行うことである。
【課題を解決するための手段】
【００１１】
本発明によれば、上記の目的は、請求項１の構成を有する方法によって達成される。この請求項に記載の通り、本方法は、ネットワーク要素が前記ソースと前記複数の受信機との間に設けられ、前記送信されたデータパケットが前記ネットワーク要素を経由するようにされ、前記複数の受信機によって経験されたデータパケット損失が前記ネットワーク要素に報告され、該報告された損失データパケットが前記ネットワーク要素によって修復パケットとして符号化され再送されることを特徴とする。
【００１２】
また、上記の目的は、独立請求項２１の構成を有するシステムによって達成される。この請求項に記載の通り、本システムは、前記ソースと前記複数の受信機との間に設けられたネットワーク要素を有し、前記送信されたデータパケットが前記ネットワーク要素を経由するようにされ、前記ネットワーク要素は、前記複数の受信機によって経験されたデータパケット損失に関する報告を前記複数の受信機から受信した場合に、該報告された損失データパケットを修復パケットへと符号化し、該修復パケットを前記複数の受信機へ再送するように構成されることを特徴とする。
【００１３】
本発明によって初めて認識されたこととして、多くのアプリケーションでは、許容遅延があまりに短いため、データのソースへメッセージを返送することができない。また、認識されたこととして、すべての損失パケットに関する報告をソースへ送信することをそのまま大規模なマルチキャストグループに拡張することはできない。どのパケットの再送が必要かについて受信機が個別にソースへ通知すると、エンドツーエンド再送方式はフィードバック爆発を引き起こすであろう。本発明は、マルチキャストツリーの共通部分において、ソースと複数の受信機との間に位置するネットワーク要素を挿入することを提案する。これにより、受信機は、パケット損失をソースに報告する必要がなく、報告をそのネットワーク要素のみに送ればよいので、大規模なマルチキャストグループに拡張できる低遅延の損失回復が実現される。本発明によれば、挿入されるネットワーク要素は、損失していると報告されたデータパケットを修復パケットへと符号化し、その修復パケットを複数の受信機へ再送するように構成される。ネットワーク符号化を用いることにより、再送に要する帯域幅は大幅に低減される。
【００１４】
パケット再送のための追加的伝送帯域幅を低減し、データパケットの回復に要する時間を短縮することにより、例えばＩＰＴＶの体感品質の大幅な改善が達成される。なお、本発明は、固定・無線両方のネットワークにおけるマルチキャストに適用可能であることに注意すべきである。
【００１５】
本発明が特に有利な場合として、ネットワーク技術がすでにＧＰＯＮ（Gigabit Passive Optical Network）および無線のように、マルチキャストまたはブロードキャストをサポートしている場合、最終的には実際に１個のパケットを送信するだけで、複数のクライアントのＱｏＥが改善される。接続するクライアントの高速起動のために、パケットのバッファリングはネットワークノードですでに行われていてもよい。
【００１６】
好ましい実施形態によれば、ネットワーク要素は、損失していると報告されたパケットを把握しておく。特に、ネットワーク要素は、ある時間の間、それらのデータパケットをバッファリングしてもよい。
【００１７】
有利な態様として、修復パケットがネットワーク要素によって送信される再送期間が規定される。アプリケーションごとに適切に適応させるため、再送期間の長さは、複数の受信機で修復パケットを受信する特定の許容遅延に応じて選択してもよい。
【００１８】
有利な実施形態によれば、ネットワーク要素は、再送期間中に損失しているとしてネットワーク要素に報告されたすべてのパケットを含む修復パケットを各再送期間の終了時に送信してもよい。
【００１９】
修復パケットの特に効率的な再送のため、ネットワーク要素は、複数の受信機のいずれかが失っているパケットの最大数を追跡してもよい。このような場合、ネットワーク要素は、最後に要求されたパケット（すなわち、特定の受信機によって報告された第２の損失パケット）を最初のデータパケットとして含む新しい修復パケットの符号化を開始することができる。新しい修復パケットの符号化が開始されるごとにタイマを始動させ、再送期間が経過した時、１つの受信機からの二重の要求によりすでに送信済みでなければ修復パケットを送信する、としてもよい。
【００２０】
別の実施形態によれば、固定時間間隔を規定し、この時間間隔のそれぞれの終了時に、ネットワーク要素が、複数の受信機のいずれかによって要求されたパケットの最大数と同数の修復パケットを送信してもよい。アプリケーション要求が満たされることを保証するため、固定時間間隔の長さは、再送期間の長さよりも短く設定してもよい。固定長の時間間隔を規定する場合、同じデータパケットのセットから複数の独立な修復パケットを生成することが可能な符号化を用いてもよい。別法として、ＸＯＲ演算による単純な符号化を用いてもよい。後者の場合、符号化されるべきパケットを相異なるセットに分配し、どのセットもいずれか１つの受信機から要求されたパケットを１つよりも多くは含まないようにすべきである。その場合、１個の修復パケットがそれぞれのセットから生成される。
【００２１】
さらに別の好ましい実施形態によれば、所定時間間隔の間にネットワーク要素によって送信される修復パケットの最大数を規定してもよい。このような構成は、時間間隔を規定することによって、または修復パケット数を規定することによって、実現可能である。これにより、オペレータは、サービスの信頼性をどの程度にすべきかを決定することができる。修復パケット数を多くすると複雑さが増大するが、その一方で、回復不能な損失の確率が低減される。
【００２２】
特に、１つの間隔の間に複数の修復パケットを生成する場合、複数の独立な修復パケットを生成することが可能な符号化を用いてもよい。このような場合のネットワーク要素の挙動に関して、ネットワーク要素は、すべての到着するパケットを別々の修復パケットへと連続的に符号化してもよい。その結果、ソースから受信された元のデータパケットをネットワーク要素にバッファリングする必要がなくなる。別法として、受信機によって要求されたパケットのみを修復パケットに入れてもよい。この場合、損失パケットに関する受信機からのフィードバックがまず到着する必要があるので、符号化が実行されるまでにある遅延が必要となる。したがって、符号化を開始することができるまで、一部のパケットはネットワーク要素によってバッファリングされる必要がある。しかし、このような実施形態の利点として、より少数のパケットが符号化された場合には、復号の複雑さを下げることができる。
【００２３】
上記ですでに述べたように、ネットワーク要素によって用いられるネットワーク符号化は、単純なビットごとのＸＯＲ演算によるものでもよい。しかし、より一般的なネットワーク符号、例えば、同じデータパケットから複数の独立なパリティパケットを生成することが可能な２元（ＸＯＲに基づく）符号（非特許文献３に記載）を用いることも可能である。さらに、より大きなガロア体からとった係数によってパケットを線型結合した符号、あるいはリード・ソロモン符号も適用可能である。
【００２４】
具体的応用に関して、送信されるデータパケットは、マルチメディアストリーム、特にＩＰＴＶストリームを構成してもよい。マルチメディアストリームは、ソースとして作用するサービスプロバイダ、特にＩＰＴＶサーバによって発信されるものでもよい。このような場合、複数の受信機は、そのサービスプロバイダによって提供されるマルチメディアサービスへの加入者であってもよい。有利な態様として、ネットワーク要素は、所定数の受信機がマルチメディアストリームに接続した時に修復パケットの送信を開始してもよい。このような構成により、どのストリームが再送によってサポートされ、どのストリームがサポートされないかの動的変更が可能となる。これは、符号化の種類やクライアントまでのラウンドトリップ時間によって決めてもよい。
【００２５】
パケットが上流で損失した状況において、ネットワーク要素からソースへの再送要求がサポートされている場合には、それによって回復してもよい。これは例えば、ソースからのと同じ種類のネットワーク符号化再送を用いることによってサポート可能であり、これにより階層的修復システムが構成される。そうでない場合、ネットワーク要素は、欠落パケットを抜かすしかない。その場合、受信機が欠落パケットを要求するが、ネットワーク要素は要求されたパケットを含まない修復パケットを送出するので、それは有効でないと受信機は結論することができる。したがって、受信機はそれを要求し続けることはない。別法として、有効期限が経過してパケットがもはや使用可能でなくなったら直ちに要求を停止してもよい。
【００２６】
受信機からネットワーク要素へのフィードバック情報を効率的にするため、ＲＴＣＰ（Real Time Control Protocol）受信機レポートを、場合によっては非特許文献４に記載されているような拡張プロファイルに従って、用いてもよい。無線チャネルに特に適した別の例として、結合チャネルが否定応答のために用いられるＭＡＣレイヤ「２進ＯＲ」チャネルを用いることができる。肯定応答チャネルは、特定のパケットに対するＮＡＣＫが所定タイムスロットにおいて送信されるように構成することができる。各受信機は、対応するパケットが損失している場合に否定応答を送信することが可能であり、ネットワーク要素は、いずれかの受信機がＮＡＣＫを送信したかどうかを判断して、パケットを再送するかどうかを決定することができる。
【００２７】
なお、この点に関して、ネットワーク要素は、遅延および信頼性に対するアプリケーション要求を満たすように構成可能であることに注意すべきである。これはまた、処理能力および記憶容量の要求に関する複雑さをも決定する。ネットワーク要素がパケットを再送することができるために必要とする最大時間、したがってパケットをバッファリングしなければならない最大時間は、アプリケーションの許容遅延と、受信機からフィードバックを受けるのに要する時間とに依存する。フィードバック時間は、用いられるフィードバックプロトコルに依存する。例えば、ＲＴＣＰ受信機は、リンクレイヤＮＡＣＫよりも長い遅延を受ける。これらのファクタから、最大再送期間を決定することができ、その時間の後、パケットをバッファから破棄することができる。
【００２８】
ネットワーク要素は、固定回線アクセスネットワーク要素（ＤＳＬＡＭ、ＭＳＡＮ等）でも、無線アクセスポイント（例えば、３ｇｐｐノードＢ、ＬＴＥノードＢ）でもよい。
【００２９】
本発明を好適な態様で実施するにはいくつもの可能性がある。このためには、一方で請求項１および２１に従属する諸請求項を参照しつつ、他方で図面により例示された本発明の好ましい実施形態についての以下の説明を参照されたい。図面を用いて本発明の好ましい実施形態を説明する際には、本発明の教示による好ましい実施形態一般およびその変形例について説明する。
【図面の簡単な説明】
【００３０】
【図１】ＩＰ−ＴＶアプリケーションシナリオに関連する本発明の実施形態を示す。
【図２】本発明による方法で用いられるパケットを符号化する第１実施例を示す。
【図３】本発明による方法で用いられるパケットを符号化する別の実施例を示す。
【発明を実施するための形態】
【００３１】
図１は、ＩＰ−ＴＶマルチメディアストリームの場合における本発明によるシステムの実施形態を例示している。ＩＰ−ＴＶサーバ１は、マルチメディアストリームのソース２として作用する。マルチメディアストリームは、マルチキャストグループとして、インターネットを通じて多数のホストへ送信される。ホストは、ＩＰ−ＴＶサーバ１によって提供されるマルチメディアサービスへの加入者であってもよい。簡単のため、多数のホストのうち２個のホストのみを図１に例示している。２個のホストをそれぞれ、データパケットを受信する受信機３ａ、３ｂで示す。それらのデータパケットは、対応するホームネットワーク４ａ、４ｂ内のそれぞれのアプリケーションによって処理される。
【００３２】
本発明によれば、再送プロキシ６であるネットワーク要素５が、ソース２と個々の受信機３ａ、３ｂとの間のマルチキャストツリーの共通部分に挿入される。図１には具体的に示していないが、再送プロキシ６は、特定のマルチサービスアクセスノード（ＧＰＯＮ／ＭＳＡＮ）に配置されても、無線基地局に配置されてもよい。マルチメディアストリームのデータパケットがプロキシ６を経由することを保証するため、例えばエッジルータ上に配置するのも有益である。
【００３３】
図１に示す例では、再送プロキシ６は、マルチキャストツリーの共通部分の終端を規定する。しかし、言うまでもなく、再送プロキシ６は、マルチメディアストリームのソース２のほうにより近づけて配置してもよい。ただし、低遅延に関する最良のパフォーマンス結果は、マルチキャストツリーの共通部分で、できるだけ受信機３ａ、３ｂの近くにプロキシ６を配置した場合に達成することができる。
【００３４】
図１において、ソース２から受信機３ａ、３ｂへのマルチメディアストリームのデータパケットの送信は、一点鎖線矢印で示している。受信機３ａ、３ｂは、受信したストリーム中でデータパケットが欠けていると認識した場合、それぞれレポートを送信することによって、再送プロキシ６に通知する。これらのレポートは、破線矢印で示している。
【００３５】
図示した例では、複数のホストはそれぞれ異なるパケットが欠けていると報告し、再送を処理するプロキシ６は、欠落／損失していると報告されたすべてのパケットをバッファから取り出して単一のパケットへと符号化する。その後、符号化されたパケットは、修復パケットとして受信機３ａ、３ｂへ送信される。欠落パケットをまとめて最小の回復パケットのセットへと符号化するため、プロキシ６は、単純な演算を用いることができ、場合によってはＸＯＲ演算のみを用いてもよい。各受信機３ａ、３ｂは、修復パケットを受信すると、そのパケットを復号し、失っているパケットを正しく見つける。なお、その単純な符号化演算ゆえに、再送プロキシ６におけるバッファリングおよび符号化は、適応的に調整することができることに注意すべきである。
【００３６】
本発明による方法は、エンドツーエンドＦＥＣ（前方誤り訂正）とともに用いることも可能である。この場合、受信機３ａ、３ｂは、ソース２からのＦＥＣパリティパケットで損失が回復されるかもしれないので、損失を検出後すぐに再送を要求する必要はない。より多くの損失が下流のネットワークで起きていて、一部の受信機３ａ、３ｂがメッセージＦＥＣ符号語を復号することができない場合、本発明は前述のように動作することになる。したがって、プロキシ６が送信データ全体を復号するのに十分な数のパケットを受信している限り、損失パケットは受信機３ａ、３ｂによって回復されることが可能である。しかし、プロキシ６は復号をする必要がなく、パケットをまとめて符号化すればよい。終端受信機３ａ、３ｂは、まずプロキシ６からのネットワーク符号化を復号した後で、ソース２からのＦＥＣ符号化を復号する。
【００３７】
図２は、損失パケットの符号化および修復パケットあるいはパリティパケットの生成がどのように実行可能であるかの簡単な例を示している。Ｐ１、Ｐ２、Ｐ３およびＰ４というパケットがホストＡ、ＢおよびＣへ送信されると仮定する。また、ホストＡはパケットＰ２を損失し、ホストＢはパケットＰ３を損失し、ホストＣはパケットＰ４を損失すると仮定する。
【００３８】
すべてのホストが、損失したパケットについてプロキシ６に報告する。プロキシ６は、Ｐｃｏｄｅｄ＝Ｐ２＋Ｐ３＋Ｐ４（ただし「＋」はビットごとのＸＯＲを表す）と符号化し、元のパケットのいずれがＰｃｏｄｅｄに符号化されているかを通知するヘッダを付けて、Ｐｃｏｄｅｄをすべてのホストへのマルチキャストアドレスで送信する。
【００３９】
Ｐｃｏｄｅｄを受信した後、ホストＡは自己の受信バッファからＰ３およびＰ４を取り出し、Ｐｃｏｄｅｄ＋Ｐ３＋Ｐ４＝Ｐ２（ここでも「＋」はＸＯＲであり、したがってＰ３＋Ｐ３＝０、Ｐ４＋Ｐ４＝０である）を計算することによって復号する。ホストＢおよびホストＣは、同様に復号して、それぞれパケットＰ３およびＰ４を取得する。
【００４０】
図１からさらに分かるように、１個以上のパリティパケットで再送されるべきパケットを符号化する前に、パケットにパディングを施して同じ長さにしてもよい。具体的には、パディングをパケットＰ３に付加して、パケットＰ１、Ｐ２、およびＰ４と同じ長さにする。
【００４１】
別法として、一部のパケットが最長のパケットよりもずっと短い場合、図３に例示するように、それらを共通のパケットとして符号化してもよい。これは、パケット３およびパケット４の両方を失っている受信機が、単一のパリティパケットからそれら両方を回復できるという利点がある。
【００４２】
上記の説明および添付図面の記載に基づいて、当業者は本発明の多くの変形例および他の実施形態に想到し得るであろう。したがって、本発明は、開示した具体的実施形態に限定されるものではなく、変形例および他の実施形態も、添付の特許請求の範囲内に含まれるものと理解すべきである。本明細書では特定の用語を用いているが、それらは総称的・説明的意味でのみ用いられており、限定を目的としたものではない。
【技術分野】
【０００１】
本発明は、ネットワークを通じてソースから複数の受信機へデータパケットを送信する方法およびシステムに関する。
【背景技術】
【０００２】
ソースからマルチキャストツリーを形成する複数の受信機へのデータパケットの送信は、特にマルチメディアコンテンツ配信に関連して、ますます重要性が高まっている。マルチメディア配信ネットワークでは、データパケットの損失は、マルチメディアコンテンツを利用するユーザの体感品質（Quality of Experience, ＱｏＥ）に悪影響を及ぼすおそれがある。マルチメディアストリームの符号化に応じて、パケット損失がコンテンツの品質に及ぼす影響は大きくも小さくもなり得ることが知られている。
【０００３】
多くのアプリケーションでは、マルチメディアコンテンツが受信機側で直ちに再生されるわけではない、と仮定するのは正しい。マルチメディアコンテンツはリアルタイムデータを含むので、データはある限られた時間内に受信されなければならないが、一般に、データパケットが受信機でバッファリングされる短い期間が存在し、その後にそのバッファを用いてメディアの再生や表示が行われる。この短い期間中に、欠落パケットに対処しそれらを回復しようとすることには意味がある。
【０００４】
マルチキャストツリーの共通部分で起こるパケット損失については、すべてのホストが同じパケットを失っているので、再送が比較的効率が高い。しかし、各ホストに固有のリンク上で起こる損失については、異なるホストは一般に異なるパケットを損失するので、パケットを再送するのは効率が低い。例えば、光アクセスネットワークでは損失はまれであるが、相異なるクラスのトラフィックに対する優先順位付けをしないこともある無線リンク等を用いたホームネットワークや、ＵＭＴＳあるいはＬＴＥのような広域無線ネットワークでは、損失はより起こりやすい。
【０００５】
マルチキャスト配信の信頼性は、従来のファイル転送のためだけでなく、特にＩＰＴＶに対して高い体感品質を提供するために重要である。ＩＰＴＶに対する現在の商業的関心は、ＩＰマルチキャストに対する真に新しい関心を引き起こしている。しかし、上記のように、一般にはパケットを失っている多くのユーザが存在し、パケットの損失および遅延特性は関与するユーザの間で様々なので、効率的かつスケーラブルな形でマルチキャストをパケット損失に対して堅牢にすることは困難である。
【０００６】
マルチキャストにおけるパケット損失の問題に対処するいくつかの解決法がある。しかし、従来技術において知られている手法は、さまざまな側面で不都合なことがわかっている。例えば、ルータに配置されたビデオエラー修復機能を提供することが知られている（例えば非特許文献１に記載）。しかし、提案されているエラー修復機能は、比較的大きな帯域幅を要するため、かなり非効率的である。
【０００７】
別の手法によれば、ＭＢＭＳ（非特許文献２に記載）のような一部のマルチキャストシステムでは、強力なＦＥＣ（前方誤り訂正）符号化を用いて信頼性を改善している。残念ながら、この解決法は大きい遅延を生じるので、リアルタイムあるいは準リアルタイムのアプリケーションには適しない手法になってしまう。
【０００８】
一般に、何らかのマルチキャスト（ＩＰマルチキャストおよびアプリケーションマルチキャストを含む）を通じてサービスされる多数のクライアントを有するノードを含むシステムでは、記憶容量が、パケット再送のための追加的な伝送帯域幅とともに、問題となる。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】Cisco whitepaper, "Delivering Video Quality in Your IPTV Development", URL: http://www.cisco.com/en/US/netsol/ns610/networking_solutions_white_paper0900aecd8057f290.shtml
【非特許文献２】3GPP, "TS 26.346, Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs (Release 7)", URL: http://www.3gpp.org/ftp/Specs/html-info/26346.htm
【非特許文献３】M. Xiao, M. Medard, and T. Aulin, "A Binary Coding Approach for Combination Networks and General Erasure Networks", In Proc. IEEE International Symposium on Information Theory (ISIT2007), URL: http://www.ce.chalmers.se/~mxiao/NC_isit_2007.pdf
【非特許文献４】J. Ott et al., "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July, 2006
【発明の概要】
【発明が解決しようとする課題】
【００１０】
したがって、本発明の目的は、頭書のような方法およびシステムにおいて、実施の容易なメカニズムを使用することにより、パケット損失に対する信頼性および堅牢性に関する改善が、高い帯域効率で達成されるように、改良を行うことである。
【課題を解決するための手段】
【００１１】
本発明によれば、上記の目的は、請求項１の構成を有する方法によって達成される。この請求項に記載の通り、本方法は、ネットワーク要素が前記ソースと前記複数の受信機との間に設けられ、前記送信されたデータパケットが前記ネットワーク要素を経由するようにされ、前記複数の受信機によって経験されたデータパケット損失が前記ネットワーク要素に報告され、該報告された損失データパケットが前記ネットワーク要素によって修復パケットとして符号化され再送されることを特徴とする。
【００１２】
また、上記の目的は、独立請求項２１の構成を有するシステムによって達成される。この請求項に記載の通り、本システムは、前記ソースと前記複数の受信機との間に設けられたネットワーク要素を有し、前記送信されたデータパケットが前記ネットワーク要素を経由するようにされ、前記ネットワーク要素は、前記複数の受信機によって経験されたデータパケット損失に関する報告を前記複数の受信機から受信した場合に、該報告された損失データパケットを修復パケットへと符号化し、該修復パケットを前記複数の受信機へ再送するように構成されることを特徴とする。
【００１３】
本発明によって初めて認識されたこととして、多くのアプリケーションでは、許容遅延があまりに短いため、データのソースへメッセージを返送することができない。また、認識されたこととして、すべての損失パケットに関する報告をソースへ送信することをそのまま大規模なマルチキャストグループに拡張することはできない。どのパケットの再送が必要かについて受信機が個別にソースへ通知すると、エンドツーエンド再送方式はフィードバック爆発を引き起こすであろう。本発明は、マルチキャストツリーの共通部分において、ソースと複数の受信機との間に位置するネットワーク要素を挿入することを提案する。これにより、受信機は、パケット損失をソースに報告する必要がなく、報告をそのネットワーク要素のみに送ればよいので、大規模なマルチキャストグループに拡張できる低遅延の損失回復が実現される。本発明によれば、挿入されるネットワーク要素は、損失していると報告されたデータパケットを修復パケットへと符号化し、その修復パケットを複数の受信機へ再送するように構成される。ネットワーク符号化を用いることにより、再送に要する帯域幅は大幅に低減される。
【００１４】
パケット再送のための追加的伝送帯域幅を低減し、データパケットの回復に要する時間を短縮することにより、例えばＩＰＴＶの体感品質の大幅な改善が達成される。なお、本発明は、固定・無線両方のネットワークにおけるマルチキャストに適用可能であることに注意すべきである。
【００１５】
本発明が特に有利な場合として、ネットワーク技術がすでにＧＰＯＮ（Gigabit Passive Optical Network）および無線のように、マルチキャストまたはブロードキャストをサポートしている場合、最終的には実際に１個のパケットを送信するだけで、複数のクライアントのＱｏＥが改善される。接続するクライアントの高速起動のために、パケットのバッファリングはネットワークノードですでに行われていてもよい。
【００１６】
好ましい実施形態によれば、ネットワーク要素は、損失していると報告されたパケットを把握しておく。特に、ネットワーク要素は、ある時間の間、それらのデータパケットをバッファリングしてもよい。
【００１７】
有利な態様として、修復パケットがネットワーク要素によって送信される再送期間が規定される。アプリケーションごとに適切に適応させるため、再送期間の長さは、複数の受信機で修復パケットを受信する特定の許容遅延に応じて選択してもよい。
【００１８】
有利な実施形態によれば、ネットワーク要素は、再送期間中に損失しているとしてネットワーク要素に報告されたすべてのパケットを含む修復パケットを各再送期間の終了時に送信してもよい。
【００１９】
修復パケットの特に効率的な再送のため、ネットワーク要素は、複数の受信機のいずれかが失っているパケットの最大数を追跡してもよい。このような場合、ネットワーク要素は、最後に要求されたパケット（すなわち、特定の受信機によって報告された第２の損失パケット）を最初のデータパケットとして含む新しい修復パケットの符号化を開始することができる。新しい修復パケットの符号化が開始されるごとにタイマを始動させ、再送期間が経過した時、１つの受信機からの二重の要求によりすでに送信済みでなければ修復パケットを送信する、としてもよい。
【００２０】
別の実施形態によれば、固定時間間隔を規定し、この時間間隔のそれぞれの終了時に、ネットワーク要素が、複数の受信機のいずれかによって要求されたパケットの最大数と同数の修復パケットを送信してもよい。アプリケーション要求が満たされることを保証するため、固定時間間隔の長さは、再送期間の長さよりも短く設定してもよい。固定長の時間間隔を規定する場合、同じデータパケットのセットから複数の独立な修復パケットを生成することが可能な符号化を用いてもよい。別法として、ＸＯＲ演算による単純な符号化を用いてもよい。後者の場合、符号化されるべきパケットを相異なるセットに分配し、どのセットもいずれか１つの受信機から要求されたパケットを１つよりも多くは含まないようにすべきである。その場合、１個の修復パケットがそれぞれのセットから生成される。
【００２１】
さらに別の好ましい実施形態によれば、所定時間間隔の間にネットワーク要素によって送信される修復パケットの最大数を規定してもよい。このような構成は、時間間隔を規定することによって、または修復パケット数を規定することによって、実現可能である。これにより、オペレータは、サービスの信頼性をどの程度にすべきかを決定することができる。修復パケット数を多くすると複雑さが増大するが、その一方で、回復不能な損失の確率が低減される。
【００２２】
特に、１つの間隔の間に複数の修復パケットを生成する場合、複数の独立な修復パケットを生成することが可能な符号化を用いてもよい。このような場合のネットワーク要素の挙動に関して、ネットワーク要素は、すべての到着するパケットを別々の修復パケットへと連続的に符号化してもよい。その結果、ソースから受信された元のデータパケットをネットワーク要素にバッファリングする必要がなくなる。別法として、受信機によって要求されたパケットのみを修復パケットに入れてもよい。この場合、損失パケットに関する受信機からのフィードバックがまず到着する必要があるので、符号化が実行されるまでにある遅延が必要となる。したがって、符号化を開始することができるまで、一部のパケットはネットワーク要素によってバッファリングされる必要がある。しかし、このような実施形態の利点として、より少数のパケットが符号化された場合には、復号の複雑さを下げることができる。
【００２３】
上記ですでに述べたように、ネットワーク要素によって用いられるネットワーク符号化は、単純なビットごとのＸＯＲ演算によるものでもよい。しかし、より一般的なネットワーク符号、例えば、同じデータパケットから複数の独立なパリティパケットを生成することが可能な２元（ＸＯＲに基づく）符号（非特許文献３に記載）を用いることも可能である。さらに、より大きなガロア体からとった係数によってパケットを線型結合した符号、あるいはリード・ソロモン符号も適用可能である。
【００２４】
具体的応用に関して、送信されるデータパケットは、マルチメディアストリーム、特にＩＰＴＶストリームを構成してもよい。マルチメディアストリームは、ソースとして作用するサービスプロバイダ、特にＩＰＴＶサーバによって発信されるものでもよい。このような場合、複数の受信機は、そのサービスプロバイダによって提供されるマルチメディアサービスへの加入者であってもよい。有利な態様として、ネットワーク要素は、所定数の受信機がマルチメディアストリームに接続した時に修復パケットの送信を開始してもよい。このような構成により、どのストリームが再送によってサポートされ、どのストリームがサポートされないかの動的変更が可能となる。これは、符号化の種類やクライアントまでのラウンドトリップ時間によって決めてもよい。
【００２５】
パケットが上流で損失した状況において、ネットワーク要素からソースへの再送要求がサポートされている場合には、それによって回復してもよい。これは例えば、ソースからのと同じ種類のネットワーク符号化再送を用いることによってサポート可能であり、これにより階層的修復システムが構成される。そうでない場合、ネットワーク要素は、欠落パケットを抜かすしかない。その場合、受信機が欠落パケットを要求するが、ネットワーク要素は要求されたパケットを含まない修復パケットを送出するので、それは有効でないと受信機は結論することができる。したがって、受信機はそれを要求し続けることはない。別法として、有効期限が経過してパケットがもはや使用可能でなくなったら直ちに要求を停止してもよい。
【００２６】
受信機からネットワーク要素へのフィードバック情報を効率的にするため、ＲＴＣＰ（Real Time Control Protocol）受信機レポートを、場合によっては非特許文献４に記載されているような拡張プロファイルに従って、用いてもよい。無線チャネルに特に適した別の例として、結合チャネルが否定応答のために用いられるＭＡＣレイヤ「２進ＯＲ」チャネルを用いることができる。肯定応答チャネルは、特定のパケットに対するＮＡＣＫが所定タイムスロットにおいて送信されるように構成することができる。各受信機は、対応するパケットが損失している場合に否定応答を送信することが可能であり、ネットワーク要素は、いずれかの受信機がＮＡＣＫを送信したかどうかを判断して、パケットを再送するかどうかを決定することができる。
【００２７】
なお、この点に関して、ネットワーク要素は、遅延および信頼性に対するアプリケーション要求を満たすように構成可能であることに注意すべきである。これはまた、処理能力および記憶容量の要求に関する複雑さをも決定する。ネットワーク要素がパケットを再送することができるために必要とする最大時間、したがってパケットをバッファリングしなければならない最大時間は、アプリケーションの許容遅延と、受信機からフィードバックを受けるのに要する時間とに依存する。フィードバック時間は、用いられるフィードバックプロトコルに依存する。例えば、ＲＴＣＰ受信機は、リンクレイヤＮＡＣＫよりも長い遅延を受ける。これらのファクタから、最大再送期間を決定することができ、その時間の後、パケットをバッファから破棄することができる。
【００２８】
ネットワーク要素は、固定回線アクセスネットワーク要素（ＤＳＬＡＭ、ＭＳＡＮ等）でも、無線アクセスポイント（例えば、３ｇｐｐノードＢ、ＬＴＥノードＢ）でもよい。
【００２９】
本発明を好適な態様で実施するにはいくつもの可能性がある。このためには、一方で請求項１および２１に従属する諸請求項を参照しつつ、他方で図面により例示された本発明の好ましい実施形態についての以下の説明を参照されたい。図面を用いて本発明の好ましい実施形態を説明する際には、本発明の教示による好ましい実施形態一般およびその変形例について説明する。
【図面の簡単な説明】
【００３０】
【図１】ＩＰ−ＴＶアプリケーションシナリオに関連する本発明の実施形態を示す。
【図２】本発明による方法で用いられるパケットを符号化する第１実施例を示す。
【図３】本発明による方法で用いられるパケットを符号化する別の実施例を示す。
【発明を実施するための形態】
【００３１】
図１は、ＩＰ−ＴＶマルチメディアストリームの場合における本発明によるシステムの実施形態を例示している。ＩＰ−ＴＶサーバ１は、マルチメディアストリームのソース２として作用する。マルチメディアストリームは、マルチキャストグループとして、インターネットを通じて多数のホストへ送信される。ホストは、ＩＰ−ＴＶサーバ１によって提供されるマルチメディアサービスへの加入者であってもよい。簡単のため、多数のホストのうち２個のホストのみを図１に例示している。２個のホストをそれぞれ、データパケットを受信する受信機３ａ、３ｂで示す。それらのデータパケットは、対応するホームネットワーク４ａ、４ｂ内のそれぞれのアプリケーションによって処理される。
【００３２】
本発明によれば、再送プロキシ６であるネットワーク要素５が、ソース２と個々の受信機３ａ、３ｂとの間のマルチキャストツリーの共通部分に挿入される。図１には具体的に示していないが、再送プロキシ６は、特定のマルチサービスアクセスノード（ＧＰＯＮ／ＭＳＡＮ）に配置されても、無線基地局に配置されてもよい。マルチメディアストリームのデータパケットがプロキシ６を経由することを保証するため、例えばエッジルータ上に配置するのも有益である。
【００３３】
図１に示す例では、再送プロキシ６は、マルチキャストツリーの共通部分の終端を規定する。しかし、言うまでもなく、再送プロキシ６は、マルチメディアストリームのソース２のほうにより近づけて配置してもよい。ただし、低遅延に関する最良のパフォーマンス結果は、マルチキャストツリーの共通部分で、できるだけ受信機３ａ、３ｂの近くにプロキシ６を配置した場合に達成することができる。
【００３４】
図１において、ソース２から受信機３ａ、３ｂへのマルチメディアストリームのデータパケットの送信は、一点鎖線矢印で示している。受信機３ａ、３ｂは、受信したストリーム中でデータパケットが欠けていると認識した場合、それぞれレポートを送信することによって、再送プロキシ６に通知する。これらのレポートは、破線矢印で示している。
【００３５】
図示した例では、複数のホストはそれぞれ異なるパケットが欠けていると報告し、再送を処理するプロキシ６は、欠落／損失していると報告されたすべてのパケットをバッファから取り出して単一のパケットへと符号化する。その後、符号化されたパケットは、修復パケットとして受信機３ａ、３ｂへ送信される。欠落パケットをまとめて最小の回復パケットのセットへと符号化するため、プロキシ６は、単純な演算を用いることができ、場合によってはＸＯＲ演算のみを用いてもよい。各受信機３ａ、３ｂは、修復パケットを受信すると、そのパケットを復号し、失っているパケットを正しく見つける。なお、その単純な符号化演算ゆえに、再送プロキシ６におけるバッファリングおよび符号化は、適応的に調整することができることに注意すべきである。
【００３６】
本発明による方法は、エンドツーエンドＦＥＣ（前方誤り訂正）とともに用いることも可能である。この場合、受信機３ａ、３ｂは、ソース２からのＦＥＣパリティパケットで損失が回復されるかもしれないので、損失を検出後すぐに再送を要求する必要はない。より多くの損失が下流のネットワークで起きていて、一部の受信機３ａ、３ｂがメッセージＦＥＣ符号語を復号することができない場合、本発明は前述のように動作することになる。したがって、プロキシ６が送信データ全体を復号するのに十分な数のパケットを受信している限り、損失パケットは受信機３ａ、３ｂによって回復されることが可能である。しかし、プロキシ６は復号をする必要がなく、パケットをまとめて符号化すればよい。終端受信機３ａ、３ｂは、まずプロキシ６からのネットワーク符号化を復号した後で、ソース２からのＦＥＣ符号化を復号する。
【００３７】
図２は、損失パケットの符号化および修復パケットあるいはパリティパケットの生成がどのように実行可能であるかの簡単な例を示している。Ｐ１、Ｐ２、Ｐ３およびＰ４というパケットがホストＡ、ＢおよびＣへ送信されると仮定する。また、ホストＡはパケットＰ２を損失し、ホストＢはパケットＰ３を損失し、ホストＣはパケットＰ４を損失すると仮定する。
【００３８】
すべてのホストが、損失したパケットについてプロキシ６に報告する。プロキシ６は、Ｐｃｏｄｅｄ＝Ｐ２＋Ｐ３＋Ｐ４（ただし「＋」はビットごとのＸＯＲを表す）と符号化し、元のパケットのいずれがＰｃｏｄｅｄに符号化されているかを通知するヘッダを付けて、Ｐｃｏｄｅｄをすべてのホストへのマルチキャストアドレスで送信する。
【００３９】
Ｐｃｏｄｅｄを受信した後、ホストＡは自己の受信バッファからＰ３およびＰ４を取り出し、Ｐｃｏｄｅｄ＋Ｐ３＋Ｐ４＝Ｐ２（ここでも「＋」はＸＯＲであり、したがってＰ３＋Ｐ３＝０、Ｐ４＋Ｐ４＝０である）を計算することによって復号する。ホストＢおよびホストＣは、同様に復号して、それぞれパケットＰ３およびＰ４を取得する。
【００４０】
図１からさらに分かるように、１個以上のパリティパケットで再送されるべきパケットを符号化する前に、パケットにパディングを施して同じ長さにしてもよい。具体的には、パディングをパケットＰ３に付加して、パケットＰ１、Ｐ２、およびＰ４と同じ長さにする。
【００４１】
別法として、一部のパケットが最長のパケットよりもずっと短い場合、図３に例示するように、それらを共通のパケットとして符号化してもよい。これは、パケット３およびパケット４の両方を失っている受信機が、単一のパリティパケットからそれら両方を回復できるという利点がある。
【００４２】
上記の説明および添付図面の記載に基づいて、当業者は本発明の多くの変形例および他の実施形態に想到し得るであろう。したがって、本発明は、開示した具体的実施形態に限定されるものではなく、変形例および他の実施形態も、添付の特許請求の範囲内に含まれるものと理解すべきである。本明細書では特定の用語を用いているが、それらは総称的・説明的意味でのみ用いられており、限定を目的としたものではない。
【特許請求の範囲】
【請求項１】
ネットワークを通じてソースから複数の受信機へデータパケットを送信する方法において、
ネットワーク要素（５）が前記ソース（２）と前記複数の受信機（３ａ，３ｂ）との間に設けられ、前記送信されたデータパケットが前記ネットワーク要素（５）を経由するようにされ、
前記複数の受信機（３ａ，３ｂ）によって経験されたデータパケット損失が前記ネットワーク要素（５）に報告され、該報告された損失データパケットが前記ネットワーク要素（５）によって修復パケットとして符号化され再送されることを特徴とする、ネットワークを通じてソースから複数の受信機へデータパケットを送信する方法。
【請求項２】
前記ネットワーク要素（５）が、損失していると報告されたパケットを、特に該パケットをバッファリングすることによって、把握していることを特徴とする請求項１に記載の方法。
【請求項３】
前記修復パケットが前記ネットワーク要素（５）によって送信される再送期間が規定されることを特徴とする請求項１または２に記載の方法。
【請求項４】
前記再送期間の長さが、前記複数の受信機（３ａ，３ｂ）で前記送信されたデータパケットを受信する特定の許容遅延に応じて規定されることを特徴とする請求項３に記載の方法。
【請求項５】
前記ネットワーク要素（５）が、前記再送期間中に損失しているとして前記ネットワーク要素（５）に報告されたすべてのパケットを含む修復パケットをそれぞれの前記再送期間の終了時に送信することを特徴とする請求項３または４に記載の方法。
【請求項６】
前記ネットワーク要素（５）が、前記複数の受信機（３ａ，３ｂ）のいずれかが失っているパケットの最大数を追跡することを特徴とする請求項１ないし５のいずれか１項に記載の方法。
【請求項７】
前記ネットワーク要素（５）は、前記複数の受信機（３ａ，３ｂ）のうちの１つが複数のパケットを損失したら直ちに、最後の修復パケットの送信後に損失しているとして前記ネットワーク要素（５）に報告されたすべてのパケットの情報を含む１個の符号化パケットを送信することを特徴とする請求項１ないし６のいずれか１項に記載の方法。
【請求項８】
固定時間間隔を規定し、それぞれの該時間間隔の終了時に、前記ネットワーク要素（５）が、前記複数の受信機（３ａ，３ｂ）のいずれかによって要求されたパケットの最大数と同数の修復パケットを送信することを特徴とする請求項１ないし７のいずれか１項に記載の方法。
【請求項９】
前記固定時間間隔の長さが前記再送期間の長さよりも短いことを特徴とする請求項８に記載の方法。
【請求項１０】
所定時間間隔の間に前記ネットワーク要素（５）によって送信される修復パケットの最大数が規定されることを特徴とする請求項１ないし９のいずれか１項に記載の方法。
【請求項１１】
前記ネットワーク要素（５）が、同じデータパケットのセットから複数の独立な修復パケットを生成することが可能な符号化方式を使用することを特徴とする請求項１ないし１０のいずれか１項に記載の方法。
【請求項１２】
前記ネットワーク要素（５）が、すべての到着するデータパケットを別々の修復パケットへと連続的に符号化することを特徴とする請求項１ないし１１のいずれか１項に記載の方法。
【請求項１３】
前記ネットワーク要素（５）が、要求されたデータパケットのみを前記修復パケットに含めることを特徴とする請求項１ないし１１のいずれか１項に記載の方法。
【請求項１４】
前記ネットワーク要素（５）によって用いられるネットワーク符号化が、ビットごとのＸＯＲ演算を含むことを特徴とする請求項１ないし１３のいずれか１項に記載の方法。
【請求項１５】
前記ネットワーク要素（５）によって用いられるネットワーク符号化が、２元符号および／またはガロア体からとった係数によってデータパケットを線型結合した符号および／またはリード・ソロモン符号を含むことを特徴とする請求項１ないし１４のいずれか１項に記載の方法。
【請求項１６】
前記送信されたデータパケットが、マルチメディアストリーム、特にＩＰ−ＴＶストリームを構成することを特徴とする請求項１ないし１５のいずれか１項に記載の方法。
【請求項１７】
前記ネットワーク要素（５）は、所定数の受信機が前記ストリームに接続した時に修復パケットの送信を開始することを特徴とする請求項１６に記載の方法。
【請求項１８】
前記ソースと前記ネットワーク要素（５）との間の上流で損失したパケットが、前記ネットワーク要素（５）から前記ソース（２）への再送要求によって回復されることを特徴とする請求項１ないし１７のいずれか１項に記載の方法。
【請求項１９】
前記複数の受信機（３ａ，３ｂ）から前記ネットワーク要素（５）へのフィードバック情報が、ＲＴＣＰ（Real Time Control Protocol）受信機レポートによって実現されることを特徴とする請求項１ないし１８のいずれか１項に記載の方法。
【請求項２０】
前記複数の受信機（３ａ，３ｂ）から前記ネットワーク要素（５）へのフィードバック情報が、ＭＡＣレイヤ「２進ＯＲ」チャネルによって実現されることを特徴とする請求項１ないし１９のいずれか１項に記載の方法。
【請求項２１】
ネットワークを通じてソースから複数の受信機へデータパケットを送信するシステムにおいて、
該システムは、前記ソース（２）と前記複数の受信機（３ａ，３ｂ）との間に設けられたネットワーク要素（５）を有し、前記送信されたデータパケットが前記ネットワーク要素（５）を経由するようにされ、
前記ネットワーク要素（５）は、前記複数の受信機（３ａ，３ｂ）によって経験されたデータパケット損失に関する報告を前記複数の受信機（３ａ，３ｂ）から受信した場合に、該報告された損失データパケットを修復パケットへと符号化し、該修復パケットを前記複数の受信機（３ａ，３ｂ）へ再送するように構成されることを特徴とする、ネットワークを通じてソースから複数の受信機へデータパケットを送信するシステム。
【請求項２２】
前記ネットワーク要素（５）が再送プロキシ（６）であることを特徴とする請求項２１に記載のシステム。
【請求項２３】
前記ネットワーク要素（５）がエッジルータまたはマルチサービスアクセスノード（ＭＳＡＮ）に配置されることを特徴とする請求項２１または２２に記載のシステム。
【請求項２４】
前記ソース（２）がサービスプロバイダ、特にＩＰＴＶサーバ（１）であることを特徴とする請求項２１ないし２３のいずれか１項に記載のシステム。
【請求項２５】
前記複数の受信機（３ａ，３ｂ）が、前記サービスプロバイダによって提供されるマルチメディアサービスへの加入者であることを特徴とする請求項２１ないし２４のいずれか１項に記載のシステム。
【請求項１】
ネットワークを通じてソースから複数の受信機へデータパケットを送信する方法において、
ネットワーク要素（５）が前記ソース（２）と前記複数の受信機（３ａ，３ｂ）との間に設けられ、前記送信されたデータパケットが前記ネットワーク要素（５）を経由するようにされ、
前記複数の受信機（３ａ，３ｂ）によって経験されたデータパケット損失が前記ネットワーク要素（５）に報告され、該報告された損失データパケットが前記ネットワーク要素（５）によって修復パケットとして符号化され再送されることを特徴とする、ネットワークを通じてソースから複数の受信機へデータパケットを送信する方法。
【請求項２】
前記ネットワーク要素（５）が、損失していると報告されたパケットを、特に該パケットをバッファリングすることによって、把握していることを特徴とする請求項１に記載の方法。
【請求項３】
前記修復パケットが前記ネットワーク要素（５）によって送信される再送期間が規定されることを特徴とする請求項１または２に記載の方法。
【請求項４】
前記再送期間の長さが、前記複数の受信機（３ａ，３ｂ）で前記送信されたデータパケットを受信する特定の許容遅延に応じて規定されることを特徴とする請求項３に記載の方法。
【請求項５】
前記ネットワーク要素（５）が、前記再送期間中に損失しているとして前記ネットワーク要素（５）に報告されたすべてのパケットを含む修復パケットをそれぞれの前記再送期間の終了時に送信することを特徴とする請求項３または４に記載の方法。
【請求項６】
前記ネットワーク要素（５）が、前記複数の受信機（３ａ，３ｂ）のいずれかが失っているパケットの最大数を追跡することを特徴とする請求項１ないし５のいずれか１項に記載の方法。
【請求項７】
前記ネットワーク要素（５）は、前記複数の受信機（３ａ，３ｂ）のうちの１つが複数のパケットを損失したら直ちに、最後の修復パケットの送信後に損失しているとして前記ネットワーク要素（５）に報告されたすべてのパケットの情報を含む１個の符号化パケットを送信することを特徴とする請求項１ないし６のいずれか１項に記載の方法。
【請求項８】
固定時間間隔を規定し、それぞれの該時間間隔の終了時に、前記ネットワーク要素（５）が、前記複数の受信機（３ａ，３ｂ）のいずれかによって要求されたパケットの最大数と同数の修復パケットを送信することを特徴とする請求項１ないし７のいずれか１項に記載の方法。
【請求項９】
前記固定時間間隔の長さが前記再送期間の長さよりも短いことを特徴とする請求項８に記載の方法。
【請求項１０】
所定時間間隔の間に前記ネットワーク要素（５）によって送信される修復パケットの最大数が規定されることを特徴とする請求項１ないし９のいずれか１項に記載の方法。
【請求項１１】
前記ネットワーク要素（５）が、同じデータパケットのセットから複数の独立な修復パケットを生成することが可能な符号化方式を使用することを特徴とする請求項１ないし１０のいずれか１項に記載の方法。
【請求項１２】
前記ネットワーク要素（５）が、すべての到着するデータパケットを別々の修復パケットへと連続的に符号化することを特徴とする請求項１ないし１１のいずれか１項に記載の方法。
【請求項１３】
前記ネットワーク要素（５）が、要求されたデータパケットのみを前記修復パケットに含めることを特徴とする請求項１ないし１１のいずれか１項に記載の方法。
【請求項１４】
前記ネットワーク要素（５）によって用いられるネットワーク符号化が、ビットごとのＸＯＲ演算を含むことを特徴とする請求項１ないし１３のいずれか１項に記載の方法。
【請求項１５】
前記ネットワーク要素（５）によって用いられるネットワーク符号化が、２元符号および／またはガロア体からとった係数によってデータパケットを線型結合した符号および／またはリード・ソロモン符号を含むことを特徴とする請求項１ないし１４のいずれか１項に記載の方法。
【請求項１６】
前記送信されたデータパケットが、マルチメディアストリーム、特にＩＰ−ＴＶストリームを構成することを特徴とする請求項１ないし１５のいずれか１項に記載の方法。
【請求項１７】
前記ネットワーク要素（５）は、所定数の受信機が前記ストリームに接続した時に修復パケットの送信を開始することを特徴とする請求項１６に記載の方法。
【請求項１８】
前記ソースと前記ネットワーク要素（５）との間の上流で損失したパケットが、前記ネットワーク要素（５）から前記ソース（２）への再送要求によって回復されることを特徴とする請求項１ないし１７のいずれか１項に記載の方法。
【請求項１９】
前記複数の受信機（３ａ，３ｂ）から前記ネットワーク要素（５）へのフィードバック情報が、ＲＴＣＰ（Real Time Control Protocol）受信機レポートによって実現されることを特徴とする請求項１ないし１８のいずれか１項に記載の方法。
【請求項２０】
前記複数の受信機（３ａ，３ｂ）から前記ネットワーク要素（５）へのフィードバック情報が、ＭＡＣレイヤ「２進ＯＲ」チャネルによって実現されることを特徴とする請求項１ないし１９のいずれか１項に記載の方法。
【請求項２１】
ネットワークを通じてソースから複数の受信機へデータパケットを送信するシステムにおいて、
該システムは、前記ソース（２）と前記複数の受信機（３ａ，３ｂ）との間に設けられたネットワーク要素（５）を有し、前記送信されたデータパケットが前記ネットワーク要素（５）を経由するようにされ、
前記ネットワーク要素（５）は、前記複数の受信機（３ａ，３ｂ）によって経験されたデータパケット損失に関する報告を前記複数の受信機（３ａ，３ｂ）から受信した場合に、該報告された損失データパケットを修復パケットへと符号化し、該修復パケットを前記複数の受信機（３ａ，３ｂ）へ再送するように構成されることを特徴とする、ネットワークを通じてソースから複数の受信機へデータパケットを送信するシステム。
【請求項２２】
前記ネットワーク要素（５）が再送プロキシ（６）であることを特徴とする請求項２１に記載のシステム。
【請求項２３】
前記ネットワーク要素（５）がエッジルータまたはマルチサービスアクセスノード（ＭＳＡＮ）に配置されることを特徴とする請求項２１または２２に記載のシステム。
【請求項２４】
前記ソース（２）がサービスプロバイダ、特にＩＰＴＶサーバ（１）であることを特徴とする請求項２１ないし２３のいずれか１項に記載のシステム。
【請求項２５】
前記複数の受信機（３ａ，３ｂ）が、前記サービスプロバイダによって提供されるマルチメディアサービスへの加入者であることを特徴とする請求項２１ないし２４のいずれか１項に記載のシステム。
【図１】
【図２】
【図３】
【図２】
【図３】
【公表番号】特表２０１０−５３９７６３（Ｐ２０１０−５３９７６３Ａ）
【公表日】平成２２年１２月１６日（２０１０．１２．１６）
【国際特許分類】
【出願番号】特願２０１０−５２４４１６（Ｐ２０１０−５２４４１６）
【出願日】平成２０年９月２９日（２００８．９．２９）
【国際出願番号】ＰＣＴ／ＥＰ２００８／００８２６８
【国際公開番号】ＷＯ２００９／０４０１３８
【国際公開日】平成２１年４月２日（２００９．４．２）
【出願人】（５０８３４２１８３）エヌイーシー ヨーロッパ リミテッド (101)
【氏名又は名称原語表記】ＮＥＣ ＥＵＲＯＰＥ ＬＴＤ．
【Ｆターム（参考）】
【公表日】平成２２年１２月１６日（２０１０．１２．１６）
【国際特許分類】
【出願日】平成２０年９月２９日（２００８．９．２９）
【国際出願番号】ＰＣＴ／ＥＰ２００８／００８２６８
【国際公開番号】ＷＯ２００９／０４０１３８
【国際公開日】平成２１年４月２日（２００９．４．２）
【出願人】（５０８３４２１８３）エヌイーシー ヨーロッパ リミテッド (101)
【氏名又は名称原語表記】ＮＥＣ ＥＵＲＯＰＥ ＬＴＤ．
【Ｆターム（参考）】
[ Back to top ]