JP5185187B2 - 中継装置、中継方法、中継プログラム及び、該プログラムを記録したコンピュータ読み取り可能な記録媒体 - Google Patents

Description

本発明は、端末間、または端末と通信ネットワークとの間でパケットデータを中継するパケット中継装置の再起動タイミングを制御する技術に関するものである。

近年、ＩＰ（Internet Protocol：インターネットプロトコル）技術を利用する次世代電話網として、電話・データ通信・ストリーミング放送の融合したマルチメディアサービスを実現するＮＧＮ（Next Generation Network：次世代ネットワーク）が構築されてきている。例えば、ＮＧＮを構築して、ＰＣ、電話、ＴＶなど情報家電の通信インフラを１つにまとめることが考えられている。この際、情報家電間および情報家電とＮＧＮとを接続するために、ホームゲートウェイ（ＨＧＷ：Home Gateway）が用いられる。つまり、ＨＧＷは、家庭内のＬＡＮ（Local Area Network）または無線ＬＡＮ（ＷＬＡＮ：Wireless LAN）とＮＧＮなどのＷＡＮ（Wide Area Network）とを相互接続するものである。

ＨＧＷは、情報家電とインターネット等のネットワークとをプロトコル中継、アドレス変換、ＩＰパケットの転送を行うことによって相互接続する。そのため、ＮＧＮにおいて新しいサービスを追加するために通信規格を追加・変更する場合、ＨＧＷのファームウェアを更新するだけで新しいサービスをユーザに提供することができる。

一般に、ファームウェアの更新を有効なものにするためにＨＧＷをリセット（再起動）しなければならない。ＨＧＷのファームウェアの更新は、通常、インターネットなどを介して自動的に行われており、ファームウェアが更新されるとその都度自動的にＨＧＷが再起動される。

しかしながら、ＨＧＷはいつでも再起動してもいいものではない。すなわち、電話通信（通話）中にＨＧＷのリセットが行われると通話が遮断されてしまうので、ＨＧＷは、通話中はリセットしないように制御しなければならない。

以上のように、ＨＧＷのような中継装置では、ファームウェアの更新のために自動的に再起動を行うことが求められている。その一方で、再起動によって、通信サービスを中断させないことが求められている。例えば、下記の特許文献１から３には、再起動による通信サービスの中断を防ぐ技術が開示されている。

具体的には、特許文献１には、中継装置が、特定の通信装置からの契機信号を受信したときに、自装置の再起動を行うことによって、自装置が確実に通信を行っていない状態で再起動を行う技術が開示されている。

また、特許文献２には、ＶｏＩＰ（Voice over IP）回線で通話を行っているときに再起動を要する操作が行われた場合に、利用者に再起動の許可を求め、許可が無いときは通話終了時に再起動を行うことによって、再起動による通話の中断を防ぐ技術が開示されている。

さらに、特許文献３には、通信中のデータが存在しないことが確認されたときに再起動を実行することによって、通信中のデータが再起動によって破壊されることを防ぐ技術が開示されている。

ここで、通話以外のデータ通信の場合には、データ通信が途切れたとしても、再起動後にデータの再送信を行うことでリカバリーできる可能性があるので、再起動による通信の中断は許容できる。つまり、通話以外のデータ通信が行われている場合には、ファームウェアの更新等によるＨＧＷの再起動を優先してもよい。しかし、通話のデータ通信が中断することは問題であるから、通話中にはＨＧＷを再起動させないことが好ましい。

このように、通話以外のデータ通信よりも再起動を優先させるが、通話のデータ通信は再起動によって中断させないようにするためには、現在行われているデータ通信が、通話によるものであるか否かを判定する必要がある。

例えば、特許文献２のように、通話専用の回線を備えている装置であれば、その回線を使用しているか否かによって、現在行われているデータ通信が、通話によるものであるか否かを判定することができる。

また、従来の一般的なＮＧＮ用のＨＧＷでは、ＮＧＮの通信規格がＳＩＰ（Session Initiation Protocol）で標準化されていることから、現在行われているデータ通信が、通話によるものであるか否かを判定することができる。これにより、通話中にのみ再起動を行わないように制御することもできる。これについて、図９〜１２に基づいて説明する。

図９は、従来のＮＧＮ用のＨＧＷ２００と、ＮＧＮ５１、Ｉｎｔｅｒｎｅｔ（インターネット）５２、ＮＧＮ端末４１、４２、およびＰＣ４４との接続関係を示す図である。図示のように、ＨＧＷ２００は、ＬＡＮ３１、ＷＬＡＮ３２、およびＷＡＮ３３と接続している。

そして、ＨＧＷ２００は、ＬＡＮ３１を介してＮＧＮ端末４１と接続され、ＷＬＡＮ３２を介してＮＧＮ端末４２およびＰＣ４４と接続されている。さらに、ＨＧＷは、ＷＡＮ３３を介してＮＧＮ５１およびインターネット５２と接続されている。このような接続関係の下、ＨＧＷ２００は、ＮＧＮ端末４１、ＮＧＮ端末４２、およびＰＣ４４と、ＮＧＮ５１またはインターネット５２との通信を中継している。

図１０は、従来のＨＧＷ２００の要部構成を示すブロック図である。図示のように、ＨＧＷ２００は、制御部１０１、記憶部１０２、ＬＡＮインターフェース１１、ＷＬＡＮインターフェース１２、およびＷＡＮインターフェース１３を含む。そして、制御部１０１は、パケット転送部１０３、電話部４、およびリセット制御部１０６を含む。また、記憶部１０２は、電話呼フラグ記憶部７を含む。

パケット転送部１０３は、ＨＧＷ２００の主要機能であるアドレス変換機能、およびファイアウォール機能などを有している。すなわち、パケット転送部１０３は、ＬＡＮ３１、ＷＬＡＮ３２、またはＷＡＮ３３（以下、ＨＧＷ２００が接続しているＬＡＮ３１、ＷＬＡＮ３２およびＷＡＮ３３のネットワークを総称して接続ネットワークとも称する）を介してパケットデータを受信し、受信したパケットデータが電話呼である場合には、電話部４に当該パケットデータの処理を行わせる。また、受信したパケットデータが電話呼ではない場合には、ウィルスなどの危険なデータでないか確認し、正常なデータであれば、必要に応じてアドレス変換して所定の転送先に送信する。なお、電話呼であるか否かは、電話部４が利用しているポート番号を見て判断することができる。

電話部４は、電話呼に関する制御を行う。具体的には、電話部４は、パケット転送部１０３が電話呼の受信を確認したときに、通話を開始するための処理を行う。また、通話の開始後は、受信した通話のパケットを通話の相手端末に転送する処理を行う。そして、通話を終了するときには、通話を終了するための処理を行う。

また、電話部４は、電話呼の受信を確認したときに、電話呼フラグを電話呼フラグ記憶部７に立てる（電話呼フラグをＯＮにする）。さらに、電話部４は、電話呼の受信の終了を確認したときに、電話呼フラグ記憶部７の電話呼フラグを下げる（電話呼フラグをＯＦＦにする）。なお、電話部４は、ＳＩＰメッセージを転送する、いわゆるＢ２ＢＵＡ（Back to Back User Agent）の機能も有する。

リセット制御部１０６は、ＨＧＷ２００のファームウェアの更新などにより、ＨＧＷ２００の再起動の要求があったときに、電話呼フラグ記憶部７に記憶されている電話呼フラグの有無（ＯＮ／ＯＦＦ）を参照して、ＨＧＷ２００の再起動を実行するか否かを制御する。

次に、ＨＧＷ２００において、ＳＩＰによる通話開始時、および通話終了時に行われる処理の詳細について図１１を用いて説明する。図１１は、ＳＩＰによる通話開始時時・通話終了時の典型的なシーケンスを示す図であり、同図（ａ）は通話開始時のシーケンスを示し、同図（ｂ）は通話終了時のシーケンスを示す図である。ここでは、発呼側と着呼側とのＳＩＰメッセージの転送を行うサーバとしてプロキシ・サーバ(Proxy Server；SIP Proxy)がある場合を考える。

同図（ａ）に示すように、通話開始時には、発呼側は、プロキシ・サーバを介してＳＩＰ ＩＮＶＩＴＥを着呼側に送信し、着呼側は、ＳＩＰ ＩＮＶＩＴＥを受信して、当該ＳＩＰ ＩＮＶＩＴＥに対する２００ＯＫを、プロキシ・サーバを介して発呼側に送信する。そして、発呼側がＳＩＰ ＩＮＶＩＴＥに対する２００ＯＫを受信すると、通話が開始される。

一方、通話終了時には、同図（ｂ）に示すように、電話の接続を切る側は、切られる側に対してプロキシ・サーバを介してＳＩＰ ＢＹＥを送信する。そして、電話の接続を切られる側は、ＳＩＰ ＢＹＥに対する２００ＯＫを、プロキシ・サーバを介して切る側に送信する。そして、切る側がＳＩＰ ＢＹＥに対する２００ＯＫを受信すると、通話が終了となる。

このように、ＳＩＰでは、電話呼の受信時に、電話呼の受信を示すＳＩＰメッセージであるＳＩＰ ＩＮＶＩＴＥが送受信される。また、通話終了時には、通話の終了を示すＳＩＰメッセージであるＳＩＰ ＢＹＥが送受信される。このため、電話部４は、ＳＩＰメッセージを参照することによって、通話中であるか否かを判断することができる。

次に、図１２を用いて、リセット制御部１０６の動作を説明する。図１２は、リセット制御部１０６が行う再起動制御のシーケンスを示す図である。上述のように、電話部４は、正常な電話呼を発呼または着呼したとき、より詳細にはＳＩＰ ＩＮＶＩＴＥまたはＳＩＰ ＩＮＶＩＴＥに対する２００ＯＫの受信を確認したときには、電話呼フラグ記憶部７に電話呼フラグを立てる。電話呼フラグが立てられた後は、リセット制御部１０６は、ＨＧＷのリセットの要求があったとしても、リセットを行わないように制御する。

そして、電話部４は、通話を終了したとき、より詳細にはＳＩＰ ＢＹＥまたはＳＩＰ ＢＹＥに対する２００ＯＫの受信を確認したときには、電話部４は、電話呼フラグ記憶部７の電話呼フラグを下げる。リセット制御部１０６は、電話呼フラグが下げられた状態において、ＨＧＷ２００のリセットの要求があったときには、リセットが行われるように制御する。

このように、ＨＧＷ２００では、リセット制御部１０６が、電話部４が電話呼を送受信していることを示す電話呼フラグに応じてリセットの可否を制御する。これにより、ＨＧＷ２００では、電話中に再起動が行われることを防ぐことができる。

ここで、携帯電話等の通信端末においても、通信のオールＩＰ化が進められており、３ＧＰＰ（Third Generation Partnership Project）などによって標準規格の策定が行われている。その中で、次世代（Ｓ３Ｇ（Super3G）、３．９Ｇ）の携帯電話では、ＷＬＡＮやＬＴＥ（Long Term Evolution）などの無線通信機能を備えることも可能となっている。

例えば、ＷＬＡＮを用いて３Ｇ網にアクセスするための技術として、３ＧＰＰにより標準化されたＩ−ＷＬＡＮ(Interworking WLAN)技術がある。また、ＬＴＥを用いて３Ｇ網にアクセスするための技術として、３ＧＰＰによりＳＡＥ(System Architecture Evolution)の仕様の策定が進められている。

ここで、上記のような無線通信機能を有する通信端末が３Ｇ網にアクセスする方法を図１３に基づいて説明する。図１３は、Ｉ−ＷＬＡＮの無線通信機能を有する３Ｇ端末（ＵＥ）４３と、３Ｇ網（３ＧＮｅｔｗｏｒｋ）５６との接続関係を示す図である。３Ｇ端末４３は、Ｎｏｎ３Ｇアクセスにて、３Ｇ網５６に接続するようになっている。

なお、Ｎｏｎ３Ｇアクセスとは、携帯電話における通常の通信経路（携帯電話の中継基地）を介さずに３Ｇ網５６にアクセスすることをいう。例えば、上記のＩ−ＷＬＡＮやＳＡＥなどでは、Ｎｏｎ３Ｇアクセスが行われる。

図示のように、３Ｇ端末４３は、ＷＬＡＮ ＡＰ（Access Point）３４を介してインターネット５２に接続する。これは、ＩＰによるアクセスである。Ｉ−ＷＬＡＮでは、３Ｇ端末４３と、３Ｇ網の末端であるｅＰＤＧ（evolved Packet Data Gateway）５３との間にＩＰｓｅｃトンネルを張ることによって、ＩＰネットワークから３Ｇネットワークへのアクセスを実現する。

このように、Ｉ−ＷＬＡＮなどの技術を用いることにより、３Ｇ端末は、ＷＬＡＮ ＡＰを介して３Ｇ網にアクセスすることができる。この場合には、３Ｇ端末は、通話のデータについてもＩＰｓｅｃパケットとして、ＷＬＡＮ ＡＰを介して３Ｇ網と送受信することができる。

なお、一般的には、ＷＬＡＮ ＡＰ３４は、ファームウェアの自動更新を行わない。そのため、ＷＬＡＮ ＡＰ３４が自動的にリセットされることもない。例えば、家庭内にあるＷＬＡＮ ＡＰ３４の場合、リセットは、通常手動で行われる。また、商用的なＷＬＡＮ ＡＰ３４（例えばホットスポットなど）の場合、計画的に再起動が行われる。

このように、従来は、ＷＬＡＮ ＡＰ３４のリセットは、自動化されていなかったため、ＷＬＡＮ ＡＰ３４を介して通話しているときにリセットが行われて通話が中断するという問題は生じていなかった。そのため、通話中にＷＬＡＮ ＡＰ３４の再起動を抑制する技術は、考えられていなかった。

しかしながら、近年では、ＮＧＮのネットワークの中に３Ｇ端末を取り込み、ＮＧＮ用のＨＧＷを３Ｇ端末のＷＬＡＮ ＡＰとして使用されるようになった。ＮＧＮ用のＨＧＷを３Ｇ端末のＷＬＡＮ ＡＰとして用いる場合、ＨＧＷは、３Ｇ端末の電話呼を電話呼として管理せず、電話呼以外の通信データとして処理する。

このため、従来のＨＧＷでは、３Ｇ端末の電話呼の送受信中に、ファームウェアの更新などがあった場合にも、自動的にリセットが行われる。つまり、従来のＮＧＮ用のＨＧＷを３Ｇ端末のＷＬＡＮ ＡＰとして用いる場合、３Ｇ端末の電話呼を電話呼として管理できないため、３Ｇ端末の通話を中断するようなリセットが行われる虞がある。

特開２００８−２７１３８１号公報（２００８年１１月６日公開） 特開２００４−１０４３５１号公報（２００４年４月２日公開） 特開２００６−６０５０９号公報（２００６年３月２日公開）

ここで、通話のデータをＩＰｓｅｃパケットで送受信する場合には、ＩＰｓｅｃパケットは、暗号化されておりＳＩＰであるかの判定はできないため、通話のデータと通話以外のデータとを識別することができない。

つまり、通話のデータをＩＰｓｅｃパケットで送受信することが可能となることによって、通話中に再起動を行わないように制御することができないという問題が生じる。

なお、上記特許文献３では、通話のデータか否かにかかわらず、通信中のデータがある場合には再起動を制御している。このため、通話以外のデータ通信中において再起動を優先させることができず、必要な再起動が行われない虞がある。

本発明は、上記の問題点に鑑みてなされたものであり、その目的は、通話のデータがＩＰｓｅｃパケットで送受信される状況下において、通話中に再起動を行わないように制御する中継装置等を実現することにある。

本発明に係る中継装置は、上記課題を解決するために、通信パケットの中継を行うと共に、所定のタイミングで再起動を行う中継装置であって、上記通信パケットの中継を行うパケット中継手段と、上記パケット中継手段が中継する上記通信パケットが、ＩＰｓｅｃプロトコルによって暗号化された通信パケットであるＩＰｓｅｃパケットであるか否かを判定するＩＰｓｅｃパケット判定手段と、上記ＩＰｓｅｃパケット判定手段が、上記パケット中継手段が中継する通信パケットがＩＰｓｅｃパケットであると判定したときに、再起動を行わないようにする再起動制御手段とを備えていることを特徴としている。

また、本発明に係る中継方法は、通信パケットの中継を行うと共に、所定のタイミングで再起動を行う中継装置の中継方法であって、上記通信パケットの中継を行うパケット中継ステップと、上記パケット中継ステップにおいて中継される上記通信パケットが、ＩＰｓｅｃプロトコルによって暗号化された通信パケットであるＩＰｓｅｃパケットであるか否かを判定するＩＰｓｅｃパケット判定ステップと、上記ＩＰｓｅｃパケット判定ステップにおいて、上記パケット中継ステップにおいて中継される通信パケットがＩＰｓｅｃパケットであると判定したときに、再起動を行わないように制御する再起動制御ステップとを含むことを特徴としている。

上記の構成によれば、中継する通信パケットに対してＩＰｓｅｃパケットであるか否かを判定して、中継する通信パケットがＩＰｓｅｃであると判定した場合に、再起動を行わないように制御を行う。

すなわち、上記の構成によれば、ＩＰｓｅｃパケットを中継するときには、中継装置の再起動が行われない。このように、通話のデータの送信に用いられるＩＰｓｅｃパケット中継時に再起動させないことにより、再起動による通話の中断を防ぐことができる。

なお、ＩＰｓｅｃパケットには、通話に使用されているもの（例えばＶｏＩＰのＩＰｓｅｃパケット）と、それ以外のもの（例えばＨＴＴＰのＩＰｓｅｃパケット）とが含まれる。しかしながら、どのようなデータの通信中であっても再起動を行わないようにする特許文献３の技術と比べて、通話に使用されることの多いＩＰｓｅｃパケットの中継時に限って再起動を制御する上記の構成の方が、通話以外のデータ通信中において再起動を優先させることができる点で有利である。

また、上記パケット中継手段が中継する通信パケットは、ＩＰｖ４のＵＤＰパケットであって、上記ＩＰｓｅｃパケット判定手段は、上記パケット中継手段が中継するＩＰｖ４のＵＤＰパケットの送信先及び送信元のポート番号と、ＩＰｓｅｃパケットの中継の際に用いられるポート番号とが一致する場合に、当該通信パケットがＩＰｓｅｃパケットであると判定することが好ましい。

ここで、中継装置において中継される通信パケットには、そのあて先及び送信元のポート番号が付されているが、上記ＩＰｖ４のＵＤＰパケットがＩＰｓｅｃパケットであるときには、特定のポート番号が使用される。

そこで、上記の構成によれば、上記パケット中継手段が中継する通信パケットがＩＰｖ４のＵＤＰパケットの場合、上記ＩＰｖ４のＵＤＰパケットの送信先及び送信元のポート番号と、ＩＰｓｅｃパケットの送受信の際に用いられる特定のポート番号とが一致していることを確認することによって、当該通信パケットがＩＰｓｅｃパケットであるか否か判定している。

例えば、ＩＰｖ４の場合には、ＩＰｓｅｃパケットの送受信時には、当該通信パケットの送信先がＷＡＮである場合を除いて、送信先及び送信元のポート番号として５００番が使用される。このため、上記ＩＰｓｅｃパケット判定手段は、中継する通信パケットの送信先及び送信元のポート番号が５００番であることを確認した場合に、当該パケットをＩＰｓｅｃパケットであると判定してもよい。

なお、ＩＰｖ４を利用しＨＧＷでＮＡＴ（Network address translation）を行う場合において、ＩＰｓｅｃパケットをＷＡＮに送信する場合には、送信元のポート番号として５００番以外が使用され、送信先のポート番号として５００が使用される。このため、上記ＩＰｓｅｃパケット判定手段は、ＩＰｓｅｃパケットをＷＡＮに送信する場合には、中継する通信パケットの送信先のポート番号が５００番であり、送信元のポート番号が５００番でないことを確認したときに、当該パケットをＩＰｓｅｃパケットであると判定してもよい。

また、上記パケット中継手段が中継する通信パケットは、ＩＰｖ４のＵＤＰパケットであって、上記ＩＰｓｅｃパケット判定手段は、上記パケット中継手段が中継する通信パケットのＵＤＰチェックサムフィールドの値がゼロである場合に、当該通信パケットがＩＰｓｅｃパケットであると判定することが好ましい。

ここで、中継装置において中継されるＵＤＰパケットには、データの検査のためにチェックサムフィールドが設けられていることがある。そして、ＩＰｖ４のＩＰｓｅｃパケットの中には、チェックサムフィールドに特定の値が格納されているものもある。

そこで、上記の構成によれば、上記パケット中継手段が中継する通信パケットがＩＰｖ４のＵＤＰパケットの場合、当該通信パケットのＵＤＰチェックサムフィールドの値を確認することによって、当該通信パケットがＩＰｓｅｃパケットであるか否か判定している。

例えば、ＩＥＴＦ（Internet Engineering Task Force）では、ＩＰｖ４において、ＵＤＰパケットがＵＤＰ Encapsulationされた通信パケット、すなわちＩＰｖ４のＩＰｓｅｃパケットのＵＤＰチェックサムフィールドをゼロに設定する仕様となっている。したがって、上記ＩＰｓｅｃパケット判定手段は、通信パケットがＩＰｖ４のＵＤＰパケットであり、かつそのＵＤＰチェックサムフィールドの値がゼロであることを確認した場合に、当該通信パケットをＩＰｓｅｃパケットであると判定してもよい。

なお、ＵＤＰチェックサムフィールドの値のみに基づいて、通信パケットがＩＰｓｅｃパケットであるか否かを判定してもよいが、上述の送信先及び送信元のポート番号による判定を併用してもよい。

例えば、送信先及び送信元のポート番号に基づいてＩＰｓｅｃパケットであると判定した通信パケットについて、さらにそのＵＤＰチェックサムフィールドの値から、当該通信パケットがＩＰｓｅｃパケットであるか否かを判定するようにしてもよい。これにより、中継する通信パケットがＩＰｓｅｃパケットであるか否かをより厳密に判断することができる。

また、上記ＩＰｓｅｃパケット判定手段は、上記パケット中継手段が中継する通信パケットのヘッダの値が、当該通信パケットがＩＰｓｅｃパケットであることを示している場合に、当該通信パケットがＩＰｓｅｃパケットであると判定することが好ましい。

ここで、ＩＰｓｅｃパケットのヘッダには、当該通信パケットがＩＰｓｅｃパケットであることを示す情報が含まれていることもある。そこで、上記の構成によれば、中継する通信パケットのヘッダの値を確認することによって、当該通信パケットがＩＰｓｅｃパケットであるか否か判定する。

例えば、ＩＰｓｅｃパケットのヘッダには、当該通信パケットがＩＰｓｅｃパケットであることを示す情報が含まれている場合がある。したがって、上記ＩＰｓｅｃパケット判定手段は、通信パケットのヘッダの値が、当該通信パケットがＩＰｓｅｃパケットであることを示していることを確認した場合に、その通信パケットをＩＰｓｅｃパケットであると判定してもよい。

また、上記ＩＰｓｅｃパケット判定手段は、上記パケット中継手段が中継する通信パケットのペイロード長が、予め定めたＩＰｓｅｃパケットのペイロード長の下限値以上、かつ、上限値以下である場合に、該通信パケットがＩＰｓｅｃパケットであると判定することが好ましい。

上述のように、ＩＰｓｅｃパケットには、通話に使用されているものと、それ以外のものとが含まれる。そして、通信中にリセットが行われると問題があるのは、通話に使用しているＩＰｓｅｃパケットである。つまり、ＩＰｓｅｃパケットのうち、通話に使用しているものと、それ以外のものとを判別し、通話以外のＩＰｓｅｃパケットをリセットの判定に用いないようにすること（ＩＰｓｅｃパケットではないものとして取り扱うこと）によって、ＩＰｓｅｃパケットの送受信時であっても、それが通話のパケットでない場合にはリセットを行うことが可能になる。

ここで、通話に使用されているＩＰｓｅｃパケットは、通話等のデータの送受信に用いられる性質上、そのペイロード長が一定の範囲内に含まれることが多い。このため、通話に使用されているＩＰｓｅｃパケットのペイロード長の上限値及び下限値を予め設定することができる。

そこで、上記の構成によれば、中継する通信パケットのペイロード長が、予め定めた下限値と上限値とで規定される範囲内に含まれているか否かを確認することによって、当該通信パケットがＩＰｓｅｃパケットであるか否か判定する。

例えば、ＶｏＩＰ／ＩＰＴＶ電話に用いられるＩＰｓｅｃパケットのペイロード長は、１６０ＢＹＴＥから１４７９ＢＹＴＥの範囲に含まれることが多い。このため、上記ＩＰｓｅｃパケット判定手段は、例えば上記下限値を１６０ＢＹＴＥとし、上記上限値を１４７９ＢＹＴＥとして、中継する通信パケットがＩＰｓｅｃパケットであるか否かを判定してもよい。

これにより、ＩＰｓｅｃパケットの中継時であっても、それが通話のパケットでない場合には再起動を行うことが可能になる。

また、上記再起動制御手段は、上記ＩＰｓｅｃパケット判定手段が、上記パケット中継手段が中継する通信パケットがＩＰｓｅｃパケットであると判定した後の一定時間Ｔの間は、再起動を行わないように制御することが好ましい。

ここで、通話のデータがＩＰｓｅｃパケットで送受信されるときには、一連の通話が複数のＩＰｓｅｃパケットに分割して送受信される。このため、通話データを構成するＩＰｓｅｃパケットの１つが受信または送信された後、該ＩＰｓｅｃパケットの次のＩＰｓｅｃパケットが受信または送信されるまでには、タイムラグが生ずる。このタイムラグの期間は、ＩＰｓｅｃパケットの受信中ではないが、一連の通話データの受信または送信中であるから、この期間に再起動が行われることは好ましくない。

そこで、上記の構成によれば、上記ＩＰｓｅｃパケット判定手段が、上記パケット中継手段の中継する通信パケットがＩＰｓｅｃパケットであると判断した後の一定時間Ｔの間は、上記中継装置の再起動を行わないようにしている。

このように、再起動を行わないようにする期間に、時間Ｔの幅を持たせることによって、ＩＰｓｅｃパケットを受信または送信した後、次のＩＰｓｅｃパケットを受信するまでのタイムラグの期間に再起動が行われる可能性を低減することができる。つまり、上記の構成によれば、一連の通話データの受信中に再起動が行われる可能性を低減することができる。

また、上記一定時間Ｔは、上記パケット中継手段がＩＰｓｅｃパケットを受信する、予め定められた一定の時間間隔ｔ１の自然数倍であることが好ましい。

上記のように、ＩＰｓｅｃパケットを受信または送信した後、次のＩＰｓｅｃパケットを受信または送信するまでのタイムラグが発生するが、このタイムラグの期間が一定である場合がある。

そこで、上記の構成によれば、上記一定時間Ｔを、上記タイムラグの期間に合わせて設定している。つまり、上記一定時間Ｔを、ＩＰｓｅｃパケットが上記パケット中継手段に対して送信される、予め定められた一定の時間間隔ｔ１の自然数倍としている。

したがって、上記タイムラグの期間に再起動が行われること、すなわち一連の通話データの受信中に再起動が行われることを防ぐことができる。

また、上記一定時間Ｔは、連続して受信される通信パケットが一連の通話データを構成する通信パケットであるか否かを判定する基準として予め定められた基準時間ｔ２より大きいことが好ましい。

上述のように、一連の通話データを構成する各通信パケットは、時間間隔を空けて受信される。ここで、一定以上の時間を空けて通信パケットが受信された場合には、それらの通信パケットは、一連の通話データを構成しないものと判断される。長時間、続きの通信パケットが受信されない場合には、通信パケットの送信等に失敗している可能性があるからである。なお、連続して受信される通信パケットが一連の通話データを構成する通信パケットであるか否かを判定する基準となる基準時間は、予め定められる。

逆に言えば、通信パケットの受信間隔が上記基準時間以下であれば、それらの通信パケットは、一連の通話データを構成する可能性がある。したがって、少なくとも上記基準時間の間は、通信パケットの受信が行われていなくとも、再起動を行わないようにすることが好ましい。

そこで、上記の構成によれば、上記一定時間Ｔを、連続して受信される通信パケットが一連の通話データを構成する通信パケットであるか否かを判定する基準として予め定められた基準時間ｔ２より大きく設定している。したがって、上記の構成によれば、一連の通話データの受信中に再起動が行われる可能性を低減することができる。

また、上記パケット中継手段は、受信時間ｔ３の間通信パケットを受信し、その後送信時間ｔ４の間に通信パケットの送信を行う処理の繰り返しによって通信パケットの中継を行い、上記一定時間Ｔは、上記受信時間ｔ３と送信時間ｔ４との和の自然数倍であり、上記ＩＰｓｅｃパケット判定手段は、上記パケット中継手段が送信する通信パケットがＩＰｓｅｃパケットであるか否かを判定することが好ましい。

ここで、通信パケットの中継には、通信パケットを受信する処理と、受信した通信パケットを他の装置に送信する処理とが含まれている。そして、上記中継装置において、通信パケットがＩＰｓｅｃパケットであるか否かを判定する処理は、通信パケットを受信するときに行ってもよいし、送信するときに行ってもよい。

しかし、通信パケットを受信するときに、当該通信パケットがＩＰｓｅｃパケットであると判定した後、上記一定時間Ｔが経過したときに、中継装置が通信パケットを送信する処理を行っていた場合には、送信している通信パケットがＩＰｓｅｃパケットであっても、再起動が行われる可能性がある。通信パケットを送信するときにＩＰｓｅｃパケットの判定を行う場合も同様である。

すなわち、通話の中断を完全に防ぐためには、通信パケットを受信するときにＩＰｓｅｃパケットの判定を行う場合には、少なくとも次の通信パケットの受信時までは、再起動を行わないようにする必要がある。同様に、通信パケットを送信するときにＩＰｓｅｃパケットの判定を行う場合には、少なくとも次の通信パケットの送信時までは、再起動を行わないようにする必要がある。

そこで、上記の構成によれば、上記一定時間Ｔを、受信時間ｔ３と送信時間ｔ４との自然数倍としている。これにより、一連の通話データの受信中に再起動が行われることを防ぐことができる。

また、上記中継装置は、自装置が接続されているＷＡＮから通信パケットを受信するＷＡＮ通信部を備え、上記ＩＰｓｅｃパケット判定手段は、上記ＷＡＮ通信部から受信した通信パケットをＩＰｓｅｃパケットであると判定しないことが好ましい。

ＷＡＮには不特定多数の人間がアクセス可能であることから、ＷＡＮから受信した通信パケットに対しては、特にセキュリティ対策を厚くして、第三者からの攻撃を防ぐ必要がある。例えば、上記中継装置では、ＩＰｓｅｃパケットの中継時に再起動を行わないようにしているので、該中継装置に定期的にＩＰｓｅｃパケットを送信して、再起動をさせないようにする攻撃を受ける可能性がある。

そこで、上記の構成によれば、上記ＩＰｓｅｃパケット判定手段は、上記ＷＡＮ通信部から受信した通信パケットをＩＰｓｅｃパケットであると判断しない。これにより、上記のような攻撃を受けることなく、必要な再起動を行うことができる。

なお、上記中継装置は、コンピュータによって実現してもよく、この場合には、コンピュータを上記中継装置の各手段として動作させることにより、上記中継装置をコンピュータにて実現させる制御プログラム、及びそれを記録したコンピュータ読み取り可能な記録媒体も本発明の範疇に入る。

以上のように、本発明に係る中継装置は、通信パケットの中継を行うパケット中継手段と、上記パケット中継手段が中継する上記通信パケットが、ＩＰｓｅｃプロトコルによって暗号化された通信パケットであるＩＰｓｅｃパケットであるか否かを判定するＩＰｓｅｃパケット判定手段と、上記ＩＰｓｅｃパケット判定手段が、上記パケット中継手段が中継する通信パケットがＩＰｓｅｃパケットであると判定したときに、再起動を行わないように制御する再起動制御手段とを備えている構成である。

また、本発明に係る中継方法は、通信パケットの中継を行うと共に、所定のタイミングで再起動を行う中継装置の中継方法であって、上記通信パケットの中継を行うパケット中継ステップと、上記パケット中継ステップにおいて中継される上記通信パケットが、ＩＰｓｅｃプロトコルによって暗号化された通信パケットであるＩＰｓｅｃパケットであるか否かを判定するＩＰｓｅｃパケット判定ステップと、上記ＩＰｓｅｃパケット判定ステップにおいて、上記パケット中継ステップにおいて中継される通信パケットがＩＰｓｅｃパケットであると判定したときに、再起動を行わないように制御する再起動制御ステップとを含む構成である。

上記の構成によれば、通話のデータの送受信に用いられるＩＰｓｅｃパケットの中継時に再起動が行われないので、再起動による通話の中断を防ぐことができるという効果を奏する。

本発明のＨＧＷにおけるソフトウェア構成の一例を示すブロック図である。 上記ＨＧＷと、ＮＧＮ、インターネット、３Ｇ網、ＮＧＮ端末、および３Ｇ端末との接続関係の一例を示す図である。 上記ＨＧＷのハードウェア構成の一例を示すブロック図である。 上記ＨＧＷのパケット転送部が接続ネットワークからパケットを受信する際の処理一例を示すフローチャートである。 上記ＨＧＷの受信パケット判定処理の一例を示すフローチャートである。 上記ＨＧＷのパケット転送部が接続ネットワークへパケットを送信する際の処理の一例を示すフローチャートである。 送信パケット判定処理の一例を示すフローチャートである。 リセット制御部が行うリセット制御処理の一例を示すフローチャートである。 従来のＮＧＮ用のＨＧＷと、ＮＧＮおよびインターネット並びにＮＧＮ端末およびＰＣとの接続関係を示す図である。 上記ＨＧＷの機能ブロック図である。 ＳＩＰによる電話呼の通信開始・終了の典型的なシーケンスを示す図である。 リセット管理部のリセット制御に関するシーケンスを示す図である。 Ｉ−ＷＬＡＮの無線通信技術を備える３Ｇ携帯端末と３Ｇ網の接続関係を示す図である。

本発明の一実施形態について図１から図８に基づいて説明すると以下の通りである。ここでは、まず、本実施形態の通信システムの概要について、図２に基づいて説明する。

〔通信システムの概要〕
図２は、ＨＧＷ（中継装置）２０と、ＮＧＮ５１、インターネット５２、３Ｇ網５６、ＮＧＮ端末４１、４２、および３Ｇ端末（ＵＥ）４３との接続関係の一例を示す図である。ＨＧＷ２０はＮＧＮに対応したゲートウェーであり、図示のように、ＬＡＮ３１、ＷＬＡＮ３２、およびＷＡＮ３３と接続している。また、ＨＧＷ２０は、ＷＡＮ３３を介してＮＧＮ５１およびインターネット５２と接続している。さらに、ＨＧＷ２０は、ＬＡＮ３１を介してＮＧＮ端末４１と接続し、ＷＬＡＮ３２を介してＮＧＮ端末４２および３Ｇ端末４３と接続している。このような接続関係の下、ＨＧＷ２０は、ＮＧＮ端末４１、ＮＧＮ端末４２、および３Ｇ端末４３と、ＮＧＮ５１またはインターネット５２との通信を中継している。

ＮＧＮ端末４１、４２、および３Ｇ端末４３は、ＨＧＷ２０を介して通信を行うクライアント端末である。ここでは、ＮＧＮ端末４１は固定電話機、ＮＧＮ端末４２は携帯型情報端末、３Ｇ端末４３は携帯電話機である例を示している。無論、ＨＧＷ２０のクライアント端末は、これらの端末に限られない。

そして、ＮＧＮ端末４１、４２、および３Ｇ端末４３は、それぞれＬＡＮ３１またはＷＬＡＮ３２を介してＨＧＷ２０にアクセスし、該ＨＧＷ２０を介して相互に通信を行う。また、ＮＧＮ端末４１、４２、および３Ｇ端末４３は、それぞれＬＡＮ３１またはＷＬＡＮ３２を介してＨＧＷ２０にアクセスし、該ＨＧＷ２０のＷＡＮ３３を介してＮＧＮ５１およびインターネット５２にアクセスする。

ここで、３Ｇ端末４３が、３Ｇ網５６にアクセスするときには、図１３の従来例と同様に、３Ｇ網の末端であるｅＰＤＧ５３、ＰＤＮゲートウェー５４を経由して、３Ｇ網５６のＳｅｒｖｉｎｇ Ｇａｔｅｗａｙ５５に接続する。この際、ＩＰ網から３Ｇへアクセスするために、３Ｇ端末４３と、ｅＰＤＧ５３との間にＩＰｓｅｃトンネルが張られる。そして、このＩＰｓｅｃトンネルを介して３Ｇ網５６とＩＰｓｅｃパケット、すなわちＩＰｓｅｃプロトコルによって暗号化された通信パケットの送受信が行われる。

〔ＨＧＷ２０のハードウェア構成〕
次に、ＨＧＷ２０のハードウェア構成について、図３に基づいて説明する。図３は、ＨＧＷ２０のハードウェア構成の一例を示すブロック図である。図示のように、ＨＧＷ２０は、ＣＰＵ２１、不揮発性メモリ２２、揮発性メモリ２３、ＬＡＮ ＮＩＣ（Network Interface Card）２４、ＷＬＡＮ ＮＩＣ２５、ＷＡＮ ＮＩＣ２６、操作部２７、および表示部２８を含む構成である。

ＣＰＵ２１は、ＨＧＷ２０で行われる各種処理を統括して制御する。ＣＰＵ２１は、不揮発性メモリ２２または揮発性メモリ２３からプログラムまたはデータなどを読み出して、所定の処理を実行する。ＣＰＵ２１が実行する処理については、後に詳しく説明する。

不揮発性メモリ２２は、例えば、ＨＤ（ハードディスク）などで構成されており、ＣＰＵ２１が処理に用いるプログラムおよびデータなどを保持する。

揮発性メモリ２３は、ＣＰＵ２１が処理を行うためにプログラムまたはデータを一時保存する記録媒体（いわゆるメインメモリ）である。

ＬＡＮ ＮＩＣ２４は、ＨＧＷ２０がＬＡＮ３１に接続するためのインターフェースである。同様に、ＷＬＡＮ ＮＩＣ２５は、ＨＧＷ２０がＷＬＡＮ３２に接続するためのインターフェースであり、ＷＡＮ ＮＩＣ２６は、ＨＧＷ２０がＷＡＮ３３に接続するためのインターフェースである。

図示の例では、ＨＧＷ２０は、ＬＡＮ ＮＩＣ２４を介してＬＡＮ３１に接続し、ＬＡＮ３１からＮＧＮ端末４１に接続している。また、ＷＬＡＮ ＮＩＣ２５を介してＷＬＡＮ３２に接続し、ＷＬＡＮ３２からＮＧＮ端末４２および３Ｇ端末４３に接続している。そして、ＷＡＮ ＮＩＣ２６を介してＷＡＮ３３に接続し、ＷＡＮ３３からＮＧＮ５１およびインターネット５２に接続している。

操作部２７は、ユーザがＨＧＷ２０に操作入力を行うためのものである。操作部２７は、ユーザが所望の操作入力を行えるものであればよく、特に限定されない。

表示部２８は、ユーザにＨＧＷ２０の動作状態または処理内容を通知するものである。表示部２８は、例えばＬＥＤ（Light Emitting Diode）のように点灯、点滅等で通知を行うものであってもよいし、液晶表示パネル等のように画像を表示して通知を行うものであってもよい。なお、操作部２７および表示部２８は、ＨＧＷ２０の必須の構成ではない。

〔ＨＧＷ２０のソフトウェア構成〕
次に、ＨＧＷ２０のソフトウェア構成について図１に基づいて説明する。図１は、ＨＧＷ２０のソフトウェア構成の一例を示すブロック図である。図示のように、ＨＧＷ２０は、制御部１、記憶部２、ＬＡＮインターフェース（ＬＡＮ通信部）１１、ＷＬＡＮインターフェース（ＷＬＡＮ通信部）１２、およびＷＡＮインターフェース（ＷＡＮ通信部）１３を含む。

制御部１は、上述のＣＰＵ２１に相当するものであり、パケット転送部（パケット中継手段）３、電話部４、タイマ５、およびリセット制御部（再起動制御手段）６を含む。記憶部２は、上述の不揮発性メモリ２２または揮発性メモリ２３に相当するものであり、電話呼フラグ記憶部７およびＩＰｓｅｃフラグ記憶部８を含む。さらに、パケット転送部３は、ＩＰｓｅｃパケット検知部（ＩＰｓｅｃパケット判定手段）３ａおよびＩＰｓｅｃフラグ設定部３ｂを含む。

パケット転送部３は、ＨＧＷ２０が中継するパケット（通信パケット）、具体的にはＬＡＮ３１、ＷＬＡＮ３２、またはＷＡＮ３３を介して伝送されてくるパケットを監視し、ＬＡＮ３１、ＷＬＡＮ３２、またはＷＡＮ３３の何れへ転送すべきかを判断する。つまり、パケット転送部３は、いわゆるルータの機能を有する。

具体的には、パケット転送部３は、接続ネットワークからパケットを受信した場合、パケットのヘッダを確認して、電話部４で処理するパケットか自身で処理するパケットかを判断する。そして、パケット転送部３は、電話部４で処理すると判断した場合、電話部４に当該パケットを送信する。なお、電話部４で処理するパケットは、ＳＩＰの電話呼及びＲＴＰ（Real-time Transport Protocol）の音声データ等である。一方、パケット転送部３は、自身で処理するパケットを受信した場合には、当該パケットのヘッダを確認して、所定の宛先へ接続ネットワークを介して送信する。

ＩＰｓｅｃパケット検知部３ａは、パケット転送部３が中継するパケットがＩＰｓｅｃパケットであるか否かを判定する。そして、ＩＰｓｅｃパケット検知部３ａは、パケット転送部３が中継するパケットがＩＰｓｅｃパケットであると判定した場合、タイマ５に対して一定時間Ｘのタイマをスタートするように命令する。また、ＩＰｓｅｃパケット検知部３ａは、パケット転送部３が中継するパケットがＩＰｓｅｃパケットであると判定すると、その旨をＩＰｓｅｃフラグ設定部３ｂに対して通知する。

ＩＰｓｅｃフラグ設定部３ｂは、ＩＰｓｅｃパケット検知部３ａから、パケット転送部３が中継するパケットがＩＰｓｅｃパケットである旨の通知を受けると、ＩＰｓｅｃフラグ記憶部８にＩＰｓｅｃフラグを立てる。ＩＰｓｅｃフラグは、パケット転送部３がＩＰｓｅｃパケットの中継を行っていることを示すものであり、このフラグが立っている間は、ＨＧＷ２０のリセットが行われないように制御される。

電話部４は、パケット転送部３によって振り分けられたＳＩＰに基づく電話呼を管理し、また、ＲＴＰの音声データ等を所定の宛先へ転送する。つまり、電話部４は、ＳＩＰにおいて、いわゆるＢ２ＢＵＡの機能を有するものである。また、電話部４は、ＳＩＰメッセージを参照することによって、通話中であるか否かを判断する。電話部４は、詳細は後述するが、通話中であると判断したときには、通話中（電話呼の送受信中）であることを示す電話呼フラグを電話呼フラグ記憶部７に立てる。このフラグが立っている間も、ＨＧＷ２０のリセットが行われないように制御される。

タイマ５は、ＩＰｓｅｃパケット検知部３ａによって定められた時間（一定時間Ｘ）を計時（カウント）するものである。なお、タイマ５の計時のスタートおよび計時のリセットは、ＩＰｓｅｃパケット検知部３ａの命令に従って行われる。

リセット制御部６は、電話呼フラグ記憶部７に記憶されている電話呼フラグ、およびＩＰｓｅｃフラグ記憶部８に記憶されているＩＰｓｅｃフラグの有無に応じて、ＨＧＷ２０のリセットを制御する。

電話呼フラグ記憶部７は、電話部４によって立てられた電話呼フラグを記憶するものであり、ＩＰｓｅｃフラグ記憶部８は、ＩＰｓｅｃフラグ設定部３ｂによって立てられたＩＰｓｅｃフラグを記憶するものである。

ＬＡＮインターフェース１１、ＷＬＡＮインターフェース１２、およびＷＡＮインターフェース１３は、それぞれＬＡＮ ＮＩＣ２４、ＷＬＡＮ ＮＩＣ２５、およびＷＬＡＮ ＮＩＣ２６に対応している。図示のように、ＬＡＮインターフェース１１、ＷＬＡＮインターフェース１２、およびＷＡＮインターフェース１３は、何れもパケット転送部３および電話部４と接続している。

つまり、ＬＡＮ３１、ＷＬＡＮ３２、またはＷＡＮ３３を介してＨＧＷ２０が受信するパケットは、全てパケット転送部３に受信されるようになっている。そして、ＨＧＷ２０が接続ネットワークを介して送信するパケットのうち、ＳＩＰの電話呼及びＲＴＰの音声データ等は、電話部４が送信し、それ以外のパケットは、パケット転送部３が送信する。

以上のように、本実施形態では、ＨＧＷ２０の各ブロック、特に制御部１を、ＣＰＵ２１を用いてソフトウェアによって実現する例を説明する。

すなわち、ＨＧＷ２０は、各機能を実現する制御プログラムの命令を実行するＣＰＵ２１、上記プログラムを格納したＲＯＭ（read only memory）、上記プログラムを展開するＲＡＭ（random access memory）、上記プログラムおよび各種データを格納するメモリ等の記憶装置（記録媒体）などを備えている。そして、本発明の目的は、上述した機能を実現するソフトウェアであるＨＧＷ２０の制御プログラムのプログラムコード（実行形式プログラム、中間コードプログラム、ソースプログラム）をコンピュータで読み取り可能に記録した記録媒体を、上記ＨＧＷ２０に供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に記録されているプログラムコードを読み出し実行することによっても、達成可能である。

上記記録媒体としては、例えば、磁気テープやカセットテープ等のテープ系、フロッピー（登録商標）ディスク／ハードディスク等の磁気ディスクやＣＤ−ＲＯＭ／ＭＯ／ＭＤ／ＤＶＤ／ＣＤ−Ｒ等の光ディスクを含むディスク系、ＩＣカード（メモリカードを含む）／光カード等のカード系、あるいはマスクＲＯＭ／ＥＰＲＯＭ／ＥＥＰＲＯＭ／フラッシュＲＯＭ等の半導体メモリ系などを用いることができる。

また、ＨＧＷ２０を通信ネットワークと接続可能に構成し、上記プログラムコードを通信ネットワークを介して供給してもよい。この通信ネットワークとしては、特に限定されず、例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ、ＩＳＤＮ、ＶＡＮ、ＣＡＴＶ通信網、仮想専用網（virtual private network）、電話回線網、移動体通信網、衛星通信網等が利用可能である。また、通信ネットワークを構成する伝送媒体としては、特に限定されず、例えば、ＩＥＥＥ１３９４、ＵＳＢ、電力線搬送、ケーブルＴＶ回線、電話線、ＡＤＳＬ回線等の有線でも、ＩｒＤＡやリモコンのような赤外線、Ｂｌｕｅｔｏｏｔｈ（登録商標）、８０２．１１無線、ＨＤＲ、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。なお、本発明は、上記プログラムコードが電子的な伝送で具現化された、搬送波に埋め込まれたコンピュータデータ信号の形態でも実現され得る。無論、制御部１をハードウェアロジックによって構成することもできる。

〔ＨＧＷ２０が行う処理の流れ〕
次に、ＨＧＷ２０が行う処理の流れについて、図４〜７に基づいて説明する。ここで、上述のように、ＨＧＷ２０は、中継するパケット（通信パケット）がＩＰｓｅｃパケットであるか否かを判定し、ＩＰｓｅｃパケットであると判定した場合に、リセットを行わないようにする。このＩＰｓｅｃパケットであるか否かの判定は、パケットを受信したとき、またはパケットを送信するときに行われる。

〔パケット受信時にＩＰｓｅｃパケットの判定を行う場合の例〕
ここでは、まず、パケット転送部３がパケットを受信したときに、当該パケットがＩＰｓｅｃパケットであるか否かの判定を行う例について、図４および図５に基づいて説明する。図４および図５は、パケット転送部３が接続ネットワークからパケットを受信する際の処理の一例を示すフローチャートである。

パケット転送部３は、ＬＡＮ３１、ＷＬＡＮ３２、またはＷＡＮ３３からのパケット受信を確認する（Ｓ１０）と、受信したパケットがＳＩＰによる電話呼（通常の電話呼）のパケットか否かを判断する（Ｓ１１）。

ここで、受信したパケットが通常の電話呼であると判断した場合（Ｓ１１でＹＥＳ）には、パケット転送部３は、受信したパケットを電話部４に転送する。そして、パケットの転送を受けた電話部４は、通話が開始されたか否かを確認する（Ｓ１２）。具体的には、電話部４は、ＳＩＰ ＩＮＶＩＴＥの受信を確認したとき、またはＳＩＰ ＩＮＶＩＴＥに対する２００ＯＫの受信を確認したときに通話が開始されたと判断する。

通話が開始されたことが確認された場合（Ｓ１２でＹＥＳ）には、電話部４は、電話呼フラグ記憶部７に、上記開始された通話に対応する電話呼フラグを立てる（Ｓ１３）。上述のように、この電話呼フラグはＨＧＷ２０のリセット禁止を示すフラグである。

Ｓ１２において、通話が開始されたことが確認されなかった場合（Ｓ１２でＮＯ）、およびＳ１３で電話呼フラグを立てた後には、電話部４は、通話が終了されたか否かを確認する（Ｓ１４）。具体的には、電話部４は、現在管理している電話呼、つまり、Ｓ１２で受信を確認したＳＩＰ ＩＮＶＩＴＥ、またはＳＩＰ ＩＮＶＩＴＥに対する２００ＯＫに対するＳＩＰ ＢＹＥを受信したとき、またはＳＩＰ ＢＹＥに対する２００ＯＫを受信したときに通話が終了されたと判断する。

ここで、通話が終了されたことが確認された場合（Ｓ１４でＹＥＳ）には、電話部４は、電話呼フラグ記憶部７に立てられている、当該終了された通話に対応する電話呼フラグを下げる（Ｓ１５）。

Ｓ１４において、通話が終了されたことが確認されなかった場合（Ｓ１４でＮＯ）、およびＳ１５で電話呼フラグを下げた後には、処理はＳ１０に戻る。つまり、パケット転送部３は、パケットの受信を待ち受け、パケットの受信を確認したとき（Ｓ１０）に、受信したパケットが通常の電話呼であるか確認する（Ｓ１１）。そして、通常の電話呼であることを確認した場合には、再びＳ１２からＳ１５の処理が行われる。

一方、Ｓ１１において、受信したパケットが通常の電話呼以外のパケットであると判断した場合（Ｓ１１でＮＯ）には、パケット転送部３のＩＰｓｅｃパケット検知部３ａは、受信パケット判定処理を行う（Ｓ２１）。これにより、Ｓ１０で受信したパケットがＩＰｓｅｃパケットであるか否かが判定される。なお、受信パケット判定処理の詳細については後述する。

ここで、受信パケット判定処理の結果、受信したパケットがＩＰｓｅｃではないと確認された場合（Ｓ２２でＮＯ）には、処理はＳ１０に戻る。一方、受信したパケットがＩＰｓｅｃであると確認された場合（Ｓ２２でＹＥＳ）には、ＩＰｓｅｃパケット検知部３ａは、その旨をＩＰｓｅｃフラグ設定部３ｂに通知する。

次に、ＩＰｓｅｃパケットの受信が確認された旨の通知を受けたＩＰｓｅｃフラグ設定部３ｂは、ＩＰｓｅｃフラグ記憶部８に、ＩＰｓｅｃフラグが立っているか否かを確認する（Ｓ２３）。

ここで、ＩＰｓｅｃフラグが立っていないことが確認された場合（Ｓ２３でＹＥＳ）には、ＩＰｓｅｃフラグ設定部３ｂは、ＩＰｓｅｃフラグ記憶部８にＩＰｓｅｃフラグを立てる（Ｓ２４）。そして、タイマ５に指示して一定時間Ｘの計測をスタートさせる（Ｓ２６）。

一方、すでにＩＰｓｅｃフラグが立っていることが確認された場合（Ｓ２３でＮＯ）には、タイマ５によって上記一定時間Ｘの計測が行われていることになるので、ＩＰｓｅｃフラグ設定部３ｂはタイマ５のカウントをリセットする（Ｓ２５）。そして、タイマ５に指示して一定時間Ｘの計測を再スタートさせる（Ｓ２６）。

次に、ＩＰｓｅｃフラグ設定部３ｂは、タイマ５のカウントがゼロになったか否か、すなわち上記一定時間Ｘが経過したか否かを確認する（Ｓ２７）。ここで、タイマ５のカウントがゼロになっていた場合（Ｓ２７でＹＥＳ）には、ＩＰｓｅｃフラグ設定部３ｂは、ＩＰｓｅｃフラグ記憶部８に立てられているＩＰｓｅｃフラグを下げる（Ｓ２８）。一方、タイマ５のカウントがゼロになっていなかった場合（Ｓ２７でＮＯ）には、処理はＳ１０に戻り、次のパケットの受信が行われる。

なお、ＩＰｓｅｃフラグ設定部３ｂは、ＩＰｓｅｃフラグをＩＰｓｅｃパケットの受信が確認される度に立ててもよい。その場合、タイマ５のカウントは、各ＩＰｓｅｃフラグについて行われる。つまり、ＩＰｓｅｃパケットの受信が確認されてＩＰｓｅｃフラグが立てられた後、そのＩＰｓｅｃフラグが下げられる前に、別のＩＰｓｅｃパケットの受信が確認されたときには、２つ目のＩＰｓｅｃフラグが立てられる。そして、１つ目のＩＰｓｅｃフラグが立てられた後、一定時間Ｘが経過したときに１つ目のＩＰｓｅｃフラグが下げられ、２つ目のＩＰｓｅｃフラグが立てられた後、一定時間Ｘが経過したときに、２つ目のＩＰｓｅｃフラグが下げられる。

〔一定時間Ｘについて〕
ＩＰｓｅｃフラグが立てられてから下げられるまでの一定時間Ｘは、リセットを行わないように制御されるが、この一定時間Ｘは、ＩＰｓｅｃパケットの送信間隔に合わせて設定することが好ましい。すなわち、一般に、ＩＰｓｅｃパケットは、一定の時間間隔で送受信される。このため、一定時間ＸをＩＰｓｅｃパケットの送信間隔に合わせることによって、１つのＩＰｓｅｃパケットの送信または受信が確認された後、次のＩＰｓｅｃパケットの送信または受信が行われるまでの間、ＩＰｓｅｃフラグが立てられた状態を保つことができる。これにより、ＩＰｓｅｃパケットの送受信中にリセットが行われることを防ぐことができる。

例えば、音声符号化方式であるＧ．７１１（ｍｕ−ｌａｗ）によって、通話に関する通信データがコーデックされている場合、２０ｍｓ（一定の時間間隔ｔ１）ごとにＩＰｓｅｃパケットの送受信が行われる。このため、３Ｇ端末４３がｍｕ−ｌａｗに対応している場合には、Ｘを２０ｍｓのｍ倍（ｍ：自然数）に設定すればよい。

なお、ＨＧＷ２０の消費電力を抑えるためには、各部材の処理を簡素化することが好ましく、ＩＰｓｅｃフラグの上げ下げ回数も必要最小限に抑えることが好ましい。そこで、ＩＰｓｅｃパケットの通過周期（２０ｍｓ）毎にＩＰｓｅｃフラグの確認または再起動の制御判断を行うのではなく、例えば、一定時間Ｘを２０ｍｓのｍ倍（ｍ：２以上の自然数）に設定することがより好ましい。

また、一定時間Ｘは、ＨＧＷ２０のスリープ時間に合わせて設定してもよい。例えば、ＷｉＦｉ（登録商標）では、省電力化のために、ＷＬＡＮ ＡＰが電源管理機能を有する仕様となっている。上記の電源管理機能を有するＷＬＡＮ ＡＰには、１００ｍｓの間送信機能がスリープし、受信のみを行うものもある。そして、１００ｍｓスリープした後、数ｍｓの間にそれまでに蓄積しているデータの送信を行う。そして、また、１００ｍｓのスリープモードに入る。

ＨＧＷ２０が、このような電源管理機能を有する場合には、上記一定時間Ｘを送信機能がスリープする１００ｍｓ（受信時間ｔ３）＋数ｍｓ（送信時間ｔ４）に設定することによって、一連の通話データを構成するＩＰｓｅｃパケットの送受信中にリセットが行われることを防ぐことができる。

また、上記一定時間Ｘは、ジッタバッファに基づいて設定することが望ましい。ジッタバッファは、パケットの送信時に発生するジッタをカバーするためのバッファである。例えば、ＩＰｓｅｃパケットを用いて通話を行うＶｏＩＰ（Voice over IP）では、送信側のパケットを送信する間隔と受信側のパケットを受信する間隔とが一致しない場合がある。そのため、ＶｏＩＰによるパケットデータを送受信する場合、パケットの損失を防ぐために受信側にジッタバッファを設ける。

ジッタバッファを設けた３Ｇ端末４３では、受信するＶｏＩＰパケットが遅延した場合であっても、ジッタバッファで規定される所定時間内に受信すれば、連続した通話データとみなす。そのため、一連の通話データを途切れさせないために、ＨＧＷ２０においても、３Ｇ端末４３におけるジッタバッファで規定される所定時間（基準時間ｔ２）内に受信した通信パケットを、連続した通話データと判断可能である。なお、上記所定時間は、ジッタバッファが蓄積可能な通信パケットの受信に要する時間である。例えば、ジッタバッファが、ＶｏＩＰパケット４個分の容量に設定されている場合には、一般的にＶｏＩＰパケットは２０ｍｓ毎に送信されるので、上記所定時間は８０ｍｓとなる。

このように、通信パケットの受信間隔が、上記所定時間以下であれば、その通信パケットは、連続した通話データである可能性があるので、上記所定時間内にはリセットを行わないようにすることが好ましい。つまり、上記一定時間Ｘは、上記所定時間以上に設定することが好ましい。これにより、連続した通話データがリセットによって中断されることを防ぐことができる。

ただし、上記一定時間Ｘは、ＩＰｓｅｃパケットの送信時間間隔、スリープ時間、またはジッタバッファに正確に一致している必要はなく、上記の効果が得られる程度の誤差を含んだ時間であってもよい。例えば、上記一定時間Ｘが２０ｍｓの場合、（２０ｍｓ−数ｍｓ）から（２０ｍｓ＋数ｍｓ）の範囲に設定してもよい。

〔受信パケット判定処理〕
次に、図４のＳ２１で行われる受信パケット判定処理の詳細について図５に基づいて説明する。図５は、受信パケット判定処理の一例を示すフローチャートである。

まず、ＩＰｓｅｃパケット検知部３ａは、受信したパケットがＷＡＮ側から受信したものであるか否かを確認する（Ｓ２１１）。具体的には、ＩＰｓｅｃパケット検知部３ａは、パケットをＷＡＮインターフェース１３で受信したときには、ＷＡＮ側で受信したと判断する。一方、パケットをＬＡＮインターフェース１１またはＷＬＡＮインターフェース１２で受信したときには、ＷＡＮ側で受信されなかった（ＬＡＮ側で受信した）と判断する。

ここで、ＷＡＮ側から受信したと判断した場合（Ｓ２１１でＹＥＳ）には、ＩＰｓｅｃパケット検知部３ａは、受信したパケットをＩＰｓｅｃパケットではないと判断して（Ｓ２１２）、受信パケット判定処理を終了する。

なお、ＷＡＮ側からのパケット受信時に、無条件で受信したパケットをＩＰｓｅｃパケットではないと判断する理由は、ＨＧＷ２０のセキュリティを向上させるためである。つまり、ＨＧＷ２０は、ＩＰｓｅｃパケットの受信時にリセットが行われないように制御するので、定期的にＩＰｓｅｃパケットを受信している状態ではリセットが行われない。

このため、何者かがＨＧＷ２０のリセットを妨害する目的でＨＧＷ２０にＩＰｓｅｃパケットを定期的に送信する可能性がある。このような攻撃は、不特定多数の者がアクセス可能なＷＡＮ経由で行われる可能性が高い。ゆえに、ＨＧＷ２０では、ＷＡＮ側から受信したパケットをＨＧＷ２０のリセット制御の判断に使用しないこととして、セキュリティを向上させている。

一方、ＷＡＮ側で受信されなかった（ＬＡＮ側で受信した）と判断した場合（Ｓ２１１でＮＯ）には、ＩＰｓｅｃパケット検知部３ａは、受信したパケットのヘッダを参照して、当該パケットがＩＰｖ６のＩＰｓｅｃパケットかどうかの確認をする（Ｓ２１３）。これは、ＩＰｖ６では、ＩＰｓｅｃパケットのヘッダ情報に該パケットがＩＰｓｅｃパケットであることを示す情報が含まれているからである。

ここで、当該パケットがＩＰｖ６のＩＰｓｅｃパケットであることが確認された場合（Ｓ２１３でＹＥＳ）には、ＩＰｓｅｃパケット検知部３ａは、受信したパケットをＩＰｓｅｃパケットと判断して（Ｓ２１４）、受信パケット判定処理を終了する。

一方、受信したパケットがＩＰｖ６のＩＰｓｅｃパケットであることが確認されなかった場合（Ｓ２１３でＮＯ）には、ＩＰｓｅｃパケット検知部３ａは、受信したパケットの送信元ポートが５００であり、かつ送信先ポートも５００であるか否かを確認する（Ｓ２１５）。

送信元ポートが５００であり、かつ送信先ポートも５００であるパケットは、ＩＰｖ４のＩＰｓｅｃパケットと考えられる。これは、ＨＧＷ２０が中継するパケットは、ＩＰｖ６およびＩＰｖ４の２種類のパケットであり、一般的にＩＰｖ４の場合グローバルアドレスが不足しており、ＮＡＰＴ（Network Address Port Translation）によるＩＰアドレスの変換が行われる。そのため、ＩＰｓｅｃを利用する場合はＵＤＰ encapsulationという技術を用いてＵＤＰに見せかける。結果、ＨＧＷ２０は、ヘッダを参照してもＩＰｓｅｃであることが識別できない（単なるＵＤＰ（User Datagram Protocol）パケットとして識別する）。そのため、ＩＰｓｅｃパケットの送受信の際に用いられるポート番号（送信元ポート＝５００、且つ、送信先ポート＝５００）と通信パケットの宛先及び送信元のポート番号が一致するかどうかを確認することによって、通信パケットがＩＰｓｅｃパケットであるかどうかを判断する。

したがって、送信元ポートが５００であり、かつ送信先ポートも５００であることが確認された場合（Ｓ２１５でＹＥＳ）には、ＩＰｓｅｃパケット検知部３ａは、受信したパケットをＩＰｓｅｃパケットと判断して（Ｓ２１４）、受信パケット判定処理を終了する。

なお、Ｓ２１５の処理の代わりに、ＩＰｓｅｃパケット検知部３ａは、受信した通信パケットがＩＰｖ４のＵＤＰパケットであり、かつそのＵＤＰチェックサムフィールドが０であるか否かを確認してもよい。ＩＰｖ４のＵＤＰパケットが、ＩＰｓｅｃパケットである場合には、チェックサムフィールドがゼロに設定されるからである。

すなわち、ＩＥＴＦでは、ＩＰｖ４のＵＤＰパケットをＵＤＰ Encapsulationした通信パケット、つまりＩＰｖ４のＩＰｓｅｃパケットのＵＤＰチェックサムフィールドをゼロに設定する仕様となっている。したがって、ＩＰｓｅｃパケット検知部３ａは、通信パケットがＩＰｖ４のＵＤＰパケットであり、かつそのＵＤＰチェックサムフィールドの値がゼロであることを確認した場合に、当該通信パケットをＩＰｓｅｃパケットであると判定してもよい。

なお、ここでは、中継する通信パケットが、ＩＰｖ６かＩＰｖ４の何れかの通信パケットであることを想定しているので、Ｓ２１３でＮＯと判定された通信パケットは、ＩＰｖ４の通信パケットであると考えられる。つまり、Ｓ２１５で判定の対象となる通信パケットは、ＩＰｖ４の通信パケットであると考えられる。このため、Ｓ２１５において、チェックサムフィールドに基づいて当該通信パケットがＩＰｓｅｃパケットであるか否かを判定する場合には、チェックサムフィールドの値がゼロであるか否かのみが判定される。

また、ＩＰｓｅｃパケット検知部３ａは、Ｓ２１５でＹＥＳと判断した後に、さらに当該通信パケットがＩＰｖ４のＵＤＰパケットであり、かつそのＵＤＰチェックサムフィールドが０であるか否かを確認してもよい。この場合には、より厳密に通信パケットがＩＰｓｅｃパケットであるか否かを判定することができる。なお、この場合には、ポート番号による判定と、チェックサムフィールドによる判定とをそれぞれ別の機能ブロックが実行するようにしてもよい。

一方、送信元ポートが５００であり、かつ送信先ポートも５００であることが確認されなかった場合（Ｓ２１５でＮＯ）には、ＩＰｓｅｃパケット検知部３ａは、受信したパケットはＩＰｓｅｃパケットではないと判断して（Ｓ２１２）、受信パケット判定処理を終了する。

〔パケット送信時にＩＰｓｅｃパケットの判定を行う場合の例〕
続いて、パケット転送部３がパケットを送信するときに、当該パケットがＩＰｓｅｃパケットであるか否かの判定を行う例について、図６および図７に基づいて説明する。図６および７は、パケット転送部３が接続ネットワークへパケットを送信する際の処理の一例を示すフローチャートである。なお、図６には図４と同様の処理が含まれている。これらの処理については、同一の参照番号を付してその説明を省略する。

まず、パケット転送部３が接続ネットワークにパケットを送信することを確認する（Ｓ３０）と、パケット転送部３のＩＰｓｅｃパケット検知部３ａは、送信パケット判定処理を行う（Ｓ３１）。これにより、Ｓ３０で送信するパケットがＩＰｓｅｃパケットであるか否かが判定される。なお、送信パケット判定処理の詳細については後述する。

ここで、送信パケット判定処理の結果、送信するパケットがＩＰｓｅｃではないと確認された場合（Ｓ３２でＮＯ）には、処理はＳ３０に戻る。一方、送信するパケットがＩＰｓｅｃであると確認された場合（Ｓ３２でＹＥＳ）には、ＩＰｓｅｃパケット検知部３ａは、その旨をＩＰｓｅｃフラグ設定部３ｂに通知する。以下の処理は、図４のＳ２３からＳ２８の処理と同じである。

〔送信パケット判定処理〕
次に、図６のＳ３１で行われる送信パケット判定処理の詳細について、図７に基づいて説明する。図７は、送信パケット判定処理の一例を示すフローチャートである。

まず、ＩＰｓｅｃパケット検知部３ａは、送信するパケットのヘッダを参照して、当該パケットがＩＰｖ６のＩＰｓｅｃパケットかどうかの確認をする（Ｓ３１１）。ここで、当該パケットがＩＰｖ６のＩＰｓｅｃパケットであることが確認された場合（Ｓ３１１でＹＥＳ）には、ＩＰｓｅｃパケット検知部３ａは、送信するパケットをＩＰｓｅｃパケットと判断して（Ｓ３１２）、送信パケット判定処理を終了する。

一方、送信するパケットがＩＰｖ６のＩＰｓｅｃパケットであることが確認されなかった場合（Ｓ３１１でＮＯ）には、ＩＰｓｅｃパケット検知部３ａは、当該パケットの送信先がＬＡＮ側であるか否かを確認する（Ｓ３１３）。

ここで、パケットの送信先がＬＡＮ側であることが確認された場合（Ｓ３１３でＹＥＳ）には、ＩＰｓｅｃパケット検知部３ａは、送信するパケットの送信元ポートが５００であり、かつ送信先ポートも５００であるか否かを確認する（Ｓ３１４）。

ＬＡＮ側へ送信するパケットの送信元ポートが５００であり、かつ送信先ポートも５００である場合には、当該パケットは、ＩＰｖ４のＩＰｓｅｃパケットと考えられる。このため、送信元ポートが５００であり、かつ送信先ポートも５００であることが確認された場合（Ｓ３１４でＹＥＳ）には、ＩＰｓｅｃパケット検知部３ａは、送信するパケットをＩＰｓｅｃパケットと判断して（Ｓ３１２）、送信パケット判定処理を終了する。

一方、送信元ポートが５００であり、かつ送信先ポートも５００であることが確認されなかった場合（Ｓ３１４でＮＯ）には、ＩＰｓｅｃパケット検知部３ａは、送信するパケットはＩＰｓｅｃパケットではないと判断して（Ｓ３１６）、送信パケット判定処理を終了する。

ここで、パケットの送信先がＬＡＮ側でないこと、すなわちパケットの送信先がＷＡＮ側であることが確認された場合（Ｓ３１３でＮＯ）には、ＩＰｓｅｃパケット検知部３ａは、送信するパケットの送信元ポートが５００ではなく、かつ送信先ポートが５００であるか否かを確認する（Ｓ３１５）。

ＷＡＮ側へ送信するパケットの送信元ポートが５００ではなく、かつ送信先ポートが５００である場合には、当該パケットは、ＩＰｖ４のＩＰｓｅｃパケットと考えられる。このため、送信元ポートが５００でなく、かつ送信先ポートが５００であることが確認された場合（Ｓ３１５でＹＥＳ）には、ＩＰｓｅｃパケット検知部３ａは、送信するパケットをＩＰｓｅｃパケットと判断して（Ｓ３１２）、送信パケット判定処理を終了する。

なお、図５の例と同様に、送信する通信パケットがＩＰｖ４のＵＤＰパケットであり、かつそのＵＤＰチェックサムフィールドが０であるか否かに基づいて、当該通信パケットがＩＰｓｅｃパケットであるか否かを判定してもよい。また、Ｓ３１４またはＳ３１５でＹＥＳと判断した後に、チェックサムフィールドに基づく判定を行ってもよい。

一方、送信元ポートが５００でなく、かつ送信先ポートが５００であることが確認されなかった場合（Ｓ３１５でＮＯ）には、ＩＰｓｅｃパケット検知部３ａは、送信するパケットはＩＰｓｅｃパケットではないと判断して（Ｓ３１６）、送信パケット判定処理を終了する。

なお、電話部４も、パケットの送信時に当該パケットが通話データであるか否かを判断してもよい。この場合には、電話部４は、ＳＩＰメッセージを確認することによって通話開始・通話終了を判断して、パケットを送信する際に通話中と判断した場合に電話呼フラグを立てる。

〔リセット制御処理〕
次に、電話呼フラグおよびＩＰｓｅｃフラグの有無に基づいて、ＨＧＷ２０のリセット（再起動）を制御するリセット制御部６の処理を図８に基づいて説明する。図８は、リセット制御部６が行うリセット制御処理の一例を示すフローチャートである。

まず、リセット制御部６は、ＨＧＷ２０のファームウェアのアップデート時等に発生されるリセット指示を受信する（Ｓ５０）。そして、リセット制御部６は、リセット指示を受信したときに、リセット禁止フラグの確認を行う（Ｓ５１）。具体的には、リセット制御部６は、電話呼フラグ記憶部７の電話呼フラグおよびＩＰｓｅｃフラグ記憶部８のＩＰｓｅｃフラグの状態を確認する。

そして、リセット制御部６は、電話呼フラグおよびＩＰｓｅｃフラグの何れも立っていない状態となっているか否かを確認する（Ｓ５２）。ここで、電話呼フラグおよびＩＰｓｅｃフラグのどちらのフラグも立っていないことが確認された場合（Ｓ５２でＹＥＳ）、リセット制御部６は、Ｓ５０で受信したリセット指示に従ってＨＧＷ２０のリセットを開始する（Ｓ５３）。これにより、リセット制御処理は終了する。

一方、少なくとも１つのフラグが立っていることが確認された場合（Ｓ５２でＮＯ）には、リセット制御部６は、一定時間Ｙだけスリープ（待機）する（Ｓ５４）。なお、一定時間Ｙの経過は、例えばタイマ５に計測させればよい。

そして、一定時間Ｙの経過後、リセット制御部６は、リセット禁止フラグの再確認を行い（Ｓ５１）、フラグが立っていれば再び一定時間Ｙの待機を行い（Ｓ５４）、フラグが立っていなければリセットを開始する（Ｓ５３）。

このように、リセット制御処理では、電話呼フラグおよびＩＰｓｅｃフラグの何れも立っていない状態となったことが確認されたときにリセットが開始されるようになっている。これにより、通話が通常の電話呼によるものであっても、ＩＰｓｅｃによるものであっても、通話中にリセットが行われて通話が途切れることを防ぐことができる。

〔一定時間Ｙについて〕
一定時間Ｙは、リセット禁止フラグ（電話呼フラグおよびＩＰｓｅｃフラグ）の状態を確認する周期を示すものであるから、ＩＰｓｅｃフラグが立てられてから下げられるまでの一定時間Ｘに合わせて設定すればよい。なお、上記一定時間ＸおよびＹは、同じでもよいが、異なっていてもよい。例えば、上記一定時間Ｘを２０ｍｓに設定し、上記一定時間Ｙを２０ｍｓのｎ倍に設定してもよい。

〔ＩＰｓｅｃパケットが通話に使用されているものであるか否かの判定方法〕
上記では、ＩＰｖ６パケットの場合パケットヘッダに基づいて、またＩＰｖ４パケットの場合、パケットの送信元および受信元のポート番号に基づいてＩＰｓｅｃパケットとそれ以外のパケットとを判定する例について説明した。

ここで、ＩＰｓｅｃパケットには、通話に使用されているもの（例えばＶｏＩＰのＩＰｓｅｃパケット）と、それ以外のもの（例えばＨＴＴＰのＩＰｓｅｃパケット）とが含まれる。そして、上述のように、通信中にリセットが行われると問題があるのは、通話に使用しているＩＰｓｅｃパケットである。つまり、ＩＰｓｅｃパケットのうち、通話に使用しているものと、それ以外のものとを判別し、通話以外のＩＰｓｅｃパケットをリセットの判定に用いないようにすること（ＩＰｓｅｃパケットではないものとして取り扱うこと）によって、ＩＰｓｅｃパケットの送受信時であっても、それが通話のパケットでない場合にはリセットを行うことが可能になる。

具体的には、ＩＰｓｅｃパケットを送信する、または受信したと判定したときに、さらに以下のような判定を行うことによって、当該ＩＰｓｅｃパケットが通話に使用されているものであるか否かを判定することもできる。

例えば、パケットのペイロード長に基づいて、ＩＰｓｅｃパケットが通話に使用されているものであるか否かを判定するようにしてもよい。すなわち、通信パケットのペイロード長が、予め定めたＩＰｓｅｃパケットのペイロード長の下限値以上、かつ、上限値以下である場合に、該通信パケットが電話に使用されているＩＰｓｅｃパケットであると判定してもよい。

ここで、一般的に、通話に関する通信パケット（例えば、ＶｏＩＰ／ＩＰＴＶで通話に用いられる通信パケット）のペイロード長は、１６０バイトから１４７９バイトとなっている。このため、判定の対象となっているパケットのペイロード長が１６０バイト以上である場合に、当該パケットを電話に使用されているＩＰｓｅｃパケットと判断してもよい。同様に、判定の対象となっているパケットのペイロード長が１４７９バイト以下である場合に、当該パケットを電話に使用されているＩＰｓｅｃパケットと判断してもよく、当該パケットのペイロード長が１６０バイトから１４７９バイトの間である場合に、当該パケットを電話に使用されているＩＰｓｅｃパケットと判断してもよい。これにより、ＩＰｓｅｃパケットの送受信時であっても、それが電話のパケットでない場合にはリセットを行うことが可能になる。

本発明は上述した実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能である。すなわち、請求項に示した範囲で適宜変更した技術的手段を組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。

本発明は、ＩＰｓｅｃで送受信される通話データ等のパケットの中継を行う中継装置のうち、ファームウェアのアップデート時などに自動的に再起動を行う中継装置に利用することができる。

１ 制御部
２ 記憶部
３ パケット転送部（パケット中継手段）
３ａ ＩＰｓｅｃパケット検知部（ＩＰｓｅｃパケット判定手段）
３ｂ ＩＰｓｅｃフラグ設定部
４ 電話部
５ タイマ
６ リセット制御部（再起動制御手段）
７ 電話呼フラグ記憶部
８ ＩＰｓｅｃフラグ記憶部
１１ ＬＡＮインターフェース（ＬＡＮ通信部）
１２ ＷＬＡＮインターフェース（ＷＬＡＮ通信部）
１３ ＷＡＮインターフェース（ＷＡＮ通信部）
２０ ＨＧＷ（中継装置）

Claims (13)

1. 通信パケットの中継を行うと共に、所定のタイミングで再起動を行う中継装置であって、
   上記通信パケットの中継を行うパケット中継手段と、
   上記パケット中継手段が中継する上記通信パケットが、ＩＰｓｅｃプロトコルによって暗号化された通信パケットであるＩＰｓｅｃパケットであるか否かを判定するＩＰｓｅｃパケット判定手段と、
   上記ＩＰｓｅｃパケット判定手段が、上記パケット中継手段が中継する通信パケットがＩＰｓｅｃパケットであると判定したときに、再起動を行わないように制御する再起動制御手段とを備えていることを特徴とする中継装置。
2. 上記パケット中継手段が中継する通信パケットは、ＩＰｖ４のＵＤＰパケットであって、
   上記ＩＰｓｅｃパケット判定手段は、上記パケット中継手段が中継するＩＰｖ４のＵＤＰパケットの送信先及び送信元のポート番号と、ＩＰｓｅｃパケットの中継の際に用いられるポート番号とが一致する場合に、当該通信パケットがＩＰｓｅｃパケットであると判定することを特徴とする請求項１に記載の中継装置。
3. 上記パケット中継手段が中継する通信パケットは、ＩＰｖ４のＵＤＰパケットであって、
   上記ＩＰｓｅｃパケット判定手段は、上記パケット中継手段が中継する通信パケットのＵＤＰチェックサムフィールドの値がゼロである場合に、当該通信パケットがＩＰｓｅｃパケットであると判定することを特徴とする請求項１または２に記載の中継装置。
4. 上記ＩＰｓｅｃパケット判定手段は、上記パケット中継手段が中継する通信パケットのヘッダの値が、当該通信パケットがＩＰｓｅｃパケットであることを示している場合に、当該通信パケットがＩＰｓｅｃパケットであると判定することを特徴とする請求項１に記載の中継装置。
5. 上記ＩＰｓｅｃパケット判定手段は、上記パケット中継手段が中継する通信パケットのペイロード長が、予め定めたＩＰｓｅｃパケットのペイロード長の下限値以上、かつ、上限値以下である場合に、該通信パケットがＩＰｓｅｃパケットであると判定することを特徴とする請求項１から４の何れか１項に記載の中継装置。
6. 上記再起動制御手段は、上記ＩＰｓｅｃパケット判定手段が、上記パケット中継手段が中継する通信パケットがＩＰｓｅｃパケットであると判定した後の一定時間Ｔの間は、再起動を行わないように制御することを特徴とする請求項１から５の何れか１項に記載の中継装置。
7. 上記一定時間Ｔは、上記パケット中継手段がＩＰｓｅｃパケットを受信する、予め定められた一定の時間間隔ｔ１の自然数倍であることを特徴とする請求項６に記載の中継装置。
8. 上記一定時間Ｔは、連続して受信される通信パケットが一連の通話データを構成する通信パケットであるか否かを判定する基準として予め定められた基準時間ｔ２より大きいことを特徴とする請求項６に記載の中継装置。
9. 上記パケット中継手段は、受信時間ｔ３の間通信パケットを受信し、その後送信時間ｔ４の間に通信パケットの送信を行う処理の繰り返しによって通信パケットの中継を行い、
   上記一定時間Ｔは、上記受信時間ｔ３と送信時間ｔ４との和の自然数倍であることを特徴とする請求項６に記載の中継装置。
10. 自装置が接続されているＷＡＮから通信パケットを受信するＷＡＮ通信部を備え、
    上記ＩＰｓｅｃパケット判定手段は、上記ＷＡＮ通信部から受信した通信パケットをＩＰｓｅｃパケットであると判定しないことを特徴とする請求項１から９の何れか１項に記載の中継装置。
11. 通信パケットの中継を行うと共に、所定のタイミングで再起動を行う中継装置の中継方法であって、
    上記通信パケットの中継を行うパケット中継ステップと、
    上記パケット中継ステップにおいて中継される上記通信パケットが、ＩＰｓｅｃプロトコルによって暗号化された通信パケットであるＩＰｓｅｃパケットであるか否かを判定するＩＰｓｅｃパケット判定ステップと、
    上記ＩＰｓｅｃパケット判定ステップにおいて、上記パケット中継ステップにおいて中継される通信パケットがＩＰｓｅｃパケットであると判定したときに、再起動を行わないように制御する再起動制御ステップとを含むことを特徴とする中継方法。
12. 請求項１から１０の何れか１項に記載の中継装置を動作させるための中継プログラムであって、コンピュータを上記各手段として機能させるための中継プログラム。
13. 請求項１２に記載の中継プログラムを記録したコンピュータ読み取り可能な記録媒体。

Images