JP2001053794A - Ｉｐ通信のリアルタイムバックアップ通信方法 - Google Patents
Ｉｐ通信のリアルタイムバックアップ通信方法Info
- Publication number
- JP2001053794A JP2001053794A JP22486899A JP22486899A JP2001053794A JP 2001053794 A JP2001053794 A JP 2001053794A JP 22486899 A JP22486899 A JP 22486899A JP 22486899 A JP22486899 A JP 22486899A JP 2001053794 A JP2001053794 A JP 2001053794A
- Authority
- JP
- Japan
- Prior art keywords
- communication
- real
- time
- node
- failure
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5691—Access to open networks; Ingress point selection, e.g. ISP selection
- H04L12/5692—Selection among different networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/14—Network analysis or design
- H04L41/142—Network analysis or design using statistical or mathematical methods
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/28—Flow control; Congestion control in relation to timing considerations
- H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/22—Arrangements for supervision, monitoring or testing
- H04M3/2254—Arrangements for supervision, monitoring or testing in networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/0024—Services and arrangements where telephone services are combined with data services
- H04M7/0057—Services where the data services network provides a telephone service in addition or as an alternative, e.g. for backup purposes, to the telephone service provided by the telephone services network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2207/00—Type of exchange or network, i.e. telephonic medium, in which the telephonic communication takes place
- H04M2207/20—Type of exchange or network, i.e. telephonic medium, in which the telephonic communication takes place hybrid systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/08—Indicating faults in circuits or apparatus
- H04M3/12—Marking faulty circuits "busy"; Enabling equipment to disengage itself from faulty circuits ; Using redundant circuits; Response of a circuit, apparatus or system to an error
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/4228—Systems providing special services or facilities to subscribers in networks
- H04M3/42289—Systems providing special services or facilities to subscribers in networks with carrierprovider selection by subscriber
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Mathematical Analysis (AREA)
- Probability & Statistics with Applications (AREA)
- Algebra (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Mathematical Optimization (AREA)
- Mathematical Physics (AREA)
- Physics & Mathematics (AREA)
- Pure & Applied Mathematics (AREA)
- Multimedia (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
- Maintenance And Management Of Digital Transmission (AREA)
- Telephonic Communication Services (AREA)
Abstract
(57)【要約】
【課題】 経済的であるインターネット網の網障害、網
遅延時間による通信品質の低下を安価に、且つ、簡略に
回避する。 【解決手段】 送信側ノード１２０と受信側ノード１３
０との間を接続するＩＰ網１００の上のリアルタイム通
信中のリアルタイム通信の障害の発生を検出して、リア
ルタイム通信の通信呼を送信側ノード１３０と受信側ノ
ード１２０との間で自動的に公衆網１１０へ迂回させ
る。このような迂回により、リアルタイム通信を継続す
ることができる。障害発生は、リアルタイム通信の品質
を確保できない程度の遅延時間の発生である。周期的送
受信には、ＩＣＭＰが用いられる。リアルタイム通信の
途中に新たなリアルタイム通信呼が発生することがあ
る。そのような場合、その新たなリアルタイム通信も公
衆網１１０上に迂回させられて、そのリアルタイム通信
が可能になる。その障害が回復した場合は、リアルタイ
ム通信は、公衆網からＩＰ網に戻される。
遅延時間による通信品質の低下を安価に、且つ、簡略に
回避する。 【解決手段】 送信側ノード１２０と受信側ノード１３
０との間を接続するＩＰ網１００の上のリアルタイム通
信中のリアルタイム通信の障害の発生を検出して、リア
ルタイム通信の通信呼を送信側ノード１３０と受信側ノ
ード１２０との間で自動的に公衆網１１０へ迂回させ
る。このような迂回により、リアルタイム通信を継続す
ることができる。障害発生は、リアルタイム通信の品質
を確保できない程度の遅延時間の発生である。周期的送
受信には、ＩＣＭＰが用いられる。リアルタイム通信の
途中に新たなリアルタイム通信呼が発生することがあ
る。そのような場合、その新たなリアルタイム通信も公
衆網１１０上に迂回させられて、そのリアルタイム通信
が可能になる。その障害が回復した場合は、リアルタイ
ム通信は、公衆網からＩＰ網に戻される。
Description
【０００１】
【発明の属する技術分野】本発明は、ＩＰ通信のリアル
タイムバックアップ通信方法に関し、特に、公衆網を利
用するＩＰ通信のリアルタイムバックアップ通信方法に
関する。
タイムバックアップ通信方法に関し、特に、公衆網を利
用するＩＰ通信のリアルタイムバックアップ通信方法に
関する。
【０００２】
【従来の技術】近年、インターネット、イントラネッ
ト、エキストラネット（これらは、以下、インターネッ
ト網又はＩＰ網といわれる）上の音声、動画のようなデ
ータは、リアルタイム通信が行われ始めている。そのリ
アルタイム通信の品質をできるだけ保証するためのＱｏ
Ｓ（品質保証）制御に関して、ＩＥＴＦ標準化の活動が
活発になってきており、以下に、その主なものが記述さ
れる。 １．RSVP（ReSource reserVation Protocol ）：資源予
約プロトコル ２．RTP/RTCP（Real-time Transport Protocol）／（Re
al-time Transport Control Protocol）：リアルタイム
通信制御プロトコル ３．DiffServe（Differentiated Services）：ＩＰヘッ
ダを用いた優先制御 ４．RTSP（Real-time Transport Streaming Protoco
l）：リアルタイム・ストリームデータ制御プロトコル
ト、エキストラネット（これらは、以下、インターネッ
ト網又はＩＰ網といわれる）上の音声、動画のようなデ
ータは、リアルタイム通信が行われ始めている。そのリ
アルタイム通信の品質をできるだけ保証するためのＱｏ
Ｓ（品質保証）制御に関して、ＩＥＴＦ標準化の活動が
活発になってきており、以下に、その主なものが記述さ
れる。 １．RSVP（ReSource reserVation Protocol ）：資源予
約プロトコル ２．RTP/RTCP（Real-time Transport Protocol）／（Re
al-time Transport Control Protocol）：リアルタイム
通信制御プロトコル ３．DiffServe（Differentiated Services）：ＩＰヘッ
ダを用いた優先制御 ４．RTSP（Real-time Transport Streaming Protoco
l）：リアルタイム・ストリームデータ制御プロトコル
【０００３】これらのＱｏＳ制御は、これのみでは、イ
ンターネット網上で安定したリアルタイム通信を行うこ
とは不可能であり、例えば、インターネット網に接続さ
れるノードの障害、網障害により送信側ノードからの音
声データ、動画データなどのリアルタイム通信呼が受信
側ノードでエラーを発生することになる：再送制御を行
わないＵＤＰ（User Datagram Protocol）手順での通信
形態であるリアルタイム通信は、インターネット網障害
をノード側で検出する手段がなく、その障害が対向ノー
ド障害であるか、網障害であるか、どちらであるかを区
別することができない。
ンターネット網上で安定したリアルタイム通信を行うこ
とは不可能であり、例えば、インターネット網に接続さ
れるノードの障害、網障害により送信側ノードからの音
声データ、動画データなどのリアルタイム通信呼が受信
側ノードでエラーを発生することになる：再送制御を行
わないＵＤＰ（User Datagram Protocol）手順での通信
形態であるリアルタイム通信は、インターネット網障害
をノード側で検出する手段がなく、その障害が対向ノー
ド障害であるか、網障害であるか、どちらであるかを区
別することができない。
【０００４】このような現状では、ユーザーからの通信
異常申告によって始めて網障害を検知する高度な能力を
有する保守技術者は、ノード間にエコー要求メッセージ
を送出し、エコー応答メッセージの返信がないことによ
って始めて異常を確認し、その技術者が手動によりＩＮ
Ｓ等の公衆網に切り替えてバックアップ切り替えを行う
方法をとっている。このような方法の実行に必要な障害
原因の特定のためには、技術者の高度な保守技術が必要
であり、更に、そのような高度の保守技術者は、網障
害、通信障害の特定を行うための多くの工数を必要とし
ていた。更に、ユーザー申請から、高度保守技術者によ
る手動操作に関わる一連の障害解析による時間が多くか
かり、その間の著しいサービスの低下を招いている。
異常申告によって始めて網障害を検知する高度な能力を
有する保守技術者は、ノード間にエコー要求メッセージ
を送出し、エコー応答メッセージの返信がないことによ
って始めて異常を確認し、その技術者が手動によりＩＮ
Ｓ等の公衆網に切り替えてバックアップ切り替えを行う
方法をとっている。このような方法の実行に必要な障害
原因の特定のためには、技術者の高度な保守技術が必要
であり、更に、そのような高度の保守技術者は、網障
害、通信障害の特定を行うための多くの工数を必要とし
ていた。更に、ユーザー申請から、高度保守技術者によ
る手動操作に関わる一連の障害解析による時間が多くか
かり、その間の著しいサービスの低下を招いている。
【０００５】特に、近年のＩＰネットワークによる網の
ダウンサイジング化、フラット（水平）化にともない、
企業内に多く存在する小規模網ごとに、専門的であり、
且つ、高度である保守技術を配置することは経済的にも
困難であり、低級な一般業務との兼任保守兼務者すなわ
ち各部門でアサインされた素人の保守者でも速やかに障
害原因を特定できる仕組みが必要とされ始めてきてい
る。言い換えれば、低信頼、低品質であるが非常に経済
的であるインターネット網の網障害、網遅延時間による
通信品質の低下を安価な方法によりユーザー機器側で監
視して、リアルタイム通信呼の安定かつ継続的な通信を
おこなうことができるＩＰ網の信頼性を経済的に確保す
る構成を確立することの要望が大きくなってきている。
ダウンサイジング化、フラット（水平）化にともない、
企業内に多く存在する小規模網ごとに、専門的であり、
且つ、高度である保守技術を配置することは経済的にも
困難であり、低級な一般業務との兼任保守兼務者すなわ
ち各部門でアサインされた素人の保守者でも速やかに障
害原因を特定できる仕組みが必要とされ始めてきてい
る。言い換えれば、低信頼、低品質であるが非常に経済
的であるインターネット網の網障害、網遅延時間による
通信品質の低下を安価な方法によりユーザー機器側で監
視して、リアルタイム通信呼の安定かつ継続的な通信を
おこなうことができるＩＰ網の信頼性を経済的に確保す
る構成を確立することの要望が大きくなってきている。
【０００６】
【発明が解決しようとする課題】本発明の課題は、非常
に経済的であるインターネット網の網障害、網遅延時間
による通信品質の低下を安価に、且つ、簡略に回避する
ことができるＩＰ通信のリアルタイムバックアップ通信
方法を提供することにある。本発明の他の課題は、リア
ルタイム通信を安定的に、且つ、継続的に実行すること
によりインターネット網の信頼性を経済的に確保する技
術を確立することができるＩＰ通信のリアルタイムバッ
クアップ通信方法を提供することにある。
に経済的であるインターネット網の網障害、網遅延時間
による通信品質の低下を安価に、且つ、簡略に回避する
ことができるＩＰ通信のリアルタイムバックアップ通信
方法を提供することにある。本発明の他の課題は、リア
ルタイム通信を安定的に、且つ、継続的に実行すること
によりインターネット網の信頼性を経済的に確保する技
術を確立することができるＩＰ通信のリアルタイムバッ
クアップ通信方法を提供することにある。
【０００７】
【課題を解決するための手段】その課題を解決するため
の手段が、下記のように表現される。その表現中に現れ
る技術的事項には、括弧（）つきで、番号、記号等が添
記されている。その番号、記号等は、本発明の実施の複
数・形態又は複数の実施例のうちの少なくとも１つの実
施の形態又は複数の実施例を構成する技術的事項、特
に、その実施の形態又は実施例に対応する図面に表現さ
れている技術的事項に付せられている参照番号、参照記
号等に一致している。このような参照番号、参照記号
は、請求項記載の技術的事項と実施の形態又は実施例の
技術的事項との対応・橋渡しを明確にしている。このよ
うな対応・橋渡しは、請求項記載の技術的事項が実施の
形態又は実施例の技術的事項に限定されて解釈されるこ
とを意味しない。
の手段が、下記のように表現される。その表現中に現れ
る技術的事項には、括弧（）つきで、番号、記号等が添
記されている。その番号、記号等は、本発明の実施の複
数・形態又は複数の実施例のうちの少なくとも１つの実
施の形態又は複数の実施例を構成する技術的事項、特
に、その実施の形態又は実施例に対応する図面に表現さ
れている技術的事項に付せられている参照番号、参照記
号等に一致している。このような参照番号、参照記号
は、請求項記載の技術的事項と実施の形態又は実施例の
技術的事項との対応・橋渡しを明確にしている。このよ
うな対応・橋渡しは、請求項記載の技術的事項が実施の
形態又は実施例の技術的事項に限定されて解釈されるこ
とを意味しない。
【０００８】本発明によるＩＰ通信のリアルタイムバッ
クアップ通信方法は、送信側ノード（１２０）と受信側
ノード（１３０）との間を接続するＩＰ網（１００）の
上のリアルタイム通信中のリアルタイム通信の障害の発
生を検出すること、その検出に基づいて、リアルタイム
通信の通信呼を送信側ノード（１２０）と受信側ノード
（１３０）との間で自動的に公衆網（１１０）へ迂回さ
せることとからなる。このような迂回により、リアルタ
イム通信を継続することができる。その発生は、前記リ
アルタイム通信の品質を確保できない程度の遅延時間の
発生である。周期的送受信には、ＩＣＭＰが用いられ
る。
クアップ通信方法は、送信側ノード（１２０）と受信側
ノード（１３０）との間を接続するＩＰ網（１００）の
上のリアルタイム通信中のリアルタイム通信の障害の発
生を検出すること、その検出に基づいて、リアルタイム
通信の通信呼を送信側ノード（１２０）と受信側ノード
（１３０）との間で自動的に公衆網（１１０）へ迂回さ
せることとからなる。このような迂回により、リアルタ
イム通信を継続することができる。その発生は、前記リ
アルタイム通信の品質を確保できない程度の遅延時間の
発生である。周期的送受信には、ＩＣＭＰが用いられ
る。
【０００９】リアルタイム通信の途中に新たなリアルタ
イム通信呼が発生することがある。そのような場合、そ
の新たなリアルタイム通信も公衆網（１１０）上に迂回
させられて、そのリアルタイム通信が可能になる。その
障害が回復した場合は、リアルタイム通信は、公衆網か
らＩＰ網に戻される。
イム通信呼が発生することがある。そのような場合、そ
の新たなリアルタイム通信も公衆網（１１０）上に迂回
させられて、そのリアルタイム通信が可能になる。その
障害が回復した場合は、リアルタイム通信は、公衆網か
らＩＰ網に戻される。
【００１０】公衆網にも障害が発生することがある。迂
回の間、送信側ノードと受信側ノードとの間を接続する
公衆網上のリアルタイム通信の障害の発生が検出され
る。その検出は、送信側ノード（１２０）と受信側ノー
ド（１３０）との間のエコー要求メッセージとエコー応
答メッセージの周期的送受信の時間の検出によって実行
される。その迂回の間の検出は、公衆網（１１０）上に
障害が発生している間にエコー要求メッセージが正常に
受信された場合は、公衆網（１１０）は正常でありノー
ド（１２０又は１３０）が異常であると判断する。
回の間、送信側ノードと受信側ノードとの間を接続する
公衆網上のリアルタイム通信の障害の発生が検出され
る。その検出は、送信側ノード（１２０）と受信側ノー
ド（１３０）との間のエコー要求メッセージとエコー応
答メッセージの周期的送受信の時間の検出によって実行
される。その迂回の間の検出は、公衆網（１１０）上に
障害が発生している間にエコー要求メッセージが正常に
受信された場合は、公衆網（１１０）は正常でありノー
ド（１２０又は１３０）が異常であると判断する。
【００１１】ＩＰ網（又は、単にＩＰ）（１００）上の
その検出は、送信側ノード（１２０）と受信側ノード
（１３０）との間のエコー要求メッセージとエコー応答
メッセージの周期的送受信の時間を検出することにより
実行される。その検出は、エコー応答メッセージが正常
に返信された場合、ＩＰ網（１００）に障害がなく、且
つ、ノード（１２０又は１３０）に障害があると判断す
る。一般的には、ＩＰ（１００）上の障害の回復を検出
することと、公衆網（１１０）上のリアルタイム通信の
障害の発生を検出することとから、ノード（１２０，１
３０）の障害とＩＰ網（１００）の障の判別を行うこと
ができる。
その検出は、送信側ノード（１２０）と受信側ノード
（１３０）との間のエコー要求メッセージとエコー応答
メッセージの周期的送受信の時間を検出することにより
実行される。その検出は、エコー応答メッセージが正常
に返信された場合、ＩＰ網（１００）に障害がなく、且
つ、ノード（１２０又は１３０）に障害があると判断す
る。一般的には、ＩＰ（１００）上の障害の回復を検出
することと、公衆網（１１０）上のリアルタイム通信の
障害の発生を検出することとから、ノード（１２０，１
３０）の障害とＩＰ網（１００）の障の判別を行うこと
ができる。
【００１２】
【発明の実施の形態】図に一致対応して、本発明による
ＩＰ通信のリアルタイムバックアップ通信方法の実施の
形態は、公衆（回線）網１１０がＩＰ（インタネット
網）１００とともに設けられている。そのＩＰ１００に
は、図１に示されるように、ＩＰ側第１接続インタフェ
ース１０１を介して、送信側ノード１２０が接続してい
る。ＩＰ１００は、ＩＰ側第２接続インタフェース１０
２とＩＰ側第３接続インタフェース１０３を介して、受
信側第１ノード１３０と受信側第２ノード１４０にそれ
ぞれに接続している。
ＩＰ通信のリアルタイムバックアップ通信方法の実施の
形態は、公衆（回線）網１１０がＩＰ（インタネット
網）１００とともに設けられている。そのＩＰ１００に
は、図１に示されるように、ＩＰ側第１接続インタフェ
ース１０１を介して、送信側ノード１２０が接続してい
る。ＩＰ１００は、ＩＰ側第２接続インタフェース１０
２とＩＰ側第３接続インタフェース１０３を介して、受
信側第１ノード１３０と受信側第２ノード１４０にそれ
ぞれに接続している。
【００１３】その公衆網１１０には、公衆網側第１接続
インタフェース１１１を介して、送信側ノード１２０が
接続している。公衆網１１０は、公衆網側第２接続イン
タフェース１１２と公衆網側第３接続インタフェース１
１３を介して、受信側第１ノード１３０と受信側第２ノ
ード１４０にそれぞれに接続している。
インタフェース１１１を介して、送信側ノード１２０が
接続している。公衆網１１０は、公衆網側第２接続イン
タフェース１１２と公衆網側第３接続インタフェース１
１３を介して、受信側第１ノード１３０と受信側第２ノ
ード１４０にそれぞれに接続している。
【００１４】送信側音声端末１２２と送信側動画端末１
２３は、送信側ＬＡＮ１２１に接続している。送信側Ｌ
ＡＮ１２１は、送信側ノード１２０に接続している。第
１受信側音声端末１３２と第１受信側動画端末１３３
は、第１受信側ＬＡＮ１３１に接続している。受信側Ｌ
ＡＮ１３１は、受信側第１ノード１３０に接続してい
る。第２受信側音声端末１４２と第２受信側動画端末１
４３は、第２受信側ＬＡＮ１４１に接続している。第２
受信側ＬＡＮ１３１は、受信側第２ノード１４０に接続
している。
２３は、送信側ＬＡＮ１２１に接続している。送信側Ｌ
ＡＮ１２１は、送信側ノード１２０に接続している。第
１受信側音声端末１３２と第１受信側動画端末１３３
は、第１受信側ＬＡＮ１３１に接続している。受信側Ｌ
ＡＮ１３１は、受信側第１ノード１３０に接続してい
る。第２受信側音声端末１４２と第２受信側動画端末１
４３は、第２受信側ＬＡＮ１４１に接続している。第２
受信側ＬＡＮ１３１は、受信側第２ノード１４０に接続
している。
【００１５】音声、動画のようなデータを送受信するマ
ルチメディア通信であるリアルタイム通信では、通信誤
りが発生した時に、メッセージの再送によって遅延を引
き起こす＊プロトコル（図５参照）が”１６進の６”で
あるＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏ
ｌ Ｐｒｏｔｏｃｏｌ）を用いず、誤りが発生しても再
送を行わない＊プロトコルビットが”１６進の１７”で
あるＵＤＰ（ＵｓｅｒＤａｔａｇｒａｍ Ｐｒｏｔｏｃ
ｏｌ）が用いられる。
ルチメディア通信であるリアルタイム通信では、通信誤
りが発生した時に、メッセージの再送によって遅延を引
き起こす＊プロトコル（図５参照）が”１６進の６”で
あるＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏ
ｌ Ｐｒｏｔｏｃｏｌ）を用いず、誤りが発生しても再
送を行わない＊プロトコルビットが”１６進の１７”で
あるＵＤＰ（ＵｓｅｒＤａｔａｇｒａｍ Ｐｒｏｔｏｃ
ｏｌ）が用いられる。
【００１６】ＬＡＮ１２１に接続された音声端末１２２
と動画端末１２３は、図２に示される「ＩＥＥＥ ８０
２．１ＱのＴａｇ付きＥｔｈｅｒｎｅｔフレーム」で構
成される。リアルタイム性が高い音声、動画は、この規
定のＴａｇの内の３ビットのＵｓｅｒ Ｐｒｉｏｒｉｔ
ｙにより最も優先度の高い値に設定されている。
と動画端末１２３は、図２に示される「ＩＥＥＥ ８０
２．１ＱのＴａｇ付きＥｔｈｅｒｎｅｔフレーム」で構
成される。リアルタイム性が高い音声、動画は、この規
定のＴａｇの内の３ビットのＵｓｅｒ Ｐｒｉｏｒｉｔ
ｙにより最も優先度の高い値に設定されている。
【００１７】ＩＰ１００は、リアルタイム性が高い音
声、動画のために、ＱｏＳ（帯域保証）が可能な制御
（例示：ネットワーク層（ＩＰ）を補間する形式のシグ
ナリング制御）として使用され、情報を受信する受信側
の主導により単方向にネットワーク資源を予約するため
のプロトコルとして図３に示されるＲＳＶＰ（ＲｅＳｏ
ｕｒｃｅ ｒｅｓｅｒＶａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：
資源予約プロトコル）、更には、ユーザとＩＳＰ（Ｉｎ
ｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）との
間の契約に基づく優先制御サービスであり、従来、ほと
んど使用されていなかった図４に示されるＩＰヘッダ内
のＴＯＳ（Ｔｙｐｅ Ｏｆ Ｓｅｒｖｉｃｅ）フィール
ド（８ビット長）をＤｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓ
ｅｒｖｉｃｅｓフィールドとして再定義し、その上位６
ビットをＰＨＢ（Ｐｅｒ−Ｈｏｐ−Ｂｅｈａｖｉｏｒ）
フィールドと名付け、その中の３ビットを用いて６段階
の優先度を設定することができるＩＰヘッダを用いた優
先制御であるＤｉｆｆＳｅｒｖｅ（Ｄｉｆｆｅｒｅｎｔ
ｉａｔｅｄ Ｓｅｒｖｉｃｅｓ）、その他（ＩＰ ｏｖｅ
ｒ） のＡＴＭにおけるＱｏＳ設定などの制御が可能な
構成となっている。
声、動画のために、ＱｏＳ（帯域保証）が可能な制御
（例示：ネットワーク層（ＩＰ）を補間する形式のシグ
ナリング制御）として使用され、情報を受信する受信側
の主導により単方向にネットワーク資源を予約するため
のプロトコルとして図３に示されるＲＳＶＰ（ＲｅＳｏ
ｕｒｃｅ ｒｅｓｅｒＶａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：
資源予約プロトコル）、更には、ユーザとＩＳＰ（Ｉｎ
ｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）との
間の契約に基づく優先制御サービスであり、従来、ほと
んど使用されていなかった図４に示されるＩＰヘッダ内
のＴＯＳ（Ｔｙｐｅ Ｏｆ Ｓｅｒｖｉｃｅ）フィール
ド（８ビット長）をＤｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓ
ｅｒｖｉｃｅｓフィールドとして再定義し、その上位６
ビットをＰＨＢ（Ｐｅｒ−Ｈｏｐ−Ｂｅｈａｖｉｏｒ）
フィールドと名付け、その中の３ビットを用いて６段階
の優先度を設定することができるＩＰヘッダを用いた優
先制御であるＤｉｆｆＳｅｒｖｅ（Ｄｉｆｆｅｒｅｎｔ
ｉａｔｅｄ Ｓｅｒｖｉｃｅｓ）、その他（ＩＰ ｏｖｅ
ｒ） のＡＴＭにおけるＱｏＳ設定などの制御が可能な
構成となっている。
【００１８】ＩＰ１００には、更に、網には依存せずに
端末間、すなわち トランスポート層、アプリケーショ
ン間でのリアルタイム通信品質を向上させるために、送
信側端末からのヘッダにメッージ毎の物理時刻情報やシ
ーケンス番号を付与することにより、受信側で再生速度
の制御、メディア間の同期制御をおこなうリアルタイム
通信制御プロトコルであるＲＴＰ／ＲＴＣＰ（Ｒｅａｌ
-ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）／
（Ｒｅａｌ-ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒ
ｏｌ Ｐｒｏｔｏｃｏｌ）、及び、受信側から秒当たり
の動画フレーム数や解像度などの表示品質、通信速度な
どを動的に送信側に伝えるストリームデータ制御プロト
コルであるＲＴＳＰ（Ｒｅａｌ-ｔｉｍｅ Ｔｒａｎｓｐ
ｏｒｔＳｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）が搭載
されて設けられている。
端末間、すなわち トランスポート層、アプリケーショ
ン間でのリアルタイム通信品質を向上させるために、送
信側端末からのヘッダにメッージ毎の物理時刻情報やシ
ーケンス番号を付与することにより、受信側で再生速度
の制御、メディア間の同期制御をおこなうリアルタイム
通信制御プロトコルであるＲＴＰ／ＲＴＣＰ（Ｒｅａｌ
-ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）／
（Ｒｅａｌ-ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒ
ｏｌ Ｐｒｏｔｏｃｏｌ）、及び、受信側から秒当たり
の動画フレーム数や解像度などの表示品質、通信速度な
どを動的に送信側に伝えるストリームデータ制御プロト
コルであるＲＴＳＰ（Ｒｅａｌ-ｔｉｍｅ Ｔｒａｎｓｐ
ｏｒｔＳｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）が搭載
されて設けられている。
【００１９】ＬＡＮ１２１上の送信側音声端末１２２と
第１受信側ＬＡＮ１３１上の第１受信側音声端末１３２
との間で、ＩＰ１００を介してリアルタイム電話通信を
行う場合が、次に考えられる。送信側音声端末１２２
は、図２に示される「ＩＥＥＥ８０２．１Ｑ Ｔａｇ付
きＥｔｈｅｒｎｅｔフレーム」に第１受信側音声端末１
３２に相当するＤＡ（Ｄｅｓｔｉｎａｔｉｏｎ Ａｄｄ
ｒｅｓｓ）を設定し、且つ、そのＴａｇの中のＵｓｅｒ
Ｐｒｉｏｒｉｔｙ に最優先ビットを設定して、送信側
ノード１２０上に送出する。
第１受信側ＬＡＮ１３１上の第１受信側音声端末１３２
との間で、ＩＰ１００を介してリアルタイム電話通信を
行う場合が、次に考えられる。送信側音声端末１２２
は、図２に示される「ＩＥＥＥ８０２．１Ｑ Ｔａｇ付
きＥｔｈｅｒｎｅｔフレーム」に第１受信側音声端末１
３２に相当するＤＡ（Ｄｅｓｔｉｎａｔｉｏｎ Ａｄｄ
ｒｅｓｓ）を設定し、且つ、そのＴａｇの中のＵｓｅｒ
Ｐｒｉｏｒｉｔｙ に最優先ビットを設定して、送信側
ノード１２０上に送出する。
【００２０】送信側ノード１２０は、送信側ＬＡＮ１２
１上のＤＡ（Ｄｅｓｔｉｎａｔｉｏｎ Ａｄｄｒｅｓ
ｓ）から第１受信側音声端末１３２に相当するＩＰ番号
（受信側第１ノード１３０のＩＰ番号）に変換すると同
時に、Ｕｓｅｒ Ｐｒｉｏｒｉｔｙの最優先ビットを検
出し、ＩＰ１００のＱｏＳ制御［ＲＳＶＰ、ＤｉｆｆＳ
ｅｒｖｅ または、（ＩＰ ｏｖｅｒ） ＡＴＭのＱｏ
Ｓ］にマッピングする。
１上のＤＡ（Ｄｅｓｔｉｎａｔｉｏｎ Ａｄｄｒｅｓ
ｓ）から第１受信側音声端末１３２に相当するＩＰ番号
（受信側第１ノード１３０のＩＰ番号）に変換すると同
時に、Ｕｓｅｒ Ｐｒｉｏｒｉｔｙの最優先ビットを検
出し、ＩＰ１００のＱｏＳ制御［ＲＳＶＰ、ＤｉｆｆＳ
ｅｒｖｅ または、（ＩＰ ｏｖｅｒ） ＡＴＭのＱｏ
Ｓ］にマッピングする。
【００２１】ここでは、送信側ノード１２０が、ＱｏＳ
制御として、図４のＤｉｆｆＳｅｒｖｅにおけるＩＰヘ
ッダのＰＨＢ（Ｐｅｒ−Ｈｏｐ−Ｂｅｈａｖｉｏｒ）フ
ィールドの中の３ビットに最優先ビットを設定してＩＰ
網に送出する場合が１例として説明されている。その結
果、図１に示されるように、送信側音声端末１２２−送
信側ＬＡＮ１２１−送信側ノード１２０−ＩＰ側第１接
続インタフェース１０１−ＩＰ１００−ＩＰ側第２接続
インタフェース１０２−受信側第１ノード１３０までの
ＱｏＳを確保したリアルタイム通信を確保することがで
き、更に、受信側第１ノード１３０は内部ＬＡＮ１３１
から第１受信側音声端末１３２までを、図２の「８０
２．１Ｑ Ｔａｇ付きＥｔｈｅｒｎｅｔフレーム」に第
１受信側音声端末１３２に相当するＤＡ（Ｄｅｓｔｉｎ
ａｔｉｏｎ Ａｄｄｒｅｓｓ）及びＴａｇ内にＵｓｅｒ
Ｐｒｉｏｒｉｔｙ に最優先ビットを設定して送出する
ことにより、送信側音声端末１２２と第１受信側音声端
末１３２の間をＩＰ１００を介したＱｏＳ制御によるリ
アルタイム通信が可能となる。
制御として、図４のＤｉｆｆＳｅｒｖｅにおけるＩＰヘ
ッダのＰＨＢ（Ｐｅｒ−Ｈｏｐ−Ｂｅｈａｖｉｏｒ）フ
ィールドの中の３ビットに最優先ビットを設定してＩＰ
網に送出する場合が１例として説明されている。その結
果、図１に示されるように、送信側音声端末１２２−送
信側ＬＡＮ１２１−送信側ノード１２０−ＩＰ側第１接
続インタフェース１０１−ＩＰ１００−ＩＰ側第２接続
インタフェース１０２−受信側第１ノード１３０までの
ＱｏＳを確保したリアルタイム通信を確保することがで
き、更に、受信側第１ノード１３０は内部ＬＡＮ１３１
から第１受信側音声端末１３２までを、図２の「８０
２．１Ｑ Ｔａｇ付きＥｔｈｅｒｎｅｔフレーム」に第
１受信側音声端末１３２に相当するＤＡ（Ｄｅｓｔｉｎ
ａｔｉｏｎ Ａｄｄｒｅｓｓ）及びＴａｇ内にＵｓｅｒ
Ｐｒｉｏｒｉｔｙ に最優先ビットを設定して送出する
ことにより、送信側音声端末１２２と第１受信側音声端
末１３２の間をＩＰ１００を介したＱｏＳ制御によるリ
アルタイム通信が可能となる。
【００２２】図５の＊プロトコルの８ビットが１６進の
１である場合には、図６及び図７のＩＣＭＰ（Ｉｎｔｅ
ｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏ
ｃｏｌ）の指定となり、タイプ（メッセージタイプ）の
８ビットが”１６進の８”の場合にはエコー要求、それ
が”０”の場合にはエコー応答をあらわす。これらの要
求・応答の実行の際、ＩＰ１００に接続されているホス
トやノードが生きているかどうかを確認するときにエコ
ー機能が用いられている。このために、あるホスト又は
ノードがメッセージタイプ８のエコー要求を送ると、指
定されたホストやノードは、応答できる状態であれば、
メッセージタイプ０のエコー応答を送り返す。このよう
なエコーによる動作確認は頻繁に行われるものであり、
一般にはピング（ｐｉｎｇ）と呼ばれるユーティリティ
プログラムがエコー要求を送り出す。
１である場合には、図６及び図７のＩＣＭＰ（Ｉｎｔｅ
ｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏ
ｃｏｌ）の指定となり、タイプ（メッセージタイプ）の
８ビットが”１６進の８”の場合にはエコー要求、それ
が”０”の場合にはエコー応答をあらわす。これらの要
求・応答の実行の際、ＩＰ１００に接続されているホス
トやノードが生きているかどうかを確認するときにエコ
ー機能が用いられている。このために、あるホスト又は
ノードがメッセージタイプ８のエコー要求を送ると、指
定されたホストやノードは、応答できる状態であれば、
メッセージタイプ０のエコー応答を送り返す。このよう
なエコーによる動作確認は頻繁に行われるものであり、
一般にはピング（ｐｉｎｇ）と呼ばれるユーティリティ
プログラムがエコー要求を送り出す。
【００２３】送信側ノード１２０は、図８に示されるよ
うに、図５に示される送信元アドレスに送信側ノード１
２０のＩＰアドレス番号を設定し、宛先アドレスにノー
ド１３０のＩＰアドレス番号を設定し、＊プロトコルに
１６進の１（ＩＣＭＰ）を設定し、更に、 図７に示さ
れるメッセージタイプに１６進の８（図６のエコー要
求）を設定し、図７のデータ（可変長）にループバック
用テストデータを設定した図８のエコー要求メッセージ
８００をＩＰ１００を介して、受信側第１ノード１３０
に送出する。
うに、図５に示される送信元アドレスに送信側ノード１
２０のＩＰアドレス番号を設定し、宛先アドレスにノー
ド１３０のＩＰアドレス番号を設定し、＊プロトコルに
１６進の１（ＩＣＭＰ）を設定し、更に、 図７に示さ
れるメッセージタイプに１６進の８（図６のエコー要
求）を設定し、図７のデータ（可変長）にループバック
用テストデータを設定した図８のエコー要求メッセージ
８００をＩＰ１００を介して、受信側第１ノード１３０
に送出する。
【００２４】受信側第１ノード１３０が、図８のエコー
要求メッセージ８００を受信すると、図５の送信元アド
レスに受信側第１ノード１３０のＩＰアドレス番号を設
定し、宛先アドレスに送信側ノード１２０のＩＰアドレ
ス番号を設定し、＊プロトコルに１６進の１（ＩＣＭ
Ｐ）を設定し、更に、図７のメッセージタイプには１６
進の０（図６のエコー応答）を設定、図７のデータ（可
変長）に受信した図８のエコー要求メッセージ８００の
データフィールドに書き込まれているループバック用テ
ストデータをそのままコピーして、図８のエコー応答メ
ッセージ８０１として送信側ノード１２０に送り返すこ
とにより、送信元ノードである送信側ノード１２０はル
ープバックテストにより、データ授受の状況を確認する
ことができ、送信側ノード１２０−ＩＰ側第１接続イン
タフェース１０１−ＩＰ１００−ＩＰ側第２接続インタ
フェース１０２−受信側第１ノード１３０の経路での網
及びノードの障害を検出することができると同時に、ノ
ード１２０がエコー要求メッセージ８００を送出してか
ら、受信側第１ノード１３０から送り返されるエコー応
答メッセージ８０１が受信されるまでの一巡時間（ラウ
ンドトリップタイム）がリアルタイム通信品質を確保で
きる時間以内であるか、例えば、ＩＴＵ−ＴＧ．１１４
で規定する１５０ｍｓｅｃ以内であれば、良好なリアル
タイム電話通信品質を確保できていることを確認するこ
とができる。
要求メッセージ８００を受信すると、図５の送信元アド
レスに受信側第１ノード１３０のＩＰアドレス番号を設
定し、宛先アドレスに送信側ノード１２０のＩＰアドレ
ス番号を設定し、＊プロトコルに１６進の１（ＩＣＭ
Ｐ）を設定し、更に、図７のメッセージタイプには１６
進の０（図６のエコー応答）を設定、図７のデータ（可
変長）に受信した図８のエコー要求メッセージ８００の
データフィールドに書き込まれているループバック用テ
ストデータをそのままコピーして、図８のエコー応答メ
ッセージ８０１として送信側ノード１２０に送り返すこ
とにより、送信元ノードである送信側ノード１２０はル
ープバックテストにより、データ授受の状況を確認する
ことができ、送信側ノード１２０−ＩＰ側第１接続イン
タフェース１０１−ＩＰ１００−ＩＰ側第２接続インタ
フェース１０２−受信側第１ノード１３０の経路での網
及びノードの障害を検出することができると同時に、ノ
ード１２０がエコー要求メッセージ８００を送出してか
ら、受信側第１ノード１３０から送り返されるエコー応
答メッセージ８０１が受信されるまでの一巡時間（ラウ
ンドトリップタイム）がリアルタイム通信品質を確保で
きる時間以内であるか、例えば、ＩＴＵ−ＴＧ．１１４
で規定する１５０ｍｓｅｃ以内であれば、良好なリアル
タイム電話通信品質を確保できていることを確認するこ
とができる。
【００２５】このような前提条件の下で、図１の送信側
音声端末１２２が送信側ＬＡＮ１２１、送信側ノード１
２０、ＩＰ側第１接続インタフェース１０１、ＩＰ１０
０、ＩＰ側第２接続インタフェース１０２、受信側第１
ノード１３０、第１受信側ＬＡＮ１３１を介して第１受
信側音声端末１３２の間でリアルタイム通信を行う場
合、送信側ＬＡＮ１２１から到来する図２のＴａｇ付き
Ｅｔｈｅｒｎｅｔフレームを送信側ノード１２０で受信
し、このＴａｇ内のＵｓｅｒ Ｐｒｉｏｒｉｔｙにより
ＱｏＳの最優先検出を行い、ＤＡ（Ｄｅｓｔｉｎａｔｉ
ｏｎ Ａｄｄｒｅｓｓ）から第１受信側音声端末１３２
へのＩＰアドレス番号への変換が行われる。
音声端末１２２が送信側ＬＡＮ１２１、送信側ノード１
２０、ＩＰ側第１接続インタフェース１０１、ＩＰ１０
０、ＩＰ側第２接続インタフェース１０２、受信側第１
ノード１３０、第１受信側ＬＡＮ１３１を介して第１受
信側音声端末１３２の間でリアルタイム通信を行う場
合、送信側ＬＡＮ１２１から到来する図２のＴａｇ付き
Ｅｔｈｅｒｎｅｔフレームを送信側ノード１２０で受信
し、このＴａｇ内のＵｓｅｒ Ｐｒｉｏｒｉｔｙにより
ＱｏＳの最優先検出を行い、ＤＡ（Ｄｅｓｔｉｎａｔｉ
ｏｎ Ａｄｄｒｅｓｓ）から第１受信側音声端末１３２
へのＩＰアドレス番号への変換が行われる。
【００２６】同時に、図１０のＡに示されるように送信
側ＬＡＮ１２１から送信側ノード１２０に到来する音声
データパケットにより、図１０のＢに示される音声デー
タパケット断検出用のタイムオーバーカウンタをクリア
して、音声通信中モード（Ｌレベル）にする。以降、送
信側ＬＡＮ１２１から送信側ノード１２０に、リアルタ
イム通信を確保するために引き続き一定時間以内には、
必ず到来する音声データパケット毎に、図１０のＢに示
される音声データパケット断検出用のタイムオーバーカ
ウンタをクリアして、音声通信中モード（Ｌレベル）を
継続する。
側ＬＡＮ１２１から送信側ノード１２０に到来する音声
データパケットにより、図１０のＢに示される音声デー
タパケット断検出用のタイムオーバーカウンタをクリア
して、音声通信中モード（Ｌレベル）にする。以降、送
信側ＬＡＮ１２１から送信側ノード１２０に、リアルタ
イム通信を確保するために引き続き一定時間以内には、
必ず到来する音声データパケット毎に、図１０のＢに示
される音声データパケット断検出用のタイムオーバーカ
ウンタをクリアして、音声通信中モード（Ｌレベル）を
継続する。
【００２７】音声通信の終了に伴って、図１０のＢに示
される音声データパケット検出用のタイムオーバーカウ
ンタのクリア信号が到来しなくなるので、当該カウンタ
はタイムオーバーによりＨレベルの無通話モードにな
る。送信側ノード１２０はＱｏＳ制御として図４に示さ
れるＤｉｆｆＳｅｒｖｅにおけるＩＰヘッダのＰＨＢ
（Ｐｅｒ−Ｈｏｐ−Ｂｅｈａｖｉｏｒ）フィールドの中
の３ビットに最優先ビットを設定し、図５の＊プロトコ
ルに１６進の１７（ＵＤＰ：Ｕｓｅｒ Ｄａｔａｇｒａ
ｍ Ｐｒｏｔｏｃｏｌ）を設定し、送信元アドレスに送
信側音声端末１２２を収容する送信側ノード１２０のＩ
Ｐアドレス番号を設定し、宛先アドレスに第１受信側音
声端末１３２を収容する受信側第１ノード１３０のＩＰ
アドレス番号を設定して、図２のＩＥＥＥ８０２．１Ｑ
Ｔａｇ付きＥｔｈｅｒｎｅｔフレームのペイロードに
ある音声データを図９のトランスポート層のＵＤＰのデ
ータ（可変部）にコピーし、ＩＰ１００を介して、受信
側第１ノード１３０に送出する。受信側第１ノード１３
０はこの受信した音声データを図９のＵＤＰの宛先ポー
ト番号即ちアプリケーション、図４のＩＰヘッダ内のＰ
ＨＢ（Ｐｅｒ−Ｈｏｐ−Ｂｅｈａｖｉｏｒ）内の３ビッ
トの優先ビットにより、リアルタイム通信呼すなわちＱ
ｏＳ制御の要求呼を検出し、第１受信側ＬＡＮ１３１上
に図２のＩＥＥＥ８０２．１Ｑ Ｔａｇ付きＥｔｈｅｒ
ｎｅｔフレーム内にＵｓｅｒ Ｐｒｉｏｒｉｔｙに最優
先ビットを設定して、第１受信側音声端末１３２に送出
する。この結果、送信側音声端末１２２と第１受信側音
声端末１３２との間でのＱｏＳを保証したリアルタイム
通信が可能となる。
される音声データパケット検出用のタイムオーバーカウ
ンタのクリア信号が到来しなくなるので、当該カウンタ
はタイムオーバーによりＨレベルの無通話モードにな
る。送信側ノード１２０はＱｏＳ制御として図４に示さ
れるＤｉｆｆＳｅｒｖｅにおけるＩＰヘッダのＰＨＢ
（Ｐｅｒ−Ｈｏｐ−Ｂｅｈａｖｉｏｒ）フィールドの中
の３ビットに最優先ビットを設定し、図５の＊プロトコ
ルに１６進の１７（ＵＤＰ：Ｕｓｅｒ Ｄａｔａｇｒａ
ｍ Ｐｒｏｔｏｃｏｌ）を設定し、送信元アドレスに送
信側音声端末１２２を収容する送信側ノード１２０のＩ
Ｐアドレス番号を設定し、宛先アドレスに第１受信側音
声端末１３２を収容する受信側第１ノード１３０のＩＰ
アドレス番号を設定して、図２のＩＥＥＥ８０２．１Ｑ
Ｔａｇ付きＥｔｈｅｒｎｅｔフレームのペイロードに
ある音声データを図９のトランスポート層のＵＤＰのデ
ータ（可変部）にコピーし、ＩＰ１００を介して、受信
側第１ノード１３０に送出する。受信側第１ノード１３
０はこの受信した音声データを図９のＵＤＰの宛先ポー
ト番号即ちアプリケーション、図４のＩＰヘッダ内のＰ
ＨＢ（Ｐｅｒ−Ｈｏｐ−Ｂｅｈａｖｉｏｒ）内の３ビッ
トの優先ビットにより、リアルタイム通信呼すなわちＱ
ｏＳ制御の要求呼を検出し、第１受信側ＬＡＮ１３１上
に図２のＩＥＥＥ８０２．１Ｑ Ｔａｇ付きＥｔｈｅｒ
ｎｅｔフレーム内にＵｓｅｒ Ｐｒｉｏｒｉｔｙに最優
先ビットを設定して、第１受信側音声端末１３２に送出
する。この結果、送信側音声端末１２２と第１受信側音
声端末１３２との間でのＱｏＳを保証したリアルタイム
通信が可能となる。
【００２８】同時に、送信側ノード１２０はＱｏＳ制御
として、図４のＤｉｆｆＳｅｒｖｅにおけるＩＰヘッダ
のＰＨＢ（Ｐｅｒ−Ｈｏｐ−Ｂｅｈａｖｉｏｒ）フィー
ルドの中の３ビットに最優先ビットを設定し、図５の＊
プロトコルに１６進の１（ＩＣＭＰ：Ｉｎｔｅｒｎｅｔ
Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）
を設定し、送信元アドレスに送信側音声端末１２２のＩ
Ｐアドレス番号を設定し、宛先アドレスに第１受信側音
声端末１３２のＩＰアドレス番号（受信側第１ノード１
３０のＩＰアドレス番号）を設定し、図７のメッセージ
タイプに１６進の８（エコー要求）を設定し、データ
（可変長）にループバック用テストデータを設定した図
８のエコー要求メッセージ８００をＩＰ１００を介して
受信側第１ノード１３０に送出する。
として、図４のＤｉｆｆＳｅｒｖｅにおけるＩＰヘッダ
のＰＨＢ（Ｐｅｒ−Ｈｏｐ−Ｂｅｈａｖｉｏｒ）フィー
ルドの中の３ビットに最優先ビットを設定し、図５の＊
プロトコルに１６進の１（ＩＣＭＰ：Ｉｎｔｅｒｎｅｔ
Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）
を設定し、送信元アドレスに送信側音声端末１２２のＩ
Ｐアドレス番号を設定し、宛先アドレスに第１受信側音
声端末１３２のＩＰアドレス番号（受信側第１ノード１
３０のＩＰアドレス番号）を設定し、図７のメッセージ
タイプに１６進の８（エコー要求）を設定し、データ
（可変長）にループバック用テストデータを設定した図
８のエコー要求メッセージ８００をＩＰ１００を介して
受信側第１ノード１３０に送出する。
【００２９】以降、このエコー要求メッセージ８００
は、図１０のＢの音声データパケット断検出用のタイム
オーバーカウンタ出力がＬレベルである音声通信中モー
ドの間に、図１０のＣの一定間隔（周期）毎に、定期的
に送出される。送信側ノード１２０は、図１０のＣの一
定時間以内に受信側第１ノード１３０から送り返される
エコー応答メッセージ８０１が受信されるまでの一巡時
間（ラウンドトリップタイム）がリアルタイム通信品質
を確保できる時間以内であるか否かを、図１０のＤのタ
イムオーバーカウンタで検出し、図１０のＥのようにラ
ウンドトリップタイム経過後のエコー応答メッセージ８
０１の受信、及び、図１０のＦのようにエコー応答メッ
セージ８０１が返信されない場合には、ＩＰ又は対向ノ
ード１３０の障害と判断する。
は、図１０のＢの音声データパケット断検出用のタイム
オーバーカウンタ出力がＬレベルである音声通信中モー
ドの間に、図１０のＣの一定間隔（周期）毎に、定期的
に送出される。送信側ノード１２０は、図１０のＣの一
定時間以内に受信側第１ノード１３０から送り返される
エコー応答メッセージ８０１が受信されるまでの一巡時
間（ラウンドトリップタイム）がリアルタイム通信品質
を確保できる時間以内であるか否かを、図１０のＤのタ
イムオーバーカウンタで検出し、図１０のＥのようにラ
ウンドトリップタイム経過後のエコー応答メッセージ８
０１の受信、及び、図１０のＦのようにエコー応答メッ
セージ８０１が返信されない場合には、ＩＰ又は対向ノ
ード１３０の障害と判断する。
【００３０】この場合、送信側ノード１２０は、接続先
の第１受信側音声端末１３２のＩＰアドレス番号（受信
側第１ノード１３０のＩＰアドレス番号）から、公衆網
１１０の電話番号に変換してダイアルアップによる公衆
網接続により、送信側ノード１２０−公衆網側第１接続
インタフェース１１１−公衆網１１０−公衆網側第２接
続インタフェース１１２−受信側第１ノード１３０まで
のバックアップ迂回ルートを確保し、送信側ノード１２
０は受信側第１ノード１３０に、バックアップ切り替え
迂回後の公衆網１１０を介して、図１１のエコー要求メ
ッセージ１１００を送信して、受信側第１ノード１３０
からのエコー応答メッセージ１１０１が許容時間以内に
返信された場合には、ＩＰ１００が障害で受信側第１ノ
ード１３０は正常であり、エコー応答メッセージ１１０
１が返信されない場合には受信側第１ノード１３０が異
常であると判別することができ、受信側第１ノード１３
０の障害を検出した場合には、緊急処置を要請すること
ができる。
の第１受信側音声端末１３２のＩＰアドレス番号（受信
側第１ノード１３０のＩＰアドレス番号）から、公衆網
１１０の電話番号に変換してダイアルアップによる公衆
網接続により、送信側ノード１２０−公衆網側第１接続
インタフェース１１１−公衆網１１０−公衆網側第２接
続インタフェース１１２−受信側第１ノード１３０まで
のバックアップ迂回ルートを確保し、送信側ノード１２
０は受信側第１ノード１３０に、バックアップ切り替え
迂回後の公衆網１１０を介して、図１１のエコー要求メ
ッセージ１１００を送信して、受信側第１ノード１３０
からのエコー応答メッセージ１１０１が許容時間以内に
返信された場合には、ＩＰ１００が障害で受信側第１ノ
ード１３０は正常であり、エコー応答メッセージ１１０
１が返信されない場合には受信側第１ノード１３０が異
常であると判別することができ、受信側第１ノード１３
０の障害を検出した場合には、緊急処置を要請すること
ができる。
【００３１】更に、このバックアップ迂回によるリアル
タイム通信中は公衆網１１０通信ルートによる公衆網１
１０、及び、受信側第１ノード１３０の正常性を引き続
き監視するために、図８及び図１０の一連の構成による
動作と全く同一の動作、即ち、エコー要求メッセージ８
００を図１１のエコー要求メッセージ１１００に、エコ
ー応答メッセージ８０１を図１１のエコー応答メッセー
ジ１１０１に読み替えて、図１１の公衆網１１０上にも
適用する構成となっている。
タイム通信中は公衆網１１０通信ルートによる公衆網１
１０、及び、受信側第１ノード１３０の正常性を引き続
き監視するために、図８及び図１０の一連の構成による
動作と全く同一の動作、即ち、エコー要求メッセージ８
００を図１１のエコー要求メッセージ１１００に、エコ
ー応答メッセージ８０１を図１１のエコー応答メッセー
ジ１１０１に読み替えて、図１１の公衆網１１０上にも
適用する構成となっている。
【００３２】同時に、送信側ノード１２０は、このＩＰ
網切断／異常障害及びラウンドトリップタイムオーバー
によるＩＰ内遅延時間が規定時間以上となった網輻輳状
態からの正常復旧を監視するために、図１０のＢの条件
の代わりに、送信側ノード１２０と受信側第１ノード１
３０の間のＩＰ障害（ラウンドトリップタイムオーバー
を含む）条件すなわち網障害時には強制的に図１０のＢ
をＬレベルにすることの条件に置き換えて、図１０のＣ
の一定間隔（周期）毎に、エコー要求メッセージ８００
を定期的に送出する。
網切断／異常障害及びラウンドトリップタイムオーバー
によるＩＰ内遅延時間が規定時間以上となった網輻輳状
態からの正常復旧を監視するために、図１０のＢの条件
の代わりに、送信側ノード１２０と受信側第１ノード１
３０の間のＩＰ障害（ラウンドトリップタイムオーバー
を含む）条件すなわち網障害時には強制的に図１０のＢ
をＬレベルにすることの条件に置き換えて、図１０のＣ
の一定間隔（周期）毎に、エコー要求メッセージ８００
を定期的に送出する。
【００３３】送信側ノード１２０は、図８のエコー要求
メッセージ８００すなわち図１０のＣに示される送出の
後、一定時間以内に受信側第１ノード１３０から送り返
されるエコー応答メッセージ８０１が受信されるまでの
一巡時間（ラウンドトリップタイム）がリアルタイム通
信品質を確保できる時間以内であるか否かを、図１０の
Ｄのタイムオーバーカウンタで検出し、図１０のＥのよ
うにラウンドトリップタイム許容制限時間経過後のエコ
ー応答メッセージ８０１の受信、又は、図１０のＦのよ
うにエコー応答メッセージ８０１が返信されない現状の
障害状態から連続（安定）して正常状態に復旧するまで
監視を続ける。すなわち、送信側ノード１２０と受信側
第１ノード１３０の間のバックアップ迂回による通信が
完了した後であっても、送信側ノード１２０と受信側第
１ノード１３０間のＩＰ１００が正常状態を回復するま
で、継続して監視を続けることを意味し、この間に新た
に、受信側第１ノード１３０への通信呼が発生した場合
には、公衆網１１０を介したバックアップ迂回を行うこ
とになる。
メッセージ８００すなわち図１０のＣに示される送出の
後、一定時間以内に受信側第１ノード１３０から送り返
されるエコー応答メッセージ８０１が受信されるまでの
一巡時間（ラウンドトリップタイム）がリアルタイム通
信品質を確保できる時間以内であるか否かを、図１０の
Ｄのタイムオーバーカウンタで検出し、図１０のＥのよ
うにラウンドトリップタイム許容制限時間経過後のエコ
ー応答メッセージ８０１の受信、又は、図１０のＦのよ
うにエコー応答メッセージ８０１が返信されない現状の
障害状態から連続（安定）して正常状態に復旧するまで
監視を続ける。すなわち、送信側ノード１２０と受信側
第１ノード１３０の間のバックアップ迂回による通信が
完了した後であっても、送信側ノード１２０と受信側第
１ノード１３０間のＩＰ１００が正常状態を回復するま
で、継続して監視を続けることを意味し、この間に新た
に、受信側第１ノード１３０への通信呼が発生した場合
には、公衆網１１０を介したバックアップ迂回を行うこ
とになる。
【００３４】ＩＰ１００が正常安定状態を回復したこと
を確認した後、送信側ノード１２０から受信側第１ノー
ド１３０までの公衆網１１０を介したリアルタイム通信
が行われている場合には、この正常状態を回復したＩＰ
１００に切り替えることにより、より経済的な通信を行
うことができる。この場合、正常安定状態に回復したこ
とを検出した時点で、図１０のＢのＩＰ障害条件すなわ
ち、網障害状態である図１０のＢの強制Ｌレベル条件を
一旦クリアして、イニシャル状態であるＨレベルに戻
し、ＩＰへの通信呼の開始時点で、図１０のＡからの正
常シーケンスによりＩＰ１００の障害監視を行う構成で
ある。また、ＩＰ１００が正常状態に回復した時点で速
やかに公衆網１１０からＩＰ１００への切り戻しを行
い、以降は、既述の一連の通常のＩＰ１００を介したリ
アルタイム通信を行うことは当然のことである。
を確認した後、送信側ノード１２０から受信側第１ノー
ド１３０までの公衆網１１０を介したリアルタイム通信
が行われている場合には、この正常状態を回復したＩＰ
１００に切り替えることにより、より経済的な通信を行
うことができる。この場合、正常安定状態に回復したこ
とを検出した時点で、図１０のＢのＩＰ障害条件すなわ
ち、網障害状態である図１０のＢの強制Ｌレベル条件を
一旦クリアして、イニシャル状態であるＨレベルに戻
し、ＩＰへの通信呼の開始時点で、図１０のＡからの正
常シーケンスによりＩＰ１００の障害監視を行う構成で
ある。また、ＩＰ１００が正常状態に回復した時点で速
やかに公衆網１１０からＩＰ１００への切り戻しを行
い、以降は、既述の一連の通常のＩＰ１００を介したリ
アルタイム通信を行うことは当然のことである。
【００３５】こにような実施の形態では、送信側ノード
１２０が発信呼側、受信側第１ノード１３０が着信呼側
として記述されているが、送信側ノード１２０が着信呼
側で受信側第１ノード１３０が発信呼側とした場合、送
信側ノード１２０は図９のＵＤＰ（Ｕｓｅｒ Ｄａｔａ
ｇｒａｍ Ｐｒｏｔｏｃｏｌ）のポート番号すなわちア
プリケーション番号又は図４のＩＰヘッダ内部のＰＨＢ
（Ｐｅｒ−Ｈｏｐ−Ｂｅｈａｖｉｏｒ）のＤｉｆｆＳｅ
ｒｖｅ優先ビットの最優先設定から着信呼がリアルタイ
ム通信呼であることを知ることができ、送信側ノード１
２０が発信呼で受信側第１ノード１３０が着信呼であっ
た図８のエコー要求メッセージ８００及びエコー応答メ
ッセージ８０１による監視、図１０のＡ、Ｂ，Ｃ，Ｄ、
Ｅ、Ｆの一連の動作、及び、図１１に関わるエコー要求
メッセージ１１００およびエコー応答メッセージ１１０
１の一連の動作と全く同一動作を実行することにより、
ノード相互間で対称性を有するＩＰ障害、許容遅延時間
を監視し、迅速な障害検出、回復保守を行うことが可能
となる。
１２０が発信呼側、受信側第１ノード１３０が着信呼側
として記述されているが、送信側ノード１２０が着信呼
側で受信側第１ノード１３０が発信呼側とした場合、送
信側ノード１２０は図９のＵＤＰ（Ｕｓｅｒ Ｄａｔａ
ｇｒａｍ Ｐｒｏｔｏｃｏｌ）のポート番号すなわちア
プリケーション番号又は図４のＩＰヘッダ内部のＰＨＢ
（Ｐｅｒ−Ｈｏｐ−Ｂｅｈａｖｉｏｒ）のＤｉｆｆＳｅ
ｒｖｅ優先ビットの最優先設定から着信呼がリアルタイ
ム通信呼であることを知ることができ、送信側ノード１
２０が発信呼で受信側第１ノード１３０が着信呼であっ
た図８のエコー要求メッセージ８００及びエコー応答メ
ッセージ８０１による監視、図１０のＡ、Ｂ，Ｃ，Ｄ、
Ｅ、Ｆの一連の動作、及び、図１１に関わるエコー要求
メッセージ１１００およびエコー応答メッセージ１１０
１の一連の動作と全く同一動作を実行することにより、
ノード相互間で対称性を有するＩＰ障害、許容遅延時間
を監視し、迅速な障害検出、回復保守を行うことが可能
となる。
【００３６】上記は説明の容易性のために、ＩＰは、イ
ンターネット網として述べられたが、イントラネット
網、エキストラネット網も包含する。ＱｏＳが保証され
たＩＰにおけるリアルタイム通信について言及されてい
るが、ＱｏＳが保証されないベストエフォートである現
状の一般的なＩＰ（インターネット）網を用いて構成す
ることが可能であり、ラウンドトリップタイムの監視に
より遅延時間を監視して制限時間を超えた場合に、公衆
網へのバックアップ迂回を行わせることにより、より経
済的なリアルタイム通信が可能である。
ンターネット網として述べられたが、イントラネット
網、エキストラネット網も包含する。ＱｏＳが保証され
たＩＰにおけるリアルタイム通信について言及されてい
るが、ＱｏＳが保証されないベストエフォートである現
状の一般的なＩＰ（インターネット）網を用いて構成す
ることが可能であり、ラウンドトリップタイムの監視に
より遅延時間を監視して制限時間を超えた場合に、公衆
網へのバックアップ迂回を行わせることにより、より経
済的なリアルタイム通信が可能である。
【００３７】また、上記の基本動作に加えて、ＩＰ（イ
ンターネット）網１００の障害発生時、及び、正常状態
回復時のバックアップ切り替え、切り戻し時に発生する
リアルタイム通信呼のパケットロス、遅延時間などを吸
収して、より容易且つスムースなる通信安定品質を確保
するために、ＭＰ（Ｔｈｅ ＰＰＰ Ｍｕｌｔｉｌｉｎｋ
Ｐｒｏｔｏｃｏｌ）が有益である。
ンターネット）網１００の障害発生時、及び、正常状態
回復時のバックアップ切り替え、切り戻し時に発生する
リアルタイム通信呼のパケットロス、遅延時間などを吸
収して、より容易且つスムースなる通信安定品質を確保
するために、ＭＰ（Ｔｈｅ ＰＰＰ Ｍｕｌｔｉｌｉｎｋ
Ｐｒｏｔｏｃｏｌ）が有益である。
【００３８】
【発明の効果】本発明によるＩＰ通信のリアルタイムバ
ックアップ通信方法は、ＩＰ障害、及び、リアルタイム
通信品質を確保できない程度の遅延時間の発生をリアル
タイム通信障害として、公衆網１１０へ自動的にバック
アップ切り替え迂回でき、低信頼性、低品質であるが非
常に経済的なＩＰ上で、安定且つ高品質なリアルタイム
通信が可能となる経済的な大きな効果に加えて、高度な
保守技術者を配置することなく、低級な保守者すなわち
一般業務との兼任者程度であっても保守が可能な大きな
経済性と障害箇所の迅速な特定、復旧時間の短縮が可能
となり、通信サービス品質向上と経済的な効果を得るこ
とができる。
ックアップ通信方法は、ＩＰ障害、及び、リアルタイム
通信品質を確保できない程度の遅延時間の発生をリアル
タイム通信障害として、公衆網１１０へ自動的にバック
アップ切り替え迂回でき、低信頼性、低品質であるが非
常に経済的なＩＰ上で、安定且つ高品質なリアルタイム
通信が可能となる経済的な大きな効果に加えて、高度な
保守技術者を配置することなく、低級な保守者すなわち
一般業務との兼任者程度であっても保守が可能な大きな
経済性と障害箇所の迅速な特定、復旧時間の短縮が可能
となり、通信サービス品質向上と経済的な効果を得るこ
とができる。
【図１】図１は、本発明によるＩＰ通信のリアルタイム
バックアップ通信方法の実施の形態を示す回路ブロック
図である。
バックアップ通信方法の実施の形態を示す回路ブロック
図である。
【図２】図２は、Ｅｔｈｅｒｎｅｔのデータ構成図であ
る。
る。
【図３】図３は、ＲＳＶＰの制御方法を示すタイムチャ
ートである。
ートである。
【図４】図４は、優先制御の従来・本発明のフィールド
形成を示すデータ構成図である。
形成を示すデータ構成図である。
【図５】図５は、ＩＰデータグラムである。
【図６】図６は、ＩＣＰＭのメッセージ表である。
【図７】図７は、ＩＣＰＭのメッセージ形成を示すデー
タ形成図である。
タ形成図である。
【図８】図８は、図１の一部の動作信号を示す回路ブロ
ック図である。
ック図である。
【図９】図９は、ＵＤＰのメッセージ形成を示すデータ
形成図である。
形成図である。
【図１０】図１０は、応答の遅延を検出する信号フロー
のタイミングチャートである。
のタイミングチャートである。
【図１１】図１１は、公知装置を示す回路ブロック図で
ある。
ある。
１００…ＩＰ網 １１０…公衆網 １２０…送信側ノード １３０…受信側ノード
Claims (11)
- 【請求項１】送信側ノードと受信側ノードとの間を接続
するＩＰ網の上のリアルタイム通信中のリアルタイム通
信の障害の発生を検出すること、 前記検出に基づいて、前記リアルタイム通信の通信呼を
前記送信側ノードと前記受信側ノードとの間で自動的に
公衆網へ迂回させることとからなるＩＰ通信のリアルタ
イムバックアップ通信方法。 - 【請求項２】請求項１において、 前記発生は、前記リアルタイム通信の品質を確保できな
い程度の遅延時間の発生であるＩＰ通信のリアルタイム
バックアップ通信方法。 - 【請求項３】請求項２において、 前記周期的送受信にはＩＣＭＰが用いられるＩＰ通信の
リアルタイムバックアップ通信方法。 - 【請求項４】請求項２において、更に、 前記リアルタイム通信の途中に新たなリアルタイム通信
呼が発生した場合、前記新たなリアルタイム通信を前記
公衆網に迂回させることとからなるＩＰ通信のリアルタ
イムバックアップ通信方法。 - 【請求項５】請求項２において、更に、 前記迂回の間、前記送信側ノードと前記受信側ノードと
の間を接続する前記公衆網上のリアルタイム通信の障害
の発生を検出することからなるＩＰ通信のリアルタイム
バックアップ通信方法。 - 【請求項６】請求項５において、更に、 前記迂回の間の前記公衆網上の前記検出は、前記送信側
ノードと前記受信側ノードとの間のエコー要求メッセー
ジとエコー応答メッセージの周期的送受信の時間を検出
することを含むＩＰ通信のリアルタイムバックアップ通
信方法。 - 【請求項７】請求項６において、更に、 前記迂回の間の前記検出は、前記公衆網上に前記障害が
発生している間に前記エコー要求メッセージが正常に受
信された場合は、前記公衆網は正常であり前記ノードが
異常であると判断することを含むＩＰ通信のリアルタイ
ムバックアップ通信方法。 - 【請求項８】請求項２において、更に、 前記検出は、前記送信側ノードと前記受信側ノードとの
間のエコー要求メッセージとエコー応答メッセージの周
期的送受信の時間を検出することを含むＩＰ通信のリア
ルタイムバックアップ通信方法。 - 【請求項９】請求項８において、更に、 前記検出は、前記エコー応答メッセージが正常に返信さ
れた場合、前記ＩＰ網に障害がなく、且つ、前記ノード
に障害があると判断することを含むＩＰ通信のリアルタ
イムバックアップ通信方法。 - 【請求項１０】請求項２において、更に、 前記ＩＰ網上のリアルタイム通信の障害の回復を検出す
ること、 前記回復の検出に基づいて、前記リアルタイム通信の通
信呼を前記公衆網上から前記ＩＰ上へ復帰させることと
からなるＩＰ通信のリアルタイムバックアップ通信方
法。 - 【請求項１１】請求項１０において、 前記ＩＰ上の前記障害の回復を検出することと前記公衆
網上のリアルタイム通信の障害の発生を検出することと
から、前記ノードの障害と前記ＩＰ網の障害とを判別す
ることからなるＩＰ通信のリアルタイムバックアップ通
信方法。
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP22486899A JP2001053794A (ja) | 1999-08-09 | 1999-08-09 | Ｉｐ通信のリアルタイムバックアップ通信方法 |
| AU51845/00A AU765534B2 (en) | 1999-08-09 | 2000-08-07 | Method for carrying out real time backup communication of IP communication |
| US09/634,645 US6711614B1 (en) | 1999-08-09 | 2000-08-08 | Method for carrying out real time backup communication of IP communication |
| GB0019611A GB2356536B (en) | 1999-08-09 | 2000-08-09 | Method for carrying out real-time backup communication of IP communication |
| GB0202535A GB2369019B (en) | 1999-08-09 | 2000-08-09 | Method for carrying out real-time backup communication of IP communication |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP22486899A JP2001053794A (ja) | 1999-08-09 | 1999-08-09 | Ｉｐ通信のリアルタイムバックアップ通信方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2001053794A true JP2001053794A (ja) | 2001-02-23 |
Family
ID=16820437
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP22486899A Pending JP2001053794A (ja) | 1999-08-09 | 1999-08-09 | Ｉｐ通信のリアルタイムバックアップ通信方法 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US6711614B1 (ja) |
| JP (1) | JP2001053794A (ja) |
| AU (1) | AU765534B2 (ja) |
| GB (1) | GB2356536B (ja) |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2002071732A2 (en) * | 2001-03-02 | 2002-09-12 | Teltone Corporation | Selection of alternative voice connection paths |
| WO2003026210A1 (en) * | 2001-06-22 | 2003-03-27 | Caners Co., Ltd. | Back-up and load balancing method and apparatus based on dual lines |
| JP2005012711A (ja) * | 2003-06-20 | 2005-01-13 | Sony Corp | リアルタイムデータ通信システム、リアルタイムデータ通信装置およびリアルタイムデータ通信方法 |
| JP2009164758A (ja) * | 2007-12-28 | 2009-07-23 | Nec Infrontia Corp | 通信システムと通信端末、及びネットワーク切り替え方法 |
| US7633943B2 (en) | 2001-07-23 | 2009-12-15 | Acme Packet, Inc. | System and method for providing rapid rerouting of real-time multi-media flows |
| KR100987421B1 (ko) * | 2001-12-12 | 2010-10-13 | 소니 가부시키가이샤 | 데이터통신시스템, 데이터송신장치, 데이터수신장치, 데이터통신방법 및 컴퓨터가 판독가능한 기록 매체 |
| KR101563356B1 (ko) | 2014-11-26 | 2015-10-27 | 주식회사 케이티 | 행정 인터넷 전화망의 백업 절체 자동화 시스템 |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020141376A1 (en) * | 2000-09-18 | 2002-10-03 | Sharp Labs Of America | Devices, softwares, and methods for wireless devices to form a network on the fly by performing admission control in the second layer |
| US7068645B1 (en) * | 2001-04-02 | 2006-06-27 | Cisco Technology, Inc. | Providing different QOS to layer-3 datagrams when transported on tunnels |
| GB2378782B (en) * | 2001-08-16 | 2005-04-13 | Sun Microsystems Inc | Message brokering |
| JP3801559B2 (ja) | 2002-12-26 | 2006-07-26 | ソニー株式会社 | 通信装置および方法、記録媒体、並びにプログラム |
| US7843925B2 (en) * | 2004-01-20 | 2010-11-30 | Nortel Networks Limited | Ethernet differentiated services architecture |
| JP4989397B2 (ja) * | 2007-09-26 | 2012-08-01 | 京セラ株式会社 | 移動通信システム、基地局装置、およびハンドオーバ方法 |
| JP2021177598A (ja) * | 2020-05-08 | 2021-11-11 | シャープ株式会社 | 音声処理システム、音声処理方法、及び音声処理プログラム |
Family Cites Families (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4996685A (en) * | 1989-04-10 | 1991-02-26 | Bell Communications Research, Inc. | Technique for dynamically changing an ISDN connection during a host session |
| JP3614991B2 (ja) | 1995-08-31 | 2005-01-26 | 株式会社東芝 | 通信システム及び交換機 |
| CN1216657A (zh) * | 1996-04-24 | 1999-05-12 | 北方电讯有限公司 | 互联网协议过滤器 |
| JPH1065737A (ja) | 1996-08-23 | 1998-03-06 | Matsushita Electric Ind Co Ltd | 代理サーバ装置およびサーバ装置 |
| JPH10112739A (ja) | 1996-10-03 | 1998-04-28 | Nec Telecom Syst Ltd | モデム装置 |
| US5898668A (en) | 1996-12-13 | 1999-04-27 | Siemens Information And Communication Networks, Inc. | Method and system for increasing quality of service at or below a threshold cost |
| JP3708656B2 (ja) | 1997-02-04 | 2005-10-19 | 株式会社東芝 | 通信システム |
| US6049825A (en) * | 1997-03-19 | 2000-04-11 | Fujitsu Limited | Method and system for switching between duplicated network interface adapters for host computer communications |
| US6278994B1 (en) * | 1997-07-10 | 2001-08-21 | International Business Machines Corporation | Fully integrated architecture for user-defined search |
| DE19745961A1 (de) * | 1997-10-17 | 1999-04-22 | Cit Alcatel | Vorrichtung und Verfahren zum Aufbau einer Gesprächsverbindung |
| US6389005B1 (en) * | 1997-12-01 | 2002-05-14 | Nortel Networks Limited | Automatic backup trunking for voice over the internet |
| WO1999028979A2 (en) | 1997-12-02 | 1999-06-10 | Alcatel Usa Sourcing, L.P. | Digital phone system |
| JP3144546B2 (ja) * | 1998-04-21 | 2001-03-12 | 日本電気株式会社 | ネットワークと構内ネットワーク |
| US6510162B1 (en) * | 1998-05-27 | 2003-01-21 | 3Com Corporation | System and method for managing channel usage in a data over cable system |
| US6084874A (en) * | 1998-06-30 | 2000-07-04 | Storage Technology Corporation | Temporary data transfer connections |
| US6388988B1 (en) * | 1998-08-04 | 2002-05-14 | Electronic Data Systems Corporation | Method and system for automatic line protection switching of embedded channels |
| US6430610B1 (en) * | 1998-09-02 | 2002-08-06 | Steeleye Technology, Inc. | TCP/IP address protection mechanism in a clustered server environment |
| US6590869B1 (en) * | 1999-03-11 | 2003-07-08 | Siemens Information & Communication Networks, Inc. | Method and apparatus for selecting whether to place a call over the internet or the PSTN using a two tiered process |
| US6496477B1 (en) * | 1999-07-09 | 2002-12-17 | Texas Instruments Incorporated | Processes, articles, and packets for network path diversity in media over packet applications |
-
1999
- 1999-08-09 JP JP22486899A patent/JP2001053794A/ja active Pending
-
2000
- 2000-08-07 AU AU51845/00A patent/AU765534B2/en not_active Ceased
- 2000-08-08 US US09/634,645 patent/US6711614B1/en not_active Expired - Fee Related
- 2000-08-09 GB GB0019611A patent/GB2356536B/en not_active Expired - Fee Related
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2002071732A2 (en) * | 2001-03-02 | 2002-09-12 | Teltone Corporation | Selection of alternative voice connection paths |
| WO2002071732A3 (en) * | 2001-03-02 | 2003-04-24 | Teltone Corp | Selection of alternative voice connection paths |
| WO2003026210A1 (en) * | 2001-06-22 | 2003-03-27 | Caners Co., Ltd. | Back-up and load balancing method and apparatus based on dual lines |
| US7633943B2 (en) | 2001-07-23 | 2009-12-15 | Acme Packet, Inc. | System and method for providing rapid rerouting of real-time multi-media flows |
| KR100987421B1 (ko) * | 2001-12-12 | 2010-10-13 | 소니 가부시키가이샤 | 데이터통신시스템, 데이터송신장치, 데이터수신장치, 데이터통신방법 및 컴퓨터가 판독가능한 기록 매체 |
| JP2005012711A (ja) * | 2003-06-20 | 2005-01-13 | Sony Corp | リアルタイムデータ通信システム、リアルタイムデータ通信装置およびリアルタイムデータ通信方法 |
| JP2009164758A (ja) * | 2007-12-28 | 2009-07-23 | Nec Infrontia Corp | 通信システムと通信端末、及びネットワーク切り替え方法 |
| JP4569910B2 (ja) * | 2007-12-28 | 2010-10-27 | Ｎｅｃインフロンティア株式会社 | 通信システムとｐｏｓ端末、及びネットワーク切り替え方法 |
| KR101563356B1 (ko) | 2014-11-26 | 2015-10-27 | 주식회사 케이티 | 행정 인터넷 전화망의 백업 절체 자동화 시스템 |
Also Published As
| Publication number | Publication date |
|---|---|
| GB2356536A (en) | 2001-05-23 |
| GB0019611D0 (en) | 2000-09-27 |
| AU5184500A (en) | 2001-02-15 |
| AU765534B2 (en) | 2003-09-18 |
| GB2356536B (en) | 2002-07-24 |
| US6711614B1 (en) | 2004-03-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8774005B2 (en) | Congestion control method and devices | |
| US20070286351A1 (en) | Method and System for Adaptive Media Quality Monitoring | |
| US7606149B2 (en) | Method and system for alert throttling in media quality monitoring | |
| US9332037B2 (en) | Method and apparatus for redundant signaling links | |
| JP4167072B2 (ja) | リング・トポロジーに対する選択的保護 | |
| JP2001053794A (ja) | Ｉｐ通信のリアルタイムバックアップ通信方法 | |
| US7710861B2 (en) | Network system and method for link failure recovery | |
| US20060233107A1 (en) | Method and apparatus for monitoring surges in busy and no answer conditions in a communication network | |
| EP1825621B1 (en) | System and method for improving the quality of real time multimedia sessions | |
| US20060182131A1 (en) | Gateway interface control | |
| US20070223378A1 (en) | Internet traffic controller, internet-traffic controlling system, and internet-traffic controlling method | |
| US8737237B2 (en) | Network fault detection method and apparatus | |
| US9591108B2 (en) | Management of network impairment by communication endpoints | |
| US9344322B2 (en) | Method and apparatus for providing internet protocol call signaling network assurance | |
| JP2006094487A (ja) | ＦＴＴｘプラットフォーム上のＰＯＴＳエミュレーションサービスのための障害分離構成 | |
| US8107465B1 (en) | Slim bandwidth reservation protocol over an IP network | |
| Cisco | MGCP CAS PBX and PRI Backhaul on Cisco 7200 Routers | |
| US8363555B2 (en) | Monitoring internet protocol (IP) telephony signaling links | |
| Cisco | MGCP CAS PBX and AAL2 PVC | |
| GB2369019A (en) | Method for carrying out real-time backup communication of IP communication | |
| Cisco | MGCP VoIP Call Admission Control | |
| JP2002247067A (ja) | 帯域制御装置 | |
| US8670323B1 (en) | Method and apparatus for monitoring of access network status in communication networks | |
| CN103238293B (zh) | 用于监控通信系统的方法 | |
| JP2002335327A (ja) | 通信システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20030422 |