(57)【要約】      （修正有）【課題】より効率的なデータ・パケット処理方法を提供する。【解決手段】受信データ・ストリームが、パケット・ストリームへ形成され、各パケットは、データのペイロード・セクションと、オーバーヘッド・セクションとを有する。テンプレート・オーバーヘッド・セクションが作成され、パケットを形成するデータに適用される。これにより、パケットを個々にルーティング・スタックを通す必要がなくなり、プロセッサ上のデータ・パケットを組み立てる処理要求を低減させ、送信遅延を低減させることができる。第一のプロセッサがシグナリング・パケットを処理し、第二のプロセッサがリアルタイム・データ・パケットを処理する。第一のプロセッサは、リアルタイム・データ・パケットを形成するのに用いられ得る第二のプロセッサへテンプレート情報を転送する前にテンプレート・オーバーヘッド・セクションを作成するのに用いられる。【選択図】図３
2010233240.tif 000002
【特許請求の範囲】
【請求項１】
シグナリング・パケットとリアルタイム・データを運ぶリアルタイム・パケットとの２種類のデータ・パケットを処理する方法であって、
前記シグナリング・パケットを第一のプロセッサによって処理し、
前記リアルタイム・パケットを第二のプロセッサによって処理する、
ことを特徴とする方法。
【請求項２】
請求項１記載の方法であって、
前記第二のプロセッサは、前記第一のプロセッサよりも低い機能性を有する、
ことを特徴とする方法。
【請求項３】
請求項２記載の方法であって、
前記第二のプロセッサは、前記第一のプロセッサのコプロセッサ、縮小命令セット（ＲＩＳＣ）プロセッサ、及びＦＰＧＡ（ｆｉｅｌｄ  ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙ）のうちの１つである、
ことを特徴とする方法。
【請求項４】
請求項１記載の方法であって、
パケットを送信するために、
前記第一のプロセッサを用いて、リアルタイム・データ・パケット・ストリームによって用いられるテンプレート・オーバーヘッド・セクションを生成し、
前記第二のプロセッサを用いて、前記テンプレートを前記リアルタイム・データ・パケットに適用する、
ことを特徴とする方法。
【請求項５】
シグナリング・パケットとリアルタイム・データを運ぶリアルタイム・パケットとの２種類のデータ・パケットを処理する装置であって、
前記シグナリング・パケットを処理する第一のプロセッサと、
前記リアルタイム・パケットを処理する第二のプロセッサと、
を有することを特徴とする装置。
【請求項６】
請求項５記載の装置であって、
前記第二のプロセッサは、前記第一のプロセッサよりも低い機能性を有する、
ことを特徴とする方法。
【請求項７】
請求項５記載の装置であって、
前記第二のプロセッサは、前記第一のプロセッサのコプロセッサ、縮小命令セット（ＲＩＳＣ）プロセッサ、及びＦＰＧＡ（ｆｉｅｌｄ  ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙ）のうちの１つであることを特徴とする方法。
【請求項８】
リアルタイム・データ・パケット・ストリームを送信するのに用いられる請求項２３記載の装置であって、
前記第一のプロセッサは、リアルタイム・データ・パケット・ストリームによって用いられるテンプレート・オーバーヘッド・セクションを生成し、このテンプレートを前記第二のプロセッサへ転送するように構成され、
前記第二のプロセッサは、前記テンプレートを前記リアルタイム・データ・パケットに適用するように構成される、
ことを特徴とする装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネット・プロトコル（ＩＰ）パケットの処理に用いることが可能なデータ・パケット処理方法及び装置に関する。
【背景技術】
【０００２】
パケット単位及びセル単位の転送プロトコルは、音声、データ、及び映像などの広範囲なトラフィック種類を運ぶ能力のために受け入れられてきている。インターネット・プロトコル（ＩＰ）は、相互接続されたネットワークを超える通信、及び、様々なハードウェア・アーキテクチャを有するコンピュータとオペレーティング・システムとの間の通信を提供するネットワーキング・プロトコルとして、産業界で幅広く受け入れられてきている。国際電気通信連合（ＩＴＵ）のＨ．３２３、及び、インターネット・エンジニアリング・タスクフォースのセッション・イニシエイション・プロトコル（ＳＩＰ）のプロトコル一式は、いずれもＩＰ及びインターネット電話用の規格として開発されている。図１は、音声データがＩＰネットワークを通じた転送のために処理される典型的な方法を示す。最初に、音声データが受信され（２）、多くの場合圧縮され（４）、データ・パケットのペイロードを構成する。このデータ・パケットは、ＩＰスタックを通ってルーティングされる（６）。ＩＰスタックは、パケットにルーティング情報及び他のオーバーヘッド情報を付加する。最後に、組み立てられたデータ・パケットがデータ・ネットワークを通じて送信される（８）。図２に示すように、これにより、パケット・ストリーム７４〜７７が得られる。各パケットは、オーバーヘッド若しくはヘッダ・セクション７０と、ペイロード・セクション７２とを有する。各データ・パケットは、これと同じように処理される。すなわち、パケット７４〜７７のそれぞれのオーバーヘッド・セクション７２は、パケットをＩＰスタックを通してルーティングさせることによって生成される。データ・パケットをＩＰスタックを通るようにルーティングさせる工程は、多くの場合、ソフトウェアによって実行され、システム・プロセッサ上に高い要求を発生させる。プロセッサ上の要求は、このデータが、音声信号を遅延させるのを回避するためにリアルタイム処理が要求されるリアルタイム音声データであるという事実によって、更に悪化させられる。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
本発明は、より効率的なデータ・パケット処理方法を提供することを探究する。
【課題を解決するための手段】
【０００４】
本発明の第一の態様は、データ・ネットワーク上にパケット形式で送信されることが意図された受信データ・ストリームを処理する方法であって、該データを、各パケットがペイロード・セクションとオーバーヘッド・セクションとを有するパケット・ストリームへ構成する工程を有し、該パケットを構成する工程は、前記パケット・ストリームによって用いられるテンプレート・オーバーヘッド・セクションを作成し、該テンプレートを前記データに適用して前記パケットを構成する方法を提供する。
【０００５】
パケット・ストリームによって用いられるテンプレート・オーバーヘッド、ヘッダ、又はセクションを生成することは重要な利点を有する。このオーバーヘッド・データは、ストリームのすべてのパケットに対して生成される必要はなく、一度だけ生成されればよい。これは、データ・パケットを構築するプロセッサ上の処理要求を大幅に削減する。これにより、より安価なマイクロプロセッサを用いることができる。或いは、同じマイクロプロセッサが従前よりも多くのトラフィック処理チャネルをサポートすることができる。更に、データによって経験される送信遅延を削減することができ、データによって運ばれるトラフィックの品質を向上させることができる。
【０００６】
テンプレート作成工程は、そのパケットに対するルーティング情報を含むテンプレートを作成することが好ましい。テンプレート・オーバーヘッド・セクションは、パケットをルーティング・スタックを通るように送信することによって構成することができる。テンプレートが適用される後続データはルーティング・スタックを通るように転送されないため、処理リソースを大幅に節約することができる。
【０００７】
本方法は、後でテンプレート・パケットとして識別され得るパケットを生成する工程を更に有し、テンプレート・オーバーヘッド・セクションは、テンプレート・パケットをルーティング・スタックを通るように送信し、後で該パケットをテンプレート・パケットとして識別し、ルーティング・スタックによってテンプレート・パケットに適用されたルーティング情報を用いて構成されることが好ましい。
【０００８】
テンプレート構造は、メモリ内に作成することが可能であり、ルーティング・スタックを通るように転送されるパケットは、このテンプレート構造へのポインタを含み得る。このポインタは、ルーティング・スタックを通るように転送されるパケットのペイロードに保持されることが可能であり、テンプレート構造は、そのパケットがテンプレートであることを示す識別子を含み得る。
【０００９】
ルーティング情報は、テンプレート・パケットからテンプレート構造へコピーされるのが好ましい。このパケットの後でテンプレート・パケットとして識別されること及びテンプレート構造への情報のコピーは、データリンク層で実行され得る。この方法は、全体的に、ルーティング・スタックの内部動作から独立している。なぜなら、ルーティング・スタックは、データのペイロードに対して、通常通りの方法で、通常通りのルーティング情報及び他のオーバーヘッド情報を生成するように動作するからである。パケットがテンプレート・パケットであることを明らかにし、テンプレート構造をオーバーヘッド情報で満たすのは、データリンク層によるパケットの後続の調査である。
【００１０】
必要であれば、新しいテンプレート・オーバーヘッド・セクションが、データ・ストリームの持続時間中に周期的に作成されることも可能である。
【００１１】
このテンプレーティング方法は、選択されたパケット種類に対してのみ適切である。よって、パケット種類を決定する工程を更に有し、テンプレートを生成し、該テンプレートを選択されたパケット種類に適用する工程のみを実行することが好ましい。このテンプレーティング方法は、リアルタイム転送プロトコル（ＲＴＰ）及びユーザ・データグラム・プロトコル（ＵＤＰ）のパケット種類に対して特に適切である。
【００１２】
更に、第一のプロセッサを用いてテンプレート・パケットを作成し、このテンプレートを第二のプロセッサを用いてデータに適用することによっても利点が得られる。第二のプロセッサは、第一のプロセッサよりも低い機能性を有するプロセッサであって、第一のプロセッサのコプロセッサ、縮小命令セット（ＲＩＳＣ）プロセッサ、又はＦＰＧＡ（ｆｉｅｌｄ  ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙ）であると有益的である。
【００１３】
本発明の別の態様は、データ・ネットワーク上にパケット形式で送信されることが意図された受信データ・ストリームを処理する装置であって、該受信データを、各パケットがデータのペイロード・セクション及びオーバーヘッド・セクションを有するパケット・ストリームへ構成するプロセッサを有し、該プロセッサは、前記パケット・ストリームによって用いられるテンプレート・オーバーヘッド・セクションを作成し、該テンプレートを前記データに適用して前記パケットを構成するように構成されている装置を提供する。
【００１４】
この装置は、全体がハードウェアで実現されてもよく、ソフトウェアとハードウェアの組み合わせにより実現されてもよい。
【００１５】
本方法は、プロセッサを制御するソフトウェア・コードとして実現されてもよい。従って、本発明の更に別の態様は、上記方法を実行するソフトウェア・コードを提供する。このコードは、ディスケット、光ディスク、若しくはメモリ装置などの機械可読媒体上に記録されてもよい。
【００１６】
本発明の更に別の態様は、シグナリング・パケットとリアルタイム・データを運ぶリアルタイム・パケットとの２種類のデータ・パケットを処理する方法であって、シグナリング・パケットを第一のプロセッサによって処理し、リアルタイム・パケットを第二のプロセッサによって処理する方法を提供する。
【００１７】
第二のプロセッサは、第一のプロセッサよりも低い機能性を有するプロセッサであると有益的である。これにより、第一のプロセッサ上の処理要求が大幅に低減され、完全な機能性を備えたプロセッサ群を用いる場合よりもより安価な装置とすることができる。第二のプロセッサは、第一のプロセッサのコプロセッサ、縮小命令セット（ＲＩＳＣ）プロセッサ、又はＦＰＧＡ（ｆｉｅｌｄ  ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙ）であると有益的である。
【００１８】
データ・パケットを送信する際、第一のプロセッサを用いて、リアルタイム・データ・パケット・ストリームによって用いられるテンプレート・オーバーヘッド・セクションを生成し、第二のプロセッサを用いて、テンプレートをリアルタイム・データ・パケットに適用することによって更なる利点が得られる。
【００１９】
好ましい特徴は、適切に組み合わせられてもよく、本発明の任意の態様と組み合わせられてもよいことは当業者には明らかであろう。
【図面の簡単な説明】
【００２０】
【図１】ＩＰネットワーク上を転送させるために音声データを処理する既知の方法を示す図である。
【図２】図１に係る方法から得られるパケット・ストリームを示す図である。
【図３】データ・ネットワーク上で音声トラフィックを運ぶための例示的システムを示す図である。
【図４】ＩＰパケットのフォーマットを示す図である。
【図５】ＵＤＰヘッダのフォーマットを示す図である。
【図６】ＩＰヘッダのフォーマットを示す図である。
【図７】テンプレート・パケットを作成する処理を示す図である。
【図８】データ・ネットワーク上を送信させるためのデータ・パケット処理が可能な方法を示す図である。
【図９】パケット処理装置を示す図である。
【図１０】受信データ・パケットを処理することができる方法を示す図である。
【発明を実施するための形態】
【００２１】
本発明をより良い理解のために、及び、本発明が如何にして実行され得るかを例示的に示すために、ここで、添付図面を参照して実施形態を説明する。
【００２２】
図３は、データ・ネットワークを通じて電話を掛けることができる典型的なシステムを示す。端末１０、１１は、構内交換機ＰＢＸ  Ａの個別のディジタル回線カード（ＤＬＣ）１２へ接続されている。音声、ＦＡＸ、及び他の情報は、シグナリング情報と共に、時分割多重（ＴＤＭ）内部バス１５を通じて、データ・ネットワーク３０とのインターフェースとなるＩＰゲートウェイ・カード２０へ切り替えられる。ゲートウェイ・カード２０は、ＰＢＸによって用いられるフォーマットとデータ・ネットワーク３０を通じた転送に必要なフォーマットとの間の変換を実行する。このゲートウェイ機能は、更に、ダイヤルされた番号とインターネット・プロトコル・アドレスとの間の変換を扱う。トラフィックは、通常、ＴＣＰ／ＩＰ若しくはＵＤＰ／ＩＰフォーマットに従って、データ・ネットワーク上を運ばれる。すなわち、シグナリングは、通常、ＴＣＰパケットによって運ばれ、音声データは、リアルタイム転送プロトコル（ＲＴＰ）のユーザ・データグラム・プロトコル（ＵＤＰ）パケット・ストリームによって運ばれる。音声若しくは他の音声帯域情報は、データ・ネットワーク３０を超えてパケットをルーティングさせるための情報を運ぶヘッダをそれぞれが有するデータ・パケット内へパッケージ化される。このデータ・ネットワークは、データ・ネットワーク３０を超えるトラフィックのルーティングを実行するルータ２５、２６を含む。以上の装置は本分野では既知である。データ・ネットワーク３０は、構内ＩＰデータ・ネットワーク若しくはイントラネットでもよく、公のインターネットでもよい。ユーザがデータ・ネットワーク３０に直接接続されたコンピュータ端末１６から電話を掛ける場合、（音声データをパケットへ組み立てる）ＩＰゲートウェイ・カードの機能は、端末１６自身のソフトウェアによって実行される。
【００２３】
図４は、ＵＤＰデータを運ぶＩＰパケット若しくはデータグラムのフォーマットを示す。これは、ＵＤＰデータのペイロード６０と、（８バイトの）ＵＤＰヘッダ６１と、（２０バイトの）ＩＰヘッダ６２と、物理層若しくはデータリンク層ヘッダ６３と、を有する。ペイロード６０の長さは変化する。図５は、８バイトのＵＤＰヘッダ６１のフォーマットを示し、図６は、２０バイトのＩＰヘッダ６２のフォーマットを示す。ＵＤＰヘッダの１６ビットのＵＤＰチェックサム６４が、ＵＤＰデータ６０、ＵＤＰヘッダ６１、及びＩＰヘッダ６２の一部に提示されたデータに従って計算される。
【００２４】
図７は、データ・パケットをデータ・ネットワークを通じた送信のために処理する方法を示す。これは、ＵＤＰ／ＩＰパケットを参照して説明される。ＵＤＰ／ＩＰは、ＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ；ＩＰネットワーク上に音声を通すための技術の総称）用途で用いられる種類のＲＴＰ音声データ・パケットを運ぶのに用いられる。しかし、この技術が、ストリーム内の各パケットに関連付けられたオーバーヘッド情報が同じであれば、あらゆる種類のストリーム化されたデータ・パケットに対してより幅広く適用させることが可能なのは明らかである。ＴＣＰパケットは、この方法によって処理することができない。なぜなら、それらは個々にＩＰ層における承認を必要とするからである。
【００２５】
最初に、データ・ネットワークを超えて発信元から宛先へデータ・ストリームを送信するために、発信元においてＵＤＰソケット１００が確立される。このソケットは、通常、ＴＣＰ／ＩＰ呼セットアップ・シグナリングの結果として確立される。ソケットは、ほとんどの今日のオペレーティング・システムにおいて、幅広く用いられているネットワーク・インターフェース用プログラミング・インターフェースである。
【００２６】
特殊なテンプレート・パケットが、通常のＵＤＰ／ＩＰルーティング・スタック１０５を通ってルーティングされる。このテンプレート・パケットのペイロードは、メモリに記録された固有のテンプレート構造のポインタ、すなわちメモリ・アドレスを有する。このポインタにより、パケットはデータリンク層によってテンプレート・パケットとして識別される。
【００２７】
テンプレート構造の好ましい構成は、
１．固有の識別子
−  それがテンプレート・パケットであるか否かを素早く判断するためにデータリンク層によって用いられる。
２．手旗信号（ｓｅｍａｐｈｏｒｅ）
−  テンプレート構造の送信者にこのテンプレートが使える状態であることを示すためにデータリンク層によって用いられるフラグ。
３．ドライバ送信機能
−  ＵＤＰ／ＩＰスタックを通るようにルーティングされない後続のパケットの直接送信を可能にするためにパケットが送信される際に通らなければならないインターフェースに固有の機能。パケット・テンプレートと共にデータリンク層によって満たされる。
４．ドライバ送信パラメータ
−  ドライバ送信機能と共に用いられ、パラメータ・ストリームが通るインターフェースの識別を可能にするパラメータ。複数のネットワーク・インターフェースを有するシステムにおいて必要とされる。パケット・テンプレートと共にデータリンク層によって満たされる。
５．テンプレート・データ
−  作成されたテンプレートの実際のデータ。
６．テンプレート長
−  テンプレート・データ・エリアの長さ。
【００２８】
デバイス・ドライバ（データリンク層１１０）は、テンプレート・パケットを検知し、このルーティングされたテンプレート・パケットを送信者へ送り返す。次いで、データリンク層は、このルーティングされたパケットからのヘッダ情報をメモリ内の特殊なテンプレート構造内へコピーする。後続データ１３０は、パケットをデータリンク層へ直接送信するためにデータリンク層によってちょうど満たされたテンプレート構造における情報を用いるテンプレート・ソケット１２０を通じて、送信される。
【００２９】
ＩＰプロトコルは、ＩＰヘッダのみをカバーするＩＰヘッダ・チェックサム（６５４、図６４）を含む。このチェックサムの値は、特に、ペイロード長に依存する。データ・パケットが同じ長さであれば、ＩＰヘッダ・チェックサムは、すべてのパケットに対して同じであり、テンプレート情報の一部として含まれ得る。これは、ＵＤＰストリーム・パケットがなるであろう長さまで詰めものが埋め込まれたテンプレート・パケットを送信することによって為される。パケットが異なる長さであれば、ＩＰヘッダ・チェックサムは、データリンク層へ送信される前に、各パケットに対して再計算されなければならない。
【００３０】
パケットは、データ・ネットワークを通じた送信のためにデバイス・ドライバ（データリンク層）へ直接送信され、ＵＤＰ／ＩＰスタック１０５をバイパスする。前述のＩＰチェックサムと同様に、パケット毎に長さが異なれば、ＵＤＰチェックサムのみが再計算されなければならない。従って、テンプレートが適用される後続データ１３０は、すべてのパケットに対してＵＤＰ／ＩＰルーティングを実行することをプロセッサに要求することがなく、より迅速に処理され得る。ここで図２に戻る。パケット７４のオーバーヘッド・セクション７０は、ＩＰスタックを通るようにテンプレート・パケットをルーティングさせることによって生成することができ、パケット７５〜７７のオーバーヘッド・セクション７０は、パケット７５〜７７のそれぞれをＩＰスタックを通るようにルーティングさせることなく、テンプレートを適用することによって生成することができる。
【００３１】
すべての後続パケットはこのように処理され、ＵＤＰ／ＩＰスタック１０５をバイパスする。ＶｏＩＰシナリオにおける新しい呼の開始時などに、各ＵＤＰストリームのそれぞれに対して新しいテンプレートが生成される。テンプレートのルーティング情報が変更される必要があることはめったにない。なぜなら、パケット・ストリームのルーティングは固定的となる傾向にあるからである。しかし、ルートがより頻繁に変更するネットワークにおいては、ルート変更に対応するために、Ｎパケット毎に新しいテンプレート・パケットが生成されるように上記技術を適応させることも可能である。Ｎの値は、特定のネットワークに対して可能な限り大きくなるように選ばれる。ほとんどのアプリケーションにおいて、ルーティングが変更されることは稀であり、テンプレート情報は、データ・ネットワークを超えるルート上の第一のルータ２５が変更された場合のみ、変更する必要がある。
【００３２】
以下は、ＵＤＰ／ＩＰ環境においてテンプレートを作成する処理の擬似コードの説明である。ソケット側及びデータリンク側の２つの部分が存在する。
【００３３】
ソケット側：１．データを宛先に送信するために、ソケットを通常通り作成する。
２．前述のテンプレート構造の対してメモリ空間を割り当て、固有識別子を初期化する。
３．テンプレートがリンク層によって作成された場合に示される手旗信号を作成し、テンプレート構造内へデータを埋め込む。
４．テンプレート構造へのポインタであるデータを有するソケット用の書き込み機能を呼び出す。あなたが作成中のテンプレートのためのデータ・ストリームが固定長であれば、例えばすべてのパケットがＸバイト長である場合にソケットにポインタ値及び（ポイント・サイズＸである）パッド・バイトを書き込むように、ソケットに正しい長さを書き込ませるために十分なパッド・データをソケットに書き込む。パッド・バイトの値は重要ではない。これは、パケット長がＵＤＰ最大パケットサイズ未満である場合のみ機能する。
５．手旗信号を待機。
６．リンク層が手旗信号を与えると、テンプレート構造の残りのフィールドがリンク層によって満たされ、このテンプレートは使用可能な状態となる。
７．すべての更なるデータ・パケットは、ドライバ送信機能を用いることによって、テンプレート構造からリンク層（１１０）へ直接送信される。
【００３４】
リンク層側：１．最初の（ポインタ・サイズ）バイトがテンプレート構造ポインタであると仮定することによって、返されたポインタ値を参照するのを止めることによって、それがテンプレート・パケットであるか否かを判断するために、パケットをチェックする。参照を止める前に、それが妥当なメモリ範囲にあることを確認するためにポインタのレンジをチェックする。それが妥当なテンプレート・パケットであるかを判断するために固有識別子をチェックする。
２．テンプレート・パケットでない場合、通常通りに送信する。
３．テンプレート・パケットである場合、テンプレート構造をパケット・ヘッダ・コンテンツ及び長さで満たす。ドライバ送信機能及びパラメータをこのデバイス・ドライバ（リンク層）に関する詳細で満たす。
４．テンプレート構造が使用可能な状態になったことをソケット層へ伝えるための手旗信号を与える。
５．データ・パケットに関連付けられたメモリを開放する。これで、すべての関連データがテンプレート構造内に記録された状態となる。
【００３５】
図８乃至１０は、より効率的にパケットを処理する方法及び装置を示す。
【００３６】
ＩＰゲートウェイによって運ばれるトラフィックは、２つの種類：音声トラフィックなどのリアルタイムを運ぶリアルタイム転送プロトコル（ＲＴＰ）パケット、及び例えばシグナリングを運ぶ非ＲＴＰパケット、に分けることができる。
【００３７】
ＩＰ電話ゲートウェイについて、９９％を超えるパケットは、音声トラフィックを運ぶＲＴＰパケットである。これは、パケットをリアルタイムに組み立てるために、プロセッサに面倒な要求を掛ける。非圧縮Ｇ．７１１音声トラフィックをパケット毎に１０ミリ秒の音声ペイロードで３２チャネル設けることによって、毎秒３２００パケットの送信パケット及び受信パケットをそれぞれ作成することができる。Ｗｉｎｄ  Ｒｉｖｅｒ  ＳｙｔｅｍｓからのＶｘＷｏｒｋｓＴＭなどのリアルタイム・オペレーティング・システムのルーティング・ソフトウェアを用いると、Ｉｎｔｅｌ  ４８６ＤＸ１００などの非常に処理能力の高いプロセッサを用いたとしても、パケットを送信するためのリアルタイム量の半分は、パケットをＵＤＰ／ＩＰ／イーサネット（登録商標）・スタックを通るように転送することに占められる。チャネル容量をより大きくスケールアップするには、処理能力が高く、高価なプロセッサが必要となる。
【００３８】
しかし、パケットのほとんどはＲＴＰパケットであるため、前述のテンプレート・パケット技術を用いることによって大幅な節約が可能となる。前述のようにテンプレート・パケットを用いることによって処理要求を簡素化することに加えて、上記テンプレート・メカニズムを用いることによって、ＵＤＰストリーム・パケット処理の負荷を減らし、主ＣＰＵをテンプレートをデータ・ストリームに適用する役割に最適化された低価格のコプロセッサへ変えることができるという別の利点も得ることができる。このアーキテクチャは、２つのプロセッサを有する。
【００３９】
第一のプロセッサ（パケット・プロセッサ３２０）は、ＲＴＰパケットの処理を扱うことに最適化されている。このプロセッサは、ＦＰＧＡ（ｆｉｅｌｓ  ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙ）でもよく、ＭｏｔｏｒｏｌａＴＭからのＰｏｗｅｒ  ＱＵＩＣＣなどのエンペデッド・システム・コントローラへコプロセッサとしてしばしば提供されるマイクロＲＩＳＣプロセッサでもよく、その他の装置でもよい。
【００４０】
第二のプロセッサは、他のすべてのパケット、すなわち非ＲＴＰパケット及びテンプレート・パケットの処理と、他のアプリケーション・コードの起動とを扱う。この第二のプロセッサは、ＩｎｔｅｌＴＭ４８６若しくはＰｅｎｔｉｕｍＴＭプロセッサなどのＣＰＵでもよい。
【００４１】
縮小命令セット（ＲＩＳＣ）プロセッサ若しくはＦＰＧＡ装置は、完全なＣＰＵと比べて縮小された機能しか持たないが、完全なＣＰＵと比べて大幅にコストが安い。
【００４２】
ここで、上記技術を図８及び９を参照して詳述する。図８は、送信のためのパケット処理に含まれる工程を示す。最初に、ユーザからの呼リクエストへの応答として、呼がセットアップされる（工程２００）。これは、通常、ＴＣＰ／ＩＰシグナリングを用いて達成される。この呼が音声トラフィックなどのリアルタイム・データを運ぶものである場合、この発信元と固定された宛先との間にＵＤＰ／ＩＰパケット・ストリームが生成される。すなわち、該ストリーム内のすべてのパケットは同じ宛先へ向かい、従って同じオーバーヘッド情報を運ぶ。ＣＰＵは、テンプレート・パケットをＵＤＰ／ＩＰスタックを通るようにルーティングさせ、後続パケットによって用いられるテンプレートを生成する（工程２１０）。このテンプレートは、パケット・プロセッサへ送信される（工程２２０）。このパケット・プロセッサは、テンプレートを受信し、リアルタイム・データを受信するのに備え、該データを処理するためにＤＳＰチャネルをセットアップする（工程２４０）。リアルタイム・データは、ＤＳＰへ送信される（工程２４５）。次いで、ＤＳＰは、該データを処理し（工程２５０）、その後、処理されたデータをパケット・プロセッサへ送信する（工程２６０）。パケット・プロセッサは、このテンプレートを処理済データの各バッチへ適用してＵＤＰ／ＩＰを形成し（工程２７０）、次いで、このパケットをイーサネット・コントローラを通じてデータ・ネットワークへ送信する（工程２８０）。ＵＤＰ／ＩＰパケットは、ＣＰＵによる処理無しに、該ネットワークへ直接送信される。ＣＰＵは、一旦テンプレートが作成されれば、ＲＴＰパケットの送信にはかかわらないのが好ましい。但し、ＳＲＡＭバッファのメンテナンス若しくは統計の収集はＣＰＵによって為されてもよい。ＣＰＵによって為されなければならない作業量は、自立的に機能するパケット・プロセッサの能力に依存する。ＣＰＵは、パケット・プロセッサの最終的な制御を有する。なぜなら、シグナリングとＵＤＰストリームを処理する制御部とを取り扱うからである。
【００４３】
ここで、図１０を参照して、受信パケットの処理方法を説明する。前と同様に、通常はＴＣＰ／ＩＰシグナリングを用いて、発信元エンティティとこの受信エンティティとの間に呼がセットアップされる（工程４００）。ＣＰＵは、ＵＤＰポート番号と対応するＤＳＰチャネル情報とをパケット・プロセッサへ送信する（工程４１０）。到来ＩＰパケットは、イーサネット・コントローラによって、データ・ネットワークから受信される（工程４２０）。このイーサネット・コントローラは、パケットをパケット・プロセッサのスタティックＲＡＭ３２５へ直接ＤＭＡ（ｄｉｒｅｃｔ  ｍｅｍｏｒｙ  ａｃｃｅｓｓ）転送する。パケット・プロセッサは、受信パケットのパケット種類（工程４３０）及びポート番号（工程４３５）を検査する。ＲＴＰパケットからのデータは、例えば解凍などの処理のためにＤＳＰ装置へ送信される（工程４４０）。ＣＰＵによって供給されるポート番号は、パケット・プロセッサが使用するＤＳＰチャネルを決定し得る。パケット・プロセッサがパケット種類がＵＤＰでないと判断した場合、又は、ポート番号が非ＲＴＰポートであった場合、そのパケットは通常処理のためにＣＰＵへ送信される。パケット・プロセッサの容量に応じて、ＲＴＰパケットについて、パケット・プロセッサは、ＣＰＵへ信号を送り、該到来パケットによって使われているＳＲＡＭバッファを開放させる。或いは、自身を再使用するためにそれらを開放してもよい。
【００４４】
パケット・プロセッサ３２０は、アプリケーションの要求に応じて、複雑なものとしてもよく、簡易なものとしてもよい。例えば、ＦＰＧＡは主ＣＰＵから一部補助を受けるだけで十分な場合もあれば、パケット・プロセッサはそれ自体が完璧なＣＰＵである場合もある。この差は、システムによって処理されることが要求される毎秒あたりのパケット数と、主ＣＰＵが実行しなければならない余剰作業量とに帰因する。
【符号の説明】
【００４５】
１０、１１  端末
１２  ディジタル回線カード（ＤＬＣ）
１５  時分割多重（ＴＤＭ）内部バス
１６  コンピュータ端末
２０、４０  ゲートウェイ・カード
２５、２６  ルータ
３０  データ・ネットワーク
５０  ＰＳＴＮ／構内交換網
６１  ＵＤＰヘッダ
６２  ＩＰヘッダ
６３  データリンク層ヘッダ
６４  ＵＤＰチェックサム
７０  オーバーヘッド
７２  ペイロード
７４〜７７  パケット・ストリーム
１００  ＵＤＰソケット
１０５  ＵＤＰ／ＩＰルーティング・スタック
１１０  データリンク層
１２０  テンプレート・ソケット
３００  ＴＤＭインターフェース
３０５  ＤＳＰアレイ
３２０  パケット・プロセッサ
３２５  スタティックＲＡＭ
【図１】
2010233240.tif 000003
【図２】
2010233240.tif 000004
【図３】
2010233240.tif 000005
【図４】
2010233240.tif 000006
【図５】
2010233240.tif 000007
【図６】
2010233240.tif 000008
【図７】
2010233240.tif 000009
【図８】
2010233240.tif 000010
【図９】
2010233240.tif 000011
【図１０】
2010233240.tif 000012