(57)【特許請求の範囲】
【請求項１】
モデム・ボードにおいてマルチコア・プロセッサを用いてワイヤレス・ネットワークにおけるデータ・パケットを処理する、コンピュータ実装方法であって、
ポーリング・モードでキュー・マネージャを実行している間、入力データ・パケットのバッファを取得し、フレーム・キューに前記データ・パケットをエンキューするステップであって、前記フレーム・キューは、前記キュー・マネージャによって扱われるべきフレーム記述子のリンクされたリストを含む、ステップと、
キューに入れられたフレーム記述子について、前記キュー・マネージャを定期的にポーリングするためにカーネル・スレッドを使用するステップと、
前記ハードウェア・コンポーネントからＮ個のフレーム記述子をデキューするステップであって、ここでＮは、調整可能なパラメータである、ステップと、
カーネル空間でデキューされた各フレーム記述子に関連するコールバック機能を実行するステップであって、前記コールバック機能は、前記フレーム記述子内のデータ・パケットのバッファ・ポインタを処理のためにバッファ記述子のカーネルからユーザへのマップされたリングにエンキューする、ステップと、
コンテキスト・スイッチなしでメッセージング・モジュールに前記データ・パケットを送るステップと
を含み、前記マルチコア・プロセッサは、データ・プレーン機能を実行するように構成された１つまたは複数のデータ・プレーン・コアと、コントロール・プレーン機能を実行するように構成された１つまたは複数のコントロール・プレーン・コアとを含み、前記方法は、前記データ・プレーン・コアで受信された重要でない割込みを無効にし、
さらに、コントロール・プレーン・コアに前記重要でない割込みをルーティングするステップを含む方法。
【請求項２】
前記キュー・マネージャは、ハードウェア・コンポーネントを含み、ソフトウェア初期化の間にポーリング・モードで実行するように構成されている請求項１に記載の方法。
【請求項３】
バッファ・マネージャは、前記入力データ・パケットの前記バッファを提供する請求項１に記載の方法。
【請求項４】
前記マルチコア・プロセッサは、すべての非リアル・タイムのスレッドおよびプロセスが、すべてのコントロール・プレーン活動専用のプロセッサ・コアに結合され、すべてのデータ・プレーン活動専用のプロセッサ・コアは、データ経路の実装またはレイヤ２処理に直接的に必要ないスレッドをホストまたは実行しないように構成されている請求項１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の例示的な実施形態は、一般に、ワイヤレス通信で使用されるモデム・ボードに関する。詳細には、様々な実施形態は、マルチコア・プロセッサを使用する単一のモデム・ボードにおいてマルチセルをサポートするためにＰＲＥＥＭＰＴ  ＲＴを用いるＳＭＰ  Ｌｉｎｕｘなど、オペレーティング・システムのリアル・タイム性能を拡張するための技術に関する。本発明は、詳細には、ワイヤレス通信の技術分野に関し、したがって、それを特に参照して記述するが、本発明は、他の分野および用途でも有用であることが理解されるであろう。
【背景技術】
【０００２】
背景として、ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）は、将来的な通信ネットワーク需要に対処するためにＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｓｙｓｔｅｍ）携帯電話規格を改善することを目的とする、急速に展開している３ＧＰＰプロジェクトである。ＬＴＥにより、ワイヤレス・ネットワークの効率および帯域幅が改善され、コストが削減され、サービス経験が向上される。具体的には、ＬＴＥは、新しいスペクトル機会（ｓｐｅｃｔｒｕｍ  ｏｐｐｏｒｔｕｎｉｔｙ）を利用し、他のオープン規格とのより優れた統合を実現する。ＬＴＥは、一般に、ＥＰＳ（Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｓｙｓｔｅｍ、Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｃｏｒｅとも呼ぶ）とともにＬＴＥ  ＲＡＮ（Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）（またＥ−ＵＴＲＡＮとして知られている）を含む。
【０００３】
通信システムは、一般に、次の２つの主要な機能、すなわち、データ・プレーン機能とコントロール・プレーン機能とに分割される。以前のＬＴＥ製品では、モデム・ボードにおいて少なくとも２つのプロセッサが使用されていた。１つは、コントロール・プレーン機能をサポートするためのもの（非リアル・タイム、たとえばＯｐｅｒａｔｉｏｎｓ，  Ａｄｍｉｎｉｓｔｒａｔｉｏｎ，  ａｎｄ  Ｍａｎａｇｅｍｅｎｔ（または、ＯＡ＆Ｍ）、および呼処理の管理に関係する機能）、もう１つは、データ・プレーン機能を終了およびサポートするためのもの（リアル・タイム（たとえばＬＴＥレイヤ２処理））である。コントロール・プレーンおよびデータ・プレーンの両方は、コントロール・プレーンにはＬｉｎｕｘ、およびデータ・プレーン・コアにはｖＸＷｏｒｋｓ（カリフォルニア州アラメダのＷｉｎｄ  Ｒｉｖｅｒ  Ｓｙｓｔｅｍｓが製作および販売）などのリアル・タイム・オペレーティング・システム（ＯＳ）など、異なるＯＳのインスタンスを使用していた。通常、１つのモデム・ボードは、１つのセクタまたはセルをサポートした。このため、マルチセル（たとえば３つのセルまたは６つのセル）構成をサポートするには、セルの数と同数のモデム・ボードを提供することが必要になる。
【０００４】
改善策として、マルチコア・プロセッサをＬＴＥワイヤレス基地装置のモデム・ボードで使用することができる。その場合、ＰＲＥＥＭＰＴ  ＲＴパッチを用いるＳＭＰ  Ｌｉｎｕｘなどのオペレーティング・システムは、８つのコアをすべて含む１つのＳＭＰ（対称型マルチプロセッシング）パーティションで動作する。この構成では、コントロール・プレーン（非リアル・タイムのスレッドおよびプロセス）およびデータ・プレーン（リアル・タイムのスレッドおよびプロセス）は、異なるコアで実行しなければならないが、同じオペレーティング・システム・インスタンスを共有する。
【０００５】
しかし、ＰＲＥＥＭＰＴ  ＲＴを用いるオープン・ソースのＳＭＰ  Ｌｉｎｕｘは、ｖｘＷｏｒｋｓなどのハード・コアのリアル・タイム・オペレーティング・システムではない。したがって、ＰＲＥＥＭＰＴ  ＲＴを用いるＳＭＰ  Ｌｉｎｕｘから最適なリアル・タイム性能を保証するために、通常、そのようなオペレーティング・システムの使用から生じる制限されないレイテンシ・スパイク（ｌａｔｅｎｃｙ  ｓｐｉｋｅ）を減らす、または排除するためにさえ、いくつかの技術を用いることができる。制限されないレイテンシ・スパイクは、対処および排除されなければ、ＬＴＥレイヤ２スケジューラなどアプリケーションの全体的なシステムの振る舞いに悪影響を及ぼす傾向があり、場合によっては、システムを展開できなくなる。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】米国特許出願第１２／９４５，１４６号
【発明の概要】
【発明が解決しようとする課題】
【０００７】
したがって、たとえば、（ａ）リアル・タイムのプロセスまたはスレッドだけを実行することを専用とするデータ・プレーン・コアで重要でない割込みを無効にして、コントロール・プレーン・コアにこれらの割込みをルーティングすることによって、かつ（ｂ）デフォルトの「割込み」モードではなく、「ポーリング」モードで特定のハードウェア・コンポーネントを実行し、これによって、特定のデータ・コアに対して生成される割込みの数を減らすことによって、ＰＲＥＥＭＰＴ  ＲＴパッチを用いるＳＭＰ  Ｌｉｎｕｘなどのオペレーティング・システムのリアル・タイム性能を拡張する方法およびシステムに対するニーズがある。
【課題を解決するための手段】
【０００８】
本明細書に記述するのは、ＰＲＥＥＭＰＴ  ＲＴパッチを用いるＳＭＰ  Ｌｉｎｕｘなどのオペレーティング・システム（ＯＳ）のリアル・タイム性能を拡張するために用いることができる様々な技術である。ＰＲＥＥＭＰＴ  ＲＴを用いるＳＭＰ  Ｌｉｎｕｘは、ハード・コアのリアル・タイム・オペレーティング・システムではない。したがって、ＰＲＥＥＭＰＴ  ＲＴを用いるＳＭＰ  Ｌｉｎｕｘを使用することにより、そうでなければ発生する可能性がある制限されないレイテンシ問題に対処する技術を導入することが重要である。これらの制限されないレイテンシ・スパイクは、非常に厳格なリアル・タイム性能を必要とする、ＬＴＥレイヤ２スケジューラの適切なシステムの振る舞いに容易に影響し、システムを展開できなくなる可能性がある。特に、ＰＲＥＥＭＰＴ  ＲＴを用いるＳＭＰ  Ｌｉｎｕｘなどオペレーティング・システムのリアル・タイム性能を拡張するために用いることができるソフトウェア技術の１つは、リアル・タイムのプロセスまたはスレッドだけで実行することを専用とするデータ・プレーン・コアの重要でない割込みを無効にすることを含む。代わりに、ソフトウェアＤＭＡ割込みなど、これらの重要でない割込みは、コントロール・プレーン・コアにルーティングされる。さらに、ハードウェア・コンポーネントの少なくとも１つ（たとえばキュー・マネージャ）は、デフォルトの「割込み」モードではなく「ポーリング」モードで実行できるため、特定のデータ・コアに対して生成される割込みの数を減らすことができる。
【０００９】
一実施形態では、モデム・ボードにおいてマルチコア・プロセッサを用いてワイヤレス・ネットワークにおけるデータ・パケットを処理する、コンピュータ実装方法が提供される。ポーリング・モードでキュー・マネージャを実行している間、入力データ・パケットのバッファが取得され、データ・パケットはフレーム・キューにエンキューされ、フレーム・キューは、キュー・マネージャによって扱われるべきフレーム記述子のリンクされたリストを含む。カーネル・スレッドは、キューに入れられたフレーム記述子について、キュー・マネージャを定期的にポーリングし、ハードウェア・コンポーネントからＮ個のフレーム記述子をデキューするために使用され、ここでＮは、調整可能なパラメータである。カーネル空間でデキューされた各フレーム記述子に関連するコールバック機能を実行することができ、コールバック機能は、フレーム記述子内のデータ・パケットのバッファ・ポインタを処理のためにバッファ記述子のカーネルからユーザにマップされたリングにエンキューする。最後に、データ・パケットは、コンテキスト・スイッチなしでメッセージング・モジュールに送られる。
【００１０】
他の実施形態では、ワイヤレス・ネットワークでデータ・パケットを処理するためのシステムが提供される。装置は、概して、モデム・ボードと、モデム・ボードに取り付けられた複数のプロセッサ・コアを含むマルチコア・プロセッサとを含み、モデム・ボードはカーネル空間およびユーザ空間を含む。さらに、システムは、キューを管理し、かつポーリング・モードで実行するように構成されたキュー・マネージャと、入力データ・パケットのバッファを取得し、かつフレーム・キューにデータ・パケットをエンキューするように構成されたフレーム・マネージャとを含み、フレーム・キューは、ハードウェア・コンポーネントによって扱われるべきフレーム記述子のリンクされたリストを含む。さらに、カーネル・スレッドは、キューに入れられたフレーム記述子について、キュー・マネージャを定期的にポーリングし、ハードウェア・コンポーネントからＮ個のフレーム記述子をデキューするように構成され、ここでＮは、調整可能なパラメータである。カーネル空間でデキューされた各フレーム記述子に関連するコールバック機能は、フレーム記述子内のデータ・パケットのバッファ・ポインタを処理のためにバッファ記述子のカーネルからユーザにマップされたリングにエンキューするように構成される。最後に、システムは、コンテキスト・スイッチなしでメッセージング・モジュールにデータ・パケットを送るための手段を含むことができる。
【００１１】
さらに他の実施形態では、電気通信ネットワークの単一のＳＭＰパーティション内でマルチセル・サポートを提供するためのシステムが開示される。システムは、典型的には、モデム・ボードと、複数のプロセッサ・コアを有するマルチコア・プロセッサとを含み、マルチコア・プロセッサは、複数のデータ・プレーン・コアに到着する重要でない割込みを無効にし、複数のコントロール・プレーン・コアに、重要でない割込みをルーティングするように構成される。
【００１２】
この例示的な実施形態の適用性のさらなる範囲は、以下に提供する詳細な説明から明白になるであろう。しかし、本発明の精神および範囲内の様々な変更形態および修正形態は当業者には明白になるため、詳細な説明および特定の例は、本発明の好適な実施形態を示しているが、例示を目的としてのみ与えられることを理解されたい。
【００１３】
本発明は、デバイスの様々な部品の構造、構成物、および組合せ、ならびに方法のステップにおいて存在するものであり、意図する目的は、以下により完全に記述され、特に特許請求の範囲において指摘され、添付の図面に示されるように達成される。
【図面の簡単な説明】
【００１４】
【図１】本発明の態様によるプラットフォーム・アーキテクチャの一実施形態を示す図である。
【図２】本発明の態様によるコア・リザベーション（ｃｏｒｅ  ｒｅｓｅｒｖａｔｉｏｎ）およびコア・アフィニティ（ｃｏｒｅ  ａｆｆｉｎｉｔｙ）を用いる例示的なアーキテクチャを示す図である。
【図３】コア抽象化レイヤを実装するための例示的なアーキテクチャを示す図である。
【図４】ハードウェアが、デフォルトの割込みモードではなくポーリング・モードで実行するように構成されている場合の入力データ・パケットに関するプロセス・フローを示すハイ・レベルな記述である。
【発明を実施するための形態】
【００１５】
ここで図を参照すると、図は、例示的な実施形態を示すことのみが目的であり、請求される主題を限定することが目的ではない。図１は、この記述された実施形態を組み込むことができるシステムの図である。
【００１６】
ここで図１を参照すると、例示的なプラットフォーム・アーキテクチャ１００が示されている。このアーキテクチャは、概して、モデム・ボードで使用されるが、他の用途でも使用できることを理解されたい。本実施形態では、８つのコアすべてをその中に含む１つのパーティションが規定される。しかし、マルチコア・プロセッサ１００は、任意の数のコアを有することができることを理解されたい。この実施形態では、したがって、コアのすべて（たとえば８つのコア）で実行される単一の対称型マルチプロセッシング（ＳＭＰ）オペレーティング・システム（ＯＳ）インスタンス１０２を使用することが可能である。コントロール・プレーンおよびデータ・プレーンは、１つのＯＳインスタンス下にあるため、データ・プレーンに関する問題のためにコントロール・プレーンまでもが低下しないことを保証するために注意が全体として必要である。
【００１７】
この例では、マルチコア・プロセッサ１００は、３つのセルにサービスを提供する（図に１０４、１０６、および１０８として示す）。各セルは、アップリンク（ＵＬ）スケジューラ（図に１１０、１１２、および１１４として示す）およびダウンリンク（ＤＬ）スケジューラ（図１に１１６、１１８、および１２０として示す）を必要とする。
【００１８】
Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤは、ＬＴＥエア・インターフェースを横断して送信および受信されるパケット・フレームのエラーをセグメント化、連結、かつ修正するために使用されることが知られている。Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ／Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ（ＲＬＣ／ＭＡＣ）ソフトウェアが、ＧＰＲＳ（２．５Ｇ）ワイヤレス・スタックで使用される。これにより、移動局と基地局制御装置（ＢＳＣ）との間で承認されたデータ転送および承認されていないデータ転送が提供される。したがって、アーキテクチャ１００は、また、ＲＬＣ／ＭＡＣブロック１２２を含み、これは、移動局とネットワークとの間で使用されるエア・インターフェース上の基本的な伝達装置である。ＲＬＣ／ＭＡＣブロック１２２は、概して、データおよびＲＬＣ／ＭＡＣシグナリングを運ぶために使用される。
【００１９】
マルチコア・プロセッサ１００は、また、Ｏｐｅｒａｔｉｏｎｓ，  Ａｄｍｉｎｉｓｔｒａｔｉｏｎ，  ａｎｄ  Ｍａｎａｇｅｍｅｎｔ（ＯＡ＆Ｍ）モジュール１２４、および呼処理（または、ＣＡＬＬＰ）モジュール１２６を提供する。ＯＡ＆Ｍは、概して、電気通信ネットワークのコンポーネントの運用、保守、管理、および維持に関連するプロセス、活動、ツール、規格などを記述するために使用される。ＣＡＬＬＰモジュール１２６は、典型的には、呼処理活動の非リアル・タイムの態様を管理する。
【００２０】
さらに、マルチコア・プロセッサ１００は、コア抽象化レイヤ（ＣＡＬ）１２８を含み、これは、概して、レイヤ２（Ｌ２）のアプリケーション・ソフトウェアからコア固有の詳細を隠すものである。レイヤ２は、コンピュータ・ネットワーキングの７層の開放型システム間相互接続（ＯＳＩ）モデルのデータ・リンク・レイヤである。データ・リンク・レイヤは、ワイド・エリア・ネットワークの隣接するネットワーク・ノード間、または同じローカル・エリア・ネットワーク・セグメントのノード間のデータを転送するプロトコル・レイヤである。データ・リンク・レイヤは、ネットワーク・エンティティ間でデータを転送するための機能的および手続き的な手段を提供し、物理レイヤで発生する可能性があるエラーを検出および場合によっては修正するための手段を提供することもできる。データ・リンク・プロトコルの例は、ローカル・エリア・ネットワーク（マルチノード）のイーサネット、ポイント・ツー・ポイント・プロトコル（ＰＰＰ）、ＨＤＬＣ、およびポイント・ツー・ポイント（デュアルノード）接続のＡＤＣＣＰである。この場合、Ｌ２は、概して、ＬＴＥエア・インターフェースに必要なＬ２スケジューラ処理を指し、これは非常に厳格なリアル・タイム要件を有する。
【００２１】
移動通信装置とネットワーク・スイッチング・サブシステムとの間のトラフィックおよびシグナリングの処理を担当する、基地局のリアル・タイム性能のニーズを満たすために、ＰＲＥＥＭＰＴ  ＲＴパッチを用いるＳＭＰ  Ｌｉｎｕｘなどのオペレーティング・システムを使用することができる。もちろん、他のオペレーティング・システムが使用されてもよいことを理解されたい。そのようなＳＭＰ構成で決定的な振る舞いを達成するために、システムは、好ましくは、非同期マルチプロセッシング（ＡＭＰ：Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｍｕｌｔｉｐｒｏｃｅｓｓｉｎｇ）と同等のシステムの振る舞いを達成するためにコア・リザベーションおよびコア・アフィニティの構成物を用いる方法で実装される。たとえば、また、これはＰＲＥＥＭＰＴ  ＲＴを用いるＳＭＰ  Ｌｉｎｕｘから最高の性能を引き出すのにも望ましい。バッファ管理およびメッセージング・サービスなど、ロックレスのゼロ・コピー・サービスの使用は、また、ＰＲＥＥＭＰＴ  ＲＴを用いるＳＭＰ  Ｌｉｎｕｘオペレーティング・システムの使用によって提起される可能性があるレイテンシ問題に対処するのを支援することができる。
【００２２】
図１に示すようなコア抽象化レイヤ（１２８）の主な機能の１つは、マルチコア・プラットフォームの全機能を利用する様々なサービスを用いて、Ｌ２処理など、ハイ・レベルなアプリケーションを提供することである。したがって、コア抽象化レイヤは、複数の目標を達成するように設計されている。第一に、より高いレベルのアプリケーション・ソフトウェア（すなわちＬ２ソフトウェア）からＤＰＡＡおよびマルチコア固有の実装を隠しながら、新しいデータ・パス・アクセラレーション・アーキテクチャ（ＤＰＡＡ：Ｄａｔａ  Ｐａｔｈ  Ａｃｃｅｌｅｒａｔｉｏｎ  Ａｒｃｈｉｔｅｃｔｕｒｅ）に基づくＢＥＤ（バックプレーン・イーサネット・ドライバ）インターフェースをサポートする（ＤＰＡＡは、負荷拡散およびリソースの共有など、マルチコア・ネットワーク処理を最適化するように設計され、ネットワーク・インターフェースおよびハードウェア・アクセラレータを含む）。第２に、それは、入力および出力の両方向において、ユーザ・プレーン・データに対する加速されたデータ経路を提供するためにＰ４０８０のＤＰＡＡハードウェア・コンポーネントを利用する。第３に、それは、構成変更に容易に適合するために可能な限りの柔軟性を提供する（すなわちコード変更を必要としない）。ＣＡＬ構成の一例は、バッファ・プール、入力フレーム・キュー、および出力フレーム・キューのＤＰＡＡリソース構成である。
【００２３】
図１に示すように、本発明の実施形態は、１つのパーティションでプロセッサ・コアのすべてを使用する。シンプルなＬｉｎｕｘが難しいリアル・タイム処理のニーズをすべて満たすのは難しい場合があるので、ＰＲＥＥＭＰＴ  ＲＴパッチを用いるＳＭＰ  Ｌｉｎｕｘなどのオペレーティング・システムが好まれる。また、オープン・ソース・オペレーティング・システムは、コストを削減するためにも使用される。システムは、さらにＳＭＰ構成内にＡＭＰのようなシステムの振る舞いを規定するために、ＳＭＰ  Ｌｉｎｕｘのコア・アフィニティおよびＣＰＵ予約機能を組み込み、これにより、６セルまたは９セルの構成が可能になる。オペレーティング・システム・インスタンスは、非リアル・タイム・コア（コントロール・プレーンなど）とリアル・タイム・コア（データ・プレーンなど）との間で共有され、ロックが非リアル・タイムのスレッドおよびプロセスによって取られた場合、問題が生じる可能性がある。リアル・タイムのスレッドまたはプロセスは、データ・プレーン・コア（複数可）のロックの開放を待たなければならないため、ロックは、リアル・タイムのスレッドまたはプロセスの遅延を引き起こす可能性がある。転送制御プロトコル（ＴＣＰ）、ユーザ・データグラム・プロトコル（ＵＤＰ）などのトランスポート・レイヤ・プロトコルは、パケット・ヘッダでソースおよび宛先のポート番号を指定することが知られている。ポート番号は、１６ビットの符号のない整数である。プロセスは、ポート番号およびＩＰアドレスに、その入力または出力チャネルのファイル記述子（ソケット）を関連付け（バインディングとして知られているプロセス）、ネットワークを介してデータを送信および受信する。オペレーティング・システムのネットワーク・ソフトウェアは、すべてのアプリケーション・ポートからネットワークに出力データを伝送し、パケットのＩＰアドレスとポート番号とを照合することによって、到着するネットワーク・パケットをプロセスに転送するタスクを有する。標準的なＬｉｎｕｘプロトコル・スタックは、ロックレスの実装を保証しないため、例示的な実施形態では、Ｌｉｎｕｘプロトコル・スタックの使用を回避しながら、ＴＣＰ／ＵＤＰ  ＩＰパケットを送信および受信するために、データ・プレーン・コアで実行されるリアル・タイム・プロセス（ＬＴＥ  Ｌ２スケジューラ）のロックレス・メッセージング方式を規定する。コントロール・プレーン・コアで実行されるＯＡ＆Ｍなど非リアル・タイム・プロセスは、通常の運用にＬｉｎｕｘプロトコル・スタックを使用し続ける。
【００２４】
概して、Ｌｉｎｕｘの一般公有使用許諾（ＧＰＬ）問題を回避するために、ＬＴＥ  Ｌ２スケジューラは、ユーザ空間で運用される。このため、ＬＴＥ  Ｌ２スケジューラからＴＣＰ／ＵＤＰ  ＩＰデータを送信および受信するために、データは、ユーザ−カーネル空間の境界を横断する必要がある。このステップは、典型的には、データ・コピーを必要とする。このように、あるメモリ位置から他の位置にデータをコピーするためにプロセッサ・パワーを消費することは、貴重なリソースを無駄にすることになる。したがって、（従来のＬｉｎｕｘプロトコル・スタックを使用するなど）コントロール・プレーンが通常の方法で動作することを可能にしながら、データ・プレーン・コアで実行されるリアル・タイムのスレッドおよびプロセスについて、効率的なロックレスのゼロ・コピーおよび非閉塞メッセージング・サービスを可能にする方法およびシステムを提供することが望ましい。
【００２５】
コントロール・プレーン（ＯＡ＆Ｍおよび呼処理など、非リアル・タイムのプロセスおよびスレッド）およびデータ・プレーン（ＬＴＥ  Ｌ２スケジューラなど、リアル・タイムのプロセスおよびスレッド）の両方は、同じオペレーティング・システム・インスタンスを共有するため、これらの２種類の活動が実施されるコアの少なくとも一部を物理的に分離することを確認することは有用である。
【００２６】
この点で、図２は、コア・リザベーションおよびコア・アフィニティの構成物を用いるアーキテクチャを示している。この例では、８つのコア・プロセッサが使用される。コア０〜７は、図において参照番号２０２、２０４、２０６、２０８、２１０、２１２、２１４、および２１６と示されている。非リアル・タイムのスレッドまたはプロセスはすべて、コントロール・プレーンの活動専用のコアに結合される（２１８）。言い換えると、データ・プレーン活動専用のコアのグループ分け（図に２２０、２２２、２２４、および２２６として示す）は、「高速経路（ｆａｓｔ  ｐａｔｈ）」（データ経路）の実装またはＬ２処理に直接的に必要でないスレッドをホストまたは実行しない。「高速経路」は、「通常の経路」と比べてプログラムを通じた指示経路の長さが短い経路を記述する用語である。高速経路を効果的にするために、最も一般に発生するタスクを通常の経路よりも効率的に扱い、珍しいケース、めったに発生しない厄介なケース、エラー処理、および他の異常を扱うために通常の経路を残す必要がある。高速経路は、最適化の一形式である。高速経路ドライバによって使用される入力バッファ・プールは、システム全体の共有リソースの一例である。それらは、ユーザ・プレーン・パケットを受信することを専用としている。
【００２７】
コア・アフィニティおよびコア・リザベーションを達成するために、コントロール・プレーン・コアのグループ分け２１８へのデフォルトのアフィニティ・マスクが規定される。この方法で、特定のバインディングを割り当てられていないスレッドまたはプロセスは、デフォルトでコントロール・プレーン・コア（複数可）になる。コア抽象化レイヤ（ＣＡＬ）２２０は、Ｌ２アプリケーション・ソフトウェアからコア固有の詳細を隠す。この構成では、１つのオペレーティング・システム・インスタンス２２２だけが実行されている。
【００２８】
所与のセルに対応するリアル・タイムのプロセスおよびスレッドは、コア・リザベーションおよびコア・アフィニティを介して指定されたコアに結合される。たとえば、セル１およびセル４のアップリンク・スケジューラ・スレッドは、コア２に結合され、ダウンリンク・スケジューラ・スレッドはコア３に結合される。したがって、図２は、ＳＭＰ構成内のＡＭＰのような構成を示している。この実施形態では、たとえば、ＯＡ＆Ｍおよび呼管理プロセスなど、すべてのコントロール・プレーンのプロセスおよびスレッドは、コア０（２０２）で実行される。セルのリアル・タイムのプロセスおよびスレッドのそれぞれは、専用のコアで実行され、非リアル・タイムのプロセスまたはスレッドは実行されない。この方法で、（１）非リアル・タイム・スレッドは、処理時間不足になることはない。（２）非リアル・タイム・スレッドは、リアル・タイム・スレッドから貴重な処理時間を奪わず、厳密なリアル・タイム処理要件を有するデータ・コアの処理レイテンシ・スパイクを増加させない。
【００２９】
概して、Ｌｉｎｕｘなどオペレーティング・システムのシステム・メモリは、カーネル空間およびユーザ空間という、２つの個別の領域に分割できることが知られている。カーネル空間は、カーネル（すなわちオペレーティング・システムのコア）を動作（すなわち実行）させサービスを提供する場所である。
【００３０】
メモリは、概してＲＡＭ（ランダム・アクセス・メモリ）セルから構成され、そのコンテンツは非常に高速にアクセス（すなわち、読取りおよび書込み）できるが、一時的（すなわち、使用中、またはせいぜい電源がオンの間）にしか保存されない。その目的は、現在使用されているプログラムおよびデータを保持することである。
【００３１】
ユーザ空間は、ユーザ・プロセス（すなわちカーネル以外のすべて）が実行されるメモリ位置の組である。プロセスは、プログラムの実行インスタンスである。カーネルの役割の１つは、この空間内で個々のユーザ・プロセスを管理し、相互に干渉するのを防ぐことである。
【００３２】
カーネル空間は、システム・コールの使用を通じてのみユーザ・プロセスによってアクセスすることができる。システム・コールは、入出力（Ｉ／Ｏ）またはプロセス作成など、カーネルによって実行されるサービスのアクティブなプロセスによるＵｎｉｘのようなオペレーティング・システムの要求である。ＣＰＵで次の順番を待っているプロセスとは対照的に、アクティブなプロセスは、ＣＰＵで現在進行しているプロセスである。Ｉ／Ｏは、ＣＰＵとの間、および周辺機器（ディスク・ドライブ、キーボード、マウス、およびプリンタなど）との間でデータを転送する任意のプログラム、操作、またはデバイスである。
【００３３】
したがって、カーネル空間は、カーネル、カーネル拡張、およびほとんどのデバイス・ドライバを実行するために厳密に予約される。これとは対照的に、ユーザ空間は、すべてのユーザ・モード・アプリケーションが機能するメモリ領域であり、必要な場合は、このメモリはスワップ・アウトすることができる。
【００３４】
ここで図３を参照すると、これらおよび他の目標を達成する例示的なアーキテクチャ３００が示されている。この点で、コア抽象化レイヤ（ＣＡＬ）３０１は、次を含むが、これらに限定されない、様々なモジュールをユーザ空間に含む：ＬＴＥネットワーク構成および任意の静的なパーシング、クラス分け、および配布（ＰＣＤ：Ｐａｒｓｉｎｇ，Ｃｌａｓｓｉｆｉｃａｔｉｏｎ  ａｎｄ  Ｄｉｓｔｒｉｂｕｔｉｏｎ）のルールをフレーム・マネージャ（ＦＭａｎ）３３０および３３２にロードし、１組の構成ファイルに基づいてＣＡＬフレームワークを設定する、コア抽象化レイヤ初期化（ＣＡＬＩｎｉｔ）モジュール３０２、コア抽象化レイヤ・バッファ（ＣＡＬＢｕｆ）モジュール３０４、他のボード（すなわちｅＣＣＭ）との間でユーザ・プレーン・データを送信および受信するために、Ｌ２ソフトウェアにメッセージング・サービスを提供する、コア抽象化レイヤ・メッセージング（ＣＡＬＭｓｇ）モジュール３０６、適切なコアに入力フレームをルーティングするために各ＦＭａｎ（３３０および３３２）によって使用されるＰＣＤルールおよび構成を提供する、コア抽象化レイヤ・パーシング、分類、および分配（ＣＡＬＰｃｄＦｍｃ）モジュール３０８、ならびにカーネル空間モジュールである、コア抽象化レイヤのＤＰＡＡドライバ（ＣＡＬＤｐａａＤｒｉｖｅｒ）３１２においてトレースを有効および無効にするためのトレーシング能力を提供する、コア抽象化レイヤＤＰＡＡトレース（ＣＡＬＤｐａａＴｒａｃｅ）モジュール３１０。
【００３５】
さらに、ＣＡＬ３０１は、また、バッファ・プール、入力フレーム・キュー、および出力フレーム・キューを管理するためのＤＰＡＡリソース構成ツール３１３を含むことができる。
【００３６】
アーキテクチャ３００は、ＰＲＥＥＭＰＴ  ＲＴパッチを用いるＳＭＰ  Ｌｉｎｕｘなど、適切なオペレーティング・システム３１４をさらに含む。オペレーティング・システム３１４は、次に、前述のＣＡＬＤＰａａドライバ３１２、少なくとも１つのフレーム・マネージャ（ＦＭａｎ）ドライバ３１６、少なくとも１つのバッファ・マネージャ（ＢＭａｎ）ドライバ３１８、および少なくとも１つのキュー・マネージャ（ＱＭａｎ）ドライバ３２０など、様々なドライバをサポートする。バッファ記述子３２１のリングは、ＣＡＬＭｓｇモジュール３０６などのユーザ空間コンポーネント、およびＣＡＬＤｐａａＤｒｉｖｅｒ３１２などのカーネル空間コンポーネントがアドレス問題を全く伴わず、またはデータ・コピーの必要なく、アクセスすることを可能にするためにマップされたカーネルからユーザ（Ｋ−Ｕ）への空間である。
【００３７】
図３に示すように、アーキテクチャ３００は、複数のパワー・アーキテクチャ処理コアをキャッシュ、スタンド・アロンのキャッシュ、およびメモリ・サブシステムに接続するための拡張可能なオンチップ・ネットワークに適した相互接続アーキテクチャである、Ｐ４０８０のＣｏｒｅＮｅｔ構造３２２を適切に含むことができる。
【００３８】
Ｐ４０８０プロセッサは、ＤＰＡＡの実装を含む。したがって、アーキテクチャ２００は、Ｐ４０８０のＤＰＡＡ２２４をさらに含むことができる。ＤＰＡＡ３２４は、負荷拡散およびリソースの共有などマルチコア・ネットワーク処理を最適化するように設計され、ネットワーク・インターフェースおよびハードウェア・アクセラレータを含む。図示するように、ＤＰＡＡ３２４は、概して、それぞれＢＭａｎ３２６、ＱＭａｎ３２８、ならびに第１および第２のＦｍａｎ３３０および３３２など様々なマネージャを含む。
【００３９】
ワイヤレス多重アクセス通信システムにおいて、送信機および受信機は、複数レイヤの通信スタックを使用して通信できることが知られている。レイヤは、たとえば、物理レイヤ、Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ（ＭＡＣ）レイヤ、Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ（ＲＬＣ）レイヤ、プロトコル・レイヤ（たとえばパケット・データ・コンバージェンス・プロトコル（ＰＤＣＰ：ｐａｃｋｅｔ  ｄａｔａ  ｃｏｎｖｅｒｇｅｎｃｅ  ｐｒｏｔｏｃｏｌ）レイヤ）、アプリケーション・レイヤなどを含むことができる。ＲＬＣレイヤは、ＰＤＣＰレイヤからサービス・データ単位（ＳＤＵ）を受信し、ＭＡＣレイヤへの伝送のために、ＲＬＣプロトコル・データ・ユニット（ＰＤＵ）へとＳＤＵを連結またはセグメント化する。
【００４０】
したがって、ＣＡＬＢｕｆモジュール３０４は、ＲＬＣ  ＳＤＵ処理で使用するＬ２アプリケーションのためにロックレスのバッファ管理サービスを促進する。当技術分野で知られているように、非閉塞アルゴリズムにより、共有リソースを取り合うスレッドは、相互排除によって無期限にそれらの実行を延期しないことが保証される。システム全体の進行が保証されている場合、非閉塞アルゴリズムは、ロックレスである（またはロックがない）。ＣＡＬＢｕｆモジュール３０４は、また、バッファ・プール統計データの照会をサポートすることができる（たとえば、プールの消耗状態、消耗数、プールの利用状態、プール割り当てエラー数など）。ＣＡＬＢｕｆモジュール３０４は、概して、そのようなサービスを実装するためにＣＡＬＤｐａａＤｒｉｖｅｒ３１２とインターフェースする。ＣＡＬＢｕｆモジュール３０４は、マルチコア環境で適切なシステム運用に望ましいロックレスのバッファ管理方式をさらに提供し、非リアル・タイム・プロセスによって取られたロックは、そのロックの開放を待っているリアル・タイム・プロセスのレイテンシ問題を引き起こす可能性がある。
【００４１】
ＣＡＬＭｓｇモジュール３０６は、他のボード（すなわちｅＣＣＭ）との間でユーザ・プレーン・データを送信および受信するために、Ｌ２ソフトウェアにメッセージング・サービスを提供する。ＣＡＬＭｓｇモジュール３０６は、概して、ＤＰＡＡを介して、ロックレスのゼロ・コピー・メッセージング・サービスを提供するためにＣＡＬＤＰＡＡＤｒｉｖｅｒ３１２とインターフェースする。ＣＡＬＤｐａａＤｒｉｖｅｒ３１２は、バッファ記述子３２１のリングの作成元である。この点で、ＣＡＬＤｐａａＤｒｉｖｅｒ３１２は、バッファ記述子３２１のリング上に入力データ・フロー・パケットをエンキューする。ＣＡＬＭｓｇ  ＡＰＩからの支援を受けるＬＴＥ  Ｌ２スケジューラなどユーザ空間アプリケーションは、バッファ記述子３２１のリングの典型的な消費者である。ユーザ・アプリケーションは定期的に実行され、バッファ記述子３２１のリング上にエンキューされたパケットのそれぞれを処理する。この機能は、制限されていないレイテンシ遅延（ｌａｔｅｎｃｙ  ｄｅｌａｙ）を回避するために、ロックなしのゼロ・データ・コピーの方法で、プロトコル・スタックを使用することなく、Ｌ２アプリケーション・ソフトウェアがＴＣＰ／ＵＤＰ  ＩＰパケットを送信および受信することを可能にする。
【００４２】
ＣＡＬＤｐａａＤｒｉｖｅｒ３１２は、ＣＡＬ３０１のカーネル空間コンポーネントであり、ＢｍａｎおよびＱｍａｎのＡＰＩを使用してバッファ管理サービスおよびメッセージング・サービスを実施および提供するのを支援する。本明細書で使用する場合、ＡＰＩ（またはアプリケーション・プログラミング・インターフェース）という用語は、ソフトウェア・プログラムによって実装されたインターフェースを指し、これにより他のソフトウェアと対話することが可能になる。これにより、ユーザ・インターフェースにより、ユーザとコンピュータとの間の対話処理が促進されるのに似た方法で、異なるソフトウェア・プログラム間の対話処理が促進される。ＡＰＩは、ボキャブラリおよび呼び出し規約を決定するために、アプリケーション、ライブラリ、およびオペレーティング・システムによって実装され、それらのサービスにアクセスするために使用される。それは、ルーチン、データ構造、オブジェクト・クラス、および消費者とＡＰＩの実装者との間で通信するために使用されるプロトコルの仕様を含むことができる。
【００４３】
ＣＡＬＤｐａａＤｒｉｖｅｒ３１２は、概して、ユーザ・プレーン・データの分配；オープン、クローズ、初期化のためのｉ−ｏ−ｃｏｎｔｒｏｌ（ｉｏｃｔｌ：入出力制御）、バッファ管理、およびメッセージング・サービスなど、様々なファイル操作を介する他のＣＡＬモジュールにユーザ空間インターフェースの提供；カーネルからユーザ空間（Ｋ−Ｕ）へのバッファ・マッピングの実行；ＤＰＡＡバッファ・プールならびに受信機および送信機の統計データの提供；ならびにリング・バッファを管理するためのサービスの実装に使用されるＤＰＡＡリソース（バッファ・プールおよびフレーム・キュー）を管理することを担当する。リング・バッファは、概して、ＣＡＬのレイヤ２ソフトウェア・キューを表し、それらは、特定のレイヤ２ダウンリンク・スケジューラ・スレッドを宛先とするフレーム記述子（ＦＤ）を格納するために使用されることに注意されたい。ＣＡＬＭｓｇモジュール３０６は、リングからバッファ記述子を取り込むために、レイヤ２ダウンリンク・スケジューラのＡＰＩを提供する。
【００４４】
ＣＡＬＢｕｆモジュール３０４は、「高速経路」データ処理に排他的に使用されるバッファ管理サービスを提供する。ＣＡＬＢｕｆモジュール３０４は、Ｌ２アプリケーションにユーザ空間ＡＰＩを提供する。ＣＡＬＢｕｆモジュール２０４は、ＣＡＬＤｐａａドライバ３１２が作成するが、Ｂｍａｎ３２６によって管理されるバッファに対して、ゼロ・コピーおよびロックレスのバッファ管理サービスを提供するために、ＣＡＬＤｐａａＤｒｉｖｅｒ３１２と協働する。
【００４５】
ＣＡＬＤｐａａＤｒｉｖｅｒ３１２の例外はあるが、上記のＣＡＬコンポーネントはすべて、概して、（ユーザ空間で実行される）プラットフォーム・ミドルウェアである。ＣＡＬＤｐａａＤｒｉｖｅｒ３１２は、カーネル空間で実行されるカスタム・ドライバであり、ＣＡＬユーザ空間ミドルウェアによって必要とされるサービス、具体的にはＰ４０８０のＤＰＡＡハードウェア・コンポーネントに依存するサービスを実装および提供するように設計されている。
【００４６】
この新しいアーキテクチャのコア抽象化レイヤの一部として、ロックレスのバッファ管理およびメッセージング・サービスを導入することで、コントロール・プレーンおよびデータ・プレーンの両方が同じＯＳインスタンスを共有する、ＳＭＰ環境において制限されていないレイテンシ・スパイクを回避するのに役立つ。ＳＭＰ環境では、１つのコアで非リアル・タイムのプロセスまたはスレッドによって取られるロックは（コントロール・プレーンで見つかるものなど）、別のコアでそのロックが開放されるのを待っているリアル・タイムのスレッドまたはプロセスにレイテンシ・スパイクを引き起こす可能性がある（データ・プレーンで見つかるものなど）。したがって、１つのパーティションを使用するマルチコア・プロセッサ・ベースのモデム・ボードの性能のニーズを満たすために、データ・プレーン・コアで高速のデータ経路にＬｉｎｕｘプロトコル・スタックを使用しないロックレスでゼロ・コピーの非閉塞メッセージング方式へのニーズがある。そのような方式がなければ、特にＬＴＥ  Ｌ２スケジューラの処理に関して、システムは、システム全体を機能停止させる可能性がある制限されていないレイテンシ・スパイクの影響を受けやすい場合がある。
【００４７】
ゼロ・コピー・メッセージング方式を使用することで、データ・コピーの必要なく、カーネル空間のイーサネット・インターフェースに到着するパケットが、ユーザ空間のレイヤ２ダウンリンク・スケジューラなど、その宛先に到達することが可能になる。Ｌｉｎｕｘ  ＧＰＬの課題のために、ＬＴＥ  Ｌ２スケジューラはユーザ空間で運用される。したがって、ＬＴＥ  Ｌ２スケジューラとの間でＴＣＰ／ＵＤＰ  ＩＰデータを送信および受信するために、データは、ユーザ−カーネル空間の境界を横断する必要がある。そのような活動は、典型的には、データ・コピーを必要とする。このように、あるメモリ位置から他の位置にデータをコピーするためにプロセッサ・パワーを消費することは、貴重なリソースを無駄にすることになる。したがって、（従来のＬｉｎｕｘプロトコル・スタックを使用するなど）コントロール・プレーンが通常の方法で動作することを引き続き可能にしながら、データ・プレーン・コアで実行されるリアル・タイムのスレッドおよびプロセスについて、効率的なロックレスでゼロ・コピーの非閉塞メッセージング・サービスを可能にする方法およびシステムを提供することが望ましい。
【００４８】
高速データ経路の実装のためにＬｉｎｕｘプロトコル・スタックを回避することで、データ・プレーン・コアで実行されるＬＴＥ  Ｌ２スケジューラは、代替のロックレス・メッセージング方式を使用して、ＴＣＰおよびＵＤＰのＩＰパケットを送信および受信することができる。Ｌｉｎｕｘプロトコル・スタックを使用すると、ＬＴＥ  Ｌ２スケジューラの処理を機能停止させる可能性がある制限されていないレイテンシ・スパイクが生じる可能性がある。これは、Ｌｉｎｕｘプロトコル・スタックがロックレスとして設計されていないという事実によるものである。さらに、コントロール・プレーン・コアで実行されるＯＡ＆Ｍおよび呼処理のエンティティなど、プロトコル・スタックも非リアル・タイムのプロセスおよびスレッドによって使用されるため、リアル・タイムのプロセスおよびスレッドについて制限されていないレイテンシ・スパイクを引き起こす場合がある。プロトコル・スタックは、コントロール・プレーン・コアで実行しなければいけないため、ＯＡ＆Ｍおよび呼処理など、非リアル・タイムのプロセスおよびスレッドは、プロトコル・スタックを使用し続ける。これらは、システムの振る舞いおよび／または運用において故障なく、時々発生する制限されていないレイテンシ・スパイクに容易に耐えられるためである。
【００４９】
図４は、入力データ・パケット・フローについてデータ・プレーン・コアでの割込みを無効にする例示的な方法を示している。入力データ・フロー・パケットは、カーネル・スレッドによって扱われ、これは、各割込みに関連するコンテキスト・スイッチ処理のオーバヘッドを減らすために、パケットについてハードウェアをポーリングする。
【００５０】
最初に、ハードウェア（たとえば、ＱＭａｎ３２８）は、デフォルトの「割込み」モードではなく、「ポーリング」モードで実行するように構成される（４１０）。ＱＭａｎ３２８は、最初に、すなわちプロセッサが再起動されるときにソフトウェアの初期化の間に、ポーリング・モードで実行するように構成することができる。デフォルトの割込みモードについては、参照によりその開示が本明細書に組み込まれている、たとえば、２０１０年１１月１２日に出願した米国特許出願第１２／９４５，１４６に、より詳細に記述されていることに注意されたい。
【００５１】
データ・パケットは、外部イーサネット・インターフェースに継続的に到着するため、ＦＭａｎ３３０などのフレーム・マネージャは、（１）ＢＭａｎ３２６などのバッファ・マネージャからバッファを取得すべきであり、（２）バッファ内にパケットをコピーすべきであり、（３）フレーム・キュー（ＦＱ）にパケットをエンキューすべきである。フレーム・キューは、ＱＭａｎ３２８などキュー・マネージャによって扱われるべきフレーム記述子のハードウェア・リンクされたリストである（４２０）。本明細書で使用する場合、「リンクされたリスト」は、データ・レコードの連続から構成されるデータ構造を指し、各レコードに、連続内の次のレコードへの参照（すなわち「リンク」）を含むフィールドがある。この場合、各フレーム記述子は、データ・パケットを保持するバッファへのポインタを含む。ＱＭａｎ３２８は、システムに対して作成されたフレーム・キューをすべて管理する。ＦＭａｎ３３０は、到着する各データ・パケットのＩＰアドレスを検査するために、ＣＡＬモジュール３０１によって規定されたＰＣＤルール（たとえば、入力フレーム・キュー・マッピングへのＩＰアドレス）を使用する。次に、Ｆｍａｎ３３０は、データ・パケットを保持するバッファへのポインタを含むフレーム記述子を作成し、適切なフレーム・キューにそれをエンキューする。
【００５２】
パケットがハードウェア・キューの先頭に到達するまで、ＱＭａｎ３２８はその内部ハードウェア・キューにパケットを押し入れる（４３０）。重要なことに、ハードウェアは、データ・プレーン・コアへのポータル割込み（ｐｏｒｔａｌ  ｉｎｔｅｒｒｕｐｔ）を生成しない。
【００５３】
カーネル・スレッドは、概して、この実施形態においてポーリング・モードで実行するように構成された、ＱＭａｎ３２８にサービスを提供するために、ＣＡＬＤｐａａＤｒｉｖｅｒ３１２の一部として作成される（４４０）。
【００５４】
ＣＡＬＤｐａａＤｒｉｖｅｒ３１２のカーネル・スレッドは、（定期的な間隔ΔＴで）定期的にウェイクアップし、ＱＭａｎ  ＡＰＩを呼び出して、ハードウェア・キューの先頭に到達したキューに入れられた任意のフレーム記述子についてポーリングする（４５０）。
【００５５】
次に、カーネル・スレッドは、ＱＭａｎ３２８から「Ｎ」個のエントリ（フレーム記述子）をデキューする（すなわち、キューからアイテムを取り除く）（４６０）。ただし、「Ｎ」は、調整可能なパラメータを表している（たとえば、Ｎ＝１００）。特に、Ｎは、カーネル・スレッドが「ウェイクアップ」するたびにサービスを提供するＱＭａｎ３２８からのフレーム記述子エントリの数を示している。
【００５６】
次に、サービスが提供されるフレーム記述子があるかどうかに関して決定が行われる（４７０）。ない場合は、カーネル・スレッドはスリープに戻る（４９０）。
【００５７】
そうでない場合、デキューされた各フレーム記述子エントリに関連する登録済みのコールバック機能が実行される。コールバック機能は、コンテキスト・スイッチなし、かつロックレスのゼロ・コピーの方法で、ＣＡＬＭｓｇモジュール３０６にパケットを送る。これは、たとえば、バッファ記述子内にフレーム記述子からデータ・パケットのバッファ・ポインタをコピーし、それをユーザ空間レイヤ２ダウンリンク・スケジューラによって最終的に消費されるバッファ記述子３２１の適切なＫ−Ｕマップされたリングにエンキューすることによって、達成することができる（４９０）。
【００５８】
割込みモードでは、各入力データ・パケットの到着は、典型的には、データ・プレーン・コアへの割込みへとつながる。最大１５のデータ・パケットが１つの割込みサービス・ルーチン（ＩＳＲ）で扱われる、割込み結合（ｉｎｔｅｒｒｕｐｔ  ｃｏａｌｅｓｃｉｎｇ）モードでも、ユーザ−カーネル−ユーザ（ｕｓｅｒ−ｔｏ−ｋｅｒｎｅｌ−ｔｏ−ｕｓｅｒ）空間のコンテキスト・スイッチの処理オーバヘッドはかなり際立っている。この理由は、４Ｇ  ＬＴＥのワイヤレス・システムは、大人数のユーザをサポートし、それぞれが高いデータ速度を保持することができるからである（約２ＭＢｉｔｓ／秒の平均データ速度）。しかし、ＱＭａｎ３２８が、デフォルトの割込みモードではなくポーリング・モードで実行されるように構成することで、複数の恩恵が得られる。たとえば、上に概説した方式は、入力データ・フローについて、特定のデータ・コアに対して生成される割込みの数を大幅に減らす。これにより、データ・プレーン・コアに発生するコンテキスト・スイッチングの大きな減少につながる（ユーザ−カーネル−ユーザ空間）。これは、データ・プレーン・コアの処理オーバヘッドの大きな減少につながり、ＬＴＥシステムのリアル・タイム性能が拡張される。
【００５９】
さらに、ソフトウェアＤＭＡ割込みなど重要でない割込みは、リアル・タイムのプロセスまたはスレッドだけを実行することを専用とするデータ・プレーン・コアで無効化され、その代わりに、コントロール・プレーン・コアに発生するように、これらの割込みをルーティングする。これは、カーネル空間で実行される割込みサービス・ルーチン（ＩＳＲ）へのＬＴＥ  Ｌ２スケジューラなど、ユーザ空間アプリケーションからの不必要なコンテキスト・スイッチが、これらの割込みの結果としてデータ・プレーン・コアに発生しないことを保証するのを支援する。各コンテキスト・スイッチは、かなりの関連している処理オーバヘッドを含む。この不必要な処理オーバヘッドを排除することによって、ＬＴＥ  Ｌ２スケジューラなど、リアル・タイムのプロセスおよびスレッドについて、より多くの処理時間およびパワーがデータ・プレーン・コアに与えられる。
【００６０】
上記の様々な方法のステップは、プログラムされたコンピュータによって実行できることを当業者なら容易に理解するであろう。本明細書において、一部の実施形態は、たとえば、デジタル・データ記憶媒体など、プログラム記憶装置を包含するようにも意図されており、プログラム記憶装置は、読取り可能な機械またはコンピュータであり、機械で実行可能なまたはコンピュータで実行可能なプログラム命令をエンコードし、前述の命令は、上記方法のステップの一部またはすべてを実行する。プログラム記憶装置は、たとえば、デジタル・メモリ、磁気ディスクや磁気テープなどの磁気記憶媒体、ハードドライブ、または光学的に読取り可能なデジタル・データ記憶媒体などであってもよい。また、実施形態は、上記方法の上述したステップを実行するようにプログラムされたコンピュータを包含することを意図するものである。
【００６１】
上記の記述は、単に本発明の特定の実施形態の開示を提供するものであり、それに限定することを目的とすることを意図するものではない。したがって、本発明は上記の実施形態だけに限定されない。むしろ、当業者なら本発明の範囲に入る代替の実施形態を想到し得ることが認識される。
【図１】
0005726320.tif 000002
【図２】
0005726320.tif 000003
【図３】
0005726320.tif 000004
【図４】
0005726320.tif 000005