"マルチコアプロセッサにおけるコア抽象化レイヤであって、1つまたは複数のフレームマネージャに対してネットワーク構成データと、静的な構文解析分類配信PCDルールとをロードし、また1組の構成ファイルに基づいて前記コア抽象化レイヤのフレームワークをセットアップする初期化モジュールと、1つまたは複数のレイヤ2アプリケーションについてのロックレスバッファ管理サービスを提供するバッファモジュールと、別のボードへとユーザプレーンデータを送信し、または別のボードからユーザプレーンデータを受信するように、ゼロコピーおよびロックレスのメッセージングサービスをレイヤ2ソフトウェアに対して提供するメッセージングモジュールと、適切なコアに対して入口フレームをルーティングするための、前記フレームマネージャによって使用されるべきPCDのルールおよび構成を提供するPCDモジュールと、データパス加速アーキテクチャDPAAドライバモジュールにおいてトレースをイネーブルにし、またディスエーブルにするためのトレース能力を提供するDPAAトレースモジュールとを備えるコア抽象化レイヤ。前記バッファモジュールは、1つまたは複数の以下のサービスを、すなわちバッファを獲得するサービスと、与えられたサイズの与えられた数のバッファを獲得し、また次いで使用可能なバッファのリストをバッファの前記要求された数になるまで戻すサービスと、指定されたバッファをリリースするサービスと、バッファのリストをリリースするサービスと、バッファプール統計データについて問い合わせを行うサービスとをサポートするロックレスアプリケーションプログラミングインターフェースを実装し、また提供する、請求項1に記載のコア抽象化レイヤ。前記初期化モジュールと、前記バッファモジュールと、前記メッセージングモジュールと、前記PCDモジュールと、前記DPAAトレースモジュールとは、ユーザ-空間の中で動作する、請求項1に記載のコア抽象化レイヤ。前記DPAAドライバモジュールは、カーネル-空間の中で動作する、請求項1に記載のコア抽象化レイヤ。前記DPAAドライバモジュールは、1つまたは複数の以下の機能を、すなわちユーザプレーンデータ配信のために使用されるべき、バッファプールとフレーム待ち行列とを含むDPAAリソースを管理する機能と、オープン、リリース、初期化のためのi-o-制御、バッファ管理、およびメッセージングサービスなどのファイルオペレーションを経由してユーザ-空間インターフェースを他のCALモジュールに対して提供する機能と、カーネルからユーザ-空間へのバッファマッピングを実行する機能と、DPAAバッファプールと、レシーバおよびトランスミッタとの統計データを提供する機能と、リングバッファを管理するためのサービスを実装する機能とを提供するように動作する、請求項1に記載のコア抽象化レイヤ。電気通信ネットワークにおいてマルチセルサポートを提供するための装置であって、モデムボードと、前記モデムボードに取り付けられた複数のプロセッサコアを備えるマルチコアプロセッサとを備え、単一のパーティションは、その中に含まれる前記プロセッサコアのすべてを用いて定義され、また前記単一のパーティションを使用して、すべての制御プレーン機能、およびすべてのデータプレーン機能、ならびに前記単一のパーティションの中の前記プロセッサコアの上で実行されるアプリケーションソフトウェアから任意のコア特有の詳細を隠すコア抽象化レイヤを実行し、前記コア抽象化レイヤは、1つまたは複数の以下のモジュールを、すなわち1つまたは複数のフレームマネージャに対してネットワーク構成データと、静的な構文解析分類配信PCDルールとをロードし、また1組の構成ファイルに基づいて前記コア抽象化レイヤのフレームワークをセットアップする初期化モジュールと、1つまたは複数のレイヤ2アプリケーションについてのロックレスバッファ管理サービスを提供するバッファモジュールと、別のボードへとユーザプレーンデータを送信し、または別のボードからユーザプレーンデータを受信するように、ゼロコピーおよびロックレスのメッセージングサービスをレイヤ2ソフトウェアに対して提供するメッセージングモジュールと、適切なコアに対して入口フレームをルーティングするための、前記フレームマネージャによって使用されるべきPCDのルールおよび構成を提供するPCDモジュールと、データパス加速アーキテクチャDPAAドライバモジュールにおいてトレースをイネーブルにし、またディスエーブルにするためのトレース能力を提供するDPAAトレースモジュールとを備える、装置。前記初期化モジュールと、前記バッファモジュールと、前記メッセージングモジュールと、前記PCDモジュールと、前記DPAAトレースモジュールとは、ユーザ-空間の中で動作する、請求項6に記載の装置。前記DPAAドライバモジュールは、カーネル-空間の中で動作する、請求項6に記載の装置。前記DPAAドライバモジュールは、1つまたは複数の以下の機能を、すなわちユーザプレーンデータ配信のために使用されるべき、バッファプールとフレーム待ち行列とを含むDPAAリソースを管理する機能と、オープン、リリース、初期化のためのi-o-制御、バッファ管理、およびメッセージングサービスなどのファイルオペレーションを経由してユーザ-空間インターフェースを他のCALモジュールに対して提供する機能と、カーネルからユーザ-空間へのバッファマッピングを実行する機能と、DPAAバッファプールと、レシーバおよびトランスミッタとの統計データを提供する機能と、リングバッファを管理するためのサービスを実装する機能とを提供するように動作する、請求項8に記載の装置。前記マルチコアプロセッサは、前記電気通信ネットワークにおいて、各セルが、対応するアップリンクスケジューラと、対応するダウンリンクスケジューラとを有する、少なくとも3つのセルにサービスを行うように構成されている、請求項6に記載の装置。処理環境において、ミドルウェアレイヤは、一般的に、すべてのハードウェア特有の実装の詳細をアプリケーションレイヤから隠す。新しいサブシステム、コア抽象化レイヤCAL:coreabstractionlayerは、マルチコアプロセッサベースのモデムボードのミドルウェアレイヤに導入される。この新しいモジュールは、マルチコアプロセッサと、そのデータパス加速アーキテクチャまたはDPAA:DataPathAccelerationArchitectureとについての抽象化を提供する。このモデムボードの展開の場合には、CALは、LTEL2アプリケーションについてのゼロコピーロックフリーバッファ管理スキームなど、様々なサービスと、マルチセル構成についてのコントローラボードへの無線リンク制御RLC:RadioLinkControlサービスデータユニットSDU:ServiceDataUnit送信と、コントローラボードからの無線リンク制御RLCサービスデータユニットSDU受信とのためのバックプレーンイーサネットドライバBED:BackplaneEthernetdriverインターフェースについてのサポートとを提供する。ソフトウェア移植性が、CALの主要な目的である。それはまた、アプリケーション、ミドルウェア、およびプラットフォームレイヤサービスの並列なソフトウェア開発を容易にする低レベルのプラットフォームサービスからアプリケーションレイヤを切り離す。したがって、アプリケーションレイヤソフトウェアに対してほとんど影響を与えずに、または全く影響を与えずに、マルチコアプロセッサについての多かれ少なかれ、コアを用いて、または異なるベンダーさえも用いて、複数のプロセッサに移行することは比較的簡単であろう。本発明の一態様においては、電気通信ネットワークにおいてマルチセルサポートを提供するための装置が、提供される。本装置は、モデムボードと、マルチコアプロセッサとを含む。プロセッサは、一般に、モデムボードに取り付けられた複数のプロセッサコアを含んでおり、そこでは少なくとも1つのプロセッサコアを使用して、すべての制御プレーン機能を実行し、また残りのプロセッサコアを使用して、すべてのデータプレーン機能と、プロセッサコアの上で実行されるアプリケーションソフトウェアからどのようなコア特有の詳細も隠すコア抽象化レイヤとを実行する。コア抽象化レイヤは、様々なモジュールを含んでいる。初期化モジュールは、1つまたは複数のフレームマネージャに対してネットワーク構成データと、静的な構文解析分類配信PCD:parsing,classifyinganddistributingルールとをロードし、また1組の構成ファイルに基づいてコア抽象化レイヤフレームワークをセットアップする。バッファモジュールは、レイヤ2アプリケーションについてのロックレスバッファ管理サービスlock-lessbuffermanagementservicesを提供することができる。メッセージングモジュールは、別のボードへとユーザプレーンデータを送信し、または別のボードからユーザプレーンデータを受信するように、ゼロコピー、およびロックレスのメッセージングサービスをレイヤ2ソフトウェアに対して提供することができる。PCDモジュールは、適切なコアに対して入口フレームingressframesをルーティングするための、フレームマネージャによって使用されるべきPCDのルールおよび構成を提供する。データパス加速アーキテクチャDPAAトレースモジュールは、DPAAドライバモジュールにおいてトレースをイネーブルにし、またディスエーブルにするためのトレース能力を提供する。本発明の別の態様においては、電気通信ネットワークにおいてマルチセルサポートを提供するための装置が提供される。本装置は、モデムボードと、そのモデムボードに取り付けられた複数のプロセッサコアを有するマルチコアプロセッサとを含み、そこでは単一のパーティションが、その中に含まれるプロセッサコアのすべてを用いて定義され、またそこでは単一のパーティションを使用して、すべての制御プレーン機能、およびすべてのデータプレーン機能、ならびに単一パーティションにおいてプロセッサコアの上で実行されるアプリケーションソフトウェアからどのようなコア特有の詳細も隠すコア抽象化レイヤを実行する。コア抽象化レイヤは、様々なモジュールを含んでいる。初期化モジュールは、1つまたは複数のフレームマネージャに対してネットワーク構成データと、静的な構文解析分類配信PCDルールとをロードし、また1組の構成ファイルに基づいてコア抽象化レイヤフレームワークをセットアップする。バッファモジュールは、レイヤ2アプリケーションについてのロックレスバッファ管理サービスを提供することができる。メッセージングモジュールは、別のボードへとユーザプレーンデータを送信し、または別のボードからユーザプレーンデータを受信するように、ゼロコピー、およびロックレスのメッセージングサービスをレイヤ2ソフトウェアに対して提供することができる。PCDモジュールは、適切なコアに対して入口フレームをルーティングするための、フレームマネージャによって使用されるべきPCDのルールおよび構成を提供する。データパス加速アーキテクチャDPAAトレースモジュールは、DPAAドライバモジュールにおいてトレースをイネーブルにし、またディスエーブルにするためのトレース能力を提供する。本発明のさらに別の態様においては、マルチコアプロセッサについてのコア抽象化レイヤが、提供される。コア抽象化レイヤは、様々なモジュールを含んでいる。初期化モジュールは、1つまたは複数のフレームマネージャに対してネットワーク構成データと、静的な構文解析分類配信PCDルールとをロードし、また1組の構成ファイルに基づいてコア抽象化レイヤフレームワークをセットアップする。バッファモジュールは、レイヤ2アプリケーションについてのロックレスバッファ管理サービスを提供することができる。メッセージングモジュールは、別のボードへとユーザプレーンデータを送信し、または別のボードからユーザプレーンデータを受信するように、ゼロコピー、およびロックレスのメッセージングサービスをレイヤ2ソフトウェアに対して提供することができる。PCDモジュールは、適切なコアに対して入口フレームをルーティングするための、フレームマネージャによって使用されるべきPCDのルールおよび構成を提供する。データパス加速アーキテクチャDPAAトレースモジュールは、DPAAドライバモジュールにおいてトレースをイネーブルにし、またディスエーブルにするためのトレース能力を提供する。本発明の適用可能性のさらなる範囲は、以下で提供される詳細な説明から明らかになるであろう。しかしながら、詳細な説明および特定の例は、本発明の好ましい例を示しながら、本発明の趣旨および範囲の内部にある様々な変更形態および修正形態が、当業者には明らかになるので、例証としてのみ与えられることを理解すべきである。本発明は、デバイスの様々な部分の構造、構成、および組合せ、ならびに方法のステップの中に存在し、これによって、企図される目的は、以下でより十分に説明され、特許請求の範囲の中で特に指摘され、また添付の図面の中で示されるように、達成される。それらの提示が例示の実施形態だけを示す目的のためであり、また特許請求の範囲の主題を限定する目的のためではない図面を次に参照すると、図1は、現在説明しようとしている実施形態を組み込むことができるシステムの図を提供するものである。このプラットフォームアーキテクチャは、一般にモデムボードの上で使用されるが、それは、他のアプリケーションにおいても使用され得ることを理解すべきである。この場合には、8つのコア図において、12、14、16、18、20、22、24、および26のように示されるを有するマルチコアプロセッサ10が、提供される。しかしながら、マルチコアプロセッサ10は、任意の数のコアを有することができることを理解すべきである。この例においては、第1のパーティション28は、第1のオペレーティングシステムOS132を実行する制御プレーン30についてのものである。第1のパーティション28はまた、オペレーション、統治、および管理OAM34と、BCS/UPS36とを含む。BCS/UPS36は、OAMエンティティなどのアプリケーションソフトウェアに対してハードウェアについての抽象化を提供するミドルウェアレイヤである。残りの7つのコアのおのおの当たりに1つの、7つのAMPパーティション図において、38、40、42、44、46、48、50のように示されるは、おのおのが、第2のオペレーティングシステムOS254を実行するデータプレーン52についてのものである。レイヤ2L2処理のすべては、一般的に、プロセッサの7つのコアの上で実行される。レイヤ2は、コンピュータネットワーキングの7レイヤのOSIモデルのうちのデータリンクレイヤである。データリンクレイヤは、広域ネットワークにおける隣接したネットワークノードの間で、または同じローカルエリアネットワークセグメントの上のノードの間でデータを転送するプロトコルレイヤである。データリンクレイヤは、ネットワークエンティティの間でデータを転送する機能的手段および手続き的手段を提供し、また物理レイヤにおいて起こる可能性のあるエラーを検出し、場合によってはエラーを訂正する手段を提供することもある。データリンクプロトコルの例は、ローカルエリアネットワークマルチノードのためのイーサネットと、ポイントツーポイントプロトコルPPPと、HDLCと、ポイントツーポイントデュアルノード接続のためのADCCPとである。この場合には、L2は、一般に、LTEエアインターフェースのために必要とされるL2スケジューラ処理のことを意味しており、これは、非常に厳しいリアルタイム要件を有する。レイヤ1L1処理のすべては、一般的に、DSPおよびFPGAの上で実行される。とりわけ、コア抽象化レイヤCAL56は、L2アプリケーションソフトウェアからコア特有の詳細を隠す。例示のアーキテクチャは、すべてのこれらのパーティションが、独立に実行され、また互いに破損し合わないことを保証するすなわち、障害分離を保証する、ハイパーバイザ58などのスーパーバイザソフトウェアエンティティをさらに含むことができる。ハイパーバイザは、仮想化において使用されるソフトウェアプログラムである。ハイパーバイザは、いくつかのオペレーティングシステムが、与えられた1つのハードウェアの上で並んで実行されることを可能にする。従来の仮想コンピューティングプログラムとは違って、ハイパーバイザは、ターゲットハードウェアの上で直接に実行される。これにより、ゲストオペレーティングシステムと、ハイパーバイザとの両方は、ずっとより効率的に実行することができるようになる。可能性があるハイパーバイザのリストは、それだけには限定されないが、以下の複数のタイプを、すなわち、XenCitrixと、KVMカーネルベースの仮想マシンと、VMwareESX/vmkernelと、マイクロソフトMicrosoftHyper-Vと、PowerVMIBMと、論理ドメインLogicalDomains/OracleVMと、ウィンドリバーハイパーバイザWindRiverHypervisorとを含む。この例においては、プロセッサ10は、3つのセル図において60、62、および64として示されるにサービスを行う。各セルは、アップリンクULスケジューラ図において、66、70、および74として示されると、ダウンリンクDLスケジューラ図において68、72、および76として示されるとを必要とする。無線リンク制御RLCレイヤを使用して、LTEエアインターフェースを通して送信され、また受信されるパケットフレームの上で、エラーをセグメント化し、連結させ、また訂正することが、知られている。無線リンク制御および媒体アクセス制御のRLC/MACソフトウェアは、GPRS2.5Gワイヤレススタックの中で使用される。RLC/MACソフトウェアは、移動局と基地局制御装置BSC:basestationcontrollerとの間の肯定応答されたデータ転送と、肯定応答されないデータ転送とを提供する。これに関して、プロセッサ10は、RLC/MACブロック78をさらに含んでおり、このRLC/MACブロックは、モバイルとネットワークとの間で使用されるエアインターフェースの上の基本トランスポートユニットである。RLC/MACブロックを使用して、データとRLC/MAC信号とを搬送する。次に図2を参照すると、代替的なプラットフォームアーキテクチャ100が、示されている。このアーキテクチャは、一般にモデムボードの上で使用されるが、このアーキテクチャが他のアプリケーションにおいても使用され得ることを理解すべきである。この実施形態においては、1つのパーティションは、その中のすべての8つのコアを用いて定義される。しかしながら、マルチコアプロセッサ100は、任意の数のコアを有し得ることを理解すべきである。この実施形態を用いて、それゆえに、すべてのコア例えば、8つのコアの上で実行される単一のSMPOSインスタンス102を使用することが可能である。制御プレーンと、データプレーンとは、今や1つのOSインスタンスの下にあるので、データプレーンに伴う問題が、制御プレーンも同様に駄目にすることにならないことを保証する配慮が必要とされる。この例においては、プロセッサ100は、3つのセル図において104、106、および108として示されるにサービスを行う。各セルは、アップリンクULスケジューラ図において、110、112、および114として示されると、ダウンリンクDLスケジューラ図において116、118、および120として示されるとを必要とする。RLC/MACブロック122もまた含められ、このRLC/MACブロックは、モバイルとネットワークとの間で使用されるエアインターフェースの上の基本トランスポートユニットである。RLC/MACブロックを使用して、データと、RLC/MAC信号とを搬送する。プロセッサ100はまた、OAM124と、BCS/UPS126とを提供する。第1の実施形態におけるように、プロセッサ100は、コア抽象化レイヤCAL128を含んでおり、このコア抽象化レイヤは、L2アプリケーションソフトウェアからコア特有の詳細を隠す。基地局のリアルタイム性能の必要性を満たすために、PREEMPT_RTパッチを有するSMPリナックスSMPLinuxなどのOSが、使用されることもある。もちろん、他のオペレーティングシステムも使用され得ることを理解すべきである。SMP構成は、監視されたAMP構成の決定論的動作を失う傾向があることもある。SMP構成において、決定論的動作を達成するために、本システムは、コア予約とコア親和性構造とを使用して、AMPのようなシステム動作を達成するようにして実装されることが好ましい。これはまた、例えば、PREEMPT_RTOSを有するSMPリナックスから最高の性能を引き出すためにも望ましい。バッファ管理などのロックレスゼロコピーサービスと、メッセージングサービスとの使用は、PREEMPT_RTOSを有するSMPリナックスの使用によって課される任意のレイテンシー問題に対処する助けを行うこともできる。図1および2に示されるようなコア抽象化レイヤ56、128の主要機能のうちの1つは、マルチコアプラットフォームの全部の能力を利用する様々なサービスをL2処理などの高レベルアプリケーションに提供することである。コア抽象化レイヤは、このようにして、いくつかの目標を達成するように設計される。第1に、コア抽象化レイヤは、より高いレベルのアプリケーションソフトウェアすなわち、L2ソフトウェアからDPAAおよびマルチコア特有の実装を隠しながら、BEDバックプレーンイーサネットドライバBackplaneEthernetDriverDPAA-ベースのインターフェースをサポートすべきである。第2に、コア抽象化レイヤは、P4080のDPAAハードウェアコンポーネントを利用して、入口方向と出口方向との両方において、ユーザプレーンデータについての加速されたデータパスを提供すべきである。第3に、コア抽象化レイヤは、できる限り多くの柔軟性を実現して、そのようにして構成変更にすなわち、コード変更を必要とすることなく簡単に適応させるべきである。CAL構成の一例は、バッファプールと、入口フレーム待ち行列と、出口フレーム待ち行列とについてのDPAAリソース構成である。次に図3を参照すると、これらの目標および他の目標を達成する例示のアーキテクチャ300が、示されている。これに関して、コア抽象化レイヤCAL301は、ユーザ-空間の中に、コア抽象化レイヤ初期化CALInitモジュール302と、コア抽象化レイヤバッファCALBufモジュール304と、コア抽象化レイヤメッセージングCALMsgモジュール306と、コア抽象化レイヤ構文解析分類配信CALPcdFmcモジュール308と、コア抽象化レイヤDPAAトレースCALDpaaTraceモジュール310とを含む様々なモジュールを含んでいる。CAL301は、カーネル-空間モジュールを、すなわち、コア抽象化レイヤDPAAドライバCALDpaaDriver312を含むこともできる。アーキテクチャ300は、リナックスPreemptRTなど、適切なオペレーティングシステム314をさらに含んでいる。オペレーティングシステム314は、上記のCALDPaaドライバ312、少なくとも1つのフレームマネージャFManドライバ316、少なくとも1つのバッファマネージャBManドライバ318、少なくとも1つの待ち行列マネージャQManドライバ320など、様々なドライバをサポートする。図3に示されるように、アーキテクチャ300は、P4080CoreNetファブリック322を適切に含むことができ、このP4080CoreNetファブリックは、スケーラブルオンチップネットワークが複数のパワーアーキテクチャ処理コアをキャッシュ、スタンドアロンキャッシュ、およびメモリサブシステムと接続するために適切な相互接続アーキテクチャである。P4080プロセッサは、新しいデータパス加速アーキテクチャDPAAの実装形態を含んでいる。したがって、アーキテクチャ300は、P4080DPAA324をさらに含むことができる。DPAA324は、ネットワークインターフェースと、ハードウェアアクセラレータとを含めて、負荷拡散やリソースの共用などのマルチコアネットワーク処理を最適化するように設計される。示されるように、DPAA324は、一般に、BMan326、QMan328、第1および第2のFman330および332など、様々なマネージャをそれぞれ含んでいる。CALInitモジュール302は、一般的に、LTEネットワーク構成と、任意の静的PCDルールとをフレームマネージャ330および332に対してロードし、また1組の構成ファイルに基づいてCALフレームワークをセットアップする。CALInitモジュール302は、CAL構成例えば、ユーザプレーンDPAリソースをロードしセットアップするようにFManPCDと、CALDpaaドライバ312とを構成するFMCFMan構成ツール図示されず、または任意の数のFManAPI単数または複数図示されずとインターフェースする。本明細書において使用される場合、用語APIまたはアプリケーションプログラミングインターフェースは、ソフトウェアプログラムによって実装されるインターフェースを意味しており、このソフトウェアプログラムは、他のソフトウェアと相互作用することを可能にする。それは、ユーザインターフェースが、ユーザとコンピュータとの間の相互作用を容易にするやり方と同様に、異なるソフトウェアプログラムの間の相互作用を容易にする。APIは、アプリケーションと、ライブラリと、オペレーティングシステムとによって実装されて、それらの用語集と呼び出す慣習とを決定し、またAPIを使用して、それらのサービスにアクセスする。APIは、APIの消費者と、実装者との間で情報をやりとりするために使用されるルーチンと、データ構造と、オブジェクトクラスと、プロトコルとについての仕様を含むことができる。CALInitモジュール302はまた、LECリナックスエラーコレクタLinuxErrorCollectorサービスを経由してデバッグメカニズムを提供し、これによって様々なCALおよびDPAAのリソースの状況および統計データが、事後の調査のためのLECのスナップショットファイルに対して収集され、またダンプされる。ワイヤレス多重アクセス通信システムにおいては、トランスミッタとレシーバとは、マルチレイヤの通信スタックを使用して、情報をやりとりすることができることが、知られている。レイヤは、例えば、物理レイヤ、媒体アクセス制御MACレイヤ、無線リンク制御RLCレイヤ、プロトコルレイヤ例えば、パケットデータコンバージェンスプロトコルPDCP:packetdataconvergenceprotocolレイヤ、アプリケーションレイヤなどを含むことができる。RLCレイヤは、PDCPレイヤからサービスデータユニットSDUを受信し、またMACレイヤに対して送信するためにSDUをRLCプロトコルデータユニットPDUへと連結し、またはセグメント化する。それに応じて、CALBufモジュール304は、RLCSDU処理において使用するためにL2アプリケーションについてのロックレスバッファ管理サービスを提供する。当技術分野において知られているように、非ブロッキングアルゴリズムは、共用されたリソースについて競合するスレッドが、それらの実行が相互排除によって無期限に延期されないことを保証する。システム規模の進歩が保証されている場合に、非ブロッキングアルゴリズムは、ロックレスまたはロックフリーである。CALBufモジュール304はまた、バッファプール統計データ例えば、プール枯渇状態、枯渇カウント、プール使用可能状態、プール割付エラーカウントなどについての問い合わせをサポートする。CALBufモジュール304は、サービスを実装するCALDpaaドライバ312とインターフェースする。CALBufモジュール304は、マルチコア環境における適切なシステムオペレーションのために非常に重要であるロックレスバッファ管理スキームを提供し、ここでは、非リアルタイムプロセスによってとられるロックは、そのロックのリリースを待つリアルタイムプロセスの場合に、レイテンシー問題を引き起こす可能性がある。CALMsgモジュール306は、DPAAを経由して、RLCSDUを受信し入口、またRLCSDUを送信する出口サービスを提供する。CALMsgモジュール306はまた、Tx/Rxイーサネットインターフェース統計データ例えば、受信され、または送信されるFDの数、脱落されるFDの数、悪いFDの様々なタイプなどについての問い合わせをサポートする。CALMsgモジュール306は、サービスを実装するCALDPaaドライバ312とインターフェースする。CALMsgモジュール306は、プロトコルスタックの使用なしに、TCP/UDPIPパケットを送信し、また受信するゼロコピーロックレスメッセージングサービスをLTEL2アプリケーションに対して提供する。これは、アプリケーションソフトウェアが、LTEシステムの適切なシステム動作を破壊してしまう可能性がある制限されないレイテンシースパイクに出合わないことを保証するために必要とされ、このLTEシステムは、非常に厳しいリアルタイム処理要件を有する。CALPcdFmcモジュール308は、適切なコアに対して入口フレームをルーティングするための各FMan330、332によって使用されるべき、構文解析分類配信PDCのルールおよび構成を提供する。CALDPaaTraceモジュール310は、CALDpaaDriver312においてトレースをイネーブルにし、またディスエーブルにするためのトレース能力を提供する。CALDPaaTraceモジュール310は、そのようなサービスを実装するCALDpaaドライバ312とインターフェースする。CALDpaaDriver312は、CAL301のカーネル-空間コンポーネントであり、このドライバは、BmanおよびQmanのAPIを使用して、バッファ管理サービスおよびメッセージングサービスを実装し、また提供する助けを行う。CALDpaaDriver312は、ユーザプレーンデータ配信のために使用されるべきDPAAリソースバッファプールおよびフレーム待ち行列を管理すること、オープン、リリース、初期化のためのi-o-制御ioctl、バッファ管理、メッセージングサービスなど、様々なファイルオペレーションを経由してユーザ-空間インターフェースを他のCALモジュールに対して提供すること、カーネル-ユーザ空間K-Uバッファマッピングを実行すること、DPAAバッファプールと、レシーバおよびトランスミッタとの統計データを提供すること、およびリングバッファを管理するためのサービスを実装することを担っている。リングバッファは、CALのL2ソフトウェア待ち行列を表し、また特定のL2DLTに向かうことになっているFDを記憶するために使用されることに注意すべきである。CALMsgモジュール306は、L2がリングからバッファ記述子を取り出すためのAPIを提供する。上記で説明されるCALコンポーネントのすべては、CALDpaaDriver312を除いて、一般に、プラットフォームミドルウェアユーザ-空間の中で実行されるである。CALDpaaDriver312は、カーネル-空間の中で実行されるカスタムドライバであり、それは、CALユーザ空間ミドルウェアによって必要とされるサービスを-とりわけ、P4080DPAAハードウェアコンポーネントに依存するこれらのサービスを実装し、また提供するように設計される。CALInitモジュール302は、様々な機能を提供することを担っている。起動時におけるマスタコアでは、CALInitモジュール302は、CALフレームワークをセットアップして、高速パス処理をサポートする。このステップは、CALDpaaDriver312を初期化するステップを含むことができ、初期化するステップは、aユーザプレーンデータ例えば、バッファプール、FQまたはフレーム待ち行列framequeuesを処理するために必要とされる様々なDPAAリソースを生成し、またbDPAA例えば、バッファプール構成、FQ、および入口FQとDLTIPアドレスとの間の関連付けなどを保持する内部テーブルを経由してバッファ管理サービスおよびメッセージングサービスをサポートするために必要とされるCALインフラストラクチャを生成することになる。CALInitモジュール302はまた、LTEFMCの静的なPCDルールとネットワーク構成とをロードする。起動時におけるマスタコアおよびユーザプレーンコアここにL2DLTおよびL2アップリンクスケジューラのスレッドが、バインドされるでは、CALInitモジュール302は、LECを用いてCAL301を実行し、登録し、またアタッチする。プロセスが、異常に終了する例えば、LECの致命的なエラーが引き起こされるときに、これは、呼び出すべきルーチンをLECのスナップショットタスクに提供する。このルーチンは、バッファプール統計データとTx/Rxイーサネットインターフェース統計データとを含めて、様々なCALデータとDPAAデータとを収集し、またデバッグの目的のためにそのデータをLECのスナップショットファイルにダンプする。CALBufモジュール304は、高速パスデータ処理のために排他的に使用されるべきバッファ管理サービスを提供する。CALBufモジュール304は、ユーザ-空間APIをL2アプリケーションに対して提供する。CALBufモジュール304は、CALDpaaDriver312と協調して、CALDpaaドライバ312が、生成するが、Bman326によって管理されるバッファについてのゼロコピーおよびロックレスバッファ管理のサービスを提供する。CALBufモジュール304は、数ある中でも以下のサービスを、すなわち1.バッファサイズを仮定して、バッファを獲得すること、2.与えられたサイズの与えられた数のバッファを獲得し、また次いで、使用可能なバッファのリストをバッファの要求された数になるまで戻すこと、3.指定されたバッファをリリースすること、4.バッファのリストをリリースすること、および5.バッファプール統計データについて問い合わせを行うことをサポートするAPIを実装し、また提供する。CALMsgモジュール306は、別のボードすなわち、eCCMに対してユーザプレーンデータを送信し、また別のボードからユーザプレーンデータを受信するメッセージングサービスをL2ソフトウェアに対して提供する。CALMsgモジュール306は、一般に、DPAAを経由してロックレスゼロコピーメッセージングサービスを提供するCALDpaaDriver312とインターフェースする。この機能により、L2アプリケーションソフトウェアは、制限されないレイテンシー遅延を回避するプロトコルスタックの使用なしに、TCP/UDPIPパケットを送信し、また受信することができるようになる。CALMsgモジュール306は、以下の段落において説明されるサービスなど、様々なサービスをサポートするAPIを実装し、また提供する。1つの可能性のあるサービスは、CALMsgサービスへのL2アプリケーションエンティティの登録であり、それによってエンティティは、高速パスを経由して着信パケットを受信することができる。この登録プロセス中に、CALのL2ソフトウェア待ち行列リングバッファが、エンティティに向かうことになっている、受信されたバッファ記述子を保持するように生成される。この登録中にもまた、CALMsgモジュール306は、IPアドレスに対する入口FQと、他の処理例えば、フレームがFQに到達するときに、どのリングバッファに対してバッファ記述子をプッシュすべきかを決定することにおいて後の参照単数または複数のためのリングIDとの間の関連付けを生成し、カーネル-空間からユーザ-空間への関連のあるバッファプールのマッピングを実行し、また静的ルールを経由してまだ行われていない場合アプリケーションエンティティについてのPCDルールを構成する。さらに、登録プロセスの最初に、CAL301は、アプリケーションによって獲得されるすべてのバッファが、スレッドがクラッシュするときに、適切にリリースされることを保証するための防衛戦略を実装する。第2のサービスは、アプリケーションエンティティに向かうことになっているフレームを取り出すことである。戻されたバッファアドレスが、イーサネットヘッダで開始されるペイロードの開始を指し示すことになることが期待される。第3のサービスは、ユーザプレーンデータ例えば、eth0を処理するように構成されたイーサネットインターフェースの上でDPAAを経由してメッセージを外部エンティティに対して送信することである。L2は、必要とされるすべてのヘッダイーサネット、IP、UDPを入力し、またハードウェアは、IPチェックサムとUDPチェックサムとを生成し、また入力するように適切に構成されていることになることが期待される。第4のサービスは、レシーバおよびトランスミッタのポート統計データについて問い合わせを行うことである。第5のサービスは、CALMsgモジュール306からアプリケーションエンティティの登録を解除することである。ひとたびアプリケーションエンティティの登録が解除された後に、アプリケーションエンティティは、もはや高速パスを経由してパケットを受信することができなくなる。登録解除プロセスの一部として、CALは、アプリケーションソフトウェアによって獲得されるすべてのバッファをリリースすることになる。CALMsgモジュール306を使用して、高速パスを経由してフレームを受信する場合には、関連するリングバッファおよびPCDルールもまた、取り除かれるであろう。CALPcdFmcモジュール308は、少なくともネットワークインターフェース構成ファイルと、CAL301が、FMan330、332のPCDコンポーネントを初期化し、構成するために使用することができる構文解析分類配信PCDルールとを提供する。FManのPCDコンポーネントは、適切なコアへの着信フレームの配信を可能にするように構成される必要がある。例示のアーキテクチャを用いて、LTEPCDルールを静的に、または動的に定義するために使用され得る戦略の一例が、以下で説明される。ユーザ-空間の配信に関して、IPヘッダおよびUDPヘッダとともにユーザ-空間イーサネットインターフェースeth0に到着するすべてのフレームは、FManによる粗い分類を通過することになる。これは、適切なPCDルールのプロビジョニングを経由して静的に、または動的にのいずれかで達成され得る。正確なマッチ配信スキームを使用して、宛先IPアドレスの全部または一部を宛先IPアドレスのどの部分が静的に定義され得るかに応じて特定のコアに対してマッピングすることができる。マッチしていない任意のフレームは、デフォルトにより、制御プレーンコアすなわち、core0に割り当てられるFQのキューに加えられることになる。デフォルトの配信に関して、制御プレーンイーサネットインターフェースeth1またはデバッグイーサネットインターフェースeth2に到達するすべてのフレームは、制御プレーンコアすなわち、core0に対して配信されることになる。どのようにして、またいつPCDルールが、Fmanにおいて定義され、また構成されるかは、PCDルールが、プラットフォームの初期化中に、あらかじめ定義され、また構成されるかどうかに依存する。L2ダウンリンクスレッドのIPアドレスと、様々なコアに対するそれらのバインディングが、前もって決定され得ないので、ボードの起動および初期化中に入口ダウンリンクユーザプレーンパスについてのFmanのPCDルールを定義することは、可能ではない。それゆえに、ユーザプレーンデータパスについてのPCDルールは、セルが構成された後のランタイムに、定義される必要がある。ダウンリンクスケジューラDLTIPアドレスと、スレッドがバインドされる相手のコアとは、DLTが、CALMsgモジュール306に登録されるときには、一般に知られている。他方、制御プレーンとデバッグトラフィックとについてのディスパッチルールは、直接的なものであり、どのような変形形態にも依存しない。したがって、制御プレーンおよびデバッグプレーンのトラフィックについてのPCDルールは、静的に定義され、また初期化中に構成されることもある。制御プレーンイーサネットインターフェースについてのPCDルールと、デバッグイーサネットインターフェースについてのPCDルールとは、前もって定義され、またFSLイーサネットドライバが初期化されるときに、構成されることもある。ユーザプレーンイーサネットインターフェースでは、PCDルールは、知られているIPアドレスとバインディングコアとを用いて、DLTが過ぎた後のランタイムに定義され、また構成される必要がある。CALDPaaTraceモジュール310は、CALDpaaドライバ312と、様々なP4080DPAAコンポーネントドライバとについてトレースし、デバッグすることをイネーブルにし、またディスエーブルにする様々なサービスを提供する。これらのサービスは、例えば、1CALDpaaドライバトレースをイネーブルにし、またディスエーブルにすること、2Bmanトレース将来をイネーブルにし、またディスエーブルにすること、3Qmanトレース将来をイネーブルにし、またディスエーブルにすること、および4Fmanトレース将来をイネーブルにし、またディスエーブルにすることを含む。CAL301が、使用され得る様々なシナリオが存在する。例えば、CAL301は、初期化時にすなわち、プラットフォームの起動中にマスタコアをサポートすることができる。すなわち、1.CAL構成データ例えば、DPAAリソース構成をロードすること、およびCALDpaaドライバ312を初期化することにより、CALのフレームワークをセットアップする。2.もしあれば、LTEFMCのネットワークインターフェース構成と静的PCDルールとをロードする。CAL301は、初期化時にユーザ-空間プロセスをサポートすることもできる。その場合には、CAL301が、ロードされ、初期化されるときに、CAL301は、それ自体をLECに登録し、またはアタッチし、プロセスが終了するときに、実行すべき、LECのスナップショットタスクに対してルーチンを提供する。このルーチンは、Bmanにより管理されたバッファプールとTx/Rxイーサネットインターフェースに関連した様々な統計データを収集し、また事後の調査のためにデータをLECのスナップショットファイルにダンプすることになる。CAL301は、パケットの送信すなわち、L2ULUソフトウェア処理をサポートすることもできる。すなわち、1.ULUアップリンクスケジューラは、それ自体をCALMsg306に登録し、そのようにして、それは、DPAAを経由してパケットを送信することができる。2.ULUは、CALBufサービスを使用してバッファを割り付ける。3.ULUは、すべての必要とされるヘッダイーサネット/IP/UDPおよびペイロードとともに送信されるべきデータをバッファに入力する。4.ULUは、CALMsgサービスを使用してDPAAを経由してメッセージを宛先エンティティに対して送信する。CAL301は、パケットの受信すなわち、L2DLTソフトウェア処理をサポートすることもできる。すなわち、1.DLTダウンリンクスケジューラは、それ自体をCALMsg306に登録し、そのようにして、それは、DPAAを経由してパケットを受信することができる。2.あるデルタT時間すなわち、1msの後に、DLTは、CALMsgサービスを使用してそれに向かうことになっているフレームを読み取る。3.DLTが読み取るフレームごとに、DLTは、CALBufサービスを使用して、フレームを処理し、またCAL301またはBman326に対してバッファをリリースして戻す。セルを削除することをもたらすすべてのシナリオでは、L2DLTおよびULUのスレッドは、それらが終了される前に、必要なクリーンアップを実行することになることが、仮定される。クリーンアップの一部として、L2DLTおよびULUのスレッドは、CAL301からそれら自体の登録を解除すべきである。登録解除プロセスの一部として、CAL301は、アプリケーションが獲得しているCALBufサービスを経由して直接に、またはFMAN330または332によって暗黙のうちに獲得されるかのいずれかすべてのバッファをリリースすることや、関連するリングバッファを削除し、またPCDルール高速パスのレシーバだけについて関連のあるを取り除くことなど、何らかのクリーンアップ作業を実行する必要がある。ULUおよびDLTは、CALMsgサービスを使用して、CAL301からそれら自体の登録を解除することができる。L2DLTまたはL2ULUのスレッドが、異常に終了する例えば、クラッシュする場合には、CAL301は、デバッグメカニズムを提供することができ、それによってバッファプール統計データやTx/Rxイーサネットインターフェース統計データなど、様々なCALおよびDPAAのリソースは、LECのサービスを経由して、収集され、またダンプされる。上記の説明は、単に本発明の特定の実施形態についての開示を提供するにすぎず、同じものをそれらだけに限定する目的のために意図されてはいない。したがって、本発明は、上記で説明された実施形態だけに限定されるものではない。もっと正確に言えば、当業者なら、本発明の範囲内に含まれる代替的な実施形態を考えることができることが、認識される。"