(57)【要約】【課題】エア・インターフェースを介してストリーミング・サーバから移動クライアント装置に画像・音声等のメディアをパケット交換ストリーミングするための方法。【解決手段】ダウンリンク・エア・インターフェース帯域幅の変化を通知するステップと、ストリーミング・サーバ送信ビット・レートを適応させる要求を移動クライアント装置からストリーミング・サーバに送信するステップと、ストリーミング・サーバで要求を受信するステップと、要求に従ってストリーミング・サーバ送信ビット・レートを適応させるステップとで構成される方法。要求は、現在のダウンリンク・エア・インターフェース帯域幅及びストリーミング・サーバ送信ビット・レートの適応が現在のダウンリンク・エア・インターフェース帯域幅に従って実行されることをストリーミング・サーバに示す。【選択図】図１
2010136395.tif 000002
【特許請求の範囲】
【請求項１】
エア・インターフェースを介してストリーミング・サーバから移動クライアント装置にメディアをパケット交換ストリーミングするための方法であって、
ダウンリンク・エア・インターフェース帯域幅における変化を通知するステップと、
ストリーミング・サーバ送信ビット・レートを適応させるための要求を前記移動クライアント装置から前記ストリーミング・サーバに送信するステップと、
前記ストリーミング・サーバにおいて前記要求を受信するステップと、
現在のダウンリンク・エア・インターフェース帯域幅及び前記ストリーミング・サーバ送信ビット・レートの前記適応が前記現在のダウンリンク・エア・インターフェース帯域幅に従って実行されることを前記ストリーミング・サーバに示す前記要求に従って前記ストリーミング・サーバ送信ビット・レートを適応させるステップと、
で構成される方法。
【請求項２】
前記現在のダウンリンク・エア・インターフェース帯域幅は、前記移動クライアント装置がデータを受信することのできる最大ビット・レートを示す、請求項１に記載の方法。
【請求項３】
前記ストリーミング・サーバは、移動体通信ネットワークを介して前記移動クライアント装置にメディア・ストリームを送信する、請求項１に記載の方法。
【請求項４】
前記ストリーミング・サーバは、前記移動体通信ネットワークに接続されたＩＰ（インターネット・プロトコル）ベースのネットワークに対するＩＰ接続を有する、請求項３に記載の方法。
【請求項５】
前記移動体通信ネットワークは、ＧＰＲＳ（汎用パケット無線サービス）ネットワークのような移動パケット無線ネットワークである、請求項３に記載の方法。
【請求項６】
前記メディア・ストリームは、画像ストリーム、音声ストリーム、マルチメディア・ストリームの内の１つで構成される、請求項３に記載の方法。
【請求項７】
前記エア・インターフェースは、前記移動クライアント装置を前記移動体通信ネットワークに接続する、請求項３に記載の方法。
【請求項８】
前記ストリーミング・サーバ送信ビット・レートの前記適応は、第１の送信ビット・レートでの送信から前記第１の送信ビット・レートとは異なる第２の送信ビット・レートでの送信に前記ストリーミング・サーバを切替えることによって実行される、請求項１に記載の方法。
【請求項９】
前記ストリーミング・サーバ送信ビット・レートの前記適応は、第１のビット・レートで符号化される第１のメディア・ストリームの送信から前記第１のビット・レートとは異なる第２のビット・レートで符号化される第２のメディア・ストリームの送信に前記ストリーミング・サーバを切替えることによって実行される、請求項１に記載の方法。
【請求項１０】
前記メディア・ストリームは、あらかじめ記録されたメディア・ファイルの部分を形成する、請求項９に記載の方法。
【請求項１１】
前記メディア・ストリームは、ライブ・ストリーミング・メディア送信の部分を形成する、請求項９に記載の方法。
【請求項１２】
前記第１及び第２のビット・レートは、マルチレート・コーデックによって与えられる、請求項９に記載の方法。
【請求項１３】
前記現在のダウンリンク・エア・インターフェース帯域幅より高いビット・レートで符号化されるメディア・ストリームが、送信のために選択され、前記ストリーミング・サーバ送信ビット・レートは、付加的な適応手段によって前記現在のダウンリンク・エア・インターフェース帯域幅に一致するように適応される、請求項９に記載の方法。
【請求項１４】
前記付加的な適応手段は、前記ストリーミング・サーバによる動的な適応で構成される、請求項１３に記載の方法。
【請求項１５】
前記動的な適応は、前記ストリーミング・サーバ送信ビット・レートを前記現在のダウンリンク・エア・インターフェース帯域幅に適応させるために前記メディア・ストリームの一部の送信をスキップすることによる時間的適応性を用いることで構成される、請求項１４に記載の方法。
【請求項１６】
前記メディア・ストリームの一部の送信をスキップすることは、いくつかの画像フレームの送信をスキップすることで構成される、請求項１５に記載の方法。
【請求項１７】
前記ストリーミング・サーバ送信ビット・レートを適応させるために、前記現在のダウンリンク・エア・インターフェース帯域幅の隣の最低のストリーミング・サーバ送信ビット・レートが、１組の利用可能なストリーミング・サーバ送信ビット・レートから、送信のために選択される、請求項１に記載の方法。
【請求項１８】
前記移動クライアント装置及び前記ストリーミング・サーバは、継続中のストリーミング・セッションを有し、ダウンリンク・エア・インターフェース帯域幅における変化を通知する前記ステップは、前記継続中のストリーミング・セッションの間に生じる、請求項１に記載の方法。
【請求項１９】
前記ストリーミング・サーバ送信ビット・レートを適応させるための前記要求は、前記ダウンリンク・エア・インターフェース帯域幅における前記変化を通知するステップに反応して生成され送信される、請求項１に記載の方法。
【請求項２０】
前記ストリーミング・サーバ送信ビット・レートを適応させるための前記要求は、前記現在のダウンリンク・エア・インターフェース帯域幅が所定の時間持続した後でのみ送信される、請求項１に記載の方法。
【請求項２１】
前記ストリーミング・サーバ送信ビット・レートを適応させるための前記要求は、アプリケーション層の要求である、請求項１に記載の方法。
【請求項２２】
前記移動クライアント装置は、セルラー移動電話で構成される、請求項１に記載の方法。
【請求項２３】
前記現在のダウンリンク・エア・インターフェース帯域幅は、現在保証されているエア・インターフェース・ダウンリンク帯域幅を示す、請求項１に記載の方法。
【請求項２４】
ダウンリンク・エア・インターフェース帯域幅における前記変化を通知する前記ステップは、アプリケーション・プログラミング・インターフェース（ＡＰＩ）によって生じる、請求項１に記載の方法。
【請求項２５】
前記要求は、前記現在のダウンリンク・エア・インターフェース帯域幅を示すためのＢａｎｄｗｉｄｔｈフィールドのようなメッセージ・フィールドで構成される、請求項１に記載の方法。
【請求項２６】
前記メッセージ・フィールドは、メッセージ・ヘッダー・フィールドである、請求項２５に記載の方法。
【請求項２７】
ストリーミング・セッションの設定において、利用可能な異なるビット・レートのメディア・ストリームに関する情報が、前記移動クライアント装置に通信される、請求項１に記載の方法。
【請求項２８】
ストリーミング・セッションの設定において、複数のビット・レート又はそれらのいずれかを特定せずに利用可能な複数のビット・レート・ストリームが存在することが、前記クライアント装置に通信される、請求項１に記載の方法。
【請求項２９】
前記情報は、ＲＴＳＰ（リアル・タイム・ストリーミング・プロトコル）  ＤＥＳＣＲＩＢＥメッセージのＳＤＰ（セッション記述プロトコル）ボディにおいて、前記ストリーミング・サーバから前記クライアント装置に通信される、請求項２７又は２８に記載の方法。
【請求項３０】
前記要求は、ＲＴＳＰ  ＯＰＲＩＯＮＳ、ＲＴＳＰ  ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ、ＲＴＳＰ  ＰＬＡＹメッセージの内の１つにおいて送信される、請求項１に記載の方法。
【請求項３１】
前記ストリーミング・サーバ送信ビット・レートを適応させる際に、コーデックの変更が実行される、請求項１に記載の方法。
【請求項３２】
エア・インターフェースを介してストリーミング・サーバからパケット交換されるストリーミング・メディアを受信するための移動クライアント装置であって、
ダウンリンク・エア・インターフェース帯域幅における変化を通知するための手段と、
ストリーミング・サーバ送信ビット・レートを適応させるための要求であって、現在のダウンリンク・エア・インターフェース帯域幅に従って前記ストリーミング・サーバ送信ビット・レートを適応させるために前記現在のダウンリンク・エア・インターフェース帯域幅を前記ストリーミング・サーバに示すための情報を含む要求を前記ストリーミング・サーバに送信するための手段と、
で構成される移動クライアント装置。
【請求項３３】
エア・インターフェースを介して移動クライアント装置にパケット交換されるストリーミング・メディアを送信するためのストリーミング・サーバであって、
ストリーミング・サーバ送信ビット・レートを適応させるための要求であって、現在のダウンリンク・エア・インターフェース帯域幅を示す情報を含む要求を受信するための手段と、
前記現在のダウンリンク・エア・インターフェース帯域幅に従って前記ストリーミング・サーバ送信ビット・レートを適応させるための手段と、
で構成されるストリーミング・サーバ。
【請求項３４】
エア・インターフェースを介してストリーミング・サーバから移動クライアント装置にメディアをパケット交換ストリーミングするための、前記ストリーミング・サーバ及び前記移動クライアント装置で構成される、システムであって、
前記移動クライアント装置においては、
ダウンリンク・エア・インターフェース帯域幅における変化を通知するための手段と、
ストリーミング・サーバ送信ビット・レートを適応させるための要求であって、現在のダウンリンク・エア・インターフェース帯域幅を前記ストリーミング・サーバに示すための情報を含む要求を前記ストリーミング・サーバに送信するための手段と、
で構成され、
前記ストリーミング・サーバにおいては、
前記要求を受信するための手段と、
前記現在のダウンリンク・エア・インターフェース帯域幅に従って前記ストリーミング・サーバ送信ビット・レートを適応させるための手段と、
で更に構成されるシステム。
【請求項３５】
移動クライアント装置において実行可能なコンピュータ・プログラム製品であって、
前記移動クライアント装置をして、ダウンリンク・エア・インターフェース帯域幅における変化を通知せしめることと、
前記移動クライアント装置をして、ストリーミング・サーバ送信ビット・レートを適応させるための要求であって、現在のダウンリンク・エア・インターフェース帯域幅に従って前記ストリーミング・サーバ送信ビット・レートを適応させるために前記現在のダウンリンク・エア・インターフェース帯域幅を前記ストリーミング・サーバに示すための情報を含む要求を前記ストリーミング・サーバに送信せしめることと、
をするためのプログラム・コードで構成されるコンピュータ・プログラム製品。
【請求項３６】
ストリーミング・サーバにおいて実行可能なコンピュータ・プログラム製品であって、
前記ストリーミング・サーバをして、ストリーミング・サーバ送信ビット・レートを適応させるための要求であって、現在のダウンリンク・エア・インターフェース帯域幅を示す情報を含む要求を受信せしめることと、
前記ストリーミング・サーバをして、前記現在のダウンリンク・エア・インターフェース帯域幅に従って前記ストリーミング・サーバ送信ビット・レートを適応せしめることと、
をするためのプログラム・コードで構成されるコンピュータ・プログラム製品。
【請求項３７】
前記ストリーミング・サーバは、前記ストリーミング・サーバ送信ビット・レートの前記適応において用いられるＱｏＳ（サービス品質）情報を備えており、前記ＱｏＳ情報は、保証される帯域幅が前記ストリーミング・メディアに対して与えられるか否かを示す、請求項１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、エア・インターフェースを介したストリーミング・サーバから移動クライアント装置へのメディアのパケット交換ストリーミングに関する。
【背景技術】
【０００２】
マルチメディア・ストリーミングにおいて、音声付の「動画像」の列は、ストリーミング・サーバからクライアント装置へ送信される。全メディア・ファイルが再生可能となる前にクライアントのところに到着している必要のある技術とは対照的に、ストリーミング技術は、ストリーミング・サーバからクライアントへ連続的な方法でメディア（画像及び／又は音声）を送信すること、及びメディアがクライアントのところに到着するときにメディアを再生することを可能とする。
【０００３】
パケット交換ストリーミング・サービス（ＰＳＳ）は、現在、３ＧＰＰ（第３世代共同プロジェクト）によって移動環境に対して規格化されつつある。固定インターネット環境と比較して、移動環境に特有の新たな問題が生じている。これらの問題は、主に、移動システムの様々な制約による。
【０００４】
移動システムにおいては、ネットワークと移動体通信装置との間で、情報は、無線路を介して、すなわち、無線周波数チャンネル用いたエア・インターフェースを介して、転送される。エア・インターフェースは、通信に対して限られた無線リソース（限られた帯域幅）しか提供しない。従って、システムが適切に機能することを保証するためには、できる限り効率的に（無線リソースが浪費されないように）、エア・インターフェースの限られた帯域幅を利用することが望まれる。
【０００５】
メディアをストリーミング（画像及び／又は音声をストリーミング）することができる通信システムの例を図１に示す。このシステムは、ＩＰ（インターネット・プロトコル）ネットワーク１０４に接続されたストリーミング・サーバ１１１で構成される。ＩＰネットワーク１０４は、例えば、インターネット又はサービス・プロバイダ・オペレータのイントラネット（オペレータのドメインに属するイントラネット・ネットワーク）とすることができる。ＩＰネットワーク１０４は、Ｇiインターフェースを介して、移動体通信ネットワークの基幹ネットワーク１０３に接続される。移動体通信ネットワークは、また、基幹ネットワーク１０３に接続された無線アクセス・ネットワーク（ＲＡＮ）１０２を有する。無線アクセス・ネットワーク１０２は、エア・インターフェースを介した移動体通信ネットワークへのアクセスを移動体通信装置１０１に提供する。上述のアクセスは、回線交換手段（回線交換される音声又はデータ・コール）又はパケット交換手段のいずれかによって、或いはそれらの両者によって、提供することができる。以下では、エア・インターフェースを介して通信するパケット交換手段の例としてＧＰＲＳ（汎用パケット無線サービス）を用いる。
【０００６】
メディアのストリーミングは、通常、ストリーミング・サーバ１１１から移動体通信装置１０１（以後、クライアント装置１０１と称する）に、圧縮された形態で予め記録された（マルチ）メディア（画像及び／又は音声）ファイルを送信することによって実行される。メディア・コンテンツを符号化するために用いられるコーデックに依存して、ストリーミング・サーバは、クライアント装置１０１に異なるビット・レートの組でメディアを送信することができる。例として、サーバは、３つのビット・レートで符号化されたコンテンツを有することができる。これらのビット・レートは、例えば、３つの異なるコーデックによって或いは１つのマルチレート・コーデックによって生成することができる。ビット・レートが高くなるほど受信した画像及び音声の品質が良好になるのは、当然のことである。しかしながら、より高いビット・レートは、限られたエア・インターフェース帯域幅のより多くを費やす。
【０００７】
規格化されたＧＰＲＳリリース‘９７ネットワーク及びＧＰＲＳリリース‘９９（ＥＧＰＲＳ、拡張ＧＰＲＳ）ネットワークは、エア・インターフェースを介した通信に対してＴＤＭＡ（時分割多重アクセス）タイム・スロットを用いる。誤り訂正に対して用いられるビットの量とともにタイム・スロットの数が、接続のペイロード（payload）に対する有効帯域幅を規定する。従って、限られた無線リソースを効率的に利用可能とするために、ＧＰＲＳリリース‘９７及びリリース‘９９の両ネットワークに対して規定された、様々なタイム・スロットと符号化方式（誤り訂正）の組み合わせが存在する。
【０００８】
例えば、ＧＰＲＳリリース‘９７ネットワークは、（３タイム・スロットまでに対して）以下のタイム・スロット及び符号化方式の実現性を与える。
【０００９】
【表１】
2010136395.tif 000003
【００１０】
タイム・スロット（ＴＳ）及び符号化方式（ＣＳ）の設定に依存する、ペイロード（ユーザ・データ、有効なデータ）に対して利用可能な有効エア・インターフェース・ダウンリンク帯域幅（すなわち、ビット・レート）を、この表は示している。例えば、用いる符号化方式がＣＳ−１であり、用いるタイム・スロットの設定がＴＳ２＋１（２タイム・スロットがダウンリンク方向（ＲＡＮ−＞クライアント装置）に用いられ、１タイム・スロットがアップリンク方向（クライアント装置−＞ＲＡＮ）に用いられる）設定においては、利用可能なダウンリンク帯域幅は、１８．１ｋｂｐｓである。これは、実際に、例えばストリーミング（マルチ）メディア等のペイロードに対して利用可能な有効帯域幅である。ＧＰＲＳに関しては、一般的用語である無線アクセス・ネットワーク（ＲＡＮ）は、基地（送信機）局（ＢＴＳ）及び基地局制御装置（ＢＳＣ）で構成されると考えられる。
【００１１】
同様に、ＧＰＲＳリリース‘９９ネットワークは、（２タイム・スロットまでに対して）以下のタイム・スロット及び符号化方式の実現性を与える。
【００１２】
【表２】
2010136395.tif 000004
【００１３】
タイム・スロット（ＴＳ）及び符号化方式（ＭＣＳ（変調及び符号化の方式））の設定に依存する、ペイロードに対して利用可能な有効エア・インターフェース・ダウンリンク帯域幅を、やはり、この表は示している。例えば、用いる符号化方式がＭＣＳ−６であり、用いるタイム・スロットの設定がＴＳ２＋２（２タイム・スロットがダウンリンク方向に用いられ、２タイム・スロットがアップリンク方向に用いられる）設定においては、利用可能なダウンリンク帯域幅は、５９．２ｋｂｐｓである。
【００１４】
ストリーミング・メディアに対して利用可能なエア・インターフェース・ダウンリンク帯域幅（すなわち、ストリーミングに対して利用可能なエア・インターフェースダウンリンク・ビット・レート）は、ストリーミング・セッションの間に大幅に変化することがあることに着目されたい。クライアント装置１０１において受信されるストリーミング・メディアの品質が変化するエア・インターフェース状態（悪い無線リンク品質）によって劣化する場合には、無線アクセス・ネットワーク１０２は、例えば、ストリーミング・セッションの間にエア・インターフェース誤り予防を増加させる必要がある。それとは別に、又はそれに加えて、無線アクセス・ネットワーク（ＧＰＲＳ）は、無線アクセス・ネットワークにおいて変化する負荷状態によってタイム・スロットの設定を変更しなければならないこともある。
【００１５】
エア・インターフェース帯域幅は、サーバ帯域幅（すなわち、サーバがストリーミング・メディアを送信するビット・レート）とは異なる概念であることに着目されたい。
【００１６】
ストリーミング・セッションに対する元々のエア・インターフェース帯域幅が５９．２ｋｂｐｓ（ＧＰＲＳリリース‘９９：ＭＣＳ−６＆ＴＳ  ２＋２）である例を考えると、ストリーミング・セッションの設定において、ストリーミング・サーバ１１１は、ビット・レート５９ｋｂｐｓで送信することが認められる。ストリーミング・セッションの間に、無線アクセス・ネットワーク１０２は、ＭＣＳ−６からＭＣＳ−５に変化したエア・インターフェース状態により、エア・インターフェース誤り予防を高める必要がある。この結果、新しいタイム・スロットと符号化方式の組み合わせ、すなわちＭＣＳ−５  ＆  ＴＳ  ２＋２が生じる。この変化の後、利用可能なエア・インターフェース帯域幅は、４４．８ｋｂｐｓになる。エア・インターフェースは、５９ｋｂｐｓのサーバ送信ビット・レートよりかなり低い４４．８ｋｂｐｓのビット・レートを高々維持できるだけなので、ストリーミング・サーバが５９ｋｂｐｓのビット・レートで送信を続けた場合は、大きな遅延及びネットワーク・バッファのオーバーフローによるパケットの損失につながることになろう。最終的にストリーミング・セッションが失われることさえ起こり得る。
【００１７】
この問題を克服するために、Ericssonは、以下の出版物で一連の解決策を提案した。
-Ericsson, Improved Session Setup and Bandwidth Adaptation, 3GPP TSG-SA WG4 Meeting #17, Tdoc S4-010349, June 4-8, 2001, Naantali, Finland.
-Ericsson, Improved Session Setup and Bandwidth Adaptation, 3GPP TSG-SA WG4 Meeting #18, Tdoc S4-(01)0477, September 3-7, 2001, Erlangen, Germany.
-Ericsson, Proposal for Bandwidth Selection in PSS, 3GPP TSG-SA WG4 Meeting #22, Tdoc S4-(02)0407, July 22-26, 2002, Tampere, Finland.
【００１８】
提案された解決策によれば、ストリーミング・サーバ１１１がストリーミング・メディアを送信することのできる可能なビット・レートが、予め、クライアント装置１０１に通信される。サーバ１１１又はクライアント１０１は、アクティブ・セッションの間に変化したネットワーク状態に気付くことができる。サーバ１１１が変化したネットワーク状態に気付く場合には、サーバ１１１は、ビット・ストリームを切替えることができる（このことは、サーバ１１１が第１のビット・レートでの送信から別のビット・レートでの送信に切替われるように理解される）。クライアント１０１が変化したネットワーク状態に気付く場合には、クライアント１０１は、特定のメッセージをサーバ１１１に送信することによって、現在のビット・ストリームと（クライアント１０１が知っている）別のビット・ストリームとの間におけるビット・ストリーム切替えを要求することができる。サーバは、このとき、ビット・ストリーム切替えに対する要求を受け入れるか又は無視するかのいずれかを実行することができる。
【００１９】
前述の例において、クライアント装置１０１が符号化方式をＭＣＳ−６からＭＣＳ−５に変化させた後で、クライアント装置１０１は、サーバが異なるビット・レートでの送信に切替えるように要求する、サーバ１１１への要求を送信すべきである。変化後の利用可能なエア・インターフェース帯域幅は、４４．８ｋｂｐｓなので、クライアントは、場合によっては例えば４４ｋｂｐｓ等の、４４．８ｋｂｐｓの隣の最低のビット・レートでサーバが送信するように要求する傾向が最も高くなろう。
【００２０】
４４．８ｋｂｐｓに近い代わりのビット・ストリームが存在する場合には、この解決策は良い解決策となり得るが、４４．８ｋｂｐｓの隣の最低のビット・レートが、例えば３０ｋｂｐｓ等のように、かなり離れている場合には、状況はより悪くなる。この場合、サーバ１１１が３０ｋｂｐｓで送信を開始すると、エア・インターフェース帯域幅のほぼ１５ｋｂｐｓが浪費される（ストリーミング・メディアに対して利用することができない）。マルチメディア・ストリーミングにおいて、理論的に可能なビット・レートよりほぼ１５ｋｂｐｓ低いビット・レートを用いることは、クライアント装置１０１において受信される画像及び／又は音声の品質に悪影響を与える可能性がかなり高くなることに着目されたい。
【００２１】
以前の表におけるＧＰＲＳ無線ベアラに関して示したように、エア・インターフェースに対して規定された多くの異なるビット・レートが存在するので、ストリーミング・サーバ１１１が全ての相当するビット・レートでストリーミング・メディアを符号化する可能性は非常に低い。従って、前段落に示したシナリオは、かなり現実的となり得る。その結果、利用可能な帯域幅を多大に浪費せずにエア・インターフェース帯域幅の変化に対処するための新しい解決策に対する要請が存在する。
【先行技術文献】
【非特許文献】
【００２２】
【非特許文献１】Ericsson, Improved Session Setup and Bandwidth Adaptation, 3GPP TSG-SA WG4 Meeting #17, Tdoc S4-010349, June 4-8, 2001, Naantali, Finland.
【非特許文献２】Ericsson, Improved Session Setup and Bandwidth Adaptation, 3GPP TSG-SA WG4 Meeting #18, Tdoc S4-(01)0477, September 3-7, 2001, Erlangen, Germany.
【非特許文献３】Ericsson, Proposal for Bandwidth Selection in PSS, 3GPP TSG-SA WG4 Meeting #22, Tdoc S4-(02)0407, July 22-26, 2002, Tampere, Finland.
【発明の概要】
【００２３】
エア・インターフェース帯域幅の変化により良く対処するために、前述の方法を改良することが、本発明の目的である。
【００２４】
本発明の第１の態様によれば、
エア・インターフェースを介してストリーミング・サーバから移動クライアント装置にメディアをパケット交換ストリーミングするための方法であって、
ダウンリンク・エア・インターフェース帯域幅における変化を通知するステップと、
ストリーミング・サーバ送信ビット・レートを適応させるための要求を前記移動クライアント装置から前記ストリーミング・サーバに送信するステップと、
前記ストリーミング・サーバにおいて前記要求を受信するステップと、
現在のダウンリンク・エア・インターフェース帯域幅及び前記ストリーミング・サーバ送信ビット・レートの前記適応が前記現在のダウンリンク・エア・インターフェース帯域幅に従って実行されることを前記ストリーミング・サーバに示す前記要求に従って前記ストリーミング・サーバ送信ビット・レートを適応させるステップと、
で構成される方法が提供される。
【００２５】
メディアという用語は、画像又は音声又は静止画像のような別のメディア、又はそれらの任意の組み合わせ、すなわちマルチメディアのいずれかを意味すると考える。
【００２６】
クライアントがストリーミング・サーバに特定のビット・レートで送信するように要求し、ストリーミング・サーバがクライアント装置に盲目的に従うか又は要求を無視するかのいずれかであった従来技術の解決策とは対照的に、本発明は、ストリーミング・サーバに対する現在のダウンリンク・エア・インターフェース帯域幅の送信を可能とし、その結果、サーバは、その送信ビット・レートを最適に適応させることができる。
【００２７】
従来技術の解決策は、ストリーミング・サーバの動的な適応機能に依存しないが、本発明の実施形態は、例えばいくつかの画像フレームの送信をスキップすることによって、時間的適応性を用いることによりサーバ送信ビット・レートをエア・インターフェース帯域幅に適応させるためのサーバの動的な適応機能をストリーミング・サーバが用いることができるようにしている。この実施形態において、ストリーミング・サーバは、ストリーミング・セッションの間により良いＱｏＳを得るために、クライアントと協力することができるようにしている。
【００２８】
本発明の第２の態様によれば、
エア・インターフェースを介してストリーミング・サーバからパケット交換されるストリーミング・メディアを受信するための移動クライアント装置であって、
ダウンリンク・エア・インターフェース帯域幅における変化を通知するための手段と、
ストリーミング・サーバ送信ビット・レートを適応させるための要求であって、現在のダウンリンク・エア・インターフェース帯域幅に従って前記ストリーミング・サーバ送信ビット・レートを適応させるために前記現在のダウンリンク・エア・インターフェース帯域幅を前記ストリーミング・サーバに示すための情報を含む要求を前記ストリーミング・サーバに送信するための手段と、
で構成される装置が提供される。
【００２９】
本発明の第３の態様によれば、
エア・インターフェースを介して移動クライアント装置にパケット交換されるストリーミング・メディアを送信するためのストリーミング・サーバであって、
ストリーミング・サーバ送信ビット・レートを適応させるための要求であって、現在のダウンリンク・エア・インターフェース帯域幅を示す情報を含む要求を受信するための手段と、
前記現在のダウンリンク・エア・インターフェース帯域幅に従って前記ストリーミング・サーバ送信ビット・レートを適応させるための手段と、
で構成されるストリーミング・サーバが提供される。
【００３０】
本発明の第４の態様によれば、
エア・インターフェースを介してストリーミング・サーバから移動クライアント装置にメディアをパケット交換ストリーミングするための、前記ストリーミング・サーバ及び前記移動クライアント装置で構成される、システムであって、
前記移動クライアント装置においては、
ダウンリンク・エア・インターフェース帯域幅における変化を通知するための手段と、
ストリーミング・サーバ送信ビット・レートを適応させるための要求であって、現在のダウンリンク・エア・インターフェース帯域幅を前記ストリーミング・サーバに示すための情報を含む要求を前記ストリーミング・サーバに送信するための手段と、
で構成され、
前記ストリーミング・サーバにおいては、
前記要求を受信するための手段と、
前記現在のダウンリンク・エア・インターフェース帯域幅に従って前記ストリーミング・サーバ送信ビット・レートを適応させるための手段と、
で更に構成されるシステムが提供される。
【００３１】
本発明の第５の態様によれば、
移動クライアント装置において実行可能なコンピュータ・プログラム製品であって、
前記移動クライアント装置をして、ダウンリンク・エア・インターフェース帯域幅における変化を通知せしめることと、
前記移動クライアント装置をして、ストリーミング・サーバ送信ビット・レートを適応させるための要求であって、現在のダウンリンク・エア・インターフェース帯域幅に従って前記ストリーミング・サーバ送信ビット・レートを適応させるために前記現在のダウンリンク・エア・インターフェース帯域幅を前記ストリーミング・サーバに示すための情報を含む要求を前記ストリーミング・サーバに送信せしめることと、
をするためのプログラム・コードで構成される製品が提供される。
【００３２】
本発明の第６の態様によれば、
ストリーミング・サーバにおいて実行可能なコンピュータ・プログラム製品であって、
前記ストリーミング・サーバをして、ストリーミング・サーバ送信ビット・レートを適応させるための要求であって、現在のダウンリンク・エア・インターフェース帯域幅を示す情報を含む要求を受信せしめることと、
前記ストリーミング・サーバをして、前記現在のダウンリンク・エア・インターフェース帯域幅に従って前記ストリーミング・サーバ送信ビット・レートを適応せしめることと、
をするためのプログラム・コードで構成される製品が提供される。
【００３３】
本発明の更に別の態様によれば、
エア・インターフェースを介してストリーミング・サーバから移動クライアント装置にメディアをパケット交換ストリーミングするための方法であって、
前記ストリーミング・サーバに現在のダウンリンク・エア・インターフェース帯域幅を示すステップと、
前記現在のダウンリンク・エア・インターフェース帯域幅に従ってストリーミング・サーバ送信ビット・レートを適応させるステップと、
で構成される方法が提供される。
【００３４】
従属請求項は、本発明の望ましい実施形態を含む。本発明の特定の態様に関連する従属請求項に含まれる対象は、本発明の別の態様にも適用可能である。
【図面の簡単な説明】
【００３５】
例を目的として添付の図面を参照し、本発明の実施形態をここに記載する。
【図１】メディアをストリーミングすることのできる通信システムを示す図である。
【図２】本発明の望ましい実施形態に従うクライアント装置を示す図である。
【図３】本発明の望ましい実施形態に従うストリーミング・サーバを示す図である。
【発明を実施するための形態】
【００３６】
図１は、既に前述した。しかしながら、図１に示したシステムは、本発明の望ましい実施形態においても用いることができる。それ故、このシステムは、ＩＰネットワーク１０４に接続されたストリーミング・サーバ１１１で構成される。ＩＰネットワーク１０４は、例えば、インターネット又はサービス・プロバイダ・オペレータのイントラネット等とすることができる。ＩＰネットワーク１０４は、Ｇiインターフェースを介して、移動体通信ネットワークの基幹ネットワーク１０３に接続される。移動体通信ネットワークは、また、基幹ネットワーク１０３に接続された無線アクセス・ネットワーク（ＲＡＮ）１０２を有する。無線アクセス・ネットワーク１０２は、エア・インターフェースを介した移動体通信ネットワークへのアクセスを移動体通信装置１０１に提供する。上述のアクセスは、回線交換手段（回線交換される音声又はデータ・コール）又はパケット交換手段のいずれかによって、或いはそれらの両者によって、提供することができる。以下では、エア・インターフェースを介して通信するためのパケット交換手段の例としてＧＰＲＳ（汎用パケット無線サービス）を用いる。
【００３７】
前述の移動体通信ネットワークは、例えば、「第２．５世代の」ＧＰＲＳ又はＥＧＰＲＳのネットワーク或いは第３世代セルラー移動体通信ネットワークとすることができる。
【００３８】
本発明の望ましい実施形態において、ストリーミング・セッションが、クライアント装置１０１とストリーミング・サーバ１１１との間で開始される。ＲＴＳＰ（リアル・タイム・ストリーミング・プロトコル）が、ストリーミング・セッションの設定において用いられる。一旦セッションが確立すると、ＲＴＰ（リアル・タイム転送プロトコル）又は別のプロトコルに従って、ストリーミング自体を実行することができる（すなわち、メディア・フローを送信することができる）。しかしながら、確立されたセッションに変更をなすのが望ましい場合には、これは、再び、ＲＴＳＰを用いることによって実行される。
【００３９】
ストリーミング・セッションの設定において、ストリーミング・セッションにおいて用いるのに可能なビット・レートを、ストリーミング・サーバ１１１からクライアント１０１に通信することができる。これは、サーバ１１１からクライアント１０１に送信されるＲＴＳＰ  ＤＥＳＣＲＩＢＥメッセージのメッセージ・ボディにおいて実行することができる。メッセージ・ボディは、ＳＤＰ（セッション記述プロトコル）プロトコルを用いて形成することができる。そのようなＳＤＰボディの一例（画像部のみを示す）は、以下のようなものである。
m=video 0 RTP/AVP 98
b=AS:40
a=rtpmap:98 H263-2000/90000
a=control: rtsp://example.com/foo /track_id=1
a=fmtp:98 profile=0; level=10; bw=18,27,40
【００４０】
このＳＤＰボディにおいて、示した最終属性行の終了部は、マルチレート・コーデックの利用可能な帯域幅を示しており、これらは、１８ｋｂｐｓ、２７ｋｂｐｓ、及び４０ｋｂｐｓである。ＳＤＰボディのその他のフィールドは、一般的に規格化され、そのようなものとして知られている。帯域幅行ｂは、最初に用いられるデフォルト帯域幅、すなわち４０ｋｂｐｓを示す。
【００４１】
これとは別に、利用可能な複数のビット・レートがそれらのいずれかを指定することなく存在することを、サーバ１１１からクライアント１０１に通信することができる。そのようなＳＤＰボディの一例（画像部のみを示す）は、以下のようなものである。
m=video 0 RTP/AVP 98
b=AS:40
a=rtpmap:98 H263-2000/90000
a=control: rtsp://example.com/foo /track_id=1
a=fmtp:98 profile=0; level=10; multi-bw
【００４２】
このＳＤＰボディにおいて、示した最終属性行の終了部は、利用可能なマルチレート・コーデックの複数の帯域幅が存在することを示しているが、どの帯域幅かは示していない。ＳＤＰボディのその他のフィールドは、一般的に規格化され、そのようなものとして知られている。帯域幅行ｂは、最初に用いられるデフォルト帯域幅、すなわち４０ｋｂｐｓを示す。
【００４３】
本発明の望ましい実施形態は、クライアント１０１がストリーミング・メディアに対する利用可能なエア・インターフェース・ダウンリンク帯域幅における変化を監視する、クライアント・サーバ・ベースの方法を提示する。例えば、タイム・スロット構成又は符号化方式（又は変調及び符号化の方式）における変化により、利用可能な帯域幅が変化する場合には、クライアント１０１は、利用可能な帯域幅の変化を検出し、ストリーミング・サーバ１１１に対してサーバ帯域幅を適応させるように要求する。「サーバ帯域幅」と言う用語は、サーバがストリーミング・メディアを送信する送信ビット・レートを意味する。
【００４４】
本明細書の導入部に記載した従来技術の解決策に反して、本発明の望ましい実施形態によれば、クライアントは、サーバ１１１に対して特定のビット・レートでの送信に切替えるように要求するのではなく、サーバに現在のエア・インターフェース帯域幅（すなわち、クライアントがストリーミング・メディアを受信することのできる最大ビット・レート）を知らせて、どの送信ビット・レートに切替えるべきかをその情報に基づいてサーバ１１１に決定させる。換言すると、クライアント１０１は、サーバ１１１に対して帯域幅適応を実行するように要求し、開始点としての現在のダウンリンク帯域幅をサーバ１１１に与える。
【００４５】
この要求は、ＲＴＳＰ  ＯＰＴＩＯＮＳ又はＲＴＳＰ  ＳＥＴ＿ＰＡＲＡＭＥＴＥＲのメッセージを用いて実行することができる。これらのメッセージは、クライアント１０１及びサーバ１１１において実施され理解されるべき１つの随意的フィールドであるＢａｎｄｗｉｄｔｈを要求する。Ｂａｎｄｗｉｄｔｈというフィールドは、ＲＦＣ２３２６（リアル・タイム・ストリーミング・プロトコル）という規格におけるＩＥＴＦ（インターネット・エンジニアリング・タスク・フォース）によって既に指定されている。
【００４６】
クライアント１０１からサーバ１１１に送信されるべき、かかるＯＰＴＩＯＮＳメッセージの一例は、以下のようなものである。
OPTIONS rtsp://example.com/foo RTSP/1.0
Cseq: 421
Content-length: 17
Content-type: text/parameters
Bandwidth: 27000
【００４７】
‘Ｂａｎｄｗｉｄｔｈ’という新しいフィールドは、現在の利用可能なエア・インターフェース・ダウンリンク帯域幅を示している。ＯＰＴＩＯＮＳメッセージのその他のフィールドは、一般的に規格化され、そのようなものとして知られている。
【００４８】
クライアント１０１からサーバ１１１に送信されるべきＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージの一例は、以下のようなものである。
SET_PARAMETER rtsp://example.com/foo RTSP/1.0
Cseq: 421
Content-length: 17
Content-type: text/parameters
Bandwidth: 27000
【００４９】
やはり、‘Ｂａｎｄｗｉｄｔｈ’というフィールドは、現在の利用可能なエア・インターフェース・ダウンリンク帯域幅を示している。ＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージのその他のフィールドは、一般的に規格化され、そのようなものとして知られている。
【００５０】
ＯＰＴＩＯＮＳ又はＳＥＴ＿ＰＡＲＡＭＥＴＥＲのメッセージを受信すると、ストリーミング・サーバ１１１は、そのメッセージに従って動作する。サーバ１１１は、（帯域幅フィールド内の）メッセージにおいて、クライアントがストリーミング・メディアを受信することのできる（実際の）現在の最大ビット・レートを入手するので、サーバは、送信ビット・レートをエア・インターフェース帯域幅に最適に適応させるために、帯域幅適応を実行する。サーバ１１１は、サーバが特定のビット・レートで送信することへのクライアントの要求を盲目的に受け入れる（実行する）か又は無視するかのいずれかを行う、従来技術の帯域幅適応技術に、もはや限定されない。しかし、サーバは、現在の帯域幅を知っているので、サーバは、それとは別に又はそれに加えて、別の帯域幅適応技術を用いることもできる。
【００５１】
例えば、サーバが５９ｋｂｐｓ、５０ｋｂｐｓ、及び３０ｋｂｐｓのビット・レートで符号化されたコンテンツを有しており、利用可能なエア・インターフェース帯域幅が突然５９．２ｋｂｐｓから４４．８ｋｂｐｓに落ちる場合、サーバ１１１は、実際のエア・インターフェース帯域幅を知っているので、（従来技術の場合であれば新しいビット・レートとなっていた）３０ｋｂｐｓの新しい送信ビット・レートを選択する代わりに、新しい送信ビット・レート５０ｋｂｐｓを選択し、更に、送信ビット・レートを５０ｋｂｐｓから正確に４４．８ｋｂｐｓまで又は４４．８ｋｂｐｓの近くまで下げる別の帯域幅適応技術を用いることができる。上述の別の帯域適応技術は、例えば画像ストリームに関しては、いくつかのフレーム（画像）の送信をスキップすることによる時間的適応性を用いることとすることができる。いくつかのフレームの送信をスキップすることによって、画像品質を多大に劣化させることなく、有効サーバ送信レートを５０ｋｂｐｓから４４．８ｋｂｐｓに下げることができる。少なくとも画像品質は、（従来技術の場合であれば新しいビット・レートとなっていた）３０ｋｂｐｓのビット・レートで送信するのと比較してかなり良好なままとなろう。このように、本発明の望ましい実施形態によれば、従来技術と比較して画像品質を改善することができ、かつ、より効率的なエア・インターフェースの利用が可能となる。
【００５２】
従来技術に反して、本発明の望ましい実施形態において、クライアントは、利用可能な個々のサーバのビット・レートを必ずしも知っている必要はないことに着目されたい。これは、例えば、利用可能な複数のビット・レートのいずれかを指定することなくそれらのレートが存在することを単に通信するだけであった、前述のＲＴＳＰ  ＤＥＳＣＲＩＢＥメッセージが用いられた場合である。本発明の望ましい実施形態によれば、クライアント装置１０１は、（サーバが特定のビット・レートでの送信を開始するように要求する代わりに）サーバのビット・レートを適応させる要求と共に現在のダウンリンク・エア・インターフェース帯域幅のみをサーバ１１１に対して送信してサーバに決定をさせるので、問題は生じない。実際のダウンリンク・エア・インターフェース帯域幅を知っているので、サーバは、最適なビット・ストリーム選択肢（すなわち、（必要ならば）付加的な帯域幅適応技術と共に、最適なビット・レート・ストリームの可能性）を単純に選択する。
【００５３】
既に前述したように、最適な選択肢は、サーバ１１１によってサポートされる１組のビット・レートから、実際の利用可能なエア・インターフェース帯域幅の隣の最低のビット・レートを選択するか、又は実際の利用可能なエア・インターフェース帯域幅よりわずかに高いビット・レートを選択するが、サーバの送信ビット・レートを実際の利用可能なエア・インターフェース帯域幅に適応させるように（いくつかのフレームの送信をスキップする等の）付加的な帯域幅適応技術を用いることとすることができる。
【００５４】
図２は、本発明の望ましい実施形態に従うクライアント装置１０１を示す。クライアント装置は、セルラー無線電話ネットワークの移動局とすることができる。クライアント装置１０１は、処理装置ＭＣＵ、無線周波数部ＲＦ、及びユーザ・インターフェースＵＩで構成される。無線周波数部ＲＦ及びユーザ・インターフェースＵＩは、処理装置ＭＣＵに接続される。ユーザ・インターフェースＵＩは、通常、ディスプレイ、スピーカ、及び、キーボード（図示せず）で構成され、これらを用いて、ユーザは、装置１０１を用いることができる。
【００５５】
処理装置ＭＣＵは、プロセッサ（図示せず）、メモリ２１０及びコンピュータ・ソフトウェアで構成される。ソフトウェアは、メモリ２１０に記憶されている。プロセッサは、ソフトウェアに従って、無線周波数部ＲＦを介したサーバ１１１からのメッセージ（例えば、ＲＴＳＰ  ＤＥＳＣＲＩＢＥ）の受信及びサーバ１１１への要求（例えば、ＯＰＴＩＯＮＳ、ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ）の送信、受信したストリーミング・メディアのユーザ・インターフェースＵＩ上への表示、及びユーザ・インターフェースＵＩのキーボードから受け取った入力の読み込み等の、クライアント装置１０１の動作を制御する。
【００５６】
ソフトウェアは、ストリーミング・クライアント・ソフトウェア・アプリケーション２２０（以後、クライアント・ソフトウェア２２０と称する）、ＲＴＰ層、ＲＴＳＰ層、ＳＤＰ層、ＴＣＰ（送信制御プロトコル）層、ＩＰ層、及びＩＰ層の下のＧＰＲＳプロトコル層、及びその他のより低い層等の必要なプロトコル層を実現するためのプロトコル・スタック２３０で構成される。更に、ソフトウェアは、クライアント装置１０１の無線周波数部ＲＦを介してストリーミング・サーバ１１１から受信したストリーミング・メディアをクライアント装置のプレーヤ（図示せず）で再生する前に一時的に記憶しておくバッファ２４０を実現するための手段で構成される。
【００５７】
クライアント・ソフトウェア２２０は、より低い層のアプリケーション・プログラミング・インターフェース（ＡＰＩ、図示せず）を介して、プロトコル・スタック２３０のより低い層から帯域幅の情報を受け取ることができる。例えば、ＧＰＲＳ電話は、瞬間のタイム・スロット構成及び誤り訂正符号化方式をより低い層からアプリケーション層へ信号伝達することができる。この帯域幅の情報に基づいて、元々アプリケーション層に存在しているクライアント・ソフトウェア２２０は、現在の利用可能なエア・インターフェース・ダウンリンク帯域幅を計算することができる。
【００５８】
ＵＭＴＳ（ユニバーサル移動体通信システム）ネットワークの状況においては、現在の利用可能なエア・インターフェース・ダウンリンク帯域幅を決定する際に、ＱｏＳ（サービス品質）特性の保証されたビット・レート・パラメータを用いることができる（このことは、かかるパラメータが与えられるその他のネットワークにおいても適用可能である）。更に、現在の利用可能なエア・インターフェース・ダウンリンク帯域幅は、現在「保証された」エア・インターフェース・ダウンリンク帯域幅を意味することができる。これらの場合においては、ＰＤＰ（パケット・データ・プロトコル）状況の修正後に（又は、ＰＤＰ状況の最初の起動後に）、クライアント・ソフトウェア２２０は、送信ビット・レート適応のために（与えられた）保証されたビット・レートをサーバに信号伝達することができる。
【００５９】
ＱｏＳ特性における保証されたビット・レート・パラメータがいつ利用不可能であろうとも、クライアント・ソフトウェア２２０は、現在の利用可能なエア・インターフェース・ダウンリンク帯域幅を見積もるために、内部アルゴリズム又はその他の指定されない手段を用いることができる。
【００６０】
望ましい実施形態において、クライアント・ソフトウェア２２０は、帯域幅の情報を一定の間隔でＡＰＩを介して受け取り、前述の現在のエア・インターフェース帯域幅を計算し、その帯域幅の値を前に記憶された帯域幅の値と比較し、その比較に基づいて、サーバ・ビット・レートを適応させる新たな要求を送信すべきか否かに関する決定を行う。ストリーミング・クライアント・ソフトウェア２２０は、また、現在の帯域幅の値をメモリ２１０に記憶して、それは、クライアント・ソフトウェアがＡＰＩを介して帯域幅の情報を次回に受け取るときに比較がなされる、前に記憶された帯域幅の値となる。
【００６１】
より低い層のＡＰＩから帯域幅の情報における変化を受け取るときに、クライアント・ソフトウェア２２０が実行することのできるアルゴリズムとして、上述のことを表すことができる。クライアント・ソフトウェア２２０は、帯域幅の情報を一定の間隔でポーリングする。
【００６２】
そのアルゴリズムは、以下のように表すことができる。
If (Current_Bandwidth ≠ Previous_Bandwidth)｛
Start timer Bandwidth_change_timer;
If (Bandwidth_change_timer > k seconds)
Send OPTIONS or SET_PARAMETER message with Bandwidth field.
｝
【００６３】
このアルゴリズムにおいては、現在の帯域幅の値は、アルゴリズムが起動される前に利用可能な帯域幅を現す、前に記憶された帯域幅の値と比較される。２つの値が異なる場合には、２つの可能性が存在する。
１）現在の帯域幅＜前の帯域幅。これは、帯域幅減少の状況である。
２）現在の帯域幅＞前の帯域幅。これは、帯域幅増加の状況である。
【００６４】
状況１及び状況２のいずれにおいても、動作が起こされ、ＯＰＴＩＯＮＳ又はＳＥＴ＿ＰＡＲＡＭＥＴＥＲのメッセージがクライアント１０１からサーバ１１１に送信される。送信すべきメッセージは、（既に前に示したように）ＲＴＳＰプロトコルに従ってクライアント・ソフトウェア２２０によって生成され、クライアント装置１０１の無線周波数部ＲＦを介してサーバ１１１に送信される。
【００６５】
帯域幅は、非常に頻繁に変化し得る。短い時間内における過度に多くのメッセージ送信及びその結果生じる不必要なサーバの動作を避けるために、タイマー（Ｂａｎｄｗｉｄｔｈ＿ｃｈａｎｇｅ＿ｔｉｍｅｒ）が、認知された帯域幅の変化の際に始動される。現在の帯域幅の値（Ｃｕｒｒｅｎｔ＿Ｂａｎｄｗｉｄｔｈ）が所定の適当な量の時間、すなわちｋ秒間持続して始めて、ＯＰＴＩＯＮＳ又はＳＥＴ＿ＰＡＲＡＭＥＴＥＲのメッセージが送信される。適当な量の時間は、例えば、１又は２秒とすることができる。
【００６６】
図３は、本発明の望ましい実施形態に従うストリーミング・サーバ１１１を示す。ストリーミング・サーバ１１１は、中央演算処理装置ＣＰＵ、第１のメモリ３１０、ＩＰネットワーク・インターフェース３５０、及び第２のメモリ３６０で構成される。第１のメモリ３１０、ＩＰネットワーク・インターフェース３５０、及び第２のメモリ３６０は、中央演算処理装置ＣＰＵに接続される。
【００６７】
中央演算処理装置ＣＰＵは、第１のメモリ３１０に記憶されているコンピュータ・ソフトウェアに従って、クライアント装置１０１から受信した要求の処理、及び第２のメモリ（ディスク）３６０に記憶されている画像及び／又は音声のストリームのＩＰネットワーク・インターフェース３５０を介したクライアント装置１０１への送信等の、ストリーミング・サーバ１１１の動作を制御する。
【００６８】
ソフトウェアは、ストリーミング・サーバ・ソフトウェア・アプリケーション３２０（以後、サーバ・ソフトウェア３２０と称する）、ＲＴＰ層、ＲＴＳＰ層、ＳＤＰ層、ＴＣＰ層、ＩＰ層、及びより低いプロトコル層等の必要なプロトコル層を実現するためのプロトコル・スタック３３０で構成される。
【００６９】
サーバ・ソフトウェア３２０は、前述のＲＴＳＰ  ＤＥＳＣＲＩＢＥメッセージを生成し、このメッセージ内で、ストリーミング・セッションにおいて用いるべき可能なビット・レートをストリーミング・サーバ１１１からクライアント１０１に通信することができる。メッセージは、ＩＰネットワーク・インターフェース３５０を介して送信される。更に、クライアント装置１０１がサーバ１１１にその送信ビット・レートを適応させるように要求する手段であるＯＰＴＩＯＮＳ又はＳＥＴ＿ＰＡＲＡＭＥＴＥＲのメッセージ（いずれが用いられるにしても）は、ＩＰネットワーク・インターフェース３５０を介してサーバ１１１において受信される。サーバ・ソフトウェア３２０は、要求を処理し、適切な動作を取る。
【００７０】
以下では、本発明の代替実施形態を記載する。
【００７１】
一代替実施形態において、ストリーミング・セッションで用いるべき可能なサーバ・ビット・レートの選択肢をセッションの設定の間に通信するために、以下のＳＤＰボディで構成されるＲＴＳＰ  ＤＥＳＣＲＩＢＥメッセージを、サーバ１１１からクライアント１０１に送信する（画像部のみを示し、音声は示さず）。
m=video 0 RTP/AVP 98
b=AS:40
a=rtpmap:98 MP4V-ES/90000
a=control:trackID=4
a=fmtp:98 profile-level-id=8; config=01010000012000884006682C2090A21F
a=range:npt=0-150.2
a=alt-default-id:4
a=alt:3:b=AS:18
a=alt:3:a=control:trackID=3
a=alt:5:b=AS:27
a=alt:5:a=control:trackID=5
【００７２】
このＲＴＳＰ  ＤＥＳＣＲＩＢＥメッセージは、Proposal for Bandwidth Selection in PSSと題する従来技術の出版物（本出願の導入部を参照されたい）において示されている従来技術のＲＴＳＰ  ＤＥＳＣＲＩＢＥメッセージに相当する。
【００７３】
この模範的なＳＤＰボディにおいて、第５の属性行（ａ行）は、デフォルトの選択肢がトラック４であることを示しており、そのデフォルトのビット・レートは、ｂ行が示すように４０ｋｂｐｓである。ＳＤＰは、２つの別のトラックであるトラック３及びトラック５も規定する。これらのデフォルトのビット・レートは、それぞれ、１８ｋｂｐｓ及び２７ｋｂｐｓである。これらのトラックは、異なるコーデックと関係がある。単一のトラックは、単一の（マルチレート）コーデックのみを用いて符号化されたストリームを有する。従って、トラック４は、例えば、或るコーデックを用いて符号化された一連の異なるビット・レートの画像ストリームを有し、トラック５は、別のコーデックを用いて符号化された一連の異なるビット・レートの画像ストリームを有するようにすることができる。
【００７４】
一旦ストリーミング・セッションが確立すると、この実施形態においては、ＯＰＴＩＯＮＳ及びＳＥＴ＿ＰＡＲＡＭＥＴＥＲのメッセージを用いることができる。しかしながら、特にコーデックの変更が望まれる場合には、現在の利用可能なダウンリンク・インターフェース帯域幅は、ＰＡＵＳＥ／ＰＬＡＹメッセージ対を用いて、サーバ１１１に示すことができる。まず、ＰＡＵＳＥメッセージが、現在の送信を中止するために、クライアント１０１からサーバ１１１に送信される。引き続き、帯域幅の情報を有する前述の「帯域幅」フィールドで構成されるＰＬＡＹメッセージが、クライアント１０１からサーバ１１１に送信される。
【００７５】
クライアント１０１からサーバ１１１に送信すべきＰＡＵＳＥメッセージの一例は、以下のようなものである。
PAUSE rtsp://example.com/foo RTSP/1.0
CSeq: 6
Session: 354832
【００７６】
クライアント１０１からサーバ１１１に送信すべき引き続くＰＬＡＹメッセージの一例は、以下のようなものである。
PLAY rtsp://example.com/foo RTSP/1.0
CSeq: 7
Session: 354832
Bandwidth: 27000
Range: npt=28.00-
【００７７】
‘Ｂａｎｄｗｉｄｔｈ’というフィールドは、現在の利用可能なダウンリンク・エア・インターフェース帯域幅を示す。ＰＡＵＳＥ及びＰＬＡＹのメッセージのその他のフィールドは、一般的に規格化され、そのようなものとして知られている。
【００７８】
サーバの送信ビット・レートの切替えは、マルチレート・コーデックの異なるビット・レート間の切替えを伴い、或る送信ビット・レートから別の送信ビット・レートへの切替えの間にコーデックを変更することはできない、ＯＰＴＩＯＮＳ及びＳＥＴ＿ＰＡＲＡＭＥＴＥＲのメッセージの利用に反して、ＰＡＵＳＥ／ＰＬＡＹ法は、コーデックの変更を可能とする。従って、本発明の代替実施形態において、サーバ１１１は、受信した現在のダウンリンク・エア・インターフェース帯域幅に基づいて、ビット・レート及びコーデックを変更する。例えば、サーバは、トラック４からトラック５に変わることができる。
【００７９】
本発明は、エア・インターフェース帯域幅の変化に対処するための手段を提供する。ストリーミング・セッションにおいて、ストリーミング・サーバの送信ビット・レートを現在のダウンリンク・エア・インターフェース帯域幅に適応させることによって、アプリケーション層のパケット損失を減らすことができる。望ましい実施形態は、エア・インターフェース帯域幅の情報を伝達するメッセージをクライアント装置からストリーミング・サーバに送信するに際して、ＴＣＰ上のＲＴＳＰ又は別の信頼できるプロトコル上のＲＴＳＰを好適に用いる。ゆえに、ストリーミング・サーバにおけるメッセージの受信は、基本的に保証することができる。
【００８０】
前述の様々な例においては、画像部のみを示してきたが、画像に関して示したことは音声に対しても同様に適用可能であることは明らかである。
【００８１】
また、「帯域幅」と名付けられたメッセージ・フィールドを示してきた。しかしながら、このフィールドは「帯域幅」と名付けられる必要はなく、クライアント装置及びストリーミング・サーバの両者がそのフィールドの意味、すなわちクライアント装置における利用可能な帯域幅、を理解している限りは、別の名前でも良い。特に、ＱｏＳ特性（ＵＭＴＳ及びその他の適用可能なネットワーク）の上述のビット・レート・パラメータに基づいて、保証されたビット・レートを決定した場合には、例えば、「最大ビット・レート」又は「保証ビット・レート」と名付けられたフィールドを用いることができる。
【００８２】
また、あらかじめ記録されたメディア（画像及び／又は音声）・ファイルを用いてストリーミング・メディアを流すことを提案してきた。しかしながら、本発明は、ライブ画像及び／又はライブ音声をストリーミング・サーバにおいてリアルタイムに符号化し、クライアント装置に送信する、ライブ供給ストリーミングにも同様に適用可能である。
【００８３】
あらかじめ記録されたメディア・ファイルと関連して、或るストリーミング・サーバ送信ビット・レートから別のビット・レートへの変更は、実際問題としては、（第１のビット・レートで送信できるように符号化されたメディア・コンテンツで構成された）第１のあらかじめ記録されたビット・ストリームの送信から（第１のビット・レートとは異なる第２のビット・レートで送信できるように符号化された同じメディア・コンテンツで構成された）第２のあらかじめ記録されたビット・ストリームの送信への切替えを意味することができる。メディア・コンテンツがより高いビット・レートで符号化された場合には、より低いビット・レートでの符号化に比較して、より多くのビットが符号化に用いられたことを、このことは意味する。これは、通常、より良好な画像及び／又は音声の品質をもたらす。
【００８４】
本発明の更に別の実施形態は、更に、図１に示したエンドツーエンド・ストリーミング・システムに関連する。この実施形態において、ストリーミング・クライアント１０１は、それが接続されているネットワークの種類（又は、接続、すなわち、ＰＤＰ状況の種類）をストリーミング・サーバ１１１に通信すべきであることが理解された。すなわち、例えば、以下のような２種類の接続が存在してもよい。
１）ＱｏＳ保証接続
２）非ＱｏＳ保証（又は、ベスト・エフォート型）接続
【００８５】
ＱｏＳ保証接続は、クライアント１０１に対して保証されたビット・レート（すなわち、帯域幅）を提供するのに対し、非ＱｏＳ保証接続は、クライアント１０１に対して保証されないビット・レートを提供する。
【００８６】
ストリーミング・クライアント１０１（例えば、移動局）は、ストリーミング・セッションの間に異なる種類のネットワークの間でローミングを実行して、以下のような動的なシナリオを生じることも可能である。クライアントは、ＱｏＳ保証ネットワークを介した接続から始まり、しばらくした後に非ＱｏＳ保証ネットワークにローミングする。またその逆もある。クライアント１０１がどの種類のネットワーク接続を用いているかをサーバ１１１が知らない場合には、ネットワーク間のローミングは、ストリーミング・メディアの品質（関連するストリーミング・アプリケーションの性能）に影響を与える可能性が非常に高い。
【００８７】
従って、改善された帯域幅（レート）適応を可能とするために、ストリーミング・サーバ１１１は、この実施形態において、現在の潜在的なネットワークＱｏＳ情報（すなわち、ネットワーク（又は、接続）の種類）を知らされている。このことによって、サーバ１１１は、用いるべきレート適応法に関するより正確な仮定及び決定をなすことができる。
【００８８】
メッセージ（例えば、信号伝達メッセージ）をクライアント１０１からサーバ１１１に転送することによって、ストリーミング・サーバ１１１にＱｏＳ情報を知らせることができる。メッセージは、（あらゆる適用可能な方法による）ＲＴＳＰプロトコルによって又はＲＴＣＰ（リアルタイム制御プロトコル）プロトコルによってサーバに伝達することができる。メッセージは、以下の種類のものとすることができる。
１）「ＱｏＳ保証」  −現在のネットワーク接続が保証されたビット・レートを提供していることを示すためにこのメッセージを用いる。
２）「ＱｏＳ非保証」  −現在のネットワーク接続が保証されていない（又は、ベスト・エフォートの）ビット・レートを提供していることを示すためにこのメッセージを用いる。
（動作が同じである限りは、実際のメッセージ名は、異なっていてもよい。）
【００８９】
このメッセージ（Ｑｏｓ保証又はＱｏＳ非保証）は、接続の寿命の様々な瞬間において、ストリーミング・クライアント１０１がストリーミング・サーバ１１１に対して送信することができる。（どのネットワークの種類がメディア・ストリームを伝達するかを通信するために）ＰＤＰ状況の起動後に、及び／又はＰＤＰ状況の再ネゴシエーション後に、及び／又はネットワーク管理の結果として又は異なる種類のネットワークへのユーザ・ローミングの結果として接続を向上させるか又は劣化させるときに、少なくとも、メッセージを送信することができる。
【００９０】
別の代替実施形態において、本特許出願の前述にて既に定義したように‘Ｂａｎｄｗｉｄｔｈ’というパラメータ（又は、保証されたビット・レートに対する意味上等価なパラメータ）の既存の定義を用いて、クライアント１０１からサーバ１１１にＱｏＳ情報を送信する。かかるパラメータの適用は、以下の意味規則を用いて、拡張することができる。
ａ）クライアントからサーバに送信される、値＞０を有する‘Ｂａｎｄｗｉｄｔｈ’パラメータは、通信される帯域幅がＱｏＳ保証ネットワークを介する（すなわち、ネットワークが保証ビット・レートを提供する）ことを意味する。
ｂ）クライアントからサーバに送信される、値＝０を有する‘Ｂａｎｄｗｉｄｔｈ’パラメータは、ネットワークが非保証ビット・レートを提供することを意味する。
【００９１】
換言すると、‘Ｂａｎｄｗｉｄｔｈ’というパラメータの値がゼロより大、例えば２７０００、である場合には、このことは、現在の利用可能なダウンリンク・エア・インターフェース帯域幅が２７ｋｂｐｓであり、更に、ネットワークがＱｏＳ保証されていることを意味することになる。それに対し、値がゼロである場合には、このことは、ネットワークがＱｏＳ保証されていないことを意味することになる。
【００９２】
‘Ｂａｎｄｗｉｄｔｈ’というパラメータの値は、ＲＴＳＰ  ＯＰＴＩＯＮＳ又はＲＴＳＰ  ＳＥＴ＿ＰＡＲＡＭＥＴＥＲのメッセージ等の前述の実施形態において示したメッセージ内で、又は、例えば別のＲＴＳＰ又はＲＴＣＰのメッセージとすることができる別の適当なメッセージ内で伝達することができる。これらのメッセージのいずれも、‘Ｂａｎｄｗｉｄｔｈ’というパラメータに加えて、明確な「ＱｏＳ保証」又は「非ＱｏＳ保証」のヘッダーを含むことができる。これとは別に、ヘッダー（「ＱｏＳ保証」又は「非ＱｏＳ保証」）は、現在の利用可能なダウンリンク・エア・インターフェース帯域幅に関する情報を含んでいるメッセージとは異なるメッセージを介して伝達することができる。
【００９３】
保証されたビット・レート又は保証されないビット・レートが提供されているか否かをサーバ１１１が知っているという事実は、サーバ１１１が（帯域幅適応法に関連する）以下のような仮定及び決定をなすことの補助となる。
問題となっているネットワークがＱｏＳ保証されている場合には、
−クライアントの通信する帯域幅の値及びＲＴＣＰ受信機報告において利用可能な情報は、決定をなす際に、考慮することができる。
そうでない場合には、
−ＲＴＣＰ受信機報告において利用可能な情報のみを、考慮することができる。
【００９４】
ＲＴＣＰ受信機報告は、クライアントからサーバに送信されるパケットである。それらのパケットは、クライアント側におけるメディア受信の品質に関連する情報（例：パケット損失及び遅延ジッターに関する情報）を含む。
【００９５】
本発明の一実施形態によれば、ストリーミング・サーバは、移動オペレータのネットワークの外側に（すなわち、公衆インターネット内に）置かれる。この実施形態において、移動ネットワーク・ベアラはＱｏＳ保証されているが、ストリーミング・サーバと移動ネットワークの入り口との間のネットワーク・トランクは、ＱｏＳ保証されていない（すなわち、ベスト・エフォートである）。かかる場合においては、組み合わさったネットワーキングのシナリオ（ＱｏＳ保証＋非ＱｏＳ保証）が存在する。サーバは、エンドツーエンド・ネットワーク・チャンネルの実際の帯域幅を計算するために、ストリーミング・クライアントから直接来る帯域幅の情報とＲＴＣＰ受信機報告によってサーバ自身により計算される帯域幅の見積もりとの間の不整合（すなわち、逸脱）を利用することができる。従って、サーバは、適切な帯域幅適応動作を取ることができる。
【００９６】
本発明の特定の実施及び実施形態を記載してきた。本発明は、上述の実施形態の詳細に限定されるのではなく、本発明の特徴から逸脱せずに均等な手段を用いて別の実施形態で実施することができることは、当業者には明らかである。本発明の範囲は、添付の特許請求の範囲によってのみ限定される。
【図１】
2010136395.tif 000005
【図２】
2010136395.tif 000006
【図３】
2010136395.tif 000007