JPH05227209A - 通信管理装置 - Google Patents

Abstract

(57)【要約】 【目的】ワークステーションや各種サーバなどのデータ
端末装置上で機能する通信管理装置において、未知の装
置からの接続要求に対してデータの機密を保持できるよ
うにする。 【構成】発呼要求検出手段１は当該装置が発呼要求送信
先からの接続完了パケットを待っている間に前記発呼要
求送信先からの発呼要求パケットの受信を検出し、応答
パケット検出手段２は当該装置の発呼したパケットに対
する応答パケットの受信を検出する。呼開通手段３は発
呼要求検出手段１において発着呼衝突が発生した場合、
もしくは応答パケット検出手段２において応答パケット
を受信した場合にのみ呼を開通する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は、ワークステーション
や各種サーバなどのデータ端末装置上で機能する通信管
理装置に関し、特にＸ．２５プロトコル制御部を持つ通
信管理装置における呼びの設定に関する。

【０００２】

【従来の技術】Ｘ．２５プロトコルに従い通信を行う通
信管理装置が公衆回線（ＤＤＸなど）を利用する場合、
図６に示す呼の設定手順に従って手続きを行っている。
図において、左側は発呼ＤＴＥ（データ端末装置）の動
作を、右側は着呼ＤＴＥの動作をそれぞれ示し、中央は
両ＤＴＥに接続されたパケット交換網（ＤＣＥ）を示し
ている。発呼ＤＴＥからの呼の設定は着呼受付の手順に
示すような手続きに従って行われる。また、着呼ＤＴＥ
に発生した問題あるいは意思により着呼拒否する場合に
は、着呼拒否の手続きに従って復旧要求パケットを送出
して拒否する。このような着呼拒否の原因としては、リ
ソースの制限などが例として上げられる。また、網の状
態が原因の時には呼設定不可能の手順に従う。

【０００３】この図からも明らかなように、着呼ＤＴＥ
において何らかの手続きにより着呼拒否しない場合に
は、どの端末装置からの接続要求も受け付けられるた
め、未知の端末装置との接続が完了してしまうことにな
る。すなわち、外部からのアクセスに対して無防備とな
り、データの機密が保持できない状態になってしまう。
この問題を解決するため、プロトコル識別子を用い
る、アクセス権としてＤＴＥアドレスなどを予め登録
しておき、登録されているサイトからの接続要求のみ許
可する、上位レイヤにて処理を行うなどの方法が用い
られている。

【０００４】

【発明が解決しようとする課題】しかしながら、のプ
ロトコル識別子を用いる方法は、同じソフトウェアを利
用したもの同士であると全て同じ識別子であることが多
いため、接続要求が受け付けられてしまうこともある。
また、のＤＴＥアドレスなどを用いる方法では、前も
って必要なＤＴＥアドレスを全て着信許可リストに登録
しておかなければならないため、登録に手間がかかると
いう問題点がある。の上位レイヤにより呼の設定を管
理する方法では、一旦呼が設定されてから上位レイヤの
意思により呼を解放するなどの余分な手続きが必要であ
り、処理に時間がかかるという問題点を抱えている。

【０００５】この発明は、簡単な手続きにより、手間や
時間をかけることなくデータの機密を保持できるように
した通信管理装置を提供することを目的とする。

【０００６】

【課題を解決するための手段】この発明に係わる通信管
理装置は、当該装置が発呼要求送信先からの接続完了パ
ケットを待っている間に前記発呼要求送信先からの発呼
要求パケットの受信を検出する第１の検出手段と、当該
装置の発呼したパケットに対する応答パケットの受信を
検出する第２の検出手段と、前記第１の検出手段におけ
る発着呼衝突が発生した場合、もしくは第２の検出手段
において応答パケットを受信した場合にのみ呼を開通す
る呼開通手段とを具えている。

【０００７】着呼ＤＴＥが通常のＤＴＥである場合に
は、第１又は第２の検出手段のどちらかにより接続する
ことができる。また、着呼ＤＴＥにもこの発明を適用し
た場合には、第１の検出手段により接続することができ
る。

【０００８】

【作用】上記通信管理装置によれば、呼の開通は、発呼
要求を送信した相手から接続完了パケットを待っている
間に発呼要求パケットを受信した場合（発着呼衝突：こ
こでは、論理チャネルグループ番号、論理チャネル番号
が同一という条件を外してこの用語を使用する）と、自
ら発呼したパケットに対する応答パケット（接続完了パ
ケット）を受信した場合に限られ、２つの装置間で接続
の意志がある場合にのみ接続することができる。したが
って、未知の端末装置からの接続要求は全て拒否される
ことになるため、データの機密を保持することができ
る。

【０００９】

【実施例】以下、この発明に係わる通信管理装置の一実
施例を図面を参照しながら説明する。

【００１０】図２は、この発明に係わる通信管理装置を
適用したデータ端末装置の基本的な構成を示すブロック
図であり、次に説明する各部により構成されている。

【００１１】ＣＰＵ（中央処理装置）１１は、システム
全体の制御を行うと共に、各種の指示に基づいて所定の
データに対する演算処理を行う回路であり、データバス
等のバス１２を通じて各種の回路装置と接続されてい
る。

【００１２】ＲＡＭ（ランダム・アクセス・メモリ）１
３は、例えば通信管理装置の制御のためのプログラムを
格納したり、各種作業用のデータを一時的に格納するた
めの作業用メモリである。

【００１３】キーボード１４は、各種のデータをキー入
力するための入力装置であり、ポインティングデバイス
としてのマウス１５を接続している。ユーザーによりキ
ーボード１４やマウス１５から入力された各種のデータ
や指示は、バス１２を通じてＣＰＵ１１に送られる。

【００１４】表示制御装置１６は、ＣＲＴ等のディスプ
レイ１７上に各種データを表示するための制御装置であ
り、ウィンドウやアイコンなどのほか、磁気ディスク１
８に格納されている各データを表示出力する。

【００１５】磁気ディスク１８には、各種のプログラム
やファイルが格納され、磁気ディスク制御装置１９によ
りデータの入出力が管理されている。

【００１６】通信制御部２０は、図示せぬパケット交換
網に接続され、他のＤＴＥとの間で行われるパケットの
送受信を管理する。

【００１７】図１は、上記データ端末装置上で実現され
る通信管理装置の機能的な構成を示すブロック図であ
り、特に呼の設定を行う場合の構成を示している。図１
において、発呼要求検出手段１は当該装置が発呼要求送
信先からの接続完了パケットを待っている間に前記発呼
要求送信先からの発呼要求パケットの受信を検出する。
応答パケット受信手段２は当該装置の発呼したパケット
に対する接続完了パケットの受信を検出する。呼開通手
段３は発呼要求検出手段１における発着呼衝突が発生し
た場合、もしくは応答パケット検出手段２において接続
完了パケットを受信した場合にのみ呼を開通する。な
お、ここには表現されていないが、パケットの送信を行
う送信手段や、受信を行う受信手段のほか、受け付けた
パケットを処理するためのパケット処理手段を具えてい
る。

【００１８】次に、上述した図１の機能を持つＤＴＥ同
士で呼設定を行う場合の処理手順を図３のフローチャー
トにより説明する。ここでは、図１の発呼要求検出手段
１における接続条件（発着呼衝突）を利用している。

【００１９】まず、両ＤＴＥから、お互いに発呼要求パ
ケットを送信し（ステップ１０１）、Ｔ21秒以内に発呼
要求パケットで設定した着呼アドレスからのパケットを
受信したかどうかを判断する（ステップ１０２、１０
３）。Ｔ21秒以内にパケット受信した場合、呼開通手段
３は当該パケットにより発着呼衝突が発生したかどうか
を判断する（ステップ１０４）。ここで、発呼要求検出
手段１が発呼要求パケットの受信を検出した場合は発着
呼衝突が発生する。呼開通手段３は発着呼衝突が発生し
たときは、呼を開通するために着呼受付パケットを送出
して（ステップ１０５）、データ転送状態とする（ステ
ップ１０６）。なお、Ｔ21というのは、ＤＴＥが発呼要
求パケットを送信してから接続完了パケットを待つ時間
（約２００秒）である。発呼からデータ転送状態になる
までのシーケンスを図４に示す。通常は、ＤＴＥからＤ
ＣＥへ発呼要求パケット（ＣＲ）が送信されてから、Ｔ
21秒以内に接続完了パケット（ＣＣ）を受け取った場合
にデータ転送フェーズへ移行する。 さて、Ｔ21秒以内
に何のパケットも受信しなかった場合、あるいはステッ
プ１０４で発着呼衝突を発生しなかったときは、通信を
終了するために復旧要求パケットを送出するとともに、
論理チャンネルなどを解放してレディ状態となる（ステ
ップ１０７）。

【００２０】本来、発着呼衝突を発生したときの接続
は、偶然に２つの装置同士がお互いに発呼した場合に用
いられる接続制御手順であるが、ここでは、発着呼衝突
を特定の相手との接続条件として利用している。すなわ
ち、図１の機能を持つＤＴＥ同士を接続させる場合に
は、発着呼衝突させることにより接続を完了させ、デー
タ転送フェーズへと移行できることになる。したがっ
て、２つの装置間で接続の意志がある場合のみ接続する
ことができ、未知の装置からの接続要求は全て拒否する
ことができる。

【００２１】次に、図１の機能を持つＤＴＥから一般の
ＤＴＥに対して接続要求パケットを送信（発呼）した場
合の処理手順を図５のフローチャートにより説明する。
ここでは、図１の応答パケット受信手段２における接続
条件（応答パケットの受信）を利用している。

【００２２】まず、図１の機能を持つＤＴＥから一般の
ＤＴＥに対して接続要求パケットを送信（発呼）し（ス
テップ２０１）、Ｔ21秒以内に発呼要求パケットで設定
した着呼アドレスからパケットを受信したかどうかを判
断する（ステップ２０２、２０３）。Ｔ21秒以内にパケ
ット受信した場合、呼開通手段３は当該パケットが接続
完了パケットであるかどうかを判断する（ステップ２０
４）。ここで、応答パケット受信手段２が接続完了パケ
ットを受信した場合、呼開通手段３は接続を完了してデ
ータ転送状態とする（ステップ２０５）。一方、ステッ
プ２０４において、受信したパケットが接続完了パケッ
トでなかった場合、呼開通手段３は発着呼衝突が発生し
たかどうかを判断する（ステップ２０６）。ここで、発
呼要求検出手段１が発呼要求パケットの受信を検出した
場合は発着呼衝突が発生する。呼開通手段３は発着呼衝
突が発生したときは、呼を開通するため着呼受付パケッ
トを送出して（ステップ２０７）、データ転送状態とす
る（ステップ２０５）。

【００２３】さて、Ｔ21秒以内に何のパケットも受信し
なかった場合、あるいはステップ２０６で発着呼衝突を
発生しなかったときは、通信を終了するために復旧要求
パケットを送出するとともに、論理チャンネルなどを解
放してレディ状態となる（ステップ２０８）。

【００２４】このように、図１の機能を持つＤＴＥから
の発呼パケットを受け付けるようなＤＴＥ（一般のＤＴ
Ｅ）との接続においても問題なく接続が完了する。この
場合、当該ＤＴＥが接続要求パケットを受信しても、そ
のパケットが当該ＤＴＥが発呼要求を行ったＤＴＥから
のものであり、発着呼衝突が発生した場合以外は全て接
続要求を拒否するため、呼の設定は起こらない。

【００２５】したがって、従来のプロトコル識別子を用
いる方法のように、相手側の装置によって接続要求が受
け付けられてしまうことはない。また、ＤＴＥアドレス
などを着信許可リストに登録する方法と比べると、アド
レスの登録やリストを管理する手間を省くことができ
る。さらに、接続要求の受付と拒否が即座に決まるた
め、上位レイヤにより呼の設定を管理する方法に比べ
て、処理時間を大幅に短縮することができる。

【００２６】

【発明の効果】以上説明したように、この発明に係わる
通信管理装置では、発呼要求を送信した相手から接続完
了パケットを待っている間に発呼要求パケットを受信し
た場合（発着呼衝突）と、自ら発呼したパケットに対す
る応答パケットを受信した場合に限定して呼を開通する
ようにしたため、２つの装置間で接続の意志がある場合
にのみ接続が可能となる。したがって、未知の端末装置
からの接続要求は全て拒否されることになり、データの
機密を保持することができる。しかも、従来の方法に比
べて手間や時間がかからず、簡単な手続きで実現するこ
とができる。

【図面の簡単な説明】

【図１】データ端末装置上で実現される通信管理装置の
機能的な構成を示すブロック図。

【図２】この発明に係わる通信管理装置を適用したデー
タ端末装置の基本的な構成を示すブロック図。

【図３】図１の機能を持つＤＴＥ同士で呼設定を行う場
合の処理手順を示すフローチャート。

【図４】発呼からデータ転送状態になるまでのシーケン
スを示す図。

【図５】図１の機能を持つＤＴＥから一般のＤＴＥに対
して接続要求パケットを送信（発呼）した場合の処理手
順示すフローチャート。

【図６】Ｘ．２５プロトコルに従い通信を行う通信管理
装置が公衆回線を利用する場合の呼の設定手順を示す
図。

【符号の説明】

１…発呼要求検出手段（第１の検出手段）、２…応答パ
ケット検出手段（大２の検出手段）、３…呼開通手段

Claims (1)

【特許請求の範囲】
1. 【請求項１】発呼要求送信先からの接続完了パケットを
   待っている間に前記発呼要求送信先からの発呼要求の受
   信を検出する第１の検出手段と、自己の発呼したパケッ
   トに対する応答パケットの受信を検出する第２の検出手
   段とを有する通信制御装置において、 前記第１の検出手段で発着呼衝突が発生したとき、もし
   くは第２の検出手段で応答パケットを受信したときに呼
   を開通する呼開通手段を具えたことを特徴とする通信管
   理装置。