JP6029755B2 - ネットワーク支援されたデータ転送スケジューリングのための方法および装置 - Google Patents

Description

本発明の例示の実施形態は、全般的に、データ転送のための技術に関し、特に、クラウド・サービス・サポートなどのためにデータ転送をスケジューリングする方法および装置に関する。

背景

クラウド・コンピューティングは、インターネットなどのネットワーク接続を介して共有リソースがデバイスに提供されることを可能にする。例えばクラウド・コンピューティングは、例として、計算、ソフトウェア・アプリケーション、データ・アクセス、ロケーション、コマース、またはストレージ・サービスなどを提供することができる。これらサービスのエンド・ユーザは、サービスを配信するクラウド・コンピューティング・システムの物理的な位置についても構成についても認識する必要がない場合もある。一部のエンド・ユーザは、セルラ・ネットワークまたはＷＬＡＮ（ｗｉｒｅｌｅｓｓ ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ：無線ローカル・エリア・ネットワーク）などを介して、クラウド・コンピューティング・サービスに無線アクセスすることさえできる。

無線デバイスには、選択可能な接続性オプションが複数あることもある。各接続性オプションは、サービス品質（ＱＯＳ：ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ）、電力消費などの面で異なる特徴を有することもある。時とともに、さらなる技術が利用可能になるにつれて、こうした利用可能な接続性オプションの数は増加の一途をたどるであろう。例として、新技術による、帯域の組み合わせおよび複信モードがある。これらオプションが増加するのに伴い、クラウド・コンピューティング・サービスに関連するデータ送信のスケジューリングが複雑化する可能性がある。したがって、特に複数のアクセス・ポイントおよび／または複数のＲＡＴ（ｒａｄｉｏ ａｃｃｅｓｓ ｔｅｃｈｎｏｌｏｇｙ：無線アクセス技術）が利用可能であるときに、当該トラフィックを効率的にスケジューリングすることが課題となる。

摘要

したがって、本発明の例示の実施形態によれば、クラウド・サービスのためのサポートをスケジューリングするための方法、装置、およびコンピュータ・プログラム製品が提供される。この関連で、一実施形態の方法、装置、およびコンピュータ・プログラム製品は、クラウド・サービスまたはその他大量の非緊急データ転送などの大量データ転送をサポートするよう求めるリクエストに対処するための容量の通知（ｉｎｄｉｃａｔｉｏｎ）をユーザ機器に提供することにより、ネットワーク・アクセス・ポイントの支援によってクラウド・サービスが効率的にスケジューリングされることを可能にしてもよい。このようにして、本方法、装置、およびコンピュータ・プログラムは、アクセス・ポイントからのサポートを待つかどうか、別のアクセス・ポイントへハンドオーバするかどうか、またはサポート・リクエストを遅延させるかどうかなどのスケジューリングの決定が、ユーザ機器またはアクセス・ポイントによって、より効果的に下されることを可能にし得る。なお、本発明の適用範囲は、クラウド・サービスに限定されず、例えばソフトウェア更新、バックアップ、デバイス・カメラを用いて撮影された写真などのコンテンツの同期化、地図コンテンツのダウンロード、または大量データの転送を含む任意の非緊急バックグラウンド・タスクなど、他のタイプのトラフィックまたはサービスにも適用可能である。言い換えれば、ＵＥは、その非緊急大量データ・タスク（例えばソフトウェア更新、バックアップ、デバイス・カメラを用いて撮影された写真などのコンテンツの同期化、アプリケーションのダウンロード、地図コンテンツのダウンロード、クラウドとの文書の同期化）をスケジューリングするために、ネットワークからのサポート／支援をリクエストする。それに応答して、ネットワークは、例えばリンク品質、ＵＥ移動状態、ネットワーク負荷、トラフィックなどに基づいて、長期的なタスク・スケジューリングを適用し、前記タスクをいつ開始するかについての、ＵＥによる自律的決定を改善することを可能にする。

一実施形態では、タスクに関連するデータの量の通知、またはタスクの緊急性の通知のうちの少なくとも一方を含むサポート・リクエストを送信させることを含む方法が提供される。本方法は、通知メッセージを受信することと、通知メッセージに少なくとも部分的に基づいて、タスクを待つか、または拒否するかを決定することとをさらに含む。別の実施形態によれば、本方法は、タスクを待つと決定された場合に、１つ以上のアイドル機能を実行することと；準備完了通知を受信することと；タスクに進むか、またはキャンセルするかを決定することと；タスクに進むと決定された場合に、承諾通知を送信させることと、タスクに関連するデータを受信するか、または該データの送信を生じさせることとをさらに含んでもよい。

別の実施形態では、タスクに関連するデータの量の通知、またはタスクの緊急性の通知のうちの少なくとも一方を含むサポート・リクエストを受信することを含む方法が提供される。本方法は、サポート・リクエストに基づいて、タスクをサポートするための容量を求めることと、容量の通知を含む通知メッセージを送信させることと、タスクのサポートが開始可能であるかどうかを判断することとをさらに含む。本方法は、タスクのサポートが開始可能であると判断された場合に、準備完了通知を送信させることと、承諾通知が受信された場合に、タスクに関連するデータを受信するか、または該データの送信を生じさせることによって、タスクをサポートすることとをさらに含む。

さらなる実施形態では、少なくとも１つのプロセッサと、プログラム・コード命令を含む少なくとも１つのメモリとを備える装置が提供され、少なくとも１つのメモリおよびプログラム・コード命令は、プロセッサとともに、装置に少なくとも、タスクに関連するデータの量の通知、またはタスクの緊急性の通知のうちの少なくとも一方を含むサポート・リクエストを送信させるように命令するよう構成される。装置には、通知メッセージを受信することと、通知メッセージに少なくとも部分的に基づいて、タスクを待つか、または拒否するかを決定することとをさらに行わせる。別の実施形態によれば、装置には、タスクを待つと決定された場合に、１つ以上のアイドル機能を実行することと；準備完了通知を受信することと；タスクに進むか、またはキャンセルするかを決定することと；タスクに進むと決定された場合に、承諾通知を送信させることと、タスクに関連するデータを受信するか、または該データの送信を生じさせることとをさらに行わせてもよい。

別の実施形態では、少なくとも１つのプロセッサと、プログラム・コード命令を含む少なくとも１つのメモリとを備える装置が提供され、少なくとも１つのメモリおよびプログラム・コード命令は、プロセッサとともに、装置に少なくとも、タスクに関連するデータの量の通知、またはタスクの緊急性の通知のうちの少なくとも一方を含むサポート・リクエストを受信するように命令するよう構成される。装置には、サポート・リクエストに基づいて、タスクをサポートするための容量を求めることと、容量の通知を含む通知メッセージを送信させることと、タスクのサポートが開始可能であるかどうかを判断することとをさらに行わせる。装置には、タスクのサポートが開始可能であると判断された場合に、準備完了通知を送信させることと、承諾通知が受信された場合に、タスクに関連するデータを受信するか、または該データの送信を生じさせることによって、タスクをサポートすることとをさらに行わせる。

さらなる実施形態では、プログラム・コード部分を記憶する非一時的コンピュータ可読媒体を含むコンピュータ・プログラム製品が提供される。コンピュータ・プログラム・コード命令は、実行されると、装置に少なくとも、タスクに関連するデータの量の通知、またはタスクの緊急性の通知のうちの少なくとも一方を含むサポート・リクエストを送信させるように命令するよう構成される。装置には、通知メッセージを受信することと、通知メッセージに少なくとも部分的に基づいて、タスクを待つか、または拒否するかを決定することとをさらに行わせる。別の実施形態によれば、コンピュータ・プログラム・コード命令は、実行されると、装置に、タスクを待つと決定された場合に、１つ以上のアイドル機能を実行することと；準備完了通知を受信することと；タスクに進むか、またはキャンセルするかを決定することと；タスクに進むと決定された場合に、承諾通知を送信させることと、タスクに関連するデータを受信するか、または該データの送信を生じさせることとをするように命令するようさらに構成されてもよい。

別の実施形態では、プログラム・コード部分を記憶する非一時的コンピュータ可読媒体を含むコンピュータ・プログラム製品が提供される。コンピュータ・プログラム・コード命令は、実行されると、装置に少なくとも、タスクに関連するデータの量の通知、またはタスクの緊急性の通知のうちの少なくとも一方を含むサポート・リクエストを受信するように命令するよう構成される。装置には、サポート・リクエストに基づいて、タスクをサポートするための容量を求めることと、容量の通知を含む通知メッセージを送信させることと、タスクのサポートが開始可能であるかどうかを判断することとをさらに行わせる。装置には、タスクのサポートが開始可能であると判断された場合に、準備完了通知を送信させることと、承諾通知が受信された場合に、タスクに関連するデータを受信するか、または該データの送信を生じさせることによって、タスクをサポートすることとをさらに行わせる。

さらなる実施形態では、タスクに関連するデータの量の通知、またはタスクの緊急性の通知のうちの少なくとも一方を含むサポート・リクエストを送信させる手段を備える装置が提供される。装置は、通知メッセージを受信する手段と、通知メッセージに少なくとも部分的に基づいて、タスクを待つか、または拒否するかを決定する手段とをさらに備える。別の実施形態によれば、装置は、タスクを待つと決定された場合に、１つ以上のアイドル機能を実行し；準備完了通知を受信し；タスクに進むか、またはキャンセルするかを決定し；タスクに進むと決定された場合に、承諾通知を送信させ、タスクに関連するデータを受信するかまたは該データの送信を生じさせる手段をさらに備えてもよい。

別の実施形態では、タスクに関連するデータの量の通知、またはタスクの緊急性の通知のうちの少なくとも一方を含むサポート・リクエストを受信する手段を備える装置が提供される。装置は、サポート・リクエストに基づいて、タスクをサポートするための容量を求める手段と、容量の通知を含む通知メッセージを送信させる手段と、タスクのサポートが開始可能であるかどうかを判断する手段とをさらに備える。装置は、タスクのサポートが開始可能であると判断された場合に、準備完了通知を送信させる手段と、承諾通知が受信された場合に、タスクに関連するデータを受信するか、または該データの送信を生じさせることによって、タスクをサポートする手段とをさらに備える。

別の実施形態では、ユーザ機器および第１アクセス・ポイントを備えるシステムが提供される。ユーザ機器は、少なくとも１つの第１プロセッサと、第１プログラム・コード命令を記憶する少なくとも１つの第１メモリとを有する第１装置を有する。少なくとも１つの第１メモリおよび第１プログラム・コード命令は、少なくとも１つの第１プロセッサとともに、第１装置に少なくとも、タスクに関連するデータの量の通知、またはタスクの緊急性の通知のうちの少なくとも一方を含むサポート・リクエストを第１アクセス・ポイントへ送信させることを行わせるよう構成される。第１装置には、第１アクセス・ポイントから容量の通知を受信することと、通知メッセージに少なくとも部分的に基づいて、タスクを待つか、または拒否するかを決定することとをさらに行わせる。第１装置には、タスクを待つか、または拒否すると決定された場合に、１つ以上のアイドル機能を実行することと、第１アクセス・ポイントから準備完了通知を受信することと、タスクに進むか、またはキャンセルするかを決定することと；タスクに進むと決定された場合に、承諾通知を送信させることとをさらに行わせる。第１アクセス・ポイントは、少なくとも１つの第２プロセッサと、第２プログラム・コード命令を記憶する少なくとも１つの第２メモリとを有する第２装置を有する。少なくとも１つの第２メモリおよび第２プログラム・コード命令は、少なくとも１つの第２プロセッサとともに、第２装置に少なくとも、サポート・リクエストを受信することと；サポート・リクエストに基づいて、タスクをサポートするための容量を求めることと；容量の通知を含む通知メッセージを送信させることと；タスクのサポートが開始可能であるかどうかを判断することとを行わせるよう構成される。第２装置には、タスクのサポートが開始可能であると判断された場合に、準備完了通知を送信させることと、承諾通知が受信された場合に、タスクに関連するデータを受信するかまたは送信させることによって、タスクをサポートすることとをさらに行わせる。

以上、本発明の例示の実施形態について概括的に記載した。以下では添付の図面を参照する。図面は、必ずしも一定の縮尺で描かれてはいない。

本発明の例示の実施形態をサポートできるシステムの略図である。 本発明の例示の実施形態を実装するよう構成され得るユーザ機器のブロック図である。 電子デバイスにより具現化されても、または電子デバイスに関連してもよく、かつ本発明の例示の実施形態を実装するよう構成されてもよい装置のブロック図である。 本発明の実施形態に従って実行される動作を、ユーザ機器に関連する装置の観点から示すフローチャートである。 本発明の実施形態に従って実行される動作を、アクセス・ポイントに関連する装置の観点から示すフローチャートである。 本発明の実施形態による例示の信号フローを示すシグナリング図である。

詳細説明

以下、本発明の、すべてではないがいくつかの実施形態が示されている添付の図面を参照しながら、本発明の一部の実施形態について、以下さらに深く説明する。実際には、本発明の様々な実施形態は、異なる多数の形態で具現化できるものであり、本願明細書に記載される実施形態に限定されると解釈されてはならない。正確には、これらの実施形態は、本開示が関連する法的要件を充足するように提供されるものである。同じ参照数字は、全体にわたって同じ構成要素を指す。本発明の実施形態によれば、本願明細書で使用される「データ」、「コンテンツ」、「情報」という用語、および同様の用語は、送信、受信、処理、および／または記憶が可能なデータを指すよう、置き換え可能なように用いることができる。したがって、そのような用語のいずれかを使用することが、本発明の実施形態の意図および範囲を限定すると見なされてはならない。

さらに、本願明細書で使用される「回路」という用語は、（ａ）ハードウェアのみの回路実装（例えば、アナログ回路および／またはデジタル回路における実装）；（ｂ）本願明細書に記載の１つ以上の機能を装置に実行させるよう協働する、回路と、１つ以上のコンピュータ可読メモリ上に記憶されたソフトウェアおよび／またはファームウェア命令を含むコンピュータ・プログラム製品（単数または複数）との組み合わせ；および（ｃ）ソフトウェアまたはファームウェアが物理的に存在しなくても、動作のためにソフトウェアまたはファームウェアを必要とする、例えばマイクロプロセッサ（単数または複数）またはマイクロプロセッサ（単数または複数）の一部などの回路を指す。「回路」のこの定義は、任意の特許請求の範囲を含め、本願明細書におけるこの用語の使用すべてに当てはまる。さらなる例として、本願明細書で使用される「回路」という用語は、１つ以上のプロセッサおよび／またはその一部（単数または複数）ならびに付随するソフトウェアおよび／またはファームウェアを含む実装も含む。別の例として、本願明細書で使用される「回路」という用語は、例えば、モバイル電話のベースバンド集積回路もしくはアプリケーション・プロセッサ集積回路、またはサーバ、セルラ・ネットワーク・デバイス、その他ネットワーク・デバイス、および／またはその他コンピューティング・デバイス内の同様の集積回路も含む。

本願明細書に定義されるように、物理的なストレージ媒体（例えば揮発性または不揮発性メモリ・デバイス）を指す「コンピュータ可読ストレージ媒体」は、電磁信号を指す「コンピュータ可読送信媒体」とは区別できる。

後述のように、例えばクラウド・サービス、または大量のデータを含むこともある非緊急データ転送、もしくは追加容量を確保せずにリクエストされた時間内での完了を期待できないほど大きな緊急データ転送などの他のタスクのサポートなどをスケジューリングするための方法、装置、およびコンピュータ・プログラム製品が提供される。本願明細書で用いるとき、例えばクラウド・サービスまたはその他タイプのデータ転送タスクなどのタスクのスケジューリングは、容量の確保、優先順位の管理、さらにその他、タスクを支援またはサポートする手段を含むと解釈されるべきである。さらに、当然のことながら、本願明細書で用いるとき、クラウド・サービスは、本発明の実施形態から利益を受けることができる、データ転送を伴うタスクの一例でしかない。したがって、クラウド・サービスまたはクラウド・サービス・タスクという用語の使用は、限定的に理解されてはならないが、データの転送を伴う、考えられる任意のタスクを含むと解釈されるべきである。この関連で、一実施形態の方法、装置、およびコンピュータ・プログラム製品は、クラウド・サービスをサポートするよう求めるリクエストに対処するための通知メッセージをユーザ機器に提供することによって、例えば負荷分散、ハンドオーバ、または同様のものを処理するよう構成され得るサーバ、移動性管理エンティティ（ＭＭＥ：ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｅｎｔｉｔｙ）などの１つ以上のネットワーク・アクセス・ポイントまたは１つ以上の他のネットワーク構成要素などを介したネットワークの支援を受けて、クラウド・サービスが効率的にスケジューリングされることを可能にしてもよい。このように、本方法、装置、およびコンピュータ・プログラムは、アクセス・ポイントもしくはネットワークからのサポートを待つかどうか、別のアクセス・ポイントもしくはネットワークへハンドオーバするかどうか、またはリクエストされたタスクを遅延させるかどうかなどのスケジューリングの決定が、ユーザ機器またはアクセス・ポイントによって、より効果的に下されることを可能にし得る。アクセス・ポイントまたはネットワークによってＵＥに与えられるサポートは、例えば、追加容量の確保、または向上したサービス優先順位もしくはサービス品質もしくはサービス品質保証、またはアクセス・ポイントもしくはネットワークの負荷がより低いときにタスクをスケジューリングすることで向上した電力効率、またはサービスを提供されるＵＥすべてのタスクを効率的に（例えば重複しない形で）スケジューリングすることで向上した電力効率、またはより適切なセルへのハンドオーバ、または利用可能な容量もしくはデータ転送速度の通知、またはいつタスクの開始もしくは完了が可能か、もしくはどのくらいの間タスクが続くかの通知もしくは推定、またはＵＥが代わりの接続性を発見しない場合、リクエストされた時間内にタスクが完了できない（もしくはできる）という通知、または状況が変化した場合における、前に与えられた推定に対する更新のシグナリングとしてもよい。

図１は、本発明の実施形態から利益を受けることができるシステムのブロック図を示す。図１は、そのようなシステムの構成の一例を示すが、本発明の実施形態は、他の多数のシステム構成に実装され得る。なお、図１に関して、システムは、第１アクセス・ポイント１２を介してインターネットなどの共通ネットワーク１４に接続されたユーザ機器１１を備えてもよい。このシステムはさらに、共通ネットワーク１４にアクセスするためにユーザ機器が接続してもよい（潜在的な接続がジグザグの破線により表現されている）第２アクセス・ポイント１３を備えてもよい。さらに、第１アクセス・ポイント１２および第２アクセス・ポイント１３の一方または両方に、関連する別々の第１ネットワークおよび第２ネットワーク（図示せず）があってもよい。システムはさらに、ネットワーク構成要素１５などのネットワーク・デバイスを備えてもよく、ネットワーク構成要素１５も共通ネットワーク１４に接続されており、共通ネットワーク１４を介してユーザ機器１１に１つ以上のクラウド・サービスを提供してもよい。

ユーザ機器１１は、ネットワーク上で通信するよう構成されている任意のデバイスとしてもよい。例えば、ユーザ機器１１は、モバイル電話、ＰＤＡ、ページャ、ラップトップ・コンピュータ、タブレット・コンピュータ、データ・カード、ユニバーサル・シリアル・バス（ＵＳＢ：Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）ドングル、またはその他多数のハンドヘルドもしくはポータブル通信デバイス、計算デバイス、コンテンツ生成デバイス、コンテンツ消費デバイスのうちのいずれか、またはその組み合わせなどのモバイル端末とすることもできる。

第１アクセス・ポイント１２および第２アクセス・ポイント１３は、ユーザ機器１１などの接続されたユーザ機器に共通ネットワーク１４へのアクセスを提供することができる有線または無線のアクセス・ポイントとすることもできる。例えば、アクセス・ポイント１２および１３の一方または両方を、基地局、アクセス・ノード、またはＮｏｄｅ Ｂ、進化型Ｎｏｄｅ Ｂ（ｅＮＢ：ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ）、中継ノード、もしくはその他のタイプのアクセス・ポイントなどの任意の等価物とすることもできる。アクセス・ポイントは、他のデバイスのためのアクセス・ポイントとしての機能を果たし、例えばテザリングによるインターネット・アクセスを提供することによってその接続を共有する、別のＵＥまたはモバイル・デバイスとすることもできる。アクセス・ポイント１２または１３はさらに、ＷＬＡＮなどのローカル・エリア・ネットワークへのアクセスを提供するよう構成されたアクセス・ポイントとすることもできる。したがって、アクセス・ポイント１２または１３は、ＩＥＥＥ８０２．１１などのＷＩＦＩ標準に従って動作するよう構成されたアクセス・ポイントとすることもできる。アクセス・ポイント１２および／または１３は、光ファイバ、同軸もしくはイーサネット（登録商標）ケーブル、デジタル加入者回線（ＤＳＬ：ｄｉｇｉｔａｌ ｓｕｂｓｃｒｉｂｅｒ ｌｉｎｅ）を介するなど、有線手段を介して共通ネットワーク１４にアクセスしてもよく、またはロング・ターム・エボリューション（ＬＴＥ：Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）ネットワーク、ＬＴＥ−Ａｄｖａｎｃｅｄ（ＬＴＥ−Ａ）ネットワーク、ＧＳＭ（登録商標）ネットワーク、ＷＣＤＭＡ（登録商標）ネットワークやＣＤＭＡ２０００ネットワーク等の符号分割多重接続（ＣＤＭＡ：Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）ネットワーク、汎用パケット無線サービス（ＧＰＲＳ：Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）ネットワーク、もしくはその他のタイプのネットワークなどの無線ネットワークと接続することによって共通ネットワーク１４にアクセスしてもよい。

アクセス・ポイント１２および１３は、種々の手段を使用して、かつ／または関連する種々の介在ネットワークを介して、ネットワーク１４へのアクセスをユーザ機器１１に提供してもよい。例示の実施形態では、アクセス・ポイント１２は、関連するＬＴＥネットワークを介したネットワーク１４へのアクセスをユーザ機器１１に提供するよう構成されたｅＮＢなどの基地局とすることもでき、アクセス・ポイント１３は、ＷＩＦＩ標準に従って構成されたアクセス・ポイントであり、関連するＷＬＡＮネットワークを介したネットワーク１４へのアクセスをユーザ機器１１に提供する。別の例示の実施形態によれば、アクセス・ポイント１２および１３はいずれも、関連するＬＴＥネットワークを介したネットワーク１４へのアクセスをユーザ機器１１に提供するよう構成されたｅＮＢなどの基地局とすることもでき、各アクセス・ポイントは、それぞれの個別のセルに関連する。３つ以上のアクセス・ポイントを含む構成を含め、他にいくつものシステム構成が可能である。

ネットワーク構成要素１５は、任意のタイプのネットワーク・アクセス可能デバイスとすることができる。例えば、ネットワーク構成要素１５は、サーバであってもよい。ネットワーク構成要素１５は、例えば、共通ネットワーク１４、および／またはその他アクセス・ポイント１２および／または１３に関連し得る個々のネットワークなどの１つ以上のネットワーク上でアクセス・ポイント１２および／または１３ならびにユーザ機器１１と通信してもよい。あるいは、ネットワーク構成要素１５は、アクセス・ポイント１２または１３のうちのいずれかと、直接通信しても、または他の形で直接関連してもよい。

ユーザ機器１１、アクセス・ポイント１２、アクセス・ポイント１３、およびネットワーク構成要素１５のうちのいずれかまたはすべては、後述のように本発明の実施形態に従って構成された、図３に示されているものなどの装置４５を備えても、それと関連してもよい。

一実施形態では、ユーザ機器１１は、モバイル端末によって具現化されてもよい。この関連で、本発明の実施形態から利益を受けることになるモバイル端末２５のブロック図が、図２に示されている。なお、当然のことながら、図示および後述されるモバイル端末２５は、本発明の実施形態から利益を受けることができる１つのタイプのユーザ機器の例示にすぎないため、本発明の実施形態の範囲を限定するものと見なされてはならない。よって、ＰＤＡ、モバイル電話、ページャ、モバイル・テレビ、ゲーム用デバイス、ラップトップ・コンピュータ、カメラ、タブレット・コンピュータ、タッチ面、ウェアラブル・デバイス、ビデオ・レコーダ、オーディオ／ビデオ・プレーヤ、ラジオ、電子書籍、測位デバイス（例えば全地球測位システム（ＧＰＳ：ｇｌｏｂａｌ ｐｏｓｉｔｉｏｎｉｎｇ ｓｙｓｔｅｍ）デバイス）、または前述のものの任意の組み合わせなどの多数のタイプのモバイル端末が、本発明の実施形態を容易に採用することができるが、固定（非モバイル）電子デバイスを含む他のユーザ機器も、一部の例示の実施形態を採用し得る。

モバイル端末２５は、送信機１８および受信機２０と動作可能に通信する１つのアンテナ１７（または複数のアンテナ）を備えてもよい。モバイル端末２５は、送信機１８への信号の供給および受信機２０からの信号の受信を制御する、プロセッサ２２またはその他の処理デバイス（例えば図３の装置のプロセッサ５０）などの装置をさらに備えてもよい。信号は、適切なセルラ・システムの無線インターフェース標準に従ったシグナリング情報を含んでもよく、さらにユーザ音声、受信データ、および／またはユーザ生成データを含んでもよい。この点に関して、モバイル端末２５は、１つ以上の無線インターフェース標準、通信プロトコル、変調方式、およびアクセス方式で動作できる。例として、モバイル端末２５は、無線通信メカニズムに従って動作でき、複数の無線アクセス技術（ＲＡＴ）を用いて通信できることもある。例えば、モバイル端末２５は、いくつかの第１、第２、第３、および／または第４世代セルラ通信プロトコルまたは同様のもののうちの任意のものに従って動作できてもよい。例えば、モバイル端末２５は、ＩＳ−１３６（時分割多重接続（ＴＤＭＡ：ｔｉｍｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ））、ＧＳＭ（登録商標）、およびＩＳ−９５（符号分割多重接続（ＣＤＭＡ））などの第２世代（２Ｇ：ｓｅｃｏｎｄ−ｇｅｎｅｒａｔｉｏｎ）無線通信プロトコル、またはユニバーサル・モバイル通信システム（ＵＭＴＳ：Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）、ＣＤＭＡ２０００、ＷＣＤＭＡ（登録商標）、および時分割同期ＣＤＭＡ（ＴＤ−ＳＣＤＭＡ：ｔｉｍｅ ｄｉｖｉｓｉｏｎ−ｓｙｎｃｈｒｏｎｏｕｓ ＣＤＭＡ）などの第３世代（３Ｇ：ｔｈｉｒｄ−ｇｅｎｅｒａｔｉｏｎ）無線通信プロトコル、進化型ＵＭＴＳ地上無線アクセス・ネットワーク（Ｅ−ＵＴＲＡＮ：ｅｖｏｌｖｅｄ ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）などの３．９Ｇ無線通信プロトコル、第４世代（４Ｇ：ｆｏｕｒｔｈ−ｇｅｎｅｒａｔｉｏｎ）無線通信プロトコル（例えばロング・ターム・エボリューション（ＬＴＥ）またはＬＴＥ−Ａｄｖａｎｃｅｄ（ＬＴＥ−Ａ））、または同様のものに従って動作できてもよい。代わりとして（または追加的に）、モバイル端末２５は、例えば、ＩＥＥＥ８０２．１１ａ、ｂ、ｇ、またはｎなどのＩＥＥＥ８０２．１１標準ファミリのうちの１つ以上に従って、無線ローカル・エリア・ネットワーク（ＷＬＡＮ）またはその他通信ネットワークにおいて通信できてもよい。

一部の実施形態では、プロセッサ２２は、モバイル端末２５のオーディオ機能および論理機能を実装するのに望ましい回路を備えてもよい。例えば、プロセッサ２２は、デジタル信号プロセッサ・デバイス、マイクロプロセッサ・デバイス、および様々なアナログ−デジタル変換器、デジタル−アナログ変換器、およびその他サポート回路から成ってもよい。これらのデバイス間に、モバイル端末２５の制御機能および信号処理機能が、デバイスの個々の能力に従って割り当てられる。したがって、プロセッサ２２は、変調および送信の前にメッセージおよびデータを畳み込み符号化およびインターリーブする機能性も備えてもよい。プロセッサ２２はさらに、内蔵音声符号器を備えてもよく、内蔵データ・モデムを備えてもよい。さらに、プロセッサ２２は、メモリに記憶され得る１つ以上のソフトウェア・プログラムを動作させる機能性を備えてもよい。例えば、プロセッサ２２は、従来のウェブ・ブラウザなどの接続プログラムを動作させることができてもよい。その場合、接続プログラムは、モバイル端末２５が、例えば無線アプリケーション・プロトコル（ＷＡＰ：Ｗｉｒｅｌｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ：Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、および／または同様のものに従って、ロケーション・ベース・コンテンツおよび／またはその他ウェブ・ページ・コンテンツなどのウェブ・コンテンツを送受信できるようにしてもよい。様々なソフトウェア・プログラムへのアクセスおよびシステム・サービスの供給は、例えば、メモリ３６または３８などのメモリに記憶されてプロセッサ２２などのプロセッサにより実行可能なプログラム命令として実装されたオペレーティング・システム（ＯＳ：ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ）により処理されてもよい。

モバイル端末２５はさらに、従来のイヤホンまたはスピーカ２６などの出力デバイス、リンガ２４、マイクロホン２８、ディスプレイ３０、およびユーザ入力インターフェースを含むユーザ・インターフェースを有してもよく、そのすべてがプロセッサ２２に接続される。モバイル端末２５がデータを受領できるようにするユーザ入力インターフェースには、キーパッド３２、タッチ・スクリーン・ディスプレイ（ディスプレイ３０がそのようなタッチ・スクリーン・ディスプレイの例を示す）、またはその他の入力デバイスなど、モバイル端末２５がデータを受領できるようにするいくつかのデバイスのうちの任意のものが含まれ得る。キーパッド３２を含む実施形態では、キーパッド３２は、従来の数字（０〜９）および関連キー（＃、＊）、ならびにモバイル端末２５を動作させるために使用される他のハードキーおよびソフトキーを備えてもよい。あるいは、またはさらに、キーパッド３２は、従来のＱＷＥＲＴＹキーパッド配列を備えてもよい。キーパッド３２はさらに、関連する機能を伴う様々なソフトキーを備えてもよい。さらに、または代わりに、モバイル端末２５は、ジョイスティックまたはその他のユーザ入力インターフェースなどのインターフェース・デバイスを備えてもよい。さらに後述する、タッチ・スクリーン・ディスプレイを採用するいくつかの実施形態は、キーパッド３２と、スピーカ２６、リンガ２４、およびマイクロホン２８のうちのいずれかまたはすべてとを、完全に省略してもよい。モバイル端末２５は、モバイル端末２５を動作させるのに必要な様々な回路に電力を供給し、さらに、検出可能な出力として機械的振動をもたらしてもよい、振動電池パックなどの電池をさらに備える。

モバイル端末２５は、ユーザ識別モジュール（ＵＩＭ：ｕｓｅｒ ｉｄｅｎｔｉｔｙ ｍｏｄｕｌｅ）３４をさらに備えてもよい。典型的には、ＵＩＭ３４は、プロセッサが組み込まれたメモリ・デバイスである。ＵＩＭ３４には、例えば、加入者識別モジュール（ＳＩＭ：ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙ ｍｏｄｕｌｅ）、汎用集積回路カード（ＵＩＣＣ：ｕｎｉｖｅｒｓａｌ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ ｃａｒｄ）、汎用加入者識別モジュール（ＵＳＩＭ：ｕｎｉｖｅｒｓａｌ ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙ ｍｏｄｕｌｅ）、リムーバブル・ユーザ識別モジュール（Ｒ−ＵＩＭ：ｒｅｍｏｖａｂｌｅ ｕｓｅｒ ｉｄｅｎｔｉｔｙ ｍｏｄｕｌｅ）などが含まれ得る。典型的には、ＵＩＭ３４は、モバイル加入者に関する情報要素を記憶する。モバイル端末２５は、ＵＩＭ３４に加えてメモリを備えていてもよい。例えば、モバイル端末２５は、データの一時記憶のためのキャッシュ領域を備える、揮発性のランダム・アクセス・メモリ（ＲＡＭ：Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などの揮発性メモリ３６を備えてもよい。モバイル端末１５はさらに、組み込み式および／またはリムーバブルとされ得る、他の不揮発性メモリ３８を備えてもよい。メモリは、モバイル端末２５の機能を実装するためにモバイル端末２５によって使用される、複数の情報およびデータのうちのいずれかを記憶してもよい。

本発明の例示の実施形態について、以下、図３を参照して記載する。図３には、クラウド・サービスをスケジューリングする、装置４５の特定の構成要素が示されている。クラウド・サービスをスケジューリングするために、図３の装置４５は、例えば、図１のユーザ・デバイス１１、アクセス・ポイント１２、アクセス・ポイント１３、および／またはネットワーク構成要素１５のうちのいずれかまたはすべてとともに採用されてもよい。したがって、一部の実施形態によれば、後述する装置４５の機能性は、前述のデバイスのうちの１つにおいて実行されてもよい。なお、他の実施形態によれば、後述する装置４５の機能性を、別々の装置４５をそれぞれ有する複数のデバイスにわたって分散させてもよい。

さらに、図３は、クラウド・サービスをスケジューリングする装置４５の構成の一例を示すが、他に多数の構成が、同じく本発明の実施形態を実装するために使用され得るということに留意すべきである。よって、一部の実施形態では、デバイスまたは構成要素が、相互通信しているように示されているが、以下、そのようなデバイスまたは構成要素は、同じデバイスまたは構成要素内に具現化できると見なされるべきであり、したがって、通信して示されているデバイスまたは構成要素は、選択的に、同じデバイスまたは構成要素の一部であると理解されるべきである。

以下、図３を参照する。クラウド・サービスをスケジューリングする装置４５は、プロセッサ５０、通信インターフェース５４、およびメモリ・デバイス５６を備えてもよく、他の形でそれと通信してもよい。後述するとおり、図３に破線で示されているように、装置４５がユーザ・デバイス１１により具現化される実施形態などの一部の実施形態では、装置４５は、ユーザ・インターフェース５２も備えてもよい。一部の実施形態では、プロセッサ５０（および／またはプロセッサ５０を支援し、もしくはプロセッサ５０と他の形で関連する、コプロセッサまたはその他任意の処理回路）が、装置４５のコンポーネント間で情報を渡すためのバスを介してメモリ・デバイス５６と通信してもよい。メモリ・デバイス５６は、例えば、１つ以上の揮発性および／または不揮発性メモリを備えてもよい。すなわち、例えば、メモリ・デバイス５６は、マシン（例えばプロセッサ５０のようなコンピューティング・デバイス）により読み出すことができるデータ（例えばビット）を格納するよう構成されたゲートを有する電子ストレージ・デバイス（例えばコンピュータ可読ストレージ媒体）であってもよい。装置４５がモバイル端末２５として具現化される実施形態では、メモリ・デバイス５６は、メモリ３６、３８によって具現化されてもよい。メモリ・デバイス５６は、装置が本発明の例示の実施形態に従って様々な機能を実行できるようにするための情報、データ、コンテンツ、アプリケーション、命令、または同様のものを記憶するよう構成されてもよい。例えば、メモリ・デバイス５６は、プロセッサ５０による処理のために入力データをバッファリングするよう構成され得るであろう。さらに、または代わりに、メモリ・デバイス５６は、プロセッサ５０により実行される命令を記憶するよう構成され得るであろう。

一部の実施形態では、装置４５は、ユーザ端末（例えばモバイル端末２５）もしくは固定の通信デバイス（例えばネットワーク構成要素１５、アクセス・ポイント１２、および／またはアクセス・ポイント１３）、または本発明の例示の実施形態を採用するよう構成されたコンピューティング・デバイスにより具現化されてもよく、それに関連してもよい。なお、一部の実施形態では、装置４５は、チップまたはチップセットとして具現化されてもよい。すなわち、装置４５は、構造組立品（例えばベースボード）上の材料、コンポーネント、および／またはワイヤを備えた１つ以上の物理的パッケージ（例えばチップ）を有してもよい。構造組立品は、物理的強度、サイズの節減、および／または構造組立品に含まれるコンポーネント回路の電気的相互作用の制限をもたらし得る。したがって、装置４５は、場合によっては、本発明の実施形態を単一チップ上に、すなわち単一の「システム・オン・チップ」として実装するよう構成されてもよい。よって、場合によっては、チップまたはチップセットは、本願明細書に記載された機能性を提供するために１つ以上の動作を実行する手段を構成してもよい。

プロセッサ５０は、いくつかの異なる方法で具現化され得る。例えば、プロセッサ５０は、コプロセッサ、マイクロプロセッサ、コントローラ、デジタル信号プロセッサ（ＤＳＰ：ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ）、付属するＤＳＰを有するもしくは有しない処理要素、またはその他、例えばＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ：特定用途向け集積回路）、ＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ：フィールド・プログラマブル・ゲートアレイ）、マイクロコントローラ・ユニット（ＭＣＵ：ｍｉｃｒｏｃｏｎｔｒｏｌｌｅｒ ｕｎｉｔ）、ハードウェア・アクセラレータ、専用コンピュータ・チップ、または同様のものなどの集積回路を含む様々な処理回路など、様々なハードウェア処理手段のうちの１つ以上として具現化され得る。よって、一部の実施形態では、プロセッサ５０は、独立して動作するよう構成された１つ以上の処理コアを備えてもよい。マルチコア・プロセッサは、単一の物理的パッケージ内でのマルチプロセッシングを可能にしてもよい。さらに、または代わりに、プロセッサ５０は、命令の独立した実行、パイプライン処理、および／またはマルチスレッディングを可能にするよう、バスを介してタンデム構成された１つ以上のプロセッサを備えてもよい。装置４５がモバイル端末２５として具現化される実施形態では、プロセッサ５０は、プロセッサ２２によって具現化されてもよい。

例示の実施形態では、プロセッサ５０は、メモリ・デバイス５６に記憶されているか、またはその他の形でプロセッサ５０がアクセスできる、命令を実行するよう構成されてもよい。代わりに、またはさらに、プロセッサ５０は、ハードコードされた機能性を実行するよう構成されてもよい。よって、プロセッサ５０は、ハードウェア手法により構成されるか、ソフトウェア手法により構成されるか、またはその組み合わせにより構成されるかにかかわらず、適宜構成されている間、本発明の実施形態による動作を実行できる（例えば回路に物理的に具現化された）エンティティを表し得る。したがって、例えばプロセッサ５０がＡＳＩＣ、ＦＰＧＡ、または同様のものとして具現化される場合、プロセッサ５０は、本願明細書に記載の動作を実行するよう特に構成されたハードウェアであってもよい。あるいは、別の例として、プロセッサ５０がソフトウェア命令の実行器として具現化される場合、命令は、命令が実行されると、本願明細書に記載のアルゴリズムおよび／または動作を実行するよう、プロセッサ５０を特に構成してもよい。なお、場合によっては、プロセッサ５０は、本願明細書に記載されたアルゴリズムおよび／または動作を実行するための命令によるプロセッサ５０のさらなる構成によって、本発明の実施形態を採用するよう構成された、特定のデバイス（例えばモバイル端末またはネットワーク・エンティティ）のプロセッサであってもよい。プロセッサ５０は、特に、プロセッサ５０の動作をサポートするよう構成されたクロック、算術論理演算ユニット（ＡＬＵ：ａｒｉｔｈｍｅｔｉｃ ｌｏｇｉｃ ｕｎｉｔ）、および論理ゲートを備えてもよい。

一方、通信インターフェース５４は、ネットワーク１４などのネットワークもしくはアクセス・ポイント１２および／または１３に関連する他の任意のネットワーク、および／または装置４５と通信する他の任意のデバイスもしくはモジュールとの間でデータを受信および／または送信するよう構成されている、ハードウェア、またはハードウェアとソフトウェアとの組み合わせのいずれかにおいて具現化された、デバイスまたは回路などの任意の手段としてもよい。この点に関して、通信インターフェース５４は、例えば、無線通信ネットワークとの通信を可能にするために、アンテナ（または複数のアンテナ）ならびに支援ハードウェアおよび／またはソフトウェアを備えてもよい。さらに、または代わりに、通信インターフェース５４は、アンテナ（単数または複数）を介した信号の送信を発生させるため、またはアンテナ（単数または複数）を介して受信される信号の受信を処理するために、アンテナ（単数または複数）と相互作用する回路を備えてもよい。一部の環境では、通信インターフェース５４は、代わりに、またはさらに、有線通信をサポートしてもよい。よって、例えば、通信インターフェース５４は、ケーブル、デジタル加入者回線（ＤＳＬ：ｄｉｇｉｔａｌ ｓｕｂｓｃｒｉｂｅｒ ｌｉｎｅ）、ユニバーサル・シリアル・バス（ＵＳＢ：ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）、またはその他メカニズムを介した通信をサポートするために、通信モデムおよび／またはその他ハードウェア／ソフトウェアを備えてもよい。装置４５がモバイル端末２５として具現化される実施形態では、通信インターフェース５４は、アンテナ１６、送信機１８、受信機２０、または同様のものによって具現化されてもよい。

装置４５がユーザ・デバイス１１により具現化される場合など、一部の実施形態では、装置４５はユーザ・インターフェース５２を備えてもよく、ユーザ・インターフェース５２はさらに、ユーザ入力の通知を受領し、かつ／または可聴、視覚、機械的、もしくはその他出力をユーザに供給させるプロセッサ５０と通信していてもよい。よって、ユーザ・インターフェース５２は、例えば、キーボード、マウス、ジョイスティック、ディスプレイ、タッチ・スクリーン（単数または複数）、タッチ領域、ソフトキー、マイクロホン、スピーカ、またはその他の入出力メカニズムを備えてもよい。代わりに、またはさらに、プロセッサ５０は、例えばスピーカ、リンガ、マイクロホン、ディスプレイ、および／または同様のものなどの１つ以上のユーザ・インターフェース要素の少なくとも一部の機能を制御するよう構成されたユーザ・インターフェース回路を有してもよい。プロセッサ５０および／またはプロセッサ５０を有するユーザ・インターフェース回路は、１つ以上のユーザ・インターフェース要素の１つ以上の機能を、プロセッサ５０がアクセスできるメモリ（例えばメモリ・デバイス５６および／または同様のもの）に記憶されたコンピュータ・プログラム命令（例えばソフトウェアおよび／またはファームウェア）を用いて制御するよう構成されてもよい。一方、装置４５がアクセス・ポイント１２、アクセス・ポイント１３、またはネットワーク構成要素１５により具現化される場合など、他の実施形態では、装置４５は、ユーザ・インターフェース５２を備えなくてもよい。

背景において説明したように、クラウド・コンピューティング・サービスは、インターネットなどのネットワーク上で、リモート計算、ソフトウェア・アプリケーション、データ・アクセス、および／またはストレージ・サービスがデバイスに提供されることを可能にし得る。これらサービスのエンド・ユーザは、サービスを配信しているクラウド・コンピューティング・システムの物理的な位置または構成を認識する必要がないと思われ、一部のエンド・ユーザは、セルラおよび／またはＷＩ−ＦＩ通信プロトコルなどのＲＡＴを介してクラウド・コンピューティング・サービスに無線アクセスすることさえもある。

特にありがちで難しいスケジューリング・シナリオは、完了すべき、大量であるが非緊急のトラフィック動作（例えば、デバイス・カメラを用いて撮影された写真、クラウド・データ、バックアップ、ソフトウェア更新、または地図コンテンツのダウンロードなどのコンテンツの同期化）を伴うユーザ機器（ＵＥ：ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）を含む。ＵＥには、大量であるが非緊急のトラフィック動作をいつ開始すべきか、正確に分からない場合もあり、同じくネットワークにとっても、ＵＥの正確なニーズが分からないため、大量の非緊急データをサポート（例えばスケジューリング）するのは難題である。

現在のソリューションは、チャネル品質に基づいてユーザ・トラフィックをスケジューリングすることを伴う。これらのソリューションは、例えば、特定のチャネル品質が良好なときに、ＵＥのスケジューリングしようと試みることができる。しかしながら、これは、１つのセル内で行われる短期的なメカニズムでしかない。必要とされているのは、複数のセルおよび／または複数のＲＡＴ（例えばセルラおよびＷＩ−ＦＩ）が利用可能である可能性のある状態で、クラウド・サービス、例えば非緊急データ送信機会の、より長い時間スケールのスケジューリングをサポートするフレームワークである。大量の非緊急データのペンディング中、ＵＥの他のトラフィックのスケジューリングは、通常通り行われてもよい。状況次第で、非緊急データの送信は、そのネットワーク（例えばＷＬＡＮ）の制御外の接続を使用して実施されてもよいし、適切な接続または十分な容量が利用可能にならなければ完全にキャンセルされてもよい。

したがって、ここで図４を参照すると、クラウド・サービスをスケジューリングするための、上記のようなフレームワークを提供する動作が示されている。この関連で、後述の通り、図４の動作は、ユーザ機器１１により具現化され、またはその他の形でユーザ機器１１と関連する、図３に示されているものなどの装置４５によって実行されてもよい。この関連で、装置４５は、サポート・リクエストを送信させる、プロセッサ５０、通信インターフェース５４、または同様のものなどの手段を備えてもよい。動作４００を参照されたい。サポート・リクエストは、例えば、アクセス・ポイント１２へ送信されてもよい。サポート・リクエストは、例えば、クラウド・サービスに関連するデータなど、ユーザ機器１１によって送信される必要があり得るデータのサイズなどの情報を含んでもよい。サポート・リクエストはさらに、リクエストの緊急性の通知を含んでもよい。例えば、サポート・リクエストは、サポート・リクエストが開始されるまでの好適な最大遅延、またはサポート・リクエストが完了されるまでの好適な最大遅延など、好適な最大遅延の通知を含んでもよい。さらに、または代わりに、スケジューリングの決定に有用となり得る、その他多数のタイプの情報が、サポート・リクエストに含まれてもよい。一部の実施形態では、サポート・リクエストにおいて提供される情報は、完全に正確ではなく推定であってもよい。ＵＥの非緊急の大量データ・タスク（単数または複数）をスケジューリングするために、サポート・リクエストがネットワークまたはアクセス・ポイントへ送信されてもよい。これは、例えば、タスクに関連するデータの量が閾値を上回るか、もしくはタスクに関連する遅延要件が閾値よりも緩やかである場合、または現在の容量もしくは予測される容量に基づき、タスクが時間内に完了しないこと、もしくはタスク完了までの長時間もしくは低リソース利用効率が原因でタスクを電力効率よく実施できないことが推定される場合などであってもよい。

装置４５はさらに、例えば容量通知などの通知メッセージを受信する、プロセッサ５０、通信インターフェース５４、または同様のものなどの手段を備えてもよい。動作４１０を参照されたい。容量通知は、例えば、アクセス・ポイント１２など、もとのサポート・リクエストを受信したアクセス・ポイントから受信されてもよく、サポート・リクエストに対処するためのアクセス・ポイントの容量に関する情報を含んでもよい。例えば容量通知は、例として、リクエストされたサポートがいつ開始および／または完了可能かの推定を含んでもよい。さらに、または代わりに、容量通知は、例えば、リクエストされたサポートを提供可能なデータ転送速度、リクエストされたサポートが提供されることになる電力効率、および／またはリクエストされたサポートを提供するためのコストに関する情報を含んでもよい。さらに、または代わりに、スケジューリングの決定に有用となり得る、その他多数のタイプの情報が、容量通知に含まれてもよい。一部の実施形態では、装置４５は、追加のサポートを全く与えることができないと示されてもよく、または同じ理由で、装置４５には何の応答も与えられない。一部の実施形態では、サポート・リクエストは、例えば、ＵＥが接続することができる１つ以上のアクセス・ポイントを介してＵＥを支援できるネットワーク１４など、単一のアクセス・ポイントではなくネットワーク全体を対象とする。

装置４５は、例として、通知メッセージ、例えば容量通知などに基づき、サポート・タスクを待つか、または拒否するか、または遅延させるかの適切な応答を判断する、プロセッサ５０、通信インターフェース５４、または同様のものなどの手段をさらに備えてもよい。動作４２０を参照されたい。例えば、装置４５は、推定待ち時間が長すぎる場合、または最適でないサポートがアクセス・ポイント１２により提供されるであろうことを、容量通知で提供された他の何らかの情報が示す場合に、サポートを拒否しても、遅延させてもよい。サポートは、例えば、ＵＥの電池残量が少ない場合、または他のユーザ・アクティビティがある場合に（例えばウェブ・ブラウジング・セッションの減速を回避するために）、拒否または遅延されてもよい。装置４５はさらに、サポートが拒否されるべきであると判断された場合に、サポート・リクエスト・キャンセル通知を送信させる、前述のものなどの手段を備えてもよい。動作４８０を参照されたい。したがって、サポート・キャンセル通知は、当該アクセス・ポイントおよび／またはアクセス・ポイント１２が接続されているネットワーク１４からのサポートをユーザ機器１１がもはや必要としないことを、アクセス・ポイント１２に連絡してもよい。さらに装置４５は、アクセス・ポイント１２からのサポートが拒否されるべきであると判断された場合にアクセス・ポイント１３などの別のアクセス・ポイントからのサポートを求める、前述のものなどの手段を備えてもよい。動作４９５を参照されたい。別のアクセス・ポイントからのサポートを求めることは、例えば、別のアクセス・ポイントを介してデータを送信させることを含んでもよい。上記のように、別のアクセス・ポイントは、例えば、第１のＲＡＴとは異なるＲＡＴを採用してもよい。あるいは、装置４５は、別のアクセス・ポイントからのサポートを求めることなく、サポート・リクエストを単にキャンセルすることも、またはさらに遅延させることもできる。これは、例えば、ユーザがウェブ・ブラウザを使用しているときなど、ＵＥにおいてより優先度の高いアクティビティが他に進行している場合に当てはまる可能性がある。

装置４５はさらに、アクセス・ポイント１２によるサポート・タスクの提供を装置４５が待つべきであると判断された場合に１つ以上のアイドル機能を実行する、プロセッサ５０、通信インターフェース５４、または同様のものなどの手段を備えてもよい。前記待機は、例えば、十分に良好な接続品質および／または容量が利用可能でないことが原因となり得る。動作４３０を参照されたい。アイドル機能は、例えば、ＵＥ１１の位置および／またはチャネル品質などの他の情報を定期的に更新することを含んでもよい。ＵＥ１１の位置の更新は、例えば、ＵＥがセルラ・ネットワークと通信している場合、セル・レベルなどで、または例えば座標レベル、もしくは例えば伝搬経路損失もしくは信号品質などを単位として測定されるアクセス・ポイントに対する相対的位置など、より正確に、セルラ・ネットワークに対してＵＥ１１の位置を更新することを含んでもよい。ＵＥ１１がセルラ・ネットワークに接続されている場合、アイドル機能はさらに、ＵＥ１１が新たなセルもしくはアクセス・ポイントに入るか、またはチャネル品質の大幅な変化などスケジューリングに影響を与えるかもしれない他のイベントがあると、例えば新たなアクセス・ポイントに接続してネットワークにシグナリングすることにより、ＵＥ１１の位置を更新することを含んでもよい。新たなセルに入ったことをＵＥ１１がネットワークにシグナリングした場合、ネットワークは、アクセス・ポイント１２またはネットワーク・エンティティ１３に関連する装置４５などを介して、サポートを再計算および／または再スケジューリングしてもよく、これには例えば、更新された容量通知をＵＥ１１に関連する装置４５へ送信させることが含まれてもよい。別の実施形態によれば、サポート・リクエストは、ＵＥがセルまたはアクセス・ポイントを変更すると、新たに開始されてもよい。アイドル機能は、アクセス・ポイント１２などを介して、ネットワークからページング情報を時折受信することをもさらに含んでもよい。さらに、アイドル機能は、サポート・リクエストが実現されるのを待つ間、ＵＥ１１が、接続モード（例えばＲＲＣ接続モード）に保たれること、またはそれを保持することを含んでもよく、したがって、例えば、ＵＥ１１は通常通りデータを送信し続けることができる。アイドル機能はさらに、例えばＵＥ１１を「スリープ」モード（例えばＤＲＸ、すなわち不連続受信モード）に入らせることまたはＵＥ１１とアクセス・ポイント１２との間の接続を解放すること（例えば、タスクを待つ間ＵＥをＲＲＣ接続モードに保つことも可能ではあるが、ＵＥをＲＲＣ接続モードからＲＲＣアイドル・モードに移行させること）により、ＵＥ１１を低電力消費モードに入らせることを含んでもよい。場合によっては、タスクが遅延なしに開始されることも、例えばアクセス・ポイント１２がそのように指示すれば、可能である。

当然のことながら、例えばサポートのリクエスト先としたアクセス・ポイントからのサポートを拒否するか承諾するかなど、適切な応答は何かについての装置４５の判断は、さらに、または代わりに、容量通知以外の情報に基づいてもよい。例えば、装置４５は、判断を下す際、その周辺の履歴情報または測定値を考慮に入れてもよい。履歴情報の使用例として、ＵＥは、例えば一日のうちの特定の時間、または特定の位置（地理的、または接続されたアクセス・ポイント）における接続品質または利用可能容量などの前の監視に基づきタスクの遅延制約内で獲得することを期待できる典型的なサービス・レベルよりも、提示されたサポート／容量が低いことを理由に、サポート／支援を拒否することを決定してもよい。

図４に示されているように、ＵＥ１１に関連する装置４５は、待つことが適切な応答であると判断した後、サポート・リクエストがさらに続行されるべきか、またはここでキャンセルされるべきかを判断してもよい。動作４４０を参照されたい。装置４５は、そのような判断を、任意数の要因に基づいて下すことができる。例えば、装置４５は、ＵＥ１１の電池残量が低いことに基づいて、またはＵＥ１１のユーザによりとられている特定のアクション（例えばユーザが、減速されてはならない、アクティブなブラウジング・セッション、またはその他、インタラクティブな、もしくはより優先順位の高いアクティビティを進行中である）に基づいて、サポート・リクエストがキャンセルまたは遅延されるべきであると判断してもよい。別の例示の実施形態によれば、装置４５は、より良好な接続が利用可能であると判断することに基づいて、サポート・リクエストがキャンセルされるべきであると判断してもよい。例えば、装置４５は、アクセス・ポイント１３などの別のアクセス・ポイントが、より高速なもしくはより安定した送信速度で、またはより短い待ち時間後になど、より良好にサポート・リクエストを満たすことができると判断してもよい。装置４５は、例えば無線スキャンを実行すること、および／または追加のサポート・リクエストを追加のアクセス・ポイントへ送信させることによって、より良好な接続が利用可能であると判断してもよい。装置４５はさらに、利用可能な代わりの接続１つ以上の比較を行い、より良好な接続が利用可能かどうか、およびそれゆえに、ペンディング中のリクエストをキャンセルしてより良好な接続を介したサポートをリクエストすべきかどうかを判断してもよい。具体的な例として、ＵＥ１１に関連する装置４５が、現在、セルラ・ネットワークに関連するアクセス・ポイント１２によりサポート・リクエストが実現されるのを待っているとして、急にＵＥ１１が、アクセス・ポイント１３などのＷＩ−ＦＩアクセス・ポイントの圏内に運び込まれると、装置４５は、アクセス・ポイント１２に対するペンディング中のリクエストをキャンセルして、代わりにＷＩ−ＦＩアクセス・ポイント１３を介したサポートを求めるべきであると判断してもよい。上記の、サポートを拒否するという判断のように、キャンセルするという判断に続いて、サポート・リクエスト・キャンセル通知を送信させてもよい。動作４８０を参照されたい。一部の実施形態では、ネットワークまたはアクセス・ポイントは、ＵＥが別のアクセス・ポイントにより最良にサポート／支援されると判断し、さらにネットワークまたはアクセス・ポイントは、ＵＥのハンドオーバを開始してもよく、または条件がより適切になるまで待ってもよい。

当然のことながら、図４は、キャンセルの決定が論理上生じ得る、ＵＥ１１に関連する装置４５の動作における２つの時点の例を示すにすぎない。実際は、キャンセルの決定４４０は、前記動作の中の多数の可能な時点において発生し得るものであり、したがって、図４は、装置４５がリクエストがキャンセルされるべきであると判断することができる時期を限定するものと解釈されてはならない。したがって、例えば、ペンディング中のリクエストがキャンセルされるべきであると装置４５が判断するより前に、必ずしも１つ以上のアイドル機能が完了されなければならないとは限らない。さらに当然のことながら、キャンセルするという決定は、アクセス・ポイント１２からも生じてもよく、その結果、キャンセル動作４４０はさらに、キャンセル通知が受信されたかどうかなど、タスクがキャンセルされたかどうかを判断することを含んでもよい。

装置４５は、リクエストされたサポート（またはサポート・リクエストに関連するタスク）が開始可能かどうか判断する、プロセッサ５０、通信インターフェース５４、または同様のものなどの手段をさらに備えてもよい。動作４５０を参照されたい。例示の実施形態によれば、装置４５は、そのような判断を、アクセス・ポイント１２などから準備完了通知を受信するのに基づいて下してもよい。したがって、準備完了通知は、アクセス・ポイント１２が現在、リクエストされたサポートを提供する準備のできた状態であることを、ＵＥ１１に関連する装置４５にシグナリングしてもよい。準備完了通知は、ネットワークまたはアクセス・ポイントが、例えば追加容量、優先順位の上昇、保証付きサービス、またはサービス品質を改善する他の支援／サポートを提供する準備のできた状態であることを示してもよい。別の例示の実施形態によれば、装置４５は、受信された容量通知に基づいて、リクエストされたサポートが開始可能であると判断してもよい。例えば、装置４５は、容量通知に含まれる、サポート・タスクが開始できるまでの推定時間と、その容量通知が受信または送信されてからの経過時間とを比較してもよい。

図４にさらに示されているように、ＵＥ１１に関連する装置４５は、リクエストしたサポート・タスクに進むべきか、または開始を遅延させるべきかを判断してもよい。動作４６０を参照されたい。例えば、装置４５は、ＵＥの電池残量または現在の使用量など、ＵＥのステータスに基づいて、サポート・タスクの開始が遅延されるべきであると判断してもよい。例えば装置４５は、ユーザが、ウェブ・ブラウザを使用していること、またはその他ＵＥ１１を使用して、サポート・タスクの開始を許せば減速またはその他妨害されるであろうタスクを、実行していると判断し、それに応じて、サポート・タスクが遅延されるべきであると判断してもよい。サポート・タスクが遅延されるべきであると判断されれば、装置４５は、上記のように、１つ以上のアイドル機能を実行してもよい。サポート・タスクが遅延されるべきであるという判断に続いて、遅延通知を送信させてもよい。したがって、装置４５は、サポート・タスクの開始を遅延させたいと、アクセス・ポイント１２にシグナリングしてもよい。その結果、アクセス・ポイント１２は、例えば容量を再び判断して新たな容量通知を送信させることで、サポート・タスクを再スケジューリングすることなどによって、適宜応答してもよい。上記のキャンセルの判断４４０のように、遅延の判断４６０も、同じく、かつ／または追加的に、ＵＥ１１に関連する装置４５の動作中、図４に示されているのとは異なる時点において発生してもよい。さらに当然のことながら、遅延させるという決定は、アクセス・ポイント１２からも生じてもよく、その結果、遅延動作４６０はさらに、遅延通知がアクセス・ポイント１２から受信されたかどうかを判断することなどによって、タスクが遅延されたかどうかを判断することを含んでもよい。

装置４５は、装置４５が、サポート・タスクが開始可能であると判断した場合であって、サポート・タスクが遅延またはキャンセルされた、またはされるべきであると判断していない場合、承諾通知を送信させる、プロセッサ５０、通信インターフェース５４、または同様のものなどの手段をさらに備えてもよい。動作４８５を参照されたい。装置４５はさらに、例えば、サポート・タスクに関連するデータをアクセス・ポイント１１などへ送信させることまたはサポート・タスクに関連するデータを受信することによって、サポート・タスクを実行させる、上記のものなどの手段を備えてもよい。動作４９０を参照されたい。

このように、クラウド・サービスをスケジューリングするための、特許請求される発明の例示の実施形態の動作について、ＵＥ１１に関連する装置４５の観点から記載したところで、以下では、アクセス・ポイント１２などのアクセス・ポイントに関連する装置４５の対応する動作について説明する。この関連で、図５を参照するが、アクセス・ポイント１２に関連する装置４５は、サポート・リクエストを受信する、プロセッサ５０、通信インターフェース５４、または同様のものなどの手段を備えてもよい。動作５１０を参照されたい。上述のように、サポート・リクエストは、例えば、送信されるべきでありリクエストに関連するデータのサイズを、リクエストの緊急性（すなわち、例えば１分、１５分、１時間、１日など、分単位またはより概略的にカテゴリで表現される、どの程度の時間で完了されるべきか）の通知とともに含んでもよい。

装置４５は、例えばリクエストされたサポートに関連するサポート・タスクをスケジューリングするために、リクエストされたサポートを提供する容量を判断する、プロセッサ５０、通信インターフェース５４、または同様のものなどの手段をさらに備えてもよい。動作５２０を参照されたい。容量を判断することは、例えば、サポート・タスクを開始および／または完了可能と考えられる時までの推定時間を判断することを含んでもよい。容量はさらに、または代わりに、データ転送速度、電力効率、および／またはサポート・タスクの実行に関連するコストの推定を含んでもよい。容量は、例えば、例えばＳＩＮＲ（ｓｉｇｎａｌ ｔｏ ｉｎｔｅｒｆｅｒｅｎｃｅ ｎｏｉｓｅ ｒａｔｉｏ：信号対干渉雑音比）、伝送誤り率、および／または通信リンクのデータ転送速度など、ＵＥ１１との通信リンクの品質；ＵＥ ＭＳＥ（ｍｏｂｉｌｉｔｙ ｓｔａｔｅ ｅｓｔｉｍａｔｉｏｎ：移動状態推定）；ネットワーク負荷；ＵＥの移動状態；および／またはその他パラメータなどに基づいて判断されてもよい。別の例示の実施形態によれば、アクセス・ポイント１２に関連する装置４５は、サポート・タスクがダウンリンク（ＤＬ：ｄｏｗｎｌｉｎｋ）転送を伴う場合などに、ローカル・プロキシまたはバッファにリモート・データが受信されるまで、リクエストされたタスクを開始するのを待ってもよい。これにより、データは、サーバからＵＥ１１ではなく、プロキシ（またはそれどころかローカル・アクセス・ポイント・バッファ）からＵＥ１１へと移動するので、より効率的なデータ転送につながると思われる。全体的な遅延は短縮されないかもしれないが、アクセス・ポイントとＵＥ１１との間のアクティブなデータ送信および受信の継続時間は短縮することができ、これによって、電力効率の向上した動作を可能にすることができる。

装置４５はさらに、リクエストされたサポートを提供するか否かを決定する、プロセッサ５０、通信インターフェース５４、または同様のものなどの手段を備えてもよい。動作５３０を参照されたい。装置４５は、そのような決定を、例えば、判断された容量に基づいて下してもよい。タスクをサポートしないという決定は、例えば、アクセス・ポイント１３などの別のアクセス・ポイントがタスクをサポートできるように、その別のアクセス・ポイントにＵＥをハンドオーバするという決定を含んでもよい。例示の実施形態によれば、装置４５は、例えば、サポート・リクエスト、ネットワーク負荷、またはその他考慮事項に基づいて、ハンドオーバが実行されるべきであると判断してもよい。例えば、アクセス・ポイント１２の負荷が高い場合、アクセス・ポイント１２に関連する装置４５は、ＵＥ１１のリクエストされたタスクを時間内に完了するために必要なトラフィック量（およびその負荷影響）から、負荷がより低い別のセルへＵＥ１１をハンドオーバさせるハンドオーバ動作を生じさせるのが適切であると判断してもよい。例としてこれが当てはまる可能性がある状況に、マクロ・セルを提供するアクセス・ポイントに接続されていながら、より小さなセル（ＨｅＮＢ（ホームｅＮｏｄｅＢ）、ピコセル、ＷｉＦｉアクセス・ポイントなど）に対する接続を確立する場所にもあるＵＥの場合がある。ハンドオーバは、例えば、ＵＥの既知の／予測される将来のトラフィックが、リクエストされた時間内にアクセス・ポイント１２により処理可能な場合には必要ない。したがって、装置４５は、ハンドオーバが実行されるべきであると装置４５が判断した場合に、ハンドオーバ手順を開始させ、リクエストされたサポート・タスクを別のアクセス・ポイントが提供できるようにする、プロセッサ５０、通信インターフェース５４、または同様のものなどの手段をさらに備えてもよい。例示の実施形態によれば、装置４５は、アクセス・ポイント１２および１３などの２つ以上のアクセス・ポイントに関連してもよく、かつ、それらを制御するよう構成されてもよい。したがって、ハンドオーバ手順を開始させることは、例えばアクセス・ポイント１３などの別のアクセス・ポイントと、ＵＥ１１との間に接続を確立させることを含んでもよく、その結果、アクセス・ポイント１３は、リクエストされたサポート・タスクを、サポート・タスクに関連するデータを受信または送信することなどにより提供してもよい。別の例示の実施形態によれば、装置４５は、ハンドオーバの実行先のアクセス・ポイントを制御するよう構成されていなくてもよく、ハンドオーバ手順を開始させることは、ＵＥ１１自らハンドオーバ手順を開始すべきであるとＵＥ１１にシグナリングすることを含む。したがって、上記実施形態のうちの特定のものは、サポートをリクエストするＵＥを戦略的にハンドオーバすることにより、ＵＥのニーズがより良好にサポートされることを可能にしてもよく、かつ／またはより良好なネットワーク負荷分散を提供してもよい。

装置４５は、ＵＥ１１などへ容量指標を送信させる、プロセッサ５０、通信インターフェース５４、または同様のものなどの手段をさらに備えてもよい。動作５４０を参照されたい。容量指標は、動作５２０において判断された容量に関する情報を含む。容量指標は、サポートが提供されるべきであると装置４５が判断した場合にのみ送信されてもよい。装置４５はさらに、サポート・タスクが開始できるまで他の機能を実行する、プロセッサ５０、通信インターフェース５４、または同様のものなどの手段を備えてもよい。動作５５０を参照されたい。このような他の機能には、例えば、上記のＵＥ１１に関連する装置４５により実行されるアイドル機能に対応する、ネットワーク側の機能が含まれてもよい。例えば、このような他の機能は、ＵＥ１１から位置更新を受信すること、容量指標を更新して送信させるなどしてサポート・タスクを再スケジューリングすること、およびページング情報を送信させることを含んでもよく、またはネットワークは、いつ実際にタスクを開始すべきかＵＥにシグナリングしてもよい。このような他の機能はさらに、他のＵＥなどのために他のサポート・タスクを実行すること、ならびに他のスケジューリング動作および／または送信動作を実行することを含んでもよい。

アクセス・ポイント１２に関連する装置４５は、その、ＵＥ１１に関連する等価物のように、サポート・タスクをキャンセルするかどうか、および／またはサポート・タスクがＵＥ１１によりキャンセルされたかどうかを判断する、プロセッサ５０、通信インターフェース５４、または同様のものなどの手段を備えてもよい。動作５６０を参照されたい。同じく、アクセス・ポイント１２に関連する装置４５はさらに、サポート・タスクを遅延させるかどうか、および／またはサポート・タスクがＵＥ１１により遅延されたかどうかを判断する、プロセッサ５０、通信インターフェース５４、または同様のものなどの手段を備えてもよい。サポート・タスクをキャンセルするか、または遅延させるかの判断は、例えば、他の何らかのＵＥから先または後に受信されたサポート・リクエスト、ネットワークもしくは送信条件、システム負荷、またはその他任意数の要因もしくは考慮事項に基づいてもよい。図４のように、キャンセルの判断５６０および遅延の判断５６５の配置は例示にすぎず、タスクをキャンセルしもしくは遅延させる判断、またはタスクがキャンセルもしくは遅延されたという判断がいつ生じ得るかに関して、本発明の範囲を限定するものと解釈されてはならない。

装置４５は、サポート・タスクが開始可能かどうかを判断する、プロセッサ５０、通信インターフェース５４、または同様のものなどの手段をさらに備えてもよい。動作５７０を参照されたい。装置４５は、そのような判断を、例えば、利用可能なリソース、容量指標が送信されてからの経過時間、またはその他任意数の要因もしくは考慮事項に基づいて下してもよい。装置４５は、サポート・タスクが開始可能であり、かつ遅延もキャンセルもされていない場合に、準備完了通知を送信させる、前述のものなどの手段をさらに備えてもよい。動作５７５を参照されたい。装置４５はさらに、承諾が受信されたかどうかを判断する、上記のものなどの手段を備えてもよい。動作５８０を参照されたい。最後に、装置４５はさらに、承諾を受信するのに応答して、リクエストされたサポートに関連するデータを受信するか、またはリクエストされたサポートに関連するデータを送信させることなどによって、リクエストされたサポートを提供する、上記のものなどの手段を備えてもよい。動作５９０を参照されたい。

以下、図６を参照する。ＵＥ１１などのＵＥと、アクセス・ポイント１２などのｅＮＢとの間で例示の実施形態によりやり取りされ得る、シグナリングの例が示されている。シグナリングは、例えば、ＵＥ１１およびアクセス・ポイント１２にそれぞれ関連する装置４５などの別々の装置により可能となってもよい。なお、図６に示すように、ＵＥの範囲内の信号は、オペレーティング・システム（ＯＳ：ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ）によって最終的に受信され、ＯＳから生じ、ＯＳが送信させる。ＯＳは、例えば、メモリ５６などのメモリにおいて具現化されプロセッサ５０などのプロセッサにより実行可能な、プログラム・コード命令などを用いて、ＵＥ１１に関連する装置４５に実装されてもよい。信号は、例えば、通信インターフェース５４または同様のものによって送信され、第一次的に受信されてもよい。

したがって、ＵＥ１１は、例えば上記の実装されているＯＳを介して、大量の非緊急データの送信を伴うクラウド・サービス・サポート・タスクが利用可能になったと判断してもよい。動作６００を参照されたい。例えば、ＯＳは、デバイス・カメラを用いて撮影した写真、クラウド・データ、バックアップ、ソフトウェア更新、または地図データなど、同期化コンテンツが必要であると判断してもよい。次に、ＯＳは、データ量または緊急性などに基づいて、大量の非緊急データを送信することを伴うクラウド・サービス・サポート・タスクが延期されるべきであると判断してもよい。動作６１０を参照されたい。この時点で、ＯＳは、サポートをリクエストする信号を生成し、これを、通信インターフェース５４または同様のものに提供することなどによって、送信のために提供してもよい。動作６２０を参照されたい。続いて、サポート・リクエストは、アクセス・ポイント１２に送信されてもよい。動作６２５を参照されたい。続いて、アクセス・ポイント１２は、サポート・リクエストを受信すると、例えば開始時間または完了時間などのタスクのスケジュールを推定することなどによって、容量を判断してもよい。動作６３０を参照されたい。容量の判断は、例えば、ＵＥリンク品質、ＵＥ ＭＳＥ、またはネットワーク負荷に基づいてもよい。容量を判断した後、アクセス・ポイント１２は、続いて、タスクを開始できるまでの推定待ち時間などの容量通知を、ＵＥ１１へ送信させてもよい。動作６４０を参照されたい。ＵＥ１１は、通信インターフェース５４または同様のものなどを介して容量通知を受信した後、この情報をＯＳに渡してもよい。動作６４５を参照されたい。続いて、ＯＳは、アクセス・ポイント１２によるサポートを待つかどうか決定してもよい。動作６５０を参照されたい。待つという決定が下された場合、アクセス・ポイント１２は、それに関連する装置４５のメモリ５６およびプロセッサ５０などを介して、待機期間の間に推定スケジュールを更新してもよい。動作６６０を参照されたい。推定スケジュールは、例えば、ＵＥリンク品質、ＵＥ ＭＳＥ、および／またはネットワーク負荷に基づいて更新されてもよい。アクセス・ポイント１２は、言及したばかりの手段などを介して、サポート・タスクが開始可能であると判断すると、準備完了通知をＵＥ１１へ送信させてもよい。動作６７０を参照されたい。通信インターフェース５４または同様のものなどを介して準備完了通知を受信した後、ＵＥ１１は続いて、この情報をＯＳに渡してもよい。動作６７５を参照されたい。サポートが承諾される場合、ＯＳは、サポートの承諾を示す承諾通知信号を生成して、この信号を、通信インターフェース５４または同様のものに提供することなどによって、送信のために提供してもよい。動作６８０を参照されたい。続いて、承諾通知は、アクセス・ポイント１２へ送信されてもよい。動作６８５を参照されたい。承諾通知を受信するのに応答して、次にアクセス・ポイント１２は、ＵＥ１１のサポート・リクエストに関連するデータのためにリソースを確保してもよい。動作６９０を参照されたい。承諾通知を送信するのに応答して、または別の実施形態によればリソースが確保されたという通知（図示せず）を受信するのに応答して、ＵＥ１１は、サポート・タスクに関連するデータを送信させてもよく、さらに／またはサポート・タスクに関連するデータの受信を開始してもよい。動作６９５を参照されたい。

上記のように、図４および図５は、本発明の例示の実施形態による、装置４５、方法、およびコンピュータ・プログラム製品のフローチャートを示す。当然のことながら、フローチャートの各ブロック、フローチャート内の複数ブロックの組み合わせは、ハードウェア、ファームウェア、プロセッサ、回路、および／または１つ以上のコンピュータ・プログラム命令を含むソフトウェアの実行に関連する他のデバイスなど、様々な手段によって実装され得る。例えば、上述の手順のうちの１つ以上が、コンピュータ・プログラム命令によって具現化されてもよい。この関連で、上述の手順を具現化するコンピュータ・プログラム命令は、本発明の実施形態を採用する装置４５のメモリ・デバイス５６により記憶され、装置４５のプロセッサ５０により実行されてもよい。当然のことながら、そのような任意のコンピュータ・プログラム命令が、マシンを生じさせるよう、コンピュータまたはその他のプログラム可能装置（例えばハードウェア）上にロードされて、結果として生じるコンピュータまたはその他のプログラム可能装置が、フローチャートのブロックに規定された機能を実装するようにすることもできる。さらに、特定の形で機能するようコンピュータまたはその他のプログラム可能装置に指示することができる当該コンピュータ・プログラム命令は、コンピュータ可読メモリに記憶されて、コンピュータ可読メモリに記憶されたこの命令が、製品をもたらし、この製品の実行が、フローチャートのブロックに規定された機能を実装するようにすることもできる。さらに、コンピュータ・プログラム命令は、コンピュータまたはその他のプログラム可能装置にロードされて、コンピュータまたはその他のプログラム可能装置上で一連の動作が実行されるようにしてコンピュータに実装されるプロセスを生じさせ、コンピュータまたはその他のプログラム可能装置上で実行される命令が、フローチャートのブロックに規定された機能を実装するための動作をもたらすようにすることもできる。

よって、フローチャートの各ブロックは、規定された機能を実行するために、規定された機能を実行する手段の組み合わせ、および規定された機能を実行する動作の組み合わせをサポートする。さらに、当然のことながら、フローチャートの１つ以上のブロック、およびフローチャート内の複数ブロックの組み合わせは、規定された機能を実行する専用ハードウェア・ベースのコンピュータ・システム、または専用ハードウェアとコンピュータ命令との組み合わせによって実装可能である。

一部の実施形態では、上記の動作のうち特定のものが変更または強化されてもよい。さらに、一部の実施形態には、追加の任意選択の動作が含まれてもよく、そのうちいくつかが、図４および図５に破線で示されている。上記の動作に対する変更、追加、または強化は、任意の順序および任意の組み合わせで実行され得る。

上述の方法、装置４５、およびコンピュータ・プログラム製品は、多数の利点を提供することができる。例えば、方法、装置４５、およびコンピュータ・プログラム製品は、大量のデータを受信または送信することになるとネットワークに連絡することにより、ネットワークに便益をもたらすことができる。この事前警告は、電力効率のよい動作を可能にして、ネットワーク負荷のバランスをとるために、ネットワークが、種々のＵＥの同期化を制御／スケジューリングできるようにしてもよい。例えば、ネットワークは、夜間などのオフピーク時の間に、重い動作をスケジューリングしてもよい。ネットワークはさらに、例えば、同期化の前に別のセルにＵＥをハンドオーバすることを決定することができ、これもネットワークの負担を軽減し得る。本方法、装置４５、およびコンピュータ・プログラム製品はさらに、電力効率の向上と、データ転送速度および送信／受信容量の予測可能性の向上とを可能にすることにより、ＵＥに便益をもたらすことができる。ＵＥはさらに、大量データ同期化タスクなどのタスクを開始する前に、タスクの開始準備をすることができるか、または妥当な時間内に完了できるかの推定を受信してもよい。さらに、ＵＥは、タスクのために、例えばＬＴＥおよびＷＬＡＮのいずれかなど、種々の接続オプションのいずれかへの決定をサポートする情報を受信してもよい。

これらの発明が関連し、前述の説明および関連する図面に示された教示の利益を享受する技術分野の当業者は、本願明細書に記載された発明の、多数の変更および他の実施形態に想到するであろう。したがって、当然のことながら、本発明は、開示された特定の実施形態に限定されるものではなく、変更および他の実施形態は、添付の特許請求の範囲に記載の範囲内に含まれるものとする。さらに、前述の説明および関連する図面は、構成要素および／または機能の特定の例示の組み合わせに即して例示の実施形態を示しているが、当然のことながら、他の実施形態によって、構成要素および／または機能の他の組み合わせが、添付の特許請求の範囲に記載の範囲から逸脱することなく提供され得る。この点に関して、例えば、添付の特許請求の範囲の一部に記載されていることもある、上記で明示的に記載したものとは異なる構成要素および／または機能の組み合わせも意図されている。本願明細書では特定の用語が採用されているが、それらは、一般的かつ説明的な意味でのみ使用され、限定を目的として使用されてはいない。

Claims (26)

1. タスクに関連するデータの量の通知または前記タスクの緊急性の通知のうちの少なくとも一方を含む、サポート・リクエストを送信させることと；
   前記タスクをサポートするための容量通知を含む通知メッセージを受信することと；
   前記通知メッセージに少なくとも部分的に基づいて、前記タスクを待つか、または拒否するかを決定することと；
   を含み、
   前記サポート・リクエストを送信させることは、第１アクセス・ポイントへ前記サポート・リクエストを送信させることを含み、前記容量通知を受信することは、前記第１アクセス・ポイントから前記通知メッセージを受信することを含み、
   前記タスクを拒否すると決定された場合に、前記タスクに関連する前記データを、第２アクセス・ポイントから受信するか、または前記第２アクセス・ポイントへ送信させることをさらに含む、
   方法。
2. 前記タスクを待つと決定された場合に、
   １つ以上のアイドル機能を実行することと、
   準備完了通知を受信することと、
   前記タスクに進むか、またはキャンセルするかを決定することと、
   前記タスクに進むと決定された場合に、
   ・承諾通知を送信させることと、
   ・前記タスクに関連する前記データを受信するか、または送信させることと；
   をさらに含む、請求項１に記載の方法。
3. 前記サポート・リクエストを送信させることは、第１アクセス・ポイントへ前記サポート・リクエストを送信させることを含み、前記通知メッセージを受信することは、前記第１アクセス・ポイントから前記通知メッセージを受信することを含み；前記方法は、
   前記タスクをキャンセルすると決定された場合に、前記タスクに関連する前記データを、第２アクセス・ポイントから受信するか、または前記第２アクセス・ポイントへ送信させることをさらに含む、
   請求項１または２のいずれかに記載の方法。
4. 前記タスクを待つか、または拒否するかの前記決定は、履歴情報、周辺領域の測定、より良好な接続が利用可能かどうか、電池残量、またはユーザ・アクティビティのうちの少なくとも１つに少なくとも部分的に基づく、請求項１〜３のいずれかに記載の方法。
5. 前記タスクに進むか、またはキャンセルするかの前記決定は、履歴情報、周辺領域の測定、より良好な接続が利用可能かどうか、電池残量、またはユーザ・アクティビティのうちの少なくとも１つに少なくとも部分的に基づく、請求項２〜４のいずれかに記載の方法。
6. 前記タスクに進むか、または遅延させるかを決定することをさらに含む、請求項１〜５のいずれかに記載の方法。
7. 前記タスクに進むか、または遅延させるかの前記決定は、ユーザ機器のステータスに少なくとも部分的に基づく、請求項６に記載の方法。
8. 前記１つ以上のアイドル機能は、位置を更新すること、新たなセルに接続すること、ページング情報を受信すること、接続モードを保持させること、および低電力消費モードに入らせることを含む、請求項２記載の方法。
9. タスクに関連するデータの量の通知、または前記タスクの緊急性の通知のうちの少なくとも一方を含む、サポート・リクエストを受信することと；
   前記サポート・リクエストに基づいて、前記タスクをサポートするための容量を求めることと；
   前記容量の通知を含む通知メッセージを送信させることと；
   前記タスクのサポートが開始可能かどうかを判断することと；
   前記タスクのサポートが開始可能であると判断された場合に、
   ・準備完了通知を送信させることと、
   ・承諾通知が受信された場合に、前記タスクに関連する前記データを受信するかまたは送信させることによって、前記タスクをサポートすることと；
   前記容量の前記通知を送信させるより前に、前記タスクをサポートするか、またはハンドオーバを実行するかを決定することと；
   ハンドオーバを実行すると決定された場合に、ハンドオーバ手順を開始させることと；
   を含む、方法。
10. 前記タスクをサポートするか、または前記ハンドオーバを実行するかの前記決定は、前記サポート・リクエストまたはネットワーク負荷に基づく、請求項９に記載の方法。
11. タスクに関連するデータの量の通知または前記タスクの緊急性の通知を少なくとも含む、サポート・リクエストを送信させる手段と；
    前記タスクをサポートするための容量通知を含む通知メッセージを受信する手段と；
    前記通知メッセージに少なくとも部分的に基づいて、前記タスクを待つか、または拒否するかを決定する手段と；
    を備え、
    前記サポート・リクエストを送信する手段は、前記サポート・リクエストを第１アクセス・ポイントへ送信するように構成され、
    前記通知メッセージを受信する手段は、前記第１アクセス・ポイントから前記通知メッセージを受信するように構成され、
    前記装置は、前記タスクを拒否すると決定された場合に、前記タスクに関連する前記データを、第２アクセス・ポイントから受信するか、または前記第２アクセス・ポイントへ送信する手段を更に備える、
    装置。
12. 前記タスクを待つか、または拒否すると決定された場合に、
    １つ以上のアイドル機能を実行することと、
    準備完了通知を受信することと、
    前記タスクに進むか、またはキャンセルするかを決定することと、
    前記タスクに進むと決定された場合に、
    ・承諾通知を送信させることと、
    ・前記タスクに関連する前記データを受信するかまたは送信させることと；
    を行う手段を更に備える、請求項１１に記載の装置。
13. 前記サポート・リクエストを送信する手段は、前記サポート・リクエストを第１アクセス・ポイントへ送信するように構成され、
    前記通知メッセージを受信する手段は、前記第１アクセス・ポイントから前記通知メッセージを受信するように構成され、
    前記装置は、前記タスクをキャンセルすると決定された場合に、前記タスクに関連する前記データを、第２アクセス・ポイントから受信するか、または前記第２アクセス・ポイントへ送信する手段を更に備える、
    請求項１２のいずれかに記載の装置。
14. 前記タスクを待つか、または拒否するかの前記決定は、履歴情報、周辺領域の測定、より良好な接続が利用可能かどうか、電池残量、またはユーザ・アクティビティのうちの少なくとも１つに少なくとも部分的に基づく、請求項１１〜１３のいずれかに記載の装置。
15. 前記タスクに進むか、またはキャンセルするかの前記決定は、履歴情報、周辺領域の測定、より良好な接続が利用可能かどうか、電池残量、またはユーザ・アクティビティのうちの少なくとも１つに少なくとも部分的に基づく、請求項１２〜１４のいずれかに記載の装置。
16. 前記タスクに進むか、または遅延させるかを決定する手段をさらに備える、請求項１１〜１５のいずれかに記載の装置。
17. 前記タスクに進むか、または遅延させるかの前記決定は、前記装置に関連するユーザ機器のステータスに少なくとも部分的に基づく、請求項１６に記載の装置。
18. 前記１つ以上のアイドル機能は、位置を更新すること、新たなセルに接続すること、ページング情報を受信すること、接続モードを保持させること、および低電力消費モードに入らせることを含む、請求項１２に記載の装置。
19. タスクに関連するデータの量の通知、または前記タスクの緊急性の通知のうちの少なくとも一方を含む、サポート・リクエストを受信する手段と；
    前記サポート・リクエストに基づいて、前記タスクをサポートするための容量を求める手段と；
    前記容量の通知を含む通知メッセージを送信させる手段と；
    前記タスクのサポートが開始可能かどうかを判断する手段と；
    前記タスクのサポートが開始可能であると判断された場合に、
    ・準備完了通知を送信させることと、
    ・承諾通知が受信された場合に、前記タスクに関連する前記データを受信するかまたは送信させることによって、前記タスクをサポートすることと；
    を行う手段と；
    を備え、
    前記通知メッセージを送信させるより前に、前記タスクをサポートするか、またはハンドオーバを実行するかを決定する手段と；
    ハンドオーバを実行すると決定された場合に、ハンドオーバ手順を開始する手段と；
    を更に備える、装置。
20. 前記タスクをサポートするか、または前記ハンドオーバを実行するかの前記決定は、前記サポート・リクエストまたはネットワーク負荷に基づく、請求項１９に記載の装置。
21. 処理手段と、プログラム命令を格納する記憶手段とを有する装置であって、前記プログラム命令は、前記処理手段に実行されることにより、前記装置に、請求項１から１０のいずれかに記載の方法を遂行させるように構成される、装置。
22. 装置の処理手段に実行されることにより、前記装置に、請求項１から１０のいずれかに記載の方法を遂行させるように構成されるプログラム命令を備える、コンピュータプログラム。
23. ユーザ機器および第１アクセス・ポイントを有するシステムであって；
    前記ユーザ機器は、少なくとも１つの第１プロセッサと、第１プログラム・コード命令を記憶する少なくとも１つの第１メモリとを有する第１装置を有し、前記第１プログラム・コード命令は、前記少なくとも１つの第１プロセッサに実行されることにより、前記第１装置に少なくとも、
    タスクに関連するデータの量の通知、または前記タスクの緊急性の通知のうちの少なくとも一方を含む、サポート・リクエストを前記第１アクセス・ポイントへ送信させることと；
    前記タスクをサポートするための容量通知を含む通知メッセージを前記第１アクセス・ポイントから受信することと；
    前記通知メッセージに少なくとも部分的に基づいて、前記タスクを待つか、または拒否するかを決定することと；
    前記タスクを待つか、または拒否すると決定された場合に、
    １つ以上のアイドル機能を実行することと、
    前記第１アクセス・ポイントから準備完了通知を受信することと、
    前記タスクに進むか、またはキャンセルするかを決定することと、
    前記タスクに進むと決定された場合に、
    承諾通知を送信させることと；
    を行わせるよう構成され、さらに、前記第１アクセス・ポイントは、少なくとも１つの第２プロセッサと、第２プログラム・コード命令を記憶する少なくとも１つの第２メモリとを有する第２装置を有し、前記第２プログラム・コード命令は、前記少なくとも１つの第２プロセッサに実行されることにより、前記第２装置に少なくとも、
    前記サポート・リクエストを受信することと；
    前記サポート・リクエストに基づいて、前記タスクをサポートするための容量を求めることと；
    前記容量の通知を含む通知メッセージを送信させることと；
    前記タスクのサポートが開始可能かどうかを判断することと；
    前記タスクのサポートが開始可能であると判断された場合に、
    前記準備完了通知を送信させることと、
    前記承諾通知が受信された場合に、前記タスクに関連する前記データを受信するかまたは送信させることによって、前記タスクをサポートすることと；
    を行わせるよう構成され、
    前記第１アクセス・ポイントには、前記通知メッセージを送信させるより前に、前記タスクをサポートするか、またはハンドオーバを実行するかを決定することと、ハンドオーバを実行すると決定された場合に、ハンドオーバ手順を開始させることとをさらに行わせ、
    前記ユーザ機器には、前記ハンドオーバ手順が開始された後、前記タスクに関連する前記データを、前記第２アクセス・ポイントから受信するか、または前記第２アクセス・ポイントへ送信させることをさらに行わせる、
    システム。
24. 前記システムは、第２アクセス・ポイントをさらに有し、
    前記ユーザ機器には、前記タスクを拒否すると決定された場合に、前記タスクに関連する前記データを、前記第２アクセス・ポイントから受信するか、または前記第２アクセス・ポイントへ送信させることをさらに行わせる、請求項２３に記載のシステム。
25. 前記システムは、第２アクセス・ポイントをさらに有し、
    前記ユーザ機器には、前記タスクをキャンセルすると決定された場合に、前記タスクに関連する前記データを、前記第２アクセス・ポイントから受信するか、または前記第２アクセス・ポイントへ送信させることをさらに行わせる、請求項２３または２４のいずれかに記載のシステム。
26. 前記ユーザ機器には、前記タスクに進むか、または遅延させるかを決定することをさらに行わせる、請求項２３〜２５のいずれかに記載のシステム。

Images