JP6007974B2 - 通信システム及び経路制御方法 - Google Patents

Description

本発明は通信システムに関し、特に障害発生時に経路制御を行う通信システムに関する。

近年、仮想化技術を活用したサーバ統合（仮想サーバ）や、クラウド化が急速に進展している。これに伴い、ストレージ装置の拡張及びストレージ装置間のリソースの移動等の対応が進められている。しかし、ユーザが使用する通信端末と仮想サーバとの間を接続するネットワークの運用はいまだに高度な知識や技術等が必要とされる。そのため、ネットワークの運用を簡素化することができる装置の開発が望まれている。

そこで、ネットワークの運用を簡素化するために用いられる技術の一つとしてＯｐｅｎＦｌｏｗに関する技術が検討されている。ＯｐｅｎＦｌｏｗは、ＯｐｅｎＦｌｏｗコンソーシアムにより標準スペックが策定される技術である。ＯｐｅｎＦｌｏｗを用いたネットワークにおいては、ＯｐｅｎＦｌｏｗコントローラを用いてネットワークを集中制御することによって、ネットワークの運用を簡素化する。さらに、ＯｐｅｎＦｌｏｗを用いたネットワークにおいては、フロー単位で経路制御を行うことにより、柔軟なルーティングを実現することができるため、耐障害性を高めることができる。

特許文献１には、データ転送を行うスイッチ群と、プロトコル種別や、ポート番号等の情報を保持するフローテーブルをスイッチ群に設定するコントローラとから構成されるＯｐｅｎＦｌｏｗを利用したコンピュータシステムの構成が開示されている。

特開２０１１−１６０３６３号公報

３ＧＰＰ標準化団体などで規定される現在の携帯電話システムは、一般的なＩＰネットワーク技術を携帯電話パケット網に適用して、データ通信サービスを携帯電話ユーザに提供している。また、携帯電話システムは、現在社会インフラの一部として認識されており、安定したサービスの提供が強く求められている。そこで、現在の携帯電話システムに、フロー単位で経路制御を行うネットワーク技術を導入することにより、携帯電話システム内の装置故障及び輻輳等に起因するサービスの中断を回避することが考えられる。しかし、携帯電話システムにおいてフロー単位で経路制御を行うネットワーク技術の導入する方法については明示的に検討が行われていないため、フロー単位で経路制御を行うネットワーク技術を用いた携帯電話システムの構成を明確にすることが求められている。

本発明は、このような課題を解決するために、通信システム内の装置故障、装置輻輳、装置増設、装置減設及び装置メンテナンス等に起因するサービスの中断を回避することができる通信システム及び経路制御方法を提供することを目的とする。

本発明の第１の態様にかかる通信システムは、データ転送装置と、前記データ転送装置と通信を行っている第１のゲートウェイと、前記第１のゲートウェイの代替装置である第２のゲートウェイと、前記データ転送装置と、前記第１及び第２のゲートウェイとの間の通信経路を制御する経路制御手段と、を備える通信システムであって、前記経路制御手段は、前記第１のゲートウェイにおける障害状態を検出した場合、前記データ転送装置から前記第１のゲートウェイへ転送されるデータを前記第２のゲートウェイへ転送するように前記データ転送装置を制御するとともに、前記第１のゲートウェイに設定されているセッション情報を前記第２のゲートウェイへ通知するように構成されるものである。

本発明の第２の態様にかかる経路制御方法は、データ転送装置と通信を行っている第１のゲートウェイにおける障害状態を検出し、前記データ転送装置から前記第１のゲートウェイへ転送されるデータを前記第１のゲートウェイの代替装置である第２のゲートウェイへ転送させるとともに、前記第１のゲートウェイに設定されているセッション情報を前記第２のゲートウェイへ通知するものである。

本発明により、通信システム内の装置故障、装置輻輳、装置増設、装置減設及び装置メンテナンス等に起因するサービスの中断を回避することができる通信システム及び経路制御方法を提供することができる。

実施の形態１にかかる通信システムの構成図である。 実施の形態１にかかる通信システム内における故障の発生を示す図である。 実施の形態１にかかるルーティングテーブルを説明する図である。 実施の形態１にかかる通信システム内における故障の発生を示す図である。 実施の形態１にかかる通信システム内における故障の発生を示す図である。 実施の形態１にかかる通信システム内における故障の発生を示す図である。 実施の形態１にかかるベアラー設定処理に関するシーケンスである。 実施の形態１にかかるベアラー設定処理に関するシーケンスである。 実施の形態１にかかる通信システム内の故障発生に関するシーケンスである。 実施の形態１にかかる通信システム内の故障発生に関するシーケンスである。 実施の形態１にかかる通信システム内の故障復旧に関するシーケンスである。 実施の形態１にかかる通信システム内の故障復旧に関するシーケンスである。 実施の形態１にかかる通信システム内の故障復旧に関するシーケンスである。 実施の形態２にかかる通信システム内における輻輳の発生を示す図である。 実施の形態２にかかるルーティングテーブルを説明する図である。 実施の形態２にかかる通信システム内の輻輳発生に関するシーケンスである。 実施の形態２にかかる通信システム内の輻輳発生に関するシーケンスである。 実施の形態２にかかる通信システム内の輻輳発生に関するシーケンスである。 実施の形態２にかかる通信システム内の輻輳発生に関するシーケンスである。 実施の形態２にかかる通信システム内の輻輳発生に関するシーケンスである。 実施の形態２にかかる通信システム内の輻輳発生に関するシーケンスである。 実施の形態２にかかる通信システム内の輻輳復旧に関するシーケンスである。 実施の形態２にかかる通信システム内の輻輳復旧に関するシーケンスである。 実施の形態２にかかる通信システム内の輻輳復旧に関するシーケンスである。 実施の形態３にかかる通信システム内における故障の発生を示す図である。 実施の形態３にかかる通信システム内における故障の発生を示す図である。 実施の形態３にかかる通信システム内における故障の発生を示す図である。 実施の形態３にかかる通信システム内の故障発生に関するシーケンスである。 実施の形態３にかかる通信システム内の故障発生に関するシーケンスである。 実施の形態３にかかる通信システム内の故障復旧に関するシーケンスである。 実施の形態３にかかる通信システム内の故障復旧に関するシーケンスである。 実施の形態３にかかる通信システム内の故障復旧に関するシーケンスである。 実施の形態４にかかる通信システム内における輻輳の発生を示す図である。 実施の形態４にかかる通信システム内の輻輳発生に関するシーケンスである。 実施の形態４にかかる通信システム内の輻輳発生に関するシーケンスである。 実施の形態４にかかる通信システム内の輻輳発生に関するシーケンスである。 実施の形態４にかかる通信システム内の輻輳発生に関するシーケンスである。 実施の形態４にかかる通信システム内の輻輳発生に関するシーケンスである。 実施の形態４にかかる通信システム内の輻輳発生に関するシーケンスである。 実施の形態４にかかる通信システム内の輻輳復旧に関するシーケンスである。 実施の形態４にかかる通信システム内の輻輳復旧に関するシーケンスである。 実施の形態４にかかる通信システム内の輻輳復旧に関するシーケンスである。 ３ＧＰＰにおいて規定されているｅＵＴＲＡＮ（evolved UTRAN） ａｃｃｅｓｓに関する通信ネットワークの全体構成である。 ３ＧＰＰにおいて規定されているＵＴＲＡＮ ｗｉｔｈ ＥＰＣ ｄｉｒｅｃｔ ｔｕｎｎｅｌｉｎｇ ｍｏｄｅｌに関する通信ネットワークの全体構成である。 ３ＧＰＰにおいて規定されているＵＴＲＡＮ ａｃｃｅｓｓ ｗｉｔｈ ＥＰＣに関する通信ネットワークの全体構成である。 ３ＧＰＰにおいて規定されているＵＴＲＡＮ ａｃｃｅｓｓ ｗｉｔｈ ＧＰＲＳに関する通信ネットワークの全体構成である。 本発明の適用例を示す図である。 本発明の適用例を示す図である。

（実施の形態１）
以下、図面を参照して本発明の実施の形態について説明する。本発明は、ＯｐｅｎＦｌｏｗ、ＶＸＬＡＮ、ＮＶＧＲＥ、ＤＯＶＥ、Ｃｉｓｃｏ ＮＥＸＵＳ、Ｊｕｎｉｐｅｒ ＱＦａｂｒｉｃ（登録商標）等に適用することが可能である。下記の実施の形態においては、主にＯｐｅｎＦｌｏｗを用いた例について説明する。

はじめに、図４３を用いて、３ＧＰＰにおいて規定されているｅＵＴＲＡＮ（evolved UTRAN） ａｃｃｅｓｓに関する通信ネットワークの全体構成について説明する。通信ネットワークは、ＥＰＳ１００と、Ｅｘｔｅｒｎａｌ ｎｅｔｗｏｒｋ２００とから構成される。ＥＰＳ１００は、ｅＮＢ１０１〜１０４と、ＦＲ１０５〜１０７と、ＳＧＷ１０８〜１１１と、ＦＣ／ＭＭＥ１１２と、ＦＲ１１３〜１１５と、ＰＧＷ１１６〜１１７と、ＦＣ／ＰＣＲＦ１１８とを備えている。Ｅｘｔｅｒｎａｌ ｎｅｔｗｏｒｋ２００は、ＦＲ（Flexible Router）２０１〜２０３と、ＴＤＦ（Traffic Detection Function）２０４〜２０７と、Ｓｅｒｖｉｃｅ ｓｅｒｖｅｒ２０８〜２０９とを備えている。

ＦＲ１０５〜１０７は、ｅＮＢ１０１〜１０４と、ＳＧＷ１０８〜１１１との間の通信を中継する。さらに、ＦＲ１１３〜１１５は、ＳＧＷ１０８〜１１１と、ＰＧＷ１１６〜１１７との間の通信を中継する。ここで、ＦＲは、ＯｐｅｎＦｌｏｗを用いたシステムにおいて用いられる通信装置であり、例えば、ＦＣ／ＭＭＥ１１２や、ＦＣ／ＰＣＲＦ１１８において制御されるスイッチやルータ等であってもよい。

ＦＣ／ＭＭＥ１１２は、ＦＲ１０５〜１０７における経路制御を行う。つまり、ｅＮＢ１０１〜１０４とＳＧＷ１０８〜１１１との間の通信経路を設定する。また、ＦＣ／ＭＭＥ１１２は、ＦＣとＭＭＥとが連携して動作することを示している。

ＦＣ／ＰＣＲＦ１１８は、ＦＲ１１３〜１１５における経路制御を行う。つまり、ＳＧＷ１０８〜１１１とＰＧＷ１１６〜１１７との間の通信経路を設定する。また、ＦＣ／ＰＣＲＦ１１８は、ＦＣとＰＣＲＦとが連携して動作することを示している。

続いて、Ｅｘｔｅｒｎａｌ ｎｅｔｗｏｒｋ２００の構成例について説明する。ＦＲ２０１〜２０３は、ＰＧＷ１１６〜１１７と、ＴＤＦ２０４〜２０７との間の通信を中継する。また、ＦＲ２０１〜２０３は、ＦＣ／ＰＣＲＦ１１８を用いて経路制御が行われる。つまり、ＦＣ／ＰＣＲＦ１１８は、ＰＧＷ１１６〜１１７と、ＴＤＦ２０４〜２０７との間の通信経路を設定する。

Ｓｅｒｖｉｃｅ ｓｅｒｖｅｒ２０８〜２０９は、ＴＤＦ２０４〜２０７を介して送信されたデータを受け取り、サービスを実行する。

通信ネットワーク内の各構成要素については、図２以降において説明を行う。

続いて、図４４を用いて、３ＧＰＰにおいて規定されているＵＴＲＡＮ ｗｉｔｈ ＥＰＣ ｄｉｒｅｃｔ ｔｕｎｎｅｌｉｎｇ ｍｏｄｅｌに関する通信ネットワークの全体構成について説明する。図４４においては、図４３のｅＮＢ１０１〜１０４の代わりに、ＲＮＣ１２１〜１２４が用いられている。さらに、ＦＣ／ＭＭＥ１１２の代わりに、ＦＣ／ＳＧＳＮ１３１が用いられている。その他の構成については、図４３と同様である。

続いて、図４５を用いて、３ＧＰＰにおいて規定されているＵＴＲＡＮ ａｃｃｅｓｓ ｗｉｔｈ ＥＰＣに関する通信ネットワークの全体構成について説明する。図４５においては、図４４のＦＲ１０５〜１０７と、ＦＲ１１３〜１１５との間に、ＳＧＷ１０８〜１１１の代わりに、ＦＣ／ＳＧＳＮ１３２が用いられている。ＦＣ／ＳＧＳＮ１３２は、ＦＲ１０５〜１０７の経路制御を行う。また、ＦＲ１０５〜１０７は、ＲＮＣ１２１〜１２４から送信された制御信号をＦＣ／ＳＧＳＮ１３２へ送信する。それ以外の構成については、図４３及び４４と同様である。

続いて、図４６を用いて、３ＧＰＰにおいて規定されているＵＴＲＡＮ ａｃｃｅｓｓ ｗｉｔｈ ＧＰＲＳに関する通信ネットワークの全体構成について説明する。図４６においては、ＰＧＷ１１６〜１１７の代わりに、ＧＧＳＮ１５１〜１５２が用いられる。

また、図４３〜４６以外の構成として、ＲＮＣ１２１〜１２４の代わりに、ＢＳＣ（Base Station Controller）を用いることによって、いわゆる２Ｇシステムへ本発明を適用することも可能である。

次に、図１を用いて本発明の実施の形態１にかかる通信システムの構成例について説明する。図１の通信システムは、データ転送装置１１と、ゲートウェイ１２及び１３と、経路制御装置１４とを備えている。
データ転送装置１１は、データを中継する装置であり、例えば、ＩＰアドレスを用いてデータを転送するルータや、ＭＡＣアドレス等を用いてデータを転送するＬ２スイッチ等であってもよい。

ゲートウェイ１２は、データ転送装置１１と通信を行っている装置である。つまり、実際にデータ転送装置１１との間でデータの送受信を行っている装置である。さらに、ゲートウェイ１３は、ゲートウェイ１２の代替装置である。つまり、ゲートウェイ１２に障害等が発生した場合に、ゲートウェイ１３は、データ転送装置１１からゲートウェイ１２宛のデータを受け取り、データ処理を行う。ゲートウェイ１３は、ゲートウェイ１２に障害等が発生していない場合には、動作していても停止していてもよい。

経路制御装置１４は、データ転送装置１１及びゲートウェイ、並びに、データ転送装置１１及びゲートウェイ１３との間の通信経路を制御する。例えば、経路制御装置１４は、データ転送装置１１におけるデータの転送先を、ゲートウェイ１２又は１３を指定して通信経路を定めてもよい。ここで、経路制御装置１４の具体的な動作について説明する。

経路制御装置１４は、ゲートウェイ１２における障害状態を検出した場合、データ転送装置１１からゲートウェイ１２へ転送されるデータをゲートウェイ１３へ経路変更するようにデータ転送装置１１を制御するとともに、ゲートウェイ１２に設定されているセッション情報をゲートウェイ１３へ通知する。

ゲートウェイ１２における障害状態とは、ゲートウェイ１２の故障、輻輳及びデータ転送装置１１とゲートウェイ１２との間の経路障害などである。つまり、障害状態は、ゲートウェイ１２においてデータ処理を行うことができなくなる状態や、ゲートウェイ１２が高負荷状態となり、データ処理を行うことが困難となる状態等を含む。

セッション情報は、ベアラー情報を含む。さらに、セッション情報には、制御信号情報等が含まれてもよい。ベアラー情報とは、例えば、通信端末と、ゲートウェイ１２もしくは１３とがデータの送受信を行うために設定されているコネクション情報である。通信端末は、携帯電話端末等の移動通信端末や、ＭＴＣ（Machine Type Communication）に用いられる端末を含む。制御信号情報とは、ベアラーを設定するために用いられる信号等であってもよい。

以上説明したように、図１の通信システムにおいては、ゲートウェイ１２に障害が発生した場合においても、経路制御装置１４を用いることにより、ゲートウェイ１２に送信されているデータを代替装置であるゲートウェイ１３へ送信するように切り替えることができる。さらに、データ経路を切り替えるのみではなく、ゲートウェイ１２に設定されているセッション情報をゲートウェイ１３へ通知することができる。これにより、ゲートウェイ１２に障害が発生した場合においても、ゲートウェイ１２において実行されていたデータ処理をゲートウェイ１３においても実行することができる。そのため、通信システム内に障害が発生した場合においても、代替装置を用いることにより、障害発生前と同様のサービスを提供することができる。

続いて、図２を用いて通信システム内における故障の発生について説明する。図２は、ＥＰＳ（Evolved Packet System）２０と、Ｅｘｔｅｒｎａｌ ｎｅｔｗｏｒｋ４０とを用いて通信が行われる構成を示している。ＥＰＳ２０は、ＬＴＥ（Long Term Evolution）、Ｗ−ＣＤＭＡ（Wideband Code Division Multiple Access）、ＧＥＲＡＮ(GSM(登録商標) EDGE Radio Access Network)、およびＷｉＦｉ（登録商標）などに代表されるＮｏｎ−３ＧＰＰアクセスなどで実現される無線通信と、ＥＰＣ（Evolved Packet Core）で提供される柔軟なコアネットワークとで構成される。ＬＴＥ、Ｗ−ＣＤＭＡ、ＧＥＲＡＮ及びＥＰＣは、３ＧＰＰの技術仕様書において規定されている。Ｅｘｔｅｒｎａｌ ｎｅｔｗｏｒｋ４０は、ＥＰＳ２０とは異なるＰａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ（ＰＤＮ）であり、例えば、ＥＰＳ２０を運用している事業者とは異なる事業者によって運用されているネットワークである。例えば、Ｅｘｔｅｒｎａｌ ｎｅｔｗｏｒｋ４０は、インターネットプロバイダが運用しているネットワーク等であってもよい。

ＥＰＳ２０は、ＳＧＷ（Serving GW）２１と、Ｒｏｕｔｅｒ２２と、ＰＧＷ（Packet data network GW）２３及び２４と、ＦＣ（Flow Controller）２５と、ＰＣＲＦ（Policy and Charging Rules Function）２６とを備えている。Ｅｘｔｅｒｎａｌ ｎｅｔｗｏｒｋ４０は、Ｒｏｕｔｅｒ４１と、ＴＤＦ（Traffic Data Function）４２と、Ｓｅｒｖｉｃｅ ｓｅｒｖｅｒ４３とを備えている。

ＳＧＷ２１は、３ＧＰＰにおいていわゆる３Ｇシステムと称されているシステムと、ＬＴＥシステムとのＵ−Ｐｌａｎｅ（ユーザトラヒック）を収容する論理ノードである。３Ｇシステムは、無線方式として主にＷ−ＣＤＭＡ技術を用いている。

ＳＧＷ２１は、ＵＥから送信されたユーザトラヒックを、Ｒｏｕｔｅｒ２２を介してＰＧＷ２３もしくはＰＧＷ２４へ送信する。ユーザトラヒックには、宛先アドレスとして、ＰＧＷ２３に割り当てられているＩＰアドレス＃ＡもしくはＰＧＷ２４に割り当てられているＩＰアドレス＃Ｂが設定されている。Ｒｏｕｔｅｒ２２は、宛先アドレスと転送先の装置とが関連付けられているルーティングテーブルを用いて、ＳＧＷ２１から送信されたユーザトラヒックをＰＧＷ２３もしくはＰＧＷ２４へ転送する。本図においては、ＰＧＷ２３に障害が発生する前のユーザトラヒックは、ＰＧＷ２３に転送されていることを示している。

ＰＧＷ２３及びＰＧＷ２４は、ＥＰＳ２０とＥｘｔｅｒｎａｌ ｎｅｔｗｏｒｋ４０とのインタフェース機能を有する論理ノードである。つまり、ＥＰＳ２０内の通信装置とＥｘｔｅｒｎａｌ ｎｅｔｗｏｒｋ４０内の通信装置等との間におけるデータの送受信は、ＰＧＷ２３もしくは２４を介しておこなわれる。

ＦＣ２５は、ＥＰＳ２０内において、伝送される経路をフロー単位で決定し、決定した経路をＲｏｕｔｅｒ２２へ通知する。Ｒｏｕｔｅｒ２２は、ＦＣ２５より通知された経路情報に従ってデータ転送を行う。また、ＦＣ２５は、Ｅｘｔｅｒｎａｌ ｎｅｔｗｏｒｋ４０内についても、伝送される経路をフロー単位で決定してもよい。この場合、ＦＣ２５は、決定した経路をＲｏｕｔｅｒ４１へ通知する。ここで、フローとは、Ｌ１（物理ポート等）、Ｌ２（ＭＡＣ）、Ｌ３（ＩＰ）、Ｌ４（ポート番号）の各レイヤの任意のアドレスもしくは、Ｌ１（物理ポート等）、Ｌ２（ＭＡＣ）、Ｌ３（ＩＰ）、Ｌ４（ポート番号）の各レイヤの任意のアドレスおよびフロー制御のための識別子の組み合わせで特定される通信トラヒックである。さらに、フロー単位とは、ＩＰアドレス及び識別子として用いられるＴＥＩＤ(Tunnel Endpoint Identifier)により定まるＥＰＳベアラー毎もしくは複数のＥＰＳベアラーの組み合わせ等であってもよい。さらに、フロー単位とは、加入者（ＵＥ）毎もしくはサービス毎等であってもよい。

ＦＣ２５は、特定のルールに従って各レイヤの任意のアドレスもしくは識別子を組み合わせることによって通信トラヒックを特定する。ＦＣ２５において決定された経路であって、Ｒｏｕｔｅｒ２２及びＲｏｕｔｅｒ４１へ通知する経路情報をルーティングポリシーと称する。

さらに、ＦＣ２５は、通信端末と、ＰＧＷ２３もしくは２４との間に設定されるベアラー情報及び制御信号情報等を含むセッション情報を保持してもよい。例えば、ベアラー情報には、通信端末に割り当てるＩＰアドレスや、ＴＥＩＤ、ＱｏＳ情報等が含まれる。制御信号情報は、例えば、ベアラー情報を設定するために用いられる信号等である。ＦＣ２５は、ベアラー情報及び制御情報を、ＰＧＷ２３及び２４へ通知する。

ＰＧＷ２３、およびＰＧＷ２４は、課金情報等を生成する論理ノードである。

Ｒｏｕｔｅｒ４１は、ＰＧＷ２３もしくは２４から送信されたデータを、ＴＤＦ４２を介してＳｅｒｖｉｃｅ ｓｅｒｖｅｒ４３へ送信する。もしくは、Ｒｏｕｔｅｒ４１は、ＴＤＦ４２を介してＳｅｒｖｉｃｅ ｓｅｒｖｅｒ４３から送信されたデータをＰＧＷ２３もしくは２４へ送信する。Ｓｅｒｖｉｃｅ ｓｅｒｖｅｒ４３は、Ｅｘｔｅｒｎａｌ ｎｅｔｗｏｒｋ４０内に配置されているサーバ装置であって、例えば、Ｗｅｂサーバや、動画データを保持するストレージ装置等であってもよい。

本図においては、ＰＧＷ２３に故障が発生した場合に、ＵＥから送信されたユーザトラヒックについて、Ｒｏｕｔｅｒ２２が、ＰＧＷ２３宛のデータをＰＧＷ２４へ経路変更すること、およびサービスサーバ４３から送信されたユーザトラヒックについて、Ｒｏｕｔｅｒ４１が、ＰＧＷ２３宛のデータをＰＧＷ２４へ経路変更することを示している。また、本図においては、ＰＧＷが２つである場合の動作について示しているが、ＰＧＷが３つ以上の場合においても同様に本発明を適用することができる。

ここで、図３を用いて、Ｒｏｕｔｅｒ２２の保持するルーティングテーブルに設定される情報（ルーティングポリシー）について説明する。ルーティングテーブルは、ＩＰアドレス情報（IP address）と、宛先情報（Destination）とから構成されている。たとえば、ＩＰアドレス＃Ａと、ＰＧＷ２３と、が対応付けられており、ＩＰアドレス＃Ｂと、ＰＧＷ２４とが対応付けられている。

その後、ＰＧＷ２３に故障が発生した場合に、ＩＰアドレス＃Ａと、ＰＧＷ２４と、が対応付けられるように更新される。これにより、Ｒｏｕｔｅｒ２２は、ＰＧＷ２３に故障が発生した後、宛先アドレスとしてＩＰアドレス＃Ａが設定されているデータを、ＰＧＷ２４へ送信する。なお、Ｒｏｕｔｅｒ２２は、ＰＧＷ２３に故障が発生した後、ＦＣ２５から通知される経路情報に基づいて、ルーティングテーブルの設定情報を更新する。

さらに、ＰＧＷ２３に故障が発生した場合に、ＦＣ２５は、ＰＧＷ２４に対して、ＰＧＷ２３において設定されていたベアラー情報や、制御信号情報等を含むセッション情報を通知する。本図においては、ＦＣ２５とＰＣＲＦ２６とが連携して動作していることを示している。ＦＣ２５とＰＣＲＦ２６とは、同一の装置として構成されてもよく、異なる装置として構成されてもよい。ＦＣ２５とＰＣＲＦ２６とが連携して動作することにより、ＰＧＷ２３に故障が発生し、ＰＧＷ２４に切り替えられた場合においても、ＰＧＷ２４には、ベアラー情報などが引き継がれるため継続して課金情報の収集が可能となる。これにより、ＰＧＷ２４に引き継がれたベアラ−情報に関して、ＰＧＷ２３において発生した課金情報と、ＰＧＷ２４において発生した課金情報とを合わせた課金情報を生成することができる。

ＦＣ２５とＰＣＲＦ２６が同一の装置として構成された場合には、ＦＣ２５が提供するフロー制御とＰＣＲＦ２６が提供するポリシィおよび課金制御とを同一装置内で連携することで処理の高速化が図れ、装置切り替えによるサービス性の劣化（サービスの瞬断など）を防ぐ事が可能となる。

続いて、図４を用いて、図２と異なる通信システム内における故障の発生について説明する。図４においては、ＳＧＷ２１の代わりに、Ｎｏｎ ３ＧＰＰ ａｃｃｅｓｓ３１が用いられている。その他の構成については図２と同様である。

ＰＧＷ２３及び２４は、Ｅｘｔｅｒｎａｌ ｎｅｔｗｏｒｋ４０とのインタフェース機能を有する論理ノードであって、その機能は３ＧＰＰの技術仕様書に規定されている。例えば、ＰＧＷ２３及び２４は、ＧＴＰ（GPRS Tunneling Protocol）、またはＰＭＩＰ(Proxy Mobile IP)を用いて転送されたパケットデータであって、Ｎｏｎ ３ＧＰＰ ａｃｃｅｓｓ３１からＲｏｕｔｅｒ２２を介して転送されたパケットデータをＥｘｔｅｒｎａｌ ｎｅｔｗｏｒｋ４０へ送信する。本図においては、ＰＧＷ２３に故障が発生した場合に、Ｒｏｕｔｅｒ２２がＰＧＷ２３宛のデータをＰＧＷ２４へ経路変更することを示している。Ｒｏｕｔｅｒ２２におけるルーティングテーブルの更新処理等は、図２及び図３と同様であるため詳細な説明を省略する。

続いて、図５を用いて、図２及び図４と異なる通信システム内における故障の発生について説明する。図５においては、ＳＧＷ２１の代わりにＳＧＳＮ２９が用いられている。さらに、ＰＧＷ２３及びＰＧＷ２４の代わりにＧＧＳＮ２７及び２８が用いられている。その他の構成については、図４と同様である。ＳＧＳＮ２９は、主に３ＧＰＰの技術仕様書に規定されている３Ｇシステムに用いられる無線アクセスシステムと接続され、Ｕ−Ｐｌａｎｅデータ及びＣ−Ｐｌａｎｅデータについてデータ処理を行う。ＧＧＳＮ２７及び２８は、Ｅｘｔｅｒｎａｌ ｎｅｔｗｏｒｋ４０とのインタフェース機能を有する論理ノードであって、その機能は３ＧＰＰ技術仕様書に規定されている。本図においては、ＧＧＳＮ２７に故障が発生した場合に、Ｒｏｕｔｅｒ２２がＧＧＳＮ２７宛のデータをＧＧＳＮ２８へ経路変更することを示している。Ｒｏｕｔｅｒ２２におけるルーティングテーブルの更新処理等は、図２及び図３と同様であるため詳細な説明を省略する。

続いて、図６を用いて、図２、図４及び図５と異なる通信システム内における故障の発生について説明する。図６においては、ＳＧＷ２１の代わりにＲＮＣ３０が用いられている。その他の構成については、図５と同様である。ＲＮＣ３０は、主に３Ｇシステムにおいて用いられる基地局を制御する。例えば、ＲＮＣ３０は、基地局間におけるハンドオーバ制御等を行う。本図においては、図５と同様に、ＧＧＳＮ２７に故障が発生した場合に、Ｒｏｕｔｅｒ２２がＧＧＳＮ２７宛のデータをＧＧＳＮ２８へ経路変更することを示している。Ｒｏｕｔｅｒ２２におけるルーティングテーブルの更新処理等は、図２及び図３と同様であるため詳細な説明を省略する。また、ＲＮＣ３０の代わりに、ＢＳＣ（Base Station Controller）を用いることによって、いわゆる２Ｇシステムへ本発明を適用することも可能である。

続いて、図７を用いてベアラー設定処理の流れについて説明する。はじめに、ＵＥ（User Equipment）は、ＰＧＷとの間のパスを確立するために、ＰＧＷ２３へEstablish IP CAN bearer requestを送信する（Ｓ１１）。ＵＥは、例えば、３ＧＰＰのシステムにおいて用いられる移動通信装置等を示す呼称である。次に、ＰＧＷ２３は、ポリシー情報等を得るために、ＰＣＲＦ２６へPCC rule request(CCR)を送信する（Ｓ１２）。ＰＣＣとは、Policy and Charging Controlの略称である。ここで、ＰＣＲＦ２６は、ＦＣ２５と連携して動作している。そのため、本図以降の説明においては、ＦＣ２５とＰＣＲＦ２６とを同一のノード装置として説明を行う。

次に、ＰＣＲＦ２６は、ＰＧＷ２３にＰＣＣルールを設定するために、ＰＧＷ２３へPCC rule answer(CCA)を送信する（Ｓ１３）。次に、ＰＧＷ２３は、ＰＧＷ２３において設定するＰＣＣルールに対応するベアラー情報及び制御信号情報を通知するために、PCC rule update(CCR)を送信する（Ｓ１４）。ＰＣＣルールは、ベアラー毎に設定される帯域等のポリシー情報と課金情報等を規定する。ベアラー情報には、例えば、ＵＥに割り当てるＩＰアドレス、ＴＥＩＤ（Tunnel Endpoint Identifier）及びＱｏＳパラメータ等が含まれる。さらに、制御信号情報には、例えば、ＵＥに割り当てるＩＰアドレス、ＴＥＩＤ−Ｃ、自ノードのリスタートカウンター及び対応ノードのリスタートカウンター等が含まれる。ＴＥＩＤは、ＵＥとＰＧＷ２３との間に設定されるユーザデータ伝送用のトンネルを識別する識別子である。また、ＴＥＩＤ−Ｃは、Ｃ−Ｐｌａｎｅ上で用いられるトンネルの識別子である。

ＰＣＲＦ２６は、PCC rule update(CCR)に設定されているベアラー情報及び制御信号情報等を記録する。ここで、ＰＣＲＦ２６は、ベアラー情報及び制御信号情報等を、ポリシールールとして記録してもよい。

ＰＣＲＦ２６は、PCC rule update(CCR)に対する応答信号として、PCC rule answer(CCA)をＰＧＷ２３へ送信する（Ｓ１５）。この動作の結果、ＵＥとＰＧＷ２３との間でベアラが確立される（Ｓ１６）。

続いて、図８を用いてＥｘｔｅｒｎａｌ ｎｅｔｗｏｒｋ４０との間のベアラー設定処理の流れについて説明する。はじめに、Ｓｅｒｖｉｃｅ ｓｅｒｖｅｒ４３は、ＰＣＲＦ２６に対して、Session request(AAR)を送信する（Ｓ２１）。次に、ＰＣＲＦ２６は、Ｓｅｒｖｉｃｅ ｓｅｒｖｅｒ４３に対して、Session request(AAR)に対する応答として、Session request Answer(AAA)を送信する（Ｓ２２）。次に、ＰＣＲＦ２６は、ＰＧＷ２３にＰＣＣルールを送信するために、ＰＧＷ２３へPCC rule provision(RAR)を送信する（Ｓ２３）。次に、ＰＧＷ２３は、ＰＧＷ２３において設定するＰＣＣルールに対応するベアラー情報を通知するために、ＰＣＲＦ２６へPCC rule provision answer(RAA)を送信する（Ｓ２４）。ベアラー情報には、例えば、ＵＥに割り当てるＩＰアドレス、ＴＥＩＤ（Tunnel Endpoint Identifier）及びＱｏＳパラメータ等が含まれる。

ＰＣＲＦ２６は、PCC rule provision answer(RAA)に設定されているベアラー情報を記録する。ここで、ＰＣＲＦ２６は、ベアラー情報を、ポリシールールとして記録してもよい。この動作の結果、ＵＥとＰＧＷ２３との間でベアラーが確立される（Ｓ２５）。

次に、図９を用いて、ＰＣＲＦ２６がＰＧＷ２３の故障を検出した場合の処理の流れについて説明する。はじめに、ＰＣＲＦ２６は、ＰＧＷ２３の故障を検出する（Ｓ３１）。ＰＣＲＦ２６は、ＳＮＭＰ（Simple Network Management Protocol）又はＩＣＭＰ（Internet Control Message Protocol）等のネットワークマネジメントプロトコルを用いて、ＰＧＷ２３の故障を検出してもよい。もしくは、ＰＣＲＦ２６は、ＳＣＴＰ（Stream Control Transmission Protocol）のkeep alive機能を用いてＰＧＷ２３の故障を検出してもよい。

次に、ＰＣＲＦ２６は、ＰＧＷ２３の代替装置となるＰＧＷ２４においてデータ通信サービスを継続させるために、Redirection decision処理を開始する（Ｓ３２）。次に、ＰＣＲＦ２６は、ＰＧＷ２３に故障が発生することにより影響を受けるフローのポリシー情報をＰＧＷ２４へ通知するために、Install all policy rules for affected sessionをＰＧＷ２４へ通知する（Ｓ３３）。ポリシー情報にはセッション情報が含まれる。セッション情報には、PCCルール、ベアラー情報、制御信号情報及びOpenFlowルール等が含まれる。OpenFlowルールは、例えば、ＦＣ２５がOpenFlowコントローラとして動作し、Ｒｏｕｔｅｒ２２及び４１がOpenFlowコントローラを用いて制御されるOpenFlowスイッチ等である場合に適用される制御ルールである。次に、ＰＧＷ２４は、Install all policy rules for affected sessionに対する応答信号として、Install policy rule ackをＰＣＲＦ２４へ通知する（Ｓ３４）。

ここで、ステップＳ３３及びＳ３４は、ＰＧＷ２３との間にベアラーを確立しているＵＥ毎に実行されてもよく、複数のＵＥのポリシー情報をまとめて送信するためにバルクメッセージを用いて一括で実行されてもよい。バルクメッセージを用いることにより、ＵＥ毎にメッセージを送信する場合と比較して切り替え時間の短縮、処理量の低減及び処理負荷の削減を図ることができる。

次に、ＦＣ２５は、Ｒｏｕｔｅｒ２２に対してルーティングポリシーを通知するために、Routing policy updateを送信する（Ｓ３５）。Ｒｏｕｔｅｒ２２は、Routing policy updateを受信すると、図３において説明したように、ルーティングテーブルを更新する。具体的には、宛先ＩＰアドレスとしてＩＰアドレス＃Ａが設定されているユーザデータを、ＰＧＷ２４へ転送するようにルーティングテーブルを更新する。同様に、ＦＣ２５は、Ｒｏｕｔｅｒ４１に対してRouting policy updateを送信する（Ｓ３６）。

次に、Ｒｏｕｔｅｒ２２は、ＦＣ２５に対してRouting policy update ackを送信し（Ｓ３７）、Ｒｏｕｔｅｒ４１は、ＦＣ２５に対してRouting policy update ackを送信する（Ｓ３８）。

続いて、図１０を用いて、ＰＣＲＦ２６がＰＧＷ２３の故障を検出した場合の処理の流れについて図９とは異なる例について説明する。ステップＳ４１及びＳ４２は、図９のステップＳ３１及びＳ３２と同様であるため説明を省略する。

次に、ＦＣ２５は、Ｒｏｕｔｅｒ２２に対してRouting policy updateを送信する（Ｓ４３）。Ｒｏｕｔｅｒ２２は、Routing policy updateを受信すると、図３において説明したように、ルーティングテーブルを更新する。具体的には、宛先ＩＰアドレスとしてＩＰアドレス＃Ａが設定されているユーザデータを、ＰＧＷ２４へ転送するようにルーティングテーブルを更新する。同様に、ＦＣ２５は、Ｒｏｕｔｅｒ４１に対してRouting policy updateを送信する（Ｓ４４）。

次に、Ｒｏｕｔｅｒ２２は、ＦＣ２５に対してRouting policy update ackを送信し（Ｓ４５）、Ｒｏｕｔｅｒ４１は、ＦＣ２５に対してRouting policy update ackを送信する（Ｓ４６）。

次に、Ｒｏｕｔｅｒ２２におけるルーティングテーブルが更新された後に、ＰＧＷ２４に対して、宛先ＩＰアドレスとしてＩＰアドレス＃Ａが設定されたＵ−ＰｌａｎｅトラヒックもしくはＣ−Ｐｌａｎｅトラヒックが送信される（Ｓ４７）。次に、ＰＧＷ２４は、セッション情報を含むポリシー情報を受け取るために、ＰＣＲＦ２６に対してPolicy rule requestを送信する（Ｓ４８）。Policy rule requestには、ＰＧＷ２４が受信したフローに関するＩＭＳＩもしくはＩＰアドレスと、ＴＥＩＤもしくはＴＥＩＤ−Ｃとが含まれている。次に、ＰＣＲＦ２６は、ＰＧＷ２４に対して、セッション情報を含むInstall all policy rules for affected sessionを送信する（Ｓ４９）。

以上説明したように、図１０においては、図９と異なり、ＰＧＷ２３の故障を検出するとＲｏｕｔｅｒ２２及び４１のルーティングテーブルを更新し、その後、ＰＧＷ２４にデータが送信されると、ＰＧＷ２４に対してポリシー情報が通知される。このような順番で処理をすることにより、切替先のＰＧＷ２４において、全てのＵＥに関するベアラーを設定する必要はなく、データが送信されてきたベアラーのみをＰＧＷ２４に設定すればよい。これにより、ＰＧＷ２４において設定するベアラー数を減少させることが可能となり、切り替え時間の削減及びＰＧＷ２４における処理負荷の削減を図ることができる。

続いて、図１１を用いて、ＰＧＷ２３に発生した故障が復旧した場合の処理の流れについて説明する。はじめに、ＦＣ２５は、ＰＧＷ２３の故障が復旧したことを検出する（Ｓ５１）。たとえば、ＦＣ２５は、ＳＮＭＰや、ＩＣＭＰ等のネットワークマネジメントプロトコルを用いてＰＧＷ２３の故障が復旧したことを検出してもよい。

次に、ＦＣ２５は、ＰＧＷ２３が復旧したため、データ通信サービスを代替装置であるＰＧＷ２４からＰＧＷ２３へ切り替えるために、Redirection decision処理を開始する（Ｓ５２）。次に、ＰＣＲＦ２６は、ＰＧＷ２３へポリシー情報を通知するために、Re-Install all policy rules originally in PGW23をＰＧＷ２３へ通知する（Ｓ５３）。ポリシー情報には、PCC rule、ベアラー情報、制御信号情報及びOpen Flow rule等を含むセッション情報が含まれる。次に、ＰＧＷ２３は、Re-Install all policy rules originally in PGW23に対する応答信号として、Install policy rule ackをＰＣＲＦ２６へ通知する（Ｓ５４）。

ここで、ステップＳ５３及びＳ５４は、ＰＧＷ２３との間にベアラーを確立しているＵＥ毎に実行されてもよく、複数のＵＥのポリシー情報をまとめて送信するためにバルクメッセージを用いて一括で実行されてもよい。バルクメッセージを用いることにより、ＵＥ毎にメッセージを送信する場合と比較して切り替え時間の短縮、処理量の低減及び処理負荷の削減を図ることができる。

次に、ＦＣ２５は、Ｒｏｕｔｅｒ２２に対してRouting policy updateを送信する（Ｓ５５）。Ｒｏｕｔｅｒ２２は、Routing policy updateを受信すると、ルーティングテーブルを更新する。具体的には、宛先ＩＰアドレスとしてＩＰアドレス＃Ａが設定されているユーザデータを、ＰＧＷ２３へ転送するようにルーティングテーブルを更新する。同様に、ＦＣ２５は、Ｒｏｕｔｅｒ４１に対してRouting policy updateを送信する（Ｓ５６）。

次に、Ｒｏｕｔｅｒ２２は、ＦＣ２５に対してRouting policy update ackを送信し（Ｓ５７）、Ｒｏｕｔｅｒ４１は、ＦＣ２５に対してRouting policy update ackを送信する（Ｓ５８）。

次に、ＰＣＲＦ２６は、ＰＧＷ２３が復旧し、ＰＧＷ２４をＰＧＷ２３へ切り替えることによりＰＧＷ２４において不要となったセッションを削除するために、ＰＧＷ２４へRemove transferred sessionを送信する（Ｓ５９）。ＰＧＷ２４は、不要となったセッションを削除した後、Remove transferred session ackをＰＣＲＦ２６へ送信する（Ｓ６０）。

ここで、リスタートカウンタを用いた処理について説明する。現行のＧＴＰプロトコル使用においては、ＰＧＷは、ＳＧＷとの間でリスタートカウンターを定期的に通知し合っている。ＰＧＷ及びＳＧＷの一方は、自身に障害が発生し且つ障害から復旧すると、リスタートカウンタをインクリメントして通知する。ＰＧＷ及びＳＧＷの他方は、リスタートカウンタのインクリメントを検知すると、ＰＧＷ及びＳＧＷの一方に関するトンネルを削除する。一方、本発明にかかるＰＧＷ及びＳＧＷにおいては、障害から復旧したＰＧＷ及びＳＧＷは、既存のトンネルを維持するように制御される。つまり、障害から復旧したＰＧＷ及びＳＧＷは、誤ってトンネルを削除しないように、復旧した場合においてもリスタートカウンタをインクリメントさせないように動作する。

続いて、図１２を用いて、ＰＧＷ２３に発生した故障が復旧した場合の処理の流れについて図１１とは異なる例について説明する。はじめに、ＰＧＷ２３が復旧した場合、ＰＧＷ２３は、ＰＣＲＦ２６に対して、Recovery notificationを通知する（Ｓ６１）。

次に、ＰＣＲＦ２６は、ＰＧＷ２３にポリシー情報を通知するために、Re-Install all policy rules originally in PGW23をＰＧＷ２３へ通知する（Ｓ６２）。ポリシー情報には、PCC rule、ベアラー情報、制御信号情報及びOpen Flow rule等を含むセッション情報が含まれる。次に、ＰＧＷ２３は、Re-Install all policy rules originally in PGW23に対する応答信号として、Install policy rule ackをＰＣＲＦ２６へ通知する（Ｓ６３）。

ここで、ステップＳ６２及びＳ６３は、ＰＧＷ２３との間にベアラーを確立しているＵＥ毎に実行されてもよく、複数のＵＥのポリシー情報をまとめて送信するためにバルクメッセージを用いて一括で実行されてもよい。バルクメッセージを用いることにより、ＵＥ毎にメッセージを送信する場合と比較して切り替え時間の短縮、処理量の低減及び処理負荷の削減を図ることができる。

次に、ＰＣＲＦ２６は、ＰＧＷ２３へRecovery notificationの応答信号としてRecovery ackを送信する（Ｓ６４）。ステップＳ６５〜Ｓ７０の処理は、図１１におけるステップＳ５５〜Ｓ６０と同様であるため詳細な説明を省略する。

続いて、図１３を用いて、ＰＧＷ２３に発生した故障が復旧した場合の処理の流れについて図１１及び図１２とは異なる例について説明する。はじめに、ＰＣＲＦ２６は、ＰＧＷ２３の故障が復旧したことを検出する（Ｓ７１）。たとえば、ＦＣ２５は、ＳＮＭＰや、ＩＣＭＰ等のネットワークマネジメントプロトコルを用いてＰＧＷ２３の故障が復旧したことを検出してもよい。

次に、ＰＣＲＦ２６は、ＰＧＷ２３が復旧したため、データ通信サービスを代替装置であるＰＧＷ２４からＰＧＷ２３へ切り替えるために、Redirection decision処理を開始する（Ｓ７２）。

次に、ＦＣ２５は、Ｒｏｕｔｅｒ２２に対してRouting policy updateを送信する（Ｓ７３）。Ｒｏｕｔｅｒ２２は、Routing policy updateを受信すると、ルーティングテーブルを更新する。具体的には、宛先ＩＰアドレスとしてＩＰアドレス＃Ａが設定されているユーザデータを、ＰＧＷ２３へ転送するようにルーティングテーブルを更新する。同様に、ＦＣ２５は、Ｒｏｕｔｅｒ４１に対してRouting policy updateを送信する（Ｓ７４）。

次に、Ｒｏｕｔｅｒ２２は、ＦＣ２５に対してRouting policy update ackを送信し（Ｓ７５）、Ｒｏｕｔｅｒ４１は、ＦＣ２５に対してRouting policy update ackを送信する（Ｓ７６）。

次に、ＰＧＷ２３に対して、宛先ＩＰアドレスとしてＩＰアドレス＃Ａが設定されたＵ−ＰｌａｎｅトラヒックもしくはＣ−Ｐｌａｎｅトラヒックが送信される（Ｓ７７）。次に、ＰＧＷ２３は、宛先ＩＰアドレスとしてＩＰアドレス＃Ａが設定されたデータに関するポリシー情報を受け取るために、ＰＣＲＦ２６に対してPolicy rule requestを送信する（Ｓ７８）。Policy rule requestには、ＰＧＷ２３が受信したフローに関するＩＭＳＩもしくはＩＰアドレスと、ＴＥＩＤもしくはＴＥＩＤ−Ｃとが含まれている。ステップＳ７９の処理は、図１１のステップＳ５３の処理と同様であるため詳細な説明を省略する。さらに、ステップＳ８０及びＳ８１の処理は、図１１のステップＳ５９及びＳ６０の処理と同様であるため詳細な説明を省略する。

続いて、図４７を用いて、ネットワーク内の一部のＰＧＷまたはＧＧＳＮにおける障害耐性を強化するネットワーク構成について説明する。通常、ユーザがアクセスするサービスは、ＡＰＮ（Access Point Name）を指定することにより決定されるが、本図においては、警察、消防などの緊急通信を行う加入者には特別のＡＰＮを用いてＩＭＳシステム７７にアクセスすることを示している。なお、ＩＭＳシステムとは、音声サービスなどのテレフォニーサービスを提供するシステムである。

ＰＧＷは、ユーザが指定したＡＰＮ、またはユーザのプロファイルで指定されているＡＰＮからＤＮＳサーバを介して選択される。本図では、通常の加入者のIMSアクセス要求に対してＰＧＷ７４がＤＮＳサーバ７２から指定されている一方、優先加入者のIMSアクセス要求に対してはＰＧＷ７５がＤＮＳサーバ７２から指定されている。

本図では、ＰＧＷ７４とＰＧＷ７５とが同一屋舎に配置されている状況で、その屋舎が火事などの災害によりＰＧＷ７４とＰＧＷ７５とが動作不能に陥った場合を想定している。また、ＰＧＷ７５とＰＧＷ７６とは、ＯｐｅｎＦｌｏｗシステムにおいて用いられるＯＦ ｂａｓｅｄ ｒｏｕｔｅｒ７３によって、切り替えて選択される。

この想定下では、通常の加入者に対してはIMSサービスが中断してしまうが、優先加入者に対しては、ＯＦ ｂａｓｅｄ ｒｏｕｔｅｒ７３により、ＰＧＷ７５から代替のＰＧＷ７６へ経路変更がおこなわれる。これにより、優先加入者に対するIMSサービスを継続する事が可能となる

本図は、ネットワークへの投資を最小限に抑えながらも緊急性の高い通信にはＯｐｅｎＦｌｏｗ技術を適用する事によってネットワークを強化する例を示している。

（実施の形態２）
続いて、図１４を用いて通信システム内における輻輳の発生について説明する。本図のネットワーク構成は、図２と同様であるため詳細な説明を省略する。本図においては、ＰＧＷ２３に輻輳が発生した場合に、ＵＥから送信されたユーザトラヒックについて、Ｒｏｕｔｅｒ２２が、ＰＧＷ２３宛のデータの一部をＰＧＷ２４へ経路変更すること、およびサービスサーバ４３から送信されたユーザトラヒックについて、Ｒｏｕｔｅｒ４１が、ＰＧＷ２３宛のデータの一部をＰＧＷ２４へ経路変更することを示している。なお、ＰＧＷ２３及び２４の代わりに、ＧＧＳＮが用いられてもよい。さらに、ＳＧＷ２１の代わりに、ＳＧＳＮや、ＲＮＣが用いられてもよい。

ここで、図１５を用いて、Ｒｏｕｔｅｒ２２の保持するルーティングテーブルに設定される情報について説明する。ルーティングテーブルは、ＩＰアドレス情報（IP address）と、宛先情報（Destination）とから構成されている。たとえば、ＩＰアドレス＃Ａと、ＰＧＷ２３と、が対応付けられており、ＩＰアドレス＃Ｂと、ＰＧＷ２４とが対応付けられている。

その後、ＰＧＷ２３に輻輳が発生した場合に、偶数のＴＥＩＤと対応付けられているＩＰアドレス＃Ａと、ＰＧＷ２３と、が対応付けられるように更新される。さらに、奇数のＴＥＩＤと対応付けられているＩＰアドレス＃Ａと、ＰＧＷ２４と、が対応付けられるように更新される。これにより、Ｒｏｕｔｅｒ２２は、ＰＧＷ２３に輻輳が発生した場合、奇数のＴＥＩＤと対応付けられているＩＰアドレス＃Ａ宛のパケットデータをＰＧＷ２４へ経路変更することができる。そのため、ＰＧＷ２３宛てのパケットデータを減少させることができるため、ＰＧＷ２３の輻輳状態を解消することができる。上記の偶数もしくは奇数のＴＥＩＤとＩＰアドレスとの対応付けは一例であり、例えば、偶数のＴＥＩＤと対応付けられているＩＰアドレス＃Ａと、ＰＧＷ２４とが対応付けられ、奇数のＴＥＩＤと対応付けられているＩＰアドレス＃Ａと、ＰＧＷ２３とが対応付けられてもよい。

ここで、上記においては、奇数のＴＥＩＤと対応付けられているＩＰアドレスとＰＧＷとの対応付けを更新する例を示したが、奇数のＴＥＩＤの代わりに、ＴＥＩＤのレンジを用いてもよい。さらに、ＴＥＩＤを用いる代わりに、ＰＭＩＰトンネルのＧＲＥ Ｋｅｙのレンジもしくは、奇数や偶数のＧＲＥ Ｋｅｙを用いてもよい。さらに、ＴＥＩＤ及びＧＲＥ Ｋｅｙの代わりに、ＰＧＷが通信するＳＧＷと対応付けを行ってもよく、ルーティングテーブルの設定は通信事業者が独自の指標を用いて設定する事ができる。

なお、Ｒｏｕｔｅｒ２２は、ＰＧＷ２３に輻輳が発生した後、ＦＣ２５から通知される経路情報、つまりルーティングポリシーに基づいて、ルーティングテーブルの設定情報を更新する。

続いて、図１６を用いて、ＰＣＲＦ２６がＰＧＷ２３の輻輳を検出した場合の処理の流れについて説明する。はじめに、ＰＣＲＦ２６は、ＰＧＷ２３の輻輳を検出する（Ｓ９１）。ＰＣＲＦ２６は、ＳＮＭＰ又はＩＣＭＰ等のネットワークマネジメントプロトコルを用いて、ＰＧＷ２３の輻輳を検出してもよい。

次に、ＰＣＲＦ２６は、ＰＧＷ２３の代替装置となるＰＧＷ２４においてデータ通信サービスを実行させるために、Redirection decision処理を開始する（Ｓ９２）。次に、ＰＣＲＦ２６は、ＰＧＷ２３に故障が発生することにより影響を受けるフローのポリシー情報をＰＧＷ２４へ通知するために、Install all policy rules for affected sessionをＰＧＷ２４へ通知する（Ｓ９３）。ポリシー情報には、PCC rule、ベアラー情報、制御信号情報及びOpen Flow rule等を含むセッション情報が含まれる。次に、ＰＧＷ２４は、Install all policy rules for affected sessionに対する応答信号として、Install policy rule ackをＰＣＲＦ２６へ通知する（Ｓ９４）。

ここで、ステップＳ９３及びＳ９４は、ＰＧＷ２３との間にベアラーを確立しているＵＥ毎に実行されてもよく、複数のＵＥのポリシー情報をまとめて送信するためにバルクメッセージを用いて一括で実行されてもよい。バルクメッセージを用いることにより、ＵＥ毎にメッセージを送信する場合と比較して切り替え時間の短縮、処理量の低減及び処理負荷の削減を図ることができる。

次に、ＦＣ２５は、Ｒｏｕｔｅｒ２２に対してRouting policy updateを送信する（Ｓ９５）。Ｒｏｕｔｅｒ２２は、Routing policy updateを受信すると、図１５において説明したように、ルーティングテーブルを更新する。具体的には、Ｒｏｕｔｅｒ２２は、奇数のＴＥＩＤと対応付けられている宛先ＩＰアドレス＃Ａが設定されているユーザデータを、ＰＧＷ２４へ経路変更するようにルーティングテーブルを更新する。同様に、ＦＣ２５は、Ｒｏｕｔｅｒ４１に対してRouting policy updateを送信する（Ｓ９６）。

次に、Ｒｏｕｔｅｒ２２は、ＦＣ２５に対してRouting policy update ackを送信し（Ｓ９７）、Ｒｏｕｔｅｒ４１は、ＦＣ２５に対してRouting policy update ackを送信する（Ｓ９８）。

次に、ＰＣＲＦ２６は、ＰＧＷ２３を宛先とするパケットデータのうち、一部のパケットデータをＰＧＷ２４へ経路変更させることにより不要となったセッションを削除するために、ＰＧＷ２３へRemove transferred sessionを送信する（Ｓ９９）。ＰＧＷ２３は、不要となったセッションを削除した後、Remove transferred session ackをＰＣＲＦ２６へ送信する（Ｓ１００）。

続いて、図１７を用いて、ＰＣＲＦ２６がＰＧＷ２３の輻輳を検出した場合の処理の流れについて図１６とは異なる例について説明する。ステップＳ１０１及びＳ１０２は、図１６のステップＳ９１及びＳ９２と同様であるため説明を省略する。また、ステップＳ１０３〜Ｓ１０６は、図１６のステップＳ９５〜Ｓ９８と同様であるため説明を省略する。

次に、ステップＳ１０６までに、Ｒｏｕｔｅｒ２２は、ＰＧＷ２３宛ての一部のデータをＰＧＷ２４へ経路変更するようにルーティングテーブルを更新した後に、ＰＧＷ２４は、Ｒｏｕｔｅｒ２２から宛先ＩＰアドレスとしてＩＰアドレス＃Ａが設定されたユーザデータを受信する（Ｓ１０７）。

次に、ＰＧＷ２４は、受信したユーザデータに対応するポリシー情報を受け取るために、ＰＣＲＦ２６に対してPolicy rule requestを送信する（Ｓ１０８）。Policy rule requestには、ＰＧＷ２４が受信したフローに関するＩＭＳＩもしくはＩＰアドレスと、ＴＥＩＤもしくはＴＥＩＤ−Ｃとが含まれている。次に、ＰＣＲＦ２６は、ＰＧＷ２４が受信したフローに関する、PCC rule、ベアラー情報、制御信号情報及びOpen Flow rule等を含むセッション情報を通知するために、ＰＧＷ２４に対して、Install policy rule for specified sessionを送信する（Ｓ１０９）。

ステップＳ１１０及びＳ１１１は、図１６のステップＳ９９及びＳ１００と同様であるため説明を省略する。

続いて、図１８を用いて、ＰＣＲＦ２６がＰＧＷ２３の輻輳を検出した場合の処理の流れについて図１６及び図１７とは異なる例について説明する。ステップＳ１２１及び１２２は、図１６のステップＳ９１及びＳ９２と同様であるため説明を省略する。

次に、ＰＣＲＦ２６は、輻輳したＰＧＷ２３に対して、ＰＧＷ２４への移行対象となるルーティングポリシーを通知し、一部或いは全てのセッションの移行を促すために、Context transfer requestを送信する（Ｓ１２３）。ここでは、移行対象として、奇数のＴＥＩＤと関連付けられているＩＰアドレス＃Ａを指定している。

次に、ＰＧＷ２３は、移行対象となるルーティングポリシー情報に該当するセッション情報（ＰＣＣルール、ベアラー情報、制御信号情報及びOpen Flow rule等）をＰＧＷ２４へ通知するために、ＰＧＷ２４に対してTransfer all policy rules for affected sessionsを送信する（Ｓ１２４）。

ここで、ステップＳ１２３及びＳ１２４は、ＰＧＷ２３との間にベアラーを確立しているＵＥ毎に実行されてもよく、複数のＵＥのポリシー情報をまとめて送信するためにバルクメッセージを用いて一括で実行されてもよい。バルクメッセージを用いることにより、ＵＥ毎にメッセージを送信する場合と比較して切り替え時間の短縮、処理量の低減及び処理負荷の削減を図ることができる。

次に、ＰＧＷ２４は、応答信号としてＰＧＷ２３へTransfer policy rules ackを送信する（Ｓ１２５）。次に、ＰＧＷ２３は、Context transfer requestに対する応答信号として、ＦＣ２５へContext transfer answerを送信する。

ステップＳ１２７〜Ｓ１３０は、図１６のステップＳ９５〜９８と同様であるため説明を省略する。

続いて、図１９を用いて、ＰＣＲＦ２６がＰＧＷ２３の輻輳を検出した場合の処理の流れについて図１６〜図１８とは異なる例について説明する。はじめに、ＰＧＷ２３において輻輳が発生すると、ＰＧＷ２３は、ＰＣＲＦ２６に対して輻輳を通知するためにCongestion notificationを送信する（Ｓ１３１）。Congestion notificationには、ＰＧＷ２４へ移行対象となるルーティングポリシー情報が含まれており、ＰＧＷ２３は、ＰＣＲＦ２６に対して、一部或いは全てのセッションンの移行を促す。ここでは、移行対象として、奇数のＴＥＩＤと関連付けられているＩＰアドレス＃Ａを指定している。

ステップＳ１３２及びＳ１３３は、図１６のステップＳ９３及びＳ９４と同様であるため説明を省略する。ステップＳ１３３の後に、ＰＣＲＦ２６は、ＰＧＷ２３へCongestion notificationの応答信号として、Congestion notification ackを送信する（Ｓ１３４）。ステップＳ１３５〜Ｓ１４０は、図１６のステップＳ９５〜Ｓ１００と同様であるため説明を省略する。

続いて、図２０を用いて、ＰＣＲＦ２６がＰＧＷ２３の輻輳を検出した場合の処理の流れについて図１６〜図１９とは異なる例について説明する。ステップＳ１４１は、図１９のステップＳ１３１と同様であるため説明を省略する。次に、ＰＣＲＦ２６は、応答信号としてCongestion notification ackを送信する（Ｓ１４２）。ステップＳ１４３〜Ｓ１５１は、図１７のステップＳ１０３〜Ｓ１１１と同様であるため説明を省略する。

続いて、図２１を用いて、ＰＣＲＦ２６がＰＧＷ２３の輻輳を検出した場合の処理の流れについて図１６〜図２０とは異なる例について説明する。ステップＳ１６１及びＳ１６２は、図２０のステップＳ１４１及び１４２と同様であるため説明を省略する。さらに、ステップＳ１６３〜Ｓ１７０は、図１８のステップＳ１２３〜Ｓ１３０と同様であるため説明を省略する。

続いて、図２２を用いて、ＰＧＷ２３が輻輳状態から復旧した場合の処理の流れについて説明する。はじめに、ＰＣＲＦ２６は、ＰＧＷ２３の輻輳が復旧したことを検出する（Ｓ１７１）。たとえば、ＰＣＲＦ２６は、ＳＮＭＰや、ＩＣＭＰ等のネットワークマネジメントプロトコルを用いてＰＧＷ２３の輻輳が復旧したことを検出してもよい。

次に、ＰＣＲＦ２６は、ＰＧＷ２３が復旧したため、代替装置であるＰＧＷ２４におけるセッションをＰＧＷ２４からＰＧＷ２３へ切り替えるために、Redirection decision処理を開始する（Ｓ１７２）。次に、ＰＣＲＦ２６は、輻輳発生時にＰＧＷ２３からＰＧＷ２４へ移行されたセッションを復旧するためＰＧＷ２４へContext transfer requestを送信する（Ｓ１７３）。Context transfer requestには、ＰＧＷ２３へ移行対象となるルーティングポリシー情報が含まれている。ここでは、移行対象として、奇数のＴＥＩＤと関連付けられているＩＰアドレス＃Ａを指定している。

次に、ＰＧＷ２４は、ＰＧＷ２３へ移行対象となるルーティングポリシーに該当するセッション情報を含むTransfer all policy rules for affected sessionsをＰＧＷ２３へ通知する（Ｓ１７４）。

ここで、ステップＳ１７４は、ＰＧＷ２３との間にベアラーを確立しているＵＥ毎に実行されてもよく、複数のＵＥのポリシー情報をまとめて送信するためにバルクメッセージを用いて一括で実行されてもよい。バルクメッセージを用いることにより、ＵＥ毎にメッセージを送信する場合と比較して切り替え時間の短縮、処理量の低減及び処理負荷の削減を図ることができる。

次に、ＰＧＷ２３は、ＰＧＷ２４へ応答信号としてTransfer all policy rules ackを送信する（Ｓ１７５）。さらに、ＰＧＷ２４は、Context transfer requestに対する応答信号としてＦＣ２５へContext transfer answerを送信する（Ｓ１７６）。

次に、ＦＣ２５は、Ｒｏｕｔｅｒ２２に対してRouting policy updateを送信する（Ｓ１７７）。Ｒｏｕｔｅｒ２２は、Routing policy updateを受信すると、奇数のＴＥＩＤと対応付けられている宛先ＩＰアドレス＃Ａが設定されているユーザデータを、ＰＧＷ２３へ経路変更するようにルーティングテーブルを更新する。同様に、ＦＣ２５は、Ｒｏｕｔｅｒ４１に対してRouting policy updateを送信する（Ｓ１７８）。

次に、Ｒｏｕｔｅｒ２２は、ＦＣ２５に対してRouting policy update ackを送信し（Ｓ１７９）、Ｒｏｕｔｅｒ４１は、ＦＣ２５に対してRouting policy update ackを送信する（Ｓ１８０）。

続いて、図２３を用いて、ＰＧＷ２３が輻輳状態から復旧した場合の処理の流れについて図２２とは異なる例について説明する。はじめに、ＰＧＷ２３が輻輳状態から復旧すると、ＰＧＷ２３は、ＰＣＲＦ２６に対して輻輳復旧を通知するためにCongestion notificationを送信する（Ｓ１８１）。Congestion notificationには、ＰＧＷ２４からＰＧＷ２３へ移行対象となるルーティングポリシー情報が含まれており、ＰＧＷ２３は、ＰＣＲＦ２６に対して、一部或いは全てのセッションンの移行を促す。次に、ＰＣＲＦ２６は、ＰＧＷ２３へCongestion notificationの応答信号として、Congestion notification ackを送信する（Ｓ１８２）。

次に、ＰＣＲＦ２６は、代替装置であるＰＧＷ２４に対して、ＰＧＷ２３への移行対象となるルーティングポリシーを通知し、一部或いは全てのセッションの移行を促すために、Context transfer requestを送信する（Ｓ１８３）。ここでは、移行対象として、宛先ＩＰアドレス＃Ａを指定している。

次に、ＰＧＷ２４は、移行対象となるルーティングポリシー情報に該当するセッション情報（ＰＣＣルール、ベアラー情報、制御信号情報及びOpen Flow rule等）をＰＧＷ２３へ通知するために、ＰＧＷ２３に対してTransfer all policy rules for affected sessionsを送信する（Ｓ１８４）。

次に、ＰＧＷ２３は、応答信号としてＰＧＷ２４へTransfer policy rules ackを送信する（Ｓ１８５）。さらに、ＰＧＷ２４は、Context transfer requestへの応答信号として、ＰＣＲＦ２６へContext transfer answerを送信する（Ｓ１８６）。

ここで、ステップＳ１８４及びＳ１８５は、ＰＧＷ２３との間にベアラーを確立しているＵＥ毎に実行されてもよく、複数のＵＥのポリシー情報をまとめて送信するためにバルクメッセージを用いて一括で実行されてもよい。バルクメッセージを用いることにより、ＵＥ毎にメッセージを送信する場合と比較して切り替え時間の短縮、処理量の低減及び処理負荷の削減を図ることができる。

ステップＳ１８７〜Ｓ１９０は、図２２のステップＳ１７７〜１８０と同様であるため説明を省略する。

続いて、図２４を用いて、ＰＧＷ２３が輻輳状態から復旧した場合の処理の流れについて図２２及び図２３とは異なる例について説明する。ＰＧＷ２３の輻輳復旧を検出するステップＳ１９１及びＳ１９２は、図２３のステップＳ１８１及びＳ１８２と同様であるため説明を省略する。さらに、Ｒｏｕｔｅｒ２２及びＲｏｕｔｅｒ４１のルーティングポリシーを変更するステップＳ１９３〜Ｓ１９６は、図２２のステップＳ１７７〜Ｓ１８０と同様であるため説明を省略する。

次に、ステップＳ１９６までに、Ｒｏｕｔｅｒ２２は、ＰＧＷ２４宛ての一部のデータをＰＧＷ２３へ経路変更するようにルーティングテーブルを更新した後に、ＰＧＷ２３は、Ｒｏｕｔｅｒ２２から宛先ＩＰアドレスとしてＩＰアドレス＃Ａが設定されたユーザデータを受信する（Ｓ１９７）。

次に、ＰＧＷ２３は、受信したユーザデータに対応するポリシー情報を受け取るために、ＰＣＲＦ２６に対してPolicy rule requestを送信する（Ｓ１９８）。Policy rule requestには、ＰＧＷ２３が受信したフローに関するＩＭＳＩもしくはＩＰアドレスと、ＴＥＩＤもしくはＴＥＩＤ−Ｃとが含まれている。次に、ＰＣＲＦ２６は、ＰＧＷ２３が受信したフローに関するPCC rule、ベアラー情報、C-Plane制御情報等を通知するために、ＰＧＷ２３に対して、Install policy rule for specified sessionを送信する（Ｓ１９９）。

次に、ＰＣＲＦ２６は、ＰＧＷ２３が復旧することによりＰＧＷ２４において不要となったセッションを削除するために、ＰＧＷ２４へRemove transferred sessionを送信する（Ｓ２００）。ＰＧＷ２４は、不要となったセッションを削除した後、Remove transferred session ackをＰＣＲＦ２６へ送信する（Ｓ２０１）。

（実施の形態３）
続いて、図２５を用いて実施の形態３にかかる通信システム内における故障の発生について説明する。図２５は、ＲＡＮ（Radio Access Network）５０と、ＥＰＣ６０とを用いて通信が行われる構成を示している。

ＲＡＮ５０は、ｅＮＢ５１と、Ｒｏｕｔｅｒ５２と、ＳＧＷ５３及び５４と、ＦＣ５５と、ＭＭＥ５６と、を備えている。ＥＰＣ６０は、Ｒｏｕｔｅｒ６１と、ＰＧＷ６２とを備えている。ＰＧＷ６２は、Ｅｘｔｅｒｎａｌ ｎｅｔｗｏｒｋ４０のＳｅｒｖｉｃｅ ｓｅｒｖｅｒ４３と接続されている。

ｅＮＢ５１は、無線方式として３ＧＰＰにおいて規定されているＬＴＥ方式を用いて通信端末と通信を行う基地局である。ｅＮＢ５１は、ＵＥがユーザトラヒックを、Ｒｏｕｔｅｒ５２を介してＳＧＷ５３もしくはＳＧＷ５４へ送信する。ユーザトラヒックには、宛先アドレスとして、ＳＧＷ５３に割り当てられているＩＰアドレス＃ＡもしくはＳＧＷ５４に割り当てられているＩＰアドレス＃Ｂが設定されている。Ｒｏｕｔｅｒ５２は、宛先アドレスと転送先の装置とが関連付けられているルーティングテーブルを用いて、ｅＮＢ５１から送信されたユーザトラヒックをＳＧＷ５３もしくはＳＧＷ５４へ転送する。本図においては、ＳＧＷ５３に故障が発生する前のユーザトラヒックは、ＳＧＷ５３に転送されていることを示している。

Ｒｏｕｔｅｒ６１は、ＳＧＷ５３もしくは５４から送信されたデータを、ＰＧＷ６２を介してＳｅｒｖｉｃｅ ｓｅｒｖｅｒ４３へ送信する。もしくは、Ｒｏｕｔｅｒ６１は、ＰＧＷ６２を介してＳｅｒｖｉｃｅ ｓｅｒｖｅｒ４３から送信されたデータをＳＧＷ５３もしくは５４へ送信する。

ＭＭＥ５６は、無線方式として３ＧＰＰにおいて規定されているＬＴＥ方式を用いて通信を行う通信端末のモビリティ管理、セッション管理及びサービス管理を行う。

ＦＣ５５は、実施の形態１におけるＦＣ２５と同様の機能を有するため詳細な説明を省略する。また、ＳＧＷ５３及び５４は、実施の形態１におけるＳＧＷ２１と同様の機能を有するため詳細な説明を省略する。また、ＰＧＷ６２は、実施の形態１におけるＰＧＷ２３もしくは２４と同様の機能を有するため詳細な説明を省略する。

本図においては、ＳＧＷ５３に故障が発生した場合に、Ｒｏｕｔｅｒ５２が、ＳＧＷ５３宛のデータをＳＧＷ５４へ経路変更することを示している。

続いて、図２６を用いて図２５とは異なる通信システム内における故障の発生について説明する。本図においては、図２５のｅＮＢ５１の代わりに、ＳＧＳＮ５７が用いられている。その他の構成については、図２５と同様である。本図においても、ＳＧＷ５３に故障が発生した場合に、Ｒｏｕｔｅｒ５２が、ＳＧＷ５３宛のデータをＳＧＷ５４へ経路変更することを示している。

続いて、図２７を用いて図２５及び図２６とは異なる通信システム内における故障の発生について説明する。本図においては、図２５のｅＮＢ５１の代わりに、ＲＮＣ５８が用いられている。その他の構成については、図２５と同様である。本図においても、ＳＧＷ５３に故障が発生した場合に、Ｒｏｕｔｅｒ５２が、ＳＧＷ５３宛のデータをＳＧＷ５４へ経路変更することを示している。ＲＮＣ５８の代わりに、ＢＳＣ（Base Station Controller）を用いることによって、いわゆる２Ｇシステムへ本発明を適用することも可能である。

図２５〜図２７のＲｏｕｔｅｒ５２において用いられるルーティングテーブルは、図３と基本的には同一であり、図３におけるＰＧＷの代わりに本図においては、ＳＧＷが用いられている。

続いて、図２８及び図２９を用いて、ＭＭＥ５６がＳＧＷ５３の故障を検出した場合の処理の流れについて説明する。ここで、図２８は、図９におけるＰＧＷをＳＧＷとした場合の処理と同様である。ただし、ステップＳ２１３において、本図においては、ＭＭＥ５６から代替装置であるＳＧＷ５４に対してInstall all contexts for affected sessionsを送信し、ステップＳ２１４においてＳＧＷ５４からＭＭＥ５６に対して、Install ackを送信することが図９と異なる。Install all contexts for affected sessionsには、ベアラー情報、制御信号情報及びOpen Flow rule等が含まれる。図２８におけるその他の処理は、図９と同様である。

さらに、図２９は、図１０におけるＰＧＷをＳＧＷとした場合の処理と同様である。但し、ステップＳ２２８において、本図においては、代替装置であるＳＧＷ５４からＭＭＥ５６に対してContext requesutを送信し、さらに、ステップＳ２２９において、本図においては、ＭＭＥ５６から代替装置であるＳＧＷ５４に対してInstall all contexts for affected sessionsを送信することが図１０と異なる。Install all contexts for affected sessionsには、ベアラー情報、制御信号情報及びOpen Flow rule等が含まれる。図２９におけるその他の処理は、図１０と同様である。

図２８及び図２９は、図９及び図１０と同様に、代替装置であるＳＧＷ５４へのポリシーの設定処理及びＲｏｕｔｅｒ５２における代替装置であるＳＧＷ５４へのルーティングポリシーの変更処理を示している。その処理は、図９及び図１０と同一であるため、詳細な説明を省略する。

続いて、図３０〜３２を用いて、ＭＭＥ５６がＳＧＷ５３の故障が復旧した場合の処理の流れについて説明する。図３０は、図１１におけるＰＧＷをＳＧＷとした場合の処理と同様である。ただし、ステップＳ２３３において、本図においては、ＭＭＥ５６から故障が復旧した装置であるＳＧＷ５３に対してRe-install all sessions originally in SGW53を送信し、ステップＳ２３４においてＳＧＷ５４からＭＭＥ５６に対して、Install ackを送信することが図１１と異なる。Re-install all sessions originally in SGW23には、ベアラー情報、制御信号情報及びOpen Flow rule等が含まれる。図３０におけるその他の処理は、図１１と同様である。

図３１は、図１２におけるＰＧＷをＳＧＷとした場合の処理と同様である。ただし、ステップＳ２４２において、本図においては、ＭＭＥ５６から故障が復旧した装置であるＳＧＷ５３に対してRe-install all sessions originally in SGW53を送信し、ステップＳ２４３においてＳＧＷ５４からＭＭＥ５６に対して、Install ackを送信することが図１１と異なる。図３１におけるその他の処理は、図１２と同様である。

図３２は、図１３におけるＰＧＷをＳＧＷとした場合の処理と同様である。ただし、ステップＳ２５８において、本図においては、復旧した装置であるＳＧＷ５３からＭＭＥ５６に対してSession re-installation requestを送信し、ステップＳ２５９においてＭＭＥ５６からＳＧＷ５３に対して、Install specified sessionを送信することが図１１と異なる。Install specified sessionには、ベアラー情報、制御信号情報及びOpen Flow rule等が含まれる。図３２におけるその他の処理は、図１３と同様である。

続いて、図４８を用いて、地理的またはネットワークトポロジーを単位としたＥＰＣネットワークの強化について説明する。通常、ＳＧＷは、地理的またはネットワークトポロジーを単位として配置される。本図においては、地理的またはネットワークトポロジーを示すエリアＡ、エリアＢ及びエリアＣがＯｐｅｎＦｌｏｗ技術を用いることにより、相互に切り替えが可能であることを示している。本図においては、地震、津波、台風等、地理的に発生する災害等に対して、ＯｐｅｎＦｌｏｗ技術を用いることによりネットワークの強化が図れることを示している。

（実施の形態４）
続いて、図３３を用いて通信システム内における輻輳の発生について説明する。図３３３は、図２５と同様の構成であって、ＳＧＷ５３において輻輳が発生していることを示している。

図３３のＲｏｕｔｅｒ５２において用いられるルーティングテーブルは、図１５と基本的には同一であり、図１５におけるＰＧＷの代わりに本図においてはＳＧＷが用いられている。

続いて、図３４〜図３９を用いて、ＳＧＷ５３が輻輳状態から復旧した場合の処理の流れについて説明する。

図３４は、図１６におけるＰＧＷをＳＧＷとした場合の処理と同様である。ただし、ステップＳ２７３において、本図においては、ＭＭＥ５６から代替装置であるＳＧＷ５４に対してInstall all affected sessionsを送信し、ステップＳ２７４においてＳＧＷ５４からＭＭＥ５６に対して、Install ackを送信することが図１６と異なる。Install all affected sessions には、ベアラー情報、制御信号情報及びOpen Flow rule等が含まれる。図３４におけるその他の処理は、図１６と同様である。

図３５は、図１７におけるＰＧＷをＳＧＷとした場合の処理と同様である。ただし、ステップＳ２８８において、本図においては、代替装置であるＳＧＷ５４からＭＭＥ５６に対してSession installation requestを送信し、ステップＳ２８９においてＦＣ５５からＳＧＷ５４に対して、Install specified sessionを送信することが図１７と異なる。図３５におけるその他の処理は、図１７と同様である。

図３６は、図１８におけるＰＧＷをＳＧＷとした場合の処理と同様である。ただし、ステップＳ３０４において、本図においては、輻輳している装置であるＳＧＷ５３からＭＭＥ５６に対してInstall all affected sessionsを送信し、ステップＳ３０５においてＭＭＥ５６からＳＧＷ５３に対して、Install ackを送信することが図１８と異なる。図３６におけるその他の処理は、図１８と同様である。

図３７は、図１９におけるＰＧＷをＳＧＷとした場合の処理と同様である。ただし、ステップＳ３１２において、本図においては、ＭＭＥ５６から代替装置であるＳＧＷ５４に対してInstall all affected sessionsを送信し、ステップＳ３１３においてＳＧＷ５４からＭＭＥ５６に対して、Install ackを送信することが図１９と異なる。図３７におけるその他の処理は、図１９と同様である。

図３８は、図２０におけるＰＧＷをＳＧＷとした場合の処理と同様である。ただし、ステップＳ３２８において、本図においては、代替装置であるＳＧＷ５４からＭＭＥ５６に対してSession install request を送信し、ステップＳ３２９においてＭＭＥ５６からＳＧＷ５４に対して、Install specified sessionを送信することが図２０と異なる。図３８におけるその他の処理は、図２０と同様である。

図３９は、図２１におけるＰＧＷをＳＧＷとした場合の処理と同様である。ただし、ステップＳ３４４において、本図においては、ＳＧＷ５３から代替装置であるＳＧＷ５４に対してTransfer all affected sessions を送信し、ステップＳ３４５においてＳＧＷ５４からＳＧＷ５３に対して、Transfer ackを送信することが図２１と異なる。図３９におけるその他の処理は、図２１と同様である。

図４０は、図２２におけるＰＧＷをＳＧＷとした場合の処理と同様である。ただし、ステップＳ３５４において、本図においては、代替装置であるＳＧＷ５４から輻輳状態から復帰したＳＧＷ５３に対してTransfer all affected sessions を送信し、ステップＳ３５５においてＳＧＷ５３からＳＧＷ５４に対して、Transfer ackを送信することが図２２と異なる。図４０におけるその他の処理は、図２２と同様である。

図４１は、図２３におけるＰＧＷをＳＧＷとした場合の処理と同様である。ただし、ステップＳ３６４において、本図においては、代替装置であるＳＧＷ５４から輻輳状態から復帰したＳＧＷ５３に対してTransfer all affected sessions を送信し、ステップＳ３６５においてＳＧＷ５３からＳＧＷ５４に対して、Transfer ackを送信することが図２３と異なる。図４１におけるその他の処理は、図２３と同様である。

図４２は、図２４におけるＰＧＷをＳＧＷとした場合の処理と同様である。ただし、ステップＳ３７８において、本図においては、輻輳状態から復帰したＳＧＷ５３からＭＭＥ５６に対してSession installation request を送信し、ステップＳ３７９においてＦＣ５５からＳＧＷ５３に対して、Install specified sessionを送信することが図２４と異なる。図４２におけるその他の処理は、図２４と同様である。

なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。

以上、実施の形態を参照して本願発明を説明したが、本願発明は上記によって限定されるものではない。本願発明の構成や詳細には、発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

この出願は、２０１２年４月２７日に出願された日本出願特願２０１２−１０２７４１を基礎とする優先権を主張し、その開示の全てをここに取り込む。

１１ データ転送装置
１２ ゲートウェイ
１３ ゲートウェイ
１４ 経路制御装置
２０ ＥＰＳ
２１ ＳＧＷ
２２ Ｒｏｕｔｅｒ
２３ ＰＧＷ
２４ ＰＧＷ
２５ ＦＣ
２６ ＰＣＲＦ
２７ ＧＧＳＮ
２８ ＧＧＳＮ
２９ ＳＧＳＮ
３０ ＲＮＣ
３１ Ｎｏｎ ３ＧＰＰ ａｃｃｅｓｓ
４０ Ｅｘｔｅｒｎａｌ ｎｅｔｗｏｒｋ
４１ Ｒｏｕｔｅｒ
４２ ＴＤＦ
４３ Ｓｅｒｖｉｃｅ ｓｅｒｖｅｒ
５０ ＲＡＮ
５１ ｅＮＢ
５２ Ｒｏｕｔｅｒ
５３ ＳＧＷ
５４ ＳＧＷ
５５ ＦＣ
５６ ＭＭＥ
５７ ＳＧＳＮ
５８ ＲＮＣ
６０ ＥＰＣ
６１ Ｒｏｕｔｅｒ
６２ ＰＧＷ

Claims (19)

1. データ転送装置と、
   前記データ転送装置と通信を行っている第１のゲートウェイと、
   前記第１のゲートウェイの代替装置である第２のゲートウェイと、
   ＰＣＲＦ又はＭＭＥと、
   前記データ転送装置と、前記第１及び第２のゲートウェイとの間の通信経路を制御する経路制御手段と、を備える通信システムであって、
   前記ＰＣＲＦ又はＭＭＥと前記経路制御手段とが同一の装置で構成され、
   前記同一の装置は、
   前記第１のゲートウェイにおける障害状態を検出した場合、前記データ転送装置から前記第１のゲートウェイへ転送されるデータを前記第２のゲートウェイへ転送させるとともに、前記第１のゲートウェイに設定されているセッション情報を前記第２のゲートウェイへ通知するように構成される、通信システム。
2. 前記障害状態は、前記第１のゲートウェイの故障、輻輳及び前記データ転送装置と前記第１のゲートウェイとの間の経路障害の少なくも１つを含む、請求項１に記載の通信システム。
3. 前記セッション情報は、ベアラー情報を含む、請求項１又は２に記載の通信システム。
4. 前記データ転送装置は、
   前記第１のゲートウェイに割り当てられている第１のアドレス情報と、前記第１のゲートウェイとを関連づけたルーティングテーブルを有し、
   前記経路制御手段は、
   前記第１のゲートウェイにおける前記障害状態を検出した場合、前記第１のアドレス情報と前記第２のゲートウェイとを関連付けるように前記ルーティングテーブルを更新させる、請求項１乃至３のいずれか１項に記載の通信システム。
5. 前記経路制御手段は、
   前記障害状態であった前記第１のゲートウェイが復旧したことを検出した場合、前記第１のアドレス情報と前記第１のゲートウェイとを関連付けるように前記ルーティングテーブルを更新させる請求項４に記載の通信システム。
6. 前記経路制御手段は、
   前記第１のゲートウェイにおいて輻輳が発生した場合に、前記第１のゲートウェイから送信され輻輳通知に基づいて、前記第１のゲートウェイに設定されている前記セッション情報を前記第２のゲートウェイへ通知する、請求項１乃至５のいずれか１項に記載の通信システム。
7. 前記データ転送装置は、
   前記第１のゲートウェイに割り当てられている第１のアドレス情報及び複数のトンネル識別子と、前記第１のゲートウェイとを関連づけたルーティングテーブルを有し、
   前記経路制御手段は、
   前記第１のゲートウェイにおける輻輳を検出した場合、前記複数のトンネル識別子のうち一部のトンネル識別子と関連付けられている前記第１のアドレス情報と、前記第２のゲートウェイと、を関連付けるように前記ルーティングテーブルを更新させる、請求項１乃至６のいずれか１項に記載の通信システム。
8. 前記経路制御手段は、
   前記第１のゲートウェイにおける輻輳を検出した場合、前記一部のトンネル識別子と関連付けられている前記第１のアドレス情報に関連するセッション情報を前記第２のゲートウェイへ通知させるセッション情報転送通知を前記第１のゲートウェイへ送信し、
   前記第１のゲートウェイは、
   前記セッション情報転送通知を受信した場合、前記第２のゲートウェイへ前記一部のトンネル識別子と関連付けられている前記第１のアドレス情報に関連するセッション情報を前記第２のゲートウェイへ送信する、請求項７に記載の通信システム。
9. 前記第１及び第２のゲートウェイは、
   ３ＧＰＰ技術仕様書において規定されているＰＧＷ又はＧＧＳＮである、請求項１乃至８のいずれか１項に記載の通信システム。
10. 前記経路制御手段は、
    ３ＧＰＰ技術仕様書において規定されているＰＣＲＦと連携して動作する、請求項１乃至７と請求項９のいずれか１項に記載の通信システム。
11. 前記第１及び第２のゲートウェイは、
    ３ＧＰＰ技術仕様書において規定されているＳＧＷである、請求項１乃至８のいずれか１項に記載の通信システム。
12. 前記経路制御手段は、
    ３ＧＰＰ技術仕様書において規定されているＭＭＥと連携して動作する、請求項１乃至７と請求項１１のいずれか１項に記載の通信システム。
13. データ転送装置と、前記データ転送装置と通信を行っている第１のゲートウェイと、前記第１のゲートウェイの代替装置である第２のゲートウェイと、ＰＣＲＦ又はＭＭＥと、前記データ転送装置と前記第１及び第２のゲートウェイとの間の通信経路を制御し、前記ＰＣＲＦ又はＭＭＥと同一の装置で構成される経路制御手段と、を備える通信システムにおける経路制御方法であって、
    前記データ転送装置と通信を行っている前記第１のゲートウェイにおける障害状態を検出し、
    前記データ転送装置から前記第１のゲートウェイへ転送されるデータを前記第１のゲートウェイの代替装置である前記第２のゲートウェイへ転送させるとともに、前記第１のゲートウェイに設定されているセッション情報を前記第２のゲートウェイへ通知する、経路制御方法。
14. 前記障害状態は、前記第１のゲートウェイの故障、輻輳及び前記データ転送装置と前記第１のゲートウェイとの間の経路障害の少なくも１つを含む、請求項１３に記載の経路制御方法。
15. 前記セッション情報は、ベアラー情報を含む、請求項１３又は１４に記載の経路制御方法。
16. 前記障害状態を検出し、
    前記前記データ転送装置から前記第１のゲートウェイへ転送されるデータを前記第１のゲートウェイの代替装置である第２のゲートウェイへ転送させるように制御し、
    前記第２のゲートウェイへデータが転送された場合に、前記第２のゲートウェイから送信されるセッション情報取得要求を受信し、
    前記セッション情報取得要求に基づいて、前記第２のゲートウェイへ前記セッション情報を送信する、請求項１３乃至１５のいずれか１項に記載の経路制御方法。
17. 前記第１のゲートウェイにおいて輻輳が発生した場合、前記第１のゲートウェイから送信される輻輳通知に基づいて、前記第１のゲートウェイに設定されている前記セッション情報を前記第２のゲートウェイへ通知する、請求項１３乃至１６のいずれか１項に記載の経路制御方法。
18. 前記データ転送装置は、前記第１のゲートウェイに割り当てられている第１のアドレス情報及び複数のトンネル識別子と、前記第１のゲートウェイとを関連づけたルーティングテーブルを有し、
    前記第１のゲートウェイにおける輻輳を検出した場合、前記複数のトンネル識別子のうち一部のトンネル識別子と関連付けられている前記第１のアドレス情報と、前記第２のゲートウェイと、を関連付けるように前記ルーティングテーブルを更新させる、請求項１３乃至１７のいずれか１項に記載の経路制御方法。
19. 前記第１のゲートウェイにおける輻輳を検出した場合、前記一部のトンネル識別子と関連付けられている前記第１のアドレス情報に関連するセッション情報を前記第２のゲートウェイへ通知させるセッション情報転送通知を前記第１のゲートウェイへ送信する請求項１８に記載の経路制御方法。

Images