マルチコアプロセッサを有するマルチセル構成をサポートする、単一モデムボード上のセル回復メカニズムを提供するコンピュータ実装された方法であって、故障しているセルに起因する1つまたは複数の障害を検出するステップと、セルが故障していることを1つまたは複数のソフトウェアコンポーネントに通知するステップと、前記故障しているセルに関連したリソースを解放するステップと、事後のデータを収集するステップと、新しいセルをホストするための実行環境をセットアップするステップと、新しいセルが、前記モデムボード上で開始され得ることをリモートコントローラボード上の運用、管理、保守OAMエンティティに知らせるステップとを含む方法。セル内の故障しているプロセスをエラー訂正スナップショットについてのデータを収集するように複数のエラーコレクタハンドラを起動すること、複数のコードトレースログを収集するように複数のコードトレースハンドラを起動すること、前記故障しているプロセスによって現在オープンにされている各カーネルドライバモジュールをクローズすること、および前記故障しているプロセスの終了についてランチャプロセスに通知することにより、終了させるステップをさらに含む、請求項1に記載の方法。セルが故障していることを通知される前記ソフトウェアコンポーネントは、前記モデムボード上のOAMエンティティと、前記モデムボード上のコール処理モジュールとのうちの少なくとも一方を含む、請求項1に記載の方法。前記モデムボード上の前記OAMエンティティは、前記故障しているセルによって使用されている孤立した入口データバッファを解放するバッファアプリケーションを呼び出すことにより、リソースを解放する、請求項1に記載の方法。前記ソフトウェアコンポーネントのすべてを停止させるステップと、次いで前記故障しているセルに関連する前記ソフトウェアコンポーネントのすべてを再起動するステップとをさらに含む、請求項1に記載の方法。マルチコアプロセッサを使用したマルチセル構成をサポートする、単一モデムボード上のセル回復を提供するためのシステムであって、モデムボードと、前記モデムボードに取り付けられた複数のプロセッサコアを備えるマルチコアプロセッサとを備え、前記マルチコアプロセッサは、少なくとも以下の機能、すなわち、故障しているセルに起因する1つまたは複数の障害を検出する機能と、セルが故障していることを1つまたは複数のソフトウェアコンポーネントに通知する機能と、前記故障しているセルに関連したリソースを解放する機能と、事後のデータを収集する機能と、新しいセルをホストするための実行環境をセットアップする機能と、新しいセルが、前記モデムボード上で開始され得ることをリモートコントローラボード上の運用、管理、保守OAMエンティティに知らせる機能とを実行するように構成されたセル回復メカニズムを含む、システム。前記セル回復メカニズムは、さらに、セル内で故障しているプロセスをエラー訂正スナップショットについてのデータを収集するように複数のエラーコレクタハンドラを起動すること、複数のコードトレースログを収集するように複数のコードトレースハンドラを起動すること、前記故障しているプロセスによって現在オープンにされている各カーネルドライバモジュールをクローズすること、および前記故障しているプロセスの終了についてランチャプロセスに通知することにより、終了させるように構成されている、請求項6に記載のシステム。セルが故障していることを通知される前記ソフトウェアコンポーネントは、前記モデムボード上のOAMエンティティと、前記モデムボード上のコール処理モジュールとのうちの少なくとも一方を含む、請求項6に記載のシステム。前記セル回復メカニズムは、さらに、前記故障しているセルによって使用されている孤立した入口データバッファを解放するバッファアプリケーションを呼び出すことにより、リソースを解放するように構成されている、請求項6に記載のシステム。前記セル回復メカニズムは、さらに、前記ソフトウェアコンポーネントのすべてを停止させ、また次いで前記故障しているセルに関連する前記ソフトウェアコンポーネントのすべてを再起動するように構成されている、請求項6に記載のシステム。本明細書においては、モデムボード上の他のアクティブセルに影響を及ぼさずに、ソフトウェアの誤動作またはクラッシュの後に、オペレータの介入を通して、または自動的にかのいずれかで、特定のセルを個別にリブートするまたは回復するための効果的なセル回復プロシージャが、説明される。一実施形態においては、マルチコアプロセッサを用いてマルチセル構成をサポートする単一モデムボード上のセル回復メカニズムを提供するコンピュータ実装された方法が、提供される。故障しているセルに起因する1つまたは複数の障害が、検出され、また1つまたは複数のソフトウェアコンポーネントは、セルが故障していることを通知される。さらに、故障しているセルに関連した解放するリソースは、解放され、また事後のデータが、収集される。さらに、新しいセルをホストするための実行環境が、セットアップされ、またリモートコントローラボード上の運用、管理、保守OAMエンティティは、新しいセルが、モデムボード上で開始され得ることを知らされる。別の実施形態においては、マルチコアプロセッサを使用したマルチセル構成をサポートする単一モデムボード上でセル回復を提供するためのシステムが、提供される。システムは、モデムボードと、モデムボードに取り付けられた複数のプロセッサコアを備えるマルチコアプロセッサとを含んでおり、モデムボードは、カーネル空間と、ユーザ空間とを含む。システムは、様々な機能を実行するように構成されているセル回復メカニズムをさらに含んでいる。これらの機能は、例えば、故障しているセルに起因する1つまたは複数の障害を検出する機能と、セルが故障していることを1つまたは複数のソフトウェアコンポーネントに通知する機能と、故障しているセルに関連したリソースを解放する機能と、事後のデータを収集する機能と、新しいセルをホストするための実行環境をセットアップする機能と、新しいセルが、モデムボード上で開始され得ることをリモートコントローラボード上の運用、管理、保守OAMエンティティに知らせる機能とを含むことができる。さらに別の実施形態においては、コンピュータによって実行されたとき、コンピュータに、セル回復プロシージャを実行させる命令を記憶する非一時的なコンピュータ使用可能データキャリア。セル回復プロシージャは、様々な機能を含むことができる。例えば、そのような機能は、故障しているセルに起因する1つまたは複数の障害を検出する機能と、セルが故障していることを1つまたは複数のソフトウェアコンポーネントに通知する機能と、故障しているセルに関連したリソースを解放する機能と、事後のデータを収集する機能と、新しいセルをホストするための実行環境をセットアップする機能と、新しいセルが、モデムボード上で開始され得ることをリモートコントローラボード上の運用、管理、保守OAMエンティティに知らせる機能とを含むことができる。本発明の適用可能性のさらなる範囲は、以下で提供される詳細な説明から明らかになるであろう。しかしながら、本発明の精神および範囲の内部の様々な変更形態および修正形態が、当業者には明らかになるので、詳細な説明と特定の例とは、本発明の好ましい実施形態を示しながら、例示のためだけに与えられていることを理解されたい。本発明は、デバイスの構造、構成、および様々な部分の組合せと、方法のステップとの中に存在しており、これによって、企図される目的は、以降でより十分に説明され、特に特許請求の範囲内で指摘され、また添付の図面において示されるように、達成される。それらの提示が例示の実施形態だけを示す目的のためであり、また特許請求の範囲の主題を限定する目的のためではない図面を次に参照すると、図1は、現在説明しようとしている実施形態を組み込むことができるシステムの図を提供するものである。次に図1を参照すると、例示のプラットフォームアーキテクチャ100が、示されている。このアーキテクチャは、一般にモデムボード上で使用されるが、他のアプリケーションにおいても使用され得ることを理解されたい。この実施形態においては、1つのパーティションは、その中のすべての8つのコアを用いて規定される。しかしながら、マルチコアプロセッサ100は、任意の数のコアを有し得ることを理解されたい。この実施形態を用いて、すべてのコア例えば、8つのコア上で実行される単一の対称型多重処理SMPオペレーティングシステムOSインスタンス102を使用することがしたがって可能である。制御プレーンおよびデータプレーンは、1つのOSインスタンスの下にあるので、データプレーンを伴う問題は、同様に制御プレーンを停止させることにならないことを保証する配慮が、一般に必要とされる。この例においては、マルチコアプロセッサ100は、3つのセル図において、104、106、および108として示されるにサービスを行う。各セルは、アップリンクULスケジューラ図において110、112、および114として示されると、ダウンリンクDLスケジューラ図1において116、118、および120として示されるとを必要とする。無線リンク制御RLC:RadioLinkControlレイヤを使用して、LTEエアインターフェースを通して送信され、また受信されるパケットフレーム上でエラーをセグメント化し、連結させ、また訂正することが、知られている。無線リンク制御および媒体アクセス制御のRLC/MACソフトウェアは、GPRS2.5Gワイヤレススタックにおいて使用される。このソフトウェアは、移動局と基地局制御装置BSC:basestationcontrollerとの間の肯定応答されたデータ転送と、肯定応答されていないデータ転送とを提供する。このようにして、アーキテクチャ100はまた、RLC/MACブロック122も含み、このRLC/MACブロックは、移動局とネットワークとの間で使用されるエアインターフェース上の基本トランスポートユニットである。RLC/MACブロック122を一般に使用して、データとRLC/MAC信号とを搬送する。マルチコアプロセッサ100はまた、運用、管理、保守OAMモジュール124と、コール処理またはCALLPモジュール126とを提供する。OAMは、一般に、電気通信ネットワークにおいて運用コンポーネント、管理コンポーネント、保守コンポーネント、および維持するコンポーネントとともに必要とされるプロセス、アクティビティ、ツール、規格などを説明するために使用される。CALLPモジュール126は、一般的に、コール処理アクティビティの非リアルタイム態様を管理する。さらに、マルチコアプロセッサ100は、コア抽象化レイヤCAL128を含んでおり、このコア抽象化レイヤは、レイヤ2L2アプリケーションソフトウェアからコア特有の詳細を隠す。レイヤ2は、コンピュータネットワーキングの7レイヤオープンシステムインターコネクションOSI:OpenSystemsInterconnectionモデルのうちのデータリンクレイヤDataLinkLayerである。データリンクレイヤは、広域ネットワークにおける隣接するネットワークノードの間で、または同じローカルエリアネットワークセグメント上のノードの間でデータを転送するプロトコルレイヤである。データリンクレイヤは、ネットワークエンティティの間でデータを転送する機能手段および手続き手段を提供し、また物理レイヤ内で起こり得るエラーを検出し、また場合によってはエラーを訂正する手段を提供する可能性がある。データリンクプロトコルの例は、ローカルエリアネットワークマルチノードについてのイーサネットEthernet、ポイントツーポイントプロトコルPPP:Point-to-PointProtocol、HDLC、およびポイントツーポイントデュアルノード接続についてのADCCPである。この場合には、L2は、一般に、LTEエアインターフェースのために必要とされるL2スケジューラ処理のことを意味しており、これは、非常に厳しいリアルタイム要件を有する。モバイル通信デバイスと、ネットワーク交換サブシステムとの間のトラフィックと信号とを処理する役割を担う基地局のリアルタイム性能ニーズを満たすために、PREEMPTRTパッチを有するSMPリナックスなどのオペレーティングシステムが、使用されることもある。もちろん、他のオペレーティングシステムも使用され得ることを理解されたい。そのようなSMP構成において決定論的な動作を達成するために、システムは、コア予約とコア親和性構造とを使用して、非同期多重処理AMP:AsynchronousMultiprocessingに匹敵するシステム動作を達成するようにして実装されることが好ましい。これはまた、例えば、PREEMPTRTを有するSMPリナックス内から最上の性能を得るためにも望ましい。バッファ管理などのロックレスゼロコピーサービスと、メッセージングサービスとの使用は、PREEMPTRTオペレーティングシステムを有するSMPリナックスの使用によって課されることもあるどのようなレイテンシー問題にも対処する助けをすることもできる。図1に示されるようなコア抽象化レイヤ128の主要な機能のうちの1つは、マルチコアプラットフォームの全能力を利用する様々なサービスをL2処理などの高レベルアプリケーションに提供することである。コア抽象化レイヤは、このようにして、いくつかの目標を達成するように設計される。第1に、より高レベルのアプリケーションソフトウェアすなわち、L2ソフトウェアからDPAAおよびマルチコア特有の実装形態を隠しながら、新しいデータパス加速アーキテクチャDPAA:DataPathAccelerationArchitectureに基づいたBEDバックプレーンイーサネットドライバインターフェースをサポートする。DPAAは、ネットワークインターフェースおよびハードウェアアクセラレータを含む、負荷分散やリソースの共用などマルチコアネットワーク処理を最適化するように設計される。第2に、P4080のDPAAハードウェアコンポーネントを利用して、入口方向と出口方向との両方においてユーザプレーンデータについての加速されたデータパスを提供する。第3に、構成変化にすなわち、コード変更を必要とせずに簡単に適応するように、できるだけ多くの柔軟性を提供する。CAL構成の一例は、バッファプールと、入口フレーム待ち行列と、出口フレーム待ち行列とについてのDPAAリソース構成である。リナックスなどのオペレーティングシステムにおけるシステムメモリは、2つの異なる領域、すなわち、カーネル空間とユーザ空間とに分割され得ることが、一般に知られている。カーネル空間は、カーネルすなわち、オペレーティングシステムのコアが、実行しすなわち実行され、またそのサービスを提供する場所である。メモリは、一般に、RAMランダムアクセスメモリrandomaccessmemoryセルから構成され、RAMセルの内容は、非常に高速度でアクセスされすなわち、読み取られ、また書き込まれる可能性があるが、ただ一時的にすなわち、使用される間、またはせいぜい電力供給が続いている間保持される。その目的は、現在使用されているプログラムおよびデータを保持することである。ユーザ空間は、ユーザプロセスすなわち、カーネル以外のあらゆるものが実行されるメモリロケーションのその組である。プロセスは、プログラムの実行するインスタンスである。カーネルの役割のうちの1つは、この空間の内部で個別のユーザプロセスを管理することであり、またそれらが互いに干渉しないようにすることである。カーネル空間は、システムコールの使用を通してのみユーザプロセスによってアクセスされる可能性がある。システムコールは、入出力I/O:input/outputやプロセス生成など、カーネルによって実行されるサービスについてのアクティブプロセスによる、Unixのようなオペレーティングシステム内の要求である。アクティブプロセスは、CPUにおいてその次の順番を待っているプロセスと対照されるように、CPUにおいて現在進行しているプロセスである。I/Oは、CPUに対して、またはCPUから、また周辺デバイスディスクドライブ、キーボード、マウス、プリンタなどに対して、または周辺デバイスから、データを転送する任意のプログラム、オペレーションまたはデバイスである。したがって、カーネル空間は、カーネル、カーネル拡張、およびほとんどのデバイスドライバを実行するためにきちんと予約される。対照的に、ユーザ空間は、すべてのユーザモードアプリケーションが作業するメモリエリアであり、またこのメモリは、必要に応じて、交換されることもある。次に図2を参照すると、これらの目標および他の目標を達成する例示のアーキテクチャ200が、示されている。これに関して、コア抽象化レイヤCAL201は、それだけには限定されないが、フレームマネージャFMan230および232に対してLTEネットワーク構成と任意の静的な構文解析、分類および配信のPCD:Parsing、ClassificationandDistributionルールとをロードし、また1組の構成ファイルに基づいてCALフレームワークをセットアップするコア抽象化レイヤ初期化CALInitモジュール202と、コア抽象化レイヤバッファCALBufモジュール204と、別のボードすなわち、eCCMに対してユーザプレーンデータを送信し、または別のボードからユーザプレーンデータを受信するメッセージングサービスをL2ソフトウェアに対して提供するコア抽象化レイヤメッセージングCALMsgモジュール206と、適切なコアに対して入口フレームをルーティングするために各Fman230、232によって使用されるべきPCDルールおよび構成を提供するコア抽象化レイヤの構文解析、分類および配信のCALPcdFmcモジュール208と、カーネル空間のモジュールである、コア抽象化レイヤのDPAAドライバCALDpaaDriver212においてトレースをイネーブルにし、またディスエーブルにするためのトレース能力を提供するコア抽象化レイヤDPAAトレースCALDpaaTraceモジュール210とを含む様々なモジュールをユーザ空間内に含んでいる。アーキテクチャ200は、PREEMPTRTパッチを有するSMPリナックスなど、適切なオペレーティングシステム214をさらに含んでいる。オペレーティングシステム214は、順に、上述のCALDPaaドライバ212、少なくとも1つのフレームマネージャFManドライバ216、少なくとも1つのバッファマネージャBManドライバ218、少なくとも1つの待ち行列マネージャQManドライバ220など、様々なドライバをサポートする。図2に示されるように、アーキテクチャ200は、P4080CoreNetファブリックP4080CoreNetfabric222を適切に含むことができ、このファブリックは、スケーラブルなオンチップネットワークが、キャッシュ、スタンドアロンキャッシュ、およびメモリサブシステムと複数のパワーアーキテクチャ処理コアを接続するために適した相互接続アーキテクチャである。P4080プロセッサは、DPAAの実装形態を含んでいる。したがって、アーキテクチャ200は、P4080DPAA224をさらに含むこともある。DPAA224は、ネットワークインターフェースとハードウェアアクセラレータとを含めて、負荷分散やリソースの共用化などのマルチコアネットワーク処理を最適化するように設計される。示されるように、DPAA224は、一般に、BMan226、QMan228、第1および第2のFManそれぞれ230および232など、様々なマネージャを含んでいる。ワイヤレス多重アクセス通信システムにおいては、トランスミッタとレシーバとは、マルチレイヤの通信スタックを使用して通信することができることが、知られている。それらのレイヤは、例えば、物理レイヤ、媒体アクセス制御MAC:mediumaccesscontrolレイヤ、無線リンク制御RLCレイヤ、プロトコルレイヤ例えば、パケットデータコンバージェンスプロトコルPDCP:packetdataconvergenceprotocolレイヤ、アプリケーションレイヤなどを含むことができる。RLCレイヤは、PDCPレイヤからサービスデータユニットSDUを受信し、またMACレイヤに対して伝送するためにSDUをRLCプロトコルデータユニットPDU:protocoldataunitsに連結し、またはセグメント化する。それに応じて、CALBufモジュール204は、RLCSDU処理において使用するために、L2アプリケーションについてのロックレスバッファ管理サービスを容易にする。当技術分野において知られているように、非ブロッキングアルゴリズムは、共用されたリソースについて競合するスレッドが、それらの実行が相互排除によって無期限に延長されないことを保証する。非ブロッキングアルゴリズムは、システム規模の進化が保証されている場合に、ロックレスまたはロックフリーである。CALBufモジュール204はまた、バッファプール統計データ例えば、プール不足状態、不足カウント、プール使用可能状態、プール割付エラーカウントなどについての問い合わせもサポートする。CALBufモジュール204は、一般に、CALDpaaドライバ212とインターフェースして、そのようなサービスを実装する。CALBufモジュール204は、さらに、マルチコア環境において適切なシステムオペレーションのために非常に重要であるロックレスバッファ管理スキームを提供し、ここで、非リアルタイムプロセスによってかけられるロックは、そのロックの解放を待つリアルタイムプロセスについてレイテンシー問題を引き起こす可能性がある。CALDpaaドライバ212は、CAL201のカーネル空間コンポーネントであり、またBmanおよびQmanのAPIを使用してバッファ管理サービスとメッセージングサービスとを実装し、また提供する助けを行う。本明細書において使用されるように、用語APIまたはアプリケーションプログラミングインターフェースは、ソフトウェアプログラムによって実装されるインターフェースのことを意味しており、それによりソフトウェアプログラムが他のソフトウェアと相互作用することができる。APIは、ユーザインターフェースが、ユーザとコンピュータとの間の相互作用を容易にするやり方と同様に、異なるソフトウェアプログラムの間の相互作用を容易にする。APIは、それらの語彙と呼び出し規則とを決定するようにアプリケーション、ライブラリ、およびオペレーティングシステムによって実装され、またそれらのサービスにアクセスするために使用される。APIは、ルーチンと、データ構造と、オブジェクトクラスと、APIの消費者と実装者との間で通信するために使用されるプロトコルとについての仕様を含むことができる。CALDpaaドライバ212は、一般に、ユーザプレーンデータ配信のために使用されるべきDPAAリソースバッファプールおよびフレーム待ち行列を管理する役割と、オープン、クローズ、初期化のためのi-o-制御ioctl、バッファ管理、メッセージングサービスなど、様々なファイルオペレーションを経由してユーザ空間インターフェースを他のCALモジュールに対して提供する役割と、カーネルツーユーザ空間K-Uバッファマッピングを実行する役割と、DPAAのバッファプール、レシーバおよびトランスミッタの統計データを提供する役割と、リングバッファを管理するためのサービスを実装する役割とを担う。リングバッファは、一般に、CALのL2ソフトウェア待ち行列を表し、またそれらは、特定のL2ダウンリンクスケジューラスレッドに向かうことになっているフレーム記述子FDを記憶するために使用されることに留意されたい。CALMsgモジュール206は、L2が、リングからバッファ記述子を取り出すためのAPIを提供する。上記で説明されるCALコンポーネントのすべては、一般に、CALDpaaドライバ212を例外として、プラットフォームミドルウェアユーザ空間において実行されるである。CALDpaaドライバ212は、カーネル空間において実行されるカスタムドライバであり、またCALユーザ空間ミドルウェアによって必要とされるサービスを-とりわけ、P4080DPAAハードウェアコンポーネントに依存するこれらのサービスを-実装し、また提供するように設計される。CALBufモジュール204は、高速パスデータ処理のために排他的に使用されるべきバッファ管理サービスを提供する。CALBufモジュール204は、ユーザ空間APIをL2アプリケーションに対して提供する。CALBufモジュール204は、CALDpaaドライバ212と協調して、CALDpaaドライバ212が生成するが、Bman226によって管理されるバッファについてのゼロコピーおよびロックレスのバッファ管理サービスを提供する。上記で述べられるように、ロックレスバッファ管理スキームは、マルチコアプロセッサベースのモデムボードの性能ニーズを満たすために重要であり、このマルチコアプロセッサベースのモデムボードは、すべての8つのコアから成る1つのパーティションを使用し、またPREEMPTRTを有するSMPリナックスを実行する。そのようなスキームなしには、システムは、無制限のレイテンシースパイクの影響を受ける可能性があり、このレイテンシースパイクは、全体システムを破壊してしまう可能性がある。本発明者等は、次に、モデムボード上のセルのうちの1つが故障しており、または故障したことがある状況のことを考える。例示の実施形態に関しては、故障しているセルと、故障したセルとの間の差異は存在しない。いずれの場合においても、最終結果は、そのようなセルによって獲得されるリソースを解放することである。これに関して、セル回復プロシージャが、実装されることもある。セル回復プロシージャについての一般的な要件のうちの1つは、セルの回復が、故障しているセルにホストしている同じモデムボード上にある他のセルの機能、動作、および性能に影響を及ぼすべきではないことである。さらに、セル回復は、モデムボード上の他のアクティブセルに非常に影響を及ぼす可能性のある不安定性またはリソース不足を導入するべきではない。次に、図3を参照すると、例示のセル回復プロシージャが、フローチャート内に示されている。セル回復プロシージャの基本的機能は、以下で説明されており、すなわち、それらは、故障しているまたは故障したセルに起因する1つまたは複数の障害を検出し、また影響を受けたソフトウェアコンポーネントに対して適切なメッセージ単数または複数を送信する機能310と、故障しているセルに関連したリソースを解放するまたはクリーンアップする機能320と、故障しているセルに関連した事後のデータを収集する機能330と、新しいセルにホストすることができるように実行環境をセットアップし、また新しいセルが、モデムボード上で開始され得ることをリモートコントローラボード上のOAM-Cに知らせる機能340とである。例示のセル回復プロシージャは、一般に、独立したソフトウェアコンポーネントではないことを理解されたい。その代わりに、セル回復プロシージャは、モデムボードに関連した多数の他のソフトウェアコンポーネントに組み込まれている1組の統合されたプロシージャから適切に構成される。セル回復プロシージャは、セルリソースを管理するすべてのソフトウェアコンポーネントに対して様々なルールを課す。とりわけ、モデムソフトウェアコンポーネントは、様々な共通設計ルールおよび符号化ルールを忠実に守るべきである。最初に、セル回復プロシージャは、それらの責任の下にある他の任意のソフトウェアコンポーネントおよび/またはハードウェアコンポーネントの故障を予測し、また検出することができるべきである。エラーは、ステータスと統計データとを定期的に取り出すことにより予測されることもある。またセル回復プロシージャは、所定の期間にわたって故障を検出すべきであるソフトウェアウォッチドッグとハードウェアウォッチドッグとが、使用される可能性がある。実行される任意のエンティティの健全性が、監視されるべきである。さらに、セルについてのシステムリソースを割り付け、またはアクティブにする任意のソフトウェアコンポーネントは、これらのリソースについてのクリーンアッププロシージャを提供する必要がある。適切には、アーキテクチャ200はまた、ランチャプロセスも含んでおり、このランチャプロセスは、レイヤ2スケジューラプロセスを含めて、すべてのソフトウェアプロセスを起動するミドルウェアコンポーネントである。進化型ノードBeNodeBは、LTEエアインターフェースをサポートし、また故障している/故障したセルに関連した無線リソース管理アクティビティを実行することに留意されたい。これに関して、LTEeNodeBアプリケーションは、1組の協調するプロセスである。これらのプロセスは、別個の信頼できるプロセスによって開始され、また監視される必要がある。監視プロセスは、ランチャと呼ばれる。ランチャは、スタンドアロンであり、データ駆動型であり、1組の構成ファイルを経由してアプリケーションプロセスを開始し、監視し、また回復するために必要とされるデータを受信している。ランチャは、リナックスinitプロセスLinuxinitprocessによって開始スクリプトを経由して開始され、また、次には、アプリケーションを構成するすべての他のプロセスを開始する。設計によって、ランチャは、一般に、リナックスサービスだけを使用する。ランチャプロセスは、すべてのアプリケーションプロセスの親プロセスである。ランチャは、一般に、定期的に、プロセス終了イベントレイヤ2プロセス終了を含むに関する情報を求めてリッスンしている。セルに関連するレイヤ2プロセスのコードが、故障するすなわち、コードの制御が効かないレイヤ2プロセスの不本意な終了のときに、その終了に先立ってプロセスとの関連で起こるいくつかのアクティビティが依然として存在している。例えば、リナックスは、一般的に、故障しているスレッドとの関連で、LECリナックスエラーコレクタLinuxErrorCollectorおよび他のライブラリによってセットアップされた信号ハンドラおよび終了ハンドラを起動する。いくつかの終了ハンドラは、LECに登録され、また後で、プロセスが情報を収集することを終了したとき、呼び出されることに留意されたい。リナックスは、信号ハンドラを使用して、信号通知を送信する。リナックスは、故障しているプロセスによってオープンにされた各ドライバのクローズ機能をトランスペアレントに呼び出す。とりわけ、リナックスは、高速パスドライバCALDpaaドライバ212を呼び出す。これは、カーネルモードにおいてセルに関連したリソースをクリーンアップする機会である。レイヤ2プロセス終了において構成される場合に、リナックスは、コアダンプを生成する。図4は、プロセス終了フェーズの時系列を示すものである。最初に、オペレーティングシステム102は、エラーコレクタハンドラをアプリケーションコードについてトランスペアレントに起動して、エラー訂正スナップショットについてのデータを収集する410。次いで、オペレーティングシステム214は、コードトレースハンドラをアプリケーションコードについてトランスペアレントに起動して、コードトレースログを収集する420。次に、オペレーティングシステム214は、カーネルドライバモジュールによって故障しているプロセスに割り付けられる任意のリソースクリーンアップを実行するために、故障しているプロセスによって現在オープンにされている各カーネルドライバモジュールのクローズ機能を呼び出す430。最後に、オペレーティングシステム214は、終了プロセスについてランチャに通知する440。任意選択で、ランチャは、終了ステータスを含めて、終了イベントを受信することもできる。次いで、ランチャは、故障したセルについて、システム規模の通知およびリソースクリーンアップのプロシージャをトリガする。マルチコアプロセッサはまた、やはりミドルウェアコンポーネントでもあるプロセスモニタをサポートする。プロセスモニタは、公開/加入サービスを使用して、監視されるプログラムのステータス、ならびに可用性を発行する。プロセスモニタは、例えば、リナックスメッセージ待ち行列を経由してランチャに接続されることもある。プロセスモニタは、ランチャプロセスの子である。本明細書において使用されるように、用語子プロセスは、別のプロセス親プロセスによって生成されるプロセスのことを意味する。各プロセスは、多数の子プロセスを生成することができるが、親を持たないまさしく最初のプロセスを除いて、ただ1つの親プロセスを有することになる。リナックスにおいてinitと呼ばれる最初のプロセスは、ブート時にカーネルによって開始され、また決して終了することはない。ランチャは、プロセス終了イベント例えば、SIGCHLDリナックス信号を受信したとき、メッセージ待ち行列を経由して、そのイベントをプロセスモニタに対して送信する。本明細書において使用されるように、SIGCHLDは、子プロセスが終了したときプロセスに対して送信される信号のことを意味する。公開/加入プロシージャを使用して、プロセスモニタは、レイヤ2プロセスの終了状態をプロセスについてのステータス変更表示として発行する。その初期化において、モデムボード上のローカルOAMモジュール124は、プロセスモニタによって発行されるようなレイヤ2プロセスのステータス変更表示に加入する。加入するために、OAMモジュール124は、すべてのレイヤ2プロセスのアイデンティティを知っているべきであり、これらは、一般的に所定のフォーマットになっている。プロセスモニタが、レイヤ2プロセスのステータス変更表示を発行したとき、終了情報が、OAMモジュール124によって受信される。OAMモジュール124は、レイヤ2プロセス終了についての表示を受信したとき、共用メモリカーネルモジュールを用いて実装されることが好ましいから故障例えば、DSPソフトウェアクラッシュについての理由についての情報を取り出す。OAMモジュール124は、リモートコントローラボード上で実行されるOAM-Cに対してメッセージを送信して、故障したセルに関連したすべての他のeNodeBアクティビティをできるだけすぐに停止させる。ソフトウェアコンポーネントの故障の後に、そのようなセルリソースの所有権が、故障しているコンポーネントに依然として割り当てられている場合に、対応するクリーンアッププロシージャは、アクティブにされて、所有権を放棄し、また対応するセルに関連したリソースを解放する必要がある。この要件は、主として、要求しているアプリケーションプロセスのためにカーネル空間においてセルリソースを割り付けるP4080ドライバに対処している。セル構成中に、ユーザ空間内のL2プロセスは、それ自体をCALMsgモジュール206に登録する。CALMsgモジュール206は、次には、要求しているL2プロセスについてCALDpaaドライバ212を経由してリソースカーネル、ハードウェアを割り付ける。モデムボード上の任意の致命的で回復不能なソフトウェアまたはハードウェアの故障は、サービス可用性に影響を及ぼす。以上に述べられるように、モデムボードは、一般に、複数のセルによって共用される多数のリソースを含んでいる。したがって、例示のセル回復プロシージャの目標は、一般に、実行されるセルに影響を及ぼさずに、関連するソフトウェアをシャットダウンし、またセルリソースをリボークすること、故障しているセルを再びスタートアップし、またサービス可用性を最適化することができるようにすること、および事後の診断の目的のために故障についての十分なデータを収集することを含む。セル回復プロシージャの範囲についてのソフトウェア故障は、セルに関連するソフトウェアコンポーネント全体の損失に対応するので、対応する電気通信コンテキストは、セル回復プロシージャによって回復される可能性がない。セル回復プロシージャは、必ずしも故障しているセルについてのサービスの中断を回避することができるとは限らないが、この中断の持続時間と範囲とを最小限にすることをその主要な目標として有している。制御プレーンのプロセスまたはスレッドを伴う任意のクラッシュは、一般的に、モデムボード上で構成されるすべてのセルに影響を及ぼすことになることに注意することが重要である。それに応じて、それによってオペレータが、セルリブートコマンドを発行する通常の終了プロセスでは、L2のプロセスまたはスレッドは、それを終了させる前に、そのセルリソースのすべてのクリーンアップまたは解放を実行する論理を実装すべきである。セルのために割り付けられるP4080システムリソースは、いくつかのやり方で管理される。例えば、いくつかのリソースは、システム規模の共用されたプールから割り付けられる。そのようなリソースが、割り付けられるすなわち、セルによって所有されるときに、それらは、それらが明示的に解放されるまで、他のコンポーネントによって再使用される可能性がない。共用されたプールからのリソースを所有するソフトウェアの故障の場合には、プラットフォームソフトウェアは、所有者ソフトウェアの代わりにこれらのリソースをクリーンアップする必要がある。そうでなければ、対応するリソースは、永遠に失われるであろう。これらのリソースをクリーンアップするために、プラットフォームは、どのセルがそれらを所有するかを識別する方法を必要とする。その理由のために、共用されたプールからの個別の各リソースは、リソースの所有者を指定する関連するタグを有する。所有者のソフトウェアは、セルリソースが割り付けられるたびごとに、またそれが共用されたプールから解放されるたびごとにアップデートされるべきである。高速パスは、通常のパスに比べてプログラムを通してより短い命令パス長を有するパスを説明するために使用される用語である。高速パスを効果的であるようにするために、それは、最も一般的に行われるタスクを通常のパスよりも効率的に処理する必要があり、後者の通常のパスを一般的でない場合、コーナーの場合、エラー処理、および他の異常を取り扱うように放置しておく。高速パスは、最適化の一形態である。高速パスドライバによって使用される入口バッファプールは、システム規模の共用されたリソースの一例である。それらは、ユーザプレーンパケットを受信するために専用にされる。いくつかの他のリソースが、プライベートプールから割り付けられることに留意されたい。プライベートプールからのリソースは、リソースを保持する所有者を用いてタグ付けされる必要はない。これは、そのようなリソースが割り付けられるときに、所有者が、暗黙のうちに知られているからである。プラットフォームソフトウェアは、セルの状態を、すなわち、セルが使用中であるか、またはリソースがないかを知っている必要があるだけである。セルリソースは、実行環境がセットアップされたとき生成されるが、それらのリソースは、必ずしも割り付けられるとは限らないことに留意されたい。割付けは、論理セルが構成されたとき行われる。高速パスドライバによって使用される出口バッファプールは、セル特有のプライベートリソースの一例である。それらは、ユーザプレーンパケットを送信するために専用にされる。共用されたプールから割り付けられ、また故障しているセルによって所有されるリソースは、できる限り速やかに、セル回復プロシージャによって解放されるべきである。レイヤ2プロセスが、思いがけなく終了したとき、そのリソースのクリーンアップは、次に続いている2つのフェーズ、すなわち、1オペレーティングシステムが、プロセスの終了を検出してすぐ、または2レイヤ2スケジューラプロセスの新しいインスタンスが、セルの開始および/または構成の一部分として引き起こされるときの後のうちの一方の間に達成される可能性がある。特定の問題が存在しない場合に、レイヤ2スケジューラプロセスについてのセルリソースのクリーンアップは、好ましくは対応するレイヤ2スケジューラプロセスが終了した後に行われるべきである。セルリソースは、少なくとも以下の理由のために、すなわち、1残りのセルについての余裕を十分なシステムリソースを用いて実行されるようにすること、2セルの新しいインスタンスが生成される場合に、リソースの不足、およびメモリリークを回避することのために、クリーンアップされる可能性がある。セルソフトウェアリソースは、セルの寿命のいくつかのステージに割り付けられる。いくつかのソフトウェアリソースは、セルが構成されたとき、割り付けられる。いくつかの他のリソースは、セルのアクティビティに応じて、しばしば、割り付けられ、また解放される。1つのそのような例は、通信バッファである。その場合には、着信データパケットに関して、カーネルツーユーザ空間K-Uマッピングされたバッファは、適切なフレームマネージャによって獲得され、また故障しているセルのダウンリンクスケジューラによって解放される必要がある。セルを処理するソフトウェアが、故障したとき、通信バッファのうちのいくつかは、依然として故障しているソフトウェアコンポーネント単数または複数によって所有される。一般に、すべてのセル特有のリソース例えば、バッファ、コンテキスト、データ構造、割り込み、スレッド、未解決のDMAなどは、セル故障により影響を受ける可能性がある。しかしながら、リソースが管理されるやり方は、アプリケーションアーキテクチャに特有であり、またリナックスなど、適用可能なオペレーティングシステムの動作に特有である。例えば、ユーザ空間リソースと、カーネル空間リソースとの間の区別、ならびにリソースのプライベートプールと、リソースの共用されたプールとの間の区別が存在する可能性がある。同様に、レイヤ2スケジューラプロセスなど、セル特有のエンティティからの割付けに比べてCALLPモジュール126やOAMモジュール124などの中央エンティティからの割付けの間の区別も存在する可能性がある。リナックスなどのオペレーティングシステムのメモリ管理サブシステムは、いくつかの仮想メモリアドレス指定空間を、すなわち、各プロセスについての1つのアドレス空間と、カーネルについての1つのアドレス空間とを管理する。プロセスが終了したとき、オペレーティングシステムは、プロセスアドレス空間から割り付けられるすべてのリソースを自動的に解放する。その結果として、プロセスアドレス空間の一部分であるリソースの明確なクリーンアップの必要はない。カーネルアドレス空間からの故障しているセルのために割り付けられるセル特有のリソースは、プラットフォームソフトウェアドライバ、例えば、CALDpaaドライバ212によってクリーンアップされるべきである。プロセスの終了は、カーネルモジュールからのセルリソースを自動的にクリーンアップしないことに留意されたい。本明細書において使用される用語クリーンアップは、カーネル空間内のメモリバッファのことを意味するだけでなく、同様にセルに特有の多数の他のカーネルのリソースおよびアクティビティのことを意味する。そのようなカーネルのリソースおよびアクティビティのいくつかの例は、以下で説明される。例として、管理されたセルが、セルクラッシュの結果として削除される場合、いくつかの割り込みが、ディスエーブルにされる必要がある可能性がある。同様に、管理されたセルが、削除される例えば、セルクラッシュの結果として場合、いくつかのDMA転送が、ディスエーブルにされる必要がある可能性がある。DMAは、ダイレクトメモリアクセスdirectmemoryaccessの省略形を表し、またCPUを経由せずに、メインメモリの内容を修正する、コンピューティングシステムにおけるデバイスまたは他のエンティティの能力のことを意味する。ドライバは、ハウスキーピングアクティビティ、統計アクティビティ、または他の定期的アクティビティについてカーネルスレッドを使用することができる。これらのアクティビティは、管理されたセルが、例えば、セルクラッシュの結果として削除される場合に、ディスエーブルにされる可能性がある。データプレーン内の入口データフローは、最初に、対応するP4080コアに対してディスパッチされ、また次いで、高速パス要件、DPAA要件、およびリナックス要件によって規定される構成に従って、ダウンリンクスケジューラスレッドにマッチするバッファ記述子の右入口リングに対してディスパッチされる。とりわけ、データフローについての高速パスおよびDPAA構成は、少なくとも以下の要件、すなわち、1.セルの論理IPアドレスは、モデムボード上で規定されるべきである、2.セルの論理IPアドレスに関連するフレーム待ち行列は、セルをホストするコアに関連するQManポータルにバインドされるべきである、3.セルに関連するフレーム待ち行列のコンテキストは、ターゲットセルに関連するバッファ記述子の入口リングを指し示すべきであるを満たすべきである。セル回復に関して、セルについての入口データフローのための以前の構成は、キャンセルされるべきである。この構成をキャンセルするために、いくつかのアクションが、考慮されるべきである。例えば、CALLPモジュール126が、呼び出され、またセル故障について知らされたとき、モデムボードからセルの論理IPアドレスを取り除くべきである。さらに、高速パスCALMsgモジュール206は、レイヤ2スケジューラプロセス終了について通知されたとき、現在のデータプレーンコアから逆に制御プレーンコアに対して入口フレーム待ち行列の間のマッピングを変更することができる。図2のCALMsgモジュール206は、登録機能と登録解除機能とを含めて、様々なAPIを含むことに留意されたい。これに関して、いくつかのプロシージャは、一般に、それだけには限定されないが、1CALMsg登録機能各データフロータイプ、すなわち入口と出口とについて1つと、2CALMsg登録解除機能各データフロータイプ、すなわち入口と出口とについて1つと、3ドライバクローズプロシージャすべてのデータフロータイプを対象として含むとを含めて、レイヤ2プロセスのために割り付けられるセルリソースのために提供される。BEDインターフェースについてのCALMsg登録機能は、出口データフロータイプと、入口データフロータイプとの両方についての必要とされるリソースを生成するように、高速パスカーネルモジュールに要求する。CALMsg登録機能はまた、同じレイヤ2スケジューラプロセスの以前のインスタンスから残りのリソースをクリーンアップするように高速パスカーネルモジュールに要求する。レイヤ2スケジューラプロセスは、それが、CALLPモジュール126からセルセットアップ要求を受信したとき、BEDインターフェースのCALMsg登録機能を呼び出す。プライベート出口バッファプールからレイヤ2スケジューラプロセスによって割り付けられる出口バッファは、レイヤ2プロセスの次のインスタンスによるクリーンアップのための可能性のある候補である。これらのリソースは、出口データフロータイプに対応する。これらのリソースのクリーンアップを延期する1つの理由は、そのクラッシュの前にL2アップリンクスケジューラによって既に待ち行列に入れられていたすべてのデータパケットを送信し、また解放する時間を適切なフレームマネージャに対して与えるべき必要性に由来する。バッファマネージャの出口バッファは、プライベートバッファプールの一部分であり、またバッファプールをリセットすることは、比較的簡単なオペレーションである。したがって、バッファプールをリセットすることは、レイヤ2スケジューラプロセスが、セルセットアップメッセージを受信したとき行われる可能性があり、また必ずしもレイヤ2スケジューラプロセスが、生成される瞬間に行われるとは限らない。BEDインターフェースの章によって指定されるようなCALAPIに対応するエントリポイントに加えて、高速パスドライバ、例えば、CALDpaaドライバ212は、クローズエントリポイントを提供する必要がある。アプリケーションによって呼び出されるどのようなドライバも、オープンエントリポイントと、クローズエントリポイントとを提供すべきである。CALライブラリによって見えるようにされる他のエントリポイントとは違って、高速パスモジュールについてのクローズエントリポイントは、レイヤ2スケジューラアプリケーションに対して見えるようにされない。レイヤ2スケジューラアプリケーションは、高速パスドライバについてのクローズ機能を直接に呼び出すことができない。ドライバについてのクローズ機能は、一般に、任意のドライバについての標準的なリナックス機能である。プロセスが終了する場合、リナックスは、終了させるプロセスによってオープンにされたすべてのドライバを見出し、またこれらのドライバのすべてについて、次々にクローズエントリポイントを呼び出す。クローズ機能は、呼び出しているレイヤ2スケジューラプロセスのPIDプロセスIDと、それが呼び出されたコア番号とを決定することができる。クローズ機能は、要求元PIDを対応するセルIDに関連づけることができる。クローズ機能は、バッファ記述子のリングなど、対応するセルIDによって所有されるセルリソースをクリーンアップすることができる。OAMモジュール124は、FFSフラッシュファイルシステムFlashFileSystem内のいくつかのコアダンプファイル内から、どのファイルが、プロセスモニタから受信される終了ステータスに対応するかを決定することができる。このようにして、OAMモジュール124は、事後の分析のためにコアダンプについてのストレージ空間を管理することができる。事後のデータは、一般に、コアダンプと、コードトレースログとを含んでおり、これらのコードトレースログは、セルクラッシュの根本的原因分析のために使用される。OAMモジュール124は、すべての必要とされたリソースクリーンアップが、達成される例えば、CALBufAPIを呼び出して、故障しているセルによって使用される孤立した入口データバッファを解放することを保証しようと試みる。実行環境は、新しいセルをホストすることができるようにセットアップされ、すなわち、新しいセルが、OAM-Cによるセル構成に先立って必要とする可能性があるすべてのソフトウェアリソースとハードウェアリソースとをセットアップすることが必要である。モデムボード上のローカルOAMモジュール124は、したがって、新しいセルが、ボード上で再び構成され得ることをリモートマスタOAM-Cに通知する。モデムボードを再スタートすることは、数分かかる可能性があり、またボードによってホストされるすべてのセルに影響を及ぼす。正常なセル回復は、数秒しかかからず、また一般的に、故障しているセルだけに影響を及ぼす。事後の分析のためにデータを収集することは、一般に、セル回復プロシージャのうちの最も長いステップである。このステップは、一般的に、デジタル信号プロセッサDSP:digitalsignalprocessorが、そのメモリダンプ中に再スタートすることができないので、短縮され得ない。他のセル回復ステップの持続時間は、それらが、TTI伝送時間間隔ティック一般的に1秒よりも短いで測定されるので、必ずしも極めて重要とは限らない。セルに専用のソフトウェアコンポーネントに関しては、セル回復プロシージャを実装するための様々な可能性がある。1つのやり方は、故障しているソフトウェアコンポーネント故障しているセルに関連するだけを提示することであり、またそれらを停止させることなく、関連するリソースをクリーンアップし、また他のコンポーネント故障しているセルに関連するを初期状態にロールバックすることである。広い範囲の故障可能性と、ソフトウェアコンポーネントの間の相互依存性とのためにこの解決法は、複雑であり、何らかのリスクのないものではない。好ましいアプローチは、たとえただ1つだけが故障していることが疑わしいとしても、力ずくbruteforceによりコンポーネントを停止させること、また次いで故障しているセルに関連するすべての参加しているソフトウェアコンポーネントを再起動することである可能性がある。当業者は、様々な上記で説明された方法のステップが、プログラムされたコンピュータによって実行され得ることを簡単に認識するであろう。本明細書においては、いくつかの実施形態はまた、プログラムストレージデバイスを、例えば、デジタルデータストレージ媒体を対象として含むことも意図しており、このプログラムストレージデバイスは、マシン読み取り可能、またはコンピュータ読み取り可能であり、また命令のマシン実行可能プログラム、またはコンピュータ実行可能プログラムを符号化し、前記命令は、前記上記で説明された方法のステップのうちの一部または全部を実行する。プログラムストレージデバイスは、例えば、デジタルメモリ、磁気ディスクや磁気テープなどの磁気ストレージ媒体、ハードドライブ、または光学的読取り可能デジタルデータストレージ媒体とすることができる。実施形態はまた、上記で説明された方法の前記ステップを実行するようにプログラムされるコンピュータを対象として含むようにも意図される。上記説明は、単に本発明の特定の実施形態の開示を提供しているにすぎず、また本発明をそれだけに限定する目的のために意図されてはいない。したがって、本発明は、上記で説明された実施形態だけには限定されない。もっと正確に言えば、当業者は、本発明の範囲内に含まれる代替的な実施形態を考えることができることが、認識される。