JPH11509384A - 分散処理による通信アクセス・システム - Google Patents

Abstract

(57)【要約】 複数の計算プラットホームの間でプロトコル処理を分散するための方法および機器。遠隔アクセス・デバイス、通信サーバ、端末サーバ、およびダイヤル呼び出しルータなどのデータ通信装置(10)は、さまざまな計算環境に対して単独ユーザ通信アクセスまたは大規模複数ユーザ通信アクセスを提供する。このようなアクセス装置を提供することの設備費およびレベル性能は、希望の数のシリアル通信リンクをサポートするために必要とされるCPU処理能力およびメモリの量に関係する。完全に同じ処理機械に成端するプロトコルを使用するのが一般的である。本発明は、モデム(m)のようなデバイスを含み、おもにプロトコル処理アクセス複数計算プラットホームを分散することによってこれらのシリアル・リンクをサポートする通信装置のコスト／パフォーマンスを高めるために開発された方法を含む。

Description

【発明の詳細な説明】 分散処理による通信アクセス・システム 著作権に関する注意 本特許文書の開示の一部分には、著作権保護の対象となる事柄が含まれる。こ の特許開示は特許商標局ファイルおよび記録に記載されているため、著作権所有 者は、いかなる人物によるそのファクシミリ複製にも異議を唱えないが、それ以 外にはいずれにせよ全著作権を保留する。 発明の背景 本発明は、概して電気通信の分野およびそれによって電話の呼び出しが電話回 線またはその他の通信リンクからコンピュータ・システムの内外に切り替えられ るプロセスに関する。本発明は、特に、大量の呼び出しが同時にコンピュータ・ システムの内外に送られる環境での使用に適している。 本明細書中に開示される方法は、いわゆる「ネットワーク・アクセス・サーバ 」と呼ばれる通信装置の1要素により実行できる。ネットワーク・アクセス・サ ーバとは、着信呼び出しを受け取り、それらをネットワークを経由して任意のコ ンピュータ・システムに送るデバイス、またはネットワークから呼び出しを受け 取り、それらを通信リンクに送るデバイスのことである。我々の分散処理発明で は、呼び出し経路選択プロセスの効率の飛躍的な 上昇が達成され、それにより呼び出し処理効率を最大限にし、総体的な呼び出し 接続時間を最小限に抑える。この成果は、ネットワーク・アクセス・サーバのモ デムのような複数の計算プラットホーム間で（ポイント・トゥー・ポイント・プ ロトコル、つまりPPP処理のような）集約型プロトコル処理をコンピュータの使 用により分散することにより達成される。 ルータ、端末サーバ、および「ゲートウェイ・カード」と呼ばれることもある モジュールのような、さまざまな種類の通信デバイスが、モデムとコンピュータ ・ネットワークの間のインターフェースに配置される。これらのデバイスは、モ デムとネットワークの間の呼び出しの流入および流出を制御するソフトウェア・ プログラムを実装する。これらのデバイス内で実行されるソフトウェア階層の１ つの層は、その技術で「アプリケーション層」として知られている。本明細書で は、用語「アプリケーション」、「アプリケーション層」および「アプリケーシ ョン・ソフトウェア層」を頻繁に参照する。本明細書中で使用されるように、以 上の用語は、通信デバイス内のプロトコル・スタックの上にある通信制御管理ソ フトウェア層を意味し、デバイスは通常モデムとコンピュータ・ネットワークの 間のゲートウェイ（つまりインターフェース）に配置される。 本発明の譲り請け人である、イリノイ州、Ｓｋｏｋｉｅの米国ロボティックス によって開発されたV.34クワッド ・モデムのような最新式のモデムは、2つのプロトコルがモデム内で実現される という機能を備える。最初のプロトコルは、ポイント・トゥー・ポイント・プロ トコル(PPP)の非同期ハイ・レベル・データ・リンク制御手順(HDLC)フレーム指 示の修正バージョンである。プロトコルは、他のインプリメンテーションでは、 PPPの同期HDLCフレーム指示となる場合がある。モデムは、各PPPフレームで、フ ラグ・シーケンス、データ・トランスペアレンシー、およびフレーム検査文字列 (FCS)を実行する。モデムで実行される第2のプロトコルが、シリアル・ライン・ インターネット・プロトコル(SLIP)である。 従来の技術では、ネットワーク・アクセス・サーバ・ゲートウェイにあるアプ リケーション・ソフトウェア・ルーチンはPPP（またはSLIP）フレームを作成す ると、制御文字であるバイトを探して各バイトを検査する。アプリケーションが 制御文字を検出すると、PPPエスケープ文字（またはSLIPエスケープ文字）がデ ータ・ストリームに詰め込まれる。それから、元の制御文字がトランスペアレン トな文字に変換され、データ・ストリームに詰め込まれる。通常、余分な文字が 追加されるため、これには２つのバッファが必要となる。PPPフレームの場合、 アプリケーションはフレームの各バイトを検討する間に、FCSも計算しなければ ならない。アプリケーションは、PPP（またはSLIP）フレームを受け取ると、前 記プロセスの逆を実行しなければならない。U.S.ロボティックスのNE TServerのようないくつかのネットワーク・アクセス・サーバでは、最高60台の モデムが、任意の一時点でアクティブとなることができる。つまり、従来の技法 が使用されるならば、ネットワーク・アクセス・サーバ内のゲートウェイ計算プ ラットホームが60台のモデムの一つ一つに対しこのプロセスを実行するだろう。 この結果、1つの計算プラットホームに課される処理負荷はきわめて高くなり、 呼び出し経路選択プロセスで待ち時間および遅延が生じる。特に、大量の呼び出 しが同時に受信されたり、ネットワーク・アクセス・サーバを通して伝送される 場合に、これらの影響が重なり合って呼び出しの処理効率を大幅に引き下げる。 従来の技術による呼び出しの処理効率を上昇させる1つのアプローチは、Cirru s Logic CL-CD 2430/CD2431デバイスのような通信制御装置ハードウェアをプロ トコル処理回路に取り込むことであった。本発明は、ネットワーク・アクセス・ サーバに対応するモデム内のプロセッサのような、既存の計算プラットホーム内 でのプロトコル処理の実行を可能にすることにより、このような高価なハードウ ェア・デバイスに対するニーズを排除する。 発明の要約 本発明は、コンピュータ・システムの内外に着信呼び出しまたは発信呼び出し を送るための方法である。着信呼び出しの場合、方法は、着信呼び出しを受け取 り、呼び出しを複数のモデムに送るステップ、複数の計算プラットホームの間で 着信呼び出しのプロトコルの処理を分散するステップ、着信呼び出しのプロトコ ルを処理するステップ、およびその後でネットワーク上のコンピュータ・システ ムに着信呼び出しを送るステップから構成される。発信呼び出しの場合、呼び出 しは、ネットワークからネットワーク・アクセス・サーバ内の複数のモデムに送 られ、プロトコル処理を複数の計算プラットホームで分散し、呼び出しをT1電話 回線のような通信リンクに送出する。 本発明の実施例では、方法は、複数の着信呼び出しを受け取ったり、複数の呼 び出しを通信リンク上に変調するための複数のモデムを備えるネットワーク・ア クセス・サーバの中で実行される。計算プラットホームは、各モデムのデータ処 理構造を具備する。 本発明のもう一つの面とは、呼び出しをモデムを介して任意のコンピュータ・ システムに送るための方法であり、モデムで着信呼び出しを受け取るステップと 、モデム内の計算プラットホームで着信呼び出しのプロトコルの処理を実行する ステップと、着信呼び出しをコンピュータ・システムに送るすステップとから構 成される。本実施 例では、モデムをプロトコル処理のための計算プラットホームとして使用するこ とにより、(ルータ内の計算プラットホームのような)モデムとコンピュータ・シ ステムの間のインターフェースにある計算プラットホームが、プロトコル処理の 負担から解放され、呼び出し経路選択プロセスの待ち時間が削減され、総体的な 呼び出し接続時間が削減される。 図面の簡単な説明 本発明の現在好ましい実施例は、類似した参照番号がさまざまな図中の同様の 要素を指す図面に描かれる。 図1Aは、本発明を実装できる1つの形式を図解するブロック図である。 図1Bは、ホスト・コンピュータのオペレーティング・システム・ソフトウェア 内での図1Aの送り機能の実施例を図解するブロック図である。 図2は、本発明の代替形式が実装される総合的な通信システムの図であり、さ まざまな呼び出し発信者、電話網、ネットワーク・アクセス・サーバ、およびネ ットワークを経由してネットワーク・アクセス・サーバにリンクされるホスト・ コンピュータ・システムの間の関係性を説明する。 図3は、図1のネットワーク・アクセス・サーバの概要ブロック図である。 図4は、図3のアプリケーション・モジュールとモデム・モジュールの接続を示 す概要ブロック図である。 図5は、図3に図示されるクワッド・モデム・モジュールの好ましい形式の詳細 なブロック図であり、本発明に従った分散処理は、モデム・モジュール処理装置 によって実行される。 図6は、分散処理手順のフローチャートである。 図7は、図6のPPPルーチンの詳細なフローチャートである。 図8は、PPPプロトコル・ネットワーク・ゲートウェイの1つのプラットホーム での従来の技術によるコンピュータ使用によるアップロード・処理効率のグラフ である。 図9は、本発明の教示に従った分散処理技法が使用される場合のアップロード ・処理効率のグラフである。 図10は、PPP処理が、ネットワーク・ゲートウェイでの1つのプラットホームの 従来の技術による技法に従って実行される場合のダウンロード・処理効率のグラ フである。 図11は、本発明の教示に従った分散処理技法が使用される場合のダウンロード ・処理効率のグラフである。 好ましい実施例の詳細な説明 Ｉ．概略説明 図1Aを参照すると、本発明は、呼び出しがコンピュータから発せられる通信シ ステムに実装することができる。例えば(モデムMのような)データ通信装置(DCE) を介して電話網50へデータを送信するＰＣ２０や、あるいはモデムのような受信 側ＤＣＥ１０に接続する別の通信のようなものである。発信呼び出しデータ端末 20には、PPPやSLIPのような通信プロトコルを使用する通信ソフトウェアが備え られる。ＤＥＣ１０は、パーソナル・コンピュータ２０からの呼び出しを復調し 、それを、例えばＲＳ232ケーブルやパケット・バスのような伝送手段11上でル ータまたは端末サーバ12に渡す。ルータまたは端末サーバ12は、ネットワークま たは例えばパーソナル・コンピュータ（図1Aには図示されていない）のようなホ スト・コンピュータ・システムに呼び出しを渡す。予想着信通話量に応じて、最 高n台のＤＣＥ１０を具備できる。また、DCE、つまりモデム10が1台だけ必要と なるアプリケーションもある。DCE10およびルータ12の機能は、物理的に別個の ハードウェア内で実装されるか、あるいは図2に関係して説明されるネットワー ク・アクセス・サーバの場合のように1台の装置に結合することもできる。 本発明の好ましい形式では、PPP（またはSLIP）プロトコルによって要求され るバイト対バイトのトランスペアレンシー変換処理が、従来の技術でのように、 ルータや 端末サーバ12の計算プラットホームで実行されるのではなく、むしろDCE10プロ セッサに分散される。このため、(ルータまたは端末サーバ12での計算プラット ホームのような)アプリケーション・プラットホームが、この時間がかかるタス クから解放される。モデム10プロセッサは、データをモデムのデータ・ポンプと 受け渡すときに、すでに、バイト単位のプロセスでデータを処理している。デー タ・トランスペアレンシーおよびFCS計算という追加タスクは、マルチ・セッシ ョン・アプリケーションの場合ほどわずらわしくなく、したがって、モデム・プ ロセッサは、その中で本発明を実装するための好ましい計算プラットホームであ る。 本発明の好ましい形式では、ネットワーク・インターフェースにあるアプリケ ーション・ソフトウェア・プロセッサは、パケット・バスを介してモデム10と通 信するが、通信はRS232ケーブルのようなその他の同等な手段によっても可能だ ろう。2種類のメッセージがそれらの間で受け渡され、要求および応答、ならび にデータを構成する。それ以外のメッセージ種類は、現在、この実施例には適用 できない。すべてのメッセージには、ステータス・フィールドおよび長さフィー ルドが設定される。パケット・バス・データ・メッセージごとに正確に1つのPPP またはSLIPフレームが送信または受信される。長さフィールドは、未変換のデー タ・バイトの正確な数を保持する。これにより、モデムは、発信フレーム上のフ ラグ・シー ケンスをどこに挿入するのかを理解するのである。 PPP／SLIPモデム10の基本的な設計は、モデムをPPPモードにするか、SLIPモー ドにするか、あるいはどちらにもしないモデム10に、特別なコマンドを発行する ためのルータ／端末サーバ12でのゲートウェイ・アプリケーション・ソフトウェ ア用である。発行可能な他の構成コマンドには、以下が含まれる。ローカル非同 期制御文字マップ、遠隔非同期文字マップ、ローカル削除文字変換（つまり、AS CII 7F、16進）、遠隔削除文字変換、最大フレーム・サイズ、フレーム・タイム アウト、文字間タイムアウト、FCSタイプ（例えば、CCITT 16ビットCRC）。モデ ム10は、アプリケーション・ソフトウェアに、それがいつ無事に構成されるのか を知らせる。 モデム10は遠隔PC20への伝送のためにデータ・メッセージをアプリケーション 層から受け取ると、モデム10は、長さフィールドからのメッセージの中にどれほ どのデータがあるのかを理解している。それから、モデムは、フレーム終了文字 を伝送してデータを伝送し(必要に応じて変換し)、それがPPPフレームであるな らFCSを計算して伝送してから、別のフレーム終了文字を伝送することによって 、PPPまたはSLIPフレームを作成する。モデムはデータを解釈しないので、PPPア ドレスおよび制御フィールドが、モデムに渡されるときにPPPデータにプリペン ド（prepended）されなければならないことに注意する。 モデム10がPPPまたはSLIPフレームを遠隔位置から受け 取ると、モデム10は、フレーム文字（またはフレーム終了文字でもある）の始ま りを検索する。この文字は廃棄される。それから、モデムは、トレーリング・フ レーム終了文字を探す一方で、データの各着信バイトを検査し、トランスペアレ ント・データを必要に応じて変換し、それがPPPフレームである場合には現在のF CSを保存する。トレーリング・フレーム終了文字も廃棄される。モデムがPPP用 に構成されている場合、現在のFCS値は、有効であることが確認され、FCS文字で ある最後の2(または4)文字も破棄される（つまり、長さが減分される）。(PPPの 場合にはアドレス・フィールドおよび制御フィールドによってプリペンドされる )未処理データから成るこのフレームは、RS232ケーブルのような、パケット・バ スまたは同等な手段を介して、ただちにゲートウェイ内のアプリケーション層に 渡される。ステータス値は、OK、無効FCS、フレーム大きすぎる、文字間タイム アウト、フレーム・タイムアウト、およびパリティ・エラーを示す(フレーム打 ち切りは廃棄され、アプリケーション層は知らされない)。 本発明の技法を使用すると、ネットワーク・インターフェースにあるアプリケ ーション・計算プラットホームが決してトランスペアレント・データを目にしな いことに注意する。アプリケーション・計算プラットホームは、PPPまたはSLIP フレーム内の実際の情報を処理する。また、モデムがPPPやSLIPフレームの内容 を解釈しないことにも 注意する。モデムは、シリアル・リンク上でデータグラムのもっとも基本的なカ プセル化、つまりバイト単位のトランスペアレンシー変換およびFCSを行うだけ である。PPPアドレス・フィールドおよび制御フィールド、ならびにLCPまたはIP CPのような交渉は、アプリケーション・ソフトウェア層で処理される。したがっ て、本発明の技法を使用すると、モデム10およびルータ／端末サーバ12を経由す るアップロードおよびダウンロードの両方のデータ・処理効率が大幅に改善され る。この結果、ゲートウェイ計算プラットホームでの処理要件が削減され、シス テムの総体的な待ち時間が減少する。 図1Aを再び参照すると、モデム10の他にも、それ以外の類似した機能上同等の DCEが本発明に従って使用できることが理解されるだろう。例えば、DSU（データ ・シンクロナイザー装置）およびCSU（回線交換装置）のようなその他の種類の モデムが、デジタル・データ・ネットワーク50とともに使用できる。呼び出しが ISDN回線を経由して入信する場合には、ISDN（デジタル総合サービス網）端末ア ダプタも使用できる。請求項中の用語「モデム」は、このようなすべての機能上 同等なデバイスを含むとして広義に解釈されることが意図されている。 図1Bを参照すると、ルータまたは端末サーバ12の物理的な位置は、特に重要で はないことが理解されるだろう。例えば、ルータ機能が、マイクロソフト社のWi ndows^TMプログラムの多様なバージョンなど、パーソナル・コン ピュータの任意のオペレーティング・システム14内のソフトウェア機能として存 在する場合がある。この例では、プロトコル処理は、モデム10で実行される。プ ロトコル処理を、コンピュータのCPU内ではなくモデム10内の計算プラットホー ムに分散するおかげで、CPUに対する計算負荷および呼び出し経路選択プロセス の待ち時間は削減され、呼び出し処理効率が上昇する。 さらに、呼び出しをモデムからゲートウェイに伝送するための特定な手段は、 特に重要ではない。RS232ケーブル、パケット・バス、または（ISA、EISA、PCI またはVESAバスのような）ホスト・パーソナル・コンピュータの内部バスも使用 できる。 II．好ましいネットワーク・アクセス・サーバの実施例 本発明は、図2に一般的に描かれる通信処理システムで実現される。複数の呼 び出し発信者20、22および24は、着信通信をネットワーク・アクセス・サーバ30 に伝送する、さまざまな遠隔位置に位置する。呼び出し発信者20、22および24は 、デジタル・データを作成し、そのデータを、それぞれ電話回線40、42、および 44上に変調するモデムM1、M2、およびM3に伝送する、それぞれパーソナル・コン ピュータC1、C2、およびC3から構成される場合がある。本明細書の目的のため、 特定の種類の呼び出し発信者は重要ではなく、図2の呼び出し発信者が図解のた め だけに選択される。呼び出し発信者は、PPPまたはSLIPプロトコルを使用する通 信ソフトウェアを所有する。 図２では、40、42、および44にある電話回線に伝送されるデータはアナログ形 式である。図2では、通信システムがT1ネットワークのようなデジタル公衆加入 電話網(PSTN)50を利用すると仮定される。呼び出し発信者からの呼び出しは、デ ジタル化され、電話会社によって4線式T1スパン回線の24の多重化されたチャネ ルの内の1つに入れられ、ネットワーク・アクセス・サーバ30に供給される。本 明細書中で使用されるように、用語T1スパン回線とは、1.544 Mbps DS1速度で多 重化される24の64 Kbps(毎秒1000ビット)DSOチャネルを指し、各DSOチャネルは 、アナログ音声チャネルのデジタル表記を搬送する。本明細書に使用されるよう に、用語「中継線」とは、1つの単独のDSOチャネルを指す。 着信通信を表すデジタル信号は、T1スパン回線51（またはおそらく2本のスパ ン回線）によってネットワーク・アクセス・サーバに供給される。それから、ネ ットワーク・アクセス・サーバは、着信呼び出しをネットワーク52に送る。ネッ トワークは、トークン・リング・ネットワーク、イーサネット、またはそれ以外 の種類のネットワークであってもよく、その特定の詳細は重要ではない。次に、 図2に描かれるホスト・コンピュータ・システム60は、パーソナル・コンピュー タC4、データ記憶装置端末C5、およびメインフレーム・コンピュータC3のような さ まざまなコンピュータから構成される。呼び出し発信者20、22および24の場合と 同様に、ホスト・コンピュータ・システム60およびその構成要素部品の詳細は特 に重要ではない。ホスト・コンピュータ・システム60には、ネットワーク・アク セス・サーバ30を介して（呼び出し発信者20のような）遠隔データ端末に呼び出 しを送出する機能がある。 今度は図3を参照すると、ネットワーク・アクセス・サーバ30は、機能ブロッ ク図形式で示され、詳細に記述される。ネットワーク・アクセス・サーバ30は、 T1スパン回線51で着信呼び出しを受け取り、呼び出しを多重分離し、呼び出しを 高速時分割多重バス・コンプレックス74上で12のクワッド・モデム・モジュール 76A、76Bなどに送る電話インターフェース装置72を収容するシャーシ70を備える 。各モデム・モジュール76には、着信呼び出しを復調する4台のモデム（図３に は図示されていない）が備えられる。したがって、ネットワーク・アクセス・サ ーバ30に着信する2本のT1スパン回線51がある場合、ネットワーク・アクセス・ サーバ30に着信する48のDSOチャネルには全部で48のモデムがある。TDMバス・コ ンプレックス上での電話インターフェース装置とモデムの間の接続は、静的、つ まり「ネールドアップ」接続であり、ネットワーク・アクセス・サーバ30のパワ ーアップ時に確立される。TDMバス・コンプレックス74は、データを、ネットワ ーク・アクセス・サーバ30のさまざまなモジュール のすべての間であちこちに搬送する。バス・コンプレックス74は、以下に詳説さ れる。 各モデム・モジュール76には、対応するモデム・ネットワーク・インターフェ ース・モジュール78A、78Bなどが具備される。モデム・ネットワーク・インター フェースモジュール78には、同期／非同期RS232ポート80が備えられる。RS232ポ ート80は、ホスト・コンピュータ・システムのコンピュータにリンクされ、ネッ トワーク・アクセス・サーバ30からホスト・コンピュータに呼び出しを出力する ために使用できる（その用語が本明細書中で使用されるように「ネットワーク」 52として動作する）。 ネットワーク・アクセス・サーバ30には、ネットワーク・アクセス・サーバ30 の動作を支配するソフトウェアとホスト・コンピュータ・システムのソフトウェ アとの間でインターフェースとして機能するゲートウェイ・アプリケーション・ モジュール82も具備される。ゲートウェイ・アプリケーション・モジュール82は 、呼び出しが同期であるか、非同期であるかに関係なく、モデム・モジュール76 内のモデムに対し、着信呼び出しのためにどの変調機構を使用するのか、および どのエラー訂正プロトコルに従うのかを教える。また、ゲートウェイ・アプリケ ーション・モジュール82は、モデムに対し、呼び出しをRS232ポート80に送り出 すのかどうか、または呼び出しをネットワーク52とホスト・コンピュータ・シス テム60に対し送信するのかどうかも教える。ゲートウェイ・ アプリケーション・モジュール82には、当業者がその詳細を熟知しており、特に 本明細書では重要ではない、適当なデータ・プロセッサ、メモリおよびそれ以外 のハードウェアが具備される。着信呼び出しインターフェース内のすべてのモジ ュールに電力を供給する電源モジュール88も、シャーシ70に搭載される。電源モ ジュールは、acからdcへ電力変換を実行する2つの電源装置から構成され、装置 の内の一方が故障した場合に完全な冗長性を実現する。モジュール88内の電源装 置は、標準的な方法論に従って設計される。高速冷却ファン90が、ネットワーク ・アクセス・サーバの動作中に電力の供給によって発生する熱を消散させるため に、シャーシ70に具備される。電源オン／オフ・スイッチ（図示されていない） は、装置30全体をオンとオフにするために具備される。 シャーシ70は、標準型19インチのカードケージであり、16枚の前面装填アプリ ケーション・カードおよび16枚の背面装填インターフェース・カード、ネットワ ーク管理モジュールおよび関連インターフェース・モジュールを提供する。 A．電話インターフェース装置72 図3の電話インターフェース装置は、着信呼び出しインターフェース・モジュ ール105と着信呼び出しアプリケーション・モジュール175の2台の別個のモジュ ールから構成される。インターフェース・モジュール105は、着信T 1スパン回線を物理的に受け入れ、デジタルTTL形式の信号を変換し、信号を呼び 出しアプリケーション・モジュール175に送達することを目的とする。インター フェースモジュール105は、クロック信号およびデータを着信T1信号から受け取 るCSUインターフェースを提供するだけではなく、回線T1へのデジタル・データ を表す発信デジタル電話信号の伝送を実現する。モジュール105は、バックプレ ーン・コネクタを介してアプリケーション・モジュール175に接続される。アプ リケーション・モジュール175は、T1 DSOチャネル・データを抽出するために、 復旧されたT1データのフレーム指示を提供してから、チャネル・データをTDMバ ス74を介してモデム・モジュールに切り替える。 時分割多重(TDM)バス・コンプレックス74が、フレーム同期回線、時間スロッ ト(TS)クロック回線、ビット・クロック回線および2本のデータ・ハイウェイ回 線が具備することが理解されるだろう。パケット・バスも、ネットワーク・アク セス・サーバ30の間の通信を伝送するために具備される。 図4に図示されるように、データは、データ・ハイウェイ回線156、157を介し て、アプリケーション・モジュール175（図3）の送信(TD)端子からクワッド・モ デム（例えば76Ａが76Ｂ）の内の1つの受信端子(RD)に、あるいはその逆に、直 接書き込まれる。 B．モデム・モジュール76と78の詳細な説明 図5は、ネットワーク・アクセス・サーバのその他のモデム・モジュールに同 一の代表的なクワッド・モデム・モジュール76Aを図解する。モデム・モジュー ル76のそれぞれには、合計24のモデムのための4つのモデムが具備される。その 結果、ネットワーク・アクセス・サーバ30は、合計24の同時全二重チャネルのデ ータ通信を処理することができる。2本のT1スパン回線が電話インターフェース 装置72(図3)に入力される場合、48の同時全二重チャネルを処理するために、12 のモデム・モジュールが提供される。言うまでもなく、希望される場合は、追加 容量も提供される。 モデム・モジュール76Aは、出力バス419を通してパケット・バス99を使用して 通信するバス・インターフェース装置414を具備する。ボード制御プロセッサ425 は、バス428、433および435上で通信する。フラッシュROM431は、プロセッサ425 にメモリを提供する。フラッシュROMは、デジタル信号プロセッサ453-456だけで はなく、モデム制御プロセッサ473-476のコードも記憶する。バス・インターフ ェース415は、バス421上でTDMバス74と通信する。 デジタル信号プロセッサ・シリアル・インターフェース論理回路437は、バス4 39上でプロセッサ425と通信し、バス441-444上でそれぞれ個別モデム447-450と 通信する。モデム447-450のそれぞれは同一である。モデムは、バス457-460およ び467-470上で図示される用に接続される、 デジタル信号プロセッサ453-456、特定用途向け集積回路(ASICs)463-466、およ びモデム制御プロセッサ473-476を具備する。プロセッサ473-476は、バス435上 でプロセッサ425と通信する。ASIC463-466は、RS232ポート477-480を提供する。 これらのポートは、モデム・モジュール76B-76Fの同等のポートとともに、デジ タル信号をホスト・コンピュータ・システムに結合するために、モデム・ネット ワーク・インターフェース・モジュール78A-78F(図3)のグループを形成する。モ デム447-450のそれぞれのハードウェアは、実質上、イリノイ州、スコーキーのU .S.ロボティックスによって製造されているUSR Courier Dual Standardモデムに 搭載されるハードウェアと同じである。 ボード制御プロセッサ425は、以下に示す機能を実行する。つまり、パケット の、受信および管理バス（図示されていない）との間の伝送、パケット・バス99 の多重化タスク、モデム・モジュール76A全体のコード集合の制御、およびコー ドのモジュール76A内のモデムへの分散（つまり、ダウンロード）。 インターフェース論理回路437は、以下に示す機能を実行する。つまり、TDMバ ス74へのインターフェースを処理する、時間スロットをカウントする、およびTD Mバス74内で信号を多重分離する。 本発明の実施例での着信呼び出しおよび発信呼び出しのプロトコル処理は、4 台のモデム制御プロセッサ473、47 4、475および476の間で分散される。DSP453およびモデム制御プロセッサ473のデ ータ処理機能およびモデム制御処理機能は、1つの単独デジタル信号プロセッサ にまとめることができる。 図6に図示される回線は、以下の表に示されるように市販されている。 回路 製造メーカーおよびモデル番号 バス・インターフェース414 Xilinx 304 ボード制御プロセッサ425 インテル80C188EB フラッシュROM 431 インテル28F020 DSPシリアル・インターフェース論理回路437 Xilinx 3042 DSP 453-456 テキサス・インスツルメント320C51 ASIC 463-466 U.S.ロボティックス1.016.684 モデム制御プロセッサ473-476 インテル80C188EB III．PPPおよびSLIPプロトコルの分散処理 前記説明を念頭に入れた上で、読者の注意は、本発明の好ましい形式に従った 分散処理手順のフローチャートである図6に喚起される。以下の説明は、本発明 のネットワーク・アクセス・サーバの実施例を参照して行われ、その技術分野の 通常の技能を持った人は、説明が他の考えられる実施例にも適合できることを容 易に理解するだろう。 ステップ200では、呼び出しは、遠隔呼び出し発信者の内の1つから到着する、 またそれ以外には呼び出しはホスト・コンピュータ・システムから遠隔コンピュ ータまたは他のデータ端末に起動される。ステップ202では、呼び出しは、周知 の方法で応答される。ステップ204では、ゲートウェイ・アプリケーション・モ ジュール82(図3)が、着信呼び出しまたは発信呼び出しのプロトコルを判断する 。これは、例えば、呼び出しのポート構成を、呼び出し発信者または呼び出し宛 先の電話番号により、ユーザとの会話またはメニューによって、あるいはユーザ 名およびデータベース・ルックアップによって、データ・ルーチンの自動検出ま たは検査によって、あるいはそれ以外のあらゆる実現されるプロセスによって判 断することにより行われる。 ステップ206では、ゲートウェイ・モジュール82が、モデムのプロトコル・モ ードを構成する。CONFIG1.Sのソフトウェア・ルーチンは、このステップで実現 される。非同期トランスペアレント・プロトコルが実行されると、ステップ214 で、タイムアウト時の転送またはバッファフルコマンドが、モデム・モジュール 76内のモデムに送信される。SLIPプロトコルが使用されると、ステップ210で呼 び出しを受信するために、モデムはトランスペアレンシー文字および変換文字を 削除し、ペイロード（バイト数）またはオーバフロー・エラーをゲートウェイ・ モジュール82に送信する。添付のソフトウェア・リスティン グでは、SLIPRX.Sのルーチンがこのステップで実現される。呼び出しを伝送する ためには、ステップ212で、モデムがトランスペアレンシー変換文字およびSLIP フレーム指示文字を付加する。添付のソフトウェア・リスティングでは、SLIPTX .Sのルーチンが実現される。 PPPプロトコルが使用されると、CONFIG1.S内のルーチンは、ステップ208で実 現される。図6のステップ208は、図7に詳細に示される。今度は図7を参照すると 、ステップ216で、ゲートウェイ・モジュール82が、本明細書中に参考により取 り入れられる、コメント要求：1661標準に明らかにされる命令セットに従ってLC P交渉手順に入る。コメント要求(RFC)1661標準は、インターネット・コミュニテ ィ向けのインターネット基準追跡調査プロトコルを明記する公に入手可能な文書 である。その技術分野の通常の技能を持つ人は、RFC 1661文書を熟知している。 ステップ218では、ゲートウェイ・モジュールが、LCP交渉済みパラメータごと にモデムを構成する。これは、例えば、MTU、TX同期マップ、RX非同期マップの 順序で達成できる。添付のソフトウェア・リスティングでは、CONFIG2.S内のル ーチンがこの手順を記述する。それから、「メッセージ」がネットワーク・アクセ ス・サーバ30を通してアップロードまたはダウンロードされると、手順はステッ プ220でデータ転送段階に入る。受け取るつまりアップロードする方向で、モデ ムは、HDLCフレーム文字を削除し、ペイロード、つまりバイト数および(良FCS、 不良 FCS、オーバラン、または部分的などの)エラー・コードを送信する。この手順は 、添付のソフトウェア・リスティングPPPRX.Sに明らかにされる。 ステップ224の送信(ダウンロード)方向では、モデムはゲートウェイ・モジュ ール82からペイロードを得て、文字トランスペアレンシー変換を実行し、非同期 マップを伝送し、FCSを計算し、HDLCフレーム指示文字を付加する。ステップ226 では、メッセージが電話網51を通して送出される。この手順は、添付のリスティ ングのPPPTX.Sルーチンに明らかにされる。 本発明の優位点を従来の技術に優る処理効率という点で説明する1つの代表的 な例が、図8-図11に示される。図8は、PPPプロトコル・ネットワーク・ゲートウ ェイでの単独プラットホームでの、従来の技術の計算法を使用したアップロード ・処理効率のグラフである。ネットワーク・アクセス・サーバの総処理効率が、 8つのアクティブ・ポートでのピークに到達後も実質上一定したままであり、毎 秒24,000バイトで17のアクティブ・ポートで横ばいになっていることに注意する 。ポートごとの処理効率は、少ない数のアクティブ・ポート（つまり、10を下回 る）の場合、毎秒約4,600バイトできわめて高く開始するが、アクティブ・ポー トの数が増えると、劇的に低下する。したがって、図8は、PPPプロトコル処理が 、ネットワーク・インターフェースにある単独プラットホームで実行される場合 に発生する処理の「ボトルネック」を説明して いる。 図9は、本発明の教示に従った分散処理技法が使用される場合のアップロード ・処理効率のグラフである。図9では、総処理効率が18ポートまで着実に上昇し 、18ポートと21ポートの間でわずかに低下してから、アクティブ・ポートが25の 場合に毎秒約92,000バイトの総処理効率まで上昇することに注意する。アクティ ブ・ポートが25と48の間では、総処理効率は、毎秒約72,000バイトと毎秒86,000 バイトの間にとどまる。これは、図7の結果に比較して約3倍から4倍の総処理効 率である。発明者は、システム・チューニングのさらなる改良により、図9に示 されるシステム・処理効率での振幅が、特にアクティブ・ポートの数がさらに増 加した場合に取り除かれるだろうと予測する。また、本発明の技法を使用するポ ートあたりの平均処理効率が、アクティブ・ポートの数が増加するに従って比較 的高いままとなり、特にアクティブ・ポートの量がさらに多い場合に、図8の結 果と比較して3倍を上回る効率の改善を達成することにも注意する。 図10は、PPP処理が、ネットワーク・ゲートウェイでの単独プラットホームの 従来の技法で実行される場合のダウンロード・処理効率のグラフである。図10で は、従来の技術の技法が使用される場合、総ダウンロード・処理効率が、20以上 のアクティブ・ポートの間で毎秒約55,00バイトで横ばいになることに注意する 。ポートあたりの平均処理効率は、10以下のアクティブ・ポートで毎秒約 45,000バイトで始まるが、この値は、48のアクティブ・ポートが使用される場合 には、毎秒約12,000バイトの低さまで着実に低下する。 図11は、本発明の教示に従った分散処理技法が使用される場合のダウンロード ・処理効率のグラフである。本発明の技法を使用する総ダウンロード・処理効率 が、26のアクティブ・ポートが使用される場合に毎秒約104,000バイトの高さま で着実に上昇し、呼び出しの活動がさらに高いレベルでも比較的一定のままとな ることに注意する。図11を図10に比較することによって理解できるように、これ は呼び出し処理効率におけるかなりの改善である。本発明の技法を使用するポー トあたりの平均処理効率は、22のポートまで毎秒4500バイトで比較的一定したま まとなり、この値は48のポートが使用される場合には毎秒約2000バイトまで徐々 に低下する。これは、特に呼び出しの量が多い場合の、ポートあたりのダウンロ ード・処理効率での約2対1の改善を表す。 図6および図7に示される手順を実現するために現在好ましいソフトウェア・ル ーチンは、以下の符号で明らかにされる。その技術分野の通常の技能を持つ人は 、符号がネットワーク・アクセス・サーバ環境における本発明の実現の1つの例 を表すにすぎないことを理解するだろう。符号は、図3のモデム・モジュール76 のモデム内で記憶され、実行される。モデム・ソフトウェア・ルーチンと対話す るゲートウェイ・モジュール82内のソフトウェア・ ルーチンは、それを使用すればその技術分野の通常の技能を有する人によって容 易に作成される比較的に簡略な高水準制御ルーチンから構成される。 読者は、本明細書中に参考により取り入れられる、前記に明らかにされる著作 権に関する注意に向けられる。 前記詳細な説明から、多くの変化および修正を本発明の真の精神および適用範囲 から逸脱することなく加えることができることが理解されるだろう。この真の精 神および適用範囲は、前記明細書の観点から解釈される添付請求項により定義さ れる。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 ＦＩ Ｈ０４Ｌ 12/66 Ｈ０４Ｌ 13/00 ３０５Ｃ 29/06 11/00 ３１０Ｃ Ｈ０４Ｍ 3/00 (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＬＳ，ＭＷ，ＳＤ，Ｓ Ｚ，ＵＧ)，ＵＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＺ， ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＨＵ，Ｉ Ｌ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＫ ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ， ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，Ｒ Ｕ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＲ ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ (72)発明者 ヴァーマン、リチャード ジェイ. アメリカ合衆国 60010 イリノイ州 デ ィアパーク イースト カンティー ライ ン ロード 132

Claims (1)

1. 【特許請求の範囲】 １．効率的な呼び出し処理効率を達成するために、複数のモデムから構成される システムで実行され、任意のコンピュータ・システムに着信呼び出しを送るため の方法であって、 前記着信呼び出しを受け取り、前記呼び出しを前記複数のモデムに送り、前記 着信呼び出しのプロトコルの処理を複数の計算プラットホームの間で分散するス テップと、 その後に、着信呼び出しを前記コンピュータ・システムにネットワーク上で送 るステップと から成る方法。 ２．前記プロトコルがPPPから構成される請求項1に記載の方法。 ３．前記プロトコルがSLIPから構成されることを特徴とする請求項1に記載の方 法。 ４．前記モデムが、複数の着信呼び出しを実質上同時に処理することができるよ うに配列され、前記プロトコル処理が実質上同時に前記モデムで実行される請求 項1または請求項2または請求項3に記載の方法。 ５．前記処理のステップが、前記複数のモデムの内の少なくとも1つでソフトウ ェアを介して実行される請求項1に記載の方法。 ６．効率的な呼び出し処理効率を達成するためにコンピュータ・システムから通 信リンクに発信呼び出しを送るた めに、複数のモデムから構成されるシステムで実行される方法であって、 ネットワークからの前記発信呼び出しを前記モデムに送るステップと、 前記モデム内の複数の計算プラットホームの間で前記発信呼び出しのプロトコ ルの処理を分散するステップと、 その後に発信呼び出しを前記通信リンクに送るステップと から成る方法。 ７．前記プロトコルがPPPから構成される請求項6に記載の方法。 ８．前記プロトコルがSLIPから構成される請求項6に記載の方法。 ９．前記プロトコル処理が前記モデム内で実質上同時に実行され、前記モデムが 複数の呼び出しを実質上同時に処理できるように配列される請求項6または請求 項7または請求項8に記載の方法。 10．前記処理のステップが、前記複数のモデムの内の少なくとも1つでソフトウ ェアを介して実行される方法。 11．ネットワーク・アクセス・サーバであって、 前記ネットワーク・アクセス・サーバを通信リンクに機能的に接続するインタ ーフェースと、 複数のモデムと、 前記インターフェースからの呼び出しを前記モデムに受け渡すための伝送手段 と、 前記モデムから前記呼び出しを受け取り、前記ネットワーク・アクセス・サー バからの前記呼び出しをネットワークに送るゲートウェイと を組み合わせて具備し、 前記複数のモデムの内の少なくとも1つが、さらに、着信呼び出しまたは発信 呼び出しのプロトコルを処理するデータ・プロセッサを具備するネットワーク・ アクセス・サーバ。 12．前記伝送手段がパケット・バスを具備する請求項11に記載のネットワーク・ アクセス・サーバ。 13．前記伝送手段がRS 232ケーブルを具備する請求項11に記載のネットワーク・ アクセス・サーバ。 14．前記呼び出しが、パケット・バスを介して前記モデムから前記ゲートウェイ に送信される請求項11に記載のネットワーク・アクセス・サーバ。 15．前記呼び出しが、RS 232ケーブルを介して前記モデムから前記ゲートウェイ に送信される請求項11に記載のネットワーク・アクセス・サーバ。 16．前記複数のモデムのそれぞれが、着信呼び出しまたは発信呼び出しのプロト コルを処理するソフトウェア・ルーチンを実現するデータ・プロセッサを具備し 、それにより、複数の計算プラットホームの間でプロトコル処理を分散し、効率 的な呼び出し処理効率を達成する請求項11に記載のネットワーク・アクセス・サ ーバ。 17．前記プロトコルがPPPまたはSLIPから構成される請求 項11に記載のネットワーク・アクセス・サーバ。 18．呼び出しをモデムを介して任意のコンピュータ・システムに送るための方法 であって、 着信呼び出しを前記モデムで受け取るステップと、 前記モデム内の計算プラットホームで前記着信呼び出しのプロトコルの処理を 実行するステップと、 着信呼び出しを前記コンピュータ・システムに送るステップと から成る方法。 19．前記送るステップが、前記コンピュータ・システムで実行されるソフトウェ ア・プログラム内で実行される請求項18に記載の方法。 20．前記プロトコルがPPPまたはSLIPから構成される請求項18に記載の方法。 21．モデムを介してコンピュータ・システムから通信リンクに呼び出しを送るた めの方法であって、 呼び出しをコンピュータ・システムから前記モデムに送るステップと、 前記モデム内の計算プラットホームで前記発信呼び出しのプロトコルの処理を 実行するステップと、 前記発信呼び出しを前記通信リンク上に載せるステップと から成る方法。 22．前記コンピュータ・システムから前記モデムに前記呼び出しを送る前記ステ ップが、前記コンピュータ・シス テム内で実行されるソフトウェア・プログラムで実行される請求項21に記載の方 法。 23．前記プロトコルがPPPまたはSLIPから構成される請求項18に記載の方法。 24．前記コンピュータ・システムが、パーソナル・コンピュータを具備する請求 項19または請求項22に記載の方法。 25．前記着信呼び出しが、デジタル電話網により前記モデムに搬送される請求項 18に記載の方法。 26．前記通信リンクがデジタル電話網を具備する請求項21に記載の方法。 27．前記モデムがISDN端末アダプタを具備する請求項18または請求項21に記載の 方法。 28．前記モデムがISDN端末アダプタを具備する請求項1または請求項6に記載の方 法。 29．前記モデムがISDN端末アダプタを具備する請求項11に記載のネットワーク・ アクセス・サーバ。 30．前記呼び出しが、前記モデムから前記ゲートウェイに、コンピュータの内部 バス上で送信される請求項11に記載のネットワーク・アクセス・サーバ。 31．前記バスが、ISAバス、EISAバス、PCIバス、およびVESAバスから構成される グループから選択される任意のバスを具備する請求項30に記載のネットワーク・ アクセス・サーバ。 32．前記呼び出しが、コンピュータの内部バス上で前記 モデムから前記コンピュータ・システムに送信される請求項18に記載の方法。 33．前記バスが、ISAバス、EISAバス、PCIバスおよびVESAバスから構成されるグ ループから選択される任意のバスを具備する請求項32に記載の方法。