JP4287376B2

JP4287376B2 - ストリーミングメディア

Info

Publication number: JP4287376B2
Application number: JP2004544332A
Authority: JP
Inventors: ダニロディエゴクルシオ，イゴール; ルンダン，ミーッカ
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2002-10-14
Filing date: 2003-10-10
Publication date: 2009-07-01
Anticipated expiration: 2023-10-10
Also published as: JP2006503463A; CA2500781A1; EP1552644A1; FI20021820A0; FI20021820A; KR20050065592A; US7733830B2; MY143014A; US20040071088A1; WO2004036824A1; TW200406108A; EP1552644B1; AU2003278207A1; KR100705432B1; CN1706146B; BRPI0315207B1; FI116816B; CN1706146A; TWI248740B; BR0315207A

Description

本発明は、無線インターフェイス上におけるストリーミングサーバーからモバイルクライアント装置へのメディアのストリーミングに関するものである。

パケット交換ストリーミングサービス（Packet switched Streaming Service：ＰＳＳ）は、現在、３ＧＰＰ（3rd Generation Partnership Project）により、モバイル環境における標準化作業が行われている。図１には、メディアをストリーミングする（ストリーミングビデオ及び／又はオーディオ）能力を有する通信システムの一例が示されている。このシステムは、ＩＰ（Internet Protocol）ネットワーク１０４に接続されたストリーミングサーバー１１１を有している。このＩＰネットワーク１０４は、例えば、インターネットやサービスプロバイダ事業者のイントラネット（それらの事業者のドメインに属するイントラネットネットワーク）であってよい。ＩＰネットワーク１０４は、Ｇ_iインターフェイスを介してモバイル通信ネットワークのコアネットワーク１０３に接続されている。そして、このモバイル通信ネットワークは、コアネットワーク１０３に接続された無線アクセスネットワーク（Radio Access Network：ＲＡＮ）１０２をも具備している。この無線アクセスネットワーク１０２は、無線インターフェイス上におけるモバイル通信ネットワークへのアクセスをモバイル通信装置１０１に対して提供する。このアクセスは、回線交換手段（回線交換による音声又はデータ通話）、又はパケット交換手段、或いは、これらの両方により、提供可能である。以下においては、無線インターフェイス上において通信するためのパケット交換手段の一例として、ＧＰＲＳ（General Packet Radio Service）を使用する。尚、ＧＰＲＳに関連し、この「無線アクセスネットワーク（ＲＡＮ）」という一般的な用語には、基地（トランシーバ）局（ＢＳ）と基地局コントローラ（ＢＳＣ）を含んでいるものと見なされたい。

ストリーミングメディアにおいては、「動画（即ち、ビデオ）」又はサウンド（即ち、オーディオ）のシーケンス、或いはサウンドを伴う「動画」（即ち、マルチメディア）のシーケンスを、圧縮された形態で、ストリーミングサーバー１１１からモバイル通信装置１０１に送信する（尚、以下においては、このモバイル通信装置１０１をクライアント装置１０１と呼ぶ）。再生の前に、メディアファイルの全体がクライアントに到着していなければならない技法とは対照的に、このストリーミング法によれば、ストリーミングサーバー１１１からクライアント装置１０１にメディア（ビデオ及び／又はオーディオ）を継続的に送信しつつ、クライアントにメディアが到着次第、メディアを逐次再生することができる。

しかしながら、この図１に示されているシステムなどのセルラーモバイル通信システムにおいてメディアをストリーミングする際には、モバイル環境に固有の新しい問題が生じることになる。これらの問題は、そのほとんどがモバイルシステムの様々な制約に起因するものであり、これらの問題の１つが、図２に示されているセルの再選択（即ち、ハンドオーバー）状態において発生する。

図２において、無線アクセスネットワーク１０２の第１基地局ＢＳ１は、第１セル２０１のエリアにサービスしており、無線アクセスネットワーク１０２の第２基地局ＢＳ２は、第２セル２０２のエリアにサービスしている。セル再選択の前の段階においては、クライアント装置１０１は、第１基地局ＢＳ１のサービスを受けており、即ち、クライアント装置１０１は、第１基地局ＢＳ１との間にアクティブな無線リンクを具備している。この状況は、図２の左側に示されている。一方、セル再選択の後の段階においては、クライアント装置１０１は、第２基地局ＢＳ２のサービスを受けることになり、破線によって示されている第１基地局ＢＳ１との無線リンクは切断される。この状況が、図２の右側に示されている。

このセルの再選択（Cell Reselection：ＣＲ）は、時間的に、（ａ）プレＣＲ期間、（ｂ）ＣＲ期間、及び（ｃ）ポストＣＲ期間という３つの期間に分割することができる。

プレＣＲ期間においては、第１セル内において受信される信号の品質が弱化し、クライアント装置１０１は、セル再選択のシグナリングを開始する。この期間中は、クライアント装置１０１は、第１基地局ＢＳ１を介してストリーミングメディアを受信可能である。そして、ＣＲ期間中に、実際のセルの再選択が実行されることになる。この期間中においては、クライアント装置１０１は、ストリーミングメディアを受信することはできない。そして、クライアント装置１０１は、ポストＣＲ期間において、第２基地局ＢＳ２を介し、再度、ストリーミングメディアを受信できるようになる。

このセルの再選択により、サービスの長い休止状態が発生することになる。例えば、ＧＰＲＳを無線ベアラとして使用する場合には、セルの再選択（ＣＲ期間）は、最大３０〜４０秒を所要することになり、これは、進行中のストリーミングセッションに影響を与える。例えば、ストリーミングメディアを搬送するパケットの一部が消失したり、クライアント装置１０１において、メディアの再生がフリーズしたりすることになるのである。このフリーズは、ストリーミングメディアがビデオストリームから構成されている場合には、クライアント装置のディスプレイ上に静止画が表示され、ストリーミングメディアの受信と再生が再び可能になる時点まで、これが一定の期間にわたって留まることを意味している。又、ストリーミングメディアがオーディオストリームから構成されている場合には、このフリーズは、ＣＲ期間が終了する時点まで、サウンドが再生されないことを（即ち、無音状態）を意味している。

従って、進行中のストリーミングセッションに対するセル再選択の影響を軽減する適切な手段に対するニーズが存在している。

本発明の第１の態様によれば、無線インターフェイス上においてストリーミングサーバーからモバイルクライアント装置にメディアをストリーミングする方法が提供され、この方法は、セル再選択のためにモバイルクライアント装置が受信できないストリーミングメディアを送信するように、ストリーミングサーバーに対して要求する段階を有している。

このストリーミングメディアを送信するようにストリーミングサーバーに対して要求する要求は、前述のセル再選択の前又は後において、モバイルクライアント装置からストリーミングサーバーに送信可能である。

尚、この要求は、セル再選択に起因して（セル再選択期間中に）モバイルクライアント装置が受信できない（又、できなかった）メディアのみの送信要求に限定されるものではない。一実施例においてはこの要求を、受信できなかったメディアコンテンツの部分の再送に加え、メディアコンテンツの残りの部分の送信を実際に要求しているものと解釈することができる。

又、この「メディア」という用語は、ビデオ又はオーディオ、又は静止画などのその他のメディア、或いは、これらの組み合わせ（即ち、マルチメディア）を意味するものと見なされたい。

好ましくは、再送要求は、セル再選択に応答して送信される。そして、この再送要求は、好ましくは、モバイルクライアント装置アプリケーションとストリーミングサーバーアプリケーション間において送信されるアプリケーションレイヤの要求である。

好適な実施例においては、再生の前に、クライアント装置において、ストリーミングメディアを一時的に保存するバッファなどの一時ストアの充填度を上昇させるべく、所定の期間にわたって高速送信するように、ストリーミングサーバーに対して要求する。好ましくは、これは、高ビットレートメディアストリームの送信から、低ビットレートメディアストリームの高速送信に切り替えるように、ストリーミングサーバーに対して要求することにより、実行する。そして、この高ビットレートストリーム又は低ビットレートストリームは、好ましくは、マルチレートコーデックによって提供する。

本発明の第２の態様によれば、無線インターフェイス上においてストリーミングサーバーからストリーミングメディアを受信するモバイルクライアント装置が提供され、このモバイルクライアント装置は、セル再選択のためにモバイルクライアント装置が受信できないストリーミングメディアを送信するように、ストリーミングサーバーに対して要求する手段を有している。

好ましくは、このモバイルクライアント装置は、無線インターフェイスにより、モバイル通信ネットワークに接続されている。そして、このモバイルクライアント装置は、好ましくは、携帯電話機から構成されている。

本発明の第３の態様によれば、無線インターフェイス上においてストリーミングメディアをモバイルクライアント装置に送信するストリーミングサーバーが提供され、このストリーミングサーバーは、セル再選択のためにモバイルクライアント装置が受信できないストリーミングメディアを送信するように、ストリーミングサーバーに対して要求する要求を受信する手段と、この受信した要求に応答して動作する手段と、を有している。

本発明の第４の態様によれば、ストリーミングサーバーとモバイルクライアント装置を有し、無線インターフェイス上において、ストリーミングサーバーからモバイルクライアント装置にメディアをストリーミングするシステムが提供され、このシステムは、セル再選択のためにモバイルクライアント装置が受信できないストリーミングメディアを送信するように、ストリーミングサーバーに対して要求する手段をモバイルクライアント装置に有し、更に、このシステムは、この要求を受信する手段と、この受信した要求に応答して動作する手段と、をストリーミングサーバーに有している。

本発明の第５の態様によれば、モバイルクライアント装置内において実行可能なコンピュータプログラムが提供され、このコンピュータプログラムは、セル再選択のためにモバイルクライアント装置が受信できないストリーミングメディアを送信するように、モバイルクライアント装置からストリーミングサーバーに対して要求させるプログラムコードを有している。

本発明の第６の態様によれば、ストリーミングサーバー内において実行可能なコンピュータプログラムが提供され、このコンピュータプログラムは、セル再選択のためにモバイルクライアント装置が受信できないストリーミングメディアを送信するようにストリーミングサーバーに対して要求する要求をストリーミングメディアに受信させるプログラムコードと、この受信した要求に応答して動作するプログラムコードと、を有している。

従属請求項には、本発明の好適な実施例について記載されている。そして、この本発明の特定の態様に関係する従属請求項に記載されている主題は、本発明のその他の態様にも適用可能である。

以下、一例として、添付の図面を参照し、本発明の実施例について説明する。

図１に示されているシステムは、本発明の好適な実施例においても使用することができる（これは、図２についても当てはまる）。即ち、このシステムは、ＩＰネットワーク１０４に接続されたストリーミングサーバー１１１を有している。そして、このＩＰネットワーク１０４は、例えば、インターネットやサービスプロバイダ事業者のイントラネットであってよい。ＩＰネットワーク１０４は、Ｇ_iインターフェイスを介してモバイル通信ネットワークのコアネットワーク１０３に接続されている。このモバイル通信ネットワークは、コアネットワーク１０３に接続された無線アクセスネットワーク（ＲＡＮ）１０２をも具備している。そして、この無線アクセスネットワーク１０２は、無線インターフェイス上におけるモバイル通信ネットワークへのアクセスをモバイル通信装置１０１に提供している。このアクセスは、回線交換手段（回線交換による音声又はデータ通話）、又はパケット交換手段、或いは、これらの両方により、提供可能である。そして、以下においては、無線インターフェイス上において通信するためのパケット交換手段の一例として、ＧＰＲＳ（General Packet Radio Service）を使用することとする。

本発明の好適な実施例について十分に理解できるように、次のような例を考えてみよう。

この例においては、モバイル通信装置１０１（この場合にも、これをクライアント装置１０１と呼ぶ）は、第１基地局ＢＳ１のサービスを受けている際に、既にストリーミングサーバー１１１とのストリーミングセッションを確立した状態にある。そして、この例においては（並びに、以下の説明においては）、主に、ビデオストリーミングセッションについて検討することとする。但し、この対応する検討内容は、オーディオストリーミングセッション及びマルチメディア（例：オーディオを伴うビデオ）ストリーミングセッションにも適用可能である。

ストリーミングセッションのセットアップの際には、ＲＴＳＰ（Real Time Streaming Protocol）プロトコルを使用する。そして、セッションが確立すれば、ＲＴＰ（Real Time Transport Protocol）やその他のプロトコルにより、ストリーミング自体を実行可能である（即ち、メディアフローを送信することができる）。尚、確立されたセッションの変更が望ましい場合には、ＲＴＳＰを使用し、これを再度実行することなる。

この確立したストリーミングセッションの開始時点においては、パケット（又は、フレーム）によって送信され、受信されたストリーミングメディア（メディフロー）は、クライアント装置のバッファ（以下、これをクライアントバッファと呼ぶ）内にバッファリングされる（即ち、一時的に保存される）。そして、このクライアント装置のバッファが満杯になると、バッファの一端からストリーミングメディアの再生（プレイバック）が開始され、これと同時に、このバッファは、受信されるストリーミングメディアにより、その他端において、継続的に充填される。この結果、このバッファは、システムの通常の動作においては、略満杯の状態に維持されることになる。

ここで、クライアント装置は、第１セル２０１から第２セル２０２へのセルの再選択を経験する（図２）。尚、この図２においては、無線アクセスネットワーク（ＲＡＮ）１０２は、単一の雲の形状のみによって示されているが、これは、様々な無線アクセスネットワークから構成可能であることに留意されたい。即ち、これは、ＧＰＲＳ（ＧＰＲＳのみの）ＲＡＮ、３Ｇ（３ｒｄＧｅｎｅｒａｔｉｏｎ）ＲＡＮ、又はこれらの組み合わせから構成することができる。従って、第１セル２０１（基地局ＢＳ１のサービスを受けているもの）と第２セル２０２（基地局ＢＳ２のサービスを受けているもの）は、例えば、ＧＰＲＳＲＡＮ又は３ＧＲＡＮのセルであってよい。この結果、セルの再選択（ハンドオーバー）も、例えば、ＧＰＲＳＲＡＮに属する基地局間、３ＧＲＡＮに属する基地局間、或いは、ＧＰＲＳＲＡＮに属する基地局と３ＧＲＡＮに属する基地局間において、発生することになる。

クライアント装置１０１は、ＣＲ期間中においては、ストリーミングメディアを受信することはできない。従って、ＣＲ期間が始まると、バッファコンテンツが更に再生される一方で、連続的な充填が停止するため、クライアント装置のバッファに空きが発生し始めることになる。そして、クライアント装置バッファのサイズに応じて、（ｉ）セルの再選択が所要する時間に比べて、クライアント装置バッファのほうが短い（単位：時間）（即ち、ＣＲ期間に比べて、満杯のクライアント装置バッファが空になるのに所要する時間のほうが短い）場合と、（ｉｉ）セルの再選択が所要する時間に比べて、クライアント装置バッファのほうが長い（単位：時間）（即ち、ＣＲ期間に比べて、満杯のクライアント装置が空になるのに所要する時間のほうが長い）場合という２つの異なるケースが存在し得る。

まず、第１のケースにおいては（図３）、バッファは、ＣＲ期間中に完全に空になってしまう。そして、バッファが空になるため、クライアント装置１０１にとっては、それ以上再生するメディアが存在していない。このため、クライアント装置１０１は、リバッファリングを始めることになる。このリバッファリングは、ポストＣＲ期間に開始可能である。リバッファリングを開始するには、クライアント装置１０１は、ＲＴＳＰＰＡＵＳＥ／ＰＬＡＹ法を使用することができる。この方法によれば、クライアント装置１０１は、まず、ＲＴＳＰＰＡＵＳＥメッセージをストリーミングサーバー１１１に対して送信する。このＰＡＵＳＥメッセージにより、サーバー１１１は、メディアフローの送信を休止する。続いて、クライアント装置１０１は、最後に受信したフレームに続いてストリーミングメディアの再送を開始するように、ストリーミングサーバー１１１に対して要求するＲＴＳＰＰＬＡＹメッセージを送信する。このようにして、クライアントがストリーミングメディアの受信を再開すると、リバッファリングが始まることになる。そして、クライアント装置バッファが満杯になると、最後に受信したフレームに続いてストリーミングメディアの再生が再開されることになる。尚、この間においては、クライアント装置のディスプレイ上には、最後に受信したフレームが静止画として表示されている。従って、このケースの場合には、静止画が表示されるという欠点は有しているものの、ＣＲ期間中にクライアント装置が受信できないメディアフローが、ＣＲ期間の後に、サーバー１１１からクライアント装置１０１に再送されるため、パケットが実際に消失することはない。

一方、第２のケースにおいては（図４）、バッファのコンテンツ全体の再生がＣＲ期間中には完了しない。従って、ＣＲ期間中には、バッファは、部分的に空になるのみである（即ち、ＣＲ期間が終了した時点で、バッファ内には、ストリーミングメディア（データ）がまだ存在している。そして、ポストＣＲ期間においては（ＣＲ期間の後には）、ＣＲ期間の前にバッファ内に保存されていたストリーミングメディア（即ち、データ^*）の再生が、バッファの一端において更に継続される一方で、ＣＲ期間の後に受信されるストリーミングメディア（即ち、データ^**）により、他端が充填されることになる。なんの処置も施さなければ、データ^*は、最終的には終了し、データ^**の第１フレームから再生が継続されることになる。静止画が表示されることはない。しかしながら、データ^**の第１フレームは、データ^*の最後のフレームの直後に再生されるべきフレームではない。クライアント装置１０１は、ＣＲ期間中にストリーミングメディアを受信できなかったため、データ^*の最後のフレームの次に表示するべきフレームを受信してはおらず、バッファリングされているメディア内には、時間的なギャップが存在している。この結果、クライアント装置１０１は、セルの再選択のために受信できなかったストリーミングメディアシーケンス（ビデオ）の表示をスキップすることになる。尚、同様のことは、オーディオストリームの場合にも発生する（即ち、受信できなかったサウンドの再生をクライアント装置１０１がスキップすることになる）。

図５には、この第２のケースが更に詳細に示されている。尚、この図５は、非常に単純なケースを示しているに過ぎないことに留意されたい。そして、この図５においては、時間は、左から右に経過するものと見なされたい。サーバーが送信するストリーミングメディアシーケンスは、ビデオフレームＡ〜Ｓによって構成されている。これらのフレームは、クライアント装置において受信され、再生の前にバッファリングされる。そして、バッファが満杯になった際に（即ち、バッファ内におけるフレームＡ〜Ｇの保存が完了した時点で）、メディアストリームの再生がフレームＡから開始され、次いで、それらのフレーム（動画）がクライアント装置のディスプレイ上に表示されることになる。尚、この図５には、わかりやすくするために、フレームＧに続くフレームのバッファリングは示されてはいない。

ＣＲ期間中には、サーバーからクライアント装置へのメディアフローは不可能である。従って、クライアント装置は、フレームＬ〜Ｏを受信することができない（ＣＲ期間が存在しなければ、このメディアフローは、クライアント装置において完全に受信される）。ここで、ＣＲ期間がバッファサイズよりも短い場合には、ＣＲ期間の前に最後に受信されたフレーム（フレームＫ）の表示の後には、ＣＲ期間の後に最初に受信されたフレーム（フレームＰ）の表示が続くことになり、ビデオフレームＬ〜Ｏは、まったく表示されない。同様のことは、オーディオストリームの場合にも発生する。即ち、ユーザーは、サウンドの休止と時間的なギャップを聞くことになる。

フレームには、イントラフレームとインターフレームという２つのタイプが存在する。イントラフレームには、画像の必要な情報がすべて含まれているが、インターフレームに含まれているのは、先行する画像と比べた場合の変化（又は、予想される変化）のみである。この先行画像は、イントラフレーム又はインターフレームかもしれない。従って、フレームＰがイントラフレームであれば、表示画像は、フレームＫからフレームＰに時間の経過方向に飛ぶだけであり、この場合には、ユーザーにとっては、フレームＬ〜Ｏが表示されないということに過ぎない。しかしながら、フレームＰがインターフレームである場合には、次のイントラフレームが受信及び再生されるまで、表示画像（動画）に大きな歪が発生することになろう。

図６に示されている本発明の好適な実施例においては、この第２のケースに関係する前述の問題に焦点を絞っている。この実施例においては、バッファが、ＣＲ期間の持続時間よりも長くなっている。従って、バッファは、ＣＲ期間中に完全に空にはならず、部分的に空になるのみである。尚、この図６は、非常に単純なケースを示しているに過ぎないことに留意されたい。又、この図６においては、時間は、左から右に経過するものと見なされたい。サーバーが送信するストリーミングメディアシーケンスは、フレームＡ〜Ｓによって構成されている。そして、これらのフレームは、クライアント装置において受信され、再生の前にバッファリングされる。そして、バッファが満杯になった際に、メディアの再生がフレームＡから始まり、次いで、これらのフレーム（動画）がクライアント装置のディスプレイ上において表示されることになる。尚、この図６には、わかりやすくするために、フレームＧに続くフレームのバッファリングは示されてはいない。ＣＲ期間中には、サーバーからクライアント装置へのメディアフローは不可能である。従って、クライアント装置は、フレームＬ〜Ｏを受信することができない（ＣＲ期間が存在しない場合には、このメディアフローは、クライアント装置において完全に受信されることになる）。

ＣＲ期間が終了した際に、クライアント装置は、ＣＲ期間の前に（即ち、プレＣＲ期間中に）自身が受信した最後のフレームがなんであったかを正確に認知している。この実施例の場合には、それは、フレームＫである。従って、クライアント装置は、ＣＲ期間が終了した直後に、この最後に受信したフレームに続いてストリーミングメディアの再送を開始するようにストリーミングサーバーに対して要求する。そして、この要求を受信すると、ストリーミングサーバーは、メディアフローの再送を開始する。送信するべき第１のフレームは、この実施例の場合には、フレームＬである。尚、ＣＲ期間の後に、且つ再送が始まる前に、送信及び受信されるフレームは、クライアント装置によって無視される（これらは、恐らく、フレームＰから始まるいくつかのフレームであろう）。そして、ＣＲ期間の前にバッファ内に保存されている（フレームＡ〜Ｋからなる）ストリーミングメディアが終了すると、ＣＲ期間の後に受信された再送ストリーミングメディアの第１フレーム（フレームＬ）によって再生が継続されることになる。従って、表示ビデオ画像の不連続性は、ユーザーには表示されない。尚、この図６には、その他の方式によってはクライアント装置において受信されない再送ビデオフレームＬ〜Ｏが太字で示されている。又、オーディオストリームの場合にも、同様に、クライアント装置において受信が停止した時点からオーディオストリームの再送を開始するように、ストリーミングサーバーに対して要求する。そして、この結果、再生の不連続性は表れない。

実際には、この再送要求は、ＲＴＳＰＰＡＵＳＥ／ＰＬＡＹ法によって実行可能である。この方法によれば、クライアント装置は、ＣＲ期間が終了した後に、まず、ＲＴＳＰＰＡＵＳＥメッセージをストリーミングサーバーに対して送信する。このＰＡＵＳＥメッセージにより、サーバーは、メディアフローの送信を休止する。但し、クライアント装置おいて受信されているストリーミングメディアの再生は、バッファが空にならない限り（この場合には、これは発生しないはずである）、休止されることはない。続いて、クライアント装置は、ＲＴＳＰＰＬＡＹメッセージをストリーミングサーバー１１１に対して送信する。このＰＬＡＹメッセージには、再送の開始点に関する情報が含まれている。ＣＲ期間の終了時点において、クライアント装置は、最後に受信したフレームの時刻を認知している。クライアント装置は、これに基づいて、ＰＬＡＹメッセージを送信する前に、この開始点を判定する。そして、このＰＬＡＹメッセージにより、サーバーは、再送を開始する。

ＰＡＵＳＥメッセージの一例は、次のとおりである。

ＰＡＵＳＥｒｔｓｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｆｏｏＲＴＳＰ／１．０
ＣＳｅｑ：６
Ｓｅｓｓｉｏｎ：３５４８３２

このＰＡＵＳＥメッセージは、変化の到来についてサーバーに通知するものである。一方、これに続いて送信されるＰＬＡＹメッセージの一例は、次のとおりである。

ＰＬＡＹｒｔｓｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｆｏｏＲＴＳＴ／１．０
ＣＳｅｑ：７
Ｓｅｓｓｉｏｎ：３５４８３２
Ｒａｎｇｅ：ｎｐｔ＝２８．００−

「Ｒａｎｇｅ」というメッセージフィールドが、再送の開始点を示している。この例の場合には、開始点は、ストリーミングメディアシーケンスの開始から２８秒のところに位置している。図６に示されている実施例との関係においては、この時点は、ちょうど、ストリーミングメディアシーケンス内のフレームＬの時点に相当しよう。

先程説明した実施例においては、ＣＲ期間中に失われたフレーム（パケット）が、サーバーからクライアント装置に対して再送される。又、バッファサイズがＣＲ期間の持続時間よりも長いため、表示されるビデオ画像の中断は発生せず、ユーザーの経験は極大化されることになる。

しかしながら、バッファの充填度が変化しない通常のストリーミングの場合には、充填されるのと同一のレートでバッファが空になるため（再生されるため）、この結果、更なる問題が生じることになる。即ち、先程説明した実施例の場合には、セルの再選択の後に、クライアント装置バッファは、前述の理由により、以前の状態よりも更に空になった状態で維持されることになる。従って、例えば、近い将来に新たにセルの再選択が実行された場合には、この更に空になったバッファに起因し、前述の第１のケース（即ち、セルの再選択が所要する時間に比べて、クライアント装置のバッファが短いケース）に関連して説明したものと同一の不都合が発生することになってしまうのである。

本発明の好適な一実施例においては、この問題に焦点を絞っている。即ち、この実施例においては、表示されるビデオ画像（同様に、再生されるサウンド）の滑らかな動作を確保するべく、ＣＲ期間の後に、一定の期間にわたって、空になる（再生される）レートに比べて、高いレートで、クライアントバッファを充填している（この期間を充填期間と呼ぶことができよう）。そして、この充填期間が終了すると、バッファは、再度、満杯状態になっており、この時点で、空になるのと同一のレートでバッファを充填する通常のストリーミングを再開するのである。

尚、通常は、バッファの充填度を上昇させるには、再生の休止を必要とすることに留意されたい。本実施例においては、再生中に再生レートよりも高いレートによってバッファを充填するという巧妙なバッファ管理により、再生を休止させることなしに、バッファの充填度を上昇させることができる。

再生を休止させることなしに、バッファの充填度を上昇させるべく、この実施例においては、クライアント装置は、低ビットレートのストリーミングメディアシーケンスに切り替えると共に、実際の送信においては、以前と同一の伝送ビットレート（以下においては、これをオリジナルの伝送ビットレートと呼ぶ）を使用するように、サーバーに対して要求する。そして、オリジナルの伝送ビットレートに到達するべく、クライアント装置は、加速係数によって低ビットレートシーケンスの伝送を加速するように、サーバーに対して要求する。この伝送ビットレートの加速により、データのバッファからの読み出し量をバッファへの書き込み量が上回ることになる。そして、この結果、所望どおりに、バッファの充填度が上昇する。

換言すれば、第１ビットレートにおいてエンコードされたオリジナルのシーケンスの送信から、第１ビットレートよりも低い第２ビットレートにおいてエンコードされた新しい対応するシーケンスの送信に切り替えると共に、オリジナルの伝送ビットレート（帯域幅）に到達するべく、新しいシーケンスの伝送ビットレートを上昇させるように、サーバーに対して要求するのである。尚、メディアストリームをエンコード（及びデコード）するビットレートは、伝送ビットレートとは別の概念であることに留意されたい。メディアストリームをエンコードしたビットレートは、その画像の品質に影響を与える。メディアストリームを高ビットレートにおいてエンコードした場合には、これは、低ビットレートにおけるエンコードと比べて、多くのビットがエンコードに使用されていることを意味している。通常は、これにより、優れた画像品質を結果的に得ることができる。一方、伝送ビットレートとは、メディアストリームが実際に送信されるビットレートのことであり、これは、利用可能な帯域幅によって左右されることになる。

この低ビットレートシーケンスの送信への切り替えと伝送ビットレートの加速の要求は、ＲＴＳＰＰＡＵＳＥ／ＰＬＡＹ法を使用して伝達可能である。即ち、ポストＣＲ期間において、クライアント装置バッファの充填を所望する場合には、クライアント装置は、まず、先程の説明において既に提示済みのものに対応するＰＡＵＳＥメッセージをサーバーに対して送信し、変化の到来について通知する。そして、これに続いて、クライアント装置は、ＰＬＡＹメッセージを生成し、サーバーに送信することになる。

このＰＬＡＹメッセージの例は、次のとおりである。

ＰＬＡＹｒｔｓｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｆｏｏＲＴＳＰ／１．０
ＣＳｅｑ：７
Ｓｅｓｓｉｏｎ：３５４８３２
Ｒａｎｇｅ：ｎｐｔ＝２８．００−４０．００
Ｂａｎｄｗｉｄｔｈ：２００００
Ｓｐｅｅｄ：１．５

このメッセージには、クライアント装置及びストリーミングサーバーが理解する「Ｂａｎｄｗｉｄｔｈ」及び「Ｓｐｅｅｄ」という２つの任意選択のメッセージフィールドが含まれている。尚、これらのフィールドは、ＩＥＴＦ（Internet Engineering Task Force）により、ＲＦＣ２３２６規格「ＲｅａｌＴｉｍｅＳｔｒｅａｍｉｎｇＰｒｏｔｏｃｏｌ」において、任意選択フィールドとして既に規定済みである。

「Ｂａｎｄｗｉｄｔｈ」メッセージフィールドは、低ビットレートシーケンスの送信に変更するように、サーバーに対して通知するものであり（この場合には、このシーケンスのビットレートは、２０ｋｂｐｓである）、「Ｓｐｅｅｄ」メッセージフィールドは、加速係数により、送信を加速するようにサーバーに対して通知している（この場合には、加速係数は、１．５である）。そして、「Ｒａｎｇｅ」メッセージフィールドは、ストリーミングメディアシーケンス内の開始点及び停止点（単位：時間）について通知している（これらは、ストリーミングメディアシーケンスの開始点から算出されたものである）。

このＰＬＡＹメッセージは、当初、サーバーが、３０ｋｂｐｓのオリジナルの伝送ビットレートにおいて、３０ｋｂｐｓのビットレートのシーケンスを送信しており、バッファを充填するべく、サーバーが、好ましくは、２０ｋｂｐｓのビットレートの送信に切り替えると共に、加速係数１．５により、この送信を加速して、１２秒の充填期間において（即ち、メディアシーケンスの２８秒と４０秒の時点間において）、３０ｋｂｐｓのオリジナルの伝送ビットレートに到達させる例の場合に好適なものである。

可能なビットレートオプションがクライアントに判明している場合には（これらについは、通常、セッションのセットアップの際に、例えば、ＲＴＳＰＤＥＳＣＲＩＢＥメッセージに対する「２００ＯＫ」応答などにより、サーバーからクライアントに伝達される）、クライアントは、次の式を使用して、オリジナルのビットレートに到達するのに必要な加速係数を算出することができる。

加速係数＝オリジナルの伝送ビットレート／新しい伝送ビットレート

そして、バッファが満杯になった時点で、クライアント装置は、更なるＲＴＳＰＰＡＵＳＥ及びＰＬＡＹメッセージのペアをサーバーに対して送信する。このＰＬＡＹメッセージの例は、次のとおりである。

ＰＬＡＹｒｔｓｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｆｏｏＲＴＳＰ／１．０
ＣＳｅｑ：６７
Ｓｅｓｓｉｏｎ：３５４８３２
Ｒａｎｇｅ：ｎｐｔ＝４０．００−
Ｂａｎｄｗｉｄｔｈ：３００００
Ｓｐｅｅｄ：１．０

この模範的なメッセージは、オリジナルの伝送ビットレート３０ｋｂｐｓ（Ｓｐｅｅｄ：１．０）において（オリジナルの）３０ｋｂｐｓのビットレートのメディアシーケンス（Ｂａｎｄｗｉｄｔｈ：３００００）の送信をメディアシーケンスの４０秒の時点から（Ｒａｎｇｅ：ｎｐｔ＝４０．００−）開始するように、サーバーに対して要求している。

クライアント装置は、次の式を使用して、バッファ充填期間の長さを算出可能である。

充填期間＝ＬｏｗＳｅｑＴｉｍｅ／加速係数

ここで、ＬｏｗＳｅｑＴｉｍｅは、次のとおりである。

ＬｏｗＳｅｑＴｉｍｅ＝（ＢｕｆｆｅｒＳｉｚｅ−ＢｕｆｆｅｒＤａｔａ）・（オリジナルの伝送ビットレート）／（オリジナルの伝送ビットレート−新しい伝送ビットレート）

これらの式において、ＬｏｗＳｅｑＴｉｍｅは、クライアント装置における低ビットレートシーケンスの再生時間の持続時間を示しており、ＢｕｆｆｅｒＳｉｚｅは、バッファのサイズ（単位：秒）を示し、ＢｕｆｆｅｒＤａｔａは、バッファ内に残されているデータ（単位：秒）を示している。

図７に、このバッファの充填について示されている。尚、この図７は、非常に単純なケースを示しているに過ぎないことに留意されたい（例えば、遅延がすべて無視されている）。又、この図７においては、時間は、左から右に経過するものと見なされたい。ＣＲ期間が始まると、バッファが空になり始めることがわかる。そして、第１のＰＬＡＹメッセージを受信した際に、サーバーは、低ビットレート（これは、この場合には、２０ｋｂｐｓである）を具備するメディアシーケンスの送信に切り替え、加速係数（これは、この場合にも、１．５である）によって送信を加速する。尚、加速係数が１．５であるため、バッファを充填するには、空になる期間が継続した時間の２倍を所要することになる。例えば、空になる期間が２５秒だけ継続した場合には、充填期間は、この加速係数の場合には、５０秒となろう。そして、バッファが満杯になった時点で、第２のＰＬＡＹメッセージが送信され、サーバーは、高ビットレート（これは、この場合には、３０ｋｂｐｓである）を具備するオリジナルのメディアシーケンスの送信に切り替え、オリジナルの伝送ビットレートにおける送信を継続することになる。

以上においては、例えば、ビデオストリームが、通常、イントラフレームとインターフレームの両方から構成されており、イントラフレームは、画像の必要なすべての情報を含む「独立的なフレーム」であり、インターフレームは、先行する画像と比べた場合の変化（又は、予想される変化）のみを含んでいるものと説明している。そこで、本発明の以下の好適な実施例においては、この点に関連し、低ビットレートシーケンスからオリジナルのビットレートシーケンスへの切り替えのタイミングについて、更に詳しく説明することとする。

この実施例における目的は、可能な場合には常に、低ビットレートシーケンスからオリジナルのビットレートシーケンスへの切り替えが、オリジナルのビットレートシーケンスのイントラフレームの時点において（更に一般的に表現すれば、送信の切り替え先であるシーケンスのイントラフレームの時点において）発生するように、時間設定することにある。このようにすることにより、予測誤差及び／又はメディア（フレーム）フローのジャンプを回避することができる。図８に、この実施例が示されている。尚、この図８は、単純なケースを示しているに過ぎないことに留意されたい。又、この図８においては、時間は、左から右に経過するものと見なされたい。この実施例においては、オリジナルのビットレートシーケンスから低ビットレートシーケンスへの第１の切り替えは、第１のＰＡＵＳＥ／ＰＬＡＹメッセージペアにより、２８秒の時点において実施されている。

この図８に示されているように、オリジナルのビットレートシーケンスにおけるイントラフレームの位置は、低ビットレートシーケンスのものとは異なっている。しかしながら、バッファを完全に充填するのに必要な時間（即ち、充填期間）、オリジナルのシーケンスにおける２つの隣接するイントラフレームの時間距離（即ち、イントラフレームレート「ＩＦｒａｍｅＴｉｍｅ_Original」、及びオリジナルビットレートシーケンスから低ビットレートシーケンスへの第１の切り替えが行われる時点（即ち、「ＳｗｉｔｃｈＴｉｍｅ」）に基づいて、オリジナルのビットレートシーケンスに戻るべく切り替わるのに好適な時点を算出することができる。尚、「ＩＦｒａｍｅＴｉｍｅ_Original」パラメータは、低ビットレートシーケンスに切り替わる前に、クライアント装置において、オリジナルのビットレートシーケンスから算出可能である。そして、オリジナルのビットレートシーケンスに戻るべく切り替わるのに好適な時点の算出は、次の式を使用して実行可能である。

ＳｅｑＣｈａｎｇｅＴｉｍｅ＝ＩＦｒａｍｅＴｉｍｅ_Original＊［（Ｓｗｉｔｃｈｔｉｍｅ＋充填期間）／ＩＦｒａｍｅＴｉｍｅ_Original］

この式において、「ＳｅｑＣｈａｎｇｅＴｉｍｅ」は、オリジナルのビットレートシーケンスに戻るべく切り替わる時点を示しており、大括弧は、この大括弧内において算出された値の端数部分を切り捨てるＦＬＯＯＲ関数（又は、ＴＲＵＮＣ関数）を示している。例えば、バッファを完全に充填するのに必要な時間（即ち、「充填期間」）が１６秒であれば、第１の切り替えが行われる時点（即ち、「ＳｗｉｔｃｈＴｉｍｅ」）は、２８秒であり、オリジナルのシーケンスにおける２つの隣接するイントラフレーム間の時間距離（即ち、「ＩＦｒａｍｅＴｉｍｅ_Original」）は、５秒であり、オリジナルのビットレートシーケンスに戻るべく切り替わる時点は、４０秒となる（ＳｅｑＣｈａｎｇｅＴｉｍｅ＝５＊ｆｌｏｏｒ（２８＋１６）／５）＝４０ｓ）。従って、図８に示されているように、第２のＰＡＵＳＥ／ＰＬＡＹメッセージペアは、４０秒の時点において送信されることになり、この実施例においては、ＰＬＡＹメッセージのメッセージフィールド「Ｒａｎｇｅ」内に配置される開始点と停止点は、それぞれ２８秒及び４０秒となる。

尚、イントラフレームレートに起因し、必ずしもすべてのケースにおいてバッファを完全に充填できないことに留意されたい。例えば、先程説明した例においては、バッファを完全に充填するには、更に４秒を所要することになろう。但し、これらの式によれば、バッファの充填期間に最も近接した適切なイントラフレームを取得することができる。

別の実施例においては、ＣＲ期間の前に最後に受信されたフレームの時点において、低ビットレートのメディアシーケンス内にイントラフレームが存在していない。従って、この実施例の場合には、開始点において、低ビットレートシーケンス内にイントラフレームが存在するように、後方に、必要なフレームの数（又は、時間）だけ、再送要求の開始点を調節している。尚、この場合には、連続的な再生を保証するべく、その開始点に続く期間に属するＣＲ期間前の最後に受信されたフレームの組は、クライアント装置において無視されることになる。

本発明の別の実施例においては、先程説明した時間設定法を使用することなしに、２つの異なるビットレートシーケンス間における切り替えを実行している。この実施例においては、第１の切り替えポイント（高ビットレートシーケンスから低ビットレートシーケンスへの切り替え）を、最後に受信されたフレームによって直接的に判定し、第２の切り替えポイント（低ビットレートシーケンスから高ビットレートシーケンスへの切り替え）は、バッファを完全に充填するのに必要な時間（「充填期間」）により、直接的に判定している。従って、これらの切り替えポイントは、最終的に、イントラフレーム又はインターフレームの時点に位置することになる。そして、切り替えポイントがインターフレームの時点（例えば、Ｐフレーム）に最終的に位置した場合には、再生されるメディアに小さな予測誤差が生じることになるが、この実施例においては、バッファを完全に充填することが可能である。

切り替えを実行する更なる方法は、所謂「スイッチフレーム」を使用する方法である。異なるビットレートシーケンスにおける対応するフレーム間の「差」情報を含むフレームが存在している。この実施例においては、２つのシーケンス間におけるブリッジング及びスイッチングは、これらのフレームにより、この差情報を使用して実行される。

図９は、本発明の好適な実施例によるクライアント装置１０１を示している。このクライアント装置は、携帯無線電話ネットワークの移動局であってよい。クライアント装置１０１は、処理ユニットＭＣＵ、高周波部ＲＦ、及びユーザーインターフェイスＵＩを有している。高周波部ＲＦとユーザーインターフェイスＵＩは、処理ユニットＭＣＵに接続されている。ユーザーインターフェイスＵＩは、通常、ディスプレイ、１つ又は複数のスピーカ、及びキーボードを有しており（図示されてはいない）、ユーザーは、これらを利用して、装置１０１を使用することができる。

処理ユニットＭＣＵは、プロセッサ（図示されてはいない）、メモリ２１０、及びコンピュータソフトウェアを有している。このソフトウェアは、メモリ２１０内に保存されている。前述のクライアント装置バッファ２４０も、このメモリ２１０内に含まれている。プロセッサは、ソフトウェアに従って、サーバー１１１から送信されるストリーミングメディアの受信や、高周波部ＲＦを介したサーバー１１１への要求の送信、受信したストリーミングメディア（ビデオ及び／又はオーディオ）のバッファ２４０への書き込み及び読み取り、並びにユーザーインターフェイスＵＩのディスプレイ上における受信ストリーミングビデオの提示及び１つ又は複数のスピーカ上におけるオーディオの提示などのクライアント装置１０１の動作を制御する。バッファの適切なサイズ（単位：時間）は、例えば、最大（又は、平均）ＣＲ期間の１．５又は２倍であってよい。

ソフトウェアは、ストリーミングクライアントアプリケーション２２０（以下、これをクライアントソフトウェア２２０と呼ぶ）、ＲＴＰレイヤ、ＲＴＳＰレイヤ、ＳＤＰ（Session Description Protocol）レイヤ、ＴＣＰレイヤ（Transmission Control Protocol）、ＩＰレイヤ、及びＩＰレイアの下に位置する下位プロトコルレイヤなどの必要なプロトコルレイヤを実装するためのプロトコルスタック２３０を有している。又、このソフトウェアは、クライアントソフトウェア２２０の一部として、受信したメディアを再生するメディアプレーヤをも有している。

プロセッサは、クライアントソフトウェア２２０に基づいて、前述のＰＡＵＳＥ及びＰＬＡＹメッセージを生成し、高周波部ＲＦを介して、サーバー１１１に送信する。又、プロセッサは、クライアントソフトウェア２２０に基づいて、加速係数、バッファ充填期間、及び低ビットレートシーケンスからオリジナルのビットレートシーケンスに戻るべく切り替える適切な時点に関係する必要な計算をも実行する。

この再送要求（ＰＬＡＹメッセージ）の生成及び送信とその他の適切な動作は、モバイルクライアント装置１０１内において発生するセル再選択イベントによってトリガされる。クライアントソフトウェア２２０は、プロトコルスタック２３０の下位レイヤによって提供されるＡＰＩ（Application Programming Interface）から非同期メッセージを受信することにより、このイベントを検出することができる。或いは、この代わりに（又は、これに加えて）、バッファのレベル（即ち、クライアント装置バッファ２４０の充填度）を監視することにより、このイベントを検出することも可能である。この場合には、バッファ２４０が特定量の時間Ｘにわたってデータを受信せず（このパラメータＸは、実装に応じて、一定の値として定義可能であり、これは、セル再選択イベントが発生したことをクライアントソフトウェア２２０が理解するための閾値ある）、且つ、クライアント装置１０１が、特定の可変時間量Ｙの後に、後からデータの受信を開始した場合に（ここで、Ｙ＞Ｘであり、Ｙは、ＣＲ期間の実際の持続時間である）、クライアントは、先程説明した動作をトリガすることができる。

図１０は、本発明の好適な実施例によるストリーミングサーバー１１１を示している。このストリーミングサーバー１１１は、処理ユニットＣＰＵ、第１メモリ３１０、ＩＰネットワークインターフェイス３５０、及び第２メモリ３６０を有している。そして、第１メモリ３１０、ＩＰネットワークインターフェイス３５０、及び第２メモリ３６０は、処理ユニットＣＰＵに接続されている。

処理ユニットＣＰＵは、第１メモリ３１０内に保存されているコンピュータソフトウェアに従って、クライアント装置１０１から受信した要求の処理や、第２メモリ（ディスク）３６０内に保存されている事前に記録されたメディアストリームのＩＰネットワークインターフェイス３５０を介したクライアント装置１０１への送信などのストリーミングサーバー１１１の動作を制御する。

ソフトウェアは、ストリーミングサーバーソフトウェアアプリケーション３２０（以下においては、これをサーバーソフトウェア３２０と呼ぶ）、ＲＴＰレイヤ、ＲＴＳＰレイヤ、ＳＤＰレイヤ、ＴＣＰレイヤ、ＩＰレイア、及び下位プロトコルレイヤなどの必要なプロトコルレイヤを実装するプロトコルスタック３３０を有している。

クライアント装置１０１から送信されたＰＡＵＳＥ及びＰＬＡＹメッセージは、ＩＰネットワークインターフェイス３５０を介して受信される。そして、処理ユニットＣＰＵのプロセッサ（図示されてはいない）が、サーバーソフトウェア３２０とプロトコルスタック３３０に従ってメッセージを処理し、適切な動作を実行する。

本発明は、進行中のストリーミングセッションに対するセル再選択の影響を軽減するための手段を提供している。尚、本発明の好適な実施例によれば、再送の要求（例：ＰＬＡＹメッセージ）は、アプリケーションレイヤ上において（即ち、クライアントソフトウェアアプリケーション２２０とサーバーソフトウェアアプリケーション３２０間において）送信されることに留意されたい。尚、クライアント装置からストリーミングサーバーに対して、このアプリケーションレイヤの要求を転送する際には、ＴＣＰ（Transmission Control Protocol）上におけるＲＴＳＰ、又はその他の信頼性の高いプロトコル上におけるＲＴＳＰを使用することが好ましい。これにより、ストリーミングサーバーにおけるメッセージの受信を基本的に保証することができる。

尚、以上においては、セルの再選択は、２つの基地局間において実行されるものとして説明しているが、セルの再選択は、１つの同一の基地局の２つのセクター間において実行することも可能であることに留意されたい。又、実装に応じて、ストリーミングメディアの送信を休止させる別個のメッセージ（ＰＡＵＳＥメッセージ）が不要な場合も存在することに留意されたい。即ち、代替実施例においては、ストリーミングメディアの送信の停止とストリーミングメディアの再送の開始の両方を単一の適切なメッセージによって起動している。

又、バッファ充填の実施例に関連し、以上においては、サーバーが低ビットレートシーケンスの送信に切り替わる際に、オリジナルの伝送ビットレートが維持されるものとして説明している。しかしながら、本発明の代替実施例においては、バッファを更に高速で充填するべく、充填期間中に、オリジナルの伝送ビットレートを上回る伝送ビットレートを使用している。尚、この実施例においては、モバイルクライアント装置が大きな帯域幅を要求可能であると共に、無線アクセスネットワークにおいて大きな帯域幅が実際に利用可能であることを前提としている。

又、バッファ充填の実施例に関連し、「Ｂａｎｄｗｉｄｔｈ」ＲＴＳＰフィールド以外の手段によっても、シーケンスの帯域幅情報をストリーミングサーバー１１１に送信することが可能である（例：クライアント装置１０１に既知のビットレートにおいてエンコードされた特定のシーケンスを要求する）。この場合には、「Ｂａｎｄｗｉｄｔｈ」フィールドは使用せず、実際の既知のシーケンスのビットレートに従って、「Ｓｐｅｅｄ」及び「Ｒａｎｇｅ」フィールドを再算出することになる。

バッファ充填期間中に、ネットワーク（無線インターフェイス）の帯域幅が変化することも考えられる。クライアント装置１０１が、ビットストリームの切り替えを伴う帯域幅適合機能をサポートしている場合には、クライアント装置１０１は、ストリーミングサーバー１１１に対して帯域幅適合メッセージを送信する前に、（ＲＴＳＰＰＡＵＳＥメッセージにより）バッファの充填を休止させる。そして、帯域幅適合操作が終了したら、クライアント装置は、バッファの充填を再開し、その新しいメディアストリームのビットレートとタイミング情報に従って、「Ｂａｎｄｗｉｄｔｈ」、「Ｓｐｅｅｄ」、及び「Ｒａｎｇｅ」の値を再算出可能である。

又、バッファ充填の実施例に関連し、代替実施例においては、第２のＰＡＵＳＥ／ＰＬＡＹメッセージを送信することなしに、第１のＰＬＡＹメッセージ内に含まれている停止点情報に基づいて、オリジナルの伝送ビットレートのオリジナルメディアシーケンスの送信に戻るための切り替えをサーバーが自動的に実行していることにも留意されたい。

本発明の様々な実施例において言及した再送要求は、特定のケースにおいては、実際には送信要求であってよい。このような１つのケースも本発明の代替実施例として見なされる。この実施例においては、非常に近い将来にセルの再選択が発生することを事前に認知しているクライアント装置（１０１）が、セル再選択期間の開始前に（即ち、プレＣＲ期間中に）、ＰＡＵＳＥメッセージをストリーミングサーバー（１１１）に対して送信する。このＰＡＵＳＥメッセージの送信は、下位レイヤのＡＰＩによってクライアントソフトウェア２２０に通知されるセル再選択起動イベントによってトリガされる。このＰＡＵＳＥメッセージにより、ストリーミングサーバー１１１は、ストリーミングメディアの送信を停止する。そして、ＣＲ期間が終了すると、クライアント装置１０１は、ＰＬＡＹメッセージを送信し、ＣＲ期間の前に送信が停止された時点において送信をストリーミングサーバーに開始させることになる。尚、この間においても、クライアント装置１０１におけるストリーミングメディアの再生は停止せず、クライアント装置バッファ２４０が、セル再選択が所要する時間よりも長く（単位：時間）選択されている場合には、バッファ２４０は、セル再選択の際に完全に空にはならず、ユーザーが再生のジャンプや中断を経験することもない。又、バッファ２４０の充填度を上昇させるべく、このＰＬＡＹメッセージに、高速送信の要求を含めることも可能である。

更に別の実施例においては、モバイルクライアント装置１０１は、ＣＲ期間の前に、ストリーミングメディアの送信を停止し、ＣＲ期間の後の適切な時点において送信を再開するようにストリーミングサーバー１１１に対して要求する適切なメッセージをストリーミングサーバー１１１に送信する。このメッセージの送信は、プレＣＲ期間中において、下位レイヤのＡＰＩによってクライアントソフトウェア２２０に通知されるセル再選択起動イベントによってトリガされる。セルの再選択が所要する大体の時間に関する知識を有しているモバイルクライアント装置１０１は、再度データを受信できるようになる適切な時点を推定する。そして、モバイルクライアント装置は、ストリーミングサーバー１１１が過剰に早期に送信を再開することを防止するべく、この情報をメッセージ内に挿入する。

このメッセージの例は、次のとおりである。

ＰＬＡＹｒｔｓｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｆｏｏＲＴＳＰ／１．０
ＣＳｅｑ：７
Ｓｅｓｓｉｏｎ：３５４８３２
Ｒａｎｇｅ：ｎｐｔ＝２８．００−４０．００；ｔｉｍｅ＝１９９７０１２３Ｔ１５３６００Ｚ
Ｂａｎｄｗｉｄｔｈ：２００００
Ｓｐｅｅｄ：１．５

これは、「Ｔｉｍｅ」というヘッダフィールドを具備するＲＴＳＰＰＬＡＹメッセージである。このフィールドの値により、ストリーミングメディアの「将来」の送信の開始点をスケジューリングしている。

図１１には、（特に、バッファ充填の実施例に関連し）、次の３つの可能なメッセージ送信方法が示されている。

ケース１：第１のＰＡＵＳＥ及びＰＬＡＹメッセージは、ＣＲ期間の後に送信される。第２のＰＡＵＳＥ及びＰＬＡＹメッセージは、バッファ２４０が満杯になった際に送信される。

ケース２：第１のＰＡＵＳＥメッセージは、ＣＲ期間の前に送信される。これに関連するＰＬＡＹメッセージは、ＣＲ期間の後に送信される。第２のＰＡＵＳＥ及びＰＬＡＹメッセージは、バッファ２４０が満杯になった際に送信される。

ケース３：第１のＰＡＵＳＥメッセージは、ＣＲ期間の前に送信される。これに関連するＰＬＡＹメッセージは、ＰＡＵＳＥメッセージの後であり、且つＣＲ期間の前に、送信される。第２のＰＡＵＳＥ及びＰＬＡＹメッセージは、バッファ２４０が満杯になった際に送信される。

第１のＰＬＡＹメッセージに、閉じた「Ｒａｎｇｅ」フィールドが含まれている場合には、第２のＰＡＵＳＥメッセージの送信は不要である。

以上、本発明の特定の実装及び実施例について説明したが、本発明は、以上において提示した実施例の詳細事項（例：メッセージ名やメッセージフィールド名）に限定されるものではなく、本発明の特徴を逸脱することなしに、等価な手段を使用し、その他の実施例においても実装可能であることは、当業者に明らかである。従って、本発明の範囲を限定するものは、添付の特許請求項のみである。

メディアをストリーミングする能力を有する通信システムを示している。図１の通信システム内におけるセル再選択の状況を示している。セル再選択が所要する時間に比べて、クライアント装置のバッファが短いケースにおけるクライアント装置のバッファを示している。セル再選択が所要する時間に比べて、クライアント装置のバッファが長いケースにおけるクライアント装置のバッファを示している。図４の背景となっている状況を示す別の図である。本発明の好適な実施例における好適な動作を示している。本発明の好適な実施例を示している。本発明の好適な実施例を示している。本発明の好適な実施例によるクライアント装置を示している。本発明の好適な実施例によるストリーミングサーバーを示している。本発明の好適な実施例による３つのメッセージ送信方法を示している。

Claims

無線インターフェイス上においてストリーミングサーバー（１１１）からモバイルクライアント装置（１０１）にメディアをストリーミングする方法であって、前記ストリーミングメディアは、再生の前に前記モバイルクライアント装置（１０１）において一時ストア（２４０）内に一時的に保存され、前記方法は、
前記一時ストア（２４０）の充填度を上昇させるべく、セルの再選択のために前記モバイルクライアント装置（１０１）が受信できないストリーミングメディアを前記メディアの再生レートを上回るレートで送信するように、前記ストリーミングサーバー（１１１）に対して要求する段階を有し、
前記要求する段階は、
オリジナルのビットレートより低いビットレートでエンコードされた低ビットレートのストリーミングメディアの送信に切り替えるように要求することと、
オリジナルの伝送ビットレートに到達するべく前記低ビットレートのストリーミングメディアの伝送を加速するように要求することと、を有する方法。
無線インターフェイス上においてストリーミングサーバー（１１１）からモバイルクライアント装置（１０１）にメディアをストリーミングする方法であって、前記ストリーミングメディアは、再生の前に前記モバイルクライアント装置（１０１）において一時ストア（２４０）内に一時的に保存され、前記方法は、
前記一時ストア（２４０）の充填度を上昇させるべく、セルの再選択のために前記モバイルクライアント装置（１０１）が受信できないストリーミングメディアを前記メディアの再生レートを上回るレートで送信するように、前記ストリーミングサーバー（１１１）に対して要求する段階を有し、
前記要求する段階は、
オリジナルのビットレートより低いビットレートでエンコードされた低ビットレートのストリーミングメディアの送信に切り替えるように要求することと、
オリジナルの伝送ビットレートを上回る伝送レートで前記低ビットレートのストリーミングメディアの伝送を加速するように要求することと、を有する方法。
前記要求する段階は、
前記セルの再選択前に受信した最後のストリーミングメディアフレームの時刻に基づいて、前記低ビットレートのストリーミングメディアの送信を開始する開始点を指定することと、
前記開始点に前記一時ストアの充填期間を加算して、前記低ビットレートのストリーミングメディアの送信を停止する停止点を指定することと、をさらに含む請求項１又は２記載の方法。
前記開始点は、前記開始点において前記低ビットレートのメディアストリーミングのイントラフレームが存在するように調節され、
前記停止点は、前記停止点において前記オリジナルのビットレートのメディアストリーミングのイントラフレームが存在するように調節される、請求項３記載の方法。