JP5349457B2

JP5349457B2 - ゲートウエイ装置において障害を検出する方法及び装置

Info

Publication number: JP5349457B2
Application number: JP2010506166A
Authority: JP
Inventors: ブローマン，キース，アール; ウェーバー，バリー，ジェイ; スミス，アーロン，エム
Original assignee: Thomson Licensing SAS
Current assignee: Thomson Licensing SAS
Priority date: 2007-04-23
Filing date: 2007-12-19
Publication date: 2013-11-20
Anticipated expiration: 2027-12-19
Also published as: RU2463718C2; JP2010527533A; WO2008133670A1; CN101652960A; KR101459170B1; EP2156608A1; KR20100015823A; RU2009142983A; US20100142381A1; BRPI0721534A2; MX2009011514A

Description

本願実施例は、一般に、集合住宅（MDU：Multi-Dwelling Unit）にサービスを提供するのに使用されるゲートウエイ装置に関連し、特に、そのようなゲートウエイ装置に関する不具合状態を検出及び軽減するための仕組みに関連する。

衛星テレビジョンサービスのようなサービスを提供するシステムが発展してきており、そのシステムは、集合住宅の建物やアパートメントのような1個所で複数ユーザが操作する必要性に応じる構造を使用する。MDU設置のような設置に使用されるシステム配置は、しばしば、ローカルネットワークを介してセントラル装置又はゲートウエイ装置に接続されたクライアント装置（複数）を含み、セントラル装置はサービスプロバイダのネットワークに接続される。ハードウエア又はソフトウエアに起因して、所与のゲートウエイ装置の中で不具合が生じ、システムパフォーマンス及びユーザからのサービスコールの劣化が生じるかもしれない。

所与のゲートウエイ装置においてソフトウエアモジュールの不具合を検出及び軽減する1つの方法は、監視モニタ（watchdog monitor）を使用することである。そのような監視モニタは、例えばスレッド毎に設定され、1つ以上の実行の脈絡（thread of execution）を監視し、スレッド不具合を示す（すなわち、ミクロレベルの不具合検出）。より複雑なソフトウエアモジュールは、多くの場合、複数の実行の脈絡に加えて、監視されない第三者のオブジェクトモジュールをも含み、伝送制御プロトコル/インターネットプロトコル（TCP/IP）スタックのサービスも使用する。これらのより複雑なモジュールの場合、スレッド毎の監視モニタ方法は、ソフトウエアモジュール全体の不具合や、ソフトウエアファンクションポイントの欠如を検出するのに充分でないかもしれない。

したがって、ゲートウエイ装置に関する不具合状態を検出及び軽減する改善された仕組みが望まれている。説明される本願実施例は、これら及び/又は他の問題に対処し、1つ以上のゲートウエイ装置に関わるハードウエア及びソフトウエアモジュール不具合を検出するマクロレベルの能力をもたらす。

本発明の一形態によれば、ゲートウエイ装置において障害を検出する方法が開示される。一実施例による方法は、ネットワークの動作に関連する、サービスの第1のアナウンスメントを受信するステップと、前記第1のアナウンスメントの分類を判定するステップと、
前記第1のアナウンスメントの前記分類に基づいて、タイミングインターバルを初期化するステップと、前記タイミングインターバルが満了する前に、前記第1のアナウンスメントの前記分類に属する次のアナウンスメントが受信されなかった場合、エラーメッセージを提供するステップとを有する方法である。

本発明の別の形態によれば、ゲートウエイ装置が開示される。一実施例によるゲートウエイ装置は、前記データネットワークの動作に関連する、サービスの第1のアナウンスメントを受信するネットワークインターフェースと、プロセッサとを有し、該プロセッサは、前記第1のアナウンスメントの分類を判定し、前記第1のアナウンスメントの前記分類に基づいて、タイミングインターバルを初期化し、前記タイミングインターバルが満了する前に、前記第1のアナウンスメントと同じ分類に属する次のアナウンスメントが受信されなかった場合、エラーメッセージを提供する。

本発明の別の形態によれば、別の装置が開示される。一実施例による装置は、ネットワークの動作に関連する、サービスの第1のネットワークアナウンスメントを受信する手段と、
前記第1のネットワークアナウンスメントのソース及び前記第1のネットワークアナウンスメントのタイプを判定し、タイミングインターバルを初期化し、前記タイミングインターバルが満了する前に、前記第1のネットワークアナウンスメントと同じ分類に属しかつ前記第1のネットワークアナウンスメントの前記ソースから次のアナウンスメントが受信されなかった場合、エラーメッセージを提供する手段とを有する装置である。

開示される実施例を使用するシステム例を示すブロック図。図1の1つのゲートウエイ装置における本願の関連部分を示すブロック図。図1の1つのゲートウエイ装置の一例を示すブロック図。開示される実施例で使用する方法例を示す一部のフローチャート。開示される実施例で使用する方法例を示す別の部分のフローチャート。開示される実施例で使用する方法例を示す別の部分のフローチャート。

本願実施例及びその実現方法に関する上記及び他の特徴や利点は、以下の説明によりさらに明確になり、本開示内容は、添付図面と共に以下の実施例の詳細な説明を参照することでさらに理解できるであろう。

本願の説明は開示される好適実施例を示しているが、そのような説明は、如何なる方法によっても実施例の範囲を限定するように解釈されるべきでない。

説明される実施例は、主に、集合住宅に見受けられる導入されたシステムを意図している。本実施例は、ヘッドエンド又はゲートウエイインターフェースを使用する如何なるネットワーク情報伝送システムに使用及び適用されてもよく、そのシステムは、データネットワークを介してクライアント装置、セットトップボックス又は受信回路にコンテンツを提供するものである。例えば、航空機やバスの乗客の娯楽用情報提供システムに関する当業者に既知の方法を利用して、開示される実施例が修正されてもよい。

図面の内特に図1を参照するに、開示される実施例を使用するシステム例100が示されている。図1に示されるように、シスレム例100は、1つ以上のシステムヘッドエンド（図示せず）、ゲートウエイ装置10、主配線盤（メイン分配フレーム）（MDF）20、インターネット30のようなネットワーク、ネットワーク処理センタ（NOC）40、中間配線盤（中間分配フレーム）（IDF）50及びクライアント装置（図示せず）を有する。本実施例では図1は、イーサーネットネットワーク又は他のタイプのネットワークを利用するMDUで使用される一般的なシステムを示し、ネットワークは、例えば、同軸ケーブル、ディジタル加入者回線（DSL）、送電線ネットワーク又は無線技術によるもの等である。

図1の場合、ゲートウエイ装置10の各々は、システムヘッドエンド（すなわち、サービスプロバイダ）に動作可能に結合されかつ通信を行い、そのヘッドエンドは、例えば、衛星システム、地上システム、ケーブルシステム、インターネットシステム及び/又は他のタイプのブロードキャストシステムのヘッドエンド等である。本実施例では、ゲートウエイ装置10の各々は、オーディオ及び/又はビデオコンテンツを含む信号をシステムヘッドエンドから受信し、受信信号の信号フォーマットを変換し、集合住宅各々におけるユーザのリクエスト（要求）に基づいて、MDF20及びIDF50を介するネットワークを通じて、インターネットプロトコル（IP）フォーマットのようなフォーマットにより、適切なデータストリームをクライアント装置（例えば、セットトップボックス、テレビジョン等）に送信する。当該技術分野で知られているように、MDF20及びIDF50は、スイッチング及びルーティングの装置として機能する。所与のMDU設置に含まれるゲートウエイ装置10、MDF20及びIDF50の数は、設計事項に基づいて異なってもよい。IDF50の各々は、例えば、MDUの所与の階（フロア）及び/又は他の決められた場所にあるサービスクライアント装置でもよい。システム100は特殊なネットワークフォーマットを利用するイーサーネット交換ネットワークであるとして例示及び説明されるが、当業者は、開示される原理が他のネットワークに適用されてもよいことを認めるであろう。そのネットワークは、例えば、同軸ケーブル、ディジタル加入者回線（DSL）、送電線網及び/又は無線技術によるものでもよく、多数の可能なネットワーク形式があり得る。

1つ以上のゲートウエイ装置10が、同じシステムサービスプロバイダのヘッドエンドに接続されてもよいことは、重要である。1つのゲートウエイ装置10のサイズ及び容量の設計上の制約に起因して、利用可能なコンテンツ全てをサービスプロバイダから受信及び分配するために、複数のゲートウエイ装置10が必要になるかもしれない。さらに、ゲートウエイ装置10は、MDF20に至るローカルネットワーク接続とは別に又はそれに関連して、互いの間で接続及び通信する機能を備えていてもよい。

図1に示されるように、MDF20は、インターネット30又は他の適切なネットワーク接続を介して、NOC40と動作可能に結合され通信を行う。一実施例の場合、MDF20は、ゲートウエイ装置10の処理状態に関する通知メッセージを受信し、そのような通知メッセージをNOC40に送信する。これらの通知メッセージの内の1つが、あるゲートウエイ装置10の処理に問題のあること（例えば、ハードウエア及び/又はソフトウエアモジュールの不具合等）を示している場合、その問題を特定及び解決する適切な処理が行われてもよい（例えば、オペレータの介在なしに、サービスコール、新たなソフトウエアのダウンロード、不具合のあるゲートウエイ装置を再起動すること等が行われてもよい。）。開示される原理によれば、ゲートウエイ装置10の各々は、自装置及び/又は他のゲートウエイ装置10の動作不具合を検出し、それに関する通知メッセージをMDF20及びインターネット30を介してNOC40に与える。このように、有利なことに、開示される実施例は、例えばMDUネットワークに使用されるゲートウエイ装置10における不具合状態を検出及び軽減することができる。

図2を参照するに、図1のゲートウエイ装置10の本願に関する一部分を示すブロック図が示されている。図2のゲートウエイ装置10は、I/Oブロック12、プロセッサ14及びメモリ16を含む。説明の簡明化のため、所定の制御信号、電源信号及び/又は他の要素のような、ゲートウエイ装置10に関する所定の通常の要素は、図2の中で示されていない。

I/Oブロック12は、ゲートウエイ装置10のI/O機能を実行する。一実施例によれば、I/Oブロック12は、オーディオ、ビデオ及び/又はデータ信号のような信号を、1つ以上のヘッドエンド信号ソース（例えば、衛星、地上、ケーブル、インターネット及び/又は他の信号ソース）から、アナログ及び/又はディジタルフォーマットで受信する。また、I/Oブロック12は、その1つ以上のヘッドエンド信号ソースへ信号を出力する。I/Oブロック12は、MDF12へ及びMDF12から信号を送信及び受信する。一実施例では、I/Oブロック12は、オーディオ及びビデオコンテンツを含むブロードキャスト信号を受信する信号インターフェースと、MDFを含むローカルネットワークにおいてデータ信号形式の信号を送信及び受信するネットワークインターフェースとを含む。データ信号は、ゲートウエイ装置10により処理されるオーディオ及びビデオコンテンツを表す信号と、ゲートウエイ装置10により生成されたネットワークアナウンスメントとを含む。

プロセッサ14は、ゲートウエイ装置10の様々な信号処理及び制御機能を実行する。一実施例では、プロセッサ14は、I/Oブロック12から受信したオーディオ、ビデオ及び/又はデータ信号を処理し、それらの信号を、クライアント装置への送信及びクライアント装置による処理に相応しいフォーマットにする。

プロセッサ14はソフトウエアコードを実行し、そのソフトウエアコードは、開示される原理にしたがって、1つ以上のゲートウエイ装置10（自装置を含む）の動作上の問題（例えば、ハードウエア及び/又はソフトウエアモジュール不具合等）を検出及び軽減することを可能にする。好適実施例の場合、プロセッサ14はソフトウエアコードを実行するマイクロプロセッサであり、そのソフトウエアコードは、アナウンスメントに関する情報を受信した後、アナウンスメントの分類を決定する。プロセッサ14は、そのアナウンスメントの分類に基づいて時間インターバルを初期化するコードを実行し、そのタイミングインターバルが経過する前に、既に受信しているアナウンスメントと同じ分類の次の（第２の）アナウンスメントに関する情報が受信されなかった場合、エラーメッセージを提供する。この形態のプロセッサ14に関するさらなる詳細については後述される。プロセッサ14は、ゲートウエイ装置10の他の機能を実行及び/又は実行可能にし、その機能は、ユーザ入力装置（図示せず）を介して得られたユーザ入力を処理すること、通知メッセージを含む出力を生成すること、メモリ16からデータを読み取ること、メモリ16へデータを書き込むこと及び/又は他の処理を含むが、これらに限定されない。

メモリ16は、プロセッサ14に結合され、ゲートウエイ装置10のデータストレージ機能を実行する。一実施例では、メモリ16は、ソフトウエアコード、1つ以上のデータテーブル、所定の通知メッセージ、ユーザ設定データ及び/又は他のデータ等を含むデータを格納するが、これらに限定されない。

ゲートウエイ装置10は、複数の衛星信号を含む様々なタイプのブロードキャスト信号を受信してもよい。ゲートウエイ装置10は、ブロードキャスト信号により提供されるオーディオ及びビデオコンテンツを含む複数のネットワークデータ信号を生成し、かつゲートウエイ装置10をクライアント装置に接続するネットワークを介して、ネットワークデータ信号を提供する。

図3を参照するに、衛星ゲートウエイ装置例300のブロック図が示されている。衛星ゲートウエイ装置300は、図1で説明したゲートウエイ装置10と同様なものである。図示されているように、衛星ゲートウエイ装置300は、パワーサプライ（電源供給部）340、2つのフロントエンド341a,341b及びバックエンド352を含む。パワーサプライ340は何らかの工業規格のAC又はDC電源であり、フロントエンド341a,b及びバックエンド352が、後述の機能を実行できるように構築されたものである。

衛星ゲートウエイ装置300は、2つのフロントエンド341a,bを含む。一実施例の場合、フロントエンド341a,bの各々は、1:2スプリッタ326a-326dから供給された2つの信号を受信する。例えば、フロントエンド341aは1:2スプリッタ326aから2つの信号を受信し、フロントエンド341bは1:2スプリッタ326bから2つの信号を受信する。

フロントエンド341a,bは、1:4スプリッタ342a、342b、342c及び342dを用いて信号をさらに細分する。細分された信号は、デュアルチューナーリンクの4つのバンク344a、344b、344c及び344dに伝送される。バンク344a−344d内のデュアルチューナーリンクの各々は、そのデュアルチューナーリンク各自が受信した信号中の2つのサービスに同調し、1つ以上のトランスポートストリームを生成する。デュアルチューナーリンク344a、344b、344c及び344dの各々は、低電圧作動シグナリングドライバ（LVDS: Low Voltage Differential Signaling）348a、348b、348c及び348dの何れかにトランスポートストリームを送信する。LVDSドライバ348a-348dは、トランスポート信号をバックエンド352へ送信するために増幅する。代替実施例では、LVDSドライバ348a-348dの代わりに、異なる形式の作動ドライバ及び/又は増幅器が使用されてもよい。他の実施例では、バックエンド352へのルーティング用に全てのトランスポート信号の直列化（serialization）を使用してもよい。

図示されているように、フロントエンド341a,bは、マイクロプロセッサ346a及び346bを含む。一実施例では、マイクロプロセッサ346a,bは、デュアルチューナーリンクのバンク344a−344d及び1:4スプリッタ342a-342dに対するコマンドを制御及び中継する。マイクロプロセッサ346a,bは、例えば、STマイクロエレクトロニクスにより製造されているST10マイクロプロセッサでもよい。他の実施例では、他のプロセッサが使用されてもよいし、或いは、バックエンド352内のプロセッサから制御が行われてもよい。マイクロプロセッサ346a,bは、LVDS受信機及び送信機モジュール350a及び350bに結合される。LVDS受信機/送信機モジュール350a,bは、後述するように、マイクロプロセッサ346a,bとバックエンド352における要素との間の通信を促す。

次に、バックエンド352に関し、バックエンド352はLVDS受信機354a、354b、354c及び354dを含み、これらはLVDSドライバ348a-348dから送信されたトランスポートストリームを受信する。バックエンド352は、LVDS受信機/送信機モジュール356a及び356bを含み、LVDS受信機/送信機モジュール350a,bと通信する。

図示されているように、LVDS受信機354a-354d及びLVDS受信機/送信機モジュール356a,bは、コントローラ又はトランスポートプロセッサ358a及び358bと通信を行う。一実施例では、トランスポートプロセッサ358a,bは、フロントエンド341a,bのデュアルチューナによって生成されたトランスポートストリームを受信する。トランスポートプロセッサ358a,bは、そのトランスポートストリームをインターネットプロトコル（IP）パケットにパケット化し直し、IPパケットは、上記のローカルネットワークを介してマルチキャストで伝送可能である。例えば、トランスポートプロセッサ358a,bは、ブロードキャストプロトコルパケットをIPプロトコルパケットにパケット化し直し、あるIPアドレスでそれらのIPパケットを、1つ以上のクラアイント装置宛にマルチキャストする。

トランスポートプロセッサ358a,bはバス362に結合され、バスは、例えば、32ビット66MHzのペリフェラルコンポーネントインターコネクト（PCI）バスである。バス362を介して、トランスポートプロセッサ358a,bは、他のコントローラ又はネットワークプロセッサ370、イーサーネットインターフェース384及び/又は拡張スロット366と通信を行う。ネットワークプロセッサ370は、ローカルネットワークからサービスのリクエストを受信し、トランスポートプロセッサ358a,bが、要求されたサービスをマルチキャストするように指示する。或いは、クライアント装置からリクエストを受信し、現在提供しているサービスのリストを保持し、それらのサービスをSTB22a-22nに提供するために受信リソースを照合する又は割り当てることで、ネットワークプロセッサ370は、オーディオ及びビデオコンテンツを含むデータ信号の処理及び配信を管理してもよい。ゲートウエイ装置10により提供されたネットワーク関連アナウンスメントを受信、監視及び/又は処理することで、ネットワークプロセッサは、ネットワーク状態を管理する。一実施例の場合、ネットワークプロセッサは、インテル社により製造されているIXP425であり、あるソフトウエアコードを実行し、そのソフトウエアコードは、ネットワークアナウンスメントに関する情報を受信した後に、ネットワークアナウンスメントの分類を判定する。プロセッサ14はあるコードを実行し、そのコードは、アナウンスメントの分類に基づいてタイミングインターバルを初期化し、そのタイミングインターバルが満了するまでに、既に受信しているアナウンスメントと同じ分類の次のアナウンスメントに関する情報が受信できなかった場合、エラーメッセージを提供する。図示してはいないが、ネットワークプロセッサ370は、衛星ゲートウエイ装置300のフロントパネルにステータスデータを送信し、或いは、デバッグポートを介して衛星ゲートウエイ装置300のデバッグ処理又は監視処理をサポートする。

図示されているように、トランスポートプロセッサ358a,bは、バス362を介して、イーサーネットインターフェース368にも結合されている。一実施例では、イーサーネットインターフェース368はギガビットイーサーネットインターフェースであり、銅線又は光ファイバのインターフェースをローカルネットワークにもたらす。他の実施例では、ディジタルホームネットワークアプリケーションに使用されているような他のインターフェースが、使用されてもよい。さらに、バス362は、PCI拡張スロットのような拡張スロットにも結合され、衛星ゲートウエイ装置300のアップグレード又は拡張を可能にする。

トランスポートプロセッサ358a,bは、ホストバス64にも結合される。一実施例では、ホストバス364は、トランスポートプロセッサ358a,bをモデム372に接続する16ビットデータバスであり、公衆サービス電話網（PSTN）28を介して通信を行うのに使用される。代替実施例では、モデム372がバス362に結合されてもよい。

ネットワークプロセッサ370はメモリを含み、衛星ゲートウエイ装置300の様々な処理に関する情報を格納する。メモリは、図示されていないが、ネットワークプロセッサ370の中にあってもよいし、或いは外部に設けられてもよい。タイマやネットワークアナウンスメントのようなステータス情報に加えて、受信リソースのチューニング情報等を格納するために、メモリは使用される。

トランスポートプロセッサ358a,b、ネットワークプロセッサ370及びマイクロプロセッサ346a,bは、より大きな1つのコントローラ又は処理ユニット内に含まれてもよく、そのコントローラ又は処理ユニットは、衛星ゲートウエイ装置300の処理に必要な制御機能の全部又は一部を実行可能なものである。制御機能の全部又は一部は他のブロック群に分散されてもよく、このことは衛星ゲートウエイ装置300内の主要な動作に影響しない。

図4ないし6を参照するに、開示される実施例で使用する方法例を表すフローチャートが示されている。例示及び説明の便宜上、図1のシステム及び図2のゲートウエイ装置10の構成要素を指す参照番号と共に、図4ないし6の方法が説明される。図4ないし6の方法は、図1の衛星ゲートウエイ装置20の構成要素についても同様に説明されてよい。例示及び説明の便宜上、図4ないし6のステップは、ただ1つのゲートウエイ装置10を参照しながら主に説明される。しかしながら実際は、所与のMDU設置におけるゲートウエイ装置10の各々は、図4ないし6のステップを別個独立に実行することが、予想される。図4ないし6のステップは、単なる例示に過ぎず、如何なる方法によっても本願実施例を限定するようには意図されていない。

ステップ410から本方法は始まる。一実施例では、1つ以上のゲートウエイ装置10に関する動作上の問題（例えば、ハードウエア及び/又はソフトウエアモジュール不具合等）を検出及び対処する特徴機能がイネーブルにされていた場合にのみ、ステップ410において本方法が始まる。説明の便宜上、この特徴機能は当初からイネーブルにされているものとする。

ステップ420において、ゲートウエイ装置10はテーブル及び全てのタイマをクリアする（消去する）。一実施例の場合、ゲートウエイ装置10の各々はメモリ16内にテーブルを格納し、そのテーブルは、1つ以上のゲートウエイ装置10（自装置を含む）に関する動作上の問題（例えば、ハードウエア及び/又はソフトウエアモジュール不具合等）を検出及び対処するのに使用される。一実施例の場合、ゲートウエイ装置10の各々は所定のプロトコルにしたがってアナウンスメントを周期的に送信及び再送信し、例えばそのプロトコルは、セッション記述プロトコル（SDP）を担うセッションアナウンスメントプロトコル（SAP）である。SAP及びSDP双方とも当該技術分野で既知である。様々なタイプ又は分類のアナウンスメントが存在し、ネットワークの有効性、有用性又は利用可能性（availability）、プロキシモデムホストの有効性等、クライアント装置ソフトウエアの有効性等、又は他のタイプのアプリケーション関連事項に関するアナウンスメントがある。ゲートウエイ装置10により受信された固有のSPAパケットSDPペイロードの各々について、メモリ16内の上記のテーブルは、以下の事項を保存する：（i）送信するゲートウエイ装置10のIPアドレス（すなわち、ゲートウエイ装置10の識別子）、（ii）SAPアナウンスメントのタイプ、分類又は種類、（iii）メディアタイトル（（ii）の項目に対応する）及び（iv）パケット到着時間。アナウンスメントのタイプ又は分類、及びゲートウエイ装置10の各々について、プロセッサ14は対応するタイマを有する。ステップ420において、プロセッサ14は、メモリ16の上記のテーブル及び対応する内部タイマの全てをクリアし、これらは動作上の問題を検出及び軽減するのに使用されるものである。これらの内部タイマは、プロセッサ14の不具合検出モジュールの一部である。

ステップ430において、ゲートウエイ装置10は全てのタイプのアナウンスメントを監視する。一実施例では、ステップ430において、ゲートウエイ装置10は、プロセッサ14の制御の下で、自装置自身により発行されたものだけでなく他のアクティブなゲートウエイ装置10の全部又は何れかにより発行されたSAPアナウンスメントをも監視する。ゲートウエイ装置10は、ステップ430におけるアナウンスメントの監視のために、プロセッサ14による制御の下で、例えば特定のIPアドレスを監視してもよい。

ステップ440において、アナウンスメントがゲートウエイ装置10により受信されたか否かについて判断される。一実施例では、プロセッサ14は、アナウンスメントが他のゲートウエイ装置10から受信されたこと又は自ら受信したことを検出し、ステップ440における判断を行う。ステップ440における判断が肯定的であれば、プロセスフローは「C」（図5）に進み、この場合については後述される。また、ステップ440における判断が否定的であった場合、プロセスフローはステップ450に進み、何らかのタイマが満了したか否かが判定される。一実施例によれば、プロセッサ14は自身の内部タイマ（すなわち、ステップ420でクリアされたもの）を検査し、ステップ450における判断を行う。図4に示されているように、プロセスフローは「D」（図5）からもステップ450に至り、図5については後述される。

プロセッサ14が内部タイマを使用する代わりに、時間間隔を測定又は監視する多数の方法が可能であることは、重要である。例えば、タイマは、水晶に接続された外部クロック回路、存在する連続的な時間信号をサンプリングするサンプリング回路、又はプロセッサ14上で動作するソフトウエアアルゴリズム等でもよい。

ステップ450の判断が肯定的であった場合、プロセスフローは「E」（図6）に進み、この場合については後述される。また、ステップ450における判断が否定的であった場合、プロセスフローはステップ460に進み、テーブルのリセットが要求されているか否かが判断される。一実施例では、ステップ420で言及されているメモリ16のテーブルは、ネットワーク管理者又は他の権限を有する者によってその都度手作業でリセットされてもよいし、及び/又はユーザの設定に基づいて自動的にリセットされてもよい。したがって、そのテーブルがリセットを要するか否かを確認することで、プロセッサ14はステップ460における判断を行う。

ステップ460における判断が肯定的であった場合、プロセスフローは「A」により示されているようにステップ420にループバックする。また、ステップ460における判断が否定的であった場合、プロセスフローはステップ470に進み、1つ以上のゲートウエイ装置10（自装置を含む）に関する動作上の問題（例えば、ハードウエア及び/又はソフトウエアモジュール不具合等）を検出及び軽減する特徴機能が、イネーブルにされているか否かを判断する。一実施例の場合、本開示によるこの特徴機能は、ネットワーク管理者又は他の権限のある者がマニュアルでターンオンにする（すなわち、イネーブルにする）及びターンオフにする（すなわち、ディセーブルにする）。したがって、この特徴機能がイネーブルにされているか否かを確認することで、プロセッサ14はステップ470の判断を行う。ステップ470における判断が肯定的であった場合、プロセスフローは「B」により示されているようにステップ430にループバックする。また、ステップ470における判断が否定的であった場合、プロセスフローはステップ480に進み、本方法は終了する。

図5を参照するに、「C」（すなわち、図4のステップで肯定的な判定結果であった場合）はステップ510に至り、ステップ440において特定のゲートウエイ装置10から受信したアナウンスメントが、新たなタイプ又は分類のアナウンスメントを表現しているか否かが判断される。一実施例の場合、メモリ内の上記のテーブルのエントリを検査することで、プロセッサ14はステップ510における判断を行う。上述したように、ネットワークの有効性、プロキシモデムホストの有効性、クライアント装置のソフトウエアの有効性、又は他のタイプのアプリケーション関連事項に関するアナウンスメントは、様々なタイプ又は分類のアナウンスメントを表現する。

ステップ510の判断が肯定的であった場合、プロセスフローはステップ520に進み、ゲートウエイ装置10は、新たなテーブルエントリを生成し、特定のゲートウエイ装置10及びアナウンスメントのタイプ又は分類に対応するタイマを初期化する。一実施例では、メモリ16内に新たなテーブルエントリを生成し、対応するタイマを内部で初期化することで、プロセッサ14はステップ520を実行する。プロセスフローはステップ520からステップ530に進み、ゲートウエイ装置10は、プロセッサ14の制御の下で、通知メッセージをNOC40に（MDF20及びインターネット30を介して）送信し、新たなテーブルエントリが作成されたこと、及び対応するタイマが初期化されていることを通知する。

ステップ510を再び参照するに、そこでの判断が否定的であった場合、プロセスフローはステップ550に進み、対応するタイマが満了したか否かが判断される。一実施例の場合、ステップ440で受信したアナウンスメントのタイプ又は分類及び特定のゲートウエイ装置10に対応する内部タイマが、満了したか否かを確認することで、プロセッサ14はステップ550における判断を行う。

ステップ550における判断が肯定的であった場合、プロセスフローはステップ530に進み、ゲートウエイ装置10は、プロセッサ14の制御の下で、エラー通知メッセージをNOC40（MDF20及びインターネット30を介して）送信し、アナウンスメントのタイプ又は分類及び特定のゲートウエイ装置10に対応する内部タイマが、満了したことを通知する。言い換えれば、ステップ550における判断が肯定的であった場合、ステップ530において送信されるエラー通知メッセージは、対応するタイマが満了するまでに、既に受信しているアナウンスメントと同じタイプ又は分類の第2の又は後続のアナウンスメントを、ゲートウエイ装置10が特定のゲートウエイ装置10から受信していないことを示す。したがって、エラー通知メッセージは、該当するゲートウエイ装置10に関し、動作上問題のある可能性があることをNOC40に通知し、適切な対策をとることを可能にする。

プロセスフローは、ステップ530からステップ540に進み、或いはステップ550の判断が否定的であった場合、プロセスフローはステップ540に進み、ゲートウエイ装置10は、対応するタイマを開始又はリセットする。一実施例によれば、対応するタイマをスタートさせる又はリセットすることで、プロセッサ14はステップ540を実行する。プロセスフローは、「D」により表現されているように、ステップ540からステップ450（図4）へループバックする。

図6を参照するに、「E」（図4のステップにおいて肯定的に判断された場合）はステップ610に至り、最後の（最新の）通知メッセージが、アナウンスメントのタイプ又は分類及び特定のゲートウエイ装置10について送信された最初の通知メッセージであるか否か、或いは、最後の通知メッセージが、アナウンスメントのタイプ又は分類及び特定のゲートウエイ装置10について送信されて以来、例えば10分間のような期間が経過したか否かが判断される。一実施例の場合、内部で維持されているタイミング情報を利用して、プロセッサ14はステップ610の判断を行う。

アナウンスメントのタイプ又は分類の各々について異なる期間を使用し、開示される実施例の動作をさらに改善できることは、重要である。例えば、ネットワークの有効性のアナウンスメントは、約2秒の反復期間（周期）を有するが、ネットワーク時間アナウンスメントは、約12時間の反復期間（周期）を有する。

ステップ610における判断が肯定的であった場合、プロセスフローはステップ620に進み、ゲートウエイ装置10は、プロセッサ14の制御の下で、通知メッセージをNOC40（MDF20及びインターネット30を介して）送信し、ステップ610において決定された状態を通知する。プロセスフローは、ステップ620からステップ630に進み、或いはステップ610の判断が否定的であった場合、プロセスフローはステップ630に進み、メモリ16内の満了したテーブルエントリの全てが処理されたか否かが判断される。一実施例の場合、内部で使用されるステータス情報を利用して、プロセッサ14はステップ630の判断を行う。

ステップ630における判断が肯定的であった場合、「B」により示されるように、プロセスフローはステップ430（図4）にループバックする。或いは、ステップ630における判断が否定的であった場合、プロセスフローはステップ640に進み、満了している次のテーブルエントリが処理される。プロセスフローはステップ640からステップ610にループバックする。

上述したように、図4ないし6のフローチャートは、ゲートウエイ装置10の不具合状態を検出及び軽減する仕組みをもたらす。要するに、アクティブなゲートウエイ装置10の各々は、自身のアナウンスメントを周期的に再送している。プロセッサ14の障害検出モジュール（不具合検出モジュール）は、一群のタイマを有し、ゲートウエイ装置10及び特定のアナウンスメントのタイプ/メディアタイトルの組み合わせ各々につき1つのタイマを有する（例えば、［GW1 id，アナウンスメントタイプ1］，［GW1 id，アナウンスメントタイプ2］．．．［GW3 id，アナウンスメントタイプ1］，［GW3 id，アナウンスメントタイプ2］．．．）。本実施例の原理によれば、新たなアナウンスメントのタイプ/メディアタイトルが特定のゲートウエイ装置10から受信された場合、その特定のゲートウエイ装置10及びアナウンスメントのタイプ/メディアタイトルに対応するエントリが、メモリ16のテーブル内に用意され、そのエントリに対するタイマが開始させられる。そのタイプ/メディアタイトルに関するさらなるアナウンスメントが、その特定のゲートウエイ装置10から受信されずに、タイマが満了した場合、その問題を通知/解決する処理が行われる（例えば、通知メッセージがNOC40に通知され、サービスコール、新たなソフトウエアのダウンロード、不具合のあるゲートウエイ装置の再起動等をオペレータの介在なしに行う。）。通知メッセージはサービス情報を含み、サービス情報は、不具合のあるゲートウエイ装置10のIPアドレスだけでなく、問題のあるサービスの情報をも含む。いったんタイマが満了すると、特定のゲートウエイ装置からアナウンスメントが再び受信されるまで、或いは不具合検出モジュールがリセットされるまで、或いはディセーブルとして管理されるまで、システム通知が周期的に再送されてもよい。

あるゲートウエイ装置10が別のゲートウエイ装置10のアナウンスメントを受信できない不具合は、送信側のゲートウエイ装置10のハードウエアの不具合（例えば、電源、ネットワークインターフェース等の不具合）や、提供するサービスに応答する1つ以上のソフトウエアモジュールの不具合等を含む。あるゲートウエイ装置10が自身のアナウンスメントを受信できない不具合は、提供するサービスに応答する1つ以上の自身のソフトウエアモジュールの不具合等を含む。3つ以上のゲートウエイ装置10を導入する例の場合、システム通知メッセージは冗長的になり、したがってそのような通知の信頼性を増進する。例えば、動作している2つのゲートウエイ装置10が、不具合のある第3のゲートウエイ装置10からの1つ以上のアナウンスメントの欠如を検出し、各々のゲートウエイ装置がその旨を示す通知メッセージをNOC40に送信する。

本実施例はゲートウエイ装置10の障害検出を主に取り扱っているが、障害（不具合）を軽減することに使用されてもよい。さらに、開示された実施例は、検出及び軽減する方法においてSAPアナウンスメントを利用している。SAPアナウンスメントは、（公知のインターネット規格RFC2974）SAPペイロードを含むユーザデータパケット（UDP）であり、SAPペイロードはSDP(RFC2327)を含み、周知のマルチキャストIPアドレスによりアクティブなゲートウエイ装置からそれぞれ送信される。SAPアナウンスメントのクラス各々は、提供しているサービスを通知し、機能に関する詳細や、そのサービスへのアクセス方法を提供する。例えば、現行のSAPアナウンスメントは、ネットワーク利用性、プロキシモデムホスト利用性、クライアント装置ソフトウエア利用性及びネットワーク時間を含む。

開示された実施例は、動作中にハードウエア又はソフトウエアの不具合について監視プロセスを要するシステム動作に関し、いくつもの恩恵をもたらす。これらの恩恵は、自ら監視する能力と、標準的なIPメッセージを利用することとを含むが、これらに限定されず、前者は、システムの状態に関するより多くの情報をネットワーク監視部に与え、後者は、SAPアナウンスメントのような標準的なIPメッセージを用いて、システム状態を通知し、ネットワーク上の誰かが活動状態（アクティビティステータス）を通知できかつネットワーク装置が機能しているか否かを通知できるようにするだけでなく、他の重要なメッセージや情報をも通知する。さらに、そのようなメッセージを利用すると、遠隔システムの監視者によるポーリングを可能にし、或いは、障害に関する情報を前もって送られるようにする。また、プロセッサ14により維持されるインターバルタイマについて様々なインターバル満了時間を、遠隔的に設定することもでき、アナウンスメントタイプが遠隔的に設定されてもよい。通知メッセージがいったん生成されると、メッセージは、オペレータ固有の複数のNOC宛に送信可能である。

上述したように、開示される実施例は、発展しつつある障害監視技術に関連し、複数のゲートウエイシステムのハードウエア及びソフトウエアが検出及び報告される。単独のゲートウエイシステムの場合、本方法は、主要なソフトウエアモジュールの障害検出をサポートする。開示される実施例は、とりわけ、複数のゲートウエイ装置を導入した際の様々なクラス（段階）の問題に対処し、冗長的な電源を備えていないゲートウエイ装置10が自身の電源不具合を検出できない問題や、通信インターフェースハードウエアが故障していた場合にゲートウエイ装置10が自身の不具合を報告できない問題等にも対処できる。さらに、開示される実施例は、単独の又は複数のゲートウエイ導入におけるクラスの問題に対処することができ、複数のスレッド、第三者オブジェクトコード等が使用される場合、単独の監視モニタベースの方法を使用して、壊滅的なソフトウエアモジュール障害を検出することができる。最初の実現手段が、ゲートウエイ装置10同士の間で又はローカルネットワークにおいてSAPアナウンスメントをブロードキャストするだけであったとしても、他のタイプのネットワークアナウンスメントさえも利用し、その実現手段を拡張して発展させ、それらのアナウンスメントをNOC40に送信することができる。

本願は好ましい設計内容を有するように説明されてきたが、本実施例は、開示の精神及び範囲の中でさらに修正することが可能である。したがって本願は、開示内容について一般原理を使用して如何なる変形、利用又は適用をも網羅するように意図されている。さらに、開示の記載から逸脱するものがあったとしてもそれは実施例が関連する技術分野における周知慣用技術に由来するのであることが意図されており、それらは添付の特許請求の範囲内に含まれる。

（関連出願）
本願は35U.S.C§119により西暦2007年4月23日で出願された仮特許出願番号60/925,792号に基づく恩恵を有する。

Claims

ゲートウエイ装置において障害を検出する方法であって、
ネットワークの動作に関連するサービスについての第1のアナウンスメントを他のゲートウエイ装置から受信するステップと、
前記第1のアナウンスメントの分類を判定するステップと、
前記第1のアナウンスメントの前記分類に基づいて、タイミングインターバルを初期化するステップと、
前記タイミングインターバルが満了する前に、前記第1のアナウンスメントの前記分類に属する次のアナウンスメントが受信されなかった場合、エラーメッセージを提供するステップと
を有する方法。
前記第1のアナウンスメントが、ネットワークの有効性のアナウンスメント、プロキシモデムホストの有効性のアナウンスメント、及びクライアント装置のソフトウエアの有効性のアナウンスメントの内の少なくとも1つを含む、請求項1記載の方法。
前記第1のアナウンスメントが、セッションアナウンスメントプロトコルにしたがう、請求項1記載の方法。
前記タイミングインターバルが満了する前に、前記第1のアナウンスメントと同じ分類に属する次のアナウンスメントが受信された場合、前記ゲートウエイ装置は適切に動作していると判断される、請求項1記載の方法。
前記分類は、前記第1のアナウンスメントのソース装置の識別子を含む、請求項1記載の方法。
決定された分類と、決定された分類に関連付けられたタイミングインターバルとを含む情報を格納するステップをさらに有する、請求項1記載の方法。
データネットワークに接続されたネットワークインターフェースと、前記ネットワークインターフェースに接続されたプロセッサとを有するゲートウエイ装置をなす装置であって、
前記ネットワークインターフェースは、前記データネットワークの動作に関連するサービスについての第1のアナウンスメントを他のゲートウエイ装置から受信し、
前記プロセッサは、前記第1のアナウンスメントの分類を判定し、前記第1のアナウンスメントの前記分類に基づいて、タイミングインターバルを初期化し、前記タイミングインターバルが満了する前に、前記第1のアナウンスメントと同じ分類に属する次のアナウンスメントが受信されなかった場合、エラーメッセージを提供する、装置。
前記第1のアナウンスメントが、ネットワークの有効性のアナウンスメント、プロキシモデムホストの有効性のアナウンスメント、及びクライアント装置のソフトウエアの有効性のアナウンスメントの内の少なくとも1つを含む、請求項7記載の装置。
前記第1のアナウンスメントが、セッションアナウンスメントプロトコルにしたがう、請求項7記載の装置。
前記タイミングインターバルが満了する前に、前記第1のアナウンスメントと同じ分類に属する次のアナウンスメントが受信された場合、前記ゲートウエイ装置は適切に動作していると判断される、請求項7記載の装置。
前記分類は、前記第1のアナウンスメントのソース装置の識別子を含む、請求項7記載の装置。
前記プロセッサに接続された信号インターフェースをさらに有し、該信号インターフェースは、ブロードキャストネットワークを介して提供されるオーディオ及びビデオコンテンツを受信する、請求項7記載の装置。
当該装置は、前記データネットワークに接続された複数のゲートウエイ装置の内の1つである、請求項7記載の装置。
前記分類と、前記分類に関連付けられたタイミングインターバルとを含む情報を格納するメモリをさらに有する、請求項7記載の装置。
ゲートウエイ装置をなす装置であって、
ネットワークの動作に関連するサービスについての第1のネットワークアナウンスメントを他のゲートウエイ装置から受信する手段と、
前記第1のネットワークアナウンスメントのソース及び前記第1のネットワークアナウンスメントのタイプを判定し、タイミングインターバルを初期化し、前記タイミングインターバルが満了する前に、前記第1のネットワークアナウンスメントと同じ分類に属しかつ前記第1のネットワークアナウンスメントの前記ソースから次のアナウンスメントが受信されなかった場合、エラーメッセージを提供する手段と
を有する装置。
前記第1のアナウンスメントが、ネットワークの有効性のアナウンスメント、プロキシモデムホストの有効性のアナウンスメント、及びクライアント装置のソフトウエアの有効性のアナウンスメントの内の少なくとも1つを含む、請求項15記載の装置。
前記第1のアナウンスメントが、セッションアナウンスメントプロトコルにしたがう、請求項15記載の装置。
オーディオ及びビデオコンテンツを含む複数の信号を、ブロードキャストネットワークを介して受信する手段と、
前記オーディオ及びビデオコンテンツを前記ネットワークを利用して送信する手段と
を有する請求項15記載の装置