JPH0514342A - パケツト同報通信方式 - Google Patents

Abstract

(57)【要約】 【目的】 中継トラフィックに負荷をかけることなく、
多数の同報先端末に対して短時間で同報通信を行うこと
ができる柔軟で拡張性が高いシステムを得る。 【構成】 パケット交換局Ｐ１〜Ｐ４よりなるパケット
交換システムに、マスタ同報装置ＭＢ及びスレーブ同報
装置ＳＢ１〜ＳＢ３を設置する。同報装置は、呼接続要
求のあった端末、すなわちマスタ同報装置ではスレーブ
同報装置、各スレーブ同報装置ではシンク端末ＳＫ１〜
ＳＫ６のうち同一パケット交換局に接続される端末を同
報先端末として自動登録する。各同報装置は、受信した
データパケットの内容を７面の送信バッファに複写し
て、登録した同報先端末に送信する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、パケツト同報通信方式
に係り、特に、特定の同報元端末が送信したデータパケ
ットを多数の同報先端末に対して同報送信するためのパ
ケット同報通信方式に関する。

【０００２】

【従来の技術】パケット交換システムの同報通信に関す
る従来技術として、例えば、特開昭６１−１４０２５１
号公報等に記載された技術が知られている。

【０００３】この従来技術は、パケット交換局内に同報
を行う発信端末毎に着信端末を定義した同報テーブルを
持ち、この同報テーブルに基づいてパケット交換局が同
報処理を行うものである。

【０００４】

【発明が解決しようとする課題】前記従来技術は、パケ
ット交換局に同報通信機能備えて同報通信が行われるた
め、既存のパケット交換網で同報通信を実現しようとす
ると、パケツト交換局に同報通信機能を追加する必要が
あるため、既存のパケット交換網で同報通信を実現する
ことが困難であるという問題点を有している。また、同
報を行う発信端末毎に着信端末をデータ定義する必要が
あるため大量のデータ定義が必要となるという問題点を
有している。

【０００５】また、前記従来技術は、同報の着信端末を
追加変更する場合にはパケット交換局のデータを変更す
る必要があり、システムとしての柔軟性に欠け、また、
同報テーブルが同報を行う発信端末毎に定義されるが、
同報テーブルにはテーブル識別子がないため各発信端末
が１グループの同報先のみしか定義することができず、
同報するデータの内容によって同報先を選別することが
できないという問題点を有している。

【０００６】さらに、前記従来技術は、着信端末に対し
てデータパケットを送信する場合に、発信端末からデー
タパケットを受信したパケット交換局が直接全ての着信
端末に対してそのデータパケットを個別に送信するた
め、着信端末が多くなった場合に同報送信処理全体に要
する時間が長くなり、着信端末間におけるデータパケッ
ト受信の時間差が拡大し、かつ、パケット交換網の中継
トラフィックを急激に増大させて他の通信に対して大き
な影響を与えてしまうという問題点を有している。

【０００７】本発明の目的は、前記従来技術の問題点を
解決し、既存のパケット交換網において柔軟で拡張性の
高い同報通信システムを実現し、パケット交換網の中継
トラフィックに負荷をかけることなく短時間で同報通信
を行うことが可能なパケット同報通信方式を提供するこ
とにある。

【０００８】

【課題を解決するための手段】本発明によれば前記目的
は、ＤＴＥアドレスを割り当てた同報装置をパケット交
換システム内に設置して、パケット同報処理を前記同報
装置上で行うようにすることにより達成される。また、
前記目的は、同報装置をプロトコル上の端末としてパケ
ツト交換システム内に設け、同報装置に対して、自端末
が同報先端末（以下、シンク端末という）となること
を、各端末に報告させ、同報装置がこれらのデータに基
づいて同報通信を行うようにすることにより達成され
る。

【０００９】すなわち、前記目的は、同報装置に対して
同報データの送信元端末（以下、ソース端末という）以
外の端末から着呼があった場合に該当端末を自動的にシ
ンク端末として登録し、同報装置に割り当てた複数のＤ
ＴＥ（端末）アドレスに対応して同報テーブルを多重定
義しておくことにより、また、シンク端末に対するデー
タパケットを、データパケットの内容を複写した複数か
つ有限の送信バッファを繰返し使用して連続送信するこ
とにより、さらに、必要に応じてパケット交換システム
に複数の同報装置を分散設置してシンク端末に対するデ
ータパケットの送信処理を同報装置間で分散処理するよ
うにすことにより達成される。

【００１０】なお同報装置の実現方法は、同報装置をパ
ケット交換局に外部接続する方法と、パケット交換局の
内部機能として実現する方法がある。

【００１１】

【作用】ソース端末は、パケット交換システムに設置し
た同報装置に対してデータパケットを送信する。ソース
端末からデータパケットを受信した同報装置は、同報テ
ーブルに登録されている全てのシンク端末に対してデー
タパケットを複製して送信する。これにより、ソース端
末が送信するデータパケットをパケット交換網を経由し
て多数のシンク端末に対して一斉に同報送信することが
できる。

【００１２】同報装置内の同報テーブルへのシンク端末
の登録は、ソース端末として登録されていない端末から
同報装置に対して呼接続要求があったものについて、そ
の端末を自動的にシンク端末として登録する。これによ
り、柔軟で拡張性の高い同報通信システムを実現するこ
とができる。

【００１３】また、同報テーブルに複数のソース端末を
登録することにより、複数のソース端末からのデータパ
ケットを同一シンク端末群に対して同報送信することが
でき、さらに、同報装置の複数のＤＴＥアドレスに対応
して同報テーブルを多重に定義しておくことにより、ソ
ース端末がデータパケットを送信するときにデータの内
容によって同報装置のＤＴＥアドレスを選択することに
よりグループ同報を多重化することができる。

【００１４】また、シンク端末に対してデータパケット
を複製して送信する場合、データパケットの内容を複写
する送信バッファを、例えば、７面に限定して７面の送
信バッファへの書き込みと読み出しを順次切り替えるよ
うにすることにより、複写処理時間を短縮し、データの
連続送信を可能とすることができるので、データパケッ
ト送信時の回線利用効率を高め、短時間で同報通信を行
うことができる。

【００１５】また、必要に応じてパケット交換システム
に複数の同報装置を分散設置して同報装置を階層構造に
形成することにより、シンク端末に対するデータパケッ
トの送信処理を同報装置間で分散処理することが可能と
なり、パケット交換網の中継トラフィックに負荷をかけ
ることなく多数のシンク端末に対して短時間で同報送信
を行うことができる。

【００１６】

【実施例】以下、本発明によるパケット同報通信方式の
一実施例を図面により詳細に説明する。

【００１７】図１は本発明が適用されるパケット同報通
信システムの一実施例のシステム構成例を示すブロック
図である。図１において、Ｐ１〜Ｐ４はパケット交換
局、ＭＢはマスタ同報装置、ＳＢ１〜ＳＢ３はスレーブ
同報装置、ＳＣはソース端末、ＳＫ１〜ＳＫ６はシンク
端末である。図示本発明の一実施例は、複数の同報装置
による階層構造を備えた例である。

【００１８】図１に示すシステムは、マスタ同報装置Ｍ
Ｂ及びスレーブ同報装置ＳＢ１〜ＳＢ３が回線Ｌ１１〜
Ｌ１４を介してパケット交換局Ｐ１〜Ｐ４に接続され、
ソース端末ＳＣ及びシンク端末ＳＫ１〜ＳＫ６が加入者
回線Ｌ２１及びＬ３１〜Ｌ３６を介してパケット交換局
Ｐ１〜Ｐ４に接続され、また、パケット交換局Ｐ１〜Ｐ
４相互間が中継回線Ｌ４１〜Ｌ４４を介して接続されて
構成されている。

【００１９】図示本発明の一実施例において、マスタ同
報装置ＭＢ内には、予めソース端末ＳＣが定義されてお
り、マスタ同報装置ＭＢは、スレーブ同報装置ＳＢ１〜
ＳＢ３及びシンク端末から着呼があった場合、それらを
同報テーブル内にシンク端末として登録する。また、各
スレーブ同報装置ＳＢ１〜ＳＢ３内には、マスタ同報装
置ＭＢがソース端末として定義されている。そして、シ
ンク端末ＳＫ１〜ＳＫ６は、それぞれ、自端末が接続さ
れているパケツト交換局Ｐ２〜Ｐ４のスレーブ端末ＳＢ
１〜ＳＢ３に対して発呼し、自端末がシンク端末となる
ことを報告する。各スレーブ端末ＳＢ１〜ＳＢ３は、こ
れにより、シンク端末ＳＫ１〜ＳＫ６を同報テーブル内
に登録する。

【００２０】図２は前述のように構成される本発明の一
実施例における呼接続とデータパケットの送信例を説明
する図である。

【００２１】図２において、シンク端末ＳＫ１は、発呼
要求（ＣＲ）パケットをパケツト交換局Ｐ２に送信し
て、スレーブ同報装置ＳＢ１に対する発呼を要求する。
パケツト交換局Ｐ２は、これによりスレーブ同報装置Ｓ
Ｂ１に着呼（ＣＮ）パケットを送信し、スレーブ同報装
置ＳＢ１から着呼受付（ＣＡ）パケットを受取り、シン
ク端末ＳＫ１に対して接続完了（ＣＣ）パケットを送信
する。この動作により、スレーブ同報装置ＳＢ１は、シ
ンク端末ＳＫ１を同報テーブルに格納する。

【００２２】その後、スレーブ同報装置ＳＢ１は、パケ
ット交換局Ｐ２に対してＣＲパケットを送信し、マスタ
同報装置ＭＢに対する発呼を要求する。このＣＲパケッ
トは、パケット交換局Ｐ１に送られ、パケット交換局Ｐ
１は、マスタ同報装置ＭＢに対してＣＮパケットを送信
し、マスタ同報装置ＭＢからＣＡパケットを受取り、ス
レーブ同報装置ＳＢ１に対してＣＣパケットを送信す
る。これにより、マスタ同報装置ＭＢは、スレーブ同報
装置ＳＢ１をシンク端末として、内部の同報テーブルに
登録する。

【００２３】ソース端末ＳＣがデータパケットの同報通
信を行おうとする場合、ソース端末ＳＣは、前述したシ
ンク端末ＳＫ１がスレーブ同報装置ＳＢ１に発呼したと
同様な手順により、マスタ同報装置ＭＢに対して発呼
し、マスタ同報装置ＭＢからＣＣパケットを受け取った
後、データ（ＤＴ）パケットを送信する。マスタ同報装
置ＭＢは、データパケットを受信すると、パケット交換
局Ｐ１を介してソース端末ＳＣに対して受信可（ＲＲ）
パケットを送信する。

【００２４】その後、マスタ同報装置ＭＢは、同報テー
ブルを使用して同報通信を開始する。この例の場合、同
報テーブル内にはスレーブ同報装置ＳＢ１が登録されて
いるので、マスタ同報装置ＭＢは、パケット交換局Ｐ
１、Ｐ２を介してＤＴパケットをスレーブ同報装置ＳＢ
１に送信し、ＲＲパケットを受領する。スレーブ同報装
置ＳＢ１は、受信したＤＴパケットを自装置内の同報テ
ーブルを参照して、シンク端末ＳＫ１に送信する。

【００２５】本発明の一実施例は、前述したような動作
を行うため、同報装置がソース端末以外の発呼元端末を
自動的にシンク端末として登録することができ、シンク
端末をシステム定義データとして定義する必要がなく、
シンク端末の登録及び追加を容易に行うことができる。
また、マスタ同報装置は、スレーブ同報装置をシンク端
末として扱かい、スレーブ同報装置はマスタ同報装置を
ソース端末として扱かっているため、スレーブ同報装置
の登録及び追加を容易に行うことができる。

【００２６】本発明の一実施例によれば、前述により柔
軟で拡張性の高い同報通信システムを実現することがで
きる。

【００２７】前述の説明においては、スレーブ同報装置
及びシンク端末を各１台づつとしたが、マスタ同報装置
は、同報テーブルにシンク端末として登録されている複
数のスレーブ同報装置にデータパケットを送信すること
ができ、また、各スレーブ同報装置は、自装置内の同報
テーブルに登録されている複数の全てのシンク端末に対
してデータパケットを送信することができる。

【００２８】また、図１において、パケット交換局Ｐ２
〜Ｐ３に接続されているシンク端末は、それぞれ、自端
末を収容しているパケット交換局に接続されているスレ
ーブ同報装置に対して発呼を行い、シンク端末であるこ
とを登録する。このため、マスタ同報装置ＭＢは、同報
データパケットを、スレーブ同報装置に送るだけでよ
く、パケット交換網の中継トラフィックは、マスタ同報
装置ＭＢとスレーブ同報装置ＳＢ１との間のわずかなト
ラフィックだけとすることができる。これにより、本発
明の実施例は、多数のシンク端末に対する同報通信をパ
ケット交換網の中継トラフィックに負荷をかけることな
く実現することができる。

【００２９】図３は各同報装置上で定義される同報テー
ブル３の構成を説明する図である。同報装置に複数のＤ
ＴＥアドレスを割り当てる場合は、各ＤＴＥアドレスに
対応して本テーブルを多重定義することにより、ソース
端末とシンク端末の組合せ、すなわちグループ同報を多
重化することができる。同報テーブル３の中でシステム
構成定義データは自ＤＴＥアドレス３１とソースＤＴＥ
アドレス３２であり、その他のデータはワークエリアと
して使用する。

【００３０】図３において、自ＤＴＥアドレス３１は、
同報装置のＤＴＥアドレスを示し、同報テーブル３を多
重定義する場合には、各テーブルごとに異なる自ＤＴＥ
アドレスを定義する。ソースＤＴＥアドレス３２は、ソ
ース端末のＤＴＥアドレスを示すが、スレーブ同報装置
の場合、マスタ同報装置をソース端末とみなすため、こ
のソースＤＴＥアドレスには、マスタ同報装置のＤＴＥ
アドレスが定義される。このソースＤＴＥアドレス３２
には、複数のソースＤＴＥアドレス３２を定義すること
が可能であり、これにより、複数のソース端末から受信
するデータパケットを同一の配布先シンク端末群に同報
することができる。

【００３１】なお、同報テーブル３の多重定義は、前述
したように各テーブルごとに異なる自ＤＴＥアドレスを
定義することによってもよく、また、後述するように、
論理チャネルに対応して、従来技術ＤＴＥアドレスの定
義を含む同報テーブルを備えて行ってもよい。

【００３２】同報待ちキューヘッド３３と同報待ちキュ
ーテール３４とは、シンク端末に対してデータパケット
送信中にソース端末から新たなデータパケットを受信し
た場合に、そのデータパケットをチェーンにしてセーブ
するためのワークエリアである。また、同報中パケット
アドレス３５は、シンク端末に対して送信中のデータパ
ケットのアドレスをセーブするためのワークエリアであ
る。

【００３３】送信バッファキューヘッド３６と送信バッ
ファキューテール３７とは、シンク端末にデータパケッ
トを送信するための送信バッファをチェーンにしてセー
ブするためのセーブエリアであり、初期状態では７面の
送信バッファがセーブされている。送信バッファを７面
とするのは、ＨＤＬＣの最大送信アウトスタンディング
数が７であり、７面あればＨＤＬＣレベルで肯定応答さ
れた送信バッファを未送信のシンク端末に対する送信に
順次転用することが可能になり、必要最小限の送信バッ
ファへの複写処理を行うのみで、データパケット送信に
関する回線利用効率を高め、同報処理全体の処理時間を
短縮することができるためである。

【００３４】送信待ちキューヘッド３８と送信待ちキュ
ーテール３９とは、未送信のシンク端末に対する論理チ
ャネルのチャネル管理テーブル４（詳細は後述する）を
チェーンにしてセーブするためのワークエリアであり、
シンク端末との間で接続された論理チャネルのチャネル
管理テーブル４は、最初このキューにセーブされる。ま
た、送信済みキューヘッド３Ａと送信済みキューテール
３Ｂとは、送信済みのシンク端末に対する論理チャネル
のチャネル管理テーブル４をチェーンにしてセーブする
ためのワークエリアである。

【００３５】図４は論理チャネルの状態を管理するため
のチャネル管理テーブル４の構成を説明する図である。
このチャネル管理テーブル４は、論理チャネル番号対応
に設けられている。

【００３６】図４において、論理チャネル番号４１は、
論理チャネル番号の定義データであり、同報テーブルア
ドレス４２は、この論理チャネルが対応する同報グルー
プの同報テーブルアドレスをセーブするためのワークエ
リアである。また、ソース・シンク識別表示４３は、こ
の論理チャネルの通信相手がソース端末かシンク端末か
を識別するためのワークエリアであり、呼接続時に設定
される。チャネル状態４４は、この論理チャネルの状態
をセーブするためのワークエリアであり、データパケッ
ト送信可能状態であるか、ＲＲパケット受信待ち状態で
あるか、リセット中の状態であるかを示す。

【００３７】送信ウィンドウ４５は、この論理チャネル
でデータパケットを送信できるウィンドウをセーブする
ためのワークエリアであり、送信ウィンドウがフルにな
ると、その後データパケットの送信ができなくなること
を示している。また、ＲＲパケット受信タイマ４６は、
送信ウィンドウがフルになったときにＲＲパケット受信
を監視するためのワークエリアであり、ＲＲパケット送
信タイマ４７は、同報待ちのデータパケット数が規制値
を超えた場合に、ソース端末に対するＲＲパケットの送
信タイミングを監視するためのワークエリアである。

【００３８】次に、本発明の一実施例の動作の詳細を、
同報装置におけるパケット送受信に関する処理手順を示
す図５〜図１５のフローチャートにより説明する。図示
フローチャートは、マスタ同報装置とスレーブ同報装置
とで共通である。

【００３９】図５は着呼パケット受信時の処理を説明す
るフローチャート、図６は発呼パケット送信時の処理を
説明するフローチャート、図７は着呼応答パケット受信
時の処理を説明するフローチャート、８図はデータパケ
ット受信時の処理概要を説明するフローチャート、９図
はデータパケット受信時の同報開始処理を説明するフロ
ーチャート、図１０はデータパケット送信終了時の処理
を説明するフローチャート、図１１はＲＲパケット受信
時の処理を説明するフローチャート、図１２はＲＲパケ
ット送信タイマの処理を説明するフローチャート、図１
３はＲＲパケット受信タイマの処理を説明するフローチ
ャート、図１４はリセットパケット受信時の処理を説明
するフローチャート、図１５はリセット応答パケット受
信時の処理を説明するフローチャートである。

【００４０】まず、図５を参照して、着呼パケット受信
時の処理Ｆ０を説明する。

【００４１】（１）同報装置が着呼パケットを受信する
と、着呼パケット内の論理チャネル番号に対応する論理
チャネル番号４１のチャネル管理テーブル４を取り出す
（ステップＦ００１）。

【００４２】（２）次に、同報テーブル３のうち、自Ｄ
ＴＥアドレス３１が着呼パケット内の着ＤＴＥアドレス
と一致するものがあるか否かを調べ、一致すればその同
報テーブル３のアドレスをチャネル管理テーブル４の同
報テーブルアドレス４２にセーブし、着呼応答パケット
を送信すると共に、チャネル管理テーブル４のチャネル
状態４４を送信可能状態に更新する（ステップＦ００２
〜Ｆ００５）。

【００４３】（３）同報テーブル３のソースＤＴＥアド
レス３２内のアドレスで、着呼パケット内の発ＤＴＥア
ドレスと一致するものがあれば、その着呼はソース端末
からの着呼であるため、チャネル管理テーブル４のソー
ス・シンク識別表示４３にソース表示を設定し、それ以
外の場合、シンク端末からの着呼とみなしシンク表示を
設定するとともに、チャネル管理テーブル４を同報テー
ブル３の送信待ちキューヘッド３８と送信待ちキューテ
ール３９を参照して送信待ちキューに接続する（ステッ
プＦ００６〜Ｆ００９）。

【００４４】次に、図６を参照して、発呼パケット送信
時の処理Ｆ１を説明する。

【００４５】（１）自装置がスレーブ同報装置であるか
否かをチェックし、スレーブ同報装置の場合、同報テー
ブル３の各テーブルに対して以下に説明する発呼処理を
行なう（ステップＦ１０１、Ｆ１０２）。

【００４６】（２）同報テーブル３と未使用中のチャネ
ル管理テーブル４とを取り出して、チャネル管理テーブ
ル４の同報テーブルアドレス４２に同報テーブル３のア
ドレスをセーブし、ソース端末（実際にはマスタ同報装
置）に対して同報テーブル３のソースＤＴＥアドレス３
２を着ＤＴＥアドレスとしてセットした発呼パケットを
送信する（ステップＦ１０３〜Ｆ１０６）。

【００４７】次に、図７を参照して、スレーブ同報装置
が発呼パケット送信後に着呼応答パケットを受信した時
の処理Ｆ２を説明する。

【００４８】（１）スレーブ同報装置が着呼応答パケッ
トを受信すると、着呼応答パケット内の論理チャネル番
号に対応する論理チャネル番号４１のチャネル管理テー
ブル４を取り出す（ステップＦ２０１）。

【００４９】（２）テーブル４のチャネル状態４４を送
信可能状態に更新し、ソース・シンク識別表示４３にソ
ース表示を設定する（ステップＦ２０２、Ｆ２０３）。

【００５０】次に、図８及び図９を参照して、データパ
ケット受信時の処理であるデータパケット受信処理と同
報開始処理Ｆ３を説明する。

【００５１】（１）同報装置がデータパケットを受信す
ると、データパケット内の論理チャネル番号に対応する
論理チャネル番号４１のチャネル管理テーブル４を取り
出す（ステップＦ３０１）。

【００５２】（２）チャネル管理テーブル４のソース・
シンク識別表示４３を参照し、受信データパケットがソ
ース端末からのものか、シンク端末からのものかをチェ
ックし、シンク表示の場合、受信データパケットを廃棄
し、肯定応答としてＲＲパケットを送信する（ステップ
Ｆ３０２、Ｆ３２８、Ｆ３２９）。

【００５３】（３）ステップＦ３０２の判定がソース表
示の場合、チャネル管理テーブル４の同報テーブルアド
レス４２を参照して同報テーブル３を取り出す（ステッ
プＦ３０３）。

【００５４】（４）同報テーブル３の同報待ちキューヘ
ッド３３と同報待ちキューテール３４を参照し、同報待
ちキュー内のデータパケット数により、異常処理または
規制処理または正常処理を行なう（ステップＦ３０４、
Ｆ３０９）。

【００５５】（５）ステップＦ３０４の判定で、同報待
ちキュー内のデータパケット数が異常値を超えている場
合、受信データパケットを廃棄し、チャネル管理テーブ
ル４のＲＲパケット送信タイマ４７を停止し、チャネル
状態４４をリセット状態に更新した後、リセットパケッ
トを送信する（ステップＦ３０５〜Ｆ３０８）。

【００５６】（６）ステップＦ３０４及びＦ３０９の判
定で、同報待ちキュー内のデータパケット数が異常値は
超えていないが規制値を超えている場合、受信データパ
ケットを同報待ちキューに接続し、チャネル管理テーブ
ル４のＲＲパケット送信タイマ４７が動作中でなければ
ＲＲパケット送信タイマ４７を起動する（ステップＦ３
１０〜Ｆ３１２）。

【００５７】（７）ステップＦ３０９の判定で、同報待
ちキュー内のデータパケット数が規制値以内の場合、チ
ャネル管理テーブル４のＲＲパケット送信タイマ４７を
停止させ、肯定応答としてＲＲパケットを送信する（ス
テップＦ３１３、Ｆ３１４）。

【００５８】（８）次に、同報管理テーブル３の同報中
パケットアドレス３５を参照し、同報中のパケットがあ
るか否かをチェックし、同報中のパケットがある場合、
受信データパケットを同報管理テーブル３の同報待ちキ
ューに接続する（ステップＦ３１５、Ｆ３２７）。

【００５９】（９）ステップＦ３１５の判定で、同報中
のパケットがない場合、同報開始処理として、受信デー
タパケットの内容を同報テーブル３の送信バッファキュ
ーヘッド３６と送信バッファキューテール３７にチェー
ンされている７面の送信バッファに複写し、受信データ
パケットを同報中パケットアドレス３５にセーブする
（ステップＦ３１６、Ｆ３１７）。

【００６０】（１０）次に、送信待ちキューヘッド３８
と送信待ちキューテール３９とにチェーンされているチ
ャネル管理テーブル４をスキャンし、この中でチャネル
状態４４が送信可能状態となっているチャネル管理テー
ブル４を先頭から７テーブル選別して送信バッファ上の
データパケットを送信する（ステップＦ３１８〜Ｆ３２
１）。

【００６１】（１１）データパケットを送信したチャネ
ル管理テーブル４について、送信ウィンドウ４５を更新
し、送信待ちキューからはずして送信済みキューヘッド
３Ａと送信済みキューテール３Ｂとにチェーンされてい
る送信済みキューにつなぎかえる。このとき、データパ
ケット送信により送信ウィンドウ４５がフルとなれば、
ＲＲパケット受信タイマ４６を起動し、チャネル状態４
４をＲＲ待ち状態に更新する（ステップＦ３２２〜Ｆ３
２６）。

【００６２】次に、図１０を参照して、データパケット
送信終了時の処理Ｆ４を説明する。この処理は、データ
パケットの送信に対して、パケット交換局からのＨＤＬ
Ｃレベルの肯定フレームが受信されたときに起動され
る。

【００６３】（１）送信終了した送信バッファに対応す
る同報テーブル３を取り出し、送信待ちキューヘッド３
８を参照して送信待ちキューがあるか否かを判定する
（ステップＦ４０１、Ｆ４０２）。

【００６４】（２）ステップＦ４０２で送信待ちキュー
があると判定された場合、送信待ちキューにチェーンさ
れているチャネル管理テーブル４をスキャンして、この
中でチャネル状態４４が送信可能状態となっているチャ
ネル管理テーブル４を先頭から１テーブル選別して、送
信終了で戻ってきた送信バッファ上のデータパケットを
送信する（ステップＦ４０３〜Ｆ４０６）。

【００６５】（３）データパケットを送信したチャネル
管理テーブル４について、送信ウィンドウ４５を更新
し、送信待ちキューからはずして送信済みキューヘッド
３Ａと送信済みキューテール３Ｂにチェーンされている
送信済みキューにつなぎかえる。このとき、データパケ
ット送信により送信ウィンドウ４５がフルとなれば、Ｒ
Ｒパケット受信タイマ４６を起動し、チャネル状態４４
をＲＲ待ち状態に更新する（ステップＦ４０７〜Ｆ４１
１）。

【００６６】（４）ステップＦ４０２で送信待ちキュー
がないと判定された場合、送信終了バッファを同報テー
ブル３の送信バッファキューヘッド３６と送信バッファ
キューテール３７とのチェーンに接続し、接続後の送信
バッファが７面あるか否か判定する。ステップＦ４０２
の判定で送信待ちキューがない状態で、送信バッファが
７面あれば同報送信が完了したと判断することができる
（ステップＦ４１２、Ｆ４１３）。

【００６７】（５）ステップＦ４１３で同報送信完了と
判定された場合、同報テーブル３の送信済みキューヘッ
ド３Ａと送信済みキューテール３Ｂにチェーンされてい
る全てのチャネル管理テーブル４を、送信待ちキューヘ
ッド３８及び送信待ちキューテール３９のチェーンにつ
なぎかえ、同報中パケットアドレス３５にセーブしてい
た受信データパケットを廃棄する（ステップＦ４１４、
Ｆ４１５）。

【００６８】（６）次に、同報待ちキューヘッド３３を
参照して同報待ちキューがあるか否かを判定し、同報待
ちキューがあれば受信データパケットを取り出して同報
開始処理を行なう。同報開始処理は、データパケット受
信処理Ｆ３により説明したステップＦ３１６〜Ｆ３２６
の処理と全く同一である（ステップＦ４１６〜Ｆ４１
８）。

【００６９】次に、図１１を参照して、ＲＲパケット受
信時の処理Ｆ５を説明する。

【００７０】（１）同報装置がＲＲパケットを受信する
と、ＲＲパケット内の論理チャネル番号に対応する論理
チャネル番号４１のチャネル管理テーブル４を取り出す
（ステップＦ５０１）。

【００７１】（２）チャネル管理テーブル４のソース・
シンク識別表示４３を参照し、シンク表示の場合は送信
ウィンドウ４５を更新し、更新後の送信ウィンドウ４５
がフルでなければＲＲパケット受信タイマ４６を停止し
てチャネル状態４４を送信可能状態に更新し、以下に説
明するデータパケットの送信処理を行なう（ステップＦ
５０２〜Ｆ５０６）。

【００７２】（３）データパケット送信の条件判定とし
て、チャネル管理テーブル４の同報テーブルアドレス４
２を参照して対応する同報テーブル３を取り出し、該当
するチャネル管理テーブル４自身が送信待ちキューヘッ
ド３８及び送信待ちキューテール３９のチェーンの中に
含まれているか否かを判定する（ステップＦ５０７、Ｆ
５０８）。

【００７３】（４）ステップ５０８の判定で、送信待ち
キューに含まれている場合、さらに同報テーブル３の送
信バッファキューヘッド３６を参照して送信バッファが
あるか否かを判定し、送信バッファがあれば以下に説明
するデータパケット送信処理を行う（ステップＦ５０
９）。

【００７４】（５）ステップＦ５０９で送信バッファあ
りと判定された場合、送信バッファキューヘッド３６か
ら送信バッファを１面取り出して送信バッファ上のデー
タパケットを送信する（ステップＦ５１０）。

【００７５】（６）次に、チャネル管理テーブル４の送
信ウィンドウ４５を更新し、送信待ちキューからはずし
て、送信済みキューヘッド３Ａ及び送信済みキューテー
ル３Ｂにチェーンされている送信済みキューにつなぎか
える。このとき、データパケット送信により送信ウィン
ドウ４５がフルとなれば、ＲＲパケット受信タイマ４６
を起動し、チャネル状態４４をＲＲ待ち状態に更新する
（ステップＦ５１１〜Ｆ５１５）。

【００７６】次に、図１２を参照して、ＲＲパケット送
信タイマの処理Ｆ６を説明する。

【００７７】（１）ＲＲパケット送信タイマ４７を参照
してＲＲパケット送信タイマ起動中のチャネル管理テー
ブル４を取り出す（ステップＦ６０１）。

【００７８】（２）タイムアウトした論理チャネルに対
応したＲＲパケット送信タイマ４７を停止してＲＲパケ
ットを送信する（ステップＦ６０２〜Ｆ６０４）。

【００７９】次に、図１３を参照して、ＲＲパケット受
信タイマの処理Ｆ７を説明する。

【００８０】（１）ＲＲパケット受信タイマ４６を参照
してＲＲパケット受信タイマ起動中のチャネル管理テー
ブル４を取り出す（ステップＦ７０１）。

【００８１】（２）タイムアウトした論理チャネルに対
応したＲＲパケット受信タイマ４６を停止し、チャネル
状態４４をリセット状態に更新し、送信ウィンドウ４５
をリセットしてリセットパケットを送信する（ステップ
Ｆ７０２〜Ｆ７０６）。

【００８２】次に、図１４を参照して、リセットパケッ
ト受信時の処理Ｆ８を説明する。

【００８３】（１）同報装置がリセットパケットを受信
すると、リセットパケット内の論理チャネル番号に対応
する論理チャネル番号４１のチャネル管理テーブル４を
取り出し、チャネル状態４４を送信可能状態に更新して
リセット応答パケットを送信する（ステップＦ８０１〜
Ｆ８０３）。

【００８４】（２）チャネル管理テーブル４のソース・
シンク識別表示４３を参照して、ソース表示の場合、Ｒ
Ｒパケット送信タイマ４７を停止させる（ステップＦ８
０４、Ｆ８０５）。

【００８５】（３）ステップＦ８０４の判定がシンク表
示であった場合、ＲＲパケット受信タイマ４６を停止さ
せ、送信ウィンドウ４５をリセットしてデータパケット
送信処理を行なう。データパケット送信処理は、ＲＲパ
ケット受信処理Ｆ５により説明したステップＦ５０７〜
Ｆ５１５の処理と全く同一である（ステップＦ８０６、
Ｆ８０７、Ｆ８０８）。

【００８６】次に、図１５を参照して、リセット応答パ
ケット受信時の処理Ｆ９を説明する。

【００８７】（１）同報装置がリセット応答パケットを
受信すると、リセット応答パケット内の論理チャネル番
号に対応する論理チャネル番号４１のチャネル管理テー
ブル４を取り出し、チャネル状態４４を送信可能状態に
更新する（ステップＦ９０１、Ｆ９０２）。

【００８８】（２）チャネル管理テーブル４のソース・
シンク識別表示４３を参照して、シンク表示の場合、デ
ータパケット送信処理を行なう。データパケット送信処
理は、ＲＲパケット受信処理Ｆ５により説明したステッ
プＦ５０７〜Ｆ５１５の処理と全く同一である（ステッ
プＦ９０３、Ｆ９０４）。

【００８９】前述した本発明の実施例によれば、呼接続
要求元の端末を同報先端末として自動的に登録すること
ができるので、パケット交換システムに対して柔軟で拡
張性の高い同報通信システムを実現することができる。
また、必要に応じてパケット交換システム内に同報装置
を分散設置することにより、パケット交換網の中継トラ
フィックに負荷をかけることなく、多数の同報先端末に
対して、短時間で同報通信を行うことができる。

【００９０】

【発明の効果】以上説明したように本発明によれば、パ
ケット交換システム内に柔軟で拡張性の高い同報通信シ
ステムを構築することができ、パケット交換網の中継ト
ラフィックに負荷をかけることなく、多数の同報先端末
に対して短時間で同報通信を行うことが可能になる。

【図面の簡単な説明】

【図１】本発明が適用されるパケット同報通信システム
の一実施例のシステム構成例を示すブロック図である。

【図２】本発明の一実施例における呼接続とデータパケ
ットの送信例を説明する図である。

【図３】各同報装置上で定義される同報テーブルの構成
を説明する図である。

【図４】論理チャネルの状態を管理するチャネル管理テ
ーブルの構成を説明する図である。

【図５】着呼パケット受信時の処理を説明するフローチ
ャートである。

【図６】発呼パケット送信時の処理を説明するフローチ
ャートである。

【図７】着呼応答パケット受信時の処理を説明するフロ
ーチャートである。

【図８】データパケット受信時の処理概要を説明するフ
ローチャートである。

【図９】データパケット受信時の同報開始処理を説明す
るフローチャートである。

【図１０】データパケット送信終了時の処理を説明する
フローチャートである。

【図１１】ＲＲパケット受信時の処理を説明するフロー
チャートである。

【図１２】ＲＲパケット送信タイマの処理を説明するフ
ローチャートである。

【図１３】ＲＲパケット受信タイマの処理を説明するフ
ローチャートである。

【図１４】リセットパケット受信時の処理を説明するフ
ローチャートである。

【図１５】リセット応答パケット受信時の処理を説明す
るフローチャートである。

【符号の説明】

Ｐ１〜Ｐ４ パケット交換局 ＭＢ マスタ同報装置 ＳＢ１〜ＳＢ３ スレーブ同報装置 ＳＣ ソース端末 ＳＫ１〜ＳＫ６ シンク端末

───────────────────────────────────────────────────── フロントページの続き (72)発明者 鈴木 道雄 神奈川県横浜市中区尾上町六丁目81番地 日立ソフトウエアエンジニアリング株式会 社内 (72)発明者 山口 小一郎 神奈川県秦野市堀山下１番地 株式会社日 立製作所神奈川工場内

Claims (4)

【特許請求の範囲】
1. 【請求項１】 同報元端末が送信したデータパケットを
   多数の同報先端末に同報送信するパケット同報通信方式
   において、パケット交換システムに固有のＤＴＥアドレ
   スを持つ同報装置を設置し、該同報装置に１つまたは複
   数の同報元端末を登録した同報テーブルを定義し、該同
   報装置は、同報元端末以外の端末からの呼接続により該
   当端末を前記同報テーブルに同報先端末として登録し、
   前記同報元端末からデータパケットを受信したとき、前
   記同報先端末に対して受信データパケットと同一内容の
   データを持つデータパケットを送信することを特徴とす
   るパケット同報通信方式。
2. 【請求項２】 前記同報装置に複数のＤＴＥアドレスを
   割り当て、各ＤＴＥアドレスに対して同報テーブルを定
   義することを特徴とする請求項１記載のパケット同報通
   信方式。
3. 【請求項３】 前記同報先端末に対するデータパケット
   の送信は、同報元端末から受信したデータパケットの内
   容を複数かつ有限の送信バッファに複写し、複数の送信
   バッファを繰返し使用して行われることを特徴とする請
   求項１または２記載のパケット同報通信方式。
4. 【請求項４】 パケット交換システム内に複数の同報装
   置を設置して同報装置の階層構造を形成し、下位の同報
   装置の同報元端末として上位の同報装置を定義すること
   を特徴とする請求１、２または３記載のパケット同報通
   信方式。