JP5759006B2 - 電気通信ネットワーク・アプリケーションのためのコア抽象化レイヤ - Google Patents

Description

本発明は、マルチ・コア・プロセッサを使用した、単一のモデム・ボードの上のマルチ・セル・サポートのためのコア抽象化レイヤに関する。本発明は、特にモバイル電気通信の技術を対象としており、またそれゆえにこの技術に特に関連して説明されることになるが、本発明は、他の分野およびアプリケーションにおいても有用性を有する可能性があることが、理解されるであろう。

背景として、ＬＴＥ（ロング・ターム・エボリューション（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ））は、将来の通信ネットワーク需要に対処するようにＵＭＴＳ（ユニバーサル・モバイル・テレコミュニケーション・システム（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ））モバイル電話規格を改善することを目指す急速に進化する３ＧＰＰプロジェクトである。ＬＴＥは、ワイヤレス・ネットワークの効率および帯域幅を改善し、コストを低減させ、またサービス経験を向上させる。具体的には、ＬＴＥは、新しいスペクトルの機会を使用し、また他のオープンな規格とのよりよい統合を提供する。ＬＴＥは、一般に、ＥＰＳ（進化型パケット・システム、進化型パケット・コアとも呼ばれる）と一緒にＬＴＥ ＲＡＮ（無線アクセス・ネットワーク（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ））（Ｅ−ＵＴＲＡＮとしても知られている）を含んでいる。

通信システムは、一般に、２つの主要な機能、すなわち、データ・プレーン機能と、制御プレーン機能とに分割される。以前のＬＴＥ製品においては、少なくとも２つのプロセッサ、すなわち制御プレーン機能（非リアル・タイム、例えば、オペレーション、統治、および管理（またはＯＡ＆Ｍ）に関連した機能、ならびにコール処理管理に関連した機能）をサポートする１つのプロセッサと、データ・プレーン機能（リアル・タイム、例えば、ＬＴＥレイヤ２処理）を終了させ、またサポートする別のプロセッサとが、モデム・ボードの上で使用された。制御プレーンと、データ・プレーンとの両方は、制御プレーンについてのＬｉｎｕｘやデータ・プレーン・コアについてのｖＸＷｏｒｋｓ（カリフォルニア州、アラメダ市のウィンド・リバー・システムズ（Ｗｉｎｄ Ｒｉｖｅｒ Ｓｙｓｔｅｍｓ）によって作られ、また販売される）などのリアル・タイムＯＳなど、異なるオペレーティング・システム（ＯＳ：ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ）インスタンスを使用した。一般的に、１つのモデム・ボードは、１つのセクタまたはセルをサポートする。そのようにしてマルチ・セル（例えば、３−セルまたは６−セル）構成をサポートするためには、セルの数と同じ数のモデム・ボードを提供することが、必要であろう。

アプリケーション・レイヤと、ハードウェア・レイヤとの間に位置しており、低レベルのハードウェアに関連した機能からアプリケーション・レイヤを切り離すミドルウェア抽象化レイヤについての必要性が存在する。

処理環境において、ミドルウェア・レイヤは、一般的に、すべてのハードウェア特有の実装の詳細をアプリケーション・レイヤから隠す。新しいサブシステム、コア抽象化レイヤ（ＣＡＬ：ｃｏｒｅ ａｂｓｔｒａｃｔｉｏｎ ｌａｙｅｒ）は、マルチ・コア・プロセッサ・ベースのモデム・ボードのミドルウェア・レイヤに導入される。この新しいモジュールは、マルチ・コア・プロセッサと、そのデータ・パス加速アーキテクチャ（またはＤＰＡＡ：Ｄａｔａ Ｐａｔｈ Ａｃｃｅｌｅｒａｔｉｏｎ Ａｒｃｈｉｔｅｃｔｕｒｅ）とについての抽象化を提供する。このモデム・ボードの展開の場合には、ＣＡＬは、ＬＴＥ Ｌ２アプリケーションについてのゼロ・コピー・ロック・フリー・バッファ管理スキームなど、様々なサービスと、マルチ・セル構成についてのコントローラ・ボードへの無線リンク制御（ＲＬＣ：Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）サービス・データ・ユニット（ＳＤＵ：Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）送信と、コントローラ・ボードからの無線リンク制御（ＲＬＣ）サービス・データ・ユニット（ＳＤＵ）受信とのためのバックプレーン・イーサネット・ドライバ（ＢＥＤ：Ｂａｃｋｐｌａｎｅ Ｅｔｈｅｒｎｅｔ ｄｒｉｖｅｒ）インターフェースについてのサポートとを提供する。

ソフトウェア移植性が、ＣＡＬの主要な目的である。それはまた、アプリケーション、ミドルウェア、およびプラットフォーム・レイヤ・サービスの並列なソフトウェア開発を容易にする低レベルのプラットフォーム・サービスからアプリケーション・レイヤを切り離す。したがって、アプリケーション・レイヤ・ソフトウェアに対してほとんど影響を与えずに、または全く影響を与えずに、マルチ・コア・プロセッサについての多かれ少なかれ、コアを用いて、または異なるベンダーさえも用いて、複数のプロセッサに移行することは比較的簡単であろう。

本発明の一態様においては、電気通信ネットワークにおいてマルチ・セル・サポートを提供するための装置が、提供される。本装置は、モデム・ボードと、マルチ・コア・プロセッサとを含む。プロセッサは、一般に、モデム・ボードに取り付けられた複数のプロセッサ・コアを含んでおり、そこでは少なくとも１つのプロセッサ・コアを使用して、すべての制御プレーン機能を実行し、また残りのプロセッサ・コアを使用して、すべてのデータ・プレーン機能と、プロセッサ・コアの上で実行されるアプリケーション・ソフトウェアからどのようなコア特有の詳細も隠すコア抽象化レイヤとを実行する。コア抽象化レイヤは、様々なモジュールを含んでいる。初期化モジュールは、１つまたは複数のフレーム・マネージャに対してネットワーク構成データと、静的な構文解析分類配信（ＰＣＤ：ｐａｒｓｉｎｇ， ｃｌａｓｓｉｆｙｉｎｇ ａｎｄ ｄｉｓｔｒｉｂｕｔｉｎｇ）ルールとをロードし、また１組の構成ファイルに基づいてコア抽象化レイヤ・フレームワークをセットアップする。バッファ・モジュールは、レイヤ２アプリケーションについてのロック・レス・バッファ管理サービス（ｌｏｃｋ−ｌｅｓｓ ｂｕｆｆｅｒ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｉｃｅｓ）を提供することができる。メッセージング・モジュールは、別のボードへとユーザ・プレーン・データを送信し、または別のボードからユーザ・プレーン・データを受信するように、ゼロ・コピー、およびロック・レスのメッセージング・サービスをレイヤ２ソフトウェアに対して提供することができる。ＰＣＤモジュールは、適切なコアに対して入口フレーム（ｉｎｇｒｅｓｓ ｆｒａｍｅｓ）をルーティングするための、フレーム・マネージャによって使用されるべきＰＣＤのルールおよび構成を提供する。データ・パス加速アーキテクチャ（ＤＰＡＡ）トレース・モジュールは、ＤＰＡＡドライバ・モジュールにおいてトレースをイネーブルにし、またディスエーブルにするためのトレース能力を提供する。

本発明の別の態様においては、電気通信ネットワークにおいてマルチ・セル・サポートを提供するための装置が提供される。本装置は、モデム・ボードと、そのモデム・ボードに取り付けられた複数のプロセッサ・コアを有するマルチ・コア・プロセッサとを含み、そこでは単一のパーティションが、その中に含まれるプロセッサ・コアのすべてを用いて定義され、またそこでは単一のパーティションを使用して、すべての制御プレーン機能、およびすべてのデータ・プレーン機能、ならびに単一パーティションにおいてプロセッサ・コアの上で実行されるアプリケーション・ソフトウェアからどのようなコア特有の詳細も隠すコア抽象化レイヤを実行する。コア抽象化レイヤは、様々なモジュールを含んでいる。初期化モジュールは、１つまたは複数のフレーム・マネージャに対してネットワーク構成データと、静的な構文解析分類配信（ＰＣＤ）ルールとをロードし、また１組の構成ファイルに基づいてコア抽象化レイヤ・フレームワークをセットアップする。バッファ・モジュールは、レイヤ２アプリケーションについてのロック・レス・バッファ管理サービスを提供することができる。メッセージング・モジュールは、別のボードへとユーザ・プレーン・データを送信し、または別のボードからユーザ・プレーン・データを受信するように、ゼロ・コピー、およびロック・レスのメッセージング・サービスをレイヤ２ソフトウェアに対して提供することができる。ＰＣＤモジュールは、適切なコアに対して入口フレームをルーティングするための、フレーム・マネージャによって使用されるべきＰＣＤのルールおよび構成を提供する。データ・パス加速アーキテクチャ（ＤＰＡＡ）トレース・モジュールは、ＤＰＡＡドライバ・モジュールにおいてトレースをイネーブルにし、またディスエーブルにするためのトレース能力を提供する。

本発明のさらに別の態様においては、マルチ・コア・プロセッサについてのコア抽象化レイヤが、提供される。コア抽象化レイヤは、様々なモジュールを含んでいる。初期化モジュールは、１つまたは複数のフレーム・マネージャに対してネットワーク構成データと、静的な構文解析分類配信（ＰＣＤ）ルールとをロードし、また１組の構成ファイルに基づいてコア抽象化レイヤ・フレームワークをセットアップする。バッファ・モジュールは、レイヤ２アプリケーションについてのロック・レス・バッファ管理サービスを提供することができる。メッセージング・モジュールは、別のボードへとユーザ・プレーン・データを送信し、または別のボードからユーザ・プレーン・データを受信するように、ゼロ・コピー、およびロック・レスのメッセージング・サービスをレイヤ２ソフトウェアに対して提供することができる。ＰＣＤモジュールは、適切なコアに対して入口フレームをルーティングするための、フレーム・マネージャによって使用されるべきＰＣＤのルールおよび構成を提供する。データ・パス加速アーキテクチャ（ＤＰＡＡ）トレース・モジュールは、ＤＰＡＡドライバ・モジュールにおいてトレースをイネーブルにし、またディスエーブルにするためのトレース能力を提供する。

本発明の適用可能性のさらなる範囲は、以下で提供される詳細な説明から明らかになるであろう。しかしながら、詳細な説明および特定の例は、本発明の好ましい例を示しながら、本発明の趣旨および範囲の内部にある様々な変更形態および修正形態が、当業者には明らかになるので、例証としてのみ与えられることを理解すべきである。

本発明は、デバイスの様々な部分の構造、構成、および組合せ、ならびに方法のステップの中に存在し、これによって、企図される目的は、以下でより十分に説明され、特許請求の範囲の中で特に指摘され、また添付の図面の中で示されるように、達成される。

本発明の態様によるプラットフォーム・アーキテクチャの一実施形態を示す図である。 本発明の態様によるプラットフォーム・アーキテクチャの代替的な一実施形態を示す図である。 本発明の態様によるコア抽象化レイヤを実装するための例示のアーキテクチャを示す図である。

それらの提示が例示の実施形態だけを示す目的のためであり、また特許請求の範囲の主題を限定する目的のためではない図面を次に参照すると、図１は、現在説明しようとしている実施形態を組み込むことができるシステムの図を提供するものである。このプラットフォーム・アーキテクチャは、一般にモデム・ボードの上で使用されるが、それは、他のアプリケーションにおいても使用され得ることを理解すべきである。この場合には、８つのコア（図において、１２、１４、１６、１８、２０、２２、２４、および２６のように示される）を有するマルチ・コア・プロセッサ１０が、提供される。しかしながら、マルチ・コア・プロセッサ１０は、任意の数のコアを有することができることを理解すべきである。この例においては、第１のパーティション２８は、第１のオペレーティング・システム（ＯＳ１）３２を実行する制御プレーン３０についてのものである。第１のパーティション２８はまた、オペレーション、統治、および管理（ＯＡ＆Ｍ）３４と、ＢＣＳ／ＵＰＳ ３６とを含む。ＢＣＳ／ＵＰＳ ３６は、ＯＡ＆Ｍエンティティなどのアプリケーション・ソフトウェアに対してハードウェアについての抽象化を提供するミドルウェア・レイヤである。残りの７つのコアのおのおの当たりに１つの、７つのＡＭＰパーティション（図において、３８、４０、４２、４４、４６、４８、５０のように示される）は、おのおのが、第２のオペレーティング・システム（ＯＳ２）５４を実行するデータ・プレーン５２についてのものである。

レイヤ２（Ｌ２）処理のすべては、一般的に、プロセッサの７つのコアの上で実行される。レイヤ２は、コンピュータ・ネットワーキングの７レイヤのＯＳＩモデルのうちのデータ・リンク・レイヤである。データ・リンク・レイヤは、広域ネットワークにおける隣接したネットワーク・ノードの間で、または同じローカル・エリア・ネットワーク・セグメントの上のノードの間でデータを転送するプロトコル・レイヤである。データ・リンク・レイヤは、ネットワーク・エンティティの間でデータを転送する機能的手段および手続き的手段を提供し、また物理レイヤにおいて起こる可能性のあるエラーを検出し、場合によってはエラーを訂正する手段を提供することもある。データ・リンク・プロトコルの例は、ローカル・エリア・ネットワーク（マルチ・ノード）のためのイーサネットと、ポイント・ツー・ポイント・プロトコル（ＰＰＰ）と、ＨＤＬＣと、ポイント・ツー・ポイント（デュアル・ノード）接続のためのＡＤＣＣＰとである。この場合には、Ｌ２は、一般に、ＬＴＥエア・インターフェースのために必要とされるＬ２スケジューラ処理のことを意味しており、これは、非常に厳しいリアル・タイム要件を有する。

レイヤ１（Ｌ１）処理のすべては、一般的に、ＤＳＰおよびＦＰＧＡの上で実行される。とりわけ、コア抽象化レイヤ（ＣＡＬ）５６は、Ｌ２アプリケーション・ソフトウェアからコア特有の詳細を隠す。

例示のアーキテクチャは、すべてのこれらのパーティションが、独立に実行され、また互いに破損し合わないことを保証する（すなわち、障害分離を保証する）、ハイパーバイザ５８などのスーパーバイザ・ソフトウェア・エンティティをさらに含むことができる。ハイパーバイザは、仮想化において使用されるソフトウェア・プログラムである。ハイパーバイザは、いくつかのオペレーティング・システムが、与えられた１つのハードウェアの上で並んで実行されることを可能にする。従来の仮想コンピューティング・プログラムとは違って、ハイパーバイザは、ターゲット・ハードウェアの上で直接に実行される。これにより、ゲスト・オペレーティング・システムと、ハイパーバイザとの両方は、ずっとより効率的に実行することができるようになる。可能性があるハイパーバイザのリストは、それだけには限定されないが、以下の複数のタイプを、すなわち、Ｘｅｎ（Ｃｉｔｒｉｘ）と、ＫＶＭ（カーネル・ベースの仮想マシン）と、ＶＭｗａｒｅ ＥＳＸ／ｖｍｋｅｒｎｅｌと、マイクロソフト（Ｍｉｃｒｏｓｏｆｔ） Ｈｙｐｅｒ−Ｖと、ＰｏｗｅｒＶＭ（ＩＢＭ）と、論理ドメイン（Ｌｏｇｉｃａｌ Ｄｏｍａｉｎｓ）／Ｏｒａｃｌｅ ＶＭと、ウィンド・リバー・ハイパーバイザ（Ｗｉｎｄ Ｒｉｖｅｒ Ｈｙｐｅｒｖｉｓｏｒ）とを含む。

この例においては、プロセッサ１０は、３つのセル（図において６０、６２、および６４として示される）にサービスを行う。各セルは、アップリンク（ＵＬ）スケジューラ（図において、６６、７０、および７４として示される）と、ダウンリンク（ＤＬ）スケジューラ（図において６８、７２、および７６として示される）とを必要とする。

無線リンク制御（ＲＬＣ）レイヤを使用して、ＬＴＥエア・インターフェースを通して送信され、また受信されるパケット・フレームの上で、エラーをセグメント化し、連結させ、また訂正することが、知られている。無線リンク制御および媒体アクセス制御の（ＲＬＣ／ＭＡＣ）ソフトウェアは、ＧＰＲＳ（２．５Ｇ）ワイヤレス・スタックの中で使用される。ＲＬＣ／ＭＡＣソフトウェアは、移動局と基地局制御装置（ＢＳＣ：ｂａｓｅ ｓｔａｔｉｏｎ ｃｏｎｔｒｏｌｌｅｒ）との間の肯定応答されたデータ転送と、肯定応答されないデータ転送とを提供する。これに関して、プロセッサ１０は、ＲＬＣ／ＭＡＣブロック７８をさらに含んでおり、このＲＬＣ／ＭＡＣブロックは、モバイルとネットワークとの間で使用されるエア・インターフェースの上の基本トランスポート・ユニットである。ＲＬＣ／ＭＡＣブロックを使用して、データとＲＬＣ／ＭＡＣ信号とを搬送する。

次に図２を参照すると、代替的なプラットフォーム・アーキテクチャ１００が、示されている。このアーキテクチャは、一般にモデム・ボードの上で使用されるが、このアーキテクチャが他のアプリケーションにおいても使用され得ることを理解すべきである。この実施形態においては、１つのパーティションは、その中のすべての８つのコアを用いて定義される。しかしながら、マルチ・コア・プロセッサ１００は、任意の数のコアを有し得ることを理解すべきである。この実施形態を用いて、それゆえに、すべてのコア（例えば、８つのコア）の上で実行される単一のＳＭＰ ＯＳインスタンス１０２を使用することが可能である。制御プレーンと、データ・プレーンとは、今や１つのＯＳインスタンスの下にあるので、データ・プレーンに伴う問題が、制御プレーンも同様に駄目にすることにならないことを保証する配慮が必要とされる。

この例においては、プロセッサ１００は、３つのセル（図において１０４、１０６、および１０８として示される）にサービスを行う。各セルは、アップリンク（ＵＬ）スケジューラ（図において、１１０、１１２、および１１４として示される）と、ダウンリンク（ＤＬ）スケジューラ（図において１１６、１１８、および１２０として示される）とを必要とする。ＲＬＣ／ＭＡＣブロック１２２もまた含められ、このＲＬＣ／ＭＡＣブロックは、モバイルとネットワークとの間で使用されるエア・インターフェースの上の基本トランスポート・ユニットである。ＲＬＣ／ＭＡＣブロックを使用して、データと、ＲＬＣ／ＭＡＣ信号とを搬送する。プロセッサ１００はまた、ＯＡ＆Ｍ １２４と、ＢＣＳ／ＵＰＳ １２６とを提供する。

第１の実施形態におけるように、プロセッサ１００は、コア抽象化レイヤ（ＣＡＬ）１２８を含んでおり、このコア抽象化レイヤは、Ｌ２アプリケーション・ソフトウェアからコア特有の詳細を隠す。

基地局のリアル・タイム性能の必要性を満たすために、ＰＲＥＥＭＰＴ＿ＲＴパッチを有するＳＭＰリナックス（ＳＭＰ Ｌｉｎｕｘ）などのＯＳが、使用されることもある。もちろん、他のオペレーティング・システムも使用され得ることを理解すべきである。ＳＭＰ構成は、監視されたＡＭＰ構成の決定論的動作を失う傾向があることもある。ＳＭＰ構成において、決定論的動作を達成するために、本システムは、コア予約とコア親和性構造とを使用して、ＡＭＰのようなシステム動作を達成するようにして実装されることが好ましい。これはまた、例えば、ＰＲＥＥＭＰＴ＿ＲＴ ＯＳを有するＳＭＰリナックスから最高の性能を引き出すためにも望ましい。バッファ管理などのロック・レス・ゼロ・コピー・サービスと、メッセージング・サービスとの使用は、ＰＲＥＥＭＰＴ＿ＲＴ ＯＳを有するＳＭＰリナックスの使用によって課される任意のレイテンシー問題に対処する助けを行うこともできる。

図１および２に示されるようなコア抽象化レイヤ（５６、１２８）の主要機能のうちの１つは、マルチ・コア・プラットフォームの全部の能力を利用する様々なサービスをＬ２処理などの高レベルアプリケーションに提供することである。コア抽象化レイヤは、このようにして、いくつかの目標を達成するように設計される。第１に、コア抽象化レイヤは、より高いレベルのアプリケーション・ソフトウェア（すなわち、Ｌ２ソフトウェア）からＤＰＡＡおよびマルチ・コア特有の実装を隠しながら、ＢＥＤ（バックプレーン・イーサネット・ドライバ（Ｂａｃｋｐｌａｎｅ Ｅｔｈｅｒｎｅｔ Ｄｒｉｖｅｒ））ＤＰＡＡ−ベースのインターフェースをサポートすべきである。第２に、コア抽象化レイヤは、Ｐ４０８０のＤＰＡＡハードウェア・コンポーネントを利用して、入口方向と出口方向との両方において、ユーザ・プレーン・データについての加速されたデータ・パスを提供すべきである。第３に、コア抽象化レイヤは、できる限り多くの柔軟性を実現して、そのようにして構成変更に（すなわち、コード変更を必要とすることなく）簡単に適応させるべきである。ＣＡＬ構成の一例は、バッファ・プールと、入口フレーム待ち行列と、出口フレーム待ち行列とについてのＤＰＡＡリソース構成である。

次に図３を参照すると、これらの目標および他の目標を達成する例示のアーキテクチャ３００が、示されている。これに関して、コア抽象化レイヤ（ＣＡＬ）３０１は、ユーザ−空間の中に、コア抽象化レイヤ初期化（ＣＡＬＩｎｉｔ）モジュール３０２と、コア抽象化レイヤ・バッファ（ＣＡＬＢｕｆ）モジュール３０４と、コア抽象化レイヤ・メッセージング（ＣＡＬＭｓｇ）モジュール３０６と、コア抽象化レイヤ構文解析分類配信（ＣＡＬＰｃｄＦｍｃ）モジュール３０８と、コア抽象化レイヤＤＰＡＡトレース（ＣＡＬＤｐａａＴｒａｃｅ）モジュール３１０とを含む様々なモジュールを含んでいる。ＣＡＬ ３０１は、カーネル−空間モジュールを、すなわち、コア抽象化レイヤＤＰＡＡドライバ（ＣＡＬＤｐａａＤｒｉｖｅｒ）３１２を含むこともできる。

アーキテクチャ３００は、リナックスＰｒｅｅｍｐｔ ＲＴなど、適切なオペレーティング・システム３１４をさらに含んでいる。オペレーティング・システム３１４は、上記のＣＡＬＤＰａａドライバ３１２、少なくとも１つのフレーム・マネージャ（ＦＭａｎ）ドライバ３１６、少なくとも１つのバッファ・マネージャ（ＢＭａｎ）ドライバ３１８、少なくとも１つの待ち行列マネージャ（ＱＭａｎ）ドライバ３２０など、様々なドライバをサポートする。

図３に示されるように、アーキテクチャ３００は、Ｐ４０８０ ＣｏｒｅＮｅｔファブリック３２２を適切に含むことができ、このＰ４０８０ ＣｏｒｅＮｅｔファブリックは、スケーラブル・オン・チップ・ネットワークが複数のパワー・アーキテクチャ処理コアをキャッシュ、スタンド・アロン・キャッシュ、およびメモリ・サブシステムと接続するために適切な相互接続アーキテクチャである。

Ｐ４０８０プロセッサは、新しいデータ・パス加速アーキテクチャ（ＤＰＡＡ）の実装形態を含んでいる。したがって、アーキテクチャ３００は、Ｐ４０８０ ＤＰＡＡ ３２４をさらに含むことができる。ＤＰＡＡ ３２４は、ネットワーク・インターフェースと、ハードウェア・アクセラレータとを含めて、負荷拡散やリソースの共用などのマルチ・コア・ネットワーク処理を最適化するように設計される。示されるように、ＤＰＡＡ ３２４は、一般に、ＢＭａｎ ３２６、ＱＭａｎ ３２８、第１および第２のＦｍａｎ ３３０および３３２など、様々なマネージャをそれぞれ含んでいる。

ＣＡＬＩｎｉｔモジュール３０２は、一般的に、ＬＴＥネットワーク構成と、任意の静的ＰＣＤルールとをフレーム・マネージャ３３０および３３２に対してロードし、また１組の構成ファイルに基づいてＣＡＬフレームワークをセットアップする。ＣＡＬＩｎｉｔモジュール３０２は、ＣＡＬ構成（例えば、ユーザ・プレーンＤＰＡリソース）をロードしセットアップするようにＦＭａｎ ＰＣＤと、ＣＡＬＤｐａａドライバ３１２とを構成するＦＭＣ（ＦＭａｎ構成ツール）（図示されず）、または任意の数のＦＭａｎ ＡＰＩ（単数または複数）（図示されず）とインターフェースする。本明細書において使用される場合、用語ＡＰＩ（またはアプリケーション・プログラミング・インターフェース）は、ソフトウェア・プログラムによって実装されるインターフェースを意味しており、このソフトウェア・プログラムは、他のソフトウェアと相互作用することを可能にする。それは、ユーザ・インターフェースが、ユーザとコンピュータとの間の相互作用を容易にするやり方と同様に、異なるソフトウェア・プログラムの間の相互作用を容易にする。ＡＰＩは、アプリケーションと、ライブラリと、オペレーティング・システムとによって実装されて、それらの用語集と呼び出す慣習とを決定し、またＡＰＩを使用して、それらのサービスにアクセスする。ＡＰＩは、ＡＰＩの消費者と、実装者との間で情報をやりとりするために使用されるルーチンと、データ構造と、オブジェクト・クラスと、プロトコルとについての仕様を含むことができる。

ＣＡＬＩｎｉｔモジュール３０２はまた、ＬＥＣ（リナックス・エラー・コレクタ（Ｌｉｎｕｘ Ｅｒｒｏｒ Ｃｏｌｌｅｃｔｏｒ））サービスを経由してデバッグ・メカニズムを提供し、これによって様々なＣＡＬおよびＤＰＡＡのリソースの状況および統計データが、事後の調査のためのＬＥＣのスナップショット・ファイルに対して収集され、またダンプされる。

ワイヤレス多重アクセス通信システムにおいては、トランスミッタとレシーバとは、マルチ・レイヤの通信スタックを使用して、情報をやりとりすることができることが、知られている。レイヤは、例えば、物理レイヤ、媒体アクセス制御（ＭＡＣ）レイヤ、無線リンク制御（ＲＬＣ）レイヤ、プロトコル・レイヤ（例えば、パケット・データ・コンバージェンス・プロトコル（ＰＤＣＰ：ｐａｃｋｅｔ ｄａｔａ ｃｏｎｖｅｒｇｅｎｃｅ ｐｒｏｔｏｃｏｌ）レイヤ）、アプリケーション・レイヤなどを含むことができる。ＲＬＣレイヤは、ＰＤＣＰレイヤからサービス・データ・ユニット（ＳＤＵ）を受信し、またＭＡＣレイヤに対して送信するためにＳＤＵをＲＬＣプロトコル・データ・ユニット（ＰＤＵ）へと連結し、またはセグメント化する。

それに応じて、ＣＡＬＢｕｆモジュール３０４は、ＲＬＣ ＳＤＵ処理において使用するためにＬ２アプリケーションについてのロック・レス・バッファ管理サービスを提供する。当技術分野において知られているように、非ブロッキング・アルゴリズムは、共用されたリソースについて競合するスレッドが、それらの実行が相互排除によって無期限に延期されないことを保証する。システム規模の進歩が保証されている場合に、非ブロッキング・アルゴリズムは、ロック・レス（またはロック・フリー）である。ＣＡＬＢｕｆモジュール３０４はまた、バッファ・プール統計データ（例えば、プール枯渇状態、枯渇カウント、プール使用可能状態、プール割付エラー・カウントなど）についての問い合わせをサポートする。ＣＡＬＢｕｆモジュール３０４は、サービスを実装するＣＡＬＤｐａａドライバ３１２とインターフェースする。ＣＡＬＢｕｆモジュール３０４は、マルチ・コア環境における適切なシステム・オペレーションのために非常に重要であるロック・レス・バッファ管理スキームを提供し、ここでは、非リアル・タイム・プロセスによってとられるロックは、そのロックのリリースを待つリアル・タイム・プロセスの場合に、レイテンシー問題を引き起こす可能性がある。

ＣＡＬＭｓｇモジュール３０６は、ＤＰＡＡを経由して、ＲＬＣ ＳＤＵを受信し（入口）、またＲＬＣ ＳＤＵを送信する（出口）サービスを提供する。ＣＡＬＭｓｇモジュール３０６はまた、Ｔｘ／Ｒｘイーサネット・インターフェース統計データ（例えば、受信され、または送信されるＦＤの数、脱落されるＦＤの数、悪いＦＤの様々なタイプなど）についての問い合わせをサポートする。ＣＡＬＭｓｇモジュール３０６は、サービスを実装するＣＡＬＤＰａａドライバ３１２とインターフェースする。ＣＡＬＭｓｇモジュール３０６は、プロトコル・スタックの使用なしに、ＴＣＰ／ＵＤＰ ＩＰパケットを送信し、また受信するゼロ・コピー・ロック・レス・メッセージング・サービスをＬＴＥ Ｌ２アプリケーションに対して提供する。これは、アプリケーション・ソフトウェアが、ＬＴＥシステムの適切なシステム動作を破壊してしまう可能性がある制限されないレイテンシー・スパイクに出合わないことを保証するために必要とされ、このＬＴＥシステムは、非常に厳しいリアル・タイム処理要件を有する。

ＣＡＬＰｃｄＦｍｃモジュール３０８は、適切なコアに対して入口フレームをルーティングするための各ＦＭａｎ（３３０、３３２）によって使用されるべき、構文解析分類配信（ＰＤＣ）のルールおよび構成を提供する。

ＣＡＬＤＰａａＴｒａｃｅモジュール３１０は、ＣＡＬＤｐａａＤｒｉｖｅｒ３１２においてトレースをイネーブルにし、またディスエーブルにするためのトレース能力を提供する。ＣＡＬＤＰａａＴｒａｃｅモジュール３１０は、そのようなサービスを実装するＣＡＬＤｐａａドライバ３１２とインターフェースする。

ＣＡＬＤｐａａＤｒｉｖｅｒ ３１２は、ＣＡＬ ３０１のカーネル−空間コンポーネントであり、このドライバは、ＢｍａｎおよびＱｍａｎのＡＰＩを使用して、バッファ管理サービスおよびメッセージング・サービスを実装し、また提供する助けを行う。ＣＡＬＤｐａａＤｒｉｖｅｒ ３１２は、ユーザ・プレーン・データ配信のために使用されるべきＤＰＡＡリソース（バッファ・プールおよびフレーム待ち行列）を管理すること、オープン、リリース、初期化のためのｉ−ｏ−制御（ｉｏｃｔｌ）、バッファ管理、メッセージング・サービスなど、様々なファイル・オペレーションを経由してユーザ−空間インターフェースを他のＣＡＬモジュールに対して提供すること、カーネル−ユーザ空間（Ｋ−Ｕ）バッファ・マッピングを実行すること、ＤＰＡＡバッファ・プールと、レシーバおよびトランスミッタとの統計データを提供すること、およびリング・バッファを管理するためのサービスを実装することを担っている。リング・バッファは、ＣＡＬのＬ２ソフトウェア待ち行列を表し、また特定のＬ２ ＤＬＴに向かうことになっているＦＤを記憶するために使用されることに注意すべきである。ＣＡＬＭｓｇモジュール３０６は、Ｌ２がリングからバッファ記述子を取り出すためのＡＰＩを提供する。

上記で説明されるＣＡＬコンポーネントのすべては、ＣＡＬＤｐａａＤｒｉｖｅｒ ３１２を除いて、一般に、プラットフォーム・ミドルウェア（ユーザ−空間の中で実行される）である。ＣＡＬＤｐａａＤｒｉｖｅｒ ３１２は、カーネル−空間の中で実行されるカスタム・ドライバであり、それは、ＣＡＬユーザ空間ミドルウェアによって必要とされるサービスを−とりわけ、Ｐ４０８０ ＤＰＡＡハードウェア・コンポーネントに依存するこれらのサービスを実装し、また提供するように設計される。

ＣＡＬＩｎｉｔモジュール３０２は、様々な機能を提供することを担っている。起動時におけるマスタ・コアでは、ＣＡＬＩｎｉｔモジュール３０２は、ＣＡＬフレームワークをセットアップして、「高速パス」処理をサポートする。このステップは、ＣＡＬＤｐａａＤｒｉｖｅｒ ３１２を初期化するステップを含むことができ、初期化するステップは、（ａ）ユーザ・プレーン・データ（例えば、バッファ・プール、ＦＱ（またはフレーム待ち行列（ｆｒａｍｅ ｑｕｅｕｅｓ））を処理するために必要とされる様々なＤＰＡＡリソースを生成し、また（ｂ）ＤＰＡＡ（例えば、バッファ・プール構成、ＦＱ、および入口ＦＱとＤＬＴ ＩＰアドレスとの間の関連付けなどを保持する内部テーブル）を経由してバッファ管理サービスおよびメッセージング・サービスをサポートするために必要とされるＣＡＬインフラストラクチャを生成することになる。ＣＡＬＩｎｉｔモジュール３０２はまた、ＬＴＥ ＦＭＣの（静的な）ＰＣＤルールとネットワーク構成とをロードする。

起動時におけるマスタ・コアおよびユーザ・プレーン・コア（ここにＬ２ ＤＬＴおよびＬ２アップリンク・スケジューラのスレッドが、バインドされる）では、ＣＡＬＩｎｉｔモジュール３０２は、ＬＥＣを用いてＣＡＬ ３０１を実行し、登録し、またアタッチする。プロセスが、異常に終了する（例えば、ＬＥＣの致命的なエラーが引き起こされる）ときに、これは、呼び出すべきルーチンをＬＥＣのスナップショット・タスクに提供する。このルーチンは、バッファ・プール統計データとＴｘ／Ｒｘイーサネット・インターフェース統計データとを含めて、様々なＣＡＬデータとＤＰＡＡデータとを収集し、またデバッグの目的のためにそのデータをＬＥＣのスナップショット・ファイルにダンプする。

ＣＡＬＢｕｆモジュール３０４は、「高速パス」データ処理のために排他的に使用されるべきバッファ管理サービスを提供する。ＣＡＬＢｕｆモジュール３０４は、ユーザ−空間ＡＰＩをＬ２アプリケーションに対して提供する。ＣＡＬＢｕｆモジュール３０４は、ＣＡＬＤｐａａＤｒｉｖｅｒ ３１２と協調して、ＣＡＬＤｐａａドライバ３１２が、生成するが、Ｂｍａｎ ３２６によって管理されるバッファについてのゼロ・コピーおよびロック・レス・バッファ管理のサービスを提供する。

ＣＡＬＢｕｆモジュール３０４は、数ある中でも以下のサービスを、すなわち
１．バッファ・サイズを仮定して、バッファを獲得すること、
２．与えられたサイズの与えられた数のバッファを獲得し、また次いで、使用可能なバッファのリストをバッファの要求された数になるまで戻すこと、
３．指定されたバッファをリリースすること、
４．バッファのリストをリリースすること、および
５．バッファ・プール統計データについて問い合わせを行うこと
をサポートするＡＰＩを実装し、また提供する。

ＣＡＬＭｓｇモジュール３０６は、別のボード（すなわち、ｅＣＣＭ）に対してユーザ・プレーン・データを送信し、また別のボードからユーザ・プレーン・データを受信するメッセージング・サービスをＬ２ソフトウェアに対して提供する。ＣＡＬＭｓｇモジュール３０６は、一般に、ＤＰＡＡを経由してロック・レス・ゼロ・コピー・メッセージング・サービスを提供するＣＡＬＤｐａａＤｒｉｖｅｒ ３１２とインターフェースする。この機能により、Ｌ２アプリケーション・ソフトウェアは、制限されないレイテンシー遅延を回避するプロトコル・スタックの使用なしに、ＴＣＰ／ＵＤＰ ＩＰパケットを送信し、また受信することができるようになる。

ＣＡＬＭｓｇモジュール３０６は、以下の段落において説明されるサービスなど、様々なサービスをサポートするＡＰＩを実装し、また提供する。

１つの可能性のあるサービスは、ＣＡＬＭｓｇサービスへの（Ｌ２）アプリケーション・エンティティの登録であり、それによってエンティティは、「高速パス」を経由して着信パケットを受信することができる。この登録プロセス中に、ＣＡＬのＬ２ソフトウェア待ち行列（リング・バッファ）が、エンティティに向かうことになっている、受信されたバッファ記述子を保持するように生成される。この登録中にもまた、ＣＡＬＭｓｇモジュール３０６は、ＩＰアドレスに対する入口ＦＱと、他の処理（例えば、フレームがＦＱに到達するときに、どのリング・バッファに対してバッファ記述子をプッシュすべきかを決定すること）において後の参照（単数または複数）のためのリングＩＤとの間の関連付けを生成し、カーネル−空間からユーザ−空間への関連のあるバッファ・プールのマッピングを実行し、また（静的ルールを経由してまだ行われていない場合）アプリケーション・エンティティについてのＰＣＤルールを構成する。さらに、登録プロセスの最初に、ＣＡＬ ３０１は、アプリケーションによって獲得されるすべてのバッファが、スレッドがクラッシュするときに、適切にリリースされることを保証するための防衛戦略を実装する。

第２のサービスは、アプリケーション・エンティティに向かうことになっているフレームを取り出すことである。戻されたバッファ・アドレスが、イーサネット・ヘッダで開始されるペイロードの開始を指し示すことになることが期待される。

第３のサービスは、ユーザ・プレーン・データ（例えば、ｅｔｈ０）を処理するように構成されたイーサネット・インターフェースの上でＤＰＡＡを経由してメッセージを外部エンティティに対して送信することである。Ｌ２は、必要とされるすべてのヘッダ（イーサネット、ＩＰ、ＵＤＰ）を入力し、またハードウェアは、ＩＰチェックサムとＵＤＰチェックサムとを生成し、また入力するように適切に構成されていることになることが期待される。

第４のサービスは、レシーバおよびトランスミッタのポート統計データについて問い合わせを行うことである。

第５のサービスは、ＣＡＬＭｓｇモジュール３０６からアプリケーション・エンティティの登録を解除することである。ひとたびアプリケーション・エンティティの登録が解除された後に、アプリケーション・エンティティは、もはや「高速パス」を経由してパケットを受信することができなくなる。登録解除プロセスの一部として、ＣＡＬは、アプリケーション・ソフトウェアによって獲得されるすべてのバッファをリリースすることになる。ＣＡＬＭｓｇモジュール３０６を使用して、高速パスを経由してフレームを受信する場合には、関連するリング・バッファおよびＰＣＤルールもまた、取り除かれるであろう。

ＣＡＬＰｃｄＦｍｃモジュール３０８は、少なくともネットワーク・インターフェース構成ファイルと、ＣＡＬ ３０１が、ＦＭａｎ（３３０、３３２）のＰＣＤコンポーネントを初期化し、構成するために使用することができる構文解析分類配信（ＰＣＤ）ルールとを提供する。ＦＭａｎのＰＣＤコンポーネントは、適切なコアへの着信フレームの配信を可能にするように構成される必要がある。

例示のアーキテクチャを用いて、ＬＴＥ ＰＣＤルールを（静的に、または動的に）定義するために使用され得る戦略の一例が、以下で説明される。

ユーザ−空間の配信に関して、ＩＰヘッダおよびＵＤＰヘッダとともにユーザ−空間イーサネット・インターフェース（ｅｔｈ０）に到着するすべてのフレームは、（ＦＭａｎによる）粗い分類を通過することになる。これは、適切なＰＣＤルールのプロビジョニングを経由して（静的に、または動的にのいずれかで）達成され得る。正確なマッチ配信スキームを使用して、宛先ＩＰアドレスの全部または一部を（宛先ＩＰアドレスのどの部分が静的に定義され得るかに応じて）特定のコアに対してマッピングすることができる。マッチしていない任意のフレームは、デフォルトにより、制御プレーン・コア（すなわち、ｃｏｒｅ０）に割り当てられるＦＱのキューに加えられることになる。

デフォルトの配信に関して、制御プレーン・イーサネット・インターフェース（ｅｔｈ１）またはデバッグ・イーサネット・インターフェース（ｅｔｈ２）に到達するすべてのフレームは、制御プレーン・コア（すなわち、ｃｏｒｅ０）に対して配信されることになる。

どのようにして、またいつＰＣＤルールが、Ｆｍａｎにおいて定義され、また構成されるかは、ＰＣＤルールが、プラットフォームの初期化中に、あらかじめ定義され、また構成されるかどうかに依存する。Ｌ２（ダウンリンク）スレッドのＩＰアドレスと、様々なコアに対するそれらのバインディングが、前もって決定され得ないので、ボードの起動および初期化中に入口（ダウンリンク）ユーザ・プレーン・パスについてのＦｍａｎのＰＣＤルールを定義することは、可能ではない。それゆえに、ユーザ・プレーン・データ・パスについてのＰＣＤルールは、セルが構成された後のランタイムに、定義される必要がある。ダウンリンク・スケジューラ（ＤＬＴ）ＩＰアドレスと、スレッドがバインドされる相手のコアとは、ＤＬＴが、ＣＡＬＭｓｇモジュール３０６に登録されるときには、一般に知られている。他方、制御プレーンとデバッグ・トラフィックとについてのディスパッチ・ルールは、直接的なものであり、どのような変形形態にも依存しない。したがって、制御プレーンおよびデバッグ・プレーンのトラフィックについてのＰＣＤルールは、静的に定義され、また初期化中に構成されることもある。

制御プレーン・イーサネット・インターフェースについてのＰＣＤルールと、デバッグ・イーサネット・インターフェースについてのＰＣＤルールとは、前もって定義され、また（ＦＳＬ）イーサネット・ドライバが初期化されるときに、構成されることもある。ユーザ・プレーン・イーサネット・インターフェースでは、ＰＣＤルールは、知られているＩＰアドレスとバインディング・コアとを用いて、ＤＬＴが過ぎた後のランタイムに定義され、また構成される必要がある。

ＣＡＬＤＰａａＴｒａｃｅモジュール３１０は、ＣＡＬＤｐａａドライバ３１２と、様々なＰ４０８０ ＤＰＡＡコンポーネント（ドライバ）とについてトレースし、デバッグすることをイネーブルにし、またディスエーブルにする様々なサービスを提供する。これらのサービスは、例えば、（１）ＣＡＬＤｐａａドライバ・トレースをイネーブルにし、またディスエーブルにすること、（２）Ｂｍａｎトレース（将来）をイネーブルにし、またディスエーブルにすること、（３）Ｑｍａｎトレース（将来）をイネーブルにし、またディスエーブルにすること、および（４）Ｆｍａｎトレース（将来）をイネーブルにし、またディスエーブルにすることを含む。

ＣＡＬ ３０１が、使用され得る様々なシナリオが存在する。例えば、ＣＡＬ ３０１は、初期化時に（すなわち、プラットフォームの起動中に）マスタ・コアをサポートすることができる。すなわち、
１．ＣＡＬ構成データ（例えば、ＤＰＡＡリソース構成）をロードすること、およびＣＡＬＤｐａａドライバ３１２を初期化することにより、ＣＡＬのフレームワークをセットアップする。
２．もしあれば、ＬＴＥ ＦＭＣのネットワーク・インターフェース構成と静的ＰＣＤルールとをロードする。

ＣＡＬ ３０１は、初期化時にユーザ−空間プロセスをサポートすることもできる。その場合には、ＣＡＬ ３０１が、ロードされ、初期化されるときに、ＣＡＬ ３０１は、それ自体をＬＥＣに登録し、またはアタッチし、プロセスが終了するときに、実行すべき、ＬＥＣのスナップショット・タスクに対してルーチンを提供する。このルーチンは、Ｂｍａｎにより管理されたバッファ・プールとＴｘ／Ｒｘイーサネット・インターフェースに関連した様々な統計データを収集し、また事後の調査のためにデータをＬＥＣのスナップショット・ファイルにダンプすることになる。

ＣＡＬ ３０１は、パケットの送信（すなわち、Ｌ２ ＵＬＵソフトウェア処理）をサポートすることもできる。すなわち、
１．ＵＬＵ（アップリンク・スケジューラ）は、それ自体をＣＡＬＭｓｇ ３０６に登録し、そのようにして、それは、ＤＰＡＡを経由してパケットを送信することができる。
２．ＵＬＵは、ＣＡＬＢｕｆサービスを使用してバッファを割り付ける。
３．ＵＬＵは、すべての必要とされるヘッダ（イーサネット／ＩＰ／ＵＤＰ）およびペイロードとともに送信されるべきデータをバッファに入力する。
４．ＵＬＵは、ＣＡＬＭｓｇサービスを使用してＤＰＡＡを経由してメッセージを宛先エンティティに対して送信する。

ＣＡＬ ３０１は、パケットの受信（すなわち、Ｌ２ ＤＬＴソフトウェア処理）をサポートすることもできる。すなわち、
１．ＤＬＴ（ダウンリンク・スケジューラ）は、それ自体をＣＡＬＭｓｇ ３０６に登録し、そのようにして、それは、ＤＰＡＡを経由してパケットを受信することができる。
２．あるデルタＴ時間（すなわち、１ｍｓ）の後に、ＤＬＴは、ＣＡＬＭｓｇサービスを使用してそれに向かうことになっているフレームを読み取る。
３．ＤＬＴが読み取るフレームごとに、ＤＬＴは、ＣＡＬＢｕｆサービスを使用して、フレームを処理し、またＣＡＬ ３０１またはＢｍａｎ ３２６に対してバッファをリリースして戻す。

セルを削除することをもたらすすべてのシナリオでは、Ｌ２ ＤＬＴおよびＵＬＵのスレッドは、それらが終了される前に、必要なクリーンアップを実行することになることが、仮定される。クリーンアップの一部として、Ｌ２ ＤＬＴおよびＵＬＵのスレッドは、ＣＡＬ ３０１からそれら自体の登録を解除すべきである。登録解除プロセスの一部として、ＣＡＬ ３０１は、アプリケーションが獲得している（ＣＡＬＢｕｆサービスを経由して直接に、またはＦＭＡＮ ３３０または３３２によって暗黙のうちに獲得されるかのいずれか）すべてのバッファをリリースすることや、関連するリング・バッファを削除し、またＰＣＤルール（高速パスのレシーバだけについて関連のある）を取り除くことなど、何らかのクリーンアップ作業を実行する必要がある。

ＵＬＵおよびＤＬＴは、ＣＡＬＭｓｇサービスを使用して、ＣＡＬ ３０１からそれら自体の登録を解除することができる。

Ｌ２ ＤＬＴまたはＬ２ ＵＬＵのスレッドが、異常に終了する（例えば、クラッシュする）場合には、ＣＡＬ ３０１は、デバッグ・メカニズムを提供することができ、それによってバッファ・プール統計データやＴｘ／Ｒｘイーサネット・インターフェース統計データなど、様々なＣＡＬおよびＤＰＡＡのリソースは、ＬＥＣのサービスを経由して、収集され、またダンプされる。

上記の説明は、単に本発明の特定の実施形態についての開示を提供するにすぎず、同じものをそれらだけに限定する目的のために意図されてはいない。したがって、本発明は、上記で説明された実施形態だけに限定されるものではない。もっと正確に言えば、当業者なら、本発明の範囲内に含まれる代替的な実施形態を考えることができることが、認識される。

Claims (26)

1. 電気通信ネットワークにおいてマルチ・セル・サポートを提供するための装置であって、
   モデム・ボードと、
   前記モデム・ボードに取り付けられたマルチ・コア・プロセッサと
   を備え、
   前記マルチ・コア・プロセッサは複数のプロセッサ・コアを含み、また少なくとも１つのプロセッサ・コアを使用して、制御プレーン機能を実行し、残りのプロセッサ・コアを使用して、データ・プレーン機能を実行し、前記マルチ・コア・プロセッサは、前記プロセッサ・コアの上で実行されるアプリケーション・ソフトウェアからコア特有の詳細を隠すコア抽象化レイヤを含み、前記マルチ・コア・プロセッサは障害分離に対するスーパーバイザ・ソフトウェア・エンティティを含み、
   前記コア抽象化レイヤは、
   １つまたは複数のハードウェア加速フレーム・マネージャに対してネットワーク構成データと、静的な構文解析分類配信（ＰＣＤ）ルールとをロードし、また１組の構成ファイルに基づいて前記コア抽象化レイヤのフレームワークをセットアップする初期化モジュールと、
   １つまたは複数のデータ・リンク・レイヤのアプリケーションについてのロック・レス・バッファ管理サービスを提供するバッファ・モジュールと、
   別のモデム・ボードへとユーザ・プレーン・データを送信し、または別のモデム・ボードからユーザ・プレーン・データを受信するように、ゼロ・コピーおよびロック・レスのメッセージング・サービスをデータ・リンク・レイヤのアプリケーションに対して提供するメッセージング・モジュールと、
   適切なコアへの入口フレームをルーティングするための、前記フレーム・マネージャによって使用されるべきＰＣＤのルールおよび構成を提供するＰＣＤモジュールと、
   ドライバ・モジュールにおいてトレースをイネーブルにし、またディスエーブルにするためのトレース能力を提供するトレース・モジュールと
   を備える、装置。
2. 前記初期化モジュールと、前記バッファ・モジュールと、前記メッセージング・モジュールと、前記ＰＣＤモジュールと、前記トレース・モジュールとは、ユーザ−空間の中で動作する、請求項１に記載の装置。
3. 前記ドライバ・モジュールは、カーネル−空間の中で動作する、請求項１に記載の装置。
4. 前記ドライバ・モジュールは、
   ユーザ・プレーン・データ配信のために使用されるべき、バッファ・プールとフレーム待ち行列とを含むリソースを管理する構成、
   ファイル・オペレーションを経由してユーザ−空間インターフェースを他のコア抽象化レイヤ・モジュールに対して提供する構成であって、前記ファイル・オペレーションがオープン、リリース、初期化のためのｉ−ｏ−制御、バッファ管理、およびメッセージング・サービスを備える構成、
   カーネルからユーザ−空間へのバッファ・マッピングを実行する構成、
   バッファ・プールと、レシーバおよびトランスミッタとの統計データを提供する構成、および、
   リング・バッファを管理するためのサービスを実装する構成
   のうちの１つ又は複数を備える、請求項３に記載の装置。
5. 前記マルチ・コア・プロセッサは、前記電気通信ネットワークにおいて、各セルが、対応するアップリンク・スケジューラと、対応するダウンリンク・スケジューラとを有する、３つのセルにサービスを行うように構成されている、請求項１に記載の装置。
6. 前記マルチ・コア・プロセッサが８つのプロセッサ・コアを有する、請求項１に記載の装置。
7. 第１のプロセッサ・コアが第１のオペレーティング・システムを実行し、残りのプロセッサ・コアが第２のオペレーティング・システムをそれぞれ実行する、請求項１に記載の装置。
8. 電気通信ネットワークにおいてマルチ・セル・サポートを提供するための装置であって、
   モデム・ボードと、
   前記モデム・ボードに取り付けられたマルチ・コア・プロセッサと
   を備え、
   前記マルチ・コア・プロセッサは単一のオペレーティング・システム・インスタンスによってサービスされる複数のプロセッサ・コアを含み、単一のパーティションは、その中に含まれる前記プロセッサ・コアを用いて定義され、また前記単一のパーティションを使用して、制御プレーン機能およびデータ・プレーン機能を実行し、前記マルチ・コア・プロセッサは、前記単一のパーティションの中の前記プロセッサ・コアの上で実行されるアプリケーション・ソフトウェアからコア特有の詳細を隠すコア抽象化レイヤを含み、前記マルチ・コア・プロセッサは前記電気通信ネットワークにおける少なくとも３つのセルをサービスし、それぞれのセルは対応するアップリンク・スケジューラおよびダウンリンク・スケジューラを有し、
   前記コア抽象化レイヤは、
   １つまたは複数のハードウェア加速フレーム・マネージャに対してネットワーク構成データと、静的な構文解析分類配信（ＰＣＤ）ルールとをロードし、また１組の構成ファイルに基づいて前記コア抽象化レイヤのフレームワークをセットアップする初期化モジュールと、
   １つまたは複数のデータ・リンク・レイヤのアプリケーションについてのロック・レス・バッファ管理サービスを提供するバッファ・モジュールと、
   別のボードへとユーザ・プレーン・データを送信し、または別のボードからユーザ・プレーン・データを受信するように、ゼロ・コピーおよびロック・レスのメッセージング・サービスをデータ・リンク・レイヤのアプリケーションに対して提供するメッセージング・モジュールと、
   適切なコアへの入口フレームをルーティングするための、前記フレーム・マネージャによって使用されるべきＰＣＤのルールおよび構成を提供するＰＣＤモジュールと、
   ドライバ・モジュールにおいてトレースをイネーブルにし、またディスエーブルにするためのトレース能力を提供するトレース・モジュールとを備える、装置。
9. 前記初期化モジュールと、前記バッファ・モジュールと、前記メッセージング・モジュールと、前記ＰＣＤモジュールと、前記トレース・モジュールとは、ユーザ−空間の中で動作する、請求項８に記載の装置。
10. 前記ドライバ・モジュールは、カーネル−空間の中で動作する、請求項８に記載の装置。
11. 前記ドライバ・モジュールは、
    ユーザ・プレーン・データ配信のために使用されるべき、バッファ・プールとフレーム待ち行列とを含むリソースを管理する構成、
    オープン、リリース、初期化のためのｉ−ｏ−制御、バッファ管理、およびメッセージング・サービスなどのファイル・オペレーションを経由してユーザ−空間インターフェースを他のコア抽象化レイヤ・モジュールに対して提供する構成、
    カーネルからユーザ−空間へのバッファ・マッピングを実行する構成、
    バッファ・プールと、レシーバおよびトランスミッタとの統計データを提供する構成、および、
    リング・バッファを管理するためのサービスを実装する構成
    のうちの１つ又は複数を備える、請求項１０に記載の装置。
12. 前記マルチ・コア・プロセッサが８つのプロセッサ・コアを有する、請求項８に記載の装置。
13. 単一のオペレーティング・システム・インスタンスを全ての前記コア上で実行し、前記オペレーティング・システム・インスタンスがＰＲＥＥＭＰＴ＿ＲＴパッチを有するＳＭＰリナックスからなる請求項８に記載の装置。
14. 電気通信ネットワークにおいてマルチ・セル・サポートを提供するための装置であって、
    複数のプロセッサ・コアを含むマルチ・コア・プロセッサを備えるモデム・ボードと、
    アプリケーション・ソフトウェアからコア特有の詳細およびハードウェアを抽象化することにより、および、１つまたは複数のユーザ空間のデータ・リンク・レイヤのアプリケーションに対してロック・レス・ゼロ・コピーのマルチ・コア・バッファ管理サービスを実装するためのハードウェア加速エンジンのバッファ・マネージャを形成するユーザ−空間のフレームワークを提供することにより、前記マルチ・コア・プロセッサ上の１つまたは複数のハードウェア加速エンジンおよびリソースを管理し構成するコア抽象化レイヤのフレームワークとを備え、
    前記コア抽象化レイヤ・フレームワークは、
    １つまたは複数のハードウェア加速フレーム・マネージャ・エンジンに対して１つまたは複数のネットワーク構成データと、静的な構文解析分類配信（ＰＣＤ）ルールとをロードし、１組の構成ファイルに基づいてパケット・ルーティング・フレームワークをセットアップする初期化モジュールと、
    前記ハードウェア加速エンジンの待ち行列マネージャおよびハードウェア加速フレーム・マネージャ・エンジンをプログラムするアプリケーション・ソフトウェアを可能にして静的な、または、動的なＰＣＤルールおよび適切なコアへの入口フレームをルーティングする構成をサポートするＰＣＤモジュールと、
    前記１つまたは複数のハードウェア加速エンジン、および前記１つまたは複数のハードウェア加速エンジンをデバッグ目的で管理するカーネル−空間のコア抽象化レイヤ・デバイス・ドライバに対するトレースをイネーブルにし、またディスエーブルにするためのトレース能力を提供するトレース・モジュールとを備える、装置。
15. ネットワーク・インターフェースから前記プロセッサ・コアの内の１つで実行されるアプリケーション・ソフトウェアへとパケットをルーティングする処理動作は、前記ハードウェア加速フレーム管理エンジンへとオフロードされ、パケット・ルーティングの前記処理動作が、パケット・ヘッダの構文解析、パケット分類ＴＣＰ／ＵＤＰ、制御プレーンまたはユーザ・プレーン、および特有のコアへのパケット配信の内の１つまたは複数を含む請求項１４に記載の装置。
16. ハードウェア加速エンジン・バッファ・マネージャを使用し、マルチコア、ロック・レス、ゼロ・コピーバッファ管理スキームを実装するユーザ空間フレームワークをさらに備え、多重バッファ要求が前記プロセッサ・コアのいずれかの上で実行される前記アプリケーション・ソフトウェアのいずれかから同時に到達する請求項１４に記載の装置。
17. 前記マルチ・コア・プロセッサ上のハードウェア加速エンジン・リソースを管理し構成すると共に前記アプリケーション・ソフトウェアへの前記ハードウェア加速エンジン・リソースにユーザ空間インターフェースを提供するコア抽象化レイヤ・ハードウェア加速エンジン・ドライバを前記コア抽象化レイヤ・フレームワークがさらに備える請求項１４に記載の装置。
18. 前記初期化モジュールが１つまたは複数のハードウェア加速エンジンの内の第１を構成してＩＰアドレス、前記アプリケーション・ソフトウェアおよび前記プロセッサ・コアの内の少なくとも１つに基づいて制御プレーン・トラフィックおよびデータ・プレーン・トラフィックに対する１つまたは複数の静的ＰＣＤルールをセットアップし、前記アプリケーションが初期化時に実行されている請求項１４に記載の装置。
19. 前記マルチ・コア・プロセッサに含まれる前記モデム・ボードが初期化され動作可能となった後に新しいセルが構成される場合、前記ＰＣＤモジュールがさらに、ユーザ・プレーン・トラフィックに対する動的なＰＣＤルールをセットアップする請求項１４に記載の装置。
20. 以前に構成されたセルがリムーブまたはデリートされた場合、前記ＰＣＤモジュールがさらに、前記セルと関連するユーザ・プレーン・トラフィックに対する動的なＰＣＤルールを削除する請求項１４に記載の装置。
21. 前記ハードウェア加速フレーム管理エンジンは、分類を経たＩＰおよびＵＤＰを有するユーザ空間イーサネット・インターフェースに到達するフレームを許可するＰＣＤルールで構成され、目標プロセッサ・コアへとルーティングされる請求項２０に記載の装置。
22. 宛先ＩＰアドレスの全部または一部を特定のコアに対してマッピングするために使用される正確なマッチ配信スキームを許可するＰＣＤルールで前記ハードウェア加速フレーム管理エンジンがプロビジョンされ、マッチしていないフレームが制御プレーン・コアに割り当てられるフレーム・キューに加えられる請求項２０に記載の装置。
23. 前記コア抽象化レイヤ・フレームワークは、カーネル−空間の中で動作する請求項１４に記載の装置。
24. 前記カーネル−空間のコア抽象化レイヤ・デバイス・ドライバ・モジュールは、
    ユーザ・プレーン・データ配信のために使用されるべきバッファ・プールとフレーム待ち行列とを含むハードウェア加速エンジン・リソースを管理する構成、
    １つまたは複数のファイル・オペレーションを経由してユーザ−空間インターフェースを他のコア抽象化レイヤ・デバイス・ドライバ・モジュールに対して提供する構成であって、前記１つまたは複数のファイル・オペレーションがオープン、リリース、初期化のためのｉ−ｏ−制御、バッファ管理、およびメッセージング・サービスを備える構成、
    カーネルからユーザ−空間へのバッファ・マッピングを提供する構成、
    ハードウェア加速エンジン・バッファ・プールと、レシーバおよびトランスミッタとの統計データを提供する構成、および、
    リング・バッファを管理するためのサービスを実装する構成の内の１つまたは複数の構成を有する請求項１４に記載の装置。
25. 前記マルチ・コア・プロセッサが８つのプロセッサ・コアを有する、請求項１４に記載の装置。
26. 前記マルチ・コア・プロセッサは、前記電気通信ネットワークにおいて、各セルが、対応するアップリンク・スケジューラと、対応するダウンリンク・スケジューラとを有する、３つのセルにサービスを行うように構成されている、請求項１４に記載の装置。

Images