JP2008521360A - リアルタイムパケット処理システムおよび方法 - Google Patents

Abstract

いくつかの実施例では、この発明は、リアルタイムパケット検出、処理、およびルーティングの組合せを含んでいてもよい。分散型アーキテクチャにおいて実現される場合、そのようなシステムは、低コスト、高い利用可能性、および／または、リアルタイムデータを交換し、重要な役割を担うシステムにおいて期待されるサービスの質を提供することが可能な安全なネットワークを生み出すことができる。

Description

本願は、２００４年１１月１９日に出願された米国仮特許出願第６０／６２９，３３１号の利益を主張し、その内容全体はここに引用により援用される。

発明の背景
発明の分野
この発明は一般に、たとえばＴＣＰ／ＩＰパケットを含む、パケット交換システムにおけるパケットの処理に関する。いくつかの好ましい実施例は、音声、映像および／またはマルチメディアパケット処理システムおよび方法に関与する。

背景の説明
パケット交換システムは、重要な役割を担うアプリケーションにおいて最小限しか受入れられていない。これは主として、パケット交換システムが、重いネットワーク負荷の下での低いリアルタイムデータ品質と、制限されたネットワーク帯域幅に起因する伝搬遅延とを経験するおそれがある、ということによる。

ネットワーク帯域幅の問題に加え、従来のパケット交換ネットワークノードは、そのパケットが対象パケットかどうかを判断するためにすべてのネットワークトラフィックを受信し、処理する必要がある。パケットを調べるには、ノードプロセッサは、ネットワークプロトコルソフトウェアスタックの少なくとも一部をホストする必要がある。大型システムでは、この要件はネットワークノードのコストに影響を与え得る。なぜなら、処理負荷に対処するために強力なマイクロプロセッサが必要とされるためである。

しかしながら、パケット交換システムは、重要な役割を担うアプリケーションにおいて有利となり得る特徴を有する。たとえば、そのようなシステムは、音声およびリアルタイムデータ配信に対処するために、重要なタイミング基準信号を全ノードに配信することを必要とはしない。加えて、例示的なパケット交換システムは、システムノード間の標準タイプのネットワーク接続（たとえば、イーサネット（登録商標）接続）しか必要とはしないかもしれず、それは、設置の簡略化、インフラストラクチャコストの低減、およびライフサイクルコストの著しい低下という効果を有し得る。

したがって所望されるのは、パケット交換ノードが重要なアプリケーションにより良好に適するように、それらの上述の、および／または他の限界を克服するシステムおよび方法である。

発明の概要
この特許出願に記載された発明のいくつかの好ましい実施例は、重要な役割を担うアプリケーションにおけるパケット交換ネットワークの限界を克服する。いくつかの実施例では、この発明は、リアルタイムパケット検出、処理、およびルーティングの組合せを含んでいてもよい。分散型アーキテクチャにおいて実現される場合、そのようなシステムは、低コスト、高い利用可能性、および／または、リアルタイムデータを交換し、重要な役割を担うシステムにおいて期待されるサービスの質を提供することが可能な安全なネットワークを生み出すことができる。これらの著しい改良は、パケット交換システムの既存のネ
ットワークおよび将来の展開の双方との互換性を確実にする標準ネットワークプロトコルおよびインフラストラクチャを用いて達成可能である。

この発明の一実施例に従ったシステムは、ネットワークからパケットデータを受信するための媒体アクセス制御レイヤモジュールと、ネットワークから受信されたパケットデータを記憶するためのパケットメモリとを備え、パケットデータはパケットヘッダデータを含み、前記システムはさらに、リアルタイムパケットハンドラと、プロトコルスタックを実行するプロセッサと、パケットヘッダデータを調べて、パケットヘッダと関連付けられたペイロードがリアルタイムデータを含むことをパケットヘッダデータが示しているかどうかを判断するパケットヘッダテストモジュールとを備え、ヘッダテストモジュールは、ペイロードがリアルタイムデータを含むことをパケットヘッダが示していないとモジュールが判断した場合には、パケットデータをプロセッサにルーティングし、ペイロードがリアルタイムデータを含むことをパケットヘッダが示しているとモジュールが判断した場合には、パケットデータをリアルタイムパケットハンドラにルーティングする。

いくつかの実施例では、リアルタイムパケットハンドラは、パケットデータをフィルタリングし、処理するためのコントローラと、デジタル信号プロセッサに結合され、フィルタリングされ処理されたパケットデータを記憶するためのキューとを備える。いくつかの実施例では、リアルタイムパケットハンドラは、（ａ）パケットデータに含まれるソースアドレスを判断し、（ｂ）ソースアドレスが予め定められたソースアドレスのリストに含まれているかどうかを判断し、および（ｃ）ソースアドレスがアクティブチャネルと関連付けられているかどうかを判断するよう構成されており、ソースアドレスがアクティブチャネルと関連付けられ、かつソースアドレスが予め定められたソースアドレスの前記リストに含まれている場合、ハンドラはパケットデータを修正し、修正されたパケットデータを前記キューに記憶させる。

この発明の一実施例に従った方法は、（ａ）ネットワークからパケットデータを受信するステップを備え、パケットデータはパケットヘッダデータとパケットペイロードデータとを備えており、前記方法はさらに、（ｂ）パケットヘッダデータを調べるステップと、（ｃ）パケットヘッダデータに基づいて、パケットペイロードデータがリアルタイムデータを含むかどうかを判断するステップと、（ｄ）パケットペイロードデータがリアルタイムデータを含んでいない場合、プロトコルスタックを実行中のプロセッサにパケットデータを提供するステップと、パケットペイロードデータがリアルタイムデータを含んでいる場合、（ｅ）パケットデータがフィルタを通過し、かつソースアドレスがアクティブチャネルと関連付けられている場合には、デジタル信号プロセッサに結合されたキューにパケットデータを記憶させるステップと、（ｆ）パケットデータが前記フィルタを通過し、かつパケットデータのペイロードが快適雑音および／または無音から成っていない場合には、前記キューにパケットデータを記憶させるステップとを備える。

この発明の上述の、および他の特徴、ならびに利点と、この発明の好ましい実施例の構造および動作とを、添付図面を参照して以下に詳細に説明する。

ここに援用され、明細書の一部を形成する添付図面は、この発明のさまざまな実施例の例示を支援しており、さらに、この発明の原理を解説し、関連技術の当業者がこの発明の実施例を作成して使用することを可能にするように、説明とともに機能する。図面において、同じ参照番号は、同一の、または機能的に同様の要素を示す。

好ましい実施例の詳細な説明
図１は、この発明の一実施例に従ったコンピュータシステム１００の機能ブロック図で
ある。システム１００は、媒体アクセス制御（ＭＡＣ）レイヤモジュール１０２を含む。ＭＡＣレイヤモジュール１０２は、ネットワーク１９０との間でパケットを送受信する。ＭＡＣレイヤモジュール１０２は、ネットワーク１９０からパケットデータを受信すると、パケットを形成してパケットデータをパケットオフセットメモリ１０４に記憶させる。

ヘッダテストモジュール１０６は、ＭＡＣレイヤ１０２によって受信中のパケットがリアルタイムパケット（すなわち、特殊な処理を必要とするパケット）であるかどうかを判断するために、メモリ１０４に記憶されたパケットデータを調べる。たとえば、ヘッダテストモジュール１０６は、パケットがリアルタイムペイロード（たとえば音声ペイロード）を含むかどうかを判断するために、適切なパケットヘッダを調べてもよい。

パケットがリアルタイムパケットではないとヘッダテストモジュール１０６が判断した場合、次にそれは、処理のために従来のプロトコルスタック１１２（たとえばＴＣＰ／ＩＰプロトコルスタック）を実行中のプロセッサ（たとえばＲＩＳＣプロセッサ、ＣＩＳＣプロセッサ、または他のプロセッサ）にパケットがルーティングされ得るように、スイッチ１０８を閉じる。パケットがリアルタイムパケットであるとヘッダテストモジュール１０６が判断した場合、次にそれは、リアルタイムパケットハンドラ１１４にパケットがルーティングされ得るように、スイッチ１１０を閉じる。スイッチ１０８および１１０は、ハードウェアスイッチまたはソフトウェアスイッチであってもよい。リアルタイムパケットハンドラ１１４は、それが受信したパケットをフィルタリングして修正し、そのフィルタリングされ修正されたパケットを、パケットのペイロードを処理するデジタル信号プロセッサ（ＤＳＰ）１１６に提示するよう構成されてもよい。

ここで図２を参照すると、図２は、リアルタイムパケットハンドラ１１４の機能ブロック図である。ハンドラ１１４は、パケットオフセットメモリ１０４から受信したパケットを記憶するためのパケットメモリ２０２を有していてもよい。ハンドラ１１４はまた、メモリ２０２に記憶されたパケットを処理するよう構成されたコントローラ２０４を含んでいてもよい。

ここで図３を参照すると、図３は、コントローラ２０４によって行なわれ得る、一実施例に従ったプロセス３００を示すフローチャートである。プロセス３００はステップ３０２で始まってもよく、そこでコントローラ２０４はパケットのソースアドレスを判断する。ステップ３０４で、コントローラは、ソースアドレスが予め規定されたアドレスの範囲内に該当するかどうかを判断してもよい。たとえば、この範囲は６５，５３６個のアドレスを含んでいてもよい。判断されたソースアドレスがこの範囲内にない場合、コントローラ２０４はそのパケットを廃棄してもよい（ステップ３０６）。ソースアドレスがこの範囲内にある場合、コントローラ２０４はソースアドレスを、アプリケーションまたはユーザにとって特定の対象となっているアドレスを記憶するテーブル２０６と比較してもよい（ステップ３０８）。ソースアドレスとテーブル２０６内のアドレスとの間に整合がないとコントローラ２０４が判断した場合、コントローラ２０４はそのパケットを廃棄してもよい（ステップ３０６）。

一方、パケットのソースアドレスがテーブル２０６に含まれているとコントローラ２０４が判断した場合、コントローラ２０４はそのパケットの処理を続行する（すなわち、制御はステップ３１２に移ってもよい）。

ステップ３１２で、コントローラ２０４は、ソースアドレスがアクティブチャネルと関連付けられているかどうかを判断してもよい。たとえば、いくつかの実施例では、ソースアドレスがアクティブチャネルテーブル２０８に記憶されている場合、ソースアドレスはアクティブチャネルと関連付けられている。いくつかの実施例では、アクティブチャネル
の数に制限があってもよい。たとえば、一実施例では、ＤＳＰ１１６は所与の時点において１２８個のチャネルしか処理できない。このため、この実施例では、アクティブチャネルの数は１２８を超えてはならない。アクティブチャネルテーブルはソースアドレスをチャネル番号にマッピングする。

ステップ３１２で、ソースアドレスがアクティブチャネルと関連付けられているとコントローラ２０４が判断した場合、プロセス３００はステップ３１４に進んでもよい。一方、ソースアドレスがアクティブチャネル値と関連付けられていないとコントローラ２０４が判断した場合、プロセス３００はステップ３３０に進んでもよい。

ステップ３１４で、コントローラ２０４はパケットのヘッダを修正する。たとえば、コントローラ２０４は、ヘッダから不必要な情報を除去して（たとえば、不必要なＲＴＰ定義が除去される）、パケットのソースアドレスと関連付けられたチャネル番号をヘッダに挿入してもよい。上述のように、テーブル２０８はチャネル番号をソースアドレスと関連付ける。すなわち、テーブル２０８に記憶された各ソースアドレスは、固有のチャネル番号と関連付けられてもよい。いくつかの実施例では、ステップ３１８の後では、パケットのヘッダはもはやすべてのＲＴＰ定義を含んでおらず、チャネル割当値および制御ビットしか含んでいない。

ステップ３１６で、コントローラはパケットのペイロードを調べて、ペイロードが快適雑音および／または無音のいずれかから成るかどうかを判断する。ペイロードが快適雑音および／または無音のいずれかから成るとコントローラ２０４が判断した場合、コントローラ２０４はテーブル２０８からチャネル割当を除去してもよい（ステップ３１８）。すなわち、コントローラ２０４は、パケットのソースアドレスがアクティブチャネルの値と関連付けられないように、テーブル２０８を修正してもよい。

ペイロードが快適雑音および／または無音以外の何かを含むとコントローラ２０４が判断した場合、プロセス３００はステップ３２０に進んでもよい。加えて、プロセス３００はステップ３１８の後でステップ３２０に進む。

ステップ３２０で、今や完全に形成されたものの修正されたパケットヘッダおよびペイロードが、次にキュー２１０に記憶される。キュー２１０は、１つ以上の先入り先出し（ＦＩＦＯ）キューを含んでいてもよい。たとえば、いくつかの実施例では、キュー２１０は２つのＦＩＦＯキューを含み、そのため、コントローラ２０４がキューのうちの一方にパケットを書込んでいる間、ＤＳＰ１１６が他方のキューからパケットを読出すことができるようになっている。

いくつかの実施例では、コントローラ２０４によって処理中のパケットまたはパケットの一部（たとえばパケットペイロード）は暗号化される。そのような実施例では、テーブル２０６または２０８は、テーブル内の各ソースアドレスを、パケットを解読するために使用される鍵と関連付けてもよい。この実施例では、コントローラ２０４がキュー２１０にパケットを書込む前に、コントローラ２０４はパケットのソースアドレスと関連付けられた鍵を用いて、暗号化されたパケットまたはその一部を解読する。

ここでステップ３１０を参照すると、ステップ３３０で、コントローラ２０４、コントローラ２０４はパケットのペイロードを調べて、ペイロードが快適雑音および／または無音のいずれかから成るかどうかを判断する。ペイロードが快適雑音および／または無音のいずれかから成るとコントローラ２０４が判断した場合、コントローラ２０４はそのパケットを廃棄してもよい（ステップ３３２）。

ペイロードが快適雑音および／または無音以外の何かを含むとコントローラ２０４が判断した場合、プロセス３００はステップ３３４に進んでもよい。

ステップ３３４で、コントローラ２０４はソースアドレスをチャネルと関連付けて、パケットのヘッダを修正する。たとえば、コントローラ２０４は、ヘッダから不必要な情報を除去して、パケットのソースアドレスと関連付けられたチャネル番号をヘッダに挿入してもよい。いくつかの実施例では、ステップ３３４の後では、パケットのヘッダはもはやすべてのＲＴＰ定義を含んでおらず、チャネル割当値および制御ビットしか含んでいない。ステップ３３４の後で、制御はステップ３２０に移ってもよい。

この発明の好ましい実施例では、モジュール１０２、１０６および１１４はハードウェアで実現されているが、これは要件ではない。たとえば、モジュール１０２、１０６および１１４は、１つ以上のフィールドプログラマブルゲートアレイ（ＦＰＧＡ）および／または特定用途向け集積回路（ＡＳＩＣ）を用いて実現されてもよい。加えて、プロトコルスタック１１２は好ましくは、汎用プロセッサ（たとえばＲＩＳＣプロセスまたは他のプロセッサ）上で実行するソフトウェアで実現される。

この発明のさまざまな実施例／変形を上述してきたが、それらは限定のためではなく単なる例示として提示されてきたことが理解されるべきである。このため、この発明の幅および範囲は、上述の例示的な実施例のいずれによっても限定されるべきではなく、特許請求の範囲およびそれらの均等物に従ってのみ定義されるべきである。

加えて、上述され、図面に例示されたプロセスは一連のステップとして示されているが、これは例示のためにのみ行なわれたものである。したがって、いくつかのステップが追加されてもよく、いくつかのステップが省略されてもよく、ステップの順序が並び替えられてもよく、いくつかのステップが同時に行なわれてもよい、ということが考えられる。

一実施例に従ったコンピュータシステム１００の機能ブロック図である。 一実施例に従ったリアルタイムパケットハンドラの機能ブロック図である。 一実施例に従ったプロセスを示すフローチャートである。

Claims (20)

1. リアルタイムの音声および／または映像データを含むパケットを処理するためのシステムであって、
   ネットワークからパケットデータを受信するための媒体アクセス制御レイヤモジュールと、
   ネットワークから受信されたパケットデータを記憶するためのパケットメモリとを備え、パケットデータはパケットヘッダデータを含み、前記システムはさらに、
   リアルタイムパケットハンドラと、
   プロトコルスタックを実行するプロセッサと、
   パケットヘッダデータを調べて、パケットヘッダと関連付けられたペイロードがリアルタイムデータを含むことをパケットヘッダデータが示しているかどうかを判断するパケットヘッダテストモジュールとを備え、ヘッダテストモジュールは、ペイロードがリアルタイムデータを含むことをパケットヘッダが示していないとモジュールが判断した場合には、パケットデータをプロセッサにルーティングし、ペイロードがリアルタイムデータを含むことをパケットヘッダが示しているとモジュールが判断した場合には、パケットデータをリアルタイムパケットハンドラにルーティングし、
   リアルタイムパケットハンドラは、パケットデータをフィルタリングし、処理するためのコントローラと、デジタル信号プロセッサに結合され、フィルタリングされ処理されたパケットデータを記憶するためのキューとを備え、
   リアルタイムパケットハンドラは、（ａ）パケットデータに含まれるソースアドレスを判断し、（ｂ）ソースアドレスがソースアドレスのリストに含まれているかどうかを判断し、および（ｃ）ソースアドレスがアクティブチャネルと関連付けられているかどうかを判断するよう構成されており、ソースアドレスがアクティブチャネルと関連付けられ、かつソースアドレスがソースアドレスの前記リストに含まれている場合、ハンドラはパケットデータを修正し、修正されたパケットデータを前記キューに記憶させる、システム。
2. ハンドラはさらに、パケットデータのペイロードが快適雑音および／または無音から成るかどうかを判断するよう構成されている、請求項１に記載のシステム。
3. データ構造がソースアドレスをアクティブチャネルと関連付けている場合、ならびにパケットデータのペイロードが快適雑音および／または無音から成るとハンドラが判断した場合、ハンドラは、ソースアドレスがアクティブチャネルと関連付けられないようにデータ構造を修正する、請求項２に記載のシステム。
4. データ構造がソースアドレスをアクティブチャネルと関連付けていない場合、ならびにパケットデータのペイロードが快適雑音および／または無音から成っていないとハンドラが判断した場合、ハンドラは、ソースアドレスがアクティブチャネルと関連付けられるようにデータ構造を修正する、請求項２に記載のシステム。
5. ヘッダテストモジュールはＦＰＧＡを用いて実現される、請求項１に記載のシステム。
6. リアルタイムパケットハンドラはＦＰＧＡを用いて実現される、請求項５に記載のシステム。
7. プロトコルスタックを実行するプロセッサは、ＲＩＳＣまたはＣＩＳＣプロセッサである、請求項６に記載のシステム。
8. ソースアドレスがソースアドレスの前記リストに含まれているとハンドラが判断した後でののみ、ハンドラは、ソースアドレスがアクティブチャネルと関連付けられているかど
   うかを判断する、請求項１に記載のシステム。
9. ソースアドレスが前記リストに含まれているかどうかを判断する前に、前記ハンドラは、ソースアドレスがアドレスの予め定められた範囲内にあるかどうかを判断する、請求項１に記載のシステム。
10. パケットデータを修正し、修正されたパケットデータを前記キューに記憶させる前に、ハンドラは、ソースアドレスと関連付けられた鍵を用いて、パケットデータの少なくとも一部を暗号化する、請求項１に記載のシステム。
11. リアルタイムの音声および／または映像データを含むパケットを処理するための方法であって、
    （ａ） ネットワークからパケットデータを受信するステップを備え、パケットデータはパケットヘッダデータとパケットペイロードデータとを備えており、前記方法はさらに、
    （ｂ） パケットヘッダデータを調べるステップと、
    （ｃ） パケットヘッダデータに基づいて、パケットペイロードデータがリアルタイムデータを含むかどうかを判断するステップと、
    （ｄ） パケットペイロードデータがリアルタイムデータを含んでいない場合、プロトコルスタックを実行中のプロセッサにパケットデータを提供するステップと、
    パケットペイロードデータがリアルタイムデータを含んでいる場合、
    （ｅ） パケットデータがフィルタを通過し、かつソースアドレスがアクティブチャネルと関連付けられている場合には、デジタル信号プロセッサに結合されたキューにパケットデータを記憶させるステップと、
    （ｆ） パケットデータが前記フィルタを通過し、かつパケットデータのペイロードが快適雑音および／または無音から成っていない場合には、前記キューにパケットデータを記憶させるステップとを備える、方法。
12. ステップ（ｅ）は、パケットデータのペイロードが快適雑音および／または無音から成るか否かにかかわらず行なわれる、請求項１１に記載の方法。
13. ステップ（ｆ）は、ソースアドレスがアクティブチャネルと関連付けられているか否かにかかわらず起こる、請求項１１に記載の方法。
14. パケットヘッダデータに含まれるソースアドレスがアドレスのリストに含まれている場合、パケットデータは前記フィルタを通過する、請求項１１に記載の方法。
15. パケットヘッダデータに含まれるソースアドレスがアドレスのリストに含まれ、かつ予め定められたアドレス範囲内にある場合、パケットデータは前記フィルタを通過する、請求項１１に記載の方法。
16. パケットペイロードデータが快適雑音および／または無音から成るかどうかを判断するステップをさらに備える、請求項１１に記載の方法。
17. パケットペイロードデータが快適雑音および／または無音から成り、かつデータ構造がソースアドレスをアクティブチャネルと関連付けている場合、データ構造がソースアドレスをアクティブチャネルと関連付けないようにデータ構造を修正するステップをさらに含む、請求項１６に記載の方法。
18. パケットペイロードデータが音声データを含み、かつデータ構造がソースアドレスをア
    クティブチャネルと関連付けていない場合、データ構造がソースアドレスをアクティブチャネルと関連付けるようにデータ構造を修正するステップをさらに含む、請求項１６に記載の方法。
19. 前記キューは１つ以上の先入れ先出しキューを備える、請求項１１に記載の方法。
20. デジタル信号プロセッサは、前記キューからパケットを読出すよう構成されている、請求項１１に記載の方法。

Images