JP6575975B2 - 無線デバイスにおけるサービスアプリケーションのネットワーク推奨によるバッファ管理 - Google Patents

Description

本開示は、無線デバイスにおけるサービスアプリケーションのバッファ管理のための方法およびデバイスに関する。

コンテンツ適応は、デバイスおよびネットワーク能力に従ってメディアサービスのコンテンツを変換するための方法である。ネットワーク能力は、さまざまな技術によって、またさまざまな位置および時間によって異なっているので、コンテンツ適応は、特に、モバイルネットワークおよびモバイルデバイスにおいて有用である。たとえば、モバイルネットワーク内を移動しているユーザは、カバレッジの変化およびトラフィック負荷の変化に起因するさまざまなスループットを体感することになり、ネットワークのトラフィック負荷は時間の経過に伴って変動する。

メディアの例は、ビデオ、オーディオ、およびピクチャであり、適応アクションは、ビデオおよびオーディオのメディアレート、ならびにピクチャの解像度を変換することである。

適応ビットレート（ＡＢＲ）ストリーミングは、ストリーミングメディアに使用される技法である。今日の適応ストリーミング技法は、主にハイパーテキスト転送プロトコル（ＨＴＴＰ）に基づいている。原理は、メディアを複数のビットレートにエンコードし、次いでエンコードされたメディアファイルの各々をより小さいチャンクに分割することである。クライアントは、使用可能なメディアレートおよびセグメント長について認識する。メディアをストリーミングする場合、クライアントは、ネットワークにおいて体感されるスループットに従って適切な各セグメントのメディアレートを選択し、スループットの変化に適応する。通常、クライアントは、最低のメディアレートで最初の１つまたは数個のセグメントをダウンロードすることから開始する。ダウンロードビットレートがメディアビットレートよりも高い場合には、クライアントは、より高いメディアレートを選択して次のセグメントをダウンロードし、以降同様に繰り返してゆく。後に、ダウンロードビットレートが低下してメディアビットレートを下回った場合、クライアントは、より低いメディアレートを選択してセグメントをダウンロードする。

Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ）−ＤＡＳＨとしても知られているＤｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ）は、国際標準である唯一のＨＴＴＰベースの適応ビットレートストリーミングソリューションである。さらに、ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ（ＨＬＳ）のような、その他のＨＴＴＰベースの適応ビットレートストリーミングソリューションもある。

たとえば、ＷＯ２０１２／１１８４１４およびＷＯ２０１０／０６６８５５において説明されているようにスループットを推定するための方法を提供することが知られている。

現在、コンテンツ適応は、たとえばユーザ機器（ＵＥ）のようなデバイスにおいてクライアントから視聴された以前のセグメントのダウンロードからの測定に基づいているが、これはネットワーク内の現在の状況および近い将来の状況とは異なる場合がある。したがって、コンテンツ適応についてクライアントにおいて行なわれる決定は、事前対応的というよりも、事後対応的になる傾向がある。モバイル環境において、条件は非常に迅速に変化する、たとえばＵＥが位置を変更してその結果無線リンク品質およびスループットに変化が生じることがある。同じ無線リソースを共有しているユーザの数が減少または増加することもあり、その結果ＵＥの使用可能スループットの変化が生じることもある。

さらに、ＵＥは、使用可能な帯域幅にはかかわりなく、バッファ状況に基づいてサービスに対しサービスアプリケーションのアプリケーションバッファを満たす。

本開示の目的は、特にメディアサービスを提供するための、サービスアプリケーションのアプリケーションバッファのバッファ管理を改善することである。本開示によれば、ネットワークは、サービスアプリケーションに使用可能になると予測される将来の帯域幅に関する情報、およびアプリケーションバッファの状況に関する情報を取得し、アプリケーションバッファを管理する方法、特にメディアセグメントをメディアバッファにいつダウンロードするか（時間単位）についてのサービスアプリケーションへの推奨を準備する。その結果、無線デバイス、典型的には、その中のサービスアプリケーションは、アプリケーションバッファを管理する際に推奨を考慮することができる。

本開示の態様によれば、通信ネットワークにおいて実行される方法が提供される。本方法は、前記ネットワークに接続されている無線デバイスにおいてサービスアプリケーションに将来使用可能な無線キャリアの帯域幅の予測を取得することを備える。本方法はまた、サービスアプリケーションのアプリケーションバッファの状況に関する情報を受信することを備える。本方法はまた、取得された予測および受信されたバッファ情報に基づいて、サービスアプリケーションのアプリケーションバッファをいつ満たすべきかについてのサービスアプリケーションへの推奨を準備することを備える。本方法はまた、準備された推奨を備える推奨メッセージの無線デバイスへの送信を開始することを備える。

本開示のもう１つの態様によれば、コンピュータ実行可能コンポーネントを備える、コンピュータプログラム製品であって、通信ネットワークのノードに、ノードに含まれるプロセッサ回路上でコンピュータ実行可能コンポーネントが実行されるとき、本開示の通信ネットワークにおいて実行される方法の一実施形態を実行させる、コンピュータプログラム製品が提供される。

本開示のもう１つの態様によれば、通信ネットワークのためのノードが提供される。ノードは、プロセッサ回路と、前記プロセッサ回路により実行可能な命令を格納するストレージユニットとを備え、それにより前記ノードは、前記ネットワークに接続されている無線デバイスにおいてサービスアプリケーションに将来使用可能な無線キャリアの帯域幅の予測を取得するように動作可能である。ノードはまた、サービスアプリケーションのアプリケーションバッファの状況に関する情報を受信するように動作可能である。ノードはまた、取得された予測および受信されたバッファ情報に基づいて、サービスアプリケーションのアプリケーションバッファをいつ満たすべきかについてのサービスアプリケーションへの推奨を準備するように動作可能である。ノードまた、準備された推奨を備える推奨メッセージの無線デバイスへの送信を開始するように動作可能である。

本開示のもう１つの態様によれば、通信ネットワークに接続されている無線デバイスにおいて実行される方法が提供される。本方法は、アプリケーションバッファを有するサービスアプリケーションを実行することを備える。本方法はまた、アプリケーションバッファの状況に関する情報を通信ネットワークに送信することを備える。本方法はまた、通信ネットワークから、アプリケーションバッファをいつ満たすべきかについての推奨を備える推奨メッセージを受信することを備える。本方法はまた、受信した推奨に基づいて、無線デバイスがアプリケーションバッファを満たすであろう時間期間を判定することを備える。本方法はまた、判定された時間期間中にデータをアプリケーションバッファにダウンロードするためにサービスアプリケーションのサービスプロバイダに要求を送信することを備える。

本開示のもう１つの態様によれば、コンピュータ実行可能コンポーネントを備える、コンピュータプログラム製品であって、通信ネットワークの無線デバイスに、無線デバイスに含まれるプロセッサ回路上でコンピュータ実行可能コンポーネントが実行されるとき、本開示の無線デバイスにおいて実行される方法の一実施形態を実行させる、コンピュータプログラム製品が提供される。

本開示のもう１つの態様によれば、通信ネットワークを介する通信のための無線デバイスが提供される。無線デバイスは、プロセッサ回路と、前記プロセッサ回路により実行可能な命令を格納するストレージユニットとを備え、それにより前記無線デバイスは、アプリケーションバッファを有するサービスアプリケーションを実行するように動作可能である。無線デバイスはまた、アプリケーションバッファの状況に関する情報を通信ネットワークに送信するように動作可能である。無線デバイスはまた、通信ネットワークから、アプリケーションバッファをいつ満たすべきかについての推奨を備える推奨メッセージを受信するように動作可能である。無線デバイスはまた、受信した推奨に基づいて、無線デバイスがアプリケーションバッファを満たすであろう時間期間を判定するように動作可能である。無線デバイスはまた、判定された時間期間中にデータをアプリケーションバッファにダウンロードするためにサービスアプリケーションのサービスプロバイダに要求を送信するように動作可能である。

本開示のもう１つの態様によれば、コンピュータプログラムコードを備える、コンピュータプログラムであって、コンピュータプログラムコードは、通信ネットワークのノードのプロセッサ回路上で実行されるとき、ノードに、前記ネットワークに接続されている無線デバイスにおいてサービスアプリケーションに将来使用可能な無線キャリアの帯域幅の予測を取得させることができる、コンピュータプログラムが提供される。このコードはまた、ノードに、サービスアプリケーションのアプリケーションバッファの状況に関する情報を受信させることができる。このコードはまた、ノードに、取得された予測および受信されたバッファ情報に基づいて、サービスアプリケーションのアプリケーションバッファをいつ満たすべきかについてのサービスアプリケーションへの推奨を準備させることができる。このコードはまた、ノードに、準備された推奨を備える推奨メッセージの無線デバイスへの送信を開始させることができる。

本開示のもう１つの態様によれば、コンピュータプログラムコードを備える、コンピュータプログラムであって、コンピュータプログラムコードは、無線デバイスのプロセッサ回路上で実行されるとき、無線デバイスに、アプリケーションバッファを有するサービスアプリケーションを実行させることができる、コンピュータプログラムが提供される。このコードはまた、無線デバイスに、アプリケーションバッファの状況に関する情報を通信ネットワークに送信させることができる。このコードはまた、無線デバイスに、通信ネットワークから、アプリケーションバッファをいつ満たすべきかについての推奨を備える推奨メッセージを受信させることができる。このコードはまた、無線デバイスに、受信した推奨に基づいて、無線デバイスがアプリケーションバッファを満たすであろう時間期間を判定させることができる。このコードはまた、無線デバイスに、判定された時間期間中にデータをアプリケーションバッファにダウンロードするためにサービスアプリケーションのサービスプロバイダに要求を送信させることができる。

本開示のもう１つの態様によれば、本開示のコンピュータプログラムの一実施形態と、コンピュータプログラムが格納されるコンピュータ可読手段とを備える、コンピュータプログラム製品が提供される。

ネットワークが、データをアプリケーションバッファにいつダウンロードすべきかを、無線デバイス、より正確には無線デバイス内のサービスアプリケーションに、推奨することができることは、本開示の利点である。したがって、ダウンロードがより容易でより迅速である場合、使用可能な多量のリソース（帯域幅）があれば、サービスアプリケーションがデータをそのバッファにダウンロードするように選択することができ、使用可能なリソースが限られていれば、ダウンロードしないように選択することができるので、ネットワークリソースは、さらに効率的に使用され得る。

態様のいずれかの任意の特徴が、適当と認められるときは、任意の他の態様に適用されてもよいことに留意されたい。同様に、態様のいずれかの任意の利点は、その他の態様のいずれかに適用することができる。添付の実施形態のその他の目的、特徴、および利点は、以下の詳細な開示から、添付の独立クレームから、および図面から明らかとなろう。

一般に、特許請求の範囲において使用されるすべての用語は、本明細書において明示的に規定されていない限り、当技術分野におけるそれらの通常の意味に従って解釈されるものとする。「１つの（ａ／ａｎ）／要素、装置、コンポーネント、手段、ステップなど」のすべての参照は、特に明記のない限り、要素、装置、コンポーネント、手段、ステップなどの少なくとも１つの例を参照するものとして広義に解釈されるものとする。本明細書において開示される任意の方法のステップは、特に明記のない限り、開示されている正確な順序で実行される必要はない。本開示のさまざまな特徴／コンポーネントに対する「第１」、「第２」の使用は、特徴／コンポーネントをその他の類似する特徴／コンポーネントと区別することが意図されているにすぎず、特徴／コンポーネントにいかなる順序または階層を与えることも意図されない。

実施形態は、ほんの一例として、添付の図面を参照して説明される。

本開示による通信ネットワークに接続されている無線デバイスの一実施形態を示す概略図である。 本開示の無線デバイスの一実施形態を示す概略ブロック図である。 本開示のネットワークノードの一実施形態を示す概略ブロック図である。 本開示のコンピュータプログラム製品の一実施形態を示す概略図である。 本開示の通信ネットワークにおいて実行される方法の一実施形態を示す概略流れ図である。 本開示の無線デバイスにおいて実行される方法の一実施形態を示す概略流れ図である。 本開示の例示的実施形態による無線デバイスにおける使用可能な帯域幅とサービスアプリケーションのアプリケーションバッファ状況を示す概略グラフである。 本開示の別の例示的実施形態による無線デバイスにおける使用可能な帯域幅とサービスアプリケーションのアプリケーションバッファ状況を示す概略グラフである。 本開示の例示的実施形態を示す概略ブロック図である。

これ以降、実施形態は、特定の実施形態が示される添付の図面を参照して、以下にさらに詳細に説明される。しかし、多くのさまざまな形態のその他の実施形態は、本開示の範囲内において可能である。むしろ、以下の実施形態は、この開示が綿密かつ完璧なものとなり、本開示の範囲を当業者に十分に伝達できるように、一例として提供されている。説明全体を通じて、類似する番号は類似する要素を示す。

図１は、通信ネットワーク１を介してサービスプロバイダ７に接続されている無線デバイス２を示す。通信ネットワークは、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）またはセルラーネットワーク、たとえば第３世代パートナーシッププロジェクト（３ＧＰＰ）通信標準に従ったセルラーネットワークなどの、任意のタイプの無線通信ネットワークを備えることができる。図において、通信ネットワーク１は、たとえば広帯域符号分割多元接続（ＷＣＤＭＡ）通信標準のノードＢまたはＬｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）通信標準のエボルブドノードＢ（ｅＮＢ）のような、少なくとも１つの基地局３を備えるセルラー無線アクセスネットワーク（ＲＡＮ）４を備える３ＧＰＰネットワークである。通信ネットワーク１はまた、たとえばインターネットのような、パケットデータネットワーク（ＰＤＮ）５へのアクセスが提供されるコアネットワーク（ＣＮ）６を備える。無線デバイス２は、通信ネットワーク１に接続されているので、ネットワーク２を介してＰＤＮ５にアクセスすることができる。無線デバイス２は、モバイルまたは固定の、通信ネットワークにおいて無線チャネルを介して通信できるようにされた任意のデバイスまたはＵＥであってもよく、例としてただし非限定的に、たとえば携帯電話、スマートフォン、モデム、センサー、メーター、車両（たとえば、自動車）、家電製品、医療器具、メディアプレイヤー、カメラであるか、もしくは任意のタイプの消費家電製品であってもよく、例としてただし非限定的に、テレビジョン、ラジオ、照明設備、タブレットコンピュータ、ラップトップ、またはパーソナルコンピュータ（ＰＣ）がある。本開示によれば、無線デバイス２はサービスアプリケーションを実行する、つまり無線デバイス２はアプリケーションソフトウェアを実行してサービスアプリケーションを形成する。サービスアプリケーションによって提示されるサービス（たとえば、メディアストリーミング）は、サービスプロバイダ（ＳＰ）７のサーバによってＰＤＮ５を介して提供される。

図２ａは、本開示の無線デバイス２の一実施形態を概略的に示す。無線デバイス２は、たとえば中央演算処理装置（ＣＰＵ）のような、プロセッサ回路２１を備える。プロセッサ回路２１は、マイクロプロセッサの形態をとる１つまたは複数の処理ユニットを備えることができる。しかし、たとえば特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、または複合プログラマブルロジックデバイス（ＣＰＬＤ）のような、コンピューティング能力を備えるその他の適切なデバイスが、プロセッサ回路２１に含まれてもよい。プロセッサ回路２１は、たとえばメモリのような１つまたは複数のストレージユニットのストレージ２２に格納されている１つまたは複数のコンピュータプログラムまたはソフトウェア（ＳＷ）４１（図４も参照）を実行するように設定される。ＳＷ４１は、プロセッサ回路によって実行されるときにサービスアプリケーション２４を形成するアプリケーション（Ａｐｐ）ＳＷ４４を備える。ＳＷ４１に含まれるその他のコンピュータプログラムは、たとえば、サービスアプリケーション２４のアプリケーションバッファへのデータのダウンロードをスケジュールするスケジューラ２５を形成することができる。スケジューラ２５は、サービスアプリケーション２４の一部であってもよいか、または独立したものであってもよい。ストレージユニット２２は、本明細書において説明されるコンピュータ可読手段４２（図４を参照）と見なされ、たとえばランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリまたはその他のソリッドステートメモリ、もしくはハードディスク、もしくはその組み合わせの形態であってもよい。プロセッサ回路２１はまた、必要に応じて、ストレージ２２にデータを格納するように設定されてもよい。無線デバイス２はまた、通常は、たとえばデータをＳＰ７からダウンロードするためなど、通信ネットワーク１との／を介する無線通信を可能にするための、送受信機およびアンテナを備える、無線通信インターフェイス２３を備える。

したがって、本開示の態様によれば、通信ネットワーク１を介する通信のための無線デバイス２が提供される。無線デバイスは、プロセッサ回路２１と、前記プロセッサ回路により実行可能な命令４１を格納するストレージユニット２２とを備え、それにより前記無線デバイスは、アプリケーションバッファを有するサービスアプリケーション２４を実行するように動作可能である。無線デバイスはまた、アプリケーションバッファの状況に関する情報を通信ネットワークに送信するように動作可能である。無線デバイスはまた、通信ネットワークから、アプリケーションバッファをいつ満たすべきかについての推奨を備える推奨メッセージを受信するように動作可能である。無線デバイスはまた、受信した推奨に基づいて、無線デバイスがアプリケーションバッファを満たすであろう時間期間を判定するように動作可能である。無線デバイスはまた、判定された時間期間中にデータをアプリケーションバッファにダウンロードするためにサービスアプリケーションのサービスプロバイダ７に要求を送信するように動作可能である。

図２ｂは、図２ａの無線デバイス２の一実施形態を機能的に示す概略ブロック図である。前述のように、プロセッサ回路２１は、無線デバイスが本開示の方法の実施形態を実行できるようにするためにソフトウェア４１を実行することができ、それにより機能モジュールが、方法のさまざまなステップを実行するために、無線デバイス２、たとえばプロセッサ回路２１において形成されてもよい。これらのモジュールは、無線デバイス２内のブロックとして概略的に示される。したがって、無線デバイス２は、サービスアプリケーション２４を実行するためのアプリケーション実行モジュール２６、アプリケーションバッファ状況に関する情報を送信するためおよびサービスプロバイダ７に要求を送信するための送信モジュール２７、推奨メッセージを受信するための受信モジュール２８、および無線デバイス２（特に、サービスアプリケーション２４）がアプリケーションバッファを満たすであろう時間期間を判定するための判定モジュール２９（たとえば、スケジューラ２５を備える）を備える。

図３ａは、本開示のネットワークノード３の一実施形態を概略的に示す。ＮＷノード３は、通信ネットワーク１内の任意のノードであってもよいが、いくつかの実施形態において、好ましくは、基地局３のようなＲＡＮノードであってもよい。ネットワークノード３は、たとえば中央演算処理装置（ＣＰＵ）のような、プロセッサ回路３１を備える。プロセッサ回路３１は、マイクロプロセッサの形態をとる１つまたは複数の処理ユニットを備えることができる。しかし、たとえば特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、または複合プログラマブルロジックデバイス（ＣＰＬＤ）のような、コンピューティング能力を備えるその他の適切なデバイスが、プロセッサ回路３１に含まれてもよい。プロセッサ回路３１は、たとえばメモリのような１つまたは複数のストレージユニットのストレージ３２に格納されている１つまたは複数のコンピュータプログラムまたはソフトウェア（ＳＷ）４３（図４も参照）を実行するように設定される。ＳＷ４３は、たとえば、プロセッサ回路によって実行されるときに、本明細書において説明されるサービスアプリケーション２４に将来使用可能な帯域幅を予測するための予測器３４を形成するソフトウェアを備えることができる。ストレージユニット３２は、本明細書において説明されるコンピュータ可読手段４２（図４を参照）と見なされ、たとえばランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリまたはその他のソリッドステートメモリ、もしくはハードディスク、もしくはその組み合わせの形態であってもよい。プロセッサ回路３１はまた、必要に応じて、ストレージ３２にデータを格納するように設定されてもよい。ＮＷノード３はまた、たとえば無線通信インターフェイスを含み、通常は、たとえばデータをＳＰ７から転送するためなど、無線デバイス２との無線通信を可能にするための送受信機およびアンテナを備える、通信インターフェイス３３を備える。

したがって、本開示の態様によれば、通信ネットワーク１のためのノード３が提供される。ノードは、プロセッサ回路３１と、前記プロセッサ回路により実行可能な命令を格納するストレージユニット３２とを備え、それにより前記ノードは、前記ネットワークに接続されている無線デバイス２においてサービスアプリケーション２４に将来使用可能な無線キャリア８の帯域幅の予測を取得するように動作可能である。ノードはまた、サービスアプリケーションのアプリケーションバッファの状況に関する情報を受信するように動作可能である。ノードはまた、取得された予測および受信されたバッファ情報に基づいて、サービスアプリケーションのアプリケーションバッファをいつ満たすべきかについてのサービスアプリケーションへの推奨を準備するように動作可能である。ノードまた、準備された推奨を備える推奨メッセージの無線デバイスへの送信を開始するように動作可能である。

図３ｂは、図３ａのＮＷノード３の一実施形態を機能的に示す概略ブロック図である。前述のように、プロセッサ回路３１は、ノードが本開示の方法の実施形態を実行できるようにするためにソフトウェア４３を実行することができ、それにより機能モジュールが、方法のさまざまなステップを実行するために、ノード３、たとえばプロセッサ回路３１において形成されてもよい。これらのモジュールは、ノード３内のブロックとして概略的に示される。したがって、ＮＷノード３は、将来使用可能な帯域幅の予測を取得するための予測モジュール３６（たとえば、予測器３４を備える）、アプリケーションバッファ状況情報を受信するための受信モジュール３７、推奨を準備するための準備モジュール３８、および推奨メッセージの送信を開始するための送信モジュール３９を備える。

図４はコンピュータプログラム製品４０を示す。コンピュータプログラム製品４０は、コンピュータ実行可能コンポーネント４１／４３の形態をとるコンピュータプログラム４１／４３を備えるコンピュータ可読の（たとえば、不揮発性または非一時的）手段／媒体４２を備える。コンピュータプログラム／コンピュータ実行可能コンポーネントは、デバイス、たとえば本明細書において説明される無線デバイス２またはネットワークノード３に、本開示の方法の実施形態を実行させるように設定されてもよい。コンピュータプログラム／コンピュータ実行可能コンポーネントは、プロセッサ回路２１／３１に方法を実行させるためにデバイス２／３のプロセッサ回路２１／３１上で実行されてもよい。コンピュータプログラム製品４０は、たとえば、デバイス２／３に含まれ、プロセッサ回路２１／３１に関連付けられているストレージユニットまたはメモリ２２／３２に含まれてもよい。あるいは、コンピュータプログラム製品４０は、コンピュータ可読ディスク、たとえばＣＤまたはＤＶＤまたはハードディスク／ドライブのような、もしくはソリッドステートストレージ媒体、たとえばＲＡＭまたはフラッシュメモリのような、別個の、たとえばモバイルのストレージ手段であってもよいか、またはストレージ手段の一部であってもよい。

本開示の態様によれば、通信ネットワーク１のノード３のプロセッサ回路３１上で実行されるとき、ノードに、前記ネットワークに接続されている無線デバイス２においてサービスアプリケーション２４に将来使用可能な無線キャリアの帯域幅の予測を取得させることができるコンピュータプログラムコードを備えるコンピュータプログラム４３が提供される。コードはまた、ノードに、サービスアプリケーションのアプリケーションバッファの状況に関する情報を受信させることができる。コードはまた、ノードに、取得された予測および受信されたバッファ情報に基づいて、サービスアプリケーションのアプリケーションバッファをいつ満たすべきかについてのサービスアプリケーションへの推奨を準備させることができる。コードはまた、ノードに、準備された推奨を備える推奨メッセージの無線デバイスへの送信を開始させることができる。

本開示のもう１つの態様によれば、無線デバイス２のプロセッサ回路２１上で実行されるとき、無線デバイスに、アプリケーションバッファを有するサービスアプリケーション２４を実行させることができるコンピュータプログラムコードを備えるコンピュータプログラム４１が提供される。コードはまた、無線デバイスに、アプリケーションバッファの状況に関する情報を通信ネットワーク１に送信させることができる。コードはまた、無線デバイスに、通信ネットワークから、アプリケーションバッファをいつ満たすべきかについての推奨を備える推奨メッセージを受信させることができる。コードはまた、無線デバイスに、受信した推奨に基づいて、無線デバイスがアプリケーションバッファを満たすであろう時間期間を判定させることができる。コードはまた、無線デバイスに、判定された時間期間中にデータをアプリケーションバッファにダウンロードするためにサービスアプリケーションのサービスプロバイダに要求を送信させることができる。

本開示のもう１つの態様によれば、本開示のコンピュータプログラム４１および／または４３の実施形態と、コンピュータプログラムが格納されるコンピュータ可読手段４２とを備える、コンピュータプログラム製品４０が提供される。

図５は、通信ネットワーク１において、たとえばｅＮＢ、ノードＢ、または無線ネットワークコントローラ（ＲＮＣ）のようなネットワークノード３において、実行される方法の一実施形態を示す概略流れ図である。

無線キャリア８の将来使用可能な帯域幅の予測は、前記ネットワークに接続されている無線デバイス２のサービスアプリケーション２４に対して取得されるＳ１。予測が取得されることは、図５の方法を実行するネットワークノード３が予測を行なうこと、またはネットワークノード３が他の場所から（たとえば、機械学習機能から）、たとえば通信ネットワーク内の別のノードから、または無線デバイス２から、発信される予測に関する情報を受信することを暗示することができる。したがって、予測を行なうための機能は、通信ネットワーク１内に、たとえばＲＡＮ４のｅＮＢまたはＲＮＣと併置されるか、もしくは通信ネットワーク１の外部に、たとえばクラウド機能として位置してもよい。使用可能な帯域幅（ダウンリンクスループット）は、たとえば無線デバイスが接続されている通信ネットワークのセルの予測されるセル負荷に基づいて予測されてもよい。セル負荷は、無線デバイスに接続されているセルに送信するために（たとえば、セルを提供する基地局のような）ネットワークのバッファ内に保持されているデータの量、および前記データの送信のスケジューリングに基づいて予測されてもよい。付加的に、または代替として、予測は、無線デバイス２と基地局３の間の無線接続の品質に基づいてもよい。たとえば無線デバイスが基地局から遠ざかっている場合、使用可能な帯域幅が減少すると予測され得るが、無線デバイスが基地局に近づいている場合、帯域幅は増大すると予測され得る。

予測を取得することＳ１の前、後、または並行して、サービスアプリケーションのアプリケーションバッファの状況に関する情報が受信されるＳ２。無線デバイス２、たとえば無線デバイス内のサービスアプリケーション２４は、そのアプリケーションバッファに関する情報をネットワーク１に（たとえばノード３に）送信することができる。さらに具体的には、状況情報は、アプリケーションバッファにサービスのためにバッファリングされているデータの量に関する情報を備えることができる。サービスがメディアストリーミング向けである場合、状況情報は、バッファリングされたデータが持続するであろう（たとえば、バッファが再度満たされない場合にストリーミングが中断されるまで指定された秒数間メディアストリーミングサービスを提供するために、アプリケーションバッファに現在バッファリングされているメディアデータの量が持続するであろう）ストリーミング時間の長さに関する情報を備えることができる。したがって、状況情報は、無線デバイスがアプリケーションバッファに直ちにデータをダウンロードする必要があるかどうか、または無線デバイスがサービスを中断することなくしばらく待つことができるかどうかについてネットワーク１に通知することができる。

取得されたＳ１予測および受信されたＳ２バッファ情報に基づいて、サービスアプリケーションのアプリケーションバッファをいつ満たすべきかについてのサービスアプリケーション２４への推奨が準備されるＳ３。ネットワーク１、たとえばネットワーク内のノード３は、あらかじめ定められたアルゴリズムを使用して、無線デバイス２がデータ（たとえば、ストリーミングメディアサービスのメディアセグメント）をアプリケーションバッファにいつダウンロードすることが（サービスアプリケーション２４およびネットワークにとって）有利となるかを計算するか、または推測することができる。一般に、帯域幅が限られている場合よりも十分にある場合のほうがデータをダウンロードするのに消費するリソースが少ないので、バッファ状況により無線デバイスが空アプリケーションバッファに起因するサービス中断を生じることなくダウンロードを控えることができるようにすることを前提として、帯域幅がより制限されている場合ではなく、多く使用可能帯域幅がある場合に、主としてデータをダウンロードするよう無線デバイスに提案することは有利である。一部の実施態様において、推奨は、サービスアプリケーション２４によって要求されている場合もある。１つの代替は、サービスアプリケーションがバッファ状況情報を定期的に送信し、ネットワークノード３が必要に応じて推奨を開始する、たとえばさらなる通知があるまでダウンロードを待機する、直ちにダウンロードするなどである。もう１つの代替は、サービスアプリケーション２４がダウンロード情報を要求して、ネットワークノードが応答することである。

次いで、準備されたＳ３推奨を備える推奨メッセージの無線デバイス２への送信は開始される。方法がサービングＲＡＮノード３によって実行される場合、ノードは、推奨メッセージを無線インターフェイスを介して無線デバイス２に送信することができる。それ以外の場合、方法を実行するノードは、サービングＲＡＮノードが推奨メッセージを送信できるようにする情報を提供することができる。推奨メッセージを無線デバイス２に提供することにより、無線デバイス、たとえばサービスアプリケーション２４は、ＳＰ７へのデータセグメントの要求をいつ（どの時点において）スケジュールするかを決定する際に推奨を考慮することができる。

図６は、無線デバイス２において実行される方法の一実施形態を示す概略流れ図である。方法は、ネットワーク側に関して図５の方法に対応することができる。したがって、図５に関連する説明はまた、該当する部分において図６の方法に関連する。

無線デバイス２は、サービスアプリケーション２４を実行しＳ１１、サービスアプリケーションはアプリケーションバッファを有する。これは、アプリケーションＳＷ４４が、サービスアプリケーション２４を形成するためにプロセッサ回路２１によって実行されることを暗示する。

サービスアプリケーションを実行するＳ１１間、無線デバイス２は、アプリケーションバッファの状況に関する情報を通信ネットワークに送信するＳ１２。無線デバイスは、サービスアプリケーション２４を用いて状況情報を取得することができ、次いで状況情報を無線通信インターフェイス２３を介して送信することができる。状況情報は、通信ネットワーク内の任意のノード、たとえばＲＡＮノード３に送信されてもよい。次いで、情報は、無線ベアラでＲＡＮ ＩＰアドレスを備えるＲＡＮ４に宛てられたメッセージで送信されてもよい。ベアラ（たとえば、エボルブドパケットシステム（ＥＰＳ）ベアラ）が無線デバイス２とＣＮ６の間でセットアップされて（ベアラは、たとえばＰＤＮゲートウェイ（ＰＧＷ）で終端することができる）、ＲＡＮ４を介して通過するだけであったとしても、ＲＡＮノード３は、ＲＡＮノードがＲＡＮに宛てられた、状況情報を備えるメッセージを代行受信できるようにするＲＡＮ ＩＰアドレスをリッスン（「スニッフィング」を実行）して、それをベアラから除去することができる。

送信されたＳ１２状況情報に応じて、無線デバイスは、通信ネットワーク１から、アプリケーションバッファをいつ満たすべきかについての推奨を備える推奨メッセージを受信するＳ１３。サービスアプリケーション２４は、スケジューラ２５を用いて、ＳＰ７へのサービスデータの要求をスケジュールする際にこの推奨を考慮することができる。

したがって、無線デバイス２は、通常サービスアプリケーション２４を用いて、受信したＳ１３推奨に基づいて、無線デバイス２がアプリケーションバッファを満たすであろう時間期間を判定するＳ１４。サービスアプリケーション２４は、受信したＳ１３推奨に応じて、時間期間中にサービスデータのダウンロードをスケジュールするよう選択し、別の時間期間中にサービスデータのダウンロードをスケジュールしないように選択することができる。

次いで、無線デバイス２は、判定されたＳ１４時間期間中にデータをアプリケーションバッファにダウンロードするためにサービスアプリケーション２４のサービスプロバイダ７に要求を送信するＳ１５。

概して、ＲＡＮ４は、アプリケーションバッファ状況および無線条件に基づいて、どの無線デバイス２サービスアプリケーション２４が次にそのバッファ（たとえば、専用ベアラで）を満たすかを決定することができる。ＲＡＮ４が、任意の数の無線デバイス２、通常は２つ以上の無線デバイス２にサーブできることに留意されたい。無線デバイス２は、そのバッファ状況についてＲＡＮ４に通知し、ＲＡＮは、新しいコンテンツをいつ要求するのがより最適であるかを無線デバイスに知らせる。このようにすることで、ネットワーク１は、良好な無線条件の間にさらにダウンロードして、混雑状態のダウンロードを回避するように無線デバイスを導くことができるようになる。この手法、つまり、無線デバイス側ではなくネットワーク側にこの機能を有すること、の利点は、ネットワークがダウンリンクをスケジュールして、スケジューラの振る舞いを導くことができること、およびネットワークが任意の他のサービスユーザについての知識を有することである。

無線デバイスモビリティ予測およびセル負荷予測は、カバレッジホールおよびハンドオーバ状態、ならびに場合によっては混雑状態および低負荷の可能性を予期できるようにし、それにより無線デバイスのダウンリンクスループットの関連する次回のドロップおよび次回のスループットピークを予期できるようにする。この情報は、たとえばメディアプレイアウトバッファの状況に関する無線デバイスからの情報と併せて、カバレッジを使い果たす前に、スループットが良好であるときにコンテンツをダウンロードするように、またはより良好な条件に近づくまでダウンロードを控えるように、無線デバイスを作動させて、エンドユーザ品質およびＲＡＮの効率を共に改善するために、ＲＡＮによって使用されてもよい。

本開示の実施形態を用いて、無線デバイス２のメディアコンテンツのダウンロードは、過去の無線条件および負荷ではなく、現在および近い将来の無線条件および負荷に適応され得る。また、ＳＰ７サーバへのメディアコンテンツのアップロードも、同様の方法で適応されてもよい。ダウンロード／アップロードが低負荷および良好な無線条件に向けて導かれるので、これはエンドユーザ品質の向上とＲＡＮ効率の増大を共にもたらすことができる。さらに、アプリケーションバッファのサイズに基づいて固有の無線デバイスのアクションが行なわれて、たとえばサービングセル内の劣悪な無線条件または負荷ピーク時のビデオ機能停止を回避することができるが、これはエンドユーザ体験を高めることにつながる。

本開示のいくつかの実施形態において、バッファ状況情報は、アプリケーションバッファが事前定義されているしきい値を超えて満たされていることを示す。次いで、推奨は、アプリケーションバッファを満たすことを待機せよという推奨を備えることができる。

本開示のいくつかの実施形態において、将来の使用可能な帯域幅は、改善するために予測される。その場合、推奨は、特にバッファが緊急に再度満たされる必要はないようなバッファ状況である場合、アプリケーションバッファを満たすことを待機せよという推奨を備えることができる。

具体的には、アプリケーションバッファが事前定義されているしきい値を超えて満たされていることをバッファ状況情報が示し、かつ将来使用可能な帯域幅が改善すると予測される場合、推奨は、アプリケーションバッファを満たすことを待機せよという推奨を備えることができる。

いくつかの実施形態において、アプリケーションバッファを満たすことを待機せよという推奨は、指定された時間期間を待機せよという推奨を備えることができる。バッファ情報は、たとえば、指定された時間期間中にバッファを再度満たす必要なくサービスを提供するのに十分なデータをバッファが含むようなバッファの状態であることを示した場合もある。

本開示のいくつかの実施形態において、推奨は、指定されたしきい値を超えてアプリケーションバッファを満たせという推奨を備える。しきい値は、たとえば次回の時間期間（前記特定の時間が適応される長さを有する）がデータをバッファにダウンロードするのに好ましくないと予測される場合に、バッファが、特定の時間にわたりサービスを提供可能にするのに十分なデータを保持するようなものであってもよい。

機械学習方法およびパターン認識技法は、ＲＡＮ４内の別のセルへの無線デバイスの移動に関連する無線デバイス２へのスループットの将来の低下、たとえばハンドオーバ（ＨＯ）または間近な状態、を予見することを可能にする。さらに、サービングセル負荷の変動および差し迫った混雑状態を予測することも可能である。

予想されるスループット変動に関する情報、および無線デバイスのアプリケーションバッファ状況の知識は、固有の無線デバイス２にとっていつダウンロードするのがより好ましいか、および特に重大なバッファレベルを体験しないようにいつダウンロードすることが最重要となるかを推定することができるようにする。さらに、低スループットであるため、ダウンロードが推奨されない期間を指摘することも可能である。

固有の時点においてダウンロードするかどうかは、バッファ状況および予測されたスループットに関する情報を使用することによって決定されてもよい。サービスが、たとえばカバレッジの不足による、スループットの一時的低下を切り抜けることができる場合、無線デバイスは、より良好なスループットが提供されるまでダウンロードを行なわないよう求められてもよい。別の状況において、無線デバイスは、劣悪なカバレッジまたは次回のハンドオーバによりスループットが低下する前に、あらかじめそのバッファを満たすよう求められてもよい。

基本ダウンロードルールの例：
予測される高スループット−＞アプリケーションバッファが許容する限りダウンロードする
予測される低スループットおよび事前定義されているしきい値を超えるバッファ状況−＞より良好な条件が提供されるまでダウンロードを控える
予測される低スループットおよび低バッファ状況−＞次回の低スループットを切り抜けるのに十分なコンテンツをすばやくダウンロード／場合によってはメディアレート低下による停止

予測の数に基づいて、最も好ましいダウンロード機会が推定されてもよい。ダウンロードする決定は、予測および、たとえばアプリケーションバッファ状況に基づく。予測は、たとえばスライディングウィンドウの手法により、継続的に繰り返される。

アルゴリズムは、図７および図８におけるような外観であってもよく、ここでＰｘは、たとえば、１００ｍｓ、２ｓ、４ｓに対応する３つの次回の期間０．１、２、および４の平均予測スループットである。図７は、プリバッファリングによる状況に関連する。Ｐは、さまざまな時間間隔の予測平均スループットである。さまざまな時間間隔の予測された値に基づいて、さらに多くのコンテンツをプリバッファする決定が行なわれる（点線は、従来技術によりどのように機能するかを示し、実線は、本開示によりどのように機能するかを示す）。サービスプレイアウトは、劣悪な無線条件を切り抜ける。図８は、延期による状況に関連する。Ｐは、さまざまな時間間隔の予測平均スループットである。さまざまな時間間隔の予測された値に基づいて、さらに多くの帯域幅がサービスアプリケーションに使用可能になるまでコンテンツのダウンロードを延期する決定が行なわれる（点線は、従来技術によりどのように機能するかを示し、実線は、本開示によりどのように機能するかを示す）。さらに多くのスループットが使用可能になるまで送信が延期される場合、消費されるリソースは少なくなる。

アルゴリズムは概して、以下のように設定されてもよい。
以下の場合、次のセグメントのダウンロードを延期する
Ｐ_０．１＜＜Ｐ_２
かつ以下の場合、
バッファ状況＞延期しきい値

アプリケーションバッファが、たとえば２秒よりも多い、サービスプレイアウトを切り抜けさせるためにバッファ内に十分なコンテンツがあることを保証するしきい値を超えて満たされ、スループットが大幅に増大すると予測される場合、現在のビデオセグメントのダウンロードは、この場合は２秒の時間フレームと予測される、使用可能なスループットが増大するまで延期される。

スループットが安定しているかまたは徐々に増加すると予測される場合、メディアセグメントのダウンロードは、バッファ状況レベルにより示された通常のペースに従う。

以下の場合、次のセグメントをプリバッファリングする
Ｐ_０．１＞Ｐ_２
かつ以下の場合、
バッファ状況＜プリバッファリングしきい値

言い換えれば、使用可能なスループットが現在、たとえば今後２秒間のスループットよりも高い場合、つまりスループットが減少すると予測される場合、およびサービスアプリケーション２４のバッファ状況がプリバッファリングしきい値よりも低い場合、次のビデオセグメントをダウンロードする。プリバッファリングしきい値は、ビデオフレームのフリーズを回避するため、いつ次のセグメントがダウンロードされ得るかに関してバッファを空けるために要する時間によって規定されてもよい。バッファがこのしきい値を超える場合、サービスプレイアウトが２秒よりも長く切り抜けることが保証される。プリバッファリングしきい値は通常、延期しきい値よりも高い。

この手順は、今後のＮ個のセグメントにわたり繰り返されてもよい。たとえば、より長いスループット停止を伴う次回のハンドオーバが予測される場合、より長い停止を切り抜けるために複数のセグメントがプリバッファリングされてもよい。第２の次のセグメントの例示の手順は以下のとおりである。

以下の場合、第２の次のセグメントをプリバッファリングする
Ｐ_２＞Ｐ_４かつ＜Ｐ_４＜必要なメディアレート
以下の場合、スループット停止の最後まで今後のＮ個のセグメントについて第３の次のセグメントなどもプリバッファリングする。
Ｐ_０．１＞Ｐ_２＞Ｐ_４≧Ｐ_５かつＰ_４およびＰ_５＜必要なメディアレート

今後の２秒のほうが将来のより遠いほうよりもスループットが高いと予測され、将来のスループットが実際のメディアレート、つまりサービスプレイアウトレートよりも低いと予想される場合、メディアは、ビデオを機能停止するリスクを生じることなくスループットの予期される低下を切り抜けるために、今後のセグメントについてもあらかじめダウンロードされるべきである。

以下の場合、メディアレートの低減を開始する。
Ｐ_１Ｘ×ｔ_２＜メディアレート×ｔ_２−バッファ

使用可能なスループットが低く、ビデオコンテンツの機能停止がプリバッファリングでは回避され得ない場合、メディアレートは、ビデオセッションが一時的なスループット停止を切り抜けるために低減される必要がある。それはつまり、アプリケーションバッファが最大達成可能ダウンロードレートよりも速く、バッファが満たされる（ビデオが機能停止されるリスクが生じることを意味する）よりも速く空にされる場合、メディアレートの低減を開始することである。

機能は、予測されるスループット停止の長さを、およびスループットの予測されるピークの長さを考慮することによっても増強されてもよい。ネットワーク容量は現在、サービスアプリケーションが悪条件において低いプレイアウトレートのメディアをダウンロードしバッファをそのメディアで満たすことによって浪費され、次いで条件が改善すると、以前ダウンロードされた低レートメディアはただ使い捨てられて、バッファは高品質のメディア（高プレイアウトレート）で再び満たされる。スループット（つまり帯域幅）が低い間ダウンロードが保留され、次いで可能な限り速やかにより高い品質のメディアで続行されるとすれば、つまりより良好な条件が十分な確実性を伴って予測され得る場合、はるかに効率が高まることになる。これはつまり、上記で示されているように、時間０から時間４までの平均スループットを予測するのではなく、スループットは、時間０から時間２、および時間２から時間４、および時間４から時間６などというように予測されるべきである。当然、時間間隔は、任意のサイズであってもよい。スループット予測は、上記で示されているように、スライディングウィンドウの手順により継続的に更新されてもよく、予測更新の間隔は、たとえば秒単位ではなく１００ｍｓのような、予測が行なわれる時間間隔の長さよりもはるかに小さくてもよい。

ダウンロードルールはまた、コンテンツ適応へのアクションと組み合わされてもよく、たとえばスループットの深刻な低下が予測される場合、スループットが低下する前に可能な限り多くのメディアをダウンロードし、それによりエンドユーザ体感への低スループットの影響を緩和できるようにするため、コンテンツはすでに前もって低プレイアウトレートに適応されてもよい。

図９を参照すると、スループット予測器３４は、履歴データの統計的分析により、たとえば数秒のような近い将来、およびたとえば１０ｓのようなより長い時間間隔にわたる各無線デバイス２（たとえば、ＲＡＮノード３に接続されている各無線デバイス）のスループットを予測することができる。次いで、予測されるスループットは、無線デバイスのアプリケーションメディアプレイアウトバッファの知識と併せて、無線デバイスにとってコンテンツデータまたはコンテンツデータのチャンクをいつダウンロードするのが最も好ましいかを見つけ出すために準備モジュール３８によって使用されてもよい。

スループット予測器３４はまた、ハンドオーバなどに起因する重大なスループットの低下を予見することもできる。準備モジュール３８は、アプリケーションメディアプレイアウトバッファを考慮に入れ、メディアプレイアウトが（アプリケーションバッファのサイズによって決まる）着信メディアの一時的保留を切り抜ける可能性、または無線デバイス２がスループット低下の前にバッファを迅速に満たす可能性に基づいて、ダウンロードを強制する（１つまたは複数のセグメントをプリバッファリングする）か、またはダウンロードを一時的に保留にする（スループットが増大するまでダウンロードを延期する）かどうかについて決定が行なわれる。

入力トラフィックパターンは通常、到着時間の間のアップリンクおよびダウンリンク履歴、メディアセグメントサイズ、ならびに固有の無線デバイス２の各チャンクをダウンロードする時間から成る。

モビリティパターンは、アップリンクおよびダウンリンクの、信号強度および固有の無線デバイスの信号対干渉比の履歴で構成されてもよい。モビリティパターンはまた、ＨＯ履歴を考慮することができる。

さらなる機能強化のために、最近ドロップされたパケットおよび再送信レートなどに関する情報を含むことも可能である。

セル負荷履歴は、時間の経過に伴う負荷の変動とソースの利用状況、ならびにサービングセルにおいて接続されている加入者の数、および合計スループット、およびサービス加入者あたりの平均スループットを含むことができる。

時間の経過に伴うスループットの予測は、その最も簡単な形態で、単に、たとえば現在から数秒先までの、固有の時間フレームにわたる平均スループットの標識である。この予測はまた、迅速にダウンロードするか待機すること、およびコンテンツを適応するかどうかの重要性を知らせる、スループットの継続的な低下または増大を示すスループット導関数のような、スループットの変動を含むことができる。時間の経過に伴うスループットのもう１つの代替は、たとえば差し迫ったハンドオーバにおける、一時スループット停止の長さである。

後段において、本開示のいくつかのその他の態様が続く。

本開示の態様によれば、通信ネットワーク１のためのノード３が提供される。ノードは、前記ネットワークに接続されている無線デバイス２においてサービスアプリケーション２４に将来使用可能な無線キャリア８の帯域幅の予測を取得するＳ１ための手段（たとえば、予測モジュール３６および／または予測器３４）を備える。ノード３はまた、サービスアプリケーションのアプリケーションバッファの状況に関する情報を受信するＳ２ための手段（たとえば、受信モジュール３７および／または通信インターフェイス３３）を備える。ノード３はまた、取得されたＳ１予測および受信されたＳ２バッファ情報に基づいて、サービスアプリケーションのアプリケーションバッファをいつ満たすべきかについてのサービスアプリケーションへの推奨を準備するＳ３ための手段（たとえば、準備モジュール３８）を備える。ノード３はまた、準備されたＳ３推奨を備える推奨メッセージの無線デバイス２への送信を開始するＳ４ための手段（たとえば、送信モジュール３９および／または通信インターフェイス３３）を備える。

本開示のもう１つの態様によれば、通信ネットワーク１を介する通信のための無線デバイス２が提供される。無線デバイスは、アプリケーションバッファを有するサービスアプリケーション２４を実行するＳ１１ための手段（たとえば、アプリケーション実行モジュール２６）を備える。無線デバイスはまた、アプリケーションバッファの状況に関する情報を通信ネットワーク１に送信するＳ１２ための手段（たとえば、送信モジュール２７および／または無線通信インターフェイス２３）を備える。無線デバイスはまた、通信ネットワーク１から、アプリケーションバッファをいつ満たすべきかについての推奨を備える推奨メッセージを受信するＳ１３ための手段（たとえば、受信モジュール２８および／または無線通信インターフェイス２３）を備える。無線デバイス２はまた、受信したＳ１３推奨に基づいて、無線デバイス２がアプリケーションバッファを満たすであろう時間期間を判定するＳ１４ための手段（たとえば、判定モジュール２９および／またはスケジューラ２５）を備える。無線デバイスはまた、判定されたＳ１４時間期間中にデータをアプリケーションバッファにダウンロードするためにサービスアプリケーション２４のサービスプロバイダ７に要求を送信するＳ１５ための手段（たとえば、送信モジュール２７および／または無線通信インターフェイス３３）を備える。

本開示は、主として、いくつかの実施形態を参照して上記で説明された。しかし、当業者によって容易に理解されるように、上記で開示されている実施形態以外の他の実施形態は、添付の特許請求の範囲によって規定される本開示の概念の範囲内で同等に可能である。

Claims (13)

1. 通信ネットワーク（１）のノード（３）において実行される方法であって、
   前記ネットワークに接続されている無線デバイス（２）においてサービスアプリケーション（２４）に将来使用可能な無線キャリア（８）の帯域幅の予測を取得すること（Ｓ１）と、
   前記サービスアプリケーションのアプリケーションバッファの状況に関する情報を受信すること（Ｓ２）と、
   前記取得された（Ｓ１）予測および前記受信された（Ｓ２）バッファ情報に基づいて、前記サービスアプリケーションのアプリケーションバッファをいつ満たすべきかについての前記サービスアプリケーションへの推奨を準備すること（Ｓ３）と、
   前記準備された（Ｓ３）推奨を備える推奨メッセージの前記無線デバイスへの送信を開始すること（Ｓ４）と
   を備える、方法。
2. 前記アプリケーションバッファが事前定義されているしきい値を超えて満たされていることを前記バッファ情報が示す場合、前記推奨は、前記アプリケーションバッファを満たすことを待機せよという推奨を備える、請求項１に記載の方法。
3. 前記将来使用可能な帯域幅が改善すると予測される場合、前記推奨は、前記アプリケーションバッファを満たすことを待機せよという推奨を備える、請求項１または２に記載の方法。
4. 前記推奨は、指定された時間期間待機せよという推奨を備える、請求項２または３に記載の方法。
5. 前記推奨は、指定されたしきい値を超えて前記アプリケーションバッファを満たせという推奨を備える、請求項１に記載の方法。
6. 前記サービスアプリケーション（２４）は、ストリーミングメディア向けである、請求項１から５のいずれか一項に記載の方法。
7. 前記ノードは、無線アクセスネットワーク（ＲＡＮ）ノード（３）である、請求項１から６のいずれか一項に記載の方法。
8. 通信ネットワーク（１）のノード（３）であって、
   プロセッサ回路（３１）と、
   前記プロセッサ回路により実行可能な命令（４３）を格納するストレージユニット（３２）であって、それにより前記ノードは、
   前記通信ネットワークに接続されている無線デバイス（２）においてサービスアプリケーション（２４）に将来使用可能な無線キャリア（８）の帯域幅の予測を取得し、
   前記サービスアプリケーションのアプリケーションバッファの状況に関する情報を受信し、
   前記取得された予測および前記受信されたバッファ情報に基づいて、前記サービスアプリケーションのアプリケーションバッファをいつ満たすべきかについての前記サービスアプリケーションへの推奨を準備し、
   前記準備された推奨を備える推奨メッセージの前記無線デバイスへの送信を開始する
   ように動作可能である、ストレージユニットと
   を備える、ノード。
9. 通信ネットワーク（１）に接続された無線デバイス（２）において実行される方法であって、
   アプリケーションバッファを有するサービスアプリケーション（２４）を実行する（Ｓ１１）ことと、
   前記アプリケーションバッファの状況に関する情報を前記通信ネットワークに送信すること（Ｓ１２）と、
   前記通信ネットワークから、前記アプリケーションバッファをいつ満たすべきかについての推奨を備える推奨メッセージを受信すること（Ｓ１３）と、
   前記受信した（Ｓ１３）推奨に基づいて、前記無線デバイスが前記アプリケーションバッファを満たすであろう時間期間を判定すること（Ｓ１４）と、
   前記判定された（１４）時間期間中にデータを前記アプリケーションバッファにダウンロードするために前記サービスアプリケーションのサービスプロバイダ（７）に要求を送信すること（Ｓ１５）と
   を備える、方法。
10. 通信ネットワーク（１）を介して通信するための無線デバイス（２）であって、
    プロセッサ回路（２１）と、
    前記プロセッサ回路により実行可能な命令（４１）を格納するストレージユニット（２２）であって、それにより前記無線デバイスは、
    アプリケーションバッファを有するサービスアプリケーション（２４）を実行し、
    前記アプリケーションバッファの状況に関する情報を前記通信ネットワークに送信し、
    前記通信ネットワークから、前記アプリケーションバッファをいつ満たすべきかについての推奨を備える推奨メッセージを受信し、
    前記受信した推奨に基づいて、前記無線デバイスが前記アプリケーションバッファを満たすであろう時間期間を判定し、
    前記判定された時間期間中にデータを前記アプリケーションバッファにダウンロードするために前記サービスアプリケーションのサービスプロバイダ（７）に要求を送信する
    ように動作可能である、ストレージユニットと
    を備える、無線デバイス。
11. コンピュータプログラムコードを備える、コンピュータプログラム（４３）であって、前記コンピュータプログラムコードは、通信ネットワーク（１）のノード（３）のプロセッサ回路（３１）上で実行されるとき、前記ノードに、
    前記通信ネットワークに接続されている無線デバイス（２）においてサービスアプリケーション（２４）に将来使用可能な無線キャリア（８）の帯域幅の予測を取得させ（Ｓ１）、
    前記サービスアプリケーションのアプリケーションバッファの状況に関する情報を受信させ（Ｓ２）、
    前記取得された（Ｓ１）予測および前記受信された（Ｓ２）バッファ情報に基づいて、そのアプリケーションバッファをいつ満たすべきかについての前記サービスアプリケーションへの推奨を準備させ（Ｓ３）、
    前記準備された（Ｓ３）推奨を備える推奨メッセージの前記無線デバイスへの送信を開始させる（Ｓ４）
    ことができる、コンピュータプログラム（４３）。
12. コンピュータプログラムコードを備える、コンピュータプログラム（４１）であって、前記コンピュータプログラムコードは、無線デバイス（２）のプロセッサ回路（２１）上で実行されるとき、前記無線デバイスに、
    アプリケーションバッファを有するサービスアプリケーション（２４）を実行させ（Ｓ１１）、
    前記アプリケーションバッファの状況に関する情報を通信ネットワークに送信させ（Ｓ１２）、
    前記通信ネットワークから、前記アプリケーションバッファをいつ満たすべきかについての推奨を備える推奨メッセージを受信させ（Ｓ１３）、
    前記受信した推奨に基づいて、前記無線デバイスが前記アプリケーションバッファを満たすであろう時間期間を判定させ（Ｓ１４）、
    前記判定された時間期間中にデータを前記アプリケーションバッファにダウンロードするために前記サービスアプリケーションのサービスプロバイダ（７）に要求を送信させる（Ｓ１５）
    ことができる、コンピュータプログラム（４１）。
13. 請求項１１または１２に記載のコンピュータプログラムが格納されるコンピュータ可読ストレージ媒体（４２）。

Images