一般ＮＡＣＫレポートブロックおよび消失ＲＬＥレポートブロックを使用するフィードバックの提供
本発明は、ＲＴＰプロトコルおよびＲＴＣＰプロトコルを使用して提供される少なくとも１つのストリーミングセッションのデータパケットに対するＲＴＣＰフィードバックメッセージをクライアントからストリーミングサーバに提供する方法に関する。さらに、前記ストリーミングセッションの利用可能な帯域幅の一部であるＲＴＣＰ帯域幅が、ＲＴＣＰフィードバックメッセージに割り当てられる。さらに、本発明は、モバイル通信システムにおける、本方法を実行するクライアントにさらに関する。本発明は、利用可能なクライアントバッファリング時間による最大再送信回数を保証することと、可能な場合に消失パケットに関する望ましいレベルの冗長レポーティングを行えるようにすることとを目的として、ユニキャストセッションにおけるＲＴＣＰフィードバックを最適化する方法を提供する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＲＴＰプロトコルおよびＲＴＣＰプロトコルを使用して提供される少なくとも１つのストリーミングセッションのデータパケットに対するＲＴＣＰフィードバックメッセージを、クライアントからストリーミングサーバに提供する方法に関する。さらに、ストリーミングセッションの利用可能な帯域幅の一部であるＲＴＣＰ帯域幅が、このＲＴＣＰフィードバックメッセージに割り当てられる。その上、本発明は、モバイル通信システムにおける、本方法を実行するクライアントにさらに関する。
【背景技術】
【０００２】
３ＧＰＰ（3rd Generation Partnership Project）では、メディアを符号化するＡＭＲ（Adaptive Multi-Rate）やＨ．２６４（MPEG 4 part 10)などの伝送およびパケット交換コーデックに、ＲＴＰ、ＵＤＰ、ＩＰなどのＩＥＴＦ（Internet Engineering Task Force)標準プロトコルを採用している。３ＧＰＰパケット交換ストリーミングサービス（非特許文献１参照、http://www.3gpp.orgで入手可能）では、音声／映像／テキストメディアをストリーミングするためにＲＴＰ／ＵＤＰプロトコルスタックを使用している。
【０００３】
ＲＴＰは、主としてリアルタイム通信またはほぼリアルタイムの通信、すなわち遅延制約がゆるい通信に使用されているリアルタイムトランスポートプロトコル（非特許文献２参照、すべてのＲＦＣおよびインターネットドラフトはhttp://www.ietf.orgで入手可能）である。ＲＴＰでは、伝送するメディアのタイミングについての情報が提供され、受信者において順序入れ替え（re-ordering）および再構築を行うこともできる。
【０００４】
ＲＴＣＰ（Real Time Control Protocol）は、このプロトコルに統合されている部分であり、最小限の受信情報とゆるいグループメンバーシップとを提供する。ＲＴＰは、一般的には、ＲＴＰ／ＡＶＰプロファイル（非特許文献３参照）と組み合わせて使用され、ＲＴＰ／ＡＶＰプロファイルは、ＲＴＰヘッダフィールドの使用と、ペイロードタイプのマッピングテーブル、さらには単純なＲＴＣＰフィードバックタイミング規則を定義する。ＴＣＰ／ＩＰベースのトラフィックと公平に競合するように、ＲＴＣＰプロトコルには、利用可能なＲＴＰ帯域幅の一部が割り当てられる。
【０００５】
ＵＤＰ（非特許文献４）は、ＲＴＰパケットを伝送する目的に使用されるユーザデータグラムプロトコルである。ＵＤＰは、一般に、ストリーミングアプリケーションの場合など、メディアの通信の信頼性が低くてもよいときに使用される。プロトコルスタックＲＴＰ／ＵＤＰが使用される理由は、メディアのタイミング制約のために、例えばＴＣＰ（Transmission Control Protocol）の使用による信頼性の高い通信を行うことができないためである。
【０００６】
ＲＴＰでは、既存のメディア形式（コーデック）に対するパケット化方式（ペイロード形式）が、Internet Engineering Task Force Audio/Video Transport Working Group（IETF AVT WG)において指定されている。例えば、ＡＭＲ方式で符号化される音声データ用のペイロード形式と、Ｈ．２６４映像用の別の形式とが存在する。非特許文献５に定義されているＲＴＰペイロード形式では、このフレームワークにおいてＲＴＰパケットを再送信することもできる。このことは、３ＧＰＰ ＰＳＳストリーミングサービスに特に有用である。
【０００７】
非特許文献５に指定されているように、複数回の再送信を発行するメカニズムは、クライアントが必要なときにのみ要求を発行することに依存している。クライアントは、非特許文献６に指定されている可能なフィードバック方式を使用しなければならない。その他のレポーティングブロック、例えば、非特許文献７によって定義されているブロックも、使用することができる。
【０００８】
レポーティングの頻度は、RFC 3550における標準のＲＴＣＰレポート間隔計算法を使用して計算することができる（６．３節およびＡｎｎｅｘを参照）。受信者レポートの範囲、すなわち、レポートするパケットの数は、指定されていない。クライアントは、ＲＴＰ／ＡＶＰＦプロファイルに指定されている一般ＮＡＣＫ（Ｎｅｇａｔｉｖｅ ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ）フィードバックメッセージを使用する（draft-ietf-avt-rtcp-feedback-11.txtはhttp://www.ietf.org/internet-drafts/において取得できる）。なお、ＲＴＰ／ＡＶＰＦプロファイルにはＡＣＫメッセージに関して指定されていないため、クライアントはＲＴＰ／ＡＶＰＦプロファイルを使用してパケットに対して肯定応答することはできない。したがって、例えばＲＬＥレポートを使用することによる包括的なレポーティングは提供されない。
【０００９】
さらに、RFC 3611に定義されている消失ＲＬＥレポートは、圧縮可能な高度なレポーティングブロックであり、初期設定においてＡＣＫとＮＡＣＫとが組み合わされる、すなわち、消失パケットおよび受信パケットについてレポートすることができる。これらのレポートは、ネットワークの保守目的、課金、マルチキャストツリーインファレンス（multicast tree inference）、および統計情報の収集のために指定されたものである。
【００１０】
消失ＲＬＥレポートおよびユニキャストＲＴＣＰレポーティングに対処している３番目のドキュメントは、３ＧＰＰパケット交換ストリーミングサービス（ＰＳＳ）フレームワークである。このドキュメントによると、ストリーミングクライアントは消失ＲＬＥレポートブロックの使用を実装し、過去のＲＴＣＰ間隔について冗長にレポートすることが推奨されている。さらに、３ＧＰＰ ＰＳＳフレームワークによると、これらのレポートは再送信をトリガする目的には使用すべきでないことが記されている。
【００１１】
３ＧＰＰ ＰＳＳフレームワークのコンテキストにおける冗長なレポーティングとは、消失データパケットに関する最小回数のレポートを、それらの処理前、または処理後において有効にすることとして理解される。しかしながら、クライアントにおいてこのメカニズムをどのように実装すべきか、およびこのメカニズムをＲＴＰ再送信要求と一緒にどのように使用すべきかに関する指定はない。消失パケットに関する冗長なレポーティングが望ましいのは、フィードバック、すなわちＲＴＣＰメッセージが、一般には、ＵＤＰのような、肯定応答されず、従って信頼性の低い伝送プロトコルを使用して送信されるためである。したがって、特に、例えばＵＭＴＳのような無線アクセスネットワークを介したサービスの提供を考慮するときには、セッションの受信者によって提供されるフィードバックが消失することがある。
【００１２】
上述したように、ＰＳＳフレームワークでは、消失ＲＬＥレポートブロック（RFC 3611）は課金およびネットワークの監視のみを目的として使用することが要求されるのに対して、消失データパケットの再送信を実際にトリガする目的には一般ＮＡＣＫメッセージ（ＲＴＰ／ＡＶＰＦプロファイル）が使用される。したがって、ＰＳＳフレームワークでは、再送信をトリガできるようにすると同時に、（例えば）課金およびネットワークの監視を行うことができるようにするためには、伝送セッションのＲＴＣＰフィードバックには一般ＮＡＣＫレポートブロックおよび消失ＲＬＥレポートブロックが含まれていることが要求される。
【００１３】
Ｒｅｙらによって説明されている複数回再送信アルゴリズムでは、パケットの再送信をトリガする目的に、ＯｔｔらによるＲＴＰ／ＡＶＰＦドラフトに定義されているメッセージ形式、すなわち一般ＮＡＣＫを使用する（または使用することができる）。
【００１４】
３ＧＰＰ ＰＳＳフレームワークによって推奨されているように、受信されたパケットと受信されないパケットとの両方をレポートする場合、このことは、これらのレポートブロックが増大して相当なオーバーヘッドとなりうることを意味し、従って、ＲＴＣＰに割り当てられている予約帯域幅が不足して、継続的な送受信（play-out）および／または要求されるレポートの冗長度を保証するのに必要な時間長にわたりレポートすることができなくなることがある。さらに、再送信のトリガと平行して、課金およびネットワークの監視サービスを可能にするためには、ＰＳＳセッションを受信するクライアントのフィードバックに冗長なレポートブロック（消失ＲＬＥレポートブロック）を含める必要があり、このブロックもオーバーヘッドにつながり、レポーティングの頻度と、従って提供することのできる冗長レポーティングのレベルに影響する。
【非特許文献１】"Universal Mobile Telecommunications System (UMTS) ; Transparent end-to-end streaming service ; Protocols and codecs", 3GPP TS 26.234 version 6.1.0, September 2004
【非特許文献２】Schulzrinne et al., "RTP : A Transport Protocol for Real-Time Applications", RFC 3550, July 2003
【非特許文献３】Schulzrinne et al., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003
【非特許文献４】Postel, "User Datagram Protocol", RFC 768, August 1980
【非特許文献５】Rey et al., "RTP Retransmission Format", Internet Draft, IETF AVT Workgroup, August 2003
【非特許文献６】Ott et al., "Extended RTP Profile for RTCP-based FeedbacK （RTP/AVPF）", Internet Draft, IETF AVT Workgroup, August 2004
【非特許文献７】Friedman et al., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003
【発明の開示】
【００１５】
（発明の概要）
したがって、本発明の目的は、ユニキャストセッションにおけるＲＴＣＰフィードバックを最適化する方法を提供することである。
【００１６】
本発明のこの目的は、独立請求項の主題によって解決される。好ましい実施形態は、従属請求項の主題である。
【００１７】
本発明の１つの実施形態は、ＲＴＰプロトコルおよびＲＴＣＰプロトコルを使用して提供される少なくとも１つのストリーミングセッションのデータパケットに対するＲＴＣＰフィードバックメッセージを、クライアントからストリーミングサーバに提供する方法に関する。この方法によると、クライアントは、ストリーミングセッションのセッション制約内で提供することのできるデータパケットの最大再送信回数が、クライアントによって有効にされる最小再送信回数よりも大きいか否かを、最初に判断することができる。大きい場合、消失データパケットの再送信を要求する複数の一般ＮＡＣＫレポートブロックを、ＲＴＣＰフィードバックパケットに追加することができる。これらの追加された複数の一般ＮＡＣＫレポートブロックによって、クライアントバッファリング時間内での消失データパケットの再送信を最小回数にすることができる。次に、クライアントは、セッション制約を考慮したときに許容されるＲＴＣＰフィードバックメッセージの最大サイズを決定して、結果のＲＴＣＰフィードバックパケットのサイズがＲＴＣＰフィードバックメッセージの最大サイズを超えないように、消失データパケットに関してレポートする複数の消失ＲＬＥレポートブロックを、ＲＴＣＰフィードバックパケットに追加することができる。さらに、クライアントは、ＲＴＣＰフィードバックパケットを、ＲＴＣＰフィードバックメッセージとしてストリーミングサーバに送信することができる。
【００１８】
本発明の別の実施形態は、少なくとも１つのストリーミングセッションのデータパケットに対するＲＴＣＰフィードバックメッセージをクライアントからストリーミングサーバに提供する方法に関する。この実施形態においては、少なくとも１つのストリーミングセッションが、ＲＴＰプロトコルおよびＲＴＣＰプロトコルを使用して提供されており、ストリーミングセッションの利用可能な帯域幅の一部であるＲＴＣＰ帯域幅が、ＲＴＣＰフィードバックメッセージに割り当てられる。
【００１９】
クライアントは、ＲＴＣＰフィードバックメッセージのためのＲＴＣＰ帯域幅と、クライアントバッファリング時間内で有効にする最小再送信回数と、少なくとも１つのストリーミングセッションの消失データパケットに関する最小レポーティング冗長度と、クライアントバッファリング時間とを示すセッション記述情報を受信することができる。さらに、クライアントは、クライアントバッファリング時間とＲＴＣＰレポート間隔とに基づいて提供されうるデータパケットの最大再送信回数を決定することができる。ＲＴＣＰレポート間隔は、ＲＴＣＰフィードバックメッセージの平均サイズと、クライアントに割り当てられているＲＴＣＰ帯域幅とに依存する。
【００２０】
クライアントは、最大再送信回数が、最小再送信回数以上であるかをさらに判断することができ、以上である場合、クライアントは、消失データパケットの再送信を要求する複数の一般ＮＡＣＫレポートブロックを、ＲＴＣＰフィードバックパケットに追加することができる。ＲＴＣＰフィードバックパケットに追加されるこの複数の一般ＮＡＣＫレポートブロックによって、クライアントバッファリング時間内での消失データパケットの再送信を最小回数にすることができる。
【００２１】
さらに、クライアントは、割り当てられているＲＴＣＰ帯域幅と、クライアントバッファリング時間と、最小再送信回数とを考慮したときに許容されるＲＴＣＰフィードバックメッセージの最大サイズを決定することができ、さらに、以前に送られたＲＴＣＰフィードバックメッセージの平均サイズと、複数の一般ＮＡＣＫレポートブロックを含むＲＴＣＰパケットのサイズとに基づいて、結果のＲＴＣＰフィードバックメッセージの平均サイズを決定することができる。
【００２２】
さらに、クライアントは、結果のＲＴＣＰフィードバックパケットのサイズがＲＴＣＰフィードバックメッセージの最大サイズを超えない場合、消失データパケットに関してレポートする複数の消失ＲＬＥレポートブロックを、ＲＴＣＰフィードバックパケットに追加することができ、ＲＴＣＰフィードバックパケットを、ＲＴＣＰフィードバックメッセージとしてクライアントからストリーミングサーバに送信することができる。
【００２３】
本発明の別の実施形態においては、課金またはネットワークの監視を目的とする消失ＲＬＥレポートブロックが、ＲＴＣＰフィードバックパケットに追加される。
【００２４】
さらなる実施形態においては、複数の消失ＲＬＥレポートブロックにランレングス（ｒｕｎｌｅｎｇｔｈ）符号化を行い、次いで、ランレングス符号化を行ったこれらの消失ＲＬＥレポートブロックを含む結果のＲＴＣＰフィードバックパケットのサイズが、ＲＴＣＰフィードバックメッセージの最大サイズを超えていないか否かを判断する。消失ＲＬＥレポートブロックのランレングス符号化を実行することによって、それぞれの数のレポートブロックによって提供することのできるレポーティング冗長度を一定に維持しながら、消失ＲＬＥレポートブロックのサイズを減少させることができる。
【００２５】
別の実施形態においては、クライアントは、クライアントによるセッション記述情報によって設定されている最小レポーティング冗長度を減少させることを決定することができる。パケットの消失に関するレポーティング冗長度を減少させるためのさまざまな可能な方法を予測することができる。
【００２６】
例えば、この実施形態の１つの変形形態においては、クライアントは、ストリーミングセッションのパケットに提供されているアップリンクのサービス品質を決定することができる。この測定された、または決定されたサービス品質（ＱｏＳ）に基づいて、例えば、決定されたサービス品質が所定のしきい値レベルより大きい場合に、最小レポーティング冗長度を減少させる。
【００２７】
別の変形形態においては、複数の消失ＲＬＥレポートブロックのサイズを減少させることによって、クライアントがレポーティング冗長度を減少させることが予測される。
【００２８】
例えば、ストリーミングセッションのデータに、ストリーミングメディアの基本品質を提供する基本データ層と、このストリーミングメディアの基本品質を高める少なくとも１つのエンハンスメント層（enhancement layer）とが含まれている場合には、基本データ層のデータが含まれているデータパケットに関する情報のみを消失ＲＬＥレポートブロックに含めることによって、複数の消失ＲＬＥレポートブロックのサイズを減少させることができる。
【００２９】
例えば、少なくとも１つのストリーミングセッションのデータがＭＰＥＧストリームであり、基本データ層にＩフレームが含まれており、少なくとも１つのエンハンスメント層にＰフレームおよび／またはＢフレームが含まれているとする。この例においては、クライアントは、Ｉフレームは必ずレポートされるが、クライアントによって認識されるストリームのＱｏＳに対する影響の小さいＰフレームおよび／またはＢフレームについては、セッション記述情報によって設定されているセッション制約の中で可能な場合にのみレポートされるようにすることができる。
【００３０】
これに関して、クライアントは、消失データパケットに基本データ層のデータが含まれているか否かを、クライアントにおいてすでに受信されたデータパケットに基づいて判断することができる。
【００３１】
本実施形態のさらなる変形形態による、複数の消失ＲＬＥレポートブロックのサイズを減少させるさらなる可能な方法は、（１つ以上の）消失ＲＬＥレポートブロックにシニング（thinning）を適用することである。
【００３２】
さらに、本実施形態の別の変形形態では、ＲＴＣＰフィードバックパケットにおいてレポートされる複数の消失ＲＬＥレポートブロックを減少させることによって、複数の消失ＲＬＥレポートブロックのサイズを減少させることが予測される。
【００３３】
理想的には、本発明の別の実施形態においては、ＲＴＣＰフィードバックパケットに追加される複数の消失ＲＬＥレポートブロックによって、消失パケットのレポーティング冗長度を最小にすることができる。
【００３４】
さらに、本発明の別の実施形態においては、ストリーミングセッションのＭＩＭＥタイプのパラメータがパケットレートを示すことが予測される。このパラメータは、例えば、ＲＴＣＰレポート間隔の中でレポートしなければならないストリーミングセッションの平均パケット数を推定するのに有用である。
【００３５】
本発明のさらなる実施形態においては、クライアントは、ストリーミングセッションのどのパケットが消失したかを、クライアントにおいて受信されたデータパケットの連続番号に基づいて判断することができる。
【００３６】
本発明の別の実施形態は、少なくとも１つのストリーミングセッションのデータパケットに対するＲＴＣＰフィードバックメッセージをクライアントからストリーミングサーバに送信する、モバイル通信システムにおけるクライアントに関する。この場合も、この少なくとも１つのストリーミングセッションは、ＲＴＰプロトコルおよびＲＴＣＰプロトコルを使用して提供されており、ストリーミングセッションの利用可能な帯域幅の一部であるＲＴＣＰ帯域幅が、ＲＴＣＰフィードバックメッセージに割り当てられる。本発明のこの実施形態によるクライアントは、セッション記述情報を受信する受信器、およびクライアントバッファリング時間とＲＴＣＰレポート間隔とに基づいたときに提供することのできるデータパケットの最大再送信回数を決定するステップと、最大再送信回数が最小再送信回数以上であるか否かを判断するステップとを行う処理手段を備えていることができる。セッション記述情報は、ＲＴＣＰフィードバックメッセージのためのＲＴＣＰ帯域幅と、クライアントバッファリング時間内で有効にする最小再送信回数と、少なくとも１つのストリーミングセッションの消失データパケットの最小レポーティング冗長度と、クライアントバッファリング時間とを示す。ＲＴＣＰレポート間隔は、ＲＴＣＰフィードバックメッセージの平均サイズと、クライアントに割り当てられるＲＴＣＰ帯域幅とに依存する。
【００３７】
上記処理手段は、消失データパケットの再送信を要求する複数の一般ＮＡＣＫレポートブロックをＲＴＣＰフィードバックパケットに追加してクライアントバッファリング時間内での消失データパケットの再送信回数を最小にするステップと、最大再送信回数が最小再送信回数以上である場合に、割り当てられているＲＴＣＰ帯域幅、クライアントバッファリング時間、および最小再送信回数を考慮したときに許容されるＲＴＣＰフィードバックメッセージの最大サイズを決定するステップと、を行うようにすることができる。
【００３８】
上記処理手段は、以前に送られたＲＴＣＰフィードバックメッセージの平均サイズと、複数の一般ＮＡＣＫレポートブロックを含んでいるＲＴＣＰパケットのサイズとに基づいて、結果のＲＴＣＰフィードバックメッセージの平均サイズを求めるステップと、この結果のＲＴＣＰフィードバックパケットのサイズがＲＴＣＰフィードバックメッセージの最大サイズを超えない場合、消失データパケットに関してレポートする複数の消失ＲＬＥレポートブロックをＲＴＣＰフィードバックパケットに追加するステップと、を行うようにすることもできる。
【００３９】
クライアントは、ＲＴＣＰフィードバックパケットをＲＴＣＰフィードバックメッセージとしてストリーミングサーバに送信する送信器をさらに備えていることができる。
【００４０】
別の実施形態は、上述したさまざまな実施形態およびそれらの変形形態のうちの１つによる方法を実行するようにされている手段、をさらに備えているクライアントに関する。
【００４１】
さらに、本発明の別の実施形態は、モバイル通信システムにおけるクライアントのプロセッサによって実行されたときに、クライアントに、少なくとも１つのストリーミングセッションのデータパケットに対するＲＴＣＰフィードバックメッセージをクライアントからストリーミングサーバに提供させる、命令、を格納しているコンピュータ可読媒体に関する。この場合も、少なくとも１つのストリーミングセッションは、ＲＴＰプロトコルおよびＲＴＣＰプロトコルを使用して提供されており、ストリーミングセッションの利用可能な帯域幅の一部であるＲＴＣＰ帯域幅は、ＲＴＣＰフィードバックメッセージに割り当てられる。
【００４２】
クライアントにおいて、ＲＴＣＰフィードバックメッセージのためのＲＴＣＰ帯域幅と、クライアントバッファリング時間内で有効にする最小再送信回数と、少なくとも１つのストリーミングセッションの消失データパケットの最小レポーティング冗長度と、クライアントバッファリング時間とを示すセッション記述情報を受信するステップと、クライアントバッファリング時間と、ＲＴＣＰフィードバックメッセージの平均サイズおよびクライアントに割り当てられるＲＴＣＰ帯域幅に依存するＲＴＣＰレポート間隔とに基づいてデータパケットの最大再送信回数を決定するステップと、最大再送信回数が最小再送信回数以上であるか否かを判断するステップと、によって、クライアントに、少なくとも１つのストリーミングセッションのデータパケットに対するＲＴＣＰフィードバックメッセージをクライアントからストリーミングサーバに提供させることができる。
【００４３】
後者の場合、命令によって、消失データパケットの再送信を要求する複数の一般ＮＡＣＫレポートブロックをＲＴＣＰフィードバックパケットに追加して、クライアントバッファリング時間内での消失データパケットの再送信を最小回数にするステップと、割り当てられているＲＴＣＰ帯域幅、クライアントバッファリング時間および最小再送信回数を考慮したときに許容されるＲＴＣＰフィードバックメッセージの最大サイズを決定するステップと、以前に送られたＲＴＣＰフィードバックメッセージの平均サイズおよび複数の一般ＮＡＣＫレポートブロックを含んでいるＲＴＣＰパケットのサイズに基づいて、結果のＲＴＣＰフィードバックメッセージの平均サイズを決定するステップと、この結果のＲＴＣＰフィードバックパケットのサイズがＲＴＣＰフィードバックメッセージの最大サイズを超えない場合に、消失データパケットに関してレポートする複数の消失ＲＬＥレポートブロックをＲＴＣＰフィードバックパケットに追加するステップと、ＲＴＣＰフィードバックパケットをＲＴＣＰフィードバックメッセージとしてクライアントからストリーミングサーバに送信するステップと、をクライアントに行わせることができる。
【００４４】
本発明のさらなる実施形態によるコンピュータ可読媒体は、クライアントのプロセッサによって実行されたときに、クライアントに、上述した本発明のさまざまな実施形態およびそれらの変形形態のうちの１つによる方法を実行させる、命令、をさらに格納している。
【００４５】
本発明の別の実施形態は、ＲＴＰプロトコルおよびＲＴＣＰプロトコルを使用して提供される少なくとも１つのストリーミングセッションをクライアントに提供するストリーミングサーバと、上記の本発明の実施形態のうちの１つによるクライアントと、を備えているシステムを提供する。
【００４６】
（詳細な説明）
以下では、添付の図面を参照しながら本発明についてさらに詳細に説明する。図面における類似するかまたは対応する細部は、同じ参照数字によって表してある。
【００４７】
図１は、本発明の実施形態によるストリーミング環境の概要を示している。ストリーミングサーバ１００は、１つまたは複数のセッションの形式におけるストリーミングサービスを、無線アクセスネットワークを介してクライアント１０１またはモバイル端末に配信することができる。この例においては、コアネットワーク１０３（ＣＮ）を備えているＵＭＴＳネットワークと、ＵＭＴＳ無線アクセスネットワーク１０４（ＵＴＲＡＮ）は、3GPP TS 26.234に定義されている要件に従って運用することのできるストリーミングパケット交換サービスを提供する。コアネットワーク１０３をパケット交換ネットワーク、例えばインターネットに接続するために、コアネットワークは、ゲートウェイＧＰＲＳサポートノード１０５（ＧＧＳＮ）と、サービングＧＰＲＳサポートノード１０６（ＳＧＳＮ）とを備えていることができる。これらコアネットワークの構成要素は、少なくとも１つの無線アクセスコントローラ１０７（ＲＮＣ）と、ＲＮＣに接続されている少なくとも１つのノードＢとを備えているＵＴＲＡＮ １０４に接続することができる。ストリーミングメディアのデータは、無線リンクを介してモバイルクライアント１０１に提供することができる。
【００４８】
本発明の１つの態様は、さまざまなＲＴＰ再送信の実施形態において、消失をレポートするＲＬＥレポートブロックを効率的に使用することである。そのような実施形態は、一般には、サーバおよびクライアントが実行する機能と、再送信のスケジューリングおよび要求を行うのにサーバおよびクライアントが使用する情報と、サーバおよびクライアントがネットワーク条件（混雑、パケット消失、リンク特性）に関して保持する情報とにおいて異なる。３ＧＰＰ ＰＳＳストリーミングサービスでは、セッション記述属性が定義される。上記の情報を通信ピア間で利用可能にするために、この属性をしてもよく、使用しなくてもよい。
【００４９】
ＲＴＰ再送信の実施形態のいずれにおいても、同一の初期シナリオおよび要件として、以下を想定することができる。すなわち、ＲＴＣＰ伝送の信頼性が低いので、クライアントは冗長なレポーティングを実行すべきである。さらに、クライアントは、少なくとも現在のレポートと１つ前のレポートとの間の期間についてレポートする、すなわち最小受信者レポーティングを保証すべきである。
【００５０】
レポートの頻度は、適切なタイミングで再送信を行うことができるように、すなわち、各ＲＴＰパケットに対して最小回数の再送信が保証されるように、十分に大きくすべきである。したがって、クライアントは、サーバによって伝えられるＲＴＣＰ帯域幅に従うように、レポートの頻度、レポートのブロックサイズ、および冗長レポーティングを制限することができる。
【００５１】
これらの要件のいくつかは競合し、すべてのシナリオにおいてこれらの要件を同時に満たすことが不可能なことがあるので、クライアントは、与えられた条件に対して、冗長レポーティングのレベル、レポーティングの頻度、およびレポートされるＲＴＰパケットの数を最適化することができる。
【００５２】
このことは、例えば、（ＲＴＣＰ帯域幅割当ておよびクライアントバッファリング時間が、冗長なレポーティングを行うことのできるものであると仮定すると）、単純な実施形態において、クライアントが、現在のＲＴＣＰレポートと前のＲＴＣＰレポートとの間の消失パケットすべてに対して一般ＮＡＣＫレポートブロックを使用して再送信を要求し、これらの消失パケットすべてについて消失ＲＬＥレポートブロックを使用してレポートし、消失パケットおよび受信パケットに関する冗長レポーティングのレベルを適切な値に設定し、ＲＴＣＰレポートの頻度を、適切なタイミングで最大回数だけ再送信できるようにできる限り高く維持することを意味しうる。ダウンリンク（サーバからクライアント）上のＲＴＰパケットは複数回消失することがあり、したがって、複数回の再送信が必要となりうることに留意されたい。
【００５３】
伝えられるＲＴＣＰ帯域幅に従うようにレポートの頻度、レポートブロックのサイズ、および冗長レポーティングを制限するための要件に、この単純な実施形態が従う必要がない場合、クライアントは、最初に、ランレングス符号化によって消失ＲＬＥレポートブロックのサイズを減少させることを試みることができる。
【００５４】
消失ＲＬＥレポートブロックによって、個々のパケットの受信イベントおよび消失イベントに関する詳細なレポーティングが可能である。そのようなレポートは、例えば、ネットワーク特性のマルチキャストインファレンス（ＭＩＮＣ）に使用することができる。消失ＲＴＰパケットおよび受信ＲＴＰパケットのブール式トレース（Boolean trace）は長さが大きくなりうるため、このブロックタイプでは、ランレングス符号化を通じてトレースを圧縮することができる。ランレングス符号化を使用するときには、符号化するトレースを分析し、同一イベントの「連続（runs）」をまとめて消失ＲＬＥレポートブロックの全体的なサイズを減少させることができる。
【００５５】
次に、クライアントは、消失ＲＬＥレポートブロックあたりレポートされるＲＴＰパケットの数を減少させることができる。なお、１つのレポートブロックによってレポートされるパケット数が減少すると、結果的に冗長レポーティングのレベルが減少することに留意されたい。
【００５６】
消失ＲＬＥレポートブロックによってレポートされるパケットの数を減少させる目的で、消失イベントのレポートを、シニングと称されるメカニズムにおいてトレースから体系的にドロップすることができる。このシニングメカニズムは、シニング値Ｔを選択することによって実施することができ、この値Ｔを使用して、連続番号空間内のパケットのサブセット、例えば連続番号が２Ｔの倍数であるパケットを選択することができる。パケットの受信および消失のレポートは、これらのパケットにのみ適用される。Ｔは、例えば、０〜１５の間で変えることができる。Ｔがゼロである場合、連続番号空間内のすべてのパケットがレポートされる。Ｔが１５である場合、３２，７６８個のパケットごとに１つのパケットがレポートされる。
【００５７】
いま、上述したトレースが連続番号１３，８２１から開始されるとする。トレースにおける最後の連続番号は１３，８６５である。シニング値Ｔ＝２でトレースにシニングを行う場合、４つごとに１つの連続番号、すなわち、１３，８２４、１３，８２８、１３，８３２、１３，８３６、１３，８４０、１３，８４４、１３，８４８、１３，８５２、１３，８５６、１３，８６０、１３，８６４がレポートされる。
【００５８】
レポートされるパケットの数を減少させる別のオプションは、最も新しいパケット群に属するパケットのみをレポートすることである。
【００５９】
最後に、これらの方策のいずれも有用ではなく、クライアントバッファリング時間が終了するまでの再送信要求（１つ以上の一般ＮＡＣＫレポートブロック）の最小回数について厳しい要件が課される場合、クライアントは、これらの要求される最小再送信回数に従うための大きなＲＴＣＰ帯域幅でセッションを再起動し、および／またはクライアントバッファリング時間を増加させる（詳細は後の説明を参照）。
【００６０】
本発明の基礎をなす概念をさらに説明する目的で、ＲＴＣＰ帯域幅、クライアントバッファリング時間、ＲＴＣＰレポート間隔などの間の関係について、図３を参照しながら以下に説明する。図３は、本発明の実施形態によるストリーミング環境の概要を示している。この図には、複数の連続的な再送信要求と再送信とを時系列で示してある。ＲＴＰパケットの最初の送信（ＳＮ＝０）と、その１回目および２回目の再送信とが消失するものと仮定する。
【００６１】
送信者（例えばストリーミングサーバ）は、受信者（クライアント）にＲＴＰデータパケットを提供する。遅延Ｔ１に寄与するパラメータは、送信者から１つ以上のネットワークを通じての受信者までの一方向遅延、すなわち、物理的な遅延（physical delay）、エアインタフェースにおける送信遅延（transmission delay）、およびネットワークキューや順序入れ替えなどによる到着間ジッタ（interarrival jitter）に起因する遅延である。
【数１】
より詳細には次のようになる。
【数２】
【００６２】
いま、パケットの最初の送信が消失すると仮定すると、Ｔ２は、そのパケットの理論的な到着と、受信者がパケット消失を示すフィードバックを送信者に提供する時点との間の時間間隔を表す。
【００６３】
したがって、Ｔ２は、クライアントにおいてパケット消失を検出するのに要する時間（パケット消失検出時間：packet loss detection time）と、クライアントからの次のフィードバックレポートまでの平均時間（average time to the next feedback report）とからなる。
【数３】
【００６４】
パケット消失検出時間は、１つのパケットが偶発的に消失するのか（シングルトン消失）、またはパケットがバースト的に消失するのか（バースト消失）に依存する。前者の場合、パケット消失検出時間は、受信者において生じる到着間遅延ジッタ（interarrival delay jitter）に等しいはずである。後者の場合、実際の値を求めるには、バッファリング時間に追加のガードタイム（guard time）を加えなければならない。このガードタイムは、平均消失バースト（average loss burst）として定義され、バースト消失が検出されるまでに時間がかかることを反映するものである。
【００６５】
一般には、消失イベントは均一に分布しているので、次のフィードバックレポートまでの平均時間は、通常ではＲＴＣＰレポート間隔（RTCP report interval）の１／２である。
【数４】
【００６６】
フィードバックレポートの遅延Ｔ３は、基本的には遅延Ｔ１と同様に計算することができる。
【数５】
より詳細には次のようになる。
【数６】
【００６７】
最後に、送信者における再送信の処理時間は、Ｔ４で表してあり、送信者がどのパケットを再送信するかを決定するまでに必要な時間（フィードバック処理時間：feedback processing time）と、送信者におけるキューイング時間（queuing time）、すなわち、再送信されるパケットが実際に送信される前に送信者の（再）送信キューの中にとどまる時間とが含まれる。
【数７】
【００６８】
なお、Ｔ１＋Ｔ２＋Ｔ３はラウンドトリップタイム（ＲＴＴ）に相当することに留意されたい。
【数８】
【００６９】
ＲＴＴは、一般には、ＲＴＣＰレポート間隔よりも小さい。そうでない場合、受信者は最初にパケットの再送信を待機することなくフィードバックを送信するため、レポーティングは過剰になる。さらに、ＲＴＴにフィードバック処理時間を加えた合計は、一般には同様にＲＴＣＰレポート間隔より小さい。なぜなら、サーバは、通常、定義されている再送信帯域幅を保証しなくてはならず、したがってこの時間は大幅には増大しないからである。
【００７０】
提供することのできるレポーティング冗長度に影響を与える、ＲＴＰセッションの別の重要な「変数」は、上述したクライアントバッファリング時間である。このクライアントバッファリング時間は、一般的には、データパケットがユーザに「出力」されるまで受信者のメモリにバッファリングされている時間期間として定義することができる。例えば、映像ストリーミングセッションの場合、クライアントバッファリング時間は、データパケットの内容がユーザに表示されるまでそのデータパケットが受信者のメモリ（バッファ）に格納されている時間期間として理解することができる。
【００７１】
パケットがユーザに提供されるまでにＲＴＰセッション内で提供できる再送信回数は、次のように表すことができる。
【数９】
【００７２】
「Ｉｎｔｅｇｅｒ（）」関数は、除算の結果から整数値を取り出す。（アップリンク送信の）ＲＴＣＰレポート間隔は、次のように定義される。
【数１０】
この式において、
【数１１】
【００７３】
この等式において、現在のＲＴＣＰパケットサイズ（current RTCP packet size）は、送信される次のＲＴＣＰフィードバックのサイズに等しい。
【００７４】
上の計算の１つの単純化として、Ｔ２の定義において、バースト的ではない、すなわちパケットのシングルトン消失のみを考慮することができ、すなわち次式となる。
【数１２】
【００７５】
クライアントにおいてＴ１＋Ｔ２＋Ｔ３＋Ｔ４が必ず計算可能であるとは限らないので、この合計に使用することのできる控えめな近似として、図３に示した近似を使用することができる（模範例を目的として最小再送信回数は３とする）。例えば、ＲＴＣＰレポート間隔の値は、この合計のおおまかな推定値を表すことができ、控えめなバッファリング時間（ｃｌｉｅｎｔ＿ｂｕｆｆｅｒｉｎｇ＿ｔｉｍｅ’）は、次のように定義することができる。
【数１３】
【００７６】
控えめなクライアントバッファリング時間（ｃｌｉｅｎｔ＿ｂｕｆｆｅｒｉｎｇ＿ｔｉｍｅ’）は、要求される最小再送信回数（ｍｉｎ＿ｎｏ＿ｒｔｘｓ）を確保するためのバッファリング時間として理解することもできる。このことは、当然ながら、値Ｔ１＋Ｔ２＋Ｔ３＋Ｔ４がＲＴＣＰレポート間隔よりも小さいときにのみ当てはまる。値Ｔ１＋Ｔ２＋Ｔ３＋Ｔ４は、一般にはＲＴＣＰレポート間隔よりも小さく、なぜなら、そうでない場合、クライアントは生じうる再送信を待機せずにフィードバックを送信することになるからである。このことは、サーバによって、あるいはＳＤＰまたは類似するプロトコルを使用してセッション記述情報を設定する責務を負うコンテンツ作成者によって確保されるものとする。
【００７７】
本発明の１つの実施形態によると、可能な再送信回数の計算（等式９を参照）は、次のように単純化することができる。
【数１４】
【００７８】
当然ながら、より正確である等式９の計算を使用することもできる。しかしながら、等式１３は、より容易に実施することができる。ＰＳＳストリーミングサービスの初期段階において、クライアントは、特定のサーバから提供されるセッションの詳細に関する記述を要求する。サーバは、この要求に応答して、セッション記述を送信する。特に、以下のパラメータがセッション記述によってクライアントに知らされる。
【００７９】
・ メディアセッションに使用されるコーデックのＭＩＭＥタイプ（例えば、Ｈ２６３、ＡＭＲ、ＭＰＥＧ４など）
・ 受信者レポートのためのＲＴＣＰ帯域幅割当て（ｃｌｉｅｎｔ＿ｒｔｃｐ＿ｂａｎｄｗｉｄｔｈ）（ビット／秒）。ＰＳＳ仕様が対象としているアプリケーションなどのユニキャストストリーミングアプリケーションの場合の帯域幅割当ての初期値は、送信者および受信者のそれぞれについて、合計ＲＴＣＰ帯域幅の５０％である。それ以外の値は、RFC 3556の規定を使用して明示的に指定することができる。合計ＲＴＣＰ帯域幅は、一般にはセッション総帯域幅の５％である。
・ コーデックを記述する任意のＭＩＭＥタイプパラメータ。これらのパラメータは、パケットレート（１秒あたりのパケット数）などストリームのその他の値を計算するのに使用することができる。
・ クライアントが使用することのできる任意のＲＴＣＰパケットの最大サイズ。現在、ＰＳＳフレームワークの中でサーバの（ＲＴＣＰではなく）ＲＴＰパケットのサイズを制限することが可能である。将来的には、ＲＴＣＰレポートパケットについて同様の制限が可能である。
【００８０】
さらに、本発明の実施形態によると、以下の追加のパラメータがクライアントに知らされる。
【００８１】
・ サーバによって推奨される最小再送信回数（ｍｉｎ＿ｎｏ＿ｒｔｘｓ）。サーバは、クライアントが各パケットに対して最小回数の再送信を保証することを提案することができる。この理由は、例えば、サービスプロバイダがリンク上のパケット消失を認識しているからである。上述したように、ＰＳＳストリーミングサービスにおける再送信は、フィードバックにおける一般ＮＡＣＫレポートブロックによってトリガする必要がある。
・ （同じく）サーバによって推奨されるレポーティング冗長度（ｒｅｐｏｒｔ＿ｒｅｄｕｎｄａｎｃｙ）。この数値は、消失ＲＬＥレポートブロックを使用してパケットをレポートする回数を示す。サービスプロバイダにとっては、達成されているリンクのパフォーマンス（どのパケットが受信された、または受信されていないか）と、パケットをクライアントに提供するのに最大で何回の再送信が必要であるかとを知ることは重要である。このことは、個々に知覚されるサービス品質に対してのみクライアントに課金を行ううえでも重要である。
・ クライアントバッファリング時間（ｃｌｉｅｎｔ＿ｂｕｆｆｅｒｉｎｇ＿ｔｉｍｅ）（単位：秒）。これは、あとの段落に説明するようにセッションパラメータから導くことができる。
【００８２】
クライアントバッファリング時間を考慮するとき、以下の２つの可能なシナリオがある。
【００８３】
第１の可能なシナリオは、３ＧＰＰ ＰＳＳフレームワークに定義されているビットレートの適合化をクライアントがサポートしない場合である。
【００８４】
この場合、クライアントバッファリング時間は、初期バッファリング時間、すなわち、セッション開始後にクライアントがバッファのパケットの読み出しを開始するまでの時間、に等しい値に選択することができる。
【００８５】
第２の可能なシナリオは、３ＧＰＰ ＰＳＳフレームワークに定義されているビットレートの適合化をクライアントがサポートする場合である。この場合、クライアントは以下のパラメータを使用することができる。
【００８６】
・ バッファサイズ（ｂｕｆｆｅｒ＿ｓｉｚｅ）。これは、「３ＧＰＰ適合化」ヘッダにおいて伝えられる。このパラメータは、ＲＴＰヘッダを含む完全なＲＴＰパケット用にこの特定のスペース量を持つ受信バッファおよびデジッタ処理バッファ（reception and de-jittering buffer）と一致している必要がある。指定されるバッファサイズには、そのメディアに使用される予備復号器のバッファ空間を含めることもできる。したがって、このパラメータは、セッションの任意の瞬間にクライアントが利用できるセッションデータ（ＲＴＰパケット）の最大サイズに対応する。一般には、このパラメータはクライアントバッファリング時間の値を決定する目的には使用されない。
・ 目標保護時間（ｔａｒｇｅｔ＿ｐｒｏｔｅｃｔｉｏｎ＿ｔｉｍｅ）。これは、「３ＧＰＰ適合化」ヘッダ（「目標時間」パラメータ）においてクライアントに伝えられる。このパラメータは、目標の最小バッファレベル、言い換えれば、中断のない再生が保証され、かつ必要な場合にサーバが送信速度を調整することのできる、クライアントにおける望ましい再生時間長（単位：ミリ秒）を表す。本発明の１つの実施形態によると、このパラメータはクライアントバッファリング時間（ｃｌｉｅｎｔ＿ｂｕｆｆｅｒｉｎｇ＿ｔｉｍｅ）として使用される。
【００８７】
クライアントは、一旦セッション記述情報を受信すると、伝えられたＲＴＣＰ帯域幅割当て（ｃｌｉｅｎｔ＿ｒｔｃｐ＿ｂａｎｄｗｉｄｔｈ）と、そのメディアストリームを対象とするクライアントバッファリング時間（ｃｌｉｅｎｔ＿ｂｕｆｆｅｒｉｎｇ＿ｔｉｍｅ）とが、パケット消失に関するレポーティングが可能であるように選択されているか否かを判断することができる。さらに、クライアントは、そのＲＴＣＰ帯域幅割当ておよびクライアントバッファリング時間において、パラメータｒｅｐｏｒｔ＿ｒｅｄｕｎｄａｎｃｙによって指定されている望ましいレポート冗長度と、パラメータｍｉｎ＿ｎｏ＿ｒｔｘｓによって指定されている要求される最小回数の再送信とを提供することができるか否かを、さらに判断することができる。
【００８８】
なお、レポーティング冗長度は、サービス提供ネットワークの監視、課金などの課題（消失ＲＬＥレポートブロック）に関連するのに対し、提供される最小回数の再送信は、先に概説したように一般ＮＡＣＫのフィードバックに基づいていることに留意されたい。
【００８９】
１つの実施形態によると、クライアントのバッファによって各パケットに対するタイマがｃｌｉｅｎｔ＿ｂｕｆｆｅｒｉｎｇ＿ｔｉｍｅ秒に設定されていると仮定する。パケットがこの時間期間内に受信されない場合、タイマが切れて、そのパケットに対してもはや再送信を要求することができない（すなわち、さらなる一般ＮＡＣＫメッセージに含めることができない）。
【００９０】
さらに、過去のＲＴＣＰレポート（以前に送信された一般ＮＡＣＫレポートブロックおよび消失ＲＬＥレポートブロックが含まれている）がクライアントにおける送信バッファに保存されることを仮定することもできる。このバッファのサイズは、例えば、サーババッファリング時間（ｓｅｒｖｅｒ＿ｂｕｆｆｅｒｉｎｇ＿ｔｉｍｅ）（単位：秒）に一致する値に設定することができる。さらに、このバッファは、後から説明する方法によって必要とされるように、送信された必要なＲＴＣＰパケットを格納するのに十分な大きさである必要がある。
【００９１】
以下の段落では、本発明の実施形態による好ましいアルゴリズムについて説明する。このアルゴリズムは、RFC 3550のAnnex Aに記載されている標準ＲＴＰアルゴリズムと補完的な関係にある。標準ＲＴＰアルゴリズムとは対照的に、このアルゴリズムによる発明によれば、パラメータｍｉｎ＿ｎｏ＿ｒｔｘｓおよびパラメータｒｅｐｏｒｔ＿ｒｅｄｕｎｄａｎｃｙを考慮して、ＰＳＳに従ったセッションを設定することができる。このアルゴリズムは、以下を達成するうえで必要である一般ＮＡＣＫレポートおよび消失ＲＬＥレポートのサイズをクライアントが求めるときに有用である。
【００９２】
・ すべての各パケットに対して最大回数のパケット再送信を可能にし、またはクライアントバッファリング時間内での最小回数（ｍｉｎ＿ｎｏ＿ｒｔｘｓ）の再送信を実施し、
・ （可能な場合に）パラメータｒｅｐｏｒｔ＿ｒｅｄｕｎｄａｎｃｙによって設定されているレポート冗長度を提供し、
・ その一方で、受信者レポートのための与えられたＲＴＣＰ帯域幅と、クライアントのバッファリング能力とに従う。
【００９３】
以下の好ましいステップは、クライアントが、自身が送信するすべての各ＲＴＣＰ受信者レポートについて、最初のＲＴＣＰパケットから開始して実行することができる。
【００９４】
ステップ１：ＲＴＰ／ＡＶＰＦによる１秒の初期待機期間後、クライアントは、新しい一般ＮＡＣＫメッセージにおいてパケットの再送信を要求することができる。実施の観点からは、このステップは照合動作である。なぜなら、上述したＲｅｙらのインターネットドラフトに従って再送信を実行しているすべてのクライアントは、保留中の要求のリストを維持する必要があるからである。
【００９５】
模範的なリストは、２つの列、すなわち、連続番号ＳＮの列と、特定のＳＮを持つパケットが受信されたか受信されていないかを示すフラグ（例えば、「０」：受信されていない、「１」：受信された）の列とで構成することができる。このリスト中に存在する受信されていないパケットをＮＡＣＫに含める。なお、受信されていないパケットは、各パケットのクライアントバッファリング時間（ｃｌｉｅｎｔ＿ｂｕｆｆｅｒｉｎｇ＿ｔｉｍｅ）が経過した後に、このリストから削除する。
【００９６】
ステップ２：第２のステップは、与えられたＲＴＣＰ帯域幅（ｃｌｉｅｎｔ＿ｒｔｃｐ＿ｂａｎｄｗｉｄｔｈ）の場合における、一般ＮＡＣＫレポートブロックにレポートされるパケットの最大再送信回数（ｍａｘ＿ｎｏ＿ｒｔｘｓ）を計算することである。再送信が保留中であるパケットは、最小回数（ｍｉｎ＿ｎｏ＿ｒｔｘｓ）の再送信を実施するうえですべての各再送信パケットに含まれている必要のある最小の情報であるため、最大再送信回数は、控えめなクライアントバッファリング時間（ｃｌｉｅｎｔ＿ｂｕｆｆｅｒｉｎｇ＿ｔｉｍｅ’）をＲＴＣＰレポート間隔（ＲＴＣＰ＿ｒｅｐｏｒｔ＿ｉｎｔｅｒｖａｌ）の現在の値で除することによって計算することができる。
【数１５】
【００９７】
この計算には、上の等式（１３）に提示した単純化が含まれていることに留意されたい。ＲＴＣＰレポート間隔パラメータｒｔｃｐ＿ｒｅｐｏｒｔ＿ｉｎｔｅｒｖａｌは、一般にはＲＴＰ基本アルゴリズムの一部として各ＲＴＰクライアントおよびサーバによって維持される。
【００９８】
平均ＲＴＣＰパケットサイズ（ａｖｇ＿ｒｔｃｐ＿ｐａｃｋｅｔ＿ｓｉｚｅＮＡＣＫ）は、次のように計算することができる（上の等式１１も参照）。
【数１６】
【００９９】
現在のＲＴＣＰパケットサイズ（単位：バイト）、すなわち一般ＮＡＣＫレポートブロックを含んでいる（しかし消失ＲＬＥレポートブロックは含んでいない）ときの次のフィードバックメッセージのパケットサイズは、次のように計算することができる。
【数１７】
この式において、ｓｔｅｐ（）は、パラメータとしてｎおよび定数１７をとる数学ステップ関数である。１７は、１つの一般ＮＡＣＫレポートブロックにおいて要求することのできるパケット数である。当然ながら、１７を超える／１７未満のパケットを１つの一般ＮＡＣＫレポートブロックによって要求できる場合には、ステップ関数のパラメータとして１７以外の別の定数を選択することが可能である。いくつかのｎの値に対しては次のようになる。
【数１８】
Ｋは、少なくとも１つの一般ＮＡＣＫメッセージを有するＲＴＣＰ受信者メッセージを含んでいるＩＰパケットにおける固定フィールドを考慮する定数である。
【０１００】
例えば、パケットの構成が、３２バイトの１つの受信者レポート（ＲＲ）と、１２バイトの１つのＳＤＥＳアイテム（ＣＮＡＭＥを持つ）とを有し、暗号化ヘッダあるいはプロファイルに固有な拡張部が存在しないという標準的な構成である場合、固定フィールドは、ＩＰヘッダ＋ＵＤＰヘッダ＋ＲＴＣＰヘッダ＋１ＲＲ＋１ＳＤＥＳアイテム（ＣＮＡＭＥ）＋ＮＡＣＫ固定フィールド、すなわち、２０＋８＋８＋２４＋１２＋１２＝８４バイトとなる。
【０１０１】
パケットに、電話番号や電子メールのような、プロファイルに固有の拡張部またはその他のＳＤＥＳアイテム、もしくはＢＹＥパケットやアプリケーションに固有のパケット（ＡＰＰ）のような、その他のＲＴＣＰレポートブロックが含まれている場合、それらの固定フィールドをこの定数Ｋに追加しなければならない。同じことは、後述するＫ’にも当てはまる。
【０１０２】
計算された最大再送信回数（ｍａｘ＿ｎｏ＿ｒｔｘｓ）（等式１４）が１より大きい（＞１）場合、そのことは、消失パケットが後からの１回以上の再送信において受信される可能性があることを意味する。
【０１０３】
一般には、クライアントは、最小再送信回数（ｍｉｎ＿ｎｏ＿ｒｔｘｓ）に従うことが要求される。これが不可能である場合、すなわちｍａｘ＿ｎｏ＿ｒｔｘｓ＜ｍｉｎ＿ｎｏ＿ｒｔｘｓである場合、ＲＴＣＰ帯域幅割当てとクライアントバッファリング時間とによって決まる制約内では、要求される最小回数のパケット再送信を提供することが不可能であるので、クライアントは、より少ない再送信回数で続行するか、あるいはセッションを再起動して別の設定（例えば、より高いＲＴＣＰ帯域、ｍｉｎ＿ｎｏ＿ｒｔｘｓがより小さくなるようにさらに良好に保護されたストリームなどを選択することによる、要求されるバッファリング時間がより少ないコーデック設定）を選択することを決定することができる。
【０１０４】
言い換えれば、上の計算を満たすことのできる、クライアントによって要求される最小再送信回数が存在する場合、最大パケットサイズ（後から説明する）に達するまでフィードバックにデータを追加することが可能である。存在しない場合、ＲＴＣＰパケットが大きすぎ、必要な回数だけ再送信を要求することができない。
【０１０５】
ｍｉｎ＿ｎｏ＿ｒｔｘｓ回のパケット再送信を要求することのできる、ＲＴＣＰパケットの最大サイズ（ｍａｘ＿ｒｔｃｐ＿ｐａｃｋｅｔ＿ｓｉｚｅ）は、次のように計算することができる。
【数１９】
【０１０６】
後者のパラメータは常に１より大きいので、等式１７は、ｍｉｎ＿ｎｏ＿ｒｔｘｓのすべての値それぞれに対して定義されることに留意されたい。そうでない場合、上述したインターネットラフトにおいてＲｅｙらによって提案されている再送信を使用する意味がなくなる。
【０１０７】
ステップ３：クライアントがｍｉｎ＿ｎｏ＿ｒｔｘｓを実施することができると仮定し、かつ、ｍａｘ＿ｎｏ＿ｒｔｘｓ＞ｍｉｎ＿ｎｏ＿ｒｔｘｓであると仮定すると、次のステップは、等式１７を使用して計算されるｍａｘ＿ｒｔｃｐ＿ｐａｃｋｅｔ＿ｓｉｚｅに達するまで、（再送信を要求する一般ＮＡＣＫに加えて）消失ＲＬＥレポートブロックをフィードバックメッセージに含めることである。言い換えれば、ｍａｘ＿ｒｔｃｐ＿ｐａｃｋｅｔ＿ｓｉｚｅとｃｕｒｒｅｎｔ＿ｒｔｃｐ＿ｐａｃｋｅｔ＿ｓｉｚｅＮＡＣＫとの間の差は、最小再送信回数ｍｉｎ＿ｎｏ＿ｒｔｘｓの要件に違反することなく現在のＲＴＣＰパケットに追加することのできるデータ量に等しい。
【数２０】
【０１０８】
さきの場合（等式１６を参照）に似て、ＲＴＣＰのＩＰヘッダおよびＵＤＰヘッダと、一般ＮＡＣＫメッセージおよび消失ＲＬＥレポートとを含めたＲＴＣＰパケットサイズをｎの関数として計算するための一般式は、次のとおりである。
【数２１】
この式において、ｓｔｅｐ’（）はさきと同じであり、ｓｔｅｐ（）は、パラメータとしてｎおよび定数３０をとる数学ステップ関数である。なお、等式１９においては、フィードバックには少なくとも１つの消失ＲＬＥレポートブロックが含まれていることを仮定しており、含まれていない場合、等式１６を使用して現在のＲＴＣＰパケットサイズを計算できる。パラメータ３０は、１つの消失ＲＬＥレポートブロックにおいてレポートすることのできるパケットの数である。当然ながら、３０を超える／３０未満のパケットを１つのＲＬＥレポートブロックによってレポートできる場合には、ステップ関数のパラメータとして３０以外の別の定数を選択することが可能である。いくつかのｎ’記号の値に対しては次のようになる。
【数２２】
【０１０９】
なお、ｎおよびｎ’は、段階的に増加することに留意されたい。この理由は、ＲＴＣＰレポートが３２ビットに揃えられており、レポートするパケットの数が１７または３０の倍数を超えると４バイトワード全体が追加されるからである。
【０１１０】
等式１９においては、Ｋ’は、上の等式１６の場合に定義されているＫよりも大きい６バイトである。なぜなら、次に送られる（現在の）ＲＴＣＰフィードバックメッセージには（少なくとも）１つの消失ＲＬＥレポートブロックが含まれているからである。
【０１１１】
クライアントが、与えられたｒｅｐｏｒｔ＿ｒｅｄｕｎｄａｎｃｙの値に従うことが要求される場合、クライアントは、その値によって定義されるとおりに過去の消失ＲＬＥレポートブロックを含めることができる。例えば、ｒｅｄｕｎｄａｎｃｙ＿ｖａｌｕｅが２である場合、同一の消失ＲＬＥレポートブロックが２つの連続するＲＴＣＰレポートにおいて送られることを意味する。この値が３である場合は、同一の消失ＲＬＥレポートブロックが３つの連続するＲＴＣＰパケットに存在し、以下同様である。言い換えれば、レポーティング冗長度が２に設定されている場合、１つのＲＴＣＰレポート（すなわちその中のＲＬＥレポートブロック）は、過去の２つのＲＴＣＰレポート間隔についてレポートする必要があり、レポーティング冗長度が３に設定されている場合、過去の３つのＲＴＣＰレポート間隔についてレポートする必要があり、以下同様である。このことにより、クライアントには、有効期間が終了しているパケットを含めて、受信したパケットおよび受信していないパケットのリスト（例えば２列の配列）を維持することが要求される。このリストは、有効期間がまだ終了していないパケットのみが含まれているクライアントバッファの内容とは異なる。
【０１１２】
ステップ４：必要なレポーティング冗長度を提供するために、次のＲＴＣＰフィードバックメッセージに（１つ以上の一般ＮＡＣＫレポートブロックに加えて）追加しなければならない必要な数の消失ＲＬＥレポートブロックを含めると、許容される最大ＲＴＣＰパケットサイズ（ｍａｘ＿ｒｔｃｐ＿ｐａｃｋｅｔ＿ｓｉｚｅ）を超えるということも起こりうる。この場合、クライアントは、ランレングス符号化によって、１つ以上の消失ＲＬＥレポートブロックのサイズを減少させることを試みることができる。パケットサイズを減少させるためのさらなるオプションとして、上述したシニングなどの別の方法も使用することができる。しかしながら、シニングの使用を考慮すると、レポーティング冗長度が減少する。
【０１１３】
これらのメカニズムによっても、必要なレポーティング冗長度が保証されるだけＲＬＥレポートブロックのサイズを十分に減少させることができない場合、クライアントは、そのｒｅｐｏｒｔ＿ｒｅｄｕｎｄａｎｃｙ値に従わないことを決定し、送信を続行することができる。これに代えて、クライアントは、セッションを再起動して、より大きなクライアントバッファリング時間、またはより低いビットレートのコーデック設定を選択することができる。
【０１１４】
ステップ５：最後に、ａｖｇ＿ｒｔｃｐ＿ｐａｃｋｅｔｓｉｚｅおよびｒｔｃｐ＿ｒｅｐｏｒｔ＿ｉｎｔｅｒｖａｌのような、RFC 3550、Annex Aによる標準的なアルゴリズムにおける残りの変数更新および標準処理を、以下の標準的な方法で計算する。
【数２３】
【０１１５】
ＲＴＣＰパケットを送るたびに、ステップ１〜ステップ５を繰り返すことができる。これに代えて、クライアントは、クライアントの能力が変化したときにのみ、特に、クライアントバッファリング時間またはクライアントのＲＴＣＰ帯域幅の変化が起きたときにのみ、これらのステップを繰り返すことを選択することもできる。
【０１１６】
フィードバックメッセージを送った後、クライアントは、RFC 3550に概略的に指定されている規定に従って、セッションのさまざまなパラメータを更新することができる。例えば、クライアントは、平均ＲＴＣＰパケットサイズを再計算し、その結果としてのＲＴＣＰレポート間隔を再計算し、送信バッファの内容を更新し、送信する次のＲＴＣＰフィードバックの計算を開始することができる。
【０１１７】
別の実施形態においては、クライアントがｒｅｐｏｒｔ＿ｒｅｄｕｎｄａｎｃｙを減少させることによって、消失ＲＬＥレポートブロックのサイズをさらに減少させることができる。しかしながら、この状況においては、クライアントが冗長レポーティングの妥当なレベルを依然として得られるかという疑問が生じる。
【０１１８】
レポーティング冗長度を減少させることは、リンク上のパケット消失率を測定することのできる実施形態において可能である。パケット消失率は、例えば、送信者からのＲＴＣＰレポートから推定することができる。これに代えて、またはこれに加えて、クライアントは、リンク確立処理からのリンクのＱｏＳに関する先験的な情報を保持することができる。したがって、クライアントへの特定のリンク上のパケット消失率が低い／高いときには、冗長レポーティングのレベルをさらに減少させる／高めることができる。なぜなら、信頼性の低い伝送プロトコルを使用しているとき、パケット消失率が低い／高いほど、クライアントのフィードバックが送信者において受信される可能性が高い／低いからである。
【０１１９】
Ｆｒｉｅｄｍａｎらのインターネットドラフトに指定されている方法以外の、消失ＲＬＥレポートブロックのサイズを減少させる別の方法は、例えば、個々のパケットの重要度の推定に基づくことができる。例えば、ＭＰＥＧ−４などの漸進的な（progressive）符号化手法においては、パケットはさまざまな優先度を持つ。したがって、重要度の低いパケット、すなわちＰフレームは、レポーティングからドロップすることができる。
【０１２０】
これに代えて、またはこれに加えて、消失ＲＬＥレポートブロックのサイズを減少させる目的で、現在のアプリケーションレベルのＱｏＳおよびリンクレベルのＱｏＳを考慮することができる。例えば、現在のアプリケーションレベルのＱｏＳが十分に高く、および／またはリンクレベルのＱｏＳが低い（すなわちリンクが輻輳状態）場合、クライアントは、一部の消失パケットについてのレポーティングをドロップすることを決定することができる。例えば、ＭＰＥＧ４コーデックでは、高度なパケット消失復元方策が実施される。場合によって、およびストリームのコンテンツによっては、リンク上でいくつかのパケットが消失しても、その消失によってピクチャの品質が影響されないということがありうる。具体的には、Ｂフレームが消失した場合、その影響は最小であり、パケットを再送信するコストの方が大きく、したがって、アプリケーションはそのパケットをドロップすることを決定することができる。
【０１２１】
本発明は、３ＧＰＰ ＰＳＳユニキャストストリーミングサービスにおいて以下の利点を有する。第一に、本発明は、一般ＮＡＣＫレポートブロックおよびＲＬＥレポートブロックを使用してＲＴＣＰ受信者レポートを構築する、ストリーミングサーバおよびクライアントのための追加のメカニズムを、３ＧＰＰ ＰＳＳフレームワークに提供する。クライアントがｃｌｉｅｎｔ＿ｂｕｆｆｅｒｉｎｇ＿ｔｉｍｅおよびｃｌｉｅｎｔ＿ｒｔｃｐ＿ｂａｎｄｗｉｄｔｈを認識していると仮定したとき、本方法では、最小再送信回数（ｍｉｎ＿ｎｏ＿ｒｔｘｓ）と、特定のレポート冗長度と、レポートの必要な送信頻度と、レポートがカバーすべきパケット数とを提供するためのレポートのサイズを指定することが可能である。
【０１２２】
上述したように、レポート冗長度は、特に、再送信のパフォーマンスに関して、すなわち、パケットがクライアントによって（正常に）受信されるまで何回再送信されるかに関して、課金アプリケーションおよびネットワークの監視にとって重要である。
【０１２３】
さらに、本発明は、最も単純なクライアントから、豊富な機能を備えたクライアントまでを、クライアント側において利用可能な情報と、消失ＲＬＥレポートの必要な圧縮効率とに応じて確立することができるように、幅広いクライアントの設定を指定するためのフレームワークを定義する。さらに、本発明のいくつかの実施形態は、ＲＴＣＰフィードバックのサイズを減少させるための追加の方法を提供する。
【０１２４】
次に、本発明のより具体的かつ好ましいさまざまな実施形態について、図４、図５および図６を参照しながら説明する。
【０１２５】
図４は、本発明の実施形態による、ストリーミングセッション内でＲＴＣＰフィードバックを提供する方法の最初のステップ群を示している。現在のＲＴＣＰレポート間隔が終了した時点で、クライアントは、次のＲＴＣＰフィードバックをサーバに送る準備を行う。最初に（ステップ４０１〜４０４）、クライアントは、設定されているセッションパラメータが、要求される最小回数（ｍｉｎ＿ｎｏ＿ｒｔｘｓ）の再送信をすることができるものであるか否かを判断することができる。この目的のために、クライアントは、現在のＲＴＣＰパケット（次に送るＲＴＣＰパケット）に、セッションに対して設計されている最小再送信回数を確保するのに必要な１つ以上の一般ＮＡＣＫレポートブロックのみが含まれていると仮定して、このパケットのサイズを決定することができる（４０１）。前述したように（等式１６を参照）、現在のＲＴＣＰパケットのサイズは、レポートするパケットの数に依存する。
【０１２６】
その計算値（ｃｕｒｒｅｎｔ＿ｒｔｃｐ＿ｐａｃｋｅｔ＿ｓｉｚｅＮＡＣＫ）と、以前のＲＴＣＰフィードバックメッセージの平均サイズ（ｓｅｎｔ＿ｒｔｃｐ＿ｐａｃｋｅｔ＿ｓｉｚｅ）とに基づいて、平均ＲＴＣＰパケットサイズ（ａｖｇ＿ｒｔｃｐ＿ｐａｃｋｅｔ＿ｓｉｚｅＮＡＣＫ）を、上の等式１５を使用して決定することができる（４０２）。次いで、クライアントバッファリング時間内で可能である最大再送信回数（ｍａｘ＿ｎｏ＿ｒｔｘｓ）を計算する（４０３）（等式１４を参照）。
【０１２７】
これらの計算に基づいて、クライアントは、ステップ４０４において、要求される最小回数（ｍｉｎ＿ｎｏ＿ｒｔｘｓ）の再送信が可能であるか否かを判断することができる。可能ではない場合、クライアントは、上述したようにセッションパラメータの別の設定を用いてセッションを再設定し、または再起動することができる（４０５）。
【０１２８】
ｍａｘ＿ｎｏ＿ｒｔｘ＞ｍｉｎ＿ｎｏ＿ｒｔｘｓである場合、セッションパラメータであるクライアントバッファリング時間と、ＲＴＣＰ帯域幅割当てと、最小再送信回数とは、クライアントがこれらの制約パラメータの中で動作できるように選択されている。したがって、クライアントは、次のステップ４０６において、最小回数の再送信を提供するのに必要な１つ以上の一般ＮＡＣＫレポートブロックを、現在のフィードバックメッセージに追加することができる。そのセッションにおいて消失ＲＬＥレポートブロックによる（追加の）レポーティングが必要ない場合には（ステップ４０７を参照）、クライアントは、１つ以上の一般ＮＡＣＫレポートブロックのみが含まれている現在のフィードバックメッセージをサーバに送信するステップ（４０８）に進むことができる。
【０１２９】
パケット消失に関する（冗長な）レポーティングがセッションに要求される場合、クライアントは、次いで、最小回数の再送信を確保するための１つ以上の一般ＮＡＣＫレポートブロックのみならず、パケット消失に関する冗長なレポーティングを確保するのに必要なＲ個の消失ＲＬＥレポートブロックをさらに含めるための十分な容量が、現在のフィードバックメッセージにあるか否かを判断することができる。
【０１３０】
この目的のために、クライアントは、次いでステップ４０９において、最小回数の再送信を提供することのできるＲＴＣＰフィードバックメッセージの最大サイズを決定することができる（等式１７を参照）。上述したように、最大ＲＴＣＰパケットサイズ（ｍａｘ＿ｒｔｃｐ＿ｐａｃｋｅｔ＿ｓｉｚｅ）は、最小回数の再送信が確保されている状態でフィードバックを提供することのできる平均メッセージサイズを示す１つの測度である。
【０１３１】
ｍａｘ＿ｎｏ＿ｒｔｘ＞ｍｉｎ＿ｎｏ＿ｒｔｘｓであることが分かっているので（ステップ４０４を参照）、最大ＲＴＣＰパケットサイズが、１つ以上の一般ＮＡＣＫレポートブロックが含まれている平均ＲＴＣＰパケットサイズ以上であることも明らかである。
【０１３２】
ステップ４１０において、クライアントは、現在のＲＴＣＰパケットに残されているペイロード残量を決定する。言い換えれば、クライアントは、１つ以上の一般ＮＡＣＫレポートブロックがすでに含まれている現在のＲＴＣＰパケットに、ＲＴＣＰフィードバックの最大許容（平均）サイズに違反することなく、さらに何バイト（ｐａｙｌｏａｄ＿ｍａｒｇｉｎ）を追加できるかを決定する。
【０１３３】
図５および図６に示した、フローチャートにおける以降のステップ群は、全体として、現在のＲＴＣＰフィードバックメッセージ内の残りの空間（ｐａｙｌｏａｄ＿ｍａｒｇｉｎ）に、可能であれば１つ以上の消失ＲＬＥレポートブロックを含めて（最小の）冗長レポーティングを確保する方法を示す例として理解されたい。後からさらに詳しく説明するように、場合によっては、消失パケットに関する最小回数の冗長レポートを有効にすることができないことがある。しかしながら、その状況においては、レポーティングをまったく行わないのではなく、少なくともある程度の（冗長な）レポーティングを提供することが望ましい。
【０１３４】
次のステップ５０１においては（図５）、クライアントは、要求される最小レポーティング冗長度を有効にするために必要であるＲ個の消失ＲＬＥレポートブロックを構築することができる。消失ＲＬＥレポートブロックのサイズはペイロード残量に含めるには大きすぎることがあるので、クライアントは、ステップ５０２に示したように消失ＲＬＥレポートブロックのランレングス圧縮を実行することができる。なお、このステップは省略することができる。次いで、ステップ５０３において、Ｒ個の（圧縮された）消失ＲＬＥレポートブロックのサイズを決定し、ステップ５０４において、その値をペイロード残量と比較し、要求される最小回数の再送信を有効にすることのできる最大許容（平均）ＲＴＣＰパケットサイズに違反することなく、Ｒ個すべての消失ＲＬＥレポートブロックが現在のＲＴＣＰフィードバックメッセージに収まるか否かを判断する。
【０１３５】
収まる場合、これらのＲ個の（圧縮された）消失ＲＬＥレポートブロックをフィードバックメッセージに追加し（５０５）、クライアントは、複数の一般ＮＡＣＫレポートブロックと複数（Ｒ個）の消失ＲＬＥレポートブロックとが含まれているＲＴＣＰフィードバックメッセージを送信する（５０６）。この場合、クライアントは、最小回数の再送信が有効であり、かつ、最小レポーティング冗長度も提供できる状況を確保することができる。
【０１３６】
しかしながら、ステップ５０４において、Ｒ個の（圧縮された）消失ＲＬＥレポートブロックのサイズがペイロード残量よりも大きい場合、クライアントは、消失パケットに関する少なくともある程度の（冗長）レポーティングを提供することを試みることができる。この目的のために、クライアントは、さらにステップ５０７に進み、現在のフィードバックに含める消失ＲＬＥレポートブロックの数を減少させていき、残りの数の（圧縮された）消失ＲＬＥレポートブロックが現在のＲＴＣＰフィードバックメッセージのペイロード残量に収まるようにすることができる（５０９）。例えば、クライアントは、「最も古い」パケットに関してレポートしているレポートブロックを連続的にドロップすることができる（ステップ５０７、５０８、５０９、５１１を参照）。なぜなら、「最も古い」パケットについては以前のレポートにおいてすでにレポートされている可能性があるからである。もう１つの可能な方法は、消失ＲＬＥレポートブロックのサイズがペイロード残量より小さくなるまでシニングを実行することである。さらには、クライアントは、上述したように、レポートされるパケットの重要度を考慮することもできる。別の代替方法は、これらのメカニズムを必要に応じて組み合わせることである。
【０１３７】
これに関して、図６は、本発明の別の実施形態による、ＲＴＣＰフィードバックメッセージを構築するさらなるステップ群を示している。以下の説明においては、図５におけるステップに類似するステップは同じ参照数字で表してあり、簡潔にするためその説明は省略した。
【０１３８】
図６に示したステップ群においては、シニングおよびその他のメカニズムを組み合わせて、消失ＲＬＥレポートブロックのサイズを減少させることができる。重要な点として、シニング（ステップ６０３を参照）を適用するか否かの決定は、クライアントへのダウンリンクにおいて現在利用可能であるサービス品質（ＱｏＳ）に基づいて行うことができる（ステップ６０１および６０２を参照）。
【０１３９】
例えば、ＲＴＣＰフィードバックメッセージの送信者レポートブロックおよび／または受信者レポートブロックの中の「消失割合（fraction lost）」フィールドの計算値（RFC 3500、６．４節を参照）を評価し、それぞれ、アップリンクおよびダウンリンク上の現在のＱｏＳの指標とすることができる。これに代えて、モバイル通信システムからの明示的にネゴシエートされるＱｏＳ測定値を提供することもできる。例えば、アップリンク上の示されたＱｏＳが高い場合、このことは、信頼性の低い伝送プロトコルを使用して送信されたときにクライアントのＲＴＣＰフィードバックがおそらくは消失しないであろうことを意味しうる。したがって、クライアントは、サーバによって設定されているよりも低いレポーティング冗長度で十分であると判断することができる。この場合、クライアントは、消失ＲＬＥレポートブロックにシニングを適用することを決定することができる。したがって、ステップ６０５は、シニングが適用された場合にはクライアントが最小レポーティング冗長度をもはや保証しなくてもよいことを除いて、図５におけるステップ５に似ている。
【０１４０】
本発明の別の実施形態においては、クライアントは、利用可能なＱｏＳに基づいて最小再送信回数を減少させることを決定することさえできる。この場合、クライアントは、すべての一般ＮＡＣＫレポートブロックをフィードバックに含めるのではなく、図５のステップ５０７、５０８、５０９、および５１１に関して説明した方法に似た方法で、最近の新しいパケットに関してのみレポートすることを考慮することができる。
【０１４１】
本発明の別の実施形態は、本発明の上述したさまざまな実施形態の実施に関する。上述したさまざまな方法と、上述した図のさまざまな論理ブロックは、コンピューティングデバイス（プロセッサ）、例えば、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、またはその他のプログラマブルロジックデバイスなどを使用して実施する、または実行できることが認識される。本発明のさまざまな実施形態は、これらのデバイスの組合せによって実行する、または具体化することもできる。
【０１４２】
さらに、本発明のさまざまな実施形態、それらの変形形態、およびＱｏＳに基づくスケジューリング（QoS-aware scheduling）の解決策は、プロセッサによって実行される、またはハードウェアにおいて直接実行されるソフトウェアモジュールによって実装することもできる。また、ソフトウェアモジュールとハードウェア実装とを組み合わせることも可能である。ソフトウェアモジュールは、例えば、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤなどの任意の種類のコンピュータ可読ストレージメディアに格納することができる。
【図面の簡単な説明】
【０１４３】
【図１】本発明の実施形態によるストリーミング環境の概要を示す図
【図２】本発明の実施形態によるクライアントバッファリング時間と、ＲＴＣＰレポート周期と、再送信の目標レベルを提供するのに要する最小時間期間との間の関係を示す図
【図３】本発明の好ましい実施形態によるストリーミング環境における複数の連続的な再送信要求と再送信とを時系列で示す図
【図４】本発明の実施形態によるストリーミングセッション内でＲＴＣＰフィードバックを提供する方法の最初のステップ群を示す図
【図５】本発明の相異なる実施形態による、図４に示されるステップ群の後に実行されるＲＴＣＰフィードバックを提供する方法のさらなるステップ群を示す図
【図６】本発明の相異なる実施形態による、図４に示されるステップ群の後に実行されるＲＴＣＰフィードバックを提供する方法のさらなるステップ群を示す図
【技術分野】
【０００１】
本発明は、ＲＴＰプロトコルおよびＲＴＣＰプロトコルを使用して提供される少なくとも１つのストリーミングセッションのデータパケットに対するＲＴＣＰフィードバックメッセージを、クライアントからストリーミングサーバに提供する方法に関する。さらに、ストリーミングセッションの利用可能な帯域幅の一部であるＲＴＣＰ帯域幅が、このＲＴＣＰフィードバックメッセージに割り当てられる。その上、本発明は、モバイル通信システムにおける、本方法を実行するクライアントにさらに関する。
【背景技術】
【０００２】
３ＧＰＰ（3rd Generation Partnership Project）では、メディアを符号化するＡＭＲ（Adaptive Multi-Rate）やＨ．２６４（MPEG 4 part 10)などの伝送およびパケット交換コーデックに、ＲＴＰ、ＵＤＰ、ＩＰなどのＩＥＴＦ（Internet Engineering Task Force)標準プロトコルを採用している。３ＧＰＰパケット交換ストリーミングサービス（非特許文献１参照、http://www.3gpp.orgで入手可能）では、音声／映像／テキストメディアをストリーミングするためにＲＴＰ／ＵＤＰプロトコルスタックを使用している。
【０００３】
ＲＴＰは、主としてリアルタイム通信またはほぼリアルタイムの通信、すなわち遅延制約がゆるい通信に使用されているリアルタイムトランスポートプロトコル（非特許文献２参照、すべてのＲＦＣおよびインターネットドラフトはhttp://www.ietf.orgで入手可能）である。ＲＴＰでは、伝送するメディアのタイミングについての情報が提供され、受信者において順序入れ替え（re-ordering）および再構築を行うこともできる。
【０００４】
ＲＴＣＰ（Real Time Control Protocol）は、このプロトコルに統合されている部分であり、最小限の受信情報とゆるいグループメンバーシップとを提供する。ＲＴＰは、一般的には、ＲＴＰ／ＡＶＰプロファイル（非特許文献３参照）と組み合わせて使用され、ＲＴＰ／ＡＶＰプロファイルは、ＲＴＰヘッダフィールドの使用と、ペイロードタイプのマッピングテーブル、さらには単純なＲＴＣＰフィードバックタイミング規則を定義する。ＴＣＰ／ＩＰベースのトラフィックと公平に競合するように、ＲＴＣＰプロトコルには、利用可能なＲＴＰ帯域幅の一部が割り当てられる。
【０００５】
ＵＤＰ（非特許文献４）は、ＲＴＰパケットを伝送する目的に使用されるユーザデータグラムプロトコルである。ＵＤＰは、一般に、ストリーミングアプリケーションの場合など、メディアの通信の信頼性が低くてもよいときに使用される。プロトコルスタックＲＴＰ／ＵＤＰが使用される理由は、メディアのタイミング制約のために、例えばＴＣＰ（Transmission Control Protocol）の使用による信頼性の高い通信を行うことができないためである。
【０００６】
ＲＴＰでは、既存のメディア形式（コーデック）に対するパケット化方式（ペイロード形式）が、Internet Engineering Task Force Audio/Video Transport Working Group（IETF AVT WG)において指定されている。例えば、ＡＭＲ方式で符号化される音声データ用のペイロード形式と、Ｈ．２６４映像用の別の形式とが存在する。非特許文献５に定義されているＲＴＰペイロード形式では、このフレームワークにおいてＲＴＰパケットを再送信することもできる。このことは、３ＧＰＰ ＰＳＳストリーミングサービスに特に有用である。
【０００７】
非特許文献５に指定されているように、複数回の再送信を発行するメカニズムは、クライアントが必要なときにのみ要求を発行することに依存している。クライアントは、非特許文献６に指定されている可能なフィードバック方式を使用しなければならない。その他のレポーティングブロック、例えば、非特許文献７によって定義されているブロックも、使用することができる。
【０００８】
レポーティングの頻度は、RFC 3550における標準のＲＴＣＰレポート間隔計算法を使用して計算することができる（６．３節およびＡｎｎｅｘを参照）。受信者レポートの範囲、すなわち、レポートするパケットの数は、指定されていない。クライアントは、ＲＴＰ／ＡＶＰＦプロファイルに指定されている一般ＮＡＣＫ（Ｎｅｇａｔｉｖｅ ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ）フィードバックメッセージを使用する（draft-ietf-avt-rtcp-feedback-11.txtはhttp://www.ietf.org/internet-drafts/において取得できる）。なお、ＲＴＰ／ＡＶＰＦプロファイルにはＡＣＫメッセージに関して指定されていないため、クライアントはＲＴＰ／ＡＶＰＦプロファイルを使用してパケットに対して肯定応答することはできない。したがって、例えばＲＬＥレポートを使用することによる包括的なレポーティングは提供されない。
【０００９】
さらに、RFC 3611に定義されている消失ＲＬＥレポートは、圧縮可能な高度なレポーティングブロックであり、初期設定においてＡＣＫとＮＡＣＫとが組み合わされる、すなわち、消失パケットおよび受信パケットについてレポートすることができる。これらのレポートは、ネットワークの保守目的、課金、マルチキャストツリーインファレンス（multicast tree inference）、および統計情報の収集のために指定されたものである。
【００１０】
消失ＲＬＥレポートおよびユニキャストＲＴＣＰレポーティングに対処している３番目のドキュメントは、３ＧＰＰパケット交換ストリーミングサービス（ＰＳＳ）フレームワークである。このドキュメントによると、ストリーミングクライアントは消失ＲＬＥレポートブロックの使用を実装し、過去のＲＴＣＰ間隔について冗長にレポートすることが推奨されている。さらに、３ＧＰＰ ＰＳＳフレームワークによると、これらのレポートは再送信をトリガする目的には使用すべきでないことが記されている。
【００１１】
３ＧＰＰ ＰＳＳフレームワークのコンテキストにおける冗長なレポーティングとは、消失データパケットに関する最小回数のレポートを、それらの処理前、または処理後において有効にすることとして理解される。しかしながら、クライアントにおいてこのメカニズムをどのように実装すべきか、およびこのメカニズムをＲＴＰ再送信要求と一緒にどのように使用すべきかに関する指定はない。消失パケットに関する冗長なレポーティングが望ましいのは、フィードバック、すなわちＲＴＣＰメッセージが、一般には、ＵＤＰのような、肯定応答されず、従って信頼性の低い伝送プロトコルを使用して送信されるためである。したがって、特に、例えばＵＭＴＳのような無線アクセスネットワークを介したサービスの提供を考慮するときには、セッションの受信者によって提供されるフィードバックが消失することがある。
【００１２】
上述したように、ＰＳＳフレームワークでは、消失ＲＬＥレポートブロック（RFC 3611）は課金およびネットワークの監視のみを目的として使用することが要求されるのに対して、消失データパケットの再送信を実際にトリガする目的には一般ＮＡＣＫメッセージ（ＲＴＰ／ＡＶＰＦプロファイル）が使用される。したがって、ＰＳＳフレームワークでは、再送信をトリガできるようにすると同時に、（例えば）課金およびネットワークの監視を行うことができるようにするためには、伝送セッションのＲＴＣＰフィードバックには一般ＮＡＣＫレポートブロックおよび消失ＲＬＥレポートブロックが含まれていることが要求される。
【００１３】
Ｒｅｙらによって説明されている複数回再送信アルゴリズムでは、パケットの再送信をトリガする目的に、ＯｔｔらによるＲＴＰ／ＡＶＰＦドラフトに定義されているメッセージ形式、すなわち一般ＮＡＣＫを使用する（または使用することができる）。
【００１４】
３ＧＰＰ ＰＳＳフレームワークによって推奨されているように、受信されたパケットと受信されないパケットとの両方をレポートする場合、このことは、これらのレポートブロックが増大して相当なオーバーヘッドとなりうることを意味し、従って、ＲＴＣＰに割り当てられている予約帯域幅が不足して、継続的な送受信（play-out）および／または要求されるレポートの冗長度を保証するのに必要な時間長にわたりレポートすることができなくなることがある。さらに、再送信のトリガと平行して、課金およびネットワークの監視サービスを可能にするためには、ＰＳＳセッションを受信するクライアントのフィードバックに冗長なレポートブロック（消失ＲＬＥレポートブロック）を含める必要があり、このブロックもオーバーヘッドにつながり、レポーティングの頻度と、従って提供することのできる冗長レポーティングのレベルに影響する。
【非特許文献１】"Universal Mobile Telecommunications System (UMTS) ; Transparent end-to-end streaming service ; Protocols and codecs", 3GPP TS 26.234 version 6.1.0, September 2004
【非特許文献２】Schulzrinne et al., "RTP : A Transport Protocol for Real-Time Applications", RFC 3550, July 2003
【非特許文献３】Schulzrinne et al., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003
【非特許文献４】Postel, "User Datagram Protocol", RFC 768, August 1980
【非特許文献５】Rey et al., "RTP Retransmission Format", Internet Draft, IETF AVT Workgroup, August 2003
【非特許文献６】Ott et al., "Extended RTP Profile for RTCP-based FeedbacK （RTP/AVPF）", Internet Draft, IETF AVT Workgroup, August 2004
【非特許文献７】Friedman et al., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003
【発明の開示】
【００１５】
（発明の概要）
したがって、本発明の目的は、ユニキャストセッションにおけるＲＴＣＰフィードバックを最適化する方法を提供することである。
【００１６】
本発明のこの目的は、独立請求項の主題によって解決される。好ましい実施形態は、従属請求項の主題である。
【００１７】
本発明の１つの実施形態は、ＲＴＰプロトコルおよびＲＴＣＰプロトコルを使用して提供される少なくとも１つのストリーミングセッションのデータパケットに対するＲＴＣＰフィードバックメッセージを、クライアントからストリーミングサーバに提供する方法に関する。この方法によると、クライアントは、ストリーミングセッションのセッション制約内で提供することのできるデータパケットの最大再送信回数が、クライアントによって有効にされる最小再送信回数よりも大きいか否かを、最初に判断することができる。大きい場合、消失データパケットの再送信を要求する複数の一般ＮＡＣＫレポートブロックを、ＲＴＣＰフィードバックパケットに追加することができる。これらの追加された複数の一般ＮＡＣＫレポートブロックによって、クライアントバッファリング時間内での消失データパケットの再送信を最小回数にすることができる。次に、クライアントは、セッション制約を考慮したときに許容されるＲＴＣＰフィードバックメッセージの最大サイズを決定して、結果のＲＴＣＰフィードバックパケットのサイズがＲＴＣＰフィードバックメッセージの最大サイズを超えないように、消失データパケットに関してレポートする複数の消失ＲＬＥレポートブロックを、ＲＴＣＰフィードバックパケットに追加することができる。さらに、クライアントは、ＲＴＣＰフィードバックパケットを、ＲＴＣＰフィードバックメッセージとしてストリーミングサーバに送信することができる。
【００１８】
本発明の別の実施形態は、少なくとも１つのストリーミングセッションのデータパケットに対するＲＴＣＰフィードバックメッセージをクライアントからストリーミングサーバに提供する方法に関する。この実施形態においては、少なくとも１つのストリーミングセッションが、ＲＴＰプロトコルおよびＲＴＣＰプロトコルを使用して提供されており、ストリーミングセッションの利用可能な帯域幅の一部であるＲＴＣＰ帯域幅が、ＲＴＣＰフィードバックメッセージに割り当てられる。
【００１９】
クライアントは、ＲＴＣＰフィードバックメッセージのためのＲＴＣＰ帯域幅と、クライアントバッファリング時間内で有効にする最小再送信回数と、少なくとも１つのストリーミングセッションの消失データパケットに関する最小レポーティング冗長度と、クライアントバッファリング時間とを示すセッション記述情報を受信することができる。さらに、クライアントは、クライアントバッファリング時間とＲＴＣＰレポート間隔とに基づいて提供されうるデータパケットの最大再送信回数を決定することができる。ＲＴＣＰレポート間隔は、ＲＴＣＰフィードバックメッセージの平均サイズと、クライアントに割り当てられているＲＴＣＰ帯域幅とに依存する。
【００２０】
クライアントは、最大再送信回数が、最小再送信回数以上であるかをさらに判断することができ、以上である場合、クライアントは、消失データパケットの再送信を要求する複数の一般ＮＡＣＫレポートブロックを、ＲＴＣＰフィードバックパケットに追加することができる。ＲＴＣＰフィードバックパケットに追加されるこの複数の一般ＮＡＣＫレポートブロックによって、クライアントバッファリング時間内での消失データパケットの再送信を最小回数にすることができる。
【００２１】
さらに、クライアントは、割り当てられているＲＴＣＰ帯域幅と、クライアントバッファリング時間と、最小再送信回数とを考慮したときに許容されるＲＴＣＰフィードバックメッセージの最大サイズを決定することができ、さらに、以前に送られたＲＴＣＰフィードバックメッセージの平均サイズと、複数の一般ＮＡＣＫレポートブロックを含むＲＴＣＰパケットのサイズとに基づいて、結果のＲＴＣＰフィードバックメッセージの平均サイズを決定することができる。
【００２２】
さらに、クライアントは、結果のＲＴＣＰフィードバックパケットのサイズがＲＴＣＰフィードバックメッセージの最大サイズを超えない場合、消失データパケットに関してレポートする複数の消失ＲＬＥレポートブロックを、ＲＴＣＰフィードバックパケットに追加することができ、ＲＴＣＰフィードバックパケットを、ＲＴＣＰフィードバックメッセージとしてクライアントからストリーミングサーバに送信することができる。
【００２３】
本発明の別の実施形態においては、課金またはネットワークの監視を目的とする消失ＲＬＥレポートブロックが、ＲＴＣＰフィードバックパケットに追加される。
【００２４】
さらなる実施形態においては、複数の消失ＲＬＥレポートブロックにランレングス（ｒｕｎｌｅｎｇｔｈ）符号化を行い、次いで、ランレングス符号化を行ったこれらの消失ＲＬＥレポートブロックを含む結果のＲＴＣＰフィードバックパケットのサイズが、ＲＴＣＰフィードバックメッセージの最大サイズを超えていないか否かを判断する。消失ＲＬＥレポートブロックのランレングス符号化を実行することによって、それぞれの数のレポートブロックによって提供することのできるレポーティング冗長度を一定に維持しながら、消失ＲＬＥレポートブロックのサイズを減少させることができる。
【００２５】
別の実施形態においては、クライアントは、クライアントによるセッション記述情報によって設定されている最小レポーティング冗長度を減少させることを決定することができる。パケットの消失に関するレポーティング冗長度を減少させるためのさまざまな可能な方法を予測することができる。
【００２６】
例えば、この実施形態の１つの変形形態においては、クライアントは、ストリーミングセッションのパケットに提供されているアップリンクのサービス品質を決定することができる。この測定された、または決定されたサービス品質（ＱｏＳ）に基づいて、例えば、決定されたサービス品質が所定のしきい値レベルより大きい場合に、最小レポーティング冗長度を減少させる。
【００２７】
別の変形形態においては、複数の消失ＲＬＥレポートブロックのサイズを減少させることによって、クライアントがレポーティング冗長度を減少させることが予測される。
【００２８】
例えば、ストリーミングセッションのデータに、ストリーミングメディアの基本品質を提供する基本データ層と、このストリーミングメディアの基本品質を高める少なくとも１つのエンハンスメント層（enhancement layer）とが含まれている場合には、基本データ層のデータが含まれているデータパケットに関する情報のみを消失ＲＬＥレポートブロックに含めることによって、複数の消失ＲＬＥレポートブロックのサイズを減少させることができる。
【００２９】
例えば、少なくとも１つのストリーミングセッションのデータがＭＰＥＧストリームであり、基本データ層にＩフレームが含まれており、少なくとも１つのエンハンスメント層にＰフレームおよび／またはＢフレームが含まれているとする。この例においては、クライアントは、Ｉフレームは必ずレポートされるが、クライアントによって認識されるストリームのＱｏＳに対する影響の小さいＰフレームおよび／またはＢフレームについては、セッション記述情報によって設定されているセッション制約の中で可能な場合にのみレポートされるようにすることができる。
【００３０】
これに関して、クライアントは、消失データパケットに基本データ層のデータが含まれているか否かを、クライアントにおいてすでに受信されたデータパケットに基づいて判断することができる。
【００３１】
本実施形態のさらなる変形形態による、複数の消失ＲＬＥレポートブロックのサイズを減少させるさらなる可能な方法は、（１つ以上の）消失ＲＬＥレポートブロックにシニング（thinning）を適用することである。
【００３２】
さらに、本実施形態の別の変形形態では、ＲＴＣＰフィードバックパケットにおいてレポートされる複数の消失ＲＬＥレポートブロックを減少させることによって、複数の消失ＲＬＥレポートブロックのサイズを減少させることが予測される。
【００３３】
理想的には、本発明の別の実施形態においては、ＲＴＣＰフィードバックパケットに追加される複数の消失ＲＬＥレポートブロックによって、消失パケットのレポーティング冗長度を最小にすることができる。
【００３４】
さらに、本発明の別の実施形態においては、ストリーミングセッションのＭＩＭＥタイプのパラメータがパケットレートを示すことが予測される。このパラメータは、例えば、ＲＴＣＰレポート間隔の中でレポートしなければならないストリーミングセッションの平均パケット数を推定するのに有用である。
【００３５】
本発明のさらなる実施形態においては、クライアントは、ストリーミングセッションのどのパケットが消失したかを、クライアントにおいて受信されたデータパケットの連続番号に基づいて判断することができる。
【００３６】
本発明の別の実施形態は、少なくとも１つのストリーミングセッションのデータパケットに対するＲＴＣＰフィードバックメッセージをクライアントからストリーミングサーバに送信する、モバイル通信システムにおけるクライアントに関する。この場合も、この少なくとも１つのストリーミングセッションは、ＲＴＰプロトコルおよびＲＴＣＰプロトコルを使用して提供されており、ストリーミングセッションの利用可能な帯域幅の一部であるＲＴＣＰ帯域幅が、ＲＴＣＰフィードバックメッセージに割り当てられる。本発明のこの実施形態によるクライアントは、セッション記述情報を受信する受信器、およびクライアントバッファリング時間とＲＴＣＰレポート間隔とに基づいたときに提供することのできるデータパケットの最大再送信回数を決定するステップと、最大再送信回数が最小再送信回数以上であるか否かを判断するステップとを行う処理手段を備えていることができる。セッション記述情報は、ＲＴＣＰフィードバックメッセージのためのＲＴＣＰ帯域幅と、クライアントバッファリング時間内で有効にする最小再送信回数と、少なくとも１つのストリーミングセッションの消失データパケットの最小レポーティング冗長度と、クライアントバッファリング時間とを示す。ＲＴＣＰレポート間隔は、ＲＴＣＰフィードバックメッセージの平均サイズと、クライアントに割り当てられるＲＴＣＰ帯域幅とに依存する。
【００３７】
上記処理手段は、消失データパケットの再送信を要求する複数の一般ＮＡＣＫレポートブロックをＲＴＣＰフィードバックパケットに追加してクライアントバッファリング時間内での消失データパケットの再送信回数を最小にするステップと、最大再送信回数が最小再送信回数以上である場合に、割り当てられているＲＴＣＰ帯域幅、クライアントバッファリング時間、および最小再送信回数を考慮したときに許容されるＲＴＣＰフィードバックメッセージの最大サイズを決定するステップと、を行うようにすることができる。
【００３８】
上記処理手段は、以前に送られたＲＴＣＰフィードバックメッセージの平均サイズと、複数の一般ＮＡＣＫレポートブロックを含んでいるＲＴＣＰパケットのサイズとに基づいて、結果のＲＴＣＰフィードバックメッセージの平均サイズを求めるステップと、この結果のＲＴＣＰフィードバックパケットのサイズがＲＴＣＰフィードバックメッセージの最大サイズを超えない場合、消失データパケットに関してレポートする複数の消失ＲＬＥレポートブロックをＲＴＣＰフィードバックパケットに追加するステップと、を行うようにすることもできる。
【００３９】
クライアントは、ＲＴＣＰフィードバックパケットをＲＴＣＰフィードバックメッセージとしてストリーミングサーバに送信する送信器をさらに備えていることができる。
【００４０】
別の実施形態は、上述したさまざまな実施形態およびそれらの変形形態のうちの１つによる方法を実行するようにされている手段、をさらに備えているクライアントに関する。
【００４１】
さらに、本発明の別の実施形態は、モバイル通信システムにおけるクライアントのプロセッサによって実行されたときに、クライアントに、少なくとも１つのストリーミングセッションのデータパケットに対するＲＴＣＰフィードバックメッセージをクライアントからストリーミングサーバに提供させる、命令、を格納しているコンピュータ可読媒体に関する。この場合も、少なくとも１つのストリーミングセッションは、ＲＴＰプロトコルおよびＲＴＣＰプロトコルを使用して提供されており、ストリーミングセッションの利用可能な帯域幅の一部であるＲＴＣＰ帯域幅は、ＲＴＣＰフィードバックメッセージに割り当てられる。
【００４２】
クライアントにおいて、ＲＴＣＰフィードバックメッセージのためのＲＴＣＰ帯域幅と、クライアントバッファリング時間内で有効にする最小再送信回数と、少なくとも１つのストリーミングセッションの消失データパケットの最小レポーティング冗長度と、クライアントバッファリング時間とを示すセッション記述情報を受信するステップと、クライアントバッファリング時間と、ＲＴＣＰフィードバックメッセージの平均サイズおよびクライアントに割り当てられるＲＴＣＰ帯域幅に依存するＲＴＣＰレポート間隔とに基づいてデータパケットの最大再送信回数を決定するステップと、最大再送信回数が最小再送信回数以上であるか否かを判断するステップと、によって、クライアントに、少なくとも１つのストリーミングセッションのデータパケットに対するＲＴＣＰフィードバックメッセージをクライアントからストリーミングサーバに提供させることができる。
【００４３】
後者の場合、命令によって、消失データパケットの再送信を要求する複数の一般ＮＡＣＫレポートブロックをＲＴＣＰフィードバックパケットに追加して、クライアントバッファリング時間内での消失データパケットの再送信を最小回数にするステップと、割り当てられているＲＴＣＰ帯域幅、クライアントバッファリング時間および最小再送信回数を考慮したときに許容されるＲＴＣＰフィードバックメッセージの最大サイズを決定するステップと、以前に送られたＲＴＣＰフィードバックメッセージの平均サイズおよび複数の一般ＮＡＣＫレポートブロックを含んでいるＲＴＣＰパケットのサイズに基づいて、結果のＲＴＣＰフィードバックメッセージの平均サイズを決定するステップと、この結果のＲＴＣＰフィードバックパケットのサイズがＲＴＣＰフィードバックメッセージの最大サイズを超えない場合に、消失データパケットに関してレポートする複数の消失ＲＬＥレポートブロックをＲＴＣＰフィードバックパケットに追加するステップと、ＲＴＣＰフィードバックパケットをＲＴＣＰフィードバックメッセージとしてクライアントからストリーミングサーバに送信するステップと、をクライアントに行わせることができる。
【００４４】
本発明のさらなる実施形態によるコンピュータ可読媒体は、クライアントのプロセッサによって実行されたときに、クライアントに、上述した本発明のさまざまな実施形態およびそれらの変形形態のうちの１つによる方法を実行させる、命令、をさらに格納している。
【００４５】
本発明の別の実施形態は、ＲＴＰプロトコルおよびＲＴＣＰプロトコルを使用して提供される少なくとも１つのストリーミングセッションをクライアントに提供するストリーミングサーバと、上記の本発明の実施形態のうちの１つによるクライアントと、を備えているシステムを提供する。
【００４６】
（詳細な説明）
以下では、添付の図面を参照しながら本発明についてさらに詳細に説明する。図面における類似するかまたは対応する細部は、同じ参照数字によって表してある。
【００４７】
図１は、本発明の実施形態によるストリーミング環境の概要を示している。ストリーミングサーバ１００は、１つまたは複数のセッションの形式におけるストリーミングサービスを、無線アクセスネットワークを介してクライアント１０１またはモバイル端末に配信することができる。この例においては、コアネットワーク１０３（ＣＮ）を備えているＵＭＴＳネットワークと、ＵＭＴＳ無線アクセスネットワーク１０４（ＵＴＲＡＮ）は、3GPP TS 26.234に定義されている要件に従って運用することのできるストリーミングパケット交換サービスを提供する。コアネットワーク１０３をパケット交換ネットワーク、例えばインターネットに接続するために、コアネットワークは、ゲートウェイＧＰＲＳサポートノード１０５（ＧＧＳＮ）と、サービングＧＰＲＳサポートノード１０６（ＳＧＳＮ）とを備えていることができる。これらコアネットワークの構成要素は、少なくとも１つの無線アクセスコントローラ１０７（ＲＮＣ）と、ＲＮＣに接続されている少なくとも１つのノードＢとを備えているＵＴＲＡＮ １０４に接続することができる。ストリーミングメディアのデータは、無線リンクを介してモバイルクライアント１０１に提供することができる。
【００４８】
本発明の１つの態様は、さまざまなＲＴＰ再送信の実施形態において、消失をレポートするＲＬＥレポートブロックを効率的に使用することである。そのような実施形態は、一般には、サーバおよびクライアントが実行する機能と、再送信のスケジューリングおよび要求を行うのにサーバおよびクライアントが使用する情報と、サーバおよびクライアントがネットワーク条件（混雑、パケット消失、リンク特性）に関して保持する情報とにおいて異なる。３ＧＰＰ ＰＳＳストリーミングサービスでは、セッション記述属性が定義される。上記の情報を通信ピア間で利用可能にするために、この属性をしてもよく、使用しなくてもよい。
【００４９】
ＲＴＰ再送信の実施形態のいずれにおいても、同一の初期シナリオおよび要件として、以下を想定することができる。すなわち、ＲＴＣＰ伝送の信頼性が低いので、クライアントは冗長なレポーティングを実行すべきである。さらに、クライアントは、少なくとも現在のレポートと１つ前のレポートとの間の期間についてレポートする、すなわち最小受信者レポーティングを保証すべきである。
【００５０】
レポートの頻度は、適切なタイミングで再送信を行うことができるように、すなわち、各ＲＴＰパケットに対して最小回数の再送信が保証されるように、十分に大きくすべきである。したがって、クライアントは、サーバによって伝えられるＲＴＣＰ帯域幅に従うように、レポートの頻度、レポートのブロックサイズ、および冗長レポーティングを制限することができる。
【００５１】
これらの要件のいくつかは競合し、すべてのシナリオにおいてこれらの要件を同時に満たすことが不可能なことがあるので、クライアントは、与えられた条件に対して、冗長レポーティングのレベル、レポーティングの頻度、およびレポートされるＲＴＰパケットの数を最適化することができる。
【００５２】
このことは、例えば、（ＲＴＣＰ帯域幅割当ておよびクライアントバッファリング時間が、冗長なレポーティングを行うことのできるものであると仮定すると）、単純な実施形態において、クライアントが、現在のＲＴＣＰレポートと前のＲＴＣＰレポートとの間の消失パケットすべてに対して一般ＮＡＣＫレポートブロックを使用して再送信を要求し、これらの消失パケットすべてについて消失ＲＬＥレポートブロックを使用してレポートし、消失パケットおよび受信パケットに関する冗長レポーティングのレベルを適切な値に設定し、ＲＴＣＰレポートの頻度を、適切なタイミングで最大回数だけ再送信できるようにできる限り高く維持することを意味しうる。ダウンリンク（サーバからクライアント）上のＲＴＰパケットは複数回消失することがあり、したがって、複数回の再送信が必要となりうることに留意されたい。
【００５３】
伝えられるＲＴＣＰ帯域幅に従うようにレポートの頻度、レポートブロックのサイズ、および冗長レポーティングを制限するための要件に、この単純な実施形態が従う必要がない場合、クライアントは、最初に、ランレングス符号化によって消失ＲＬＥレポートブロックのサイズを減少させることを試みることができる。
【００５４】
消失ＲＬＥレポートブロックによって、個々のパケットの受信イベントおよび消失イベントに関する詳細なレポーティングが可能である。そのようなレポートは、例えば、ネットワーク特性のマルチキャストインファレンス（ＭＩＮＣ）に使用することができる。消失ＲＴＰパケットおよび受信ＲＴＰパケットのブール式トレース（Boolean trace）は長さが大きくなりうるため、このブロックタイプでは、ランレングス符号化を通じてトレースを圧縮することができる。ランレングス符号化を使用するときには、符号化するトレースを分析し、同一イベントの「連続（runs）」をまとめて消失ＲＬＥレポートブロックの全体的なサイズを減少させることができる。
【００５５】
次に、クライアントは、消失ＲＬＥレポートブロックあたりレポートされるＲＴＰパケットの数を減少させることができる。なお、１つのレポートブロックによってレポートされるパケット数が減少すると、結果的に冗長レポーティングのレベルが減少することに留意されたい。
【００５６】
消失ＲＬＥレポートブロックによってレポートされるパケットの数を減少させる目的で、消失イベントのレポートを、シニングと称されるメカニズムにおいてトレースから体系的にドロップすることができる。このシニングメカニズムは、シニング値Ｔを選択することによって実施することができ、この値Ｔを使用して、連続番号空間内のパケットのサブセット、例えば連続番号が２Ｔの倍数であるパケットを選択することができる。パケットの受信および消失のレポートは、これらのパケットにのみ適用される。Ｔは、例えば、０〜１５の間で変えることができる。Ｔがゼロである場合、連続番号空間内のすべてのパケットがレポートされる。Ｔが１５である場合、３２，７６８個のパケットごとに１つのパケットがレポートされる。
【００５７】
いま、上述したトレースが連続番号１３，８２１から開始されるとする。トレースにおける最後の連続番号は１３，８６５である。シニング値Ｔ＝２でトレースにシニングを行う場合、４つごとに１つの連続番号、すなわち、１３，８２４、１３，８２８、１３，８３２、１３，８３６、１３，８４０、１３，８４４、１３，８４８、１３，８５２、１３，８５６、１３，８６０、１３，８６４がレポートされる。
【００５８】
レポートされるパケットの数を減少させる別のオプションは、最も新しいパケット群に属するパケットのみをレポートすることである。
【００５９】
最後に、これらの方策のいずれも有用ではなく、クライアントバッファリング時間が終了するまでの再送信要求（１つ以上の一般ＮＡＣＫレポートブロック）の最小回数について厳しい要件が課される場合、クライアントは、これらの要求される最小再送信回数に従うための大きなＲＴＣＰ帯域幅でセッションを再起動し、および／またはクライアントバッファリング時間を増加させる（詳細は後の説明を参照）。
【００６０】
本発明の基礎をなす概念をさらに説明する目的で、ＲＴＣＰ帯域幅、クライアントバッファリング時間、ＲＴＣＰレポート間隔などの間の関係について、図３を参照しながら以下に説明する。図３は、本発明の実施形態によるストリーミング環境の概要を示している。この図には、複数の連続的な再送信要求と再送信とを時系列で示してある。ＲＴＰパケットの最初の送信（ＳＮ＝０）と、その１回目および２回目の再送信とが消失するものと仮定する。
【００６１】
送信者（例えばストリーミングサーバ）は、受信者（クライアント）にＲＴＰデータパケットを提供する。遅延Ｔ１に寄与するパラメータは、送信者から１つ以上のネットワークを通じての受信者までの一方向遅延、すなわち、物理的な遅延（physical delay）、エアインタフェースにおける送信遅延（transmission delay）、およびネットワークキューや順序入れ替えなどによる到着間ジッタ（interarrival jitter）に起因する遅延である。
【数１】
より詳細には次のようになる。
【数２】
【００６２】
いま、パケットの最初の送信が消失すると仮定すると、Ｔ２は、そのパケットの理論的な到着と、受信者がパケット消失を示すフィードバックを送信者に提供する時点との間の時間間隔を表す。
【００６３】
したがって、Ｔ２は、クライアントにおいてパケット消失を検出するのに要する時間（パケット消失検出時間：packet loss detection time）と、クライアントからの次のフィードバックレポートまでの平均時間（average time to the next feedback report）とからなる。
【数３】
【００６４】
パケット消失検出時間は、１つのパケットが偶発的に消失するのか（シングルトン消失）、またはパケットがバースト的に消失するのか（バースト消失）に依存する。前者の場合、パケット消失検出時間は、受信者において生じる到着間遅延ジッタ（interarrival delay jitter）に等しいはずである。後者の場合、実際の値を求めるには、バッファリング時間に追加のガードタイム（guard time）を加えなければならない。このガードタイムは、平均消失バースト（average loss burst）として定義され、バースト消失が検出されるまでに時間がかかることを反映するものである。
【００６５】
一般には、消失イベントは均一に分布しているので、次のフィードバックレポートまでの平均時間は、通常ではＲＴＣＰレポート間隔（RTCP report interval）の１／２である。
【数４】
【００６６】
フィードバックレポートの遅延Ｔ３は、基本的には遅延Ｔ１と同様に計算することができる。
【数５】
より詳細には次のようになる。
【数６】
【００６７】
最後に、送信者における再送信の処理時間は、Ｔ４で表してあり、送信者がどのパケットを再送信するかを決定するまでに必要な時間（フィードバック処理時間：feedback processing time）と、送信者におけるキューイング時間（queuing time）、すなわち、再送信されるパケットが実際に送信される前に送信者の（再）送信キューの中にとどまる時間とが含まれる。
【数７】
【００６８】
なお、Ｔ１＋Ｔ２＋Ｔ３はラウンドトリップタイム（ＲＴＴ）に相当することに留意されたい。
【数８】
【００６９】
ＲＴＴは、一般には、ＲＴＣＰレポート間隔よりも小さい。そうでない場合、受信者は最初にパケットの再送信を待機することなくフィードバックを送信するため、レポーティングは過剰になる。さらに、ＲＴＴにフィードバック処理時間を加えた合計は、一般には同様にＲＴＣＰレポート間隔より小さい。なぜなら、サーバは、通常、定義されている再送信帯域幅を保証しなくてはならず、したがってこの時間は大幅には増大しないからである。
【００７０】
提供することのできるレポーティング冗長度に影響を与える、ＲＴＰセッションの別の重要な「変数」は、上述したクライアントバッファリング時間である。このクライアントバッファリング時間は、一般的には、データパケットがユーザに「出力」されるまで受信者のメモリにバッファリングされている時間期間として定義することができる。例えば、映像ストリーミングセッションの場合、クライアントバッファリング時間は、データパケットの内容がユーザに表示されるまでそのデータパケットが受信者のメモリ（バッファ）に格納されている時間期間として理解することができる。
【００７１】
パケットがユーザに提供されるまでにＲＴＰセッション内で提供できる再送信回数は、次のように表すことができる。
【数９】
【００７２】
「Ｉｎｔｅｇｅｒ（）」関数は、除算の結果から整数値を取り出す。（アップリンク送信の）ＲＴＣＰレポート間隔は、次のように定義される。
【数１０】
この式において、
【数１１】
【００７３】
この等式において、現在のＲＴＣＰパケットサイズ（current RTCP packet size）は、送信される次のＲＴＣＰフィードバックのサイズに等しい。
【００７４】
上の計算の１つの単純化として、Ｔ２の定義において、バースト的ではない、すなわちパケットのシングルトン消失のみを考慮することができ、すなわち次式となる。
【数１２】
【００７５】
クライアントにおいてＴ１＋Ｔ２＋Ｔ３＋Ｔ４が必ず計算可能であるとは限らないので、この合計に使用することのできる控えめな近似として、図３に示した近似を使用することができる（模範例を目的として最小再送信回数は３とする）。例えば、ＲＴＣＰレポート間隔の値は、この合計のおおまかな推定値を表すことができ、控えめなバッファリング時間（ｃｌｉｅｎｔ＿ｂｕｆｆｅｒｉｎｇ＿ｔｉｍｅ’）は、次のように定義することができる。
【数１３】
【００７６】
控えめなクライアントバッファリング時間（ｃｌｉｅｎｔ＿ｂｕｆｆｅｒｉｎｇ＿ｔｉｍｅ’）は、要求される最小再送信回数（ｍｉｎ＿ｎｏ＿ｒｔｘｓ）を確保するためのバッファリング時間として理解することもできる。このことは、当然ながら、値Ｔ１＋Ｔ２＋Ｔ３＋Ｔ４がＲＴＣＰレポート間隔よりも小さいときにのみ当てはまる。値Ｔ１＋Ｔ２＋Ｔ３＋Ｔ４は、一般にはＲＴＣＰレポート間隔よりも小さく、なぜなら、そうでない場合、クライアントは生じうる再送信を待機せずにフィードバックを送信することになるからである。このことは、サーバによって、あるいはＳＤＰまたは類似するプロトコルを使用してセッション記述情報を設定する責務を負うコンテンツ作成者によって確保されるものとする。
【００７７】
本発明の１つの実施形態によると、可能な再送信回数の計算（等式９を参照）は、次のように単純化することができる。
【数１４】
【００７８】
当然ながら、より正確である等式９の計算を使用することもできる。しかしながら、等式１３は、より容易に実施することができる。ＰＳＳストリーミングサービスの初期段階において、クライアントは、特定のサーバから提供されるセッションの詳細に関する記述を要求する。サーバは、この要求に応答して、セッション記述を送信する。特に、以下のパラメータがセッション記述によってクライアントに知らされる。
【００７９】
・ メディアセッションに使用されるコーデックのＭＩＭＥタイプ（例えば、Ｈ２６３、ＡＭＲ、ＭＰＥＧ４など）
・ 受信者レポートのためのＲＴＣＰ帯域幅割当て（ｃｌｉｅｎｔ＿ｒｔｃｐ＿ｂａｎｄｗｉｄｔｈ）（ビット／秒）。ＰＳＳ仕様が対象としているアプリケーションなどのユニキャストストリーミングアプリケーションの場合の帯域幅割当ての初期値は、送信者および受信者のそれぞれについて、合計ＲＴＣＰ帯域幅の５０％である。それ以外の値は、RFC 3556の規定を使用して明示的に指定することができる。合計ＲＴＣＰ帯域幅は、一般にはセッション総帯域幅の５％である。
・ コーデックを記述する任意のＭＩＭＥタイプパラメータ。これらのパラメータは、パケットレート（１秒あたりのパケット数）などストリームのその他の値を計算するのに使用することができる。
・ クライアントが使用することのできる任意のＲＴＣＰパケットの最大サイズ。現在、ＰＳＳフレームワークの中でサーバの（ＲＴＣＰではなく）ＲＴＰパケットのサイズを制限することが可能である。将来的には、ＲＴＣＰレポートパケットについて同様の制限が可能である。
【００８０】
さらに、本発明の実施形態によると、以下の追加のパラメータがクライアントに知らされる。
【００８１】
・ サーバによって推奨される最小再送信回数（ｍｉｎ＿ｎｏ＿ｒｔｘｓ）。サーバは、クライアントが各パケットに対して最小回数の再送信を保証することを提案することができる。この理由は、例えば、サービスプロバイダがリンク上のパケット消失を認識しているからである。上述したように、ＰＳＳストリーミングサービスにおける再送信は、フィードバックにおける一般ＮＡＣＫレポートブロックによってトリガする必要がある。
・ （同じく）サーバによって推奨されるレポーティング冗長度（ｒｅｐｏｒｔ＿ｒｅｄｕｎｄａｎｃｙ）。この数値は、消失ＲＬＥレポートブロックを使用してパケットをレポートする回数を示す。サービスプロバイダにとっては、達成されているリンクのパフォーマンス（どのパケットが受信された、または受信されていないか）と、パケットをクライアントに提供するのに最大で何回の再送信が必要であるかとを知ることは重要である。このことは、個々に知覚されるサービス品質に対してのみクライアントに課金を行ううえでも重要である。
・ クライアントバッファリング時間（ｃｌｉｅｎｔ＿ｂｕｆｆｅｒｉｎｇ＿ｔｉｍｅ）（単位：秒）。これは、あとの段落に説明するようにセッションパラメータから導くことができる。
【００８２】
クライアントバッファリング時間を考慮するとき、以下の２つの可能なシナリオがある。
【００８３】
第１の可能なシナリオは、３ＧＰＰ ＰＳＳフレームワークに定義されているビットレートの適合化をクライアントがサポートしない場合である。
【００８４】
この場合、クライアントバッファリング時間は、初期バッファリング時間、すなわち、セッション開始後にクライアントがバッファのパケットの読み出しを開始するまでの時間、に等しい値に選択することができる。
【００８５】
第２の可能なシナリオは、３ＧＰＰ ＰＳＳフレームワークに定義されているビットレートの適合化をクライアントがサポートする場合である。この場合、クライアントは以下のパラメータを使用することができる。
【００８６】
・ バッファサイズ（ｂｕｆｆｅｒ＿ｓｉｚｅ）。これは、「３ＧＰＰ適合化」ヘッダにおいて伝えられる。このパラメータは、ＲＴＰヘッダを含む完全なＲＴＰパケット用にこの特定のスペース量を持つ受信バッファおよびデジッタ処理バッファ（reception and de-jittering buffer）と一致している必要がある。指定されるバッファサイズには、そのメディアに使用される予備復号器のバッファ空間を含めることもできる。したがって、このパラメータは、セッションの任意の瞬間にクライアントが利用できるセッションデータ（ＲＴＰパケット）の最大サイズに対応する。一般には、このパラメータはクライアントバッファリング時間の値を決定する目的には使用されない。
・ 目標保護時間（ｔａｒｇｅｔ＿ｐｒｏｔｅｃｔｉｏｎ＿ｔｉｍｅ）。これは、「３ＧＰＰ適合化」ヘッダ（「目標時間」パラメータ）においてクライアントに伝えられる。このパラメータは、目標の最小バッファレベル、言い換えれば、中断のない再生が保証され、かつ必要な場合にサーバが送信速度を調整することのできる、クライアントにおける望ましい再生時間長（単位：ミリ秒）を表す。本発明の１つの実施形態によると、このパラメータはクライアントバッファリング時間（ｃｌｉｅｎｔ＿ｂｕｆｆｅｒｉｎｇ＿ｔｉｍｅ）として使用される。
【００８７】
クライアントは、一旦セッション記述情報を受信すると、伝えられたＲＴＣＰ帯域幅割当て（ｃｌｉｅｎｔ＿ｒｔｃｐ＿ｂａｎｄｗｉｄｔｈ）と、そのメディアストリームを対象とするクライアントバッファリング時間（ｃｌｉｅｎｔ＿ｂｕｆｆｅｒｉｎｇ＿ｔｉｍｅ）とが、パケット消失に関するレポーティングが可能であるように選択されているか否かを判断することができる。さらに、クライアントは、そのＲＴＣＰ帯域幅割当ておよびクライアントバッファリング時間において、パラメータｒｅｐｏｒｔ＿ｒｅｄｕｎｄａｎｃｙによって指定されている望ましいレポート冗長度と、パラメータｍｉｎ＿ｎｏ＿ｒｔｘｓによって指定されている要求される最小回数の再送信とを提供することができるか否かを、さらに判断することができる。
【００８８】
なお、レポーティング冗長度は、サービス提供ネットワークの監視、課金などの課題（消失ＲＬＥレポートブロック）に関連するのに対し、提供される最小回数の再送信は、先に概説したように一般ＮＡＣＫのフィードバックに基づいていることに留意されたい。
【００８９】
１つの実施形態によると、クライアントのバッファによって各パケットに対するタイマがｃｌｉｅｎｔ＿ｂｕｆｆｅｒｉｎｇ＿ｔｉｍｅ秒に設定されていると仮定する。パケットがこの時間期間内に受信されない場合、タイマが切れて、そのパケットに対してもはや再送信を要求することができない（すなわち、さらなる一般ＮＡＣＫメッセージに含めることができない）。
【００９０】
さらに、過去のＲＴＣＰレポート（以前に送信された一般ＮＡＣＫレポートブロックおよび消失ＲＬＥレポートブロックが含まれている）がクライアントにおける送信バッファに保存されることを仮定することもできる。このバッファのサイズは、例えば、サーババッファリング時間（ｓｅｒｖｅｒ＿ｂｕｆｆｅｒｉｎｇ＿ｔｉｍｅ）（単位：秒）に一致する値に設定することができる。さらに、このバッファは、後から説明する方法によって必要とされるように、送信された必要なＲＴＣＰパケットを格納するのに十分な大きさである必要がある。
【００９１】
以下の段落では、本発明の実施形態による好ましいアルゴリズムについて説明する。このアルゴリズムは、RFC 3550のAnnex Aに記載されている標準ＲＴＰアルゴリズムと補完的な関係にある。標準ＲＴＰアルゴリズムとは対照的に、このアルゴリズムによる発明によれば、パラメータｍｉｎ＿ｎｏ＿ｒｔｘｓおよびパラメータｒｅｐｏｒｔ＿ｒｅｄｕｎｄａｎｃｙを考慮して、ＰＳＳに従ったセッションを設定することができる。このアルゴリズムは、以下を達成するうえで必要である一般ＮＡＣＫレポートおよび消失ＲＬＥレポートのサイズをクライアントが求めるときに有用である。
【００９２】
・ すべての各パケットに対して最大回数のパケット再送信を可能にし、またはクライアントバッファリング時間内での最小回数（ｍｉｎ＿ｎｏ＿ｒｔｘｓ）の再送信を実施し、
・ （可能な場合に）パラメータｒｅｐｏｒｔ＿ｒｅｄｕｎｄａｎｃｙによって設定されているレポート冗長度を提供し、
・ その一方で、受信者レポートのための与えられたＲＴＣＰ帯域幅と、クライアントのバッファリング能力とに従う。
【００９３】
以下の好ましいステップは、クライアントが、自身が送信するすべての各ＲＴＣＰ受信者レポートについて、最初のＲＴＣＰパケットから開始して実行することができる。
【００９４】
ステップ１：ＲＴＰ／ＡＶＰＦによる１秒の初期待機期間後、クライアントは、新しい一般ＮＡＣＫメッセージにおいてパケットの再送信を要求することができる。実施の観点からは、このステップは照合動作である。なぜなら、上述したＲｅｙらのインターネットドラフトに従って再送信を実行しているすべてのクライアントは、保留中の要求のリストを維持する必要があるからである。
【００９５】
模範的なリストは、２つの列、すなわち、連続番号ＳＮの列と、特定のＳＮを持つパケットが受信されたか受信されていないかを示すフラグ（例えば、「０」：受信されていない、「１」：受信された）の列とで構成することができる。このリスト中に存在する受信されていないパケットをＮＡＣＫに含める。なお、受信されていないパケットは、各パケットのクライアントバッファリング時間（ｃｌｉｅｎｔ＿ｂｕｆｆｅｒｉｎｇ＿ｔｉｍｅ）が経過した後に、このリストから削除する。
【００９６】
ステップ２：第２のステップは、与えられたＲＴＣＰ帯域幅（ｃｌｉｅｎｔ＿ｒｔｃｐ＿ｂａｎｄｗｉｄｔｈ）の場合における、一般ＮＡＣＫレポートブロックにレポートされるパケットの最大再送信回数（ｍａｘ＿ｎｏ＿ｒｔｘｓ）を計算することである。再送信が保留中であるパケットは、最小回数（ｍｉｎ＿ｎｏ＿ｒｔｘｓ）の再送信を実施するうえですべての各再送信パケットに含まれている必要のある最小の情報であるため、最大再送信回数は、控えめなクライアントバッファリング時間（ｃｌｉｅｎｔ＿ｂｕｆｆｅｒｉｎｇ＿ｔｉｍｅ’）をＲＴＣＰレポート間隔（ＲＴＣＰ＿ｒｅｐｏｒｔ＿ｉｎｔｅｒｖａｌ）の現在の値で除することによって計算することができる。
【数１５】
【００９７】
この計算には、上の等式（１３）に提示した単純化が含まれていることに留意されたい。ＲＴＣＰレポート間隔パラメータｒｔｃｐ＿ｒｅｐｏｒｔ＿ｉｎｔｅｒｖａｌは、一般にはＲＴＰ基本アルゴリズムの一部として各ＲＴＰクライアントおよびサーバによって維持される。
【００９８】
平均ＲＴＣＰパケットサイズ（ａｖｇ＿ｒｔｃｐ＿ｐａｃｋｅｔ＿ｓｉｚｅＮＡＣＫ）は、次のように計算することができる（上の等式１１も参照）。
【数１６】
【００９９】
現在のＲＴＣＰパケットサイズ（単位：バイト）、すなわち一般ＮＡＣＫレポートブロックを含んでいる（しかし消失ＲＬＥレポートブロックは含んでいない）ときの次のフィードバックメッセージのパケットサイズは、次のように計算することができる。
【数１７】
この式において、ｓｔｅｐ（）は、パラメータとしてｎおよび定数１７をとる数学ステップ関数である。１７は、１つの一般ＮＡＣＫレポートブロックにおいて要求することのできるパケット数である。当然ながら、１７を超える／１７未満のパケットを１つの一般ＮＡＣＫレポートブロックによって要求できる場合には、ステップ関数のパラメータとして１７以外の別の定数を選択することが可能である。いくつかのｎの値に対しては次のようになる。
【数１８】
Ｋは、少なくとも１つの一般ＮＡＣＫメッセージを有するＲＴＣＰ受信者メッセージを含んでいるＩＰパケットにおける固定フィールドを考慮する定数である。
【０１００】
例えば、パケットの構成が、３２バイトの１つの受信者レポート（ＲＲ）と、１２バイトの１つのＳＤＥＳアイテム（ＣＮＡＭＥを持つ）とを有し、暗号化ヘッダあるいはプロファイルに固有な拡張部が存在しないという標準的な構成である場合、固定フィールドは、ＩＰヘッダ＋ＵＤＰヘッダ＋ＲＴＣＰヘッダ＋１ＲＲ＋１ＳＤＥＳアイテム（ＣＮＡＭＥ）＋ＮＡＣＫ固定フィールド、すなわち、２０＋８＋８＋２４＋１２＋１２＝８４バイトとなる。
【０１０１】
パケットに、電話番号や電子メールのような、プロファイルに固有の拡張部またはその他のＳＤＥＳアイテム、もしくはＢＹＥパケットやアプリケーションに固有のパケット（ＡＰＰ）のような、その他のＲＴＣＰレポートブロックが含まれている場合、それらの固定フィールドをこの定数Ｋに追加しなければならない。同じことは、後述するＫ’にも当てはまる。
【０１０２】
計算された最大再送信回数（ｍａｘ＿ｎｏ＿ｒｔｘｓ）（等式１４）が１より大きい（＞１）場合、そのことは、消失パケットが後からの１回以上の再送信において受信される可能性があることを意味する。
【０１０３】
一般には、クライアントは、最小再送信回数（ｍｉｎ＿ｎｏ＿ｒｔｘｓ）に従うことが要求される。これが不可能である場合、すなわちｍａｘ＿ｎｏ＿ｒｔｘｓ＜ｍｉｎ＿ｎｏ＿ｒｔｘｓである場合、ＲＴＣＰ帯域幅割当てとクライアントバッファリング時間とによって決まる制約内では、要求される最小回数のパケット再送信を提供することが不可能であるので、クライアントは、より少ない再送信回数で続行するか、あるいはセッションを再起動して別の設定（例えば、より高いＲＴＣＰ帯域、ｍｉｎ＿ｎｏ＿ｒｔｘｓがより小さくなるようにさらに良好に保護されたストリームなどを選択することによる、要求されるバッファリング時間がより少ないコーデック設定）を選択することを決定することができる。
【０１０４】
言い換えれば、上の計算を満たすことのできる、クライアントによって要求される最小再送信回数が存在する場合、最大パケットサイズ（後から説明する）に達するまでフィードバックにデータを追加することが可能である。存在しない場合、ＲＴＣＰパケットが大きすぎ、必要な回数だけ再送信を要求することができない。
【０１０５】
ｍｉｎ＿ｎｏ＿ｒｔｘｓ回のパケット再送信を要求することのできる、ＲＴＣＰパケットの最大サイズ（ｍａｘ＿ｒｔｃｐ＿ｐａｃｋｅｔ＿ｓｉｚｅ）は、次のように計算することができる。
【数１９】
【０１０６】
後者のパラメータは常に１より大きいので、等式１７は、ｍｉｎ＿ｎｏ＿ｒｔｘｓのすべての値それぞれに対して定義されることに留意されたい。そうでない場合、上述したインターネットラフトにおいてＲｅｙらによって提案されている再送信を使用する意味がなくなる。
【０１０７】
ステップ３：クライアントがｍｉｎ＿ｎｏ＿ｒｔｘｓを実施することができると仮定し、かつ、ｍａｘ＿ｎｏ＿ｒｔｘｓ＞ｍｉｎ＿ｎｏ＿ｒｔｘｓであると仮定すると、次のステップは、等式１７を使用して計算されるｍａｘ＿ｒｔｃｐ＿ｐａｃｋｅｔ＿ｓｉｚｅに達するまで、（再送信を要求する一般ＮＡＣＫに加えて）消失ＲＬＥレポートブロックをフィードバックメッセージに含めることである。言い換えれば、ｍａｘ＿ｒｔｃｐ＿ｐａｃｋｅｔ＿ｓｉｚｅとｃｕｒｒｅｎｔ＿ｒｔｃｐ＿ｐａｃｋｅｔ＿ｓｉｚｅＮＡＣＫとの間の差は、最小再送信回数ｍｉｎ＿ｎｏ＿ｒｔｘｓの要件に違反することなく現在のＲＴＣＰパケットに追加することのできるデータ量に等しい。
【数２０】
【０１０８】
さきの場合（等式１６を参照）に似て、ＲＴＣＰのＩＰヘッダおよびＵＤＰヘッダと、一般ＮＡＣＫメッセージおよび消失ＲＬＥレポートとを含めたＲＴＣＰパケットサイズをｎの関数として計算するための一般式は、次のとおりである。
【数２１】
この式において、ｓｔｅｐ’（）はさきと同じであり、ｓｔｅｐ（）は、パラメータとしてｎおよび定数３０をとる数学ステップ関数である。なお、等式１９においては、フィードバックには少なくとも１つの消失ＲＬＥレポートブロックが含まれていることを仮定しており、含まれていない場合、等式１６を使用して現在のＲＴＣＰパケットサイズを計算できる。パラメータ３０は、１つの消失ＲＬＥレポートブロックにおいてレポートすることのできるパケットの数である。当然ながら、３０を超える／３０未満のパケットを１つのＲＬＥレポートブロックによってレポートできる場合には、ステップ関数のパラメータとして３０以外の別の定数を選択することが可能である。いくつかのｎ’記号の値に対しては次のようになる。
【数２２】
【０１０９】
なお、ｎおよびｎ’は、段階的に増加することに留意されたい。この理由は、ＲＴＣＰレポートが３２ビットに揃えられており、レポートするパケットの数が１７または３０の倍数を超えると４バイトワード全体が追加されるからである。
【０１１０】
等式１９においては、Ｋ’は、上の等式１６の場合に定義されているＫよりも大きい６バイトである。なぜなら、次に送られる（現在の）ＲＴＣＰフィードバックメッセージには（少なくとも）１つの消失ＲＬＥレポートブロックが含まれているからである。
【０１１１】
クライアントが、与えられたｒｅｐｏｒｔ＿ｒｅｄｕｎｄａｎｃｙの値に従うことが要求される場合、クライアントは、その値によって定義されるとおりに過去の消失ＲＬＥレポートブロックを含めることができる。例えば、ｒｅｄｕｎｄａｎｃｙ＿ｖａｌｕｅが２である場合、同一の消失ＲＬＥレポートブロックが２つの連続するＲＴＣＰレポートにおいて送られることを意味する。この値が３である場合は、同一の消失ＲＬＥレポートブロックが３つの連続するＲＴＣＰパケットに存在し、以下同様である。言い換えれば、レポーティング冗長度が２に設定されている場合、１つのＲＴＣＰレポート（すなわちその中のＲＬＥレポートブロック）は、過去の２つのＲＴＣＰレポート間隔についてレポートする必要があり、レポーティング冗長度が３に設定されている場合、過去の３つのＲＴＣＰレポート間隔についてレポートする必要があり、以下同様である。このことにより、クライアントには、有効期間が終了しているパケットを含めて、受信したパケットおよび受信していないパケットのリスト（例えば２列の配列）を維持することが要求される。このリストは、有効期間がまだ終了していないパケットのみが含まれているクライアントバッファの内容とは異なる。
【０１１２】
ステップ４：必要なレポーティング冗長度を提供するために、次のＲＴＣＰフィードバックメッセージに（１つ以上の一般ＮＡＣＫレポートブロックに加えて）追加しなければならない必要な数の消失ＲＬＥレポートブロックを含めると、許容される最大ＲＴＣＰパケットサイズ（ｍａｘ＿ｒｔｃｐ＿ｐａｃｋｅｔ＿ｓｉｚｅ）を超えるということも起こりうる。この場合、クライアントは、ランレングス符号化によって、１つ以上の消失ＲＬＥレポートブロックのサイズを減少させることを試みることができる。パケットサイズを減少させるためのさらなるオプションとして、上述したシニングなどの別の方法も使用することができる。しかしながら、シニングの使用を考慮すると、レポーティング冗長度が減少する。
【０１１３】
これらのメカニズムによっても、必要なレポーティング冗長度が保証されるだけＲＬＥレポートブロックのサイズを十分に減少させることができない場合、クライアントは、そのｒｅｐｏｒｔ＿ｒｅｄｕｎｄａｎｃｙ値に従わないことを決定し、送信を続行することができる。これに代えて、クライアントは、セッションを再起動して、より大きなクライアントバッファリング時間、またはより低いビットレートのコーデック設定を選択することができる。
【０１１４】
ステップ５：最後に、ａｖｇ＿ｒｔｃｐ＿ｐａｃｋｅｔｓｉｚｅおよびｒｔｃｐ＿ｒｅｐｏｒｔ＿ｉｎｔｅｒｖａｌのような、RFC 3550、Annex Aによる標準的なアルゴリズムにおける残りの変数更新および標準処理を、以下の標準的な方法で計算する。
【数２３】
【０１１５】
ＲＴＣＰパケットを送るたびに、ステップ１〜ステップ５を繰り返すことができる。これに代えて、クライアントは、クライアントの能力が変化したときにのみ、特に、クライアントバッファリング時間またはクライアントのＲＴＣＰ帯域幅の変化が起きたときにのみ、これらのステップを繰り返すことを選択することもできる。
【０１１６】
フィードバックメッセージを送った後、クライアントは、RFC 3550に概略的に指定されている規定に従って、セッションのさまざまなパラメータを更新することができる。例えば、クライアントは、平均ＲＴＣＰパケットサイズを再計算し、その結果としてのＲＴＣＰレポート間隔を再計算し、送信バッファの内容を更新し、送信する次のＲＴＣＰフィードバックの計算を開始することができる。
【０１１７】
別の実施形態においては、クライアントがｒｅｐｏｒｔ＿ｒｅｄｕｎｄａｎｃｙを減少させることによって、消失ＲＬＥレポートブロックのサイズをさらに減少させることができる。しかしながら、この状況においては、クライアントが冗長レポーティングの妥当なレベルを依然として得られるかという疑問が生じる。
【０１１８】
レポーティング冗長度を減少させることは、リンク上のパケット消失率を測定することのできる実施形態において可能である。パケット消失率は、例えば、送信者からのＲＴＣＰレポートから推定することができる。これに代えて、またはこれに加えて、クライアントは、リンク確立処理からのリンクのＱｏＳに関する先験的な情報を保持することができる。したがって、クライアントへの特定のリンク上のパケット消失率が低い／高いときには、冗長レポーティングのレベルをさらに減少させる／高めることができる。なぜなら、信頼性の低い伝送プロトコルを使用しているとき、パケット消失率が低い／高いほど、クライアントのフィードバックが送信者において受信される可能性が高い／低いからである。
【０１１９】
Ｆｒｉｅｄｍａｎらのインターネットドラフトに指定されている方法以外の、消失ＲＬＥレポートブロックのサイズを減少させる別の方法は、例えば、個々のパケットの重要度の推定に基づくことができる。例えば、ＭＰＥＧ−４などの漸進的な（progressive）符号化手法においては、パケットはさまざまな優先度を持つ。したがって、重要度の低いパケット、すなわちＰフレームは、レポーティングからドロップすることができる。
【０１２０】
これに代えて、またはこれに加えて、消失ＲＬＥレポートブロックのサイズを減少させる目的で、現在のアプリケーションレベルのＱｏＳおよびリンクレベルのＱｏＳを考慮することができる。例えば、現在のアプリケーションレベルのＱｏＳが十分に高く、および／またはリンクレベルのＱｏＳが低い（すなわちリンクが輻輳状態）場合、クライアントは、一部の消失パケットについてのレポーティングをドロップすることを決定することができる。例えば、ＭＰＥＧ４コーデックでは、高度なパケット消失復元方策が実施される。場合によって、およびストリームのコンテンツによっては、リンク上でいくつかのパケットが消失しても、その消失によってピクチャの品質が影響されないということがありうる。具体的には、Ｂフレームが消失した場合、その影響は最小であり、パケットを再送信するコストの方が大きく、したがって、アプリケーションはそのパケットをドロップすることを決定することができる。
【０１２１】
本発明は、３ＧＰＰ ＰＳＳユニキャストストリーミングサービスにおいて以下の利点を有する。第一に、本発明は、一般ＮＡＣＫレポートブロックおよびＲＬＥレポートブロックを使用してＲＴＣＰ受信者レポートを構築する、ストリーミングサーバおよびクライアントのための追加のメカニズムを、３ＧＰＰ ＰＳＳフレームワークに提供する。クライアントがｃｌｉｅｎｔ＿ｂｕｆｆｅｒｉｎｇ＿ｔｉｍｅおよびｃｌｉｅｎｔ＿ｒｔｃｐ＿ｂａｎｄｗｉｄｔｈを認識していると仮定したとき、本方法では、最小再送信回数（ｍｉｎ＿ｎｏ＿ｒｔｘｓ）と、特定のレポート冗長度と、レポートの必要な送信頻度と、レポートがカバーすべきパケット数とを提供するためのレポートのサイズを指定することが可能である。
【０１２２】
上述したように、レポート冗長度は、特に、再送信のパフォーマンスに関して、すなわち、パケットがクライアントによって（正常に）受信されるまで何回再送信されるかに関して、課金アプリケーションおよびネットワークの監視にとって重要である。
【０１２３】
さらに、本発明は、最も単純なクライアントから、豊富な機能を備えたクライアントまでを、クライアント側において利用可能な情報と、消失ＲＬＥレポートの必要な圧縮効率とに応じて確立することができるように、幅広いクライアントの設定を指定するためのフレームワークを定義する。さらに、本発明のいくつかの実施形態は、ＲＴＣＰフィードバックのサイズを減少させるための追加の方法を提供する。
【０１２４】
次に、本発明のより具体的かつ好ましいさまざまな実施形態について、図４、図５および図６を参照しながら説明する。
【０１２５】
図４は、本発明の実施形態による、ストリーミングセッション内でＲＴＣＰフィードバックを提供する方法の最初のステップ群を示している。現在のＲＴＣＰレポート間隔が終了した時点で、クライアントは、次のＲＴＣＰフィードバックをサーバに送る準備を行う。最初に（ステップ４０１〜４０４）、クライアントは、設定されているセッションパラメータが、要求される最小回数（ｍｉｎ＿ｎｏ＿ｒｔｘｓ）の再送信をすることができるものであるか否かを判断することができる。この目的のために、クライアントは、現在のＲＴＣＰパケット（次に送るＲＴＣＰパケット）に、セッションに対して設計されている最小再送信回数を確保するのに必要な１つ以上の一般ＮＡＣＫレポートブロックのみが含まれていると仮定して、このパケットのサイズを決定することができる（４０１）。前述したように（等式１６を参照）、現在のＲＴＣＰパケットのサイズは、レポートするパケットの数に依存する。
【０１２６】
その計算値（ｃｕｒｒｅｎｔ＿ｒｔｃｐ＿ｐａｃｋｅｔ＿ｓｉｚｅＮＡＣＫ）と、以前のＲＴＣＰフィードバックメッセージの平均サイズ（ｓｅｎｔ＿ｒｔｃｐ＿ｐａｃｋｅｔ＿ｓｉｚｅ）とに基づいて、平均ＲＴＣＰパケットサイズ（ａｖｇ＿ｒｔｃｐ＿ｐａｃｋｅｔ＿ｓｉｚｅＮＡＣＫ）を、上の等式１５を使用して決定することができる（４０２）。次いで、クライアントバッファリング時間内で可能である最大再送信回数（ｍａｘ＿ｎｏ＿ｒｔｘｓ）を計算する（４０３）（等式１４を参照）。
【０１２７】
これらの計算に基づいて、クライアントは、ステップ４０４において、要求される最小回数（ｍｉｎ＿ｎｏ＿ｒｔｘｓ）の再送信が可能であるか否かを判断することができる。可能ではない場合、クライアントは、上述したようにセッションパラメータの別の設定を用いてセッションを再設定し、または再起動することができる（４０５）。
【０１２８】
ｍａｘ＿ｎｏ＿ｒｔｘ＞ｍｉｎ＿ｎｏ＿ｒｔｘｓである場合、セッションパラメータであるクライアントバッファリング時間と、ＲＴＣＰ帯域幅割当てと、最小再送信回数とは、クライアントがこれらの制約パラメータの中で動作できるように選択されている。したがって、クライアントは、次のステップ４０６において、最小回数の再送信を提供するのに必要な１つ以上の一般ＮＡＣＫレポートブロックを、現在のフィードバックメッセージに追加することができる。そのセッションにおいて消失ＲＬＥレポートブロックによる（追加の）レポーティングが必要ない場合には（ステップ４０７を参照）、クライアントは、１つ以上の一般ＮＡＣＫレポートブロックのみが含まれている現在のフィードバックメッセージをサーバに送信するステップ（４０８）に進むことができる。
【０１２９】
パケット消失に関する（冗長な）レポーティングがセッションに要求される場合、クライアントは、次いで、最小回数の再送信を確保するための１つ以上の一般ＮＡＣＫレポートブロックのみならず、パケット消失に関する冗長なレポーティングを確保するのに必要なＲ個の消失ＲＬＥレポートブロックをさらに含めるための十分な容量が、現在のフィードバックメッセージにあるか否かを判断することができる。
【０１３０】
この目的のために、クライアントは、次いでステップ４０９において、最小回数の再送信を提供することのできるＲＴＣＰフィードバックメッセージの最大サイズを決定することができる（等式１７を参照）。上述したように、最大ＲＴＣＰパケットサイズ（ｍａｘ＿ｒｔｃｐ＿ｐａｃｋｅｔ＿ｓｉｚｅ）は、最小回数の再送信が確保されている状態でフィードバックを提供することのできる平均メッセージサイズを示す１つの測度である。
【０１３１】
ｍａｘ＿ｎｏ＿ｒｔｘ＞ｍｉｎ＿ｎｏ＿ｒｔｘｓであることが分かっているので（ステップ４０４を参照）、最大ＲＴＣＰパケットサイズが、１つ以上の一般ＮＡＣＫレポートブロックが含まれている平均ＲＴＣＰパケットサイズ以上であることも明らかである。
【０１３２】
ステップ４１０において、クライアントは、現在のＲＴＣＰパケットに残されているペイロード残量を決定する。言い換えれば、クライアントは、１つ以上の一般ＮＡＣＫレポートブロックがすでに含まれている現在のＲＴＣＰパケットに、ＲＴＣＰフィードバックの最大許容（平均）サイズに違反することなく、さらに何バイト（ｐａｙｌｏａｄ＿ｍａｒｇｉｎ）を追加できるかを決定する。
【０１３３】
図５および図６に示した、フローチャートにおける以降のステップ群は、全体として、現在のＲＴＣＰフィードバックメッセージ内の残りの空間（ｐａｙｌｏａｄ＿ｍａｒｇｉｎ）に、可能であれば１つ以上の消失ＲＬＥレポートブロックを含めて（最小の）冗長レポーティングを確保する方法を示す例として理解されたい。後からさらに詳しく説明するように、場合によっては、消失パケットに関する最小回数の冗長レポートを有効にすることができないことがある。しかしながら、その状況においては、レポーティングをまったく行わないのではなく、少なくともある程度の（冗長な）レポーティングを提供することが望ましい。
【０１３４】
次のステップ５０１においては（図５）、クライアントは、要求される最小レポーティング冗長度を有効にするために必要であるＲ個の消失ＲＬＥレポートブロックを構築することができる。消失ＲＬＥレポートブロックのサイズはペイロード残量に含めるには大きすぎることがあるので、クライアントは、ステップ５０２に示したように消失ＲＬＥレポートブロックのランレングス圧縮を実行することができる。なお、このステップは省略することができる。次いで、ステップ５０３において、Ｒ個の（圧縮された）消失ＲＬＥレポートブロックのサイズを決定し、ステップ５０４において、その値をペイロード残量と比較し、要求される最小回数の再送信を有効にすることのできる最大許容（平均）ＲＴＣＰパケットサイズに違反することなく、Ｒ個すべての消失ＲＬＥレポートブロックが現在のＲＴＣＰフィードバックメッセージに収まるか否かを判断する。
【０１３５】
収まる場合、これらのＲ個の（圧縮された）消失ＲＬＥレポートブロックをフィードバックメッセージに追加し（５０５）、クライアントは、複数の一般ＮＡＣＫレポートブロックと複数（Ｒ個）の消失ＲＬＥレポートブロックとが含まれているＲＴＣＰフィードバックメッセージを送信する（５０６）。この場合、クライアントは、最小回数の再送信が有効であり、かつ、最小レポーティング冗長度も提供できる状況を確保することができる。
【０１３６】
しかしながら、ステップ５０４において、Ｒ個の（圧縮された）消失ＲＬＥレポートブロックのサイズがペイロード残量よりも大きい場合、クライアントは、消失パケットに関する少なくともある程度の（冗長）レポーティングを提供することを試みることができる。この目的のために、クライアントは、さらにステップ５０７に進み、現在のフィードバックに含める消失ＲＬＥレポートブロックの数を減少させていき、残りの数の（圧縮された）消失ＲＬＥレポートブロックが現在のＲＴＣＰフィードバックメッセージのペイロード残量に収まるようにすることができる（５０９）。例えば、クライアントは、「最も古い」パケットに関してレポートしているレポートブロックを連続的にドロップすることができる（ステップ５０７、５０８、５０９、５１１を参照）。なぜなら、「最も古い」パケットについては以前のレポートにおいてすでにレポートされている可能性があるからである。もう１つの可能な方法は、消失ＲＬＥレポートブロックのサイズがペイロード残量より小さくなるまでシニングを実行することである。さらには、クライアントは、上述したように、レポートされるパケットの重要度を考慮することもできる。別の代替方法は、これらのメカニズムを必要に応じて組み合わせることである。
【０１３７】
これに関して、図６は、本発明の別の実施形態による、ＲＴＣＰフィードバックメッセージを構築するさらなるステップ群を示している。以下の説明においては、図５におけるステップに類似するステップは同じ参照数字で表してあり、簡潔にするためその説明は省略した。
【０１３８】
図６に示したステップ群においては、シニングおよびその他のメカニズムを組み合わせて、消失ＲＬＥレポートブロックのサイズを減少させることができる。重要な点として、シニング（ステップ６０３を参照）を適用するか否かの決定は、クライアントへのダウンリンクにおいて現在利用可能であるサービス品質（ＱｏＳ）に基づいて行うことができる（ステップ６０１および６０２を参照）。
【０１３９】
例えば、ＲＴＣＰフィードバックメッセージの送信者レポートブロックおよび／または受信者レポートブロックの中の「消失割合（fraction lost）」フィールドの計算値（RFC 3500、６．４節を参照）を評価し、それぞれ、アップリンクおよびダウンリンク上の現在のＱｏＳの指標とすることができる。これに代えて、モバイル通信システムからの明示的にネゴシエートされるＱｏＳ測定値を提供することもできる。例えば、アップリンク上の示されたＱｏＳが高い場合、このことは、信頼性の低い伝送プロトコルを使用して送信されたときにクライアントのＲＴＣＰフィードバックがおそらくは消失しないであろうことを意味しうる。したがって、クライアントは、サーバによって設定されているよりも低いレポーティング冗長度で十分であると判断することができる。この場合、クライアントは、消失ＲＬＥレポートブロックにシニングを適用することを決定することができる。したがって、ステップ６０５は、シニングが適用された場合にはクライアントが最小レポーティング冗長度をもはや保証しなくてもよいことを除いて、図５におけるステップ５に似ている。
【０１４０】
本発明の別の実施形態においては、クライアントは、利用可能なＱｏＳに基づいて最小再送信回数を減少させることを決定することさえできる。この場合、クライアントは、すべての一般ＮＡＣＫレポートブロックをフィードバックに含めるのではなく、図５のステップ５０７、５０８、５０９、および５１１に関して説明した方法に似た方法で、最近の新しいパケットに関してのみレポートすることを考慮することができる。
【０１４１】
本発明の別の実施形態は、本発明の上述したさまざまな実施形態の実施に関する。上述したさまざまな方法と、上述した図のさまざまな論理ブロックは、コンピューティングデバイス（プロセッサ）、例えば、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、またはその他のプログラマブルロジックデバイスなどを使用して実施する、または実行できることが認識される。本発明のさまざまな実施形態は、これらのデバイスの組合せによって実行する、または具体化することもできる。
【０１４２】
さらに、本発明のさまざまな実施形態、それらの変形形態、およびＱｏＳに基づくスケジューリング（QoS-aware scheduling）の解決策は、プロセッサによって実行される、またはハードウェアにおいて直接実行されるソフトウェアモジュールによって実装することもできる。また、ソフトウェアモジュールとハードウェア実装とを組み合わせることも可能である。ソフトウェアモジュールは、例えば、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤなどの任意の種類のコンピュータ可読ストレージメディアに格納することができる。
【図面の簡単な説明】
【０１４３】
【図１】本発明の実施形態によるストリーミング環境の概要を示す図
【図２】本発明の実施形態によるクライアントバッファリング時間と、ＲＴＣＰレポート周期と、再送信の目標レベルを提供するのに要する最小時間期間との間の関係を示す図
【図３】本発明の好ましい実施形態によるストリーミング環境における複数の連続的な再送信要求と再送信とを時系列で示す図
【図４】本発明の実施形態によるストリーミングセッション内でＲＴＣＰフィードバックを提供する方法の最初のステップ群を示す図
【図５】本発明の相異なる実施形態による、図４に示されるステップ群の後に実行されるＲＴＣＰフィードバックを提供する方法のさらなるステップ群を示す図
【図６】本発明の相異なる実施形態による、図４に示されるステップ群の後に実行されるＲＴＣＰフィードバックを提供する方法のさらなるステップ群を示す図
【特許請求の範囲】
【請求項１】
ＲＴＰプロトコルおよびＲＴＣＰプロトコルを使用して提供される少なくとも１つのストリーミングセッションのデータパケットに対するＲＴＣＰフィードバックメッセージをクライアント（１０１）からストリーミングサーバ（１００）に提供する方法であって、前記ストリーミングセッションの利用可能な帯域幅の一部であるＲＴＣＰ帯域幅が前記ＲＴＣＰフィードバックメッセージに割り当てられており、
前記クライアント（１０１）において、前記ＲＴＣＰフィードバックメッセージのための前記ＲＴＣＰ帯域幅と、クライアントバッファリング時間内で有効にする最小再送信回数と、前記少なくとも１つのストリーミングセッションの消失データパケットに関する最小レポーティング冗長度と、前記クライアントバッファリング時間とを示すセッション記述情報を受信するステップと、
前記クライアントバッファリング時間と、ＲＴＣＰフィードバックメッセージの平均サイズおよび前記クライアント（１０１）に割り当てられる前記ＲＴＣＰ帯域幅に依存するＲＴＣＰレポート間隔とに基づいてデータパケットの最大再送信回数を決定するステップ（４０１，４０２，４０３）と、
前記最大再送信回数が前記最小再送信回数以上であるか否かを判断するステップ（４０４）と、
以上である場合に、
消失データパケットの再送信を要求する複数の一般ＮＡＣＫレポートブロックをＲＴＣＰフィードバックパケットに追加して前記クライアントバッファリング時間内での前記消失データパケットの前記再送信回数を最小にするステップ（４０６）と、
前記割り当てられているＲＴＣＰ帯域幅と、前記クライアントバッファリング時間と、前記最小再送信回数とを考慮したときに許容される前記ＲＴＣＰフィードバックメッセージの最大サイズを決定するステップ（４０９）と、
以前に送られたＲＴＣＰフィードバックメッセージの平均サイズと、前記複数の一般ＮＡＣＫレポートブロックを含む前記ＲＴＣＰパケットのサイズとに基づいて、結果のＲＴＣＰフィードバックメッセージの平均サイズを決定するステップ（４０２）と、
前記結果のＲＴＣＰフィードバックパケットのサイズが前記ＲＴＣＰフィードバックメッセージの最大サイズを超えない場合、前記消失データパケットに関してレポートする複数の消失ＲＬＥレポートブロックを、前記ＲＴＣＰフィードバックパケットに追加するステップ（５０５，５１０）と、
前記ＲＴＣＰフィードバックパケットをＲＴＣＰフィードバックメッセージとして前記クライアント（１０１）から前記ストリーミングサーバ（１００）に送信するステップ（５０６）と、を含む方法。
【請求項２】
前記複数の消失ＲＬＥレポートブロックにランレングス符号化を行い（５０２）、次いで、前記ランレングス符号化を行った消失ＲＬＥレポートブロックを含む前記結果のＲＴＣＰフィードバックパケットのサイズが、前記ＲＴＣＰフィードバックメッセージの最大サイズを超えていないか否かを判断する、請求項１記載の方法。
【請求項３】
前記クライアントにより前記セッション記述情報によって設定されている前記最小レポーティング冗長度を減少させるステップをさらに含む、請求項１または請求項２記載の方法。
【請求項４】
前記ストリーミングセッションのパケットに提供されているアップリンクのサービス品質を決定するステップ（６０２）をさらに含み、
前記決定されたサービス品質が所定のしきい値レベルより大きい場合に、前記最小レポーティング冗長度を減少させる、請求項３記載の方法。
【請求項５】
前記複数の消失ＲＬＥレポートブロックのサイズを減少させることによって、前記クライアントが前記レポーティング冗長度を減少させる、請求項３または請求項４記載の方法。
【請求項６】
前記ストリーミングセッションのデータは、ストリーミングメディアの基本品質を提供する基本データ層と、前記ストリーミングメディアの基本品質を高める少なくとも１つのエンハンスメント層とを含み、
前記複数の消失ＲＬＥレポートブロックのサイズを減少させる前記ステップは、前記基本データ層のデータを含むデータパケットに関する情報のみを前記消失ＲＬＥレポートブロックに含めるステップを含む、
請求項３乃至請求項５のいずれかに記載の方法。
【請求項７】
前記少なくとも１つのストリーミングセッションのデータがＭＰＥＧストリームであり、前記基本データ層がＩフレームを含み、前記少なくとも１つのエンハンスメント層がＰフレームおよび／またはＢフレームを含む、請求項６記載の方法。
【請求項８】
消失データパケットが前記基本データ層のデータを含むか否かを、前記クライアントにおいてすでに受信されたデータパケットに基づいて判断するステップをさらに含む、請求項６または請求項７記載の方法。
【請求項９】
前記複数の消失ＲＬＥレポートブロックのサイズをシニング（６０３）によって減少させる、請求項３乃至請求項８のいずれかに記載の方法。
【請求項１０】
前記ＲＴＣＰフィードバックパケットにおいてレポートされる前記複数の消失ＲＬＥレポートブロックを減少させることによって（５０７，５０８，５０９，５１１）、前記複数の消失ＲＬＥレポートブロックのサイズを減少させる、請求項３乃至請求項８のいずれかに記載の方法。
【請求項１１】
前記ＲＴＣＰフィードバックパケットに追加される前記複数の消失ＲＬＥレポートブロックによって、前記消失パケットの前記最小レポーティング冗長度が有効になる、請求項１または請求項２記載の方法。
【請求項１２】
前記ストリーミングセッションのＭＩＭＥタイプパラメータがパケットレートを示す、請求項１乃至請求項１１のいずれかに記載の方法。
【請求項１３】
前記少なくとも１つのストリーミングセッションのどのデータパケットが消失したのかを、前記クライアントにおいて受信されたデータパケットの連続番号に基づいて判断するステップをさらに含む、請求項１乃至請求項１２のいずれかに記載の方法。
【請求項１４】
ＲＴＰプロトコルおよびＲＴＣＰプロトコルを使用して提供される少なくとも１つのストリーミングセッションのデータパケットに対するＲＴＣＰフィードバックメッセージをクライアント（１０１）からストリーミングサーバ（１００）に提供する方法であって、
前記ストリーミングセッションのセッション制約内で提供することのできるデータパケットの最大再送信回数が前記クライアントによって有効にされる最小再送信回数よりも大きいか否かを判断するステップと、
大きい場合に、消失データパケットの再送信を要求する複数の一般ＮＡＣＫレポートブロックをＲＴＣＰフィードバックパケットに追加して前記クライアントバッファリング時間内での前記消失データパケットの前記再送信回数を最小にするステップと、
前記セッション制約を考慮したときに許容されるＲＴＣＰフィードバックメッセージの最大サイズを決定するステップと、
結果のＲＴＣＰフィードバックパケットのサイズが前記ＲＴＣＰフィードバックメッセージの最大サイズを超えないように、消失データパケットおよび受信データパケットに関してレポートする複数の消失ＲＬＥレポートブロックを前記ＲＴＣＰフィードバックパケットに追加するステップと、
前記ＲＴＣＰフィードバックパケットをＲＴＣＰフィードバックメッセージとして前記クライアント（１０１）から前記ストリーミングサーバ（１００）に送信するステップと、を含む方法。
【請求項１５】
前記決定されたＲＴＣＰフィードバックメッセージの最大サイズと、前記一般ＮＡＣＫレポートブロックのサイズとに基づいて、前記ＲＴＣＰフィードバックパケットにおけるペイロード残量を計算するステップと、
前記複数の消失ＲＬＥレポートブロックを前記ＲＴＣＰフィードバックパケットに追加するときに、前記結果のＲＴＣＰフィードバックパケットがＲＴＣＰフィードバックメッセージの前記最大サイズを超えることがないように、前記ペイロード残量に収まる前記複数の消失ＲＬＥレポートブロックを決定するステップと、をさらに含む、請求項１４記載の方法。
【請求項１６】
ＲＴＰプロトコルおよびＲＴＣＰプロトコルを使用して提供される少なくとも１つのストリーミングセッションのデータパケットに対するＲＴＣＰフィードバックメッセージをクライアントからストリーミングサーバに送信する、モバイル通信システムにおけるクライアントであって、前記ストリーミングセッションの利用可能な帯域幅の一部であるＲＴＣＰ帯域幅が前記ＲＴＣＰフィードバックメッセージに割り当てられており、
前記ＲＴＣＰフィードバックメッセージのための前記ＲＴＣＰ帯域幅と、クライアントバッファリング時間内で有効にする最小再送信回数と、前記少なくとも１つのストリーミングセッションの消失データパケットに関する最小レポーティング冗長度と、前記クライアントバッファリング時間とを示すセッション記述情報を受信する受信器と、
前記クライアントバッファリング時間と、ＲＴＣＰフィードバックメッセージの平均サイズおよび前記クライアントに割り当てられている前記ＲＴＣＰ帯域幅に依存するＲＴＣＰレポート間隔とに基づいて、データパケットの最大再送信回数を決定し（４０１，４０２，４０３）、前記最大再送信回数が前記最小再送信回数以上であるか否かを判断する（４０４）処理手段と、を備え、
前記処理手段は、さらに、
前記最大再送信回数が前記最小再送信回数以上である場合に、
消失データパケットの再送信を要求する複数の一般ＮＡＣＫレポートブロックをＲＴＣＰフィードバックパケットに追加して前記クライアントバッファリング時間内での前記消失データパケットの前記再送信回数を最小にするステップ（４０６）と、
前記割り当てられているＲＴＣＰ帯域幅と、前記クライアントバッファリング時間と、前記最小再送信回数を考慮したときに許容されるＲＴＣＰフィードバックメッセージの最大サイズを決定するステップ（４０９）と、
以前に送られたＲＴＣＰフィードバックメッセージの平均サイズと、前記複数の一般ＮＡＣＫレポートブロックを含む前記ＲＴＣＰパケットのサイズとに基づいて、結果のＲＴＣＰフィードバックメッセージの平均サイズを決定するステップ（４０２）と、
前記結果のＲＴＣＰフィードバックパケットのサイズが前記ＲＴＣＰフィードバックメッセージの最大サイズを超えない場合、前記消失データパケットに関してレポートする複数の消失ＲＬＥレポートブロックを前記ＲＴＣＰフィードバックパケットに追加するステップ（５０５，５１０）と、を行うように構成されており、
前記クライアント（１０１）は、前記ＲＴＣＰフィードバックパケットをＲＴＣＰフィードバックメッセージとして前記ストリーミングサーバ（１００）に送信する（５０６）送信器をさらに備える、クライアント。
【請求項１７】
請求項２乃至請求項１３のいずれかに記載の前記方法を実行するように構成されている手段をさらに備える、請求項１６記載のクライアント。
【請求項１８】
モバイル通信システムにおけるクライアントのプロセッサによって実行されたときに、
前記クライアント（１０１）において、前記ＲＴＣＰフィードバックメッセージのための前記ＲＴＣＰ帯域幅と、クライアントバッファリング時間内で有効にする最小再送信回数と、前記少なくとも１つのストリーミングセッションの消失データパケットに関する最小レポーティング冗長度と、前記クライアントバッファリング時間とを示すセッション記述情報を受信するステップと、
前記クライアントバッファリング時間と、ＲＴＣＰフィードバックメッセージの平均サイズおよび前記クライアント（１０１）に割り当てられている前記ＲＴＣＰ帯域幅に依存するＲＴＣＰレポート間隔とに基づいて、データパケットの最大再送信回数を決定するステップ（４０１，４０２，４０３）と、
前記最大再送信回数が前記最小再送信回数以上であるか否かを判断するステップ（４０４）と、
以上である場合に、
消失データパケットの再送信を要求する複数の一般ＮＡＣＫレポートブロックをＲＴＣＰフィードバックパケットに追加して前記クライアントバッファリング時間内での前記消失データパケットの前記再送信回数を最小にするステップ（４０６）と、
前記割り当てられているＲＴＣＰ帯域幅と、前記クライアントバッファリング時間と、前記最小再送信回数とを考慮したときに許容されるＲＴＣＰフィードバックメッセージの最大サイズを決定するステップ（４０９）と、
以前に送られたＲＴＣＰフィードバックメッセージの平均サイズと、前記複数の一般ＮＡＣＫレポートブロックを含む前記ＲＴＣＰパケットのサイズとに基づいて、結果のＲＴＣＰフィードバックメッセージの平均サイズを決定するステップ（４０２）と、
前記結果のＲＴＣＰフィードバックパケットの前記サイズが前記ＲＴＣＰフィードバックメッセージの最大サイズを超えない場合、前記消失データパケットに関してレポートする複数の消失ＲＬＥレポートブロックを、前記ＲＴＣＰフィードバックパケットに追加するステップ（５０５，５１０）と、
前記ＲＴＣＰフィードバックパケットをＲＴＣＰフィードバックメッセージとして前記クライアント（１０１）から前記ストリーミングサーバ（１００）に送信するステップ（５０６）と、
を行うことによって、前記クライアントに、ＲＴＰプロトコルおよびＲＴＣＰプロトコルを使用して提供される少なくとも１つのストリーミングセッションのデータパケットに対するＲＴＣＰフィードバックメッセージをクライアント（１０１）からストリーミングサーバ（１００）に提供させる命令を格納しているコンピュータ可読媒体であって、前記ストリーミングセッションの利用可能な帯域幅の一部であるＲＴＣＰ帯域幅が、前記ＲＴＣＰフィードバックメッセージに割り当てられている、コンピュータ可読媒体。
【請求項１９】
前記クライアントの前記プロセッサによって実行されたときに、前記クライアントに、請求項２乃至請求項１３のいずれかに記載の前記方法を実行させる命令をさらに格納している、請求項１８記載のコンピュータ可読媒体。
【請求項２０】
ＲＴＰプロトコルおよびＲＴＣＰプロトコルを使用して提供される少なくとも１つのストリーミングセッションをクライアントに提供するストリーミングサーバと、請求項１６または請求項１７記載のクライアントと、を備えるシステム。
【請求項１】
ＲＴＰプロトコルおよびＲＴＣＰプロトコルを使用して提供される少なくとも１つのストリーミングセッションのデータパケットに対するＲＴＣＰフィードバックメッセージをクライアント（１０１）からストリーミングサーバ（１００）に提供する方法であって、前記ストリーミングセッションの利用可能な帯域幅の一部であるＲＴＣＰ帯域幅が前記ＲＴＣＰフィードバックメッセージに割り当てられており、
前記クライアント（１０１）において、前記ＲＴＣＰフィードバックメッセージのための前記ＲＴＣＰ帯域幅と、クライアントバッファリング時間内で有効にする最小再送信回数と、前記少なくとも１つのストリーミングセッションの消失データパケットに関する最小レポーティング冗長度と、前記クライアントバッファリング時間とを示すセッション記述情報を受信するステップと、
前記クライアントバッファリング時間と、ＲＴＣＰフィードバックメッセージの平均サイズおよび前記クライアント（１０１）に割り当てられる前記ＲＴＣＰ帯域幅に依存するＲＴＣＰレポート間隔とに基づいてデータパケットの最大再送信回数を決定するステップ（４０１，４０２，４０３）と、
前記最大再送信回数が前記最小再送信回数以上であるか否かを判断するステップ（４０４）と、
以上である場合に、
消失データパケットの再送信を要求する複数の一般ＮＡＣＫレポートブロックをＲＴＣＰフィードバックパケットに追加して前記クライアントバッファリング時間内での前記消失データパケットの前記再送信回数を最小にするステップ（４０６）と、
前記割り当てられているＲＴＣＰ帯域幅と、前記クライアントバッファリング時間と、前記最小再送信回数とを考慮したときに許容される前記ＲＴＣＰフィードバックメッセージの最大サイズを決定するステップ（４０９）と、
以前に送られたＲＴＣＰフィードバックメッセージの平均サイズと、前記複数の一般ＮＡＣＫレポートブロックを含む前記ＲＴＣＰパケットのサイズとに基づいて、結果のＲＴＣＰフィードバックメッセージの平均サイズを決定するステップ（４０２）と、
前記結果のＲＴＣＰフィードバックパケットのサイズが前記ＲＴＣＰフィードバックメッセージの最大サイズを超えない場合、前記消失データパケットに関してレポートする複数の消失ＲＬＥレポートブロックを、前記ＲＴＣＰフィードバックパケットに追加するステップ（５０５，５１０）と、
前記ＲＴＣＰフィードバックパケットをＲＴＣＰフィードバックメッセージとして前記クライアント（１０１）から前記ストリーミングサーバ（１００）に送信するステップ（５０６）と、を含む方法。
【請求項２】
前記複数の消失ＲＬＥレポートブロックにランレングス符号化を行い（５０２）、次いで、前記ランレングス符号化を行った消失ＲＬＥレポートブロックを含む前記結果のＲＴＣＰフィードバックパケットのサイズが、前記ＲＴＣＰフィードバックメッセージの最大サイズを超えていないか否かを判断する、請求項１記載の方法。
【請求項３】
前記クライアントにより前記セッション記述情報によって設定されている前記最小レポーティング冗長度を減少させるステップをさらに含む、請求項１または請求項２記載の方法。
【請求項４】
前記ストリーミングセッションのパケットに提供されているアップリンクのサービス品質を決定するステップ（６０２）をさらに含み、
前記決定されたサービス品質が所定のしきい値レベルより大きい場合に、前記最小レポーティング冗長度を減少させる、請求項３記載の方法。
【請求項５】
前記複数の消失ＲＬＥレポートブロックのサイズを減少させることによって、前記クライアントが前記レポーティング冗長度を減少させる、請求項３または請求項４記載の方法。
【請求項６】
前記ストリーミングセッションのデータは、ストリーミングメディアの基本品質を提供する基本データ層と、前記ストリーミングメディアの基本品質を高める少なくとも１つのエンハンスメント層とを含み、
前記複数の消失ＲＬＥレポートブロックのサイズを減少させる前記ステップは、前記基本データ層のデータを含むデータパケットに関する情報のみを前記消失ＲＬＥレポートブロックに含めるステップを含む、
請求項３乃至請求項５のいずれかに記載の方法。
【請求項７】
前記少なくとも１つのストリーミングセッションのデータがＭＰＥＧストリームであり、前記基本データ層がＩフレームを含み、前記少なくとも１つのエンハンスメント層がＰフレームおよび／またはＢフレームを含む、請求項６記載の方法。
【請求項８】
消失データパケットが前記基本データ層のデータを含むか否かを、前記クライアントにおいてすでに受信されたデータパケットに基づいて判断するステップをさらに含む、請求項６または請求項７記載の方法。
【請求項９】
前記複数の消失ＲＬＥレポートブロックのサイズをシニング（６０３）によって減少させる、請求項３乃至請求項８のいずれかに記載の方法。
【請求項１０】
前記ＲＴＣＰフィードバックパケットにおいてレポートされる前記複数の消失ＲＬＥレポートブロックを減少させることによって（５０７，５０８，５０９，５１１）、前記複数の消失ＲＬＥレポートブロックのサイズを減少させる、請求項３乃至請求項８のいずれかに記載の方法。
【請求項１１】
前記ＲＴＣＰフィードバックパケットに追加される前記複数の消失ＲＬＥレポートブロックによって、前記消失パケットの前記最小レポーティング冗長度が有効になる、請求項１または請求項２記載の方法。
【請求項１２】
前記ストリーミングセッションのＭＩＭＥタイプパラメータがパケットレートを示す、請求項１乃至請求項１１のいずれかに記載の方法。
【請求項１３】
前記少なくとも１つのストリーミングセッションのどのデータパケットが消失したのかを、前記クライアントにおいて受信されたデータパケットの連続番号に基づいて判断するステップをさらに含む、請求項１乃至請求項１２のいずれかに記載の方法。
【請求項１４】
ＲＴＰプロトコルおよびＲＴＣＰプロトコルを使用して提供される少なくとも１つのストリーミングセッションのデータパケットに対するＲＴＣＰフィードバックメッセージをクライアント（１０１）からストリーミングサーバ（１００）に提供する方法であって、
前記ストリーミングセッションのセッション制約内で提供することのできるデータパケットの最大再送信回数が前記クライアントによって有効にされる最小再送信回数よりも大きいか否かを判断するステップと、
大きい場合に、消失データパケットの再送信を要求する複数の一般ＮＡＣＫレポートブロックをＲＴＣＰフィードバックパケットに追加して前記クライアントバッファリング時間内での前記消失データパケットの前記再送信回数を最小にするステップと、
前記セッション制約を考慮したときに許容されるＲＴＣＰフィードバックメッセージの最大サイズを決定するステップと、
結果のＲＴＣＰフィードバックパケットのサイズが前記ＲＴＣＰフィードバックメッセージの最大サイズを超えないように、消失データパケットおよび受信データパケットに関してレポートする複数の消失ＲＬＥレポートブロックを前記ＲＴＣＰフィードバックパケットに追加するステップと、
前記ＲＴＣＰフィードバックパケットをＲＴＣＰフィードバックメッセージとして前記クライアント（１０１）から前記ストリーミングサーバ（１００）に送信するステップと、を含む方法。
【請求項１５】
前記決定されたＲＴＣＰフィードバックメッセージの最大サイズと、前記一般ＮＡＣＫレポートブロックのサイズとに基づいて、前記ＲＴＣＰフィードバックパケットにおけるペイロード残量を計算するステップと、
前記複数の消失ＲＬＥレポートブロックを前記ＲＴＣＰフィードバックパケットに追加するときに、前記結果のＲＴＣＰフィードバックパケットがＲＴＣＰフィードバックメッセージの前記最大サイズを超えることがないように、前記ペイロード残量に収まる前記複数の消失ＲＬＥレポートブロックを決定するステップと、をさらに含む、請求項１４記載の方法。
【請求項１６】
ＲＴＰプロトコルおよびＲＴＣＰプロトコルを使用して提供される少なくとも１つのストリーミングセッションのデータパケットに対するＲＴＣＰフィードバックメッセージをクライアントからストリーミングサーバに送信する、モバイル通信システムにおけるクライアントであって、前記ストリーミングセッションの利用可能な帯域幅の一部であるＲＴＣＰ帯域幅が前記ＲＴＣＰフィードバックメッセージに割り当てられており、
前記ＲＴＣＰフィードバックメッセージのための前記ＲＴＣＰ帯域幅と、クライアントバッファリング時間内で有効にする最小再送信回数と、前記少なくとも１つのストリーミングセッションの消失データパケットに関する最小レポーティング冗長度と、前記クライアントバッファリング時間とを示すセッション記述情報を受信する受信器と、
前記クライアントバッファリング時間と、ＲＴＣＰフィードバックメッセージの平均サイズおよび前記クライアントに割り当てられている前記ＲＴＣＰ帯域幅に依存するＲＴＣＰレポート間隔とに基づいて、データパケットの最大再送信回数を決定し（４０１，４０２，４０３）、前記最大再送信回数が前記最小再送信回数以上であるか否かを判断する（４０４）処理手段と、を備え、
前記処理手段は、さらに、
前記最大再送信回数が前記最小再送信回数以上である場合に、
消失データパケットの再送信を要求する複数の一般ＮＡＣＫレポートブロックをＲＴＣＰフィードバックパケットに追加して前記クライアントバッファリング時間内での前記消失データパケットの前記再送信回数を最小にするステップ（４０６）と、
前記割り当てられているＲＴＣＰ帯域幅と、前記クライアントバッファリング時間と、前記最小再送信回数を考慮したときに許容されるＲＴＣＰフィードバックメッセージの最大サイズを決定するステップ（４０９）と、
以前に送られたＲＴＣＰフィードバックメッセージの平均サイズと、前記複数の一般ＮＡＣＫレポートブロックを含む前記ＲＴＣＰパケットのサイズとに基づいて、結果のＲＴＣＰフィードバックメッセージの平均サイズを決定するステップ（４０２）と、
前記結果のＲＴＣＰフィードバックパケットのサイズが前記ＲＴＣＰフィードバックメッセージの最大サイズを超えない場合、前記消失データパケットに関してレポートする複数の消失ＲＬＥレポートブロックを前記ＲＴＣＰフィードバックパケットに追加するステップ（５０５，５１０）と、を行うように構成されており、
前記クライアント（１０１）は、前記ＲＴＣＰフィードバックパケットをＲＴＣＰフィードバックメッセージとして前記ストリーミングサーバ（１００）に送信する（５０６）送信器をさらに備える、クライアント。
【請求項１７】
請求項２乃至請求項１３のいずれかに記載の前記方法を実行するように構成されている手段をさらに備える、請求項１６記載のクライアント。
【請求項１８】
モバイル通信システムにおけるクライアントのプロセッサによって実行されたときに、
前記クライアント（１０１）において、前記ＲＴＣＰフィードバックメッセージのための前記ＲＴＣＰ帯域幅と、クライアントバッファリング時間内で有効にする最小再送信回数と、前記少なくとも１つのストリーミングセッションの消失データパケットに関する最小レポーティング冗長度と、前記クライアントバッファリング時間とを示すセッション記述情報を受信するステップと、
前記クライアントバッファリング時間と、ＲＴＣＰフィードバックメッセージの平均サイズおよび前記クライアント（１０１）に割り当てられている前記ＲＴＣＰ帯域幅に依存するＲＴＣＰレポート間隔とに基づいて、データパケットの最大再送信回数を決定するステップ（４０１，４０２，４０３）と、
前記最大再送信回数が前記最小再送信回数以上であるか否かを判断するステップ（４０４）と、
以上である場合に、
消失データパケットの再送信を要求する複数の一般ＮＡＣＫレポートブロックをＲＴＣＰフィードバックパケットに追加して前記クライアントバッファリング時間内での前記消失データパケットの前記再送信回数を最小にするステップ（４０６）と、
前記割り当てられているＲＴＣＰ帯域幅と、前記クライアントバッファリング時間と、前記最小再送信回数とを考慮したときに許容されるＲＴＣＰフィードバックメッセージの最大サイズを決定するステップ（４０９）と、
以前に送られたＲＴＣＰフィードバックメッセージの平均サイズと、前記複数の一般ＮＡＣＫレポートブロックを含む前記ＲＴＣＰパケットのサイズとに基づいて、結果のＲＴＣＰフィードバックメッセージの平均サイズを決定するステップ（４０２）と、
前記結果のＲＴＣＰフィードバックパケットの前記サイズが前記ＲＴＣＰフィードバックメッセージの最大サイズを超えない場合、前記消失データパケットに関してレポートする複数の消失ＲＬＥレポートブロックを、前記ＲＴＣＰフィードバックパケットに追加するステップ（５０５，５１０）と、
前記ＲＴＣＰフィードバックパケットをＲＴＣＰフィードバックメッセージとして前記クライアント（１０１）から前記ストリーミングサーバ（１００）に送信するステップ（５０６）と、
を行うことによって、前記クライアントに、ＲＴＰプロトコルおよびＲＴＣＰプロトコルを使用して提供される少なくとも１つのストリーミングセッションのデータパケットに対するＲＴＣＰフィードバックメッセージをクライアント（１０１）からストリーミングサーバ（１００）に提供させる命令を格納しているコンピュータ可読媒体であって、前記ストリーミングセッションの利用可能な帯域幅の一部であるＲＴＣＰ帯域幅が、前記ＲＴＣＰフィードバックメッセージに割り当てられている、コンピュータ可読媒体。
【請求項１９】
前記クライアントの前記プロセッサによって実行されたときに、前記クライアントに、請求項２乃至請求項１３のいずれかに記載の前記方法を実行させる命令をさらに格納している、請求項１８記載のコンピュータ可読媒体。
【請求項２０】
ＲＴＰプロトコルおよびＲＴＣＰプロトコルを使用して提供される少なくとも１つのストリーミングセッションをクライアントに提供するストリーミングサーバと、請求項１６または請求項１７記載のクライアントと、を備えるシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公表番号】特表２００７−５１５８７２（Ｐ２００７−５１５８７２Ａ）
【公表日】平成１９年６月１４日（２００７．６．１４）
【国際特許分類】
【出願番号】特願２００６−５４０３６９（Ｐ２００６−５４０３６９）
【出願日】平成１６年１１月２４日（２００４．１１．２４）
【国際出願番号】ＰＣＴ／ＥＰ２００４／０１３３４２
【国際公開番号】ＷＯ２００５／０５０９４５
【国際公開日】平成１７年６月２日（２００５．６．２）
【出願人】（０００００５８２１）松下電器産業株式会社 (73,050)
【Ｆターム（参考）】
【公表日】平成１９年６月１４日（２００７．６．１４）
【国際特許分類】
【出願日】平成１６年１１月２４日（２００４．１１．２４）
【国際出願番号】ＰＣＴ／ＥＰ２００４／０１３３４２
【国際公開番号】ＷＯ２００５／０５０９４５
【国際公開日】平成１７年６月２日（２００５．６．２）
【出願人】（０００００５８２１）松下電器産業株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]