特表 2024-513628 ＲＩＣ ＳＤＫ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-03-27

(54)【発明の名称】ＲＩＣ ＳＤＫ

(51)【国際特許分類】

   G06F 8/00 20180101AFI20240319BHJP

   H04W 92/12 20090101ALI20240319BHJP

   G06F 8/77 20180101ALI20240319BHJP

【ＦＩ】

G06F8/00

H04W92/12

G06F8/77

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2023540965

(86)(22)【出願日】2022-01-21

(85)【翻訳文提出日】2023-09-05

(86)【国際出願番号】 US2022013427

(87)【国際公開番号】W WO2022186912

(87)【国際公開日】2022-09-09

(31)【優先権主張番号】17/376,801

(32)【優先日】2021-07-15

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】63/225,519

(32)【優先日】2021-07-25

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】63/157,351

(32)【優先日】2021-03-05

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】63/176,859

(32)【優先日】2021-04-19

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】63/180,627

(32)【優先日】2021-04-27

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】17/376,835

(32)【優先日】2021-07-15

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】17/376,758

(32)【優先日】2021-07-15

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】17/376,817

(32)【優先日】2021-07-15

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】63/157,600

(32)【優先日】2021-03-05

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】17/384,777

(32)【優先日】2021-07-25

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．Ｌｉｎｕｘ

(71)【出願人】

【識別番号】514097912

【氏名又は名称】ヴィーエムウェア エルエルシー

【氏名又は名称原語表記】ＶＭｗａｒｅ ＬＬＣ

【住所又は居所原語表記】３４０１ Ｈｉｌｌｖｉｅｗ Ａｖｅ．， Ｐａｌｏ Ａｌｔｏ， ＣＡ ９４３０３， Ｕ．Ｓ．Ａ

(74)【代理人】

【識別番号】100087642

【弁理士】

【氏名又は名称】古谷 聡

(74)【代理人】

【識別番号】100082946

【弁理士】

【氏名又は名称】大西 昭広

(74)【代理人】

【識別番号】100195693

【弁理士】

【氏名又は名称】細井 玲

(74)【代理人】

【識別番号】100203242

【弁理士】

【氏名又は名称】河戸 春樹

(74)【代理人】

【識別番号】100212657

【弁理士】

【氏名又は名称】塚原 一久

(72)【発明者】

【氏名】シン， アミット

(72)【発明者】

【氏名】ミスラ， ラケシュ

(72)【発明者】

【氏名】グディパチ， アディチャ

(72)【発明者】

【氏名】スブラマニ ジャヤヴェリュ， ギリダール

【テーマコード（参考）】

5B376

5K067

【Ｆターム（参考）】

5B376BA18

5B376BC08

5B376BC61

5K067EE10

(57)【要約】

低遅延のニアＲＴ ＲＩＣを提供するために、いくつかの実施形態は、ＲＩＣの機能を、同一のホストコンピュータ又は異なるホストコンピュータ上で動作する異なるマシン（例えば、ＶＭ又はポッド上で実行する）上で動作するいくつかの異なるコンポーネントに分離する。いくつかの実施形態はまた、これらのマシン間に高速インタフェースを提供する。これらのインタフェースの一部又は全部は、ニアＲＴ ＲＩＣの重要な動作（例えば、データパス処理）が、１つ以上のコンポーネントをストールさせる複数の要求のために遅延しないことを保証するために、ノンブロッキング、ロックレスの態様で動作する。さらに、これらのＲＩＣコンポーネントのそれぞれは、コンポーネントのあるプロセスがコンポーネントの別のプロセスの動作をブロックできないように、ノンブロッキングの態様で動作するように設計された内部アーキテクチャも有する。これらの低遅延機能はすべて、ニアＲＴ ＲＩＣがＥ２ノードとｘＡｐｐ間の高速ＩＯとして機能できるようにする。

【特許請求の範囲】

【請求項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】

請求項３４に記載の方法であって、前記ＳＤＬキャッシュが、前記制御プレーンアプリケーションによって要求されたデータを格納していない場合、前記ＲＩＣ ＳＤＫは、前記ＳＤＬキャッシュを介してＳＤＬアクセス要求を処理することができない、方法。

【発明の詳細な説明】

【背景技術】

【0001】

電気通信ネットワークでは、無線アクセスネットワーク（ＲＡＮ）は、電気通信標準の各イテレーションに伴って、より多くの機能を実行する。すなわち、従来の標準と比較して５Ｇの利点を利用可能にするために、５Ｇ ＲＡＮは様々な付加機能を実行する。

【0002】

これらのＲＡＮ機能は、ユーザデバイスとコアネットワークとの間に位置するので、コンピューティング能力が制限され得る基地局（例えば、セルタワー）においてしばしば実行される。

【発明の概要】

【0003】

いくつかの実施形態は、電気通信ネットワークのための新しいＲＡＮインテリジェントコントローラ（ＲＩＣ）を提供する。例えば、低遅延のニアＲＴ ＲＩＣを提供するために、いくつかの実施形態は、ＲＩＣ機能を、同一のホストコンピュータ又は異なるホストコンピュータ上で動作する、異なるマシン上で動作する（例えば、ＶＭ又はポッド上で動作する）いくつかの異なるコンポーネントに分離する。また、いくつかの実施形態は、これらのマシン間に高速なインタフェースを提供する。これらのインタフェースの一部又は全部は、ニアＲＴ ＲＩＣの重要な動作（例えば、データパス処理）が、１つ以上のコンポーネントをストールさせる複数の要求のために遅延しないことを保証するために、ノンブロッキング（ｎｏｎ－ｂｌｏｃｋｉｎｇ）、ロックレス（ｌｏｃｋｌｅｓｓ）の態様で動作する。さらに、これらのＲＩＣコンポーネントのそれぞれは、コンポーネントのあるプロセスがコンポーネントの別のプロセスの動作をブロックできないように、ノンブロッキングの態様で動作するように設計された内部アーキテクチャも有する。これらの低遅延機能のすべては、ニアＲＴ ＲＩＣが、基地局ノード（すなわちＥ２ノード）と制御プレーンアプリケーション（例えばｘＡｐｐｓ）との間で高速ＩＯでサービスを行うことを可能にする。

【0004】

いくつかの実施形態では、ニアＲＴ ＲＩＣは、データパスポッド（ｄａｔａｐａｔｈ Ｐｏｄ）、サービスポッド（ｓｅｒｖｉｃｅ Ｐｏｄ）、及びＳＤＬ（共有データレイヤ（ｓｈａｒｅｄ ｄａｔａ ｌａｙｅｒ））ポッドを含む。ＲＩＣの低遅延アーキテクチャの一部は、異なるポッドを使用してデータＩＯ、サービス、及びＳＤＬ動作を実施することに起因する。そのため、実行する動作のそれぞれのニーズに基づいて、異なるリソース割り当て及び管理動作をこれらのポッドのそれぞれに提供できる。また、いくつかの実施形態では、ＲＩＣは、その様々なポッド間に低遅延メッセージングを提供する。

【0005】

サービスポッドは、いくつかの実施形態において、アプリケーション（例えばｘＡｐｐ）オンボーディング、登録、ＦＣＡＰＳ（障害、構成、アカウンティング、性能、セキュリティ）、及びその他のサービスを実行する。また、他のＲＩＣコンポーネントにサービス（メトリック収集、ポリシープロビジョニング及び構成など）を提供する。ＳＤＬポッドは、ニアＲＴ ＲＩＣの共有データレイヤを実施する。また、いくつかの実施形態のＳＤＬポッドは、１つ以上のサービスコンテナを実行して、ＳＤＬに格納されたデータに対して１つ以上の前処理又は後処理サービスを実行する。

【0006】

データパスポッドは、通信ネットワークの基地局コンポーネント間でデータメッセージ転送を実行し、このネットワークの制御及びエッジアプリケーションを実行する。いくつかの実施形態では、データパスポッドのデータパスサービスの一部又は全部が、データパスポッドのデータパススレッド及び制御スレッドに組み込まれる。他の実施形態では、データパスサービスは、データＩＯスレッド、複数のデータ処理スレッド（ＤＰＴ）及び制御スレッドに組み込まれる。

【0007】

いくつかの実施形態における制御スレッドは、データパススレッドのためのサービスポッド及びＳＤＬポッドとのインタフェースであるが、他の実施形態では、データパススレッドのためのサービスポッドへのインタフェースである（データパススレッドはＳＤＬポッドと直接通信できるため）。これらのいずれかのアプローチの制御スレッドは、データパスの低速な制御関連動作を実行し、一方、１つ以上のデータパススレッドは、データパスの高速なＩＯ動作を実行する。いくつかの実施形態における制御スレッドは、データパススレッドの動作だけでなく、それ自体の動作を構成するための構成データを受信するために、サービスポッドとインタフェースを有する。

【0008】

データパススレッドをデータＩＯスレッド及び複数のデータ処理スレッドに分離する実施形態は、データパススレッドのより計算量の多い動作を複数のデータパス処理スレッドにプッシュすることにより、データＩＯをさらに最適化し、それにより、データＩＯスレッドで実行する計算量の少ない動作を可能にする。これらの最適化の両方は、（不要な遅延を発生しない）高速データパスＩＯを確実にすることを意図しており、これにより、ニアＲＴ ＲＩＣは、基地局ノードと制御及びエッジアプリケーションとの間の高速インタフェースとして機能することができる。

【0009】

前述の発明の概要は、本発明のいくつかの実施形態への簡単な導入としての役割を果たすことを意図している。これは、この文書に開示されたすべての発明の主題の導入または概要であることを意味するものではない。以下の詳細な説明および詳細な説明で参照される図面は、発明の概要ならびに他の実施形態で説明される実施形態をさらに説明する。従って、本書面によって説明される全ての実施形態を理解するため、発明の概要、詳細な説明及び図面の十分な確認が必要である。さらに、請求項に記載された主題事項は、主題事項の概念から逸脱することなく、他の特定の形態で具体化することができるので、主題事項は、発明の概要、詳細な説明、及び図面において例示される詳細によって制限されるのではなく、むしろ、添付の請求項によって定義されるものである。

【図面の簡単な説明】

【0010】

本発明の新規の特徴は、添付の請求項に記載されている。しかしながら、説明の目的のため、本発明のいくつかの実施形態は以下の図において明らかになる。

【0011】

【図1】いくつかの実施形態によるＯ－ＲＡＮアーキテクチャの例を示す。

【0012】

【図2】いくつかの実施形態による非リアルタイムのＲＩＣ及びニアリアルタイムのＲＩＣの両方のコンポーネントの詳細を示す。

【0013】

【図3】いくつかの実施形態のＭＡＣ制御アシスタのより詳細な図を示す。

【0014】

【図4】いくつかの実施形態のユーザレベルトレーサのより詳細な図を示す。

【0015】

【図5】いくつかの実施形態のＯ－ＲＡＮアーキテクチャの別の図を示し、ニアリアルタイムのＲＩＣのより詳細な図を示す。

【0016】

【図6】いくつかの実施形態において、制御プレーンアプリケーションを実行する、マシン上でのＲＩＣ ＳＤＫのデプロイを示す。

【0017】

【図7】いくつかの実施形態が、いくつかのホストコンピュータ上で実行するために、いくつかのＲＩＣをデプロイして、図５及び６に示されたＲＩＣコンポーネントを含む分散ニアＲＴ ＲＩＣを実施することを示す。

【0018】

【図8】２つの制御プレーンアプリケーションが実行される２つのマシンとともに、１つのホストコンピュータ上で実行されるＲＩＣを示す。

【0019】

【図9】２つの制御プレーンアプリケーションと２つのＲＩＣ ＳＤＫが動作する２つのマシンとともに、２つのホストコンピュータ上で動作する２つのＲＩＣを示している。

【0020】

【図10】第１のホストコンピュータ上で動作し、２つの他のホストコンピュータ上で動作する２つのマシン上で動作する２つの制御プレーンアプリケーションを接続するＲＩＣを示す。

【0021】

【図11】第１のホストコンピュータ上で動作し、２つのマシン上で動作する２つの制御プレーンアプリケーションを接続するＲＩＣであって、１つは第１のホストコンピュータ上で動作し、もう１つは別のホストコンピュータ上で動作する、ことを示す。

【0022】

【図12】いくつかの実施形態の分散ニアＲＴ ＲＩＣプラットフォームがサポートする、異なる標準仕様のＡＰＩの例を示す。

【0023】

【図13】ＳＤＬキャッシュが、その制御プレーンと同じマシン上で動作する各ＲＩＣ ＳＤＫの一部である実施形態を示す。

【0024】

【図14】ホストコンピュータのハードウェアアクセラレータにパススルーアクセスして、それらの演算の一部又は全部を実行する制御アプリケーション又はエッジアプリケーションの例を示す。

【0025】

【図15】ホストコンピュータのハードウェアアクセラレータを使用することをアプリケーションに要求する動作を実行するためにＣＰ又はエッジアプリケーションに指示するＯ－ＲＡＮコンポーネントに応答して、いくつかの実施形態において実行される処理を示す。

【0026】

【図16】Ｅ２ノードからのデータに基づいて動作を実行するアプリケーションを示している。

【0027】

【図17】それらの演算の一部（又はすべて）を実行するために、ホストコンピュータのハードウェアアクセラレータへのパススルーアクセスを有する制御アプリケーション又はエッジアプリケーションの別の例を示す。

【0028】

【図18】ホストコンピュータのハードウェアアクセラレータにパススルーアクセスして、それらの演算の一部又は全部を実行するＣＰ又はエッジアプリケーションの更に別の例を示す。

【0029】

【図19】いくつかの実施形態が、ホストコンピュータのハードウェアアクセラレータへの直接的なパススルーアクセスを有するＯ－ＲＡＮアプリケーションをデプロイするために使用する処理を示す。

【0030】

【図20】ホストコンピュータ上で実行されるハイパーバイザによって定義された仮想ハードウェアアクセラレータへのパススルーアクセスを有するＣＰ又はエッジアプリケーションの例を示している。

【0031】

【図21】いくつかの異なるマシン上で動作するいくつかのコンポーネントを有する、ニアＲＴ ＲＩＣの例を示す。

【0032】

【図22】、

【図23】図２１のニアＲＴ ＲＩＣ付近のコンポーネントをデプロイするための異なる例を示している。

【0033】

【図24】、

【図25】ニアＲＴ ＲＩＣの他の例を示している。

【0034】

【図26】ＲＩＣデータパスポッドの例を示す。

【0035】

【図27】データパススレッドが、いくつかの実施形態において、ｘＡｐｐからのサブスクリプション要求を処理するために実行する処理を示す。

【0036】

【図28】１つ以上のｘＡｐｐが受信すべきＥ２ノードからのデータメッセージを処理するために、データＩＯスレッド及びＤＰＴがいくつかの実施形態で実行する処理を示す。

【0037】

【図29】データＩＯスレッド及びＤＰＴが、いくつかの実施形態において、Ｅ２ノードに送信されるべきｘＡｐｐからのデータメッセージを処理するために実行する処理を示す。

【0038】

【図30】いくつかの実施形態においてデータＩＯスレッドがＥ２ノードをＤＰＴに割り当てるために使用する処理の例を示す。

【0039】

【図31】アクティブＲＩＣとスタンバイＲＩＣによって実施される分散ニアＲＴ ＲＩＣを示している。

【0040】

【図32】いくつかの実施形態において、ニアＲＴ ＲＩＣとＥ２ノード間、及びニアＲＴ ＲＩＣとｘＡｐｐポッド間のインタフェースを示す。

【0041】

【図33】ニアＲＴ ＲＩＣのデータパスポッドのＥ２ＡＰメッセージ処理を示す。

【0042】

【図34】ＳＤＬポッドを有するいくつかの実施形態のＲＩＣインスタンスを示す。

【0043】

【図35】本発明のいくつかの実施形態が実施される電子システムを概念的に示す。

【発明を実施するための形態】

【0044】

本発明の以下の詳細な説明では、本発明の多数の詳細、例及び実施形態を記載し説明する。しかしながら、本発明は、説明された実施形態に限定されず、本発明は、説明された特定の詳細および例のいくつか無しに実施されてもよいことが、当業者には明らかであり、明確であろう。

【0045】

今日、Ｏ－ＲＡＮとして実装された電気通信ネットワーク（例えば、セルラーネットワーク）の無線アクセスネットワーク（ＲＡＮ）を、ＲＡＮ要素とインタフェースの相互運用性を可能にする標準に押す動きがある。図１は、いくつかの実施形態による、Ｏ－ＲＡＮアーキテクチャ１００の一例を示す。Ｏ－ＲＡＮアーキテクチャ１００は、非リアルタイムＲＩＣ１０５、ニアリアルタイムＲＡＮインテリジェントコントローラ１１５、オープン制御プレーン集中ユニット（Ｏ－ＣＵ－ＣＰ）１２０、オープンユーザプレーン集中ユニット（Ｏ－ＣＵ－ＵＰ）１２５、オープン分散ユニット（Ｏ－ＤＵ）１３０、オープン無線ユニット（Ｏ－ＲＵ）１３５、及びＯ－Ｃｌｏｕｄ１４０を有するサービス管理及びオーケストレーションフレームワーク１１０を含む。Ｏ－ＣＵ－ＣＰ１２０、Ｏ－ＣＵ－ＵＰ１２５、及びＯ－ＤＵ１３０は、以下、まとめて管理対象機能１２０－１３０と称される場合がある。

【0046】

標準に定義されるように、いくつかの実施形態のＳＭＯ１１０は、ＳＭＯがＲＩＣ１１５、管理対象機能１２０－１３０、及びＯ－Ｃｌｏｕｄ１４０にオープンインタフェース１５０を介して接続し、管理することを可能にする統合ファブリックを含む。これらの要素とは異なり、Ｏ－ＲＵ１３５は、いくつかの実施形態では、ＳＭＯ１１０によって管理されず、破線１６０によって示されるように、Ｏ－ＤＵ１３０によって代わりに管理される。いくつかの実施形態では、Ｏ－ＲＵ１３５は、無線周波数を処理し、Ｏ－ＤＵ１３０に送信する。

【0047】

いくつかの実施形態では、管理対象機能１２０－１３０は、各々がプロトコルのセットをホストする論理ノードである。Ｏ－ＲＡＮ規格によれば、例えば、Ｏ－ＣＵ－ＣＰ１２０は、いくつかの実施形態では、無線リソース制御（ＲＲＣ）及びパケットデータコンバージェンスプロトコル（ＰＤＣＰ）の制御プレーン部分のようなプロトコルを含み、Ｏ－ＣＵ－ＵＰ１２５は、サービスデータアダプテーションプロトコル（ＳＤＡＰ）のようなプロトコルと、パケットデータコンバージェンスプロトコル（ＰＤＣＰ）のユーザプレーン部分を含む。

【0048】

２つのＲＩＣはそれぞれ、特定の制御ループとレイテンシ要件に適合している。ニアリアルタイムＲＩＣ１１５は、１０ｍｓから１秒の時間サイクルで、オープン集中ユニット（Ｏ－ＣＵ）とオープン分散ユニット（Ｏ－ＤＵ）のプログラム制御を提供する。一方、非リアルタイムＲＩＣ（非ＲＴ ＲＩＣ）１０５は、ニアＲＴ ＲＩＣ又はＲＡＮノードへの直接接続を介してＲＡＮで実施され得る上位レイヤポリシーを提供する。非ＲＴ ＲＩＣは、１秒以上の制御ループに使用される。各ＲＩＣ１０５又は１１５は、ＲＡＮ制御アプリケーションを実行するプラットフォームとして機能する。これらのアプリケーションは、ＲＩＣベンダとは異なるサードパーティサプライヤによって開発することができる。これらのアプリケーションは、「ｘＡｐｐｓ」（ニアＲＴ ＲＩＣ１１５の場合）及び「ｒＡｐｐｓ」（非ＲＴ ＲＩＣの場合）と呼ばれる。

【0049】

ニアリアルタイムＲＩＣ１１５は、いくつかの実施形態では、管理対象機能１２０－１３０を制御するために、インタフェース１５５を介したデータ収集及び通信を利用するいくつかの機能の論理的アグリゲーションである。いくつかの実施形態では、非リアルタイムＲＩＣ１０５は、機械学習及びモデル訓練を使用して、管理対象機能１２０－１３０を管理及び最適化する。これらの実施形態のいくつかにおけるニアＲＴ ＲＩＣは、機械学習も使用する。

【0050】

いくつかの実施形態では、Ｏ－Ｃｌｏｕｄ１４０は、ＲＩＣ１１５及び管理対象機能１２０－１３０によって使用される仮想ネットワーク機能（ＶＮＦ）を作成し、ホストする役割を果たす。いくつかの実施形態では、ＤＵは、ユーザスケジューリングのスロット毎の判定を担当し、ＭＡＣ制御アシスト及びユーザレベルのトレーシングを行うＲＡＮスケジューラを含む。クラウドで利用可能なコンピューティング能力を増加させるために（すなわち、典型的にＲＡＮ機能を実行する基地局と比較して）、ＲＩＣは、１つ以上のパブリック及び／又はプライベートクラウドデータセンタで実施され、クラウドで改良されたクラウド定義ＲＡＮスケジューラを実施し、それにより、これらのＭＡＣ制御アシスト及びユーザレベルトレーシング機能をＤＵからＲＩＣにオフロードする。いくつかの実施形態におけるインタフェース１５５は、ＲＡＮがＲＩＣにおいて機能への入力を提供することを可能にし、少なくともいくつかの実施形態では、ＲＩＣにおいてこれらの機能によって計算された出力を受信する。

【0051】

図２は、非リアルタイムＲＩＣ２０１とニアリアルタイムＲＩＣ２０２の両方のコンポーネントの詳細な図を示す。ＲＩＣ２０１及び２０２のそれぞれは、それぞれのセットの分析機能２１０及び２１２と、それぞれのセットの最適化機能２１４及び２１６とを含み、これらはそれぞれ、既存のコンポーネントであることを示すために破線で示される。これらの既存のコンポーネントに加えて、ニアリアルタイム最適化機能２１６は、２つの新しいコンポーネント、ＭＡＣ制御アシスタ２２０及びユーザレベルトレーサ２２２を含み、実線で示されて既存のコンポーネントと視覚的に区別する。いくつかの実施形態において、これらのコンポーネントは、より大きなＭＩＭＯコンポーネントの一部である（例えば、ＭＵ－ＭＩＭＯ ＵＥのペアラー及びプリコーダと共に）。

【0052】

いくつかの実施形態において、ＭＡＣ制御アシスタ２２０は、（１）ＵＬ ＳＲＳチャネル信号受信に基づくユーザ機器（ＵＥ）特定ビームフォーミング重み計算、（２） ＵＥ無線周波数（ＲＦ）条件予測、及び（３）ＵＥ特定ビームに基づくＭＡＣスケジューラに対するマルチユーザ、マルチ入力、マルチ出力（ＭＵ－ＭＩＭＯ）ペアリング提案などの様々な機能を含むことができる。これらの各機能について、いくつかの実施形態は、レポートインタフェース（ＤＵからＲＩＣへの関数の入力データを提供する）と、制御インタフェース（ＲＩＣからＤＵへの関数の出力データを提供する）を公開する。

【0053】

ユーザレベルトレーサ２２２は、いくつかの実施形態では、ユーザ構成及びトラフィック性能に関連するＬ１／Ｌ２／Ｌ３レベル情報を生成する。このトレースデータは、ＭＡＣスケジューラ、パラメータ設定など、さまざまな制御アルゴリズムへの入力として使用できる。ユーザレベルトレーサ２２２は、（ｉ）セル内のユーザ動作を追跡することができるトレース動作、（ｉｉ）ユーザＲＦ条件の追跡、（ｉｉｉ）異なるレイヤ（ＭＡＣ、無線リンク制御（ＲＬＣ）、パケットデータコンバージェンスプロトコル（ＰＤＣＰ））内のユーザデータトラフィック性能の追跡、及び（ｉｖ）ユーザＲＦリソース消費を含むことができるトレース動作を含むことができる。

【0054】

図３は、いくつかの実施形態のＭＡＣ制御アシスタ３００のより詳細な図を示す。説明するように、ＭＡＣ制御アシスタ３００は、ＵＥ－特定ビームフォーミング重み計算器（ＢＦＷＣ）３１０、ＵＥ ＲＦ条件プレディクタ３２０、及びＭＵ－ＭＩＭＯペアリングサジェスタ３３０を含んでいる。いくつかの実施形態におけるＵＥ特定ＢＦＷＣ３１０は、ＵＬ ＳＲＳチャネル信号受信に基づいている。いくつかの実施形態では、ＭＵ－ＭＩＭＯペアリングサジェスタ３３０は、ＵＥ特定ビームに基づくＭＡＣスケジューラのためのものである。

【0055】

ＭＡＣ制御アシスタ３００のコンポーネント３１０－３３０の各々は、説明するように、アップリンクとダウンリンクを含む。ＵＥ特定ＢＷＣ機能のために、いくつかの実施形態は、重み計算関数への入力であるアップリンク音声参照信号（ＵＬ ＳＲＳ）チャネル応答行列と、ＵＥ特定ビームフォーミング重み行列のための制御インタフェースとのためのレポートインタフェースを公開する。ＵＥ ＲＦ条件プレディクタ機能のために、いくつかの実施形態は、ＲＦ条件プレディクタへの入力であるダウンリンク（ＤＬ）チャネル状態レポートのためのレポートインタフェースと、次のスケジューリングウィンドウのための予測されたＤＬチャネル状態（例えば、ＤＬ ＳＩＮＲ、ＰＭＩ、及びランクを含む）のための制御インタフェースを公開する。ＭＵ－ＭＩＭＯペアリング提案機能のために、いくつかの実施形態は、ＵＥペアリング提案機能への入力であるＵＥ特定ビームフォーミング重み行列のレポートインタフェースと、ＵＥペアリング提案及びＳＩＮＲ影響評価のための制御インタフェースを公開する。

【0056】

図４は、いくつかの実施形態のユーザレベルトレーサ４００のより詳細な図を示す。トレーサ４００は、いくつかの実施形態では、追跡動作を実行するための複数のアップリンク４１０と複数のダウンリンク４１５とを含む。これらの動作は、ユーザ設定とトラフィックパフォーマンスに関連するＬ１／Ｌ２／Ｌ３レベルの情報を生成する。このトレースデータは、ＭＡＣスケジューラ、パラメータ設定など、さまざまな制御アルゴリズムへの入力として使用できる。これらの追跡動作は、１）セル内のユーザ挙動を追跡、２）ユーザＲＦ条件を追跡、３）異なるレイヤ（ＭＡＣ、ＲＬＣ、ＰＤＣＰ）におけるユーザデータトラフィック性能を追跡、及び４）ユーザＲＦリソース消費を追跡することができる。

【0057】

これらのトレース動作のために、いくつかの実施形態は、ＤＵ及び／又はＣＵのためのレポートインタフェースを公開して、ユーザレベルの追跡動作に様々なメトリックを提供する。これらのメトリックには、選択したＲＲＣメッセージ、ＭＡＣ／ＲＬＣ／ＰＤＣＰトラフィック量と性能、ＲＦ状態、及びＲＦリソース消費を含めることができる。いくつかの実施形態において、ＲＩＣへのこれらのインタフェースを介したメッセージは、ユーザの挙動及び／又は定期的な報告（例えば、トラフィック性能及びＲＦ条件／リソース消費のため）に基づいてトリガされる。

【0058】

追跡動作は、上に示された様々なユーザデータを追跡し、この情報をＲＡＮに戻すか、又は他の制御アルゴリズム（例えば、ＲＩＣで動作する他のアルゴリズム）に提供することができる。例えば、これらのアルゴリズムは、ユーザレベルのトレース動作からユーザデータ性能に関する分析を実行し、特定の性能が不十分であると判定し、ＲＡＮがユーザ・トラフィックをどのように処理しているかを変更する。いくつかの実施形態においてユーザレベルのトレースから利益を得ることができる制御アルゴリズムの例は、（１）トラフィックステアリング、（２）サービス品質（ＱｏＳ）スケジューリング最適化、（３）ユーザ構成調整、及び（４）ユーザ動作異常検出、を含む。

【0059】

図３－４で説明されているすべての動作（つまり、ＭＡＣスケジューラ機能とユーザレベルの追跡動作）では、クラウド内のＲＩＣで利用可能な計算能力の増加によって、過剰な遅延なしで、より複雑な計算が可能になる。例えば、これらの動作の一部又は全部は、機械学習を使用してＲＩＣで実行することができる（例えば、機械で訓練されたネットワークを使用する）。

【0060】

図５は、いくつかの実施形態のＯ－ＲＡＮアーキテクチャの別の図を示し、ニアリアルタイムのＲＩＣのより詳細な図を示す。アーキテクチャ５００は、非リアルタイムＲＩＣ５１０、分散ニアリアルタイムＲＩＣ５１５、及びＥ２ノード５２０（例えば、Ｏ－ＤＵ及び／又はＯ－ＣＵノード）を有するＳＭＯ５０５を含む。分散ニアリアルタイムＲＩＣ５１５は、メッセージングインフラストラクチャ５４０、サービスのセット（例えば、５５０、５５２、５５４、及び５５６）、共有データレイヤ５６０、データベース５７０、及び終端インタフェースのセット（例えば、５８０、５８２、及び５８４）を含む。図に示すように、組み込みアプリのセット（５３０、５３２、５３４など）は、この分散ニアＲＴ ＲＩＣを使用する。以下にさらに説明するように、いくつかの実施形態では、分散ニアＲＴ ＲＩＣ５１５は、複数のホストコンピュータ上で実行される複数のＲＩＣによって実現される。

【0061】

図に示すように、サービスのセットは、コンフリクトマイグレーションサービス５５０、アプリサブスクリプション管理サービス５５２、管理サービス５５４、及びセキュリティサービス５５６を含む。さらに、終端インタフェースのセットは、ＳＭＯをニアリアルタイムＲＩＣに接続するО１終端インタフェース５８０、ノンリアルタイムＲＩＣをニアリアルタイムＲＩＣに接続するＡ１終端インタフェース５８２、Ｅ２ノードをニアリアルタイムＲＩＣに接続するＥ２終端インタフェース５８４を含む。アプリの各々は、いくつかの実施形態では、Ｅ２ノード５２０から送られたデータを使用するＲＩＣの様々な機能を代表する。例えば、アプリ５３０は、ＭＡＣ制御アシスタ３００のＵＥ特定ＢＦＷＣ３１０に対応し、アプリ５３２は、ＭＡＣ制御アシスタ３００のＵＥ ＲＦ条件プレディクタ３２０に対応する、など。

【0062】

いくつかの実施形態では、フレームワーク５００の目的は、演算集中型のニアリアルタイムの機能をオフロードし、結果をＯ－ＤＵに戻すことである（例えば、Ｅ２インタフェースを介してＥ２ノード５２０に提供する）。いくつかの実施形態では、結果は、ＭＡＣレイヤにおけるリアルタイム判定を支援又は強化するために使用することができる。ＭＡＣ制御アシストフレームワークの３つのユースケース例、ＭＡＣ制御アシスタの異なるコンポーネントに固有の各サンプル（例えば、ＵＥ特定ＢＦＷＣ、ＵＥ ＲＦ条件プレディクタ、ＭＵ－ＭＩＭＯペアリングサジェスタ）、及びユーザレベルトレーサの１つのユースケース例について、以下に説明する。

【0063】

第１のユースケースの例は、ＭＡＣ制御アシストフレームワークのＵＬ ＳＲＳ信号受信コンポーネント（例えば、ＭＡＣ制御アシスタ３００のコンポーネント３１０）に基づくＵＥ特定ビームフォーミング重み計算に特有のものである。この使用事例のいくつかの実施形態では、入力メトリックは、未加工のＳＲＳ受信データのようなＵＬ ＳＲＳに基づく複数のオプションと、チャネル推定からのＳＲＳチャネル応答行列を含むことができる。

【0064】

いくつかの実施形態では、出力メトリックを生成するためのアルゴリズムは、ユーザに到達するために最適ビームフォーミングの重みを評価する。一部の実施形態は、チャネルモデルに基づく従来の信号処理アルゴリズムを使用する。代わりに、又は、組み合わせて、生データ入力を利用する機械学習ベースのアルゴリズムが使用され、これはＥ２ノード５２０内のＤＵからのフィードバックを必要とする。

【0065】

いくつかの実施形態では、アルゴリズムから得られる出力メトリックは、ユーザのためのビームフォーミング重み行列を含む。いくつかの実施形態において、ＢＦＷは、予め設計されたビームセットからのビームインデックスにマッピングすることもできる。いくつかの実施形態におけるＤＵは、ユーザデータの送受信のためにＲＵ（例えば、アーキテクチャ１００内のＯ－ＲＵ１３５）内のＭＩＭＯアンテナアレイゲイン／位相合わせを制御するために行列を使用する。

【0066】

第２のユースケースの例は、ＭＡＣ制御アシストフレームワーク（例えば、ＭＡＣ制御アシスタ３００のコンポーネント３２０）のＵＥ ＲＦ条件プレディクタコンポーネントに特有である。この第２のユースケースでは、いくつかの実施形態によれば、入力メトリックは、少なくとも、ＤＬの場合は広帯域又はサブバンドＣＱＩ／ＰＭＩ／ＲＩ、又はＵＬの場合はＳＲＳのような、ＵＥからのチャネルレポートを含む。いくつかの実施形態の入力メトリックは、ＵＥ距離、ＵＥ位置決めなどの支援情報を含むことを選択することもできる。

【0067】

いくつかの実施形態では、この第２のユースケースのためのアプリアルゴリズムは、観測に基づいてＵＥのＲＦ条件を予測することを意図している。一部の実施形態は、チャネル及び移動度モデルに基づく伝統的な信号処理アルゴリズムを利用する。代わりに、又は、組み合わせて、いくつかの実施形態は、データ入力及び潜在的にはサイトレイアウト（ＤＵからのフィードバックを必要とする）のような他の要因を使用する機械学習ベースのアルゴリズムも使用する。

【0068】

このユースケースのための出力メトリックは、いくつかの実施形態では、次のスケジューリングウィンドウのためのユーザの予測チャネル条件、ならびに予測ダウンリンク及びアップリンクＳＩＮＲ、プリコーディング行列（例えば、適用可能である場合）、及びＳＵ－ＭＩＭＯレイヤを含む。いくつかの実施形態では、これらの出力メトリックは、ＰＤＣＣＨ／ＰＤＳＣＨ／ＰＵＳＣＨ送信のユーザリンクアダプテーションのためにＤＵによって使用される。

【0069】

第３のユースケースは、ＭＵ－ＭＩＭＯペアリング提案又はＭＡＣスケジューラコンポーネント（例えば、ＭＡＣ制御アシスタ３００のコンポーネント３３０）に特有である。この例のユースケースの入力メトリックは、いくつかの実施形態では、少なくともＵＥ特定ＢＦＷ行列とＵＥ ＲＦ条件推定値とを含む。いくつかの実施形態は、ＵＥ特定ＢＦＷマトリックス及びＵＥ ＲＦ条件推定に加えて、入力指標として、ユーザデータ需要などの支援指標を含むこともできる。

【0070】

このユースケースのためのアプリアルゴリズムは、いくつかの実施形態では、ＭＵ－ＭＩＭＯ動作のためにペア化できるユーザを識別することを意図している。例えば、第３のユースケースのいくつかの実施形態は、情報理論及びクロスチャンネル共分散評価に基づく、伝統的な信号処理アルゴリズムを用いる。代わりに、又は、組み合わせて、いくつかの実施形態は、ＤＵからのフィードバックを再度必要とする、データ入力を使用する機械学習ベースのアルゴリズムを使用する。

【0071】

いくつかの実施形態では、この第３のユースケースの出力メトリックは、ＵＥペアリング提案と、ＳＩＮＲレイヤ及びＳＵ－ＭＩＭＯレイヤに対する影響評価を含むことができる。さらに、いくつかの実施形態のＤＵは、出力メトリックを使用して、ＲＦスケジューリングのためのユーザを選択し、伝送効率を決定する。

【0072】

ユーザレベルトレーサのユースケースの例として、サービス品質を最適化するためにＲＦリソースのユーザのスケジューリング優先度を調整することを目標としたＱｏＳスケジューリング最適化を含むことができる。このユースケースのいくつかの実施形態のための入力は、ユーザ加入からのサービス品質目標を含むことができる。いくつかの実施形態において、ユーザレベルのトレースは、（１）ユーザＲＦ条件を追跡すること、（２）異なるレイヤ（例えば、ＭＡＣ／ＲＬＣ／ＰＤＣＰ）におけるユーザデータトラフィック性能を追跡すること、及び（３）ユーザＲＦリソース消費を追跡することを含む。

【0073】

いくつかの実施形態では、アプリアルゴリズムは、ＱｏＳターゲット及び観察されたユーザトラフィック性能に基づいており、ユーザのリソース割り当てが不十分であることを判定するために使用することができる。アルゴリズムフォーマットは、いくつかの実施形態では、ロジックベース又は機械学習ベースとすることができる。いくつかの実施形態では、出力は、ＭＡＣスケジューラに対して発行された推奨を含み、トラフィック優先度又はリンク適応を調整して、パフォーマンスを向上させることができる。

【0074】

制御プレーンアプリケーションを実行する各マシン（例えば、各ＶＭ又はポッド）上で、いくつかの実施形態は、ＲＩＣ ＳＤＫを、マシン上の制御プレーンアプリケーションとＲＡＮの１つ以上の要素のセットとの間のインタフェースとして機能するように構成する。いくつかの実施形態において、ＲＩＣ ＳＤＫは、アプリケーションが、２つ以上のニアリアルタイムＲＩＣによって実施される分散ニアリアルタイム（ＲＴ） ＲＩＣと通信することができる一連のセットＡＰＩ（例えばフレームワーク）を提供する。このようなアプリケーションの例は、いくつかの実施形態では、ｘＡｐｐｓ、及び他の制御プレーン及びエッジアプリケーションを含む。Ｏ－ＲＡＮでは、ｘＡｐｐは制御プレーン、監視、及びデータ処理動作を実行する。図６及び８－２０に関する以下の議論は、制御プレーンアプリケーション（例えば、６１５、８１５、８２０、９１５、９２０など）を意味する。これらの制御プレーンアプリケーションは、いくつかの実施形態において、Ｏ－ＲＡＮシステムにおけるｘＡｐｐである。

【0075】

図６は、いくつかの実施形態において制御プレーンアプリケーション６１５を実行するマシン６１０上のＲＩＣ ＳＤＫ６０５のデプロイを示す。説明するように、１つ以上のマシン６１０は、１つ以上のデータセンタ内のいくつかのホストコンピュータ６０７のそれぞれ上で動作する。いくつかの実施形態では、各マシン６１０上のＲＩＣ ＳＤＫ６０５は、制御プレーンアプリケーションのためのＲＡＮ要素のセット（例えば、Ｅ２ノード５２０、共有データレイヤ５６０、管理サービス５５４、ＳＭＯ５０５など）へのネットワーク接続を確立するネットワーク接続プロセスのセットを含む。ＲＩＣ ＳＤＫプロセスを使用すると、マシン上の制御プレーンアプリケーションでネットワーク接続動作を実行せずに済む。いくつかの実施形態では、各マシンの各ＲＩＣ ＳＤＫのネットワーク接続プロセスのセットは、マシンと、マシンの制御プレーンアプリケーションによって使用されるＲＡＮ要素のセットとの間のネットワーク接続を確立及び維持し、制御プレーンアプリケーションのためのＲＡＮ要素のセットとの間のデータパケット伝送を処理する。

【0076】

各マシンの制御プレーンアプリケーションは、ＲＩＣ ＳＤＫが低レベルＡＰＩ６２５に変換する高レベルＡＰＩ６２０を介してＲＡＮ要素のセットと通信する。いくつかの実施形態では、低レベルＡＰＩコール６２５の少なくともサブセットは、標準策定団体によって規定される。また、いくつかの実施形態では、高レベルＡＰＩ６２０は、高レベルプログラミング言語（例えば、Ｃ＋＋）で作成され、低レベルＡＰＩコールは、ネットワーク接続を確立及び維持し、これらの接続を介してデータパケットを通過する低レベルコールを含む。

【0077】

ＲＩＣ ＳＤＫがそのマシン上の制御プレーンアプリケーションに接続するＲＡＮ要素のセットには、異なるＲＡＮベンダ及び／又は開発者によって生成又は開発されるＲＡＮ要素が含まれる。これらのＲＡＮ要素は、いくつかの実施形態において、ＲＡＮのＣＵ６３０及びＤＵ６３５を含む。また、このＳＤＫは低レベルの標準で策定されるＥ２インターフェイスを介してＣＵ及びＤＵと通信するが、マシン上の制御プレーンアプリケーションは高レベルＡＰＩコールを使用してＲＩＣ ＳＤＫを介してＣＵ及びＤＵと通信する。いくつかの実施形態では、高レベルＡＰＩコールは、低レベル伝送又はネットワーク動作を含まない高レベルアプリケーションレイヤでのＥ２インタフェース動作を規定する。

【0078】

組み合わせ又は代替として、ＲＩＣ ＳＤＫがそのマシン６１０上の制御プレーンアプリケーション６１５と接続するＲＡＮ要素のセットは、ＲＩＣのネットワーク要素を含む。ここでも、いくつかの実施形態におけるこれらのネットワーク要素は、異なるＲＡＮベンダ及び／又は開発者によって生成され、及び／又は開発されるＲＡＮ要素を含む。いくつかの実施形態におけるこれらのＲＩＣ要素には、共有データレイヤ５６０、データパス入出力（Ｉ／Ｏ）要素、及びいくつかの実施形態におけるアプリケーション及び管理サービス５５２及び５５４が含まれる。図７は、いくつかの実施形態が、図５及び６に示されるＲＩＣコンポーネントを含む分散ニアＲＴ ＲＩＣ７００を実施するために、いくつかのホストコンピュータ上で動作するように、いくつかのニアＲＴ ＲＩＣ７０５をデプロイすることを示す。いくつかの実施形態では、１つのＲＩＣ７０５は、制御プレーンアプリケーション６１５も実行する各ホストコンピュータ上で動作する。他の実施形態では、制御プレーンアプリケーション６１５は、ＲＩＣを実行しないホストコンピュータ上で動作することができる。例えば、いくつかの実施形態では、１つ以上の制御プレーンアプリケーションは、グラフィックプロセッシングユニット（ＧＰＵ）を有する１つ以上のホストコンピュータ上で動作するが、ＲＩＣは、ＧＰＵの処理能力を必要としないため、そのようなホストコンピュータ上で動作しない。

【0079】

ＲＩＣ ＳＤＫは、分散ニアＲＴ ＲＩＣを介して、他のマシンで動作しない他の制御プレーンアプリケーションにもその制御プレーンアプリケーションを接続する。言い換えると、いくつかの実施形態におけるＲＩＣ ＳＤＫ及び分散ニアＲＴ ＲＩＣは、制御プレーンアプリケーション間の通信インタフェースとして機能する。いくつかの実施形態では、異なる制御プレーンアプリケーションは、分散ニアＲＴ ＲＩＣを介して互いに通信するために共通セットのＲＩＣ ＡＰＩを使用する異なるアプリケーション開発者によって開発される。これらの実施形態のいくつかでは、分散ニアＲＴ ＲＩＣは、ＡＰＩコールを一方の制御アプリケーションから他方の制御アプリケーションに転送するときに、ＡＰＩコールに１つ以上のパラメータを追加する。

【0080】

図８から１１に、ＲＩＣ ＳＤＫと分散ニアＲＴ ＲＩＣが制御プレーンアプリケーション間の通信インタフェースを確立するＲＩＣアーキテクチャの例を示す。これらのアーキテクチャは、一部の実施形態では相互に排他的であるが、他の実施形態では、これらのアーキテクチャの２つ以上の組み合わせで使用される。図８は、２つの制御プレーンアプリケーション８１５及び８２０が実行する２つのマシン８１０及び８１２と共に、１つのホストコンピュータ８０５上で実行するＲＩＣ８００を示す。ＲＩＣ８００は、マシン８１０及び８１２上で実行されるＲＩＣ ＳＤＫ８０２及び８０４を介して、ＣＰアプリケーション８１５からＡＰＩコールを受信し、ＡＰＩコールをＣＰアプリケーション８２０に転送し、これらのＡＰＩコールへの応答を第２のＣＰアプリケーション８２０から第１のＣＰアプリケーション８１５に渡す。また、ＡＰＩコールを第２のＣＰアプリケーション８２０から第１のＣＰアプリケーション８１５に渡し、第１のＣＰアプリケーション８１５から第２のＣＰアプリケーション８２０に応答する。

【0081】

図９は、２つの制御プレーンアプリケーション９１５及び９２０及び２つのＲＩＣ ＳＤＫ９０２及び９０４が実行される、２つのホストコンピュータ９０５及び９０７上で実行される２つのＲＩＣ９００及び９０１と、２つのマシン９１０及び９１２を示している。図に示すように、第１のＣＰアプリケーション９１５から第２のＣＰアプリケーション９２０へのＡＰＩコールは、第１のＲＩＣ ＳＤＫ９０２、第１のＲＩＣ９００、第２のＲＩＣ９０１及び第２のＲＩＣ ＳＤＫ９０４を介して転送される。第１のＣＰアプリケーション９１５に対するこれらのＡＰＩコールに対する第２のＣＰアプリケーションの応答は、第２のＲＩＣ ＳＤＫ９０４、第２のＲＩＣ９０１、第１のＲＩＣ９００、及び第１のＲＩＣ ＳＤＫ９０２からリバースパスを通過する。

【0082】

第２のＣＰアプリケーション９２０から第１のＣＰアプリケーション９１５へのＡＰＩコールは、第２のＲＩＣ ＳＤＫ９０４、第２のＲＩＣ９０１、第１のＲＩＣ９００、及び第１のＲＩＣ ＳＤＫ９０２を介して転送されるが、これらのＡＰＩコールに対する第１のＣＰアプリケーション９１５から第２のＣＰアプリケーション９２０への応答は、第１のＲＩＣ ＳＤＫ９０２、第１のＲＩＣ９００、第２のＲＩＣ９０１、及び第２のＲＩＣ ＳＤＫ９０４を介して転送される。

【0083】

図１０は、２つの他のホストコンピュータ１００６及び１００７上で動作する２つのマシン１０１０及び１０１２上で動作する２つの制御プレーンアプリケーション１０１５及び１０２０を接続するために、第１のホストコンピュータ１００５上で動作するＲＩＣ１０００を示す。ＲＩＣ１０００は、マシン１０１０及び１０１２上で動作するＲＩＣ ＳＤＫ１００２及び１００４を介して、ＣＰアプリケーション１０１５からＡＰＩコールを受信し、ＡＰＩコールをＣＰアプリケーション１０２０に転送し、これらのＡＰＩコールへの応答を第２のＣＰアプリケーション１０２０から第１のＣＰアプリケーション１０１５に渡す。また、ＡＰＩコールを第２のＣＰアプリケーション１０２０から第１のＣＰアプリケーション１０１５に渡し、第１のＣＰアプリケーション１０１５から第２のＣＰアプリケーション１０２０に応答する。

【0084】

図１１は、ホストコンピュータ１１０５上で動作し、一方がホストコンピュータ１１０６上で動作する２つのマシン１１１０及び１１１２上で動作する２つの制御プレーンアプリケーション１１１５及び１１２０を接続するために、第１のホストコンピュータ１１０５上で実行するＲＩＣ１１００を示している。ＲＩＣ１１００は、マシン１１１０及び１１１２上で実行されるＲＩＣ ＳＤＫ１１０２および１１０４を介して、ＣＰアプリケーション１１１５からＡＰＩコールを受信し、ＡＰＩコールをＣＰアプリケーション１１２０に転送し、これらのＡＰＩコールへの応答を第２のＣＰアプリケーション１１２０から第１のＣＰアプリケーション１１１５に渡す。これらのＳＤＫ１１０２及び１１０４を介して、ＲＩＣ１１００はまた、ＡＰＩコールを第２のＣＰアプリケーション１１２０から第１のＣＰアプリケーション１１１５に渡し、第１のＣＰアプリケーション１１１５から第２のＣＰアプリケーション１１２０に応答する。

【0085】

図１２は、いくつかの実施形態の分散ニアＲＴ ＲＩＣプラットフォームがサポートする、異なる標準仕様のＡＰＩの例を示す。説明するように、いくつかの実施形態における分散ニアＲＴ ＲＩＣプラットフォーム１２００は、Ｏ－ＲＡＮ標準規格団体によって規定されるＥ２、О１及びＡ１インタフェースを使用する。Ｅ２ ＡＰＩを使用して、Ｏ－ＣＵ－ＣＰ１２０２、Ｏ－ＣＵ－ＵＰ１２０４、Ｏ－ＤＵ１２０６などのＥ２ Ｏ－ＲＡＮノードと通信する。また、Ａ１ ＡＰＩを使用して非リアルタイムＲＩＣプラットフォーム１２０８と通信し、О１ ＡＰＩを使用してＳＭＯ１２１０と通信する。

【0086】

時間Ｅ２、Ａ１及びＯ１ ＡＰＩのそれぞれについて、ＲＩＣ ＳＤＫ１２１５は、ＲＩＣ ＳＤＫ及び分散ニアＲＴ ＲＩＣプラットフォームを使用してＥ２ノード１２０２－１２０６、非リアルタイムＲＩＣプラットフォーム１２０８及びＳＭＯ１２１０と通信する制御プレーンアプリケーション１２２０のための高レベル対応ＡＰＩを提供する。図１２では、Ｅ２、О１、及びＡｌインターフェイスの上位レベルの対応するＡＰＩを、Ｅ２'ＡＰＩコール、О１'ＡＰＩコール、及びＡＥ ＡＰＩコールとしてプライムサインを使用して指定している。これらの高レベル対応ＡＰＩは、標準団体では規定されていないが、ＲＩＣ ＳＤＫ及び／又は分散ニアＲＴ ＲＩＣが、標準仕様のＡＰＩコールに変換するＡＰＩである。

【0087】

また、図１２は、制御プレーンアプリケーション１２２０がＲＩＣ ＳＤＫ及び分散ニアＲＴ ＲＩＣを介して互いに通信し、分散ニアＲＴ ＲＩＣの１つ以上の要素（例えば、共有データレイヤ５６０、データパス入出力（Ｉ／Ｏ）要素、及びアプリケーション及び管理サービス５５２及び５５４）と通信することを可能にするためのいくつかの内部ＲＩＣ ＡＰＩを示す。

【0088】

使用可能化ＡＰＩは、いくつかの実施形態で使用されるＡＰＩであり、制御プレーンアプリケーション１２２０が相互に通信することを可能にする。図８－１１を参照して上述したように、いくつかの実施形態では、これらのＡＰＩは、分散ニアＲＴ ＲＩＣを通過する。他の実施形態では、これらのＡＰＩは、制御プレーンアプリケーションのＲＩＣ ＳＤＫが、分散ニアＲＴ ＲＩＣの他のコンポーネントを通過することなく、互いに直接通信することを可能にする。このため、図１２は、２つの制御プレーンアプリケーション１２２０のＲＩＣ ＳＤＫ１２１５間に破線の双方向矢印を含み、いくつかの実施形態では、これらのアプリケーションのＲＩＣ ＳＤＫ１２１５が互いに直接通信することを示す。

【0089】

一部の実施形態における使用可能化ＡＰＩには、登録ＡＰＩ、サービス探索ＡＰＩ、及びアプリ間通信ＡＰＩが含まれる。登録ＡＰＩは、アプリケーション１２２０（例えば、ｘＡｐｐｓ）が、それらのネットワーク識別子（例えば、それらのネットワークアドレス及び利用可能なＬ４ポート）を提供し、それらの機能（例えば、チャネル予測を実行すること）を提供することによって、自身を他のアプリケーション１２２０に導入するために使用される。サービス探索ＡＰＩは、制御プレーンアプリケーション１２２０（例えば、ｘＡｐｐｓ）が、特定のサービスを提供する他の制御プレーンアプリケーション（例えば、他のｘＡｐｐｓ）のために、サービスディレクトリ（例えば、分散ニアＲＴ ＲＩＣ）に問い合わせることを可能にする。アプリ間通信ＡＰＩを使用すると、制御プレーンアプリケーションが相互に通信してデータを渡したり、特定の動作を要求したりできる。

【0090】

いくつかの実施形態は、ＳＤＬキャッシュを制御プレーンアプリケーションと同じホストコンピュータ上にデプロイし、このキャッシュを使用して、制御プレーンアプリケーションのＳＤＬストレージアクセス要求の少なくともサブセットを処理する。いくつかの実施形態において、制御プレーンアプリケーション及びＳＤＬキャッシュは、ホストコンピュータ上で動作するマシン上で動作する。他の実施形態では、ＳＤＬキャッシュは、同じホストコンピュータ上で動作するが、制御プレーンアプリケーションが動作するマシンの外部で動作する。これらの実施形態のいくつかでは、同じホストコンピュータ上で実行される複数の制御プレーンアプリケーションは、そのホストコンピュータ上で共通ＳＤＬキャッシュを使用する。

【0091】

ＳＤＬキャッシュは、いくつかの実施形態では、制御プレーンと同じホストコンピュータ上で動作するＲＩＣの一部である。他の実施形態では、ＳＤＬキャッシュは、制御プレーンアプリケーションと同じマシン上で動作するＲＩＣ ＳＤＫの一部である。これらの実施形態のいずれにおいても、ＲＩＣ又はＲＩＣ ＳＤＫの同期処理は、ＳＤＬキャッシュに記憶されたデータをＳＤＬストレージに記憶されたデータと同期させる。

【0092】

いくつかの実施形態では、ＳＤＬストレージは、制御プレーンアプリケーションが実行されるホストコンピュータとは異なるホストコンピュータ上で動作し、他の実施形態では、ＳＤＬストレージの少なくとも一部は、制御プレーンアプリケーションが動作する同じホストコンピュータ上で動作する。また、いくつかの実施形態では、ＲＩＣ ＳＤＫがＳＤＬキャッシュを介してＳＤＬアクセス要求を処理できない場合、ＲＩＣ又はＲＩＣ ＳＤＫはＳＤＬアクセス要求を制御プレーンアプリケーションからＳＤＬストレージに転送する。たとえば、ＳＤＬキャッシュが制御プレーンアプリケーションによって要求されたデータを格納しない場合、ＲＩＣ 又はＲＩＣ ＳＤＫはＳＤＬキャッシュを介してＳＤＬアクセス要求を処理できない。

【0093】

図１３は、ＳＤＬキャッシュ１３０２が、その制御プレーンアプリケーション１３１０と同じマシン１３０５上で実行される各ＲＩＣ ＳＤＫ１３００の一部である実施形態を示す。説明するように、ＲＩＣ ＳＤＫ１３００は、ＣＰアプリケーション１３１０からのＳＤＬ要求を処理するクエリマネージャ１３２と、ＳＤＬキャッシュに記憶されたデータを、分散ニアＲＴ ＲＩＣ１３３０のＳＤＬ１３５５のＳＤＬストレージ１３５０に記憶されたデータと同期させる同期サービス１３２７とを含む。この例では、ＳＤＬストレージ１３５０は、制御プレーンアプリケーション１３１０が動作するホストコンピュータとは異なるホストコンピュータ上で動作する。しかしながら、他の実施形態では、ＳＤＬストレージ１３５０の少なくとも一部は、制御プレーンアプリケーション１３１０が動作するのと同じホストコンピュータ上で動作する。

【0094】

制御プレーンアプリケーション１３１０がＳＤＬストレージへのデータの読み出し又は書込みのために高レベルＡＰＩコールを使用する場合、ＲＩＣ ＳＤＫ１３００のクエリマネージャ１３２５は、まず、読み出し又は書み込み中のデータレコードがＳＤＬキャッシュ１３０２に格納されているか否かを判定する。その場合、クエリマネージャ１３２５は、このレコードからの読み出し又は書き込みを行う。この動作が書き込み動作である場合、同期サービス１３２７は、リアルタイムに、又はバッチに基づいて、新しいデータをＳＤＬストレージ１３５０に書き込む。一方、ＲＩＣ ＳＤＫ１３００のクエリマネージャ１３２５は、読み出し又は書き込みされているデータレコードがＳＤＬキャッシュ１３０２に格納されていないと判定すると、要求された読み出し又は書き込み動作を実行するために分散ニアＲＴ ＲＩＣのＳＤＬレイヤにＡＰＩコールを渡す。このＡＰＩコールを渡すと、ＲＩＣ ＳＤＫ１３００は、このコールのフォーマットを修正し、及び／又は、いくつかの実施形態においてこのコールと共に供給されるパラメータを修正する。

【0095】

いくつかの実施形態は、ＲＡＮ（Ｏｐｅｎ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）内の動作を制御プレーン（ＣＰ）上にオフロードするための様々な方法、又はソフトウェア定義データセンタ（ＳＤＤＣ）内のハードウェアアクセラレータを備えたホストコンピュータ上で動作するエッジアプリケーションを提供する。例えば、ハードウェアアクセラレータを備えたホストコンピュータ上で動作するマシン上で動作するＣＰ又はエッジアプリケーションにおいて、いくつかの実施形態の方法は、動作を実行しなければならないＯ－ＲＡＮ Ｅ２ユニットからデータを受信する。この方法では、マシンのドライバを使用してハードウェアアクセラレータと直接通信し、ハードウェアアクセラレータに動作に関連する計算のセットを実行するように指示する。このドライバにより、ハードウェアアクセラレータとの通信は、マシンのドライバとハードウェアアクセラレータの間でホストコンピュータ上で実行されるドライバの中間セットをバイパスできる。このドライバを介して、いくつかの実施形態のアプリケーションは、演算結果を受信し、それは、次に、１つ以上のＯ－ＲＡＮコンポーネント（例えば、データを提供したＥ２ユニット、別のＥ２ユニット、又は別のｘＡｐｐ）に提供する。

【0096】

図１４－２０は、ホストコンピュータのハードウェアアクセラレータへのパススルーアクセスを有するＣＰ又はエッジアプリケーションへのＯ－ＲＡＮ動作をオフロードするためのいくつかの異なる実施形態を示す。このようなハードウェアアクセラレータの例には、グラフィカルプロセッシングユニット（ＧＰＵ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、及び構造化ＡＳＩＣが含まれる。

【0097】

図１４は、ホストコンピュータ１４１０のハードウェアアクセラレータ１４５０へのパススルーアクセスを有して、それらの演算の一部又は全部を実行するＣＰアプリケーション又はエッジアプリケーション１４０２の例を示す。説明するように、各アプリケーション１４０２は、ホストコンピュータ１４１０のアクセラレータ１４５０への直接的なパススルーアクセスを有するアクセラレータドライバ１４１２を有するポッド１４０４上で動作する。各ポッド１４０４は、ホストコンピュータのハイパーバイザ１４０８上で動作するＶＭ１４０６内で動作する（すなわち、ＶＭ１４０６上で動作する）。

【0098】

いくつかの実施形態では、ポッドは、Ｋｕｂｅｒｎｅｔｅｓで作成および管理することができる、デプロイ可能な小規模なコンピューティングユニットである。ポッドには、共有ストレージとネットワークリソースを有する１つ以上のコンテナのグループと、コンテナの実行方法の仕様が含まれる。いくつかの実施形態では、ポッドの内容は、常に同じ場所に配置され、同時にスケジュールされ、共有コンテキストで実行される。ポッドは、アプリケーション固有の論理ホストコンピュータをモデル化する。ポッドには、相互に通信する１つ以上のアプリケーションコンテナが含まれる。いくつかの実施形態では、ポッドの共有コンテキストは、オペレーティングシステム名前空間（例えば、Ｌｉｎｕｘ ｃｇｒｏｕｐｓ）の集合である。ポッドのコンテキスト内では、個々のアプリケーションにさらにサブ分離が適用される場合がある。

【0099】

各ポッドのアクセラレータドライバ１４１２は、ハードウェアアクセラレータ１４５０への直接アクセスを有し、このアクセスは、ＶＭ１４０６及びハイパーバイザ１４０８のハードウェアアクセラレータドライバ１４１４および１４１６をバイパスする。いくつかの実施形態では、ハイパーバイザ１４０８は、ホストコンピュータ１４１０のオペレーティングシステム（図示せず）上で実行される。これらの実施形態では、各ポッドのアクセラレータドライバ１４１２のハードウェアアクセラレータ１４５０への直接アクセスも、オペレーティングシステムのハードウェアアクセラレータドライバをバイパスする。

【0100】

ハードウェアアクセラレータと通信するために、いくつかの実施形態の各アプリケーション１４０２は、そのポッド上で実行されるＲＩＣ ＳＤＫ１４３０を介して通信する。例えば、いくつかの実施形態では、各アプリケーション１４０２は、ＲＩＣ ＳＤＫ１４３０の高レベルＡＰＩを使用してハードウェアアクセラレータ１４５０と通信する。次に、ＲＩＣ ＳＤＫ１４３０は、高レベルＡＰＩを、マシンのドライバ１４１２と通信するために必要とされる低レベルＡＰＩに変換し、これは、通信をハードウェアアクセラレータ１４５０に中継する。低レベルＡＰＩは、ハードウェアアクセラレータ１４５０の販売に関連する第１の会社によって提供される一方、ＲＩＣ ＳＤＫ１４３０は、ＲＩＣ ＳＤＫ１４３０の販売に関連する第２の会社によって提供される。いくつかの実施形態では、ＲＩＣ ＳＤＫ１４３０によって使用される低レベルＡＰＩは、ハードウェアアクセラレータ１４５０に関連するＡＰＩライブラリ１４３２において指定されるＡＰＩである。

【0101】

図１５は、いくつかの実施形態の方法を実施する処理１５００を示す。処理１５００は、ＣＰ又はエッジアプリケーションに命令するＯ－ＲＡＮコンポーネントに応答して実行され、アプリケーションがそのホストコンピュータのハードウェアアクセラレータを使用することを要求する動作を実行する。この処理１５００は、Ｅ２ノード１６５０から受信したデータに基づいて動作を実行するアプリケーション１４０２を示す図１６を参照して以下に説明される。

【0102】

図１５に示すように、処理１５００は、（１５０５で）アプリケーション１４０２が、ホストコンピュータ１６１０上で動作しているＯ－ＲＡＮ Ｅ２ユニット１６５０からデータを受信すると開始する。いくつかの実施形態では、アプリケーション１４０２は、Ｅ２ユニット１６５０からのデータをサブスクライブし、１５０５で受信されたデータは、このサブスクリプションに応答している。このサブスクリプションは、いくつかの実施形態では、分散ニアＲＴ ＲＩＣを介して行われる。アプリケーション１４０２のホストコンピュータ１４１０及び１６１０とＥ２ユニット１６５０は、いくつかの実施形態では１つのＳＤＤＣで動作する。他の実施形態では、これらの２つのホストコンピュータ１４１０及び１６１０は、２つの異なる物理的位置で動作する。例えば、ホストコンピュータ１４１０は第１の位置で動作し、一方ホストコンピュータ１６１０はＯ－ＲＡＮのセルサイトに近い第２の位置で動作する。いくつかの実施形態では、第２の位置は、受け付けた動作を含む複雑な動作を実行するハードウェアアクセラレータを有するコンピュータを備えていない。

【0103】

アプリケーション１４０２は、（１）ホストコンピュータ１４１０及び１６１０上で実行されるニアＲＴ ＲＩＣ１６４０及び１６４５で形成される分散ニアＲＴ ＲＩＣ１６８０を介してＥ２ユニット１６５０から（１５０５において）データを受信し、及び（２）そのポッド１４０４上で実行されるＲＩＣ ＳＤＫ１４３０を受信する。次に、アプリケーション１４０２は、ハードウェアアクセラレータ１４５０を使用して、動作に関連する計算のセットを実行する（１５１０において）。

【0104】

ハードウェアアクセラレータ１４５０と通信するために、アプリケーション１４０２は、ＲＩＣ ＳＤＫ１４３０によって提供される高レベルＡＰＩを使用する。次に、ＲＩＣ ＳＤＫ１４３０は、高レベルＡＰＩを、ハードウェアアクセラレータ１４５０に関連するＡＰＩライブラリ１４３２に規定された低レベルＡＰＩに変換する。これらの低レベルＡＰＩは、次に、ＶＭ１４０６及びハイパーバイザ１４０８のドライバ１４１４及び１４１６をバイパスするアクセラレータ１４５０への直接的なパススルーアクセスを介して、ポッドのドライバ１４１２によってハードウェアアクセラレータ１４５０に通信される。このドライバ１４１２、ＡＰＩライブラリ１４３２に規定されたＡＰＩ及びＲＩＣ ＳＤＫ１４３０を介して、アプリケーション１４０２は、ハードウェアアクセラレータ１４５０によって実行される演算（例えば、計算）の結果も受信する。

【0105】

アプリケーション１４０２は、その動作の結果を、処理１５００を開始したデータ又はＳＤＬストレージを提供したＥ２ユニット１６５０などの１つ以上のＯ－ＲＡＮコンポーネントに（１５１５において）提供する。この結果は、ＲＩＣ ＳＤＫ１４３０及び分散ニアＲＴ ＲＩＣ１６８０を介して提供される。他の実施形態では、アプリケーション１４０２は、（ＲＩＣ ＳＤＫ１４３０を介して）その動作の結果を、ハードウェアアクセラレータ１４５０を使用して動作を実行するアプリケーションと同じホストコンピュータ又は別のホストコンピュータ上で動作する別のＯ－ＲＡＮ Ｅ２ユニット又はマシン上で動作する１つ以上の他のアプリケーション（アプリケーションがその動作を実行したデータを提供したＥ２ユニット以外のアプリケーション）に提供する。処理１５００は、１５１５の後で終了する。

【0106】

他の実施形態では、Ｏ－ＲＡＮ制御又はエッジアプリケーションのパススルーアクセスを他のデプロイ設定で使用する。例えば、図１７は、ホストコンピュータ１７１０のハードウェアアクセラレータ１７５０へのパススルーアクセスを有し、それらの演算の一部（又は全部）を実行するＣＰアプリケーション又はエッジアプリケーション１７０２の別の例を示す。この例では、各アプリケーション１７０２（１）は、ＶＭ１７０６上で実行するポッド１７０４上で実行され、（２）ホストコンピュータ１７１０のアクセラレータ１７５０への直接的なパススルーアクセスを有するこのＶＭ１７０６のアクセラレータドライバ１７１２を使用する。ＶＭ１７０６は、ホストコンピュータ１７１０上で動作するハイパーバイザ１７０８上で実行される。仮想マシンのアクセラレータドライバ１７１２は、ハイパーバイザ１７０８のハードウェアアクセラレータドライバ１７１６をバイパスする。いくつかの実施形態では、ハイパーバイザ１７０８は、ホストコンピュータ１７１０のオペレーティングシステム（図示せず）上で動作する。これらの実施形態では、仮想マシンのアクセラレータドライバ１７１２のハードウェアアクセラレータ１７５０への直接アクセスは、オペレーティングシステムのハードウェアアクセラレータドライバをバイパスする。

【0107】

ハードウェアアクセラレータ１７５０を使用するために、いくつかの実施形態の各アプリケーション１７０２は、ハードウェアアクセラレータ１７５０と通信するために、ＲＩＣ ＳＤＫ１７３０の高レベルＡＰＩを使用する（そのポッド１７０４上で実行する）。ＲＩＣ ＳＤＫ１７３０は、高レベルＡＰＩを、ＶＭのドライバ１７１２と通信するために必要とされる低レベルＡＰＩに変換し、次に、通信をハードウェアアクセラレータ１７５０に中継する。いくつかの実施形態では、ＲＩＣ ＳＤＫ１７３０によって使用される低レベルＡＰＩは、ハードウェアアクセラレータ１７５０に関連するＡＰＩライブラリ１７３２において規定されるＡＰＩである。このＡＰＩライブラリ１７３２は、ＶＭ１７０６のドライバインタフェースの一部である。

【0108】

図１８は、ホストコンピュータ１８１０のハードウェアアクセラレータ１８５０へのパススルーアクセスを有し、その演算の一部又は全部を実行するＣＰ又はエッジアプリケーション１８０２のさらに別の例を示す。この例では、各アプリケーション１８０２（１）は、ホストコンピュータ１８１０上で動作するハイパーバイザ１８０６上で動作するＶＭ１８０４上で動作し、（２）ホストコンピュータ１８１０のアクセラレータ１８５０への直接的なパススルーアクセスを有するそのＶＭ１８０４のアクセラレータドライバ１８１２を使用する。

【0109】

仮想マシンのアクセラレータドライバ１８１２は、ハイパーバイザ１８０６のハードウェアアクセラレータドライバ１８１６をバイパスする。いくつかの実施形態では、ハイパーバイザ１８０６は、ホストコンピュータ１８１０のオペレーティングシステム（図示せず）上で動作する。これらの実施形態では、仮想マシンのアクセラレータドライバ１８１２のハードウェアアクセラレータ１８５０への直接アクセスは、オペレーティングシステムのハードウェアアクセラレータドライバをバイパスする。

【0110】

ハードウェアアクセラレータ１８５０を使用するために、いくつかの実施形態の各アプリケーション１８０２は、ハードウェアアクセラレータ１８５０と通信するために、ＲＩＣ ＳＤＫ１７３０の高レベルＡＰＩを使用する（そのポッド１８０４上で実行する）。ＲＩＣ ＳＤＫ１８３０は、高レベルＡＰＩを、ＶＭのドライバ１８１２と通信するために必要とされる低レベルＡＰＩに変換し、次に、通信をハードウェアアクセラレータ１８５０に中継する。いくつかの実施形態では、ＲＩＣ ＳＤＫ１８３０によって使用される低レベルＡＰＩは、ハードウェアアクセラレータ１８５０に関連するＡＰＩライブラリ１８３２において指定されるＡＰＩである。このＡＰＩライブラリ１８３２は、ＶＭ１８０６のドライバインタフェースの一部である。

【0111】

一般的な当業者であれば、Ｏ－ＲＡＮ制御又はエッジアプリケーションのためのパススルーアクセスは、他の実施形態の他のデプロイ設定において使用されることを認識するであろう。例えば、ポッド上で動作する代わりに、他の実施形態のアプリケーションは、コンテナ上で動作する。これらの実施形態は、次いで、それらのポッド又はＶＭのハードウェアアクセラレータドライバを使用して、制御又はエッジアプリケーションのためのハードウェアアクセラレータへのパススルーアクセスを有する。これらの実施形態のいくつかでは、制御又はエッジアプリケーションは、その関連ＲＩＣ ＳＤＫを介してハードウェアアクセラレータと通信し、他のＯ－ＲＡＮコンポーネントと通信し、その関連ＲＩＣ ＳＤＫ及びＯ－ＲＡＮコンポーネントとアプリケーションを接続する分散ニアＲＴ ＲＩＣを介して（データを受信し、そのデータ処理の結果を提供するために）、他のＯ－ＲＡＮコンポーネントと通信する。いくつかの実施形態において、これらの実施形態の制御又はエッジアプリケーションは、図１５の処理１５００と同様の処理を実行する。

【0112】

上記のハードウェアアクセラレータへの直接パススルーアクセスは、Ｏ－ＲＡＮに非常に有益である。ＲＩＣは、以前はＲＡＮソフトウェア（ＣＵ及びＤＵ）に組み込まれていたインテリジェンスを切り離し、クラウドに移動することについてのすべてに関する。この利点の１つは、クラウド内のより高度なコンピューティングをｘＡｐｐ及びエッジ動作（ＭＬ、ディープラーニング、制御アルゴリズムの強化学習など）に使用することである。セルサイトに近いＤＵは、ネットワークキャップＸが非常に高いため、各セルサイトにＧＰＵを配置することは経済的に実現不可能であり、通常、事前計算を実行できない。

【0113】

ＳＤＤＣ内のハードウェアアクセラレータ（ＧＰＵ、ＦＰＧＡ、ｅＡＳＩＣ、ＡＳＩＣ）を使用することにより、いくつかの実施形態は、クラウド内で複雑な制御アルゴリズムを実行する。このようなｘＡｐｐの例には、上述した、大規模ＭＩＭＯビームフォーミング及びマルチユーザ（ＭＵ） ＭＩＭＯユーザペアリングが含まれる。一般に、膨大な並列化の利点を得られるｘＡｐｐは、ＧＰＵ又はその他のアクセラレータの利点を得られる。ＡＳＩＣの使用は、チャネルデコード／エンコード（ターボ符号化、ＬＤＰＣ符号化など）に有益である。いくつかの実施形態において、ＲＩＣは、通常、ｘＡｐｐｓと同じワーカＶＭ上にある。しかしながら、他の実施形態では、ＲＩＣは、ＧＰＵ及び他のハードウェアアクセラレータを必要とするより多くのｘＡｐｐが、ＧＰＵ及び／又は他のハードウェアアクセラレータを有するホスト上で実行できるように、異なるホストコンピュータ上で動作する。

【0114】

図１９は、いくつかの実施形態が、ホストコンピュータのハードウェアアクセラレータへの直接的なパススルーアクセスを有するＯ－ＲＡＮアプリケーションをデプロイするために使用する処理を示す。ホストコンピュータにアプリケーションをインストールするために、処理１９００は、ホストコンピュータのハードウェアアクセラレータへのアプリケーションのパススルーアクセスを構成するための記述を含む、１つ以上のインストールファイルのセットを（１９０５において）選択する。いくつかの実施形態では、ファイルのセットは、そのコンピュータのハードウェアアクセラレータへのアプリケーションのための直接的なパススルーアクセスを指定する１つの記述ファイルを含む。

【0115】

処理１９００は、パススルーアクセスに関する記述に基づいて、アプリケーションに関連する特定のハードウェアアクセラレータドライバからハードウェアアクセラレータにコールを渡すためにホストコンピュータ上で動作するプログラムを、特定のハードウェアアクセラレータドライバとハードウェアアクセラレータとの間でホストコンピュータ上で動作する１つ以上のドライバのセットを介在させることなく、構成するインストールファイルのセットを（１９１０において）使用する。この構成により、アプリケーションは、アプリケーションの動作を実行するようにハードウェアアクセラレータに指示し、動作の結果をハードウェアアクセラレータから受信する場合に、介在するドライバのセットをバイパスすることができる。

【0116】

いくつかの実施形態では１９１０で構成されるプログラムはホストのオペレーティングシステムであり、他の実施形態ではホストコンピュータ上で実行されるハイパーバイザである。さらに別の実施形態では、プログラムは仮想マシン（ＶＭ）であり、アプリケーションはポッド上又はＶＭ上で実行されるコンテナ上で動作する。処理１９００は、１９０５において選択された残りのインストールファイルのセットを処理してアプリケーションのインストールを（１９１５において）完了し、終了する。他の実施形態では、処理１９００は、１９１０における第１の動作としてではなく、その最後の動作としてプログラムの構成を実行する。さらに別の実施形態では、これは、その介在するインストール動作の１つとして、この構成を実行する。

【0117】

選択及び構成を実行する前に、いくつかの実施形態のデプロイプロセスは、いくつかのホストコンピュータからホストコンピュータを、アプリケーションをインストールすべきコンピュータとして識別する。いくつかの実施形態の処理は、アプリケーションがハードウェアアクセラレータを必要とすることを判定し、各々がハードウェアアクセラレータを構成するホストコンピュータのセットを識別し、ホストコンピュータのセットからホストコンピュータを選択することによって、ホストコンピュータを識別する。このプロセスは、（１）選択されたホストコンピュータ上で実行される１つ以上の他のアプリケーションのセットとアプリケーションが通信する必要があると判定すること、及び（２）ホストコンピュータ上で同時に実行される他のアプリケーションのセットとしてホストコンピュータを選択することによって、ホストコンピュータを選択する。このように、選択したホストコンピュータ上に他のアプリケーションのセットと一緒にアプリケーションをインストールすると、アプリケーションと他のアプリケーションのセットとの間の通信遅延が削減される。

【0118】

いくつかの実施形態は、Ｏ－ＲＡＮ制御又はエッジアプリケーションのハードウェアアクセラレータドライバを有し、アプリケーションと同じホストコンピュータ上で実行される、介在する仮想化アプリケーション（例えば、ハイパーバイザ）によって提供される仮想化ハードウェアアクセラレータと通信する。例えば、いくつかの実施形態の方法は、ホストコンピュータ上で実行されるいくつかのマシン間でホストコンピュータのリソースを共有するために、ホストコンピュータ上に仮想化アプリケーションをデプロイする。このコンピュータには、１つ以上の物理ハードウェアアクセラレータの第１セットがある。

【0119】

この方法は、いくつかのマシンにいくつかのアプリケーションをデプロイし、Ｏ－ＲＡＮコンポーネントのセットに対していくつかのＯ－ＲＡＮ関連動作を実行する。仮想化アプリケーションを介して、この方法は、仮想化アプリケーションによって物理ハードウェアアクセラレータの第１のセットにマッピングされる２つ以上の仮想ハードウェアアクセラレータの第２のセットを定義する。この方法では、異なる仮想ハードウェアアクセラレータを異なるアプリケーションに割り当てる。この方法では、割り当てられた仮想ハードウェアアクセラレータを使用して動作を実行するようにアプリケーションを構成することもできる。

【0120】

いくつかの実施形態では、デプロイされたマシンはポッドであり、アプリケーションはポッド上で動作するようにデプロイされる。少なくとも２つのポッドは、仮想化アプリケーションの上位で動作する１つのＶＭ上で動作する。このＶＭには、２つのポッド上で動作する２つのアプリケーションの２つの異なる仮想ハードウェアアクセラレータと通信するように設定されたハードウェアアクセラレータドライバが含まれる。他の実施形態では、複数のポッドは、仮想化アプリケーションの上で実行される１つのＶＭ上で実行され、各ポッドは、そのドライバに割り当てられた仮想ハードウェアアクセラレータと通信するように構成されたハードウェアアクセラレータドライバを有する。

【0121】

図２０は、それらの演算の一部又は全部を実行するために、ホストコンピュータ２０１０上で実行されるハイパーバイザ２００８によって定義される仮想ハードウェアアクセラレータ２０５２及び２０５４へのパススルーアクセスを有するＣＰ又はエッジアプリケーション２００２の例を示す。説明するように、各アプリケーション２００２は、仮想アクセラレータ２０５２又は２０５４への直接的なパススルーアクセスを有するアクセラレータドライバ２０１２を有するポッド２００４上で実行される。各ポッド２００４は、ホストコンピュータのハイパーバイザ２００８上で動作するＶＭ２００６内で動作する（すなわち、ＶＭ２００６上で動作する）。

【0122】

各ポッドのアクセラレータドライバ２０１２は、仮想アクセラレータ２０５２又は２０５４への直接アクセスを有し、このアクセスは、ＶＭ２００６及びハイパーバイザ２００８のアクセラレータドライバ２０１４及び２０１６をバイパスする。いくつかの実施形態では、ハイパーバイザ２００８は、ホストコンピュータ２０１０のオペレーティングシステム（図示せず）上で動作する。これらの実施形態では、仮想アクセラレータ２０５２又は２０５４への各ポッドのアクセラレータドライバ２０１２の直接アクセスも、オペレーティングシステムのハードウェアアクセラレータドライバをバイパスする。

【0123】

説明するように、仮想アクセラレータ２０５２及び２０５４は、ハイパーバイザ２００８のアクセラレータマネージャ２０６０を介してハードウェアアクセラレータ２０５０と通信する。アクセラレータマネージャ２０６０は、仮想アクセラレータ２０５２及び２０５４（並びにそれらに関連するアプリケーション２００２）が１つのハードウェアアクセラレータ２０５０を共有することを可能にし、このアクセラレータ２０５０と共に、それぞれのアプリケーション及びポッド２００２及び２００４専用であるかのように動作する。このようなハードウェアアクセラレータ２０５０の例には、グラフィカルプロセッシングユニット（ＧＰＵ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、及び構造化ＡＳＩＣが含まれる。

【0124】

仮想アクセラレータ２０５２又は２０５４と通信するために、いくつかの実施形態の各アプリケーション２００２は、ポッド２００４上で実行されるＲＩＣ ＳＤＫ２０３０を介して通信する。例えば、いくつかの実施形態では、各アプリケーション２００２は、ＲＩＣ ＳＤＫ２０３０の高レベルＡＰＩを使用して、その仮想アクセラレータ２０５２又は２０５４と通信する。次に、ＲＩＣ ＳＤＫ２０３０は、高レベルＡＰＩを、各マシンのドライバ２０１２と通信するために必要とされる低レベルＡＰＩに変換し、これは、通信を仮想アクセラレータ２０５２又は２０５４に中継する。次に、仮想アクセラレータ２０５２又は２０５４は、アクセラレータマネージャ２０６０を介してハードウェアアクセラレータ２０５０に通信を中継する。

【0125】

図１４を参照して上述したように、いくつかの実施形態では、低レベルＡＰＩは、ハードウェアアクセラレータ２０５０の販売に関連する第１の会社によって提供され、一方、ＲＩＣ ＳＤＫ２０３０は、ＲＩＣ ＳＤＫ２０３０の販売に関連する第２の会社によって提供される。いくつかの実施形態では、ＲＩＣ ＳＤＫ２０３０によって使用される低レベルＡＰＩは、ハードウェアアクセラレータ２０５０に関連するＡＰＩライブラリ２０３２において規定されるＡＰＩである。各アプリケーション２００２は、アクセラレータマネージャ２０６０、その仮想アクセラレータ２０５２又は２０５４、そのドライバ２０１２及びそのＲＩＣ ＳＤＫ２０３０を介して、ハードウェアアクセラレータ２０５０の動作の結果を受信する。

【0126】

低遅延のニアＲＴ ＲＩＣを提供するために、いくつかの実施形態は、ＲＩＣ機能を、同一のホストコンピュータ又は異なるホストコンピュータ上で動作する異なる（例えば、ＶＭ又はポッド上で動作する）マシン上で動作するいくつかの異なるコンポーネントに分離する。また、いくつかの実施形態は、これらのマシン間に高速なインタフェースを提供する。これらのインタフェースの一部又は全部は、ニアＲＴ ＲＩＣの重要な動作（例えば、データパス処理）が、１つ以上のコンポーネントをストールさせる複数の要求のために遅延しないことを保証するために、ノンブロッキング、ロックレスの態様で動作する。さらに、これらのＲＩＣコンポーネントのそれぞれは、コンポーネントのあるプロセスがコンポーネントの別のプロセスの動作をブロックできないように、ノンブロッキングの態様で動作するように設計された内部アーキテクチャも有する。これらの低遅延機能はすべて、ニアＲＴ ＲＩＣがＥ２ノードとｘＡｐｐ間の高速ＩＯとして機能できるようにする。

【0127】

図２１は、いくつかの異なるマシン上で動作するいくつかのコンポーネントを有する、ニアＲＴ ＲＩＣ２１００の例を示す。この例では、ニアＲＴ ＲＩＣが３つのポッドに分割されている。これらはデータパスポッド２１０５、サービスポッド２１１０、ＳＤＬポッド２１１５である。いくつかの実施形態では、このＲＩＣは、（１）Ｅ２ノード２１１８とｘＡｐｐｓ２１２０との間のＥ２ＡＰメッセージを処理し、（２）Ｅ２ノード２１１８とのコネクションを管理し、（３）Ｅ２ノードへのｘＡｐｐサブスクリプションを処理し、（４）ｘＡｐｐライブネス動作を処理する。ＲＩＣ２１００は、さまざまなコンポーネント間、Ｅ２ノードとｘＡｐｐｓ間、及びＥ２ノード／ｘＡｐｐｓとＲＩＣコンポーネント間で、信頼性の高い低遅延メッセージングを提供する。ＲＩＣの低遅延アーキテクチャの一部は、異なるポッドを使用してデータＩＯ、サービス、及びＳＤＬ動作を実施することに起因する。そのため、それらが複数の異なるポッドで実行する動作のそれぞれのニーズに基づいて、異なるリソース割り当て及び管理動作をこれらのポッドのそれぞれに提供できる。

【0128】

３つのＲＩＣポッド２１０５、２１１０、及び２１１５はそれぞれ、１つ以上のｘＡｐｐポッド２１２０と通信する。いくつかの実施形態において、各ポッド（２１０５、２１１０、２１１５又は２１２０）は、ポッドの固有のニーズ（すなわち、各ポッドによって実行されるデータパス、サービス及び記憶動作）に従って、ハードウェアリソース（例えば、ＣＰＵ、メモリ、ディスクストレージ、ネットワークＩＯなど）が割り当てられる。また、一部の実施形態では、各ポッドには、各ポッドの固有のニーズに一致する独自の高可用性及びライフサイクル更新設定がある。

【0129】

サービスポッド２１１０は、いくつかの実施形態において、ｘＡｐｐオンボーディング、登録、ＦＣＡＰＳ（障害、構成、アカウンティング、性能、セキュリティ）、及びその他のサービスを実行する。例えば、いくつかの実施形態では、サービスポッド２１１０は、ニアＲＴ ＲＩＣの管理サービス５５４を提供し、О１終端５８０及びＡ１終端５８２をＳＭＯ及びその関連する非ＲＴ ＲＩＣに実行する。いくつかの実施形態では、これらのコンポーネント５５４、５８０、及び５８２のそれぞれは、サービスポッド２１１０内の別個のコンテナ上で動作し、他の実施形態では、これらのコンポーネントの２つ以上は、サービスポッド２１１０内の１つのコンテナ上で動作する。

【0130】

上述のように、いくつかの実施形態では、Ａ１インタフェースは、ニアＲＴ ＲＩＣと非ＲＴ ＲＩＣとの間にある。このインタフェースを介して、ニアＲＴ ＲＩＣはＥ２ノード（例えばＣＵ及びＤＵ）によって報告される関連ネットワーク情報を中継し、非ＲＴ ＲＩＣはＥ２ノード（例えば非ＲＴの粒度での制御ユースケース動作用）の制御コマンドを提供する。О１インタフェースは、ニアＲＴ ＲＩＣとＳＭＯの間にあり、いくつかの実施形態では、検出、構成、リソース管理、自動スケーリング、ライフサイクル管理、及びフォールトトレランスのために使用される。

【0131】

いくつかの実施形態におけるＲＩＣ管理サービス５５４は、ニアＲＴ ＲＩＣがｘＡｐｐｓ及び他のＲＩＣコンポーネントに提供するサービスを含む。ｘＡｐｐｓに提供されるサービスの例としては、ｘＡｐｐサービスレジストリ／ディレクトリ（ｘＡｐｐｓは、分散ニアＲＴ ＲＩＣに関連付けられた他のｘＡｐｐｓと、これらの他のｘＡｐｐｓによって実行される動作を識別するために使用できる）、及びＦＣＡＰ動作（メトリック収集、ポリシープロビジョニング、構成など）がある。いくつかの実施形態において、ｘＡｐｐｓは、サービスレジストリ／ディレクトリに照会して、特定のサービスを実行する他のｘＡｐｐｓ又は他のｘＡｐｐｓを識別することができ、ｘＡｐｐｓがディレクトリに追加されたときに、ｘＡｐｐｓ及びその機能に関する通知を受信するように登録することができる。

【0132】

ｘＡｐｐ用のサービスポッド２１１０によって実行されるＦＣＡＰ動作の例には、アラートを発生させるために分析するＣＰＵ及びメモリ使用率を収集するメトリック、ｘＡｐｐｓを設定又は再設定するための構成動作、ｘＡｐｐｓからメトリックを収集してｘＡｐｐのパフォーマンスを定量化するために分析するためにアカウンティング及びパフォーマンス動作に必要なデータを収集するためのアカウンティング動作が含まれる。

【0133】

その他のＲＩＣコンポーネント（データパスポッド２１０５及びＳＤＬポッド２１１５ など）の場合、サービスポッド２１１０はメトリック収集、ポリシープロビジョニング、設定などのサービスも実行する。サービスポッド２１１０は、集中制御装置、すなわちＳＭＯの方向で動作を実行するローカル制御装置と見ることができる。ＳＭＯを介して、サービスポッド２１１０はｘＡｐｐｓ及びその他のＲＩＣコンポーネントに配布する構成とポリシーを受信する。また、ＳＭＯに対して、サービスポッド ２１１０は、ｘＡｐｐｓ及び／又はＲＩＣコンポーネント（例えば、データパスポッド及びＳＤＬポッド）から収集されたメトリクス、ログ及びトレースデータを提供する。いくつかの実施形態では、サービスポッドは、他のポッドとは独立してスケーリング（例えば、複製）し、バックアップすることができる。いくつかの実施形態において、サービスポッドは、ＳＭＯの時系列データベースのためのキャッシュであるデータキャッシュを有する。このキャッシュでは、サービスポッドは、このデータをＳＭＯデータベースにアップロードする前に、ｘＡｐｐｓ及び１つ以上のＲＩＣコンポーネントから収集した統計、ログ、トレースデータ、及びその他のメトリクスを保存する。

【0134】

ＳＤＬポッド２１１５は、ＳＤＬ５６０及びそれに関連するデータベース５７０を実施する。以下にさらに説明するように、いくつかの実施形態のＳＤＬポッド２１１５は、また、１つ以上のサービスコンテナを実行して、ＳＤＬに記憶されたデータ上で１つ以上の前処理又は後処理サービスを実行する。サービスポッドと同様に、いくつかの実施形態におけるＳＤＬポッドは、他のポッドとは独立してスケーリング（例えば、複製）し、バックアップすることができる。

【0135】

データパスポッド２１０５には、いくつかの重要なニアＲＴ ＲＩＣコンポーネントが含まれている。これらは、Ｅ２終端５８４、コンフリクト緩和５５０、アプリケーションサブスクリプション管理５５２、及びＲＩＣ ＳＤＫインタフェース２１５０である。以下にさらに説明するように、いくつかの実施形態におけるこれらのデータパスサービスの一部又は全部は、データパスポッドのデータパススレッド及び制御スレッドに組み込まれる。他の実施形態では、データパスサービスは、データＩＯスレッド、複数のデータ処理スレッド、及び制御スレッドに組み込まれる。

【0136】

スレッドは、コンピュータ上で実行されるプロセスのコンポーネントである。プロセスは、アプリケーションであっても、より大きなアプリケーションの一部であってもかまわない。スレッドは、プログラムされた命令のシーケンスであり、プロセスの他のスレッドから独立して管理することができる。プロセスに割り当てられたメモリを共有しながら、特定のプロセスの複数のスレッドを同時に実行できる（マルチコアプロセッサのマルチスレッド機能を使用するなど）。マルチスレッドは、１つのプロセスのコンテキスト内に複数のスレッドを存在させるプログラミング及び実行モデルである。これらのスレッドはプロセスのリソースを共有するが、独立して実行できる。

【0137】

いくつかの実施形態における制御スレッドは、データパススレッドのためのサービスポッド及びＳＤＬポッドとのインタフェースであるが、他の実施形態では、データパススレッドのためのサービスポッドへのインタフェースである（データパススレッドはＳＤＬポッドと直接通信できるため）。これらのいずれかのアプローチの制御スレッドは、データパスの低速な制御関連動作を実行し、一方、１つ以上のデータパススレッドは、データパスの高速なＩＯ動作を実行する。いくつかの実施形態における制御スレッドは、データパススレッドの動作だけでなく、それ自体の動作を構成するための構成データを受信するために、サービスポッドとインタフェースを有する。

【0138】

データパススレッドをデータＩＯスレッド及び複数データ処理スレッドに分離する実施形態は、データパススレッドのより計算量の多い演算を複数のデータパス処理スレッドにプッシュすることにより、データＩＯをさらに最適化し、それにより、データＩＯスレッドで実行する計算量の少ない演算を可能にする。これらの最適化は両方とも、高速データパスＩＯ（不要な遅延を生じないもの）を確保することを意図しており、ニアＲＴ ＲＩＣがＥ２ノード２１１８とｘＡｐｐｓ２１２０間の高速インタフェースとして機能できるようにする。

【0139】

上述したように、ポッド２１０５、２１１０及び２１１５は、高速ポッドインターフェイスを介して通信する。いくつかの実施形態では、ポッドｔｏポッド接続は、ＳＣＴＰ（ストリーミング制御伝送プロトコル）又はさらに高速な共有メモリ（ｓｈｍｅｍ）接続を介して確立される。いくつかの実施形態では、共有メモリ接続は、同じホストコンピュータ上で実行されるポッドの対の間でのみ使用される。このようなポッドのペアの例としては、（１）データパスポッドとＳＤＬポッド、（２）データパスポッドとサービスポッド、（３）サービスポッドとＳＤＬポッド、（４）ｘＡｐｐポッドとデータパスポッド、（５）ｘＡｐｐポッドとＳＤＬポッドなどがある。共有メモリはロックレスであり、いくつかの実施形態ではそれへのアクセスは非ブロッキングである。他の実施形態では、サービスポッド２１１０と他のポッド２１０５、＃１１５、及び２１２０との間の低速インタフェース（例えば、ｇＲＰＣ）をサービスポッドとして使用するが、他のポッドほど重要ではない。

【0140】

いくつかの実施形態におけるニアＲＴ ＲＩＣの異なるポッド（例えば、２１０５、２１１０及び２１１５）は、同じホストコンピュータ上で動作することができ、又は２つ以上のホストコンピュータ上で動作することができる。他の実施形態では、１つ以上のポッド（例えば、サービスポッド２１１０）は、常に、他のポッド（例えば、データパスポッド２１０５及びＳＤＬポッド２１１５）以外の別個のホストコンピュータ上で動作する。また、いくつかの実施形態では、ポッド２１０５、２１１０及び２１１５は、１つ以上のｘＡｐｐポッド２２２０ａと共に１つのホストコンピュータ２２０５上で動作し、他のｘＡｐｐポッド２２２０ｂは、図２２に示されるように、他のホストコンピュータ２２１０上で動作する。他の実施形態では、２つのポッド２１０５、２１１０及び２１１５は、１つ以上のｘＡｐｐポッドと共に１つのホストコンピュータ上で動作し、一方のポッド２１０５、２１１０及び２１１５は、１つ以上のｘＡｐｐポッドと共に別のホストコンピュータ上で動作する。

【0141】

例えば、図２３は、２つのｘＡｐｐポッド２３２０ａと共にホストコンピュータ２３００上で実行されるデータパスポッド２１０５及びサービスポッド２１１０を示し、一方ＳＤＬポッド２１１５は２つのｘＡｐｐポッド２３２０ｂと共にホストコンピュータ２３１０上で動作する。いくつかの実施形態では、ハードウェアアクセラレータを必要とするポッドは、そのようなハードウェアリソースを有するホストコンピュータ上に置かれ、これらのアクセラレータを必要としないポッドは、上述のように、これらのアクセラレータを持たないホストコンピュータ上に置かれる。いくつかの実施形態では、ＳＤＬポッド及びｘＡｐｐポッドはハードウェアアクセラレータを使用し、データパスポッド及びサービスポッドは使用しない。ハードウェアアクセラレータから恩恵を受けることができるポッドの様々な例、及びこれらのアクセラレータへのバイパスについては、上記及び以下でさらに説明する。

【0142】

また、いくつかのニアＲＴ ＲＩＣは、ポッドを用いて実装されるものとして上記及び以下で説明されるが、他の実施形態のニアＲＴ ＲＩＣは、ＲＩＣコンポーネントを実装するためにＶＭを使用する。さらに、ポッドで異なるＲＩＣコンポーネントを実装する実施形態であっても、ポッドの一部又はすべては、軽量ＶＭ（例えば、ＶＭｗａｒｅ、Ｉｎｃ．が提供するＰｈｏｔｏｎ ＶＭ）のようなＶＭ上で動作する。

【0143】

ポッド間の高速通信インタフェースを使用することに加えて、いくつかの実施形態では、ポッドの一部又は全部が、ノンブロッキング、ロックレス通信プロトコル及びアーキテクチャを使用する。たとえば、データパスポッド２１０５は、このポッドを構成するスレッドとプロセス間で非ブロッキングのロックレス通信を使用する。データパスポッド２１０５は、サービスポッド２１１０、ＳＤＬポッド２１１５、ｘＡｐｐポッド２１２０との通信時に、ノンブロッキングロックレス通信も使用する。ノンブロッキング通信では、第２のコンポーネントに要求を送信する第１のコンポーネントは、第２のコンポーネントが処理する要求が多すぎる場合に、第２のコンポーネントの動作を停止させることはない。このような場合、第２のコンポーネントは、後で第１のコンポーネントに要求を再送信するように指示する。データパスポッドは、スレッドハンドオフを使用しない単一スレッド処理を使用するため、ロックレス通信を使用する。そのため、別のプロセススレッドが一時的な期間にメモリを変更しないようにするために、メモリの一部をロックする必要はない。

【0144】

データパスポッド２１０５のＲＩＣ ＳＤＫインタフェース２１５０とｘＡｐｐポッド２１２０のＲＩＣ ＳＤＫ２１１２との間の通信インタフェースもまた、いくつかの実施形態において新規である。いくつかの実施形態において、このインタフェースは、Ｅ２ノードから受信したＥ２ＡＰメッセージのヘッダを解析し、Ｅ２ＡＰメッセージのＥ２ＳＭペイロードを、元のＥ２ＡＰヘッダの一部又は全部とともにカプセル化する新しいカプセル化ヘッダに、解析されたコンポーネントの一部又は全部を格納する。このカプセル化を行う際に、いくつかの実施形態のＳＤＫインタフェース２１５０は、あるポッドから別のポッドへの通信のためのメッセージサイズオーバヘッドを低減する（例えば、Ｅ２グローバルＩＤ値のサイズを低減するなど）ために、データパッキングを効率的に実行するなどの特定の最適化を実行する。これらの最適化により、ニアＲＴ ＲＩＣデータパスポッド及びｘＡｐｐポッド通信の効率が向上する。

【0145】

他の実施形態におけるニアＲＴ ＲＩＣは、１つ以上の他のポッドを有する。たとえば、図２４は、ポッド２１０５、２１１０、及び２１１５に加えて、ライフサイクル管理（ＬＣＭ）ポッド２４０５も含むニアＲＴ ＲＩＣ２４００を示している。ＬＣＭポッドは、ニアＲＴ ＲＩＣ２４００の他のポッド２１０５、２１１０、及び２１１５のそれぞれをアップグレードする特別なサービスポッドである。ライフサイクル管理をサービスポッド２１１０から分離すると、サービスポッド２１１０をより簡単にアップグレードできる。

【0146】

いくつかの実施形態において、ＬＣＭポッド２４０５は、異なるポッドをアップグレードするために異なるアップグレード方法を使用する。例えば、いくつかの実施形態のＬＣＭポッドは、ＳＤＬデータストレージを複製し、ＳＤＬのヒットレスアップグレードを実行するために、アクティブデータストアから別のスタンバイデータストアにシームレスに移行する。一方、データパスポッドをアップグレードするには、ＬＣＭポッドの手順がより複雑になる。これは、アクティブデータパスポッドとスタンバイデータパスポッドがＥ２ノードと各ｘＡｐｐのデュアルホーム接続に設定され、アクティブデータパスポッドがスタンバイデータパスとの状態をレプリケートするように設定されるためである。

【0147】

図２５は、いくつかの実施形態について、ニアＲＴ ＲＩＣ２５００のより詳細な図を示す。説明するように、ニアＲＴ ＲＩＣ２５００は、データパスポッド２５０５、サービスポッド２５１０及びＳＤＬポッド２５１５を含む。ＳＤＬポッド２５１５は、ＲＩＣ２５００のＳＤＬエージェント２５２６及び共有ＳＤＬストレージ２５２８を含み、一方、サービスポッド２５１０は、О１及びＡ１終端インタフェース２５３５及び２５３７と共にサービスエージェント２５２４を含む。データパスポッド２５０５は、データパススレッド２５０７と制御スレッド２５０９とを含む。

【0148】

データパススレッド２５０７は、Ｅ２ノード２５１８とｘＡｐｐｓ２５２０との間のニアＲＴ ＲＩＣの高速データパスＩＯを提供する。いくつかの実施形態におけるＲＩＣのデータプレーン能力は、データパスポッドのデータパス処理のための負荷を共有する１つの制御スレッド及び複数のデータパススレッドを備えたＲＩＣデータパスＩＯを実装することによって、スケールアップすることができる。いくつかのこのような実装について、以下にさらに説明する。制御スレッド２５０９は、ＲＩＣのデータパスに関連するいくつかの制御動作を実行する。ニアＲＴ ＲＩＣ２５００は、データＩＯ動作を高速にする必要があり、低速で動作可能な制御動作によって速度を落とすべきではないので、制御スレッドとデータパススレッドを分離する。いくつかの実施形態では、制御及びデータパススレッドは、単一プロセス内の２つのスレッドである（すなわち、同じ共有メモリアドレス空間内で実行される）。

【0149】

いくつかの実施形態では、これらのスレッドのそれぞれは、これらの他のコンポーネントと通信する程度に、このアーキテクチャの他のコンポーネント（例えば、ＲＩＣ ＳＤＫ、サービスポッドエージェント、ＳＤＬエージェント、及び／又はＥ２ノード）と通信するために、非ブロッキングのロックレスインタフェースを使用する。また、いくつかの実施形態では、両方のスレッドは、最小限のＯＳシステムコールを使用し、無限ループとして実行する。さらに後述するように、データパススレッド及び制御スレッドは、データパススレッドから制御スレッドへのメッセージ及び制御スレッドからデータパススレッドへの他の処理メッセージを処理する１つのリングと共に、２つの円形リング２５２２（ｃｂｕｆと呼ばれる）を介してデータを交換する。

【0150】

制御スレッド２５０９は、Ｅ２ノード２５１８、ＳＭＯ２５３０（サービスポッドエージェント２５２４を介して）、ｘＡｐｐｓ（例えば、ＳＣＴＰを介して）、及びＳＤＬレイヤ（ＳＤＬエージェント２５２６を介して）への制御インタフェースとして機能する。いくつかの実施形態では、制御スレッドは、これらの外部エンティティと通信するためのメインスレッドであるが、以下でさらに説明するように、いくつかの実施形態におけるデータパススレッドは、ＳＤＬエージェント２５２６を介してＳＤＬ２５１５と通信する。

【0151】

いくつかの実施形態における制御スレッド２５０９は、すべての制御機能を処理する。このスレッドは、様々な制御パラメータを他の機能に送信し、いくつかの実施形態では、アドミッション制御を実施する。他の実施形態では、データパススレッド２５０７は、アドミッション制御を実施し、サービスポッドを介したＳＭＯは、アドミッション制御を指定する。いくつかの実施形態において、制御スレッド２５０９は、ＳＣＴＰを介したｘＡｐｐポッドのＲＩＣ ＳＤＫとの制御チャネル通信を有する。他の実施形態では、制御スレッドは、ｇＲＰＣを介してｘＡｐｐポッドのＲＩＣ ＳＤＫと通信する。また、いくつかの実施形態では、制御スレッドは、ｘＡｐｐポッド及びデータパスポッドが同じホストコンピュータ上で動作する場合、共有メモリ（ｓｈｍｅｍ）を介してＲＩＣ ＳＤＫと通信する。

【0152】

制御スレッド２５０９はまた、データパススレッド２５０７によって生成された統計、ログ及びトレースデータを伝送するための伝送機構を提供する。いくつかの実施形態では、このデータの一部又は全部は、ＳＤＬエージェント２５２６を介してＳＤＬポッド２５１５に、及び／又はサービスエージェント２５２４を介してＳＭＯ２５３０に転送される。いくつかの実施形態における制御スレッド２５０９は、Ｅ２ノードピアとセキュリティ鍵をネゴシエートし、これらのキーをデータパススレッドに渡し、データパススレッドは、それらのキーを使用して暗号化／復号化動作を実行する。

【0153】

データパススレッド２５０７は、Ｅ２ノードとｘＡｐｐ間の高速ＩＯを提供する。このスレッドは、ＲＩＣ ＳＤＫインタフェースとＥ２終了動作、及びいくつかの実施形態でのコンフリクト緩和とｘＡｐｐサブスクリプション動作を処理する。このスレッドは、Ｅ２ＡＰメッセージのＡＳＮ．１デコードを実行して、メッセージデータを抽出する。いくつかの実施形態では、データパススレッドは、これらのメッセージのＥ２ＳＭペイロードをデコードしない。データパススレッド２５０７は、Ｅ２及びｘＡｐｐメッセージとシーケンスを検証する。いくつかの実施形態では、メッセージタイプは、Ｅ２ノードセットアップ及びサービス更新、Ｅ２ノード指示レポート、Ｅ２ノードデータに対するｘＡｐｐ開始サブスクリプション、及びｘＡｐｐ開始制御要求を含む。

【0154】

いくつかの実施形態におけるデータパススレッド２５０７は、ｘＡｐｐｓの代わりに状態（例えば、Ｅ２ノードの状態、Ｅ２ノードへのサブスクリプションなど）を作成し維持するために、Ｅ２状態マシンを実行する。また、いくつかの実施形態では、データパススレッドは、データを要求するｘＡｐｐｓにメッセージを送信するためにテーブルルックアップを実行する。このスレッドは、Ｅ２ノードへのｘＡｐｐｓからの制御要求も処理し、これらの要求への応答をＥ２ノードからｘＡｐｐｓに転送する。

【0155】

データパススレッドは、ｘＡｐｐｓが別のホストコンピュータ上にある場合はＳＣＴＰを介して、ｘＡｐｐｓが同じホストコンピュータ上にある場合は共有メモリを介してｘＡｐｐｓと通信する。いくつかの実施形態では、ｘＡｐｐメッセージは、破損を検出するためのＣＲＣビットを有する。これらのメッセージはまた、タイムスタンプを運び、いくつかの実施形態では圧縮することができる。データパススレッド２５０７は、複数のサブスクリプションに対してデータレプリケーションを実行する。また、データパススレッド２５０７は、データメッセージの署名、暗号化、及び復号化などによって、データパスセキュリティ動作を実行する。

【0156】

上述し、さらに後述するように、データパススレッド２５０７は、一対のリング２５２２を介して、一部の実施形態では制御スレッド２５０９と通信する。いくつかの実施形態において、２つのスレッド間のメッセージの周波数は、リングペア当たりのサブミリ秒から秒まで調整可能である（例えば、構成可能である）。制御スレッドを介して、データパススレッド２５０７は、構成データ更新及び状態変更を受信する。データパススレッド２５０７は、統計、ログ及びトレースを生成し、生成された統計、ログ及びトレースデータをＳＤＬ内に記憶するため、及び／又はＳＭＯに提供するために制御スレッドに提供する。

【0157】

データパススレッド２５０７は、複数のｘＡｐｐが同じパラメータを同じＥ２ノードに同時に設定しようとした場合にもコンフリクト管理動作を実行する。たとえば、コンフリクト管理動作では、２つのｘＡｐｐが短期間内にモバイルネットワーク設定（アンテナの方向など）を異なる方法で変更しようとしないようにする。いくつかの実施形態では、データパススレッドのコンフリクト管理は、異なるタイプのコンフリクトに対処するために異なる方法論を採用する。例えば、（１）ある要求のセットについて、ある時間の間、コンフリクトする先の第１の要求を受信した後に、パラメータを変更する第２の要求を拒否し、（２）別の要求のセットについて、あるｘＡｐｐからのパラメータに関する要求を、別の優先度の高いｘＡｐｐが同じパラメータに対するコンフリクトする要求を行ったときに拒否し、（３）別のパラメータのセットに関する別の要求のセットについて、特定の時間の間にこのような要求を行うことが許されるｘＡｐｐｓによって行われた要求のみを受け入れる。これらのコンフリクトを処理するためのポリシーは、サービスポッドのエージェント２５２４を介してＳＭＯ２５３０によって提供される。

【0158】

図２５では、各ｘＡｐｐポッド２５２０は１つ以上のｘＡｐｐｓ２５３２を実行でき、ｘＡｐｐポッドで実行されるＲＩＣ ＳＤＫ２５３４を介してデータパスポッド２５０５、ＳＤＬポッド２５１５及びサービスポッド２５１０とインタフェースする。各ＲＩＣ ＳＤＫは、ｘＡｐｐｓがＲＩＣ及びＥ２ノードと通信するための高レベルインタフェースを提供する。この高レベルインタフェースは、基盤となる実装の詳細を非表示にする。ＲＩＣ ＳＤＫは、高速データＩＯ通信チャネル（共有メモリーやＳＣＴＰなど）を介してＲＩＣインスタンスと通信する。

【0159】

また、ＲＩＣ ＳＤＫは、ｘＡｐｐオンボーディング、登録、機能、サブスクリプション、ＦＣＡＰＳなどのｘＡｐｐ制御動作のために、サービスポッド２５１０及び制御スレッド２５０９との制御通信チャネルも使用する。いくつかの実施形態では、ＳＤＫと制御スレッド２５０９との間の制御チャネル通信は、ｘＡｐｐポッド（及びそのＳＤＫ）とデータパスポッドが同じホストコンピュータ上で動作するときには共有メモリを介し、異なるコンピュータ上で動作するときにはＳＣＴＰを介して行われる。また、いくつかの実施形態では、ｘＡｐｐポッド（及びそのＳＤＫ）とサービスポッドとの間の制御チャネル通信は、ＳＤＫとサービスポッドが同じホストコンピュータ上で動作する場合には共有メモリを介し、異なるコンピュータ上で動作する場合にはｇＲＰＣを介して行われる。その他の実施形態では、ｘＡｐｐポッド（及びそのＳＤＫ）とサービスポッドが異なるホストコンピュータで動作する場合に、ＳＤＫとサービスポッド間の通信にＳＣＴＰを使用する。

【0160】

いくつかの実施形態では、ＲＩＣ ＳＤＫがｇＲＰＣを介してサービスポッドと通信するときに、ｐｒｏｔｏ ｂｕｆｓを使用する。また、ＲＩＣ ＳＤＫとデータパスポッドとの通信が共有メモリを介して行われるいくつかの実施形態では、共有メモリ通信は、プロトコルｂｕｆを使用する。ＲＩＣ ＳＤＫには、Ｅ２ノードとの間のＥ２メッセージなど、データ関数用のＡＰＩがある。これらのＡＰＩには、オンボーディングｘＡｐｐ（名前、バージョン、機能）、メッセージサブスクリプション、キープアライブメッセージング、サービスポッドを介したＳＭＯとのＡ１及びО１インタフェース通信（たとえば、統計、ログ、トレースデータをＳＭＯ又はサービスポッド上（ＰｒｏｍｅｔｈｅｕｓやＥＬＫなど）の時系列データベースに格納するための通信）などの制御機能メッセージも含まれる。

【0161】

一部の実施形態では、データパススレッド及び制御スレッドを１つのプロセッサコアに割り当て、（データ及び制御スレッドから分離するために）ＳＤＬを別のプロセッサコアに割り当て、サービスポッドをさらに別のプロセッサコアに割り当てる。１つ以上のｘＡｐｐがＲＩＣと同じホストコンピュータ上で動作する場合、ｘＡｐｐはＲＩＣポッドとは異なるコアに割り当てられる。ＲＩＣポッドでは、複数のｘＡｐｐを同じコアに割り当てることも、個々のコアを必要に応じて個別のｘＡｐｐに割り当てることもできる。

【0162】

ＲＩＣ及びｘＡｐｐの性能をさらに向上させるために、他の実施形態は、特定のメモリ割り当て（例えば、より大きいＲＡＭ割り当て）及び特定のＩＯ割り当てのような、他のハードウェア割り当ての最適化を実行する。一部のポッドの専用のＩＯ割り当ての例としては、（１）あるホストコンピュータのｘＡｐｐポッドが別のホストコンピュータのデータパスポッドと通信するためのＳＲＩＯＶ割り当て、（２）Ｅ２ノードと通信するためのデータパスポッドのＳＲＩＯＶ割り当て、（３）あるホストコンピュータのｘＡｐｐポッドが別のホストコンピュータのサービスポッドと通信するためのＳＲＩＯＶ割り当て、及び（４）ｇＲＰＣ通信が帯域幅割り当てが低く、ＳＣＴＰ通信より優先順位が低いｇＲＰＣ通信によるＳＲＩＯＶ割り当てを使用したｇＲＰＣ又はＳＣＴＰ通信がある。

【0163】

いくつかの実施形態では、１つのＲＩＣといくつかのｘＡｐｐがバンドルされて、１つのＶＭ上で動作する異なるポッド上で動作する。異なるｘＡｐｐのセットを有するいくつかの実施形態では、ＲＩＣの複数のインスタンスをデプロイすることもできる。また、いくつかの実施形態では、相互に通信する必要があるｘＡｐｐは、同じＶＭ上にバンドルされている。

【0164】

上述したように、いくつかの実施形態は、１つのデータパススレッドとしてではなく、複数のデータパス処理スレッドと共に１つのデータＩＯスレッドとしてＲＩＣデータパスを実装する。いくつかの実施形態では、各データパス処理スレッド（ＤＰＴ）は、各Ｅ２ノードがただ１つのデータパス処理スレッドに割り当てられる、異なるＥ２ノードのセットのためのデータパス処理を実行することに責務を負う。いくつかの実施形態では、データＩＯスレッドは、メッセージに含まれるＥ２ノード識別子をハッシュし、ハッシュ化された値（ハッシュによって取得される）を、データメッセージを処理する必要があるＤＰＴのＤＰＴ識別子を提供するルックアップテーブルへのインデックスとして使用することによって、Ｅ２メッセージ又はｘＡｐｐメッセージに関連付けられたＤＰＴを識別する。

【0165】

図２６は、１つのデータＩＯスレッド２６０５、１つの制御スレッド２６１０、及び複数のＤＰＴ２６１５を有するＲＩＣデータパスポッド２６００の例を示す。ＤＰＴは、データパスポッド２６００のデータパス処理負荷を共有する。説明するように、各ＤＰＴ２６１５とデータＩＯスレッド２６０５、各ＤＰＴ２６１５と制御スレッド２６１０、及びデータＩＯスレッド２６０５と制御スレッド２６１０の間には、ｃｂｕｆリング２６２０のペアが存在する。ｃｂｕｆ対の各リング２６２０は、リングに関連する２つのスレッドの一方から他方のスレッドへの一方向にデータメッセージを渡し、一方のリングは一方向に（例えば、第１のスレッドから第２のスレッドへ）通信を処理し、他方に（例えば、第２のスレッドから第１のスレッドへ）通信を処理する。

【0166】

データＩＯスレッド２６０５を複数のＤＰＴ２６１５から分離することは、より計算集約的な動作をＤＰＴにプッシュすることによって、データパスポッド２６００のデータＩＯを最適化し、それにより、より計算集約的でないＩＯ動作をデータＩＯスレッド２６０５内で実行することを可能にする。この最適化により、高速データパスＩＯ（不要な遅延が発生しないもの）が確保されるため、ＲＩＣはＥ２ノードとｘＡｐｐ間の高速インターフェースとして機能できる。また、各Ｅ２ノードは、通常、いくつかのＥ２ノードを担う、１つのＤＰＴスレッド２６１５だけの責務である。各Ｅ２ノードは１つの特定のＤＰＴによって処理されるため、２つのＤＰＴが１つのＥ２ノードに関連付けられた１つ以上の記録を変更しようとすることはない。したがって、データパスポッド２６００は、Ｅ２ノードとの通信に対する責務が明確に区別されるため、Ｅ２ノードの記録をロックする必要はない。

【0167】

データＩＯスレッド２６０５は、（１）Ｅ２ノード及びｘＡｐｐポッドへの接続を管理すること、（２）Ｅ２ノード及びｘＡｐｐポッドとの間のこれらの接続を介してデータメッセージを送信すること、（３）セキュリティ動作を実行すること、（４）制御スレッド２６１０及びＤＰＴ２６１５とのリング通信を制御すること、及び（５）自身が処理するメッセージに関する統計、ログ及びトレースデータを生成すること、を実行する。

【0168】

各ＤＰＴスレッド２６１５は、（１）メッセージのデコード及びエンコード動作（例えば、メッセージの暗号化及び復号化動作）、（２）メッセージの検証動作、（３）シーケンスの検証動作、（４）Ｅ２ノード及びｘＡｐｐ要求及びサブスクリプションの状態を追跡するための状態マシンの維持、（５）コンフリクト管理の実行、（６）制御スレッド２６１０及びＤＰＴ２６１５との制御リング通信、及び（７）処理するメッセージに関する統計、ログ及びトレースデータの生成、の各動作を実行する。

【0169】

図２７は、いくつかの実施形態において、データパススレッドが、ｘＡｐｐからのサブスクリプション要求を処理するために実行する処理２７００を示す。図に示すように、ＤＰＴがデータＩＯスレッドからｘＡｐｐサブスクリプション要求を（２７０５で）受信すると、処理が開始される。サブスクリプション要求は、特定のＥ２ノードが維持する特定のデータタプルのセット（例えば、特定の動作パラメータのセット又は他のパラメータ）について、特定のＥ２ノードに向けられる。

【0170】

２７１０において、処理２７００は、特定のデータタプルのセットを受信するために、特定のＥ２ノードに既にサブスクライブしているか否かを判定する。これは、ＤＰＴが以前に特定のＥ２ノードを１つ以上のサブスクリプション要求を送信したときに、特定のデータタプルのセット、又は特定のデータタプルのセットを含むより大きなデータタプルを個別に、又は集合的に要求した場合である。

【0171】

処理２７１００が、特定のデータタプルのセットを受信するために特定のＥ２ノードに既にサブスクライブしていると判定すると（２７１０において）、（２７１５において）このＥ２ノードのサブスクリプションリスト内のｘＡｐｐに対して、新しいレコードを追加するか、又は以前に指定されたレコードを更新し、ｘＡｐｐが受信すべき特定のデータタプルのセットをこのレコード内に指定する。２７１５の後、処理は終了する。

【0172】

一方、処理２７１００が、特定のデータタプルのセットを受信するために特定のＥ２ノードにまだサブスクライブしていないと判定した場合（２７１０において）、それがこのノードとのアクティブなサブスクリプションを有していない場合には特定のＥ２ノードに第１のサブスクリプションを送信するか、又は、２７０５で受信した要求で指定された特定のデータタプルの特定のデータタプルのすべてのデータタプルを含むものではない場合には、更新されたサブスクリプションをノードに送信する。

【0173】

したがって、このような場合、処理２７００（２７２０で）は、このＥ２ノードのサブスクリプションリスト内のｘＡｐｐに対して、新しいレコードを追加するか、又は以前に指定されたレコードを更新し、このレコード内でｘＡｐｐが受信すべき特定のデータタプルセットを指定する。次に、以前に割り当てられたＲＩＣ要求ＩＤを使用して、更新されたサブスクリプション要求を特定のＥ２ノードに送信する。この更新されたサブスクリプションは、特定のＥ２ノードへの以前のサブスクリプションによってこれらのタプルのいずれも以前に要求されていない場合に、要求された特定のデータタプルの特定のセット内のすべてのデータタプルを指定する。又は、特定のセット内の他のデータタプルが、特定のＥ２ノードへの１つ以上の以前のサブスクリプションによって以前に要求されている場合に、これらのデータタプルの一部を指定する。２７２５の後、処理２７００は終了する。

【0174】

図２８は、処理２８００を示し、データＩＯスレッド２６０５及びＤＰＴ２６１５が、実施形態によっては、１つ以上のｘＡｐｐが受信すべきＥ２ノードからのデータメッセージを処理するために実行する。説明するように、処理２８００は、データメッセージが、Ｅ２ノードとのＳＣＴＰ接続を介してデータパスポッドによって受信されたとき（２８０５において）に開始する。２８１０において、データＩＯスレッド２６０５は、Ｅ２ノードのＩＤからハッシュ値を生成する。次に、（２８１５で）ハッシュ値をルックアップテーブルへのインデックスとして使用し、Ｅ２ノードに関連付けられたメッセージの処理に割り当てられたＤＰＴを識別する。

【0175】

２８２０で、データＩＯスレッドは、データＩＯスレッドから識別されたＤＰＴにメッセージを渡すためのｃｂｕｆリング２６２０に沿って、受信されたデータメッセージを識別されたＤＰＴ（すなわち、２８１５で識別されたＤＰＴ）に渡す。次に、２８２５で、ＤＰＴは、そのデータ構造記録（例えば、その状態機械によって維持される記録）を使用して、Ｅ２メッセージを取得すべき１つ以上のｘＡｐｐのセットを識別する。いくつかの実施形態では、識別された一連のｘＡｐｐは、Ｅ２ノードからデータ（例えば、すべてのデータ又はデータのサブセット）を受信するためにサブスクライブしているｘＡｐｐである。

【0176】

２８３０において、ＤＰＴは、識別されたｘＡｐｐｓのセットに送信するデータＩＯスレッド２６０５のためのデータメッセージを特定する。このデータメッセージは、以下の表１を参照してカプセル化されたフォーマットになっている。次に、ＤＰＴは、ＤＰＴ２６１５からデータＩＯスレッド２６０５にメッセージを渡すためのｃｂｕｆリング２６２０に沿って、データメッセージをデータＩＯスレッド２６０５に（２８３５で）渡す。次に、２８４０において、データＩＯスレッド２６０５は、ｃｂｕｆリング２６２０からデータメッセージを検索し、データメッセージを受信する必要があるｘＡｐｐｓを識別し、次いで、各識別されたｘＡｐｐにデータメッセージを送信する。２８４０の後、処理は終了する。

【0177】

図２９は、処理２９００を示しており、データＩＯスレッド２６０５及びＤＰＴ２６１５は、いくつかの実施形態において、Ｅ２ノードに送られるべきｘＡｐｐからのデータメッセージを処理するために実行する。説明するように、処理２９００は、データメッセージがＳＣＴＰ接続又はｘＡｐｐ ＲＩＣ ＳＤＫとの共有メモリ通信を介してデータパスポッドによって受信されると（２９０５で）開始する。このメッセージは、表１を参照して以下に説明するカプセル化されたフォーマットである。このメッセージには、このメッセージを受信するＥ２ノードを識別するＥ２ノード識別子が含まれる。

【0178】

２９１０において、データＩＯスレッド２６０５は、Ｅ２ノードのＩＤからハッシュ値を生成する。次に、（２９１５で）ハッシュ値をルックアップテーブルへのインデックスとして使用し、Ｅ２ノードに関連付けられたメッセージの処理に割り当てられたＤＰＴを識別する。２９２０で、データＩＯスレッドは、データＩＯスレッドから識別されたＤＰＴにメッセージを渡すためのｃｂｕｆリング２６２０に沿って、受信されたデータメッセージを識別されたＤＰＴ（すなわち、２９１５で識別されたＤＰＴ）に渡す。

【0179】

次に、２９２５において、ＤＰＴは、そのデータ構造記録（例えば、その状態マシンによって維持される記録）を使用して、メッセージを受信すべきＥ２ノードを識別する。いくつかの実施形態では、データメッセージはサブスクリプション要求であり、識別されたＥ２ノードは、ｘＡｐｐがサブスクライブしたいＥ２ノードである。２９３０において、ＤＰＴは、識別されたＥ２ノードに送信するデータＩＯスレッド２６０５のためのデータメッセージを指定する。このデータメッセージは、標準によって必要とされるＥ２ＡＰメッセージフォーマットである。次に、ＤＰＴは、ＤＰＴ２６１５からデータＩＯスレッド２６０５にメッセージを渡すためのｃｂｕｆリング２６２０に沿って、データメッセージをデータＩＯスレッド２６０５に（２９３５で）渡す。次に、２９４０で、データＩＯスレッド２６０５は、ｃｂｕｆリング２６２０からデータメッセージを検索し、データメッセージを受信する必要があるＥ２ノードを識別し、そして識別された各Ｅ２ノードにデータメッセージを送信する。２９４０の後、処理は終了する。

【0180】

いくつかの実施形態において、ＤＰＴ２６１５は、２９２５で識別するＥ２ノードに新たなサブスクリプションメッセージを送信する必要がないと判定することができる。たとえば、Ｅ２ノードから一連のデータタプルのサブスクリプション要求を第１のｘＡｐｐから（２９０５で）受信する前に、第２のｘＡｐｐに対して以前に送信されたデータパスポッドが、同じデータタプルのセット又は第１のｘＡｐｐによって要求されたデータタプルを含むより大きなデータタプルのセットに対して同じＥ２ノードにサブスクリプション要求を送信する。このような場合、ＤＰＴ２６１５は、Ｅ２ノードのサブスクリプションリストに第１のｘＡｐｐを追加するだけで、それ以降にＥ２ノードから受け取った値を第１のｘＡｐｐに提供できるようになる。いくつかの実施形態において、ＤＰＴ２６１５はまた、ＳＤＬに記憶されたＥ２ノードから以前に受信した値を第１のｘＡｐｐに供給するか、又はｘＡｐｐに指示してＳＤＬからこれらの値を取得する。

【0181】

場合によっては、第１のｘＡｐｐは、第２のｘＡｐｐが以前に要求しなかったＥ２ノードから追加のデータタプルを要求する。このような場合、ＤＰＴ２６１５は、第１のｘＡｐｐによって新たに要求されるデータタプルを要求するために、Ｅ２ノードに送信するデータＩＯスレッドのための更新されたサブスクリプションメッセージを準備する。ＤＰＴは、第２のｘＡｐｐが第１のサブスクリプションの後にＥ２ノードから追加のデータタプルを要求したときにも、このようなメッセージを準備する。

【0182】

いくつかの実施形態では、サービスポッド２５１０は、Ｎが１より大きい整数であるときに始動するとき、Ｎ個のＤＰＴをインスタンス化するようにデータパスポッド２６００を構成する。ニアＲＴ ＲＩＣのデータパスポッド２６００の場合、個数Ｎは、ニアＲＴ ＲＩＣを介してＥ２ノードと通信する予想される個数のＥ２ノード及びｘＡｐｐに基づいて、いくつかの実施形態で計算される。いくつかの実施形態では、データパスポッド２６００のデータＩＯスレッド２６０５は、次に、受信するサブスクリプション要求の順序及びこれらの要求の時点でのＤＰＴ上の負荷に基づいて、Ｅ２ノードをＤＰＴに割り当てる。

【0183】

図３０は、いくつかの実施形態においてデータＩＯスレッドがＥ２ノードをＤＰＴに割り当てるために使用する処理の例を示す。説明するように、処理３０００は、データＩＯスレッド２６０５が、データＩＯスレッドのニアＲＴ ＲＩＣに関連するｘＡｐｐから、特定のＥ２ノードに対する第１のサブスクリプション要求を受信（３００５）すると、開始する。特定のＥ２ノードに対する第１のサブスクリプション要求は、データＩＯスレッドによってこの特定のＥ２ノードに対して他のサブスクリプション要求が以前に受信されなかったことを意味する。

【0184】

次に、３０１０で、データＩＯスレッド２６０５は、特定のＥ２ノードのグローバルＥ２ノードＩＤからＮビットのハッシュ値を生成する。ここで、Ｎは整数（例えば、６又は８）である。このＮビット値は、後述するように、ハッシュＬＵＴ（ルックアップテーブル）内の特定のＥ２ノードを識別するために使用される。３０１５において、処理３０００は、データパスポッド２６００の各ＤＰＴ上の現在の負荷に基づいて（例えば、負荷量が最小のＤＰＴを選択することによって）、特定のＥ２ノードのための特定のＤＰＴを選択する。いくつかの実施形態では、現在の負荷は、各ＤＰＴに割り当てられたＥ２ノードの個数にのみ基づいているが、他の実施形態では、現在の負荷は、Ｅ２ノードの個数及びこれらのノードに対するｘＡｐｐサブスクリプションの個数に基づいている。さらに他の実施形態では、現在の負荷は他の方法で計算される。

【0185】

次に、３０２０において、処理３０００は、ＬＵＴ内に記録を作成し、この記録において、Ｎビットのハッシュ値と、特定のＥ２ノードについて３０１５で選択された特定のＤＰＴの識別子とを関連付ける。いくつかの実施形態では、Ｎビットのハッシュ値は、特定のＥ２ノードのＩＤを指定する記録を識別するＬＵＴへのインデックスである。３０２０において、処理３０００はまた、このレコードの状態をアクティブとして指定する。

【0186】

後続の時点で、データＩＯスレッドが、すべてのｘＡｐｐが特定のＥ２ノードへのサブスクリプションをキャンセルしたという状況に遭遇した場合、処理３０００は、３０２０で作成されたＬＵＴ記録を保持するが、この記録のステータスを非アクティブに変更する。データＩＯスレッドは、ｘＡｐｐが特定のＥ２ノードのサブスクリプション要求を次に送信するまで、この非アクティブ状態を維持する。その時点で、このレコードの状態が再びアクティブに変更される。このステータス値は、データＩＯスレッドがＤＰＴへのＥ２ノード割り当てを継続的に再実行する必要がないようにする機構として使用される。

【0187】

図３１は、アクティブＲＩＣ３１０２及びスタンバイＲＩＣ３１０４によって実現される分散ニアＲＴ ＲＩＣを示す。図に示すように、Ｅ２ノード３１１８及びｘＡｐｐポッド３１２０は、このＲＩＣの１つ以上のコンポーネントが故障するまで、アクティブなＲＩＣ３１０２と通信する。アクティブなＲＩＣに障害が発生すると、スタンバイＲＩＣ３１０４がアクティブなＲＩＣになり、Ｅ２ノードとｘＡｐｐポッドは、現在アクティブなＲＩＣであるＲＩＣ３１０４を介して通信を継続する。

【0188】

これらのＲＩＣにはどちらも同じコンポーネントがあり、それらはデータパスポッド３１０５、サービスポッド３１１０、及びＳＤＬポッド３１１５である。データパスポッドは、制御スレッド３１０９及びデータパススレッド３１０７を含むように示される。１つのデータパススレッド３１０７の代わりに、いくつかの実施形態は、上述したように、１つのデータＩＯスレッドと複数のＤＰＴを使用する。いくつかの実施形態では、アクティブＲＩＣ３１０２は、１つ以上のコンピュータの第１のセットによって実現され、一方、スタンバイＲＩＣ３１０４は、１つ以上のコンピュータの異なる第２のセットによって実現される。

【0189】

図に示すように、各Ｅ２ノード３１１８は、アクティブ及びスタンバイＲＩＣ３１０２及び３１０４のデータパススレッド３１０７とデュアルホームＳＣＴＰ接続を有する。同様に、各ｘＡｐｐポッド３１２０には、アクティブ及びスタンバイＲＩＣ３１０２及び３１０４のデータパススレッド３１０７とのデュアルホームＳＣＴＰ接続がある。デュアルホーミング接続は、ＳＣＴＰが提供する機能である。第１のコンポーネントがデュアルホーム接続を介してコンポーネントのアクティブ／スタンバイペアに接続すると、第１のコンポーネントは、アクティブコンポーネントに障害が発生したときに自動的にスタンバイコンポーネントを使用するように切り替えることができる。したがって、デュアルホームＳＣＴＰコネクションを使用すると、アクティブなＲＩＣ３１０２又はそのデータパスポッドに障害が発生したときに、各Ｅ２ノード又はｘＡｐｐポッドをスタンバイＲＩＣ３１０４のデータパススレッド３１０７に切り替えることができる。

【0190】

説明するように、アクティブＲＩＣ３１０２のデータパススレッド３１０７のＲＩＣ ＳＤＫインタフェース３１２２は、ｘＡｐｐ ＲＩＣ ＳＤＫから受信するメッセージと、それがｘＡｐｐ ＲＩＣ ＳＤＫに送信するメッセージを、スタンバイＲＩＣ３１０４のデータパス３１０７のＲＩＣ ＳＤＫインタフェース３１２２に転送する。これは、いくつかの実施形態では、スタンバイＲＩＣのデータパススレッド３１０７が、そのステートマシンを、アクティブＲＩＣのデータパススレッド３１０７の状態に一致するように更新できるようにする。また、説明するように、アクティブ及びスタンバイＲＩＣ ３１０２及び３１０４の同期エージェント３１２７は、スタンバイＲＩＣ ３１０４のＳＤＬストレージ３１２６をアクティブＲＩＣ３１０２のＳＤＬストレージ３１２６と同期する。アクティブ及びスタンバイＲＩＣ３１０２及び３１０４のすべてのコンポーネントは、ＳＭＯ ３１３０によって一貫して管理される。

【0191】

図３２は、いくつかの実施形態において、ニアＲＴ ＲＩＣ３２００とＥ２ノード３２０５との間、及びニアＲＴ ＲＩＣ３２００とｘＡｐｐポッド３２１０との間のインタフェースを示す。いくつかの実施形態では、ニアＲＴ ＲＩＣは、上述のニアＲＴ ＲＩＣの１つである。上述したように、また図３２に示されるように、いくつかの実施形態におけるニアＲＴ ＲＩＣは、ＳＣＴＰインタフェース３２２０及び３２２２を、Ｅ２ノード３２０５及びｘＡｐｐポッド３２１０の両方とともに使用する。ｘＡｐｐポッドとニアＲＴ ＲＩＣが同じホストコンピュータ上で実行される場合、いくつかの実施形態では、図に示すように、ニアＲＴ ＲＩＣとｘＡｐｐポッドの間のインタフェースとして共有メモリを使用する。これらのインタフェースはメッセージ交換を高速に保ち、すべてのパスにわたってエンコードとデコードのオーバーヘッドを最小にして、待ち時間を最小にする（例えば、１つのＡＳＮ復号と１つのＡＳＮ符号化を行う）。いくつかの実施形態において、Ｅ２ノードとニアＲＴ ＲＩＣとの間のインタフェース３２２０は、Ｅ２ＡＰ仕様に従い、すべてのメッセージ交換は、Ｅ２ＡＰ仕様に準拠する。

【0192】

また、いくつかの実施形態では、ニアＲＴ ＲＩＣとｘＡｐｐポッドとの間のインタフェース３２２２は、表１を参照して後述する新規のカプセル化ヘッダを使用する。インタフェース３２２２は、異なるタイプのメッセージの混合を処理する。いくつかの実施形態におけるこのようなメッセージの例には、（１）Ｅ２ノードからのＥ２ＡＰメッセージ全体（例えば、Ｅ２セットアップ要求）、（２）Ｅ２ＳＭコンテンツ全体（すなわち、Ｅ２ＡＰメッセージペイロード全体）と共にＥ２ＡＰヘッダのいくつかのフィールド、（３）ニアＲＴ ＲＩＣとｘＡｐｐポッドの間の内部メッセージ（例えば、ｘＡｐｐの以前のメッセージが誤差を起こしたことを、ニアＲＴ ＲＩＣからのメッセージ）、（４）ｘＡｐｐからニアＲＴ ＲＩＣ又はＥ２ノードへのメッセージが含まれる。いくつかの実施形態では、Ｅ２コンテンツはＡＳＮ１エンコードされていない可能性がある（例えば、サブスクリプション要求の一部がエンコードされていない可能性がある）。

【0193】

いくつかの実施形態において、ニアＲＴ ＲＩＣ３２００は、メッセージをｘＡｐｐに送信する前にＥ２ＡＰメッセージだけをデコードするか、又はＥ２ＳＭペイロードとともにＥ２ＡＰヘッダ全体をデコードするように、ケースバイケースで構成することができる。場合によっては、ニアＲＴ ＲＩＣがＥ２ＡＰヘッダ全体を送信し、それ以外の場合は、このヘッダの一部のみを送信する。いくつかの実施形態のＲＩＣ Ｅ２ＡＰメッセージ処理では、すべてのフィールドはネットワークバイトオーダーであり、ニアＲＴ ＲＩＣ３２００は可能な限りそのオーダーで動作する。フィールドを表示するために、いくつかの実施形態は、データをホスト順に変換することができる。いくつかの実施形態において、ニアＲＴ ＲＩＣ３２００は、Ｅ２ＳＭペイロードを見ることはないが、他の実施形態においては、それは、（例えば、重複したサブスクリプション誤差を避けるために）行われる。

【0194】

いくつかの実施形態において、ＲＡＮ機能ＩＤは、Ｅ２ノード特有である。各サブスクリプションは個々のＥ２ノードに属するため、ｘＡｐｐｓはＥ２ノード間でＲＡＮ機能にサブスクライブしない。また、いくつかの実施形態では、ＲＩＣ要求ＩＤ空間は、Ｅ２ノードに対してローカルである。いくつかの実施形態では、ＲＩＣ要求ＩＤ番号空間は、永続的なコンポーネントと同様に一時的なコンポーネントである。例えば、表示レポートに使用されるＲＩＣ要求ＩＤは、サブスクリプションから使用されるＲＩＣ要求ＩＤが再利用されても、存続する。

【0195】

以下の表１は、ＲＩＣとＲＩＣ ＳＤＫ間の通信のためにいくつかの実施形態で使用される例示的なメッセージフォーマットを示す。これは、ＲＩＣ ＳＤＫとの間で送受信されるすべてのメッセージをカプセル化するために使用されるカプセル化ヘッダの形式である。いくつかの実施形態において、カプセル化ヘッダは、データメッセージの効率的な処理のためにＲＩＣ ＳＤＫ及びＲＩＣによって必要とされるデータを格納する。表１に示す例では、ｍｓｇ＿ｔｙｐｅ、ｍｓｇ＿ｓｅｒｉａｌ＿ｎｕｍ、ｍｓｇ＿ｌｅｎ、ｍｓｇ＿ｆｌａｇｓ、ｃｔｒｌ＿ｌｅｎに関連する最初の１６バイトは、ｃｔｒｌ＿ｉｎｆｏフィールドとともにカプセル化ヘッダの一部である。カプセル化パケットのペイロードには、任意のデータを含めることができる。表１に示す例では、ｐａｙｌｏａｄ（ペイロード）には元のＥ２ＡＰパケットとＥ２ＳＭペイロードが含まれている。

【0196】

ＲＩＣ とＲＩＣ ＳＤＫ間のすべてのメッセージは、表１に示すヘッダでカプセル化される。制御情報とペイロードはオプションである。メッセージの中には制御情報を持っていてもペイロードフィールドを持たないものもあれば、制御情報を持たないペイロードを有するものもあり、制御フィールドとペイロードフィールドの両方を有するものもある。いくつかの実施形態において、ＲＩＣ ＳＤＫは、これらのメッセージをトラップし、それらをｘＡｐｐｓへの提示のために再フォーマットするように構成することができる。メッセージのフォーマットは生のバイトストリームである。いくつかの実施形態では、メッセージＣＲＣフィールドは使用されず、他の実施形態で使用される。

【表1】

【0197】

ニアＲＴ ＲＩＣ３２００は、Ｅ２ノードとｘＡｐｐの接続、切断、リセット、クラッシュを次のように処理する。Ｅ２ノードの場合、いくつかの実施形態のＲＩＣは、接続、切断、及びクラッシュを同様に処理する。具体的には、Ｅ２ノードへの接続がドロップされ、これらのいずれかの理由で復帰すると、Ｅ２ノードは、最初に起動したかのように、再び接続設定を送信し、ニアＲＴ ＲＩＣは、Ｅ２ノードに関連するすべての状態をクリーンアップし、やり直す。いくつかの実施形態において、ニアＲＴ ＲＩＣは、以前に特定のＥ２ノードにサブスクライブしていたか否かにかかわらず、Ｅ２ノード接続がドロップして復帰したときに、すべてのｘＡｐｐに通知する。これは、Ｅ２ノードが、以前にサブスクライブしていなかったｘＡｐｐが関心を持っていたかもしれない新しい機能をアドバタイズする可能性があるためである。ｘＡｐｐが接続、切断、又はクラッシュすると、ニアＲＴ ＲＩＣは同じ動作を再度実行する。ニアＲＴ ＲＩＣ内のｘＡｐｐのすべての状態をリセットし、そのサブスクリプションをすべてのＥ２ノードから削除する。

【0198】

図３３は、ニアＲＴ ＲＩＣ３２００のデータパスポッドのＥ２ＡＰメッセージ処理を示す。Ｅ２ＡＰメッセージ処理とその他のメッセージ処理に関する以下の説明では、簡潔にするために、このデータパスポッドを単にニアＲＴ ＲＩＣ３２００又はＲＩＣ３２００と呼ぶ。図に示すように、ニアＲＴ ＲＩＣ３２００は、最初に、Ｅ２ノードから受信したＥ２ＡＰメッセージをデコードする。いくつかの実施形態では、このデコードは、Ｅ２ＡＰヘッダのみのデコードを含むが、他の実施形態では、このデコードは、Ｅ２ＡＰヘッダ及びＥ２ＳＭペイロードのデコードを含む。このデコードの一部又は全部（例えば、Ｅ２ＳＭ）について、いくつかの実施形態のニアＲＴ ＲＩＣは、上述のバイパスパスを介してアクセスするハードウェアアクセラレータ（例えば、ＧＰＵアクセラレータ）を使用する。

【0199】

Ｅ２ＡＰメッセージをデコードした後、ニアＲＴ ＲＩＣは、受信したデータメッセージを考慮して内部データ構造を作成又は更新し、次に、表１を参照して上記のフォーマットでｘＡｐｐにフラットなカプセル化メッセージを作成する。ニアＲＴ ＲＩＣ及びＲＩＣ ＳＤＫは、異なるコンテナ上で動作し、いくつかの実施形態では異なるポッド上に存在するため、任意のデータ構造を互いに渡すことはなく、いくつかの実施形態では、それらのデータ交換を特定のバイト列を有するカプセル化されたメッセージにフォーマットする。データメッセージをカプセル化した後、ニアＲＴ ＲＩＣはデータメッセージをｘＡｐｐポッドに転送し、このポッドのＲＩＣ ＳＤＫが適切なｘＡｐｐに転送する。

【0200】

Ｅ２ＡＰメッセージの処理中にニアＲＴ ＲＩＣで作成又は更新される内部データ構造は、ｘＡｐｐからＥ２ＡＰメッセージへの応答メッセージの処理と、後続のＥ２ＡＰメッセージの処理に使用される。いくつかの実施形態において、ニアＲＴ ＲＩＣの内部データ構造に格納されるデータの例は、（１）特定のＥ２ノードからのデータに関心を有するｘＡｐｐのサブスクリプションリスト、（２）各ｘＡｐｐが各Ｅ２ノードから関心を有する特定のデータタプル、（３）Ｅ２ノード及びｘＡｐｐに関連するネットワークアドレス及び他の位置データを識別するレコード、（４）確保され、割り当てられた識別子（例えば、ＲＩＣ要求ＩＤ）を含む。

【0201】

ｘＡｐｐがメッセージを送信すると、そのＲＩＣ ＳＤＫはそのメッセージを処理し、前述のように共有メモリ又はＳＣＴＰインタフェースに沿ってＲＩＣに転送する。ニアＲＴ ＲＩＣは次にメッセージを解析し、解析されたコンポーネントを格納する。これらのコンポーネントと、関連するＥ２ノードメッセージの内部データ構造に格納されている１つ以上のデータタプルとに基づいて、ＲＩＣはＥ２ＡＰ応答を作成し、この応答をエンコードして、送信先のＥ２ノードに転送する。

【0202】

たとえば、第１のｘＡｐｐがＥ２ノードからＭ個のデータタプルを受信するサブスクリプション要求を送信した後、ニアＲＴ ＲＩＣのデータパスポッドの状態を作成して、第１のｘＡｐｐの目的のサブスクリプションを記録し、Ｍ個のデータタプルのためのＥ２ノードを使用してサブスクリプションを要求し、これらのＭ個のデータタプルを最初に受信したときにｘＡｐｐに転送し、その後、受信するたびにこれらのＭ個のデータタプルを転送する。いくつかの実施形態では、ニアＲＴ ＲＩＣのデータパスポッドは、Ｍ個のデータタプルをＥ２ノードから受信するたびに、関連するＳＤＬに転送するように構成することができる。

【0203】

第１のｘＡｐｐがＥ２ノードからＭ個のデータタプルを受信するようにサブスクライブした後、第２のｘＡｐｐは、Ｅ２ノードからＮがＭより大きいＮ個の異なるデータタプルを受信するようにサブスクライブすることができる。ニアＲＴ ＲＩＣは、更新されたサブスクリプション要求をＥ２ノードに送信する。この更新でＮ個のデータタプルが要求されるようになった。ニアＲＴ ＲＩＣ がＮ個のデータタプルを受信するたびに、Ｍ個のデータタプルが第１のｘＡｐｐに送信され、Ｎ個のデータタプルがすべて第２のｘＡｐｐに送信される。

【0204】

別の例では、ニアＲＴ ＲＩＣを削除し、サブスクリプション要求に応答してＥ２ノードからＥ２ＡＰメッセージからＲＩＣ要求ＩＤをキャッシュする。このＩＤが削除されると、ＲＩＣはＥ２ＡＰメッセージの一部とそのＥ２ＳＭペイロード（該当する場合）をｘＡｐｐに提供する。その後、ｘＡｐｐがサブスクリプションを削除する場合、ＲＩＣはＲＩＣ要求ＩＤをその状態から取得し、Ｅ２ノードへのＥ２ＡＰメッセージに挿入して、サブスクリプションの削除を要求する。

【0205】

いくつかの実施形態では、ニアＲＴ ＲＩＣのＥ２セットアップ、応答メッセージ、及び障害メッセージの処理は、次のようになる。ニアＲＴ ＲＩＣは、最初にＥ２ノードからセットアップ要求メッセージを受信する。それに応じて、ニアＲＴ ＲＩＣはメッセージをデコードし、内部データ構造を構築する。ＲＩＣはロー（ｒａｗ）ＡＳＮ１ペイロードもキャッシュする。いくつかの実施形態において、ニアＲＴ ＲＩＣは、追加されたすべてのＲＡＮ関数識別子を受け入れる。いくつかの実施形態では、ニアＲＴ ＲＩＣでは、Ｅ２ＡＰヘッダをデコードした後、他の何もデコードしないで（すなわち、ＡＳＮ１でエンコードされたＥ２ＳＭペイロードを有するメッセージとして）、セットアップメッセージをｘＡｐｐｓに送信する。いくつかの実施形態では、ニアＲＴ ＲＩＣがｘＡｐｐに送信するセットアップメッセージは、そのＡＳＮ１符号化されたペイロードと共に０の制御長（ｃｔｒｌ＿ｌｅｎ）を有する。

【0206】

ｘＡｐｐが後で接続すると、ニアＲＴ ＲＩＣはＥ２ノードからのすべてのセットアップ要求をｘＡｐｐに送信し、接続されたＥ２ノードのインベントリを保持する。いくつかの実施形態では、ニアＲＴ ＲＩＣは、これらのメッセージを一度に１つずつ送信する。また、上述したように、いくつかの実施形態におけるニアＲＴ ＲＩＣは、Ｅ２Ｓｅｔｕｐ応答を構築し、それをＥ２ノードに送信する。いくつかの実施形態では、ニアＲＴ ＲＩＣでは、セットアップ要求が誤った形式になったときに失敗メッセージを送信する（例えば、ＲＡＮ関数リストの複製である、又はリストに追加されていない記録を除去する）。

【0207】

Ｅ２ノードからリセットを受けた後、ニアＲＴ ＲＩＣはメッセージをデコードした後、以下の動作を行う。このリセットに関するメッセージを、このＥ２ノードへのサブスクリプションを有するすべてのｘＡｐｐに送信する。いくつかの実施形態では、これは、ＡＳＮ １の内容を持たない内部メッセージである。ニアＲＴ ＲＩＣは、送信した以前のすべてのサブスクリプションのＥ２ノードへのサブスクリプション削除メッセージを終了する。また、このＥ２ノードに制御、挿入、ポリシー削除を送信する。未処理の要求をクリーンアップし、Ｅ２ノードにリセット応答を送信する。

【0208】

ニアＲＴ ＲＩＣはまた、いくつかの実施形態において、サービス更新、確認、及び失敗メッセージを採用する。このメッセージは、追加、修正、及び削除とともに、サポートされるＲＡＮ関数リストを更新する。ニアＲＴ ＲＩＣは、Ｅ２ノードの新しいサービス構成についてすべてのｘＡｐｐに通知する。いくつかの実施形態では、ニアＲＴ ＲＩＣは、構成の適用後にｘＡｐｐｓにメッセージを送信するので、構成の最終状態を反映する。他の実施形態では、ニアＲＴ ＲＩＣは、サポートされるＲＡＮ機能の前の状態と新しい状態との間の差分を計算するために、ｘＡｐｐｓに対してそのままメッセージを送信する。後者のアプローチでは、ニアＲＴ ＲＩＣは、結果のデルタをＡＳＮ１エンコードする必要はない。

【0209】

Ｅ２ＡＰサブスクリプションの処理は、いくつかの実施形態では以下のようになる。ｘＡｐｐはサブスクリプションのＥ２ＳＭ部分をフォーマットし、ＡＳＮ１はそれをエンコードする。以下の表２は、サブスクリプションメッセージの制御部分（すなわち、ｘＡｐｐからニアＲＴ ＲＩＣまでのメッセージの制御フィールドに格納される部分）の詳細を示している。ペイロードは、ＡＳＮ１でエンコードされたＥ２ＳＭコンテンツになる。いくつかの実施形態では、オプション情報を明確にするために、複数のサブスクリプションメッセージタイプが定義されている。また、いくつかの実施形態では、メッセージフラグを使用して、正確なフォーマットを指定する。いくつかの実施形態では、各加入メッセージは、１つのＥ２ノードグローバルＩＤ及び１つのＲＡＮ機能ＩＤを指定する。

【0210】

いくつかの実施形態では、Ｅ２ノードは、１１３バイトの識別子を送信し、ＲＩＣは、それを４０バイトのＩＤに圧縮する。サブスクリプションメッセージをＥ２ノードに送信すると、ＲＩＣは４０バイトを１１３バイトのＩＤに変換する。サブスクリプションメッセージ制御フィールドは、可能な限り固定されたフォーマットになる。いくつかの実施形態において、ＲＩＣは、重複したサブスクリプションメッセージを送出することを避けるために、すべてのサブスクリプション要求をキャッシュし、複数のｘＡｐｐからの要求を比較する。ただし、第１の最初のｘＡｐｐの後に、第２の後続のｘＡｐｐが同じＥ２ノードから追加情報を要求すると、ＲＩＣはサブスクリプションを再送信する（一部の実施形態では同じＲＩＣ要求ＩＤを使用）。ただし、今回は追加情報を要求する。サブスクリプション要求をＥ２ノードに送信する場合、ＲＩＣは、いくつかの実施形態では、ｘＡｐｐから受信したペイロード全体をＥ２ＡＰメッセージペイロードとして送信する。

【表2】

【0211】

ニアＲＴ ＲＩＣは、Ｅ２ノードのグローバルＩＤとＲＩＣ要求ＩＤ（ＲＩＣによって生成される）を制御情報として保存し、Ｅ２ノードから正確にＡＳＮ１エンコードされたメッセージをｘＡｐｐｓに送り返すことで、Ｅ２ＡＰ ＲＩＣサブスクリプション応答を処理する。

【0212】

Ｅ２ＡＰ ＲＩＣサブスクリプション削除要求、応答、又は失敗メッセージは、制御情報として（つまり、ｃｔｒｌ＿ｉｎｆｏの一部として）送信されるメッセージフィールドとともに、ｘＡｐｐからニアＲＴ ＲＩＣに送信される。ニアＲＴ ＲＩＣはエンコードされたＡＳＮ１メッセージを作成し、Ｅ２ノードに送信する。削除要求では、Ｅ２ノードグローバルＩＤを指定しない。したがって、この情報はｘＡｐｐのＲＩＣによって提供される。いくつかの実施形態では、応答メッセージは、パックされたバイト（ＡＳＮ１エンコードされていない）として、ニアＲＴ ＲＩＣからｘＡｐｐに送られる。

【0213】

Ｅ２ノードのＥ２ＡＰ通知レポートは、次のように処理される。メッセージは、ニアＲＴ ＲＩＣによってデコードされ、ＲＩＣ要求ＩＤフィールドが判定される。これは、表示にサブスクライブしたｘＡｐｐを判別するのに役立つ。いくつかの実施形態におけるニアＲＴ ＲＩＣは、ｘＡｐｐに符号化されたＡＳＮ１としてメッセージを送信する。いくつかの実施形態において、ニアＲＴ ＲＩＣはまた、メッセージと共に制御情報として減少したＥ２グローバルＩＤを送信する。

【0214】

Ｅ２ＡＰ制御要求のニアＲＴ ＲＩＣの処理は、いくつかの実施形態では以下のようになる。ｘＡｐｐはこの要求をパックされたバイト情報として送信する。ニアＲＴ ＲＩＣでは、この情報はｘＡｐｐによって指定されるため、メッセージにＥ２グローバルＩＤは指定されない。このメッセージのニアＲＴ ＲＩＣのフォーマットを表３に示す。

【表3】

【0215】

ニアＲＴ ＲＩＣは、Ｅ２ＡＰ制御応答又は失敗メッセージを次のように処理する。ニアＲＴ ＲＩＣはメッセージをデコードし、ＲＩＣ要求ＩＤを取得する。次に、制御情報としてグローバルＥ２ノードＩＤを先頭に付加したＡＳＮ１エンコードメッセージをｘＡｐｐに送信する。

【0216】

いくつかの実施形態では、ＳＤＬデータストアは、１つ以上のポッドの独自のセットで実行されるメモリデータベース内のものである。独自のコンピューティングリソースとメモリリソースが割り当てられている。前述のように、複数のニアＲＴ ＲＩＣインスタンスは、分散ニアＲＴ ＲＩＣを定義する。いくつかの実施形態において、各ニアＲＴ ＲＩＣインスタンスには、ＲＩＣインスタンスのためのシステム全体の情報を格納するＳＤＬの独自のインスタンスがある。このような情報の例には、接続されたＥ２ノード（すなわち、基地局ノード）、ｘＡｐｐ、各ｘＡｐｐからのサブスクリプション及びＥ２ノードによって返されたクリティカルセルデータのリストが含まれる。さらに、いくつかの実施形態の各ＳＤＬインスタンスは、データが到着すると内部でカスタムアルゴリズムを実行し、ハードウェアアクセラレータ（例えば、ＧＰＵ）にインタフェースすることによって、又はそのストレージから取り出された後処理データによって、着信データを前処理するサービスを提供する。

【0217】

ＲＩＣインスタンスのデータＩＯポッド及びｘＡｐｐポッドは、ＲＩＣインスタンスのＳＤＬポッドに接続される。いくつかの実施形態では、各ＳＤＬインスタンスは、それ自体のＲＩＣインスタンスのデータＩＯポッド及びサービスポッドでのみ動作する。また、いくつかの実施形態では、ＳＤＬポッドはＳＭＯによって管理され、サービスポッドを介して設定される。ＳＤＬとの間のデータフローには、（１）データＩＯからＳＤＬデータストレージ、（２）ＳＤＬデータストレージからのｘＡｐｐｓ、（３）ＳＤＬデータストレージへのｘＡｐｐｓ、（４）ＳＤＬデータアクセスからのデータＩＯ（Ｅ２ノード情報、サブスクリプション情報の取得など）、及び（５）ＳＤＬ通信との間のサービスポッドによる構成情報の提供及び取得が含まれる。

【0218】

図３４は、ＳＤＬポッド３４１０を有するいくつかの実施形態のＲＩＣインスタンス３４００を示す。説明するように、ＳＤＬ３４１０は、構成エージェント３４１２、ＳＤＬデータパスエージェント３４１４、ＲＩＣ ＳＤＫエージェント３４１７、ＳＤＬ前後プロセッサ３４１６及び３４１８、ならびに１つ以上のＳＤＬデータストア３４２０を含む。ＳＤＬ構成エージェント３４１２は、サービスポッドエージェント３４３０とインタフェースを有する。このエージェント３４１２は、ＳＤＬポッドの他のコンポーネントを設定及び管理する。ＳＤＬポッドはＳＭＯによって管理され、サービスポッド ＃０９０のサービスエージェント３４３０を介して設定される。

【0219】

ＳＤＬデータパスエージェント３４１４は、ＳＤＬポッドがデータパスポッド３４５０の制御スレッド及びデータパススレッドに公開するデータパスインタフェースである。ＳＤＬデータパスエージェント３４１４は、ＳＤＬのためにこれらのエンティティからの通信を処理し、これらのデータパスエンティティのためにＳＤＬデータストア３４２０への読み出し及び書き込みを実行する。いくつかの実施形態では、ＳＤＬデータパスエージェントは、ＳＣＴＰ又は共有メモリライブラリのいずれかを使用してデータパスポッド３４５０と通信するように構成することができる。

【0220】

いくつかの実施形態において、ＲＩＣ ＳＤＫエージェント３４１７は、ＳＤＬポッドがｘＡｐｐポッドのＲＩＣ ＳＤＫに公開するエージェントである。ＲＩＣ ＳＤＫエージェント３４１７は、ＲＩＣ ＳＤＫからＳＤＬへの通信を処理し、ＲＩＣ ＳＤＫに対してＳＤＬデータストア３４２０への読み出し及び書き込みを実行する。いくつかの実施形態では、ＲＩＣ ＳＤＫエージェント３４１７は、ＳＣＴＰ又は共有メモリライブラリのいずれかを使用してＲＩＣ ＳＤＫと通信するように構成することができる。また、このエージェント３４１７は、ＲＩＣ ＳＤＫのＳＤＬキャッシュをＳＤＬデータストア３４２０と同期させるためのキャッシュ同期動作を実行する。また、ｘＡｐｐｓから数十個のコネクションにスケーリングする必要がある場合、いくつかの実施形態のコネクションマネージャは、ＲＩＣインスタンスのｅｐｏｌｌコネクション処理（例えば、いくつかの実施形態のデータＩＯポッドによって使用されるｅｐｏｌｌコネクション処理）を利用する。

【0221】

ＳＤＬエージェント３４１４及び３４１７は、ＲＩＣ ＳＤＫ及びデータパスポッドからのイベントサブスクリプションと通知を処理する。これはＥ２ＡＰサブスクリプション管理とは別のものであるが、概念的には似ている。たとえば、ＳＤＬのこのサブスクリプションサービスを介して、ｘＡｐｐは、キー又はレポートの周波数を介して一部のデータに対する関心を指定する。その後、ＲＩＣ ＳＤＫエージェント３４１７は、サブスクリプションに基づいてこのｘＡｐｐに定期的な更新を提供する。また、データを暗号化及び復号化することによって、いくつかの実施形態においてセキュリティサービスを提供する。

【0222】

データプリプロセッサ及びポストプロセッサ３４１６及び３４１８は、データ上で特定の付加価値アルゴリズムを柔軟に実行するために、いくつかの実施形態においてＳＤＬ３４１０の一部である。いくつかの実施形態では、これらのプロセッサ３４１６及び３４１８の両方が、一方のコンテナで動作し、他方の実施形態では、これらのそれぞれが、ＳＤＬポッド３４１０内の別個のコンテナで動作する。これらのプロセッサのそれぞれはまた、いくつかの実施形態でそれらの動作を実行するために、外部アクセラレータ（例えば、ＧＰＵ３４８０）とインタフェースする。データプリプロセッサ３４１６は、データがＳＤＬデータストア３４２０に格納されるときに、インラインで実行される。

【0223】

いくつかの実施形態では、データポストプロセッサ３４１８は、データがＳＤＬデータストア３４２０から読み出されるときにインラインで実行される。あるいは、あるいは一部の実施形態におけるポストプロセッサ３４１８は、ＳＤＬデータストレージ３４２０に記憶されたデータ上でバックグラウンドで動作するように構成することができる（例えば、このデータストレージからデータを検索し、このデータに対して何らかの動作を行い、結果をデータストレージに格納する）。いくつかの実施形態のデータプロセッサは、Ｅ２ＡＰメッセージのＥ２ＳＭペイロードをエンコード及び／又はデコードする。これは、データパスポッド がデコード及び格納するためにＡＳＮ１文字列をＳＤＬに渡すことができるので利点がある。上述したように、いくつかの実施形態におけるＲＩＣ ＳＤＫは、Ｅ２ＳＭエンコード／デコードサービスを提供するように構成することもできる。

【0224】

いくつかの実施形態においてデータプロセッサ３４１８が実行するポストプロセッサ動作の別の例は、機械訓練された動作である。いくつかの実施形態では、ポストプロセッサ３４１８は、様々なｘＡｐｐ及び／又は様々なポッド（例えば、データパスポッド）によって記憶された様々なデータタプルを収集し、これらのデータタプルを機械学習ネットワーク（例えば、機械学習によって訓練されたニューラルネットワーク）を介して渡す。いくつかの実施形態では、ポストプロセッサ３４１８は、その機械訓練ネットワークを実行するために、ＳＤＬのホストコンピュータの１つ以上のハードウェアアクセラレータ（例えば、１つ以上のＧＰＵ）を使用して、その動作を実行する。ポストプロセッサ３４１８は、図１４－２０を参照して上述したバイパスアプローチを通じてハードウェアアクセラレータにアクセスする。

【0225】

ポストプロセッサ３４１８は、その動作の結果を１つ以上のｘＡｐｐｓに渡すか、又は１つ以上のｘＡｐｐｓが取得するためのＳＤＬデータストア３４２０に結果を格納することができる。機械訓練ネットワークでＳＤＬデータを後処理することによって得られる結果の例は、異常検出（例えば、異常に振る舞っているＥ２ノードを特定する、例えば、あまりにも多くの接続を突然受け取るセルサイト）を含む。

【0226】

ＳＤＬデータストア３４２０に格納される異なるｘＡｐｐ出力を処理するためにＳＤＬポッド３４１０内の機械訓練ネットワークを使用することは、このデータストア３４２０が、ｘＡｐｐサブスクリプションに基づいてＥ２ノードが提供する多数のデータタプルと同様に、いくつかのｘＡｐｐの出力を格納するので、利点がある。多くの場合、個々のｘＡｐｐは、サブスクライブ先のデータタプルと、独自の演算結果及び他のいくつかのｘＡｐｐの出力のみを把握できる。一方、ＳＤＬポッド３４１０は、より大きなＥ２ノード入力データとｘＡｐｐ出力データのセットにアクセスできる。このような後処理を実行するために機械で訓練されたネットワークを使用する代わりに、ポストプロセッサ３４１８は、アルゴリズム（例えば、制約された最適化ソルバ）を使用して、ＳＤＬデータストレージ３４２０に記憶されたデータを後処理する。換言すれば、いくつかの実施形態のポストプロセッサ３４１８は、機械訓練されたネットワークを使用せず、依然として、そのホストコンピュータのハードウェアアクセラレータ（例えば、バイパスパスを介して）を使用して、その動作を実行する。

【0227】

一部の実施形態はまた、ポストプロセッサ３４１８を使用して、第１のｘＡｐｐがＥ２ノードの状態にサブスクライブし始めたときに、Ｅ２ノードの現在の状態を提供する。Ｅ２ノードの状態を受信するために第２のｘＡｐｐを前にサブスクライブした後、ニアＲＴ ＲＩＣは、ある期間にわたってこのノードの状態に関連する複数のデータタプルを格納する。第１のｘＡｐｐがその後Ｅ２ノードの状態にサブスクライブし、このｘＡｐｐ又はデータパスポッドのいずれかが第１のｘＡｐｐのこの状態にアクセスしようとすると、ポストプロセッサ３４１８は、ＳＤＬストレージ内のこのＥ２ノードに対して以前に格納されたすべてのデータタプルを取得し、これらのデータタプルを使用してＥ２ノードの現在の状態を計算する。次に、これが第１のｘＡｐｐに直接、又はデータパスポッドを介して提供する。

【0228】

ＳＤＬデータストア３４２０は、インメモリデータベースである。いくつかの実施形態において、メモリデータベース内のメモリは、コンピュータシステムメモリ（例えば、そのＲＡＭを含むホストコンピュータ不揮発性メモリ）にロードされ、そこから不足するデータベースである。このようなデータベースの例の１つがＲｅｄｉｓである。いくつかの実施形態では、データストレージのサイズは、探索及び記憶待ち時間を最小にするために選択される。既存のデータストレージがその所望の最大サイズに達すると、いくつかの実施形態は、ＳＤＬの同一又は異なるインスタンス内にこのデータストレージの追加のインスタンスを作成する。

【0229】

また、図３４に示すように、一部の実施形態のＳＤＬ３４１０は、ＨＡの理由から、アクティブデータストレージ３４２０及びスタンバイデータストレージ３４２１を有する。さらに、いくつかの実施形態は、データストレージ３４２０に、異なるＲＩＣインスタンスの異なるＳＤＬインスタンスが、ＨＡ及び／又はデータ可用性の理由により、それらのデータの一部又は全部のバックグラウンドで同期することを可能にする。いくつかの実施形態では、ｘＡｐｐｓ及びＲＩＣコンポーネントは、バックグラウンドでスタンバイＳＤＬストレージと同期されるアクティブＳＤＬストレージに対してデータを読み書きする。アクティブＳＤＬストレージに障害が発生した場合、これらの実施形態のＲＩＣは、スタンバイＳＤＬストレージにシームレスに切り替えることができる。また、アクティブＳＤＬ記憶がアップグレードされるときに、ＲＩＣはスタンバイＳＤＬ記憶に切り替えることができる。これにより、ＳＤＬストレージをヒットレスにできる。

【0230】

図１３を参照して前述したように、ＲＩＣ ＳＤＫにはｘＡｐｐのローカルＳＤＬストレージを提供するＳＤＬキャッシュが含まれており、このキャッシュはそのデータをＳＤＬのデータストアと同期する。一部の実施形態では、このＲＩＣ ＳＤＫキャッシュは、メインＳＤＬデータストアからデータをバルク及び定期的にプルする。これにより、メインＳＤＬポッドに対して行われる要求の数を減らすことができる。また、ＲＩＣ ＳＤＫキャッシュは、このデータの一部をローカルに提供することで、ＳＤＬデータを読み取るための遅延を削減する。また、ＲＩＣ ＳＤＫキャッシュは、データをｘＡｐｐポッドでローカルに書き込み、バックグラウンドで同期できるようにすることで、ＳＤＬにデータを書き込む時間を短縮する。いくつかの実施形態におけるＳＤＫキャッシュのサイズは、ＳＤＬのデータストレージ３４２０よりも小さい。また、一部の実施形態では、このサイズは、ＲＩＣ ＳＤＫとともにポッド上で実行される１つ以上のｘＡｐｐのセットの要件に基づいている。

【0231】

いくつかの実施形態において、ＳＤＬ３４１０へのデータのソースは、（１）データパスポッド３４５０の制御スレッド及びデータパススレッド、（２）ＲＩＣ ＳＤＫを介したｘＡｐｐ、（３）Ａ１インタフェースを介してアクセスされる非ＲＴ ＲＩＣのＭＬモデル及びポリシーストレージ及びサーバ、（４）ｘＡｐｐポッド構成ストレージ、及び（５）ＳＭＯの構成サーバを含む。いくつかの実施形態では、ＳＤＬ内のシステムデータの例（例えば、制御スレッドによって書き込まれる）は、（１）Ｅ２ノード情報、（２）セル情報、（３）ＵＥ情報、（４）Ｅ２ノードレポート、（５）ＫＰＭ（主要パフォーマンスメトリック）レポート、及び（６）トポロジ情報（ＥＭＳアダプタから）を含む。

【0232】

いくつかの実施形態におけるＳＤＬトランザクションの例には、（１）ｘＡｐｐによって読み出される、データをＳＤＬに書き込むデータＩＯポッド（制御又はデータＩＯスレッド）、（２）ＳＤＬに書き込まれる、別のｘＡｐｐからデータを読み取るｘＡｐｐ、又は別のｘＡｐｐのためにＳＤＬにデータを書き込むｘＡｐｐ、（３）ＳＤＬポッドで動作するサービスコンテナ（例えば、ポストプロセッサ）が、同じｘＡｐｐ又は別のｘＡｐｐの前に書き込まれたデータの動作を実行するようにＳＤＬに書き込むｘＡｐｐ、（例えば、ＧＰＵサービスを使用するか、又は単に一般ＣＰＵを使用することによって）ＳＤＬから、この動作の結果を取り出すｘＡｐｐ、（４）Ａ１サブスクリプションの一部としてＳＤＬからデータを読み出す及びＳＤＬへのデータを書き込む非ＲＴ ＲＩＣ、（５）ＳＤＬに０１構成データを保存するＳＭＯ、及び（６）ＳＤＬにＭＬデータを保存する非ＲＴ ＲＩＣがある。

【0233】

図３５は、本発明のいくつかの実施形態が実施される電子システムを概念的に示す。電子システム３５００は、コンピュータ（例えば、デスクトップコンピュータ、パーソナルコンピュータ、タブレットコンピュータ、サーバコンピュータ、メインフレーム、ブレードコンピュータなど）、又は任意の他の種類の電子デバイスであってもよい。このような電子システム３５００は、種々のタイプのコンピュータ可読媒体と、種々の他のタイプのコンピュータ可読媒体のインタフェースとを含む。電子システム３５００は、バス３５０５、処理ユニット３５１０、システムメモリ３５２５、読み出し専用メモリ３５３０、永続的ストレージデバイス３５３５、入力デバイス３５４０、及び出力デバイス３５４５を含む。

【0234】

バス３５０５は、集合的に、電子システム３５００の多数の内部デバイスを通信的に接続する全てのシステムバス、周辺装置バス、及びチップセットバスを表す。例えば、バス３５０５は、処理ユニット３５１０を、読み出し専用メモリ３５３０、システムメモリ３５２５及び永続的ストレージデバイス３５３５と通信可能に接続する。

【0235】

これらの種々のメモリユニットから、処理ユニット３５１０は、本発明の処理を実行するために、実行する命令及び処理するデータを検索する。処理ユニット３５１０は、様々な実施形態では、単一プロセッサ又はマルチコアプロセッサであってもよい。

【0236】

読み出し専用メモリ３５３０は、処理ユニット３５１０及び電子システム３５００の他のモジュールによって必要とされる静的データ及び命令を格納する。一方、永続的記憶デバイス３５３５は、読み書き可能なメモリデバイスである。このデバイス３５３５は、電子システム３５００がオフのときでも命令やデータを格納する不揮発性メモリユニットである。本発明の一部の実施形態は、永続的ストレージデバイス３５３５として大容量ストレージデバイス（磁気又は光ディスク及びその対応するディスクドライブなど）を使用する。

【0237】

他の実施形態では、着脱式ストレージデバイス（フロッピーディスク、フラッシュドライブ等）を永続的ストレージデバイス３５３５として使用する。永続的ストレージデバイス３５３５と同様に、システムメモリ３５２５は読み書き可能なメモリデバイスである。しかし、ストレージデバイス３５３５とは異なり、システムメモリ３５２５は、ランダムアクセスメモリなどの揮発性の読み書き可能メモリである。システムメモリ３５２５は、プロセッサが実行時に必要とする命令及びデータの一部を格納する。いくつかの実施形態では、本発明の処理は、システムメモリ３５２５、永続的ストレージデバイス３５３５、及び／又は読み出し専用メモリ３５３０に格納される。これらの種々のメモリユニットから、処理ユニット３５１０は、いくつかの実施形態の処理を実行するために、実行する命令及び処理するデータを検索する。

【0238】

バス３５０５はまた、入出力デバイス３５４０及び３５４５に接続する。入力デバイス３５４０は、ユーザが情報を通信し、コマンドを電子システム３５００に選択することを可能にする。入力デバイス３５４０は、英数字キーボード及びポインティングデバイス（「カーソル制御デバイス」とも呼ばれる）を含む。出力デバイス３５４５は、電子システム３５００によって生成された画像を表示する。出力デバイス３５４５は、カソード線管（ＣＲＴ）又は液晶ディスプレイ（ＬＣＤ）のようなプリンタ及びディスプレイデバイスを含む。一部の実施形態は、入出力デバイスの両方として機能するタッチスクリーンのようなデバイスを含む。

【0239】

最後に、図３５に示すように、バス３５０５はまた、ネットワークアダプタ（図示せず）を介して、電子システム３５００をネットワーク３５６５に結合する。このようにして、コンピュータは、コンピュータのネットワーク（ローカルエリアネットワーク（「ＬＡＮ」）、ワイドエリアネットワーク（「ＷＡＮ」）、イントラネット、又はインターネットのようなネットワークのネットワークの一部であってもよい。電子システム３５００の任意の又は全てのコンポーネントは、本発明と共に使用することができる。

【0240】

いくつかの実施形態は、電子コンポーネント、例えば、マイクロプロセッサ、コンピュータ可読又はコンピュータ可読媒体（代替的にコンピュータ可読記憶媒体、機械可読媒体、又は機械可読記憶媒体と称される）におけるコンピュータプログラム命令を記憶する記憶及びメモリを含む。このようなコンピュータ可読媒体のいくつかの例は、ＲＡＭ、ＲＯＭ、読み出し専用コンパクトディスク（ＣＤ－ＲＯＭ）、記録可能コンパクトディスク（ＣＤ－Ｒ）、書き換え可能コンパクトディスク（ＣＤ－ＲＷ）、読み出し専用デジタル汎用ディスク（例えば、ＤＶＤ－ＲＯＭ、二層ＤＶＤ－ＲＯＭ）、種々の記録可能／書き換え可能ＤＶＤ（例えば、ＤＶＤ－ＲＡＭ、ＤＶＤ－ＲＷ、ＤＶＤ＋ＲＷなど）、フラッシュメモリ（例えば、ＳＤカード、ｍｉｎｉ－ＳＤカード、ｍｉｃｒｏ－ＳＤカードなど）、及び／又はソリッドステートハードドライブ、読み出し専用及び記録可能Ｂｌｕ－Ｒａｙ（登録商標）ディスク、超密度光ディスク、その他の光学又は磁気メディア、及びフロッピーディスクを含む。コンピュータ可読媒体は、少なくとも１つの処理ユニットによって実行可能であり、種々の動作を実行するための命令のセットを含むコンピュータプログラムを記憶することができる。コンピュータプログラムまたはコンピュータコードの例としては、コンパイラによって生成されるようなマシンコードと、インタープリタを使用してコンピュータ、電子コンポーネント、またはマイクロプロセッサによって実行される上位レベルのコードを含むファイルがある。

【0241】

上記の説明では、主にソフトウェアを実行するマイクロプロセッサ又はマルチコアプロセッサを指すが、一部の実施形態は、特定用途向け集積回路（ＡＳＩＣ）、又はフィールドプログラマブルゲートアレイ（ＦＰＧＡ）など、１つ以上の集積回路によって実行される。いくつかの実施形態では、このような集積回路は、回路自体に記憶された命令を実行する。

【0242】

本明細書で使用される「コンピュータ」、「サーバ」、「プロセッサ」、「メモリ」という用語は、すべて電子又はその他の技術的デバイスを指す。これらの用語は、人または人々のグループを除外する。明細書では、用語の表示または表示は、電子デバイス上での表示を意味する。本明細書で使用されるように、「コンピュータ可読媒体」（複数）、「コンピュータ可読媒体」、および「マシン可読媒体」（複数）という用語は、コンピュータが読み取り可能な形式で情報を格納する有形の物理オブジェクトに全体として限定される。これらの語は、任意の無線信号、有線でダウンロードされた信号、及び任意の他のその場限りの信号を含まない。

【0243】

本発明は、多数の特定の詳細を参照して説明したが、当業者であれば、本発明の概念から逸脱することなく、他の特定の形態で本発明を実施することができることを認識するであろう。たとえば、いくつかの図はプロセスを概念的に示している。これらのプロセスの特定の動作は、表示及び説明されている正確な順序で実行されない場合がある。特定の動作は、１つの連続した一連の動作で実行されなくてもよく、異なる特定の動作が様々な実施形態で実行されてもよい。さらに、プロセスは、いくつかのサブプロセスを使用して、又はより大きなマクロプロセスの一部として実装することができる。

【0244】

また、上述のいくつかの実施形態は、ホストコンピュータごとに１つのハードウェアアクセラレータのみを示す。しかしながら、一般的な当業者であれば、いくつかの実施形態の方法論及びアーキテクチャを使用して、１つのホストコンピュータ上の複数のハードウェアアクセラレータへの直接的なパススルーアクセスを提供することができることを認識するであろう。さらに、上述のいくつかの実施形態は、ｘＡｐｐ動作及びｘＡｐｐｓとのニアＲＴ ＲＩＣ通信に関する。一般的な当業者の一人であれば、これらの実施形態は、遠隔通信ネットワークにおけるエッジアプリケーション、およびエッジアプリケーションとのニアＲＴ ＲＩＣ通信に等しく適用可能であることを認識するであろう。したがって、当業者であれば、本発明は、前述の例示的な詳細によって制限されるものではなく、むしろ、添付の請求項によって定義されるものであることを理解するであろう。

【図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】

【手続補正書】

【提出日】2023-09-05

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項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】

計算デバイスであって、
処理ユニットのセットと、
前記処理ユニットの少なくとも１つによって実施されると、請求項１から３５のいずれか１項に記載の方法を実施するプログラムを格納する機械可読媒体と、を含む計算デバイス。

【国際調査報告】