(57)【要約】【課題】  ＶＰＮで効率的な帯域幅使用のための暗号化が適用されたパケット通信網での音声データ処理方法を提供する。【解決手段】  発信側端末が呼接続パケットの目的地アドレスを確認するステップと、目的地アドレスが私設網に該当する場合には、呼接続パケット内の呼接続情報を保存し、アドレス変換テーブルに登録するステップと、発信側端末が呼接続パケットを暗号化して受信側に伝送するステップと、呼接続パケットを受信した受信側端末が呼接続パケット内の呼接続情報を保存するステップと、受信側端末が呼接続パケットについての応答である呼接続応答パケットを暗号化した後、発信側端末に伝送して発信側端末と受信側端末間に通話路を形成するステップと、受信側端末と発信側端末が通話路を介して暗号化されていない音声メディアデータを呼接続情報を用いて伝送するステップと、を含んで音声データを処理する。【選択図】  図３
2006115507.tif 000002
【特許請求の範囲】
【請求項１】
暗号化が適用されたパケット通信網での音声メディアデータ処理方法であって、
発信側装置が呼接続パケットを暗号化して受信側装置に伝送するステップと、
前記受信側装置が、前記呼接続パケットについての応答である呼接続応答パケットを暗号化した後に、前記受信側装置から前記発信側装置に伝送して、前記発信側装置と前記受信側装置との間に通話路を形成するステップと、
前記発信側装置が、暗号化されていない音声メディアデータを、前記通話路を介して、前記受信側装置に伝送するステップと、
を有することを特徴とする音声メディアデータ処理方法。
【請求項２】
前記音声メディアデータは、
リアルタイム伝送プロトコルデータであることを特徴とする請求項１記載の音声メディアデータ処理方法。
【請求項３】
暗号化が適用されたパケット通信網での音声メディアデータ処理方法であって、
発信側装置が呼接続パケットの目的地アドレスを確認するステップと、
前記目的地アドレスが私設網に該当する場合には、前記呼接続パケット内の呼接続情報を保存し、アドレス変換テーブルに登録するステップと、
前記発信側装置が、呼接続パケットを暗号化して、前記受信側装置に伝送するステップと、
前記呼接続パケットを受信した前記受信側装置が、前記呼接続パケット内の呼接続情報を保存するステップと、
前記受信側装置が、前記呼接続パケットについての応答である呼接続応答パケットを暗号化した後に、該暗号化した呼接続応答パケットを前記発信側装置に伝送して、前記発信側装置と前記受信側装置との間に通話路を形成するステップと、
前記受信側装置と前記発信側装置が、前記通話路を介して暗号化されていない音声メディアデータを、前記呼接続情報を用いて伝送するステップと、
を有することを特徴とする音声メディアデータ処理方法。
【請求項４】
前記呼接続情報は、
前記呼接続パケット内のリアルタイム伝送プロトコルであることを特徴とする請求項３記載の音声メディアデータ処理方法。
【請求項５】
前記呼接続情報は、
ＶｏＩＰシグナルリング(signaling)メッセージであることを特徴とする請求項３記載の音声メディアデータ処理方法。
【請求項６】
暗号化が適用されたパケット通信網での音声メディアデータ処理装置であって、
ローカル網の多数のホストが同時にグローバル網と通信できるようにするアドレス変換情報を保存するためのアドレス変換テーブルと、
ルーティング情報を保存するルーティングテーブルと、
ＩＰ網を介して伝えられた音声メディアデータを受信し、該音声メディアデータが仮想私設網を基盤としたか否かを判断する入力部と、
前記入力部の判断結果、前記音声メディアデータが仮想私設網を基盤としたと判断された場合には、前記音声メディアデータを分析して、前記音声メディアデータのリアルタイム伝送プロトコル情報を検出し、前記リアルタイム伝送プロトコル情報を前記アドレス変換テーブルに登録する分析部と、
前記音声メディアデータを仮想私設網パケットに変換するパケット処理部と、
前記アドレス変換テーブル及び前記ルーティングテーブルに保存された情報に基づいて、前記入力部を介して入力される音声メディアデータをルーティングするルーティング部と、
を備えることを特徴とする音声メディアデータ処理装置。
【請求項７】
前記アドレス変換テーブルは、
ネットワークアドレスポート変換テーブルであることを特徴とする請求項６記載の音声メディアデータ処理装置。
【請求項８】
前記入力部は、
前記入力された音声メディアデータの目的地アドレスに基づいて前記音声メディアデータが仮想私設網を基盤としたか否かを判断することを特徴とする請求項６記載の音声メディアデータ処理装置。
【請求項９】
前記分析部で検出されたリアルタイム伝送プロトコル情報は、
メディア-ゲートウエイ(media gateway)インターフェースリアルタイム伝送プロトコル情報ポート情報であることを特徴とする請求項６記載の音声メディアデータ処理装置。
【請求項１０】
前記パケット処理部は、
前記音声パケットをカプセル化して仮想私設網パケットに変換し、仮想私設網を基盤とした音声パケットをパケットシェイピング(packet shaping)することを特徴とする請求項６記載の音声メディアデータ処理装置。
【請求項１１】
前記ルーティング部は、
仮想私設網基盤の音声パケットのための通話路が形成された後に、前記アドレス変換テーブルに保存されたリアルタイム伝送プロトコル情報に基づいて、仮想私設網基盤の音声パケットをルーティングすることを特徴とする請求項６記載の音声メディアデータ処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、効率的な帯域幅使用のための暗号化が適用されたパケット通信網での音声データを処理する方法及びその装置に関し、特に、ＶＰＮでインターネットプロトコル(Internet Protocol、以下、‘ＩＰ'とする)を用いた音声データを処理する方法及びその装置に関する。
【背景技術】
【０００２】
データ(data)網として使用中のパケットスイッチ網(packet switch network)で、ＩＰを用いて音声情報を伝達する技術を‘ボイスオーバーインターネットプロトコル'(Voice over Internet Protocol、以下、‘ＶｏＩＰ'とする)という。これは、公衆交換電話網(Public  Switched  Telephone  Network、以下、‘ＰＳＴＮ'とする)のように回線に基づいた伝統的なプロトコルではなく、不連続的なパケット内にデジタル化された音声情報を送る。
【０００３】
ＶｏＩＰの根幹となるＩＰ網は、限定された資源を効率的に共有する必要がある。これは、非効率な共有によって、データが遺失したり、データ伝送に遅延が発生する可能性があるからである。したがって、ＶｏＩＰは、パケットが適時に到着するようにするために、リアルタイム伝送プロトコル(Realtime Transport Protocol、以下、‘ＲＴＰ'とする)を用いる。ＶｏＩＰにおいて、ＲＴＰを実現するためにはＩＰ網の特性をよく考慮する必要がある。特に、電話通信では音声のリアルタイム性及び双方向性が音質を決める重要な要素であるため、ＶｏＩＰを用いた電話通信には、特性を考慮したＲＴＰ設計が要求される。例えば、ＶｏＩＰ端末分野では、上記のようなＩＰ網の特性を補完するために、マルチフレーム(multi-frame)技術、ＶＡＤ (Voice Activity Detection)機能、ダイナミックジッターバッファーリング(dynamic jitter buffering)等の多様な技術が開発されてきた。しかしながら、端末でのＲＴＰ処理は、ＩＰ網で生じる遅延及び損失を補完するのに限界がある。特に、リアルタイム性と双方向性、そして音質の特性を補完するための技術の間には、相互にトレード-オフ(trade-off)される関係がある。したがって、これを克服するためには多様なパケット処理(packet processing)技術を活用する必要がある。
【０００４】
一方、パブリック(public)網を活用して私設網のような保安性を得ることができる、暗号化が適用されたパケット通信網である仮想私設網（Virtual Private Network、以下、‘ＶＰＮ'ともいう）の活用が増加するにつれて、ＶＰＮにＶｏＩＰを適用するための要求が増加している。
【０００５】
しかしながら、ＶＰＮにＶｏＩＰを適用する場合、次のような短所がある。
【０００６】
第一に、ＶＰＮ暗号化技術を適用するためのエンコーディング(encoding)及びデコーディング(decoding)時に、処理時間(processing time)が増加することによって、パケット遅延(packet delay)が発生し、それによってリアルタイム性が低下する。
【０００７】
例えば、ＶｏＩＰでG.723.1(6.3kbps)方式でＲＴＰ音声パケットをコーディングする場合には、３０ｍｓｅｃ毎に２４ｂｙｔｅｓのパケットデータを伝送する必要があり、G.729(8kbps)方式でＲＴＰ音声パケットをコーディングする場合には、１０ ｍｓｅｃ毎に１０ｂｙｔｅｓのパケットデータを伝送する必要がある。ＶＰＮ基盤のＶｏＩＰである場合には、その度に発信及び受信する音声データを暗号化(encryption)及び復号化(decryption)しなければならない。
【０００８】
したがって、ＶＰＮにＶｏＩＰを適用する場合には、上記の通りに周期的に伝送されるパケットデータの暗号化及び復号化のためのパケット処理時間(processing time)が増加するようになり、これは電話通信のリアルタイム性に阻害要素として作用するようになって、音質にも影響を与えるという短所がある。
【０００９】
第二に、ＶＰＮの基本パケット処理(packet processing)方式であるＩＰＳｅｃを活用する場合には、パケットオーバーヘッド(packet overhead)による帯域幅使用が増加する。
【００１０】
図１Ａ乃至図２Ｂは、ＶＰＮで音声コーデックのために必要な帯域幅が増加することを説明するための図面である。
【００１１】
図１Ａは、ＶＰＮ使用網とＶＰＮ非使用網でG.729A方式でＲＴＰ音声パケットをコーディングする場合についての帯域幅を比較した比較表である。特に、図１Ａは、ＶＡＤ(Voice Activity Detection)オン(on)である時の帯域幅が、ＶＡＤオフ(off)である時の６０％の使用量であることを基準で作成されたものである。図１Ｂは、図１Ａを参照してＶＰＮ使用に基づく帯域幅比率を示す図面である。
【００１２】
図２Ａは、ＩＰｖ４またはＩＰｖ６の使用時にＶＰＮ使用網とＶＰＮ非使用網でG.729A方式でＲＴＰ音声パケットをコーディングする場合についての帯域幅を比較した比較表である。図２Ｂは、図２Ａを参照してＶＰＮ使用に基づく帯域幅比率を示す図面である。
【００１３】
図１Ａ乃至図２Ｂを参照すれば、ＶＰＮ使用網(with ＶＰＮ)の帯域幅は、ＶＰＮ非使用網(without ＶＰＮ)と比較した時、より多くの帯域幅が要求されることが分かる。
【００１４】
特に、図２Ａを参照すれば、ＩＰｖ６を用いる場合には、ＩＰｖ４に比べてＩＰヘッダの大きさが２０バイトから４０バイトに増加し、ＶＰＮの使用有無によって帯域幅の浪費度がＩＰｖ４より相対的にさらに大きい。これは、ＩＰヘッダが増加するにつれて、トンネルモード(tunnel mode)において、既存ヘッダ(original header)及びあらたなヘッダ(new header)の両方で帯域幅の浪費が発生し、ＩＰｖ６においては、より大きな浪費が生じるためである。
【００１５】
上述した通り、図１Ｂ乃至図２Ｂを参照すれば、ＶｏＩＰをＶＰＮに適用する場合には、コーディングに必要な帯域幅が増加し、これによって通話品質が低下して伝送時間が遅れる短所がある。
【発明の開示】
【発明が解決しようとする課題】
【００１６】
本発明は、上述の問題点を解決するために案出されたもので、本発明は、パブリック(public)ＩＰ網(例えば、ＶＰＮ等)を用いる環境で帯域幅を効率的に用いる音声データ処理方法及びその装置を提供するものである。
【００１７】
また、本発明はＲＴＰパケットの遅延要素を減らすことによって通話品質を向上させる音声データ処理方法及びその装置を提供するものである。
【００１８】
また、本発明は、ＶＰＮ基盤の音声パケットを選択的に処理することによって、ＶｏＩＰシステム性能を向上させる音声データ処理方法及びその装置を提供するものである。
【課題を解決するための手段】
【００１９】
前述の目的を達成するため、本発明の音声データ処理方法は、発信側装置が呼接続パケットを暗号化して受信側装置に伝送するステップと、受信側装置が呼接続パケットについての応答である呼接続応答パケットを暗号化した後、発信側装置に伝送して発信側装置と受信側装置間に通話路を形成するステップと、発信側装置が暗号化されない音声メディアデータを通話路を介して受信側装置に伝送するステップと、を含むことを特徴とする。
【００２０】
また、上記目的を達成するため、本発明の音声データ処理方法は、発信側装置が呼接続パケットの目的地アドレスを確認するステップと、目的地アドレスが私設網に該当する場合には、呼接続パケット内の呼接続情報を保存し、アドレス変換テーブルに登録するステップと、発信側装置が呼接続パケットを暗号化して受信側に伝送するステップと、呼接続パケットを受信した受信側装置が呼接続パケット内の呼接続情報を保存するステップと、受信側装置が呼接続パケットについての応答である呼接続応答パケットを暗号化した後に、発信側装置に伝送して発信側装置と受信側装置間に通話路を形成するステップと、受信側装置と発信側装置が通話路を介して暗号化されていない音声メディアデータを呼接続情報を用いて伝送するステップと、を含むことを特徴とする。
【００２１】
呼接続情報は、呼接続パケット内の実時間伝送プロトコル（Realtime  Transport  Protocol）であっても良い。また、呼接続情報は、ボイスオーバーインタネットプロトコル（Voice  over  Internet  Protocol）シグナルリング（signaling）メッセージであっても良い。
【００２２】
一方、上記目的を達成するため、本発明の音声データ処理装置は、ローカル網の多数のホストが同時にグローバル網と通信できるようにするアドレス変換情報を保存するためのアドレス変換テーブルと、ルーティング情報を保存するルーティングテーブルと、IP網を介して伝えられた音声メディアデータを入力し、その音声メディアデータが仮想私設網を基盤としたか否かを判断する入力部と、入力部の判断結果、音声メディアデータが仮想私設網を基盤とする場合には、その音声メディアデータを分析してその音声メディアデータのリアルタイム伝送プロトコル(Realtime Transport Protocol)情報を検出し、リアルタイム伝送プロトコル情報をアドレス変換テーブルに登録する分析部と、音声メディアデータを仮想私設網パケットに変換するパケット処理部と、アドレス変換テーブル及びルーティングテーブルに保存された情報に基づいて、入力部を介して入力される音声メディアデータをルーティングするルーティング部と、を含むことを特徴とする。
【発明の効果】
【００２３】
本発明は、ＶＰＮ基盤の音声パケットについてはＶＰＮカプセル化(encapsulation)を行わないことで、ＶＰＮを用いる２端末(terminal)間にも伝送遅延及び帯域幅の浪費無しでＶＰＮ接続(connection)を行うことが可能となる。すなわち、ＶＰＮで伝送パケットをコーディングする時、周期的に発生するパケットデータを伝送する度にＶＰＮカプセル化する過程を省略することによって、該当パケットの伝送遅延及び帯域幅の浪費を減らすことが可能となる。
【発明を実施するための最良の形態】
【００２４】
以下、添付の図面を参照し、本発明の実施形態に係る構成及び作用についてより詳細に説明する。この際、関連した公知機能または構成についての具体的な説明が本発明の要旨を不明確とすると判断される場合には、その詳細な説明を省略する。
【００２５】
図３は、本発明の一実施形態によるＶＰＮで音声データを処理する装置についての概略的なブロック図である。
【００２６】
図３を参照すれば、本発明の一実施形態の音声データ処理装置１００は、入力部１１０、分析部１２０、ネットワークアドレスポート変換(Network Address Port Translation、以下、‘ＮＡＰＴ'とする)テーブル１３０、ルーティングテーブル(routing  table)１４０、ＶＰＮ処理部１５０及びルーティング部１６０を含む。
【００２７】
入力部１１０は、ＩＰ網２００を介して音声パケット(voice packet)を受信し、その音声パケットがＶＰＮ基盤のものか否かを確認する。すなわち、入力部１１０は、音声パケットの目的地アドレス(destination address)を確認して、その目的地アドレスがＶＰＮのためのものであるか否かを確認する。そして、入力部１１０は、その結果を分析部１２０に伝達する。
【００２８】
その音声パケットがＶＰＮ基盤のものである場合には、分析部１２０は、その音声パケットを分析(parsing)して音声パケットのＲＴＰ情報(例えば、ＲＴＰポート情報等)を検出し、そのＲＴＰ情報をＮＡＰＴテーブル１３０に登録する。
【００２９】
ＮＡＰＴテーブル１３０は、ネットワークアドレスポート変換（ＮＡＰＴ）を行うための情報を保存する。この際、‘ＮＡＰＴ'とは、ＩＰアドレスをローカル網(local network)の多数のホストが共有して同時にグローバル網(global network)と通信できるようにするための網(network)アドレス変換方法をいう。
【００３０】
ルーティングテーブル１４０は、ネットワーク間またはネットワーク内でパケットデータをルーティングするための情報を保存する。
【００３１】
ＶＰＮ処理部１５０は、入力部１１０を介して入力された音声パケットを、ＶＰＮパケットに変換してルーティング部１６０に伝達する。すなわち、ＶＰＮ処理部１５０は、音声パケットをＶＰＮパケットでカプセル化(encapsulation)した後、そのＶＰＮパケットをルーティング部１６０に伝達する。
【００３２】
ルーティング部１６０は、ＶＰＮ処理部１５０から伝えられたＶＰＮパケットの目的地アドレスを確認した後、該当目的地に上記ＶＰＮパケットをルーティングする。特に、ルーティング部１６０は、ＶＰＮ基盤の音声パケットのための通話路形成以前には、ルーティングテーブル１４０に基づいてルーティングを行い、ＶＰＮ基盤の音声パケットのための通話路が形成された後には、ＮＡＰＴテーブル１３０に保存されたＲＴＰ情報に基づいてＶＰＮ基盤の音声パケットをルーティングする。
【００３３】
図４は、本発明の一実施形態によるＶＰＮで音声データを処理する方法についてのフローチャートである。図４を参照すれば、本発明の一実施形態によるＶＰＮで音声データを処理する方法は、次の通りである。
【００３４】
先ず、ＶｏＩＰ処理のための音声データ処理装置１００の入力部１１０で、ＶＰＮ基盤の音声パケット(voice packet)が確認された場合には(ステップ１１０。なお、図においてはステップをＳと略す。以下同じ。)、音声データ処理装置１００の分析部１２０は、その音声パケットからＲＴＰ情報を検出し(ステップ１２０)、そのＲＴＰ情報をアドレス変換テーブル(例えば、ＮＡＰＴテーブル等)に登録する(ステップ１３０)。すなわち、音声データ処理装置１００で外部に伝送する音声パケットが生成され、音声データ処理装置１００が音声パケットを受信した場合には、音声データ処理装置１００は、その音声パケットのＲＴＰポート情報を検出し、そのＲＴＰポート情報をアドレス変換テーブルに登録する。
【００３５】
これは、追って生成されるＶＰＮ基盤の音声パケットについて、アドレス変換テーブルに登録されたＲＴＰポート情報を用いてルーティングするためである。
【００３６】
上記のように該当音声パケットのＲＴＰポート情報をアドレス変換テーブルに登録すると、音声データ処理装置１００は、上記音声パケットの発信側と受信側との間に通話路が形成されたか否かを確認して、通話路が形成された場合には(ステップ１４０)、ＶＰＮ基盤の音声パケットについて上記住所変換テーブルに基づいてアドレス変換を行う(ステップ１５０)。すなわち、通話路の形成後に、生成される音声パケットは、パケットシェイピング(packet shaping)を介して、ＶＰＮカプセル化を行なわずに、上記アドレス変換テーブルに登録されたアドレス変換情報(例えば、ＲＴＰポート情報等)を用いたアドレス変換を行い、アドレス変換後に上記発信側及び受信側の間で音声パケットを送/受信する。
【００３７】
これによって、ＶＰＮ基盤の音声パケットについてＶＰＮカプセル化を行わないことで、ＶＰＮを用いる２端末(terminal)間にも伝送遅延及び帯域幅の浪費無しで、ＶＰＮ接続(connection)を行うようになる。すなわち、ＶＰＮで伝送パケットをコーディングする場合に、周期的に生成されるパケットデータを伝送する度に、ＶＰＮカプセル化しないことによって、該当パケットの伝送遅延及び帯域幅の浪費を減らすようにするものである。
【００３８】
図５は、本発明の一実施形態による発信側及び受信側で音声データを処理する手順を示す図面である。図５を参照すれば、本発明の一実施形態による音声データ処理装置を用いた発信側サーバー３００及び受信側サーバー４００でＶＰＮ基盤音声データを処理する手順は、次の通りである。
【００３９】
先ず、ＶＰＮ基盤音声パケット(voice packet)を発信しようとする発信側サーバー３００は、その音声パケットのＲＴＰポート情報(例えば、ＭＧＩ(Media Gateway)ＲＴＰポート情報等)を検出した(ステップ２０５)後に、そのＲＴＰポート情報をＮＡＰＴテーブルに登録する(ステップ２１０)。これは、通話路形成以後のＶＰＮ基盤音声パケットルーティング時に、参照するためである。そして、上記音声パケットをＶＰＮパケットに変換した(ステップ２１５)後に、ＶＰＮパケットを、受信側サーバー４００に伝達する(ステップ２２０)。すなわち、音声パケットについてＶＰＮカプセル化を行うことによって、ＶＰＮパケットに変換した後に、そのＶＰＮパケットを受信側サーバー４００に伝達するものである。
【００４０】
受信側サーバー４００は、受信されたＶＰＮパケットからＲＴＰポート情報を確認した後に(ステップ２２５)、そのＲＴＰポート情報を、ＮＡＰＴテーブルに登録する(ステップ２３０)。この際、受信側サーバー４００は、受信されたＶＰＮパケットについてパケットシェイピング(packet shaping)を介してＲＴＰポート情報を確認する。受信側サーバー４００は、上記ＶＰＮパケットの受信についての応答メッセージをＶＰＮパケットで構成し(ステップ２３５)、発信側サーバー３００に伝達する(ステップ２４０)。
【００４１】
上記のような処理過程により、発信側サーバー３００と受信側サーバー４００間に通話路が形成された場合には、発信側サーバー３００及び受信側サーバー４００は、以後に生成される音声パケットについて、ＮＡＰＴテーブル情報を参照したルーティングを行う(ステップ２５０)。すなわち、発信側サーバー３００と受信側サーバー４００間に通話路が形成された以後に発信または受信する音声パケットが発生した場合には、発信側サーバー３００及び受信側サーバー４００は、その音声パケットについてＶＰＮカプセル化を行わずに、上記過程(ステップ２１０及びステップ２３０)において、ＮＡＰＴテーブルに各々登録されたＲＴＰポート情報を用いてルーティングを行うものである。
【００４２】
以上、添付図面を参照しながら本発明の好適な実施形態について説明したが、本発明は上記実施形態に限定されるものではない。当業者であれば、特許請求の範囲に記載された範囲内において、各種の変更例または修正例を想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものである。
【００４３】
より具体的には、上記例では、ＶＰＮ基盤音声パケットをＶＰＮパケットに変換せずにルーティングできるようにするため、該当音声パケットからＲＴＰポート情報を出力し、そのＲＴＰポート情報をＮＡＰＴテーブルに登録する装置及び過程について説明している。しかしながら、本発明は音声パケットのＲＴＰポート情報を、ＮＡＰＴテーブルに登録することに限定するわけではない。すなわち、本発明は、ＲＴＰを用いたＶＰＮ基盤音声パケットルーティングに必要なアドレス情報を音声パケットから検出し、そのルーティング情報を用いてルーティングを行うあらゆる処理過程に関するものである。
【図面の簡単な説明】
【００４４】
【図１Ａ】仮想私設網で音声コーデックのために必要な帯域幅が増加することを説明するための図面である。
【図１Ｂ】仮想私設網で音声コーデックのために必要な帯域幅が増加することを説明するための図面である。
【図２Ａ】仮想私設網で音声コーデックのために必要な帯域幅が増加することを説明するための図面である。
【図２Ｂ】仮想私設網で音声コーデックのために必要な帯域幅が増加することを説明するための図面である。
【図３】本発明の一実施形態の仮想私設網で音声データを処理する装置についての概略的なブロック図である。
【図４】本発明の一実施形態の仮想私設網で音声データを処理する方法についてのフローチャートである。
【図５】本発明の一実施形態の発信側及び受信側で音声データを処理する手順を示す図面である。
【符号の説明】
【００４５】
１００  データサーバー
１１０  入力部
１２０  分析部
１３０  ＮＡＰＴテーブル
１４０  ルーティングテーブル
１５０  ＶＰＮ処理部
１６０  ルーティング部
２００  ＩＰ網
【図１Ａ】
2006115507.tif 000003
【図１Ｂ】
2006115507.tif 000004
【図２Ａ】
2006115507.tif 000005
【図２Ｂ】
2006115507.tif 000006
【図３】
2006115507.tif 000007
【図４】
2006115507.tif 000008
【図５】
2006115507.tif 000009