(57)【要約】  無線マルチキャストネットワークにおける適応的でスケーラブルなパケット誤り訂正装置及び方法が提供される。受信器からの各再送信要求は、ラウンド番号と、そのラウンドにて送信されるリペア数とを含む。各受信器には、ネットワーク上に送出されるラウンドと、要求されたリペア数とをカウントする２つのカウンタが存在する。無線マルチキャストネットワーク上の受信器は、その他の受信器により送信されたＡＲＱ要求をリッスンして上記２つのカウンタを更新するとともに、自身の要求の送出が見送られるべきか、あるいは送出されるべきかを決定する。
2010521090.tif 000002
【特許請求の範囲】
【請求項１】
マルチキャストネットワーク上の受信器におけるパケット誤り訂正方法であって、
その他の受信器をリッスンし、その他の受信器により送信された再送信要求を検出する段階；
検出された再送信要求のパラメータの累算の関数として、当該受信器における再送信要求の送出が見送られるべきか、あるいは送出されるべきかを決定する段階；及び
該再送信要求の送出が見送られない場合に該再送信要求を送出する段階；
を含むパケット誤り訂正方法。
【請求項２】
請求項１に記載のマルチキャストネットワーク上の受信器におけるパケット誤り訂正方法であって、当該受信器からの各再送信要求は、前記ネットワーク上に送出される再送信要求の現在のラウンド番号を示し、且つ再送信要求の前記現在のラウンドにて当該受信器が要求するリペアの数を示す情報を含む、パケット誤り訂正方法。
【請求項３】
請求項２に記載のマルチキャストネットワーク上の受信器におけるパケット誤り訂正方法であって、前記検出された再送信要求のパラメータの前記累算は、前記検出された再送信要求によって要求されたリペアの数を累算する、パケット誤り訂正方法。
【請求項４】
請求項３に記載のマルチキャストネットワーク上の受信器におけるパケット誤り訂正方法であって、当該受信器は更に、前記検出された再送信要求の最大のラウンド番号を保持する、パケット誤り訂正方法。
【請求項５】
請求項４に記載のマルチキャストネットワーク上の受信器におけるパケット誤り訂正方法であって、当該受信器は、検出された再送信要求の前記情報内に含まれる前記リペアの数を前記累算に足し合わせ、該検出された再送信要求が当該受信器において保持された前記ラウンド番号より大きいラウンド番号を含むとき、当該受信器において保持されたラウンド番号を更新する、パケット誤り訂正方法。
【請求項６】
請求項５に記載のマルチキャストネットワーク上の受信器におけるパケット誤り訂正方法であって、当該受信器は、当該受信器が必要とするリペアの数が累算されたリペアの数より大きいとき、自身の再送信要求を送出する、パケット誤り訂正方法。
【請求項７】
請求項６に記載のマルチキャストネットワーク上の受信器におけるパケット誤り訂正方法であって、当該受信器が再送信要求を送出するとき、当該受信器において保持されたラウンド番号が１だけ増大され、且つ増大されたラウンド番号が該再送信要求に含められる、パケット誤り訂正方法。
【請求項８】
請求項７に記載のマルチキャストネットワーク上の受信器におけるパケット誤り訂正方法であって、当該受信器が再送信要求を送出するとき、要求されるリペアの数は累算されたリペアの数と当該受信器が必要とするリペアの数との間の差にされ、該差が前記累算に足し合わされる、パケット誤り訂正方法。
【請求項９】
請求項８に記載のマルチキャストネットワーク上の受信器におけるパケット誤り訂正方法であって、当該受信器は、パケットロスを検出したとき、遅延期間を待った後に再送信要求を送出する、パケット誤り訂正方法。
【請求項１０】
請求項９に記載のマルチキャストネットワーク上の受信器におけるパケット誤り訂正方法であって、前記遅延期間は、当該受信器が必要とするリペアの数に反比例する、パケット誤り訂正方法。
【請求項１１】
マルチキャストネットワーク上で送信器からのデータパケットを受信する受信器であって、
その他の受信器により送信された再送信要求を検出する再送信要求検出器；
検出された再送信要求のパラメータの累算の関数として、再送信要求の送出が見送られるべきか、あるいは送出されるべきかを決定する再送信要求プロセッサ；及び
該再送信要求の送出が見送られない場合に該再送信要求を送出する再送信要求送信器；
を含む受信器。
【請求項１２】
当該受信器からの各再送信要求は、前記ネットワーク上に送出される再送信要求の現在のラウンド番号を示し、且つ再送信要求の前記現在のラウンドにて当該受信器が要求するリペアの数を示す情報を含む、請求項１１に記載の受信器。
【請求項１３】
前記検出された再送信要求のパラメータの前記累算は、前記検出された再送信要求によって要求されたリペアの数を累算する、請求項１２に記載の受信器。
【請求項１４】
前記検出された再送信要求によって要求されたリペアの数を累算するリペア計数ユニット、を更に含む請求項１３に記載の受信器。
【請求項１５】
前記検出された再送信要求の最大のラウンド番号を保持するラウンド計数ユニット、を更に含む請求項１４に記載の受信器。
【請求項１６】
前記ラウンド計数ユニットは、当該ラウンド計数ユニット内に保持されたラウンド番号が、前記検出された再送信要求内に含まれるラウンド番号より小さいとき、ラウンド番号のカウントを更新する、請求項１５に記載の受信器。
【請求項１７】
当該受信器は、当該受信器が必要とするリペアの数が累算されたリペアの数より大きいとき、自身の再送信要求を送出する、請求項１６に記載の受信器。
【請求項１８】
当該受信器が再送信要求を送出するとき、前記ラウンド計数ユニット内に保持されたラウンド番号が１だけ増大され、且つ増大されたラウンド番号が該再送信要求に含められる、請求項１７に記載の受信器。
【請求項１９】
当該受信器が再送信要求を送出するとき、要求されるリペアの数は累算されたリペアの数と当該受信器が必要とするリペアの数との間の差であり、この差が前記累算に足し合わされる、請求項１８に記載の受信器。
【請求項２０】
当該受信器が再送信要求を送出する前に待つ遅延期間を計る遅延期間タイマ、を更に含む請求項１９に記載の受信器。
【請求項２１】
前記遅延期間は、当該受信器が必要とするリペアの数に反比例する、請求項２０に記載の受信器。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ伝送に関し、特に、適応的でスケーラブルなパケット誤り訂正装置及び方法に関する。
【背景技術】
【０００２】
データ通信を行うため、特に、ビデオ及び／又はオーディオのストリーミングを行うために無線ネットワークを使用することは、現在では一般的に行われていることである。例えばＷＬＡＮといった一部の無線システムは、送信者からマルチキャスト領域内の多数の受信者にビデオストリームを配信することができる。
【０００３】
図１は、従来のマルチキャスト無線システムを示している。このシステムは、少なくとも１つの送信器１０から複数の受信器２０にビデオストリームを伝送するために使用される。ビデオパケットが送信側のビデオサーバ（図１には図示せず）によって生成され、受信器に伝送される。受信器がビデオパケットを受信すると、受信器はこれらのビデオパケットを復号する。受信側で受信されたビデオパケットにパケットロスが発生すると、受信側のデコーダはそのビデオパケットを復号することができない。故に、何らかの誤り訂正手法が必要である。順方向誤り訂正（Forward  Error  Correction；ＦＥＣ）及び自動再送要求（Automatic  Repeat  Request；ＡＲＱ）は２つの基本的な誤り訂正手法である。
【０００４】
順方向誤り訂正（ＦＥＣ）は、ソースデータパケットに加えて幾つかの冗長パケットを受信側へと送信し、受信側でパケットロスが冗長パケットによって復元されることを可能にする手法である。或る種類のＦＥＣ法においては、データパケットのストリームに幾つかの事前的（プロアクティブ）なリペア（冗長パケット）が含められる。プロアクティブ・リペアはリペアの送信が必要かどうか分かる前に送信される。ＦＥＣにおいて、パケットの送信者はＫ個のソースパケットごとにＮ−Ｋ個のリペアを導入してＮ個のパケットを作成する。受信器は、Ｎパケットのうち少なくともＫ個を受信するとき、Ｋ個全てのソースパケットを復元することができる。ＦＥＣ法において、失われたソースパケットの数は、ソースパケット全てを復元するために、少なくとも同数のリペアの受信によって補償されなければならない。
【０００５】
リペアが受信側でソースデータを信頼性高く復号することに十分でない場合、受信器は更なるリペアの再送信を要求する。この要求は自動再送要求（ＡＲＱ）と呼ばれる。ＡＲＱはデータパケットが首尾よく復号されるまで継続的に作成される。
【０００６】
過去数十年、ハイブリッドＦＥＣ／ＡＲＱ法と呼ばれるＦＥＣとＡＲＱとの組み合わせが広く研究されてきた。一例が非特許文献１に示されている。非特許文献１は、マルチキャストネットワークで使用されるハイブリッドＦＥＣ／ＡＲＱ法であって、送信者がネットワーク状態に従ってプロアクティブ・リペアを調整するように事前行動性因子（プロアクティビティ・ファクタ）を選定する方法を開示している。送信器に多量のフィードバックが殺到する場合、送信器は、より多くのプロアクティブ・リペアを付加するようにプロアクティビティ・ファクタを増大させるべきである。送信器が少量のフィードバックしか受信しない場合、送信器は、プロアクティブ・リペアの数を減少させるようにプロアクティビティ・ファクタを低減させるべきである。
【０００７】
受信器からの各ＡＲＱ／ＮＡＫ（（すなわち、送信者にパケットロスを通知する否定応答）、ＡＲＱはＮＡＫに相当する）は、受信器が送信要求するリペア数ｎｒと、ＮＡＫラウンドＮｒとを含む。ＮＡＫラウンドは、受信器によって認識されるブロック伝送の現在の“ラウンド”を指し示す。送信器は、リペアを送信するとき、そのブロックに関して何れかの受信器から受信した最大のＮＡＫラウンドに対応するＮＡＫラウンド番号Ｎｓをそのパケットに含める。
【０００８】
受信器からラウンド番号Ｎｒとともに到来したばかりのｎｒ個のリペアを要求するＮＡＫに応答するため、３つの方法が送信器によって使用され得る。クライアントからのＮＡＫに応答するために送信器によって使用される方法のうちの１つをラウンド−カレントと呼ぶ。この方法においては、送信器は、現在の送信器ラウンド番号Ｎｓに等しいラウンド番号を有する送信リペアの総数のカウントｎを保持する。到来するＮＡＫにおいて、Ｎｒ＜Ｎｓである場合、そのＮＡＫは無視される。Ｎｒ＝Ｎｓである場合、ｍａｘ（０，ｎｒ−ｎ）個のパケットが送信され、ｎがｍａｘ（ｎ，ｎｒ）に設定される。Ｎｒ＞Ｎｓである場合、ｎがｎｒに設定され、Ｎｓ＝Ｎｒにされ、ｎｒ個のパケットが送信される。
【０００９】
受信器のＮＡＫラウンド番号Ｎｒは当初は１である。ＮＡＫを送信した後、受信器はそのＮＡＫカウンタを例えば１だけ増加させＮｒ＝Ｎｒ＋１とする。受信器は、自身の現在値以上のＮＡＫラウンド番号を伴うパケットを送信器から受信すると、自身のＮＡＫラウンド番号を送信器の現在値＋１に更新する（Ｎｓ≧Ｎｒの場合、Ｎｒ＝Ｎｓ＋１とする）。
【００１０】
しかしながら、非特許文献１に示されるように、上述の方法においては幾つかの冗長な要求が不必要に送信される。例えば、２つの受信器Ａ及びＢが存在し、受信器Ａが受信器Ｂのラウンドトリップ時間より短いラウンドトリップ時間を有するとする。Ｂがｎｂ個のリペアを要求し且つＡがより少ない数ｎａのリペアを要求して、双方の受信器がラウンド番号１を有するＮＡＫを送信するとする。そして、送信器が先ず、ｎａ個のリペアの要求を受け取り、ｎａ個のリペアをマルチキャストすると仮定する。これらのリペアの一部が受信器Ａへの経路上で失われる場合、ラウンド番号１で送信されたｎｂ−ｎａ個の更なるリペアの到着（又はその認識）に先立って、Ａは更なるリペアをラウンド番号２で要求することになる。従って、ｎｂ−ｎａ個のリペアが残存する喪失パケットを復元できるとき、ラウンド２で要求されたリペアは冗長であるが、ＮＡＫ内のラウンド番号がより大きいため、全てのパケットが送信されてしまう。
【００１１】
また、この方法においては、全ての受信器がＮＡＫラウンド番号Ｎｓと送信器からのリペア情報とによって動作を調整される。或る受信器が、或るラウンド番号と必要なリペア数とを伴う要求を送信する場合、その受信器から送信器へ、そしてその後の送信器から受信器群への手続きが完了するまで、その他の受信器はこの情報を知ることがない。この手続きは極めて多く行われるので、送信器によっては、その他の受信器から送信された情報を適時に受け取ることができず、幾らかの冗長な要求が送信されることになり得る。
【先行技術文献】
【非特許文献】
【００１２】
【非特許文献１】Dan  Rubenstein等、「A  Study  of  Proactive  Hybrid  FEC/ARQ  and  Scalable  Feedback  Techniques  for  Reliable,  Real-Time  Multicast」、Computer  Communication、2001年3月
【発明の概要】
【発明が解決しようとする課題】
【００１３】
本発明は、適応的でスケーラブルなパケット誤り訂正装置及び方法を提供することを目的とする。
【課題を解決するための手段】
【００１４】
一態様において、マルチキャストネットワーク上の受信器におけるパケット誤り訂正方法が提供される。当該方法は、その他の受信器をリッスンし、その他の受信器により送信された再送信要求を検出する段階と、検出された再送信要求のパラメータの累算の関数として、当該受信器における再送信要求の送出が見送られるべきか、あるいは送出されるべきかを決定する段階と、該再送信要求の送出が見送られない場合に該再送信要求を送出する段階とを含む。
【００１５】
一実施形態によれば、受信器からの各再送信要求は、ネットワーク上に送出される再送信要求の現在のラウンド番号を示し、且つ再送信要求の前記現在のラウンドにて当該受信器が要求するリペアの数を示す情報を含む。
【００１６】
他の一実施形態によれば、検出された再送信要求のパラメータの累算は、検出された再送信要求によって要求されたリペアの数を累算する。
【００１７】
更なる他の一実施形態において、受信器は更に、検出された再送信要求の最大のラウンド番号を保持する。
【００１８】
有利には、受信器は、検出された再送信要求の前記情報内に含まれるリペアの数を前記累算に足し合わせ、該検出された再送信要求が当該受信器において保持されたラウンド番号より大きいラウンド番号を含むとき、当該受信器において保持されたラウンド番号を更新する。
【００１９】
好適な一実施形態において、受信器は、当該受信器が必要とするリペアの数が累算されたリペアの数より大きいとき、自身の再送信要求を送出する。
【００２０】
更なる一実施形態において、受信器が再送信要求を送出するとき、当該受信器において保持されたラウンド番号が１だけ増大され、且つ増大されたラウンド番号が該再送信要求に含められる。
【００２１】
他の一実施形態において、受信器が再送信要求を送出するとき、要求されるリペアの数は累算されたリペアの数と当該受信器が必要とするリペアの数との間の差にされ、この差が前記累算に足し合わされる。
【００２２】
更なる他の一実施形態によれば、受信器は、パケットロスを検出したとき、遅延期間を待った後に再送信要求を送出し、この遅延期間は好ましくは、当該受信器が必要とするリペアの数に反比例する。
【００２３】
他の一態様において、マルチキャストネットワーク上で送信器からのデータパケットを受信する受信器が提供される。当該受信器は、その他の受信器により送信された再送信要求を検出する再送信要求検出器と、検出された再送信要求のパラメータの累算の関数として、再送信要求の送出が見送られるべきか、あるいは送出されるべきかを決定する再送信要求プロセッサと、該再送信要求の送出が見送られない場合に該再送信要求を送出する再送信要求送信器とを含む。
【００２４】
一実施形態によれば、受信器からの各再送信要求は、前記ネットワーク上に送出される再送信要求の現在のラウンド番号を示し、且つ再送信要求の現在のラウンドにて当該受信器が要求するリペアの数を示す情報を含む。
【００２５】
他の一実施形態によれば、検出された再送信要求のパラメータの累算は、検出された再送信要求によって要求されたリペアの数を累算する。
【００２６】
更なる一実施形態によれば、受信器は更に、検出された再送信要求によって要求されたリペアの数を累算するリペア計数ユニットを含む。
【００２７】
他の一実施形態において、受信器は更に、検出された再送信要求の最大のラウンド番号を保持するラウンド計数ユニットを含む。
【００２８】
一実施形態において、ラウンド計数ユニットは、当該ラウンド計数ユニット内に保持されたラウンド番号が、検出された要求内に含まれるラウンド番号より小さいとき、ラウンド番号のカウントを更新する。
【００２９】
他の一実施形態において、受信器は、当該受信器が必要とするリペアの数が累算されたリペアの数より大きいとき、自身の再送信要求を送出する。
【００３０】
更なる他の一実施形態において、受信器が再送信要求を送出するとき、ラウンド計数ユニット内に保持されたラウンド番号が１だけ増大され、且つ増大されたラウンド番号が該再送信要求に含められる。
【００３１】
有利には、受信器が再送信要求を送出するとき、要求されるリペアの数は累算されたリペアの数と当該受信器が必要とするリペアの数との間の差であり、この差が前記累算に足し合わされる。
【００３２】
好適な一実施形態において、受信器は更に、当該受信器が再送信要求を送出する前に待つ遅延期間を計る遅延期間タイマを含む。
【００３３】
更なる一実施形態において、前記遅延期間は、受信器が必要とするリペアの数に反比例する。
【図面の簡単な説明】
【００３４】
本発明のその他の特徴及び効果が、以下にて添付図面を用いて説明する本発明の非限定的な実施形態の説明によって明らかになる。
【図１】従来のマルチキャスト無線システムを示す図である。
【図２】一実施形態に従った受信器の構成要素を示すブロック図である。
【図３】パケットの受信側でのラウンド番号更新手順を示すフローチャートである。
【図４】バッファ期間中にパケットロスが発生したときの処理を示すフローチャートである。
【発明を実施するための形態】
【００３５】
以下の説明は本発明の好適実施形態を例示するものであり、この例示は本発明の範囲に何らかの限定を加えるものとして解釈されるべきではない。
【００３６】
ここでは、パケット送信者及びパケット受信者それぞれにおいてビデオストリーミングを取り扱う方法、プロセス及び装置を説明するため、幾つかの実施形態を例示する。
【００３７】
当業者に知られているように、例えばオンラインムービー等の一部の実時間ビデオ用途においては、受信器に伝送されたビデオパケットのブロックに対し、これらのビデオパケットは、或る期間ＢＴだけ受信器にてバッファリングされた後にデコーダに送られる。バッファ期間ＢＴ中、受信側でパケットロスが存在しない場合、ビデオパケットは、バッファ期間の終了後、デコーダによって首尾よく復号されることが可能である。受信器は、多数のパケットがバッファ期間ＢＴ中に失われたことを検出すると、ビデオパケットが復元されるまで、あるいはバッファ期間が満了するまで、更なるリペアの再送信のために送信器にＡＲＱを送信する。
【００３８】
図２は、本実施形態に従った受信器を示している。図２に示すように、各受信器２００は、ビデオパケットを、パケットロスを復元するためのプロアクティブ・リペアとともに受信し、且つパケットロスがプロアクティブ・リペアによって復元されることができないときに送信器からの再送信リペア、受信器２００により要求されて受信器２００に再送信された更なるリペアを受信するパケット受信ユニット２１と；受信されたパケットに従って幾つのパケットが失われたかを分析するパケットロス分析器２２と；その他の受信器によって送信されたＡＲＱを検出するＡＲＱ検出器２５と；開始されたラウンドの数をカウントするラウンド計数ユニット２４と；開始された全てのラウンド内で送信されたリペアの数をカウントするリペア計数ユニット２６と；ＡＲＱが送出されるべきか、あるいはその送出が見送られるべきかを、その他の受信器によって送信された検出ＡＲＱ及び受信器２００におけるパケットロスに基づいて決定するＡＲＱプロセッサ２３と；ネットワーク上でＡＲＱをブロードキャストするＡＲＱ送信器２９と；バッファ期間ＢＴを計るバッファ期間タイマ２８と；ＡＲＱが送出される前に待たれる遅延期間を計る遅延期間タイマ２７と、を含んでいる。
【００３９】
次に、図３を考察する。図３は、パケット受信器におけるラウンド番号更新手順を示すフローチャートである。
【００４０】
受信器Ｃｉからの各ＡＲＱ  Ａｉは、受信器Ｃｉが送信要求したリペアの数ｎｉと、ブロック伝送の現在のラウンドを指し示すＡＲＱラウンド番号Ｎｉとを含む。
【００４１】
受信器Ｃｉに伝送されたビデオパケットのブロックに対し、バッファ期間タイマ２８が先ずバッファ期間ＢＴを設定する。期間ＢＴの設定方法は従来技術において周知であり、ここでは説明しない。受信器Ｃｉには、ＡＲＱラウンドカウンタＮｉ’及びリペアカウンタｎｉ’が存在する。ＡＲＱラウンドカウンタＮｉ’は、幾つのＡＲＱラウンドが送出されたかをカウントするために用いられ、リペアカウンタｎｉ’は、開始された全ラウンド内で送信されたリペアの数をカウントするために用いられる。このラウンドカウンタは当初、ラウンド計数ユニット２４にて０に設定され、リペアカウンタｎｉ’はリペア計数ユニット２６にて０に初期化される。ＢＴ期間中、受信器Ｃｉは、ＡＲＱラウンドカウンタＮｉ’及びリペアカウンタｎｉ’を更新するため、その他の受信器からのＡＲＱを受信し続ける。説明を明瞭にするため、以下では、ラウンドカウンタ及びリペアカウンタの更新プロセスと、パケットロスの処理プロセスとを別々に説明する。
【００４２】
先ず、ラウンドカウンタ及びリペアカウンタの更新プロセスが導入される。図２及び図３を併せて参照する。段階３１０にて、バッファ期間タイマ２８がバッファ期間ＢＴを設定する。段階３２０にて、ＡＲＱラウンドカウンタがラウンド計数ユニット２４にて初期的に０に設定され、リペアカウンタｎｉ’がリペア計数ユニット２６にて０に初期化される。
【００４３】
段階３３０にて、受信器ＣｉにおけるＡＲＱ検出器２５が、バッファ期間ＢＴ中に無線ネットワーク上でその他の受信器に耳を傾ける（リッスンする）。そして、段階３４０にて、受信器Ｃｉがその他の受信器からのその他のＡＲＱ  Ａｊ（Ｎｊ，ｎｊ）を聞いたかどうかが決定される。ノー“Ｎ”であれば、このプロセスは段階３７０へと進み、ＢＴが満了したかどうかを検出する。段階３４０にてイエス“Ｙ”の場合、段階３５０にて、ＮｊがＮｉ’より大きいかどうかが更に決定される。この段階は、ラウンドＮｉ’後に別の要求ラウンドが送出されたかどうか、及び受信器ＣｉにおけるラウンドカウンタＮｉ’及びリペアカウンタｎｉ’がそれぞれラウンド計数ユニット２４及びリペア計数ユニット２６にて更新される必要があるかどうかを決定するために用いられる。ＮｊがＮｉ’より大きい場合、すなわち、段階３５０にて“Ｙ”の場合、段階３６０にて、受信器Ｃｉにおけるラウンド計数ユニット２４はラウンドカウンタＮｉ’をＮｊに従って更新し、リペア計数ユニット２６はｎｉ’＝ｎｊ＋ｎｉ’に設定する。すなわち、別のＡＲＱラウンドが送出されており、全受信器によって開始されたＡＲＱラウンドの総数はＮｊであり、全受信器によって要求されたリペアの数はもはやｎｉ’＝ｎｊ＋ｎｉ’である。ノー“Ｎ”の場合、要求Ａｊは無視され、プロセスは段階３７０へと進む。Ｎｉ’がＮｊ以上であるとき、それは、受信器Ｃｊが要求Ａｊを送信する前に一部の受信器が要求を送信したことを受信器Ｃｊが見逃したかもしれないことを意味するからである。故に、時々、受信器Ｃｊにおけるパケットロスが、受信器Ｃｊによって聞き取られなかった受信器により送信されたリペアによって復元されることが起こり得る。このようなケースが発生することを回避するため、この種の要求は該受信器において無視される。そして、要求Ａｊは受信器Ｃｊによって送出されたものであるが、この要求も（ＮｊがＮｉ’より小さいとき）送信側で無視されてもよい。段階３７０にて、受信器Ｃｉはバッファ期間ＢＴが満了したかどうかを検出する。バッファ期間ＢＴが満了した場合、すなわち、段階３７０にて“Ｙ”の場合、それは、ビデオパケットのブロックがデコーダに送られる必要があることを意味する。そうであれば、この手順は段階３８０にて終了する。そうでなければ、プロセスは段階３３０へと戻り、ネットワーク上で送信されたＡＲＱの検出を継続する。
【００４４】
斯くして、この更新プロセスにより、各受信器はその他の受信器によって送信されたＡＲＱの状況を遅滞なく知ることができ、幾つのＡＲＱラウンドが実行されたか、及び幾つのＡＲＱが送出されたかが分かる。
【００４５】
受信器Ｃｉは、ラウンドカウンタＮｉ’及びリペアカウンタｎｉ’を更新するためにその他の受信器をリッスンしながら、そのビデオパケットのブロックにパケットロスが発生したかを検出し、それに従ってパケットロスを処理する。
【００４６】
図４は、パケットロスが発生したときのプロセスを示すフローチャートである。図４に示すように、段階４００にてバッファ期間ＢＴが設定され、段階４１０にて、ラウンドカウンタＮｉ’及びリペアカウンタｎｉ’が０に初期化される。これらは図３の段階３１０及び３２０に示したものと同じである。バッファ期間ＢＴ中、段階４２０にて、一部のパケットが失われたかどうかが決定される。パケットロスがない場合、すなわち、段階４２０にて“Ｎ”の場合、プロセスは段階５３０へと進む。受信器Ｃｉにおいてパケットロスが発生した場合、すなわち、段階４２０にて“Ｙ”の場合、受信器ＣｉにおけるＡＲＱプロセッサ２３が、再送信される必要があるリペアの数ｎｉを決定する。ＡＲＱを送出するのに先立ち、受信器Ｃｉは遅延期間Ｔｉを待つ必要がある。この遅延期間Ｔｉは、段階４３０にて、遅延期間タイマ２７によって設定される。遅延期間Ｔｉはバッファ期間ＢＴより短いものであり、より多数のリペアを必要とするＡＲＱほど早期に送出され得るように、好ましくは該受信器が必要とするリペアの数ｎｉの逆比に従って、適応的に設定される。故に、一部の冗長な要求が抑制される。より少ない喪失ビデオパケットを有する受信器が自身の要求を送信器に送出していなくても、より少ない喪失パケットを有するこれら受信器における喪失パケットを復元することには、より多くの喪失パケットを有する受信器によって要求された、より多数のリペアを伴う再送信で十分だからである。
【００４７】
段階４４０にて、受信器Ｃｉが再送信リペアを受信したかどうかが決定される。“Ｙ”の場合、受信器Ｃｉは、幾つの喪失パケットが復元されたかを決定し、リペア数ｎｉを更新する。そして、要求Ａｉの送出が見送られるべきか否かが決定される。この決定は、段階４６０にて、受信器Ｃｉが必要とするリペア数ｎｉの、リペア計数ユニット２６におけるリペアカウンタｎｉ’との比較に基づいて為される。受信器Ｃｉが必要とするリペア数ｎｉが、最近更新されたリペア計数ユニット２６におけるリペアカウンタｎｉ’より大きくない場合、すなわち、段階４６０にて“Ｎ”の場合、ＡＲＱプロセッサ２３は、段階４９０にて自身のＡＲＱ  Ａｉの送出を見送り、段階５２０においてリペアの再送信を待つ。このような場合、受信器Ｃｉにおけるパケットロスを復元することには、要求されるリペア数を伴って送信されたＡＲＱ群で十分だからである。故に、受信器Ｃｉによって送信される要求Ａｉは不要である。段階４７０にて、遅延期間Ｔｉが満了したかどうかが決定される。遅延期間Ｔｉ中、リペアカウンタｎｉ’もその他の受信器からのＡＲＱ群に従って更新され続けるからである。更新されたリペアカウンタｎｉ’がｎｉ以上であるとき、受信器ＣｉはＡＲＱ  Ａｉの送出を見送る。受信器Ｃｉは遅延期間Ｔｉが満了するまでｎｉをｎｉ’と比較し続ける。
【００４８】
遅延期間Ｔｉが満了したとき、受信器Ｃｉが必要とするリペア数ｎｉが依然としてパラメータｎｉ’より大きい場合、すなわち、段階４７０にて“Ｙ”の場合、受信器Ｃｉは新たなＡＲＱラウンドを実行する必要がある。遅延期間Ｔｉの満了を受けて、段階４８０にて、ラウンドカウンタがラウンド計数ユニット２４において１だけ増大され、段階５００にて、新たなラウンド番号Ｎｉ’と送信器によって再送信される必要があるリペアの数ｎｉ−ｎｉ’とを有するＡＲＱ  Ａｉが送出される。そして、段階５１０にて、リペアカウンタｎｉ’がリペア計数ユニット２６において更新、すなわち、ｎｉ’＝ｎｉに設定される。ＡＲＱ  Ａｉが送出される場合、ｎｉ個のリペアが要求されているからである。
【００４９】
そして、段階５２０にて、受信器は或る期間、再送信を待つ。段階５３０にて、バッファ期間ＢＴが満了したかどうかが決定される。“Ｙ”の場合、プロセスは段階５５０にて終了する。“Ｎ”の場合、ＢＴの満了前に受信器がリペアを受信したとき、再送信されたリペアによってパケットロスを復元することができるか、及び別のＡＲＱが送出される必要があるかが決定される。再送信されたリペアの一部が再送信中に失われた場合、受信器は別の要求ラウンドを実行することを決定し、プロセスは段階４３０へと戻り、依然として必要とされるパケット数に従って、上述のように遅延期間Ｔｉを設定する。再送信されたリペアが受信器Ｃｉにおけるパケットロスを復元するのに十分であり、且つ受信器が別のＡＲＱ送信ラウンドを必要としない場合、すなわち、段階５４０にて“Ｎ”の場合、プロセスは段階５５０にて終了する。
【００５０】
送信側のプロセスは、非特許文献１にて提案されるように、ラウンド−カレント法にて行われる。送信器は、当初０であるラウンドＮｓを管理し、現在の送信器のラウンド番号Ｎｓに等しいラウンド番号を有する送信されたリペアの総数のカウントｎを管理する。到来するＡＲＱに対し、Ｎｉ＜Ｎｓである場合、そのＡＲＱを無視する。Ｎｉ＝Ｎｓである場合、ｍａｘ（０，ｎｉ−ｎ）個のパケットを送信し、ｎ＝ｍａｘ（ｎ，ｎｉ）に設定する。Ｎｉ＞Ｎｓである場合、ｎ＝ｎｉ、Ｎｓ＝Ｎｉに設定し、ｎｉ個のパケットを送信する。
【００５１】
本発明を好適設計を有するものとして説明したが、本発明はこの開示の精神及び範囲内で更に変更され得るものである。本出願は、故に、本発明の、その一般的原理を用いた如何なる変形、使用、又は適応化をもカバーするものである。本出願はまた、本発明が関係する技術における既知のもの又は慣用されるものの範囲内に入り且つ添付の請求項の限定の範囲内に入るような、この開示からの逸脱をカバーするものである。
【図１】
2010521090.tif 000003
【図２】
2010521090.tif 000004
【図３】
2010521090.tif 000005
【図４】
2010521090.tif 000006
【国際調査報告】
2010521090.tif 000007
2010521090.tif 000008