JP2016537870A - アプリケーションベースのネットワーク情報維持 - Google Patents

Abstract

種々の通信システムは、ネットワーク情報の通知から利益が得られる。例えば、ネットワーク装置のアプリケーションによりデータ技術を選択的に使用することでセルラー最適化が達成され、これは、外部データ要求の必要性を低減する通知を現在ネットワーク状態のアプリケーション観察と整合して使用することから更に利益が得られる。ある実施形態による方法は、ユーザ又はアプリケーションのネットワークサービス実現性を監視することを含む。又、この方法は、ユーザ又はアプリケーションに対してネットワークサービス実現性が検出されたときにユーザ装置にプッシュメッセージを送信することも含む。このプッシュメッセージは、ネットワークサービス実現性に関連した少なくとも１つのスレッシュホールドを指示する。【選択図】 図２

Description

関連出願の相互参照：本出願は、２０１３年５月１７日に出願された米国特許出願第１３／８９７，０４６号（‘０４６出願）の一部継続である２０１３年１０月１５日に出願された米国特許出願第１４／０５４，２８７号（‘２８７出願）の利益及び優先権を主張するものである。‘２８７出願及び‘０４６出願は、参考としてここにそのまま援用される。

種々の通信システムは、ネットワーク情報の通知から利益が得られる。例えば、ネットワーク装置のアプリケーションによりデータ技術を選択的に使用することでセルラー最適化が達成され、これは、外部データ要求の必要性を低減する通知を現在ネットワーク状態のアプリケーション観察と整合して使用することから更に利益が得られる。

コアネットワークのメディアオプチマイザーは、クライアントのアプリケーションのみにより制御される幾つかの適応を幾つかのストリーミングアプリケーションで遂行させることはできない。これは、例えば、ユーザ装置（ＵＥ）Ａｐｐ／アプリケーションがビデオの次のセクションに対応する要求されたユニフォームリソースロケータ（ＵＲＬ）を送信するときにそれらのプロトコル内にビデオの次のセクションしかダウンロードできない場合にビデオをプレフィルすべきか又はダウンロードのみすべきかジャストインタイムで適応させる場合に言えることである。ブラウジングゲートウェイは、メディアオプチマイザーの一例である。あるメディアオプチマイザーは、進化型パケットコア（ＥＰＣ）の外部に配置される。これらの解決策は、ＵＥが無線アクセスネットワーク状態又はコアネットワークトラフィック状態を知ることを要求し、そしてそれらの状態は、時間と共に変化し得る。

現在のワイヤレス通信システムでは、ワイヤレスネットワーク利用度は、ビジーな時間中に平均で約３０％に過ぎず、これは、ネットワークが７０％アイドル状態であることを意味する。許可共有アクセス（ＡＳＡ）及び連続するバースト的ユーザトラフィックパターンでは、この多量のアイドルリソースを、種々のアプリケーションにより使用するためのターゲットとすることができる。

特に関心のあるワイヤレストラフィックは、プリフェッチのような目的に対してビットレートが高く、レイテンシーが低く、カバレッジの一貫性が高く、及び／又はネットワーク利用度が低いことを要求するトラフィックである。しかしながら、ワイヤレスリソースは、例えば、ＡＳＡ、小型セル、リアルタイムビデオ、及び負荷のかかったセルの縁での非常にビットレートの高いサービスのために、益々間欠的なものとなる。

カバレッジホールを識別する技術が存在する。例えば、付加的な小型セルと、ある場合にはアンテナのリモート電気的チルトとを通して、付加的な容量／カバレッジを追加することができる。しかしながら、ビットレートの高いアプリケーションは、ワイヤレスシステム全体にわたって常に良好に機能することはできない。

ネットワーク状態に関する質問に応答するために知識サーバーアーキテクチャーが提供される。例えば、知識サーバーアーキテクチャーでは、アプリケーションは、ユニフォームリソースロケータ（ＵＲＬ）を使用して知識サーバーに質問することができる。それに応答して、知識サーバーは、例えば、ネットワーク利用度又は負荷が低いために及び／又はおそらくネットワークの制約のために今がプリフェッチを行う良い時であるかどうかを含むネットワークインサイト(insight)を与えることができる。

しかしながら、アプリケーション（Ａｐｐ）が新たに利用可能なリソースを発見することがゆっくりであるときには高周波（ＲＦ）リソースの浪費となり得る。他方、Ａｐｐがネットワーク状態に関してネットワーク又はサーバーを繰り返しテストし又はそれに質問する場合にはＲＦリソース及びＵＥバッテリの両方の浪費となり得る。同様に、ユーザがアプリケーションに対してタップを行ってそれが機能するかどうか調べるために待機することもユーザの時間の浪費となり得る。更に、ネットワークが変化したネットワーク状態を発見することがゆっくりであるときには、アプリケーションは、もはや適当でない振舞いで続くことになる。例えば、カバーされたホールのエリアに向かって続くか又はプリフェッチへと続くことが含まれる。

空中性能に対するカバレッジの欠落又は充分なセルラー性の欠落は、顧客経験事項及び顧客経験管理（ＣＥＭ）の要素である。顧客の観点から、顧客は、ある時間間隔にわたり、典型的に、特定の場所ではコールが一貫してドロップすることを学習する。例えば、特定のユーザにとって、そのような場所は、カフェテリアへの又は自宅と職場との間の１つのルートの特定の部分を含む。従って、この典型的なユーザは、それらのエリアでコールを発信することを簡単に回避したり、それらのエリアに入る前にコールを完了するように努力したりする。ワイヤレスカバレッジの改善／セルラーシステム内のカバレッジホールの排除は、オペレータのためのリソース集約的プロセスである。例えば、費用のかかる１つの例は、オペレータが付加的な小型のセルを配備した場合である。

顧客サービスプロバイダー又はワイヤレスインフラストラクチャープロバイダーは、カバレッジホールを修正するとき、顧客経験及び／又は顧客満足度を改善するように行う。しかしながら、それらの領域においてリアルタイムワイヤレスの使用を既に一貫して又は習慣的に回避している既存の顧客にとって、顧客経験の改善は、著しく軽視され又は全く避けられている。

ある実施形態による方法は、ユーザ又はアプリケーションのネットワークサービス実現性(viability)を監視することを含む。又、この方法は、ユーザ又はアプリケーションに対してネットワークサービス実現性が検出されたときにユーザ装置にプッシュメッセージを送信することも含む。このプッシュメッセージは、ネットワークサービス実現性に関連した少なくとも１つのスレッシュホールドを指示する。

ある実施形態による方法は、ユーザ装置又はユーザ装置のアプリケーションの機能をネットワーク要素から受け取った第１のネットワークインサイトに基づいて調整することを含む。又、この方法は、ユーザ装置に対応する少なくとも１つの環境状態を決定することも含む。更に、この方法は、少なくとも１つの環境状態を監視することも含む。加えて、この方法は、少なくとも１つの環境状態が所定の条件を満足するときにアプリケーション又はユーザ装置の機能を再調整することも含む。

ある実施形態の装置は、少なくとも１つのプロセッサと、コンピュータプログラムコードを含む少なくとも１つのメモリとを備えている。少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、ユーザ又はアプリケーションのネットワークサービス実現性を監視するようにさせるよう構成される。又、少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、ユーザ又はアプリケーションに対してネットワークサービス実現性が検出されたときにユーザ装置で実行されるアプリケーションにプッシュメッセージを送信するようにさせるよう構成される。このプッシュメッセージは、ネットワークサービス実現性に関連した少なくとも１つのスレッシュホールドを指示する。

ある実施形態の装置は、少なくとも１つのプロセッサと、コンピュータプログラムコードを含む少なくとも１つのメモリとを備えている。少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、ユーザ装置又はユーザ装置のアプリケーションの機能をネットワーク要素から受け取った第１のネットワークインサイトに基づいて調整するようにさせるよう構成される。又、少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、ユーザ装置に対応する少なくとも１つの環境状態を決定するようにさせるよう構成される。更に、少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、少なくとも１つの環境状態を監視するようにさせるよう構成される。加えて、少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、少なくとも１つの環境状態が所定の条件を満足するときにアプリケーション又はユーザ装置の機能を再調整するようにさせるよう構成される。

ある実施形態による装置は、ユーザ又はアプリケーションのネットワークサービス実現性を監視する手段を備えている。又、この装置は、ユーザ又はアプリケーションに対してネットワークサービス実現性が検出されたときにユーザ装置にプッシュメッセージを送信する手段も備えている。このプッシュメッセージは、ネットワークサービス実現性に関連した少なくとも１つのスレッシュホールドを指示する。

ある実施形態による装置は、ユーザ装置又はユーザ装置のアプリケーションの機能をネットワーク要素から受け取った第１のネットワークインサイトに基づいて調整する手段を備えている。又、この装置は、ユーザ装置に対応する少なくとも１つの環境状態を決定する手段も備えている。更に、この装置は、少なくとも１つの環境状態を監視する手段も備えている。加えて、この装置は、少なくとも１つの環境状態が所定の条件を満足するときにアプリケーション又はユーザ装置の機能を再調整する手段も備えている。

非一時的なコンピュータ読み取り可能な媒体は、ある実施形態において、ハードウェアで実行されたときにプロセスを遂行するインストラクションでエンコードされる。そのプロセスは、ユーザ又はアプリケーションのネットワークサービス実現性を監視することを含む。又、このプロセスは、ユーザ又はアプリケーションに対してネットワークサービス実現性が検出されたときにユーザ装置にプッシュメッセージを送信することも含む。このプッシュメッセージは、ネットワークサービス実現性に関連した少なくとも１つのスレッシュホールドを指示する

非一時的なコンピュータ読み取り可能な媒体は、ある実施形態において、ハードウェアで実行されたときにプロセスを遂行するインストラクションでエンコードされる。そのプロセスは、ユーザ装置又はユーザ装置のアプリケーションの機能をネットワーク要素から受け取った第１のネットワークインサイトに基づいて調整することを含む。又、このプロセスは、ユーザ装置に対応する少なくとも１つの環境状態を決定することも含む。更に、このプロセスは、少なくとも１つの環境状態を監視することも含む。加えて、このプロセスは、少なくとも１つの環境状態が所定の条件を満足するときにアプリケーション又はユーザ装置の機能を再調整することも含む。

本発明を適切に理解するため、添付図面を参照する。

ある実施形態による方法の信号フロー図である。 ある実施形態による方法を示す。 ある実施形態による別の方法を示す。 ある実施形態による更に別の方法を示す。 ある実施形態によるシステムを示す。 ある実施形態によるメッセージフローを示す。 ある実施形態による別のメッセージフローを示す。 ある実施形態による方法を示す。 ある実施形態による信号フローを示す。 ある実施形態により、ネットワーク状態のアプリケーション検出を伴わずに適用される知識サーバーインサイトの一例を示す。 ある実施形態により、ネットワーク状態のアプリケーション検出と共に適用される知識サーバーインサイトの一例を示す。 ある実施形態によるピンポンシナリオを示す。 ある実施形態によるランピングインサイトを示す。

ここに述べる幾つかの実施形態は、ワイヤレス状態が特定の状態に到達したときにアプリケーションレベルプッシュ通知のための知識サーバー（ＫＳ）プッシュ通知サービスにユーザ装置（ＵＥ）が契約するのを許すＫＳプッシュ通知サービスを提供することに関する。この状態又はトリガーは、特定のＵＥアプリケーションに即座に関連する。例えば、特定のＵＥアプリケーションが、現在、ある特定の振舞いに適した状態にある。この通知が、次いで、あるリアクションを遂行するためにアイドルのワイヤレスリソースを待機しているアプリケーションをトリガーする。

これらのリアクション使用のケースは、アプリケーション（Ａｐｐ）及び／又はユーザへの幾つかの高ビットレートサービスをバックグランドプリフェッチ及び／又は広告することを含む。更に、スマートホンでは、このプッシュされる高周波（ＲＦ）状態更新通知は、あるＡｐｐ／連絡先に対してアイコン又はバッジの変更を行って、それらのＡｐｐ／連絡先が今や「実現可能」であることを指示する。

このプッシュ通知サービスは、知識サーバー応答が装置により最後に質問されたときと同じである場合に、考えられる周期的な知識サーバーＵＲＬ質問の遂行で消費されるワイヤレスリソース及びバッテリ消耗の量を著しく減少することができる。

より一般的には、ある実施形態は、浪費されるリソースをアプリケーションが発見するのを加速するメカニズムを提供し、それらがリソースを戦略的に使用して、ネットワークの制限／混雑に関して対処できるようにする。同様に、ある実施形態は、例えば、ストリーミング映画、ビデオ電話、プリフェッチ、等の高ビットレートアプリケーションに対して充分なネットワークリソースがあることをアプリケーションが発見するのを加速するメカニズムを提供する。

そのような過酷なアプリケーションは、高いビットレート、無線カバレッジ、及び一貫した状態に関してワイヤレスシステムの両方の需要がある。又、それらは、アプリケーションサーバーが機能し且つ過負荷にならないといった要求もある。

以前に利用できなかった付加的なワイヤレスリソースが利用できるようになるケースもある。付加的なワイヤレスリソースが現在利用できるが、完全には使用されていないケースでは、ある実施形態は、リソース使用及び顧客経験の両方を改善する仕方を提供する。

そのような機会は、それ自体、小型セルの配備の後に、又は許可された共有アクセスが付加的なスペクトルを通信サービスプロバイダー（ＣＳＰ）に返送した後に、或いは他の過酷なユーザ負荷が消散した後に、生じる。ある実施形態では、付加的なアイドルの及び／又は未使用のワイヤレスリソースが利用可能となり且つアイドル状態にあるときに使用及び／又は意識をできるだけ迅速に且つ戦略的に促進させる。従って、ある実施形態は、カバレッジホールそれ自体を直接的に取り扱うのではなく、むしろ、以前のカバレッジホールに存在するもののような新たに利用できるＲＦリソースを迅速に利用することを取り扱う。

ある実施形態は、カバレッジホールを取り扱った後に、例えば、既知のカバレッジホールを固定するために付加的な小型セル又は他のセルラーリソースに投資した後に、オペレータが提供する改善された顧客経験の量を著しく増大又は増加することができる。更に、この形式の通知は、プレミアムサービスとして提供される。例えば、そのような通知は、顧客経験管理を通して識別されるプレミアムユーザに対して、或いはそのようなワイヤレス経験を向上させるために増額を支払うユーザに対して、与えることができる。別の実施形態では、そのようなメッセージは、改善と同じ地理的領域においてコール又はビデオの質について不平のあるユーザに送信される。更に別の実施形態では、そのようなメッセージは、特定のエリアの無線特性に関して知識サーバーに以前に質問したユーザに送信される。

それに加えて、それらの通知は、同じ領域内の多数のＵＥに同時に通知する試みを回避するために更にプライオリティ決めされる。従って、１秒ウインドウ、５秒ウインドウ、又は１分ウインドウのようなタイムウインドウが定義され（他の時間長さも許される）、そして最もプライオリティの高い通知だけが所与のウインドウ内に送信される。それとは別に、限定された数、例えば、５つの通知だけが所与のタイムウインドウ内に送信されてもよい。通知が制限されるかどうかは、通知がユーザに表示されるかどうかに依存する。例えば、アプリケーションにより自動的に使用されると予想される通知については、タイムウインドウは、より狭く定義され且つより限定的であり、一方、ユーザが見ると予想される通知は、より広く定義され且つあまり限定的ではない。

更に、これらの通知は、ウオッチ(watch)において構成された時間間隔及び／又は場所のスケジュールに基づいてプライオリティが決めされる。例えば、特定の判断を行う直前にアプリケーションに対して通知が最も重要で及び／又は影響力が強いことがある。その一例は、ビデオの次のセグメントの圧縮レベルがセグメント当たり一度又は１０秒ごとに一度決定されるようなビデオである。このケースでは、ハンドセットのアプリケーションは、通知の影響力が特に大きい特定の時間間隔の知識を含むようにウオッチを構成する。ユーザがそれらの通知に基づいてルートを選択する別の実施形態では、２つの異なるルートの一方が選択され且つ変更があった特定の交差点にユーザが接近するときに、一方又は他方のルートに沿ったワイヤレス状態の変更の通知の影響力が特に大きくなる。その結果、アプリケーションエンハンサーは、ウオッチにおける特定の地理的場所を構成して、そのウオッチに対応する通知があり且つユーザがその特定の場所に入る場合に、その通知に高いプライオリティを与えねばならないことを指示する。そのような状態は、ユーザが、前記交差点／場所を通過した後に、例えば、他の場所において、一方のルート又は他方のルートを丁度選択したときに生じる。

更に、ある実施形態は、情報がおそらく加入者にとって有用であるか又は重要である場合を除いてユーザに警告又はメッセージを与えることを回避する。従って、ここに述べるメカニズムは、単に、ＵＥがいつでもカバレッジに再入するときＵＥがユーザ又はアプリケーション（１つ又は複数）に警告するというものではない。同様にある実施形態では、ホットスポット及び他のローカルエリアワイヤレスアクセスポイントによって提供される接続サービスのようなサービスの通知をプッシュすることが指令されない。

従って、ある実施形態は、ユーザにとって不充分なカバレッジ／サービスの以前に確立された履歴と共に地理的領域においてカバレッジの改善から得られる顧客経験改善実現の程度を高めるための技術を提供する。更に、ある実施形態は、第１のネットワーク要素、例えば、顧客経験管理（ＣＥＭ）エンティティがプロセスを遂行できる顧客経験改善を高めるための技術に関する。このプロセスは、少なくとも第１ユーザ及び／又はアプリケーション（Ａｐｐ）のためのネットワークサービス実現性ウオッチをネットワークが生成することを含む。又、このプロセスは、ユーザのワイヤレスサービス実現性状態を監視するためにメッセージングを遂行することも含む。ユーザのためのネットワークサービス実現性ウオッチが満足されたことを検出すると、ネットワークは、それに対応するＡｐｐ／ユーザへのアプリケーションレベルプッシュ通知を開始することができる。

プッシュ通知は、バッググランドトラフィックを転送するためのアプリケーションの開始又はバッジの変更、スマートホンＡｐｐアイコン、又は連絡先アイコン、の少なくとも１つをトリガーすることができる。

ユーザ装置のＡｐｐは、サービス実現性ウオッチを生成することができる。それとは別に、ネットワークは、ウオッチを生成することができる。例えば、ユーザパターンが所定の基準に一致する場合には、ウオッチを生成することができる。

ウオッチは、要求されたビットレート、遅延、利用度、等の無線状態を含む。又、ウオッチは、特定の場所も含む。更に、ウオッチは、場所ごとに特定の場所の無線状態に焦点を合わせることができる。

ネットワーク要素は、現在ペンディング中のサービス実現性ウオッチをワイヤレスネットワークに通知することができる。その結果、ワイヤレスネットワークは、より厳密な受け入れ制御を行うことができる。例えば、より厳密な受け入れ制御は、スレッシュホールド量より多い付加的な、例えば、高い値のウオッチが確立されることを検出するのに応答して行われる。別の実施形態では、ネットワークは、構成されたウオッチを伴うユーザが相対的に接続された状態に優先的に留まるようにさせて、ネットワークが、構成されたネットワーク状態ウオッチを良好に監視する目的で、ユーザのＲＦ状態をより正確に監視できるようにする。この実施形態は、ウオッチによりカバーされる時間間隔中にユーザがアプリケーショントラフィックを遂行しないケースにより関連している。

ユーザのワイヤレス状態を監視するためのメッセージングは、ワイヤレスネットワーク要素へのメッセージング、例えば、ユニキャストメッセージングである。それとは別に、又はそれに加えて、メッセージングは、ワイヤレスネットワークを現在使用している他のワイヤレスユーザのグループへのメッセージングを含む。

ネットワーク要素は、ＣＥＭサーバー、知識サーバー、或いはプッシュ通知サーバーである。ネットワーク要素は、ユーザエリアの無線状態を連続的に監視する。例えば、監視は、高周波（ＲＦ）メッセージング、例えば、無線リソース制御（ＲＲＣ）メッセージング、ハンドオフ及び／又はハンドオーバーメッセージング、トラックエリア更新（ＴＡＵ）、位置エリア更新（ＬＡＵ）、レポートエリア更新（ＲＡＵ）、及び無線クオリティレポート、例えば、チャンネルクオリティインジケータ（ＣＱＩ）、基準信号受信クオリティ（ＲＳＲＱ）、基準信号受信電力（ＲＳＲＰ）、又は他の測定レポートメッセージングに基づく。又、監視は、当該エリア、例えば、ユーザ装置（ＵＥ）が現在存在するエリアに対応する進化型ノードＢ（ｅＮＢ）からの動作及び維持（Ｏ＆Ｍ）メッセージングも含む。

構成されたウオッチ基準に到達したときに前記プッシュ通知をいつ自動的にトリガーすべきか決定するために、種々の基準を使用することができる。例えば、ネットワーク又は装置或いは装置のＡｐｐは、イベント検出の際にサービス実現性ウオッチを自動的に生成することができる。

イベントは、例えば、ＵＥがスレッシュホールド量より大きな特定の地理的領域を横断したことである。そのような基準は、ユーザが、地理的領域におけるコール発信の成功が以前にないことに基づきその領域においてコールを発信しないよう自己トレーニングする通勤者であることを意味する。換言すれば、ユーザは、ユーザ自身の経験から、又は他のユーザからのレポートから、特定領域にカバレッジホールがあることに気付く。それ故、その基準は、特定のＵＥがコール、又は他のリアルタイム通信、例えば、ビデオチャットをこの地理的領域内に首尾良く発信していないことを含む。

それに加えて、ＵＥは、複数の同時ウオッチを構成する。そのようなケースでは、通知は、例えば、アプリケーションが２つの異なるナビゲーションルートを考慮する場合に、どのウオッチが満足されたか指示するインデックスを含む。更に、別の実施形態では、ウオッチは、２つの異なる場所又はナビゲーションルート間の相対的なネットワーク状態を監視するように構成される。例えば、ウオッチは、他方のルートに対する一方のルートのネットワーク状態の相対的な良好さがスレッシュホールド量よりも変化する場合に通知を遂行するように構成される。

更に、ウオッチのＡｐｐ構成は、どれほど長く又は一貫してネットワーク状態が予想されるかといったウオッチに関連した時間間隔の要求を指示し／課する。カバレッジの改善が行われた後に、プッシュメッセージがユーザ装置へ送信され、例えば、カバレッジ改善に続いてエリア内の改善された無線状態をユーザに通知することができる。それとは別に、プッシュ通知は、カバレッジホールの限界に関してユーザの予想を設定するために特定エリアにおけるカバレッジ問題の予想期間をユーザ又はユーザ装置に通知してもよい。

ウオッチの生成を招く別のイベントは、ＵＥ／Ａｐｐ開始サービスである。例えば、イベントは、ＵＥ／Ａｐｐ開始サービスが、例えば、ネットワーク又はＡｐｐサーバーエラーのために失敗したことである。又、ウオッチは、イベントの場所、及び／又はそのイベントがどれほど最近であるかのスレッシュホールド時間間隔も考慮に入れる。例えば、短い時間間隔内に多数の失敗があると、ウオッチがトリガーする。イベントは、場所、時刻、曜日、等の近付きつつあるコンテキストに関して検出される。更に、プッシュメッセージは、イベントのタイミング又は場所に対応するようにタイミング合わせされる。例えば、ユーザが朝の通勤時間中にトラブルに遭遇した場合には、プッシュメッセージは、朝の通勤時間中に送信される。同様に、ユーザが駅でトラブルに遭遇した場合には、プッシュメッセージは、プッシュメッセージは、ユーザが同じ駅に次に来たときに送信される。更に、構成されたウオッチは、一連の場所に対応し、各場所は、その後の将来の時間間隔に関連付けられ、ウオッチは、ユーザが計画した主要の又は別のナビゲーションルートに対応するように構成される。

ウオッチの生成を招く別のイベントは、特定の地理的領域に、カバレッジ／ワイヤレスサービスクオリティの著しい増加があったことの検出である。例えば、ネットワーク要素は、この第１の地理的領域において、カバレッジが以前にスレッシュホールドより一貫して悪かったが、現在は、スレッシュホールドより一貫して良好であることを検出する。

ネットワーク要素は、サービス実現ウオッチが満足されることを検出すると、ＵＥ／加入者への知識サーバー（ＫＳ）プッシュメッセージングをトリガーする。第１の地理的領域内のユーザとの首尾良いコールをネットワークが検出した場合には、ユーザへのメッセージングを自動的に回避することができ、その第１の地理的領域ではコールが以前に一貫して不首尾であった。換言すれば、プッシュメッセージングの送信は、プッシュメッセージがユーザに対して有益であることをネットワークが決定することを条件とする。カバレッジがあることをユーザが既に知っている場合には、メッセージを送信する必要がない。

例えば、特定の実施形態において、サーバーは、第１の地理的領域でカバレッジ／ワイヤレスサービスクオリティの顕著な増加が達成されたことを検出する。更に、サーバーは、この第１の地理的領域でカバレッジが以前にスレッシュホールドよりも一貫して悪かったことを検出する。更に、サーバーは、次の条件を満足する少なくとも１つのＵＥを識別する。例えば、その条件は、ＵＥがこの第１の地理的領域をスレッシュホールド量以上に横断したことを含む。従って、ＵＥのユーザは、この地理的領域においてコールを発信するか又は他のリアルタイム通信に関わることのないように潜在的に自己トレーニングした通勤者である。又、その条件は、この第１の地理的領域内でＵＥがコール又は他のリアルタイム通信を発信しないことも含む。換言すれば、ＵＥは、それを首尾良く行わないか、及び／又はカバレッジ改善に続いてそれを行わない。ネットワーク要素がそのようなＵＥを検出するのに応答して、ネットワーク要素は、ＵＥ／加入者へのメッセージングをトリガーして、この第１の地理的領域に新たに向上され／拡張されたネットワークカバレッジ／クオリティがあることを指示する。

メッセージングは、種々の仕方で限定することができる。例えば、メッセージングは、カバレッジ改善の前に、以前に特定の地理的領域をスレッシュホールド量以上に通過した加入者に限定される。それとは別に、又はそれに加えて、メッセージングは、典型的にコール／リアルタイム通信をスレッシュホールド量以上に発信する加入者に限定され、これは、このエリアにおけるコールの省略、即ち加入者へのそのようなメッセージングの関連性の適当な指示子を意味する。

別の選択肢は、第１の地理的領域に入る直前にコールを終了する加入者にメッセージングが限定されることである。そのようなアクションは、加入者が、今や新たなカバレッジを有する第１の地理的領域に入る直前に、コールの終了を急ぐことを意味する。例えば、トンネルは、以前はカバレッジがなかったが、今やカバレッジを有する。そのような環境では、ユーザは、トンネル内でコールを失うおそれがあるためにコールを終了する。しかしながら、ユーザがトンネル内でもカバレッジが続いていることが分かると、コールを維持したり又はトンネル内にいる間に新たなコールを発信したりすることができる。

別の選択肢において、メッセージングは、第１の地理的領域を出た直後にコールを開始する加入者に限定される。そのような振舞いは、加入者が第１の地理的領域を出るまで待ってコールを発信することを意味する。同様に、ある選択肢では、メッセージングは、ワイヤレスカバレッジが不充分なエリアに周りを一貫して進行する加入者に限定される。特に、より短い／より直接的なルートを与えると思われる第１の地理的領域を通る経路を選択するのではなく、コール／リアルタイムワイヤレス通信に関わる間にそれを行うかどうかについて考える。例えば、加入者に関する履歴データは、選択される経路がおそらくカバレッジの必要性に依存するかどうか決定するために考慮される。そのような加入者は、次いで、改善されたカバレッジのエリアに関するメッセージングを受け取る。

このタイプの通知は、プレミアムサービスとして提供される。例えば、そのような通知は、顧客経験管理を通して識別されるプレミアムユーザ、又はそのようなワイヤレス経験向上について増額を支払ったユーザだけに送信される。

第１の地理的領域におけるカバレッジ改善の検出は、種々の仕方で行うことができる。例えば、進化型ノードＢのようなワイヤレスインフラストラクチャー内の通信要素が検出を行うことができる。それとは別に又はそれに加えて、ＵＥ又は加入者装置で実行されるアプリケーションが検出を実行することができる。別の選択肢では、インターネットで実行されるアプリケーションは、そのアプリケーションがリモートサーバーにある場合でも、検出を遂行することができる。

通知は、ネットワーク要素が第１の地理的領域内で首尾良いコールを検出したときにトリガーされ、それらコールは、以前は、その第１の地理的領域において一貫して不首尾であったものである。ネットワーク要素は、動作及び維持（Ｏ＆Ｍ）システムからの情報を合体する。そのような情報は、例えば、地理的領域をカバーする付加的なセルが配備されたことを含む。この情報は、更に、リモート電気アンテナのチルトが遂行されることを示すリモート電気的チルト（ＲＥＴ）システムからの入力に基づく。そのような新たなチルトは、以前は一貫して存在しなかったカバレッジを地理的領域に与える。

ここに述べる方法は、ネットワーク顧客経験管理システム内で実施することができる。メッセージングは、そのようなケースでは、例えば、ユーザへのテキストメッセージを経て達成される。

それとは別に、ＵＥアプリケーションは、上述したパターン（１つ又は複数）を検出し、次いで、加入者へのメッセージングを直接的に遂行することができる。これは、例えば、スマートホン又はＵＥのオペレーティングシステムの部分へダウンロードされるアプリケーションの一部分である。

マッピング及びディレクションサービスのようなアプリケーション及び／又はサービスプロバイダーは、変更を検出し、次いで、通知を行うことによりサービスを提供することができる。更に、マッピングサービスは、現在多数のコールが終了するエリア、及びそのような状態が以前は存在したがもはや存在しないエリアの両方に通知を与える。従って、例えば、マッピング装置が地理に相関してユーザの振舞いを監視する場合には、マッピング装置は、カバレッジホールに気付き、そして同様に、以前のカバレッジホールがもはや存在しないときを検出することができる。

図１は、ある実施形態による方法の信号フロー図である。図１に示すように、１において、ユーザ装置１１０は、ウオッチを構成する必要性を検出する。この必要性は、例えば、職場への異なるルートを取ることをユーザが考えることに基づく。例えば、アプリケーションは、ウオッチを生成し、より短いが以前はカバレッジが悪かった別の乗物ルートにおいてネットワークトラフィック混雑が減少する場合にプッシュ通知を生じさせる。

２において、ユーザ装置又はそのアプリケーションは、ｅＮＢ１２０及び／又はサーバー１３０へメッセージを送信することによりウオッチを構成する。次いで、３において、サーバー１３０及び／又はｅＮＢ１２０は、ウオッチのトリガーが満足されるかどうか決定するために監視を行う。サーバー１３０は、ここでは、知識サーバーである。トリガーは、例えば、所定のルートに沿ったセル負荷の変更により満足される。

トリガーが満足されると、４において、サーバー１３０及び／又はｅＮＢ１２０は、プッシュ通知をユーザ装置１１０へ送信する。次いで、ユーザ装置１１０のアプリケーションは、ユーザ装置１１０に警告或いはバッジ又はアイコンの変更を生成し、状態変化に関してユーザに警告する。別の実施形態では、ユーザ装置１１０のアプリケーションは、進行中のファイル転送に関連したセッションを閉じて、セルラーネットワークの負荷の量を減少し、例えば、ＴＣＰ ＦＩＮメッセージをアプリケーションサーバーへ送信させ、プロセス内ファイルダウンロードを停止させる。これは、ネットワーク利用度が増加した後にアプリケーショントラフィックが続く場合にオーバーシュートの量を減少するように働く。

幾つかの実施形態は、種々の利益又は効果を提供する。例えば、おそらく周期的な知識サーバーＵＲＬ質問を遂行して消費されるワイヤレスリソース及びバッテリ消費の量の著しい減少が得られる。例えば、知識サーバー応答は、多くの場合、所与の場所から最後に装置が質問されたものと同じである。状態が著しく改善する場合にユーザ装置がプッシュ通知を予想できる場合には、ユーザ装置は、不必要な再質問を回避する。プッシュメッセージは、ネットワークサービス実現性に関連した少なくとも１つのスレッシュホールドを指示する。例えば、プッシュメッセージは、ユーザ装置の環境条件に関連したスレッシュホールドを指示する。スレッシュホールドは、以下に詳細に述べるように、単一のスレッシュホールドでもよいし又は動的なスレッシュホールドでもよい。

図２は、幾つかの実施形態による方法を示す。図２に示すように、この方法は、２０５において、ウオッチを生成するためのトリガーを受け取る。このトリガーは、ユーザ装置、アプリケーションサーバーから要求又は質問として受け取られるか、或いはネットワーク要素により自己発生される。

この方法は、２１０において、ユーザ又はアプリケーションに対してネットワークサービス実現性ウオッチを生成する。ネットワークサービス実現性ウオッチの生成は、少なくとも１つのイベントを検出した際に遂行される。このイベントは、ユーザ装置が地理的領域を横断すること、ユーザ装置又はアプリケーションがサービスを開始する（例えば、サービスを不首尾に開始する）こと、或いはカバレッジ又はワイヤレスサービスクオリティの著しい増加、の少なくとも１つを含む。このイベントは、ネットワーク又はアプリケーションサーバーのためにサービスの開始が失敗することを含む。

このイベントは、例えば、ユーザ装置がスレッシュホールド回数以上に地理的領域を横断することを含む。更に、このイベントは、ユーザ装置が地理的領域内でコール又はリアルタイム通信を発信しないことも含む。

又、この方法は、２２０において、ユーザ又はアプリケーション、例えば、ユーザアプリケーションに対してネットワークサービス実現性を監視することを含む。この監視は、生成されたネットワークサービス実現性ウオッチに基づく。又、この監視は、要求されたビットレート、遅延、利用度、又は地理的位置の少なくとも１つを監視することを含む。更に、この監視は、ユーザに対応する地理的エリアにおいて無線状態を監視することを含み、無線状態の監視は、無線リソース制御メッセージ、ハンドオフメッセージ、ハンドオーバーメッセージ、トラッキングエリア更新、チャンネルクオリティ指示子メッセージング、基準信号受信クオリティメッセージング、基準信号受信電力メッセージング、測定レポートメッセージング、動作及び維持メッセージング、又はリモート電気的チルトメッセージング、の少なくとも１つを監視することを含む。この監視は、更に、予想される無線状態の影響を監視することを含み、別のＵＥにより新たに開始されるコール又は転送は、推定される無線状態への更新を生じさせ、それ故、プッシュ通知をトリガーする。

この方法は、更に、２３０において、ユーザ又はアプリケーションに対してネットワークサービス実現性が検出されたときにユーザ装置へプッシュメッセージを送信することを含む。プッシュメッセージの送信は、ユーザ装置へユニキャストメッセージを送信するか又はユーザ装置を含むグループへグループメッセージを送信することを含む。プッシュメッセージは、アプリケーションレベルのプッシュメッセージである。プッシュメッセージは、上述したように及び以下に詳細に述べるように、ネットワークサービス実現性に関連した少なくとも１つのスレッシュホールドを指示する。

又、この方法は、２４０において、アクセスネットワークのネットワーク要素にネットワークサービス実現性ウオッチを通知することを含む。ネットワーク要素は、それに応答して、２５０において、ウオッチに基づきより厳密な受け入れ制御を課する。

プッシュメッセージの送信は、２２５において、第１の地理的領域内で首尾良いコールを検出しないという条件付であり、コールは、その第１の地理的領域において以前に一貫して不首尾であったものである。

サービス実現性通知は、実際のアプリケーションベアラトラフィックとは個別のアプリケーション経路を通して生成される。換言すれば、サービス実現性通知は、通知それ自体により影響を受けるアプリケーションに関連したいずれのトラフックも受け取らないか又は処理しない第１のサーバーから受け取られる。この区別は、更に、ハンドセットに２つの異なるアプリケーションがある場合に見られるもので、各アプリケーションは、同じネットワークサービス実現性ウオッチシステムでウオッチを別々に構成する。

通知のためのそのような解決策は、ユーザアプリケーションに関連したトラフィックがネットワークの中間点を通過してネットワークモニタの結果に基づいて操作される解決策とは対照的である。従って、そのような場合に、アプリケーションコンテンツは、ネットワーク監視要素の出力に基づき中間点において遅延／キューされる。これに対して、幾つかの実施形態では、中間点でアプリケーショントラフィックをインターセプトする必要がない。むしろ、幾つかの実施形態では、選択したネットワーク監視知識をＵＥのアプリケーションに選択的に直接プッシュすることができる。従って、ネットワークにおける微妙なＡｐｐ知識の必要性は低い。従って、ある実施形態では、アプリケーションへメッセージを直接送信することは、ネットワークが中間点レベル遅延を監視し、メッセージをキュー又は処理するのを回避することを指すが、メッセージは、種々のノードを経て中継され、そして通過中に典型的な低レベル処理を経験する。

図３は、幾つかの実施形態による別の方法を示す。図３に示すように、この方法は、３１０において、例えば、ユーザアプリケーションのネットワークサービス実現性を監視するための質問をユーザ装置から送信することにより、ユーザ又はアプリケーションのネットワークサービス実現性を監視するためにネットワーク要素をトリガーすることを含む。従って、このトリガー動作は、サーバー又はアクセスポイントにメッセージを送信することにより意図的にトリガーされる。例えば、このトリガー動作は、アプリケーションによりサービス実現性ウオッチを生成することを含む。それとは別に、このトリガー動作は、（例えば）特定の地理的エリアにおいてコールを繰り返し終了させ、特定の地理的エリアにおいてコールをスタートさせるか又はある地理的アリアにおいて前記リアルタイム通信をスタートさせ、或いは別の進行ルートを選択することにより、偶発的に行うこともできる。加えて、このトリガー動作は、ネットワーク状態と、例えば、乗物の交通渋滞に関連したユーザトラフィック移動推定との組み合わせに基づいて遂行されるように構成されてもよい。

又、この方法は、３２０において、監視に基づきプッシュ通知を受信することも含む。そのプッシュ通知に応答して、この方法は、３３０において、異なる／第２のアプリケーション、例えば、アプリケーションエンハンサーによりバックグランドトラフィックを転送するか、或いは３３０において、バッジ、アプリケーションアイコン、又は連絡先アイコンを修正するか、の少なくとも一方を遂行することを含む。その修正は、バッジ又はアイコンの外観又は機能である。例えば、アイコンがロックされ、そしてこのロックされた状態は、プッシュ通知が受け取られるまでアイコン上にパッドロックバッジを置くことにより示される。それ故、その修正は、プッシュ通知に応答して機能をロック又はアンロックすることを含む。

図４は、幾つかの実施形態による更に別の方法を示す。図４に示すように、この方法は、４１０において、ユーザ装置のアプリケーションに対するネットワークサービス実現性を監視する必要性をユーザ装置で検出することを含む。又、この方法は、４２０において、その検出に基づいてネットワークサービス実現性を監視することを含む。その検出は、地理的エリア及び無線状態に相関した接続のパターンを検出することを含む。この方法は、更に、４３０において、ネットワークサービス実現性が所定のスレッシュホールドを越えて改善したときにユーザ装置のユーザに通知することを含む。

図５は、本発明の幾つかの実施形態によるシステムを示す。図１−４、６及び７のフローチャートの各ブロック及びその任意の組み合わせは、ハードウェア、ソフトウェア、ファームウェア、１つ以上のプロセッサ及び／又は回路のような種々の手段又はその組み合わせによって実施されてもよいことを理解されたい。１つの実施形態において、システムは、例えば、ネットワーク要素５１０、及びユーザ装置（ＵＥ）又はユーザ装置５２０のような多数の装置を備えている。このシステムは、２つ以上のＵＥ５２０及び２つ以上のネットワーク要素５１０（例えば、図１に示すような）を備えているが、説明上、図５には各々の１つしか示されていない。ネットワーク要素は、アクセスポイント、ベースステーション、ｅＮｏｄｅＢ、サーバー（例えば、知識サーバー）、又はここに述べる他のネットワーク要素のいずれかである。これら装置の各々は、５１４及び５２４として各々示された少なくとも１つのプロセッサ又はコントロールユニット又はモジュールを備えている。そのような装置には、少なくとも１つのメモリが設けられ、５１５及び５２５として各々示されている。このメモリには、コンピュータプログラムインストラクション又はコンピュータコードが含まれる。１つ以上のトランシーバ５１６及び５２６が設けられ、各装置は、５１７及び５２７として各々示されたアンテナも備えている。１つのアンテナしか示されていないが、各装置には多数のアンテナ及び複数のアンテナ素子が設けられる。例えば、これらの装置の他の構成が設けられてもよい。例えば、ネットワーク要素５１０及びＵＥ５２０は、ワイヤレス通信に加えて、ワイヤード通信用に構成されてもよく、そのようなケースでは、アンテナ５１７及び５２７は、単なるアンテナに限定されず、任意の形態の通信ハードウェアを表してもよい。同様に、あるネットワーク要素５１０は、ワイヤード通信用だけに構成されてもよく、そのようなケースでは、アンテナ５１７は、ネットワークインターフェイスカードのような任意の形態のワイヤード通信ハードウェアを表してもよい。

トランシーバ５１６及び５２６は、各々、独立した送信器、受信器、又はその両方であるか、或いは送信及び受信の両方のために構成されたユニット又は装置である。又、送信器及び／又は受信器は、装置それ自体の中には配置されずに、例えば、マストに配置されるリモート無線ヘッドとして実施されてもよい。又、液体又は柔軟性無線概念によれば、動作及び機能は、ノード、ホスト又はサーバーのような異なるエンティティにおいて柔軟な仕方で遂行されることも明らかであろう。換言すれば、労力の分割は、ケースバイケースで変化する。１つの考えられる使用は、ローカルコンテンツを配信するようにネットワーク要素を形成することである。又、１つ以上の機能が、サーバー上で実行できるソフトウェアのようなバーチャルアプリケーションとして実施されてもよい。

ユーザデバイス又はユーザ装置は、移動電話又はスマートホン又はマルチメディア装置のような移動ステーション（ＭＳ）、ワイヤレス通信能力が設けられたタブレットのようなコンピュータ、ワイヤレス通信能力が設けられたパーソナルデータ又はデジタルアシスタント（ＰＤＡ）、ポータブルメディアプレーヤ、デジタルカメラ、ポケットビデオカメラ、ワイヤレス通信能力が設けられたナビゲーションユニット、又はその組み合わせである。

プロセッサ５１４及び５２４は、計算又はデータ処理装置、例えば、中央処理ユニット（ＣＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、プログラマブルロジック装置（ＰＬＤ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、デジタルエンハンスト回路又は同等の装置、或いはその組み合わせによって実施される。プロセッサは、単一のコントローラとして、或いは複数のコントローラ又はプロセッサとして実施されてもよい。

ファームウェア又はソフトウェアについては、実施には、例えば、手順、機能、等の少なくとも１つのチップセットのモジュール又はユニットが含まれる。メモリ５１５及び５２５は、非一時的なコンピュータ読み取り可能な媒体のような、独立した適当なストレージ装置である。ハードディスクドライブ（ＨＤＤ）、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、又は他の適当なメモリが使用される。メモリは、単一の集積回路上でプロセッサとして組み合わされてもよいし、又はそれとは個別であってもよい。更に、メモリに記憶されてプロセッサにより処理されるコンピュータプログラムインストラクションは、適当な形態のコンピュータプログラムコード、例えば、適当なプログラム言語で書かれたコンパイル型又は解釈型コンピュータプログラムである。メモリ又はデータ記憶エンティティは、内部でもよいが、サービスプロバイダーから付加的なメモリ容量が得られる場合には、外部でもよいし、又はその組み合わせでもよい。メモリは、固定でも、取り外し可能でもよい。

メモリ及びコンピュータプログラムインストラクションは、ネットワーク要素５１０及び／又はＵＥ５２０のようなハードウェア装置がここに述べるプロセス（例えば、図１−４及び６−９を参照）を遂行するようにさせるように特定の装置のプロセッサで構成される。それ故、ある実施形態では、非一時的なコンピュータ読み取り可能な媒体は、ハードウェアで実行されたときにここに述べるプロセスの１つのようなプロセスを遂行するコンピュータインストラクション又は１つ以上のコンピュータプログラム（例えば、追加又は更新されたソフトウェアルーチン、アプレット又はマクロ）でエンコードされる。コンピュータプログラムは、ｏｂｊｅｃｔｉｖｅ−Ｃ、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（登録商標）、等の高レベルプログラミング言語、或いはマシン言語又はアッセンブラーのような低レベルプログラミング言語であるプログラミング言語によりコード化される。或いは又、本発明の幾つかの実施形態は、全体的にハードウェアで遂行されてもよい。

更に、図５は、ネットワーク要素５１０及びＵＥ５２０を備えたシステムを示しているが、本発明の実施形態は、図示してここに述べるように、他の構成や、付加的な要素を含む構成に適用されてもよい。例えば、複数のユーザ装置及び複数のネットワーク要素が存在してもよく、或いは同様の機能を発揮する他のノード、例えば、ユーザ装置及びアクセスポイントの機能を結合するノード、例えば、中継ノードが存在してもよい。ＵＥ５２０は、クラスタースレーブ又はクラスターマスターのいずれかを含むクラスターメンバーである。

図６は、幾つかの実施形態によるメッセージフローを示す。図６に示すように、ユーザ装置６１０のＡｐｐは、１において、ｅＮＢ６２０によって知識サーバー６５０へＵＲＬ質問を送信する。この質問は、時間間隔Ｔ及び／又は位置Ｘを特定する。２において、知識サーバー６５０は、使用を思いとどませるＨＴＴＰテキスト応答で応答する。３において、ユーザ装置６１０と知識サーバー６５０との間にはキー、ＩＤ、等のペアリングがある。同様に、４において、プッシュサーバー６５０は、対応するペアリングについて同様に通知される。５において、ユーザ装置６１０のアプリケーションは、知識サーバー６５０でワイヤレスネットワークウオッチを生成し、位置Ｘ及び／又は時間間隔Ｔのネットワークインサイトがスレッシュホールド量以上改善する場合には新たなプッシュ通知がネットワークから与えられるようにする。ユーザ装置６１０は、６において、第２のアプリケーションサーバー６４０に関して第１の仕方で動作する。時間が経過し、そして７において、例えば、ユーザ装置６１０及び／又はｅＮＢ６２０からレポートを受け取ることによってネットワーク状態を監視するネットワークモニタ６３０は、改善されたインサイトを知識サーバー６５０に与える。次いで、８において、知識サーバー６５０は、改善されたインサイトの指示を、プッシュサーバー６６０を経て搬送する。プッシュサーバー６５０は、９において、改善されたインサイトを指示又は搬送するプッシュ通知を送信する。１０において、ユーザ装置６１０のアプリケーションは、そのプッシュ通知に応答して、時間間隔Ｔ及び／又は地理的領域Ｘにおけるサービス利用及び／又は旅行を許す。更に、ユーザ装置６１０のアプリケーションは、第２のアプリケーションサーバー６４０に対して第２の仕方で動作を開始する。

任意であるが、１１において、ユーザ装置６１０のアプリケーションは、知識サーバー６５０でワイヤレスネットワークウオッチを生成し、位置Ｘ及び／又は時間間隔Ｔのネットワークインサイトがスレッシュホールド量以上悪化する場合には新たなプッシュ通知がネットワークから与えられるようにする。時間が経過し、そして１２において、例えば、ユーザ装置６１０及び／又はｅＮＢ６２０からレポートを受け取ることによりネットワーク状態を監視するネットワークモニタ６３０は、悪化したインサイトを知識サーバー６５０に与える。次いで、１３において、知識サーバー６５０は、悪化したインサイトの指示を、プッシュサーバー６６０に搬送する。プッシュサーバー６５０は、１４において、改善されたインサイトを指示するプッシュ通知を送信する。

図７は、幾つかの実施形態による別のメッセージフローである。図７に示すように、１において、ユーザ装置６１０のアプリケーションは、キー、ＩＤ、等を知識サーバー６５０へ送信し、そして２において、それに対応するキー、ＩＤ、等をプッシュサーバー６６０へ送信する。これは、プッシュサーバーと知識／ネットワークメトリックサーバーとの間の関連を生成する。３において、ユーザ装置６１０は、第２のアプリケーションサーバー６４０に対して第１の仕方で動作する。その間に、４において、ネットワーク（例えば、知識サーバー６５０）は、第１の地理的領域をスレッシュホールド量以上に横断し且つその第１の地理的領域においてコールドロップのような悪いサービスを被ったＵＥを識別する。任意であるが、知識サーバー６５０は、ユーザがその領域でコールを発しないようにどのように自己トレーニングすべきかのような他のファクタを考慮してもよい。更に、知識サーバー６５０は、特に、任意の改善に続いて、ユーザ装置６１０が第１の地理的領域内でコール又は他のリアルタイム通信を首尾良く発信したかどうかを考慮してもよい。又、４において、知識サーバー６５０は、時間間隔Ｔ及び／又は地理的領域Ｘ内でネットワーク状態が改善する場合にはプッシュ通知のためのウオッチを生成する。

時間が経過する。ネットワーク状態が改善するとき、５において、例えば、ユーザ装置６１０及び／又はｅＮＢ６２０からレポートを受け取ることによりネットワーク状態を監視するネットワークモニタ６３０は、改善されたネットワーク状態のインサイトを知識サーバー６５０に与える。次いで、６において、知識サーバー６５０は、改善されたインサイトの指示を、プッシュサーバー６５０を経て搬送する。

プッシュサーバー６５０は、７において、改善されたインサイトを指示するプッシュ通知を送信する。プッシュサーバー６５０は、プッシュ通知の理由又はプッシュ通知のコンテンツについて知らない。従って、その指示は、プッシュサーバー６５０に対して不透明なメッセージでプッシュされ、それにより、プッシュサーバー６５０におけるネットワーク監視中間点レベル処理又は遅延を回避する。他の実施形態では、プッシュサーバー６５０は、プッシュサーバー６５０において適当なメッセージへ公式化される指示を受け取るが、これは、ある実施形態では、回避される。

８において、ユーザ装置６１０のアプリケーションは、プッシュ通知に応答して、時間間隔Ｔ及び／又は地理的領域Ｘにおけるサービス利用及び旅行を許す。更に、ユーザ装置６１０のアプリケーションは、第２のアプリケーションサーバー６４０に対して第２の仕方で動作を開始する。

任意であるが、９において、知識サーバー６５０は、ネットワーク状態が時間間隔Ｔ及び／又は地理的領域Ｘ内で悪化する場合にプッシュ通知のためのウオッチを生成する。

図１０は、幾つかの実施形態によりネットワーク状態のアプリケーション検出を行わずに適用される知識サーバーインサイトの一例を示す。図１０に示すように、１において、先ず、セルは、プリフェッチを含まずに、合計３．５Ｍｂｐｓを使用する。その間に、ＵＥは、約５から１０Ｍｂｐｓを見る。知識サーバーは、２において、利用度が約３５％であることを検出し、そしてプリフェッチを行って、ＵＥＸ及びＹの各々を約〜４Ｍｂｐｓへ増加させ、〜８０％の利用度を生み出すよう導く。次いで、３において、ＵＥ Ａ及びＢが、各々、セルに到達し、約１０Ｍｂｐｓを必要とするが、その約半分しか得られない。４において、知識サーバーは、約１分の遅延の後に、全ての又はほとんどのプリフェッチを停止、そしてＵＥ Ｘ及びＹは、既に数秒のデータをフェッチしているので、全てのデータ利用を停止する。５において、Ｘ及びＹによる減少した利用率は、ＵＥ Ａが完全な量のデータを得ることを許す。次いで、ＵＥ Ａがその利用を停止するときに、ＵＥ Ｂは、その望ましい帯域巾を得て、停止となる。５．５において、約１分の遅延が生じる。この遅延の間に、容量の浪費が生じる。６において、知識サーバーは、約０％の利用度を検出し、そしてプリフェッチを再開する。ＵＥ Ｘ及びＹは、再び約４Ｍｂｐｓまで増加することができる。

図１０に示すように、ネットワークリソースが利用可能になるか又はいっぱいになるのと、知識サーバーがその状態を知るか又はアクションを行う判断をするのとの間に遅延が生じる。この遅延は、過剰なピンポン作用を回避するために意図的なものである。それに加えて、この遅延は、多数の及び頻繁な知識サーバー更新でコアネットワークを圧倒するのを回避することができる。

従って、幾つかの実施形態は、知識サーバーインサイト維持インストラクションのセットを与える。ピンポン回避の場合に、これらインストラクションは、突然の移動を行わないようにアプリケーションに命令する。換言すれば、幾つかの実施形態は、アプリケーションが最大プリフェッチレートに対応してそのインサイトを更新する計画レートを、知識サーバーが付加的にリモートコントロールするためのメカニズムを取り扱う。特に、ある実施形態では、知識サーバー又はアプリケーションそれ自体が最大プリフェッチビットレートを構成する。最大プリフェッチレートは、プリフェッチが最初に開始されるときは、例えば、階段形態で、ある期間にわたり増加する。更に、プリフェッチがその終わりに近付いているときには、階段形態で減少もする。又、この知識サーバーインサイト維持は、知識サーバーインサイトランピング(ramping)とも称される。

プリフェッチ判断を制御するための判断／メカニズムは、ＵＥのアプリケーション内のアプリケーションレイヤにおいて制御される。例えば、そのような判断は、バッテリ寿命が既知である場合、及びビデオの次のセクションに対するＵＲＬ質問を発生できる場合に制御することができる。知識サーバーは、ネットワークがこれらアプリケーションへのネットワークインサイトにサービスできるようにし、ワイヤレスリソースが浪費されるときに付加的なプリフェッチを遂行するようにこれらアプリケーションをトリガーするためのオーバー・ザ・トップ（ＯＴＴ）メカニズムを形成する。しかしながら、知識サーバーの目標は、害を及ばさないことでもあり、従って、トリガー動作に負荷が掛かり過ぎるのを回避しながら付加的なプリフェッチを促進することである。

プリフェッチの量に影響する知識サーバー／ＯＴＴ制御メカニズムは、無線スケジューラのようにミリ秒又はマイクロ秒ではなく、例えば、秒のタイムスケールで動作する。

知識サーバーが長いタイムスケールで動作する理由は、知識サーバーがアプリケーションレイヤにおけるトラフィックの促進／抑制を取り扱うことを含む。アプリケーションレイヤのトラフィックは、しばしば、個々のファイルに分割される。例えば、ＨＴＴＰ適応ビデオでは、各々約５又は１０秒のビデオセクションが個別のファイルである。それ故、アプリケーションがビデオのセクションに対応するファイルを要求すると、プリフェッチトラフィックを停止できるまでに数秒かかる。例えば、接続を閉じることにより中間ファイルダウンロードを停止すると、部分的にダウンロードされたファイルを後でダウンロードし直してファイルの残り部分を検索する必要があるために、付加的な浪費が生じる。

更に、知識サーバーの幾つかの実施形態は、実施の複雑さレベルを低くすることを目的とする。例えば、知識サーバーは、幾つかの実施形態では、ｅＮＢと同じ位置にある必要がない。その結果、知識サーバーは、最大プレフィリングデータレートを直接計算しなくてもよい。例えば、知識サーバーは、各ＵＥにより発生されるプリフェッチトラフィックの厳密な量をマイクロマネージせず、そして知識サーバーは、ＵＥごとに非常に短期間の無線情報を要求／利用する必要がない。例えば、知識サーバーは、ＵＥごとの情報ビット当りの記号又は物理的リソースブロックの数のような情報を知る必要がない。

それに加えて、知識サーバーの幾つかの実施形態では、ネットワーク／知識サーバーとＵＥとの間の不必要な及び／又は繰り返しの監督メッセージングが回避される。

監督応答におけるこの長いタイムスケールのために、知識サーバーは、例えば、８０％ネットワーク利用度を目標とする。ネットワーク利用度が８０％を越える場合には、知識サーバーは、プリフェッチの量を減少する。

長いタイムスケール応答は、更に、プリフェッチピンポン作用に対処し、ここで、プリフェッチは、促進されるが、あまりに多くのプリフェッチが許されるので迅速に抑制され、そしてセルが非常に混雑した後にプリフェッチが暫く続くプリフェッチオーバーシュートがあるか、又は無線状態に基づきプリフェッチが適当であると考えられても、それがスタートしない。

インサイトランピングは、ピンポン作用に対処するために一方向であるが、頻繁なインサイトメッセージングを回避すると同時に、プリフェッチでネットワークが過剰利用度になる、例えば、８０％利用度を越えるシナリオを回避する。

図１２は、幾つかの実施形態によるピンポンシナリオを示す。図１２に示すように、１において、ＵＥ Ｘ及びＹは、インサイトがまだ受け取られていないので、プリフェッチを行わない。次いで、２において、知識サーバーは、低い利用度を検出し、そしてプリフェッチを許す。しかしながら、それにより行われるプリフェッチで、３において、ネットワーク利用度にスパイクが生じる。この高い利用度は、４において、ある期間の後に、知識サーバーにより検出される。それに応答して、知識サーバーは、プリフェッチをバックダウンすることができる。しかしながら、別の瞬間にサイクルを再び繰り返すことができる。

幾つかの実施形態は、ＵＥで実行されるアプリケーションにあるネットワークインサイトを与えて、そのインサイトを要求したアプリケーションがそれらのインサイトを使用できるようにすることで、浪費される又はアイドル状態のシステム容量を利用するためのメカニズムを提供する。それらのアプリケーションは、それらのインサイトを使用できる多数の制御ポイントを有している。

ネットワークインサイト変更が検出されたときＯＴＴインサイト更新がＵＥにプッシュされる。しかしながら、インサイトは、より迅速に更新することができ、そしてある実施形態では、インサイトそれ自体によりもっと低いネットワーク負荷が得られる。したがって、幾つかの実施形態では、変化するネットワークインサイトに対して高速の／より効率的なアプリケーション応答が許される。特に、幾つかの実施形態では、知識ベースのシステムにより構成される特定のアプリケーションインサイト維持ルールの使用を通してこの効果的なレイテンシー短縮を達成することができる。１つの実施形態は、以前のインサイト推奨プリフェッチを使用してアプリケーションを停止すべきとき、即ちこのプリフェッチインサイトを破棄し及び／又はプリフェッチを停止するとき、を制御するアプリケーション運営ルールである。

この実施形態では、アプリケーションは、付加的なネットワークメッセージングを待機する必要なく、この更新をローカルで実行する。むしろ、アプリケーションは、現在リンク速度が最後のネットワークインサイトに関連した基線リンク速度から充分に変化したとアプリケーションが観察したときに、その前のインサイトを破棄し、即ち最も直近のインサイトを使用して停止するための判断を実行する。このルールは、現在リンク速度が、例えば、アプリケーションがネットワークインサイト推奨プリフェッチングを受け取ったときにアプリケーションが観察したリンク速度の半分まで低下したことを検出したとき、アプリケーションがほぼ瞬時にプリフェッチングを停止できるようにする。これは、例えば、突然のネットワーク負荷スパイクが生じたとき、例えば、タッチダウン、ゴール、ホームラン、等の得点があったとき、プリフェッチングを直ちに停止することが重要であるスタジアム環境において有用である。従って、幾つかの実施形態では、それらインサイトが破棄されるときを決定するためのローカルアプリケーションベースのルールと組み合わせて、例えば、現在リンク速度のアプリケーション検出に応答して、オーバー・ザ・トップネットワークにより与えられるインサイトが使用される。

図８は、幾つかの実施形態による方法を示す。図８に示すように、この方法は、８１０において、ユーザ装置のアプリケーションにより第１のネットワークインサイトを受け取る。このインサイトは、知識サーバーのようなネットワーク要素から受け取られる。このインサイトは、知識サーバーによりプッシュされるか、又は知識サーバーに対してなされる要求に応答して受け取られる。

知識サーバーは、種々のインサイトをアプリケーションに与える。これらのインサイトは、ｅＮＢ利用のような、アプリケーションに直接見えないネットワーク知識に基づくものである。ネットワークインサイトポリシーは、知識サーバーによりトップ（ＯＴＴ）を経て与えられる。次いで、ＵＥのアプリケーションは、それらのインサイトを、インターネット上の個別のアプリケーションサーバーとのアプリケーション相互作用へと一体化する。

又、この方法は、８２０において、ネットワークインサイトを使用してアプリケーション又はユーザ装置の機能を最適化することを含む。最適化は、例えば、プリフェッチをするための判断、どれほど多くのデータをプリフェッチするかの判断、又はどんな種類のデータをプリフェッチするかの判断を含む。例えば、ネットワークインサイトに基づいて、アプリケーションは、ストリーミングビデオはプリフェッチするが、ウェブブラウジングはプリフェッチしないと判断する。というのは、２つの種類のデータは、サーバーが異なるか、又はプリフェッチからの利益が異なるためである。

加えて、この方法は、８３０において、環境状態を検出して記憶することも含む。この環境状態は、ユーザ装置及び／又はアプリケーションによって使用されるリンクの速度、レイテンシー又はパケットロスのようなネットワーク状態である。他の環境状態は、ユーザ装置がネットワークに対して有する接続の種類、例えば、第４世代（４Ｇ）、長期進化（ＬＴＥ）、第３世代（３Ｇ）、Ｗｉ−Ｆｉ、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）、等である。

８３０における環境状態の検出及び記憶は、８１０における最適化の後に示される。しかしながら、これらステップの順序は、逆転してもよいし、又はこれらの動作は、並列に遂行されてもよい。

又、この方法は、８４０において、環境状態を監視することも含む。この監視は、周期的に状態を測定するか又は測定を要求することを含む。又、この監視は、サーバーから環境状態に関する更新を受け取ることも含む。

この方法は、更に、８５０において、更新されたネットワークインサイトが受け取られたかどうか評価することも含む。この評価は、周期的に行われるか、又は新たなネットワークインサイトを受け取ることにより自動的にトリガーされる。ネットワークインサイトが必ずしもプッシュされない場合には、評価は、知識サーバーから現在ネットワークインサイトを要求することを含む。従って、例えば、知識サーバーは、ワイヤレスリンク速度のようなローカル環境の変化についてのＵＥアプリケーションの検出の変化に応答してアプリケーションが自動的にインサイトを更新するようにメカニズムを構成する。

ネットワークインサイトを更新するかどうか決定し、この決定がＵＥで行われるか、ｅＮＢで行われるか又は知識サーバーで行われるかどうか決定する基準は、現在プリフェッチイベントの開始の後に経過した時間量に依存する。従って、例えば、アプリケーションインサイトは、周期的に自動的に増加され、ランピング状のパターンを達成する。このインサイトランピングは、新たな知識サーバーメッセージを受信するたびではなく、スケジュールに従って、プリフェッチ量を自動的に増加／減少する。このランピング状の解決策は、複数のフェーズを有する。例えば、アプリケーションは、プリフェッチのレートを、第１フェーズ中にはより迅速に増加させ、次いで、第２フェーズ中にはあまり迅速に増加させない。というのは、インサイトが古いか又はセルが８０％利用度の目標に近付いている可能性が高いためである。従って、幾つかの実施形態では、アプリケーションによって観察されるリンク速度がスレッシュホールド量以上変化するまで、アプリケーションは、そのような増加を行い続ける。

図８に示すように、新たなネットワークインサイトがある場合には、８６０において、この方法は、新たなネットワークインサイトを記憶することを含む。次いで、この方法は、８２０において最適化を行うように進み、等々である。

新たなネットワークインサイトがない場合には、８７０において、この方法は、ネットワーク状態がスレッシュホールド以上変化したかどうか決定することを含む。或いは又、決定は、ネットワーク状態が変化したかどうかに関する単なる決定でよい。例えば、元の状態が、ユーザ装置がＬＴＥ及びＷｉ−Ｆｉに二重接続されるというものであり、そしてこれが全く変化する場合には、ユーザ装置は、これを、ネットワークレイテンシー、パケットロス、等の著しい変化と同様に処理する。スレッシュホールドは、例えば、ネットワークレイテンシーが２倍である場合、データレートが半分に下がる場合、又はパケットロスが２倍である場合に、セットされる。又、他のスレッシュホールドも許される。

スレッシュホールド又は他の条件が満足される場合に、８８０において、この方法は、デフォールト又は第２のネットワークインサイトを使用することを含む。デフォールトインサイトとは、ユーザ装置及び／又はアプリケーションが、知識サーバーにより以前に与えられたネットワークインサイトを完全に無視するかのように進むというものである。従って、例えば、デフォールトにより、ユーザ装置及び／又はアプリケーションは、プリフェッチを行わず、又はビデオストリーミングのようなアプリケーションに対してプリフェッチを行わず、或いはある最大データ量を越えてプリフェッチを行わないように構成される。従って、例えば、リンク速度状態がそれに対応する記憶値からスレッシュホールド量以上ずれていることが分かった場合には、アプリケーションは、プリフェッチを停止することができる。

第２のインサイトは、ユーザ装置により発生される。例えば、ユーザ装置は、検出されたネットワーク状態に基づいてプリフェッチ又は他のインサイトベースの振舞いを倍数的に増加又は減少する。例えば、リンク速度が半減した場合に、ユーザ装置は、対応的に、プリフェッチを半減することができる。或いは又、リンク速度が半減した場合に、ユーザ装置は、プリフェッチを四半減してもよい。アプリケーションそれ自体は、変化したネットワーク状態に基づいて変化したレートを計算するのに使用できる値を与えることができる。

スレッシュホールドは、例えば、リンク速度がスレッシュホールドを越えるときにプリフェッチが許され、又はリンク速度がスレッシュホールドより低いときにプリフェッチが禁止されるように、設定される。特定の例において、アプリケーションが遭遇するビットレートが充分低い場合には、ジャストインタイムを越えるプリフェッチは、許されない。

スレッシュホールドそれ自体は、アプリケーションにより事前に構成されるか、或いは知識サーバー又は他のサーバーにより指示される。特定例において、リンク速度に基づくインサイト維持メカニズムがあって、移動装置に現在再生されているビデオに適用される。この例では、ビデオは、毎秒１Ｍｂのピークビットレートを有する。従って、移動装置は、移動装置のビデオセグメントダウンロードが依然少なくとも毎秒３Ｍｂに遭遇する場合にはプリフェッチを遂行するように知識サーバーにより命令され、さもなければ、移動装置は、プリフェッチを直ちに停止しなければならない。

スレッシュホールドは時間と共に変化する。従って、例えば、リンク速度要件も、時間の関数として変化する。例えば、プリフェッチを停止するためのスレッシュホールドは、時間と共に増加し、最後のインサイトが受け取られて以来時間が経つほど、ＵＥ Ａｐｐがプリフェッチを実行し続ける可能性は益々低くなる。その間に、特に高い場合には、プリフェッチは、より長く続く。この変化するリンク速度スレッシュホールドは、グライドパスと称される。

ネットワーク要素がスレッシュホールドを供給すると、ネットワーク要素それ自体は、ＵＥごとにスレッシュホールドをランダム化、又はさもなければ、食い違わせることができる。或いは又、ＵＥアプリケーションそれ自体は、スレッシュホールドにランダム化ファクタを適用することができる。ＵＥが同様の状態を有していても、食い違ったスレッシュホールドをＵＥにわたって使用することは、セルの負荷が増すにつれて、益々多くのユーザがプリフェッチを徐々に停止できるという点で有用である。食い違いは、ランダムであってもよいし、又はユーザの相対的なプライオリティに基づいて構成されてもよく、最もプライオリティの低いユーザは、最も低いスレッシュホールドを有し、プリフェッチを最初に停止する。

ネットワークが過剰利用になったとき、プリフェッチを停止するための更新されたインサイトを送信するのではなく、ネットワークは、プリフェッチユーザに対してビットレートを単に一時的に絞って、彼等がプリフェッチの停止をトリガーするようにする。これは、例えば、ｅＮＢがローカルな理由でプレフェッチの停止を希望するが、知識サーバーがｅＮＢの制御下にないときに有用である。

それに加えて、所与のアプリケーションに関連したトラフィックフローが、低い、例えば、ベストエフォートの、サービス品質（ＱｏＳ）設定を有するように構成された場合には、付加的な、例えば、より高いプライオリティのトラフィックが、負荷スパイク発生時に、所与のアプリケーションにより達成されるリンク速度に特定の劇的な変化を生じさせることがある。それ故、アプリケーションは、このリンク速度の低下を特に素早く観察し、それ故、それに応答してプリフェッチを完全に停止することができる。

図８に示すように、環境状態が変化しないか、又はスレッシュホールド以上に変化しない場合には、８９０において、この方法は、第１のネットワークインサイトを使用し続けることを含む。従って、この方法は、８４０において環境状態を監視することにより進められ、等々となる。

幾つかの実施形態の種々の具現化が考えられる。例えば、幾つかの実施形態は、アプリケーションプログラミングインターフェイス（ＡＰＩ）に関連して具現化される。

図９は、幾つかの実施形態による信号フローを示す。図９に示すように、１において、サーバー１３０は、第１のネットワークインサイトを与える。このインサイトは、ネットワーク状態を明確に記述するか、又はネットワーク状態を、その状態に対するユーザ装置１１０のアクションに関して記述する。例えば、ネットワークインサイトは、ユーザ装置１１０にプリフェッチをターンオン又はオフするように直接的に命令するか、又はネットワーク負荷の現在レベルを間接的に指示することにより、プリフェッチをターンオン又はオフすることを指示する。

２において、ユーザ装置１１０は、ネットワークインサイトを記憶し、ユーザ装置１１０の性能又はユーザ装置１１０のアプリケーションを最適化するようにネットワークインサイトを適用し、そして第１の環境状態を検出して記憶する。このネットワークインサイトは、第１のネットワークインサイトと称される。

３において、ｅＮＢ１２０は、ネットワーク状態をユーザ装置１１０に指示する。又、ユーザ装置１１０が、例えば、状態それ自体を直接的に測定することによりネットワーク状態を決定できる他の仕方もある。このネットワーク状態は、ユーザ装置１１０が記憶値を有するところの環境状態であるか又はそれに関連したものである。

次いで、４において、ユーザ装置１１０は、スレッシュホールドを越えるネットワーク状態の変化を検出するか、さもなければ、第１のネットワークインサイトが古いか又は無関係であることを示唆する変化を検出する。この検出は、最近に受け取ったネットワーク状態と、以前に記録されたネットワーク状態との間の比較に基づく。従って、ユーザ装置１１０は、デフォールトのネットワークインサイトに頼ることになる。これは、事前に構成されるデフォールトネットワークインサイトである。或いは又、これは、ネットワーク状態がユーザ装置１１０により現在観察されるネットワーク状態に対応する時間中に以前に与えられたネットワークインサイトでもよい。

５において、ｅＮＢ２０は、新たなネットワーク状態を指示する。この状態は、以前に指示されたネットワーク状態とは異なる。６において、ユーザ装置１１０は、以前に使用したスレッシュホールド内に戻るネットワーク状態の変化があったことを検出する。従って、ユーザ装置１１０は、第１のネットワークインサイトを使用して再開する。

７において、サーバー１３０は、第２のネットワークインサイトを与える。第２のネットワークインサイトは、第１のネットワークインサイトとは異なる。従って、８において、ユーザ装置１１０は、第２のネットワークインサイトを記憶し、ユーザ装置１１０及び／又はアプリケーションの性能を最適化するように第２のネットワークインサイトを適用し、そして第２の環境状態を検出して記憶する。

他の変更も許される。例えば、インサイト維持メカニズムは、リンク速度のローカル検出のみに基づく必要はない。むしろ、入力のより広いセットが、アプリケーションにより迅速に検出される。アプリケーションは、状態の現在セットと、状態の現在セットがあるスレッシュホールドを越えて変化する程度とに基づいて、インサイトが適当であることを決定する。スレッシュホールドは、例えば、知識サーバーにより構成される。スレッシュホールドを通過すると、インサイトは、もはや有効でないと思われ、そして破棄されるか及び／又は異なる又はデフォールトのインサイトと交換される。特定の付加的な規範的基準を、それに対応する問題／論理的根拠と共に、以下に述べる。

知識サーバーネットワークインサイトを更新すべきかどうかを決定する基準は、更に、移動性又は速度に依存する。例えば、システムは、ＵＥが少数のバーに向かい移動を開始するか、及び／又はＵＥが最も直近のインサイトを受け取るときに接続されたサービングベースステーションから離れるように移動を開始するときに、プリフェッチの量を自動的に減少することができる。この解決策は、小型セルに関して有用であり、ネットワークが小型セルへハンドオフしたことを検出した後に、それに対応するインサイトがプリフェッチをスタートするのを待機することなく、過少利用の小型セルを通過するユーザ装置のアプリケーションが、セルに到達した際に、プリフェッチを直ちに開始することができる。

知識サーバーネットワークインサイトを更新すべきかどうか決定する別の基準は、例えば、既にダウンロードされたか、及び／又はプリフェッチされる現在ファイルにダウンロードされるべく残っているバイトの数である。従って、例えば、インサイトが通常にプリフェッチプロセス全体を停止させるべきケースにおいて、アプリケーションが特にファイルプリフェッチの終わりに接近する場合には、ファイルダウンロードを破壊してファイル全体の再ダウンロードを必要とすることで浪費が生じるのを回避するために、ファイルをダウンロードし続けることが許される。

別の実施形態では、異なるＵＥのグループ間でプリフェッチを自動的にローテーションするためのメッセージレスメカニズムがある。例えば、ユーザが交代するような周期的なスケジュールがある。例えば、リンク速度基準は、移動が最後にプリフェッチを遂行して以来の時間量、又はエリア内の現在プリフェッチＵＥの量のいずれか一方に依存する。この解決策は、ユーザがプリフェッチを並列に遂行するのではなく交代で行うときにバッテリ及びＲＦの観点から効率の増分的利益を得る。

或いは又、知識サーバーネットワークインサイトを更新すべきかどうか決定するための基準は、更に、ユーザ装置のマイクロホンに存在する音声／音響ノイズに依存する。例えば、スタジアムの環境では、ハンドセットマイクロホンを通して検出される音響ノイズの変化は、例えば、フィールドにおける得点イベントの時間に、ネットワーク負荷の突然の変化を指示する。従って、ある実施形態では、プリフェッチレートの減少が、アプリケーションにより検出される音響ノイズに基づいて自動的にトリガーされる。例えば、ユーザ装置ＯＳ又はユーザインターフェイスアプリケーション又はコンポーネントは、装置のマイクロホンにおいて検出を行う。更に、進行中のボイスコールがあって且つプリフェッチがＯＳにより監督されているときには、ＯＳがマイクロホンにアクセスする。

他の選択肢も考えられる。例えば、ＵＥのマイクロホンは、ユーザコマンドを識別できるように常に聴取を行ってもよいし、又はマイクロホンは、同様の理由でユーザが能動的に装置を使用するときにターンオンされてもよい。例えば、スタジアム環境では、音響ノイズのスパイクは、遅延に敏感なユーザトラフィックの大幅な増加に強く相関している。例えば、フィールドでエクサイティングなプレイがあるとき、ユーザは、多量のメッセージ及び／又はコールを発信するか、或いは写真やビデオをウェブサイトに投稿する。別の例では、ＮＡＳＣＡＲ自動車レースにおいて、音響ノイズが減少するとき、例えば、レースサーキットでイエローフラグが振られて車がスローダウンするとき、ユーザトラフィック／電話コールの量は、直ちに急上昇する。

或いは又、インサイトを更新すべきかどうか決定するための基準は、上述したように、現在プリフェッチイベントの完了が予想されるまでに残っている時間／バイトの量に依存する。これは、プリフェッチイベントの終わりにプリフェッチレートが増分的にランピングダウンするケースに適用できる。又、これは、アプリケーションインサイトが周期的に自動的に減少されて、ランピング状パターンを達成するケースにも適用できる。このランピング実施形態では、アプリケーションは、例えば、プリフェッチされるべき次のファイルをどれほど素早く要求するかを制御することにより、ダウンリンクにおけるプリフェッチのレートを自分で絞ることができる。例えば、ＨＴＴＰ適応ストリーミングのケースでは、アプリケーションは、１０秒ごとに又は１秒ごとに余分な１０秒ビデオセグメントをプリフェッチする。或いは又、アプリケーション又はＵＥ ＯＳは、ダウンロードされたファイルがダウンロードバッファから検索されるレートを制御するか、又はそれまでに受け取られたダウンロードに応答してどれほど素早くＴＣＰ／ＩＰ確認が送信されるか制限することにより、プリフェッチのレートを自分で絞ってもよい。

移動は、アプリケーション及び／又はオペレーティングシステムにとって見える。ＵＥがプリフェッチを行い、そして最後の知識サーバーインサイトの時間に軌道に対して移動を検出した場合に、ＵＥは、それが知識サーバーインサイトの新たな更新を得るまでプリフェッチを停止することができる。例えば、所与のＵＥが特定のｅＮＢに接近移動する場合には、他の２つのＵＥがダウンロードを行う間に５Ｍｂｐｓの使用を求める。移動基準では、これを回避することができ、そして２つのダウンロードＵＥのリンク速度は、負荷が既に１００％であるときにプリフェッチにより低下することはない。

特定の例では、ＵＥ Ｘ及びＹは、１０Ｍｂｐｓを共有できるが、次いで、ＵＥ Ｚが到着する。先ず、ＵＥ Ｘ及びＹは、プリフェッチを回避し、従って、各々、０．５及び３Ｍｂｐｓを使用する。ＵＥ Ｘのサービスは、０．５Ｍｂｐｓ必要であるが、５Ｍｂｐｓ利用可能と見る。同様に、ＵＥ Ｙのサービスは、３Ｍｂｐｓ必要であるが、５Ｍｂｐｓ利用可能と見る。知識サーバーは、約３５％利用度であることを検出し、従って、プリフェッチを生じさせ又は促進し、ＵＥ Ｘ及びＹ各々が約４Ｍｂｐｓを使用するように導く。このケースでは、知識サーバーは、幾つかのＵＥが、利用度が１００％付近であってもより高いリンク速度を見るこのようなケースにおいてプリフェッチを防止する上で役立ち、プリフェッチは、他のものにビデオ停止を生じさせることがある。

この例では、ＵＥ Ｚが１０Ｍｂｐｓの必要性に到達すると、ＵＥ Ｘ及びＹは、ネットワーク状態の変化、即ち利用可能な帯域巾の１．２５ｘ低下を検出し、そして新たなインサイトを受け取るまでプリフェッチを停止する。このケースでは、ＵＥ Ｘ及びＹは、既に数秒間プリフェッチしており、従って、直ちに問題を生じることなく停止することができる。従って、限定された時間中、ＵＥ Ｚは、例えば、最初の１分間、約３Ｍｂｐｓだけを得るのではなく、直ちにほぼ１０Ｍｂｐｓ全体を得ることができる。

この例では、ＵＥ Ｘ及びＹは、知識サーバーインサイトのみに基づくよりも約１分早くプリフェッチを停止し、それにより、知識サーバーの発見／通知遅延を回避することができる。

バッファが空になると、ＵＥ Ｘ及びＵＥ Ｙは、各々、０．５及び３Ｍｂｐｓを再開する。更に、ＵＥ Ｘ及びＹは、待機し、そしてレートが２倍になるのを見る。レートが２倍になると、ＵＥ Ｘ及びＹは、レートが２倍になることによりプリフェッチを再開する。これは、ＵＥ Ｚがそのような激しい使用を止めるか又は停止するや否や、生じる。

幾つかの実施形態は、種々の利益及び／又は効果を有する。例えば、幾つかの実施形態において、知識サーバーは、インサイトをアプリケーションにサービスさせる。サービスされるインサイトは、ワイヤレスネットワークに膨大なコストを掛けるのを回避しながら、ネットワークインサイトをできるだけフレッシュで／適切なものにするのを許す更に別のメカニズムをなすことができる。フレッシュで／適切なインサイトにすることで、著しい利益をホストに許すと共に、例えば、スタジアムにおける得点イベントの後にプリフェッチが約１分続いて１分の負荷スパイクになるのを回避することができる。このメカニズムは、リンク速度のようなあるローカル環境変数を検出するアプリケーション能力と組み合わせてこれらインサイトを使用するアプリケーションにおいて実施することができる。

図１１は、幾つかの実施形態により、ネットワーク状態のアプリケーション検出と共に適用される知識サーバーインサイトの一例を示す。図１１に示すように、１において、先ず、セルは、プリフェッチを含まずに、合計３．５Ｍｂｐｓを使用する。その間に、ＵＥは、約５から１０Ｍｂｐｓを見る。知識サーバーは、２において、利用度が約３５％であることを検出し、そしてプリフェッチを生じさせて、ＵＥ Ｘ及びＹの各々が約〜４Ｍｂｐｓへランピングアップすることを導き、〜８０％利用度を生み出す。次いで、３において、ＵＥ Ａ及びＢが各々セルに到達し、約１０Ｍｂｐｓを必要とし、ほとんど即座にこれを得る。４において、ＵＥ Ｘ及びＹは、おそらくレイテンシー又はリンク速度の変化を検出することにより、ネットワークの利用増加を検出したときに、既に数秒のデータをフェッチしているので、ほぼ全てのデータ使用を停止する。５において、Ｘ及びＹによる利用減少は、ＵＥ Ａがその全データ量を得るのを許す。次いで、ＵＥ Ａがその利用を停止するとき、ＵＥ Ｂは、その希望の帯域巾を得て、これも停止となる。６において、ＵＥ Ｘ及びＹは、データレートの正の変化、等の検出に基づき、再び約４Ｍｂｐｓへとランピングアップする。その間に、知識サーバーは、関連物を得る必要がない。

あるケースでは、リンク速度は、アプリケーションによって直接検出される。例えば、ＨＴＴＰ適応ビデオストリーミングアプリケーションは、ビデオの各セクションが得るリンク速度を監視し、次いで、その情報を使用して、ビデオの次のセクションにどんな圧縮レベルを使用するかに作用を及ぼす。環境の変化、例えば、ネットワークアクティビティの変化、ユーザ装置の位置の変化、又はユーザ装置に関連した会場の変化を決定するための他の仕方も許される。

図１３は、幾つかの実施形態によるランピングインサイトを示す。図１３に示したように、最初のポイントにおいて、ユーザ装置には、プリフェッチを直ちに開始するが、プリフェッチを制限するよう促進するインサイトが与えられる。又、このインサイトは、最大条件を満足するまで規則的又は不規則な間隔でプリフェッチのランピングアップを継続するようにユーザ装置を明示的又は暗示的に促進する。例えば、ランピングは、９５％を越える利用度が達成される状態を回避するように設計される。

当業者であれば、上述した本発明は、異なる順序のステップで、及び／又はここに開示したものとは異なる構成のハードウェア要素で、実施できることが容易に理解されよう。それ故、本発明は、好ましい実施形態に基づいて説明したが、当業者であれば、本発明の精神及び範囲から逸脱せずに、幾つかの変更、修正及び代替的構造が明らかであろう。それ故、本発明の境界及び限界を決定するために、特許請求の範囲を参照されたい。

用語
ＡＳＡ 許可共有アクセス
ＡＳＩＣ 特定用途向け集積回路
ＣＥＭ 顧客経験管理
ＣＱＩ チャンネルクオリティインジケータ
ＣＰＵ 中央処理ユニット
ＣＳＰ 通信サービスプロバイダー又は顧客サービスプロバイダー
ＤＳＰ デジタル信号プロセッサ
ｅＮＢ 進化型ノードＢ
ＦＰＧＡ フィールドプログラマブルゲートアレイ
ＨＤＤ ハードディスクドライブ
ＫＳ 知識サーバー
ＬＡＵ 位置エリア更新
Ｏ＆Ｍ 動作及び維持
ＰＬＤ プログラマブルロジック装置
ＲＡＭ ランダムアクセスメモリ
ＲＡＵ レポートエリア更新
ＲＥＴ リモート電気的チルト
ＲＦ 高周波
ＲＲＣ 無線リソース制御
ＲＳＲＱ 基準信号受信クオリティ
ＲＳＲＰ 基準信号受信電力
ＴＡＵ トラッキングエリア更新
ＵＥ ユーザ装置
ＵＲＬ ユニフォームリソースロケータ

１１０：ユーザ装置
１２０：ｅＮＢ
１３０：サーバー
５１０：ネットワーク要素
５１４、５２４：プロセッサ
５１５、５２５：メモリ
５１６、５２６：トランシーバ
５１７、５２７：アンテナ
５２０：ユーザ装置

Claims (56)

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. 前記所定の条件は、前記少なくとも１つの環境状態に関して少なくとも１つのスレッシュホールドを越えることを含む、請求項１９から２５のいずれかに記載の装置。
27. 前記再調整は、プリフェッチを中断又は減少することを含む、請求項２６に記載の装置。
28. 前記少なくとも１つの環境状態を更に監視する手段；及び
    前記少なくとも１つの環境状態が第２の所定の条件を満足するときに前記アプリケーション又はユーザ装置の機能を更に再調整する手段；
    を更に備えた請求項２７に記載の装置。
29. 前記第２の所定の条件は、前記少なくとも１つの環境状態に関して少なくとも１つのスレッシュホールドを越えないことを含む、請求項２８に記載の装置。
30. 前記更なる再調整は、プリフェッチを回復又は増加することを含む、請求項２９に記載の装置。
31. 前記所定の条件は、前記少なくとも１つの環境状態に関して少なくとも１つのスレッシュホールドを越えないことを含む、請求項１９から２５のいずれかに記載の装置。
32. 前記再調整は、プリフェッチを増加することを含む、請求項３１に記載の装置。
33. 前記プリフェッチの増加は、周期的に増分で行われる、請求項３２に記載の装置。
34. ユーザ又はアプリケーションに対するネットワークサービス実現性を監視するための手段；及び
    前記ネットワークサービス実現性がユーザ又はアプリケーションに対して検出されたときにユーザ装置にプッシュメッセージを送信するための手段；
    を備え、前記プッシュメッセージは、ネットワークサービス実現性に関連した少なくとも１つのスレッシュホールドを指示する、装置。
35. 前記スレッシュホールドは、少なくとも１つの環境状態に関連している、請求項３４に記載の装置。
36. 前記環境状態は、音声レベル、ネットワークレイテンシー、ネットワーク速度、又はネットワークパケットロス、の少なくとも１つを含む、請求項３４又は３５に記載の装置。
37. 少なくとも１つのプロセッサ；及び
    コンピュータプログラムコードを含む少なくとも１つのメモリ；
    を備えた装置において、少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、
    ユーザ装置又はユーザ装置のアプリケーションの機能を、ネットワーク要素から受け取った第１のネットワークインサイトに基づいて調整し、
    ユーザ装置に対応する少なくとも１つの環境状態を決定し、
    少なくとも１つの環境状態を監視し、及び
    少なくとも１つの環境状態が所定の条件を満足するときにアプリケーション又はユーザ装置の機能を再調整する、
    ようにさせるよう構成された装置。
38. 前記ネットワーク要素は、知識サーバーを含む、請求項３７に記載の装置。
39. 前記第１のネットワークインサイトは、プリフェッチを遂行すべきかどうかの指示を含む、請求項３７又は３８に記載の装置。
40. 前記環境状態は、音声レベル、ネットワークレイテンシー、ネットワーク速度、又はネットワークパケットロス、の少なくとも１つを含む、請求項３７から３９のいずれかに記載の装置。
41. 前記少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、前記第１のインサイトとは異なる第２のネットワークインサイトを適用することにより機能を再調整するようにさせるよう構成される、請求項３７から４０のいずれかに記載の装置。
42. 前記少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、前記少なくとも１つの環境状態を記憶するようにさせるよう構成され、前記監視は、現在環境状態を前記少なくとも１つの環境状態と比較することを含む、請求項３７から４１のいずれかに記載の装置。
43. 前記少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、
    第３のネットワークインサイトを決定し；及び
    前記第３のネットワークインサイトに基づいて前記アプリケーション又はユーザ装置の機能を再調整する；
    ようにさせるよう構成された、請求項３７から４２のいずれかに記載の装置。
44. 前記所定の条件は、前記少なくとも１つの環境状態に関して少なくとも１つのスレッシュホールドを越えることを含む、請求項３７から４３のいずれかに記載の装置。
45. 前記少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、プリフェッチを中断又は減少することにより再調整するようにさせるよう構成された、請求項４４に記載の装置。
46. 前記少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、
    前記少なくとも１つの環境状態を更に監視し；及び
    前記少なくとも１つの環境状態が第２の所定の条件を満足するときに前記アプリケーション又はユーザ装置の機能を更に再調整する；
    ようにさせるよう構成された請求項４５に記載の装置。
47. 前記第２の所定の条件は、前記少なくとも１つの環境状態に関して少なくとも１つのスレッシュホールドを越えないことを含む、請求項４６に記載の装置。
48. 前記少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、プリフェッチを回復又は増加することにより機能を再調整するようにさせるよう構成された、請求項４７に記載の装置。
49. 前記所定の条件は、前記少なくとも１つの環境状態に関して少なくとも１つのスレッシュホールドを越えないことを含む、請求項３７から４３のいずれかに記載の装置。
50. 前記少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、プリフェッチを増加することにより機能を再調整するようにさせるよう構成された、請求項４９に記載の装置
51. 前記少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、プリフェッチを周期的に増分で増加するようにさせるよう構成される、請求項５０に記載の装置。
52. 少なくとも１つのプロセッサ；及び
    コンピュータプログラムコードを含む少なくとも１つのメモリ；
    を備えた装置において、少なくとも１つのメモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサとで、装置が、少なくとも、
    ユーザ又はアプリケーションに対するネットワークサービス実現性を監視し；及び
    前記ネットワークサービス実現性がユーザ又はアプリケーションに対して検出されたときにユーザ装置にプッシュメッセージを送信する；
    ようにさせるよう構成され、前記プッシュメッセージは、ネットワークサービス実現性に関連した少なくとも１つのスレッシュホールドを指示する、装置。
53. 前記スレッシュホールドは、少なくとも１つの環境状態に関連している、請求項５２に記載の装置。
54. 前記環境状態は、音声レベル、ネットワークレイテンシー、ネットワーク速度、又はネットワークパケットロス、の少なくとも１つを含む、請求項５２又は５３に記載の装置。
55. 請求項１から１８のいずれかに記載の方法より成るプロセスを遂行するためのインストラクションをエンコードするコンピュータプログラム製品。
56. ハードウェアで実行されたときに、請求項１から１８のいずれかに記載の方法より成るプロセスを遂行するインストラクションでエンコードされた非一時的コンピュータ読み取り可能な媒体。

Images