JP2018538710A - 無線ネットワーク上のストリーミングを制御するための方法及びデバイス - Google Patents

Abstract

ストリーミングメディアを再生するための無線端末において実行される方法であって、端末が、無線ネットワークに接続するためのモデムと、前記無線ネットワークを介してストリーミングデータサーバからストリーミングデータを受信するためのストリーミングデータバッファを含むデータストリーミングクライアントとを含み、方法が、ストリーミングクライアントからモデムへデータバッファサイズ情報を転送することと、ストリーミングサービスの開始及びデータバッファサイズを示すために、モデムによってネットワークにシグナリングすることと、データバッファサイズに応じて適応されたバッファスキームに従って、ネットワークを介して受信されたストリーミングメディアファイルのメディアデータをバッファリングすることと、バッファリングされたメディアデータから生成されたストリーミングメディアを再生することと、ストリーミングサービスの終了を示すために、モデムによってネットワークにシグナリングすることとを含む。バッファ充足のための適したインスタンスの推奨を含むバッファ充足信号をネットワークから受信することができ、バッファスキームは受信信号に依存して決定され得る。
【選択図】図１

Description

本開示は、データストリーミングの分野における改善、及び少なくとも部分的に、端末の電力消費を最適化するようにストリーミングデータパラメータを適応させるためのソリューションに関する。

スマートフォンやタブレットデバイスなどのモバイル端末は、ユーザに様々なサービスを提供する。映画や他のマルチメディアコンテンツなどのストリーミングメディアが普及しているので、ユーザは、様々な場所で、事実上いつでも、ストリーミングメディアの視聴を楽しむことができる。現在、適応型ビットレートストリーミングは、ストリーミングメディアの配信に使用される卓越した技術である。

端末が、例えばｈｔｔｐストリーミングプロトコルを使用してマルチメディアをストリーミングしているとき、端末は、ローカルストリーミングバッファを使用している。このバッファでは、データモバイルネットワーク転送遅延、一時的に遅いデータダウンロードなどとは無関係に、端末内のメディアプレーヤに常にデータが提供されることを確実にするために、モバイル無線アクセスネットワークを介してダウンロードされたマルチメディアコンテンツが一時的にキャッシュされる。端末は、いつ、どのくらいの量のデータでストリーミングバッファを補充すべきかを完全に制御する。

増加した無線アクセスデータレートの進化、並びに端末において利用可能なメモリの増加により、マルチメディアバッファは比較的大きくなり得る。しかし、ダウンロードデータレートとバッファサイズの両方でのこれらの能力の向上によって、ネットワーク効率並びにバッテリ消費の観点から、マルチメディアバッファ処理を最適化する上でより複雑になる。この複雑さの増加、及びそれに関連する問題は、本明細書に概説されている様々なソリューションの対象となる。ローカルバッファ処理の最適化もそのようなシナリオでの複雑な動作であるため、ライブビデオにマルチメディアストリーミングを利用するときにも、本明細書で概説されている様々なソリューションが適用可能である。ライブストリーミングのシナリオでは、ライブストリームのエンドツーエンド再生遅延を最小にするために、端末内のバッファリングの量はできるだけ少なくすべきであるが、デバイスにおいてマルチメディア再生機能を供給するために、バッファ内に常にデータがなければならない。

第１の態様によれば、ストリーミングメディアを再生するための無線端末において実行される方法が提供され、端末は、無線ネットワークに接続するためのモデムと、無線ネットワークを介してストリーミングデータサーバからストリーミングデータを受信するためのストリーミングデータバッファを含むデータストリーミングクライアントとを含み、この方法は、
ストリーミングクライアントからモデムへデータバッファサイズ情報を転送することと、
ストリーミングサービスの開始及びデータバッファサイズを示すために、モデムによってネットワークにシグナリングすることと、
データバッファサイズに応じて適応されたバッファスキームに従って、ネットワークを介して受信されたストリーミングメディアファイルのメディアデータをバッファリングすることと、
バッファリングされたメディアデータから生成されたストリーミングメディアを再生することと
を含む。

この方法は、ストリーミングサービスの終了を示すために、モデムを使用してネットワークにシグナリングするステップをも含み得る。代替として、ストリーミングセッションの終了は、タイマーの満了から、又は、例えば、ストリーミングデータサーバからのファイルの終わりの指示の受信によって収集され得る。

１つの実施形態では、この方法は、
バッファ充足に適したインスタンスの推奨を含むバッファ充足信号メッセージをネットワークから受信するステップであり、バッファスキームが、前記適したインスタンスに応じて決定された受信メディアデータでバッファを満たすためのタイミングデータを含む、ステップ
を含む。

１つの実施形態では、バッファ充足信号メッセージは、前記適したインスタンスでバッファリングするために、適した量の補充データの指示を含み、バッファスキームは、前記適した量に基づいて決定されたデータバーストサイズを含む。

１つの実施形態では、この方法は、
ストリーミングクライアントからモデムへバッファを満たすインスタンスのためのタイミングデータを転送するステップと、
タイミングデータを示すために、モデムによってネットワークにシグナリングするステップと
を含む。

１つの実施形態では、バッファスキームは、前記データバッファサイズに対応するデータバーストでストリーミングデータを受信することを含む。

１つの実施形態では、この方法は、
ネットワークからモデム制御信号を受信するステップと、
モデム制御信号に従ってバッファリングのインスタンス間にモデムの電力制御を適用するステップと
を含む。

１つの実施形態では、この方法は、
瞬間的なモデム電力消費に対応する推奨圧縮レベルを決定するステップと、
推奨圧縮レベルに基づいて符号化されたストリーミングメディアデータを送信するようにネットワークにシグナリングするステップと
を含む。

第２の態様によれば、ストリーミングスケジューリングデバイスにおいて実行される方法が提案され、デバイスは、無線ネットワークを介したストリーミングサーバから第１の端末のモデムへのストリーミングメディアデータの転送を制御するために、無線端末と通信するための無線ネットワークの基地局に接続され、この方法は、
第１の端末における受信のために前記基地局を介してストリーミングデータを送信することを伴う、端末におけるストリーミングサービスの開始を示す信号メッセージを検出するステップであり、前記信号メッセージが、端末におけるデータバッファサイズの指示を含む、ステップと、
現在の無線ネットワーク容量を評価するステップと、
ネットワーク容量及びデータバッファサイズに応じてストリーミングバッファ制御データを決定するステップと、
バッファリングを制御するために端末において使用するために、決定されたストリーミングバッファ制御データを含むバッファ充足信号メッセージを第１の端末へ送信するステップと
を含む。

１つの実施形態では、バッファ充足信号メッセージは、バッファリングを制御するために端末において使用するために、バッファ充足に適したインスタンスを含む。

１つの実施形態では、ストリーミングバッファ制御データは、
すべてのサービスされるデータ端末への瞬間的なトラフィック負荷に対するデータトラフィックを含む、統合されたデータトラフィック負荷、
第１の端末の着信及び発信のデータトラフィックタイミング、
第１の端末のためのモビリティシグナリング、
第１の端末との接続における瞬間的な無線チャネル特性、及び
無線ネットワーク内のキャッシュされたマルチメディアデータの利用可能性
のうちの１つ以上に応じて決定される。

１つの実施形態では、この方法は、
ネットワークと第１の端末との間の接続に関連する無線リンク情報を決定するステップと、
ネットワーク容量が同等の容量レベルより増加している、すなわち上回っていることを示す決定されたリンク情報に応じて第２の圧縮レベルを選択するために、第１のより高い圧縮レベル及び第２のより低い圧縮レベルでストリーミングデータを配信できるストリーミングデータ配信ユニットへコーデック選択命令を送信するステップと
を含む。

１つの実施形態では、制御ユニットは、基地局に接続され、前記適した量に対応するバッファサイズを有するローカルバッファに通信可能に接続され、ローカルバッファを前記適したインスタンス間のストリーミングサーバからのデータブロックで満たすように構成される。

第３の態様によれば、ストリーミングメディアを再生するための無線端末が提案され、
無線ネットワークの基地局からメディアデータを受信するように構成されたモデムと、
モデムに接続されたストリーミングバッファと、
ストリーミングメディアを再生するためにストリーミングバッファからメディアデータを受信するために接続されたメディアプレーヤと、
ストリーミングサービスの開始を示すためのネットワークへの信号メッセージを生成し、ネットワークからバッファ充足信号メッセージを受信するように構成されたコントローラであって、受信されたバッファ充足信号メッセージに基づいてバッファの充足を制御するように構成されたコントローラと
を含む。

１つの実施形態では、コントローラは、バッファ充足に適したインスタンスの推奨に基づいて決定された時点でバッファ充足を開始するように構成される。

１つの実施形態では、バッファ充足信号メッセージは、前記適したインスタンスでバッファリングするために、適した量の補充データの指示を含み、バッファリングするステップは、適した量のデータを適したインスタンスでバッファリングすることを含む。

添付の図面を参照しながら、本発明の様々な実施形態について以下で説明する。

無線ネットワークを介したサーバから端末へのメディアストリーミングのためのシステムセットアップを概略的に示す図である。 ストリーミングメディアデータを受信し、ストリーミングメディアを再生するように構成された例示的な端末を示す図である。 ストリーミングメディアセッション中のサーバとクライアントとの間の一般的な通信を示す図である。 一実施形態によるメディアストリーミング制御を改善するための無線アクセスプロトコル内のネットワークシグナリングメッセージを示す図である。 一実施形態による、各バッファ補充が、サーバによって別のプロセスとして処理される、範囲検索機能によるストリーミングメディアセッション中のサーバ−クライアント通信を示す図である。 無線システムのネットワークによって制御される電力節約状態を決定するパラメータを概略的に示す図である。 無線ネットワークにおいてデータを迅速にバッファリングするためにキャッシュする、端末から受信された情報に基づくネットワーク開始型データフロー調整を含むストリーミングプロセスを概略的に示す図である。 コーデックタイプに応じて電流消費に関してビデオストリームの復号されたビット当たりのコストを示す図である。 １つの実施形態の適応ストリーミングアルゴリズム機能の一例を概略的に示す図である。 ストリーミングセッションのある期間にわたって端末に利用可能な瞬間的なデータレートを例として示す図である。 異なるセル負荷に起因する一時的により高い又はより低いデータレートの利用可能性又はセル容量の局面に直面する、進行中のストリーミングセッション中に異なるセル間を移動する端末を示す図である。 統計収集及び配信のために無線ネットワーク通信プロトコルに対するメディアストリーミング関連の端末を使用するためのセットアップを示す図である。

次に、図面を参照しながら、様々な実施形態の詳細な説明について記述する。この説明は、いくつかの考えられる実装の詳細な例を提供するが、その詳細は例示的なものであり、決して適用例の範囲を限定するものではないことに留意されたい。さらに、詳細に説明したもの以外の実施形態も実施することができる。

本明細書で提案されるソリューションの場面を設定するための基礎として、メディアストリーミングのためのシステムセットアップが、図１に例として示されている。本明細書で意図されるようなストリーミングメディアという用語は、基本的には、たとえばサーバ３０などから、プロバイダによって配信されている間に、端末１００を介して絶えず又は断続的にユーザによって受信され、ユーザに提示されるマルチメディアであり得る。メディアサーバ３０は、したがって、端末１００の近傍に配置され得るが、一般に遠隔地に配置される。端末１００にローカルに完全に記憶されたメディアとは対照的に、ストリーミングメディアデータは、パケット又はセグメントとしてデータのストリームで端末１００に中継され、端末１００内のメディアプレーヤによって復号され、再生される前に端末においてバッファリングされる。

メディアコンテンツがアクセスされ、再生されることになっているとき、メディアサーバ３０と端末１００との間でストリーミングセッション１３がセットアップされ得る。図において、端末１００は、セルラー無線アクセスネットワーク１を介して、インターネット２０上でストリーミングメディアコンテンツサーバ３０に接続されている。メディアストリーミングプロトコルでは、矢印１３によって示されるように、端末１００とコンテンツサーバ３０との間にエンドツーエンドの接続プロトコルが存在する。このエンドツーエンド通信は、典型的には、例えば、ＭＰＥＧ ＤＡＳＨなど、適応ビットレート（ＡＢＲ）プロトコルを使用する。エンドツーエンドプロトコルに関係なく、メディアデータも、何らかの形態の搬送波を介して搬送される必要がある。上述のように、メディアストリーミングは、少なくとも無線通信ネットワーク１を介して実行されてもよく、無線通信リンクは、破線で示される無線ネットワーク１内の基地局１２と端末との間で使用される。基地局１２はコアネットワーク１０に接続され、コアネットワーク１０には複数の他の基地局も接続されている可能性がある。コアネットワーク１０は、さらに、インターネット２０を介して他のネットワークに接続されてもよい。ＷＣＤＭＡ、ＣＤＭＡ２００、ＬＴＥなど、特定の無線システムに応じて、異なる用語が端末１００及び異なる無線ネットワークノードに使用されてもよい。しかし、簡略にするために、端末１００は、無線ネットワーク１に無線リンクによって接続可能なデバイスを示すために使用され、基地局１２は、端末１００に無線インターフェースを提供するネットワークノードに対して使用される。端末１００は、例えば、携帯電話又はタブレットなどのポータブルコンピュータ、或いは単にストリーミングメディアを受信するための無線ネットワークに接続可能なメディアレンダリングデバイスであってもよい。ストリーミングメディアは、オーディオ及びビデオを含むマルチメディアであってもよく、又は単にそれらのうちの１つであってもよい。しかし、様々な実施形態を説明するために、ストリーミングビデオデータについて言及され得る。

図２は、機能的要素の観点から、一実施形態による例示的な端末１００を概略的に示す。言うまでもなく、端末１００は、何らかの形態のケーシング又はシャーシをも含むことが好ましいが、端末１００の物理的な実施形態は、本明細書で提案されるソリューションの理解には重要ではない。端末１００は、無線ネットワーク１に無線リンクを提供するために、アンテナに接続されたモデム１０４を含み得る。端末１００は、少なくともコントローラ１０２及びストリーミングバッファ１０３を含むように図示されたストリーミングクライアント１０１をさらに含む。コントローラ１０２は、メモリに記憶されたマイクロプロセッサ及び関連するプログラムコードを含むことができ、プログラムコードは、本明細書に概説されるソリューションに従ってストリーミングメディアセッションを制御するように、コントローラ１０２内のマイクロプロセッサによって実行され得る。コントローラ１０２はまた、以下でさらに説明するように、無線ネットワーク１にメッセージをシグナリングするようにモデムを制御することも可能である。

バッファ１０３は、無線ネットワーク１を介して送信されるストリーミングメディアデータを受信するために、モデム１０４に接続され得る。メディアプレーヤ１０５は、ストリーミングメディアを再生するために、コントローラ１０２の制御下でストリーミングバッファ１０３からメディアデータを受信するように接続されている。メディアプレーヤ１０５は、メディアデータデコーダをも含んでいてもよく、又はデコーダが別途設けられてもよい。ストリーミングビデオサービスからビデオを表示するためのディスプレイ１０６、ビデオの表示と一緒に、又はストリーミングオーディオサービスからの別途の出力としてオーディオを出力するためのスピーカ１０７など、再生メディアを出力するために、メディア出力部材が接続される。代替実施形態では、端末１００は、ビデオ１０６及びオーディオ１０７の出力部材の一方又は両方がなくてもよく、単に補助ビデオ又はオーディオ出力デバイスの接続のためのコネクタ（図示せず）を提供するだけでよい。

図３は、ユーザ端末１００内のストリーミングクライアント１０１とストリーミングメディアサーバ３０との間の、１つの最新技術のシナリオによるメディアストリーミングを示す。第１のステップ３０１において、ストリーミングセッション１３を作成するために、クライアント１０１とサーバ３０との間で接続セットアップが実行される。これは、最初から全部のメディアファイルを求める無線ネットワーク１を介して実行され得る。次のステップ３０２において、クライアント１０１は、ストリーミングサービス内の動画などのあるファイルをメディアプロバイダサーバ３０に求め得る。次いで、後のステップ３０３において、サーバ３０からクライアント１０１へのファイル転送が開始される。無線ネットワーク１を介して実行されると、メディアデータがバッファを満たし、コントローラ１０２の制御下で、メディアをレンダリングするために、メディアデータがバッファからメディアプレーヤ１０５に取り込まれる。通常の状態下で、バッファの充足は、途切れることなく再生メディアを楽しむことができるように、引出し速度よりも決定的に速い。バッファ１０３の充足の期間３０４中に、データも再生され得るが、ステップ３０２においてファイル全体が要求された場合、ある時点で、バッファ１０３は完全に又は所定の程度まで一杯であり得る。充足期間３０４の後、期間３０５が続き、その間に一連の通信が行われる。バッファが充足されると、期間３０４の終わりに、例えば、「受信ウィンドウ＝０」を示すことによって、その旨のメッセージ３０６がサーバにシグナリングされる。一定時間後、サーバ３０は、次いで、クライアント１０１に対して「受信ウィンドウのチェック」メッセージ３０７をシグナリングする。期間３０５は、バッファ充足レベルがある所定の程度又は閾値に低下するまでの時間によって決定され、バッファ１０３の補充は、そのレベルに到達するまで実行されない。バッファ補充レベルに達するまで、「受信ウィンドウのチェック」信号３０７が「受信ウィンドウ＝０」信号３０６に対して応答され、これは期間３０５の間に数回繰り返され得る。ＨＴＴＰストリーミングプロトコルによるセッションでは、例えば、バッファ１０３が一杯になることに続いて、クライアント１０１が追加のデータを受信する準備ができたときをチェックするサーバ３０から、例えば５秒の周期で、頻繁なメッセージ３０７が続き得る。

上述したように、マルチメディアバッファ１０３は、最新技術の端末１００のストリーミングバッファ１０３において比較的大きい可能性があり、これは、新しいストリーミングデータを受信するために無線アクセスが不十分であるときに、バッファを空にするリスクを低減し得る。しかし、瞬間的なデータレートが比較的低いとき、又は要求されるモデム送信出力電力が比較的高いとき、例えば、無線アクセスフェージングディップ中に、端末１００が大きいマルチメディアバッファ１０３を満たそうと試みることが常に賢明であるとは限らない場合がある。また、無線ネットワークの観点から、統合されたデータトラフィック負荷は時間とともに変化し、システム容量を最適化するために、ローカルにキャッシュされたバッファを増やすために他のものよりも適したインスタンスが存在する可能性がある。

１つの実施形態によれば、端末電力消費及びネットワークシステム容量の観点から、モデムデータトラフィック利用率を最適化する目的で、ネットワーク支援型ストリーミングマルチメディアバッファ制御の概念が提案される。

図４は、非常に低いシグナリング待ち時間で端末ストリーミングバッファ制御を可能にするために、無線アクセスプロトコル内にネットワークシグナリングメッセージを導入する１つの実施形態のフローチャートを概略的に示す。図４に示す方法は、好ましくはメディアストリーミングクライアント１０１の制御下にある端末１００と無線ネットワーク１との間で実行され、端末においてストリーミングメディアを再生することに関する。端末は、無線ネットワーク１に接続するためのモデム１０４をも含む。データストリーミングクライアント１０１は、無線ネットワーク１を介してストリーミングデータサーバ３０からストリーミングデータを受信するためのストリーミングデータバッファ１０３を含む。

ステップ４０１において、データバッファ１０３のサイズ情報がストリーミングクライアント１０１からモデム１０４に転送され、モデム１０４は、無線トランシーバ及びアンテナを介してシグナリングステップ４０１を実行する。したがって、端末１００内のストリーミングデータクライアント１０１は、ストリーミングサービスの開始及びデータバッファサイズを示すために、モデム１０４によってネットワーク１にシグナリングする。したがって、端末は、ストリーミングセッション中に、サーバ３０からのストリーミングデータの受信に取りかかることができ、それによって、バッファ１０３を補充するためのデータがネットワーク１を介して送信される。シグナリングされたバッファサイズは、データバッファ１０３の最大バッファサイズであってもよく、又は最大バッファサイズよりも小さいサイズの尺度であってもよい。

ストリーミングサービスの開始及び端末におけるデータバッファサイズの指示を示す、ステップ４０１で送信された信号は、例えば、コアネットワーク１０内のノードにおいて、又は端末モデム１０４が無線インターフェースを介して通信可能に接続されている基地局１２に密接に接続されたノード１１内においてなどのような、例えばネットワークスケジューラなどの、ネットワーク１内のノードにおいて検出される。信号受信に応答して、バッファ１０３の充足を制御するために、ストリーミングバッファ制御データを決定するために、少なくとも現在の無線ネットワーク容量が評価される。

ステップ４０２において、ストリーミングデータクライアント１０１によるバッファリングを制御するために端末１００において使用されるために、決定されたストリーミングバッファ制御データを含むバッファ充足信号メッセージが端末１００へ送信される。次いで、端末１００は、データバッファ１０３のサイズに応じたバッファスキームに従って、ネットワーク１を介して受信されたストリーミングメディアファイルに関連するバッファ１０３内のメディアデータのバッファリングを制御し得る。より具体的には、バッファスキームは、ストリーミングデータクライアントのコントローラ１０２によって実行されてもよいが、受信されたバッファ制御データを考慮に入れることができる。一例として、バッファ制御データは、バッファ補充を開始する時点の提案、及び、好ましくは、その時点における提案された補充データサイズの量をも示し得る。この制御データは、ネットワーク容量を含む様々なパラメータに応じてネットワーク１において評価されている可能性がある。加えて、ネットワーク１の、例えばネットワークスケジューラなどのスケジューラは、端末１００の電力消費と全体的なシステムデータ容量の両方を改善するために、多くのパラメータを考慮に入れることができる。考えられるパラメータは、例えば、統合された合計瞬時システムデータトラフィック負荷など、各バッファ補充のためのデータ転送速度を最大にすることができる。アクティブモデム時間を最小にするために、バッファ補充と他のデータトラフィックとの同期のために、特定の端末１００の着信／発信データトラフィックを評価することをも可能である。また、ハンドオーバ手順中にバッファ補充を制限し、端末が最適な基地局に接続されたときにバッファ補充が行われることを確実にする、モビリティシグナリングも考慮に入れることができる。例えば、チャネルフェージングに基づいて、データレートを最大にするために、瞬間的な無線チャネル特性が評価され得る。さらに、好ましくは、ネットワーク内で利用可能な任意のキャッシュされたマルチメディアデータが考慮される。ネットワーク１の無線インターフェースの近くでストリーミングデータのキャッシュが可能なとき、可能なダウンロードデータレートを制限する可能性がある、データがストリーミングサーバ３０から直接転送される必要があるシナリオを回避するために、ストリーミングを常にネットワークキャッシュから取ることができるように、バッファリングスキームが構成されるものとする。バッファ補充を開始する時点及び補充する量に関する提案を提供するために、上述のものの代替として、又は上述のものとの組合せで、バッファ制御データの基礎となる他のパラメータが考えられる。

ストリーミングメディアデータが端末１００において受信され、バッファ１０３にキャッシュされると、メディアプレーヤ１０５は、例えばオーディオ及び又はビデオをユーザに出力することによって、バッファリングされたメディアデータから生成されたストリーミングメディアを再生する。

ステップ４０３において、端末１００におけるストリーミングクライアント１０１は、ストリーミングサービスの終了を示すために、モデム１０４によって無線ネットワーク１にシグナリングする。その後、バッファ制御データを受信する必要はない。

シグナリングステップ４０２は、既に受信されたデータではなく、ネットワークから受信されるデータに関連する。したがって、バッファ制御データは、バッファスキームを適応させることができるように、端末１００においてあらかじめ受信されなければならない。また、したがって、時間及びデータサイズに関連するバッファ制御データは、受信されるメディアファイルとは無関係である。代わりに、このバッファ制御データは、無線ネットワーク１のパラメータを考慮に入れることに関連する。これらのメッセージは、ステップ４０１、４０２、及び４０３でシグナリングされ、異なるレベルで３ＧＰＰ仕様に含めることができる。１つの可能な例は、信号をＲＲＣシグナリングにおける新しいシグナリングメッセージとして含めることであり、その場合、例えば、ＬＴＥの３６．３３１の「その他」のメッセージングセクションに含めることができる。別の可能性は、これを新しい物理層手順としてＬＴＥの３６．２１３に含めることである。他のソリューションは、当業者によって理解されるように、他の無線通信仕様にも適用可能である。

再び図３を参照すると、最新技術に従って、クライアント１０１が最初からファイル全体を求めるようにストリーミングプロセスがセットアップされている場合、ストリーミングバッファ１０３がいっぱいであるとき、ストリーミングクライアント１０１は、ストリーミングサーバ３０と通信する必要がある。この欠点は、サイズの大きいストリーミングバッファ１０３と、ここでは「範囲検索」と呼ばれるＨＴＴＰストリーミング機能とを使用することによって部分的に克服され得る。範囲検索機能により、ストリーミングクライアントは、最初からメディアファイル全体を求めるのではなく、各ストリーミングバッファ充足要求で特定の範囲のメディアファイルをストリーミングサーバに求める。図４を参照して概説したように、バッファスキームは、例えば、サーバ３０から受信されるストリーミングデータの時間及び／又はサイズを決定するとき、無線ネットワーク１から受信されたバッファ制御データを考慮するように構成される。範囲検索機能により、各バッファ補充は、サーバ３０によって別のプロセスとして処理され、バッファ状態メッセージはもはや送信される必要がなくなる。代わりに、通信リンクは、バッファ補充の間、サイレントであってもよい。

図５は、１つの実施形態による範囲検索通信プロセスを示す。

第１のステップ５０１において、無線通信ネットワーク１を介して接続された端末１００内のストリーミングクライアント１０１とストリーミングメディアサーバ３０との間で接続セットアップステップが実行される。

ステップ５０２において、ストリーミングクライアント１０１は、メディアファイルの第１の範囲を求めるためにサーバ３０にシグナリングする。

ステップ５０３において、メディアファイルの第１の範囲がサーバ３０からメディアクライアント１０１に転送される。

期間５０４の間、バッファ１０３は、図に破線によって示されるように、実質的にいっぱいになるか、又は所定のレベルまでいっぱいになるまで、データで満たされる。ストリーミングメディアを再生するためのバッファ１０３からのデータの引出しは、第１の範囲の第１のデータが期間５０４の始めに受信された後の任意の時点で開始され得る。

図３の手順のように、サーバがバッファ補充の必要をチェックしないように構成されているので、次の期間５０５は、クライアント１０１とサーバ３０との間のシグナリングとデータ転送の両方に関してサイレントであり得る。このサイレント期間は、図中の次の破線によって示されるバッファ１０３を補充する必要があるまで続き得る。

続いて、ステップ５０６において、クライアント１０１は、ステップ５０２に対応する、メディアファイルのデータの次の範囲を求める。

ステップ５０７において、データの第２の範囲がサーバからクライアント１０１に転送される。

図４を参照して概説した説明を参照すると、無線ネットワークにおいてバッファ制御データが評価され得る１つ以上のパラメータは、データの第１の範囲を取り出してから変化している可能性がある。したがって、バッファ制御データは、例えば、ステップ５０６で要求された範囲のサイズを決定する前に、（ステップ４０２のように）ストリーミングクライアント１０１にシグナリングされ得る。代替的に、ステップ５０７における第２の範囲のデータの転送の開始は、ストリーミングクライアントへのバッファ制御データを含む可能性があり、これは、図４を参照して概説されるように、現在のパラメータに基づいてネットワークにおいて決定された第２の範囲の要求されたサイズの適応を伴う。ストリーミングクライアントにおけるコントローラ１０２によって操作されるバッファスキームは、そのとき、受信された第２の範囲が、典型的には小さい、要求された第２の範囲とは実際には異なることを考慮に入れてもよい。

期間５０８において、バッファ１０３の充足は、期間５０４に対応する、受信されたストリーミングデータから続行する。

端末のバッテリ消費の観点から、バッファ補充の間のサイレント期間が重要であり得る。通信モデム１０４が使用されていないとき、モデム１０４が低電力状態に入る、又は他の方法でそのアクティビティを減少させるのに利用可能な時間のギャップが存在する。しかし、サイレント期間に端末モデムアクティビティを減少させるそのような方法を使用するための１つの重要な問題は、例えば、３ＧＰＰプロトコルに従って、ネットワーク１が、電力モード及び許可されたモデム非アクティビティ期間を制御していることである。

図６は、無線ネットワーク１と動作する端末モデム１０４の様々な電力節約状態を概略的に示す。より大きい、囲まれたエリア６００は、モデム１０４とネットワーク１との間の接続状態を示し、ここで６０１は完全なアクティビティの状態を示す。これは、モデムが切断されるのを防ぐ何らかの形のサービスが現在実行中であること、又は少なくとも、任意のタイマーを超過しないようにデータ通信が頻繁に行われることを意味し得る。

Ｔ１は、第１の非アクティブタイマーを表し、このタイマーを超過したとき、モデムは、短いＤＲＸ（不連続受信）サイクル状態６０２に設定され得る。図６の本実施形態では、長いＤＲＸサイクル状態６０３が設定された、第２のタイマーＴ２を超過したか、又はデータ転送が再び検出されるまで、モデム１０４はその状態にとどまり、それによってモデム１０４は、完全なアクティブ状態６０１に戻る。同様の方式が、接続モードの長いＤＲＸ状態６０３において適用され得る。長いＤＲＸの第３のタイマーＴ３の時間フレーム中にデータ転送が検出されない限り、モデム１０４は、切断してアイドルモード６０４になる。Ｔ３の間の検出されたデータ転送は、代わりに、モデム１０４を完全なアクティブ状態６０１に戻すように設定する。

しかし、特にＬＴＥの場合、図６に示される電力節約状態を決定するパラメータはすべて、ネットワークによって制御され、ＷＣＤＭＡ／ＨＳＰＡ規格では、低電力状態に入ることを望むことを端末が示すことができる高速休止という機能がある。いずれの場合も、クライアント／サーバ通信を図５のように最適化してサイレント期間を作ることができるが、端末が、例えば、モデム無線デューティサイクルを低減するために、サイレント期間の利益を得るために、無線アクセスネットワークパラメータ又は他のモデム利用制御シグナリングが整列される必要がある。一態様によれば、高速休止シグナリングがない場合のサイレント期間の無線ネットワーク使用を最適化するためのソリューションが提案される。周期は、メディアコンテンツ、クライアントバッファサイズ、及び無線アクセスデータレートなどに応じて、時間とともに変化するので、図６で言及したＴ１、Ｔ２、及びＴ３など、良好なパラメータを静的に設定することは困難である。ネットワークによる節電戦略の一例は、長いＤＲＸサイクルの高い値とＴ３の長い値を設定することであり得る。長いＤＲＸ値に起因して、これは、データバースト間の良好なマルチメディアストリーミング電力消費をもたらし、長いＴ３値は、非アクティビティ期間中の状態変化を回避し得る。しかし、定期的なトラフィック要求のない他のより突発的なサービスでは、これは、長時間端末をアクティブモードに保ち、新しいデータ要求が長い待ち時間による影響を受ける可能性がある。また、多くのユースケースが無線アクセスネットワークにおける同じサービス品質クラスで実行されるので、そのような最適化は、今日のソリューションに基づいてサービスレベルで実行できると考えるのは現実的ではない。

このために、制御シグナリングの可能性を、通信プロトコル仕様、例えば、ＬＴＥの３ＧＰＰ仕様に追加する必要がある。３ＧＰＰ仕様におけるそのようなシグナリングの位置についての１つの可能性は、ＬＴＥ ＲＲＣ仕様ＴＳ３６．３３１にあり得る。一例として、これは、ＲＲＣ接続再確立の一部として含まれ得る。例えば、ＴＳ３６．２１３の物理層手順の一部としてなど、レイヤ１シグナリングの一部とすることもできる。信号は、端末から基地局への方向であり、反復可能なパターンでのオン／オフシグナリングに対応する僅か１ビットを追加することに基づき得るが、追加のシグナリングのためにより多くのビットを必要とする可能性がある。好ましくは、これは、予想されるバーストサイズを示すための１組のビットのシグナリングをも伴う。このソリューションは、端末がネットワークにパラメータを提案する、又は特定のＱｏＳ要件などを示す概念とは異なることに留意されたい。この提案では、端末は、無線アクセスネットワークに予想される反復可能なパターンを認識させているが、ネットワークは、依然として、例えば、ＤＲＸ及びタイマーパラメータ設定など、すべての構成を完全に制御する。

制御シグナリングオーバーヘッドを最小に抑えるために、図５及び図６を参照して概説された本実施形態では、この制御シグナリングのための基地局から端末への明示的な応答は期待されない。逆に、ネットワーク基地局１２は、例えば、ＤＲＸサイクル、及びＴ１、Ｔ２、又はＴ３など非アクティブタイマーなど、節電関連の設定をさらに処理する際に、この制御信号を考慮に入れることが期待される。

この実施形態の利点は、ネットワークに関して、無線ネットワークを介して提供されるストリーミングサービスに関してユースケース対応であり得ることである。これは、例えば、かなりの量のデータリソースを消費する非常に一般的なストリーミングのユースケースに有用であり得る。その結果、不必要な状態遷移からの制御シグナリング負荷を最小に抑えるために、また端末電力消費を改善するために、状態遷移関連パラメータ及びＤＲＸサイクルなどを動的に設定することが可能になる。一例として、ストリーミングメディアサービスが開始され、あるバーストサイズ転送のある周期が基地局１２からクライアント１０１に実行されることが確立されている場合、１つ以上のタイマーＴ１〜Ｔ３は、モデム１０４からのフィードバックを必要とせずに、バースト全体が転送された直後に、モデム１０４がより低い電力消費状態になるように設定し得る。タイマーは、例えば、基地局１２からモデム１０４にシグナリングされ得る。

このソリューションの代替実施形態として、オペレータコアネットワーク１０は、ストリーミングサーバ３０と通信し、同じタイプの情報、すなわち反復可能なパターンの転送の開始及び予想されるバーストサイズをサーバ３０から得ることができる。サーバ３０はインターネット２０上に配置されていると仮定されるので、これは、例えば、３ＧＰＰで標準化されていないＩＰベースのソリューションを必要とする可能性がある。そのような実施形態では、コアネットワーク１０は、トラフィック情報を受信した後、無線プロトコル設定を最適化するために、その情報を無線アクセス基地局１２に転送し得る。さもなければ、この代替実施形態は、図５を参照して説明した本実施形態と同じ利点から利益を得るであろう。

上で概説した本実施形態では、無線アクセスネットワーク１に反復トラフィックパターンの開始／終了を通知するために、シグナリングの可能性を標準化された無線アクセスプロトコルに追加することが提案されている。これは、ストリーミングのための範囲検索の使用についてネットワーク１に通知するためのソリューションを構成し、したがって、ネットワーク１は、例えば、ＤＲＸ設定、及び非アクティブタイマーなど、無線アクセスパラメータを改善するための適切なアクションをとることができる。画像１に示されるように、ストリーミングセッション１３が、モバイルワイヤレス通信ネットワーク１で使用されるワイヤレス端末１００によって開始されると、ストリーミングサーバ３０は、クライアント１０１と合意されたストリーミングセッションパラメータに従ってデータの配信を開始する。本質的に、高レベルの抽象化では、このデータは、インターネット２０及びモバイル無線コアネットワーク１０を介して基地局１２に転送され、その後、ワイヤレス基地局１２を介して端末１００に転送され得る。多くのネットワークにおいて、１つの主要なデータトラフィック容量のネックは、端末１００と基地局１２との間の無線インターフェースである。したがって、このインターフェースの使用を最適化することが重要である。ストリーミングセッション１３のために無線リンクを最適化するための１つの技術は、画像２に示されるように、無線アクセスコアネットワーク１０内のノード１４、又はアクセスネットワーク及び基地局１２に関連するノード１１においてローカルデータキャッシュを使用することである。そのようなソリューションでは、ネットワーク１は、特定のインターネットサーバ３０の方へのデータストリームの開始を識別し、無線アクセスインターフェースにおけるバッファ１１又は無線アクセスインターフェースに近いコアネットワーク１０内に位置するバッファ１４内にメディアコンテンツを一時的に記憶／キャッシュし得る。これは、ストリーミングサーバ３０からの配信ペースとは独立して、無線アクセスネットワーク及びエアインターフェースを介してデータ配信を調整するために行われ得る。１つの実施形態では、ローカルデータキャッシングと組み合わせて、上に概説した本実施形態を構築することによって、例えばマルチメディアストリーミング１３のエンドツーエンドのデータフロー最適化の新しい概念。この提案では、クライアント−サーバ通信によって定義されたバッファリング戦略を採用するように、ローカルデータキャッシングを動的に調整することができる。

図７は、例えば、改善されたローカルキャッシングパラメータアライメントによる、最適化されたエンドツーエンドデータフローのための、オペレータコアネットワーク１０へのカスケーディングクライアント−サーバ合意データフローに基づく実施形態を示す。この実施形態では、ネットワーク１は、特に、範囲検索の端末１００の使用を認識する。図において、端末１００のアプリケーションエンティティにおけるストリーミングクライアント１０１は、反復可能データトラフィック（例えば、ストリーミング）セッションのセットアップについての情報をモデム１０４に提供し、関連するパラメータをモデム１０４に提供する可能性がある。モデム１０４で利用可能なこの情報により、モデム１０４は、標準化されたプロトコル（例えば、３ＧＰＰプロトコル）を介して、例えば、マルチメディアストリーミングセッションに起因する、比較的反復可能なトラフィックパターンの開始及び終了に関する情報を無線アクセスネットワーク基地局１２へ送信することができる。すでに述べたように、モデム１０４は、マルチメディアストリーミングバッファ１０３のサイズに対応し得るデータバーストサイズの指標値をも送信することができる。

第１のフェーズ７１０において、無線ネットワーク１を介して、クライアント１０１とストリーミングサーバ３０との間で、ストリーミングセッションセットアッププロセス７１１が実行される。この例示的な実施形態では、メディアストリーミングクライアントは、ストリーミングサーバ３０と通信しており、コンテンツ配信のために範囲検索方法を使用することを決定する。クライアントは、例えば、各範囲内の合計メディアコンテンツファイルのデータの２０ＭＢをフェッチすることを決定する。

第２のフェーズ７２０では、クライアント１０１は、ストリーミングセッションの開始と、２０ＭＢのバーストサイズなど、合意されたストリーミングパラメータとを、７２１で無線ネットワーク１に通知することができる。この情報は、例えば、ＲＲＣ接続の再確立の一部として、又はＴＳ３６．２１３の物理層手順におけるレイヤ１シグナリングの一部として、ＬＴＥ ＲＲＣ仕様ＴＳ３６．３３１など、無線アクセスプロトコルでシグナリングされ得る。

これには、例えば、ＤＲＸ及び／又は非アクティブタイマー、又はとりわけバーストサイズなどのストリーミングパラメータ、並びに無線ネットワークの負荷及び容量パラメータに基づいて設定された他のシステムパラメータなど、上記で図４に関して概説したように、様々な無線パラメータに基づくパラメータ調整７２２のステップが続き得る。第２のフェーズ７２０の結果は、クライアント１０１とネットワーク１との間で合意されたデータバースト転送のための既知のパターンが存在することである。

第３のフェーズ７３０において、ネットワーク１は、第２のフェーズ７２０において端末１００から受信された情報に基づいてデータフロー調整を開始する。

ステップ７３１において、無線アクセスネットワーク１２は、合意されたパターンをコアネットワーク１０に通知し得る。

その後、ステップ７３２において、コアネットワーク１２は、サーバ３０からデータをフェッチする。

ステップ７３３において、コアネットワーク１０は、無線アクセスネットワーク１２へデータを送信する。

第３のフェーズ７３０は、ストリーミングサーバ３０からの２０ＭＢデータのブロックを迅速にバッファリングし、２０ＭＢブロックを効率的に配信するように無線アクセスネットワークスケジューリングを適応させるために、ノード１１又は１４におけるローカルデータキャッシングの開始を含み得る。このようにして、このノード１１又は１４には、例えば、均等なフローで、又はネットワーク内の他のデータ転送を考慮したレートで、データを供給することができる。このようにして、クライアント１０１への送信は、そのノード１１又は１４内の一時的なメモリキャッシュから実行することができる。これは、例えば、バッファ１０３が補充される時に、ネットワーク１又はインターネットにおけるデータ速度の一時的な低下、又はサーバ３０でのアクセスの問題によって引き起こされるストリーミングの問題を排除する効果を有する。

ステップ７３４において、クライアント１０１は、クライアントに関して、及び好ましくは他の無線パラメータに関しても最適化されたフローでデータを受信する。

したがって、図７の本実施形態は、第３のフェーズ７３０、すなわち、ネットワークデータフローの最適化を、合意されたクライアント−サーバパラメータと整合させることを実行する可能性を伴う。ネットワークローカルデータキャッシングは、現在のクライアント−サーバトラフィックフローの方に最適化されたバッファサイズを使用できる。このようにして、エンドツーエンド送信チェーンの独立した部分における異なるデータフロー戦略のリスクが最小限に抑えられるので、高容量及び低ネットワーク遅延、並びに低い端末電力消費を達成するように、完全なエンドツーエンドトラフィック経路を調整することができる。

マルチメディアストリーミング１３は、モバイル通信システムにおける通常のユースケースである。特にビデオコンテンツの場合、より高い圧縮レベルへのコーデックの継続的な進化があり、新しいマルチメディアコーデックの主な目標は、典型的には、メディアを配信するときに必要な転送データレートを低減することである。しかし、より高い圧縮レベルを有する新しいコーデックの進化に伴い、しばしば、受信端での復号の複雑さが増加するという負の効果がある。したがって、必要とされる計算の複雑さ、及びそれによる、受信端末１００における電力消費は、典型的には、より高い圧縮コンテンツの場合、増加する。

必要な転送データレートの低減は、ネットワーク１の負荷が時間とともに増加するときに、より高いシステム容量に対する要求を処理するために作られる。しかし、すべてのネットワークが常に完全に輻輳しているとは限らない。例えば、Ｗｉ−Ｆｉ、３Ｇ、又はＬＴＥネットワークにおけるワイヤレスネットワーク基地局１２は、たとえ「ビジー時間」が完全にロードされても、毎日何時間も利用可能な容量を有することができる。したがって、本発明者は、無線リンク容量が利用可能な時間の間に、必要な無線リンクデータレートよりも端末電力消費を低減するという考えを提案する。これは、必要とされる端末送信出力電力が通常非常に低い間に、容量が時間の経過とともに大きく変化する可能性がある、スモールセルの配備及びＷｉ−Ｆｉネットワークに特に有益であり得る。

符号化されたマルチメディアコンテンツを受信しているワイヤレス端末１００における総電力消費を考慮すると、これは、最適化の問題につながる。
・一方では、受信されるデータの量が少ないほど、モデム利用率が低くなり、それによって、電力消費が少なくなる。
・他方では、受信されるデータの量の低減は、よりコンパクトなメディア符号化によって実現される。また、よりコンパクトに符号化されるほど、端末内のメディアデコーダユニット上の必要とされる計算の要求が高くなり、それによって、電力消費がより高くなる。

電力消費を最適化するためには、これらのパラメータを適応的に調整する可能性がある。したがって、１つの実施形態では、現在のネットワーク容量及び端末電力消費を考慮して、モバイル通信ネットワーク１におけるマルチメディア配信のためのコーデック圧縮レベルを適応させることが提案される。言い換えれば、モデム１０４の電力消費が高いときには複雑度の高いコーデックで、モデム１０４の電力消費が低いときには複雑度の低いコーデックでマルチメディアを転送することによって、端末１００の電力消費を低減することを目的とする。端末１００における無線送信機、特に電力増幅器は、典型的には、０ｄＢｍ以上の出力レベルからの電力消費の指数関数的な増加を有するので、モデム１０４の電力消費の１つの非常に重要な側面は、現在の送信電力である。したがって、ｍＡに関するビット当たりのコストは、端末の送信電力に応じてかなり異なる。ストリーミングデータが端末内で受信されている間、品質報告及びＡＣＫ／ＮＡＣＫインジケータなど、ネットワーク１を介して端末１００からかなりの量の制御信号も送信される。一方、ｍＡに関する復号ビット当たりのコストは変化し、そのときコーデックが変更される。

図８は、マルチメディアを復号し、再生するための、例えばｍＡでの復号されたビット当たりの瞬間的な電力消費の例示的な図を示し、縦軸は電流を表し、横軸は符号化圧縮タイプを表す。実質的に、これは実装依存であり、図８の実レベル及び相対レベルは単なる例示である。一番左のバー８１は非コード化データを表し、これは送信されるすべてのデータ、したがって、大きいデータバースト又はセグメントを意味する。しかし、「復号」及び再生は、端末１００からの電力をほとんど必要としない。右側への以降のバーは、８２のＨ．２６３、８３のＨ．２６４、及び８４のＨ．２６５によって符号化されたデータの例を示す。この場合も、圧縮が高ければ高いほど、送信されるデータの量は少なくなるが、端末１００のデコーダにおける電力消費は高くなる。

モデム電力消費に関するコーデック又は圧縮レベル選択を配置するための２つの実施形態が概説される。

１つの実施形態は、ネットワーク支援型コーデック選択に基づく。ここでは、無線ネットワーク１内の制御ロジックが、ネットワーク１と端末１００との間の接続における利用可能なリンク容量など、無線リンク情報を収集することが提案される。ＬＴＥシステムの場合、この情報は、今日現在、基地局１２（ｅＮｏｄｅＢ）内で利用可能である。制御ロジックは、例えば、電力コマンドから得られる推定端末出力電力など、基地局１２で利用可能な端末１００関連情報を使用することもできる。この情報に基づいて、制御ロジックは、追加のネットワーク容量が利用可能であるときに、端末１００の電力消費を低減することができるように、コーデック選択命令をコンテンツ配信ユニットへ送信するように構成され得る。この実施形態は、通信プロトコルの任意の仕様を変更することなく実施することができる。

別の実施形態は、端末支援型コーデック選択に基づく。この実施形態では、受信端末１００は、圧縮レベル推奨をネットワーク１へ送信するように構成される。そのような推奨は、例えば、計算の複雑さ及び瞬間的なモデム電力消費を復号する端末１００における実装の知識に基づき得る。ネットワーク１は、この推奨を現在のネットワーク負荷と組み合わせて考慮し、コーデック選択命令をコンテンツ配信ユニットへ送信するように構成され得る。この実施形態は、端末−サーバ通信が端末支援データを含むことを可能にするプロトコルの変更を必要とする場合がある。そのような変更は、例えば、適応ストリーミング（ＨＬＳ／ＤＡＳＨ）のためのプロトコルを変更し、圧縮時の端末の推奨のためのフィールド、又は場合によっては現在要求されている端末の電力消費に関する情報を含めるために行われ得る。

コンテンツ配信ユニットは、例えばインターネット２０上のビデオサーバなど、マルチメディアコンテンツソース３０の一部とすることができ、又は、オペレータネットワーク１の一部としてトランスコーディングユニット１１又は１４とすることができる。

モバイル無線アクセスネットワーク１を介したマルチメディアストリーミングの場合、利用可能なエンドツーエンドのデータレートは、典型的には、基地局−端末間の無線リンクにおける無線状態の変動、並びに無線アクセスネットワークにおける全体的な容量の変動に起因して、時間とともに変化する。マルチメディアストリーミングユースケースにおける利用可能なデータレートの変動を処理するために、転送されたデータストリームは、適応ストリーミング技術によって時間とともに変化し得る。そのような技術の例は、ＭＰＥＧ−ＤＡＳＨ及びＨＬＳであり、ストリーミングコンテンツは、各セグメントが５〜１０秒の再生時間のデータからなるセグメントで配信される。各マルチメディアセグメントは、例えば、異なるコーデックで異なる画像解像度品質に符号化されるなど、多くの異なる実現／変形形態において、ストリーミングサーバ３０上で利用可能であり得る。経時的に選択すべきセグメントバリアントと、ダウンロードされるべき新しいセグメントを要求するべきときとの決定は、モバイル端末１００内のストリーミングクライアント１０１によって行われる。エンドツーエンドのデータレートが高いとき、端末は、高品質の符号化セグメントを選択することができ、エンドツーエンドのデータレートが低いとき、低品質の符号化セグメントを使用することができる。

一態様によれば、ストリーミングクライアント１０１で実行される端末ストリーミングアルゴリズムが、ネットワーク１が支援データを端末１００へ送信する状況をどのように扱うことができるかについてのソリューションが本明細書によって提案される。提案された端末ストリーミングアルゴリズムソリューションは、そのような支援データが利用可能かどうかに関係なく、Ｗｉ−Ｆｉ、セルラーネットワークなど任意のタイプの無線アクセスシステムを介してデータを受信するために独立して動作することに留意されたい。この提案は、端末１００が無線ネットワーク１からの制御シグナリング支援を要求するかどうか、並びにセグメント選択のための適応ストリーミングクライアント１０１及びストリーミングバッファ１０３制御でそのような情報をどのように使用できるかを決定するために設定される構成に基づく。

図９は、提案された端末概念の適応ストリーミングアルゴリズム機能のフローチャートの一実施形態を例として示す。

ストリーミングセッションセットアップ時に、ストリーミングセッションが開始されると、端末１００は、適切なビデオコーデックを選択するものとする。そのようなコーデックの例は、図７に示されるコーデックを含み得る。端末１００、より具体的には、ストリーミングクライアント１０１は、この選択を、例えば、同じ無線ベアラ上の履歴データレートなど、端末内ですでに利用可能な関連する情報に基づかせることができる。このデータは、例えば、モデムから取られたデータに基づき、コントローラ１０２によって記憶され得る。この選択において考慮される正確なパラメータは、図４を参照して提供された説明において与えられたパラメータのうちのいずれかを含み得るが、本明細書では特には説明されていない。

しかし、この実施形態における１つの新しい態様として、端末１００において、バッファ戦略決定のための十分な基礎を有するかどうかをチェックする、この端末情報の精度／有効性チェックを含めることが提案される。

端末１００内の利用可能な情報が十分に正確でないと考えられる場合、端末アルゴリズムは、ストリーミング支援データを送信する旨の要求を無線ネットワーク１へ送信することを決定する。これは、例えば、履歴データが少なすぎる、又はデータレートの履歴が何秒／何分も前に収集され、正確／有効ではないと仮定されるなど、例えば、端末１００に情報利用可能なデータがない、又は少なすぎる状況であり得る。無線ネットワーク１には、無線アクセスネットワークノードに含まれるソリューション及びプロトコルがある可能性があり、端末の方に、支援要求を送信することができる。パケットゲートウェイなどのネットワークノード１５では、ストリーミングセッションを識別することができ、ノード１５は、ストリーミング支援ロジックを含み得る、又はストリーミング支援ロジックに接続され得る。

それによって、端末１００におけるストリーミングクライアント１０１は、ネットワーク１から送信された支援データを受信し得る。この支援データは、コントローラ１０２によって実行される適応ストリーミングアルゴリズムにおいて関連するデータを考慮に入れるために、端末ストリーミングクライアント１０１に転送される予測／割当て情報を含み得る。そのような情報の転送は、例えば、端末と無線アクセスネットワークとの間の既存の通信プロトコルのうちの１つにネットワーク支援を組み込むことによって、基地局１２内にデータスケジューラを含むなど、いくつかの方法で行うことができる。実装の例は、ネットワークデータレートインジケータフィールドを含むようにストリーミングプロトコル（例えば、ＭＰＥＧ ＤＡＳＨ）を変更し、中間ノードがそのデータフィールドを読み取り、変更できるようにすることであり得る。他の例は、無線アクセスネットワークノードがストリーミング支援情報を挿入できる、ＨＴＴＰヘッダなど、適用されたプロトコルにおける情報フィールドを利用することであり得る。

次いで、あらかじめ端末１００において利用可能なパラメータ、及び適用可能であれば、ネットワークから受信された支援データが、セグメントバリアントを選択するステップにおいて、すなわち、例えば、バースト受信のためのサイズ及び／又は時間の観点で、選択のコーデック及び／又はバッファ制御に応じて考慮され得る。追加の態様として、端末１００は、支援データ収集のために現在どの無線アクセス技術（ＲＡＴ）が端末モデムエンティティによって使用されているかを考慮し得る。ＲＡＴの使用に基づいて、典型的には、例えば上記のうちのどのタイプの実装形態が異なるＲＡＴで利用可能であるかに応じて、支援情報要求が異なり得る。

ストリーミングアルゴリズムは、ストリーミングサービスセッションの終了の識別をも間欠的にチェックする。そのような終了は、ファイルの終わり、又は例えばユーザがセッションを終了することによって引き起こされる可能性がある。

セッションが継続する場合、クライアント１０１は、次の合意されたバッファ充足機会を待つ。

図１０は、瞬間的な無線アクセス状態及びセル負荷状態が時間とともに変化しているので、支援データが、利用可能なデータレートにわたるある期間のネットワーク推定平均値をどのように含み得るかを例として示す。図において、縦軸は、例えば、システム容量及び無線リンク品質など、ネットワーク及び無線リンクパラメータを考慮して、１つの端末１００が利用可能な瞬間的なデータレート１００１を示す。破線１００２は、ある期間にわたる平均データレートを示す。これは、ネットワーク支援データに含まれてもよく、端末ストリーミングクライアント１０１が適切なセグメントバリアントを選択するのを支援するために、今後のある期間の平均データレート予測として使用されてもよい。セグメントが平均利用可能データレート１００２以下に対応して選択された場合、端末ストリーミングバッファリングによって平均値１００２よりも利用可能なデータレートが低い機会を依然として処理することができ、クライアント１０１にとって十分なデータが常に利用可能であることを確実にすることができる。

図９及び図１０を参照して概説された本実施形態によれば、ネットワーク１は、ネットワーク１がそのような機能が可能かどうかを、要求に応じて、支援データで応答し得る。しかし、すべてのネットワーク１がそのようなストリーミング支援をサポートするとは想定できない。支援データが受信されない場合、端末アルゴリズムは、ある期間、例えば、現在使用されているＲＡＴ又はセル識別情報が変わるまで、要求シグナリングを除外し得る。端末クライアント１０１は、図９のコーデック選択アルゴリズムを実行しており、支援データを受信した場合、本発明によるさらなる新しい態様は、端末アルゴリズムが受信された支援データと端末で利用可能な情報とを組み合わせる可能性である。支援データの利用は、例えば、適切なコードレートを選択すること、又はバッファリングパラメータを調整することを含むことができる。コーデックレート選択は、支援情報とともに利用可能な端末データを重み付けすることとして実装することができる。バッファリングパラメータの調整は、例えば、各バッファ補充期間中にバッファリングされるセグメントの量を増減すること、或いは、追加のセグメントがストリーミングサーバから要求されているときに残りのバッファレベルを調整することを決定するために行うことができる。

そのため、図９及び図１０を参照して概説された本実施形態は、少なくとも以下の態様を含む。

端末において利用可能なデータが、バッファレベル及びコーデック選択など、バッファリング戦略を決定するのに十分であり、十分正確である場合、決定機能を含むように構成された端末ストリーミングアルゴリズムを含む。端末において利用可能なデータが十分正確でないと考えられる場合、支援要求をネットワークへ送信することができる。

端末ストリーミングアルゴリズムは、支援データ要求のタイプの選択のために利用されたＲＡＴを考慮するように構成されてもよい。

端末ストリーミングアルゴリズムは、支援データが要求後に利用可能になるかどうかを考慮するように構成され得る。支援データが受信されなかった場合、端末アルゴリズムは、ある期間、又はトリガイベントが発生するまで、さらなる支援要求を送信しないように構成され得る。

端末ストリーミングアルゴリズムは、受信された支援データを利用して、コーデック選択及びバッファリング戦略を考慮に入れることができる。

図１１は、異種の無線システムで使用される一実施形態を例として示す。そのような無線システムでは、無線ネットワーク１は、異なるサイズ、無線アクセス技術などを有する複数のセル１１０１、１１０２、１１０３からなり、典型的には、複数のセルが同じ地理的エリアをカバーする。異なるセルは、接続された端末のモバイル特性、並びに端末の動的トラフィックパターンに応じて、異なる瞬間的なトラフィック負荷を有する可能性がある。図１１の本実施形態では、ストリーミングサーバ３０からデータを受信することによって、端末１００が無線ネットワークを介したストリーミングセッションに現在関わっているという事実に気付いている、例えば１１又は１５など１つ以上のネットワークノードをネットワークが含むという点で、図１をも参照して無線ネットワークを説明することが可能である。このネットワークノード１１又は１５は、ここではネットワーク支援ユニットと示される。図１１のようなセルシナリオを有する無線アクセスシステムを利用する端末１００は、そのストリーミングクライアント１０１のためのネットワーク支援を受信することから利益を得ることになり、ここで、ネットワーク支援は、上記に概説された予測される／提案される将来の利用可能なデータレートだけでなく、新しいタイプの支援データからも構成される。１つの実施形態では、モバイルネットワークノード１１、１５によって端末１００に転送される新しいタイプの支援データは、バッファ充足推奨からなる。これらのバッファ充足推奨は、高トラフィック負荷状況、又は、例えば、端末のモビリティに起因する、問題に関連する他の態様を処理するために、推奨されるバッファ補充のサイズ及び／又はタイミングを示すことができる。

マルチメディアストリーミングは、すべてのデータトラフィックのうちのかなりの量を消費するので、ここでは、上述した概念の他に、ネットワーク１は、例えば、ネットワークがより動的な方法でセル負荷を制御するために、推奨される補充サイズに関してバッファ補充命令を送信することができることが提案されている。

図１１は、同じモバイルネットワーク１に属するいくつかのセル１１０１、１１０２、１１０３を示しており、ネットワーク支援ユニット１１、１５が端末ストリーミングネットワーク支援転送を処理している。異なるセル１１０１、１１０２、１１０３は、例えば、異なる周波数帯域で動作し得るので、異なる総量のアクティブ端末に供給し得るので、又は他のモバイルオペレータと共有され得るので、異なる容量及び瞬間的な負荷を有する。進行中のストリーミングセッション１３中にこれらのセル１１０１、１１０２、１１０３の間を移動する端末１００は、高優先度のサービスが開始される時間中の一時的に低いデータレートの利用可能性、又は異なるセル負荷に起因した異なる利用可能なセル容量などの局面に直面する。この図では、より小さいセル１１０２及び１１０３が、マクロセル１１０１よりも、接続された端子の数に関して、より高い容量を有すると仮定する。別のシナリオは、キャリアが統合される場合である。したがって、端末１００が２つ以上のセルによってカバーされるエリアにあるとき、データレートは、キャリアが統合されるにつれて向上する。次いで、これを使用して、バッファアルゴリズムを制御することができる。

ネットワーク支援型バッファサイズ補充推奨の導入により、異なるセル１１０１、１１０２、１１０３の間を移動する端末は、そのバッファ補充を調整して、ネットワークセル負荷を動的に最適化することができる。ネットワーク１は、端末１００がより高い空き容量のセル１１０２、１１０３に位置する時間の間に、ストリーミングバッファ１０３を追加のより大きいサイズのデータで満たすよう端末１００に指示する場合、より低い空き容量のセル１１０１におけるストリーミングトラフィック負荷は低減される。

既存のソリューションと比較して、例えば、ページングベースの方法では、バッファ補充命令のためのサイズ指示の追加は、少数の情報ビットで表される命令からなる新しい情報要素を組み込む。情報ビットは、ネットワークがストリーミングバッファを満たすために推奨するメディア再生のｋＢ及び／又は秒の案内を提供することができる。これらの追加のビットは、ネットワークからの別のネットワークストリーミング支援メッセージで送信することができるが、他の既存のメッセージにも含めることができる。

上述の本実施形態では、端末１００は、例えば、セルラー無線ネットワーク１などの無線アクセスネットワーク１を介して、インターネット２０上でストリーミングメディアコンテンツサーバ３０に接続されている。ビデオストリーミングプロトコルでは、典型的には、例えばＭＰＥＧ ＤＡＳＨなど、適応ビットレート（ＡＢＲ）プロトコルを使用して、端末１００とコンテンツサーバ３０との間に想定されるエンドツーエンド接続プロトコルが存在する。そのようなプロトコルの中で、ＵＥは、エンドツーエンド通信リンクにおいて利用可能な変動するデータレートに一致する、ダウンロードされたビデオセグメントごとにビデオ品質を動的に選択することが要求される。これらの変形の重要な部分は、無線アクセスネットワークにおける動的な側面に由来する。したがって、時間の経過に伴う適切なビットレート変動の可能な限り良好な推定を行うために、ネットワーク支援プロトコルが定義される。このプロトコルにより、無線アクセスネットワークは、ＵＥがそれ自体で行うことができるよりも良い方法で、現在の無線アクセスネットワーク条件に合致する適切なメディアデータレートに関する情報を共有することができる。これは、上記の実施形態について一般的に概説されているが、本明細書に提示された考えを実装する当業者は、ネットワーク支援プロトコルの詳細を決定する。

しかし、端末ストリーミングクライアント１０１に即時のネットワーク状態及びデータレート指示を提供するネットワーク１の目的に加えて、プロトコルは機能性を含み得る。１つの実施形態では、データストリーミングシナリオ１３における端末１００と無線アクセスネットワーク１との間の通信プロトコルは、以下の側面を含み得る。

端末１００は、ネットワーク統計量の記憶のためのビデオ（又は他のデータ）ストリーミング情報を転送することができる。ネットワーク１は、このビデオストリーミング統計を記憶し、それを他のメディア及びＲＡＴ関連データと組み合わせることができる。この情報は、無線アクセスネットワークの特定の部分のために、すなわちある基地局１２において、又はネットワーク１全体のグローバルネットワーク使用のために局所的に使用することができる。

ネットワーク１は、適用可能なときに、例えば、ネットワーク支援プロトコルを使用するなど、他の端末に対する改善された端末支援の一部としてデータ及び統計を使用するように構成され得る。これの１つの利点は、ストリーミングクライアント１０１のアルゴリズムが、ネットワークに記憶されたデータ及び解析から支援を即座に得ることができ、それによって、端末ベースのより遅い適応学習アルゴリズムの代わりに、例えば、ネットワーク／セル固有の条件に対して迅速に調整することができることであり得る。

図１２は、この実施形態を概略的に示す。この実施形態の追加は、例えば、無線アクセスネットワークノード１２に接続されたノード１１など、モバイルネットワークにデータストリーミング分析ユニットを追加し、ビデオストリーミング関連の統計データの記憶及び共有のためにＵＥ−ネットワークプロトコルを使用することである。目的とシステムの使用は、次の原則に従って動作することができる。

ストリーミングクライアント１０１は、典型的には、バッファ／リバッファ戦略のためのアルゴリズムを含む。このアルゴリズムは、例えば、各リバッファの機会をバッファリングするための適切なデータ量、及びバッファリングされたデータの適切な最小／最大レベルなど、１組の動的パラメータを定義する。これらのパラメータは、時間の経過とともに学習／採用することによってアルゴリズム内で適応的に定義することができる。しかし、これは、ネットワーク状態ごとに適切なパラメータを見つけるのに時間がかかるプロセスである可能性がある。

この提案された機能により、端末１００は、そのストリーミングクライアント１０１とともに、ネットワーク支援プロトコルを介して情報及び選択されたパラメータを共有することができる。これは、ネットワーク１において記憶され、処理され得る。

端末（同じ端末１００又は別の端末）がネットワーク１又はネットワーク支援を含むネットワークの一部にアクセスするとき、記憶された情報は、端末が適切なストリーミングアルゴリズムパラメータをより迅速に（又は直ちに）選択するのを支援するために、ネットワークによって使用することができる。本実施形態の要素間の通信の原理が図１２に示されており、ビデオストリーミングの例示的な使用について説明される。

ビデオストリーミングセッション１３が開始すると、端末１００は、ネットワーク支援プロトコル通信を開始する。端末１００及びネットワーク１は、ネットワーク支援のレガシー機能及び上述の本実施形態のうちのいずれかに従って、ビデオストリーミングセッション関連情報を共有する。しかし、これに加えて、ネットワーク支援サーバ１１は、ビデオセッション１３に関する情報及びデータを収集するように構成された統計記憶ユニット１１１２を含む。ネットワーク支援記憶ユニット１１１２に記憶された情報は、ネットワーク支援サーバ１１のメモリ１１１１に一時的に記憶されたセッション関連情報から収集することができ、さらに、端末１００は、ネットワーク支援記憶ユニット１１１２における記憶を対象とする特定の情報を送信することができる。

ネットワーク支援記憶ユニット１１１２に記憶された情報は、分析され、ローカル及びグローバルのビデオストリーミング関連情報の両方に組み合わせることができる。ローカル情報は、すなわち、基地局１２、又は端末タイプのグループなど、特定の無線アクセスネットワークセルに関連する。グローバル情報は、例えば、他のネットワークのノード１１１３からのデータを含む、ある国のすべてのセル及び端末からの統計とすることができる。ネットワーク支援プロトコルの本来の目的に従って、ローカル及びグローバルビデオストリーミング情報を有する他のシステム及びインターフェースを提供するため、又はさらに改善されたセッション関連ネットワーク支援を提供するために、ネットワーク１は、この記憶された統計情報を考慮に入れることができる。

実施形態の上記の説明は例示を提供するものであるが、網羅的であるものでも、実施形態を開示された厳密な形態に限定するものでもない。したがって、本明細書に記載された実施形態に対する変更が可能である。

用語「ａ」、「ａｎ」、及び「ｔｈｅ」は、１つ以上のアイテムを含むと解釈されるものとし、「基づく」という語句は、別段に明記されていない限り「少なくとも部分的に基づく」と解釈されるものとする。「及び／又は」という用語は、関連する１つ以上の項目の任意及びすべての組合せを含むと解釈されるものとする。

本明細書で説明した実施形態は、ソフトウェア、ファームウェア、及び／又はハードウェアの多くの異なる形態で実装され得る。例えば、プロセス又は機能は、「ロジック」又は「構成要素」として実装されてもよい。コントローラ１０２などのこのロジックは、ハードウェア（例えば、プロセッサ）又はハードウェアとソフトウェアの組合せを含み得る。本明細書及び添付図面の記載に基づいて実施形態を実施するようにソフトウェアを設計することができるので、特定のソフトウェアコードに関係なく実施形態を説明してきた。さらに、本明細書で説明した実施形態は、命令、プログラムコード、データ構造、プログラムモジュール、アプリケーションなどのデータ及び／又は情報を記憶する非一時的記憶媒体として実装され得る。例えば、非一時的記憶媒体は、コントローラ１０２の一部を形成する又はコントローラ１０２に接続されているメモリに関連して説明した１つ以上の記憶媒体を含む。本明細書で使用される場合、「含む（ｃｏｍｐｒｉｓｅ）」、「含む（ｃｏｍｐｒｉｓｅｓ）」、又は「含む（ｃｏｍｐｒｉｓｉｎｇ）」という用語、及びその同義語は、述べられた特徴、整数、ステップ、又は構成要素の存在を特定するためのものであり、１つ以上の他の特徴、整数、ステップ、構成要素又はそのグループの存在又は追加を排除するものではない。言い換えれば、これらの用語は、限定されない包含として解釈されるものとする。

前述の明細書では、様々な実施形態を添付の図面を参照して説明してきた。しかし、添付の特許請求の範囲に記載された本発明のより広い範囲から逸脱することなく、様々な修正及び変更がなされてもよく、さらなる実施形態が実施されてもよい。したがって、明細書及び図面は、限定的ではなく例示的なものとみなされるべきである。

Claims (16)

1. ストリーミングメディアを再生するための無線端末において実行される方法であって、端末が、無線ネットワークに接続するためのモデムと、前記無線ネットワークを介してストリーミングデータサーバからストリーミングデータを受信するためのストリーミングデータバッファを含むデータストリーミングクライアントとを含み、前記方法が、
   前記ストリーミングクライアントから前記モデムへデータバッファサイズ情報を転送することと、
   ストリーミングサービスの開始及びデータバッファサイズを示すために、前記モデムによって前記ネットワークにシグナリングすることと、
   前記データバッファサイズに応じて適応されたバッファスキームに従って、前記ネットワークを介して受信されたストリーミングメディアファイルのメディアデータをバッファリングすることと、
   バッファリングされたメディアデータから生成されたストリーミングメディアを再生することと
   を含む方法。
2. バッファ充足に適したインスタンスの推奨を含むバッファ充足信号メッセージを前記ネットワークから受信するステップであり、前記バッファスキームが、前記適したインスタンスに応じて決定された受信メディアデータで前記バッファを満たすためのタイミングデータを含む、ステップ
   を含む請求項１に記載の方法。
3. 前記バッファ充足信号メッセージが、前記適したインスタンスでバッファリングするために、適した量の補充データの指示を含み、前記バッファスキームが、前記適した量に基づいて決定されたデータバーストサイズを含む、請求項２に記載の方法。
4. 前記ストリーミングクライアントから前記モデムへ前記バッファを満たすインスタンスのためのタイミングデータを転送するステップと、
   前記タイミングデータを示すために、前記モデムによって前記ネットワークにシグナリングするステップと
   を含む請求項１に記載の方法。
5. 前記バッファスキームが、前記データバッファサイズに対応するデータバーストでストリーミングデータを受信することを含む、請求項１又は４に記載の方法。
6. 前記ネットワークからモデム制御信号を受信するステップと、
   前記モデム制御信号に従ってバッファリングのインスタンス間に前記モデムの電力制御を適用するステップと
   を含む前記請求項のいずれか一項に記載の方法。
7. 瞬間的なモデム電力消費に対応する推奨圧縮レベルを決定するステップと、
   前記推奨圧縮レベルに基づいて符号化されたストリーミングメディアデータを送信するように前記ネットワークにシグナリングするステップと
   を含む請求項１に記載の方法。
8. 前記ストリーミングサービスの終了を示すために、前記モデムによって前記ネットワークにシグナリングするステップ
   を含む前記請求項のいずれか一項に記載の方法。
9. ストリーミングスケジューリングデバイスにおいて実行される方法であって、前記デバイスが、無線ネットワークを介したストリーミングサーバから第１の端末のモデムへのストリーミングメディアデータの転送を制御するために、無線端末と通信するための前記無線ネットワークの基地局に接続され、前記方法が、
   前記第１の端末における受信のために前記基地局を介してストリーミングデータを送信することを伴う、前記端末におけるストリーミングサービスの開始を示す信号メッセージを検出するステップであり、前記信号メッセージが、前記端末におけるデータバッファサイズの指示を含む、ステップと、
   現在の無線ネットワーク容量を評価するステップと、
   前記ネットワーク容量及び前記データバッファサイズに応じてストリーミングバッファ制御データを決定するステップと、
   バッファリングを制御するために前記端末において使用するために、前記決定されたストリーミングバッファ制御データを含むバッファ充足信号メッセージを前記第１の端末へ送信するステップと
   を含む方法。
10. 前記バッファ充足信号メッセージが、前記バッファリングを制御するために前記端末で使用するために、バッファ充足のための適したインスタンスを含む、請求項９に記載の方法。
11. ストリーミングバッファ制御データが、
    すべてのサービスされるデータ端末への瞬間的なトラフィック負荷に対するデータトラフィックを含む、統合されたデータトラフィック負荷、
    前記第１の端末の着信及び発信のデータトラフィックタイミング、
    前記第１の端末のためのモビリティシグナリング、
    前記第１の端末との接続における瞬間的な無線チャネル特性、及び
    前記無線ネットワーク内のキャッシュされたマルチメディアデータの利用可能性
    のうちの１つ以上に応じて決定される、請求項９又は１０に記載の方法。
12. 前記ネットワークと前記第１の端末との間の前記接続に関連する無線リンク情報を決定するステップと、
    ネットワーク容量が同等の容量レベルより増加している、すなわち上回っていることを示す前記決定されたリンク情報に応じて前記第２の圧縮レベルを選択するために、第１のより高い圧縮レベル及び第２のより低い圧縮レベルでストリーミングデータを配信できるストリーミングデータ配信ユニットへコーデック選択命令を送信するステップと
    を含む請求項９〜１１のいずれか一項に記載の方法。
13. 前記制御ユニットが、前記基地局に接続され、前記適した量に対応するバッファサイズを有するローカルバッファに通信可能に接続され、前記ローカルバッファを前記適したインスタンス間の前記ストリーミングサーバからのデータブロックで満たすように構成される、請求項９〜１１のいずれか一項に記載の方法。
14. ストリーミングメディアを再生するための無線端末であって、
    無線ネットワークの基地局からメディアデータを受信するように構成されたモデムと、
    前記モデムに接続されたストリーミングバッファと、
    ストリーミングメディアを再生するために前記ストリーミングバッファからメディアデータを受信するために接続されたメディアプレーヤと、
    ストリーミングサービスの開始を示すための前記ネットワークへの信号メッセージを生成し、前記ネットワークからバッファ充足信号メッセージを受信するように構成されたコントローラであって、前記受信されたバッファ充足信号メッセージに基づいて前記バッファの充足を制御するように構成されたコントローラと
    を含む無線端末。
15. 前記コントローラが、バッファ充足に適したインスタンスの推奨に基づいて決定された時点でバッファ充足を開始するように構成される、請求項１３に記載の無線端末。
16. 前記バッファ充足信号メッセージが、前記適したインスタンスでバッファリングするために、適した量の補充データの指示を含み、バッファリングする前記ステップが、前記適した量のデータを適したインスタンスでバッファリングすることを含む、請求項１４に記載の無線端末。
    

Images