JP2007537640A - パケット化データのビットレートの適合化とデータパケットの再送信との間の連携 - Google Patents

Abstract

パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善する方法は、第１のビットレートを用いてサーバからクライアントへデータパケットを送信し；送信済みデータパケットをサーババッファに格納し、次いで送信済みデータパケットをクライアントバッファに格納し、上記サーバへの送信中に、送信済みデータパケットの欠陥に関する欠陥情報を通知し、上記通知された欠陥情報を上記サーバにより分析して、上記サーババッファに格納したデータパケットの再送信が必要かどうかを判定し、さらに、上記クライアントバッファの状態に関するクライアントバッファ情報を上記サーバへ通知し、上記クライアントバッファ情報を上記サーバにより分析して、データパケットの再送信が必要かどうかの決定を行う。

Description

本発明は、パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するための、方法、システム、クライアント、サーバ、コンピュータプログラムおよびコンピュータプログラム製品に関する。

ストリーミングとは、第１の側面において、データネットワークを介してメディアストリームがクライアントへ送信される間に、クライアント側に設けられているアプリケーションが、音声ストリーム、オーディオストリームおよびビデオストリームのようなこれらの同期メディアストリームの再生を連続的に行い得ることをいう。第２の側面において、ストリーミングとは、通話用アプリケーションのようなリアルタイムの低遅延アプリケーションでもある。

ストリーミングサービスの最上位に位置付けることができるアプリケーションは、オン・デマンドおよびライブの情報配信用アプリケーションに分類することができる。第１のカテゴリの例としては、音楽用およびニュース・オンデマンド用アプリケーションがある。ラジオ番組とテレビ番組のライブの配信は第２のカテゴリの例である。リアルタイムの低遅延用アプリケーションとしては、例えば、マルチメディア（テレビ）電話やボイス・オーバーＩＰおよび任意のタイプの通話用マルチメディアアプリケーションなどがある。

固定インターネットプロトコル（ＩＰ）ネットワークを介するストリーミングは今日ではすでに主要なアプリケーションとなっている。インターネット技術特別調査委員会（ＩＥＴＦ）と、ワールドワイドウェブコンソーシアム（Ｗ３Ｃ）とが、固定ＩＰストリーミングサービスで使用する１組のプロトコルを開発しているのものの、完全な標準化ストリーミング用フレームワークはまだ規定されていない。第３世代パートナプロジェクト（３ＧＰＰ）が開発した規格に準拠する第３世代（３Ｇ）移動通信システムの場合、３Ｇパケット交換型ストリーミングサービスは、例えば、ダウンロード型アプリケーションとマルチメディアコンテンツなどの３Ｇマルチメディア・メッセージサービス（ＭＭＳ）と通話ストリーミングサービスと間のギャップを満たすものである。ＰＳＳについては、技術仕様３ＧＰＰ ＴＳ２６.２３４Ｖ０．３．０“透過的エンドツーエンドパケット交換型ストリーミングサービス（ＰＳＳ）；プロトコル並びにコーデック（リリース６）ＴＳＧ−ＳＡ４ ＰＳＭ ＳＷＧ内部作業用ドラフト”（以後本明細書でＴＳ２６.２３４として示す）に詳細な記載がある。

ＰＳＳによって、移動ストリーミング用アプリケーションが可能となり、端末装置の複雑さが通話サービスに必要な複雑さに比べて少なくなる。というのは、メディア入力装置およびエンコーダが不要となり、かつ、さらに複雑さの少ないプロトコルを利用できるからである。ＰＳＳには、基本セットのストリーミング制御プロトコルと、トランスポートプロトコルと、メディアコーデックと、シーン記述プロトコルとが含まれている。

ＴＳ２６.２３４から採った図１は、コンテンツサーバすなわちメディアサーバとクライアント間での、ストリーミング可能コンテンツとストリーミング不能コンテンツ双方の転送を制御するＰＳＳプロトコルスタックを概略的に描く図である。

例えば、ストリーミングを目的として作成されたものではない（端末装置に保存されたＭＭＳクリップなどの）マルチメディアコンテンツ、静止画像、ビットマップ・グラフィックとベクトル・グラフィック、テキスト、時間調節テキスト（timedtext）および合成オーディオのようなストリーミング不能コンテンツ１０６が、ハイパーテキスト転送プロトコル（ＨＴＴＰ）１０７によって転送される。上記ハイパーテキスト転送プロトコルは、基底に在るトランスポート制御プロトコル（ＴＣＰ）１０８と、さらに基底に在るＩＰ１０５のサービスとを利用するプロトコルである。

ビデオ、オーディオおよび音声のようなストリーミング可能コンテンツ１０１は、アダプテーション層１０３のリアルタイムトランスポートプロトコル（ＲＴＰ）１０２のペイロード形式へまず変換される。前記ＲＴＰは、基底に在るユーザデータグラムプロトコル（ＵＤＰ）１０４のサービスを利用することによって、リアルタイムデータまたはストリーミングデータの送信手段を提供し、該ユーザデータグラムプロトコルはさらに、基底に在るＩＰプロトコル１０５のサービスを利用する。

ＩＥＴＦコメント要求（ＲＦＣ）ドキュメント１８８９に指定されているＲＴＰ１０２“ＲＴＰ：リアルタイムアプリケーション用トランスポートプロトコル”には、双方向型オーディオおよびビデオのような、リアルタイム特性を有するデータ用のエンドツーエンド配信サービスが記載されている。上記サービスにはペイロードタイプ識別子と、シーケンス番号と、タイムスタンプと、配信モニタとが含まれる。ＲＴＰそれ自体は、タイムリな配信や別のサービス品質の保証を行うメカニズムを何も提供せずに上記を行う下位層サービスに依拠している。ＲＴＰは、配信を保証したり、順番を誤った配信を防止したり、あるいは、基底に在るネットワークが信頼性の高いものであり、パケットを順番に配信するものであることを仮定したりするものではない。ＲＴＰに含まれているシーケス番号によって、受信機が送信機のパケットシーケンスの再構成を行うことが可能になるが、例えばビデオの復号化の際などに必ずしも順番にパケットを復号化することなく、上記シーケンス番号を用いてパケットの適切な位置を決定するために使用することができる。

サービス品質をモニタし、ＲＴＰに基づいて行われている現在進行中のセッション時の参加者に関する情報を伝えるＲＴＰ制御プロトコル（ＲＴＣＰ）は、実際にデータを搬送するＲＴＰ１０２と密接にリンクしている。ＲＴＣＰは、データパケットの場合と同じ配信メカニズムを利用するセッションのすべての参加者への周期的送信制御パケットに基づくものである。ＲＴＣＰは、データ転送の品質に関するフィードバック情報を出力する。このフィードバック情報の出力は、トランスポートプロトコルとしてのＲＴＰの役割の不可欠な部分であり、別のトランスポートプロトコルのフロー制御機能および輻輳状態制御機能に関係するものである。上記フィードバック情報をデータ転送時の障害診断に直接役立てることも可能である。上記フィードバック機能はＲＴＣＰ送信機リポートおよび受信機リポートによって実行される。

ＲＴＣＰが出力した品質フィードバックに基づいて、ＰＳＳは、送信中にＲＴＰパケットが紛失した際に遭遇する品質の低下を和らげるＲＴＰの再送信方式を提供する。紛失パケットがＲＴＣＰベースの品質フィードバックによって示され、サーバからクライアントへの効率の良い再送信が行われる。この再送信は、或る送信深度までサーバがすでに送信したＲＴＰパケットの格納を必要とし、例えば最後の５秒内で送信されたすべてのＲＴＰパケットをサーバ側のＲＴＰパケット送信バッファに格納して、これらＲＴＰパケットの再送信のケースを考慮する必要がある。

ストリーミング不能コンテンツの場合、ＨＴＴＰ１０７の組み込み型セッションの確立機能と、制御処理機能とがあればコンテンツを転送するために十分であるのに対して、ストリーミング可能コンテンツの場合、例えば、ＲＴＰ／ＵＤＰ／ＩＰを介してコンテンツサーバからクライアントへ転送されるストリーミングビデオの開始、停止および中断を行うために、高度のセッション確立と制御プロトコルとを使用する必要がある。このタスクは、リアルタイムストリーミングプロトコル（ＲＴＳＰ）１０９により実行され、このリアルタイムストリーミングプロトコルは基底に在るＴＣＰ１０８か、基底に在るＵＤＰ１０４かのいずれかを使用する。少なくともストリーミングセッションを確立するために、ＲＴＳＰはプレゼンテーション記述１１０を必要とする。このようなプレゼンテーション記述１１０は、例えば、セッション記述プロトコル（ＳＤＰ）ファイルの形で利用可能にされる。前記ＳＤＰファイルには、例えば、セッション名並びに著者と、提示すべきメディアタイプと、例えばアドレスと、ポートと、フォーマット等々の前記メディアを受信するための情報と、メディアのビットレートなどのセッション記述とが含まれる。

ＰＳＳには複数のプロトコルと機能とが含まれ、このプロトコルと機能とを利用して、ＰＳＳセッションは、送信レートとコンテンツレート（ビットレートなど）とを利用可能なネットワークリソースに適合させることが可能となる。このレート適合化の目標は、言うまでもなく、メディアの中断のない再生を維持しながら、利用可能なリソースを有するエンドユーザにできる限り最高の品質を経験させることである。レートの適合化は、利用可能なネットワークリソースの推定と、利用可能なネットワークリンクレートへの送信レートの適合化とを必要とする。上記レートの適合化によって、ネットワークバッファのオーバフローを防止することが可能となり、それによってパケット損失の回避が可能となる。送信済みメディアのリアルタイムのプロパティを考慮して、メディアの着信が遅すぎて無用のものならないようにする必要がある。このことは、メディアのコンテンツレート（コンテンツのビットレートなど）の送信レートの適合を必要とする。

サーバができるだけ多くのデータをそのままクライアントバッファの中へ配信できるようにしながら、クライアントが有用なデータを破棄しなければならなくなる結果が生じるバッファのオーバフローを回避するために、クライアントバッファのフィードバックを行うための機能がＰＳＳの範囲で定義される。こうすることによって、サーバは、クライアント側でのバッファの処理状況を子細にモニタし、サーバ側ができることを行って、クライアントのバッファのアンダフローの回避を図るようにすることが可能となる。クライアントは、サーバが利用できるバッファ空間の量と、所望の目標レベルの保護とを指定する。所望のレベルの保護が達成されると、サーバは、メディア品質を高める上記保護レベルの維持に必要なリソースを上回る任意のリソースを利用することが可能となる。サーバはバッファフィードバック情報を利用して、バッファのアンダフロー並びにその結果として生じる再生の中断を回避するためにメディア品質を下げる必要があるかどうかの判定を行うことが可能となる。サーバに対して、レートの適合化を行う１つの方法は、複数の符号化済みバージョンの同じコンテンツを保持することであり、該符号化ビットレートが識別基準としての役割を果たすことになる。この場合、クライアントバッファの状態に依存して違った形で符号化された符号化済みコンテンツ間で切替えを行うことによってレートの適合化を行うようにしてもよい。

ＰＳＳ用のレートの適合化は、送信レートおよびコンテンツレートがサーバによって制御されるという意味でサーバ中心のものとなる。サーバは、クライアントとネットワークの状態に関する情報ソースとしてＲＴＣＰとＲＴＳＰとを利用する。

ＰＳＳにおいてレートの適合化を処理するために、クライアントバッファのフィードバック信号の機能がＰＳＳクライアントとＰＳＳサーバとによってサポートされていることが望ましい。クライアントバッファのフィードバック信号の機能をサポートするＰＳＳクライアントとＰＳＳサーバに対して、少なくとも以下の部分を実現することが望ましい。
− クライアントがレートの適合化のためにＲＴＳＰを通じてサーバへ出力する（バイトなどで表わされる）バッファサイズの信号送信。
− クライアントバッファ内で最も古いパケットのシーケンス番号（“最も古いバッファ済みシーケンス番号”ＯＢＳＮ）のＲＴＣＰを介する、サーバへの信号送信。このＯＢＳＮ情報は、例えば、ＲＴＣＰアプリケーション（ＡＰＰ）パケットの形でクライアントからサーバへ送信してもよい。

上記バッファサイズと、ＯＢＳＮパラメータとを用いて、並びに、ＲＴＣＰ受信機リポートの中に予め含まれている“最大受信シーケンス番号”ＨＲＳＮによって、サーバは、最後に受信されたＲＴＣＰリポートの送信時刻におけるクライアントバッファ内のバイト数を算出することができる。

上記算出したクライアントバッファの充填レベルに基づいて、サーバはバッファのオーバフローを回避することが可能となる。この充填レベルによって、サーバはバッファレベルの低下時点を検出し、それによってアンダフローの防止を試みるように反応することが可能にもなる。最大シーケンス番号のパケットのタイムスタンプと、最も古いシーケンス番号のパケットのタイムスタンプと、信号送信されていれば、最も古いシーケンス番号のパケットの再生の遅延とを参照することによって、クライアントバッファがアンダフローする前の時点をサーバにより推定することが可能となる。クライアントがアンダフローする前の推定時刻の正確さは再生の遅延によって改善される。例えば、低いフレームレートのビデオの場合、再生の遅延によって、クライアント側でのバッファ処理時間の合計が著しい影響を受ける可能性がある。

これに対して、ＰＳＳにおけるレートの適合化機能とＲＴＰの再送信機能との組み合わせは問題を引き起こす原因になる。

第１に、サーバがクライアントから受信したフィードバック情報に基づいてクライアントへ転送するパケットストリームのビットレートを変更することによりレートの適合化を行うとき、サーバによってその送信バッファのメモリ内容の一括消去が行われる。このような一括消去処理は、ＲＴＰの再送信方式の適切な機能に厳しい干渉を引き起こしたり、それを作動不能にしたりさえするものである。この再送信方式は、ＲＴＰパケットの損失に起因して生じる可能性のある将来のＲＴＰパケットの再送信が行われるケースを考慮して或る一定の送信深度に対してすでに送信済みのＲＴＰパケットの格納に基づいている。例えば、前記一括消去に起因してサーバ側ではもはや利用不能となったＲＴＰパケットの再送信が必要となった場合、前記サーバは、（例えば適切なＲＴＰパケットを見つけるためにサーバ３ＧＰファイル内のヒントトラックによる再反復を介して）前記ＲＴＰパケットを再度取得する必要が生じる場合があり、この再度の取得が追加の遅延を引き起こす原因になったり、再度の取得が全く不可能になったりする場合があり得る。前記ＲＴＰパケットの前記遅延または前記不足は、前記ＲＴＰの最上位で実行しているアプリケーションに直接影響を与えることになり、例えば、関係するストリーミングメディアの再生がフリーズしたり、機能停止が生じたりする可能性さえある。

（例えば、ＲＴＣＰ ＡＰＰパケットを介する）レートの適合化というコンテキストでクライアントがリポートするＯＢＳＮの方が、ＲＴＰの再送信というコンテキストで再送信用として要求されるＲＴＰパケットのシーケンス番号よりも大きくなったり、あるいは、該シーケンス番号に非常に近いものであったりする場合には、別の問題が生じることになる。前記リポートされたＯＢＳＮにより特定されるＲＴＰパケットは、復号化を行う目的のために、（例えば表示のために待機するためにポストデコーダバッファ入れられるなどの）クライアントがＲＴＰパケットバッファから取り出す対象となる第１のＲＴＰパケットである。したがって、リポートされたＯＢＳＮよりも小さなシーケンス番号を持つＲＴＰパケットの再送信はいずれも不要となり、このような再送信は帯域幅の浪費となる。

上述の問題を考慮して、特に、パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するための、方法、システム、クライアントサーバ、コンピュータプログラムおよびコンピュータプログラム製品を提供することが本発明の目的である。

本発明の第１の態様によれば、パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善する方法であって、第１のビットレートを用いてサーバからクライアントへデータパケットを送信し、前記送信されたデータパケットの少なくとも１つを少なくとも１つのサーババッファに少なくとも一時的に格納し、前記送信されたデータパケットのうちの少なくとも１つのデータパケットをクライアントバッファに少なくとも一時的に格納し、前記サーバへの前記送信中に、前記送信されたデータパケットの少なくとも１つの欠陥に関する欠陥情報を通知し、前記通知された欠陥情報を前記サーバにより分析して、前記サーババッファに格納された少なくとも１つのデータパケットを前記サーバから前記クライアントへ再送信する必要があるかどうかを判定し、前記クライアントバッファの状態に関するクライアントバッファ情報を前記サーバへ通知し、第２のビットレートで前記サーバから前記クライアントへデータパケットを送信し、ここで、前記第２のビットレートは、前記クライアントバッファ情報に基づいて少なくとも部分的に決定され、前記第１のビットレートで送信され、前記サーババッファにされる少なくとも１つのデータパケットは、前記第２のビットレートで前記サーバから前記クライアントへの前記データパケットの前記送信が始まるとき、前記サーババッファにさらに格納されること、を有する方法が提案される。

前記データパケットは、例えばデータビットなどの情報搬送用シンボルから成るデータストリームの論理的単位または物理的単位を表わすものであってもよいし、データストリームの変調された表現であってもよい。例えば、前記データストリームは、少なくとも部分的にリアルタイム・トランスポートプロトコルＲＴＰに基づいて、ストリーミングセッション時に前記サーバから前記クライアントへ送信されるメディアストリームであってもよい。これに対応して、前記サーバは、その場合、コンテンツサーバまたはストリーミングメディアサーバであってもよく、前記クライアントはストリーミングクライアントであってもよい。さらに前記データパケットはＲＴＰパケットであってもよい。この場合、ユニキャストモードまたはマルチキャストモードで前記ストリーミングを実行してもよい。さらに一般的な意味では、前記サーバおよびクライアントはデータ送信システムにおける送信機と受信機と理解してもよい。前記データパケットの前記送信は、プロトコルによって実行および／または制御される物理的または論理的送信であってもよい。物理的送信媒体は、無線接続か、有線接続かのいずれかの媒体であってもよく、あるいは無線および有線のセグメントから成るものであってもよい。前記データパケットの前記送信は第１のビットレートで実行され、該送信は論理的送信または物理的送信を意味するものであってもよい。例えば、上記ビットレートは、ソース量および／または前記データパケットのコンテンツに対して実行されるチャネル符号化の量によって、あるいは、前記データパケットの送信に使用する送信チャネルまたはベアラの個数および／または送信容量によって決定してもよい。

前記サーバ側では、前記クライアントへ送信される少なくとも１つのデータが少なくとも一時的にサーババッファに格納される。このバッファは再送信用バッファを表わし、例えば、自動再送信要求プロトコルの制御によって、あるいは、リアルタイム・トランスポート制御プロトコルＲＴＣＰのサービスに基づいて、クライアント側で正しく受信されなかったデータパケットを上記再送信用バッファから新規に送信することも可能である。前記サーババッファ内での前記少なくとも１つのデータパケットの前記格納は、所定時刻または動的に適合させた時刻後に前記少なくとも１つのパケットによって前記サーババッファから取り出されるようにした時間制限のある格納にしてもよい。

前記クライアント側では、前記クライアントへ送信された、および、前記クライアント側で受信された少なくとも１つのデータパケットが前記クライアントバッファに少なくとも一時的に格納される。前記クライアントバッファから、前記クライアント内の格納済みデータパケットを別の処理へ導くことも可能であり、例えば、アプリケーションによって前記クライアントバッファから前記データパケットを再生することも可能である。前記クライアントバッファは、データパケットが前記クライアントバッファ側に着信する際に用いるレートの変動（サーバとクライアント間での物理的および論理的送信媒体の送信特性（遅延、損失）に起因して生じる変動）を可能にする補償バッファとして機能することも可能である。

前記クライアントは欠陥情報を前記サーバへ通知し、前記欠陥情報は前記サーバから前記前記クライアントへのデータパケットの送信中の少なくとも１つのデータパケットの欠陥に関係する。例えば、前記欠陥が１乃至いくつかのデータパケットの損失または破損を示す場合もある。欠陥情報の１例として、正しく受信した最後のデータパケットの（例えばシーケンス番号のような）識別子の通知を挙げることができる。特に所定時刻が過ぎてしまっている場合、前記データパケットサーバが１乃至いくつかのパケットを前記受信機側で正しく受信していないことを前記欠陥情報から導き出し、次いで、データパケットの再送信を試みるようにしてもよい。前記通知は、例えば、リアルタイム・トランスポート制御プロトコルなどのプロトコルに基づくものであってもよい。前記欠陥情報に基づいて、前記サーバは、すでに送信済みで、しかも破損または紛失したデータパケットの再送信が必要かどうかを判定することも可能である。次いで、前記サーババッファから上記データパケットをフェッチし、新しく前記クライアントへ送信するようにしてもよい。

前記クライアントは、前記クライアントバッファの状態に関するクライアントバッファ情報を前記サーバへ通知する。このクライアントバッファ情報は、例えば、クライアントバッファの中に残されている容量であってもよいし、あるいは、前記クライアントバッファに格納されたある特定のデータパケットのシーケンス番号、特に前記クライアントバッファに格納された最も古いデータパケット、すなわち、別の処理を行うために前記クライアントバッファからまだ読み出されていないデータパケットであって、前記クライアントバッファに格納されたすべてのデータパケットの中で最大の格納時間を有するデータパケットのシーケンス番号を表わすものであってもよい。これに対応して、前記最も古いデータパケットは、別の処理を行うために前記クライアントバッファから読み出すべき次のデータパケットとなる。

前記通知されたクライアントバッファ情報に基づいて、前記サーバは前記第１のビットレートを第２のビットレートへ変更する。このパケット化データのビットレートの適合化ステップは、例えば前記クライアントバッファのオーバフローやアンダフローの回避のために必要となる場合もあるし、ソース量および／または前記データパケットのコンテンツに対して実行されるチャネル符号化の量、あるいは、前記データパケットの送信に使用する送信チャネルまたはベアラの個数および／または送信容量を必要とする場合もある。

本発明の第１の態様によれば、前記第２のビットレートで前記サーバから前記クライアントへの前記データパケットの前記送信が始まるとき、前記第１のビットレートで送信され前記サーババッファに格納された少なくとも１つのデータパケットが前記サーババッファにさらに格納される。したがって、ビットレートを変更するとき、第１のビットレートで送信されたデータパケットを含むサーババッファは、従来技術によるシステムでの場合のようには一括消去されないことになる。これとは対照的に、第１のビットレートで転送された格納済みのデータパケットは前記サーババッファ内に保持され、例えば、通知された欠陥情報に依存して決まる場合がある継続時間の後、前記サーババッファから削除される。こうすることによって、第２のビットレートでデータパケットの送信がすでに始まっているときでさえ、第１のビットレートで送信されたデータパケットのために再送信が必要である限り、データパケットの再送信の成功は可能となる。従来技術の場合とは対照的に、本発明によれば、第１のビットレートで送信された破損データパケットや紛失データパケットが、第１のビットレートから第２のビットレートへのパケット化データのビットレートの適合化のインスタンスで、前記サーババッファの一括消去に起因してサーババッファ内で再送信用として利用不能となるケースはもはや生じる可能性はなくなり、したがって、前記データパケットによるアプリケーションの遅延や中断が回避されることになる。

本発明の第１の態様の推奨実施形態によれば、前記通知された欠陥情報に基づいて前記サーバが決定した継続時間の間、前記第１のビットレートで送信され、前記サーババッファに格納された前記少なくとも１つのデータパケットが前記サーババッファに格納される。上記処理は前記サーババッファの期限切れ時間内にデータパケットを割り当てることにより達成可能である。

本発明の第１の態様の推奨実施形態によれば、前記第１のビットレートで送信され、前記サーババッファに格納された前記少なくとも１つのデータパケットの前記サーババッファからの除去は、前記通知されたクライアントバッファ情報に応じて決まることになる。前記少なくとも１つのデータパケットは、前記データパケットの再送信がもはや必要でなくなくなったり、役に立たなくなったりしたと前記クライアントバッファ情報から判定された場合、例えばサーババッファから削除してもよい。

本発明の第１の態様の推奨実施形態によれば、前記クライアントバッファ情報は前記クライアントバッファに格納された最も古いデータパケットの識別子である。前記“古い”という用語は、前記データパケットがクライアントバッファに格納された場合のタイムインスタンスに関係するものと理解すべきである。前記識別子は、例えば前記最も古いデータパケットのシーケンス番号であってもよい。

本発明の第１の態様の推奨実施形態によれば、前記サーバから前記クライアントへの前記データパケットの前記送信は、リアルタイム・トランスポートプロトコルＲＴＰに少なくとも部分的に基づいて行われ、前記欠陥情報および前記クライアントバッファ情報の前記信号送信は、リアルタイム・トランスポート制御プロトコルＲＴＣＰに少なくとも部分的に基づいて行われる。この時、前記データパケットはＲＴＰパケットとなり、例えば、ＲＴＣＰアプリケーションＡＰＰパケットを用いることによって、最も古いバッファシーケンス番号ＯＢＳＮなどの前記クライアントバッファ情報の通知を行うことも可能となる。

本発明の第１の態様の推奨実施形態によれば、３ＧＰＰパケット交換ストリーミングサービスＰＳＳに従って、前記データパケットは、前記サーバから前記クライアントへ送信されるメディアストリームと関連づけられる。

本発明の第１の態様によれば、パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するためのさらに別のシステムと、クライアントと、サーバとがさらに提案される。

本発明の第１の態様の推奨実施形態によれば、パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善する方法がさらに提案され、該方法は、第１のビットレートでサーバからクライアントへデータパケットを送信し、前記送信されたデータパケットの少なくとも１つを少なくとも１つのサーババッファに少なくとも一時的に格納し、前記送信されたデータパケットの少なくとも１つをクライアントバッファに少なくとも一時的に格納し、前記サーバへの前記送信中に、前記送信済みデータパケットの少なくとも１つの欠陥に関する欠陥情報を通知し、前記クライアントバッファの状態に関するクライアントバッファ情報を前記サーバへ通知し、ここで、前記通知されたクライアントバッファ情報は前記サーバにより分析されて、前記データパケットの前記送信の前記第１のビットレートが第２のビットレートへ変更され、前記通知された欠陥情報と、前記通知されたクライアントバッファ状態情報とに基づいて、データパケットの再送信が必要かどうかを判定し、データパケットの再送信の必要性が判定された場合のみ、前記サーババッファに格納された少なくとも１つのデータパケットを前記サーバから前記クライアントへ再送信すること、を有する。

前記データパケットは、例えばデータビットなどの情報搬送用シンボルから成るデータストリームの論理的単位または物理的単位を表わすものであってもよいし、データストリームの変調された表現であってもよい。例えば、前記データストリームは、少なくとも部分的にリアルタイム・トランスポートプロトコルＲＴＰに基づいて、ストリーミングセッション時に前記サーバから前記クライアントへ送信されるメディアストリームであってもよい。これに対応して、前記サーバは、その場合、コンテンツサーバまたはストリーミングメディアサーバであってもよく、前記クライアントはストリーミングクライアントであってもよい。さらに前記データパケットはＲＴＰパケットであってもよい。この場合、ユニキャストモードまたはマルチキャストモードで前記ストリーミングを実行してもよい。さらに一般的な意味では、前記サーバおよびクライアントはデータ送信システムにおける送信機と受信機と理解してもよい。前記データパケットの前記送信は、プロトコルによって実行および／または制御される物理的または論理的送信であってもよい。物理的送信媒体は、無線接続か、有線接続かのいずれかの媒体であってもよく、あるいは無線および有線のセグメントから成るものであってもよい。前記データパケットの前記送信は第１のビットレートで実行され、該送信は論理的送信または物理的送信を意味するものであってもよい。例えば、上記ビットレートは、ソース量および／または前記データパケットのコンテンツに対して実行されるチャネル符号化の量によって、あるいは、前記データパケットの送信に使用する送信チャネルまたはベアラの個数および／または送信容量によって決定してもよい。

前記サーバ側では、前記クライアントへ送信される少なくとも１つのデータが少なくとも一時的にサーババッファに格納される。このバッファは再送信用バッファを表わし、例えば、自動再送信要求プロトコルの制御によって、あるいは、リアルタイム・トランスポート制御プロトコルＲＴＣＰのサービスに基づいて、クライアント側で正しく受信されなかったデータパケットを上記再送信用バッファから新規に送信することも可能である。前記サーババッファ内での前記少なくとも１つのデータパケットの前記格納は、所定時刻または動的に適合させた時刻後に前記少なくとも１つのパケットによって前記サーババッファから取り出されるようにした時間制限のある格納にしてもよい。

前記クライアント側では、前記クライアントへ送信された、および、前記クライアント側で受信された少なくとも１つのデータパケットが前記クライアントバッファに少なくとも一時的に格納される。前記クライアントバッファから、前記クライアント内の格納済みデータパケットを別の処理へ導くことも可能であり、例えば、アプリケーションによって前記クライアントバッファから前記データパケットを再生することも可能である。前記クライアントバッファは、データパケットが前記クライアントバッファ側に着信する際に用いるレートの変動（サーバとクライアント間での物理的および論理的送信媒体の送信特性（遅延、損失）に起因して生じる変動）を可能にする補償バッファとして機能することも可能である。

前記クライアントは欠陥情報を前記サーバへ通知し、前記欠陥情報は前記サーバから前記前記クライアントへのデータパケットの送信中の少なくとも１つのパケットの欠陥に関係する。例えば、前記欠陥が１乃至いくつかのデータパケットの損失または破損を示す場合もある。欠陥情報の１例として、正しく受信した最後のデータパケットの（例えばシーケンス番号のような）識別子の通信を挙げることができる。特に所定時刻が過ぎてしまっている場合、前記データパケットサーバが１乃至いくつかのパケットを前記受信機側で正しく受信していないことを前記欠陥情報から導き出し、次いで、データパケットの再送信を試みるようにしてもよい。前記通知は、例えばリアルタイム・トランスポート制御プロトコルＲＴＰなどのプロトコルに基づくものであってもよい。

前記クライアントは、前記クライアントバッファの状態に関するクライアントバッファ情報を前記サーバへ通知する。このクライアントバッファ情報は、例えば、クライアントバッファの中に残されている容量であってもよいし、あるいは、前記クライアントバッファに格納されたある特定のデータパケットのシーケンス番号、特に前記クライアントバッファに格納された最も古いデータパケット、すなわち、別の処理を行うために前記クライアントバッファからまだ読み出されていないデータパケットであって、前記クライアントバッファに格納されたすべてのデータパケットの中で最大の格納時間を有するデータパケットのシーケンス番号を表わすものであってもよい。これに対応して、前記最も古いデータパケットは、別の処理を行うために前記クライアントバッファから読み出すべき次のデータパケットとなる。

前記通知されたクライアントバッファ情報に基づいて、前記サーバは前記第１のビットレートを第２のビットレートへ変更することも可能である。このパケット化データのビットレートの適合化ステップは、例えば前記クライアントバッファのオーバフローやアンダフローの回避のために必要となる場合もあるし、ソース量および／または前記データパケットのコンテンツに対して実行されるチャネル符号化の量、あるいは、前記データパケットの送信に使用する送信チャネルまたはベアラの個数および／または送信容量を必要とする場合もある。

本発明の第２の態様によれば、データパケットの再送信が必要であると決定された場合のみ、前記サーバから前記クライアントへの、前記サーババッファに格納された少なくとも１つのデータパケットの再送信が実行され、この決定は、前記信号送信済みの欠陥情報および前記信号送信されたクライアントバッファ状態情報に基づいて行われる。従来技術の場合とは対照的に、再送信に関する決定は単に通知された欠陥情報に基づいて行われるにすぎず、したがって、本発明の第２の態様によれば、通知されたクライアントバッファ情報は上記決定時にも考慮されることになる。例えば、前記欠陥情報によって或る一定のデータパケットの再送信の必要性が示された場合でも、前記クライアントバッファ情報によって、特定のデータパケットの再送信が不要であることがそれでも示される場合がある。その理由として、例えば、上記データパケットが前記クライアントバッファにすでに格納されていたり、すでに格納されてしまっていて、少し前にさらに処理されてしまっていたり、あるいは、該データパケットが、再送信に成功した場合でさえ、前記クライアント側への着信が遅すぎて無価値なものになっていたりする理由が挙げられる。したがって、本発明の第２の態様によれば、データパケットの再送信と、パケット化データのビットレートの適合化とを組み合わせた従来技術のシステムで生じるデータパケットの無用な再送信の完全な回避が可能となる。

本発明の第２の態様の推奨実施形態によれば、前記送信中に欠陥を受けた少なくとも１つのデータパケットのシーケンス番号の決定が前記欠陥情報によって可能となり、前記クライアントバッファ情報が、前記クライアントバッファに格納された最も古いデータパケットのシーケンス番号であり、データパケットの再送信が必要かどうかの前記決定が、前記少なくとも１つの破損データパケットと、前記最も古いデータパケットとの前記シーケンス番号の差に応じて決まることになる。これによって、例えば、前記最も古いデータパケットよりも新しいデータパケットのみを再送信するように要求することによって、不必要な再送信の回避が可能となる。上記要求は、時間と共に増加するデータパケットのシーケンス番号に対して前記破損データパケットの再送信を行うために、前記破損データパケットと前記最も古いデータパケットとの前記シーケンス番号の前記差が０よりも大きいものでなければならないというという要求につながるものである。

本発明の第２の態様の推奨実施形態によれば、前記サーババッファに格納されたデータパケットは、該サーババッファの関連するデータパケットのシーケンス番号と、前記最も古いデータパケットの前記シーケンス番号との差に応じて削除される。例えば、前記最も古いデータパケットよりも小さなシーケンス番号を有する（すなわち、前記クライアントバッファ内の前記最も古いデータパケットよりも古い）すべてのデータパケットを除去できれば好適なものとなる。次いで、前記差が０よりも小さくなれば、前記データパケットは削除される。

本発明の第２の態様の推奨実施形態によれば、前記サーバから前記クライアントへの前記データパケットの前記送信は、リアルタイム・トランスポートプロトコルＲＴＰに少なくとも部分的に基づいて行われ、前記欠陥情報および前記クライアントバッファ情報の前記信号送信は、リアルタイム・トランスポート制御プロトコルＲＴＣＰに少なくとも部分的に基づいて行われる。この時、前記データパケットはＲＴＰパケットとなり、例えば、ＲＴＣＰアプリケーションＡＰＰパケットを用いることによって、最も古いバッファシーケンス番号ＯＢＳＮなどの前記クライアントバッファ情報の信号送信を行うことも可能となる。

本発明の第２の態様の推奨実施形態によれば、３ＧＰＰパケット交換ストリーミングサービスＰＳＳに従って、前記データパケットは、前記サーバから前記クライアントへ送信されるメディアストリームと関連づけられる。

本発明の第２の態様の推奨実施形態によれば、パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するためのさらに別のシステムと、クライアントと、サーバとがさらに提案される。

本発明によれば、上述の方法ステップのうちのいずれかをプロセッサに実行にさせるように作動可能な命令を有するコンピュータプログラムがさらに提案される。

上述の方法ステップのうちのいずれかをプロセッサに実行にさせるように作動可能な命令を有するコンピュータプログラムを含むコンピュータプログラム製品がさらに提案される。

本明細書で後述する実施形態から、本発明の上記局面並びにその他の局面は明らかにし、該実施形態を参照しながら解明することにする。

本発明は、パケット化データビットレートの変更の際、サーバがその再送信用バッファを一括消去しないように要求することによって、および、クライアントからフィードバックされたクライアントバッファ情報によって再送信パケットが実際に必要である旨が示された場合にのみ、データパケットを再送信するように要求することによって、パケット化データのビットレートの適合化と、データパケットの再送信との間の連携の改善を提案するものである。以下、第３世代パートナプロジェクト（３ＧＰＰ）パケット交換型ストリーミングサービス（ＰＳＳ）というコンテキストで本発明の例示の実施形態を提示することにする。しかし、本発明は決してＰＳＳでのアプリケーションに限定されるものではなく、パケット化データのビットレートの適合化と、データパケットの再送信とをまとめて実行するすべての種類の通信システムにおいても同様に良好に利用可能であることに留意されたい。

図２は、本発明に基づいて、パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するための、例示システム２０の基本構成要素を描く図である。上記システムはサーバ２１とクライアント２２とを備え、ＲＴＰデータパケットはストリーミングセッション時に前記サーバ２１から前記クライアント２２へストリームされる。このようなストリーミングセッションの１例として、例えばインターネットサーバから移動電話へのビデオのダウンロードが挙げられ、その際、前記ダウンロード処理と同時にビデオストリームが移動電話で再生される。

前記サーバ２１は、例えばコンテンツサーバや、他の任意の種類の格納媒体（サーバ２１内に置かれていても良い）からデータストリームを受信し、エンコーダインスタンス２１０において、前記データストリームを一連のリアルタイム・トランスポートプロトコル（ＲＴＰ）パケットに符号化するものである。この符号化は、例えば異なるビットレートを用いた、ビットストリームなどのデータストリーム間での切替え処理を含むものであってもよい。次いで、前記ＲＴＰパケットは送信インスタンス２１１の中へ転送され、送信インスタンス２１１は、送信チャネルを介して前記クライアント２２内の受信インスタンスへ前記ＲＴＰパケットを送信する。この送信は論理回路として理解すべきものである。すなわち前記ＲＴＰデータパケットは、サーバ２１とクライアント２２間での物理的送信を実行する下位プロトコル層へ渡されることによって実際に送信されることになる。したがって、前記送信インスタンス２１１は、例えば前記クライアント２２内のピアエンティティ２２５と通信を行うＲＴＰエンティティを表わすものであってもよい。上記送信済みＲＴＰパケットは、送信インスタンス２１１によってビットレートに応じて再送信用バッファ２１４-１〜２１４-３にそれぞれ格納される。これらのビットレートごとの再送信用バッファ２１４-１〜２１４-３は、入出力（Ｉ／Ｏ）インタフェース２１３-１〜２１３-３を介して前記送信インスタンス２１１がアクセス可能なバッファである。図２の本例では、３つの異なるビットレートがサポートされていて、実際に、データパケットのシーケンス番号により特定される７個のデータパケットが、前記サーバ２１から前記クライアント２２へ送信され、これに対応して前記ビットレートごとの再送信用バッファ２１４-１〜２１４-３の中に該７個のデータパケットが格納されることになる。ＲＴＰパケットＳＮ＝１とＳＮ＝２は前記最大ビットレートで送信され、再送信用バッファ２１４-３に格納される。次いで、前記最大ビットレートからさらに低いビットレートへのビットレートの変更が行われ、この変更ビットレートで、ＲＴＰパケットＳＮ＝３、ＳＮ＝４、ＳＮ＝５が送信され、再送信用バッファ２１４-２に格納される。さらに低いビットレートへさらなる変更を行った後、ＲＴＰパケットＳＮ＝６とＳＮ＝７とが送信され、再送信用バッファ２１４-１に格納される。クライアントバッファ情報（本例ではＲＴＣＰ ＡＰＰパケット内の前記クライアント２２から信号送信された最も古いバッファシーケンス番号）に基づいて、ビットレートの適合化／再送信制御インスタンス２１２により前記ビットレートの前記変更が開始される。上記ＯＢＳＮと、前記クライアントバッファサイズ（セッション確立中に信号送信されたものなど）と、最大受信シーケンス番号（ＨＲＳＮ、ＲＴＣＰ受信機リポートの形で信号送信されたもの）とに基づいて、前記ビットレートの適合化／再送信制御インスタンス２１２は、前記クライアントバッファ２２４を遠隔制御して、オーバフローおよび／またはアンダフローの回避を図る。前記ビットレートの適合化／再送信制御インスタンス２１２は、それぞれ、例えば異なるビットストリームを用いて、前記エンコーダへ異なるビットレート間の切替え命令を出すことにより前記エンコーダ２１０を制御して、ビットレートの変更を図るようにするものである。前記ビットレートの適合化／再送信制御インスタンス２１２は、前記入出力インタフェース２１３-１〜２１３-３をさらに制御して、異なるビットレートを有する前記ＲＴＰパケットの正しい再送信用バッファ２１４-１〜２１４-３への格納を保証する。さらに、前記再送信用バッファ２１４-１〜２１４-３に格納されているＲＴＰパケットの再送信を行う必要がある場合、この必要性は、前記クライアント２２から出される設定の欠陥情報に基づいて、前記ビットレートの適合化／再送信制御インスタンス２１２により決定され、前記ビットレートの適合化／再送信制御インスタンス２１２は、前記再送信用バッファ２１４-１〜２１４-３から前記送信インスタンス２１１への、対応するＲＴＰパケットの転送制御も行うことになる。本例によれば紛失ＲＴＰパケットに関する情報である前記欠陥情報は、前記クライアントバッファ情報の場合と同様、受信インスタンス２１５によって前記クライアント２２５から受信される。前記送信インスタンス２１１の場合と同じように、前記受信インスタンス２１５もまた論理回路と理解すべきである。すなわち、例えば前記ＲＴＣＰを介して上記クライアントバッファ情報と、上記欠陥情報との信号送信を行うようにしてもよく、この場合、前記受信インスタンス２１５は、前記クライアント２２内のピアエンティティ２２１と通信を行うＲＴＣＰエンティティを表わすことになる。

前記クライアント２２は、受信インスタンス２２５を介して前記サーバ２１から送信された前記ＲＴＰパケットを受信する。該受信インスタンス２２５は、例えばＲＴＰエンティティであってもよい。前記エンティティ２２５において、前記ＲＴＰパケットが（破損などの）損傷を受けていないかどうかのチェックが簡単なチェックサムなどにより行われる。前記ＲＴＰパケットは、損傷を受けていなければ、入出力インタフェース２２３を介してクライアントバッファ２２４に格納される。前記クライアント２２内のビットレートの適合化／再送信制御インスタンス２２２は、例えば正しく受信された最後のデータパケットのＳＮなどの損傷ＲＴＰパケットに関する情報を前記受信インスタンス２２５から受信し、例えばＨＲＳＮとＯＢＳＮの実際の値などのクライアントバッファ状態の情報を前記クライアントバッファ２２４から受信する。前記ビットレートの適合化／再送信制御インスタンス２２２は、前記欠陥情報と、前記クライアントバッファ情報の送信インスタンス２２１を介する前記サーバ２１へのフィードバックをトリガする。該サーバ２１は再度プロトコルエンティティとして理解してもよい。さらに、前記ビットレートの適合化／再送信制御インスタンス２２２は、前記入出力インタフェース２２３を制御して、前記クライアントバッファ２２４からデコーダインスタンス２２０へのＲＴＰパケットの転送をトリガすることも可能であり、前記ＲＴＰパケットは、該デコーダインスタンス２２０において、異なるビットレートを用いて（ビットストリームなどの）元のデータストリームへの復号化を行う。本例では、前記クライアントバッファ内の前記ＯＢＳＮはＯＢＳＮ＝３であり、前記クライアントバッファにはさらにＲＴＰパケットＳＮ＝４が含まれる。このように、ＲＴＰパケットＳＮ＝１とＳＮ＝２とはすでに受信され、前記クライアントバッファ２２４に格納され、前記クライアントバッファ２２４から読み出され、そして再生用として前記デコーダ２２０により復号化されている。しかし、ＲＴＰパケットＳＮ＝５、ＳＮ＝６およびＳＮ＝７は、再送信用バッファ２１４-１内にこれらＲＴＰパケットが格納されていることが示すように、すでにサーバ２１によって送信されているにもかかわらず、まだ前記クライアントバッファ２２４には格納されていない。

次に、サーバ２１からクライアント２２への転送中、ＲＴＰパケットＳＮ＝５が破損若しくは紛失した場合について考察する。この破損若しくは紛失に関する情報は、前記クライアント２２の前記ビットレートの適合化／再送信制御インスタンス２２２によって、前記サーバ２１の前記ビットレートの適合化／再送信制御インスタンス２１２へ信号送信され、ＲＴＰパケットＳＮ＝５の再送信が図られる。このＲＴＰパケットＳＮ＝５の再送信は、該ＲＴＰパケットＳＮ＝５が前記再送信用バッファ２１４-１〜２１４-３のうちの１つのバッファにまだ格納されていることを要件とする。しかし、ＲＴＰパケットＳＮ＝３、ＳＮ＝４、ＳＮ＝５が中間のビットレートを用いて送信されたこと、並びに、これらＲＴＰパケットの送信後、ＲＴＰパケットＳＮ＝６およびＳＮ＝７の送信のためにさらに低いビットレートへの変更が生じたことに留意されたい。従来技術によれば、このような変更は、通常再送信用バッファ２１４-１〜２１４-３のメモリ内容の一括消去を引き起こす原因となる。すなわちバッファに格納されているすべてのＲＴＰパケットが即座に削除される。従来技術のこのアプローチは、本事例では問題を生じることとになる。というのは、前記すべての再送信用バッファ２１４-１〜２１４-３のメモリ内容の一括消去により、現在再送信を必要とするＲＴＰパケットＳＮ＝５が含まれている再送信用バッファ２１４-２のメモリ内容も一括消去され、前記サーバ２１による上記ＲＴＰパケットの再送信を拒否するか、前記サーバがコンテンツソースから該ＲＴＰパケットを再取得できるようになるまで遅延するかのいずれかへ導かれることになり、これによって新たな符号化などが組み込まれる可能性が生じるからである。したがって、本発明は、その第一の態様によれば、ビットレートの変更時に、前記再送信用バッファ２１４-１〜２１４-３が即座に一括消去されずに、これら再送信用バッファのＲＴＰパケットがさらに保持されなければならないことを要件とするものである。したがって、本発明によれば、ＲＴＰパケットＳＮ＝５の送信時に用いたビットレートが、ＲＴＰパケットＳＮ＝６とＳＮ＝７との送信時に用いたビットレートへ変更されたにもかかわらず、ＲＴＰパケットＳＮ＝５は再送信用バッファ２１４-２の中に含まれることになる。

したがって、本発明の第１の態様は、前記ビットレートの適合化と再送信との連携を改善することである。この連携はサーバ側で容易に実現され、かつ、クライアント側での変更を必要としない。システムの最適性のレベルに応じて、ビットレートの変更後にサーバの再送信用バッファのメモリ内容の一括消去を行ってはならない、あるいは、一括消去を行わない方が望ましい旨の要求が行われる場合がある。例えばＲＴＣＰフィードバック情報やＯＢＳＮから導き出すことが可能なＲＴＰパケットの日付が期限切れになった後、前記サーバは、その再送信用バッファ２１４-１〜２１４-３から単一のＲＴＰパケットを除去することを許される場合がある。

次に、ＲＴＰパケットＳＮ＝３が送信中に破損した場合について考察する。従来技術によるシステムでは、このような状況では前記ＲＴＰパケットＳＮ＝３の再送信がトリガされることになる（この場合、ＲＴＰパケットＳＮ＝３が前記サーバ内の再送信用バッファ２１４-１〜２１４-３にまだ格納されていると仮定しているが、この仮定は、前記サーバ２１において本発明の第１の態様を適用するか、しないに関りなく、例えば再送信用バッファ２１４-２のメモリ内容の一括消去を引き起こしたかもしれないビットレートの変更が行われなかった場合の仮定である）。しかし、前記クライアントバッファ２２４内にＲＴＰパケットＳＮ＝３がすでに正しく格納されていることを示す前記クライアントバッファ２２４のＯＢＳＮ＝３に従えば、ＲＴＰパケットＳＮ＝３の再送信は実際には不要となる。例えば、前記欠陥情報のフィードバックの避けられない遅延と、前記ＲＴＰパケットの再送信の避けられない遅延並びに結果として生じるタイム・アウトに起因して、正しいバージョンおよび破損バージョンのＲＴＰパケットＳＮ＝３がクライアント２２側で異なるタイムインスタンスで受信された場合、上記状況が生じる可能性がある。別の例では、前記ＲＴＰパケットの再送信が成功したときでさえ、クライアント２２内で次に処理（例えば再生）する前記ＯＢＳＮと、再送信の対象となる前記ＲＴＰパケットの前記ＳＮとの間のシーケンス番号の差が過度に小さいため、前記クライアント２２側での該ＲＴＰパケットの受信が遅くなりすぎることを前記ＯＢＳＮが示す場合もある。

従来技術では、前記ＯＢＳＮに関する情報は、ビットレートの適合化についてしか考慮されず、再送信については考慮されていなかった。したがって、本発明の第２の態様によれば、ＲＴＰパケットを送信する前に、（破損ＲＴＰパケットに関する）欠陥情報と、（ＯＢＳＮに関する）クライアントバッファ情報との双方の情報を考慮することが提案される。

したがって、本発明の上記第２の態様によって、ビットレートの適合化と再送信との連携も改善されることになる。この連携はサーバサイト側でも容易に実現され、クライアントサイト側での変更を必要としない。システムの最適性のレベルに応じて、クライアントが再送信を要求したパケットがすでにクライアントバッファ２２４内に含まれていることが認知されたり、クライアント側への着信が遅すぎて、クライアントにとって無価値であることが認知されたりした場合、サーバは、パケットを再送信してはならない、あるいは再送信を行わない方が望ましい旨の要求が行われる場合がある。サーバがＯＢＳＮをさらに利用して、ＯＢＳＮの数以下の複数のＳＮを含むＲＴＰパケットをその再送信用バッファ２１４-１〜２１４-３から除去するように図ることも可能であり、このことは本発明の第１の態様をサーバ内で実行する場合にも同様に特段の利点となる。

図３は、本発明に基づいて、パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するための、サーバ側で行われる方法ステップの例示フローチャートを表わす図である。第１のステップ３０１でサーバ側のビットレートを設定する。このビットレートは、例えばＲＴＰを介して、例えばサーバからクライアントへ送信されるビットストリームのビットレートである。このビットレートは、前記送信用として定義されたデフォルト値であってもよく、さらに、該ビットレートは、前記クライアントからのフィードバック情報に基づいて、送信中にさらに微調整を行うことが可能であり、それによって前記クライアントバッファ内でバッファのオーバフローやアンダフローが生じないように保証することを図るものである。第２のステップ３０２で、例えばＲＴＰパケットなどのデータパケットを前記ビットストリームから生成し、次いで、ステップ３０３で前記クライアントへ送信する。ステップ３０４で、前記設定済みビットレートに従ってビットレートごとのサーババッファ（再送信用バッファ）に送信済みデータパケットを格納する。例えば再送信すべき破損データパケットのＳＮや、前記クライアント側で正しく受信された最後のデータパケットのＳＮなどの欠陥情報を、例えばＲＴＣＰを介して前記クライアントから送信し、次いでステップ３０５で前記サーバ側で受信する。同様に、ステップ３０６で、例えばＯＢＳＮなどのクライアントバッファ情報を前記サーバ側で受信する。前記欠陥情報とクライアントバッファ情報との双方に基づいて、データパケットの再送信が実際に必要かどうかをステップ３０７で判定する。データパケットの再送信が実際に必要であると判定された場合、ステップ３０８でデータパケットの再送信を実行する。データパケットの再送信が必要でない場合、あるいは、再送信が行われた後の場合、ステップ３０９でビットレートの変更が必要かどうかのチェックを行う。データパケットの再送信の必要性は、例えばＯＢＳＮなどの、ステップ３０６で受信したクライアントバッファ情報に少なくとも部分的に基づいて決定され、次いで、クライアントバッファサイズ並びにＨＲＳＮに関するさらなる情報を利用して前記チェックを行うことが可能となる。クライアントバッファのオーバフローまたはアンダフローを避けるためにビットレートの変更が必要であると判定された場合、ステップ３１０でビットレートを変更する。このステップの後、あるいは、変更が不要と判定された場合、例えばパケットの期限の時間をオーバーしていたり、ステップ３０６で受信したクライアントバッファ情報によって上記データパケットの再送信がもはや有効でないことが示されていたりするような理由のために、ビットレートごとのサーババッファからいずれかのパケットを除去して良いかどうかをステップ３１１でさらにチェックする。データパケットを除去すべき旨の判定が行われた場合、ステップ３１２でこの除去を実行する。この除去の実行後、もしくは、除去を実行しない場合、上記方法は元のステップ３０２へジャンプし、クライアントへ送信すべきさらに別のデータパケットが作成される。

図４は、本発明に基づいて、パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するための、クライアント側で行う方法ステップの例示フローチャートを表わす図である。第１のステップ４０１で、例えばＲＴＰパケットなどのデータパケットをクライアント側で受信する。ステップ４０２で、例えばチェックサムや別のエラー検出コードの処理を行うことによって、あるいは、パケットの受信シーケンス内に欠落したＳＮが存在するかどうかのチェックを行うことによって、データパケットを正しく受信したか、破損を受けたか、あるいは紛失したかのチェックを行う。正しく受信されたと判定された場合、ステップ４０３でデータパケットをクライアントバッファに格納する。正しく受信されたと判定されなかった場合、ステップ４０４で、データパケットを送信したサーバへ欠陥情報を通知する。上記とは別に、データパケットが正しく受信された旨の判定がステップ４０２で行われたかどうかにかかわりなく、前記クライアント側で正しく受信した最後のデータパケットのＳＮのような欠陥情報を前記サーバへ信号送信してもよい。ステップ４０５で、例えばＯＢＳＮのようなクライアントバッファ情報をクライアントバッファから決定し、ステップ４０６でサーバへ通知する。次いで、ステップ４０７で、例えばクライアントバッファからデータパケットをフェッチし、復号化し、あるいは、再生することによって、該データパケットのさらなる処理を行う。最終的に、本方法は元のステップ４０１へジャンプし、そこでさらに別のデータパケットの受信が行われる。

以上、推奨実施形態により本発明を説明した。当業者にとっては明白な代替方法および変更例が存在し、添付の請求項の範囲と精神から逸脱することなく実現可能であることを付記しておく。特に、本発明は３ＧＰＰ ＰＳＳにおける利用に限定されるものではなく、ビットレートの適合化と再送信を使用するすべてのタイプの無線通信システムおよび／または有線通信システムにおいても同様に好適に利用可能である。

従来技術に従うパケット交換型ストリーミングサービス（ＰＳＳ）プロトコルスタックの概略表示。 本発明に基づいて、パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するための、例示システムの基本構成要素。 本発明に基づいて、パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するための、サーバ側で行われる方法ステップを示す例示フローチャート。 本発明に基づいて、パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するための、クライアント側で行われる方法ステップを示す例示フローチャート。

Claims (21)

1. パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善する方法であって、
   第１のビットレートを用いてサーバからクライアントへデータパケットを送信し、
   前記送信されたデータパケットの少なくとも１つを少なくとも１つのサーババッファに少なくとも一時的に格納し、
   前記送信されたデータパケットのうちの少なくとも１つのデータパケットをクライアントバッファに少なくとも一時的に格納し、
   前記サーバへの前記送信中に、前記送信されたデータパケットの少なくとも１つの欠陥に関する欠陥情報を通知し、前記通知された欠陥情報を前記サーバにより分析して、前記サーババッファに格納された少なくとも１つのデータパケットを前記サーバから前記クライアントへ再送信する必要があるかどうかを判定し、
   前記クライアントバッファの状態に関するクライアントバッファ情報を前記サーバへ通知し、
   第２のビットレートで前記サーバから前記クライアントへデータパケットを送信し、ここで前記第２のビットレートは、前記クライアントバッファ情報に基づいて少なくとも部分的に決定され、前記第１のビットレートで送信され前記サーババッファに格納される少なくとも１つのデータパケットは、前記第２のビットレートで前記サーバから前記クライアントへの前記データパケットの前記送信が始まるとき、前記サーババッファにさらに格納されること、を有する方法。
2. 前記第１のビットレートで送信され前記サーババッファに格納された前記少なくとも１つのデータパケットは前記通知された欠陥情報に基づいて前記サーバが決定した継続時間の間、前記サーババッファに格納される請求項１に記載の方法。
3. 前記第１のビットレートで送信され前記サーババッファに格納された前記少なくとも１つのデータパケットの前記サーババッファからの取り出しが、前記通知されたクライアントバッファ情報に応じて決まる請求項１に記載の方法。
4. 前記クライアントバッファ情報が、前記クライアントバッファに格納された最も古いデータパケットの識別子である請求項１に記載の方法。
5. 前記サーバから前記クライアントへの前記データパケットの前記送信が、リアルタイム・トランスポートプロトコルＲＴＰに少なくとも部分的に基づいて行われ、前記欠陥情報および前記クライアントバッファ情報の前記通知は、リアルタイム・トランスポート制御プロトコルＲＴＣＰに少なくとも部分的に基づいて行われる請求項１に記載の方法。
6. 前記データパケットは、３ＧＰＰパケット交換型ストリーミングサービスＰＳＳに従って、前記サーバから前記クライアントへ送信されるメディアストリームに関連づけられる請求項１に記載の方法。
7. パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するシステムであって、
   サーバと、
   クライアントとを備え、
   データパケットが第１のビットレートを用いて前記サーバから前記クライアントへ送信され、
   前記送信されたデータパケットの少なくとも１つが少なくとも１つのサーババッファに少なくとも一時的に格納され、
   前記送信されたデータパケットの少なくとも１つがクライアントバッファに少なくとも一時的に格納され、
   前記サーバへの前記送信中に、前記送信されたデータパケットの少なくとも１つの欠陥に関する欠陥情報が通知され、
   前記通知された欠陥情報が前記サーバにより分析されて、前記サーババッファに格納された少なくとも１つのデータパケットを前記サーバから前記クライアントへ再送信する必要があるかどうかが判定され、
   前記クライアントバッファの状態に関するクライアントバッファ情報が前記サーバへ通知され、
   データパケットが第２のビットレートで前記サーバから前記クライアントへ送信され、
   前記第２のビットレートが前記クライアントバッファ情報に基づいて少なくとも部分的に決定され、
   前記第１のビットレートを用いて送信され前記サーババッファに格納された少なくとも１つのデータパケットは、前記第２のビットレートで前記サーバから前記クライアントへの前記データパケットの前記送信が始まるとき、前記サーババッファにさらに格納されるシステム。
8. パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するクライアントであって、
   第１のビットレートでサーバから前記クライアントへ送信されたデータパケットを受信するために設けられた手段であって、前記送信されたデータパケットの少なくとも１つのデータパケットが少なくとも１つのサーババッファに少なくとも一時的に格納される、手段と、
   前記送信されたデータパケットの少なくとも１つをクライアントバッファに少なくとも一時的に格納するために設けられた手段と、
   前記サーバへの前記送信中に、前記送信されたデータパケットの少なくとも１つの欠陥に関する欠陥情報を通知するために設けられた手段であって、前記通知された欠陥情報は前記サーバにより分析されて、前記サーババッファに格納されたデータパケットの少なくとも１つを前記サーバから前記クライアントへ再送信する必要があるかどうかを判定する、手段と、
   前記クライアントバッファの状態に関するクライアントバッファ情報を前記サーバへ通知するために設けられた手段と、
   第２のビットレートで前記サーバから前記クライアントへ送信されたデータパケットを受信するために設けられた手段であって、前記第２のビットレートは、前記クライアントバッファ情報に基づいて少なくとも部分的に決定され、前記第２のビットレートで前記サーバから前記クライアントへの前記データパケットの前記送信が始まるとき、前記第１のビットレートで送信され前記サーババッファに格納された少なくとも１つのデータパケットが前記サーババッファにさらに格納される、手段と、を備えるクライアント。
9. パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するサーバであって、
   第１のビットレートで前記サーバからクライアントへデータパケットを送信するために設けられた手段であって、前記送信されたデータパケットの少なくとも１つはクライアントバッファに少なくとも一時的に格納される、手段と、
   前記送信されたデータパケットの少なくとも１つを少なくとも１つのサーババッファに少なくとも一時的に格納するために設けられた手段と、
   前記送信中に、前記送信されたデータパケットの少なくとも１つの欠陥に関して通知された欠陥情報を受信するために設けられた手段であって、前記通知された欠陥情報は前記サーバにより分析されて前記サーババッファに格納された少なくとも１つのデータパケットを前記サーバから前記クライアントへ再送信する必要があるかどうかを判定する手段と、
   前記クライアントバッファの状態に関して通知されたクライアントバッファ情報を受信するために設けられた手段と、
   第２のビットレートで前記サーバから前記クライアントへデータパケットを送信するために設けられた手段であって前記第２のビットレートが前記クライアントバッファ情報に基づいて少なくとも部分的に決定され、前記第２のビットレートで前記サーバから前記クライアントへの前記データパケットの前記送信が始まるとき、前記第１のビットレートで送信され前記サーババッファに格納された少なくとも１つのデータパケットが前記サーババッファにさらに格納される、手段と、を備えるサーバ。
10. パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善する方法であって、
    第１のビットレートでサーバからクライアントへデータパケットを送信し、
    前記送信されたデータパケットの少なくとも１つを少なくとも１つのサーババッファに少なくとも一時的に格納し、
    前記送信されたデータパケットの少なくとも１つをクライアントバッファに少なくとも一時的に格納し、
    前記サーバへの前記送信中に、前記送信済みデータパケットの少なくとも１つの欠陥に関する欠陥情報を通知し、
    前記クライアントバッファの状態に関するクライアントバッファ情報を前記サーバへ通知し、ここで、前記通知されたクライアントバッファ情報は前記サーバにより分析されて、前記データパケットの前記送信の前記第１のビットレートが第２のビットレートへ変更され、
    前記通知された欠陥情報と、前記通知されたクライアントバッファ状態情報とに基づいて、データパケットの再送信が必要かどうかを判定し、
    データパケットの再送信の必要性が判定された場合のみ、前記サーババッファに格納された少なくとも１つのデータパケットを前記サーバから前記クライアントへ再送信すること、を有する方法。
11. 前記送信中に欠陥を受けた少なくとも１つのデータパケットのシーケンス番号の決定が前記欠陥情報によって可能となり、前記クライアントバッファ情報が、前記クライアントバッファに格納された最も古いデータパケットのシーケンス番号であり、データパケットの再送信が必要かどうかの前記決定が、前記少なくとも１つの破損データパケットと、前記最も古いデータパケットとの前記シーケンス番号の差に応じて決まる請求項１０に記載の方法。
12. 前記サーババッファに格納されたデータパケットが、該データパケットの関連するシーケンス番号と、前記最も古いデータパケットの前記シーケンス番号の差に応じて削除される請求項１１に記載の方法。
13. 前記サーバから前記クライアントへの前記データパケットの前記送信が、リアルタイム・トランスポートプロトコルＲＴＰに少なくとも部分的に基づいて行なわれ、前記欠陥情報および前記クライアントバッファ情報の前記通知が、リアルタイム・トランスポート制御プロトコルＲＴＣＰに少なくとも部分的に基づいて行なわれる請求項１０に記載の方法。
14. 前記データパケットは、３ＧＰＰパケット交換型ストリーミングサービスＰＳＳに従って、前記サーバから前記クライアントへ送信されるメディアストリームと関連づけられる請求項１０に記載の方法。
15. パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するシステムであって、
    サーバと、
    クライアントとを備え、
    データパケットがサーバからクライアントへ送信され、
    前記送信されたデータパケットのうちの少なくとも１つが少なくとも１つのサーババッファに少なくとも一時的に格納され、
    前記送信されたデータパケットの少なくとも１つがクライアントバッファに少なくとも一時的に格納され、
    前記送信中に、前記送信されたデータパケットの少なくとも１つの欠陥に関する欠陥情報が前記サーバへ通知され、
    前記クライアントバッファの状態に関するクライアントバッファ情報が前記サーバへ通知され、
    前記通知されたクライアントバッファ情報が前記サーバにより分析されて、前記データパケットの前記送信の前記第１のビットレートが第２のビットレートへ変更され、
    前記通知された欠陥情報と、前記通知されたクライアントバッファ状態情報とに基づいて、データパケットの再送信が必要かどうかが判定され、
    データパケットの再送信の必要性が判定された場合のみ、前記サーババッファに格納された少なくとも１つのデータパケットが前記サーバから前記クライアントへ再送信される、システム。
16. パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するクライアントであって、
    第１のビットレートでサーバからクライアントへ送信されるデータパケットを受信するために設けられた手段であって、前記送信されたデータパケットの少なくとも１つが少なくとも１つのサーババッファに少なくとも一時的に格納される、手段と、
    前記送信されたデータパケットのうちの少なくとも１つのデータパケットをクライアントバッファに少なくとも一時的に格納するために設けられた手段と、
    前記サーバへの前記送信中に、前記送信されたデータパケットの少なくとも１つの欠陥に関する欠陥情報を通知するために設けられた手段と、
    前記クライアントバッファの状態に関するクライアントバッファ情報を前記サーバへ通知するために設けられた手段であって、前記通知されたクライアントバッファ情報は前記サーバにより分析されて、前記データパケットの前記送信の前記第１のビットレートが第２のビットレートへ変更される、手段と、
    前記サーババッファに格納され前記サーバから前記クライアントへ再送信された少なくとも１つのデータパケットを受信するために設けられた手段であって、前記少なくとも１つのデータパケットはデータパケットの再送信の必要性が判定された場合のみ、再送信され、前記判定は、前記通知された欠陥情報と、前記通知されたクライアントバッファ状態情報とに基づいて行われる、手段と、を備えたクライアント。
17. パケット化データのビットレートの適合化と、データパケットの再送信との間の連携を改善するサーバであって、
    第１のビットレートで前記サーバからクライアントへデータパケットを送信するために設けられた手段であって、前記送信されたデータパケットのうちの少なくとも１つがクライアントバッファに格納される、手段と、
    前記送信されたデータパケットのうちの少なくとも１つを少なくとも１つのサーババッファに少なくとも一時的に格納するために設けられた手段と、
    前記サーバへの前記送信中に、前記送信されたデータパケットの少なくとも１つの欠陥に関する通知された欠陥情報を受信するために設けられた手段と、
    前記サーバとつながる前記クライアントバッファの状態に関する通知されたクライアントバッファ情報を受信するために設けられた手段であって、前記通知されたクライアントバッファ情報は前記サーバにより分析されて、前記データパケットの前記送信の前記第１のビットレートが第２のビットレートに変更される、手段と、
    前記通知された欠陥情報と、前記通知されたクライアントバッファ状態情報とに基づいて、データパケットの再送信が必要かどうかを判定するために設けられた手段と、
    前記サーババッファに格納された少なくとも１つのデータパケットを前記サーバから前記クライアントへ再送信するために設けられた手段であって、データパケットの再送信の必要性が判定された場合にのみ再送信が行なわれる、手段と、を備えたサーバ。
18. プロセッサに請求項１の方法ステップを実行させることの可能な命令を含むコンピュータプログラム。
19. プロセッサに請求項１の方法ステップを実行させることの可能な命令を含むコンピュータプログラムを備えたコンピュータプログラム製品。
20. プロセッサに請求項１０の方法ステップを実行させることの可能な命令を含むコンピュータプログラム。
21. プロセッサに請求項１０の方法ステップを実行させることの可能な命令を含むコンピュータプログラムを備えたコンピュータプログラム製品。

Images