JP7588631B2 - ビッグデータ環境におけるリソース管理 - Google Patents

Description

（関連特許出願の相互参照）
[0001] 本特許出願は、これらの出願が、それらの全体が参照により本明細書に組み込まれている、２０１４年、７月１６日に出願された「Ｉｎｔｅｌｌｉｇｅｎｔ Ａｕｔｏｍａｔｉｃ Ｔｒｏｕｂｌｅｓｈｏｏｔｉｎｇ ｆｏｒ Ｃｅｌｌｕｌａｒ Ｎｅｔｗｏｒｋｓ」という名称の米国仮出願第６２／０２５，４５３号と、２０１４年、７月１７日に出願された「Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｍｅｎｔ ｗｉｔｈ Ｂｉｇ Ｄａｔａ Ｆｅｅｄｓ」という名称の米国仮出願第６２／０２５，９５８号と、２０１４年、７月１７日に出願された「Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｅｎｇｉｎｅ ｆｏｒ Ｎｅｔｗｏｒｋ Ｉｎｓｉｇｈｔｓ」という名称の米国仮出願第６２／０２５，９６１号と、２０１４年、７月１６日に出願された「Ａｕｔｏｍａｔｉｃ Ｈｅａｌｔｈｃａｒｅ Ｍｏｎｉｔｏｒｉｎｇ Ｓｙｓｔｅｍ Ｌｅｖｅｒａｇｉｎｇ Ｃｅｌｌｕｌａｒ Ｄａｔａ Ｓｙｓｔｅｍｓ」という名称の米国仮出願第６２／０２５，４４１号と、２０１５年、７月１５日に出願された「Ｂｉｇ Ｄａｔａ Ｍａｃｈｉｎｅ Ｌｅａｒｎｉｎｇ Ｕｓｅ Ｃａｓｅｓ」という名称の米国仮出願第６２／１９３，００２号との優先権を主張するものである。

[0002] 現在、ビッグデータ技法の出現に伴った革命がある。リレーショナルデータベースなど従来のデータストレージ技術は大量のデータについて十分に高性能ではなかったが、マップ縮小などの並列処理アルゴリズムと共に、クラウドに基づく代替的なデータストアの出現は、ビッグデータを実用的に、高性能に、またコスト効率の高いものにしている。さらに、現在では、データのリアルタイム解析、またはデータのリアルタイムに近い解析を可能にする、大量のデータに対するものを含む高性能の処理が最近進化している。１つの例は、Ｈａｄｏｏｐに対するそのような処理を提供し、またインメモリ計算を活用するＳｐａｒｋを含む。ビッグデータは、解析すべき統計的にかなりの量のデータを提供するので、ビッグデータは、それ自体を既存の機械学習技法によく役に立つようにしている。

[0003] ビッグデータ技法および機械学習技法は、広範な領域に適用されることもある。１つの例は、新しいネットワーク技術およびサービスの絶え間ない開発によって導かれ、スマートフォン革命とその数え切れないアプリケーションとによって先導される一定の、またかなりの変革を受けているワイヤレス通信である。これに関して、セルラー方式システムなどのワイヤレスシステムは、増大するトラフィック要求、ならびにこれらのアプリケーションによって課される性能要件に立ち向かうために、絶え間なく進化している。ワイヤレス通信システムの進化は、一般的に、無線レベルにおける性能を改善すること、またはコアネットワークのアーキテクチャを改善することなど、分離されたブロックにおいて起こっている。ワイヤレス通信は、過去１０年において改善しているが、ネットワークをサポートするバックエンドシステムの一部分は、３Ｇネットワークや２Ｇネットワークなどのレガシーアーキテクチャを依然として含むことができる。

[0004] これは、持続可能なように、自分のシステムを成長させる必要があるネットワークオペレータに対してとてつもなく大きな運用の課題を創り出す。異なるタイプのワイヤレスデバイスと、異なるタイプのデータサービスと、異種無線アクセスネットワークとの使用に関連する複雑さに起因して、顧客ケアのコストは、かなり増大している。さらに、ネットワークの中の他のシステムと、ネットワーク要素とからのコンテキスト情報を利用する様々な通信システムを改善することに対しては、あまり進化していない。絶え間なく変わり、要求するネットワーク性能要件に遅れずについて行くために、ワイヤレスプロバイダは、コスト効率のよいように、絶えず進化する顧客要求に対処する柔軟性を有しながら、自分のメンテナンスコスト構造を変革する必要がある。ネットワーク要件の変わりやすさ、進化する顧客ニーズ、コスト効率性を継続する必要性は、従来のアプローチに対する課題を提示する。本開示は、これらの考察および他の考察に関して書かれている。

[0005] 図面は、限定するものではなく単に例として、本教示に合致した１つまたは複数の実装形態を示す。図面の中で、同様な参照番号は、同じ要素または類似した要素を指す。

[0006]無線リソース管理アーキテクチャを実装するための例示のネットワークアーキテクチャを示す図である。 [0007]無線アクセスネットワークの要素の例示の高レベルインターフェースブロック図である。 [0008]例示の一実施形態と整合した、データフレームワークと相互作用する無線リソース管理（RRM: Radio Resource Management）モジュールを示すブロック図である。 [0009]ビッグデータレコードを利用した修正されたＲＲＭのための例示のプロセスの流れ図である。 [0010]測定結果メガストアからの通知に基づいてｅノードＢとＥＵとの間の接続を調整するための例示のプロセスの流れ図である。 [0011]例示の一実施形態と整合した、データフレームワークのブロック図である。 [0012]根本原因の識別のための例示のモデルを示す図である。 [0013]無線アクセスネットワーク性能を維持するための例示のプロセスの流れ図である。 [0014]測定結果メガストアに結合された端末の例示のユーザインターフェースを示す図である。 [0015]例示の一実施形態と整合した、リモート健康モニタリングを含むシステムの高レベル図である。 [0016]例示の一実施形態と整合した、モニタリングシステムのデータフレームワークのブロック図である。 [0017]ビッグデータレコードを使用した健康状態を識別するための例示のプロセスの流れ図である。 [0018]ネットワークまたはホストコンピュータを示す図である。 [0019]ユーザインターフェース要素を有するコンピュータを示す図である。

[0020] 本開示は、一般に、ネットワーク要素を最適化する方法およびシステムに関する。スケーラブルネットワークバックエンドが、データに対して単純化されたアクセスを提供し、またオートメーションを向上させるオープンアーキテクチャに基づいて、提供される。運用効率と、ネットワークの動作の全体のコストとは、機能のオートメーションと、ハードウェアリソースおよびソフトウェアリソースの合理化とによって低減される。機械学習アプローチを用いて補完されたビッグデータ技術の使用は、複雑なタスクを簡略化し、また自動化し、より効率的なネットワーク動作と、改善された顧客品質と、加入者の解約の低減とをもたらしている。

[0021] 一態様においては、本明細書において説明されるシステムは、オープンプラットフォームを提供し、ここでは異種ソースからの複数のデータフィードが、組み合わされ、またリアルタイムで処理される。一実施形態においては、システムは各ネットワークノードからの監視されたデータの絶え間ないモニタリングと送信とを実行し、この各ネットワークノードからの監視されたデータは、中央集中化されたリモートサーバにおいて、合成される可能性がある。異種ソースから取り出された合成されたデータは、可能性のある問題について解析され、また関連のある問題解決手法が、提供される。

[0022] 一態様においては、第１のネットワーク要素に関連した異種ソースからのデータは、処理レイヤによって受信される。第１のネットワーク要素と、他のネットワーク要素とに関連したコンテキスト情報が、測定結果メガストアから取り出される。異種ソースからのデータと、コンテキスト情報とは、インテリジェンスレイヤによって解析される。インテリジェンスレイヤが、所定の条件が満たされる、または所定のしきい値が超過されると決定すると、第１のネットワーク要素に対して通知が提供される。

（例示のシステムアーキテクチャ）
[0023] 図１は、無線リソース管理アーキテクチャを実装するための例示のネットワークアーキテクチャを示す。図１は、その加入者顧客と、関連するモバイルデバイスユーザとに対して広範囲のモバイル通信サービスと、補助サービスまたは補助機能とを提供するように、キャリアプロバイダまたはサービスプロバイダによって運営され得るモバイル通信ネットワーク１００を示す。参照数字１００によって一般に示される要素は、モバイル通信ネットワークの要素であり、またキャリアによって、またはキャリアのために運営される。モバイル通信ネットワーク１００は、ユーザ機器（UE: user equipment）１０２ａから１０２ｄの間の通信、ならびにモバイル通信ネットワーク１００の外側のネットワークおよび局とのＵＥのための通信を提供する。

[0024] 後での考察のために、いくつかのＵＥが図面の中に見られ、モバイル通信ネットワーク１２２を経由して様々なサービスを受信することができるデバイスについてのいくつかの例を表す。今日では、ＵＥは、一般的に、ポータブルハンドセットと、スマートフォンと、タブレットコンピュータと、携帯型個人情報端末（PDA: personal digital assistants）と、スマートウォッチとの形態をとるが、それらは、民生用電子デバイスと、ビジネス用電子デバイスと、ウェアラブル個人用健康モニタ１０２ｄなどの医用電子デバイスとを含めて、他のフォームファクタにおいて実装されることもある。モバイル通信ネットワーク１００により、ＵＥのユーザ（例えば、顧客または加入者）は、通信を開始し、またインターネット１２０から情報を受信することができるようになる。

[0025] モバイル通信ネットワーク１００は、一般的に、いくつかの相互接続されたネットワークによって実装される。したがって、ネットワーク全体１００は、いくつかの無線アクセスネットワーク（RAN: Radio Access Networks）１２２、ならびにいくつかのＲＡＮを相互接続する広域地上ネットワーク、およびマルチメディアメッセージングサービスセンタ（MMSC: Multimedia Messaging Service Centers）などのコアネットワーク要素に広域地上ネットワークを相互接続する広域ネットワーク（WAN: wide area network）を含むことができる。ＵＥ１０２ｂおよび１０２ｃにサービスする地域的部分など、ネットワーク１００の地域的部分は、１つまたは複数のＲＡＮ（ワイヤレス通信ネットワーク１２２によって表される）および地域的回路、および／またはパケット交換ネットワークおよび関連するシグナリングネットワーク施設を含むことができる。

[0026] モバイルサービスプロバイダまたはキャリアのうちの１つによって運営されるＲＡＮ１２２の物理的要素は、ｅノードＢ１１９のノードによって図１の例の中に表されるいくつかの基地局を含む。そのようなｅノードＢ１１９のノードは、ＵＥがレンジ内にあるときに、１つまたは複数のＵＥ（１０２ａから１０２ｄまで）と、ノードのサイトにおけるアンテナシステムを経由して、またエアリンクの上で、通信する基地トランシーバシステム（BTS: base transceiver system）を含むことができる。それぞれのｅノードＢ１１９のノードは、多くの場合に「セル」と称されるカバレッジエリアの内部の無線タワーに取り付けられたいくつかのアンテナに結合されたＢＴＳを含むことができる。ＢＴＳは、ｅノードＢのノード１１９が、現在サービスしているＵＥに対してＲＦ信号を送信し、またＵＥからＲＦ信号を受信する無線ネットワークの一部分である。無線アクセスネットワーク１２２は、それぞれのｅノードＢ１１９のノードと、ＵＥがそれと通信し、またはそれを通して通信する他の要素との間の、ＵＥのためのユーザ通信を搬送する。様々な実施形態においては、各ｅノードＢにおいて通信信号を（１つまたは複数のＵＥに対して）送信する無線は、後でより詳細に考察される、測定結果メガストア１４０から受信されるコンテキスト情報、および／またはモニタリングサーバ１３０から受信されるアラートに基づいて、電力出力、帯域幅などを調整することができる。無線アクセスネットワーク１２２を形成する、スイッチおよび／またはルータなどの個別の要素は、簡単にするためにここでは省略されるが、図２との関連で関連のある部分において考察される。

[0027] モバイル通信ネットワーク１００の無線アクセスネットワーク部分１２２は、１２０において示される「インターネット」と一般的に称されるネットワークなどの公衆パケットデータ通信ネットワークに接続している。無線アクセスネットワーク１２２と、インターネット１２０とを経由したパケット通信は、測定結果メガストアからのコンテキスト情報と、モニタリングサーバ１３０からのアラートとを無線アクセスネットワーク１２２の様々なネットワーク要素に対して提供するなど、ネットワーク１００を通して様々なサービスをサポートし、ならびにＵＥに対して、テキストメッセージおよびマルチメディアメッセージの通信と、電子メールと、ウェブサーフィンまたはウェブブラウジングと、プログラミングと、メディアダウンローディング（オーディオおよびビデオを含む）などと、を提供することができる。例えば、ＵＥ１０２ａから１０２ｄは、直接に（ピアツーピアに）、または様々なサーバ（別々に示されてはいない）を経由してのいずれかで、パーソナルコンピュータなどのユーザ端末デバイスからメッセージを受信し、またユーザ端末デバイスに対してメッセージを送信することができるだろう。

[0028] この考察のために留意すべきものとして、本明細書において考察されるネットワークメッセージとアラートとの多くは、無線アクセスネットワーク１２２ならびに無線アクセスネットワーク１２２の要素を使用して、様々なＵＥに対して送信され、また様々なＵＥから受信される。無線アクセスネットワーク１２２の進化型パケットコア（EPC: Evolved Packet Core）は、進化型パケットシステム（EPS: Evolved Packet System）ベアラチャネルの概念を使用して、無線アクセスネットワーク１２２の中のゲートウェイ１０７からＵＥへとＩＰトラフィックをルーティングする。ベアラチャネルは、パケットデータネットワーク（PDN: Packet Data Network）ゲートウェイ（PGW）１０７と、ＵＥ（例えば１３ａから１３ｅまで）との間の規定されたサービス品質（QoS）を有するＩＰパケットフローである。

[0029] ｅノードＢ１１９は、通常、「Ｘ２」として知られているインターフェースによって互いに相互接続される。各ｅノードＢの間の通信は、無線リソース管理（RRM）を含んでおり、この無線リソース管理は、無線ベアラ制御、無線アドミッション制御、無線モビリティ制御、スケジューリング、アップリンクとダウンリンクとの両方におけるＵＥに対するリソースの動的配分など、無線ベアラに関連したすべての機能を対象として含む。一態様においては、ＲＲＭは、測定結果メガストア１４０と通信し、かつ／またはモニタリングサーバ１３０からメッセージを受信して、その制御機能を最適化することができる。

[0030] 一実施形態においては、ネットワーク１００は、インターネット１２０を介する通信のために結合される測定結果メガストアサーバ１４０を含む。測定結果メガストアサーバは、ＵＥと、無線アクセスネットワーク１２２との間のより効率的な接続（例えば、消費電力および／または速度）を創り出すこと、ならびに無線アクセスネットワーク１２２のコンポーネントを最適化することに関連のあるコンテキスト情報（これは、様々なソースからのものである可能性がある）を記憶する。簡単にするために、ＵＥと、無線アクセスネットワークのコンポーネントとは、一括して、本明細書においてネットワーク要素と称される。様々な実施形態においては、測定結果メガストアサーバ１４０によって提供されるコンテキスト情報は、異なるタイプの情報を含むことができる。例えば、コンテキスト情報は、１つまたは複数の無線アクセスネットワーク１２２から受信されるディープパケットインスペクション（DPI: Deep Packet Inspection）を経由して抽出されるアプリケーションレベル情報を含むことができる。サーバ１４０におけるコンテキスト情報は、ＵＥ端末カテゴリ（例えば、スマートフォン、タブレット、ラップトップ、個人用健康モニタリングデバイスなど）の情報を含むことができる。コンテキスト情報は、最大送信ビットレートおよび低電力デバイスであるように構成されている（高性能と比べて低電力に構成されている）かどうかなど、ネットワーク要素の能力を関係づけることもできる。一実施形態においては、コンテキスト情報は、ネットワーク要素の最近記憶された電力ステータスを提供することができ、この最近記憶された電力ステータスを使用して、無線アクセスネットワーク１２２と、それぞれのＵＥとの間の接続を最適化することができる。

[0031] それに応じて、測定結果メガストアサーバ１４０は、様々なソースからの異種データを含むコンテキスト情報を記憶する。サーバ１４０に記憶されるデータは、ワイヤレス通信ネットワーク１２２のネットワーク要素によって使用されて、それぞれ、各ネットワーク要素のリソースの調整された最適化を提供することができる情報を含む。代わりに、または追加として、モニタリングサーバ１３０は、測定結果メガストア１４０からネットワーク全体１００からの情報を含むコンテキスト情報を取り出し、このコンテキスト情報をネットワーク要素に関連した異種ソースからのデータと共に解析して、ネットワーク全体１００のコンテキストにおいてその性能を最適化するための、それぞれのネットワーク要素に対するメッセージをトリガする１つまたは複数の所定の条件が満たされるかどうかを決定することができる。対照的に、先行技術のセルラー方式通信ネットワークは、同じベンダからのコアネットワークの中のネットワーク要素やネットワークの中で特定の機能を実装するように展開されるネットワーク要素など、ネットワーク要素の小規模サブセットから、ローカルに取得されたメトリクスを単に利用して、無線アクセスネットワーク１２２に対するＵＥ１０２の各通信リンクに対してリソースをどのようにして最適に割り当てるかを決定することができる。

[0032] 例えば、ＵＥと、ｅノードＢとの間の接続を確立するために、先行技術の無線スケジューラ（ｅノードＢにおける）は、スケジューラが、ＵＥと、対応するｅノードＢとの間の各リンクに割り当てるべきターンの数を決定するために、それぞれのＵＥのバッファにおけるデータの量、識別された無線品質、デバイス能力など、ローカルにアクセス可能な情報を単に考慮することができるだけである。ディープパケットインスペクション（DPI）を使用して、例えば、ファイル転送プロトコル（FTP）転送に対するものに比べて、Ｓｋｙｐｅビデオコールに対して異なる品質レベルを割り当てることができる、より進化した先行技術システムにおいてさえも、データは特定のサブシステム（すなわち、ワイヤレス通信ネットワーク）から抽出され、異なるネットワーク要素の間で共有されてはいない。しかしながら、この抽出されたデータは、制限され、またｅノードＢと、対応するＵＥとの間の接続に割り振られるリソースは、せいぜい推測である。例えば、先行技術のシステムにおいては、たとえｅノードＢ１１９の無線スケジューラが、端末の端末カテゴリを決定することができるとしても、スケジューラは、ＵＥ（例えば、１０２ｄ）が、できるだけバッテリ寿命を節約する必要があるマシンツーマシン（M2M: machine to machine）モジュールであることを依然として知らない可能性がある。

[0033] 対照的に、一態様においては、本明細書において説明されるシステムは、測定結果メガストアサーバ１４０においてコンテキスト情報を記憶することにより、複数のｅノードＢ１１９を通しての情報の共有化を可能にしており、この測定結果メガストアサーバ１４０は、ＵＥ（例えば、１０２ｄ）と、その対応するｅノードＢ１１９との間の接続に、例えば、リソースのタイプを割り振ることにより、ワイヤレス通信ネットワーク１２２の容量を改善する。したがって、顧客のタイプ、データプラン、アプリケーションのタイプ、デバイスのタイプなどのコンテキスト情報を利用することにより、ＵＥ１０２と無線アクセスネットワーク１２２との間の無線通信がよりよく調整され、このコンテキスト情報は、インターネット１４０を経由して測定結果メガストア１４０によって提供される。

[0034] モニタリングサーバ１３０と、測定結果メガストア１４０とは、いくつかの類似したプラットフォームの上に分散型の様式で実装されて、処理負荷を分散させ、かつ／または追加の機能を提供することができる。例えば、一実施形態においては、測定結果メガストア１４０に構成において類似しているが、リモート健康モニタリングの形で専用化されることもあるリモート健康（例えば、人間のための）モニタリングサーバ１５０が、存在することもある。これに関して、システム１００は、オープンプラットフォームを提供しており、ここでは、個人用健康モニタ１０２ｄなどの様々なＵＥと、他のネットワークやサーバなどの異種システムからの複数のデータフィードとが組み合わされ、リアルタイムで数百万人の個人のために処理される。したがって、サーバ１３０、１４０、および１５０のそれぞれに関して本明細書において説明される機能は、１つまたは複数の異なるサーバによって提供される可能性もある。システム１００の実際の動作は、後で例として説明される。

[0035] 図２は、無線アクセスネットワーク１２２の論理ノードの例示の高レベルインターフェースブロック図を示す。例えば、システムアーキテクチャエボリューション（SAE: System Architecture Evolution）２００は、第３世代パートナーシッププロジェクト（3GPP）のロングタームエボリューション（LTE: Long Term Evolution）ワイヤレス通信規格のコアネットワークアーキテクチャである。ＳＡＥ２００は、制御プレーントラフィックとユーザプレーントラフィックとの分離を伴うフラットなオールＩＰアーキテクチャを有する。ＳＡＥ２００システムは、ｅノードＢ２１９と、モビリティ管理エンティティ（MME: Mobility Management Entity）２０２と、ホーム加入者サーバ（HSS: Home Subscriber Server）２０４と、ポリシー制御および課金ルールの機能（PCRF: Policy Control and Charging Rules Function）２０６とを含んでおり、これらは、モバイルトラフィックネットワーク１２２の一部分であり、またそれぞれネットワーク要素である。ｅノードＢ２１９は、ＵＥ２０２と、無線アクセスネットワーク１２２との間のインターフェースとしての役割を果たす機能強化された基地局として捉えられ得る。ＭＭＥ２０２は、通信アクセスネットワークのための制御ノードである。例えば、ＭＭＥ２０２は、再送信を含むアイドルモードのモバイルデバイストラッキングおよびページングのプロシージャのために使用される。ＭＭＥ２０２はまた、ベアラチャネルアクティブ化／非アクティブ化プロセスと、ＵＥ２０２ｅについてのサービングゲートウェイ（SGW: serving gateway）２１２の選択とを提供する。

[0036] ホーム加入者サーバ（HSS）２０４は、ユーザ関連情報と、加入関連情報とを含む中央データベースである。ＨＳＳ２０４は、モビリティ管理、コールおよびセッションの確立サポート、ユーザ認証、アクセス認可などの機能を提供する。例えば、ＨＳＳは、移動局国際加入者ディレクトリ番号（MSISDN: Mobile Station International Subscriber Directory Number）、ＳＩＭカード識別情報などを記憶する。

[0037] パケットデータネットワーク（PDN）ゲートウェイ（PGW）１０７は、ＵＥ２０２から外部パケットデータネットワークへの接続性を提供する。ポリシー制御および課金ルールの機能（PCRF）２０６は、ポリシー制御意思決定、ならびにポリシー制御強制機能（PCEF: Policy Control Enforcement Function）におけるフローベースの課金機能を制御することを提供し、このポリシー制御強制機能は、ＰＧＷ１０７の中に常駐する。ＰＣＲＦ２０６は、どのようにしてある種のデータフローがＰＣＥＦにおいて取り扱われるかを決定し、またこれが、ユーザの加入プロファイルに従っていることを保証するＱｏＳ認可を提供する。

[0038] サービングゲートウェイ（SGW）２１２は、ＭＭＥ２０２を通してモバイル２０２に対してデータパケットをルーティングし、転送する。例えば、データパケットは、アカウントしきい値が超過されるという通知メッセージを含むことができる。ＳＧＷ２１２は、ネットワーク内部ルーティング情報を含めて、ＩＰベアラチャネルサービスのモバイルデバイスパラメータを管理し、記憶する。これらのネットワーク要素と、他のネットワーク要素とのそれぞれは、測定結果メガストア１４０からのコンテキストデータと、モニタリングサーバ１３０のアラート／メッセージとに基づいて、性能において、調整される可能性がある。

（無線リソース管理（RRM））
[0039] 図３は、例示の一実施形態と整合した、データフレームワークと相互作用する無線リソース管理（RRM）モジュールを示すブロック図である。ｅノードＢ３１９は、１つまたは複数のＵＥ（例えば、ＵＥ３０２）と、ワイヤレス通信ネットワークとの間の基地局としての役割を果たす。システム３００の例においては、各ｅノードＢ３３０は、ＵＥ３０２と、ワイヤレス通信ネットワークとの間のデータ送信のための優先順位（例えば、ターンの数を割り振る）を提供するように構成されているスケジューラ３２２を含む。ｅノードＢ３１９は、例えば、変調を調整すること、符号化すること、および送信のための適切な時間を選択することにより、チャネル状態に合わせて送信モードを調整するように構成されているリンク適応ユニット３２４を含むことができる。

[0040] ｅノードＢ３１９は、ｅノードＢ３１９の動作のフローを制御するように構成されているフロー制御ユニット３２６を含むことができる。フロー制御ユニット３２６は、アドミッション制御、セキュリティシグナリングの協調、圧縮などを提供することができる。ｅノードＢは、そのワイヤレス通信レンジの内部の様々なＵＥ（例えば、ＵＥ３０２）と通信するように構成されているアンテナ３３０を含む。

[0041] ｅノードＢ３１９の様々なコンポーネントは、共に、ＲＲＭモジュール３２８を含んでおり、このＲＲＭモジュール３２８は、オープンなアプリケーションプログラムインターフェース（API: Application Program Interface）３３４を経由して、データフレームワーク３７０と通信するように構成されている。システム３００の中に示されるように、データフレームワークは、測定結果メガストア３４０と、インテリジェンスレイヤ３５０と、データ処理レイヤ３５２とを含むことができる。例えば、ＡＰＩ３３４は、インターネット１２０（図２の）を経由した測定結果メガストア３４０に対して、ワイヤレス通信ネットワーク１２２を介したｅノードＢ３１９の間の通信を可能にすることができる。データ処理レイヤ３５２はまた、ＲＲＭ３２８からローカライズされた情報を受信することもできる。

[0042] 以上で考察されるように、測定結果メガストア３４０は、異なるｅノードＢのＲＲＭモジュールなど、様々なネットワーク要素からの、ｅノードＢ３１９（および測定結果メガストア１４０から情報を受信するように構成された他のｅノードＢ）により、図１のワイヤレス通信ネットワーク１２２の上の無線通信のそれぞれのネットワーク要素をよりよく調整するために、共有され得るコンテキスト情報を記憶するように構成されている。そのような最適化は、それぞれのｅノードＢのアドミッション制御プロシージャと、スケジューラプロシージャと、リンク適応プロシージャと、電力制御プロシージャとのうちの少なくとも１つを含むことができる。

[0043] 実施形態において、測定結果メガストア３４０の中にコンテキスト情報をポピュレートするために、データが、システム３００のデータ処理レイヤ３５２によって収集される。処理レイヤによって収集されるデータは、様々なソースからのものとすることができ、これは、ワイヤレス通信ネットワーク１２２に結合されたＲＲＭモジュールなど、ワイヤレス通信ネットワーク１２２の要素、ならびにシステム１００の他のサーバ（例えば、１３０、１５０）からのデータを含むことができる。データ処理レイヤ３５２によって受信される情報のタイプは、インターネットからの関連のある情報を含めて、ＵＥによって提供される加入者無線トレース（例えば、ロケーション）情報と、オペレーションサブシステム（OSS: operations subsystem）情報と、顧客ケアレコード情報と、課金情報と、アプリケーション性能モニタリングレポート情報と、他の情報とを含むことができる。一実施形態においては、この情報の少なくとも一部が、測定結果メガストア３４０によって提供される。

[0044] 一実施形態においては、データは、様々なｅノードＢによって提供されるディープパケットインスペクション（DPI）からの情報を含む。データ処理レイヤ３５２は、リアルタイムで、かつ／またはバッチで実行されることもある。データは、リアルタイムでネットワーク要素によって実行される問い合わせを経由して、ネットワーク要素（例えば、ｅノードＢ３１９におけるＲＲＭモジュール３２８）に対して提供されることもあり、あるいは所定の時間間隔で、またはインテリジェンスレイヤ３５０によって生成される通知に応じて、ＲＲＭモジュールに対してプッシュされることもある。

[0045] 一実施形態においては、インテリジェンスレイヤ３５０は、データ処理レイヤ３５２から情報を受信し、また所定の１つまたは複数の条件が満たされるかどうかを決定するように構成されていることもある。これらの条件は、インテリジェンスレイヤのメモリに記憶されるルールセットによって提供されることもある。所定の条件が満たされるときに、インテリジェンスレイヤは、関連のあるアラートを生成することができる。例えば、インテリジェンスレイヤ３５０は、ＲＲＭにおける問題を示すことができる任意の異常値について、データ処理レイヤ３５２によって提供されるデータのパターンを解析することができる。これに関して、インテリジェンスレイヤ３５０は、他のＲＲＭモジュールに対する通知をトリガして、拡散しないように問題を防止し、かつ／または軽減することができる。アラートは、単に、システム３００の一部分である１つまたは複数のモジュールのＲＲＭ方法を変更する通知（例えば、動作する提案）またはアクティブ制御信号とすることができる。

[0046] インテリジェンスレイヤ３５０は、一般的に、特定の原因および／またはイベントが、ドロップしたコールなどのネットワークイベントの根本原因であった確率を記憶する確率ツリーを含む。確率ツリーの実装形態は、図７を参照してさらに詳細に説明される。インテリジェンスレイヤ３５０を有するノードは、他のノードと同じ確率ツリーを有する必要がないことに留意されたい。このようにして、ノードは、シナリオおよび／または使用事例に従って区分化されることもある。

[0047] 例えば、データ処理レイヤ３５２は、問題を示している第１のＲＲＭモジュールから情報を受信することができる。第１のＲＲＭモジュールから受信されるデータは、例えば、シグナリングメッセージを用いてＳＧＷが過負荷であることを示すことができる。インテリジェンスレイヤ３５０は、第１のＳＧＷに伴う問題を識別すると、ネットワーク要素と他のネットワーク要素とに関連したコンテキスト情報を、測定結果メガストアから取り出すことができる。条件が満たされるか、または所定のしきい値が超過されると決定すると、インテリジェンスレイヤ３５０は、データフレームワーク３７０からメッセージを受信するように構成された他のＲＲＭモジュールに対して通知を発行することができる。一実施形態においては、第１のＲＲＭモジュールはまた、インテリジェンスレイヤ３５０によって生成されるアラートをデータフレームワーク３７０から受信する。これに関して、他のｅノードＢモジュールは、それらのシステムに向かっている通信要求をそれぞれバッファし、または破棄し、第１のＲＲＭモジュールに影響を及ぼした問題を防止することができる。

[0048] したがって、測定結果メガストア３４０の中のコンテキスト情報は、ＲＲＭモジュールからの要求（例えば、問い合わせ）に応じて測定結果メガストア３４０によってＲＲＭモジュールに利用可能にされることもでき、またはデータフレームワーク３７０からの通知として提供されることもある。

[0049] システムについての上記概要と共に、システム３００の例示の動作についての高レベルの考察を考慮することが、今では役に立つ可能性がある。その目的を達成するために、図４は、データフレームワーク４３０とＲＲＭモジュール４０２との高レベルフローチャートと、互いのそれらの相互作用とを示す。ＲＲＭモジュール４０２は、データフレームワーク４３０からデータを受信するように構成されている、いくつかのＲＲＭモジュールのうちの１つとすることができる。データフレームワーク４３０は、複数のソースから収集されるコンテキスト情報を含んでおり、このコンテキスト情報は、ＲＲＭモジュールのリソースを調整するためにＲＲＭモジュール４０２によって使用される（例えば、ｅノードＢとＵＥとの間の接続を最適化する）。

[0050] データフレームワーク４３０から開始して、ステップ４３４において、関連のあるデータが、様々なソースから共通のデータフレームワークへと収集される。このデータは、リアルタイムで、かつ／またはバッチで、データ処理レイヤによって収集される。収集されるデータは、様々なソースからのものとすることができ、これらのソースは、ワイヤレス通信ネットワーク１２２の上で動作するように構成された別個のＲＲＭモジュールを含めて、ワイヤレス通信ネットワーク１２２の異なるコンポーネントを含むことができる。例えば、各ＲＲＭモジュールは、図１のシステム１００のワイヤレス通信ネットワーク１２２と、その対応するＵＥとについてのそのローカルな知識に基づいて、無線リソースを提供することができる。収集されるデータのソースは、システム１００の他のサーバおよびインターネットを含むこともできる。データフレームワーク４３０により（処理レイヤを経由して）受信される情報のタイプは、インターネットからの関連のある情報を含めて、ＵＥによって提供される加入者無線トレース（例えば、ロケーション）情報と、オペレーションサブシステム（OSS）情報と、顧客ケアレコード情報と、課金情報と、アプリケーション性能モニタリングレポート情報と、他の情報とを含むことができる。一実施形態においては、データ処理レイヤによって取り出されるデータは、最終的に、測定結果メガストアサーバ３４０において記憶されるコンテキストデータになり、このコンテキストデータは、他のネットワーク要素またはデータ処理レイヤによって使用され、また取り出されることもある。

[0051] 一実施形態においては、ステップ４３６において、データフレームワーク４３０により様々なソースから収集されるデータが、ＲＲＭモジュール４０２に対して提供されて、ｅノードＢと、対応するＵＥとの間の接続に割り振られるそのリソースを調整する。情報は、加入者とネットワークノードとについての一般的な情報など、インテリジェンスレイヤによって処理されていないデータを含むことができる。

[0052] 一実施形態においては、ステップ４３８において、データフレームワークによって収集されるデータは、インテリジェンスレイヤによってさらに処理される。このインテリジェンスレイヤは、データを解析し、またそれらからパターンおよび／またはトレンドを抽出するように動作する。例えば、ステップ４３８において、インテリジェンスレイヤは、１つまたは複数のしきい値が超過されるか、あるいは１つまたは複数の判断基準が満たされるかを決定することができる。例えば、ＲＲＭモジュールがオフである、またはドロップしたコールの数が０．１％を超過する。様々な実施形態においては、インテリジェンスレイヤによる考慮は、ユーザ／加入者の所定の設定、加入者制限（例えば、しきい値データ使用を超過している）、プランのタイプ（例えば、より高いグレードのプランには、優先順位が与えられることもある）、ＵＥのタイプ（例えば、低電力状態の下で機能することを意図しているデバイスには、より少ない電力を要求する接続が提供される）などを含むことができる。これに関して、ステップ４２２においては、データフレームワーク４３０は、特別なアラートの形式で、１つまたは複数のメッセージを適切なＲＲＭモジュールに対して提供することができ、このアラートは、個別に、ｅノードＢと、その対応するＵＥとの間の接続についてのローカルなリソースをどのようにして調整すべきかに対する指示を含むことができる。例えば、データフレームワーク４３０からアラートが送信される適切なＲＲＭモジュールは、セクタおよび／または時間に基づいたものとすることができる（例えば、ＲＲＭは、ゲーム時のスポーツスタジアムをカバーする）。

[0053] ＲＲＭモジュール４０２側では、ステップ４０６において、ＲＲＭモジュール４０２は、ローカルな知識に基づいて、無線リソースを計算する。ローカルな知識は、それが接続を確立している相手のデバイス（UE）のタイプ、ローカルなｅノードＢが接続されている相手のＵＥの数、トラフィック、消費電力、変調品質、ｅノードＢの温度などを含むことができる。一実施形態（図示されていない）においては、この情報は、データ処理レイヤ３５２を経由してデータフレームワーク４３０に提供される。

[0054] ステップ４０６において、ＲＲＭモジュール４０２は、ステップ４２０においてデータフレームワーク４３０から受信される一般的な情報データに基づいて、個別に、そのｅノードＢと各ＵＥとの間のリソース配分を調整する。上記で考察されるように、一実施形態においては、ＲＲＭモジュール４０２は、１つまたは複数の特別なアラート（すなわち、通知）の形式で、データフレームワーク４３０から１つまたは複数のメッセージを受信することができる。ステップ４０８において、ＲＲＭモジュール４０２は、データフレームワークから受信される特別なアラートに基づいて、加入者とネットワークノードとに対してｅノードＢのリソースを割り当てる。ステップ４０６と、４０８とは、別々のステップであるべき例として示されているが、一実施形態においては、リソースの調整と、リソースの割り当てとは、同じステップ（例えば、４０８）によって実行されることもある。

[0055] 例えば、測定結果メガストア１４０を有するデータフレームワーク４３０から受信される情報に基づいて、ＲＲＭモジュール４０２のｅノードＢは、個別に各ＵＥについての電力（例えば、消費制限）要件に基づいて、接続を調整することができる。様々な例においては、測定結果メガストア１４０から受信されるコンテキスト情報に基づいて、ｅノードＢは、無線アクセスネットワーク１２２のリソースのバランスを取るために、かつ／または故障を防止するために、それぞれのｅノードＢに対して接続することが許可されるＵＥの数を徐々に低減させることができる。例えば、スケジューラ３２２は、測定結果メガストア３４０からの警告を受信すると、無線アクセスネットワーク１２２に対して新しいセッション要求を送信することを停止することができる。

[0056] 他の是正アクションは、帯域幅を低減させること、あるいは所定のしきい値を超過しており、または１つもしくは複数の判断基準を満たしていない特定のＵＥとの通信を防止することを含むことができる。様々な実施形態においては、制約は、しきい値時間の後に、あるいは、ＵＥが所定のしきい値内であるという測定結果メガストア１４０からのメッセージを受信すると、引き上げられることもある。一例においては、制約は、判断基準が満たされる（例えば、ｅノードＢ３１９によってサービスされるアリーナにおけるスポーツイベントが、完了している）ときに引き上げられる可能性があり、これは、ＲＲＭモジュール４０２のｅノードＢを過負荷にするリスクを低減させる。

[0057] 図５は、測定結果メガストア１４０からの通知に基づいて、ｅノードＢと、ＥＵとの間の接続を調整するための例示のプロセスの流れ図である。図５の流れ図は、ネットワーク要素のタイプと、そのようなタイプの要素についての記憶された判断基準とを考慮する特定の例である。ステップ５０６において、ＲＲＭモジュールは、ローカルな知識に基づいて、ＵＥと、ｅノードＢとの間の無線信号品質を決定する。一実施形態においては、ステップ５０８において、ＲＲＭモジュールは、ローカルな知識に基づいて決定された無線信号品質に基づいて、適切な符号化フォーマットを決定する。

[0058] ステップ５１０において、ＲＲＭモジュールは、測定結果メガストア１４０と通信して、それからコンテキスト情報を受信する。このステップは、ＲＲＭモジュールから測定結果メガストア１４０への問い合わせとして実行され、または測定結果メガストア１４０に記憶される所定の判断基準に基づいて、測定結果メガストア１４０からＲＲＭモジュールへのプッシュ通知として、実行されることもある。

[0059] 図５の例においては、ＲＲＭモジュールは、様々なネットワーク動作をサポートして、測定結果メガストア１４０に対する問い合わせ（例えば、インターネット１２０の上で）を実行することができる。本例においては、ネットワーク動作は、ＵＥのための通信を開始し、また確立することである。様々な実施形態においては、ＲＲＭは、測定結果メガストア１４０に対して、ローカルな知識に基づいて、ＵＥデバイス識別子および／または無線信号品質の他のインジケータを送信することができる。それに応じて、ステップ５２０においては、測定結果メガストア１４０は、ＲＲＭモジュールが接続を確立するプロセスの最中であるＵＥのタイプが、低電力で機能することを意図しており、ｅノードＢとＵＥとの間の接続が低電力動作のために最適化されるべきであることを示すことができる。例えば、接続は、最少量の電力を使用する接続から利益を得ることができるＭ２Ｍ顧客にサービスしている可能性がある。このシナリオは、埋め込み個人用健康モニタリングデバイス、またはウェアラブル個人用健康モニタリングデバイスである医療用デバイスにとって重要である可能性がある。したがって、ステップ５２０においては、測定結果メガストア１４０によって提供されるコンテキスト情報は、ＵＥが、より最適化された（例えば、最少の）量の電力を消費するように、接続を調整するＲＲＭモジュールに対する通知（例えば、警告）または指示の形態とすることができる。

[0060] 別のシナリオにおいては、ローカルな知識に基づいて決定され、測定結果メガストア１４０に対して提供された無線品質のインジケータは、バッテリステータス（例えば、残り少なくなっている）を含むことができる。これに関して、インテリジェンスレイヤと協力する測定結果メガストア１４０は、以前に記憶されたユーザの設定から、ＵＥ（これは、今や電力が少なくなっている）は、可能な限りその持続時間を延ばすために、低電力モードで動作させられるべきであることを識別することができる。これに関して、インテリジェンスレイヤは、ｅノードＢと、ＵＥとの間の接続が、低電力のものであるべきであるという通知を（ステップ５２０において）ＲＲＭモジュールに対して発行することができる。したがって、測定結果メガストア１４０からの追加の入力なくして、ＲＲＭモジュールは、所定の条件が満たされる（すなわち、低電力で実行している）ときに、ユーザの設定が低電力動作を含むことを決定することはできないだろう。

[0061] それに応じて、ステップ５１２において、ＲＲＭは、より低い帯域幅の動作を含み得る最も大きな電力節約を提供する、ＵＥとの接続を提供するように符号化スキームを修正する。これによって、他の目的のために無線アクセスネットワーク１２２のリソースを解放することができる。例えば、インテリジェンスレイヤから受信される警告は、ｅノードＢにおいて「イベントハンドラ」をトリガして、いくつかの電力節約機能を実行する。

（無線アクセスネットワークのためのインテリジェントな自動的トラブルシューティング）
[0062] 上記で考察されるように、一態様においては、測定結果メガストア１４０を使用することにより、加入者レベルにおけるネットワークの問題の自動検出が、可能にされる。いくつかのシナリオにおいては、問題は、顧客がその問題について知るようになる前でさえも、識別される（また時として防止される）可能性があり、これは、顧客との関係を非常に改善している。この利点は、既存のアプローチの観点からよりよく理解されて、ネットワーク問題と、関連した顧客の不満とに対処することができる。例えば、加入者（例えば、顧客）が、ネットワークの問題を受けたときに、一般的には、非常に長くて退屈な、また時としてフラストレーションを引き起こすようなプロセスが関与しており、このプロセスは、一般的に、非常に人手がかかり、課題を識別し、また解決するために熟練したエンジニアの頻繁な介入を必要としている。

[0063] 例えば、顧客が、最初に、電話をかけ、また顧客ケア代表者に症状を説明する必要があり、この顧客ケア代表者は、所定の判断基準に基づいて、問題を分類する。内部レコードが生成されて、適切な熟練したエンジニアによって解析されることもある。エンジニアは、トラフィックボリュームと、ドロップしたコールの数と、ドロップしたコールの理由と、気がかりなノードについての全体の計算されたドロップコールレートとを含むコール信頼性レポートを作成することができる。いくつかの場合には、不満のうちのいくつかに対処することができる中間のエンジニアリングトリアージグループが存在するが、他の場合には、事例は、フィールドエンジニアに送信されて、問題の根源を調査する。無線アクセスネットワークの複雑さに起因して、フィールドエンジニアは、複数のシステムを調査して、フィールドエンジニアがネットワークのローカルな知識から実行することができる限られた解析に基づいて、何が問題の原因であり得るかを決定することができる。

[0064] 今日のセルラー方式ネットワークにおいて、各ネットワーク要素（例えば、ｅノードＢ）から収集されるかなりの量の性能データを有するデータソース数の増大により、エンジニアの課題はさらに悪化させられる。この性能データは、多くの場合に、数分、数時間、数日などの時間間隔の中で集約される。データは共に、キー性能インジケータ（KPI: key performance indicators）を提供し、これらのキー性能インジケータは、無線アクセスネットワークの全体の健全性をよりよく理解し、問題となる状況を検出し、またいつネットワークの一部分をアップグレードすべきかを決定するために、エンジニアによって検討される。さらに、既存のシステムにおいては、異種ソースからデータを集約することは、とりわけそれらが、異なる性質のものである場合には、難しい。例えば、１つのエリアにおけるドロップコールレートのトレンドを含むレポートは、解約率のトレンドと組み合わせることが容易ではない。そのような専用のレポートは、かなりの処理を必要としており、したがって、エンジニアにとって直ちに利用可能ではない可能性がある。データが、利用可能にされた後であっても、エンジニアは、依然として、大量のデータを手作業で解析する必要がある。この手作業での解析は、エンジニアが、複数のデータソースからトレンドを効果的に理解することができない可能性があるので、非効率であるだけでなく、不完全である可能性もある。結果は、一般的に、準最適な無線アクセスネットワーク性能である。

[0065] 対照的に、本明細書において説明されるシステムにおいては、ネットワークの状態の解析の大部分（すべてでない場合に）は、測定結果メガストア１４０を含むデータフレームワークによって自動的に実行される。実際に、問題の根本原因は、（防止されない場合には）顧客が問題について知るようになる前でさえも決定されることもある。そのようなオートメーションは、データ処理レイヤおよびインテリジェンスレイヤと共に、ネットワーク要素のローカルな知識に頼ることだけでなく、ネットワーク全体に関連したデータを使用することにより、および問題を自動的に治し、かつ／または通知を適切な代表者および／またはフィールドエンジニアに対して提供すること（例えば、それを報告すること）により、加入者レベルで問題を検出するように構成されている測定結果メガストア１４０によって可能にされる。

[0066] 一実施形態においては、多数の（例えば、数百万人の）加入者によって生成されているリアルタイムの、また大量の情報を受け入れるために、測定結果メガストア１４０は、Ｈａｄｏｏｐ、Ｓｔｏｒｍ、またはＳｐａｒｋなどの超並列処理技術を使用する。加えて、機械学習コンポーネントを使用して、所定のトレーニングセットに基づいて、パターンおよびトレンドを識別する。一実施形態においては、これまでに知られていない問題が、異なるクラスタリングモデルによって検出される。例えば、同じグループ（すなわち、クラスタ）の中のオブジェクトは、他のグループ（すなわち、クラスタ）の中のオブジェクトに比べて、互いにより類似しているように、データはグループ分けされる。

[0067] 図６は、例示の一実施形態と整合した、データフレームワークのブロック図である。図６のデータフレームワークは、上記で考察された図３のデータフレームワークに類似しているが、無線アクセスネットワークの自動的トラブルシューティングの考察を容易にするために、明確にするために再び示されている。図６のデータフレームワークは、データ処理レイヤ６８２と、プログラマブルなパターン検出ルール６８８を含むことができるインテリジェンスレイヤ６８４と、問題のタイプ６９０に基づいて、プログラマブルなアクションの組を記憶するように構成されているオートメーションレイヤ６８６と、測定結果メガストア６８０とを含む。

[0068] データ処理レイヤ６８２によって受信される情報のタイプは、他の要素：顧客ケアのトラブルチケットデータベースからのデータ；ネットワーク要素カウンタおよびＫＰＩ；ネットワーク要素（UE）ロケーション；警告情報および故障情報；加入者プラン、利用（例えば、報告書／データ）、課金アドレスなどを含む加入者情報；ハンドセットタイプ、ＯＳ、アプリケーション、バッテリステータスなどを含むハンドセット情報；ジオロケーショントレース、無線トレース、コアネットワークトレース、およびＩＰレベルトレースを含む加入者の詳細情報レコード；Ｗｉ－Ｆｉレコードおよびメトリクスなどを含むことができる。データ処理レイヤ６８２は、リアルタイムで、かつ／またはバッチで実行されることもある。モニタリングは、絶え間なく、２４時間体制で、所定の間隔で、またはモニタリングシステムのインテリジェンスレイヤ３８４からのトリガに応じて、実行されることもある。したがって、データ処理レイヤ６８２は、詳細な加入者トレースを監視し、またドロップしたコール、アクセス障害、インターネット接続性に伴う問題などの故障状況を記録する。このデータは、様々なネットワーク要素によって使用され得るコンテキスト情報として、他のネットワーク要素からのデータと共に、測定結果メガストア６８０に記憶される。

[0069] インテリジェンスレイヤ６８４は、データ処理レイヤ６８２からの情報と、インテリジェンスレイヤ６８４においてあらかじめプログラムされていることもあるパターン検出ルール６８８とを受信するように構成されている。一実施形態においては、インテリジェンスレイヤ６８４は、異なるタイプの故障についての異なるインテリジェンスモデルを含むことができる。インテリジェンスレイヤ６８４は、問題についての起こりそうな原因、ならびにエラー検出についての精度（エラー）の推定を識別するように、構成されている。一実施形態においては、検出の精度は、エラーの発生の頻度に基づいている。

[0070] 例えば、メンテナンスを受けていることをインテリジェンスレイヤによって識別されているエリア、またはカバレッジ不足が知られているエリアにおいて、顧客が悪化した性能（切断、アクセス障害など）を経験している可能性があるときに、精度の推定値は高くなることができる。インテリジェンスレイヤは、顧客トレースと、ネットワーク健康インジケータと、ＵＥレポートなどとを検討することにより、さらに、精度を改善することができる。データの異種ソースから、インテリジェンスレイヤ６８４は、切断が、（１）カバレッジに起因するものか、（２）干渉に起因するものか、（３）ハードウェア障害に起因するものか、（４）ソフトウェア障害に起因するものかなどを識別することができる。

[0071] オートメーションレイヤ６８６は、データ処理レイヤ６８２によって取り出される生データについての先行した人間の処理に頼ることなく、識別されたネットワークエラーに対する自動的応答をトリガすることができる。一実施形態においては、識別された問題のための適切なアクションは、インテリジェンスレイヤにおいて、またはネットワーク要素ノードにおいて、システムアドミニストレータによってあらかじめプログラムされる。アクションは、識別された問題と、可能性のある問題解決手法とを用いて、ノードについてリセットすること、またはフィールドエンジニアに対してメモを送信することとすることができる。他の場合には、自動化されたアクションは、問題の原因（例えば、エリアにおいて進行中のメンテナンス作業がある）について彼らに通知し、または自動的なクレジットを提供して、悪化された性能について補償し、またその同じことについて加入者に通知するメッセージを加入者に対して送信することとすることができる。

[0072] 一例においては、複数の加入者が、１つのエリアにおいて実質的に類似した問題の影響を受ける場合に、オートメーションレイヤ６８６は、そのエリアにおけるすべての加入者に対してメッセージを自動的に送信して、加入者がその問題によって影響を及ぼされる前に、予防的に問題を治すことができる。別の言い方をすれば、第１のネットワーク要素のエリアにおける他のネットワーク要素のグループが、所定の条件を満たす、または所定のしきい値を超過すると決定すると、そのグループにおけるすべてのネットワーク要素に対して、通知が自動的に送信される。一実施形態においては、第１のしきい値を下回る精度を用いて識別されるネットワークエラーは、第２のしきい値を上回る精度を用いて識別されるネットワークエラーとは異なるように取り扱われる。一実施形態においては、第１のしきい値と、第２のしきい値とは、同じ値を有する。例えば、低い精度のものであるように見なされるエラーが検出されている場合には、自動的アクションは、問題についての精度および／または加入者コールを改善する追加のデータが受信されるまで、実行されなくてもよい。しかしながら、エラーが高い精度で識別される場合には、自動的な即時改善策が着手される。

[0073] 例えば、インテリジェンスレイヤ６８４と協力しているオートメーションレイヤ６８６は、特定の加入者が期待されたサービス品質を受信していないと決定すると、緩和するアクションを提案することができる。カバレッジ問題の場合には、インテリジェンスレイヤは、Ｗｉ－Ｆｉコーリングを使用するオプションがあるかどうかを決定することができる。これに関して、オートメーションレイヤ６８６は、加入者とケア代表者とに対して通知を送信して、Ｗｉ－Ｆｉコーリングのアクティブ化を可能にすることができる。

[0074] 図７は、自動的な根本原因の識別のための例示のモデルを示す。具体的には、図７は、ドロップしたコールについてのありそうな根本原因についての情報を記憶する確率ツリーを示す。データの大きなコーパスに基づいて、機械学習アルゴリズムは、ドロップしたコールなどのイベントが、特定の原因に相互に関連づけられた確率を決定することができる。同様にして、特定の原因は、それ自身の異なる可能性のある原因を有することができ、可能性のある原因のそれぞれは、自身の確率を有する。最終的に、根本原因の確率を把握することができる。

[0075] 図７において、我々は、ドロップしたコールのイベント７０２を有する確率ツリーの最上部から開始する。あらゆるイベントが、確率Ｐ（イベント）に関連づけられる。例えば、検出されたネットワークイベントが、ドロップしたコールである確率は、Ｐ（はい）＝０．１５（または１５％）として示される。検出されたネットワークイベントが、何らかの他のイベントである確率は、Ｐ（いいえ）＝０．８５である。

[0076] 次いで、確率ツリーをトラバースして、最も可能性の高い根本原因を決定することができる。そのようにするために、確率ツリーを、ドロップしたコールイベント７０２についての可能性のある直接的な原因を表すノードにトラバースする。これらは、無線干渉７０４、不十分なカバレッジ７０６、ハードウェア障害７０８、ソフトウェア障害７１０、または他の障害７１２を含むことができる。ドロップしたコールイベントと同様に、各原因は、確率に関連づけられる。これらの原因は、可能性のある原因であるので、それらの確率は、条件付き確率Ｐ（条件｜イベント）として表現される。例えば、ドロップしたコールが、ハードウェア障害７０８によって引き起こされた確率は、Ｐ（ＨＷ｜ＤＣ）＝０．２として示される。同様に、ドロップしたコールが、ソフトウェア障害７１０によって引き起こされた確率は、Ｐ（ＳＷ｜ＤＣ）＝０．３として示される。

[0077] 原因ノードは、ひいては、それら自体のそれぞれの原因を有することができる。例えば、無線干渉７０４と、不十分なカバレッジ７０６とは、同じ原因７１４を有することができる。ハードウェア障害７０８は、物理的エラー７１６と、ユーザ機器の間違った構成７１８として、ここで示される異なる可能性のある原因を有することができる。この場合にも、各ノードは、それぞれの確率に関連づけられ、また可能性のある原因として、各確率は、条件付き確率として表現される。ここで、ハードウェアの中の物理的エラー７１６が、ハードウェア障害を引き起こした確率は、Ｐ（ＰＨ｜ＨＷ）＝０．１として示される。間違って構成されたハードウェアがハードウェア障害を引き起こした確率７１８は、Ｐ（ＭＣＧ｜ＨＷ）＝０．６として示される。

[0078] ソフトウェア障害７１０もまた、間違った構成７１８によって引き起こされる可能性もあることに留意されたい。たとえ確率ツリーが、ハードウェア障害７０８からトラバース可能でもあるノードにトラバースするとしても、間違った構成のノード７１８は、Ｐ（ＭＣＧ｜ＳＷ）＝０．３として示されるようなソフトウェア障害７１０の原因としてそれ自体の確率を有する。ソフトウェア障害７１０は、Ｐ（ＷＶＥＲ｜ＳＷ）＝０．５という原因の条件付き確率を用いて、インストールされるソフトウェアの誤ったバージョン７２０を有することにより、引き起こされる可能性もある。

[0079] 同様に、他の原因７１２は、それら自体のそれぞれの原因７２２を有することもできる。

[0080] 確率ツリーは、一般に、データの統計的にかなりのコーパスを受信することを経由して、ポピュレートされる。次いで、データは、確率ツリーに適用されて、確率ツリーの中の確率を計算する。

[0081] 診断を実行するときに、確率ツリーは、原因および／またはＫＰＩのリーフノード７２４、７２６、７２８、７３０、７３２から開始する。観察されるネットワークデータに応じて、原因および／またはＫＰＩのリーフノード７２４、７２６、７２８、７３０、７３２の確率は、更新される。例えば、間違った構成が、実際に観察される場合に、間違った構成７２８の確率は、１００％に変更される。原因７２４が、観察されない場合に、その確率は、０％に変更される。確率は、２進数、すなわち、１００％または０％だけである必要はない。中間の（非０％、非１００％）の確率は、データのサンプリングまたは移動平均に基づいて、計算されることもある。

[0082] 原因および／またはＫＰＩのリーフノード７２４、７２６、７２８、７３０、７３２が更新された後で、親ノードの確率は、ベイズアルゴリズムに従って更新される。したがって、親ノード７１４、７１６、７１８、７２０および７２２の条件付き確率は、条件が満たされたかどうかについての決定として、子ノードを使用して更新される。親ノード７１４、７１６、７１８、７２０および７２２の確率は、次いで更新される。このプロセスは、ルートノード７０２が、到達されるまで、上記の親ノードのレベルについて、反復される。このポイントにおいて、確率ツリーの中のすべての確率が、観察された原因および／またはＫＰＩの７２４、７２６、７２８、７３０、７３２を考慮して、更新されている。

[0083] ルートノード、ドロップしたコール７０２の可能性のある根本原因は、更新された確率が所定のしきい値を超過しているすべての子ノードを選択することにより、ユーザに明るみに出されるであろう。

[0084] 解析を終了した後に、確率ツリーは、その元の状態と、元の確率へと戻される。

[0085] しかしながら、時間と共に、履歴データは、収集され、またアドミニストレータによる合意の直後に、履歴データの少なくともサブセットが、確率ツリーに適用されて、確率ツリーの中の確率を恒久的に更新することができる。次いで、後続の解析は、更新された確率ツリーを使用することになる。このようにして、確率ツリーは、履歴データから学習する。

[0086] 機械学習におけるこの特定のアプローチは、１つのオプションにすぎないことを強調すべきである。他のよく知られているオプションは、エントロピーベースのツリーと、ナイーブベイジアンツリーとを含む。ベイジアンベースのツリーに特有の１つの利点は、原因および／またはＫＰＩのドメインが、確率の再計算を強制することなく、サブドメインへと区分化され得ることである。それに応じて、確率ツリーは、アドミニストレータによって望まれるように、ネットワークの異なるサブセットについて区分化されることもある。

[0087] 図８は、無線アクセスネットワーク性能を維持する際にエンジニアを支援するための例示のプロセスの流れ図である。ステップ８０２において、測定結果メガストアに記憶されるデータは、様々なソースから共通データフレームワークへと自動的に収集される。ステップ８０４において、パターン認識が、１つまたは複数のクラスタリングアルゴリズムによってデータに対して実行される。一実施形態においては、ステップ８０６において、解析されるべきキーメトリクスは、測定結果メガストアにおいてあらかじめプログラムされ、またはオペレータによりユーザインターフェース９００（図９参照）を経由して測定結果メガストアに対して対話的に提供される。ユーザインターフェース９００は、図１の測定結果メガストア１４０に対して直接に、またはワイヤレスで、通信するように結合される端末もしくはハンドヘルドデバイスの上のソフトウェアアプリケーションを経由したものとすることができる。様々な実施形態においては、エンジニアは、ネットワーク要素（例えば、地理的／ノードのレベル）においても、またＫＰＩレベルにおいても、実行されるべき解析のタイプと、報告されるべき詳細のレベルとを選択する（例えば、９０４）ことができる。

[0088] 測定結果メガストアが検出することができる無制限の数のパターンがある。例えば、高い解約率を有するエリアは、加入者のほとんどが、狭い地理的エリアに集中していることを示すことがある。低下した性能を経験するセクタは、特定の期間において多数のリセットを示すことがある。顧客ケアに電話する多数の顧客は、所定の限界値を超過しているボイスメールに直接にルーティングされているコールの数を示すことができる。所定のしきい値内であるドロップコールレートを示すエリアは、顧客が所定の時間内に再ダイアルする必要があり、限界値を超過した（これは不十分なコール品質を示すことができる）いくつかの例を示すことができる。セクタは、限界値を下回るトラフィックを搬送するにもかかわらず、混雑状態を示す可能性がある。しきい値数の顧客は、ネットワークアップグレード後に、それらのカバレッジ縮小を経験する可能性がある。もちろん、数え切れない他のシナリオが、サポートされる。

[0089] ステップ８０８において、それらが学習されるときに、関連のあるパターンが、例えば、測定結果メガストア１４０のメモリの中に存在し続ける。一実施形態においては、測定結果メガストア１４０は、ユーザインターフェース９００の上でエンジニアに対して、最も関連のあるパターンを含む解析結果を表示する。別の実施形態においては、自動化された解決策に関連するパターンは、これらの自動化された解決策の実行をトリガすることができる。

[0090] 一実施形態においては、ステップ８１０において、エンジニアは、測定結果メガストアの解析結果を格付けすることができる。これに関して、図９００は、例として、エンジニアによって使用されて、１から５までの星印９０６の選択により、測定結果メガストアの解析（例えば、発見）の適合性を格付けすることができるインターフェースを示す。様々な実施形態においては、エンジニアが確認してネットワークの課題を治した後に、またはユーザインターフェース９００の上の最初の表示の直後に、選択を実行することができる。

[0091] 一実施形態においては、ステップ８１０において、エンジニアは、自動的なＫＰＩおよび／または通知が、解析に基づいて発行されることを要求することができる。ＫＰＩは、測定結果メガストアに記憶され、また基準として使用される可能性がある。ＫＰＩと通知とを使用して、いつエリアが解約レベルを増大させる可能性が高くなるかなどのイベントを予測することができる。

[0092] 一実施形態においては、ステップ８１２において、上記で説明されるシステムは、トレーニングされる可能性があり、ここではシステムは、従来の類似の状況に基づいて、従来の解析を自動的に反復し、また所定の間隔で、または特定のエラーが識別されるときに、絶え間なく類似したＫＰＩおよび／または警告を生成する。一例においては、本明細書において説明されるシステムのインテリジェンスレイヤは、自己組織化ネットワーク（SON: self-organizing network）と組み合わされて、自動的プランニングと、構成と、管理と、最適化と、無線アクセスネットワークの回復とを実行することができる。

（医療用分野における例示の使用事例）
[0093] 上記で考察されるように、一態様においては、本明細書において説明されるシステムは、オープンプラットフォームを提供しており、ここでは異種ソースからの複数のデータフィードが、組み合わされ、またリアルタイムで処理される可能性がある。従来の考察の多くは、ネットワーク管理におけるアプリケーションに向けられている。しかしながら、本明細書において説明される技法は、イベントデータのストリームがある任意の分野に適用され得る学習とフィードバックループとを提供しており、ここではイベントデータは、原因と相互に関連づけられることもあるカテゴリに分類される可能性がある。確率ツリーが構築され得る場合には、従来の技法が適用される可能性がある。

[0094] この能力が特に有用である場合の１つの例示の代替的な分野は、医療用分野におけるものであり、この医療用分野は、ＵＥ１０２ｄなどの健康モニタをますます使用しており、この健康モニタは、健常者と、病人との両方によって着用されて、着用者の医療用の健康状態を監視することができる。今日では、１つまたは複数のそのような健康モニタが、着用されて、ユーザ（時として、患者または加入者と本明細書において称される）についての、あるレンジの医療用解析を提供することができ、また適切な介護者に対して提供されて、１つまたは複数の健康モニタから関連のある情報を抽出することができる。

[0095] これらの健康モニタは、埋め込まれたり、手首の上に着用されたり、ネックレスとして首の周囲に着用されたり、胸の周囲にストラップされたりなど様々な形態で登場することができる。これらのモニタは、心拍数、心拍リズム、血圧、運動、酸素飽和度、体温、血糖値など、様々な健康機能を監視することができる。従来、各健康モニタは、分離して動作する。例えば、心拍数を測定する健康モニタは、血糖値または運動を測定する健康モニタから相互に排他的である。獲得されるデータポイントは、そのときに、ユーザディスプレイの上で患者に対して直接に提供されるか、またはそれぞれ、健康モニタのメモリに記憶されて、後で１人または複数人の介護者によって読み取られるかのいずれかである。いくつかの場合には、獲得されたデータは、１人または複数人の介護者における異種レシーバに対して、定期的に、あるいはユーザからのトリガの直後に、送信される。各健康モニタは、一般的に、介護者によって疑われる健康疾患に応じて、適用される。それに応じて、従来のシステムにおいては、疑われていない健康状態を識別する、健康モニタからの情報の合成を提供した絶え間ないモニタリングは、利用可能ではない。

[0096] 対照的に、本明細書において説明されるシステムは、絶え間ないモニタリングおよび／または各健康モニタからの監視されたデータの絶え間ない送信を実行することができ、この監視されたデータは、中央集中化されたリモート健康モニタリングシステム１５０において、合成される可能性がある。異種ソースから取り出される合成された情報は、可能性のある疾患についてのデータを解析し、また関連のある通知を提供するように構成されている。

[0097] 次に図１０を参照すると、この図１０は、例示の一実施形態と整合した、リモート健康モニタリングを含むシステムの高レベル図を示す。システム１０００において、ＵＥ１００２（１）から１００２（Ｎ）までによって表される１つまたは複数の健康モニタは、ユーザ１００４の健康の様々な様相を監視するように動作する。健康モニタ１００２（１）から１００２（Ｎ）までは、アプリケーションサーバ１、２（１０３０、１０３２）と、ＵＥ収集システム１からＮまで（１０３４（１）から１０３４（Ｎ）まで）によってシステム１０００の形で表される１つまたは複数の異種モニタリングシステムに対して健康情報を提供することができる。例えば、アプリケーションサーバ１、２（１０３０、１０３２）と、ＵＥ収集システム１からＮまで（１０３４（１）から１０３４（Ｎ）まで）とは、対応する健康モニタから測定結果の健康に関連したレコーディングを提供するサードパーティシステムと見なされることもあり、これらの健康モニタは、Ｓａｍｓｕｎｇ（登録商標） Ｇｅａｒ ＷａｔｃｈまたはＡｐｐｌｅ（登録商標） ｉＷａｔｃｈ（登録商標）の形態とすることができる。

[0098] 健康情報は、様々なネットワークによって提供されることもある。例えば、いくつかの健康モニタは、１つの無線アクセスネットワーク１０２２（ａ）の上で、それらのモニタリングシステムと通信することができるが、他の健康モニタは、別の無線アクセスネットワーク１０２２（ｂ）の上で通信することができる。一実施形態においては、健康モニタは、スマートフォン、タブレットなど、ネットワーク１０２２（ａ）の上で通信するように構成されているデバイスを使用することにより、無線アクセスネットワーク１０２２（ａ）の上で彼らのそれぞれの（例えば、加入された）モニタリングシステムと通信することができる。一実施形態においては、健康モニタ１００２（１）から１００２（Ｎ）までは、健康情報を直接に健康モニタリングサーバ１５０に対して提供する。

[0099] 一態様においては、例示のシステム１０００は、物理的セーフガードと技術的セーフガードとが、リモート健康モニタリングサーバに対するアクセスを認可された個人とアカウント保持者とだけに制限するために含められた医療保険の相互運用性と説明責任に関する法令（HIPPA: Health Insurance Portability and Accountability Act）に準拠している。一例においては、固有のユーザＩＤと、自動的ログオフプロシージャと、暗号化と、暗号解読とが、システム１０００にアクセスするために必要とされる。

[00100] 一態様においては、リモート健康モニタリングサーバ１５０は、測定結果メガストアとしての役割を果たし、またオープンプラットフォームを提供しており、ここでは異種サーバ１０３０、１０３２からの複数のデータフィードと、収集システム１０３４（１）から１０３４（Ｎ）までとが、組み合わされる。健康データは、データ処理レイヤにより、ユーザ１００４のような多数（例えば、数百万人）の個人について、リアルタイムで処理され、このデータ処理レイヤは、健康モニタリングサーバ１５０の一部分とすることができ、またはそれと通信していることもある。加えて、リモート健康モニタリングサーバ１５０は、病院１０４０と、介護提供者１０５０とから、患者記録などのデータを収集することができる。そのようなデータは、病歴、前治療、記録された血液検査などを含むことができる。加えて、リモート健康モニタリングサーバは、無線アクセスネットワーク（例えば、１０２２（ａ）、１０２２（ｂ））からデータを収集して、ユーザ１００４のロケーション情報を決定し、データ送信を防止する可能性があるネットワークの問題と、ネットワーク接続性および顧客エンドポイントに影響を及ぼす他の変数とを識別することができる。様々な実施形態においては、ユーザ１００４のロケーションは、健康モニタ（例えば、１００２（１）から１００２（Ｎ）まで）、またはその対応するＵＥ（例えば、１００６）によって提供され得る、三角測量、マルチラテレーション、および／またはＧＰＳ座標など、様々な技法によって決定されることもある。

[00101] 異種モニタからのデータは、パターンとトレンドとについて解析される。１つまたは複数のしきい値が超過される、あるいは１つまたは複数の判断基準が満たされることを決定すると、リモート健康モニタリングサーバ１５０は、対応する健康モニタ（例えば、ＵＥ１００２（１））または対応するＵＥネットワーク可能デバイス１００６のユーザインターフェースに対する通知を経由して通知をユーザ１００４に対して送信することができる。一実施形態においては、健康モニタサーバ１５０は、状態のタイプに基づいて、関連のある介護提供者１０５０および／または病院に対して通知を送信することができる。

[00102] 図１１は、例示の一実施形態と整合した、モニタリングシステムのデータフレームワークのブロック図である。システム１１００の中のデータフレームワークは、超並列処理方法を使用して、１つまたは複数の健康モニタ（ＵＥの）から健康データをリアルタイムで収集する。考察を容易にするために、オートメーションレイヤ１１０８と、インテリジェンスレイヤ１１０４と、データ処理レイヤ１１０２とは、測定結果メガストア１１１０から分離しているように示されるが、様々な実施形態においては、これらの機能は、単一プラットフォーム（すなわち、データ処理レイヤと、インテリジェンスレイヤと、オートメーションレイヤとの機能を実行する単一の測定結果メガストア）の上で組み合わされることもあることが、理解されるであろう。

[00103] データフレームワークは、データ処理レイヤ１１０２と、パターン検出ルール１１０６を含むことができるインテリジェンスレイヤ１１０４と、オートメーションレイヤ１１０８と、測定結果メガストア１１１０とを含む。データ処理レイヤ３５２によって受信される情報のタイプは、ＷＥＢからの関連のある情報を含めて、ＵＥおよび／または無線アクセスネットワークによって提供される加入者無線トレース（例えば、ロケーション）情報と、１つまたは複数のソースからの医療レコード情報と、顧客ケアレコード情報と、課金情報と、アプリケーション性能モニタリングレポート情報と、他の情報とを含むことができる。データ処理レイヤ１１０２は、リアルタイムで、かつ／またはバッチで実行されることもある。モニタリングは、絶え間なく、２４時間体制で、所定の間隔で、あるいはモニタリングシステムのインテリジェンスレイヤ１１０４からのトリガに応じて、実行されることもある。

[00104] インテリジェンスレイヤ１１０４は、データ処理レイヤ１１０２からの情報と、インテリジェンスレイヤにおいてあらかじめプログラムされ得るパターン検出ルール１１０６とを受信するように構成されている。一実施形態においては、検出は、従来の知識に基づいて、エキスパートの専門家によって最初にプログラムされていることもある。インテリジェンスレイヤの自己学習機能は、その特定の問題についての事前知識なしに異常状態を検出するように動作している。具体的には、ドロップしたコールなどの望ましくないイベントが発生するときに、原因および／またはＫＰＩが存在すると検出されることもある。図７に関して説明されるように、確率ツリーは、ポピュレートされ、かつ／または更新されて、これらの原因および／またはＫＰＩが、望ましくないイベントと相互に関連づけられる確率を記憶することができる。一実施形態においては、パターン検出ルール１１０６は、患者のタイプ（例えば、白血病対糖尿病）に応じて異なる。例えば、健康医学的状態と整合しているパターンを識別すると、健康モニタリングシステムは、その医学的状態に関連した健康データについてのより多くの解析を実行することにより、そのルールセットを更新して、その状態に焦点を当てることができる。したがって、パターン検出ルール１１０６は、加入したユーザごとに異なる可能性がある。

[00105] 特定の状態を検出するために、データ処理レイヤ１１０２において処理された複数のデータソースは、解析され、また相互に関連づけられて、１つまたは複数の条件が満たされるかどうかを決定することができる。具体的には、第１の検出された原因および／またはＫＰＩは、それらが、場合によっては、ドロップしたコールなど検出された望ましくないネットワークイベントについての根本原因である可能性があるかどうかを確率ツリーに対して（図７に関する考察を参照）、チェックされる。次いで、確率ツリーを、検出された原因および／またはＫＰＩから出発してトラバースする。確率ツリーは、検出された原因および／またはＫＰＩが、イベントを引き起こした確率を記憶するので、確率ツリーを、最も可能性のある経路に従ってトラバースすることができる。このようにして、望ましくないネットワーク条件についての状態が、特定の原因および／またはＫＰＩ（および確率ツリーにおける経路に沿った他のイベント／原因）が、実際にこれらの望ましくないネットワーク状態を引き起こした可能性について評価される可能性がある。

[00106] したがって、インテリジェンスレイヤ１１０４は、絶えず、データを通してシフトして、異種データソースの内部のパターンを識別する。所定の条件が満たされると、インテリジェンスレイヤは、ユーザ６０４、介護提供者６５０、測定結果メガストア１１１０のデータベースに前もって記憶された連絡担当者、および／または救急サービスのうちの少なくとも１人に対する関連のあるアラートを生成することができる。例えば、インテリジェンスレイヤ１１０４は、個別のタイプの測定結果（血圧）についてのデータのパターンを解析し、またはデータ処理レイヤ３５２によって提供される異なるタイプの測定結果またはデータ（例えば、血糖値、体重、年齢、白血球など）と、測定結果メガストア１１１０からの家族歴とを相互に関連づけて、患者に伴う健康上の懸念を示す可能性がある任意の異常値（例えば、所定の条件を満たしており、または所定のしきい値を超過している）を識別することができる。

[00107] それに応じて、オートメーションレイヤ１１０８は、データ処理レイヤによって取り出される生データの従来の人間の処理に頼ることなく、患者６０４の識別された状態に対して自動的な応答をトリガすることができる。別の言い方をすれば、オートメーションレイヤ１１０８と結合されたインテリジェンスレイヤは、加入者（すなわち、患者）レベルで、健康上の問題を検出し、また加入者または医療提供者が、加入者に伴う健康上の問題を疑ってさえもいることなしに、通知を提供することができる。認可された介護者、医師、家族および友人、または緊急対応者は、測定結果メガストア１１１０に記憶されるユーザプロファイルに記憶された設定に基づいて、自動的に連絡を受けることができる。例えば、医者２１１ａは、緊急の医療用アドバイスを提供することができる。適切なエンティティは、測定結果メガストア１１１０のアプリケーションサーバのオートメーションレイヤ１１０８を経由して、自動的に連絡を受けることができる。適切なエンティティは、無線アクセスネットワーク１２２を通して、公衆交換電話網（PSTN: public switched telephone network）（図示せず）を通して、またはインターネット接続（図１における１２０）を通して、連絡を受けることもできる。一例においては、受信するエンティティに応じて、異なる情報が送信される。例えば、家族／友人が、連絡を受ける場合、ロケーション情報と、緊急事態のタイプとを送信することができる。対照的に、医師が連絡を受ける場合、ロケーション情報、緊急事態のタイプ、生命徴候、医療履歴などが送信される。したがって、助けを求めるために様々なエンティティが連絡を受ける可能性があるが、特別に認可されたエンティティだけが、ロケーション情報を受信する。一例においては、ロケーション情報を使用して、健康モニタ（例えば、図１における１０２ｄ）に最も近い薬局に対して処方箋情報を送信する。

[00108] 図１２は、測定結果メガストアから受信されるコンテキスト情報を使用して、健康状態を識別するための例示のプロセスの流れ図である。１つまたは複数の健康モニタを着用している加入者（この人は、健康であると信じている）のことを考える。例えば、それらの健康モニタは、電子フィットネスブレスレットと、温度／湿度とを測定することができる電子ネックレスと、加入者が休息しているときにベッドの上に置かれているスマートフォンとすることができる。さらに、加入者は、スマートフォンのアプリケーションに対して、電話を彼のベッドの上に置くことにより、アプリケーションに加入者の睡眠パターンを監視させることを示す。

[00109] ステップ１２０４において、測定結果メガストアは、３つのすべてのセンサから連続した情報を受信することができる。例えば、スマートフォンは、その全地球測位システム（GPS: global positioning system）からのロケーション情報と、その加速度計からの運動情報とを提供することができ、電子フィットネスブレスレットは、その加速度計からの心拍数と、運動情報とを提供することができ、また電子ネックレスは、加入者の体温の測定値を提供することができる。様々な実施形態においては、健康情報は、上記の図６との関連で考察されるように、異なる無線アクセスネットワークと、収集システムとの上で測定結果メガストアによって受信されることもある。とりわけ、健康情報は、測定結果メガストアを含むデータフレームワークのデータ処理レイヤによって受信されることもある。

[00110] ステップ１２０６において、測定結果メガストアのインテリジェンスレイヤは、健康情報を解析して、高いレベルの運動があるかどうかを決定する。例えば、インテリジェンスレイヤは、フィットネスブレスレットからの運動情報をスマートフォンからの情報と相互に関連づけることができる。いずれのソースも高いレベルの運動がないことを示す場合には、インテリジェンスレイヤは、睡眠時無呼吸に関連した健康上の問題がないことを結論づける（すなわち、ステップ１２１０）。しかしながら、ソースのうちの一方が、第２のソースによって確認されない高いレベルの運動を示す場合には、インテリジェンスレイヤは、ＷＥＢを調べて、スマートフォンが、より正確な加速度計を有しているか、またはフィットネスブレスレットが、より正確な加速度計を有しているかを決定し、また運動に関するその解析をこの測定についてのより正確なフィットネスモニタに基づいたものにすることができる。

[00111] 測定結果メガストアのインテリジェンスレイヤが、高いレベルの運動を識別する場合、インテリジェンスレイヤは、次いで、高い心拍数があるかどうかを決定する。その目的を達成するために、ステップ１２０８において、インテリジェンスレイヤは、フィットネスブレスレットから取得される健康情報を解析する。一実施形態においては、インテリジェンスレイヤは、ＷＥＢ（またはルックアップテーブル）および／または他の以前に記憶されたデータを調べて、この加入者についての高い心拍数で何が考えられるかを決定することができる。例えば、記憶された情報は、加入者の体重、身長、および年齢と、心拍数に影響を及ぼす可能性がある以前の医学的状態（例えば、ペースメーカー）とを示すことができる。心拍数がこの加入者について高いと考えられない場合には、インテリジェンスレイヤは、睡眠時無呼吸に関連した健康上の問題がないことを結論づける（すなわち、ステップ１２１０）。

[00112] 心拍数が高いと決定される場合、ステップ１２１２において、インテリジェンスレイヤは、オートメーションレイヤと相互作用して、状態の深刻さ、または加入者の所定の個人用設定に応じて、１つまたは複数の受信側（例えば、スマートフォン、フィットネスブレスレット、認可された介護者、医師、家族および友人、および／または緊急対応）に対して通知を提供する。例えば、加入者は、彼らが睡眠時無呼吸を患っている可能性があることを示す通知を彼らのスマートフォンの上で受信することができる。オートメーションレイヤはまた、医学的状態をよりよく解析するように、１つまたは複数の追加の健康モニタに推奨することができ、これらの追加の健康モニタは、後続の測定において使用されることもある（すなわち、ステップ１２１４）。

（例示のコンピュータプラットフォーム）
[00113] 上記の考察によって示されるように、コンテキスト情報を記憶するための機能と、モニタリングネットワーク要素と、加入者の健康のリモートモニタリングと、ローカルな知識に基づいてネットワークステータスを識別する工程と、ネットワーク要素の間の接続を提供する工程と、他の機能とは、図１および２に示されるように、モニタリングサーバ１３０と、測定結果メガストア１４０と、ｅノードＢ１１９と、無線アクセスネットワーク１２２のコンポーネントとして動作する、無線アクセスネットワーク１２２のネットワーク要素を経由して、データ通信のために接続されるコンピュータの上で実装される可能性がある。専用のデバイスが使用されることもあるが、そのようなデバイスはまた、「サーバ」プログラミングを実行するために一般的に使用されるデータ処理デバイスの一般的なクラスを表すことを意図している１つまたは複数のハードウェアプラットフォームを使用して、実装されて、上記で考察されるように、データ通信のための適切なネットワーク接続にもかかわらず、異種ソースからデータを受信する工程と、コンテキスト情報を取り出す工程と、所定の条件が満たされるか、または所定のしきい値が超過されるかを決定するために情報を解析する工程と、通知を提供する工程と、を実装することができる。

[00114] 図１３および１４は、汎用コンピュータハードウェアプラットフォームの機能ブロック図の説明図を提供するものである。図１３は、サーバを実装するために、一般的に、使用され得るようなネットワークまたはホストコンピュータプラットフォームを示す。図１４は、図１のコンピュータ１０２ｃやワークステーションなどのパーソナルコンピュータを実装し、あるいはポータブルハンドセット、スマートフォン、タブレットコンピュータ、携帯型個人情報端末、他のタイプの移動局またはモバイル端末デバイス（例えば、図１のデバイス１０２ａから１０２ｄまで）などのコンピューティングデバイスを実装するために使用され得るような、ユーザインターフェース要素を有するデバイスを示すが、図１４のデバイスはまた、適切にプログラムされる場合に、サーバとしての役割を果たすこともできる。図１３および１４に示されるようなそのような機器の汎用構造および汎用動作は、高レベルの説明図から自己説明されるはずであることが、信じられている。

[00115] 例えば、サーバとして構成された汎用コンピュータは、パケットデータ通信のためのデータ通信インターフェースを含む。サーバコンピュータはまた、プログラム命令を実行するための、１つまたは複数のプロセッサの形態の、中央演算処理装置（CPU: central processing unit）を含む。サーバプラットフォームは、一般的に、内部通信バスと、プログラムストレージと、様々なデータファイルが、サーバによって処理され、かつ／または通信されるためのデータストレージとを含むが、サーバは、多くの場合にネットワーク通信を経由してプログラミングおよびデータを受信する。そのようなサーバについてのハードウェア要素と、オペレーティングシステムと、プログラミング言語とは、本来は、従来型のものである。本明細書において使用される場合、図１４のコンピュータシステムは、Ｈａｄｏｏｐ、Ｓｔｏｒｍ、Ｓｐａｒｋなどの超並列処理技術を使用している。もちろん、サーバ機能は、いくつかの類似したプラットフォームの上で分散型の様式で実装されて、処理負荷を分散させることができる。様々な他の実施形態においては、モニタリングサーバ１３０の機能と、測定結果メガストア１４０と、リモート健康モニタリングシステムとは、１つまたは複数のサーバプラットフォームの形で組み合わされることもある。

[00116] ソフトウェア機能は、実行可能コード、ならびに関連する記憶されたデータ、例えば、コンピューティングデバイスの上のアプリケーションが、処理レイヤによって異種ソースからデータを受信するために使用されるファイルを含めて、測定結果メガストアからコンテキスト情報を取り出し、異種ソースからのデータとそのコンテキスト情報とを解析し、また通知を提供するプログラミングを必要とする。ソフトウェアコードは、コンピューティングデバイスによって、実行可能である。動作中に、コードは、コンピューティングデバイスの内部に記憶される。他の時間には、しかしながら、ソフトウェアは、他のロケーションに記憶され、かつ／または適切なコンピューティングデバイスのシステムへとロードするために移送されることもある。コンピューティングデバイスのプロセッサによるそのようなコードの実行により、コンピューティングデバイスは、本明細書において考察され、また示される実装形態において実行される実質的な方法で、情報を取り出す機能、情報を解析する機能、通知を提供する機能などを実行することができるようになる。

[00117] したがって、上記で概説されるようなＳＵを受信し、また処理する方法についての態様は、プログラミングで具現化されることもある。本技術のプログラム態様は、非一時的な機械読取り可能媒体のタイプで、実行され、または具現化される実行可能コードおよび／または関連するデータの形態の、一般的に、「製品」または「製造の物品」として考えられることもある。

結論
[00118] 上記は、何が、最良の形態および／または他の例であるように考えられるかについて説明しているが、様々な修正形態が、その中で作られ得ること、本明細書において開示される主題は、様々な形態および例の形で実装され得ること、およびそれらの教示が、非常に多数のアプリケーションにおいて適用される可能性があり、それらのアプリケーションのうちの一部だけが、本明細書において説明されていることが、理解される。本教示についての真の範囲内に含まれる任意の、またすべてのアプリケーションと、修正形態と、変形形態とを特許請求することが、添付の特許請求の範囲によって、意図される。

[00119] 別段述べられていない限り、添付の特許請求の範囲を含めて、本明細書において記載されるすべての測定結果と、値と、格付けと、位置と、大きさと、サイズと、他の仕様とは、近似的なものであり、正確ではない。それらは、それらが関連する当技術分野において、それらが関連しており、また慣習となっている機能と整合している妥当な範囲を有することを意図している。

[00120] すぐ上記で述べられているものを除いて、述べられ、または示されているものは何も、特許請求の範囲において列挙されているか、または列挙されていないかに関係なく、どのようなコンポーネント、ステップ、特徴、オブジェクト、利益、利点、または公衆に対する同等物についての専念を引き起こすことを意図しておらず、または引き起こすように解釈されるべきではない。

[00121] 本明細書において使用される用語および表現は、特定の意味が、別段本明細書において記載されている場合を除いて、問い合わせおよび調査のそれらの対応するそれぞれの分野に関連するそのような用語および表現に対して与えられるような通常の意味を有することが、理解されるであろう。第１の、第２のなどのような相関的な用語を使用して、そのようなエンティティまたはアクションの間の、どのような実際のそのような関係または順序も必ずしも必要とし、または意味するとは限らずに、１つのエンティティまたはアクションを別のエンティティまたはアクションからただ区別することができる。用語「備える／含む」、「備えている／含む」またはその任意の他の変形は、要素のリストを含むプロセス、方法、物品、または装置が、これらの要素だけを含むのではないが、そのようなプロセス、方法、物品、または装置に対して明示的にリストアップされてはいない、または固有ではない他の要素を含むことができるように、非排他的な包含を対象として含むことを意図している。「１つのａ」または「１つのａｎ」によって先行される要素は、さらなる制約条件なしに、その要素を含むプロセス、方法、物品、または装置の中の追加の同一の要素の存在を除外することはない。

[00122] 本開示の「要約」は、読者が、本技術的開示の本質を直ちに確認することを可能にするように、提供される。要約は特許請求の範囲または意味を解釈し、または限定するために使用されないことを、理解と共に述べる。さらに、上記の「発明を実施するための態様」においては、様々な特徴は、本開示を簡素化する目的のために、様々な実施形態において、共にグループ分けされることが、分かる。この開示の方法は、特許請求された実施形態が、各請求項において明示的に列挙されるよりも多くの特徴を必要とするという意図を反映するように解釈されるべきではない。もっと正確に言えば、添付の特許請求の範囲が、反映しているように、発明の主題は、単一の開示された実施形態についてのすべての特徴よりも少ないものにある。したがって、添付の特許請求の範囲は、これによって「発明を実施するための態様」の中に組み込まれており、各請求項は、別々に特許請求された主題として、それ自体に基づいている。

Claims (11)

1. 加入者の健康をモニタリングするように構成された健康モニタリングサーバであって、
   プロセッサと、
   前記プロセッサに結合され、通信ネットワークを経由した通信を可能にするように構成されたネットワークインターフェースと、
   コンテンツおよびプログラミングのためのストレージデバイスと、
   前記ストレージデバイスに記憶されるプログラムと
   を備えており、前記プロセッサによる前記プログラムの実行は、
   前記加入者の健康に関連した異種データを異種ソースから受信する工程と、
   前記加入者の前記健康に関連したコンテキスト情報を測定結果メガストアから取り出す工程と、
   パターン、トレンドまたはその両方を見出すために、前記異種ソースおよび前記測定結果メガストアからの前記情報を解析する工程であって、前記解析する工程は、機械学習技法を用いることによって根本原因識別段階を組み込む工程を含み、前記根本原因識別段階は、
   ネットワークイベントを識別する、前記異種ソースおよび前記測定結果メガストアからの前記情報をクラスタリングする工程、
   特定の原因が、或るネットワークイベントの根本原因である確率を含む確率ツリーを構築する工程、
   条件が満たされる場合、前記確率ツリーをトラバースして前記確率を更新する工程、および
   前記ネットワークイベントに関する根本原因を決定する工程
   を含む、前記解析する工程と
   を含み、
   コンピュータシステムを構成する、健康モニタリングサーバ。
2. 前記異種データの前記異種ソースの少なくとも１つに通知が送信される、請求項１に記載の健康モニタリングサーバ。
3. 前記異種ソースからの前記異種データは、加入者無線トレース、１つまたは複数のソースからの医療レコード、顧客ケアレコード、課金、アプリケーション性能モニタリングレポート、またはその組み合わせを含む、請求項１に記載の健康モニタリングサーバ。
4. データのソースは、前記加入者の１つまたは複数の埋め込まれたまたは着用された個人用健康モニタを含む、請求項１に記載の健康モニタリングサーバ。
5. データのソースは、前記加入者の個人用健康情報を記憶するサーバからのレコードを含む、請求項１に記載の健康モニタリングサーバ。
6. 前記異種データは、リモート健康モニタリングサーバによって受信される前に、最初に、１つまたは複数のネットワークにわたって１つまたは複数のアプリケーションサーバおよび収集システムから受信される、請求項１に記載の健康モニタリングサーバ。
7. 前記異種データは、心拍数、血圧、運動、酸素飽和度、体温、血糖値またはその組み合わせを測定するように構成された１つまたは複数の健康モニタから少なくとも部分的に受信される、請求項１に記載の健康モニタリングサーバ。
8. 前記健康モニタリングサーバは、オープンプラットフォームを提供するように構成され、前記異種ソースからの前記異種データは、組み合わされ、リアルタイムで処理される、請求項１に記載の健康モニタリングサーバ。
9. 前記加入者、介護提供者、前記測定結果メガストアのデータベースに前もって記憶された連絡担当者、救急サービスまたはその組み合わせに通知が送信される、請求項１に記載の健康モニタリングサーバ。
10. 前記プログラムの実行は、動作を継続的に実行するように前記モニタリングサーバを構成する、請求項１に記載の健康モニタリングサーバ。
11. 前記プログラムの実行は、動作を所定の時間間隔で実行するように前記モニタリングサーバを構成する、請求項１に記載の健康モニタリングサーバ。