JP2014504466A - 電気通信ネットワークにおけるセル回復のための方法およびシステム - Google Patents

Abstract

任意のセル・クラッシュ（すなわち、ソフトウェアのバグまたは誤動作の結果として起こる不本意なアクション）は、マルチ・セル構成をサポートする単一モデム・ボード上の単一のセルに局所化されることを保証する助けとなる方法およびシステム。これに関しては、モデム・ボード上で構成される制御プレーンと残りのセルとは、動作したままになっているべきである。さらに、オペレータは、他の構成されたセルのオペレーションに影響を及ぼさずに、モデム・ボード上のセルに関して訂正のアクションを行う（すなわち、リブートする、再構成する、削除する、または生成する）ことを選択することができるべきである。

Description

本発明の例示の実施形態は、すべてのプロセッサ・コアを含む単一のＳＭＰパーティションを有するマルチ・コア・プロセッサを使用したマルチ・セル構成をサポートする単一のモデム・ボード上のセル回復プロシージャに関する。本発明は、特にワイヤレス電気通信の技術を対象としており、したがって特にそれに関して説明することになるが、本発明は、他の分野およびアプリケーションにおいても有用性を有し得ることが、理解されるであろう。

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

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

１つの改善策として、マルチ・コア・プロセッサをモデム・ボード上のＬＴＥワイヤレス基地局において使用することができる。その場合には、ＰＲＥＥＭＰＴ ＲＴパッチを有するＳＭＰリナックス（ＳＭＰ Ｌｉｎｕｘ）などのオペレーティング・システムが、すべての８つのコアを含むＳＭＰ（対称型多重処理（ｓｙｍｍｅｔｒｉｃ ｍｕｌｔｉｐｒｏｃｅｓｓｉｎｇ））パーティション上で実行される。この構成においては、制御プレーン（非リアル・タイムのスレッド／プロセス）と、データ・プレーン（リアル・タイムのスレッド／プロセス）とは、異なるコア上で実行されなければならないが、同じオペレーティング・システム・インスタンスを共用する。

モデム・ボードは、複数のセルとセクタとをサポートするので、セル回復は、複雑になってしまう可能性がある。以前の実装形態（すなわち、１つのモデム・ボードを使用し各セルをサポートするもの）においては、ソフトウェア・クラッシュに続くセル回復プロシージャは、簡単であった。その場合には、モデム・ボード全体が、リブートされた。次いで、モデム・ボードは、再起動され、ハードウェア・コンポーネントとソフトウェア・コンポーネントとのすべてが、適切に初期化され、モデム・ボード上でセルを再構成するために、マスタＯＡ＆Ｍ−Ｃがコントローラ・ボード上で実行される準備が整った。

新しいアーキテクチャを用いて、セルを回復し、または救済するためにモデム・ボードをリブートすることは、モデム・ボードによってサポートされる制御プレーンと残りのアクティブなセルをもリブートさせることになるので、もはや実行可能な選択肢ではない。高い可用性は、絶対必要なサービス・プロバイダの要件であり、またセルが１つだけ、ソフトウェア・クラッシュの後にもう一度、再起動され、または再構成される必要があるときに、セルのすべてを停止させることは、受け入れられる選択肢ではない。

したがって、任意のセル・クラッシュ（すなわち、ソフトウェアのバグまたは誤動作の結果として起こる不本意なアクション）が、単一のセルだけに局所化されることを保証する助けとなる方法およびシステムが求められている。これに関しては、モデム・ボード上で構成される制御プレーンと残りのセルとは、動作したままになっているべきである。さらに、オペレータは、他の構成されたセルのオペレーションに影響を及ぼさずに、モデム・ボード上のセルに関して訂正のアクションを行う（すなわち、リブートする、再構成する、削除する、または生成する）ことを選択することができるべきである。

本明細書においては、モデム・ボード上の他のアクティブ・セルに影響を及ぼさずに、ソフトウェアの誤動作（またはクラッシュ）の後に、オペレータの介入を通して、または自動的にかのいずれかで、特定のセルを個別にリブートする（または回復する）ための効果的なセル回復プロシージャが、説明される。

一実施形態においては、マルチ・コア・プロセッサを用いてマルチ・セル構成をサポートする単一モデム・ボード上のセル回復メカニズムを提供するコンピュータ実装された方法が、提供される。故障しているセルに起因する１つまたは複数の障害が、検出され、また１つまたは複数のソフトウェア・コンポーネントは、セルが故障していることを通知される。さらに、故障しているセルに関連した解放するリソースは、解放され、また事後のデータが、収集される。さらに、新しいセルをホストするための実行環境が、セットアップされ、またリモート・コントローラ・ボード上の運用、管理、保守（ＯＡ＆Ｍ）エンティティは、新しいセルが、モデム・ボード上で開始され得ることを知らされる。

別の実施形態においては、マルチ・コア・プロセッサを使用したマルチ・セル構成をサポートする単一モデム・ボード上でセル回復を提供するためのシステムが、提供される。システムは、モデム・ボードと、モデム・ボードに取り付けられた複数のプロセッサ・コアを備えるマルチ・コア・プロセッサとを含んでおり、モデム・ボードは、カーネル空間と、ユーザ空間とを含む。システムは、様々な機能を実行するように構成されているセル回復メカニズムをさらに含んでいる。これらの機能は、例えば、故障しているセルに起因する１つまたは複数の障害を検出する機能と、セルが故障していることを１つまたは複数のソフトウェア・コンポーネントに通知する機能と、故障しているセルに関連したリソースを解放する機能と、事後のデータを収集する機能と、新しいセルをホストするための実行環境をセットアップする機能と、新しいセルが、モデム・ボード上で開始され得ることをリモート・コントローラ・ボード上の運用、管理、保守（ＯＡ＆Ｍ）エンティティに知らせる機能とを含むことができる。

さらに別の実施形態においては、コンピュータによって実行されたとき、コンピュータに、セル回復プロシージャを実行させる命令を記憶する非一時的なコンピュータ使用可能データ・キャリア。セル回復プロシージャは、様々な機能を含むことができる。例えば、そのような機能は、故障しているセルに起因する１つまたは複数の障害を検出する機能と、セルが故障していることを１つまたは複数のソフトウェア・コンポーネントに通知する機能と、故障しているセルに関連したリソースを解放する機能と、事後のデータを収集する機能と、新しいセルをホストするための実行環境をセットアップする機能と、新しいセルが、モデム・ボード上で開始され得ることをリモート・コントローラ・ボード上の運用、管理、保守（ＯＡ＆Ｍ）エンティティに知らせる機能とを含むことができる。

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

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

本発明の態様によるプラットフォーム・アーキテクチャの一実施形態を示す図である。 図１に示されるコア抽象化レイヤを実装するための例示のアーキテクチャを示す図である。 本発明の態様による一例のセル回復プロシージャを示す図である。 プロセスを終了させるための例示のプロシージャを示す図である。

それらの提示が例示の実施形態だけを示す目的のためであり、また特許請求の範囲の主題を限定する目的のためではない図面を次に参照すると、図１は、現在説明しようとしている実施形態を組み込むことができるシステムの図を提供するものである。

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

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

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

マルチ・コア・プロセッサ１００はまた、運用、管理、保守（ＯＡ＆Ｍ）モジュール１２４と、コール処理（またはＣＡＬＬＰ）モジュール１２６とを提供する。ＯＡ＆Ｍは、一般に、電気通信ネットワークにおいて運用コンポーネント、管理コンポーネント、保守コンポーネント、および維持するコンポーネントとともに必要とされるプロセス、アクティビティ、ツール、規格などを説明するために使用される。ＣＡＬＬＰモジュール１２６は、一般的に、コール処理アクティビティの非リアル・タイム態様を管理する。

さらに、マルチ・コア・プロセッサ１００は、コア抽象化レイヤ（ＣＡＬ）１２８を含んでおり、このコア抽象化レイヤは、レイヤ２（Ｌ２）アプリケーション・ソフトウェアからコア特有の詳細を隠す。レイヤ２は、コンピュータ・ネットワーキングの７レイヤオープン・システム・インターコネクション（ＯＳＩ：Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）モデルのうちのデータ・リンク・レイヤ（Ｄａｔａ Ｌｉｎｋ Ｌａｙｅｒ）である。データ・リンク・レイヤは、広域ネットワークにおける隣接するネットワーク・ノードの間で、または同じローカル・エリア・ネットワーク・セグメント上のノードの間でデータを転送するプロトコル・レイヤである。データ・リンク・レイヤは、ネットワーク・エンティティの間でデータを転送する機能手段および手続き手段を提供し、また物理レイヤ内で起こり得るエラーを検出し、また場合によってはエラーを訂正する手段を提供する可能性がある。データ・リンク・プロトコルの例は、ローカル・エリア・ネットワーク（マルチ・ノード）についてのイーサネット（Ｅｔｈｅｒｎｅｔ）、ポイント・ツー・ポイント・プロトコル（ＰＰＰ：Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ）、ＨＤＬＣ、およびポイント・ツー・ポイント（デュアル・ノード）接続についてのＡＤＣＣＰである。この場合には、Ｌ２は、一般に、ＬＴＥエア・インターフェースのために必要とされるＬ２スケジューラ処理のことを意味しており、これは、非常に厳しいリアル・タイム要件を有する。

モバイル通信デバイスと、ネットワーク交換サブシステムとの間のトラフィックと信号とを処理する役割を担う基地局のリアル・タイム性能ニーズを満たすために、ＰＲＥＥＭＰＴ ＲＴパッチを有するＳＭＰリナックスなどのオペレーティング・システムが、使用されることもある。もちろん、他のオペレーティング・システムも使用され得ることを理解されたい。そのようなＳＭＰ構成において決定論的な動作を達成するために、システムは、コア予約とコア親和性構造とを使用して、非同期多重処理（ＡＭＰ：Ａｓｙｎｃｈｒｏｎｏｕｓ Ｍｕｌｔｉｐｒｏｃｅｓｓｉｎｇ）に匹敵するシステム動作を達成するようにして実装されることが好ましい。これはまた、例えば、ＰＲＥＥＭＰＴ ＲＴを有するＳＭＰリナックス内から最上の性能を得るためにも望ましい。バッファ管理などのロックレス・ゼロ・コピー・サービスと、メッセージング・サービスとの使用は、ＰＲＥＥＭＰＴ ＲＴオペレーティング・システムを有するＳＭＰリナックスの使用によって課されることもあるどのようなレイテンシー問題にも対処する助けをすることもできる。

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

リナックスなどのオペレーティング・システムにおけるシステム・メモリは、２つの異なる領域、すなわち、カーネル空間とユーザ空間とに分割され得ることが、一般に知られている。カーネル空間は、カーネル（すなわち、オペレーティング・システムのコア）が、実行し（すなわち実行され）、またそのサービスを提供する場所である。

メモリは、一般に、ＲＡＭ（ランダム・アクセス・メモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ））セルから構成され、ＲＡＭセルの内容は、非常に高速度でアクセスされ（すなわち、読み取られ、また書き込まれ）る可能性があるが、ただ一時的に（すなわち、使用される間、またはせいぜい電力供給が続いている間）保持される。その目的は、現在使用されているプログラムおよびデータを保持することである。

ユーザ空間は、ユーザ・プロセス（すなわち、カーネル以外のあらゆるもの）が実行されるメモリ・ロケーションのその組である。プロセスは、プログラムの実行するインスタンスである。カーネルの役割のうちの１つは、この空間の内部で個別のユーザ・プロセスを管理することであり、またそれらが互いに干渉しないようにすることである。

カーネル空間は、システム・コールの使用を通してのみユーザ・プロセスによってアクセスされる可能性がある。システム・コールは、入出力（Ｉ／Ｏ：ｉｎｐｕｔ／ｏｕｔｐｕｔ）やプロセス生成など、カーネルによって実行されるサービスについてのアクティブ・プロセスによる、Ｕｎｉｘのようなオペレーティング・システム内の要求である。アクティブ・プロセスは、ＣＰＵにおいてその次の順番を待っているプロセスと対照されるように、ＣＰＵにおいて現在進行しているプロセスである。Ｉ／Ｏは、ＣＰＵに対して、またはＣＰＵから、また周辺デバイス（ディスク・ドライブ、キーボード、マウス、プリンタなど）に対して、または周辺デバイスから、データを転送する任意のプログラム、オペレーションまたはデバイスである。

したがって、カーネル空間は、カーネル、カーネル拡張、およびほとんどのデバイス・ドライバを実行するためにきちんと予約される。対照的に、ユーザ空間は、すべてのユーザ・モード・アプリケーションが作業するメモリ・エリアであり、またこのメモリは、必要に応じて、交換されることもある。

次に図２を参照すると、これらの目標および他の目標を達成する例示のアーキテクチャ２００が、示されている。これに関して、コア抽象化レイヤ（ＣＡＬ）２０１は、それだけには限定されないが、フレーム・マネージャ（ＦＭａｎ）２３０および２３２に対してＬＴＥネットワーク構成と任意の静的な構文解析、分類および配信の（ＰＣＤ：Ｐａｒｓｉｎｇ、Ｃｌａｓｓｉｆｉｃａｔｉｏｎ ａｎｄ Ｄｉｓｔｒｉｂｕｔｉｏｎ）ルールとをロードし、また１組の構成ファイルに基づいてＣＡＬフレームワークをセットアップするコア抽象化レイヤ初期化（ＣＡＬＩｎｉｔ）モジュール２０２と、コア抽象化レイヤ・バッファ（ＣＡＬＢｕｆ）モジュール２０４と、別のボード（すなわち、ｅＣＣＭ）に対してユーザ・プレーン・データを送信し、または別のボードからユーザ・プレーン・データを受信するメッセージング・サービスをＬ２ソフトウェアに対して提供するコア抽象化レイヤ・メッセージング（ＣＡＬＭｓｇ）モジュール２０６と、適切なコアに対して入口フレームをルーティングするために各Ｆｍａｎ（２３０、２３２）によって使用されるべきＰＣＤルールおよび構成を提供するコア抽象化レイヤの構文解析、分類および配信の（ＣＡＬＰｃｄＦｍｃ）モジュール２０８と、カーネル空間のモジュールである、コア抽象化レイヤのＤＰＡＡドライバ（ＣＡＬＤｐａａＤｒｉｖｅｒ）２１２においてトレースをイネーブルにし、またディスエーブルにするためのトレース能力を提供するコア抽象化レイヤＤＰＡＡトレース（ＣＡＬＤｐａａＴｒａｃｅ）モジュール２１０とを含む様々なモジュールをユーザ空間内に含んでいる。

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

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

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

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

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

ＣＡＬＤｐａａドライバ２１２は、ＣＡＬ ２０１のカーネル空間コンポーネントであり、またＢｍａｎおよびＱｍａｎのＡＰＩを使用してバッファ管理サービスとメッセージング・サービスとを実装し、また提供する助けを行う。本明細書において使用されるように、用語ＡＰＩ（またはアプリケーション・プログラミング・インターフェース）は、ソフトウェア・プログラムによって実装されるインターフェースのことを意味しており、それによりソフトウェア・プログラムが他のソフトウェアと相互作用することができる。ＡＰＩは、ユーザ・インターフェースが、ユーザとコンピュータとの間の相互作用を容易にするやり方と同様に、異なるソフトウェア・プログラムの間の相互作用を容易にする。ＡＰＩは、それらの語彙と呼び出し規則とを決定するようにアプリケーション、ライブラリ、およびオペレーティング・システムによって実装され、またそれらのサービスにアクセスするために使用される。ＡＰＩは、ルーチンと、データ構造と、オブジェクト・クラスと、ＡＰＩの消費者と実装者との間で通信するために使用されるプロトコルとについての仕様を含むことができる。

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

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

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

上記で述べられるように、ロックレス・バッファ管理スキームは、マルチ・コア・プロセッサ・ベースのモデム・ボードの性能ニーズを満たすために重要であり、このマルチ・コア・プロセッサ・ベースのモデム・ボードは、すべての８つのコアから成る１つのパーティションを使用し、またＰＲＥＥＭＰＴ ＲＴを有するＳＭＰリナックスを実行する。そのようなスキームなしには、システムは、無制限のレイテンシー・スパイクの影響を受ける可能性があり、このレイテンシー・スパイクは、全体システムを破壊してしまう可能性がある。

本発明者等は、次に、モデム・ボード上のセルのうちの１つが故障しており、または故障したことがある状況のことを考える。例示の実施形態に関しては、故障しているセルと、故障したセルとの間の差異は存在しない。いずれの場合においても、最終結果は、そのようなセルによって獲得されるリソースを解放することである。これに関して、セル回復プロシージャが、実装されることもある。セル回復プロシージャについての一般的な要件のうちの１つは、セルの回復が、故障しているセルにホストしている同じモデム・ボード上にある他のセルの機能、動作、および性能に影響を及ぼすべきではないことである。さらに、セル回復は、モデム・ボード上の他のアクティブ・セルに非常に影響を及ぼす可能性のある不安定性またはリソース不足を導入するべきではない。

次に、図３を参照すると、例示のセル回復プロシージャが、フロー・チャート内に示されている。セル回復プロシージャの基本的機能は、以下で説明されており、すなわち、それらは、
・故障している（または故障した）セルに起因する１つまたは複数の障害を検出し、また影響を受けたソフトウェア・コンポーネントに対して適切なメッセージ（単数または複数）を送信する機能（３１０）と、
・故障しているセルに関連したリソースを解放する（またはクリーンアップする）機能（３２０）と、
・故障しているセルに関連した事後のデータを収集する機能（３３０）と、
・新しいセルにホストすることができるように実行環境をセットアップし、また新しいセルが、モデム・ボード上で開始され得ることをリモート・コントローラ・ボード上のＯＡ＆Ｍ−Ｃに知らせる機能（３４０）と
である。

例示のセル回復プロシージャは、一般に、独立したソフトウェア・コンポーネントではないことを理解されたい。その代わりに、セル回復プロシージャは、モデム・ボードに関連した多数の他のソフトウェア・コンポーネントに組み込まれている１組の統合されたプロシージャから適切に構成される。セル回復プロシージャは、セル・リソースを管理するすべてのソフトウェア・コンポーネントに対して様々なルールを課す。とりわけ、モデム・ソフトウェア・コンポーネントは、様々な共通設計ルールおよび符号化ルールを忠実に守るべきである。

最初に、セル回復プロシージャは、それらの責任の下にある他の任意のソフトウェア・コンポーネントおよび／またはハードウェア・コンポーネントの故障を予測し、また検出することができるべきである。エラーは、ステータスと統計データとを定期的に取り出すことにより予測されることもある。またセル回復プロシージャは、所定の期間にわたって故障を検出すべきである（ソフトウェア・ウォッチドッグとハードウェア・ウォッチドッグとが、使用される可能性がある）。実行される任意のエンティティの健全性が、監視されるべきである。さらに、セルについてのシステム・リソースを割り付け、またはアクティブにする任意のソフトウェア・コンポーネントは、これらのリソースについてのクリーンアップ・プロシージャを提供する必要がある。

適切には、アーキテクチャ２００はまた、「ランチャ」プロセスも含んでおり、このランチャ・プロセスは、レイヤ２スケジューラ・プロセスを含めて、すべてのソフトウェア・プロセスを起動するミドルウェア・コンポーネントである。進化型ノードＢ（ｅＮｏｄｅＢ）は、ＬＴＥエア・インターフェースをサポートし、また故障している／故障したセルに関連した無線リソース管理アクティビティを実行することに留意されたい。これに関して、ＬＴＥ ｅＮｏｄｅＢアプリケーションは、１組の協調するプロセスである。これらのプロセスは、別個の信頼できるプロセスによって開始され、また監視される必要がある。監視プロセスは、ランチャと呼ばれる。ランチャは、スタンドアロンであり、データ駆動型であり、１組の構成ファイルを経由してアプリケーション・プロセスを開始し、監視し、また回復するために必要とされるデータを受信している。ランチャは、リナックスｉｎｉｔプロセス（Ｌｉｎｕｘ ｉｎｉｔ ｐｒｏｃｅｓｓ）によって（開始スクリプトを経由して）開始され、また、次には、アプリケーションを構成するすべての他のプロセスを開始する。設計によって、ランチャは、一般に、リナックス・サービスだけを使用する。ランチャ・プロセスは、すべてのアプリケーション・プロセスの親プロセスである。ランチャは、一般に、定期的に、プロセス終了イベント（レイヤ２プロセス終了を含む）に関する情報を求めて「リッスン」している。

セルに関連するレイヤ２プロセスのコードが、故障する（すなわち、コードの制御が効かないレイヤ２プロセスの不本意な終了の）ときに、その終了に先立ってプロセスとの関連で起こるいくつかのアクティビティが依然として存在している。例えば、リナックスは、一般的に、故障しているスレッドとの関連で、ＬＥＣ（リナックス・エラー・コレクタ（Ｌｉｎｕｘ Ｅｒｒｏｒ Ｃｏｌｌｅｃｔｏｒ））および他のライブラリによってセットアップされた信号ハンドラおよび終了ハンドラを「起動」する。いくつかの終了ハンドラは、ＬＥＣに登録され、また後で、プロセスが情報を収集することを終了したとき、呼び出されることに留意されたい。リナックスは、信号ハンドラを使用して、信号通知を送信する。リナックスは、故障しているプロセスによってオープンにされた各ドライバの「クローズ」機能をトランスペアレントに呼び出す。とりわけ、リナックスは、高速パス・ドライバＣＡＬＤｐａａドライバ２１２を呼び出す。これは、カーネル・モードにおいてセルに関連したリソースをクリーンアップする機会である。レイヤ２プロセス終了において構成される場合に、リナックスは、コア・ダンプを生成する。

図４は、プロセス終了フェーズの時系列を示すものである。最初に、オペレーティング・システム１０２は、エラー・コレクタ・ハンドラを（アプリケーション・コードについてトランスペアレントに）起動して、エラー訂正スナップショットについてのデータを収集する（４１０）。次いで、オペレーティング・システム２１４は、コード・トレース・ハンドラを（アプリケーション・コードについてトランスペアレントに）起動して、コード・トレース・ログを収集する（４２０）。次に、オペレーティング・システム２１４は、カーネル・ドライバ・モジュールによって故障しているプロセスに割り付けられる任意のリソース・クリーンアップを実行するために、故障しているプロセスによって現在オープンにされている各カーネル・ドライバ・モジュールの「クローズ」機能を呼び出す（４３０）。最後に、オペレーティング・システム２１４は、終了プロセスについて「ランチャ」に通知する（４４０）。任意選択で、ランチャは、終了ステータスを含めて、終了イベントを受信することもできる。次いで、ランチャは、故障したセルについて、システム規模の通知およびリソース・クリーンアップのプロシージャをトリガする。

マルチ・コア・プロセッサはまた、やはりミドルウェア・コンポーネントでもある「プロセス・モニタ」をサポートする。プロセス・モニタは、「公開／加入」サービスを使用して、監視されるプログラムのステータス、ならびに可用性を発行する。プロセス・モニタは、例えば、リナックス・メッセージ待ち行列を経由してランチャに接続されることもある。プロセス・モニタは、ランチャ・プロセスの子である。本明細書において使用されるように、用語「子プロセス」は、別のプロセス（親プロセス）によって生成されるプロセスのことを意味する。各プロセスは、多数の子プロセスを生成することができるが、親を持たないまさしく最初のプロセスを除いて、ただ１つの親プロセスを有することになる。リナックスにおいてｉｎｉｔと呼ばれる最初のプロセスは、ブート時にカーネルによって開始され、また決して終了することはない。

ランチャは、プロセス終了イベント（例えば、ＳＩＧＣＨＬＤリナックス信号）を受信したとき、メッセージ待ち行列を経由して、そのイベントをプロセス・モニタに対して送信する。本明細書において使用されるように、ＳＩＧＣＨＬＤは、子プロセスが終了したときプロセスに対して送信される信号のことを意味する。公開／加入プロシージャを使用して、プロセス・モニタは、レイヤ２プロセスの終了状態をプロセスについての「ステータス変更表示」として発行する。

その初期化において、モデム・ボード上のローカルＯＡ＆Ｍモジュール１２４は、プロセス・モニタによって発行されるようなレイヤ２プロセスの「ステータス変更表示」に加入する。加入するために、ＯＡ＆Ｍモジュール１２４は、すべてのレイヤ２プロセスのアイデンティティを知っているべきであり、これらは、一般的に所定のフォーマットになっている。プロセス・モニタが、レイヤ２プロセスの「ステータス変更表示」を発行したとき、終了情報が、ＯＡ＆Ｍモジュール１２４によって受信される。ＯＡ＆Ｍモジュール１２４は、レイヤ２プロセス終了についての表示を受信したとき、共用メモリ（カーネル・モジュールを用いて実装されることが好ましい）から故障（例えば、ＤＳＰソフトウェア・クラッシュ）についての理由についての情報を取り出す。ＯＡ＆Ｍモジュール１２４は、（リモート・コントローラ・ボード上で実行される）ＯＡ＆Ｍ−Ｃに対してメッセージを送信して、故障したセルに関連したすべての他のｅＮｏｄｅＢアクティビティをできるだけすぐに停止させる。

ソフトウェア・コンポーネントの故障の後に、そのようなセル・リソースの所有権が、故障しているコンポーネントに依然として割り当てられている場合に、対応するクリーンアップ・プロシージャは、アクティブにされて、所有権を放棄し、また対応するセルに関連したリソースを解放する必要がある。この要件は、主として、要求しているアプリケーション・プロセスのためにカーネル空間においてセル・リソースを割り付けるＰ４０８０ドライバに対処している。セル構成中に、ユーザ空間内のＬ２プロセスは、それ自体をＣＡＬＭｓｇモジュール２０６に登録する。ＣＡＬＭｓｇモジュール２０６は、次には、要求しているＬ２プロセスについてＣＡＬＤｐａａドライバ２１２を経由してリソース（カーネル、ハードウェア）を割り付ける。

モデム・ボード上の任意の致命的で回復不能なソフトウェアまたはハードウェアの故障は、サービス可用性に影響を及ぼす。以上に述べられるように、モデム・ボードは、一般に、複数のセルによって共用される多数のリソースを含んでいる。したがって、例示のセル回復プロシージャの目標は、一般に、実行されるセルに影響を及ぼさずに、関連するソフトウェアをシャットダウンし、またセル・リソースをリボークすること、故障しているセルを再びスタートアップし、またサービス可用性を最適化することができるようにすること、および事後の診断の目的のために故障についての十分なデータを収集することを含む。

セル回復プロシージャの範囲についてのソフトウェア故障は、セルに関連するソフトウェア・コンポーネント全体の損失に対応するので、対応する電気通信コンテキストは、セル回復プロシージャによって回復される可能性がない。セル回復プロシージャは、必ずしも故障しているセルについてのサービスの中断を回避することができるとは限らないが、この中断の持続時間と範囲とを最小限にすることをその主要な目標として有している。

制御プレーンのプロセスまたはスレッドを伴う任意のクラッシュは、一般的に、モデム・ボード上で構成されるすべてのセルに影響を及ぼすことになることに注意することが重要である。それに応じて、それによってオペレータが、セル・リブート・コマンドを発行する通常の終了プロセスでは、Ｌ２のプロセスまたはスレッドは、それを終了させる前に、そのセル・リソースのすべての「クリーンアップ」（または解放）を実行する論理を実装すべきである。

セルのために割り付けられるＰ４０８０システム・リソースは、いくつかのやり方で管理される。例えば、いくつかのリソースは、システム規模の共用されたプールから割り付けられる。そのようなリソースが、割り付けられる（すなわち、セルによって所有される）ときに、それらは、それらが明示的に解放されるまで、他のコンポーネントによって再使用される可能性がない。共用されたプールからのリソースを所有するソフトウェアの故障の場合には、プラットフォーム・ソフトウェアは、所有者ソフトウェアの代わりにこれらのリソースをクリーンアップする必要がある。そうでなければ、対応するリソースは、永遠に失われるであろう。これらのリソースをクリーンアップするために、プラットフォームは、どのセルがそれらを所有するかを識別する方法を必要とする。その理由のために、共用されたプールからの個別の各リソースは、リソースの所有者を指定する関連するタグを有する。所有者のソフトウェアは、セル・リソースが割り付けられるたびごとに、またそれが共用されたプールから解放されるたびごとにアップデートされるべきである。

「高速パス」は、「通常のパス」に比べてプログラムを通してより短い命令パス長を有するパスを説明するために使用される用語である。高速パスを効果的であるようにするために、それは、最も一般的に行われるタスクを通常のパスよりも効率的に処理する必要があり、後者の通常のパスを一般的でない場合、コーナーの場合、エラー処理、および他の異常を取り扱うように放置しておく。高速パスは、最適化の一形態である。高速パス・ドライバによって使用される入口バッファ・プールは、システム規模の共用されたリソースの一例である。それらは、ユーザ・プレーン・パケットを受信するために専用にされる。

いくつかの他のリソースが、プライベート・プールから割り付けられることに留意されたい。プライベート・プールからのリソースは、リソースを保持する所有者を用いてタグ付けされる必要はない。これは、そのようなリソースが割り付けられるときに、所有者が、暗黙のうちに知られているからである。プラットフォーム・ソフトウェアは、セルの状態を、すなわち、セルが使用中であるか、またはリソースがないかを知っている必要があるだけである。セル・リソースは、実行環境がセットアップされたとき生成されるが、それらのリソースは、必ずしも割り付けられるとは限らないことに留意されたい。割付けは、論理セルが構成されたとき行われる。高速パス・ドライバによって使用される出口バッファ・プールは、セル特有のプライベート・リソースの一例である。それらは、ユーザ・プレーン・パケットを送信するために専用にされる。共用されたプールから割り付けられ、また故障しているセルによって所有されるリソースは、できる限り速やかに、セル回復プロシージャによって解放されるべきである。

レイヤ２プロセスが、思いがけなく終了したとき、そのリソースのクリーンアップは、次に続いている２つのフェーズ、すなわち、（１）オペレーティング・システムが、プロセスの終了を検出してすぐ、または（２）レイヤ２スケジューラ・プロセスの新しいインスタンスが、セルの開始および／または構成の一部分として引き起こされるときの後のうちの一方の間に達成される可能性がある。特定の問題が存在しない場合に、レイヤ２スケジューラ・プロセスについてのセル・リソースのクリーンアップは、好ましくは対応するレイヤ２スケジューラ・プロセスが終了した後に行われるべきである。

セル・リソースは、少なくとも以下の理由のために、すなわち、（１）残りのセルについての余裕を十分なシステム・リソースを用いて実行されるようにすること、（２）セルの新しいインスタンスが生成される場合に、リソースの不足、およびメモリ・リークを回避することのために、クリーンアップされる可能性がある。

セル・ソフトウェア・リソースは、セルの「寿命」のいくつかのステージに割り付けられる。いくつかのソフトウェア・リソースは、セルが構成されたとき、割り付けられる。いくつかの他のリソースは、セルのアクティビティに応じて、しばしば、割り付けられ、また解放される。１つのそのような例は、通信バッファである。その場合には、着信データ・パケットに関して、カーネル・ツー・ユーザ空間（Ｋ−Ｕ）マッピングされたバッファは、適切なフレーム・マネージャによって獲得され、また故障しているセルのダウンリンク・スケジューラによって解放される必要がある。セルを処理するソフトウェアが、故障したとき、通信バッファのうちのいくつかは、依然として故障しているソフトウェア・コンポーネント（単数または複数）によって所有される。

一般に、すべてのセル特有のリソース（例えば、バッファ、コンテキスト、データ構造、割り込み、スレッド、未解決のＤＭＡなど）は、セル故障により影響を受ける可能性がある。しかしながら、リソースが管理されるやり方は、アプリケーション・アーキテクチャに特有であり、またリナックスなど、適用可能なオペレーティング・システムの動作に特有である。例えば、ユーザ空間リソースと、カーネル空間リソースとの間の区別、ならびにリソースのプライベート・プールと、リソースの共用されたプールとの間の区別が存在する可能性がある。同様に、レイヤ２スケジューラ・プロセスなど、セル特有のエンティティからの割付けに比べてＣＡＬＬＰモジュール１２６やＯＡ＆Ｍモジュール１２４などの中央エンティティからの割付けの間の区別も存在する可能性がある。

リナックスなどのオペレーティング・システムのメモリ管理サブシステムは、いくつかの仮想メモリアドレス指定空間を、すなわち、各プロセスについての１つのアドレス空間と、カーネルについての１つのアドレス空間とを管理する。プロセスが終了したとき、オペレーティング・システムは、プロセス・アドレス空間から割り付けられるすべてのリソースを自動的に解放する。その結果として、プロセス・アドレス空間の一部分であるリソースの明確なクリーンアップの必要はない。カーネル・アドレス空間からの故障しているセルのために割り付けられるセル特有のリソースは、プラットフォーム・ソフトウェア・ドライバ、例えば、ＣＡＬＤｐａａドライバ２１２によってクリーンアップされるべきである。プロセスの終了は、カーネル・モジュールからのセル・リソースを自動的にクリーンアップしないことに留意されたい。

本明細書において使用される用語「クリーンアップ」は、カーネル空間内のメモリ・バッファのことを意味するだけでなく、同様にセルに特有の多数の他のカーネルのリソースおよびアクティビティのことを意味する。そのようなカーネルのリソースおよびアクティビティのいくつかの例は、以下で説明される。

例として、管理されたセルが、セル・クラッシュの結果として削除される場合、いくつかの割り込みが、ディスエーブルにされる必要がある可能性がある。

同様に、管理されたセルが、削除される（例えば、セル・クラッシュの結果として）場合、いくつかのＤＭＡ転送が、ディスエーブルにされる必要がある可能性がある。ＤＭＡは、ダイレクト・メモリ・アクセス（ｄｉｒｅｃｔ ｍｅｍｏｒｙ ａｃｃｅｓｓ）の省略形を表し、またＣＰＵを経由せずに、メイン・メモリの内容を修正する、コンピューティング・システムにおけるデバイスまたは他のエンティティの能力のことを意味する。

ドライバは、ハウスキーピング・アクティビティ、統計アクティビティ、または他の定期的アクティビティについてカーネル・スレッドを使用することができる。これらのアクティビティは、管理されたセルが、例えば、セル・クラッシュの結果として削除される場合に、ディスエーブルにされる可能性がある。

データ・プレーン内の入口データ・フローは、最初に、対応するＰ４０８０コアに対してディスパッチされ、また次いで、高速パス要件、ＤＰＡＡ要件、およびリナックス要件によって規定される構成に従って、ダウンリンク・スケジューラ・スレッドにマッチするバッファ記述子の右入口リングに対してディスパッチされる。とりわけ、データ・フローについての高速パスおよびＤＰＡＡ構成は、少なくとも以下の要件、すなわち、
１．セルの論理ＩＰアドレスは、モデム・ボード上で規定されるべきである、
２．セルの論理ＩＰアドレスに関連するフレーム待ち行列は、セルをホストするコアに関連するＱＭａｎポータルにバインドされるべきである、
３．セルに関連するフレーム待ち行列のコンテキストは、ターゲット・セルに関連するバッファ記述子の入口リングを指し示すべきである
を満たすべきである。

セル回復に関して、セルについての入口データ・フローのための以前の構成は、キャンセルされるべきである。この構成をキャンセルするために、いくつかのアクションが、考慮されるべきである。例えば、ＣＡＬＬＰモジュール１２６が、呼び出され、またセル故障について知らされたとき、モデム・ボードからセルの論理ＩＰアドレスを取り除くべきである。さらに、「高速パス」ＣＡＬＭｓｇモジュール２０６は、レイヤ２スケジューラ・プロセス終了について通知されたとき、現在のデータ・プレーン・コアから逆に制御プレーン・コアに対して入口フレーム待ち行列の間のマッピングを変更することができる。

図２のＣＡＬＭｓｇモジュール２０６は、登録機能と登録解除機能とを含めて、様々なＡＰＩを含むことに留意されたい。これに関して、いくつかのプロシージャは、一般に、それだけには限定されないが、（１）ＣＡＬＭｓｇ登録機能（各データ・フロー・タイプ、すなわち入口と出口とについて１つ）と、（２）ＣＡＬＭｓｇ登録解除機能（各データ・フロー・タイプ、すなわち入口と出口とについて１つ）と、（３）ドライバ「クローズ」プロシージャ（すべてのデータ・フロー・タイプを対象として含む）とを含めて、レイヤ２プロセスのために割り付けられるセル・リソースのために提供される。

ＢＥＤインターフェースについてのＣＡＬＭｓｇ登録機能は、出口データ・フロー・タイプと、入口データ・フロー・タイプとの両方についての必要とされるリソースを生成するように、高速パス・カーネル・モジュールに要求する。ＣＡＬＭｓｇ登録機能はまた、同じレイヤ２スケジューラ・プロセスの以前のインスタンスから残りのリソースをクリーンアップするように高速パス・カーネル・モジュールに要求する。レイヤ２スケジューラ・プロセスは、それが、ＣＡＬＬＰモジュール１２６からセル・セットアップ要求を受信したとき、ＢＥＤインターフェースのＣＡＬＭｓｇ登録機能を呼び出す。

プライベート出口バッファ・プールからレイヤ２スケジューラ・プロセスによって割り付けられる出口バッファは、レイヤ２プロセスの次のインスタンスによるクリーンアップのための可能性のある候補である。これらのリソースは、出口データ・フロー・タイプに対応する。これらのリソースのクリーンアップを延期する１つの理由は、そのクラッシュの前にＬ２アップリンク・スケジューラによって既に待ち行列に入れられていたすべてのデータ・パケットを送信し、また解放する時間を適切なフレーム・マネージャに対して与えるべき必要性に由来する。バッファ・マネージャの出口バッファは、プライベート・バッファ・プールの一部分であり、またバッファ・プールをリセットすることは、比較的簡単なオペレーションである。したがって、バッファ・プールをリセットすることは、レイヤ２スケジューラ・プロセスが、セル・セットアップ・メッセージを受信したとき行われる可能性があり、また必ずしもレイヤ２スケジューラ・プロセスが、生成される瞬間に行われるとは限らない。

ＢＥＤインターフェースの章によって指定されるようなＣＡＬ ＡＰＩに対応するエントリ・ポイントに加えて、高速パス・ドライバ、例えば、ＣＡＬＤｐａａドライバ２１２は、「クローズ」エントリ・ポイントを提供する必要がある。アプリケーションによって呼び出されるどのようなドライバも、「オープン」エントリ・ポイントと、「クローズ」エントリ・ポイントとを提供すべきである。ＣＡＬライブラリによって見えるようにされる他のエントリ・ポイントとは違って、高速パス・モジュールについての「クローズ」エントリ・ポイントは、レイヤ２スケジューラ・アプリケーションに対して見えるようにされない。レイヤ２スケジューラ・アプリケーションは、高速パス・ドライバについての「クローズ」機能を直接に呼び出すことができない。

ドライバについての「クローズ」機能は、一般に、任意のドライバについての標準的なリナックス機能である。プロセスが終了する場合、リナックスは、終了させるプロセスによってオープンにされたすべてのドライバを見出し、またこれらのドライバのすべてについて、次々に「クローズ」エントリ・ポイントを呼び出す。「クローズ」機能は、呼び出しているレイヤ２スケジューラ・プロセスのＰＩＤ（プロセスＩＤ）と、それが呼び出されたコア番号とを決定することができる。「クローズ」機能は、要求元ＰＩＤを対応するセルＩＤに関連づけることができる。「クローズ」機能は、バッファ記述子のリングなど、対応するセルＩＤによって所有されるセル・リソースをクリーンアップすることができる。

ＯＡ＆Ｍモジュール１２４は、ＦＦＳ（フラッシュ・ファイル・システム（Ｆｌａｓｈ Ｆｉｌｅ Ｓｙｓｔｅｍ））内のいくつかのコア・ダンプ・ファイル内から、どのファイルが、プロセス・モニタから受信される終了ステータスに対応するかを決定することができる。このようにして、ＯＡ＆Ｍモジュール１２４は、事後の分析のためにコア・ダンプについてのストレージ空間を管理することができる。事後のデータは、一般に、コア・ダンプと、コード・トレース・ログとを含んでおり、これらのコード・トレース・ログは、セル・クラッシュの根本的原因分析のために使用される。ＯＡ＆Ｍモジュール１２４は、すべての必要とされたリソース・クリーンアップが、達成される（例えば、ＣＡＬＢｕｆ ＡＰＩを呼び出して、故障しているセルによって使用される孤立した入口データ・バッファを解放する）ことを保証しようと試みる。実行環境は、新しいセルをホストすることができるようにセットアップされ、すなわち、新しいセルが、ＯＡ＆Ｍ−Ｃによるセル構成に先立って必要とする可能性があるすべてのソフトウェア・リソースとハードウェア・リソースとをセットアップすることが必要である。モデム・ボード上のローカルＯＡ＆Ｍモジュール１２４は、したがって、新しいセルが、ボード上で再び構成され得ることをリモート・マスタＯＡ＆Ｍ−Ｃに通知する。

モデム・ボードを再スタートすることは、数分かかる可能性があり、またボードによってホストされるすべてのセルに影響を及ぼす。正常なセル回復は、数秒しかかからず、また一般的に、故障しているセルだけに影響を及ぼす。事後の分析のためにデータを収集することは、一般に、セル回復プロシージャのうちの最も長いステップである。このステップは、一般的に、デジタル信号プロセッサ（ＤＳＰ：ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ）が、そのメモリ・ダンプ中に再スタートすることができないので、短縮され得ない。他のセル回復ステップの持続時間は、それらが、ＴＴＩ（伝送時間間隔）ティック（一般的に１秒よりも短い）で測定されるので、必ずしも極めて重要とは限らない。

セルに専用のソフトウェア・コンポーネントに関しては、セル回復プロシージャを実装するための様々な可能性がある。１つのやり方は、故障しているソフトウェア・コンポーネント（故障しているセルに関連する）だけを提示することであり、またそれらを停止させることなく、関連するリソースをクリーンアップし、また他のコンポーネント（故障しているセルに関連する）を初期状態にロールバックすることである。広い範囲の故障可能性と、ソフトウェア・コンポーネントの間の相互依存性とのためにこの解決法は、複雑であり、何らかのリスクのないものではない。好ましいアプローチは、たとえただ１つだけが故障している（ことが疑わしい）としても、「力ずく（ｂｒｕｔｅ ｆｏｒｃｅ）」によりコンポーネントを停止させること、また次いで故障しているセルに関連するすべての参加しているソフトウェア・コンポーネントを再起動することである可能性がある。

当業者は、様々な上記で説明された方法のステップが、プログラムされたコンピュータによって実行され得ることを簡単に認識するであろう。本明細書においては、いくつかの実施形態はまた、プログラム・ストレージ・デバイスを、例えば、デジタル・データ・ストレージ媒体を対象として含むことも意図しており、このプログラム・ストレージ・デバイスは、マシン読み取り可能、またはコンピュータ読み取り可能であり、また命令のマシン実行可能プログラム、またはコンピュータ実行可能プログラムを符号化し、前記命令は、前記上記で説明された方法のステップのうちの一部または全部を実行する。プログラム・ストレージ・デバイスは、例えば、デジタル・メモリ、磁気ディスクや磁気テープなどの磁気ストレージ媒体、ハード・ドライブ、または光学的読取り可能デジタル・データ・ストレージ媒体とすることができる。実施形態はまた、上記で説明された方法の前記ステップを実行するようにプログラムされるコンピュータを対象として含むようにも意図される。

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

Claims (10)

1. マルチ・コア・プロセッサを有するマルチ・セル構成をサポートする、単一モデム・ボード上のセル回復メカニズムを提供するコンピュータ実装された方法であって、
   故障しているセルに起因する１つまたは複数の障害を検出するステップと、
   セルが故障していることを１つまたは複数のソフトウェア・コンポーネントに通知するステップと、
   前記故障しているセルに関連したリソースを解放するステップと、
   事後のデータを収集するステップと、
   新しいセルをホストするための実行環境をセットアップするステップと、
   新しいセルが、前記モデム・ボード上で開始され得ることをリモート・コントローラ・ボード上の運用、管理、保守（ＯＡ＆Ｍ）エンティティに知らせるステップと
   を含む方法。
2. セル内の故障しているプロセスを
   エラー訂正スナップショットについてのデータを収集するように複数のエラー・コレクタ・ハンドラを起動すること、
   複数のコード・トレース・ログを収集するように複数のコード・トレース・ハンドラを起動すること、
   前記故障しているプロセスによって現在オープンにされている各カーネル・ドライバ・モジュールをクローズすること、および
   前記故障しているプロセスの終了についてランチャ・プロセスに通知すること
   により、終了させるステップをさらに含む、請求項１に記載の方法。
3. セルが故障していることを通知される前記ソフトウェア・コンポーネントは、前記モデム・ボード上のＯＡ＆Ｍエンティティと、前記モデム・ボード上のコール処理モジュールとのうちの少なくとも一方を含む、請求項１に記載の方法。
4. 前記モデム・ボード上の前記ＯＡ＆Ｍエンティティは、前記故障しているセルによって使用されている孤立した入口データ・バッファを解放するバッファ・アプリケーションを呼び出すことにより、リソースを解放する、請求項１に記載の方法。
5. 前記ソフトウェア・コンポーネントのすべてを停止させるステップと、次いで前記故障しているセルに関連する前記ソフトウェア・コンポーネントのすべてを再起動するステップとをさらに含む、請求項１に記載の方法。
6. マルチ・コア・プロセッサを使用したマルチ・セル構成をサポートする、単一モデム・ボード上のセル回復を提供するためのシステムであって、
   モデム・ボードと、
   前記モデム・ボードに取り付けられた複数のプロセッサ・コアを備えるマルチ・コア・プロセッサと
   を備え、前記マルチ・コア・プロセッサは、少なくとも以下の機能、すなわち、
   故障しているセルに起因する１つまたは複数の障害を検出する機能と、
   セルが故障していることを１つまたは複数のソフトウェア・コンポーネントに通知する機能と、
   前記故障しているセルに関連したリソースを解放する機能と、
   事後のデータを収集する機能と、
   新しいセルをホストするための実行環境をセットアップする機能と、
   新しいセルが、前記モデム・ボード上で開始され得ることをリモート・コントローラ・ボード上の運用、管理、保守（ＯＡ＆Ｍ）エンティティに知らせる機能と
   を実行するように構成されたセル回復メカニズムを含む、システム。
7. 前記セル回復メカニズムは、さらに、セル内で故障しているプロセスを
   エラー訂正スナップショットについてのデータを収集するように複数のエラー・コレクタ・ハンドラを起動すること、
   複数のコード・トレース・ログを収集するように複数のコード・トレース・ハンドラを起動すること、
   前記故障しているプロセスによって現在オープンにされている各カーネル・ドライバ・モジュールをクローズすること、および
   前記故障しているプロセスの終了についてランチャ・プロセスに通知すること
   により、終了させるように構成されている、請求項６に記載のシステム。
8. セルが故障していることを通知される前記ソフトウェア・コンポーネントは、前記モデム・ボード上のＯＡ＆Ｍエンティティと、前記モデム・ボード上のコール処理モジュールとのうちの少なくとも一方を含む、請求項６に記載のシステム。
9. 前記セル回復メカニズムは、さらに、前記故障しているセルによって使用されている孤立した入口データ・バッファを解放するバッファ・アプリケーションを呼び出すことにより、リソースを解放するように構成されている、請求項６に記載のシステム。
10. 前記セル回復メカニズムは、さらに、前記ソフトウェア・コンポーネントのすべてを停止させ、また次いで前記故障しているセルに関連する前記ソフトウェア・コンポーネントのすべてを再起動するように構成されている、請求項６に記載のシステム。

Images