JP3655673B2

JP3655673B2 - PVC status confirmation method in frame relay network

Info

Publication number: JP3655673B2
Application number: JP24761895A
Authority: JP
Inventors: 章次大吉
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1995-09-26
Filing date: 1995-09-26
Publication date: 2005-06-02
Anticipated expiration: 2015-09-26
Also published as: JPH0993249A

Description

【０００１】
【発明の属する技術分野】
本発明はフレームリレー交換機とＦＲＡＤ間のＰＶＣ状態確認方式に関する。
近年，ＬＡＮ間通信に求められる高速，並びに低遅延に適したフレームリレー通信の発展に伴い，小型の支線系集線拠点向けのフレームリレー多重化装置としてＦＲＡＤ（Rrame Relay Assembly and Disassmbly:フレームリレー組立・分解装置) が注目を集めている。
【０００２】
フレームリレー交換機とＦＲＡＤ間ではＩＴＵ−Ｔ勧告によりＰＶＣ（Permanent Virtual Circuit ：相手固定接続）状態確認手順によりＰＶＣの状態確認を行っているが，ＦＲＡＤの配下の端末の状態はフレームリレー交換機に通知されないためその改善が望まれている。
【０００３】
【従来の技術】
図１５は従来例１の接続形態とＰＶＣ状態確認の制御シーケンスである。
図１５において，９０はフレームリレー端末ａ，９１はＦＲＡＤ（フレームリレー組立・分解装置) ａ，９２はフレームリレー交換機，９３はフレームリレー端末ｂであり，各装置間はＵＮＩ（User Network Interface) により接続されている。フレームリレーの場合，ＩＴＵ(International Telecommunication Union) −Ｔ勧告Ｑ．９３３ＡＮＮＥＸＡで規定されるＰＶＣ状態確認手順に従うと，図１５に示す従来例１のケースでは，フレームリレー交換機９２がＤＣＥ（Data Circuit terminating Equipment：回線終端装置），ＦＲＡＤａがＤＴＥ（Data Terminal Equipment ：データ端末装置）として動作するのが一般的である。
【０００４】
図１５の場合，フレームリレー端末ａとフレームリレー端末ｂの間に張られたＰＶＣは，フレームリレー端末ａとＦＲＡＤａの間のＤＬＣＩ（Data Link Connection Identifire)が「１６」，ＦＲＡＤａとフレームリレー交換機９２の間のＤＬＣＩが「３２」，フレームリレー交換機９２とフレームリレー端末ｂの間のＤＬＣＩが「４８」と，それぞれ設定されている。この状態で，フレームリレー端末ａ，ＦＲＡＤａ及びフレームリレー端末ｂは，それぞれ上記ＩＴＵ−ＴのＰＶＣ状態確認手順に従ってＰＶＣ状態確認の動作を行う。
【０００５】
このＰＶＣ状態確認手順は，ユーザと網間のリンクの正常性を確認すると共にユーザとユーザ間のＰＶＣ状態を通知するために行われる。
通常，ユーザ側から網に対して, 状態問合わせを要求するメッセージ（STATUS ENQIRY:ＳＥで略称する )を送信して，網から状態表示のメッセージ（STATUS：ＳＴと略称する）が返ってくる。この状態問合わせのメッセージ（ＳＥ）には，リンク完全性確認（ユーザと網間のリンクの正常性を確認）を要求するメッセージと，フルステータス表示（通信対象の全てのＰＶＣリンクの状況を確認）を要求するメッセージ（ＳＥ−Ｆと略称する）があり，ＳＥのメッセージを構成する情報要素の中のレポート種別により何れであるかを指示する。なお，これらの状態問合せ及び応答のメッセージのアドレスフィールドのＤＬＣＩは「０」を使用することになっている。
【０００６】
リンク完全性確認は，一定周期毎にユーザ側から網に対しＳＥを送信すると，網からＳＴが返され，ＳＥとＳＴの送信シーケンス番号と受信シーケンス番号が順番に更新されることを確認して端末側及び網側で正常性を確認することができる。
【０００７】
フルステータス表示を要求する状態問合わせのメッセージ（ＳＥ−Ｆ）は，情報要素の中のレポート種別でフルステータス表示が指示され，これを受けた網側では，端末が使用している各ＰＶＣについて情報要素を作成して，各情報要素について現在のＤＬＣＩ，新規ビット（Ｎ），アクティブビット（Ａ）を状態に応じて設定したフルステータス応答のメッセージ（ＳＴ−Ｆ（ＤＬＣＩ，Ｎ，Ａ）で表示）を端末側に応答する。ここで，新規ビット（Ｎ）は，これが「０」であるとＰＶＣが以前に確立していることを表し，「１」であるとＰＶＣが新しく確立したことを表す。
【０００８】
また，アクティブビット（Ａ）は，「Ｉ」（または０）であるとＰＶＣがインアクティブ（使用不可能），「Ａ」（または１）であるとアクティブ（使用可）であることを表す。端末側は，これを識別することにより全ての使用ＰＶＣの状態を確認することができる。なお，端末側では，前回のフルステータスメッセージ（ＳＴ−Ｆ）を保持しており，今回受け取ったフルステータスメッセージの内容と比べることにより，前回存在していたＰＶＣが今回のメッセージに含まれていないと，そのＰＶＣが削除されたことを検出できる。
【０００９】
図１５には，レポート種別がリンク完全性確認を要求するメッセージ及び応答としてステータスメッセージ（ＳＴ）の送受信は図示省略されており，フルステータス表示を要求するＳＥ−Ｆがリンク完全性確認の問合わせより長い周期でフレームリレー端末ａ，ＦＲＡＤａ，フレームリレー端末ｂから，それぞれ上位（網側）の装置である，ＦＲＡＤａやフレームリレー交換機に対し送信される（図１５のａ，ｃ１，ｅ１）。これに対し，それぞれ相手装置からＳＴ−Ｆが返ってくる（図１５のｂ，ｄ１，ｆ１）。なお，ｂに示すＳＴ−Ｆ（１６，Ａ）は，ＤＬＣＩが１６であり，Ａによりアクティブであることを表示し，ｄ１，ｆ１も同様である。
【００１０】
このように状態確認が行われるが，フレームリレー端末ａとＦＲＡＤａの間の回線に障害が発生すると，フレームリレー端末ａ側ではＳＥ／ＳＥ−Ｆを送信してもＦＲＡＤａから応答（ＳＴ／ＳＴ−Ｆ）が返ってこないか，またはＦＲＡＤａ側はフレームリレー端末ａからＳＥ／ＳＥ−Ｆを受信しないので障害であることが分かるが，ＦＲＡＤａはこれをフレームリレー交換機に通知することができない。この場合，フレームリレー交換機９２は，フレームリレー端末ｂからのｅ２で示すＳＥ−Ｆの状態問合わせに対し，ｆ２で示す応答でＰＶＣのＤＬＣＩ＝４８はアクティブであることを表示している。これを確認したフレームリレー端末ｂが，フレームリレー端末ａと接続するＰＶＣによりフレームｇを送信すると，フレームリレー交換機９２を介してＦＲＡＤａまで送信できるが，ＦＲＡＤａからフレームリレー端末ａの回線が障害となっているため，このフレームをフレームリレー端末ａへ送信できずに廃棄されることになる。
【００１１】
図１６，図１７は従来例２の接続形態とＰＶＣ状態確認の制御シーケンス（その１），（その２）である。この制御シーケンスでも，レポート種別がリンク完全性確認を要求するメッセージ及び応答としてステータスメッセージ（ＳＴ）の送受信は図示省略されている。
【００１２】
図１６，図１７において，９０，９３は上記図１５と同様にそれぞれフレームリレー端末ａ，フレームリレー端末ｂ，９４はＦＲＡＤ，９５は公衆フレームリレー網，９６はプライベートフレームリレー網である。この接続において，フレームリレー端末ａとフレームリレー端末ｂ間のＰＶＣは，図に示すように，ＤＬＣＩ１６，ＤＬＣＩ３２，ＤＬＣＩ４８，ＤＬＣＩ６４の各ＤＬＣＩが設定されている。
【００１３】
この従来例２のケースでは，プライベートフレームリレー網９６，ＦＲＡＤ９４はＤＴＥ（データ端末装置），公衆フレームリレー網９５はＤＣＥ（回線終端装置）として動作し，フレームリレー端末ａはＦＲＡＤ９４に対し，ＦＲＡＤ９４は公衆フレームリレー網９５に対し，プライベートフレームリレー網９６は公衆フレームリレー網９５に対し，フレームリレー端末ｂはプライベートフレームリレー網９６に対し，それぞれフルステータス表示を要求する問合わせを行っている。図１６に示すように，フレームリレー端末ａとＦＲＡＤ９４の間の回線障害が発生した場合，フレームリレー端末ｂは２度のＳＴ−Ｆ（ｇ１，ｇ２）の送信に対し，アクティブのフルステータス表示（ｈ１，ｈ２）を受け取っているので，フレームリレー端末ａへのフレームｉを送信するが，ＦＲＡＤ９４で廃棄されてしまう。
【００１４】
この後，図１７のシーケンスに移ってフレームリレー端末ａとＦＲＡＤ９４の間の回線障害が回復した時，フレームリレー端末ｂとプライベートフレームリレー網９６間で回線障害が発生した場合，フレームリレー端末ａは，フルステータスの状態問合わせ（ａ２）に対するステータス表示（ｂ２）によりＤＬＣＩ＝１６がアクティブであることを確認すると，フレームリレー端末ｂへフレームを送信する。この場合，プライベートフレームリレー網９６において，フレームリレー端末ｂへの送信できないため，フレームは廃棄される。
【００１５】
【発明が解決しようとする課題】
上記の従来例１では，上記のＩＴＵ−Ｔ勧告Ｑ．９３３ＡＮＮＥＸＡで規定されるＰＶＣ状態確認手順によると，図１５に示す従来例１のＦＲＡＤａがＤＴＥとして動作するため，ＦＲＡＤａ配下の端末が回線障害になってＰＶＣが動作不可能な状態になっても，報告することができず，フレームリレー交換機とＦＲＡＤａ間のリンク完全性確認手順が正常であれば，相手端末に対しフルステータス表示の問合わせに対しＰＶＣが動作可能（アクティブ）と通知されてしまい，フレームが送信されても廃棄されるという問題がある。
【００１６】
同様に，従来例２の場合も，プライベートフレームリレー網，ＦＲＡＤがＤＴＥ，公衆フレームリレー網がＤＣＥとして動作するため，プライベートフレームリレー網配下のＰＶＣ状態がＦＲＡＤに，ＦＲＡＤ配下のＰＶＣ状態がプライベートフレームリレー網に報告されないため，ＦＲＡＤ配下の端末や，プライベートフレームリレー網配下の端末に回線障害が発生して動作不可能な状態になっても，公衆フレームリレー網とプライベートフレームリレー網，公衆フレームリレー網とＦＲＡＤ間のリンク完全性確認の手順が正常であれば，フルステータス表示の状態問合わせに対し，相手端末に動作可能と通知してしまう。
【００１７】
本発明はフレームリレー端末とＦＲＡＤ間の回線障害や，プライベートフレームリレー網とフレームリレー端末間の回線障害時にＰＶＣのインアクティブが，公衆フレームリレー網や，プライベートフレームリレー網に対し報告されないことによるフレーム廃棄の発生を防止することができるフレームリレー交換機とＦＲＡＤ間のＰＶＣ状態確認手順制御方式を提供することを目的とする。
【００１８】
また，フレームリレー端末とＦＲＡＤ間や，プライベートフレームリレー網とフレームリレー端末間のＰＶＣ状態情報要素で報告する新規ＰＶＣ（Ｎビット）の報告や，ＰＶＣ削除の報告についても同様に公衆フレームリレー網やプライベートフレームリレー網に対し報告できないという問題を解決することを目的とする。
【００１９】
【課題を解決するための手段】
本発明はフレームリレー交換機とＦＲＡＤ間のＰＶＣ状態確認手順として，双方向網手順を使用してフレームリレー交換機とＦＲＡＤ間の双方からＰＶＣ有効性の報告を可能とするものである。なお，この双方向網手順は，ＩＴＵ−Ｔ勧告Ｑ．９３３ＡＮＮＥＸＡでＵＮＩ（ユーザ・ネットワーク・インタフェース）でオプションとして規定されているが，本発明はその手順をＦＲＡＤとフレームリレー交換機の場合に使用するものである。
【００２０】
また，本発明はこのフレームリレー交換機とＦＲＡＤ間の双方向網手順を使用して，新規ＰＶＣの報告や，削除ＰＶＣの報告を行うものである。
更に，本発明はプライベートフレームリレー網に対しＦＲＡＤが公衆フレームリレー網を経由して接続される場合に，プライベートフレームリレー網とＦＲＡＤ間で直接ＰＶＣ状態確認手順を実施するためのＰＶＣを公衆フレームリレー網に設定して双方向網手順を両者の間で行い，ＰＶＣ有効性の報告をＦＲＡＤからプライベートフレームリレー網に通知することを可能とするものである。
【００２１】
図１は本発明による第１の原理構成図である。
図１において，１はフレームリレー端末ａ，２はＦＲＡＤａ，２ａはフレームリレー交換機３に対しフルステータスの問合せを開始して応答を受信する処理を行う状態問合わせ開始手段，２ｂは配下の端末からのフルステータスの状態問合せに対し状態表示の応答を送信する処理を行う端末間状態問合せ応答手段，２ｃはフレームリレー交換機からの問合せに対しフルステータスの問合せに対し応答を送信する処理を行う状態問合せ応答手段，３は公衆網または私設網の何れかのフレームリレー交換機，３ａはＦＲＡＤに対しフルステータスの状態問合せを開始して応答を受け取る処理を行う状態問合わせ開始手段，３ｂは端末からの状態問合せに対し応答を送信する処理を行う端末間状態問合せ応答手段，３ｃはＦＲＡＤからの状態問合せを受け取ると状態表示の応答を返す状態問合せ応答手段，４はフレームリレー端末ｂである。
【００２２】
フレームリレー端末（以下，単に端末という）ａとｂを結ぶＰＶＣは，端末ａとＦＲＡＤａ間のＤＬＣＩが「１６」，ＦＲＡＤａとフレームリレー交換機３間のＤＬＣＩが「３２」，フレームリレー交換機３と端末ｂ間のＤＬＣＩが「４８」であり，各装置の間のインタフェースは全てＵＮＩ（ユーザ・ネットワーク・インタフェース）である。なお，図１の構成において，ＦＲＡＤａの２ｃ，フレームリレー交換機３の３ａは，逆方向の状態問合せを行うために新たに設けられた手段である。
【００２３】
図１において，ＦＲＡＤａ２及びフレームリレー交換機３はそれぞれ従来と同様に端末間状態問合せ応答手段２ｂ，３ｂにより各フレームリレー端末（以下，単に端末という）ａ，ｂからの状態問合せに対し応答すると共に，端末との回線の状態（障害発生）を検出する。また，ＦＲＡＤａは網側装置（ＤＣＥ）であるフレームリレー交換機３に対し端末装置（ＤＴＥ）として従来と同様に，状態問合せ開始手段２ａにより状態問合せを行い，フレームリレー交換機３の状態問合せ応答手段３ｃにより応答を行うことで，ＦＲＡＤａとフレームリレー交換機３の間のＤＬＣＩ及びフレームリレー交換機３と端末ｂの間のＤＬＣＩの状態を識別することがてきる。
【００２４】
これと逆方向の状態問合せを行うために，本発明により，フレームリレー交換機３に状態問合せ開始手段３ａを設け，その状態問合せに対し応答するためにＦＲＡＤａに状態問合せ応答手段２ｃを設けた。この逆方向の状態問合せを行うことにより，フレームリレー交換機３は端末ａの回線状態を含むＰＶＣ状態を得ることができ，この状態を端末ｂからの状態問合せ時に通知することができる。なお，応答により通知される状態の中には，ＰＶＣのアクティブ，インアクティブだけでなく，ＰＶＣの追加（新規），ＰＶＣの削除等も含まれる。
【００２５】
図２は本発明による第２の原理構成図である。図２において，１，４は上記図１の同じ符号と同様のフレームリレー端末ａ，ｂであり，５はＦＲＡＤｃ，６は公衆フレームリレー網，７はプライベートフレームリレー網（具体的にはその中の交換機）である。ＦＲＡＤｃの５ａ，５ｂは上記図１のＦＲＡＤａ内の２ａ，２ｂと同様であり説明を省略する。５ｃはＦＲＡＤ間状態問合せ開始手段，５ｄはＦＲＡＤ間状態問合せ応答手段である。なお，プライベートフレームリレー網７は，公衆フレームリレー網６からみるとＦＲＡＤに相当するため，ＦＲＡＤｃとプライベートフレームリレー網７との間をＦＲＡＤ間と呼ぶ。公衆フレームリレー網６の６ａは状態問合せ応答手段６ａであり，プライベートフレームリレー網７の７ａ，７ｂは前記ＦＲＡＤｃの５ａ，５ｂに対応し，７ｃ，７ｄは上記ＦＲＡＤｃの５ｃ，５ｄに対応する。
【００２６】
この例では，通常のユーザデータの通信用のＰＶＣとして，端末ａとＦＲＡＤｃ間のＤＬＣＩが「１６」，ＦＲＡＤｃと公衆フレームリレー網６間のＤＬＣＩが「３２」，公衆フレームリレー網６とプライベートフレームリレー網７間のＤＬＣＩが「４８」，プライベートフレームリレー網７と端末ｂ間のＤＬＣＩが「６４」であり，各装置の間のインタフェースは全てＵＮＩである。また，ＦＲＡＤｃの５ｃ，５ｄ及びプライベートフレームリレー網７の７ｃ，７ｄは，この発明によりＦＲＡＤｃとプライベートフレームリレー網７の間で双方向の状態確認を行うために設けられた手段である。
【００２７】
図２のＦＲＡＤｃとプライベートフレームリレー網７の状態問合せ開始手段５ａ，７ａはそれぞれ網側装置である公衆フレームリレー網６に対し上記図１のＦＲＡＤａの２ａと同様に状態問合せを行い，公衆フレームリレー網６の状態問合せ応答手段６ａからの応答を受け取ることによりそれぞれ公衆フレームリレー網６とプライベートフレームリレー網７の間のＰＶＣの状態及びＦＲＡＤｃと公衆フレームリレー網６間のＰＶＣの状態を識別できる。この発明では，ＦＲＡＤｃとプライベートフレームリレー網７により，それぞれ相手側の端末の状態（回線状態）を識別するための，ＦＲＡＤ間の双方向の状態問合せ用のＰＶＣを，公衆フレームリレー網６に予め設定しておく。図２の例では，ＦＲＡＤｃと公衆フレームリレー網６間のＤＬＣＩが「１」で，公衆フレームリレー網６とプライベートフレームリレー網７間のＤＬＣＩが「２」である。
【００２８】
ＦＲＡＤｃ及びプライベートフレームリレー網７のＦＲＡＤ間状態問合せ開始手段５ｃ，７ｃは，このＦＲＡＤ間の状態問合せ用のＰＶＣを介して状態問合せを行うと相手方のＦＲＡＤ間状態問合せ応答手段５ｄ，７ｄによりＦＲＡＤｃやプライベートフレームリレー網７において，ＤＬＣＩを識別して，本来のユーザデータの通信用のＰＶＣのＤＬＣＩに接続する配下の端末の回線状態を含む状態情報をＦＲＡＤ間状態問合せ用のＰＶＣを介して応答する。この応答を受信することにより，相手ＦＲＡＤ（またはプライベートフレームリレー網）に接続する端末の状態を識別することができる。
【００２９】
上記の図２の説明では，公衆フレームリレー網６にＦＲＡＤ間状態問合せ用のＰＶＣを設定しているが，新たなＰＶＣを設定せずに，既存のＰＶＣ（ＦＲＡＤｃと公衆フレームリレー網６の間はＤＬＣＩ「３２」，公衆フレームリレー網６とプライベートフレームリレー網７の間はＤＬＣＩ「４８」を使用したＰＶＣ）を使用して，フレーム内にフレーム識別情報を設け，そこに通常フレームかＰＶＣ状態確認用フレームかの識別情報を設定するようにしてもよい。
【００３０】
【発明の実施の形態】
図３は本発明の第１の制御シーケンスの例であり，上記図１に示す構成における各装置間の相互の制御動作の例を示す。
【００３１】
図３に示す端末ａからＦＲＡＤａに対しＳＥ−Ｆ（フルステータス要求のメッセージ，以下，単にＳＥ−Ｆという）が送信され，ＦＲＡＤａでこれを受信すると，端末間状態問合せ応答手段２ｂにより従来と同様にＳＴ（フルステータス表示の応答メッセージ，以下，単にＳＴという）が送り返される（図３のａ１，ｂ１）。この端末間状態問合せ応答手段２ｂは，端末からのＳＥ−Ｆ（またはリンク完全性確認の問合せ）が一定周期で来ないと，回線障害であることを検出できる。
【００３２】
一方，ＦＲＡＤａは，従来と同様に状態問合せ開始手段２ａが動作してフレームリレー交換機３へのＳＥ−Ｆの送信と，フレームリレー交換機３の状態問合応答手段３ｃの処理により送られてくるＳＴ−Ｆを受信してＰＶＣの状態を検出する（ｃ１，ｄ１）。また，フレームリレー交換機３は，状態問合せ開始手段３ａによりＦＲＡＤａに対しＳＥ−Ｆを送出し，ＦＲＡＤａが状態問合せ応答手段２ｃの動作によりＳＴ−Ｆ（端末ａとＦＲＡＤａ間のＰＶＣ状態を含む）を受け取る。この場合，フレームリレー交換機３は端末（ＤＴＥ）として動作するのと同じである。
【００３３】
図３に示すように端末ａとＦＲＡＤａ間で回線障害が発生すると，フレームリレー交換機３からのｅ２で示すＳＥ−Ｆに対し，ＦＲＡＤａからｆ２で示すＳＴ−Ｆ（３２，Ｉ）が送られる。このＳＴは，ＤＬＣＩ３２は，インアクティブ（Ａ＝１に表示）であることを表示する。この後，フレームリレー交換機３が端末ｂからｇ２で示すＳＥ−Ｆを受け取ると，ＤＬＣＩ３２がインアクティブであるため，このＰＶＣを構成するＤＬＣＩ４８についても，インアクティブであることを表示するＳＴ−Ｆ（４８，Ｉ）を端末ｂへ通知する。これにより，端末ｂは端末ａへのフレームの送信を止める。こうして，従来の技術では，端末ｂに端末ａの状態が報告されないことによりフレームの送信が行われて，途中で廃棄される事態の発生を防止することができる。
【００３４】
図４，図５は本発明による第２の制御シーケンスの例（その１），（その２）であり，上記図２に示す構成における各装置間の相互の制御動作の例を示す。
図２を参照しながら説明すると，予めＦＲＡＤｃとプライベートフレームリレー網７の間で，直接ＰＶＣ状態確認手順を実施するためのＰＶＣを公衆フレームリレー網６に設定する。そのＰＶＣは上記したように，ＦＲＡＤｃと公衆フレームリレー網６の間のＤＬＣＩが「１」で，公衆フレームリレー網６とプライベートフレームリレー網７の間のＤＬＣＩが「２」である。
【００３５】
端末ａとＦＲＡＤｃ間及びプライベートフレームリレー網７と端末ｂの間の状態確認の問合せＳＥ−Ｆはそれぞれ端末側から従来と同様に開始され，端末間状態問合せ応答手段５ｂ，７ｂにより対応する端末へＳＴが送られる（図４のａ１，ｂ１，ｇ１，ｈ１等）。また，この端末間状態問合せ応答手段５ｂ，７ｂにより対応する端末側の回線障害の検出をリンク完全性確認（従来のシーケンス番号による）手順により行うことができる。また，ＦＲＡＤｃとプライベートフレームリレー網７は，それぞれ端末（ＤＴＥ）として公衆フレームリレー網６に対し，状態問合せ開始手段５ａ，７ａから開始し，状態問合せ開始手段５ａは公衆フレームリレー網６から，公衆フレームリレー網６とプライベートフレームリレー網７間のＰＶＣ状態を受け取り，状態問合せ開始手段７ａは公衆フレームリレー網６から，公衆フレームリレー網６とＦＲＡＤｃ間のＰＶＣ状態を受け取る。
【００３６】
また，ＦＲＡＤｃ及びプライベートフレームリレー網７のＦＲＡＤ間状態問合せ開始手段５ｃ，７ｃはそれぞれ，相手ＦＲＡＤ（またはプライベートフレームリレー網）との間でＰＶＣ状態確認を行うため，対応するＰＶＣのＤＬＣＩ（ＤＬＣＩ１または２）をテーブル（後述するＰＶＣ管理テーブル）から取り出し，相手ＦＲＡＤ（またはプライベートフレームリレー網）の番号や公衆フレームリレー網６の回線番号を指定して，ＦＲＡＤ間ＰＶＣ状態確認用の種別等を含む状態問合せＳＥ−Ｆを送信する。
【００３７】
これを受けた，相手ＦＲＡＤｃまたはプライベートフレームリレー網７のＦＲＡＤ間状態問合せ応答手段５ｄ，７ｄはそれぞれ種別によりＦＲＡＤ間状態問合せであることを識別し，テーブルを参照して上記テーブルから本来のユーザデータ用のＰＶＣのＤＬＣＩを求めて，その状態情報を相手側のＦＲＡＤ（プライベートフレームリレー網）に向けて送信する。この場合も，ＦＲＡＤ間状態問合せ用のＰＶＣを用いて公衆フレームリレー網を介して送られる。このやりとりは，図４のｉ１，ｊ１及びｋ１，ｌ（エル）１により行われる。
【００３８】
図４において，端末ａとＦＲＡＤａ間の回線障害が発生した場合，その後ＦＲＡＤａでは，端末ａからの状態問合せ（リンク完全性確認またはフルステータス表示）が一定時間以上無いことにより障害になっていることを検出する。この状態（ユーザデータ通信用のＰＶＣがＤＬＣＩ「１６」の部分で使用不可となっている状態）は，図５のｋ２で示すプライベートフレームリレー網７からのＦＲＡＤ間状態問合せ（ＳＥ−Ｆ）に対し，ＦＲＡＤｃからのｌ（エル）２で示す応答（ＳＴ−Ｆ（３２，Ｉ）：ＤＬＣＩ「３２」がインアクティブであることを表す）により通知することができる。この応答を識別すると，プライベートフレームリレー網７はその後に端末ｂからのｇ２に示す状態問合せ（ＳＥ−Ｆ）に対し，ｈ２で示す応答（ＳＴ−Ｆ（６４，Ｉ）：ＤＬＣＩ「６４」がインアクティブであることを表示）を返す。
【００３９】
その後，端末ｂの回線に障害が発生して，端末ａの回線障害が回復した場合，プライベートフレームリレー網７において，端末ｂからの状態問合せ（リンク完全性確認またはフルステータス表示）が一定時間以上ないことにより端末ｂの回線に障害が発生したことを検出する。これによりＦＲＡＤｃからのＦＲＡＤ間状態問合せ用のＰＶＣを用いたＦＲＡＤ間状態問合せが，図５のｉ３に示すようにプライベートフレームリレー網７へ送られると，プライベートフレームリレー網７で端末ｂとの回線が障害であるために，ｊ３で示すような応答（ＳＴ−Ｆ（３２，Ｉ）：ＤＬＣＩ「３２」はインアクティブであることを表示）を返す。その後，端末ａがａ２で示す状態問合せ（ＳＥ−Ｆ）を行うと，ＦＲＡＤｃは先のｊ３の応答結果に基づいて，ＤＬＣＩ「１６」がインアクティブであることを表す応答（ＳＴ（１６，Ｉ））を端末ａに送信する。これにより，端末ａは，回線障害が発生した端末ｂへの送信を止める。
【００４０】
上記図４，図５の説明ではＦＲＡＤ間状態問合せ用のＰＶＣを新たに契約して設定しているが，料金の関係等でこの方法を採用できない場合には，契約済の既存のＰＶＣ（図２のＤＬＣＩ「３２」，ＤＬＣＩ「４８」）を使用して，ＦＲＡＤ間状態確認手順用のフレームを送受信することができ，図６にそのフォーマットを示す。
【００４１】
図６はＦＲＡＤ，公衆フレームリレー網及びプライベートフレームリレー網間で送信されるフレームのフォーマットである。このフォーマットにおいて，ａはフラグ，ｂはアドレスフィールド，ｃはフレーム識別部であり，この中の１ビットを使用して，“０”が通常フレーム，“１”がＰＶＣ状態確認手順用フレームを表示する。その後の領域であるｄにユーザデータ（通常フレームの場合）か，Ｑ．９３１メッセージ（ＰＶＣ状態確認手順用フレームの場合）が選定される。
【００４２】
また，ｅはＦＣＳ，ｆはフラグである。このフレームを用いてＰＶＣ状態問合せを行う場合，公衆フレームリレー網６では，既存のＰＶＣを介して相手側のＦＲＡＤに送信する。相手側のＦＲＡＤで，フレームの中のフレーム識別部を判別して，ユーザデータ内のＱ．９３１メッセージを確認の問合せとして処理し，対応する応答を同様のフォーマットにより，問合せを開始したＦＲＡＤへ送信する。
【００４３】
図７はフレームリレー交換機の構成図である。このフレームリレー交換機の構成は，上記図２に示すＦＲＡＤｃ及びプライベートフレームリレー網７内の交換機に相当する。また，このフレームリレー交換機の構成には，上記図１に示すＦＲＡＤａ及びフレームリレー交換機３と共通の構成が含まれている（ＦＲＡＤ間ポーリング開始手順処理部１６，ＦＲＡＤ間ポーリング応答手順処理部１７及びこれらの処理に関連するテーブルを除く）。
【００４４】
図７において，１０はフレームリレー交換サービスを実行するフレームリレー交換機，１１はＣＣＩＴＴ勧告Ｑ．９２２，Ｑ．９３３に従い，ユーザとのフレーム送受信処理及びフレームリレー交換機間のフレーム送受信処理を行うフレームリレー交換処理部である。なお，フレームリレー交換処理部１１を構成する，各処理部１２〜１７のプログラムは交換機のメインメモリに格納される。
【００４５】
１２はフレーム受信処理部であり，その機能は，端末からのフレーム受信時，ＤＬＣＩ＝０の場合，ＰＶＣ状態確認用のフレームと認識し，フレームの分析処理を続行し，ステータス（ＳＴ）メッセージの場合は，ポーリング（ＰＶＣ状態確認の問合せを意味する）開始手順処理部１４（後述する）を起動し，ステータスＥＮＱ（状態問合せ：ＳＥ）メッセージの場合は，ポーリング応答手順処理部１５（後述する）を起動する。また，ＤＬＣＩ≠０の場合，回線番号とＤＬＣＩ番号からＰＶＣ管理テーブル２０（後述する）を参照し，ＰＶＣ識別表示を求める。ＰＶＣ識別表示がＦＲＡＤ間ＰＶＣ状態確認手順用であることが分かると，フレームの分析を行い，ステータスメッセージの場合は，ＦＲＡＤ間ポーリング開始手順処理部１６を起動し，ステータスＥＮＱ（状態問合せ）メッセージの場合は，ＦＲＡＤ間ポーリング応答手順処理部１７を起動する。
【００４６】
１３はフレーム送信処理部であり，ポーリング開始手順処理部１４，ポーリング応答手順処理部１５，ＦＲＡＤ間ポーリング開始手順処理部１６，ＦＲＡＤ間ポーリング応答手順処理部１７から起動され，各処理部から送信依頼されたＰＶＣ状態確認手順用のＱ．９３１メッセージ（ステータスメッセージ：ＳＴ，ステータス問合せメッセージ：ＳＥ）を回線に対して送信する。
【００４７】
１４はポーリング開始手順処理部であり，フレームリレー交換機１０とＦＲＡＤ装置が直接接続される場合（図１の場合）は，ＦＲＡＤとの間でＩＴＵ−Ｔ勧告Ｑ．９３３ＡＮＮＥＸＡで規定するＰＶＣ状態確認手順のポーリング開始手順の処理を行う。
【００４８】
１５はポーリング応答手順処理部であり，フレームリレー交換機とＦＲＡＤ装置が直接接続される場合（図１の場合）は，ＦＲＡＤとの間でＩＴＵ−Ｔ勧告Ｑ．９３３ＡＮＮＥＸＡで規定するＰＶＣ状態確認手順のポーリング応答手順の処理を行う。なお，端末からのポーリング開始手順に対しても応答手順の処理を行う。
【００４９】
１６はＦＲＡＤ間ポーリング開始手順処理部であり，公衆フレームリレー網経由でＦＲＡＤと接続されている場合（図２の場合）に，ＦＲＡＤとの間でＩＴＵ−Ｔ勧告Ｑ．９３３ＡＮＮＥＸＡで規定するＰＶＣ状態確認手順のポーリング開始手順の処理を行う。なお，ＤＬＣＩ番号はＦＲＡＤ間ＰＶＣ状態確認手順用ＤＬＣＩ管理テーブル２４（後述する）に登録されているＤＬＣＩ番号を使用する。
【００５０】
１７はＦＲＡＤ間ポーリング応答手順処理部であり，公衆フレームリレー網経由でＦＲＡＤと接続されている場合にＦＲＡＤとの間でＩＴＵ−Ｔ勧告Ｑ．９３３ＡＮＮＥＸＡで規定するＰＶＣ状態確認手順のポーリング応答手順の処理を行う。なお，ＤＬＣＩ番号はＦＲＡＤ間ＰＶＣ状態確認手順用ＤＬＣＩ管理テーブルに登録されているＤＬＣＩ番号を使用する。
【００５１】
次に１８〜２４の各符号が付されたテーブルを，図８乃至図１４を参照しながら説明する。
１８はリンク状態管理テーブルであり，その構成図を図８に示す。
【００５２】
このリンク状態管理テーブルは，図８に示すように回線番号によりインデックスされ，フレームリレー交換機と直接回線で接続されるＦＲＡＤ，または公衆フレームリレー網との間で実施するＰＶＣ状態確認手順の動作モード（ａで示す），ポーリング開始手順リンク状態（ｂで示す），ポーリング応答手順リンク状態（ｃで示す）を保持する。ａの動作モードは，該当する回線のＰＶＣ状態確認手順の動作モードを表し，次の何れかのモードが設定される。
【００５３】
▲１▼ＤＴＥモード（端末として動作し，ポーリング開始手順だけを行う）
▲２▼ＤＣＥモード（網として動作し，ポーリング応答手順だけを行う）
▲３▼双方向モード（ポーリング開始手順ならびにポーリング応答手順を行う）
ｂのポーリング開始手順リンク状態は，ポーリング開始手順におけるリンク完全性確認状態（上記した送信，受信シーケンス番号による確認）を示し，正常状態かエラー状態かを表す。但し，この情報は動作モードがＤＴＥモードか双方向モードの場合に有効である。
【００５４】
ｃのポーリング応答手順リンク状態は，ポーリング応答手順におけるリンク完全性確認状態を示し，正常状態，エラー状態を表す。但し，この情報は動作モードがＤＣＥモードか双方向モードの場合に有効である。
【００５５】
１９はＰＶＣ状態管理テーブルであり，その構成図を図９に示す。
このＰＶＣ状態管理テーブルは，図９に示すように，回線番号×ＤＬＣＩ番号でインデックスされ，登録表示ａ，Ｎビット送信状況ｂ，Ｎビット受信状況ｃ，Ａビット受信状況ｄを保有する。ａの登録表示は，当該ＤＬＣＩに対してＰＶＣが登録されているか否かを示し，ｂのＮビット送信状況は，ポーリング応答手順におけるＮビット（新規のＰＶＣを追加したことを表示するビット）の送信状況を示し，次の３つの状況がある。▲１▼Ｎビット＝１未送信，▲２▼Ｎビット＝１送信済で相手確認待ち，▲３▼Ｎビット＝１送信済で相手確認済である。
【００５６】
図９のｃのＮビット受信状況は，ポーリング開始手順におけるＮビット受信状況を示し，次の２つの状況がある。▲１▼Ｎビット＝１未受信（ＰＶＣ状態情報要素無しを含む），▲２▼Ｎビット＝１受信済である。更に，ｄのＡビット受信状況は，ポーリング開始手順におけるＡビット（リンクがアクティブかインアクティブかを表す）の受信状況を示し，▲１▼Ａビット＝０受信（インアクティブ），▲２▼Ａビット＝１受信（アクティブ）の何れかである。
【００５７】
図７の２０はＰＶＣ管理テーブルであり，その構成図を図１０に示す。
このＰＶＣ管理テーブルは，図１０に示すように，回線番号，ＤＬＣＩ番号でインデックスされ，ＰＶＣ識別表示ａ，ＰＶＣの相手情報有効表示ｂ，相手回線番号ｃ，相手ＤＬＣＩ番号ｄ，また公衆フレームリレー網経由でＦＲＡＤと接続される場合は，その表示ｅ，ＦＲＡＤ番号ｆ及びＦＲＡＤ側ＤＬＣＩ番号ｇを保有する。
【００５８】
上記ａのＰＶＣ識別表示は，当該ＰＶＣが次の２つの何れの用途であるかを表示する。すなわち，▲１▼通常ＰＶＣ用か，▲２▼ＦＲＡＤ間ＰＶＣ状態確認手順用かの何れかである。次のｂの相手情報有効表示は，相手回線番号，相手ＤＬＣＩ番号が有効か否かを示す。また，ｃの相手回線番号は，ＰＶＣの相手回線番号を示し，ｄの相手ＤＬＣＩ番号は，ＰＶＣの相手ＤＬＣＩ番号を示す。ｅの公衆フレームリレー網経由ＦＲＡＤ接続表示は，公衆フレームリレー網経由でＦＲＡＤに接続されるＰＶＣであるかを示す。また，ｆのＦＲＡＤ番号は，公衆フレームリレー網経由で接続されるＦＲＡＤ番号を示し，ｇのＦＲＡＤ側ＤＬＣＩ番号は，公衆フレームリレー網間のＤＬＣＩ番号を示す。
【００５９】
図７の２１はＦＲＡＤ間リンク状態管理テーブルであり，その構成図を図１１に示す。
このＦＲＡＤ間リンク状態管理テーブルは，図１１に示すようにＦＲＡＤ番号でインデックスされ，ＦＲＡＤとの間で実施するＰＶＣ状態確認手順の動作モードａ，ポーリング開始手順リンク状態ｂ，ポーリング応答手順リンク状態ｃを保有する。ａ〜ｃに設定される内容は，上記図８に示すリンク状態管理テーブルと同様であり，説明を省略する。但し，この場合のリンク状態は公衆フレームリレー網を介した他のＦＲＡＤとの間のＰＶＣのリンク状態に関する。
【００６０】
図７の２２はＦＲＡＤ間ＰＶＣ状態管理テーブルであり，その構成図を図１２に示す。
このテーブルは，図１２に示すように，ＦＲＡＤ番号，ＤＬＣＩ番号でインデックスされ，登録表示ａ，Ｎビット送信状況ｂ，Ｎビット受信状況ｃ，Ａビット受信状況ｄを保有する。このテーブルのａ〜ｄに設定される内容は，上記図９に示すＰＶＣ状態管理テーブルと同様であり，説明を省略する。但し，この場合のＰＶＣ状態は，公衆フレームリレー網を介した他のＦＲＡＤとの間のＰＶＣに関する。
【００６１】
図７の２３はＦＲＡＤ間ＰＶＣ管理テーブルであり，その構成図を図１３に示す。
このテーブルは，図１３に示すように，ＦＲＡＤ番号，ＤＬＣＩ番号でインデックスされ，ＰＶＣ識別表示ａ，公衆フレームリレー網と接続している回線番号ｂ，ＤＬＣＩ番号ｃを保有する。ａのＰＶＣ識別表示は，通常ＰＶＣ用か，ＦＲＡＤ間ＰＶＣ状態確認手順用かを示し，ｂの回線番号はプライベートフレームリレー網が公衆フレームリレー網と接続している回線番号を示し，ＤＬＣＩ番号はプライベートフレームリレー網と公衆フレームリレー網間のＤＬＣＩ番号を示す。
【００６２】
図７の２４はＦＲＡＤ間ＰＶＣ状態確認手順用ＤＬＣＩ管理テーブルであり，その構成図を図１４に示す。
このテーブルは，ＦＲＡＤ番号でインデックスされ，ＦＲＡＤとの間でＰＶＣ状態確認手順を実施するＤＬＣＩ番号を保有する。
【００６３】
上記のような各処理部と各テーブルを備えた図７に示すフレームリレー交換機が，上記図２に示すプライベートフレームリレー網の交換機として動作する例を説明する。但し，プライベートフレームリレー網とＦＲＡＤとのＰＶＣ状態確認手順において，ＤＬＣＩ番号の変更はプライベートフレームリレー網側（図７のフレームリレー交換機）で実施する。なお，このＤＬＣＩ番号の変更は，上記図２に関して説明した，図２のＦＲＡＤｃが公衆フレームリレー網とＦＲＡＤ間のＰＶＣ状態確認用に契約したＤＬＣＩ番号と，プライベートフレームリレー網が公衆フレームリレー網とＦＲＡＤ間のＰＶＣ状態確認用に契約したＤＬＣＩ番号に相違があるため，何れか一方で変換処理を行う。
【００６４】
ポーリング開始手順及びポーリング応答手順については，ＩＴＵ−Ｔ勧告Ｑ．９３３ＡＮＮＥＸＡで規定されている通りに従来と同様に行われ，説明を省略する。
【００６５】
以下に，主としてＦＲＡＤ間のＰＶＣ状態確認手順（図４，図５参照）に関して，図７に示すフレームリレー交換機の処理を説明する。この場合，図２，図４に示すように，通常の通信要求のＰＶＣ（ＤＬＣＩ１６，３２，４８，６４とで構成）の他にＦＲＡＤ間のＰＶＣ状態確認手順用のＰＶＣ（ＤＬＣＩ１とＤＬＣＩ２で構成）が公衆フレームリレー網に設定（契約）されているものとする。
【００６６】
フレームリレー交換機は，ポーリング開始手順処理部１４がフレーム送信処理部１３に送信依頼して公衆フレームリレー網（図２の６）に対して送信した状態問合せ（ＳＥ：STATUS ENQUIRY) メッセージ（レポート種別＝フルステータス）に対して，公衆フレームリレー網から状態表示メッセージ（ＳＴ−Ｆ）を受信するとフレーム受信処理部１２でＤＬＣＩ＝０且つＱ．９３１メッセージ種別を分析することで，状態表示メッセージ（STATUS）と認識し，ポーリング開始手順処理部１４を起動する。ポーリング開始手順処理部１４は，状態表示メッセージの情報要素を分析し，ＤＬＣＩ＝４８のＰＶＣ状態情報要素内のＡビット＝１を，図９に示すＰＶＣ状態管理テーブル内のＡビット受信状況にＡ＝１受信を設定する。
【００６７】
次に，フレームリレー交換機は，ＦＲＡＤに対し状態問合せメッセージを送信する場合，図１４に示すＦＲＡＤ間ＰＶＣ状態確認手順用のＤＬＣＩ管理テーブル２４から，ＦＲＡＤとの間でＰＶＣ状態確認手順を行うためのＤＬＣＩ番号を求める。求めたＤＬＣＩ番号とＦＲＡＤ番号から図１３に示すＦＲＡＤ間ＰＶＣ管理テーブル２３から公衆フレームリレー網と接続している回線番号とＤＬＣＩ番号を求めて，フレーム送信処理部に対して送信依頼し，フレームリレー送信処理部１３はＤＬＣＩ＝２とする状態要求メッセージ（ＳＥ）を公衆フレームリレー網に対して送信する。公衆フレームリレー網は，通常フレームの交換処理を行い，通信相手であるＦＲＡＤに対して状態問合せ（ＳＥ）を送信する。
【００６８】
ＦＲＡＤが送信した状態表示メッセージ（ＳＴ）を公衆フレームリレー網からＤＬＣＩ＝２のフレームとしてフレーム受信処理部１２が受信するとＤＬＣＩ＝０でないため，回線番号，ＤＬＣＩ番号から図１０に示すＰＶＣ管理テーブルのＰＶＣ識別表示を判定する。この判定でＦＲＡＤ間ＰＶＣ状態確認手順用であることが判別されるため，フレームの分析を継続し，Ｑ．９３１メッセージ種別が状態表示メッセージ（ＳＴ）であることからＦＲＡＤ間ポーリング開始手順処理部１６を起動する。ＦＲＡＤ間ポーリング開始手順処理部１６は，回線番号とＤＬＣＩ番号から，図１０に示すＰＶＣ管理テーブル内のＦＲＡＤ番号を求める。
【００６９】
また，ＦＲＡＤ間ポーリング開始手順処理部１６は，状態表示メッセージ（ＳＴ）の情報要素を分析し，ＤＬＣＩ＝３２のＰＶＣ状態情報要素内のＡビット＝０を図１２に示すＦＲＡＤ間ＰＶＣ状態管理テーブル内のＡビット受信状況にＡビット＝０受信を設定する。
【００７０】
次にフレームリレー端末ｂ（図２の４）に対してレポート種別がフルステータスの状態要求メッセージ（ＳＴ−Ｆ）を送信する場合，ポーリング応答手順処理部１５は，ＤＬＣＩ６４に対するＰＶＣ状態情報要素を編集するが，そのＡビットの値の編集は次のように行う。
【００７１】
まず，回線番号，ＤＬＣＩ番号から図１０に示すＰＶＣ管理テーブルを参照し，相手回線番号と相手ＤＬＣＩ番号を求める。これは，公衆フレームリレー網との接続回線番号とＤＬＣＩ番号である。また，求めた回線番号，ＤＬＣＩ番号から図１０に示すＰＶＣ管理テーブルを参照すると，公衆フレームリレー網経由ＦＲＡＤ接続表示が設定されているので，公衆フレームリレー網経由でＦＲＡＤに接続されたＰＶＣであると識別し，そのテーブルからＦＲＡＤ番号，ＦＲＡＤ側ＤＬＣＩ番号を求める。
【００７２】
こうして求めた回線番号，ＤＬＣＩ番号からＤＬＣＩ６４に対するＰＶＣ状態情報要素を編集するＡビットは，以下の全てを満足する場合だけＡビット＝１とする。
【００７３】
(1) フレームリレー端末ｂとのポーリング応答手順のリンク完全性確認が正常であること。これは，図８のリンク状態管理テーブル内のポーリング応答手順リンク状態ｃにより判定する。
【００７４】
(2) 公衆フレームリレー網からポーリング開始手順でＡビット＝１（アクティブ）を受信していること。これは，図９のＰＶＣ状態管理テーブル内のＡビット受信状況ｄにより判定する。
【００７５】
(3) 公衆フレームリレー網とのポーリング開始手順のリンク完全性確認が正常であること。これは，図８のリンク状態管理テーブル内のポーリング開始手順リンク状態ｂにより判定する。
【００７６】
(4) ＦＲＡＤｃ（図２の５）からポーリング開始手順でＡビット＝１を受信していること。これは図１２のＦＲＡＤ間ＰＶＣ状態管理テーブルのＡビット受信状況ｄにより判定する。
【００７７】
(5) ＦＲＡＤｃとのポーリング開始手順のリンク完全性確認が正常であること。これは図１１のＦＲＡＤ間リンク状態管理テーブルのポーリング開始手順リンク状態ｂにより判定する。
【００７８】
(6) ＦＲＡＤｃとのポーリング応答手順のリンク完全性確認が正常であること。これは，図１１のＦＲＡＤ間リンク状態管理テーブル内のポーリング応答手順リンク状態ｃにより判定する。
【００７９】
上記の図２，図４の構成でフレームリレー端末ａとＦＲＡＤｃの間が回線障害の場合には，上記の(4) でＡビット＝０（インアクティブ）を受信するため，ＤＬＣＩ＝６４に対するＰＶＣ状態情報要素のＡビットは０に設定される。状態表示メッセージ（ＳＴ）が編集されるとフレーム送信処理部１３が起動され，フレームリレー端末ｂに対して送信される。
【００８０】
【発明の効果】
本発明により以下のような効果を奏する。
(1) フレームリレー交換機，ＦＲＡＤの双方向でＰＶＣの有効性（アクティブ）の報告が可能となるためエンド端末に対して正確なＰＶＣ有効性の報告が可能となる。
【００８１】
(2) フレームリレー交換機とＦＲＡＤの双方向で新規ＰＶＣの報告が可能となるため，エンド端末に対してフレームリレー交換機, ＦＲＡＤの双方ともＰＶＣが登録された時点でエンド端末に対して新規ＰＶＣの報告が可能となる。
【００８２】
(3) フレームリレー交換機, ＦＲＡＤの双方向で削除ＰＶＣの報告が可能となるため，エンド端末に対してフレームリレー交換機，ＦＲＡＤの何れか一方のＰＶＣが削除された時点でエンド端末に対して削除ＰＶＣの報告をすることが可能となる。
【００８３】
(4) プライベートフレームリレー網とＦＲＡＤが公衆フレームリレー網を経由して接続した場合にも，上記(1) 〜(3) と同様の効果が得られる。
【図面の簡単な説明】
【図１】本発明の第１の原理構成図である。
【図２】本発明の第２の原理構成図である。
【図３】本発明の第１の制御シーケンスの例である。
【図４】本発明による第２の制御シーケンスの例（その１）を示す図である。
【図５】本発明による第２の制御シーケンスの例（その２）を示す図である。
【図６】ＦＲＡＤ，公衆フレームリレー網及びプライベートフレームリレー網間で送信されるフレームのフォーマットを示す図である。
【図７】フレームリレー交換機の構成図である。
【図８】リンク状態管理テーブルの構成図である。
【図９】ＰＶＣ状態管理テーブルの構成図である。
【図１０】ＰＶＣ管理テーブルの構成図である。
【図１１】ＦＲＡＤ間リンク状態管理テーブルの構成図である。
【図１２】ＦＲＡＤ間ＰＶＣ状態管理テーブルの構成図である。
【図１３】ＦＲＡＤ間ＰＶＣ管理テーブルの構成図である。
【図１４】ＦＲＡＤ間ＰＶＣ状態確認手順用ＤＬＣＩ管理テーブルの構成図である。
【図１５】従来例１の接続形態とＰＶＣ状態確認の制御シーケンスを示す図である。
【図１６】従来例２の接続形態とＰＶＣ状態確認の制御シーケンス（その１）を示す図である。
【図１７】従来例２の接続形態とＰＶＣ状態確認の制御シーケンス（その２）を示す図である。
【符号の説明】
１フレームリレー端末ａ
２ＦＲＡＤａ
２ａ状態問合せ開始手段
２ｂ端末間状態問合せ応答手段
２ｃ状態問合せ応答手段
３フレームリレー交換機
３ａ状態問合わせ開始手段
３ｂ端末間状態問合せ応答手段
３ｃ状態問合せ応答手段
４フレームリレー端末ｂ[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a PVC status confirmation method between a frame relay switch and a FRAD.
In recent years, with the development of frame relay communication suitable for high speed and low delay required for communication between LANs, FRAD (Rrame Relay Assembly and Disassmbly: Frame Relay Assembly and Disassmbly) Disassembly equipment) is attracting attention.
[0002]
While the frame relay switch and the FRAD check the PVC status by the PVC (Permanent Virtual Circuit) status check procedure according to the ITU-T recommendation, the status of the terminals under the FRAD is not notified to the frame relay switch. Therefore, the improvement is desired.
[0003]
[Prior art]
FIG. 15 is a control sequence for confirming the connection state and PVC state of Conventional Example 1.
In FIG. 15, 90 is a frame relay terminal a, 91 is a FRAD (frame relay assembling / disassembling apparatus) a, 92 is a frame relay exchange, 93 is a frame relay terminal b, and each apparatus is connected by a UNI (User Network Interface). It is connected. In the case of frame relay, ITU (International Telecommunication Union)-T Recommendation According to the PVC status confirmation procedure defined in 933ANNEX A, in the case of the conventional example 1 shown in FIG. 15, the frame relay switch 92 is DCE (Data Circuit terminating Equipment) and FRADa is DTE (Data Terminal Equipment: data). In general, it operates as a terminal device.
[0004]
In the case of FIG. 15, the PVC stretched between the frame relay terminal “a” and the frame relay terminal “b” is DLCI (Data Link Connection Identifire) “16” between the frame relay terminal “a” and FRADa, and FRADa and the frame relay switch 92 Is set to “32”, and DLCI between the frame relay switch 92 and the frame relay terminal b is set to “48”. In this state, each of the frame relay terminal a, FRADa, and frame relay terminal b performs a PVC state confirmation operation in accordance with the ITU-T PVC state confirmation procedure.
[0005]
This PVC status confirmation procedure is performed to confirm the normality of the link between the user and the network and to notify the PVC status between the user and the user.
Normally, a message requesting status inquiry (STATUS ENQIRY: abbreviated as SE) is transmitted from the user side to the network, and a status display message (STATUS: abbreviated as ST) is returned from the network. This status inquiry message (SE) includes a message requesting link integrity confirmation (confirming the normality of the link between the user and the network) and a full status display (confirming the status of all PVC links to be communicated) ) Is requested (abbreviated as SE-F), which is indicated by the report type in the information elements constituting the SE message. Note that “0” is used as the DLCI in the address field of these status inquiry and response messages.
[0006]
The link integrity check confirms that when an SE is transmitted from the user side to the network at regular intervals, ST is returned from the network, and the transmission sequence number and reception sequence number of SE and ST are updated in order. Normality can be confirmed on the terminal side and the network side.
[0007]
The status inquiry message (SE-F) requesting the full status display is instructed to display the full status by the report type in the information element, and on the network side receiving this, each PVC used by the terminal is received. An information element is created and a full status response message (ST-F (DLCI, N, A)) in which the current DLCI, new bit (N), and active bit (A) are set according to the state for each information element. Display) to the terminal side. Here, the new bit (N) indicates that the PVC has been previously established when it is “0”, and indicates that the PVC has been newly established when it is “1”.
[0008]
The active bit (A) indicates that PVC is inactive (unusable) when it is “I” (or 0), and active (usable) when it is “A” (or 1). The terminal side can confirm the state of all the used PVCs by identifying this. Note that the terminal side holds the previous full status message (ST-F), and the previously existing PVC is not included in the current message by comparing with the content of the full status message received this time. It can be detected that the PVC has been deleted.
[0009]
In FIG. 15, transmission and reception of a status message (ST) as a response and a message whose report type requests link integrity confirmation are omitted, and SE-F which requests full status display makes an inquiry about link integrity confirmation. The data is transmitted from the frame relay terminals a, FRADa, and the frame relay terminal b to FRADa and the frame relay switch, which are higher-level devices (network side), in longer periods (a, c1, e1 in FIG. 15). On the other hand, ST-F is returned from each counterpart device (b, d1, f1 in FIG. 15). Note that ST-F (16, A) shown in b indicates that DLCI is 16 and is active by A, and d1 and f1 are the same.
[0010]
Although the status is checked in this way, if a failure occurs in the line between the frame relay terminal a and FRADa, the frame relay terminal a side transmits a response (ST / ST-) even if SE / SE-F is transmitted. F) is not returned, or the FRADa side does not receive SE / SE-F from the frame relay terminal a, so that it is known that the failure has occurred, but FRADa cannot notify the frame relay switch. In this case, the frame relay switch 92 indicates that the DLCI = 48 of the PVC is active in the response indicated by f2 in response to the SE-F status inquiry indicated by e2 from the frame relay terminal b. When the frame relay terminal b confirming this transmits the frame g by the PVC connected to the frame relay terminal a, it can be transmitted to FRADa via the frame relay switch 92, but the line from FRADa to the frame relay terminal a becomes an obstacle. Therefore, this frame cannot be transmitted to the frame relay terminal a and is discarded.
[0011]
FIGS. 16 and 17 are a connection form and a PVC state confirmation control sequence (No. 1) and (No. 2) of Conventional Example 2. FIG. Also in this control sequence, transmission / reception of a message whose report type requests link integrity confirmation and a status message (ST) as a response are omitted.
[0012]
16 and 17, reference numerals 90 and 93 denote frame relay terminal a, frame relay terminals b and 94, respectively, FRAD, 95 a public frame relay network, and 96 a private frame relay network. In this connection, as shown in the figure, the DLCI 16, DLCI 32, DLCI 48, and DLCI 64 DLCI are set in the PVC between the frame relay terminal a and the frame relay terminal b.
[0013]
In the case of the conventional example 2, the private frame relay network 96 and FRAD 94 operate as DTE (data terminal equipment), the public frame relay network 95 operates as DCE (line terminator), the frame relay terminal a operates on the FRAD 94, and the FRAD 94 operates on the FRAD 94. With respect to the public frame relay network 95, the private frame relay network 96 makes an inquiry to the public frame relay network 95, and the frame relay terminal b makes an inquiry to the private frame relay network 96 to request full status display. As shown in FIG. 16, when a line failure occurs between the frame relay terminal a and the FRAD 94, the frame relay terminal b receives an active full status display (for two transmissions of ST-F (g1, g2)). Since h1 and h2) are received, the frame i is transmitted to the frame relay terminal a, but is discarded by the FRAD 94.
[0014]
Thereafter, when the line failure between the frame relay terminal a and the FRAD 94 recovers from the sequence of FIG. 17 and the line failure occurs between the frame relay terminal b and the private frame relay network 96, the frame relay terminal a When the status display (b2) for the full status inquiry (a2) confirms that DLCI = 16 is active, the frame is transmitted to the frame relay terminal b. In this case, since the private frame relay network 96 cannot transmit to the frame relay terminal b, the frame is discarded.
[0015]
[Problems to be solved by the invention]
In the conventional example 1 described above, the ITU-T recommendation Q. According to the PVC status confirmation procedure stipulated in 933ANNEX A, since FRADa of Conventional Example 1 shown in FIG. 15 operates as DTE, even if a terminal under FRADa becomes a line failure and PVC becomes inoperable. If the link integrity check procedure between the frame relay switch and FRADa is normal, the other terminal is notified that the PVC is operable (active) in response to the full status display query. , There is a problem that even if a frame is transmitted, it is discarded.
[0016]
Similarly, in the case of Conventional Example 2, since the private frame relay network, FRAD operates as DTE, and the public frame relay network operates as DCE, the PVC status under the private frame relay network is FRAD, and the PVC status under FRAD is the private frame. Since it is not reported to the relay network, even if a line failure occurs in a terminal under the FRAD or a terminal under the private frame relay network and the network becomes inoperable, the public frame relay network, the private frame relay network, and the public frame relay If the procedure for confirming link integrity between the network and FRAD is normal, the other terminal is notified that it is operable in response to a full status display status query.
[0017]
The present invention relates to a frame in which a PVC inactivity is not reported to a public frame relay network or a private frame relay network when a line failure occurs between the frame relay terminal and the FRAD or a line failure occurs between the private frame relay network and the frame relay terminal. It is an object of the present invention to provide a PVC status confirmation procedure control method between a frame relay switch and FRAD capable of preventing the occurrence of discard.
[0018]
Similarly, a report of a new PVC (N bit) reported in a PVC status information element between the frame relay terminal and the FRAD, or between the private frame relay network and the frame relay terminal, and a report of the PVC deletion are similarly applied to the public frame relay network and The purpose is to solve the problem of not being able to report to the private frame relay network.
[0019]
[Means for Solving the Problems]
The present invention makes it possible to report PVC validity from both the frame relay switch and the FRAD using a bidirectional network procedure as a PVC status check procedure between the frame relay switch and the FRAD. This bidirectional network procedure is based on ITU-T recommendation Q.3. Although 933 ANNEX A specifies as an option at UNI (User Network Interface), the present invention uses that procedure in the case of FRAD and Frame Relay switches.
[0020]
In addition, the present invention reports a new PVC or a deleted PVC using the bidirectional network procedure between the frame relay switch and the FRAD.
Furthermore, the present invention provides a PVC for performing a PVC status confirmation procedure directly between the private frame relay network and the FRAD when the FRAD is connected to the private frame relay network via the public frame relay network. It is set in the network, and the bidirectional network procedure is performed between the two, and the PVC validity report can be notified from the FRAD to the private frame relay network.
[0021]
FIG. 1 is a first principle configuration diagram according to the present invention.
In FIG. 1, 1 is a frame relay terminal a, 2 is FRADa, 2a is a state inquiry start means for starting a full status inquiry to the frame relay switch 3 and receiving a response, and 2b is a subordinate terminal. An inter-terminal status inquiry response means for performing a process for transmitting a status display response to a full status status query, and a status query for performing a process for transmitting a response to a full status query in response to a query from a frame relay switch Response means, 3 is a frame relay exchange of either a public network or a private network, 3a is a status inquiry start means for starting a full status status inquiry to FRAD and receiving a response, and 3b is a status from the terminal Inter-terminal state inquiry response means for processing to send a response to the inquiry, 3c is a state inquiry from FRAD Receiving the state inquiry response means returns a response status, 4 is a frame relay terminal b.
[0022]
The PVC connecting the frame relay terminals (hereinafter simply referred to as terminals) a and b has a DLCI between the terminal a and FRADa of “16”, a DLCI of between FRADa and the frame relay switch 3 is “32”, and the frame relay switch 3 and the terminal. The DLCI between b is “48”, and the interfaces between the devices are all UNI (User Network Interface). In the configuration of FIG. 1, FRADa 2c and frame relay switch 3a 3a are newly provided means for making a state inquiry in the reverse direction.
[0023]
In FIG. 1, FRADa 2 and frame relay switch 3 respond to status queries from frame relay terminals (hereinafter simply referred to as terminals) a and b by means of inter-terminal status query response means 2b and 3b, respectively, as in the prior art. Detect the line status (failure occurrence) with the terminal. FRADa makes a status inquiry as a terminal device (DTE) to the frame relay exchange 3 which is a network side device (DCE) by the status inquiry start means 2a as in the conventional case, and the status inquiry response means 3c of the frame relay exchange 3 Thus, the DLCI state between the FRADa and the frame relay switch 3 and the DLCI state between the frame relay switch 3 and the terminal b can be identified.
[0024]
In order to make a status inquiry in the opposite direction, according to the present invention, a status inquiry start means 3a is provided in the frame relay switch 3, and a status inquiry response means 2c is provided in FRADa to respond to the status inquiry. By performing the state inquiry in the reverse direction, the frame relay switch 3 can obtain the PVC state including the line state of the terminal a, and can notify this state at the time of the state inquiry from the terminal b. Note that the status notified by the response includes not only active / inactive PVC, but also addition (new) of PVC, deletion of PVC, and the like.
[0025]
FIG. 2 is a second principle configuration diagram according to the present invention. 2, reference numerals 1 and 4 denote frame relay terminals a and b similar to the same reference numerals in FIG. 1, 5 denotes FRADc, 6 denotes a public frame relay network, 7 denotes a private frame relay network (specifically, Exchange). FRADc 5a and 5b are the same as 2a and 2b in FRADa of FIG. 5c is an inter-FRAD state inquiry start means, and 5d is an inter-FRAD state inquiry response means. Note that the private frame relay network 7 corresponds to FRAD when viewed from the public frame relay network 6, and therefore the FRADc and the private frame relay network 7 are referred to as between FRADs. 6a of the public frame relay network 6 is a state inquiry response means 6a, 7a and 7b of the private frame relay network 7 correspond to 5a and 5b of the FRADc, and 7c and 7d correspond to 5c and 5d of the FRADc.
[0026]
In this example, as a normal PVC for user data communication, DLCI between terminal a and FRADc is “16”, DLCI between FRADc and public frame relay network 6 is “32”, public frame relay network 6 and private frame The DLCI between the relay networks 7 is “48”, the DLCI between the private frame relay network 7 and the terminal b is “64”, and the interfaces between the devices are all UNI. Further, the FRADc 5c and 5d and the private frame relay network 7c and 7d are means provided for performing a bidirectional state check between the FRADc and the private frame relay network 7 according to the present invention.
[0027]
The FRADc and private frame relay network 7 status inquiry start means 5a and 7a make a status inquiry to the public frame relay network 6 as a network side device in the same manner as FRADa 2a in FIG. By receiving the response from the status inquiry response means 6a of the network 6, it is possible to identify the PVC status between the public frame relay network 6 and the private frame relay network 7 and the PVC status between the FRADc and the public frame relay network 6, respectively. In the present invention, a PVC for bidirectional status inquiry between FRADs for identifying the status (line status) of the counterpart terminal by the FRADc and the private frame relay network 7 is preliminarily sent to the public frame relay network 6. Set it. In the example of FIG. 2, DLCI between FRADc and public frame relay network 6 is “1”, and DLCI between public frame relay network 6 and private frame relay network 7 is “2”.
[0028]
When the FRADc and private frame relay network 7 inter-FRAD state inquiry start means 5c and 7c make a state inquiry via the PVC for inter-FRAD state inquiry, the other FRAD inter-FRAD state inquiry response means 5d and 7d In the private frame relay network 7, the DLCI is identified, and status information including the line status of the subordinate terminal connected to the DLCI of the PVC for original user data communication is returned via the PVC for inter-FRAD status inquiry. . By receiving this response, the state of the terminal connected to the counterpart FRAD (or private frame relay network) can be identified.
[0029]
In the description of FIG. 2 above, the PVC for inter-FRAD status inquiry is set in the public frame relay network 6, but the existing PVC (between the FRADc and the public frame relay network 6 is set without setting a new PVC. The frame identification information is provided in the frame using the DLCI “32”, and the PVC between the public frame relay network 6 and the private frame relay network 7 using the DLCI “48”. Identification information that is a confirmation frame may be set.
[0030]
DETAILED DESCRIPTION OF THE INVENTION
FIG. 3 is an example of the first control sequence of the present invention, and shows an example of mutual control operation between the devices in the configuration shown in FIG.
[0031]
When SE-F (full status request message, hereinafter simply referred to as SE-F) is transmitted from the terminal a shown in FIG. 3 to FRADa and received by FRADa, the inter-terminal state inquiry response means 2b performs the same as in the prior art ST (response message indicating full status, hereinafter simply referred to as ST) is sent back (a1, b1 in FIG. 3). This inter-terminal state inquiry response means 2b can detect a line failure if SE-F (or link integrity confirmation inquiry) from the terminal does not come in a fixed cycle.
[0032]
On the other hand, FRADa operates in the same manner as in the prior art when the status inquiry start means 2a operates to transmit the SE-F to the frame relay exchange 3 and the ST inquiry sent by the status inquiry response means 3c of the frame relay exchange 3. -F is received and the state of PVC is detected (c1, d1). Further, the frame relay switch 3 sends SE-F to FRADa by the state inquiry start means 3a, and FRADa performs ST-F (including the PVC state between the terminal a and FRADa) by the operation of the state inquiry response means 2c. receive. In this case, the frame relay switch 3 is the same as operating as a terminal (DTE).
[0033]
As shown in FIG. 3, when a line failure occurs between the terminal a and FRADa, the FR-Da sends an ST-F (32, I) indicated by f2 to the SE-F indicated by e2 from the frame relay switch 3. This ST indicates that the DLCI 32 is inactive (displayed at A = 1). Thereafter, when the frame relay switch 3 receives SE-F indicated by g2 from the terminal b, since the DLCI 32 is inactive, the DLCI 48 that constitutes this PVC also indicates that it is inactive ST-F ( 48, I) to terminal b. Thereby, the terminal b stops the transmission of the frame to the terminal a. Thus, according to the conventional technique, it is possible to prevent a situation in which a frame is transmitted and discarded in the middle because the status of the terminal a is not reported to the terminal b.
[0034]
4 and 5 show examples (part 1) and (part 2) of the second control sequence according to the present invention, and show examples of mutual control operations between the devices in the configuration shown in FIG.
Referring to FIG. 2, a PVC for directly performing a PVC state confirmation procedure is set in the public frame relay network 6 between the FRADc and the private frame relay network 7 in advance. In the PVC, as described above, the DLCI between the FRADc and the public frame relay network 6 is “1”, and the DLCI between the public frame relay network 6 and the private frame relay network 7 is “2”.
[0035]
The inquiry SE-F between the terminals a and FRADc and between the private frame relay network 7 and the terminal b is started from the terminal side in the same manner as before, and the inter-terminal state inquiry response means 5b and 7b send the corresponding terminals. ST is sent (a1, b1, g1, h1, etc. in FIG. 4). The inter-terminal state inquiry response means 5b, 7b can detect the corresponding line failure on the terminal side by a procedure of link integrity confirmation (using a conventional sequence number). The FRADc and the private frame relay network 7 start from the state inquiry start means 5a and 7a to the public frame relay network 6 as terminals (DTE), respectively. The state inquiry start means 5a is sent from the public frame relay network 6 to the public frame relay network 6. The PVC state between the frame relay network 6 and the private frame relay network 7 is received, and the state inquiry start means 7a receives the PVC state between the public frame relay network 6 and FRADc from the public frame relay network 6.
[0036]
In addition, the FRADc and private frame relay network 7 inter-FRAD state inquiry start means 5c, 7c perform PVC state confirmation with the counterpart FRAD (or private frame relay network), respectively, and therefore the corresponding PVC DLCI (DLCI1 or 2) is extracted from the table (PVC management table described later), and the other FRAD (or private frame relay network) number or public frame relay network 6 line number is specified, including the type for checking the status of the inter-FRAD PVC state A status inquiry SE-F is transmitted.
[0037]
In response to this, the other FRADc or the inter-FRAD status inquiry response means 5d, 7d of the private frame relay network 7 identify the inter-FRAD status query by type, and refer to the table to obtain the original user data. The DLCI of the PVC for use is obtained and the status information is transmitted to the FRAD (private frame relay network) on the other side. Also in this case, it is sent via the public frame relay network using PVC for status inquiry between FRADs. This exchange is performed by i1, j1 and k1, l.
[0038]
In FIG. 4, when a line failure occurs between the terminal a and FRADa, the FRADa subsequently fails because there is no status inquiry (link integrity confirmation or full status display) from the terminal a for a certain period of time. Is detected. This state (the state in which the PVC for user data communication is disabled at the portion of DLCI “16”) corresponds to the inter-FRAD state inquiry (SE-F) from the private frame relay network 7 indicated by k2 in FIG. On the other hand, it can be notified by a response (ST-F (32, I): indicating that DLCI “32” is inactive) indicated by l (El) 2 from FRADc. When this response is identified, the private frame relay network 7 subsequently responds to the status inquiry (SE-F) indicated by g2 from the terminal b by the response indicated by h2 (ST-F (64, I): DLCI “64”). Returns inactive).
[0039]
After that, when a failure occurs in the line of terminal b and the line failure of terminal a is recovered, status inquiry (link integrity confirmation or full status display) from terminal b is longer than a certain time in private frame relay network 7 It is detected that a failure has occurred in the line of terminal b. As a result, when the inter-FRAD status inquiry using the PVC for inter-FRAD status inquiry from FRADc is sent to the private frame relay network 7 as indicated by i3 in FIG. Is a failure, a response (ST-F (32, I): indicating that DLCI “32” is inactive) is returned as indicated by j3. Thereafter, when the terminal a makes a status inquiry (SE-F) indicated by a2, FRADc responds based on the previous j3 response result (ST (16, I, I) indicating that DLCI “16” is inactive. )) To terminal a. As a result, the terminal a stops transmission to the terminal b where the line failure has occurred.
[0040]
In the description of FIGS. 4 and 5, a PVC for inter-FRAD status inquiry is newly contracted and set. However, when this method cannot be adopted due to a charge or the like, an existing PVC (Fig. 2), the frame for the inter-FRAD status confirmation procedure can be transmitted / received using the DLCI “32” and DLCI “48”.
[0041]
FIG. 6 shows a format of a frame transmitted between the FRAD, the public frame relay network, and the private frame relay network. In this format, “a” is a flag, “b” is an address field, and “c” is a frame identification unit. One bit is used to display “0” for a normal frame and “1” for a PVC status confirmation procedure frame. To do. In the subsequent area d, user data (in the case of a normal frame) or Q. A 931 message (in the case of a frame for the PVC status confirmation procedure) is selected.
[0042]
E is an FCS, and f is a flag. When a PVC status inquiry is made using this frame, the public frame relay network 6 transmits it to the other party's FRAD via the existing PVC. The other party's FRAD discriminates the frame identification part in the frame, and Q. The 931 message is processed as a confirmation query, and the corresponding response is transmitted in the same format to the FRAD that initiated the query.
[0043]
FIG. 7 is a block diagram of a frame relay switch. The configuration of this frame relay switch corresponds to the FRADc and the switch in the private frame relay network 7 shown in FIG. The configuration of this frame relay switch includes the same configuration as the FRADa and the frame relay switch 3 shown in FIG. 1 (inter-FRAD polling start procedure processing unit 16, inter-FRAD polling response procedure processing unit 17 and Excluding tables related to these operations).
[0044]
In FIG. 7, reference numeral 10 denotes a frame relay exchange for executing a frame relay exchange service, and 11 denotes a CCITT recommendation Q.D. 922, Q.E. The frame relay exchange processing unit performs frame transmission / reception processing with a user and frame transmission / reception processing between frame relay exchanges according to 933. The programs of the processing units 12 to 17 constituting the frame relay exchange processing unit 11 are stored in the main memory of the exchange.
[0045]
12 is a frame reception processing unit. When DLCI = 0 when receiving a frame from the terminal, the function is recognized as a frame for checking the PVC state, the frame analysis process is continued, and the status (ST) message In this case, a polling (PVC status confirmation query) start procedure processing unit 14 (described later) is activated, and in the case of a status ENQ (status query: SE) message, a polling response procedure processing unit 15 (described later). Start up. When DLCI ≠ 0, the PVC management table 20 (described later) is referred to from the line number and the DLCI number to obtain a PVC identification display. When it is found that the PVC identification display is for the inter-FRAD PVC status confirmation procedure, the frame is analyzed, and in the case of the status message, the inter-FRAD polling start procedure processing unit 16 is activated and the status ENQ (status inquiry) message is displayed. In this case, the inter-FRAD polling response procedure processing unit 17 is activated.
[0046]
A frame transmission processing unit 13 is activated from the polling start procedure processing unit 14, the polling response procedure processing unit 15, the inter-FRAD polling start procedure processing unit 16, and the inter-FRAD polling response procedure processing unit 17, and receives a transmission request from each processing unit. Q. for the completed PVC status confirmation procedure. A 931 message (status message: ST, status inquiry message: SE) is transmitted to the line.
[0047]
14 is a polling start procedure processing unit. When the frame relay switch 10 and the FRAD device are directly connected (in the case of FIG. 1), the ITU-T recommendation Q.14 is connected to the FRAD. The polling start procedure of the PVC status confirmation procedure defined in 933ANNEX A is performed.
[0048]
15 is a polling response procedure processing unit. When the frame relay switch and the FRAD apparatus are directly connected (in the case of FIG. 1), the ITU-T recommendation Q.15 is connected to the FRAD. The polling response procedure of the PVC status confirmation procedure specified in 933ANNEX A is performed. The response procedure is also performed for the polling start procedure from the terminal.
[0049]
16 is an inter-FRAD polling start procedure processing unit. When connected to the FRAD via the public frame relay network (in the case of FIG. 2), the ITU-T recommendation Q.16 is connected to the FRAD. The polling start procedure of the PVC status confirmation procedure defined in 933ANNEX A is performed. The DLCI number is a DLCI number registered in the DLCI management table 24 for inter-FRAD PVC status confirmation procedure (described later).
[0050]
17 is an inter-FRAD polling response procedure processing unit. When connected to the FRAD via the public frame relay network, the ITU-T Recommendation Q.17 is connected to the FRAD. The polling response procedure of the PVC status confirmation procedure specified in 933ANNEX A is performed. As the DLCI number, the DLCI number registered in the DLCI management table for inter-FRAD PVC state confirmation procedure is used.
[0051]
Next, the tables to which the reference numerals 18 to 24 are attached will be described with reference to FIGS.
Reference numeral 18 denotes a link state management table, and its configuration diagram is shown in FIG.
[0052]
This link state management table is indexed by the line number as shown in FIG. 8, and the operation mode of the PVC state confirmation procedure (FRAD connected to the frame relay switch and the direct line or the public frame relay network) ( a polling start procedure link state (indicated by b) and a polling response procedure link state (indicated by c). The operation mode a represents the operation mode of the PVC state confirmation procedure for the corresponding line, and one of the following modes is set.
[0053]
(1) DTE mode (operates as a terminal and performs only the polling start procedure)
(2) DCE mode (operates as a network and performs only the polling response procedure)
(3) Bidirectional mode (Polling start procedure and polling response procedure are performed)
The polling start procedure link status b indicates the link integrity confirmation status (confirmation based on the transmission and reception sequence numbers described above) in the polling start procedure and indicates whether the status is normal or error. However, this information is valid when the operation mode is the DTE mode or the bidirectional mode.
[0054]
The polling response procedure link status of c indicates the link integrity confirmation status in the polling response procedure, and indicates a normal status and an error status. However, this information is valid when the operation mode is the DCE mode or the bidirectional mode.
[0055]
Reference numeral 19 denotes a PVC state management table, and its configuration diagram is shown in FIG.
As shown in FIG. 9, this PVC status management table is indexed by a line number × DLCI number, and has a registration display a, an N-bit transmission status b, an N-bit reception status c, and an A-bit reception status d. The registration display of a indicates whether or not PVC is registered for the DLCI, and the N bit transmission status of b is N bits in the polling response procedure (a bit indicating that a new PVC has been added). Indicates the transmission status, and there are the following three situations. (1) N bit = 1 not transmitted, (2) N bit = 1 transmitted and waiting for partner confirmation, and (3) N bit = 1 transmitted and partner confirmed.
[0056]
The N-bit reception status in FIG. 9c indicates the N-bit reception status in the polling start procedure, and there are the following two situations. (1) N bit = 1 not received (including no PVC status information element), (2) N bit = 1 received. Further, the A bit reception status of d indicates the reception status of the A bit (indicating whether the link is active or inactive) in the polling start procedure. (1) A bit = 0 reception (inactive), (2) A Bit = 1 is either reception (active).
[0057]
Reference numeral 20 in FIG. 7 denotes a PVC management table, and its configuration is shown in FIG.
As shown in FIG. 10, this PVC management table is indexed by line number and DLCI number, PVC identification display a, PVC partner information valid display b, partner line number c, partner DLCI number d, and public frame relay network. When connected via FRAD, the display e, FRAD number f, and FRAD side DLCI number g are held.
[0058]
The PVC identification display of a above indicates which of the following two uses the PVC is. That is, either (1) for normal PVC or (2) for the FRAD PVC status confirmation procedure. The partner information valid display of the next b indicates whether the partner line number and the partner DLCI number are valid. Further, the partner line number of c indicates the partner line number of PVC, and the partner DLCI number of d indicates the partner DLCI number of PVC. The e-FRAD connection indication via the public frame relay network indicates whether the PVC is connected to the FRAD via the public frame relay network. The FRAD number of f indicates the FRAD number connected via the public frame relay network, and the FRAD side DLCI number of g indicates the DLCI number between the public frame relay networks.
[0059]
Reference numeral 21 in FIG. 7 denotes an inter-FRAD link state management table, and a configuration diagram thereof is shown in FIG.
This inter-FRAD link status management table is indexed by the FRAD number as shown in FIG. 11, and the operation mode a, polling start procedure link status b, polling response procedure link status c of the PVC status confirmation procedure executed with the FRAD is performed. Is held. The contents set in ac are the same as those in the link state management table shown in FIG. However, the link state in this case relates to the link state of the PVC with another FRAD via the public frame relay network.
[0060]
Reference numeral 22 in FIG. 7 denotes an inter-FRAD PVC state management table, and a configuration diagram thereof is shown in FIG.
As shown in FIG. 12, this table is indexed by the FRAD number and the DLCI number, and has a registration display a, an N-bit transmission status b, an N-bit reception status c, and an A-bit reception status d. The contents set in a to d of this table are the same as those in the PVC state management table shown in FIG. However, the PVC state in this case relates to a PVC with another FRAD via the public frame relay network.
[0061]
Reference numeral 23 in FIG. 7 denotes an inter-FRAD PVC management table, and a configuration diagram thereof is shown in FIG.
As shown in FIG. 13, this table is indexed by the FRAD number and the DLCI number, and holds the PVC identification display a, the line number b connected to the public frame relay network, and the DLCI number c. The PVC identification display of a indicates whether it is for normal PVC or the inter-FRAD PVC status confirmation procedure, the line number of b indicates the line number where the private frame relay network is connected to the public frame relay network, and the DLCI number is The DLCI number between a private frame relay network and a public frame relay network is shown.
[0062]
Reference numeral 24 in FIG. 7 denotes a DLCI management table for the inter-FRAD PVC state confirmation procedure. FIG.
This table is indexed by the FRAD number and holds the DLCI number for performing the PVC status confirmation procedure with the FRAD.
[0063]
A description will be given of an example in which the frame relay switch shown in FIG. 7 having the processing units and tables as described above operates as a switch for the private frame relay network shown in FIG. However, in the PVC status confirmation procedure between the private frame relay network and the FRAD, the DLCI number is changed on the private frame relay network side (frame relay switch in FIG. 7). The DLCI number is changed as described above with reference to FIG. 2, the DLCI number that FRADc in FIG. 2 has contracted to confirm the PVC status between the public frame relay network and the FRAD, and the private frame relay network that is the public frame relay network. Since there is a difference in the DLCI numbers contracted for the PVC status confirmation between the FRADs, the conversion process is performed on either side.
[0064]
For polling start procedures and polling response procedures, see ITU-T Recommendation Q.3. This is performed in the same manner as in the prior art as defined in 933ANNEX A, and a description thereof will be omitted.
[0065]
Hereinafter, the processing of the frame relay switch shown in FIG. 7 will be described mainly with respect to the PVC status confirmation procedure (see FIGS. 4 and 5) between the FRADs. In this case, as shown in FIG. 2 and FIG. 4, in addition to the normal communication request PVC (configured with DLCI 16, 32, 48, 64), PVC for the PVC status confirmation procedure between FRADs (configured with DLCI 1 and DLCI 2) ) Is set (contracted) in the public frame relay network.
[0066]
In the frame relay switch, the polling start procedure processing unit 14 requests the frame transmission processing unit 13 to transmit and transmits it to the public frame relay network (6 in FIG. 2), a status inquiry (SE: STATUS ENQUIRY) message (report type = (Full status), when the status display message (ST-F) is received from the public frame relay network, the frame reception processing unit 12 sets DLCI = 0 and Q.I. By analyzing the 931 message type, the status display message (STATUS) is recognized, and the polling start procedure processing unit 14 is activated. The polling start procedure processing unit 14 analyzes the information element of the status display message and sets the A bit = 1 in the PVC status information element of DLCI = 48 to the A bit reception status in the PVC status management table shown in FIG. = 1 Set reception.
[0067]
Next, when transmitting a status inquiry message to the FRAD, the frame relay switch performs a PVC status check procedure with the FRAD from the DLCI management table 24 for the PVC status check procedure between FRADs shown in FIG. Obtain the DLCI number. A line number and a DLCI number connected to the public frame relay network are obtained from the obtained FRCI number and FRAD number from the inter-FRAD PVC management table 23 shown in FIG. 13, and a transmission request is made to the frame transmission processing unit. The transmission processing unit 13 transmits a status request message (SE) with DLCI = 2 to the public frame relay network. The public frame relay network performs normal frame exchange processing and transmits a status inquiry (SE) to the FRAD that is the communication partner.
[0068]
When the frame reception processing unit 12 receives the status indication message (ST) sent from the FRAD as a frame of DLCI = 2 from the public frame relay network, DLCI = 0 is not satisfied. Determine PVC identification. Since it is determined that this is for the inter-FRAD PVC state confirmation procedure, the frame analysis is continued. Since the 931 message type is the status display message (ST), the inter-FRAD polling start procedure processing unit 16 is activated. The inter-FRAD polling start procedure processing unit 16 obtains the FRAD number in the PVC management table shown in FIG. 10 from the line number and the DLCI number.
[0069]
Further, the inter-FRAD polling start procedure processing unit 16 analyzes the information element of the status display message (ST), and sets the A bit = 0 in the PVC status information element of DLCI = 32 to the inter-FRAD PVC status management table shown in FIG. The A bit = 0 reception is set in the A bit reception status in FIG.
[0070]
Next, when a status request message (ST-F) whose report type is full status is transmitted to the frame relay terminal b (4 in FIG. 2), the polling response procedure processing unit 15 edits the PVC status information element for the DLCI 64. However, the value of the A bit is edited as follows.
[0071]
First, the line number and the DLCI number are obtained by referring to the PVC management table shown in FIG. 10 from the line number and the DLCI number. This is the connection line number and DLCI number for the public frame relay network. Further, referring to the PVC management table shown in FIG. 10 from the obtained line number and DLCI number, since the FRAD connection display via the public frame relay network is set, the PVC is connected to the FRAD via the public frame relay network. And the FRAD number and the FRAD side DLCI number are obtained from the table.
[0072]
The A bit for editing the PVC status information element for the DLCI 64 from the line number and the DLCI number obtained in this way is set to A bit = 1 only when all of the following are satisfied.
[0073]
(1) The link integrity check of the polling response procedure with the frame relay terminal b is normal. This is determined by the polling response procedure link state c in the link state management table of FIG.
[0074]
(2) A bit = 1 (active) is received from the public frame relay network in the polling start procedure. This is determined by the A bit reception status d in the PVC status management table of FIG.
[0075]
(3) The link integrity check of the polling start procedure with the public frame relay network is normal. This is determined by the polling start procedure link state b in the link state management table of FIG.
[0076]
(4) A bit = 1 is received from FRADc (5 in FIG. 2) in the polling start procedure. This is determined by the A-bit reception status d in the inter-FRAD PVC status management table of FIG.
[0077]
(5) The link integrity check in the polling start procedure with FRADc is normal. This is determined by the polling start procedure link state b in the inter-FRAD link state management table of FIG.
[0078]
(6) The link integrity check of the polling response procedure with FRADc is normal. This is determined by the polling response procedure link state c in the inter-FRAD link state management table of FIG.
[0079]
2 and FIG. 4, when a line failure occurs between the frame relay terminal a and FRADc, the A bit = 0 (inactive) is received in the above (4), so the PVC for DLCI = 64 The A bit of the status information element is set to 0. When the status display message (ST) is edited, the frame transmission processing unit 13 is activated and transmitted to the frame relay terminal b.
[0080]
【The invention's effect】
The present invention has the following effects.
(1) Since the validity (active) of the PVC can be reported in both directions of the frame relay switch and the FRAD, the PVC validity can be accurately reported to the end terminal.
[0081]
(2) Since it is possible to report a new PVC in both directions of the frame relay switch and the FRAD, both the frame relay switch and the FRAD register the PVC to the end terminal when both the frame relay switch and the FRAD register the PVC. Reporting is possible.
[0082]
(3) Since it is possible to report the deleted PVC in both directions of the frame relay switch and FRAD, it is deleted from the end terminal when either the frame relay switch or the FRAD PVC is deleted from the end terminal. It is possible to report PVC.
[0083]
(4) When the private frame relay network and the FRAD are connected via the public frame relay network, the same effects as in the above (1) to (3) can be obtained.
[Brief description of the drawings]
FIG. 1 is a first principle configuration diagram of the present invention.
FIG. 2 is a second principle configuration diagram of the present invention.
FIG. 3 is an example of a first control sequence of the present invention.
FIG. 4 is a diagram showing an example (part 1) of a second control sequence according to the present invention.
FIG. 5 is a diagram showing an example (part 2) of a second control sequence according to the present invention.
FIG. 6 is a diagram illustrating a format of a frame transmitted between the FRAD, the public frame relay network, and the private frame relay network.
FIG. 7 is a configuration diagram of a frame relay switch.
FIG. 8 is a configuration diagram of a link state management table.
FIG. 9 is a configuration diagram of a PVC state management table.
FIG. 10 is a configuration diagram of a PVC management table.
FIG. 11 is a configuration diagram of an inter-FRAD link state management table.
FIG. 12 is a configuration diagram of an inter-FRAD PVC state management table.
FIG. 13 is a configuration diagram of an inter-FRAD PVC management table.
FIG. 14 is a configuration diagram of a DLCI management table for a PVC status confirmation procedure between FRADs.
FIG. 15 is a diagram illustrating a connection sequence and a PVC state confirmation control sequence in Conventional Example 1;
FIG. 16 is a diagram showing a connection form and a PVC state confirmation control sequence (No. 1) of Conventional Example 2;
FIG. 17 is a diagram showing a connection form and a PVC state confirmation control sequence (part 2) of the conventional example 2;
[Explanation of symbols]
1 Frame relay terminal a
2 FRADa
2a Status inquiry start means
2b Inter-terminal state inquiry response means
2c Status inquiry response means
3 Frame relay switch
3a State inquiry start means
3b Inter-terminal state inquiry response means
3c Status inquiry response means
4 Frame relay terminal b

Claims

In a PVC status confirmation method in a network in which a private frame relay network is connected to FRAD through a public frame relay network ,
A PVC for confirmation of the PVC status between the FRADs for directly executing the PVC status confirmation procedure between the private frame relay network and the FRAD is set in the public frame relay network separately from the PVC for normal data communication.
The private frame relay network and the FRAD respond to status inquiries between the FRAD or the private frame relay network and the means for making a bi-directional status inquiry via the PVC for checking the PVC status between the FRAD and the terminals accommodated in each of them. And means for notifying the validity of the PVC to the private frame relay network or the FRAD by means of an inquiry using the means for responding to the inquiry with the terminal and the means for inquiring the status between the FRADs, respectively. A PVC status confirmation method in a frame relay network.

In claim 1,
The private frame relay network and the FRAD notify the other private frame relay network or FRAD of the new PVC by an inquiry using means for responding to an inquiry with the terminal and means for making an inter-FRAD state inquiry, respectively. A PVC status confirmation method in a frame relay network characterized by the above.

In claim 1,
The private frame relay network and the FRAD respectively notify the other private frame relay network or FRAD of the deleted PVC by an inquiry using means for responding to an inquiry with the terminal and means for making an inter-FRAD state inquiry. A PVC status confirmation method in a frame relay network characterized by the above.

In claim 1,
The difference between the DLCI number set by the private frame relay network in the public frame relay network and the DLCI number set by FRAD in the public frame relay network is determined by either the private frame relay network or the FRAD. The PVC state confirmation method in the frame relay network characterized by performing the above-mentioned conversion .

In claim 1,
The private frame relay network or the FRAD performs bi-directional PVC status confirmation via the PVC for PVC status confirmation between the FRADs, and executes a PVC status inquiry as a terminal device to the public frame relay network. ,
A PVC status confirmation method in a frame relay network, wherein a PVC status is identified based on a result of PVC status confirmation between the FRADs and a result of a status inquiry from the public frame relay network .