マルチメディアチャネルの切り替え
本発明は、ユニキャスト通信システム（１）においてユーザが感知するマルチメディアチャネルの切り替え時間を短縮する。ユーザ端末（１０）のデータバッファ（１５）へのマルチメディアデータのバッファリングを減らすことにより、切り替え手順は短くなる。メディアバッファリングを減らすことにより、新しいチャネルのマルチメディアデータが非常に短い時間でユーザ端末（１０）にレンダリングされるという結果が得られる。マルチメディアデータを端末（１０）に通信するマルチメディアプロバイダ（１００）は、バッファリングを減らすために一時的に採用される低減通信速度を決定する。この低減速度は、通常採用される通信速度より遅く且つ端末（１０）のメディアプレーヤ（１２）のレンダリング速度より遅い。その結果、端末バッファ（１５）は再度書き込まれる速度より速い速度で空になっていき、バッファレベルは低下する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システムにおけるマルチメディアセッションの管理に関し、特に、そのようなマルチメディアセッションにおいてユーザが感知するマルチメディアチャネルの切り替え時間を短縮することに関する。
【背景技術】
【０００２】
背景
既存のモバイルネットワーク及び移動通信システムにおいて、広範囲の新しいサービスを提案及び提供する傾向がある。現在、マルチメディア又はＴＶコンテンツのためにモバイルネットワークを使用することに非常に大きな関心が持たれている。これは、従来技術においてモバイルＴＶと呼ばれることが多い。モバイルＴＶアプリケーションの目標は、ユーザが種々のマルチメディア又はＴＶチャネルを選択し且つ容易にザッピングできるＴＶと同様の体験を提供することである。
【０００３】
通常のＴＶチャネルは多くのユーザにブロードキャストされ、一般に、ユーザは受信して視聴するチャネルを選択することができる。モバイルＴＶも、（ライブ）メディア又はマルチメディアストリームのセットを何人かのエンドユーザに配信すると言う点において同様である。各マルチメディアストリームはＴＶチャネルに対応し、各ユーザは視聴するチャネルを選択することができる。現在、モバイルＴＶのブロードキャスト／マルチキャスト配信方法は開発途中である。そのような標準化の取り組みの例は、３ＧＰＰマルチメディアブロードキャスト／マルチキャストサービス（ＭＢＭＳ）及び欧州電気通信標準化機構（ＥＴＳＩ）デジタルビデオ放送‐ハンドヘルド（ＤＶＢ‐Ｈ）である。これらは、ブロードキャスト配信方法において従来のＴＶと同様である。
【０００４】
マルチキャスト／ブロードキャストに基づくモバイルＴＶが利用可能になるまでの間、既存のモバイル転送チャネルを介して実現される解決策が必要である。ユニキャスト転送がモバイルＴＶの好ましい配信手段であるため、既存のモバイル転送チャネルを介して実現される解決策は殆どユーザを有さないセル及び十分な容量を有するネットワークにとって将来大きな関心事となるだろう。
【０００５】
インターネットプロトコル（ＩＰ）に基づくネットワークを介するストリーミングを使用するモバイルＴＶと同様のサービスは、既存のモバイルネットワークに提供される。一例として、３ＧＰＰで開発されたパケット交換（ＰＳ）ストリーミングサービス（ＰＳＳ）がある。そのようなマルチメディア又はＴＶセッションを開始するために、通常、ユーザはウェブページ又はポータルサイトをサーフィンし、ライブストリーミングチャネルを見るためにリンクをクリック又は選択する。
【０００６】
AppleのQuicktime及びMicrosoftのメディアプレーヤ等、RealNetworks等のモバイルＴＶに使用することができるプロプライエタリストリーミングソリューションがいくつか存在する。通常、これらはポータルサイト又はウェブページを有し、そこでリンクがクリックされ、ある特定のチャネルの受信を開始する。
【０００７】
モバイルＴＶサービスの目標の１つは、通常のブロードキャストＴＶチャネルに対して行うのと同様に、チャネル間のザッピングを可能にすることである。全てのチャネルがブロードキャストされる場合、受信機は、適切な転送チャネルを選択し、適切なデマルチプレクサを使用することにより、チャネルをローカルに選択することができる。これは、一般的なケーブル、衛星又は地上テレビ、並びに今後のモバイル規格であるＭＢＭＳ及びＤＶＢ‐Ｈでも同様である。しかし、ユニキャストセッションの場合、クライアントは、「サーバ」又はマルチメディアプロバイダに所望のチャネルを送信させる必要がある。
【０００８】
ＩＰに基づくモバイルストリーミングを行う従来の方法は、ブラウザで特定のコンテンツを選択することである。これにより、セッション記述プロトコル（ＳＤＰ）又は同期マルチメディア統合言語（ＳＭＩＬ）ファイルのダウンロードを開始させ、そして、ユーザ端末のメディアプレーヤでリアルタイムストリーミングプロトコル（ＲＴＳＰ）ストリーミングセッションが始まる。通常、ユーザがユーザ端末の画面でコンテンツを見るまでにかかるおおよその時間は、約１０秒又は１０秒を僅かに超える。１０秒の内、５秒はアプリケーションのセットアップであり、残りは信号伝送（約２秒）及びバッファリング（約３〜４秒）である。ユーザが別の「マルチメディア又はＴＶチャネル」に切り替えたい場合、ユーザは、現在のデータストリームを停止し、ブラウザに戻り、ブラウザでリンクをクリックすることにより別のチャネルを選択しなければならない。そして新しいＲＴＳＰセッションが開始されるが、メディアプレーヤが起動してバッファリングを開始するため、新たに約１０秒の遅延が生じる。
【０００９】
国際出願［１］において、ユーザが感知するマルチメディアチャネルの切り替え時間を非常に効果的に短縮する技術が提示されている。基本的にこの技術は、新しいマルチメディアチャネルを選択するために、ユーザがユーザ端末のユーザ入力の１つを簡単にアクティブにすることを可能にする。ユーザがマルチメディアプロバイダのウェブページを再び訪れる必要なく且つ新しいセッションセットアップ手順を伴わずに、新しいチャネルのマルチメディアデータはユーザ端末に直接配信される。しかし、この時間短縮技術を使用する場合でも、約４秒のバッファリングは依然として実行される。
【発明の開示】
【００１０】
概要
従って、ユニキャスト（パケット交換）ネットワーク及び通信システムにおいてマルチメディアセッション中にマルチメディアチャネルを切り替える時に、ユーザが感知する時間を短縮する必要がある。
【００１１】
本発明は、従来技術の構成のこれら欠点及び他の欠点を克服する。
【００１２】
本発明の一般的な目的は、ユニキャスト通信システムにおいてユーザが感知するマルチメディアチャネルの切り替え時間を短縮することである。
【００１３】
本発明の別の目的は、採用したユーザ端末の変更又は適合を必要とせずに、ユーザの視点からチャネル切り替え手順を短縮することである。
【００１４】
本発明の特定の目的は、ユーザ端末が分からないように実行されるチャネル切り替え手順を短縮することである。
【００１５】
本発明の別の特定の目的は、ユーザが感知するマルチメディアチャネルの切り替え時間を短縮するための他の技術を補完するものとして使用できるチャネル切り替え手順を短縮することである。
【００１６】
これら及び他の目的は、添付の請求の範囲により定義される本発明により達成される。
【００１７】
簡単に説明すると、本発明は、ユニキャスト通信システムにおいてユーザが感知するマルチメディア送信元の切り替え時間を短縮することに関する。このユーザが感知する切り替え時間は、アプリケーションセットアップ、ユーザ端末とマルチメディアプロバイダとの間の信号伝送、並びにデータのレンダリング及び再生前に行われるマルチメディアデータのユーザ端末でのバッファリングによりかかる時間である。本発明は、切り替え時間全体の内、バッファリング時間の部分を短縮する。これは、端末におけるバッファリングが減少したために、マルチメディアチャネルの切り替え後、新しいチャネルのマルチメディアデータがユーザにとって非常に短い時間でレンダリングされ且つ利用可能になることを意味する。
【００１８】
本発明は、低減通信速度を決定することにより、ユーザ端末におけるバッファリング又はバッファレベルの低減を達成する。この低減通信速度は、通常、要求側ユーザ端末にメディアデータを転送する時にマルチメディアプロバイダにより採用される、対応する（平均）通信速度よりも平均して遅い。更に、この低減通信速度は、ユーザ端末のメディアプレーヤのレンダリング速度より遅い。これは、バッファにマルチメディアプロバイダから受信する新しいデータを再び書き込む速度より速く、マルチメディアデータが端末のバッファを出る、即ちメディアプレーヤによりレンダリングされることを意味する。その結果、ユーザ端末バッファのバッファレベルは低下する。
【００１９】
端末バッファのバッファレベルを下げることによりユーザが感知するチャネル切り替え時間の短縮を可能にするために、マルチメディアプロバイダは、その決定された低減通信速度を一時的に利用する。
【００２０】
説明のために、従来のチャネル切り替えにおいて、ユーザ端末におけるメディアバッファリングは約４秒かかるものとする。通常、その４秒とは、国際特許出願［１］の教示に従って実行されるマルチメディアチャネル切り替えをユーザが感知する合計時間である。これは、本発明の教示が文献［１］の切り替え時間の短縮を補完するものとして適用され、バッファリング時間を約１秒に短縮する場合、ユーザが感知するチャネル切り替え時間は約７５％短縮することを意味する。
【００２１】
バッファが少なくなり過ぎるか又は空になるという危険を防止し且つバッファレベル低減後に特定のユーザ端末にとって適切な最終的なバッファレベルとなるように、低減通信速度及び／又は低減速度が採用される時間の決定は、少なくとも部分的にユーザ端末の特定の機能に基づいて行われる。そのような場合、マルチメディアプロバイダは、それらバッファ機能の情報又は少なくとも機能の推定を可能にする情報をユーザ端末から受信するのが好ましい。
【００２２】
この状況において適切なパラメータは、ユーザ端末の初期バッファレベル、最大バッファレベル、最小バッファレベル及び／又は現在のレベルを含む。今日利用可能なユーザ端末の殆どが、端末の機種に依存する予め決められたバッファレベルを利用する。ユーザ端末は、利用した初期バッファレベルをマルチメディアプロバイダに通知できる。あるいは、バッファ総容量のうち所定の割合を利用するように端末が構成されているかも知れない。そのような場合、最大レベルの通知をプロバイダに送信することは、低減速度の決定において有用である。
【００２３】
一般に、ユーザ端末は、通常ゼロである最小バッファレベルが達成された場合にデータの再バッファリングを実行するように構成されている。これは、本発明のバッファレベル低下の結果、最小レベルに達しないことが好ましく、そうでなければ、バッファリング時間が予め決められた初期レベルに再び上昇し、低減したことが無駄になることを意味する。
【００２４】
端末は、周期的、間欠的及び／又は要求時に、現在のバッファレベルの状態の情報をマルチメディアプロバイダに送信することができる。このバッファフィードバックは、端末において所望のバッファレベルに微調整するためにプロバイダにより利用される。
【００２５】
ユーザ端末は、初期バッファレベル、最大バッファレベル、最小バッファレベル及び／又は現在のバッファレベルのデータを送信する代わりに、例えばセッションセットアップ中、又はチャネル切り替え要求の一部として端末機種の情報を含めることができる。マルチメディアプロバイダは、例えば利用可能な異なるユーザ端末機種に対して関連するバッファ容量データを一覧表示するテーブルにアクセスできる。テーブルルックアップ手順において、受信した機種データを使用することにより、マルチメディアプロバイダによる低減速度決定において使用可能なバッファレベル情報が提供される。
【００２６】
本発明の第１の実施形態において、決定した低減通信速度はゼロである。これは、決定した短い時間の間に新しいマルチメディアデータがユーザ端末に実際に送信されないことを意味する。この場合、低減通信速度に基づいて決定されるように、マルチメディアプロバイダは、現在のマルチメディアチャネルのデータを一時的にドロップする。本実施形態の好適な実現例において、マルチメディアプロバイダは、通常の速い通信速度を使用していくつかのデータパケットをユーザ端末に送信することによりセッションを開始する。第１のパケットは、端末のデータバッファに入力され、バッファリングされる。バッファリング手順が開始されると、プロバイダは、決定した時間の間、全てのマルチメディアデータパケットをドロップする。これは、新しいデータパケットはバッファに入力されず、既に受信したデータパケットの一部がバッファを出てレンダリングされることを意味する。従って、バッファレベルは低下する。バッファレベルが適切に低下すると、マルチメディアプロバイダは、ユーザ端末にデータパケットを再び送信し始める。そして、低下したバッファレベルは維持され、その後ユーザがマルチメディアチャネルを切り替えたい場合には、非常に短いチャネル切り替えを可能にする。
【００２７】
本実施形態は、非常に単純に実現できるという利点を有する。欠点は、マルチメディアチャネルの一部のデータが欠落するため、レンダリングされたデータの中に、ユーザが検出可能な不連続性ができることである。この欠点は、ドロップする有用なデータを少なくすることにより最小化することができる。例えば、マルチメディアプロバイダは、係数なしＰ画像及びサイレントオーディオを端末に送信することにより、チャネルのデータ送信を開始できる。そのような場合、この種のデータを含むデータパケットをドロップすることをユーザは気づかないだろう。
【００２８】
本発明の別の実施形態は、ユーザ端末からのチャネル切り替え要求と関連してバッファ減少を実行する。このチャネル切り替え後、マルチメディアプロバイダは、新しい要求チャネルのデータパケットをユーザ端末に直接配信する代わりに、要求チャネルの新しいデータの送信を一時的にスキップする。この送信が行われない間、端末バッファにおいて見つかった旧データチャネルのデータパケットがレンダリングされるため、バッファリングは減少する。
【００２９】
本実施形態において、第１のチャネル切り替えは、従来の技術を採用した場合と同様に長時間かかる。しかし、第１の切り替えが実行された後、ユーザ端末のバッファレベルは低下した。これは、切り替え中にデータのバッファリングが減少するため、更なるチャネル切り替えは非常に短い時間で実行されることを意味する。
【００３０】
本実施形態は、非常に単純に実現できるという利点を有し、ユーザ端末の再生に対する要求は、再生が第１のチャネル切り替えの前に行われるべきであるということのみである。欠点は、第１の切り替えが依然として長いことである。
【００３１】
本発明の更に別の実施形態において、マルチメディアプロバイダは、低減通信速度でマルチメディアデータをユーザ端末に一時的に送信する。この場合、通信速度はゼロではないが、ユーザ端末のメディアプレーヤのレンダリング速度より遅く且つ通常の速い通信速度より遅い。この低減データ提供速度のために、マルチメディアデータは、ユーザ端末のデータバッファが再び書き込まれる速度より速い速度でデータバッファを出る（レンダリングされる）。その結果、バッファレベルは低下する。
【００３２】
ライブストリーミングの場合、あるいはマルチメディア送信元の（一定）速度が変更できない場合、この解決策は、データがユーザ端末ではなくネットワークでバッファリングすることを必要とする。そのような場合、マルチメディアプロバイダは、ユーザ端末に送信する前に、ネットワークバッファにマルチメディアデータをバッファリングする。しかし、マルチメディアプロバイダからのデータ送信は、一時的な期間、完全に阻止されるわけではなく、データ送信は低減速度で進行する。これは、端末バッファが徐々に空になるのに伴って、ネットワークバッファは徐々に増加することを意味する。
【００３３】
ユーザ端末においてバッファレベルが適切に低下すると、マルチメディアプロバイダは、バッファが完全に空になるのを防止するために、好ましくは略レンダリング速度まで通信速度を上げる。ユーザ端末からチャネル切り替え要求を受信すると、マルチメディアプロバイダは、送信前にネットワークバッファへのバッファリングを行うこと無く、新しい要求チャネルのデータを直接配信し始める。これは、ユーザ端末にまだ送信されずにネットワークバッファに依然として存在する旧チャネルのデータが廃棄されることを意味する。
【００３４】
本実施形態の利点は、ユーザ端末において再生されるメディアに不連続性がなく、第１の切り替えが従来技術と比較して短い時間で行われることである。
【００３５】
バッファに格納されたメディアのレンダリングは、メディア又はマルチメディアデータを含む受信した各パケットに対して利用可能なタイムスタンプ（又はそれに同様のもの）により制御される。通常、ユーザ端末における初期バッファリング処理は、Ｘ秒、例えば４秒の実経過時間続くが、その期間は、バッファのバイト数であってもよく、あるいはタイムスタンプにより示される時間差であってもよい。いずれにしても、初期バッファリング期間の後、メディアプレーヤは、最小のタイムスタンプを有するメディアのレンダリングを開始し、更なるパケットのタイムスタンプに従ってメディアを再生する。一般に、ある時間に消費されるバイト数は、その時間における符号化速度（ビット数）に依存し、転送速度には依存しない。換言すると、タイムスタンプは提示時間（再生時間）を示すのであって、パケットの到着時間／送信時間を示すわけではない。
【００３６】
データをドロップする場合でもレンダリング速度を下回る低減通信速度を維持し且つユーザ端末のメディアプレーヤでわからないようにバッファレベル低下を実行するために、マルチメディアプロバイダは、連続したタイムスタンプが得られるように、送信したデータパケットにタイムスタンプを割り当てるのが好ましい。また、マルチメディアデータの送信パケットのシーケンス番号を、切れ目なく連続したシーケンス番号付けとなるように設定してもよい。そのような場合、メディアプレーヤは、データパケットがマルチメディアプロバイダにおいてドロップ、スキップ又は遅延されたことに気付かない。連続したタイムスタンピングにより、端末のメディアプレーヤは、本発明のバッファレベルを低減する実施形態に影響されない同一の連続した速度でメディアレンダリングを実行する。
【００３７】
本発明は、以下の利点を提供する：
【００３８】
‐マルチメディアチャネルを切り替える場合にユーザが感知する時間を短縮する；
【００３９】
‐チャネルの「ザッピング」体験を向上する；
【００４０】
‐ユーザ端末の変形、変更又は制御を必要としない；
【００４１】
‐他のチャネル切り替え時間短縮技術を補完するものとして利用することができる；
【００４２】
‐ユーザ端末のメディアプレーヤ及びデータレンダリングに影響を与えずにバッファレベルを低減し、チャネル切り替え時間を短縮する；
【００４３】
‐本発明は、非常に容易に実現することができ、既存のネットワークユニットに対する変更を殆ど必要としない。
【００４４】
本発明により提供される他の利点は、本発明の実施形態の以下の説明を読むことにより理解されるだろう。
【００４５】
添付の図面と共に以下の説明を参照することにより、本発明は、本発明の更なる目的及び利点と共に最もよく理解されるだろう。
【発明を実施するための最良の形態】
【００４６】
詳細な説明
図中、同一の参照符号は、対応する要素又は同様の要素に対して使用される。
【００４７】
本発明は、ユニキャスト通信システムにおけるマルチメディアセッションの管理に関し、特に、そのようなシステムにおいてマルチメディアチャネルを切り替える時にユーザが感知する時間を短縮する方法及び構成に関する。
【００４８】
従来のユニキャストインターネットプロトコル（ＩＰ）による無線通信システムにおいて、ユーザがマルチメディアセッション中にメディア又はマルチメディアチャネルを切り替えたい場合、通常、ユーザは、ユーザ端末のウェブブラウザ又は他のアプリケーションによりコンテンツプロバイダ又はサービスプロバイダにより提供されるウェブサイトを訪れる必要がある。新しいアプリケーションセッションのセットアップが実行されるが、そのセットアップは、殆どの通常のユーザ端末において約５秒かかり、ユーザ端末とコンテンツプロバイダ及び／又はストリーミングサーバとの間の信号伝送が含まれる場合には約７秒かかる。その約７秒に対して、ユーザ端末におけるマルチメディアデータのバッファリング時間である約４秒が追加される。これは、チャネル切り替え後にユーザ端末により感知される遅延又は遅れの合計が約１０秒か又は１０秒を僅かに超えることを意味する。そのうちの約４０％は、ユーザ端末におけるデータバッファリングによるものである。
【００４９】
国際出願［１］において、マルチメディアチャネル切り替え中にウェブサイトを訪れ且つ新しいアプリケーションセッションをセットアップする従来の必要性を除去する解決策が提示される。しかし、この技術はユーザが感知するチャネル切り替えの合計時間を大きく短縮するが、ユーザ端末におけるデータバッファリングの約４秒は依然として残る。
【００５０】
本発明は、ユーザ端末におけるバッファレベル又はバッファリング時間を故意に低下又は短縮させることにより、チャネル切り替え後のユーザが感知する遅延又は遅れの合計を減少する。その結果、次にマルチメディア切り替えが発生した場合は、ユーザ端末のグラフィカルユーザインタフェース上に、非常に速くマルチメディアがレンダリングされ、且つデータが現れる。
【００５１】
このバッファレベルの低下を達成する本発明の基本概念は、マルチメディア通信速度又はスピードを一時的に遅くし、ユーザ端末の再生又はレンダリングレート又は速度よりも遅く維持することである。その結果、一時的にデータは、ユーザ端末バッファが補充される（すなわち、マルチメディアプロバイダから受信される）速度より速くユーザ端末バッファから出力（すなわち、レンダリング）され、バッファレベルは低下する。その後、バッファからデータが完全に無くなるのを防止するために、マルチメディアデータ通信速度は上げられ、例えば、通信速度は以前の相対的に速い速度に戻される。
【００５２】
この状況における典型的な例は、ユーザ端末のバッファレベルを約４秒のデータバッファリングから約１秒のバッファリングに下げることである。その結果、文献［１］の技術に従って取得可能な切り替え時間と比較して、チャネル切り替え後のメディアレンダリングの遅延を合計で約７５％削減することができる。これは、従来の解決策と比較して、ユーザにとって非常に良い相違点である。
【００５３】
ストリーミングユーザ端末におけるバッファリング状態を記述する一般的な方法は、受信及び再生される累積バイト数を時間の関数として示す図を描くことである。ある時間において受信されたバイト数と再生されたバイト数との差は、バッファ占有量レベルである。図を視覚的に分かり易くするために、以下において通常の受信速度及びレンダリング又は再生速度の双方が一定であり、例えば８ｋＢ／ｓと仮定するが、それに限定されない。これは、限定しない図示される例として考えられるべきである。図１は、４秒の初期（一定）バッファリングを伴う従来の解決策による原理を概略的に示す。
【００５４】
図中、塗りつぶされた正方形を含む曲線２０は、受信したマルチメディアデータ量を表し、マルチメディアプロバイダの平均通信速度を反映している。塗りつぶされた円を含む曲線３０は、ユーザ端末のマルチメディアプレーヤによりレンダリングされるマルチメディアデータ量を表す。尚、図１における上側曲線２０と下側曲線３０との間の差は一定であり、４秒の初期バッファリング時間分の３２ｋＢである。図１及び以下に更に説明される本発明の対応する図において、線の間の垂直差は、ある時間におけるバッファ占有量のバイト数に対応する。線の間の水平差は、あるバッファレベルにおけるバッファ占有の時間に対応する。
【００５５】
チャネル切り替えがトリガされる場合、新しいチャネルのマルチメディアデータは、レンダリングされ、ユーザが（視覚的及び／又は聴覚的に）アクセスできるようになる前にユーザ端末にバッファリングされる。その結果、図示される従来の例において、新しいデータのレンダリングは受信時に４秒遅延される。
【００５６】
この例及び以下の図において、図を簡単にするために、符号化速度及び転送速度が一定であることを仮定した。しかし、本発明はそれに限定されない。実際には、レンダリング曲線３０は、受信曲線２０に対して一定の距離を有さない。一定の通信速度である場合でも、受信速度を変化させるジッタが存在する。しかし、従来技術による受信曲線とレンダリング曲線との間の平均差、すなわちバッファリング時間は略一定である。
【００５７】
バッファに格納されたメディアのレンダリングは、メディア又はマルチメディアデータを含む各受信パケットに対して利用可能であるＲＴＰ（リアルタイムプロトコル）タイムスタンプ（又はそれに同様のもの）により制御される。通常、初期バッファリング処理は、Ｘ秒、例えば４秒の実経過時間続くが、その期間は、バッファのバイト数であってもよく、あるいはＲＴＰタイムスタンプにより示される時間差であってもよい。いずれにしても、初期バッファリング期間の後、メディアプレーヤは、最小のタイムスタンプを有するメディアのレンダリングを開始し、更なるパケットのタイムスタンプに従ってメディアを再生する。一般に、ある時間に消費されるバイト数は、その時間における符号化速度（ビット数）に依存し、転送速度には依存しない。換言すると、タイムスタンプは提示時間（再生時間）を示すのであって、パケットの到着時間／送信時間を示すわけではない。
【００５８】
図２は、本発明に従って、ユニキャスト通信システムにおいてユーザが感知するマルチメディアチャネルの切り替え時間を短縮する方法を示すフローチャートである。方法は、オプションのステップＳ１で開始する。ステップＳ１において、マルチメディアプロバイダ又はコンテンツプロバイダは、第１の通信速度又は現在の通信速度で第１のマルチメディアチャネル又は現在のマルチメディアチャネルのマルチメディアデータをユーザ端末に送信する。本発明において、「通信速度」は、時間単位毎にユーザ端末に送信されるデータ量（例えば、データのバイト数）と定義される。データの符号化速度の変動に対応すると共に転送品質（無線の状態）の変動に対する余裕を提供するために、ユーザ端末において、マルチメディアデータはレンダリング及び再生前にバッファリングされる。
【００５９】
次のステップＳ２において、マルチメディアプロバイダは、現在のマルチメディアセッションに対する第２の通信速度を決定する。この第２の通信速度は、第１の通信速度より遅く、ユーザ端末のマルチメディアデータのレンダリング速度又は再生速度より遅い。その結果、マルチメディアプロバイダは、この遅い通信速度を一時的に採用することによりユーザ端末のバッファレベルを下げることができる。
【００６０】
ステップＳ３において、マルチメディアプロバイダは、第２の通信速度を一時的に採用してユーザ端末のバッファレベルを下げることにより、第１の（現在の）チャネルから第２の（新しい）マルチメディアチャネルへの可能なチャネル切り替え後にユーザ端末において第２のデータチャネル又は新しいデータチャネルのマルチメディアデータをレンダリングする遅れ又は遅延時間を能動的に短縮する。これは、マルチメディアプロバイダが遅い第２の通信速度でマルチメディアデータをユーザ端末に一時的に提供又は送信することを意味する。当業者には周知であるように、通信速度は０バイト／秒であってもよく、これは、データが一時的な期間に実際に送信されないことを示す。従って、本発明によれば、「決定した第２の通信速度でマルチメディアデータを一時的に送信する」という表現は、ある期間にユーザ端末に送信されるマルチメディアデータが、第１の通信速度が使用される場合と比較して少ないか又は全く送信されないことを示す。一般に、この状況において、第１の通信速度がＸｋＢ／ｓであり且つ第２の通信速度がＹｋＢ／ｓである場合、Ｚをユーザ端末のメディアプレーヤのレンダリング速度（ｋＢ／ｓ）とすると、０≦Ｙ＜Ｘ且つＹ＜Ｚである。更に通常、Ｘは平均してＺ以上である。
【００６１】
尚、通信速度が一時的にゼロに低下した場合でも、メディアプレーヤがバッファに既に格納されているマルチメディアデータをレンダリングし続けるため、通常、ユーザは通信速度の変化を体験しない。従って、チャネル切り替えの遅れ時間を短縮する手段として採用される本発明のバッファレベルの低下は、一般に、関連するユーザにとって著しい欠点の原因にはならない。
【００６２】
所望のバッファレベルまで下がると、マルチメディアデータは、第１の通信速度又は第３の通信速度等の速い通信速度でマルチメディアプロバイダにより再び送信される。後者の場合、第３の通信速度は、第１の速度より速いか、あるいは第１の速度より遅いが第２の通信速度より速い。
【００６３】
ユーザがマルチメディアチャネルを切り替えたい場合、データのバッファリングが短いため、ユーザ端末における受信後、新しいチャネルのデータは非常に短い時間でレンダリングされる。例えば４秒の初期バッファレベルは、本発明を採用することにより、約１秒のデータのバッファリングに減少される。
【００６４】
第２の通信速度及び／又は第２の通信速度がマルチメディアプロバイダにより採用される時間は、２つの相反する目的の間の妥協点としてプロバイダにより決定される。第１に、チャネル切り替え後にマルチメディアデータをレンダリングする遅れ時間を短縮するため、ユーザの視点から、可能な限り低いバッファレベルが望ましい。低いバッファリングにより、感知されるチャネル切り替え時間は短くなり、新しいメディアが早く再生される。第２に、符号化速度及び転送（無線）条件の変動により、バッファレベルを低くしすぎると、データバッファが空になる、バッファアンダーランを起こすことがある。そのような場合、ユーザ端末は、例えば、４秒のバッファリング等の元の（大きな）バッファレベルまでデータを再バッファリングする。その結果、バッファレベルを故意に低下することは無駄になった。
【００６５】
これは、以下に更に説明するように、本発明によれば、ユーザ端末のバッファレベルを、再バッファリングを必要とせずに符号化速度及び転送の状態の僅かな変動に対処するのに十分な余裕があるところまで可能な限り下げるのが好ましいことを意味する。
【００６６】
その後、方法は終了する。
【００６７】
本発明のバッファレベル低下技術は、国際出願［１］で提示されるような他の切り替え時間短縮技術を補完するものとして採用されるのが好ましい。簡単に説明すると、ユーザがコンテンツプロバイダ又はマルチメディアプロバイダから入手可能なマルチメディアチャネルを観たい場合、ユーザはそのマルチメディアチャネルに対する要求をプロバイダに送信する。通常、このチャネル要求は、ユーザがマルチメディアプロバイダのウェブページを訪れ且つマルチメディアチャネルに関連付けられたリンクをクリックすることにより生成される。マルチメディアプロバイダは、ユーザが実行中のセッションを終了し且つマルチメディアプロバイダのウェブページを再び訪れる必要なく、任意の別のチャネルへの使用し易い切り替えを可能にするのに必要な全ての情報、オブジェクト及び命令を含むマルチメディアセッションセットアップ記述を自動的に生成する。
【００６８】
生成されたセットアップ記述はユーザ端末に返され、記述に含まれるデータオブジェクトは端末により処理される。まず、記述のマルチメディアオブジェクトは、端末において処理される場合、端末の画面又はグラフィカルユーザインタフェース（ＧＵＩ）に表示されるマルチメディアセッションウィンドウを規定する。このセッションウィンドウは、要求されたチャネルのマルチメディア（ビデオ）データを表示するように適応された表示領域を含む。ウィンドウは、プロバイダから入手可能な別のマルチメディアチャネルに関する情報を含む表示可能チャネル領域を更に含む。この情報は、例えばそれら別のチャネルで現在入手可能であるＴＶ番組又は映画の識別子又はアイコンであってもよい。これは、ユーザが表示画面の全ての異なるマルチメディアチャネルに関する情報に対してセッション開始時に既にアクセスできることを意味する。従って、ユーザは、セッションを終了して、その種の情報を入手するためにマルチメディアプロバイダのウェブページを再び訪れる必要がない。
【００６９】
セッションセットアップ記述の関連付けオブジェクトは、端末において処理される場合、端末のユーザ入力とセッションウィンドウのチャネル領域で通知される別のチャネルの識別子との間の関連付け又はバインディングを規定する。チャネル識別子と関連付けられるユーザ入力は、例えば端末のキーパッドのキー又はタッチパネルの部分であってもよい。ユーザが１つのユーザ入力をトリガすると、セットアップ記述の要求オブジェクトは、トリガされたユーザ入力に識別子が関連付けられた別のチャネルへの要求を生成する。このチャネル切り替え要求は、マルチメディアプロバイダに自動的に送信され、マルチメディアプロバイダは、それ以上のユーザからの対話なしでチャネル切り替えを実行する。
【００７０】
換言すると、ユーザがマルチメディアチャネルを切り替えたい場合、ユーザは、例えばそのチャネルに割り当てられたユーザ端末上の１つのキーを単純に押下する。チャネル領域は、入手可能な別のチャネルに関する情報を一覧表示することに加え、別のチャネルに割り当てられたキー（ユーザ入力）を識別するのが好ましい。関連するキーが押下されると、要求オブジェクトはチャネル切り替え要求をコンパイルする。この切り替え要求は、関連付けオブジェクトにより提供されるキーバインディングを介して取得される要求されたチャネルの識別子を含む。更に、マルチメディアプロバイダが関連する端末を識別できるように、要求はユーザ端末の識別子を含む。
【００７１】
これは、ユーザが文献［１］に従ってセッション中にマルチメディアチャネルを切り替えるために実行する必要のある手順のみが、表示されるチャネル領域により、所望のチャネルに関連付けられ且つ割り当てられたユーザ入力（キー）を識別し、その後そのユーザ入力をアクティブにすることを意味する。これは、ユニキャストシステムに対する従来の解決策と比較されるべきである。従来の解決策では、ユーザは、まず現在のセッションを終了し、プロバイダのウェブページを再び訪れ、所望のマルチメディアチャネルに対するリンクを選択及びクリックする必要がある。その後、新しいセッションセットアップ手順が実行される必要があるため、非常に時間のかかる煩雑なチャネル切り替え手順である。
【００７２】
マルチメディアプロバイダがチャネル切り替え要求を受信した場合、マルチメディアプロバイダは、含まれるチャネル識別子により新しい所望のチャネルを識別し、含まれる端末識別子を使用してこの新しいチャネルのマルチメディアデータフローを適切なユーザ端末に向けて送る。
【００７３】
上記説明に従って実行されるチャネル切り替えのユーザが感知する合計時間は、主にユーザ端末におけるデータバッファリングにより占められる。従って、このデータバッファリング時間を短縮する本発明は、文献［１］の向上したチャネル切り替え手順及び他の同様の切り替え時間短縮手順を非常に適切に補完する。
【００７４】
バッファアンダーラン、つまり空になるという危険を回避し且つバッファレベル低下後に特定のユーザ端末にとって最終的なバッファレベルが適切となるようにするために、第２の通信速度及び／又は第２の通信速度が採用される時間の決定は、少なくとも部分的にユーザ端末からの入力情報に基づいて行われる。これは、本発明のバッファレベル低下がユーザ端末の特定の機能に基づいて実行されることを意味する。
【００７５】
図３は、そのような決定がどのように実現されるかを示す異なる実施形態を示すフローチャートである。この方法は、図２のステップＳ１から継続する。次のステップＳ１０において、マルチメディアプロバイダは、ユーザ端末の初期バッファレベル又は時間の推定値を提供する。本発明の本実施形態及び他の実施形態において、データバッファのバッファレベルは、バッファに含まれるバイト数として表されるか、あるいはバッファへのデータのバッファリングの時間として表される。これは、バッファレベルが特定のバッファリング時間として表され且つそれと関連して説明される場合、バッファレベルはバイト数のバッファレベルも含み、逆に、バッファレベルがバッファに含まれるバイト数に関して表され且つそれと関連して説明される場合、バッファレベルはバッファリング時間のバッファレベルも含むことを意味する。
【００７６】
通常、異なる端末機種は、端末の特定の機能に基づいて選択される、異なる予め決められたバッファリング時間を有する。これは、端末機種に応じてバッファレベルを下げることが有利であることを意味する。マルチメディアプロバイダは、端末の初期バッファレベルに適応される適切なバッファレベルの低下を達成するためにこの情報を使用できる。例えば、初期バッファレベルが４秒の第１のクライアントユーザ端末と初期バッファリングが３秒の第２のクライアントユーザ端末を仮定する。双方のユーザ端末は、バッファが空になるとデータを再バッファリングする。また、適切なバッファレベルの低下は、端末における最終的なバッファリングが約１秒を達成するような低下とする。マルチメディアプロバイダがユーザ端末の入力情報を受信しない場合、プロバイダは、端末のバッファリングが３秒減少するように、第２の低通信速度を設定できる。そのような第２の通信速度及びバッファリングの低下は第１のユーザ端末には非常に適しているが、第２のユーザ端末にはバッファレベルの低下が大きすぎるため、第２のユーザ端末は、初期の３秒のレベルまでデータを再バッファリングする。これに対して、第２のユーザ端末に対して適応された第２の通信速度及びバッファレベルの低下の結果、第１のユーザ端末に対しては最適でないバッファレベルとなる。従って、マルチメディアプロバイダが参加しているユーザ端末から入力情報を受信していれば、プロバイダは、特定のユーザ端末毎に適応された個々のバッファレベル低下を実行できる。
【００７７】
第１の実施形態において、この入力情報は、ユーザ端末の機種及び可能性のあるブランドの通知であってもよい。マルチメディアプロバイダは、可能な端末機種及びブランドのリストにアクセスでき、そのリストは、そのようなユーザ端末機種により採用された初期バッファレベルを指定する。通常、機種及びブランドの情報は、マルチメディアチャネル要求及びチャネル切り替え要求に対して使用されるハイパーテキスト転送プロトコル（ＨＴＴＰ）要求で送信されている。これは、そのようなＨＴＴＰ要求から必要な機種及びブランド情報を抽出することにより、その要求がマルチメディアプロバイダにより情報源として使用できることを意味する。別の可能性としては、例えば３ＧＰＰの文献［２］で説明されるような無線アプリケーションプロトコル（ＷＡＰ）又はＲＴＳＰ及びＨＴＴＰに対して使用されるユーザエージェントプロファイル（ＵＡＰｒｏｆ）の機種属性から端末機種情報を抽出することがある。
【００７８】
ユーザ端末が初期バッファレベルの情報をマルチメディアプロバイダに実際に送信することにより、リスト又はテーブルルックアップを不必要にすることは、本発明により理解される。
【００７９】
いずれの場合においても、マルチメディアプロバイダは、機種及びオプションとしてブランドの情報を抽出し、例えば特定のユーザ端末の初期バッファレベルを判定するためにその情報をリストと共に使用する。図３のステップＳ１１及びＳ１２で開示される実施形態と関連して更に詳細に説明されるように、リストは、ユーザ端末機種の初期バッファレベルに加えて又はその代わりに、端末機種の最大バッファレベル及び／又は最小バッファレベルの情報を含むことができる。
【００８０】
ステップＳ１１に示されるような本発明の別の実施形態において、マルチメディアプロバイダは、ユーザ端末の最大バッファレベルの推定値を提供できる。実際のユーザ端末は、データバッファの容量の一部のみを通常使用し、潜在的により多くのデータをデータバッファにバッファリングすることが可能である。そのような場合、ユーザ端末の最大バッファリング容量は、第２の通信速度及び／又は第２の通信速度の一時的な使用時間を決定するために使用される。例えば、殆どの端末機種は、通常バッファリング容量の８０％のみを利用するように構成される。従って、ユーザ端末の初期バッファリングレベル又は現在のバッファリングレベルの推定値を取得するために、最大バッファレベルの情報を、この予め決められた範囲のアプリケーションと共に使用することができる。本実施形態において、マルチメディアプロバイダの機種リストは、異なる端末機種の最大バッファ容量の情報を含むのが好ましい。
【００８１】
ステップＳ１２に示されるような本発明の更に別の実施形態において、マルチメディアプロバイダは、ユーザ端末の最小バッファレベルの推定値を提供する。最小バッファレベルは、ユーザ端末において許容される最小バッファリングである。その最小レベル以下にバッファリングが減少すると、ユーザ端末の予め決められた初期バッファレベルまで再バッファリングされる。従って、チャネル切り替え後のユーザが感知する遅れを減らすために、本発明に係るバッファレベル低下の実行は、最小バッファレベルに到達しないように行われ、データ再バッファリング及び初期の高レベルへのバッファレベル増加の危険を防止する。殆どの一般的なユーザ端末機種の場合、この最小バッファレベルは０バイトであるが、約０．５ｓのデータ等のより大きい余裕を利用できる。
【００８２】
Ｓ１０及びＳ１１の実施形態と同様に、マルチメディアプロバイダが入手可能な機種リストは、端末機種において許容される最小バッファレベルの情報を含むことができる。
【００８３】
ステップＳ１０〜Ｓ１２に関連して上述した実施形態を組み合わされてもよいことは、本発明により理解される。例えば、マルチメディアプロバイダの機種リストは、利用可能なユーザ端末機種に対する最小バッファレベルと共に初期バッファレベル又は最大バッファレベルの情報を含むことができる。あるいは、ユーザ端末は初期／最大バッファレベル及び最小バッファレベルの情報を直接送信できる。
【００８４】
通常、初期バッファレベル、最大バッファレベル及び最小バッファレベルが特定のユーザ端末の機能に依存する予め決められた値であるため、殆どの場合、それら値は動作中に変化しない。その結果、値又は値を提供できるようにする情報をマルチメディアプロバイダに一度通知するだけで十分である。上述のように、この通知は、セッションセットアップ又はチャネル切り替え手順の一部であってもよい。本発明によれば、実際には、マルチメディアセッション前又はマルチメディアセッション中の通知を可能にする任意の解決策を利用することができる。
【００８５】
ステップＳ１３に示される更なる実施形態において、マルチメディアプロバイダは、ユーザ端末の現在のバッファレベルの推定値を提供する。これは、マルチメディアプロバイダが好ましくはセッション中にユーザ端末の現在のバッファリングの状態を取得できることを意味する。ユーザ端末は、間欠的に、周期的に及び／又はマルチメディアプロバイダからの要求に基づいて、現在のバッファ状態のフィードバックをプロバイダに送信するように構成することができる。バッファレベルを信号で伝送する機構は、３ＧＰＰの文献［２］において考案されている。これが以前に使用されたのは、バッファ占有量を最大限にすることによりネットワークの問題に対する頑強性を最適化するためであった。本発明の範囲において、フィードバックは、バッファレベルを小さな定数に維持するために上記方法の内の１つを監視又はその制御を補助する方法として全く新しい方法で使用される。本実施形態は、本発明に係るバッファレベルがユーザ端末において適切な小さな値まで減少するように低下を微調整するために採用される。例えば、マルチメディアプロバイダは、セッションセットアップ中に受信される機種及びブランド情報に基づいて、ユーザ端末の初期バッファレベルを判定する。この初期レベルは、端末バッファを減らすためにセッション中に一時的に採用される低減通信速度を決定するために利用される。バッファ低減の後、マルチメディアプロバイダは、低減後に取得したバッファレベルのフィードバック情報を受信できる。プロバイダは、更なるバッファリングの削減が望まれるか否かを判定するために、そのフィードバックを使用できる。
【００８６】
上述から当業者には明らかであるように、ステップＳ１３のバッファレベルフィードバック解決策は、ステップＳ１０〜Ｓ１２の任意の実施形態と組み合わされてもよく、あるいはステップＳ１０〜Ｓ１２の実施形態の任意の組み合わせと組み合わされてもよい。方法は、図２のステップＳ２に継続する。ステップＳ２において、マルチメディアプロバイダは、低減通信速度を決定するために提供されたバッファレベル情報を利用する。
【００８７】
更に、同一の結果をもたらすバッファの低減は、必ずしも毎回実行される必要はない。例えばステップＳ１４により概略的に示されるように、バッファレベルの低下は、通信システムの現在の無線の状態等の他の入力情報に基づいて実行することもできる。ユーザ端末におけるデータバッファリングが共に転送品質（無線の状態）の変動に対する余裕を提供すると共に、データの符号化速度の変動に対応するために実行されるため、本発明のデータバッファの低下は、現在の転送品質及び符号化速度に少なくとも部分的に基づいて実行される。この状況において、無線の状態が悪い（低転送品質及び大きな符号化速度の変動）間は、バッファが完全に枯渇する危険を防止するために、適切な無線の状態が適切な時よりも本発明のバッファレベルの低下を小さくすることが好ましい。信号対雑音（Ｓ／Ｎ）比等の異なる品質パラメータにより例示されるような現在の無線の状態の情報又は推定値は、実際のマルチメディアデータ送信を実行する基地局及び／又はユーザ端末等のネットワークノードから取得することができる。
【００８８】
上述のように、マルチメディアプロバイダは、ユーザ端末のメディアプレーヤのレンダリング速度より遅い低減通信速度を決定する。通常、メディアプレーヤのレンダリング速度は、メディアのタイムスタンピングにより規定される。すなわち、１秒のマルチメディアデータは１秒間にレンダリングされる。非常に一般的でなく且つ複雑であるが、ユーザ端末が適応レンダリング速度を採用する場合、マルチメディアプロバイダは、端末から速度入力情報を受信するのが好ましい。採用されたレンダリング速度の情報は、ユーザ端末から直接受信される。あるいは、マルチメディアプロバイダにおいて提供される上述のリストは、異なる端末の種類に対して、利用されるレンダリング速度の情報を含むことができる。マルチメディアプロバイダは、適切な低減通信速度を決定するために、可能性としてバッファ容量情報及びフィードバックと共にその情報を利用できる。
【００８９】
典型的な実現例において、そのような適応レンダリング速度は、端末の現在のバッファレベルに依存し且つ従う。これは、ユーザ端末からのバッファフィードバック情報が端末の現在のレンダリング速度及び採用されるべき低減通信速度を決定するためにプロバイダにとって有用な情報源であることを意味する。
【００９０】
図４は、図２の遅れ時間短縮ステップＳ３の一実施形態を更に詳細に示すフローチャートである。この方法は、図２のステップＳ２から継続する。次のステップＳ２０において、第２の通信速度に基づいて決定されるように、マルチメディアプロバイダは現在のマルチメディアチャネルのデータを一時的にドロップする。これは、一時的な期間、利用された低減通信速度が実際にゼロであり、現在のチャネルのデータストリームのコンテンツの一部はユーザ端末に送信されないことを意味する。
【００９１】
本実施形態の好適な実現例において、マルチメディアプロバイダは、（速い／通常の）第１の通信速度を使用してデータのいくつかのパケットをユーザ端末に送信することによりセッションを開始する。それら第１のパケットは、端末のデータバッファに入力され且つバッファリングされる。バッファリング手順が開始されると、決定された時間の間、プロバイダは全てのマルチメディアデータパケットをドロップする。これは、新しいデータパケットはバッファに入力されないが、既に受信されたデータパケットの一部がバッファを出てレンダリングされることを意味する。このように、バッファレベルは低下する。バッファレベルが適切に低下すると、マルチメディアプロバイダは、データパケットをユーザ端末に再び送信し始める。低下したバッファレベルは維持され、その後ユーザがマルチメディアチャネルを切り替えたい場合に、チャネル切り替えを非常に短くできる。
【００９２】
このバッファレベルの低下をユーザ及びユーザ端末に対して可能な限りシームレスにするために、ステップＳ２１においてマルチメディアプロバイダは、ユーザに送信される後続のデータパケットのタイムスタンプ及びオプションとしてパケット番号付けを変更するのが好ましい。このタイムスタンプの変更及びパケットの再番号付けのために、ユーザ端末は、データが実際に欠落したことに気付かない。
【００９３】
図５及び図６において、この原理を更に詳細に示す。図５において、データパケット４０１〜４０４は、データストリーム４５０の形式でマルチメディアプロバイダ１００からユーザ端末（不図示）に配信される。本発明では、データパケット４０１〜４０４は、第１のマルチメディアチャネルを表す所定のマルチメディア送信元４１０から発生する。この図示される例において、マルチメディアプロバイダ１００は、２つの可能なデータ送信元４１０、４２０にアクセスできるため、２つの異なるマルチメディアチャネルを接続ユーザ端末に提供できる。図５において、データパケット４０５〜４０８の第１のストリームは、第１のデータ送信元４１０から受信され、データパケット４２１〜４２４の第２のストリームは、同様に第２の送信元４２０から受信される。尚、異なるストリームのデータパケット４０１〜４０８及び４２１〜４２４は連続したシーケンス番号を有する。図中、第１のデータ送信元２１０から発生するデータパケット４０１〜４０８は、ＤＰ３３〜ＤＰ４０の範囲の第１のシーケンス番号を有する。第２の送信元２２０のデータパケット４２１〜４２４は、ＤＰ１１〜ＤＰ１４の第２の異なるシーケンス番号を有する。図６は、図４の遅れ時間短縮の実施形態を採用した後の状態を示す。図６において、マルチメディアプロバイダ１００は、データパケット４０５、４０６の２つをドロップするため、それらデータパケットはユーザ端末に送信されることはない。
【００９４】
ユーザ端末に連続したマルチメディアデータストリーム４００を提供するために、マルチメディアプロバイダ１００は、マルチメディアプロバイダ１００を出て同一のユーザ端末に送信されるデータパケット４０１〜４１０が連続したシーケンス番号付け（ＤＰ３３〜ＤＰ４０）を有するように、データパケット４０７〜４１０に再番号付けする。これは、データパケット４０７〜４１０がＤＰ３９〜ＤＰ４１からＤＰ３７〜ＤＰ４０に再番号付けされ、連続した番号付けを保持することを意味する。シーケンス再番号付けは、チャネルの残りのデータパケット４１１〜４１４に対して継続される。
【００９５】
シーケンス番号より重要なことは、図５及び図６と関連して上述したシーケンス番号付けと同様の手順に従って、データパケット４０１〜４０４、４０７〜４１０のタイムスタンプＴ１〜Ｔ８が割り当てられることである。これは、データパケット４０１〜４１０の連続したタイムスタンプＴ１〜Ｔ８が取得され且つデータパケットストリーム４５０がユーザ端末に対して連続して見えるように、データパケット４０７〜４１０のタイムスタンプＴ５〜Ｔ８がマルチメディアプロバイダ１００により設定されることを意味する。
【００９６】
従来技術において周知であるように、マルチメディアデータは、ビデオデータ及びオーディオデータの形式であってもよい。マルチメディアストリームを提供するマルチメディアチャネルは、ビデオデータから成るデータパケットを含むビデオストリームとオーディオデータから成るデータパケットを含むオーディオストリームとを提供すると考えられる。そのような場合、ビデオデータパケット及びオーディオデータパケットの連続したシーケンス番号付け及びタイムスタンピングを取得するために、本発明に係るシーケンス番号付け及びタイムスタンピングは、双方のデータストリームに対して実行されるのが好ましい。ユーザ端末におけるオーディオ再生時の劣化を回避するために、オーディオパケットに対するタイムスタンプの増加量は、データパケットが故意にドロップされた場合でも一定に保持されるのが好ましい。これにより、入力時間と出力時間との間に僅かな時間変位が生じる。ビデオパケットのタイムスタンピングは、同期を保持するようにオーディオタイムスタンピングに基づいて同様に調整されるのが好ましい。この状況において、オーディオデータはマスタである。要約すると、マルチメディアプロバイダは、オーディオデータストリームが連続したタイムスタンプを有するようにオーディオデータパケットにタイムスタンプを割り当て、またオーディオデータパケットのタイムスタンプの割り当てに基づいてビデオデータパケットにタイムスタンプを割り当てる。
【００９７】
図４を再び参照すると、データが送信されない期間の後、ステップＳ２２において上述のように、マルチメディアプロバイダは、通常の第１の通信速度又は第３の通信速度でタイムスタンプ調整され且つオプションとしてシーケンス再番号付けされたデータパケットの送信を継続する。その後、方法は終了する。
【００９８】
本実施形態は、単純に実現できるという利点を有し、マルチメディアプロバイダは、単純にデータパケットを送信することを一時的にやめ、同一のマルチメディアチャネルの後続のデータパケットのタイムスタンプを調整する。しかし、通常プロバイダは、ユーザ端末がパケットの受信を開始した時期を認識すべきである。認識しない場合、データパケットがユーザ端末でバッファリングされ始める前の早過ぎる時期に遅れ時間短縮手順（パケットのドロップ）を開始するという危険があり、これはバッファの完全な枯渇を招く可能性がある。
【００９９】
一部のデータが実際に欠落するためメディアレンダリングの際に検出可能な不連続性が存在し、そのため本発明の本実施形態は、ユーザにとって視覚的にも聴覚的（知覚的）にも魅力が足りない。この方法の可能な改善点は、送信される第１のデータが係数を有さないＰ画像であり、それに対応してオーディオ側ではサイレンスのみが送信されることである。これは、本実施形態のデータのドロップがマルチメディアセッションの初期に実現される場合、データチャネルの有用なデータではなく係数なし画像及びサイレントオーディオのみがドロップされることを意味する。これは使用されるコーデックに関する知識を必要とするが、利点はメディア表現に不連続性が存在しないことであり、多少遅い開始と感知されるだけである。
【０１００】
図７は、図４で開示された本発明の実施形態に係る、受信及びレンダリングされる累積バイト数を時間の関数として示すグラフである。図中、マルチメディアプロバイダのデータ送信が停止する時があるため、ユーザ端末による受信も０．５ｓ〜３．５ｓの間停止する。この場合、初期バッファリング時間は依然として４秒であるが、バッファ占有量（２つの曲線２０、３０の間の距離）は、４秒から後は１秒である。これは、チャネル切り替えがセッション開始から４秒以降のある時点で要求される場合、新しいチャネルのデータが４秒（図１を参照）と比較してユーザ端末に１秒のみバッファリングされることを意味する。
【０１０１】
図８は、本発明に係る、図２の遅れ時間短縮ステップＳ３の別の実施形態を示すフローチャートである。この方法は、図２のステップＳ２から継続する。次のステップＳ３０において、マルチメディアプロバイダは、０ｋＢ／ｓの第２の低減通信速度を一時的に採用する。しかし、マルチメディアプロバイダは、図４の実施形態のようにデータパケットをドロップするのではなく、データパケットを（ネットワーク）バッファにバッファリングする。本実施形態において、データバッファリングの一部は、ユーザ端末側からネットワーク側、すなわちマルチメディアプロバイダに移される。例えばデータパケットは、ネットワークバッファに約３秒バッファリングされ、ユーザ端末バッファに約１秒バッファリングされる。
【０１０２】
送信のない一時的な期間が終了すると、ネットワークバッファからのデータパケットは、ユーザ端末に送信される。データパケットを送信する前又はそれらをバッファに入力する前に、マルチメディアプロバイダは、ステップＳ３１においてタイムスタンプをデータパケットに割り当て、ユーザ端末において連続したタイムスタンピングを形成し且つデータレンダリングに不連続性がないようにするのが好ましい。データパケットは、ステップＳ３２において送信される。ステップＳ３２は図４のステップＳ２２に対応するため、更なる説明は行わない。
【０１０３】
チャネル切り替え要求がユーザ端末からマルチメディアプロバイダにより受信されると、マルチメディアプロバイダは、ネットワークバッファにバッファリングせずに新しいチャネルのデータパケットをユーザ端末に直接送信し始める。ネットワークバッファのバッファリング時間は省かれ、ユーザ端末のバッファリングの低下のみがなされる。上記で与えられた図を採用する場合、３秒のネットワークバッファリングが省略され、端末における１秒のバッファリングのみが使用されるという結果が得られる。
【０１０４】
本実施形態は、メディアストリームにおいて不連続性がないという利点を有するが、データをバッファリングする必要があるネットワーク／マルチメディアプロバイダにおいて複雑性が僅かに増加するという結果を招く。しかし、この場合、マルチメディアプロバイダは、後で徐々に減少を開始するという可能性を有し、また、例えば「無用な」データ（Ｐ画像及びサイレントオーディオ）による端末バッファリングの減少のタイミングを適応させる必要がない。図に関しては、本実施形態は図７と同様である。
【０１０５】
図９は、図２の遅れ時間短縮ステップＳ３の更なる実施形態を更に詳細に示すフローチャートである。この方法は、図２のステップＳ２から継続する。次のステップＳ４０において、マルチメディアプロバイダは、ユーザ端末Ｓ４０からチャネル切り替え要求を受信する。この要求は、文献［１］で示された技術等の従来技術に従って生成及び送信することができる。しかし、マルチメディアプロバイダは、新しく要求されたチャネルのデータパケットをユーザ端末に直接配信するのではなく、ステップＳ４１において要求チャネルの新しいデータの送信を一時的に停止する。本実施形態の第１の実現例において、マルチメディアは、新しいチャネルの第１のデータパケットをユーザに送信することをやめる。この送信していない間、端末バッファに見つけられる旧データチャネルのデータパケットがレンダリングされるため、バッファリングは減少する。別の実現例において、マルチメディアプロバイダは、第１のパケットの送信をスキップせず、それらパケットをネットワークバッファに一時的にバッファリングする。その結果はバッファ減少の観点から同様であるが、この実現例において、ユーザはデータを失うことはないが、ネットワークの複雑性は僅かに増加する。
【０１０６】
ステップＳ４２において、旧チャネルのデータパケットを第１の部分として含み且つ新しいチャネルのデータパケットを後続する第２の部分として含むデータストリームが１つの連続するストリームであるとユーザ端末により考えられるように、マルチメディアプロバイダは、新しいチャネルのデータパケットのタイムスタンプを調整するのが好ましい。図５及び図１０はこの原理を示す。図５に示される状況において、マルチメディアプロバイダ１００は、第２のマルチメディアチャネル４２０に対する要求をユーザ端末から受信する。本発明の本実施形態によると、マルチメディアプロバイダは、要求チャネルの入手可能な第１のデータパケット４２１を直接配信し始めるのではなく、ユーザ端末バッファのバッファレベルを低下させるために、新しいチャネルの２つの第１のパケット４２１、４２２の送信をやめる。ストリーム４５０は、新しいチャネルの４つの第１のパケットとしてデータパケット４２３〜４２６を含む。しかし、パケットのドロップがユーザ端末でわからなくなるように、新しいパケット４２３〜４２６のタイムスタンピングＴ５〜Ｔ８は、先のデータパケット４０１〜４０４のタイムスタンピングＴ１〜Ｔ４に続く。
【０１０７】
図９の次のステップＳ４３は、図４のステップＳ２２及び図８のＳ３２に対応するため、更なる説明は行わない。
【０１０８】
本実施形態において、チャネル切り替えは、従来技術を採用した場合と同様に長時間かかる。しかし、切り替えが実行された後、ユーザ端末のバッファレベルは低下した。これは、切り替え中にデータのバッファリングが減少するため、更なるチャネル切り替えは非常に短い時間で実行されることを意味する。
【０１０９】
図１１は、図９で開示される本発明の実施形態に係る、受信及びレンダリングされる累積バイト数を時間の関数として示すグラフである。図１１において、チャネル切り替えは８秒の時点で（図において矢印で示される）実行される。マルチメディアプロバイダは、このチャネル切り替えにおいてメディアデータの送信を３秒停止する。上述の原理によると、第１のチャネル切り替えは、その時点におけるユーザ端末のバッファレベルであるため、依然として約４秒のバッファリングを含む。しかし、新しいチャネルの第１のメディアパケットが到着すると、レベルは１秒になり、その後の切り替えは端末において１秒のバッファリングを含むだけになる。
【０１１０】
本実施形態は、非常に単純に実現できるという利点を有し、ユーザ端末の再生に対する要求は、再生が第１のチャネル切り替えの前に行われるべきであるということのみである。欠点は、第１の切り替えが依然として長いことである。
【０１１１】
図１２は、本発明における、図２の遅れ時間短縮ステップＳ３の更に別の実施形態を示すフローチャートである。この方法は、図２のステップＳ２から継続する。次のステップＳ５０において、マルチメディアプロバイダは、第２の通信速度でマルチメディアデータをユーザ端末に一時的に送信する。この場合、通信速度はゼロではないが、ユーザ端末のメディアプレーヤのレンダリング速度より遅く、また通常の第１の通信速度より遅い。この低下したデータ提供速度のために、マルチメディアデータは、再度書き込まれる速度より速い速度でユーザ端末のデータバッファを出る（レンダリングされる）。その結果、バッファレベルは低下する。
【０１１２】
ライブストリーミングの場合、あるいはマルチメディア送信元の速度が変更されない他の例の場合、この解決策は、データがユーザ端末ではなくネットワークにバッファリングされることを必要とする。そのような場合、本実施形態は、図８で開示される実施形態と同様の原理に基づく。この原理において、マルチメディアプロバイダは、ユーザ端末に送信する前に、ネットワークバッファにマルチメディアデータをバッファリングする。しかし、マルチメディアプロバイダからのデータ送信は、図７の実施形態のように一時的な期間、完全に阻止されるわけではなく、データ送信は低減速度で進行する。これは、ステップＳ５０において、端末バッファが徐々に空になるのに伴って、ネットワークバッファは徐々に増加することを意味する。
【０１１３】
低減速度は、適用期間中、一定である必要はなく変更できることが本発明により理解される。例えば、非常に遅い送信が最初に採用され、その後マルチメディアプロバイダは、例えば端末からのバッファフィードバック情報に基づいて、本来採用していた通信速度に速度を徐々に増加できる。
【０１１４】
次のステップＳ５１において、マルチメディアプロバイダは、連続したタイムスタンピングが得られるように、送信したデータパケットにタイムスタンプを割り当てる。この原理を図５及び図１３に示す。図１３において、通信速度は、図５で採用された先の速い速度と比較して低下されている。尚、データストリーム４５０の全てのパケット４０１〜４０６は連続したシーケンス番号付けＤＰ３３〜ＤＰ３８及びタイムスタンピングＴ１〜Ｔ６を有する。
【０１１５】
次のステップＳ５２において、ユーザ端末のバッファレベルが適切に低下すると、マルチメディアプロバイダは、バッファが完全に空になるのを防止するために、好ましくは略レンダリング速度まで通信速度を再び上げる。その後、方法は終了する。
【０１１６】
図１４は、図１２で開示される本発明の実施形態において、受信及びレンダリングされる累積バイト数を時間の関数として示すグラフである。この図示される例において、３秒のネットワークバッファは徐々に増加し、それに対応してユーザ端末バッファレベルは３秒低下する。この例において、ユーザ端末は８ｋＢ／ｓでデータを消費（レンダリング）するが、マルチメディアプロバイダが１秒に２ｋＢバッファリングするため、最初の１２秒の間の受信速度は６ｋＢ／ｓである。１２秒後、ユーザ端末のバッファレベルは８ｋＢ（１ｓ）に下がり、ネットワークにバッファリングされたデータは２４ｋＢ（３ｓ）である。
【０１１７】
その後、ユーザがマルチメディアチャネルを切り替えたいと考え且つ新しいチャネルを要求する場合、マルチメディアプロバイダは、ネットワークバッファにおいて見つけられる旧チャネルのデータを単純にスキップし、ネットワーク側でバッファリングせずに新しいチャネルの送信を開始する。これは、新しいチャネルのデータに対して、この例においてはユーザ端末で合計１秒のバッファリングが行われるため、データは非常に短い時間でレンダリングされることを意味する。この方法では、第１のチャネル切り替えは速く、追加の遅延は起こらない。当然、バッファレベルが所望の値まで下がる前に第１のチャネル切り替えが発生する場合、マルチメディアプロバイダは第２のチャネルにおいてバッファリングを継続できる。
【０１１８】
本実施形態の利点は、ユーザ端末において再生されるメディアに不連続性がなく、第１の切り替えが従来技術と比較して短い時間で行われることである。
【０１１９】
図４の実施形態に対して説明された問題と同様の予想される問題は、プロバイダが端末バッファを減らし始める前に、ユーザ端末が図１４の時間０においてバッファに実際に書き始めたことを、マルチメディアプロバイダが認識する必要があることである。しかし、この場合、マルチメディアプロバイダは、メディアストリームに不連続性がない、すなわちパケットのドロップがないため、後で徐々に減少し始める可能性を有する。
【０１２０】
先に説明し且つ開示した本発明の図示する実施形態において、ユーザ端末において約１秒のバッファレベルが結果として与えられることが多い。しかし、結果として得られるこの特定のバッファリングは、本発明の教示に従って取得される可能なバッファレベルの単なる例として考えられるべきである。従って本発明は、バッファレベルを１秒に下げる場合に限定されず、結果として得られるバッファリング時間が０．２５、０．５、０．７５、１．２５、１．５、１．７５及び２秒等の他のバッファリング時間である場合も含む。
【０１２１】
図１５は、本発明の一実施形態に係るユニキャストによる無線通信システム１を示す概略図である。通信システム１は、基本的にマルチメディアプロバイダ１００を含む。マルチメディアプロバイダ１００は、オペレータネットワーク５００、あるいは他の有線又は無線ネットワークを介してユーザ端末１０にマルチメディアサービス及びデータを提供する。マルチメディアプロバイダ１００は、マルチメディア送信元４００を含むか、あるいは図示されるようにマルチメディア送信元４００にアクセスできる。マルチメディア送信元４００は、異なるチャネル４１０、４２０からのマルチメディアデータを含むか又は生成するか、あるいは提供する。図示する例において、マルチメディアプロバイダ１００は、ストリーミングサーバ２００及びチャネルスイッチ３００の２つの異なるユニットを含むものとして開示される。マルチメディアプロバイダ１００の機能性を異なる（内部）ユニットに分割する場合、ストリーミングサーバ２００は、好ましくは、セッションセットアップ手順の管理、ユーザ端末１０からのチャネル要求及びチャネル切り替え要求の受信を行う。実行中のセッションの間、このサーバ２００は、チャネルスイッチ３００からユーザ端末１０にマルチメディアデータを更に配信する。その名前から明らかであるように、チャネルスイッチ３００は、ユーザ端末１０から発生した要求コマンドに応じてマルチメディアチャネルを切り替える。このチャネル切り替えにおいて、新しいマルチメディアチャネル又は送信元４１０、４２０からのマルチメディアデータは、ネットワーク５００を介してユーザ端末１０に転送するために、ストリーミングサーバ２００に配信される。
【０１２２】
図１５は、本発明に係る通信システム１の単なる例として理解されるべきであり、本発明の範囲内で他のシステム構成が可能である。例えば、入手可能なマルチメディアチャネル４１０、４２０の数は必ずしも２つである必要はなく、任意の数、すなわち少なくとも２つのチャネル４１０、４２０であってもよい。更に、マルチメディアプロバイダ１００は、１つの中央ユニット又は分散ユニットで構成されてもよく、ストリーミングサーバ２００及びチャネルスイッチ３００の動作を処理する。あるいは、マルチメディアプロバイダ１００は、より多くの又はより少ない内部ユニットを含むことができる。これを図１６に概略的に示す。
【０１２３】
図１６では、チャネルスイッチ３００が（オペレータ）ネットワーク３００を介してユーザ端末１０にマルチメディアデータを直接転送するように、ストリーミングサーバは省かれている。先に簡単に説明したように、マルチメディアプロバイダ１００は、提供したマルチメディアサービスに対する課金を行うユニット等、更に多くのユニットを含むことができる。あるいは、そのような課金ユニットは、例えばオペレータネットワークインフラストラクチャ３００の一部として他の場所に提供される。更に、専用のアプリケーションサーバが、マルチメディアプロバイダ１００の一部であってもよい。そのような場合、アプリケーションサーバは、受信したマルチメディアセッションセットアップ要求及びチャネル切り替え要求に対応するユニットであってもよい。このアプリケーションサーバは、それら要求に基づいてマルチメディアプロバイダの他のユニット２００、３００に命令する。
【０１２４】
図１７は、本発明の一実施形態に係るマルチメディアプロバイダ１００の一実施形態を示す概略ブロック図である。このプロバイダ１００は、一般的な入出力（Ｉ／Ｏ）ユニット１１０を基本的に含む。Ｉ／Ｏユニット１１０は、外部ユニットとの通信を行い且つ管理する。これは、通常、Ｉ／Ｏユニット１１０が変調器／復調器、符号器／復号器及びアドレシング機能性を含むことを意味する。特にＩ／Ｏユニット１１０は、チャネル要求及びチャネル切り替え要求をユーザ端末から受信するように構成される。ユニット１１０は、ユーザ端末とのセッションセットアップネゴシエーションに関わり、要求されたマルチメディアデータを端末に送信する。本発明の好適な実現例において、Ｉ／Ｏユニット１１０は、端末の（初期／最大／最小）バッファ容量に関する情報及び／又はバッファフィードバック情報を更に受信する。
【０１２５】
速度決定部１２０は、マルチメディアプロバイダ１００に構成され、ユーザ端末の現在のバッファレベルを下げ、それにより可能な後続するチャネル切り替え後のバッファリング時間を短縮するために、一時的に使用される低減通信速度を決定する。この決定された低減速度は、データをユーザ端末に送信するためにマルチメディアプロバイダ１００のＩ／Ｏユニット１１０により採用される通常の平均通信速度より平均して遅い。この通常の速度は、例えばストリーミングマルチメディア送信元により命令されると共に、ストリーミングマルチメディア送信元の速度と同一である。低減通信速度は、ユーザ端末のメディアレンダリング速度より遅く設定され、通常これは、メディアのタイムスタンピングにより決定される。
【０１２６】
本発明の好適な実施形態において、速度決定部１２０は、マルチメディアプロバイダ１００のバッファアナライザ１４０から入力情報を受信し、少なくとも部分的にその入力情報に基づいて速度を決定する。バッファアナライザ１４０は、ユーザ端末から発生するフィードバックメッセージからバッファ容量情報を抽出するように構成することができる。この容量情報は、端末バッファの初期バッファレベル、最大バッファレベル、最小バッファレベル及び／又は現在のバッファレベルを示すことができる。あるいは、バッファアナライザ１４０は、バッファ容量情報を提供するために、ユーザ端末からのメッセージから例えば機種及びブランド情報を抽出し、予め決められた機種リスト又はルックアップテーブル／データベースと共にその情報を使用する。
【０１２７】
上述したように、速度決定部１２０は、通信システムにおける現在の無線の状態の情報を受信し、速度決定においてその入力情報を利用することができる。無線品質情報は、内部品質推定ユニット（不図示）から、あるいは外部ネットワークユニット及び／又はユーザ端末から取得することができる。
【０１２８】
決定した低減通信速度は、速度アダプタ１３０により利用され、ユーザ端末バッファをある程度空にし、且つそれによりバッファのデータバッファリング時間を短縮することにより、マルチメディアチャネルの切り替え後のユーザが感知する遅れ時間を短縮する。低減通信速度が端末のデータレンダリング速度より遅いため（通常、データパケットタイムスタンプにより規定されたように）、ユーザ端末のバッファレベルは低下する。典型的な実施形態において、速度アダプタは、通信速度を速度決定部１２０により決定された速度に下げるように、データ送信を実際に実行するＩ／Ｏユニット１１０に命令する。あるいは、ユーザに送信するマルチメディアデータは、接続された（内部又は外部）データ送信元（不図示）から受信され、ユーザ端末に更に送信するために、決定された低減速度で速度アダプタ１３０によりＩ／Ｏユニット１１０に転送される。
【０１２９】
本発明の好適な実施形態において、マルチメディアプロバイダ１００はユニット１５０を更に含む。ユニット１５０は、連続したデータストリーム及び連続した均一なメディアレンダリングを取得するために、ユーザ端末に送信されるデータパケットにタイムスタンプを割り当て且つオプションとして再番号付けする。
【０１３０】
マルチメディアプロバイダ１００のユニット１１０〜１５０は、ソフトウェア、ハードウェア又はそれらの組合せとして提供されてもよい。ユニット１１０〜１５０は、１つのネットワークノードに共に実現されてもよい。また、いくつかのユニットが種々のネットワークノードに提供される分散型実施形態も可能である。少なくともマルチメディアプロバイダ１００の一部の機能性及びユニット１１０〜１５０がアプリケーションサーバ、ストリーミングサーバ及び／又はチャネルスイッチの間で分散されてもよく、それらが単一のネットワークノードに共に構成されるか又はユニキャスト通信システムにおいて異なるネットワークノードに提供されることは、本発明により更に理解される。
【０１３１】
図１８〜図２０は、図１７の速度アダプタ１３０の別の実施形態を更に詳細に示す。図１８から開始すると、速度アダプタの実施形態１３０は、パケットドロップ部１３１及び選択的にパケットセレクタ１３２を含む。パケットドロップ部１３１は、速度決定部により決定されるように、ある期間、通信速度ゼロを採用する。これは、マルチメディア送信元からのデータパケットの一部が実際にドロップされ且つユーザ端末に到達しないことを意味する。端末はバッファに既に存在するデータのレンダリングを継続するため、バッファレベルの低下は達成される。ユーザが感知するようなマルチメディアの不連続性が存在するため、パケットセレクタ１３２は、ドロップ部１３１によりドロップされるデータパケットがマルチメディアレンダリングに与える影響が最も少ないデータパケットを選択するように実現されるのが好ましい。好適な例は、係数なしＰ画像及びサイレントオーディオを含むデータパケットである。適切なデータ量がドロップされ、所望のバッファレベルに低下した後、データ送信は通常通りに先行する。
【０１３２】
ユーザ端末のメディアプレーヤに対してデータのドロップが分からないようにするために、マルチメディアプロバイダのパケット再番号付け部はパケットのドロップ後にデータパケットを再番号付けするため、それらパケット及びドロップ前に送信されたパケットは連続した番号を有する。また、タイムスタンピングは、端末において、データのドロップによるメディアレンダリングの一時的な停止がないように実行される。
【０１３３】
例えば３つのデータパケットをドロップすることにより適切な低下バッファレベルが得られることを速度決定部が推定する場合、３つの連続するデータパケットは、パケットドロップ部１３１によりドロップされることが本発明により理解される。あるいは、１つ又はいくつかのパケットがドロップされた後、１つ又はいくつかのデータパケットの送信が行われ、次にいくつかの又は残りのパケットがドロップされる。
【０１３４】
図１９において、速度アダプタ１３０は、要求プロセッサ１３３及びパケットプロセッサ１３４を含む。要求プロセッサ１３３は、ユーザ端末から発生するチャネル切り替え要求を受信して解析する。そのようなチャネル切り替え要求を識別すると、要求プロセッサ１３３は、新しいチャネルの第１のデータパケットの一部の送信をスキップするように、又はパケットの一部の送信を遅延するように、パケットプロセッサ１３４に命令する。データを再度書き込むことが一時的に停止されている間も、メディアレンダリングが継続されるため、ユーザ端末のバッファは減少するという同様の結果が得られる。
【０１３５】
図２０に示される速度アダプタ１３０は、バッファマネージャ１３５及びネットワークデータバッファ１３６を含む。この速度アダプタ１３０は、低減通信速度が実際にゼロではないが、マルチメディア送信元のデータ転送速度が一定であり且つ低減速度より大きい場合に適応する。そのような場合、通信速度の低減を実現するために、バッファマネージャ１３５は、アクセス可能なネットワークバッファ１３６にデータパケットを一時的にバッファリングする必要がある。データバッファリングは、端末側からネットワーク側に部分的に移動される。チャネル切り替え要求後、新しいチャネルのマルチメディアデータは、ネットワークバッファ１３６にバッファリングすることなくユーザ端末に直接転送される。そのデータに対して、端末バッファにおいてバッファリングのみが実行される必要があり、切り替えは非常に速いと感知される。
【０１３６】
この速度アダプタの実施形態１３０は、パケットをドロップせずに通信速度ゼロを一時的に適用するように使用することができる。
【０１３７】
図１８〜図２０は、３つの異なる速度アダプタの実施形態１３０を示す。本発明に係るマルチメディアプロバイダは、それら実施形態のうちの１つのみを有するように構成されることが本発明により理解される。別の実施形態において、速度アダプタ１３０は、少なくとも２つの図示された実施形態に従って動作できる。例えば、速度アダプタは、パケットドロップ部１３１、パケットセレクタ１３２、要求プロセッサ１３３及びパケットプロセッサ１３４を有することができる。これは、速度アダプタ１３０が、この場合は少なくとも２つの異なる速度適応モードに従って動作できるマルチモードユニットとして考えられることを意味する。採用する特定の速度適応モードの選択（図１８、図１９又は図２０）は、送信される実際のマルチメディアデータ、ユーザ端末の機種又は種類、マルチメディアプロバイダのネットワークバッファ１３６の現在の状態等を含む種々のパラメータに基づいて行われる。
【０１３８】
図１８〜図２０の異なる速度アダプタの実施形態１３０のユニット１３１〜１３５は、ソフトウェア、ハードウェア又はそれらの組合せとして提供されてもよい。ユニット１３１及び１３２、１３３及び１３４又は１３５及び１３６は、速度アダプタ１３０に共に実現されてもよい。あるいは、いくつかのユニットがマルチメディアプロバイダの他の場所に提供される分散型の実施が可能である。
【０１３９】
図２１は、本発明の別の実施形態に係るマルチメディアプロバイダ１００の可能な実現例を示す概略ブロック図である。図示される本実施形態において、マルチメディアプロバイダ１００は、ストリーミングサーバ２００及びチャネルスイッチ３００から構成される（図１５と比較のこと）。
【０１４０】
そのような実現例において、１つ又は複数のデータ送信元４１０、４２０からのマルチメディアデータは、送信元セレクタ３２０により各ユーザ端末に対して選択される。通常、このセレクタ３２０は、特定の送信元４１０、４２０のマルチメディアデータが送信されるべきユーザ端末を特定する、各チャネル送信元４１０、４２０に対するリスト又はテーブルにアクセスできる。マルチメディアデータは、チャネルスイッチのＩ／Ｏユニット３１０を使用してストリーミングサーバ２００に転送される。ストリーミングサーバ２００は、Ｉ／Ｏユニット２１０によりユーザ端末へのデータの直接送信を行う。
【０１４１】
本実施形態において、本発明の速度決定部２２０及び速度アダプタ２３０は、ストリーミングサーバ２００内で実現される。それら２つのユニット２２０、２３０の動作は、図１７〜図２０を参照して上述した対応するユニットと同様であるため、ここでは説明を繰り返さない。
【０１４２】
パケット処理機能性、すなわち番号付け及びタイムスタンピング機能性は、マルチメディアプロバイダ１００に存在するのが好ましい。例えば、パケット番号割り当てユニット３５０は、ストリーミングサーバ２００に転送されるデータパケットにシーケンス番号を割り当てるためにチャネルスイッチ３００に構成される。サーバ２００はユニット２５０を含み、そのユニット２５０は、例えば速度アダプタがマルチメディアストリームの一部のデータパケットをドロップするように構成される場合、必要に応じてデータパケットに再番号付けを行う。ストリーミングサーバ２００のパケット処理ユニット２５０又は他のユニットは、Ｉ／Ｏユニット２１０によりユーザ端末に送信されるデータパケットにタイムスタンプを割り当てる機能性を有する。一部のパケットがドロップ又は遅延される（ストリーミングサーバ２００のネットワークバッファ２６０に一時的にバッファリングされる）場合でも、連続したパケットタイムスタンピング及びメディアレンダリングが達成されるように、タイムスタンプの割り当ては、送信されたデータパケットに連続したタイムスタンプを割り当てることにより実行されるのが好ましい。
【０１４３】
マルチメディアプロバイダ１００のストリーミングサーバ２００及びチャネルスイッチ３００のユニット２１０〜２５０、３１０〜３５０は、ソフトウェア、ハードウェア又はそれらの組合せとして提供されてもよい。ストリーミングサーバ２００のユニット２１０〜２５０は、１つのネットワークノードに共に実現されてもよい。また、いくつかのユニットが異なるネットワークノードに提供される分散型実施形態も可能である。チャネルスイッチ３００のユニット３１０〜３５０は、１つのネットワークノードに共に実現されてもよい。また、いくつかのユニットが異なるネットワークノードに提供される分散型実施形態も可能である。ストリーミングサーバ２００、チャネルスイッチ３００及びマルチメディア送信元４１０、４２０は、単一のネットワークノードに共に構成されても、ユニキャスト通信システムの異なるネットワークノードに提供されてもよいことが本発明により更に理解される。
【０１４４】
通常、メディア又はマルチメディアストリームは、多くのフレーム（オーディオフレーム、ビデオフレーム等）から構成されると考えられる。それらフレームの一部は、ストリーミングセッションが開始するか又はチャネルの切り替えにより入力される時に使用される同期点としての役割を果たす。通常、同期点はメディアストリームにわたり均一に分布し、それらの周波数はメディアのビットレートに依存するのが一般的である。
【０１４５】
メディアストリームがユーザ端末に配信される場合、ユーザ端末において正確な復号化を行うために、マルチメディアプロバイダ（マルチメディアプロバイダのストリーミングサーバであることが多い）は同期点において配信を開始する必要がある。ユーザ端末が丁度同期点においてマルチメディアプロバイダに偶然に接続する場合を除いて、これは、プロバイダが同期点を待たなければならない時間と同等の遅延を発生する。
【０１４６】
同期点を待たずにユーザ端末が接続するとすぐにマルチメディアプロバイダがメディアストリームを配信し始める場合、問題は、ユーザ端末の復号器が適切に初期化されなくなり、乱雑な煩わしいアーティファクトを発生することである。これは、互いに依存して符号化されるメディアフレームに起因する。同期点は、この依存性を無くす。
【０１４７】
受信機において複数のチャネルが入手可能であるブロードキャストの場合にチャネルを入力又は切り替える時、同様の効果が得られる。ＤＶＴ‐Ｔのような一般的なＴＶシステムでは、１秒に２つのイントラフレーム（Ｉフレーム、同期点）があり、これはスタートアップ遅延を小さくするが、その間隔が長いほど切り替え時間は長くなる。
【０１４８】
本発明の教示は、ユーザ端末が新しいチャネルを要求し且つチャネル切り替えが実行されるとすぐに同期点の配信を開始することを可能にする技術と共に利用することができる。
【０１４９】
マルチメディアプロバイダがメディアストリームの小さなバッファを保持する場合、これは達成される。バッファは、少なくとも１つの同期点を常に保持するように十分に大きい必要がある。
【０１５０】
本発明の先の説明から明らかであるように、本発明のいくつかの実施形態は、マルチメディアデータを一時的にバッファリングし且つユーザ端末における対応するバッファリングを減らす目的で、マルチメディアプロバイダのネットワークバッファ又は少なくともマルチメディアプロバイダがアクセスできるネットワークバッファを利用する。従って、同一のネットワークバッファが、少なくとも１つの同期点を常に含むように十分に大きく設定することができる。
【０１５１】
別の面は、同期点のエミュレーションに関する。メディアの同期点の数が少ない場合、例えばビットレートが低い場合、マルチメディアプロバイダにバッファリングされる必要のあるデータ量が増加するのに伴い、送信されるメディアの遅延が増加する。これが受け入れられない場合、サーバにおいて同期点をエミュレートすることにより回避される。エミュレートされた同期点は、ユーザ端末においてレンダリングされたメディアでアーティファクトを発生するが、非同期点でメディアの配信を開始する場合と比較して全体のユーザ体験は向上する。
【０１５２】
ビデオストリームが最も少ない同期点を有する場合、例えば、同期点のエミュレーションは以下のうちの１つである：
【０１５３】
・旧イントラフレーム。この場合、マルチメディアプロバイダは最新のイントラフレームを常に格納し、ユーザ端末がチャネル切り替えを要求する場合、メディア配信がすぐに開始される。この時、配信される第１のビデオフレームは旧イントラフレームである。旧イントラフレームが配信された後、マルチメディアプロバイダは現在のフレームの配信を続ける。プロバイダは、帯域幅の制約を守るためにいくつかのフレームをスキップする必要がある可能性がある（通常、イントラフレームがインターフレームより（バイト数で）大きいため）。
【０１５４】
・灰色イントラフレーム又はＴＶチャネルのロゴを含むイントラフレーム。この場合、手順は上記例と同一である。この例は、イントラフレームが（バイト数で）小さい（灰色フレーム又はロゴフレームは効果的に圧縮されるため）という利点を有するため、追従するフレームはスキップされる必要がなく、イントラフレームは迅速に転送される（小さいため）。欠点は、ビデオストリームへの灰色又はロゴのにじみである。これらのフレームは通常のメディアストリームに存在しないため、マルチメディアプロバイダは、ある手段により灰色フレーム又はロゴフレームにアクセスできる必要がある。この問題に対する１つの解決策は、灰色フレーム又はロゴフレームで各チャネル要求を開始することであり、プロバイダはそれらを後で使用するために格納できる。
【０１５５】
・適切なイントラフレームの使用。この例は上記例に類似するが、この場合マルチメディアは、各ビデオストリームに対して、同一のコンテンツを含み且つイントラフレームとして符号化された全てのフレームを含む別のビデオストリームにアクセスできる。このフレームは、ストリームを復号化し且つ関連する画像を内部符号器に提供する復号器を有することによりリアルタイムで作成することができる。画像は、必要とされるビット数を減らすために、量子化器を増加することにより対応する非イントラフレームより更に圧縮されてもよい。
【０１５６】
別の例は、メディア送信元が文献においてＳフレームと呼ばれる復号化Ｐ画像に基づいて符号化されるイントラ画像の第２のストリームを提供することである。この例は、上記２つの例が有する欠点を有さないが、サーバ（及びシステム全体）に対する必要条件は増加する。
【０１５７】
少なくとも１つの同期点をネットワークバッファにバッファリングすることを可能にするために、マルチメディアプロバイダは、同期点としての役割を果たすフレームを識別できる必要がある。これは、いくつかの方法により解決される。
【０１５８】
・マルチメディアプロバイダが実際のメディア符号化を実行する場合、プロバイダは、どのフレームが同期点であるかを常に知っている。
【０１５９】
・メディアストリームがマルチメディアプロバイダに配信され、プロバイダがメディア転送プロトコル及びメディア符号化標準の知識を有することが可能である。その場合、同期点であるフレームを推定するために、マルチメディアプロバイダは、入力メディアストリームを構文解析し且つフレームのヘッダを復号化できる。殆どの場合、フレームヘッダの符号化は複雑ではない。最も単純な１つの例は、ＡＶＣ（Advanced Video Codec）ストリームに対するリアルタイムプロトコル（ＲＴＰ）ペイロードにおいてＮＡＬユニット（ＮＡＬＵ：Network Adaptation Layer Unit）タイプフィールドを見つけることである。ＮＡＬＵタイプフィールドは、ＲＴＰパケットが瞬時復号更新（ＩＤＲ：Instantaneous Decoding Refresh）フレームの一部であるＮＡＬＵを含むかを直接識別する。
【０１６０】
・メディアストリームがマルチメディアプロバイダに配信される場合、同期点を含むパケットに印が付けられる。例えば、ＩＰを介して配信される場合、ＩＰヘッダのＩＰｖ４のType of Service（ＴＯＳ）［３］、ＩＰｖ６のTraffic Class又はＩＰｖ６のFlow Label［４］を、同期点であるフレームに印を付けるために使用することができる。ＲＴＰプロトコル等の上位層でマーク付けすることも可能である。
【０１６１】
・イントラフレームが同期点としての役割を果たすビデオストリームの場合、イントラフレームは、フレームのサイズを見ることにより識別できることが多い。これは、通常イントラフレームがインターフレームより大きいためである。
【０１６２】
・同期点の周波数が一定であるエラーのない環境において、同期点を認識するのにフレーム番号で十分である。
【０１６３】
図２２は、本発明に係るユーザ端末１０の概略ブロック図である。このユーザ端末１０は、マルチメディアプロバイダと通信するためにＩ／Ｏユニット１１を具備する。特に、このＩ／Ｏユニット１１は、チャネル要求及びチャネル切り替え要求をプロバイダに送信するように適応される。更にＩ／Ｏユニット１１は、マルチメディアデータをプロバイダから受信する。
【０１６４】
ユーザ端末１０は、受信したマルチメディアデータをレンダリングするマルチメディア又はメディアプレーヤ１２を更に含む。このマルチメディアプレーヤ１２は、メディアを表示及び再生するために、端末１０の表示画面１３及びスピーカ１４と通信していることが好ましい。メディアプレーヤ１２は、マルチメディアバッファ１５と接続している。Ｉ／Ｏユニット１１により受信されたデータパケットは、レンダリングするためにプレーヤ１２に転送される前に、マルチメディアバッファ１５に入力され且つバッファリングされる。本発明の概念は、メディアプレーヤ１２のレンダリング速度より小さくなるようにデータ転送の通信速度を変調することにより、マルチメディアバッファ１５において実行されるデータバッファリングを減らすことである。
【０１６５】
ユーザ端末１０は、バッファ通知部１６を含むのが好ましい。バッファ通知部１６は、Ｉ／Ｏユニット１１により送信される情報をマルチメディアプロバイダに提供し、プロバイダがユーザ端末１０のバッファリング容量を推定することを可能にする。通知部１６は、マルチメディアバッファ１５の初期バッファレベル、最大バッファレベル、最小バッファレベル及び／又は現在のバッファレベルの情報を提供できる。あるいは、バッファ通知部１６は、例えばセッションセットアップ要求又はチャネル切り替え要求に端末機種情報を単純に含める。
【０１６６】
要求プロセッサ１７は、チャネル要求及びチャネル切り替え要求を生成するためにユーザ端末１０上で実現される。要求プロセッサ１７は、マルチメディアプロバイダに送信される要求にバッファ通知部１６により取得された情報を含ませることができる。
【０１６７】
ユーザ端末のユニット１１、１２、１５〜１７は、ソフトウェア、ハードウェア又はそれらの組合せとして提供されてもよい。
【０１６８】
添付の請求の範囲により定義される本発明の範囲から逸脱せずに、本発明に対して種々の変形及び変更が行われてもよいことは、当業者には理解されるだろう。
【０１６９】
参考文献
［１］国際出願第ＰＣＴ／ＳＥ２００５／００１７６８号
［２］3GPP TS 26.234 v6.5.0、第３世代パートナーシッププロジェクト；Technical Specification Group Services and System Aspects；Transparent end-to-end Packet switched Streaming Service (PSS)；Protocols and codes
［３］Postel, J., Internet Protocol, Darpa Internet Program Protocol Specification, RFC 791、１９８１年９月
［４］Deering, S. and R. Hinden, Internet Protocol, Version 6 (IPv6) Specification, RFC 1883、１９９５年１２月
【図面の簡単な説明】
【０１７０】
【図１】図１は、従来技術に係る、受信及びレンダリングされる累積バイト数を時間の関数として示すグラフである。
【図２】図２は、本発明の一実施形態に係る、ユーザが感知する切り替え時間を短縮する方法を示すフローチャートである。
【図３】図３は、図２の方法の追加のステップの異なる実施形態を更に詳細に示すフローチャートである。
【図４】図４は、本発明の一実施形態における、図２の時間短縮ステップを更に詳細に示すフローチャートである。
【図５】、
【図６】図５及び図６は、図４で開示される本発明の実施形態に係る、データパケットに再番号付けし、タイムスタンプを割り当てる原理を概略的に示す図である。
【図７】図７は、図４で開示される本発明の実施形態に係る、受信及びレンダリングされる累積バイト数を時間の関数として示すグラフである。
【図８】図８は、本発明の別の実施形態に係る、図２の時間短縮ステップを更に詳細に示すフローチャートである。
【図９】図９は、本発明の更なる実施形態に係る、図２の時間短縮ステップを更に詳細に示すフローチャートである。
【図１０】図１０は、図９で開示される本発明の実施形態に係る、タイムスタンプを割り当てる原理を概略的に示す図である。
【図１１】図１１は、図９で開示される本発明の実施形態に係る、受信及びレンダリングされる累積バイト数を時間の関数として示すグラフである。
【図１２】図１２は、本発明の更に別の実施形態に係る、図２の時間短縮ステップを更に詳細に示すフローチャートである。
【図１３】図１３は、図１２で開示される本発明の実施形態に係る、タイムスタンプを割り当てる原理を概略的に示す図である。
【図１４】図１４は、図１２で開示される本発明の実施形態に係る、受信及びレンダリングされる累積バイト数を時間の関数として示すグラフである。
【図１５】図１５は、本発明に係る通信システムの一実施形態を示す概略図である。
【図１６】図１６は、本発明に係る通信システムの別の実施形態を示す概略図である。
【図１７】図１７は、本発明の実施形態に係るマルチメディアプロバイダを示す概略ブロック図である。
【図１８】図１８は、本発明の一実施形態に係る図１７のマルチメディアプロバイダの速度アダプタを示す概略ブロック図である。
【図１９】図１９は、本発明の別の実施形態に係る図１７のマルチメディアプロバイダの速度アダプタを示す概略ブロック図である。
【図２０】図２０は、本発明の更なる実施形態に係る図１７のマルチメディアプロバイダの速度アダプタを示す概略ブロック図である。
【図２１】図２１は、本発明の別の実施形態に係るマルチメディアプロバイダを示す概略ブロック図である。
【図２２】図２２は、本発明の一実施形態に係るユーザ端末を示す概略ブロック図である。
【技術分野】
【０００１】
本発明は、通信システムにおけるマルチメディアセッションの管理に関し、特に、そのようなマルチメディアセッションにおいてユーザが感知するマルチメディアチャネルの切り替え時間を短縮することに関する。
【背景技術】
【０００２】
背景
既存のモバイルネットワーク及び移動通信システムにおいて、広範囲の新しいサービスを提案及び提供する傾向がある。現在、マルチメディア又はＴＶコンテンツのためにモバイルネットワークを使用することに非常に大きな関心が持たれている。これは、従来技術においてモバイルＴＶと呼ばれることが多い。モバイルＴＶアプリケーションの目標は、ユーザが種々のマルチメディア又はＴＶチャネルを選択し且つ容易にザッピングできるＴＶと同様の体験を提供することである。
【０００３】
通常のＴＶチャネルは多くのユーザにブロードキャストされ、一般に、ユーザは受信して視聴するチャネルを選択することができる。モバイルＴＶも、（ライブ）メディア又はマルチメディアストリームのセットを何人かのエンドユーザに配信すると言う点において同様である。各マルチメディアストリームはＴＶチャネルに対応し、各ユーザは視聴するチャネルを選択することができる。現在、モバイルＴＶのブロードキャスト／マルチキャスト配信方法は開発途中である。そのような標準化の取り組みの例は、３ＧＰＰマルチメディアブロードキャスト／マルチキャストサービス（ＭＢＭＳ）及び欧州電気通信標準化機構（ＥＴＳＩ）デジタルビデオ放送‐ハンドヘルド（ＤＶＢ‐Ｈ）である。これらは、ブロードキャスト配信方法において従来のＴＶと同様である。
【０００４】
マルチキャスト／ブロードキャストに基づくモバイルＴＶが利用可能になるまでの間、既存のモバイル転送チャネルを介して実現される解決策が必要である。ユニキャスト転送がモバイルＴＶの好ましい配信手段であるため、既存のモバイル転送チャネルを介して実現される解決策は殆どユーザを有さないセル及び十分な容量を有するネットワークにとって将来大きな関心事となるだろう。
【０００５】
インターネットプロトコル（ＩＰ）に基づくネットワークを介するストリーミングを使用するモバイルＴＶと同様のサービスは、既存のモバイルネットワークに提供される。一例として、３ＧＰＰで開発されたパケット交換（ＰＳ）ストリーミングサービス（ＰＳＳ）がある。そのようなマルチメディア又はＴＶセッションを開始するために、通常、ユーザはウェブページ又はポータルサイトをサーフィンし、ライブストリーミングチャネルを見るためにリンクをクリック又は選択する。
【０００６】
AppleのQuicktime及びMicrosoftのメディアプレーヤ等、RealNetworks等のモバイルＴＶに使用することができるプロプライエタリストリーミングソリューションがいくつか存在する。通常、これらはポータルサイト又はウェブページを有し、そこでリンクがクリックされ、ある特定のチャネルの受信を開始する。
【０００７】
モバイルＴＶサービスの目標の１つは、通常のブロードキャストＴＶチャネルに対して行うのと同様に、チャネル間のザッピングを可能にすることである。全てのチャネルがブロードキャストされる場合、受信機は、適切な転送チャネルを選択し、適切なデマルチプレクサを使用することにより、チャネルをローカルに選択することができる。これは、一般的なケーブル、衛星又は地上テレビ、並びに今後のモバイル規格であるＭＢＭＳ及びＤＶＢ‐Ｈでも同様である。しかし、ユニキャストセッションの場合、クライアントは、「サーバ」又はマルチメディアプロバイダに所望のチャネルを送信させる必要がある。
【０００８】
ＩＰに基づくモバイルストリーミングを行う従来の方法は、ブラウザで特定のコンテンツを選択することである。これにより、セッション記述プロトコル（ＳＤＰ）又は同期マルチメディア統合言語（ＳＭＩＬ）ファイルのダウンロードを開始させ、そして、ユーザ端末のメディアプレーヤでリアルタイムストリーミングプロトコル（ＲＴＳＰ）ストリーミングセッションが始まる。通常、ユーザがユーザ端末の画面でコンテンツを見るまでにかかるおおよその時間は、約１０秒又は１０秒を僅かに超える。１０秒の内、５秒はアプリケーションのセットアップであり、残りは信号伝送（約２秒）及びバッファリング（約３〜４秒）である。ユーザが別の「マルチメディア又はＴＶチャネル」に切り替えたい場合、ユーザは、現在のデータストリームを停止し、ブラウザに戻り、ブラウザでリンクをクリックすることにより別のチャネルを選択しなければならない。そして新しいＲＴＳＰセッションが開始されるが、メディアプレーヤが起動してバッファリングを開始するため、新たに約１０秒の遅延が生じる。
【０００９】
国際出願［１］において、ユーザが感知するマルチメディアチャネルの切り替え時間を非常に効果的に短縮する技術が提示されている。基本的にこの技術は、新しいマルチメディアチャネルを選択するために、ユーザがユーザ端末のユーザ入力の１つを簡単にアクティブにすることを可能にする。ユーザがマルチメディアプロバイダのウェブページを再び訪れる必要なく且つ新しいセッションセットアップ手順を伴わずに、新しいチャネルのマルチメディアデータはユーザ端末に直接配信される。しかし、この時間短縮技術を使用する場合でも、約４秒のバッファリングは依然として実行される。
【発明の開示】
【００１０】
概要
従って、ユニキャスト（パケット交換）ネットワーク及び通信システムにおいてマルチメディアセッション中にマルチメディアチャネルを切り替える時に、ユーザが感知する時間を短縮する必要がある。
【００１１】
本発明は、従来技術の構成のこれら欠点及び他の欠点を克服する。
【００１２】
本発明の一般的な目的は、ユニキャスト通信システムにおいてユーザが感知するマルチメディアチャネルの切り替え時間を短縮することである。
【００１３】
本発明の別の目的は、採用したユーザ端末の変更又は適合を必要とせずに、ユーザの視点からチャネル切り替え手順を短縮することである。
【００１４】
本発明の特定の目的は、ユーザ端末が分からないように実行されるチャネル切り替え手順を短縮することである。
【００１５】
本発明の別の特定の目的は、ユーザが感知するマルチメディアチャネルの切り替え時間を短縮するための他の技術を補完するものとして使用できるチャネル切り替え手順を短縮することである。
【００１６】
これら及び他の目的は、添付の請求の範囲により定義される本発明により達成される。
【００１７】
簡単に説明すると、本発明は、ユニキャスト通信システムにおいてユーザが感知するマルチメディア送信元の切り替え時間を短縮することに関する。このユーザが感知する切り替え時間は、アプリケーションセットアップ、ユーザ端末とマルチメディアプロバイダとの間の信号伝送、並びにデータのレンダリング及び再生前に行われるマルチメディアデータのユーザ端末でのバッファリングによりかかる時間である。本発明は、切り替え時間全体の内、バッファリング時間の部分を短縮する。これは、端末におけるバッファリングが減少したために、マルチメディアチャネルの切り替え後、新しいチャネルのマルチメディアデータがユーザにとって非常に短い時間でレンダリングされ且つ利用可能になることを意味する。
【００１８】
本発明は、低減通信速度を決定することにより、ユーザ端末におけるバッファリング又はバッファレベルの低減を達成する。この低減通信速度は、通常、要求側ユーザ端末にメディアデータを転送する時にマルチメディアプロバイダにより採用される、対応する（平均）通信速度よりも平均して遅い。更に、この低減通信速度は、ユーザ端末のメディアプレーヤのレンダリング速度より遅い。これは、バッファにマルチメディアプロバイダから受信する新しいデータを再び書き込む速度より速く、マルチメディアデータが端末のバッファを出る、即ちメディアプレーヤによりレンダリングされることを意味する。その結果、ユーザ端末バッファのバッファレベルは低下する。
【００１９】
端末バッファのバッファレベルを下げることによりユーザが感知するチャネル切り替え時間の短縮を可能にするために、マルチメディアプロバイダは、その決定された低減通信速度を一時的に利用する。
【００２０】
説明のために、従来のチャネル切り替えにおいて、ユーザ端末におけるメディアバッファリングは約４秒かかるものとする。通常、その４秒とは、国際特許出願［１］の教示に従って実行されるマルチメディアチャネル切り替えをユーザが感知する合計時間である。これは、本発明の教示が文献［１］の切り替え時間の短縮を補完するものとして適用され、バッファリング時間を約１秒に短縮する場合、ユーザが感知するチャネル切り替え時間は約７５％短縮することを意味する。
【００２１】
バッファが少なくなり過ぎるか又は空になるという危険を防止し且つバッファレベル低減後に特定のユーザ端末にとって適切な最終的なバッファレベルとなるように、低減通信速度及び／又は低減速度が採用される時間の決定は、少なくとも部分的にユーザ端末の特定の機能に基づいて行われる。そのような場合、マルチメディアプロバイダは、それらバッファ機能の情報又は少なくとも機能の推定を可能にする情報をユーザ端末から受信するのが好ましい。
【００２２】
この状況において適切なパラメータは、ユーザ端末の初期バッファレベル、最大バッファレベル、最小バッファレベル及び／又は現在のレベルを含む。今日利用可能なユーザ端末の殆どが、端末の機種に依存する予め決められたバッファレベルを利用する。ユーザ端末は、利用した初期バッファレベルをマルチメディアプロバイダに通知できる。あるいは、バッファ総容量のうち所定の割合を利用するように端末が構成されているかも知れない。そのような場合、最大レベルの通知をプロバイダに送信することは、低減速度の決定において有用である。
【００２３】
一般に、ユーザ端末は、通常ゼロである最小バッファレベルが達成された場合にデータの再バッファリングを実行するように構成されている。これは、本発明のバッファレベル低下の結果、最小レベルに達しないことが好ましく、そうでなければ、バッファリング時間が予め決められた初期レベルに再び上昇し、低減したことが無駄になることを意味する。
【００２４】
端末は、周期的、間欠的及び／又は要求時に、現在のバッファレベルの状態の情報をマルチメディアプロバイダに送信することができる。このバッファフィードバックは、端末において所望のバッファレベルに微調整するためにプロバイダにより利用される。
【００２５】
ユーザ端末は、初期バッファレベル、最大バッファレベル、最小バッファレベル及び／又は現在のバッファレベルのデータを送信する代わりに、例えばセッションセットアップ中、又はチャネル切り替え要求の一部として端末機種の情報を含めることができる。マルチメディアプロバイダは、例えば利用可能な異なるユーザ端末機種に対して関連するバッファ容量データを一覧表示するテーブルにアクセスできる。テーブルルックアップ手順において、受信した機種データを使用することにより、マルチメディアプロバイダによる低減速度決定において使用可能なバッファレベル情報が提供される。
【００２６】
本発明の第１の実施形態において、決定した低減通信速度はゼロである。これは、決定した短い時間の間に新しいマルチメディアデータがユーザ端末に実際に送信されないことを意味する。この場合、低減通信速度に基づいて決定されるように、マルチメディアプロバイダは、現在のマルチメディアチャネルのデータを一時的にドロップする。本実施形態の好適な実現例において、マルチメディアプロバイダは、通常の速い通信速度を使用していくつかのデータパケットをユーザ端末に送信することによりセッションを開始する。第１のパケットは、端末のデータバッファに入力され、バッファリングされる。バッファリング手順が開始されると、プロバイダは、決定した時間の間、全てのマルチメディアデータパケットをドロップする。これは、新しいデータパケットはバッファに入力されず、既に受信したデータパケットの一部がバッファを出てレンダリングされることを意味する。従って、バッファレベルは低下する。バッファレベルが適切に低下すると、マルチメディアプロバイダは、ユーザ端末にデータパケットを再び送信し始める。そして、低下したバッファレベルは維持され、その後ユーザがマルチメディアチャネルを切り替えたい場合には、非常に短いチャネル切り替えを可能にする。
【００２７】
本実施形態は、非常に単純に実現できるという利点を有する。欠点は、マルチメディアチャネルの一部のデータが欠落するため、レンダリングされたデータの中に、ユーザが検出可能な不連続性ができることである。この欠点は、ドロップする有用なデータを少なくすることにより最小化することができる。例えば、マルチメディアプロバイダは、係数なしＰ画像及びサイレントオーディオを端末に送信することにより、チャネルのデータ送信を開始できる。そのような場合、この種のデータを含むデータパケットをドロップすることをユーザは気づかないだろう。
【００２８】
本発明の別の実施形態は、ユーザ端末からのチャネル切り替え要求と関連してバッファ減少を実行する。このチャネル切り替え後、マルチメディアプロバイダは、新しい要求チャネルのデータパケットをユーザ端末に直接配信する代わりに、要求チャネルの新しいデータの送信を一時的にスキップする。この送信が行われない間、端末バッファにおいて見つかった旧データチャネルのデータパケットがレンダリングされるため、バッファリングは減少する。
【００２９】
本実施形態において、第１のチャネル切り替えは、従来の技術を採用した場合と同様に長時間かかる。しかし、第１の切り替えが実行された後、ユーザ端末のバッファレベルは低下した。これは、切り替え中にデータのバッファリングが減少するため、更なるチャネル切り替えは非常に短い時間で実行されることを意味する。
【００３０】
本実施形態は、非常に単純に実現できるという利点を有し、ユーザ端末の再生に対する要求は、再生が第１のチャネル切り替えの前に行われるべきであるということのみである。欠点は、第１の切り替えが依然として長いことである。
【００３１】
本発明の更に別の実施形態において、マルチメディアプロバイダは、低減通信速度でマルチメディアデータをユーザ端末に一時的に送信する。この場合、通信速度はゼロではないが、ユーザ端末のメディアプレーヤのレンダリング速度より遅く且つ通常の速い通信速度より遅い。この低減データ提供速度のために、マルチメディアデータは、ユーザ端末のデータバッファが再び書き込まれる速度より速い速度でデータバッファを出る（レンダリングされる）。その結果、バッファレベルは低下する。
【００３２】
ライブストリーミングの場合、あるいはマルチメディア送信元の（一定）速度が変更できない場合、この解決策は、データがユーザ端末ではなくネットワークでバッファリングすることを必要とする。そのような場合、マルチメディアプロバイダは、ユーザ端末に送信する前に、ネットワークバッファにマルチメディアデータをバッファリングする。しかし、マルチメディアプロバイダからのデータ送信は、一時的な期間、完全に阻止されるわけではなく、データ送信は低減速度で進行する。これは、端末バッファが徐々に空になるのに伴って、ネットワークバッファは徐々に増加することを意味する。
【００３３】
ユーザ端末においてバッファレベルが適切に低下すると、マルチメディアプロバイダは、バッファが完全に空になるのを防止するために、好ましくは略レンダリング速度まで通信速度を上げる。ユーザ端末からチャネル切り替え要求を受信すると、マルチメディアプロバイダは、送信前にネットワークバッファへのバッファリングを行うこと無く、新しい要求チャネルのデータを直接配信し始める。これは、ユーザ端末にまだ送信されずにネットワークバッファに依然として存在する旧チャネルのデータが廃棄されることを意味する。
【００３４】
本実施形態の利点は、ユーザ端末において再生されるメディアに不連続性がなく、第１の切り替えが従来技術と比較して短い時間で行われることである。
【００３５】
バッファに格納されたメディアのレンダリングは、メディア又はマルチメディアデータを含む受信した各パケットに対して利用可能なタイムスタンプ（又はそれに同様のもの）により制御される。通常、ユーザ端末における初期バッファリング処理は、Ｘ秒、例えば４秒の実経過時間続くが、その期間は、バッファのバイト数であってもよく、あるいはタイムスタンプにより示される時間差であってもよい。いずれにしても、初期バッファリング期間の後、メディアプレーヤは、最小のタイムスタンプを有するメディアのレンダリングを開始し、更なるパケットのタイムスタンプに従ってメディアを再生する。一般に、ある時間に消費されるバイト数は、その時間における符号化速度（ビット数）に依存し、転送速度には依存しない。換言すると、タイムスタンプは提示時間（再生時間）を示すのであって、パケットの到着時間／送信時間を示すわけではない。
【００３６】
データをドロップする場合でもレンダリング速度を下回る低減通信速度を維持し且つユーザ端末のメディアプレーヤでわからないようにバッファレベル低下を実行するために、マルチメディアプロバイダは、連続したタイムスタンプが得られるように、送信したデータパケットにタイムスタンプを割り当てるのが好ましい。また、マルチメディアデータの送信パケットのシーケンス番号を、切れ目なく連続したシーケンス番号付けとなるように設定してもよい。そのような場合、メディアプレーヤは、データパケットがマルチメディアプロバイダにおいてドロップ、スキップ又は遅延されたことに気付かない。連続したタイムスタンピングにより、端末のメディアプレーヤは、本発明のバッファレベルを低減する実施形態に影響されない同一の連続した速度でメディアレンダリングを実行する。
【００３７】
本発明は、以下の利点を提供する：
【００３８】
‐マルチメディアチャネルを切り替える場合にユーザが感知する時間を短縮する；
【００３９】
‐チャネルの「ザッピング」体験を向上する；
【００４０】
‐ユーザ端末の変形、変更又は制御を必要としない；
【００４１】
‐他のチャネル切り替え時間短縮技術を補完するものとして利用することができる；
【００４２】
‐ユーザ端末のメディアプレーヤ及びデータレンダリングに影響を与えずにバッファレベルを低減し、チャネル切り替え時間を短縮する；
【００４３】
‐本発明は、非常に容易に実現することができ、既存のネットワークユニットに対する変更を殆ど必要としない。
【００４４】
本発明により提供される他の利点は、本発明の実施形態の以下の説明を読むことにより理解されるだろう。
【００４５】
添付の図面と共に以下の説明を参照することにより、本発明は、本発明の更なる目的及び利点と共に最もよく理解されるだろう。
【発明を実施するための最良の形態】
【００４６】
詳細な説明
図中、同一の参照符号は、対応する要素又は同様の要素に対して使用される。
【００４７】
本発明は、ユニキャスト通信システムにおけるマルチメディアセッションの管理に関し、特に、そのようなシステムにおいてマルチメディアチャネルを切り替える時にユーザが感知する時間を短縮する方法及び構成に関する。
【００４８】
従来のユニキャストインターネットプロトコル（ＩＰ）による無線通信システムにおいて、ユーザがマルチメディアセッション中にメディア又はマルチメディアチャネルを切り替えたい場合、通常、ユーザは、ユーザ端末のウェブブラウザ又は他のアプリケーションによりコンテンツプロバイダ又はサービスプロバイダにより提供されるウェブサイトを訪れる必要がある。新しいアプリケーションセッションのセットアップが実行されるが、そのセットアップは、殆どの通常のユーザ端末において約５秒かかり、ユーザ端末とコンテンツプロバイダ及び／又はストリーミングサーバとの間の信号伝送が含まれる場合には約７秒かかる。その約７秒に対して、ユーザ端末におけるマルチメディアデータのバッファリング時間である約４秒が追加される。これは、チャネル切り替え後にユーザ端末により感知される遅延又は遅れの合計が約１０秒か又は１０秒を僅かに超えることを意味する。そのうちの約４０％は、ユーザ端末におけるデータバッファリングによるものである。
【００４９】
国際出願［１］において、マルチメディアチャネル切り替え中にウェブサイトを訪れ且つ新しいアプリケーションセッションをセットアップする従来の必要性を除去する解決策が提示される。しかし、この技術はユーザが感知するチャネル切り替えの合計時間を大きく短縮するが、ユーザ端末におけるデータバッファリングの約４秒は依然として残る。
【００５０】
本発明は、ユーザ端末におけるバッファレベル又はバッファリング時間を故意に低下又は短縮させることにより、チャネル切り替え後のユーザが感知する遅延又は遅れの合計を減少する。その結果、次にマルチメディア切り替えが発生した場合は、ユーザ端末のグラフィカルユーザインタフェース上に、非常に速くマルチメディアがレンダリングされ、且つデータが現れる。
【００５１】
このバッファレベルの低下を達成する本発明の基本概念は、マルチメディア通信速度又はスピードを一時的に遅くし、ユーザ端末の再生又はレンダリングレート又は速度よりも遅く維持することである。その結果、一時的にデータは、ユーザ端末バッファが補充される（すなわち、マルチメディアプロバイダから受信される）速度より速くユーザ端末バッファから出力（すなわち、レンダリング）され、バッファレベルは低下する。その後、バッファからデータが完全に無くなるのを防止するために、マルチメディアデータ通信速度は上げられ、例えば、通信速度は以前の相対的に速い速度に戻される。
【００５２】
この状況における典型的な例は、ユーザ端末のバッファレベルを約４秒のデータバッファリングから約１秒のバッファリングに下げることである。その結果、文献［１］の技術に従って取得可能な切り替え時間と比較して、チャネル切り替え後のメディアレンダリングの遅延を合計で約７５％削減することができる。これは、従来の解決策と比較して、ユーザにとって非常に良い相違点である。
【００５３】
ストリーミングユーザ端末におけるバッファリング状態を記述する一般的な方法は、受信及び再生される累積バイト数を時間の関数として示す図を描くことである。ある時間において受信されたバイト数と再生されたバイト数との差は、バッファ占有量レベルである。図を視覚的に分かり易くするために、以下において通常の受信速度及びレンダリング又は再生速度の双方が一定であり、例えば８ｋＢ／ｓと仮定するが、それに限定されない。これは、限定しない図示される例として考えられるべきである。図１は、４秒の初期（一定）バッファリングを伴う従来の解決策による原理を概略的に示す。
【００５４】
図中、塗りつぶされた正方形を含む曲線２０は、受信したマルチメディアデータ量を表し、マルチメディアプロバイダの平均通信速度を反映している。塗りつぶされた円を含む曲線３０は、ユーザ端末のマルチメディアプレーヤによりレンダリングされるマルチメディアデータ量を表す。尚、図１における上側曲線２０と下側曲線３０との間の差は一定であり、４秒の初期バッファリング時間分の３２ｋＢである。図１及び以下に更に説明される本発明の対応する図において、線の間の垂直差は、ある時間におけるバッファ占有量のバイト数に対応する。線の間の水平差は、あるバッファレベルにおけるバッファ占有の時間に対応する。
【００５５】
チャネル切り替えがトリガされる場合、新しいチャネルのマルチメディアデータは、レンダリングされ、ユーザが（視覚的及び／又は聴覚的に）アクセスできるようになる前にユーザ端末にバッファリングされる。その結果、図示される従来の例において、新しいデータのレンダリングは受信時に４秒遅延される。
【００５６】
この例及び以下の図において、図を簡単にするために、符号化速度及び転送速度が一定であることを仮定した。しかし、本発明はそれに限定されない。実際には、レンダリング曲線３０は、受信曲線２０に対して一定の距離を有さない。一定の通信速度である場合でも、受信速度を変化させるジッタが存在する。しかし、従来技術による受信曲線とレンダリング曲線との間の平均差、すなわちバッファリング時間は略一定である。
【００５７】
バッファに格納されたメディアのレンダリングは、メディア又はマルチメディアデータを含む各受信パケットに対して利用可能であるＲＴＰ（リアルタイムプロトコル）タイムスタンプ（又はそれに同様のもの）により制御される。通常、初期バッファリング処理は、Ｘ秒、例えば４秒の実経過時間続くが、その期間は、バッファのバイト数であってもよく、あるいはＲＴＰタイムスタンプにより示される時間差であってもよい。いずれにしても、初期バッファリング期間の後、メディアプレーヤは、最小のタイムスタンプを有するメディアのレンダリングを開始し、更なるパケットのタイムスタンプに従ってメディアを再生する。一般に、ある時間に消費されるバイト数は、その時間における符号化速度（ビット数）に依存し、転送速度には依存しない。換言すると、タイムスタンプは提示時間（再生時間）を示すのであって、パケットの到着時間／送信時間を示すわけではない。
【００５８】
図２は、本発明に従って、ユニキャスト通信システムにおいてユーザが感知するマルチメディアチャネルの切り替え時間を短縮する方法を示すフローチャートである。方法は、オプションのステップＳ１で開始する。ステップＳ１において、マルチメディアプロバイダ又はコンテンツプロバイダは、第１の通信速度又は現在の通信速度で第１のマルチメディアチャネル又は現在のマルチメディアチャネルのマルチメディアデータをユーザ端末に送信する。本発明において、「通信速度」は、時間単位毎にユーザ端末に送信されるデータ量（例えば、データのバイト数）と定義される。データの符号化速度の変動に対応すると共に転送品質（無線の状態）の変動に対する余裕を提供するために、ユーザ端末において、マルチメディアデータはレンダリング及び再生前にバッファリングされる。
【００５９】
次のステップＳ２において、マルチメディアプロバイダは、現在のマルチメディアセッションに対する第２の通信速度を決定する。この第２の通信速度は、第１の通信速度より遅く、ユーザ端末のマルチメディアデータのレンダリング速度又は再生速度より遅い。その結果、マルチメディアプロバイダは、この遅い通信速度を一時的に採用することによりユーザ端末のバッファレベルを下げることができる。
【００６０】
ステップＳ３において、マルチメディアプロバイダは、第２の通信速度を一時的に採用してユーザ端末のバッファレベルを下げることにより、第１の（現在の）チャネルから第２の（新しい）マルチメディアチャネルへの可能なチャネル切り替え後にユーザ端末において第２のデータチャネル又は新しいデータチャネルのマルチメディアデータをレンダリングする遅れ又は遅延時間を能動的に短縮する。これは、マルチメディアプロバイダが遅い第２の通信速度でマルチメディアデータをユーザ端末に一時的に提供又は送信することを意味する。当業者には周知であるように、通信速度は０バイト／秒であってもよく、これは、データが一時的な期間に実際に送信されないことを示す。従って、本発明によれば、「決定した第２の通信速度でマルチメディアデータを一時的に送信する」という表現は、ある期間にユーザ端末に送信されるマルチメディアデータが、第１の通信速度が使用される場合と比較して少ないか又は全く送信されないことを示す。一般に、この状況において、第１の通信速度がＸｋＢ／ｓであり且つ第２の通信速度がＹｋＢ／ｓである場合、Ｚをユーザ端末のメディアプレーヤのレンダリング速度（ｋＢ／ｓ）とすると、０≦Ｙ＜Ｘ且つＹ＜Ｚである。更に通常、Ｘは平均してＺ以上である。
【００６１】
尚、通信速度が一時的にゼロに低下した場合でも、メディアプレーヤがバッファに既に格納されているマルチメディアデータをレンダリングし続けるため、通常、ユーザは通信速度の変化を体験しない。従って、チャネル切り替えの遅れ時間を短縮する手段として採用される本発明のバッファレベルの低下は、一般に、関連するユーザにとって著しい欠点の原因にはならない。
【００６２】
所望のバッファレベルまで下がると、マルチメディアデータは、第１の通信速度又は第３の通信速度等の速い通信速度でマルチメディアプロバイダにより再び送信される。後者の場合、第３の通信速度は、第１の速度より速いか、あるいは第１の速度より遅いが第２の通信速度より速い。
【００６３】
ユーザがマルチメディアチャネルを切り替えたい場合、データのバッファリングが短いため、ユーザ端末における受信後、新しいチャネルのデータは非常に短い時間でレンダリングされる。例えば４秒の初期バッファレベルは、本発明を採用することにより、約１秒のデータのバッファリングに減少される。
【００６４】
第２の通信速度及び／又は第２の通信速度がマルチメディアプロバイダにより採用される時間は、２つの相反する目的の間の妥協点としてプロバイダにより決定される。第１に、チャネル切り替え後にマルチメディアデータをレンダリングする遅れ時間を短縮するため、ユーザの視点から、可能な限り低いバッファレベルが望ましい。低いバッファリングにより、感知されるチャネル切り替え時間は短くなり、新しいメディアが早く再生される。第２に、符号化速度及び転送（無線）条件の変動により、バッファレベルを低くしすぎると、データバッファが空になる、バッファアンダーランを起こすことがある。そのような場合、ユーザ端末は、例えば、４秒のバッファリング等の元の（大きな）バッファレベルまでデータを再バッファリングする。その結果、バッファレベルを故意に低下することは無駄になった。
【００６５】
これは、以下に更に説明するように、本発明によれば、ユーザ端末のバッファレベルを、再バッファリングを必要とせずに符号化速度及び転送の状態の僅かな変動に対処するのに十分な余裕があるところまで可能な限り下げるのが好ましいことを意味する。
【００６６】
その後、方法は終了する。
【００６７】
本発明のバッファレベル低下技術は、国際出願［１］で提示されるような他の切り替え時間短縮技術を補完するものとして採用されるのが好ましい。簡単に説明すると、ユーザがコンテンツプロバイダ又はマルチメディアプロバイダから入手可能なマルチメディアチャネルを観たい場合、ユーザはそのマルチメディアチャネルに対する要求をプロバイダに送信する。通常、このチャネル要求は、ユーザがマルチメディアプロバイダのウェブページを訪れ且つマルチメディアチャネルに関連付けられたリンクをクリックすることにより生成される。マルチメディアプロバイダは、ユーザが実行中のセッションを終了し且つマルチメディアプロバイダのウェブページを再び訪れる必要なく、任意の別のチャネルへの使用し易い切り替えを可能にするのに必要な全ての情報、オブジェクト及び命令を含むマルチメディアセッションセットアップ記述を自動的に生成する。
【００６８】
生成されたセットアップ記述はユーザ端末に返され、記述に含まれるデータオブジェクトは端末により処理される。まず、記述のマルチメディアオブジェクトは、端末において処理される場合、端末の画面又はグラフィカルユーザインタフェース（ＧＵＩ）に表示されるマルチメディアセッションウィンドウを規定する。このセッションウィンドウは、要求されたチャネルのマルチメディア（ビデオ）データを表示するように適応された表示領域を含む。ウィンドウは、プロバイダから入手可能な別のマルチメディアチャネルに関する情報を含む表示可能チャネル領域を更に含む。この情報は、例えばそれら別のチャネルで現在入手可能であるＴＶ番組又は映画の識別子又はアイコンであってもよい。これは、ユーザが表示画面の全ての異なるマルチメディアチャネルに関する情報に対してセッション開始時に既にアクセスできることを意味する。従って、ユーザは、セッションを終了して、その種の情報を入手するためにマルチメディアプロバイダのウェブページを再び訪れる必要がない。
【００６９】
セッションセットアップ記述の関連付けオブジェクトは、端末において処理される場合、端末のユーザ入力とセッションウィンドウのチャネル領域で通知される別のチャネルの識別子との間の関連付け又はバインディングを規定する。チャネル識別子と関連付けられるユーザ入力は、例えば端末のキーパッドのキー又はタッチパネルの部分であってもよい。ユーザが１つのユーザ入力をトリガすると、セットアップ記述の要求オブジェクトは、トリガされたユーザ入力に識別子が関連付けられた別のチャネルへの要求を生成する。このチャネル切り替え要求は、マルチメディアプロバイダに自動的に送信され、マルチメディアプロバイダは、それ以上のユーザからの対話なしでチャネル切り替えを実行する。
【００７０】
換言すると、ユーザがマルチメディアチャネルを切り替えたい場合、ユーザは、例えばそのチャネルに割り当てられたユーザ端末上の１つのキーを単純に押下する。チャネル領域は、入手可能な別のチャネルに関する情報を一覧表示することに加え、別のチャネルに割り当てられたキー（ユーザ入力）を識別するのが好ましい。関連するキーが押下されると、要求オブジェクトはチャネル切り替え要求をコンパイルする。この切り替え要求は、関連付けオブジェクトにより提供されるキーバインディングを介して取得される要求されたチャネルの識別子を含む。更に、マルチメディアプロバイダが関連する端末を識別できるように、要求はユーザ端末の識別子を含む。
【００７１】
これは、ユーザが文献［１］に従ってセッション中にマルチメディアチャネルを切り替えるために実行する必要のある手順のみが、表示されるチャネル領域により、所望のチャネルに関連付けられ且つ割り当てられたユーザ入力（キー）を識別し、その後そのユーザ入力をアクティブにすることを意味する。これは、ユニキャストシステムに対する従来の解決策と比較されるべきである。従来の解決策では、ユーザは、まず現在のセッションを終了し、プロバイダのウェブページを再び訪れ、所望のマルチメディアチャネルに対するリンクを選択及びクリックする必要がある。その後、新しいセッションセットアップ手順が実行される必要があるため、非常に時間のかかる煩雑なチャネル切り替え手順である。
【００７２】
マルチメディアプロバイダがチャネル切り替え要求を受信した場合、マルチメディアプロバイダは、含まれるチャネル識別子により新しい所望のチャネルを識別し、含まれる端末識別子を使用してこの新しいチャネルのマルチメディアデータフローを適切なユーザ端末に向けて送る。
【００７３】
上記説明に従って実行されるチャネル切り替えのユーザが感知する合計時間は、主にユーザ端末におけるデータバッファリングにより占められる。従って、このデータバッファリング時間を短縮する本発明は、文献［１］の向上したチャネル切り替え手順及び他の同様の切り替え時間短縮手順を非常に適切に補完する。
【００７４】
バッファアンダーラン、つまり空になるという危険を回避し且つバッファレベル低下後に特定のユーザ端末にとって最終的なバッファレベルが適切となるようにするために、第２の通信速度及び／又は第２の通信速度が採用される時間の決定は、少なくとも部分的にユーザ端末からの入力情報に基づいて行われる。これは、本発明のバッファレベル低下がユーザ端末の特定の機能に基づいて実行されることを意味する。
【００７５】
図３は、そのような決定がどのように実現されるかを示す異なる実施形態を示すフローチャートである。この方法は、図２のステップＳ１から継続する。次のステップＳ１０において、マルチメディアプロバイダは、ユーザ端末の初期バッファレベル又は時間の推定値を提供する。本発明の本実施形態及び他の実施形態において、データバッファのバッファレベルは、バッファに含まれるバイト数として表されるか、あるいはバッファへのデータのバッファリングの時間として表される。これは、バッファレベルが特定のバッファリング時間として表され且つそれと関連して説明される場合、バッファレベルはバイト数のバッファレベルも含み、逆に、バッファレベルがバッファに含まれるバイト数に関して表され且つそれと関連して説明される場合、バッファレベルはバッファリング時間のバッファレベルも含むことを意味する。
【００７６】
通常、異なる端末機種は、端末の特定の機能に基づいて選択される、異なる予め決められたバッファリング時間を有する。これは、端末機種に応じてバッファレベルを下げることが有利であることを意味する。マルチメディアプロバイダは、端末の初期バッファレベルに適応される適切なバッファレベルの低下を達成するためにこの情報を使用できる。例えば、初期バッファレベルが４秒の第１のクライアントユーザ端末と初期バッファリングが３秒の第２のクライアントユーザ端末を仮定する。双方のユーザ端末は、バッファが空になるとデータを再バッファリングする。また、適切なバッファレベルの低下は、端末における最終的なバッファリングが約１秒を達成するような低下とする。マルチメディアプロバイダがユーザ端末の入力情報を受信しない場合、プロバイダは、端末のバッファリングが３秒減少するように、第２の低通信速度を設定できる。そのような第２の通信速度及びバッファリングの低下は第１のユーザ端末には非常に適しているが、第２のユーザ端末にはバッファレベルの低下が大きすぎるため、第２のユーザ端末は、初期の３秒のレベルまでデータを再バッファリングする。これに対して、第２のユーザ端末に対して適応された第２の通信速度及びバッファレベルの低下の結果、第１のユーザ端末に対しては最適でないバッファレベルとなる。従って、マルチメディアプロバイダが参加しているユーザ端末から入力情報を受信していれば、プロバイダは、特定のユーザ端末毎に適応された個々のバッファレベル低下を実行できる。
【００７７】
第１の実施形態において、この入力情報は、ユーザ端末の機種及び可能性のあるブランドの通知であってもよい。マルチメディアプロバイダは、可能な端末機種及びブランドのリストにアクセスでき、そのリストは、そのようなユーザ端末機種により採用された初期バッファレベルを指定する。通常、機種及びブランドの情報は、マルチメディアチャネル要求及びチャネル切り替え要求に対して使用されるハイパーテキスト転送プロトコル（ＨＴＴＰ）要求で送信されている。これは、そのようなＨＴＴＰ要求から必要な機種及びブランド情報を抽出することにより、その要求がマルチメディアプロバイダにより情報源として使用できることを意味する。別の可能性としては、例えば３ＧＰＰの文献［２］で説明されるような無線アプリケーションプロトコル（ＷＡＰ）又はＲＴＳＰ及びＨＴＴＰに対して使用されるユーザエージェントプロファイル（ＵＡＰｒｏｆ）の機種属性から端末機種情報を抽出することがある。
【００７８】
ユーザ端末が初期バッファレベルの情報をマルチメディアプロバイダに実際に送信することにより、リスト又はテーブルルックアップを不必要にすることは、本発明により理解される。
【００７９】
いずれの場合においても、マルチメディアプロバイダは、機種及びオプションとしてブランドの情報を抽出し、例えば特定のユーザ端末の初期バッファレベルを判定するためにその情報をリストと共に使用する。図３のステップＳ１１及びＳ１２で開示される実施形態と関連して更に詳細に説明されるように、リストは、ユーザ端末機種の初期バッファレベルに加えて又はその代わりに、端末機種の最大バッファレベル及び／又は最小バッファレベルの情報を含むことができる。
【００８０】
ステップＳ１１に示されるような本発明の別の実施形態において、マルチメディアプロバイダは、ユーザ端末の最大バッファレベルの推定値を提供できる。実際のユーザ端末は、データバッファの容量の一部のみを通常使用し、潜在的により多くのデータをデータバッファにバッファリングすることが可能である。そのような場合、ユーザ端末の最大バッファリング容量は、第２の通信速度及び／又は第２の通信速度の一時的な使用時間を決定するために使用される。例えば、殆どの端末機種は、通常バッファリング容量の８０％のみを利用するように構成される。従って、ユーザ端末の初期バッファリングレベル又は現在のバッファリングレベルの推定値を取得するために、最大バッファレベルの情報を、この予め決められた範囲のアプリケーションと共に使用することができる。本実施形態において、マルチメディアプロバイダの機種リストは、異なる端末機種の最大バッファ容量の情報を含むのが好ましい。
【００８１】
ステップＳ１２に示されるような本発明の更に別の実施形態において、マルチメディアプロバイダは、ユーザ端末の最小バッファレベルの推定値を提供する。最小バッファレベルは、ユーザ端末において許容される最小バッファリングである。その最小レベル以下にバッファリングが減少すると、ユーザ端末の予め決められた初期バッファレベルまで再バッファリングされる。従って、チャネル切り替え後のユーザが感知する遅れを減らすために、本発明に係るバッファレベル低下の実行は、最小バッファレベルに到達しないように行われ、データ再バッファリング及び初期の高レベルへのバッファレベル増加の危険を防止する。殆どの一般的なユーザ端末機種の場合、この最小バッファレベルは０バイトであるが、約０．５ｓのデータ等のより大きい余裕を利用できる。
【００８２】
Ｓ１０及びＳ１１の実施形態と同様に、マルチメディアプロバイダが入手可能な機種リストは、端末機種において許容される最小バッファレベルの情報を含むことができる。
【００８３】
ステップＳ１０〜Ｓ１２に関連して上述した実施形態を組み合わされてもよいことは、本発明により理解される。例えば、マルチメディアプロバイダの機種リストは、利用可能なユーザ端末機種に対する最小バッファレベルと共に初期バッファレベル又は最大バッファレベルの情報を含むことができる。あるいは、ユーザ端末は初期／最大バッファレベル及び最小バッファレベルの情報を直接送信できる。
【００８４】
通常、初期バッファレベル、最大バッファレベル及び最小バッファレベルが特定のユーザ端末の機能に依存する予め決められた値であるため、殆どの場合、それら値は動作中に変化しない。その結果、値又は値を提供できるようにする情報をマルチメディアプロバイダに一度通知するだけで十分である。上述のように、この通知は、セッションセットアップ又はチャネル切り替え手順の一部であってもよい。本発明によれば、実際には、マルチメディアセッション前又はマルチメディアセッション中の通知を可能にする任意の解決策を利用することができる。
【００８５】
ステップＳ１３に示される更なる実施形態において、マルチメディアプロバイダは、ユーザ端末の現在のバッファレベルの推定値を提供する。これは、マルチメディアプロバイダが好ましくはセッション中にユーザ端末の現在のバッファリングの状態を取得できることを意味する。ユーザ端末は、間欠的に、周期的に及び／又はマルチメディアプロバイダからの要求に基づいて、現在のバッファ状態のフィードバックをプロバイダに送信するように構成することができる。バッファレベルを信号で伝送する機構は、３ＧＰＰの文献［２］において考案されている。これが以前に使用されたのは、バッファ占有量を最大限にすることによりネットワークの問題に対する頑強性を最適化するためであった。本発明の範囲において、フィードバックは、バッファレベルを小さな定数に維持するために上記方法の内の１つを監視又はその制御を補助する方法として全く新しい方法で使用される。本実施形態は、本発明に係るバッファレベルがユーザ端末において適切な小さな値まで減少するように低下を微調整するために採用される。例えば、マルチメディアプロバイダは、セッションセットアップ中に受信される機種及びブランド情報に基づいて、ユーザ端末の初期バッファレベルを判定する。この初期レベルは、端末バッファを減らすためにセッション中に一時的に採用される低減通信速度を決定するために利用される。バッファ低減の後、マルチメディアプロバイダは、低減後に取得したバッファレベルのフィードバック情報を受信できる。プロバイダは、更なるバッファリングの削減が望まれるか否かを判定するために、そのフィードバックを使用できる。
【００８６】
上述から当業者には明らかであるように、ステップＳ１３のバッファレベルフィードバック解決策は、ステップＳ１０〜Ｓ１２の任意の実施形態と組み合わされてもよく、あるいはステップＳ１０〜Ｓ１２の実施形態の任意の組み合わせと組み合わされてもよい。方法は、図２のステップＳ２に継続する。ステップＳ２において、マルチメディアプロバイダは、低減通信速度を決定するために提供されたバッファレベル情報を利用する。
【００８７】
更に、同一の結果をもたらすバッファの低減は、必ずしも毎回実行される必要はない。例えばステップＳ１４により概略的に示されるように、バッファレベルの低下は、通信システムの現在の無線の状態等の他の入力情報に基づいて実行することもできる。ユーザ端末におけるデータバッファリングが共に転送品質（無線の状態）の変動に対する余裕を提供すると共に、データの符号化速度の変動に対応するために実行されるため、本発明のデータバッファの低下は、現在の転送品質及び符号化速度に少なくとも部分的に基づいて実行される。この状況において、無線の状態が悪い（低転送品質及び大きな符号化速度の変動）間は、バッファが完全に枯渇する危険を防止するために、適切な無線の状態が適切な時よりも本発明のバッファレベルの低下を小さくすることが好ましい。信号対雑音（Ｓ／Ｎ）比等の異なる品質パラメータにより例示されるような現在の無線の状態の情報又は推定値は、実際のマルチメディアデータ送信を実行する基地局及び／又はユーザ端末等のネットワークノードから取得することができる。
【００８８】
上述のように、マルチメディアプロバイダは、ユーザ端末のメディアプレーヤのレンダリング速度より遅い低減通信速度を決定する。通常、メディアプレーヤのレンダリング速度は、メディアのタイムスタンピングにより規定される。すなわち、１秒のマルチメディアデータは１秒間にレンダリングされる。非常に一般的でなく且つ複雑であるが、ユーザ端末が適応レンダリング速度を採用する場合、マルチメディアプロバイダは、端末から速度入力情報を受信するのが好ましい。採用されたレンダリング速度の情報は、ユーザ端末から直接受信される。あるいは、マルチメディアプロバイダにおいて提供される上述のリストは、異なる端末の種類に対して、利用されるレンダリング速度の情報を含むことができる。マルチメディアプロバイダは、適切な低減通信速度を決定するために、可能性としてバッファ容量情報及びフィードバックと共にその情報を利用できる。
【００８９】
典型的な実現例において、そのような適応レンダリング速度は、端末の現在のバッファレベルに依存し且つ従う。これは、ユーザ端末からのバッファフィードバック情報が端末の現在のレンダリング速度及び採用されるべき低減通信速度を決定するためにプロバイダにとって有用な情報源であることを意味する。
【００９０】
図４は、図２の遅れ時間短縮ステップＳ３の一実施形態を更に詳細に示すフローチャートである。この方法は、図２のステップＳ２から継続する。次のステップＳ２０において、第２の通信速度に基づいて決定されるように、マルチメディアプロバイダは現在のマルチメディアチャネルのデータを一時的にドロップする。これは、一時的な期間、利用された低減通信速度が実際にゼロであり、現在のチャネルのデータストリームのコンテンツの一部はユーザ端末に送信されないことを意味する。
【００９１】
本実施形態の好適な実現例において、マルチメディアプロバイダは、（速い／通常の）第１の通信速度を使用してデータのいくつかのパケットをユーザ端末に送信することによりセッションを開始する。それら第１のパケットは、端末のデータバッファに入力され且つバッファリングされる。バッファリング手順が開始されると、決定された時間の間、プロバイダは全てのマルチメディアデータパケットをドロップする。これは、新しいデータパケットはバッファに入力されないが、既に受信されたデータパケットの一部がバッファを出てレンダリングされることを意味する。このように、バッファレベルは低下する。バッファレベルが適切に低下すると、マルチメディアプロバイダは、データパケットをユーザ端末に再び送信し始める。低下したバッファレベルは維持され、その後ユーザがマルチメディアチャネルを切り替えたい場合に、チャネル切り替えを非常に短くできる。
【００９２】
このバッファレベルの低下をユーザ及びユーザ端末に対して可能な限りシームレスにするために、ステップＳ２１においてマルチメディアプロバイダは、ユーザに送信される後続のデータパケットのタイムスタンプ及びオプションとしてパケット番号付けを変更するのが好ましい。このタイムスタンプの変更及びパケットの再番号付けのために、ユーザ端末は、データが実際に欠落したことに気付かない。
【００９３】
図５及び図６において、この原理を更に詳細に示す。図５において、データパケット４０１〜４０４は、データストリーム４５０の形式でマルチメディアプロバイダ１００からユーザ端末（不図示）に配信される。本発明では、データパケット４０１〜４０４は、第１のマルチメディアチャネルを表す所定のマルチメディア送信元４１０から発生する。この図示される例において、マルチメディアプロバイダ１００は、２つの可能なデータ送信元４１０、４２０にアクセスできるため、２つの異なるマルチメディアチャネルを接続ユーザ端末に提供できる。図５において、データパケット４０５〜４０８の第１のストリームは、第１のデータ送信元４１０から受信され、データパケット４２１〜４２４の第２のストリームは、同様に第２の送信元４２０から受信される。尚、異なるストリームのデータパケット４０１〜４０８及び４２１〜４２４は連続したシーケンス番号を有する。図中、第１のデータ送信元２１０から発生するデータパケット４０１〜４０８は、ＤＰ３３〜ＤＰ４０の範囲の第１のシーケンス番号を有する。第２の送信元２２０のデータパケット４２１〜４２４は、ＤＰ１１〜ＤＰ１４の第２の異なるシーケンス番号を有する。図６は、図４の遅れ時間短縮の実施形態を採用した後の状態を示す。図６において、マルチメディアプロバイダ１００は、データパケット４０５、４０６の２つをドロップするため、それらデータパケットはユーザ端末に送信されることはない。
【００９４】
ユーザ端末に連続したマルチメディアデータストリーム４００を提供するために、マルチメディアプロバイダ１００は、マルチメディアプロバイダ１００を出て同一のユーザ端末に送信されるデータパケット４０１〜４１０が連続したシーケンス番号付け（ＤＰ３３〜ＤＰ４０）を有するように、データパケット４０７〜４１０に再番号付けする。これは、データパケット４０７〜４１０がＤＰ３９〜ＤＰ４１からＤＰ３７〜ＤＰ４０に再番号付けされ、連続した番号付けを保持することを意味する。シーケンス再番号付けは、チャネルの残りのデータパケット４１１〜４１４に対して継続される。
【００９５】
シーケンス番号より重要なことは、図５及び図６と関連して上述したシーケンス番号付けと同様の手順に従って、データパケット４０１〜４０４、４０７〜４１０のタイムスタンプＴ１〜Ｔ８が割り当てられることである。これは、データパケット４０１〜４１０の連続したタイムスタンプＴ１〜Ｔ８が取得され且つデータパケットストリーム４５０がユーザ端末に対して連続して見えるように、データパケット４０７〜４１０のタイムスタンプＴ５〜Ｔ８がマルチメディアプロバイダ１００により設定されることを意味する。
【００９６】
従来技術において周知であるように、マルチメディアデータは、ビデオデータ及びオーディオデータの形式であってもよい。マルチメディアストリームを提供するマルチメディアチャネルは、ビデオデータから成るデータパケットを含むビデオストリームとオーディオデータから成るデータパケットを含むオーディオストリームとを提供すると考えられる。そのような場合、ビデオデータパケット及びオーディオデータパケットの連続したシーケンス番号付け及びタイムスタンピングを取得するために、本発明に係るシーケンス番号付け及びタイムスタンピングは、双方のデータストリームに対して実行されるのが好ましい。ユーザ端末におけるオーディオ再生時の劣化を回避するために、オーディオパケットに対するタイムスタンプの増加量は、データパケットが故意にドロップされた場合でも一定に保持されるのが好ましい。これにより、入力時間と出力時間との間に僅かな時間変位が生じる。ビデオパケットのタイムスタンピングは、同期を保持するようにオーディオタイムスタンピングに基づいて同様に調整されるのが好ましい。この状況において、オーディオデータはマスタである。要約すると、マルチメディアプロバイダは、オーディオデータストリームが連続したタイムスタンプを有するようにオーディオデータパケットにタイムスタンプを割り当て、またオーディオデータパケットのタイムスタンプの割り当てに基づいてビデオデータパケットにタイムスタンプを割り当てる。
【００９７】
図４を再び参照すると、データが送信されない期間の後、ステップＳ２２において上述のように、マルチメディアプロバイダは、通常の第１の通信速度又は第３の通信速度でタイムスタンプ調整され且つオプションとしてシーケンス再番号付けされたデータパケットの送信を継続する。その後、方法は終了する。
【００９８】
本実施形態は、単純に実現できるという利点を有し、マルチメディアプロバイダは、単純にデータパケットを送信することを一時的にやめ、同一のマルチメディアチャネルの後続のデータパケットのタイムスタンプを調整する。しかし、通常プロバイダは、ユーザ端末がパケットの受信を開始した時期を認識すべきである。認識しない場合、データパケットがユーザ端末でバッファリングされ始める前の早過ぎる時期に遅れ時間短縮手順（パケットのドロップ）を開始するという危険があり、これはバッファの完全な枯渇を招く可能性がある。
【００９９】
一部のデータが実際に欠落するためメディアレンダリングの際に検出可能な不連続性が存在し、そのため本発明の本実施形態は、ユーザにとって視覚的にも聴覚的（知覚的）にも魅力が足りない。この方法の可能な改善点は、送信される第１のデータが係数を有さないＰ画像であり、それに対応してオーディオ側ではサイレンスのみが送信されることである。これは、本実施形態のデータのドロップがマルチメディアセッションの初期に実現される場合、データチャネルの有用なデータではなく係数なし画像及びサイレントオーディオのみがドロップされることを意味する。これは使用されるコーデックに関する知識を必要とするが、利点はメディア表現に不連続性が存在しないことであり、多少遅い開始と感知されるだけである。
【０１００】
図７は、図４で開示された本発明の実施形態に係る、受信及びレンダリングされる累積バイト数を時間の関数として示すグラフである。図中、マルチメディアプロバイダのデータ送信が停止する時があるため、ユーザ端末による受信も０．５ｓ〜３．５ｓの間停止する。この場合、初期バッファリング時間は依然として４秒であるが、バッファ占有量（２つの曲線２０、３０の間の距離）は、４秒から後は１秒である。これは、チャネル切り替えがセッション開始から４秒以降のある時点で要求される場合、新しいチャネルのデータが４秒（図１を参照）と比較してユーザ端末に１秒のみバッファリングされることを意味する。
【０１０１】
図８は、本発明に係る、図２の遅れ時間短縮ステップＳ３の別の実施形態を示すフローチャートである。この方法は、図２のステップＳ２から継続する。次のステップＳ３０において、マルチメディアプロバイダは、０ｋＢ／ｓの第２の低減通信速度を一時的に採用する。しかし、マルチメディアプロバイダは、図４の実施形態のようにデータパケットをドロップするのではなく、データパケットを（ネットワーク）バッファにバッファリングする。本実施形態において、データバッファリングの一部は、ユーザ端末側からネットワーク側、すなわちマルチメディアプロバイダに移される。例えばデータパケットは、ネットワークバッファに約３秒バッファリングされ、ユーザ端末バッファに約１秒バッファリングされる。
【０１０２】
送信のない一時的な期間が終了すると、ネットワークバッファからのデータパケットは、ユーザ端末に送信される。データパケットを送信する前又はそれらをバッファに入力する前に、マルチメディアプロバイダは、ステップＳ３１においてタイムスタンプをデータパケットに割り当て、ユーザ端末において連続したタイムスタンピングを形成し且つデータレンダリングに不連続性がないようにするのが好ましい。データパケットは、ステップＳ３２において送信される。ステップＳ３２は図４のステップＳ２２に対応するため、更なる説明は行わない。
【０１０３】
チャネル切り替え要求がユーザ端末からマルチメディアプロバイダにより受信されると、マルチメディアプロバイダは、ネットワークバッファにバッファリングせずに新しいチャネルのデータパケットをユーザ端末に直接送信し始める。ネットワークバッファのバッファリング時間は省かれ、ユーザ端末のバッファリングの低下のみがなされる。上記で与えられた図を採用する場合、３秒のネットワークバッファリングが省略され、端末における１秒のバッファリングのみが使用されるという結果が得られる。
【０１０４】
本実施形態は、メディアストリームにおいて不連続性がないという利点を有するが、データをバッファリングする必要があるネットワーク／マルチメディアプロバイダにおいて複雑性が僅かに増加するという結果を招く。しかし、この場合、マルチメディアプロバイダは、後で徐々に減少を開始するという可能性を有し、また、例えば「無用な」データ（Ｐ画像及びサイレントオーディオ）による端末バッファリングの減少のタイミングを適応させる必要がない。図に関しては、本実施形態は図７と同様である。
【０１０５】
図９は、図２の遅れ時間短縮ステップＳ３の更なる実施形態を更に詳細に示すフローチャートである。この方法は、図２のステップＳ２から継続する。次のステップＳ４０において、マルチメディアプロバイダは、ユーザ端末Ｓ４０からチャネル切り替え要求を受信する。この要求は、文献［１］で示された技術等の従来技術に従って生成及び送信することができる。しかし、マルチメディアプロバイダは、新しく要求されたチャネルのデータパケットをユーザ端末に直接配信するのではなく、ステップＳ４１において要求チャネルの新しいデータの送信を一時的に停止する。本実施形態の第１の実現例において、マルチメディアは、新しいチャネルの第１のデータパケットをユーザに送信することをやめる。この送信していない間、端末バッファに見つけられる旧データチャネルのデータパケットがレンダリングされるため、バッファリングは減少する。別の実現例において、マルチメディアプロバイダは、第１のパケットの送信をスキップせず、それらパケットをネットワークバッファに一時的にバッファリングする。その結果はバッファ減少の観点から同様であるが、この実現例において、ユーザはデータを失うことはないが、ネットワークの複雑性は僅かに増加する。
【０１０６】
ステップＳ４２において、旧チャネルのデータパケットを第１の部分として含み且つ新しいチャネルのデータパケットを後続する第２の部分として含むデータストリームが１つの連続するストリームであるとユーザ端末により考えられるように、マルチメディアプロバイダは、新しいチャネルのデータパケットのタイムスタンプを調整するのが好ましい。図５及び図１０はこの原理を示す。図５に示される状況において、マルチメディアプロバイダ１００は、第２のマルチメディアチャネル４２０に対する要求をユーザ端末から受信する。本発明の本実施形態によると、マルチメディアプロバイダは、要求チャネルの入手可能な第１のデータパケット４２１を直接配信し始めるのではなく、ユーザ端末バッファのバッファレベルを低下させるために、新しいチャネルの２つの第１のパケット４２１、４２２の送信をやめる。ストリーム４５０は、新しいチャネルの４つの第１のパケットとしてデータパケット４２３〜４２６を含む。しかし、パケットのドロップがユーザ端末でわからなくなるように、新しいパケット４２３〜４２６のタイムスタンピングＴ５〜Ｔ８は、先のデータパケット４０１〜４０４のタイムスタンピングＴ１〜Ｔ４に続く。
【０１０７】
図９の次のステップＳ４３は、図４のステップＳ２２及び図８のＳ３２に対応するため、更なる説明は行わない。
【０１０８】
本実施形態において、チャネル切り替えは、従来技術を採用した場合と同様に長時間かかる。しかし、切り替えが実行された後、ユーザ端末のバッファレベルは低下した。これは、切り替え中にデータのバッファリングが減少するため、更なるチャネル切り替えは非常に短い時間で実行されることを意味する。
【０１０９】
図１１は、図９で開示される本発明の実施形態に係る、受信及びレンダリングされる累積バイト数を時間の関数として示すグラフである。図１１において、チャネル切り替えは８秒の時点で（図において矢印で示される）実行される。マルチメディアプロバイダは、このチャネル切り替えにおいてメディアデータの送信を３秒停止する。上述の原理によると、第１のチャネル切り替えは、その時点におけるユーザ端末のバッファレベルであるため、依然として約４秒のバッファリングを含む。しかし、新しいチャネルの第１のメディアパケットが到着すると、レベルは１秒になり、その後の切り替えは端末において１秒のバッファリングを含むだけになる。
【０１１０】
本実施形態は、非常に単純に実現できるという利点を有し、ユーザ端末の再生に対する要求は、再生が第１のチャネル切り替えの前に行われるべきであるということのみである。欠点は、第１の切り替えが依然として長いことである。
【０１１１】
図１２は、本発明における、図２の遅れ時間短縮ステップＳ３の更に別の実施形態を示すフローチャートである。この方法は、図２のステップＳ２から継続する。次のステップＳ５０において、マルチメディアプロバイダは、第２の通信速度でマルチメディアデータをユーザ端末に一時的に送信する。この場合、通信速度はゼロではないが、ユーザ端末のメディアプレーヤのレンダリング速度より遅く、また通常の第１の通信速度より遅い。この低下したデータ提供速度のために、マルチメディアデータは、再度書き込まれる速度より速い速度でユーザ端末のデータバッファを出る（レンダリングされる）。その結果、バッファレベルは低下する。
【０１１２】
ライブストリーミングの場合、あるいはマルチメディア送信元の速度が変更されない他の例の場合、この解決策は、データがユーザ端末ではなくネットワークにバッファリングされることを必要とする。そのような場合、本実施形態は、図８で開示される実施形態と同様の原理に基づく。この原理において、マルチメディアプロバイダは、ユーザ端末に送信する前に、ネットワークバッファにマルチメディアデータをバッファリングする。しかし、マルチメディアプロバイダからのデータ送信は、図７の実施形態のように一時的な期間、完全に阻止されるわけではなく、データ送信は低減速度で進行する。これは、ステップＳ５０において、端末バッファが徐々に空になるのに伴って、ネットワークバッファは徐々に増加することを意味する。
【０１１３】
低減速度は、適用期間中、一定である必要はなく変更できることが本発明により理解される。例えば、非常に遅い送信が最初に採用され、その後マルチメディアプロバイダは、例えば端末からのバッファフィードバック情報に基づいて、本来採用していた通信速度に速度を徐々に増加できる。
【０１１４】
次のステップＳ５１において、マルチメディアプロバイダは、連続したタイムスタンピングが得られるように、送信したデータパケットにタイムスタンプを割り当てる。この原理を図５及び図１３に示す。図１３において、通信速度は、図５で採用された先の速い速度と比較して低下されている。尚、データストリーム４５０の全てのパケット４０１〜４０６は連続したシーケンス番号付けＤＰ３３〜ＤＰ３８及びタイムスタンピングＴ１〜Ｔ６を有する。
【０１１５】
次のステップＳ５２において、ユーザ端末のバッファレベルが適切に低下すると、マルチメディアプロバイダは、バッファが完全に空になるのを防止するために、好ましくは略レンダリング速度まで通信速度を再び上げる。その後、方法は終了する。
【０１１６】
図１４は、図１２で開示される本発明の実施形態において、受信及びレンダリングされる累積バイト数を時間の関数として示すグラフである。この図示される例において、３秒のネットワークバッファは徐々に増加し、それに対応してユーザ端末バッファレベルは３秒低下する。この例において、ユーザ端末は８ｋＢ／ｓでデータを消費（レンダリング）するが、マルチメディアプロバイダが１秒に２ｋＢバッファリングするため、最初の１２秒の間の受信速度は６ｋＢ／ｓである。１２秒後、ユーザ端末のバッファレベルは８ｋＢ（１ｓ）に下がり、ネットワークにバッファリングされたデータは２４ｋＢ（３ｓ）である。
【０１１７】
その後、ユーザがマルチメディアチャネルを切り替えたいと考え且つ新しいチャネルを要求する場合、マルチメディアプロバイダは、ネットワークバッファにおいて見つけられる旧チャネルのデータを単純にスキップし、ネットワーク側でバッファリングせずに新しいチャネルの送信を開始する。これは、新しいチャネルのデータに対して、この例においてはユーザ端末で合計１秒のバッファリングが行われるため、データは非常に短い時間でレンダリングされることを意味する。この方法では、第１のチャネル切り替えは速く、追加の遅延は起こらない。当然、バッファレベルが所望の値まで下がる前に第１のチャネル切り替えが発生する場合、マルチメディアプロバイダは第２のチャネルにおいてバッファリングを継続できる。
【０１１８】
本実施形態の利点は、ユーザ端末において再生されるメディアに不連続性がなく、第１の切り替えが従来技術と比較して短い時間で行われることである。
【０１１９】
図４の実施形態に対して説明された問題と同様の予想される問題は、プロバイダが端末バッファを減らし始める前に、ユーザ端末が図１４の時間０においてバッファに実際に書き始めたことを、マルチメディアプロバイダが認識する必要があることである。しかし、この場合、マルチメディアプロバイダは、メディアストリームに不連続性がない、すなわちパケットのドロップがないため、後で徐々に減少し始める可能性を有する。
【０１２０】
先に説明し且つ開示した本発明の図示する実施形態において、ユーザ端末において約１秒のバッファレベルが結果として与えられることが多い。しかし、結果として得られるこの特定のバッファリングは、本発明の教示に従って取得される可能なバッファレベルの単なる例として考えられるべきである。従って本発明は、バッファレベルを１秒に下げる場合に限定されず、結果として得られるバッファリング時間が０．２５、０．５、０．７５、１．２５、１．５、１．７５及び２秒等の他のバッファリング時間である場合も含む。
【０１２１】
図１５は、本発明の一実施形態に係るユニキャストによる無線通信システム１を示す概略図である。通信システム１は、基本的にマルチメディアプロバイダ１００を含む。マルチメディアプロバイダ１００は、オペレータネットワーク５００、あるいは他の有線又は無線ネットワークを介してユーザ端末１０にマルチメディアサービス及びデータを提供する。マルチメディアプロバイダ１００は、マルチメディア送信元４００を含むか、あるいは図示されるようにマルチメディア送信元４００にアクセスできる。マルチメディア送信元４００は、異なるチャネル４１０、４２０からのマルチメディアデータを含むか又は生成するか、あるいは提供する。図示する例において、マルチメディアプロバイダ１００は、ストリーミングサーバ２００及びチャネルスイッチ３００の２つの異なるユニットを含むものとして開示される。マルチメディアプロバイダ１００の機能性を異なる（内部）ユニットに分割する場合、ストリーミングサーバ２００は、好ましくは、セッションセットアップ手順の管理、ユーザ端末１０からのチャネル要求及びチャネル切り替え要求の受信を行う。実行中のセッションの間、このサーバ２００は、チャネルスイッチ３００からユーザ端末１０にマルチメディアデータを更に配信する。その名前から明らかであるように、チャネルスイッチ３００は、ユーザ端末１０から発生した要求コマンドに応じてマルチメディアチャネルを切り替える。このチャネル切り替えにおいて、新しいマルチメディアチャネル又は送信元４１０、４２０からのマルチメディアデータは、ネットワーク５００を介してユーザ端末１０に転送するために、ストリーミングサーバ２００に配信される。
【０１２２】
図１５は、本発明に係る通信システム１の単なる例として理解されるべきであり、本発明の範囲内で他のシステム構成が可能である。例えば、入手可能なマルチメディアチャネル４１０、４２０の数は必ずしも２つである必要はなく、任意の数、すなわち少なくとも２つのチャネル４１０、４２０であってもよい。更に、マルチメディアプロバイダ１００は、１つの中央ユニット又は分散ユニットで構成されてもよく、ストリーミングサーバ２００及びチャネルスイッチ３００の動作を処理する。あるいは、マルチメディアプロバイダ１００は、より多くの又はより少ない内部ユニットを含むことができる。これを図１６に概略的に示す。
【０１２３】
図１６では、チャネルスイッチ３００が（オペレータ）ネットワーク３００を介してユーザ端末１０にマルチメディアデータを直接転送するように、ストリーミングサーバは省かれている。先に簡単に説明したように、マルチメディアプロバイダ１００は、提供したマルチメディアサービスに対する課金を行うユニット等、更に多くのユニットを含むことができる。あるいは、そのような課金ユニットは、例えばオペレータネットワークインフラストラクチャ３００の一部として他の場所に提供される。更に、専用のアプリケーションサーバが、マルチメディアプロバイダ１００の一部であってもよい。そのような場合、アプリケーションサーバは、受信したマルチメディアセッションセットアップ要求及びチャネル切り替え要求に対応するユニットであってもよい。このアプリケーションサーバは、それら要求に基づいてマルチメディアプロバイダの他のユニット２００、３００に命令する。
【０１２４】
図１７は、本発明の一実施形態に係るマルチメディアプロバイダ１００の一実施形態を示す概略ブロック図である。このプロバイダ１００は、一般的な入出力（Ｉ／Ｏ）ユニット１１０を基本的に含む。Ｉ／Ｏユニット１１０は、外部ユニットとの通信を行い且つ管理する。これは、通常、Ｉ／Ｏユニット１１０が変調器／復調器、符号器／復号器及びアドレシング機能性を含むことを意味する。特にＩ／Ｏユニット１１０は、チャネル要求及びチャネル切り替え要求をユーザ端末から受信するように構成される。ユニット１１０は、ユーザ端末とのセッションセットアップネゴシエーションに関わり、要求されたマルチメディアデータを端末に送信する。本発明の好適な実現例において、Ｉ／Ｏユニット１１０は、端末の（初期／最大／最小）バッファ容量に関する情報及び／又はバッファフィードバック情報を更に受信する。
【０１２５】
速度決定部１２０は、マルチメディアプロバイダ１００に構成され、ユーザ端末の現在のバッファレベルを下げ、それにより可能な後続するチャネル切り替え後のバッファリング時間を短縮するために、一時的に使用される低減通信速度を決定する。この決定された低減速度は、データをユーザ端末に送信するためにマルチメディアプロバイダ１００のＩ／Ｏユニット１１０により採用される通常の平均通信速度より平均して遅い。この通常の速度は、例えばストリーミングマルチメディア送信元により命令されると共に、ストリーミングマルチメディア送信元の速度と同一である。低減通信速度は、ユーザ端末のメディアレンダリング速度より遅く設定され、通常これは、メディアのタイムスタンピングにより決定される。
【０１２６】
本発明の好適な実施形態において、速度決定部１２０は、マルチメディアプロバイダ１００のバッファアナライザ１４０から入力情報を受信し、少なくとも部分的にその入力情報に基づいて速度を決定する。バッファアナライザ１４０は、ユーザ端末から発生するフィードバックメッセージからバッファ容量情報を抽出するように構成することができる。この容量情報は、端末バッファの初期バッファレベル、最大バッファレベル、最小バッファレベル及び／又は現在のバッファレベルを示すことができる。あるいは、バッファアナライザ１４０は、バッファ容量情報を提供するために、ユーザ端末からのメッセージから例えば機種及びブランド情報を抽出し、予め決められた機種リスト又はルックアップテーブル／データベースと共にその情報を使用する。
【０１２７】
上述したように、速度決定部１２０は、通信システムにおける現在の無線の状態の情報を受信し、速度決定においてその入力情報を利用することができる。無線品質情報は、内部品質推定ユニット（不図示）から、あるいは外部ネットワークユニット及び／又はユーザ端末から取得することができる。
【０１２８】
決定した低減通信速度は、速度アダプタ１３０により利用され、ユーザ端末バッファをある程度空にし、且つそれによりバッファのデータバッファリング時間を短縮することにより、マルチメディアチャネルの切り替え後のユーザが感知する遅れ時間を短縮する。低減通信速度が端末のデータレンダリング速度より遅いため（通常、データパケットタイムスタンプにより規定されたように）、ユーザ端末のバッファレベルは低下する。典型的な実施形態において、速度アダプタは、通信速度を速度決定部１２０により決定された速度に下げるように、データ送信を実際に実行するＩ／Ｏユニット１１０に命令する。あるいは、ユーザに送信するマルチメディアデータは、接続された（内部又は外部）データ送信元（不図示）から受信され、ユーザ端末に更に送信するために、決定された低減速度で速度アダプタ１３０によりＩ／Ｏユニット１１０に転送される。
【０１２９】
本発明の好適な実施形態において、マルチメディアプロバイダ１００はユニット１５０を更に含む。ユニット１５０は、連続したデータストリーム及び連続した均一なメディアレンダリングを取得するために、ユーザ端末に送信されるデータパケットにタイムスタンプを割り当て且つオプションとして再番号付けする。
【０１３０】
マルチメディアプロバイダ１００のユニット１１０〜１５０は、ソフトウェア、ハードウェア又はそれらの組合せとして提供されてもよい。ユニット１１０〜１５０は、１つのネットワークノードに共に実現されてもよい。また、いくつかのユニットが種々のネットワークノードに提供される分散型実施形態も可能である。少なくともマルチメディアプロバイダ１００の一部の機能性及びユニット１１０〜１５０がアプリケーションサーバ、ストリーミングサーバ及び／又はチャネルスイッチの間で分散されてもよく、それらが単一のネットワークノードに共に構成されるか又はユニキャスト通信システムにおいて異なるネットワークノードに提供されることは、本発明により更に理解される。
【０１３１】
図１８〜図２０は、図１７の速度アダプタ１３０の別の実施形態を更に詳細に示す。図１８から開始すると、速度アダプタの実施形態１３０は、パケットドロップ部１３１及び選択的にパケットセレクタ１３２を含む。パケットドロップ部１３１は、速度決定部により決定されるように、ある期間、通信速度ゼロを採用する。これは、マルチメディア送信元からのデータパケットの一部が実際にドロップされ且つユーザ端末に到達しないことを意味する。端末はバッファに既に存在するデータのレンダリングを継続するため、バッファレベルの低下は達成される。ユーザが感知するようなマルチメディアの不連続性が存在するため、パケットセレクタ１３２は、ドロップ部１３１によりドロップされるデータパケットがマルチメディアレンダリングに与える影響が最も少ないデータパケットを選択するように実現されるのが好ましい。好適な例は、係数なしＰ画像及びサイレントオーディオを含むデータパケットである。適切なデータ量がドロップされ、所望のバッファレベルに低下した後、データ送信は通常通りに先行する。
【０１３２】
ユーザ端末のメディアプレーヤに対してデータのドロップが分からないようにするために、マルチメディアプロバイダのパケット再番号付け部はパケットのドロップ後にデータパケットを再番号付けするため、それらパケット及びドロップ前に送信されたパケットは連続した番号を有する。また、タイムスタンピングは、端末において、データのドロップによるメディアレンダリングの一時的な停止がないように実行される。
【０１３３】
例えば３つのデータパケットをドロップすることにより適切な低下バッファレベルが得られることを速度決定部が推定する場合、３つの連続するデータパケットは、パケットドロップ部１３１によりドロップされることが本発明により理解される。あるいは、１つ又はいくつかのパケットがドロップされた後、１つ又はいくつかのデータパケットの送信が行われ、次にいくつかの又は残りのパケットがドロップされる。
【０１３４】
図１９において、速度アダプタ１３０は、要求プロセッサ１３３及びパケットプロセッサ１３４を含む。要求プロセッサ１３３は、ユーザ端末から発生するチャネル切り替え要求を受信して解析する。そのようなチャネル切り替え要求を識別すると、要求プロセッサ１３３は、新しいチャネルの第１のデータパケットの一部の送信をスキップするように、又はパケットの一部の送信を遅延するように、パケットプロセッサ１３４に命令する。データを再度書き込むことが一時的に停止されている間も、メディアレンダリングが継続されるため、ユーザ端末のバッファは減少するという同様の結果が得られる。
【０１３５】
図２０に示される速度アダプタ１３０は、バッファマネージャ１３５及びネットワークデータバッファ１３６を含む。この速度アダプタ１３０は、低減通信速度が実際にゼロではないが、マルチメディア送信元のデータ転送速度が一定であり且つ低減速度より大きい場合に適応する。そのような場合、通信速度の低減を実現するために、バッファマネージャ１３５は、アクセス可能なネットワークバッファ１３６にデータパケットを一時的にバッファリングする必要がある。データバッファリングは、端末側からネットワーク側に部分的に移動される。チャネル切り替え要求後、新しいチャネルのマルチメディアデータは、ネットワークバッファ１３６にバッファリングすることなくユーザ端末に直接転送される。そのデータに対して、端末バッファにおいてバッファリングのみが実行される必要があり、切り替えは非常に速いと感知される。
【０１３６】
この速度アダプタの実施形態１３０は、パケットをドロップせずに通信速度ゼロを一時的に適用するように使用することができる。
【０１３７】
図１８〜図２０は、３つの異なる速度アダプタの実施形態１３０を示す。本発明に係るマルチメディアプロバイダは、それら実施形態のうちの１つのみを有するように構成されることが本発明により理解される。別の実施形態において、速度アダプタ１３０は、少なくとも２つの図示された実施形態に従って動作できる。例えば、速度アダプタは、パケットドロップ部１３１、パケットセレクタ１３２、要求プロセッサ１３３及びパケットプロセッサ１３４を有することができる。これは、速度アダプタ１３０が、この場合は少なくとも２つの異なる速度適応モードに従って動作できるマルチモードユニットとして考えられることを意味する。採用する特定の速度適応モードの選択（図１８、図１９又は図２０）は、送信される実際のマルチメディアデータ、ユーザ端末の機種又は種類、マルチメディアプロバイダのネットワークバッファ１３６の現在の状態等を含む種々のパラメータに基づいて行われる。
【０１３８】
図１８〜図２０の異なる速度アダプタの実施形態１３０のユニット１３１〜１３５は、ソフトウェア、ハードウェア又はそれらの組合せとして提供されてもよい。ユニット１３１及び１３２、１３３及び１３４又は１３５及び１３６は、速度アダプタ１３０に共に実現されてもよい。あるいは、いくつかのユニットがマルチメディアプロバイダの他の場所に提供される分散型の実施が可能である。
【０１３９】
図２１は、本発明の別の実施形態に係るマルチメディアプロバイダ１００の可能な実現例を示す概略ブロック図である。図示される本実施形態において、マルチメディアプロバイダ１００は、ストリーミングサーバ２００及びチャネルスイッチ３００から構成される（図１５と比較のこと）。
【０１４０】
そのような実現例において、１つ又は複数のデータ送信元４１０、４２０からのマルチメディアデータは、送信元セレクタ３２０により各ユーザ端末に対して選択される。通常、このセレクタ３２０は、特定の送信元４１０、４２０のマルチメディアデータが送信されるべきユーザ端末を特定する、各チャネル送信元４１０、４２０に対するリスト又はテーブルにアクセスできる。マルチメディアデータは、チャネルスイッチのＩ／Ｏユニット３１０を使用してストリーミングサーバ２００に転送される。ストリーミングサーバ２００は、Ｉ／Ｏユニット２１０によりユーザ端末へのデータの直接送信を行う。
【０１４１】
本実施形態において、本発明の速度決定部２２０及び速度アダプタ２３０は、ストリーミングサーバ２００内で実現される。それら２つのユニット２２０、２３０の動作は、図１７〜図２０を参照して上述した対応するユニットと同様であるため、ここでは説明を繰り返さない。
【０１４２】
パケット処理機能性、すなわち番号付け及びタイムスタンピング機能性は、マルチメディアプロバイダ１００に存在するのが好ましい。例えば、パケット番号割り当てユニット３５０は、ストリーミングサーバ２００に転送されるデータパケットにシーケンス番号を割り当てるためにチャネルスイッチ３００に構成される。サーバ２００はユニット２５０を含み、そのユニット２５０は、例えば速度アダプタがマルチメディアストリームの一部のデータパケットをドロップするように構成される場合、必要に応じてデータパケットに再番号付けを行う。ストリーミングサーバ２００のパケット処理ユニット２５０又は他のユニットは、Ｉ／Ｏユニット２１０によりユーザ端末に送信されるデータパケットにタイムスタンプを割り当てる機能性を有する。一部のパケットがドロップ又は遅延される（ストリーミングサーバ２００のネットワークバッファ２６０に一時的にバッファリングされる）場合でも、連続したパケットタイムスタンピング及びメディアレンダリングが達成されるように、タイムスタンプの割り当ては、送信されたデータパケットに連続したタイムスタンプを割り当てることにより実行されるのが好ましい。
【０１４３】
マルチメディアプロバイダ１００のストリーミングサーバ２００及びチャネルスイッチ３００のユニット２１０〜２５０、３１０〜３５０は、ソフトウェア、ハードウェア又はそれらの組合せとして提供されてもよい。ストリーミングサーバ２００のユニット２１０〜２５０は、１つのネットワークノードに共に実現されてもよい。また、いくつかのユニットが異なるネットワークノードに提供される分散型実施形態も可能である。チャネルスイッチ３００のユニット３１０〜３５０は、１つのネットワークノードに共に実現されてもよい。また、いくつかのユニットが異なるネットワークノードに提供される分散型実施形態も可能である。ストリーミングサーバ２００、チャネルスイッチ３００及びマルチメディア送信元４１０、４２０は、単一のネットワークノードに共に構成されても、ユニキャスト通信システムの異なるネットワークノードに提供されてもよいことが本発明により更に理解される。
【０１４４】
通常、メディア又はマルチメディアストリームは、多くのフレーム（オーディオフレーム、ビデオフレーム等）から構成されると考えられる。それらフレームの一部は、ストリーミングセッションが開始するか又はチャネルの切り替えにより入力される時に使用される同期点としての役割を果たす。通常、同期点はメディアストリームにわたり均一に分布し、それらの周波数はメディアのビットレートに依存するのが一般的である。
【０１４５】
メディアストリームがユーザ端末に配信される場合、ユーザ端末において正確な復号化を行うために、マルチメディアプロバイダ（マルチメディアプロバイダのストリーミングサーバであることが多い）は同期点において配信を開始する必要がある。ユーザ端末が丁度同期点においてマルチメディアプロバイダに偶然に接続する場合を除いて、これは、プロバイダが同期点を待たなければならない時間と同等の遅延を発生する。
【０１４６】
同期点を待たずにユーザ端末が接続するとすぐにマルチメディアプロバイダがメディアストリームを配信し始める場合、問題は、ユーザ端末の復号器が適切に初期化されなくなり、乱雑な煩わしいアーティファクトを発生することである。これは、互いに依存して符号化されるメディアフレームに起因する。同期点は、この依存性を無くす。
【０１４７】
受信機において複数のチャネルが入手可能であるブロードキャストの場合にチャネルを入力又は切り替える時、同様の効果が得られる。ＤＶＴ‐Ｔのような一般的なＴＶシステムでは、１秒に２つのイントラフレーム（Ｉフレーム、同期点）があり、これはスタートアップ遅延を小さくするが、その間隔が長いほど切り替え時間は長くなる。
【０１４８】
本発明の教示は、ユーザ端末が新しいチャネルを要求し且つチャネル切り替えが実行されるとすぐに同期点の配信を開始することを可能にする技術と共に利用することができる。
【０１４９】
マルチメディアプロバイダがメディアストリームの小さなバッファを保持する場合、これは達成される。バッファは、少なくとも１つの同期点を常に保持するように十分に大きい必要がある。
【０１５０】
本発明の先の説明から明らかであるように、本発明のいくつかの実施形態は、マルチメディアデータを一時的にバッファリングし且つユーザ端末における対応するバッファリングを減らす目的で、マルチメディアプロバイダのネットワークバッファ又は少なくともマルチメディアプロバイダがアクセスできるネットワークバッファを利用する。従って、同一のネットワークバッファが、少なくとも１つの同期点を常に含むように十分に大きく設定することができる。
【０１５１】
別の面は、同期点のエミュレーションに関する。メディアの同期点の数が少ない場合、例えばビットレートが低い場合、マルチメディアプロバイダにバッファリングされる必要のあるデータ量が増加するのに伴い、送信されるメディアの遅延が増加する。これが受け入れられない場合、サーバにおいて同期点をエミュレートすることにより回避される。エミュレートされた同期点は、ユーザ端末においてレンダリングされたメディアでアーティファクトを発生するが、非同期点でメディアの配信を開始する場合と比較して全体のユーザ体験は向上する。
【０１５２】
ビデオストリームが最も少ない同期点を有する場合、例えば、同期点のエミュレーションは以下のうちの１つである：
【０１５３】
・旧イントラフレーム。この場合、マルチメディアプロバイダは最新のイントラフレームを常に格納し、ユーザ端末がチャネル切り替えを要求する場合、メディア配信がすぐに開始される。この時、配信される第１のビデオフレームは旧イントラフレームである。旧イントラフレームが配信された後、マルチメディアプロバイダは現在のフレームの配信を続ける。プロバイダは、帯域幅の制約を守るためにいくつかのフレームをスキップする必要がある可能性がある（通常、イントラフレームがインターフレームより（バイト数で）大きいため）。
【０１５４】
・灰色イントラフレーム又はＴＶチャネルのロゴを含むイントラフレーム。この場合、手順は上記例と同一である。この例は、イントラフレームが（バイト数で）小さい（灰色フレーム又はロゴフレームは効果的に圧縮されるため）という利点を有するため、追従するフレームはスキップされる必要がなく、イントラフレームは迅速に転送される（小さいため）。欠点は、ビデオストリームへの灰色又はロゴのにじみである。これらのフレームは通常のメディアストリームに存在しないため、マルチメディアプロバイダは、ある手段により灰色フレーム又はロゴフレームにアクセスできる必要がある。この問題に対する１つの解決策は、灰色フレーム又はロゴフレームで各チャネル要求を開始することであり、プロバイダはそれらを後で使用するために格納できる。
【０１５５】
・適切なイントラフレームの使用。この例は上記例に類似するが、この場合マルチメディアは、各ビデオストリームに対して、同一のコンテンツを含み且つイントラフレームとして符号化された全てのフレームを含む別のビデオストリームにアクセスできる。このフレームは、ストリームを復号化し且つ関連する画像を内部符号器に提供する復号器を有することによりリアルタイムで作成することができる。画像は、必要とされるビット数を減らすために、量子化器を増加することにより対応する非イントラフレームより更に圧縮されてもよい。
【０１５６】
別の例は、メディア送信元が文献においてＳフレームと呼ばれる復号化Ｐ画像に基づいて符号化されるイントラ画像の第２のストリームを提供することである。この例は、上記２つの例が有する欠点を有さないが、サーバ（及びシステム全体）に対する必要条件は増加する。
【０１５７】
少なくとも１つの同期点をネットワークバッファにバッファリングすることを可能にするために、マルチメディアプロバイダは、同期点としての役割を果たすフレームを識別できる必要がある。これは、いくつかの方法により解決される。
【０１５８】
・マルチメディアプロバイダが実際のメディア符号化を実行する場合、プロバイダは、どのフレームが同期点であるかを常に知っている。
【０１５９】
・メディアストリームがマルチメディアプロバイダに配信され、プロバイダがメディア転送プロトコル及びメディア符号化標準の知識を有することが可能である。その場合、同期点であるフレームを推定するために、マルチメディアプロバイダは、入力メディアストリームを構文解析し且つフレームのヘッダを復号化できる。殆どの場合、フレームヘッダの符号化は複雑ではない。最も単純な１つの例は、ＡＶＣ（Advanced Video Codec）ストリームに対するリアルタイムプロトコル（ＲＴＰ）ペイロードにおいてＮＡＬユニット（ＮＡＬＵ：Network Adaptation Layer Unit）タイプフィールドを見つけることである。ＮＡＬＵタイプフィールドは、ＲＴＰパケットが瞬時復号更新（ＩＤＲ：Instantaneous Decoding Refresh）フレームの一部であるＮＡＬＵを含むかを直接識別する。
【０１６０】
・メディアストリームがマルチメディアプロバイダに配信される場合、同期点を含むパケットに印が付けられる。例えば、ＩＰを介して配信される場合、ＩＰヘッダのＩＰｖ４のType of Service（ＴＯＳ）［３］、ＩＰｖ６のTraffic Class又はＩＰｖ６のFlow Label［４］を、同期点であるフレームに印を付けるために使用することができる。ＲＴＰプロトコル等の上位層でマーク付けすることも可能である。
【０１６１】
・イントラフレームが同期点としての役割を果たすビデオストリームの場合、イントラフレームは、フレームのサイズを見ることにより識別できることが多い。これは、通常イントラフレームがインターフレームより大きいためである。
【０１６２】
・同期点の周波数が一定であるエラーのない環境において、同期点を認識するのにフレーム番号で十分である。
【０１６３】
図２２は、本発明に係るユーザ端末１０の概略ブロック図である。このユーザ端末１０は、マルチメディアプロバイダと通信するためにＩ／Ｏユニット１１を具備する。特に、このＩ／Ｏユニット１１は、チャネル要求及びチャネル切り替え要求をプロバイダに送信するように適応される。更にＩ／Ｏユニット１１は、マルチメディアデータをプロバイダから受信する。
【０１６４】
ユーザ端末１０は、受信したマルチメディアデータをレンダリングするマルチメディア又はメディアプレーヤ１２を更に含む。このマルチメディアプレーヤ１２は、メディアを表示及び再生するために、端末１０の表示画面１３及びスピーカ１４と通信していることが好ましい。メディアプレーヤ１２は、マルチメディアバッファ１５と接続している。Ｉ／Ｏユニット１１により受信されたデータパケットは、レンダリングするためにプレーヤ１２に転送される前に、マルチメディアバッファ１５に入力され且つバッファリングされる。本発明の概念は、メディアプレーヤ１２のレンダリング速度より小さくなるようにデータ転送の通信速度を変調することにより、マルチメディアバッファ１５において実行されるデータバッファリングを減らすことである。
【０１６５】
ユーザ端末１０は、バッファ通知部１６を含むのが好ましい。バッファ通知部１６は、Ｉ／Ｏユニット１１により送信される情報をマルチメディアプロバイダに提供し、プロバイダがユーザ端末１０のバッファリング容量を推定することを可能にする。通知部１６は、マルチメディアバッファ１５の初期バッファレベル、最大バッファレベル、最小バッファレベル及び／又は現在のバッファレベルの情報を提供できる。あるいは、バッファ通知部１６は、例えばセッションセットアップ要求又はチャネル切り替え要求に端末機種情報を単純に含める。
【０１６６】
要求プロセッサ１７は、チャネル要求及びチャネル切り替え要求を生成するためにユーザ端末１０上で実現される。要求プロセッサ１７は、マルチメディアプロバイダに送信される要求にバッファ通知部１６により取得された情報を含ませることができる。
【０１６７】
ユーザ端末のユニット１１、１２、１５〜１７は、ソフトウェア、ハードウェア又はそれらの組合せとして提供されてもよい。
【０１６８】
添付の請求の範囲により定義される本発明の範囲から逸脱せずに、本発明に対して種々の変形及び変更が行われてもよいことは、当業者には理解されるだろう。
【０１６９】
参考文献
［１］国際出願第ＰＣＴ／ＳＥ２００５／００１７６８号
［２］3GPP TS 26.234 v6.5.0、第３世代パートナーシッププロジェクト；Technical Specification Group Services and System Aspects；Transparent end-to-end Packet switched Streaming Service (PSS)；Protocols and codes
［３］Postel, J., Internet Protocol, Darpa Internet Program Protocol Specification, RFC 791、１９８１年９月
［４］Deering, S. and R. Hinden, Internet Protocol, Version 6 (IPv6) Specification, RFC 1883、１９９５年１２月
【図面の簡単な説明】
【０１７０】
【図１】図１は、従来技術に係る、受信及びレンダリングされる累積バイト数を時間の関数として示すグラフである。
【図２】図２は、本発明の一実施形態に係る、ユーザが感知する切り替え時間を短縮する方法を示すフローチャートである。
【図３】図３は、図２の方法の追加のステップの異なる実施形態を更に詳細に示すフローチャートである。
【図４】図４は、本発明の一実施形態における、図２の時間短縮ステップを更に詳細に示すフローチャートである。
【図５】、
【図６】図５及び図６は、図４で開示される本発明の実施形態に係る、データパケットに再番号付けし、タイムスタンプを割り当てる原理を概略的に示す図である。
【図７】図７は、図４で開示される本発明の実施形態に係る、受信及びレンダリングされる累積バイト数を時間の関数として示すグラフである。
【図８】図８は、本発明の別の実施形態に係る、図２の時間短縮ステップを更に詳細に示すフローチャートである。
【図９】図９は、本発明の更なる実施形態に係る、図２の時間短縮ステップを更に詳細に示すフローチャートである。
【図１０】図１０は、図９で開示される本発明の実施形態に係る、タイムスタンプを割り当てる原理を概略的に示す図である。
【図１１】図１１は、図９で開示される本発明の実施形態に係る、受信及びレンダリングされる累積バイト数を時間の関数として示すグラフである。
【図１２】図１２は、本発明の更に別の実施形態に係る、図２の時間短縮ステップを更に詳細に示すフローチャートである。
【図１３】図１３は、図１２で開示される本発明の実施形態に係る、タイムスタンプを割り当てる原理を概略的に示す図である。
【図１４】図１４は、図１２で開示される本発明の実施形態に係る、受信及びレンダリングされる累積バイト数を時間の関数として示すグラフである。
【図１５】図１５は、本発明に係る通信システムの一実施形態を示す概略図である。
【図１６】図１６は、本発明に係る通信システムの別の実施形態を示す概略図である。
【図１７】図１７は、本発明の実施形態に係るマルチメディアプロバイダを示す概略ブロック図である。
【図１８】図１８は、本発明の一実施形態に係る図１７のマルチメディアプロバイダの速度アダプタを示す概略ブロック図である。
【図１９】図１９は、本発明の別の実施形態に係る図１７のマルチメディアプロバイダの速度アダプタを示す概略ブロック図である。
【図２０】図２０は、本発明の更なる実施形態に係る図１７のマルチメディアプロバイダの速度アダプタを示す概略ブロック図である。
【図２１】図２１は、本発明の別の実施形態に係るマルチメディアプロバイダを示す概略ブロック図である。
【図２２】図２２は、本発明の一実施形態に係るユーザ端末を示す概略ブロック図である。
【特許請求の範囲】
【請求項１】
第１の通信速度で第１のマルチメディアチャネル（４１０）のマルチメディアデータをユーザ端末（１０）に提供するマルチメディアプロバイダ（１００）を具備する通信システム（１）において、ユーザが感知するマルチメディアチャネルの切り替え時間を短縮する方法であって：
‐前記マルチメディアプロバイダ（１００）が前記第１の通信速度より遅く且つ前記ユーザ端末（１０）のマルチメディアデータレンダリング速度より遅い第２の通信速度を決定するステップと；
‐前記ユーザ端末（１０）におけるマルチメディアデータのバッファリング時間を短縮するために、前記マルチメディアプロバイダ（１００）が、前記決定した第２の通信速度でマルチメディアデータを前記ユーザ端末（１０）に一時的に送信することにより、前記第１のマルチメディアチャネル（４１０）から第２のマルチメディアチャネル（４２０）への切り替え後に、前記ユーザ端末（１０）において前記第２のマルチメディアチャネル（４２０）のマルチメディアデータをレンダリングするまでの遅れ時間を能動的に短縮するステップとから成ることを特徴とする方法。
【請求項２】
前記遅れ時間を能動的に短縮する前記ステップは、前記ユーザ端末（１０）のマルチメディアデータバッファ（１５）のバッファレベルを第１のバッファレベルから第２のより小さいバッファレベルに下げるために、前記マルチメディアプロバイダ（１００）が前記決定した第２の通信速度で前記ユーザ端末（１０）にマルチメディアデータを一時的に送信するステップを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記決決定ステップは、
‐前記ユーザ端末（１０）の推定初期バッファリング時間の情報と；
‐前記ユーザ端末（１０）のマルチメディアデータバッファ（１５）の最大バッファレベルの情報と；
‐前記ユーザ端末（１０）の可能な最小バッファリング時間の情報と；
‐前記ユーザ端末（１０）の前記マルチメディアデータバッファ（１５）の現在の推定バッファレベルの情報と
のうち少なくとも１つに基づいて、前記マルチメディアプロバイダ（１００）が前記第２の速度を決定するステップを含むことを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記決定ステップは、前記マルチメディアプロバイダ（１００）が前記通信システム（１）の現在の無線の状態を表す品質推定値に基づいて前記第２の速度を決定するステップを含むことを特徴とする請求項１から３のいずれか１項に記載の方法。
【請求項５】
前記マルチメディアプロバイダ（１００）は：
‐マルチメディアデータバッファ（２６０）を含むストリーミングサーバ（２００）と；
‐マルチメディアデータを前記ストリーミングサーバ（２００）に転送するために一定速度を有するマルチメディア送信元（３００）とを具備し、前記遅れ時間を能動的に短縮する前記ステップは、前記マルチメディアデータ通信速度を前記第１の通信速度から前記第２の通信速度に一時的に下げるために、前記ストリーミングサーバ（２００）が前記マルチメディアデータを前記ユーザ端末（１０）に送信する前にマルチメディアデータを前記マルチメディアデータバッファ（２６０）にバッファリングするステップを含むことを特徴とする請求項１から４のいずれか１項に記載の方法。
【請求項６】
前記ストリーミングサーバ（２００）が、前記第１のマルチメディアチャネル（４１０）から前記第２のマルチメディアチャネル（４２０）へのチャネル切り替えの要求に基づいて、前記第２のマルチメディアチャネル（４２０）のマルチメディアデータを前記マルチメディアデータバッファ（２６０）にバッファリングせずに前記第１の速度で前記第２のマルチメディアチャネル（４２０）の前記マルチメディアデータを前記ユーザ端末（１０）に送信するステップを更に含むことを特徴とする請求項５に記載の方法。
【請求項７】
マルチメディアデータは、データパケット（４０１〜４０７、４２４）のマルチメディアデータストリーム（４５０）として前記マルチメディアプロバイダ（１００）から前記ユーザ端末（１０）に送信され、前記遅れ時間を能動的に短縮する前記ステップは、前記マルチメディアプロバイダ（１００）が前記マルチメディアデータストリーム（４５０）の前記データパケット（４０１〜４０７、４２４）の一部を一時的に送信しないステップを含むことを特徴とする請求項１から６のいずれか１項に記載の方法。
【請求項８】
データパケット（４０１〜４０７、４２４）の前記一部の前記データパケットは、係数なしＰ画像データ及びサイレントオーディオデータを含むことを特徴とする請求項７に記載の方法。
【請求項９】
前記遅れ時間を能動的に短縮する前記ステップは、前記マルチメディアプロバイダ（１００）がマルチメディアデータを前記ユーザ端末（１０）に送信することを一時的に停止するステップを含むことを特徴とする請求項１から８のいずれか１項に記載の方法。
【請求項１０】
前記遅れ時間を能動的に短縮する前記ステップは：
‐前記マルチメディアプロバイダ（１００）が第３のマルチメディアチャネルから前記第１のマルチメディアチャネル（４１０）へのチャネル切り替えの要求を前記ユーザ端末（１０）から受信するステップと；
‐前記第３のマルチメディアチャネルから前記第１のマルチメディアチャネル（４１０）への前記チャネル切り替えの後、前記マルチメディアプロバイダ（１００）が前記第１のチャネル（４１０）のマルチメディアデータを前記ユーザ端末（１０）に送信することを一時的に停止するステップとを更に含むことを特徴とする請求項１〜９のいずれか１項に記載の方法。
【請求項１１】
マルチメディアデータは、データパケット（４１０〜４０７、４２４）のマルチメディアデータストリーム（４５０）として前記マルチメディアプロバイダ（１００）から前記ユーザ端末（１０）に送信され、各データパケット（４１０〜４０７、４２４）はシーケンス番号と関連付けられ、前記方法は、前記マルチメディアデータストリーム（４５０）の前記データパケット（４１０〜４０７、４２４）が連続したシーケンス番号を有するように、前記マルチメディアプロバイダ（１００）がデータパケット（４２４）にシーケンス番号を割り当てるステップを更に含むことを特徴とする請求項１から１０のいずれか１項に記載の方法。
【請求項１２】
マルチメディアデータは、データパケット（４１０〜４０７、４２４）のマルチメディアデータストリーム（４５０）として前記マルチメディアプロバイダから前記ユーザ端末に送信され、各データパケット（４１０〜４０７、４２４）はタイムスタンプと関連付けられ、前記方法は、前記マルチメディアデータストリーム（４５０）の前記データパケット（４１０〜４０７、４２４）が連続したタイムスタンプを有するように、前記マルチメディアプロバイダ（１００）がデータパケット（４１０〜４０７、４２４）にタイムスタンプを割り当てるステップを更に含むことを特徴とする請求項１から１１のいずれか１項に記載の方法。
【請求項１３】
前記マルチメディアプロバイダ（１００）が、マルチメディアチャネルを前記第１のマルチメディアチャネル（４１０）から前記第２のマルチメディアチャネル（４２０）に切り替え、前記第２のマルチメディアチャネル（４２０）のマルチメディアデータストリーム（４５０）がイントラ画像データを含む場合に前記第２のマルチメディアチャネル（４２０）のマルチメディアデータを前記ユーザ端末（１０）に送信するステップを更に含むことを特徴とする請求項１から１２のいずれか１項に記載の方法。
【請求項１４】
前記マルチメディアプロバイダ（１００）は、前記第２のマルチメディアチャネル（４２０）の少なくとも１つの完全なイントラ画像に対応するデータを連続的に格納するように構成されたデータバッファ（１３６；２６０）を含むことを特徴とする請求項１３に記載の方法。
【請求項１５】
ユーザが感知するマルチメディアチャネルの切り替え時間を短縮する構成（１００）であって：
‐第１の通信速度で第１のマルチメディアチャネル（４１０）のマルチメディアデータをユーザ端末（１０）に送信する送信機（１１０；２１０）と；
‐前記第１の通信速度より遅く且つ前記ユーザ端末（１０）のマルチメディアデータレンダリング速度より遅い第２の通信速度を決定する手段（１２０；２２０）と；
‐前記ユーザ端末（１０）におけるマルチメディアデータのバッファリング時間を短縮するために、前記決定した第２の通信速度でマルチメディアデータを前記ユーザ端末（１０）に一時的に送信するように前記送信機（１１０；２１０）に命令することにより、前記第１のマルチメディアチャネル（４１０）から第２のマルチメディアチャネル（４２０）への切り替え後に、前記ユーザ端末（１０）において前記第２のマルチメディアチャネル（４２０）のマルチメディアデータをレンダリングするまでの遅れ時間を短縮する手段（１３０；２３０）とを具備することを特徴とする構成。
【請求項１６】
前記短縮手段（１３０；２３０）は、前記ユーザ端末（１０）のマルチメディアデータバッファ（１５）のバッファレベルを第１のバッファレベルから第２のより小さいバッファレベルに下げるために、前記決定した第２の通信速度で前記ユーザ端末（１０）にマルチメディアデータを一時的に送信するように前記送信機（１１０；２１０）に命令するように構成されたことを特徴とする請求項１５に記載の構成。
【請求項１７】
前記決定手段（１２０；２２０）は、
‐前記ユーザ端末（１０）の推定初期バッファリング時間の情報と；
‐前記ユーザ端末（１０）のマルチメディアデータバッファ（１５）の最大バッファレベルの情報と；
‐前記ユーザ端末（１０）の可能な最小バッファリング時間の情報と；
‐前記ユーザ端末（１０）の前記マルチメディアデータバッファ（１５）の現在の推定バッファレベルの情報と
のうち少なくとも１つに基づいて、前記第２の通信速度を決定するように構成されたことを特徴とする請求項１５又は１６に記載の構成。
【請求項１８】
前記決定手段（１２０；２２０）は、前記構成（１００）が動作する無線通信システム（１）の現在の無線の状態を表す品質推定値に基づいて前記第２の通信速度を決定するように構成されたことを特徴とする請求項１５から１７のいずれか１項に記載の構成。
【請求項１９】
前記構成（１００）は：
‐マルチメディアデータバッファ（２６０）及び前記送信機（２１０）を含むストリーミングサーバ（２００）と；
‐一定速度でマルチメディアデータを前記ストリーミングサーバ（２００）に転送するマルチメディア送信元（３００）とを具備し、前記短縮手段（２３０）は、前記ストリーミングサーバ（２００）内で実現され、且つ前記マルチメディアデータ通信速度を前記第１の通信速度から前記第２の通信速度に一時的に下げるために、前記マルチメディアデータを前記ユーザ端末（１０）に送信するように前記送信機（２１０）に命令する前にマルチメディアデータを前記マルチメディアデータバッファ（２６０）にバッファリングするように構成されるたことを特徴とする請求項１５から１８のいずれか１項に記載の構成。
【請求項２０】
前記短縮手段（２３０）は、前記第１のマルチメディアチャネル（４１０）から前記第２のマルチメディアチャネル（４２０）へのチャネル切り替えの要求に基づいて、前記第２のマルチメディアチャネル（４２０）のマルチメディアデータを前記マルチメディアデータバッファ（２６０）にバッファリングせずに前記第１の速度で前記第２のマルチメディアチャネル（４２０）の前記マルチメディアデータを前記ユーザ端末（１０）に送信するように前記送信機（２１０）に命令するように構成されたことを特徴とする請求項１９に記載の構成。
【請求項２１】
前記送信機（１１０；２１０）は、マルチメディアデータをデータパケット（４０１〜４０７；４２４）のマルチメディアデータストリーム（４５０）として前記ユーザ端末（１０）に送信し、前記短縮手段（１３０；２３０）は、前記マルチメディアデータストリーム（４５０）の前記データパケット（４０１〜４０７；４２４）の一部を一時的に送信しないように前記送信機（１１０；１３０）に命令するように構成されたことを特徴とする請求項１５から２０のいずれか１項に記載の構成。
【請求項２２】
データパケット（４０１〜４０７；４２４）の前記一部の前記データパケットは、係数なしＰ画像データ及びサイレントオーディオデータを含むことを特徴とする請求項２１に記載の構成。
【請求項２３】
前記短縮手段（１３０；２３０）は、マルチメディアデータを前記ユーザ端末（１０）に送信することを一時的に停止するように前記送信機（１１０；２３０）に命令するように構成されたことを特徴とする請求項１５から２２のいずれか１項に記載の構成。
【請求項２４】
前記短縮手段（１３０；２３０）は、第３のマルチメディアチャネルから前記第１のマルチメディアチャネル（４１０）へのチャネル切り替えの要求を前記ユーザ端末（１０）から受信すると、前記第３のマルチメディアチャネルから前記第１のマルチメディアチャネル（４１０）への前記チャネル切り替えの後、前記第１のマルチメディアチャネル（４１０）のマルチメディアデータを前記ユーザ端末（１０）に送信することを一時的に停止するように前記送信機（１１０；２３０）に命令するように構成されたことを特徴とする請求項１５から２３のいずれか１項に記載の構成。
【請求項２５】
前記送信機（１１０；２１０）は、マルチメディアデータをデータパケット（４０１〜４０７；４２４）のマルチメディアデータストリーム（４５０）として前記ユーザ端末（１０）に送信し、各データパケット（４０１〜４０７；４２４）はシーケンス番号と関連付けられ、前記構成（１００）は、前記マルチメディアストリーム（４５０）の前記データパケット（４０１〜４０７；４２４）が連続したシーケンス番号を有するように、データパケット（４２４）にシーケンス番号を割り当てる手段（１５０；２５０、３５０）を更に具備することを特徴とする請求項１５から２４のいずれか１項に記載の構成。
【請求項２６】
前記送信機（１１０；２１０）は、マルチメディアデータをデータパケット（４０１〜４０７；４２４）のマルチメディアデータストリーム（４５０）として前記ユーザ端末（１０）に送信し、各データパケット（４０１〜４０７；４２４）はタイムスタンプと関連付けられ、前記構成（１００）は、前記マルチメディアデータストリーム（４５０）の前記データパケット（４０１〜４０７、４２４）が連続したタイムスタンプを有するように、データパケット（４０１〜４０７；４２４）にタイムスタンプを割り当てる手段（１５０；２５０、３５０）を更に具備することを特徴とする請求項１５から２５のいずれか１項に記載の構成。
【請求項２７】
マルチメディアチャネルを前記第１のマルチメディアチャネル（４１０）から前記第２のマルチメディアチャネル（４２０）に切り替える手段（３００）を更に具備し、前記切り替え手段（３００）は、前記第２のマルチメディアチャネル（４２０）のマルチメディアデータストリーム（４５０）がイントラ画像データを含む場合に前記チャネル切り替えを実行するように構成されることを特徴とする請求項１５から２６のいずれか１項に記載の構成。
【請求項２８】
前記第２のマルチメディアチャネル（４２０）の少なくとも１つの完全なイントラ画像に対応するデータを連続的に格納するように構成されたデータバッファ（１３６；２６０）を更に具備し、前記切り替え手段（３００）は、前記チャネル切り替え中に少なくとも１つの完全なイントラ画像に対応する前記データにアクセスするように構成されたことを特徴とする請求項２７に記載の構成。
【請求項２９】
請求項１５から２８のいずれか１項に記載の構成を具備することを特徴とするネットワークノード。
【請求項１】
第１の通信速度で第１のマルチメディアチャネル（４１０）のマルチメディアデータをユーザ端末（１０）に提供するマルチメディアプロバイダ（１００）を具備する通信システム（１）において、ユーザが感知するマルチメディアチャネルの切り替え時間を短縮する方法であって：
‐前記マルチメディアプロバイダ（１００）が前記第１の通信速度より遅く且つ前記ユーザ端末（１０）のマルチメディアデータレンダリング速度より遅い第２の通信速度を決定するステップと；
‐前記ユーザ端末（１０）におけるマルチメディアデータのバッファリング時間を短縮するために、前記マルチメディアプロバイダ（１００）が、前記決定した第２の通信速度でマルチメディアデータを前記ユーザ端末（１０）に一時的に送信することにより、前記第１のマルチメディアチャネル（４１０）から第２のマルチメディアチャネル（４２０）への切り替え後に、前記ユーザ端末（１０）において前記第２のマルチメディアチャネル（４２０）のマルチメディアデータをレンダリングするまでの遅れ時間を能動的に短縮するステップとから成ることを特徴とする方法。
【請求項２】
前記遅れ時間を能動的に短縮する前記ステップは、前記ユーザ端末（１０）のマルチメディアデータバッファ（１５）のバッファレベルを第１のバッファレベルから第２のより小さいバッファレベルに下げるために、前記マルチメディアプロバイダ（１００）が前記決定した第２の通信速度で前記ユーザ端末（１０）にマルチメディアデータを一時的に送信するステップを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記決決定ステップは、
‐前記ユーザ端末（１０）の推定初期バッファリング時間の情報と；
‐前記ユーザ端末（１０）のマルチメディアデータバッファ（１５）の最大バッファレベルの情報と；
‐前記ユーザ端末（１０）の可能な最小バッファリング時間の情報と；
‐前記ユーザ端末（１０）の前記マルチメディアデータバッファ（１５）の現在の推定バッファレベルの情報と
のうち少なくとも１つに基づいて、前記マルチメディアプロバイダ（１００）が前記第２の速度を決定するステップを含むことを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記決定ステップは、前記マルチメディアプロバイダ（１００）が前記通信システム（１）の現在の無線の状態を表す品質推定値に基づいて前記第２の速度を決定するステップを含むことを特徴とする請求項１から３のいずれか１項に記載の方法。
【請求項５】
前記マルチメディアプロバイダ（１００）は：
‐マルチメディアデータバッファ（２６０）を含むストリーミングサーバ（２００）と；
‐マルチメディアデータを前記ストリーミングサーバ（２００）に転送するために一定速度を有するマルチメディア送信元（３００）とを具備し、前記遅れ時間を能動的に短縮する前記ステップは、前記マルチメディアデータ通信速度を前記第１の通信速度から前記第２の通信速度に一時的に下げるために、前記ストリーミングサーバ（２００）が前記マルチメディアデータを前記ユーザ端末（１０）に送信する前にマルチメディアデータを前記マルチメディアデータバッファ（２６０）にバッファリングするステップを含むことを特徴とする請求項１から４のいずれか１項に記載の方法。
【請求項６】
前記ストリーミングサーバ（２００）が、前記第１のマルチメディアチャネル（４１０）から前記第２のマルチメディアチャネル（４２０）へのチャネル切り替えの要求に基づいて、前記第２のマルチメディアチャネル（４２０）のマルチメディアデータを前記マルチメディアデータバッファ（２６０）にバッファリングせずに前記第１の速度で前記第２のマルチメディアチャネル（４２０）の前記マルチメディアデータを前記ユーザ端末（１０）に送信するステップを更に含むことを特徴とする請求項５に記載の方法。
【請求項７】
マルチメディアデータは、データパケット（４０１〜４０７、４２４）のマルチメディアデータストリーム（４５０）として前記マルチメディアプロバイダ（１００）から前記ユーザ端末（１０）に送信され、前記遅れ時間を能動的に短縮する前記ステップは、前記マルチメディアプロバイダ（１００）が前記マルチメディアデータストリーム（４５０）の前記データパケット（４０１〜４０７、４２４）の一部を一時的に送信しないステップを含むことを特徴とする請求項１から６のいずれか１項に記載の方法。
【請求項８】
データパケット（４０１〜４０７、４２４）の前記一部の前記データパケットは、係数なしＰ画像データ及びサイレントオーディオデータを含むことを特徴とする請求項７に記載の方法。
【請求項９】
前記遅れ時間を能動的に短縮する前記ステップは、前記マルチメディアプロバイダ（１００）がマルチメディアデータを前記ユーザ端末（１０）に送信することを一時的に停止するステップを含むことを特徴とする請求項１から８のいずれか１項に記載の方法。
【請求項１０】
前記遅れ時間を能動的に短縮する前記ステップは：
‐前記マルチメディアプロバイダ（１００）が第３のマルチメディアチャネルから前記第１のマルチメディアチャネル（４１０）へのチャネル切り替えの要求を前記ユーザ端末（１０）から受信するステップと；
‐前記第３のマルチメディアチャネルから前記第１のマルチメディアチャネル（４１０）への前記チャネル切り替えの後、前記マルチメディアプロバイダ（１００）が前記第１のチャネル（４１０）のマルチメディアデータを前記ユーザ端末（１０）に送信することを一時的に停止するステップとを更に含むことを特徴とする請求項１〜９のいずれか１項に記載の方法。
【請求項１１】
マルチメディアデータは、データパケット（４１０〜４０７、４２４）のマルチメディアデータストリーム（４５０）として前記マルチメディアプロバイダ（１００）から前記ユーザ端末（１０）に送信され、各データパケット（４１０〜４０７、４２４）はシーケンス番号と関連付けられ、前記方法は、前記マルチメディアデータストリーム（４５０）の前記データパケット（４１０〜４０７、４２４）が連続したシーケンス番号を有するように、前記マルチメディアプロバイダ（１００）がデータパケット（４２４）にシーケンス番号を割り当てるステップを更に含むことを特徴とする請求項１から１０のいずれか１項に記載の方法。
【請求項１２】
マルチメディアデータは、データパケット（４１０〜４０７、４２４）のマルチメディアデータストリーム（４５０）として前記マルチメディアプロバイダから前記ユーザ端末に送信され、各データパケット（４１０〜４０７、４２４）はタイムスタンプと関連付けられ、前記方法は、前記マルチメディアデータストリーム（４５０）の前記データパケット（４１０〜４０７、４２４）が連続したタイムスタンプを有するように、前記マルチメディアプロバイダ（１００）がデータパケット（４１０〜４０７、４２４）にタイムスタンプを割り当てるステップを更に含むことを特徴とする請求項１から１１のいずれか１項に記載の方法。
【請求項１３】
前記マルチメディアプロバイダ（１００）が、マルチメディアチャネルを前記第１のマルチメディアチャネル（４１０）から前記第２のマルチメディアチャネル（４２０）に切り替え、前記第２のマルチメディアチャネル（４２０）のマルチメディアデータストリーム（４５０）がイントラ画像データを含む場合に前記第２のマルチメディアチャネル（４２０）のマルチメディアデータを前記ユーザ端末（１０）に送信するステップを更に含むことを特徴とする請求項１から１２のいずれか１項に記載の方法。
【請求項１４】
前記マルチメディアプロバイダ（１００）は、前記第２のマルチメディアチャネル（４２０）の少なくとも１つの完全なイントラ画像に対応するデータを連続的に格納するように構成されたデータバッファ（１３６；２６０）を含むことを特徴とする請求項１３に記載の方法。
【請求項１５】
ユーザが感知するマルチメディアチャネルの切り替え時間を短縮する構成（１００）であって：
‐第１の通信速度で第１のマルチメディアチャネル（４１０）のマルチメディアデータをユーザ端末（１０）に送信する送信機（１１０；２１０）と；
‐前記第１の通信速度より遅く且つ前記ユーザ端末（１０）のマルチメディアデータレンダリング速度より遅い第２の通信速度を決定する手段（１２０；２２０）と；
‐前記ユーザ端末（１０）におけるマルチメディアデータのバッファリング時間を短縮するために、前記決定した第２の通信速度でマルチメディアデータを前記ユーザ端末（１０）に一時的に送信するように前記送信機（１１０；２１０）に命令することにより、前記第１のマルチメディアチャネル（４１０）から第２のマルチメディアチャネル（４２０）への切り替え後に、前記ユーザ端末（１０）において前記第２のマルチメディアチャネル（４２０）のマルチメディアデータをレンダリングするまでの遅れ時間を短縮する手段（１３０；２３０）とを具備することを特徴とする構成。
【請求項１６】
前記短縮手段（１３０；２３０）は、前記ユーザ端末（１０）のマルチメディアデータバッファ（１５）のバッファレベルを第１のバッファレベルから第２のより小さいバッファレベルに下げるために、前記決定した第２の通信速度で前記ユーザ端末（１０）にマルチメディアデータを一時的に送信するように前記送信機（１１０；２１０）に命令するように構成されたことを特徴とする請求項１５に記載の構成。
【請求項１７】
前記決定手段（１２０；２２０）は、
‐前記ユーザ端末（１０）の推定初期バッファリング時間の情報と；
‐前記ユーザ端末（１０）のマルチメディアデータバッファ（１５）の最大バッファレベルの情報と；
‐前記ユーザ端末（１０）の可能な最小バッファリング時間の情報と；
‐前記ユーザ端末（１０）の前記マルチメディアデータバッファ（１５）の現在の推定バッファレベルの情報と
のうち少なくとも１つに基づいて、前記第２の通信速度を決定するように構成されたことを特徴とする請求項１５又は１６に記載の構成。
【請求項１８】
前記決定手段（１２０；２２０）は、前記構成（１００）が動作する無線通信システム（１）の現在の無線の状態を表す品質推定値に基づいて前記第２の通信速度を決定するように構成されたことを特徴とする請求項１５から１７のいずれか１項に記載の構成。
【請求項１９】
前記構成（１００）は：
‐マルチメディアデータバッファ（２６０）及び前記送信機（２１０）を含むストリーミングサーバ（２００）と；
‐一定速度でマルチメディアデータを前記ストリーミングサーバ（２００）に転送するマルチメディア送信元（３００）とを具備し、前記短縮手段（２３０）は、前記ストリーミングサーバ（２００）内で実現され、且つ前記マルチメディアデータ通信速度を前記第１の通信速度から前記第２の通信速度に一時的に下げるために、前記マルチメディアデータを前記ユーザ端末（１０）に送信するように前記送信機（２１０）に命令する前にマルチメディアデータを前記マルチメディアデータバッファ（２６０）にバッファリングするように構成されるたことを特徴とする請求項１５から１８のいずれか１項に記載の構成。
【請求項２０】
前記短縮手段（２３０）は、前記第１のマルチメディアチャネル（４１０）から前記第２のマルチメディアチャネル（４２０）へのチャネル切り替えの要求に基づいて、前記第２のマルチメディアチャネル（４２０）のマルチメディアデータを前記マルチメディアデータバッファ（２６０）にバッファリングせずに前記第１の速度で前記第２のマルチメディアチャネル（４２０）の前記マルチメディアデータを前記ユーザ端末（１０）に送信するように前記送信機（２１０）に命令するように構成されたことを特徴とする請求項１９に記載の構成。
【請求項２１】
前記送信機（１１０；２１０）は、マルチメディアデータをデータパケット（４０１〜４０７；４２４）のマルチメディアデータストリーム（４５０）として前記ユーザ端末（１０）に送信し、前記短縮手段（１３０；２３０）は、前記マルチメディアデータストリーム（４５０）の前記データパケット（４０１〜４０７；４２４）の一部を一時的に送信しないように前記送信機（１１０；１３０）に命令するように構成されたことを特徴とする請求項１５から２０のいずれか１項に記載の構成。
【請求項２２】
データパケット（４０１〜４０７；４２４）の前記一部の前記データパケットは、係数なしＰ画像データ及びサイレントオーディオデータを含むことを特徴とする請求項２１に記載の構成。
【請求項２３】
前記短縮手段（１３０；２３０）は、マルチメディアデータを前記ユーザ端末（１０）に送信することを一時的に停止するように前記送信機（１１０；２３０）に命令するように構成されたことを特徴とする請求項１５から２２のいずれか１項に記載の構成。
【請求項２４】
前記短縮手段（１３０；２３０）は、第３のマルチメディアチャネルから前記第１のマルチメディアチャネル（４１０）へのチャネル切り替えの要求を前記ユーザ端末（１０）から受信すると、前記第３のマルチメディアチャネルから前記第１のマルチメディアチャネル（４１０）への前記チャネル切り替えの後、前記第１のマルチメディアチャネル（４１０）のマルチメディアデータを前記ユーザ端末（１０）に送信することを一時的に停止するように前記送信機（１１０；２３０）に命令するように構成されたことを特徴とする請求項１５から２３のいずれか１項に記載の構成。
【請求項２５】
前記送信機（１１０；２１０）は、マルチメディアデータをデータパケット（４０１〜４０７；４２４）のマルチメディアデータストリーム（４５０）として前記ユーザ端末（１０）に送信し、各データパケット（４０１〜４０７；４２４）はシーケンス番号と関連付けられ、前記構成（１００）は、前記マルチメディアストリーム（４５０）の前記データパケット（４０１〜４０７；４２４）が連続したシーケンス番号を有するように、データパケット（４２４）にシーケンス番号を割り当てる手段（１５０；２５０、３５０）を更に具備することを特徴とする請求項１５から２４のいずれか１項に記載の構成。
【請求項２６】
前記送信機（１１０；２１０）は、マルチメディアデータをデータパケット（４０１〜４０７；４２４）のマルチメディアデータストリーム（４５０）として前記ユーザ端末（１０）に送信し、各データパケット（４０１〜４０７；４２４）はタイムスタンプと関連付けられ、前記構成（１００）は、前記マルチメディアデータストリーム（４５０）の前記データパケット（４０１〜４０７、４２４）が連続したタイムスタンプを有するように、データパケット（４０１〜４０７；４２４）にタイムスタンプを割り当てる手段（１５０；２５０、３５０）を更に具備することを特徴とする請求項１５から２５のいずれか１項に記載の構成。
【請求項２７】
マルチメディアチャネルを前記第１のマルチメディアチャネル（４１０）から前記第２のマルチメディアチャネル（４２０）に切り替える手段（３００）を更に具備し、前記切り替え手段（３００）は、前記第２のマルチメディアチャネル（４２０）のマルチメディアデータストリーム（４５０）がイントラ画像データを含む場合に前記チャネル切り替えを実行するように構成されることを特徴とする請求項１５から２６のいずれか１項に記載の構成。
【請求項２８】
前記第２のマルチメディアチャネル（４２０）の少なくとも１つの完全なイントラ画像に対応するデータを連続的に格納するように構成されたデータバッファ（１３６；２６０）を更に具備し、前記切り替え手段（３００）は、前記チャネル切り替え中に少なくとも１つの完全なイントラ画像に対応する前記データにアクセスするように構成されたことを特徴とする請求項２７に記載の構成。
【請求項２９】
請求項１５から２８のいずれか１項に記載の構成を具備することを特徴とするネットワークノード。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【公表番号】特表２００８−５３３８０８（Ｐ２００８−５３３８０８Ａ）
【公表日】平成２０年８月２１日（２００８．８．２１）
【国際特許分類】
【出願番号】特願２００８−５００６６５（Ｐ２００８−５００６６５）
【出願日】平成１７年１２月３０日（２００５．１２．３０）
【国際出願番号】ＰＣＴ／ＳＥ２００５／００２０６７
【国際公開番号】ＷＯ２００６／０９６１０４
【国際公開日】平成１８年９月１４日（２００６．９．１４）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成２０年８月２１日（２００８．８．２１）
【国際特許分類】
【出願日】平成１７年１２月３０日（２００５．１２．３０）
【国際出願番号】ＰＣＴ／ＳＥ２００５／００２０６７
【国際公開番号】ＷＯ２００６／０９６１０４
【国際公開日】平成１８年９月１４日（２００６．９．１４）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]