(57)【特許請求の範囲】
【請求項１】
移動通信システムにおける移動性管理エンティティー（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ、ＭＭＥ）の輻輳制御方法において、
端末から１つ以上のパケットデータネットワーク（Ｐａｃｋｅｔ  Ｄａｔａ  Ｎｅｔｗｏｒｋ、ＰＤＮ）連結要請受信に応答し、１つ以上のアクセスポイントネーム（Ａｃｃｅｓｓ  Ｐｏｉｎｔ  Ｎａｍｅ、ＡＰＮ）に基づいて１つ以上のＰＤＮに対する１つ以上の連結を構築する構築段階；
前記端末から移動性管理要請信号を受信する受信段階―前記移動性管理要請信号は、前記１つ以上のＰＤＮに対する前記端末の前記１つ以上の連結と関連する；
前記移動性管理要請信号の受信に応答し、前記１つ以上のＡＰＮのうちの少なくとも１つに対応する少なくとも１つのＰＤＮの輻輳（ｃｏｎｇｅｓｔｉｏｎ）状態であるか否かを判断する判断段階；及び
前記少なくとも１つのＰＤＮが輻輳状態である場合、前記移動性管理要請信号を拒絶する拒絶段階；を含み、
前記１つ以上のＰＤＮに対する前記１つ以上の連結が構築された後、前記端末がアイドル状態に遷移すると、前記アイドル状態から活性化状態に遷移するために前記移動性管理要請信号が前記端末によって送信される
ことを特徴とする輻輳制御方法。
【請求項２】
前記移動性管理要請信号は、サービス要請（Ｓｅｒｖｉｃｅ  Ｒｅｑｕｅｓｔ）メッセージであることを特徴とする、請求項１に記載の輻輳制御方法。
【請求項３】
前記判断段階は、
前記端末に対して設定されたデフォルトＡＰＮの輻輳状態であるか否かを判断し、
前記拒絶段階は、
前記デフォルトＡＰＮが輻輳状態で判断される場合、  サービス要請拒絶メッセージを前記端末に送信することを特徴とする、請求項２に記載の輻輳制御方法。
【請求項４】
前記サービス要請拒絶メッセージは、
前記端末が前記サービス要請を再送信するために待機しなければならない時間のバック−オフタイムを含むことを特徴とする、請求項３に記載の輻輳制御方法。
【請求項５】
前記移動性管理要請信号はサービス要請であり、
前記判断段階は、
前記１つ以上のＡＰＮに対応するすべてのＰＤＮの輻輳状態であるか否かを判断し、
前記拒絶段階は、
前記すべてのＰＤＮのうちの少なくとも１つのＰＤＮであっても輻輳状態で判断される場合、サービス要請拒絶メッセージを前記端末に送信する
ことを特徴とする、請求項２に記載の輻輳制御方法。
【請求項６】
前記サービス要請拒絶メッセージは、
拒絶されるＡＰＮに対する情報と、  前記端末が前記サービス要請を再送信するために待機しなければならない時間のバック−オフタイムを含むことを特徴とする、  請求項５に記載の輻輳制御方法。
【請求項７】
前記判断段階は、
前記１つ以上のＡＰＮに対応するすべてのＰＤＮの輻輳状態であるか否かを判断し、輻輳状態のＰＤＮと正常状態のＰＤＮを分類し、
前記拒絶段階は、
前記輻輳状態のＰＤＮに対する一部サービス拒絶メッセージを前記端末に送信する
ことを特徴とする、請求項２に記載の輻輳制御方法。
【請求項８】
前記一部サービス拒絶メッセージは、
拒絶されるＡＰＮに対する情報と、  前記端末が前記サービス要請を再送信するために待機しなければならない時間のバック−オフタイムを含むことを特徴とする、  請求項７記載の輻輳制御方法。
【請求項９】
輻輳状態のＰＤＮに対するＰＤＮ連結を削除するためのセッション削除要請メッセージをサービングゲートウェーに送信する段階をさらに含む
ことを特徴とする、請求項８に記載の輻輳制御方法。
【請求項１０】
前記サービス要請メッセージは端末が送信するデータに係る特定ＡＰＮを含み、
前記判断段階は、
前記サービス要請メッセージに含まれたＡＰＮの輻輳状態であるか否かを判断し、
前記拒絶段階は、
前記サービス要請メッセージに含まれたＡＰＮが輻輳状態で判断される場合、  サービス拒絶メッセージを前記端末に送信することを特徴とする、請求項２に記載の輻輳制御方法。
【請求項１１】
前記移動性管理要請信号はトラッキング領域アップデート（Ｔｒａｃｋｉｎｇ  Ａｒｅａ  Ｕｐｄａｔｅ、ＴＡＵ）メッセージである
ことを特徴とする、請求項１に記載の輻輳制御方法。
【請求項１２】
前記受信段階の以後に、
前記端末をサービングしたＭＭＥから前記端末に対するコンテキスト情報を獲得する段階をさらに含むことを特徴とする、請求項１１に記載の輻輳制御方法。
【請求項１３】
前記判断段階は、
前記コンテキスト情報から前記端末に対して設定されたＡＰＮに対応するＰＤＮの輻輳であるか否かを判断し、
前記拒絶段階は、
前記端末に対するデフォルトＡＰＮに対応するＰＤＮが輻輳状態の場合、または前記端末に対して設定されたＡＰＮに対応するＰＤＮのうちの少なくとも１つのＰＤＮであっても輻輳状態の場合、ＴＡＵ拒絶メッセージを前記端末に送信する
ことを特徴とする、請求項１２に記載の輻輳制御方法。
【請求項１４】
輻輳状態のＰＤＮに対するＰＤＮ連結を削除するためのセッション削除要請メッセージをサービングゲートウェーに送信する段階をさらに含む
ことを特徴とする、請求項１３に記載の輻輳制御方法。
【請求項１５】
前記ＴＡＵ拒絶メッセージは前記端末がサービス要請を再送信するために待機しなければならない時間のバック−オフタイムを含むことを特徴とする、請求項１３に記載の輻輳制御方法。
【請求項１６】
前記バック−オフタイム経過後、  前記端末から接続要請メッセージ（Ａｔｔａｃｈ  Ｒｅｑｕｅｓｔ）を受信する段階をさらに含むことを特徴とする、請求項１５記載の輻輳制御方法。
【請求項１７】
前記拒絶段階の以後、
前記端末のベアラーを中断させるための中断要請メッセージを前記端末をサービングしたＭＭＥに送信する段階をさらに含むことを特徴とする、請求項１１に記載の輻輳制御方法。
【請求項１８】
移動通信システムにおける移動性管理エンティティー（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ、ＭＭＥ）において、
信号を送受信する送受信部；及び
前記送受信部を通じて端末から１つ以上のパケットデータネットワーク（Ｐａｃｋｅｔ  Ｄａｔａ  Ｎｅｔｗｏｒｋ、ＰＤＮ）連結要請受信に応答し、１つ以上のアクセスポイントネーム（Ａｃｃｅｓｓ  Ｐｏｉｎｔ  Ｎａｍｅ、ＡＰＮ）に基づいて１つ以上のＰＤＮに対する１つ以上の連結を構築し、
前記送受信部を通じて前記端末から移動性管理要請信号を受信し―前記移動性管理要請信号は、前記１つ以上のＰＤＮに対する前記端末の前記１つ以上の連結と関連する；
前記移動性管理要請信号の受信に応答し、前記１つ以上のＡＰＮのうちの少なくとも１つに対応する少なくとも１つのＰＤＮの輻輳（ｃｏｎｇｅｓｔｉｏｎ）状態であるか否かを判断し、
前記少なくとも１つのＰＤＮが輻輳状態である場合、前記移動性管理要請信号を拒絶するように制御する制御部；を含み、
前記１つ以上のＰＤＮに対する前記１つ以上の連結が構築された後、前記端末がアイドル状態に遷移すると、前記アイドル状態から活性化状態に遷移するために前記移動性管理要請信号が前記端末によって送信される
ことを特徴とする移動性管理エンティティー。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は移動通信システムにおいて輻輳制御(Ｃｏｎｇｅｓｔｉｏｎ Ｃｏｎｔｒｏｌ)方法に関する。より具体的に本発明はアクセスポイントネーム(Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅ、ＡＰＮ)に基盤してネットワーク輻輳を制御する方法に関する。
【背景技術】
【０００２】
一般的に、移動通信システムは使用者の活動性を保障しながら音声サービスを提供するために開発された。しかし移動通信システムは次第に音声のみならずデータサービスまで領域を確張しており、 現在には高速のデータサービスを提供することができる程度まで発展した。しかし現在サービスが提供されている移動通信システムでは資源の不足現象及び使用者がより高速のサービスを要求するので、より発展した移動通信システムが要求されている。
【０００３】
特に、最近にはスマートフォン使用の増加で単純な通知(Ｎｏｔｉｆｉｃａｔｉｏｎ)メッセージのように少量のデータを短い時間の間隔で周期的に送信する現象が発生している。これによって、端末はアイドル状態(ｉｄｌｅ)と活性(Ａｃｔｉｖｅ)状態が持続的に変更される。このような端末の持続的な状態変化はシグナルの量を爆発的に増加させる。ところが、増加されるシグナル量に比べて送信されるデータの量は少量であるので、オペレーターの利潤(ｒｅｖｅｎｕｅ)は増加しなく、ネットワーク輻輳(ｃｏｎｇｅｓｔｉｏｎ)だけ発生するようになる。このような状況のため輻輳(ｃｏｎｇｅｓｔｉｏｎ)が発生した時、主要利潤ストリーム(ｒｅｖｅｎｕｅ ｓｔｒｅａｍ)サービスであるボイス通信のためのＩＭＳ関連フロー(ｆｌｏｗ)は継続サービスして、 利潤を創出することができないデータ通信関連フロー(ｆｌｏｗ)は選択的にサービスを中断することができる輻輳制御(ｃｏｎｇｅｓｔｉｏｎ ｃｏｎｔｒｏｌ)方法が必要である。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明は、上記のような問題点を解決するために案出されたもので、アクセスポイントネーム(Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅ、ＡＰＮ)に基盤してネットワーク輻輳を制御する方法を提供することをその目的とする。
【課題を解決するための手段】
【０００５】
上記のような問題点を解決するための本発明の移動通信システムにおいて移動性管理エンティティー(Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ、ＭＭＥ)の輻輳制御方法は少なくとも１つ以上のアクセスポイントネーム(Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅ、ＡＰＮ)に対するパケットデータネットワーク(Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ、ＰＤＮ)連結を備える端末から移動性管理要請信号を受信する受信段階、上記ＡＰＮの輻輳(ｃｏｎｇｅｓｔｉｏｎ)状態であるか否かを判断する判断段階及び輻輳状態判断時、上記移動性管理要請を拒絶する拒絶段階を含むことを特徴とする。
【発明の効果】
【０００６】
本発明によれば、ＡＰＮに基盤してネットワークに発生する輻輳(ｃｏｎｇｅｓｔｉｏｎ)をより效率的に制御することができる。また、事業者側面では利潤ストリーム(ｒｅｖｅｎｕｅ ｓｔｒｅａｍ)サービスであるボイス通信のためのＩＭＳ関連フロー(ｆｌｏｗ)は継続サービスして、利潤を創出することができないデータ通信関連フロー(ｆｌｏｗ)は選択的にサービスを中断することができる。
【図面の簡単な説明】
【０００７】
【図１】従来技術によってＡＰＮに基盤して端末のＰＤＮ連結要請を処理する過程を示したフローチャートである。
【図２】移動性管理制御信号であるサービス要請メッセージまたはトラッキング領域アップデートメッセージ処理において、従来ＡＰＮに基盤して輻輳を制御する方法をそのまま適用する場合、発生する問題点を示した図面である。
【図３】移動性管理制御信号に対してＡＰＮに基盤した輻輳制御処理方法適用時、発生することができる従来技術の問題点を示した図面である。
【図４】本発明の１-Ａ実施例による輻輳制御方法を示した図面である。
【図５】本発明の１-Ｂ実施例による輻輳制御方法を示した図面である。
【図６】本発明の１-Ｃ実施例による輻輳制御方法を示した図面である。
【図７】本発明の１-Ｄ実施例による輻輳制御方法を示した図面である。
【図８】本発明の２-Ａ実施例による輻輳制御方法を示した図面である。
【図９】本発明の２-Ｂ実施例による輻輳制御方法を示した図面である。
【発明を実施するための形態】
【０００８】
以下で記述される本発明の輻輳(ｃｏｎｇｅｓｔｉｏｎ)は移動性管理エンティティー、 サービングゲートウェー、ＰＤＮゲートウェーなどのノードに対して単位時間当たり処理することができる作業用量(ｃａｐａｃｉｔｙ)以上の作業用量が割り当てられた場合を意味することができ、 負荷状態(ｏｖｅｒｌｏａｄ)と混用して使用することができることを仮定する。
【０００９】
以下、添付された図面を参照して本発明の好ましい実施例を詳しく説明する。この時、 添付された図面で同一構成要素は可能な同一符号に示されていることに留意しなければならない。また、本発明の要旨を濁すようにできる公知機能及び構成に対する詳細な説明は省略するだろう。
【００１０】
また、本発明の実施例を具体的に説明することにおいて、キャリアアグリゲーション(ｃａｒｒｉｅｒ Ａｇｇｒｅｇａｔｉｏｎ)を支援するＡｄｖａｎｃｅｄ Ｅ-ＵＴＲＡ(あるいは、「ＬＴＥ-Ａ」と称する) システムを主な対象とするはずだが、本発明の主な要旨は類似の技術的背景及びチャンネル形態を有するその他の通信システムにも本発明の範囲を大きく外れない範囲でやや変形で適用可能であり、 これは本発明の技術分野で熟練された技術的知識を有する者の判断として可能であろう。
【００１１】
まず、図1は従来技術によってＡＰＮに基盤して端末のＰＤＮ連結要請を処理する過程を示したフローチャートである。
【００１２】
最近、オペレーターは使用しようとするネットワークを現わすＡＰＮを基盤で負荷、 輻輳(ｏｖｅｒｌｏａｄ、 ｃｏｎｇｅｓｔｉｏｎ)を制御しようとする。このようなオペレーターの要求(ｒｅｑｕｉｒｅｍｅｎｔ)を満足させるために、現在標準では図1で示されたように、セッション制御信号(ｓｅｓｓｉｏｎ ｃｏｎｔｒｏｌ ｓｉｇｎａｌ)を上記ＡＰＮを基準でコントロールする方法を提供している。ここで、上記セッション制御信号はＰＤＮ連結要請(ＰＤＮ  Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔ)、 ベアラーリソース割当て要請(Ｂｅａｒｅｒ Ｒｅｓｏｕｒｃｅ Ａｌｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ)などを含むことができる。
【００１３】
以下では図１のフローチャートを参考してＡＰＮに基盤してセッション制御信号を制御する方法に対して記述する。まず、移動性管理エンティティー(Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ、 ＭＭＥ)１３０はＳ１０５段階で、サービングゲートウェー(Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ、ＳＧＷ)(１４０)及びＰＤＮゲートウェー(ＰＤＮ  Ｇａｔｅｗａｙ、ＰＧＷ)(１５０)から負荷(ｌｏａｄ)状態を報告受けると仮定する。
【００１４】
端末(Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ、ＵＥ)１１０はＳ１１０段階で、連結しようとするＡＰＮを含むＰＤＮ連結要請メッセージ(ＰＤＮ  ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔ)を基地局(ｅＮＢ)１２０を介してＭＭＥ１３０に送信する。それではＭＭＥ１３０はＳ１２０段階で、要請されたＡＰＮに対する負荷(ｌｏａｄ)を確認する。
【００１５】
ＭＭＥ１３０は自分の負荷(ｏｖｅｒｌｏａｄ)が一定臨界値(ｔｈｒｅｓｈｏｌｄ)以上と判断した場合、音声(ｖｏｉｃｅ)通信のためのＩＭＳ関連ＡＰＮに対する要請(Ｒｅｑｕｅｓｔ)またはエンタープライズ(ｅｎｔｅｒｐｒｉｓｅ)サービスのための特定ＶＰＮ関連ＡＰＮに対する要請(Ｒｅｑｕｅｓｔ)のみを受諾(Ａｃｃｅｐｔ)できる。
【００１６】
一方、ＭＭＥ１３０はウェブブラウジング(ｗｅｂ ｂｒｏｗｓｉｎｇ)関連ＡＰＮはバック−オフタイム(ｂａｃｋ−ｏｆｆ ｔｉｍｅ)を与えて拒絶(ｒｅｊｅｃｔ)できる。このために、ＭＭＥ１３０はＳ１３０段階で、ＰＤＮ連結拒絶メッセージ(ＰＤＮ  ｃｏｎｎｅｃｔｉｏｎ ｒｅｊｅｃｔ)を基地局１２０を介して端末１１０に送信する。上記ＰＤＮ連結拒絶メッセージはバック−オフタイムを含み、端末１１０は上記受信したバック−オフタイムが経過した後、Ｓ１４０段階でＰＤＮ連結要請を再送信する。または、端末１１０はＳ１５０段階で拒絶されたＡＰＮ以外のＡＰＮに対するＰＤＮ連結要請を再送信することができる。
【００１７】
図１で記述したＡＰＮに基盤した輻輳制御(Ｃｏｎｇｅｓｔｉｏｎ Ｃｏｎｔｒｏｌ)は特定ＡＰＮに帰属されるＰＤＮ連結関連セッション制御信号に使用が可能である。
【００１８】
最近にはこのようなＡＰＮ基盤輻輳制御方法をサービス要請メッセージ(Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ)、 トラッキング領域アップデートメッセージ(Ｔｒａｃｋｉｎｇ Ａｒｅａｕｐｄａｔｅ、ＴＡＵ)のような移動性管理制御信号(ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｃｏｎｔｒｏｌ ｓｉｇｎａｌ)にも適用しようとする要求(ｒｅｑｕｉｒｅｍｅｎｔ)が発生している。
【００１９】
ところで、移動性管理制御信号は図１に示されたセッション制御信号とは異なり特定ＡＰＮに帰属されるＰＤＮ連結1つにだけ連関されない。言い換えれば、移動性管理制御信号は端末単位で適用される信号(ｓｉｇｎａｌ)であるので、端末が有するすべてのセッション(ｓｅｓｓｉｏｎ)と関連されるので、少なくとも２つ以上のＡＰＮと同時に関連される現象が発生する。これは図２を参考して説明する。
【００２０】
図２は移動性管理制御信号であるサービス要請メッセージ(ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ)またはトラッキング領域アップデート(Ｔｒａｃｋｉｎｇ Ａｒｅａ Ｕｐｄａｔｅ) メッセージ処理において、従来のＡＰＮに基盤して輻輳を制御する方法をそのまま適用する場合、発生する問題点を示した図面である。
【００２１】
まず、端末１１０が複数個のＡＰＮに対してＰＤＮ連結を形成した後、アイドル(ｉｄｌｅ)状態で転換したと仮定する。以後、端末１１０はさらに活性(Ａｃｔｉｖｅ)状態で転換するため、Ｓ２１０段階でサービス要請(Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ)メッセージを基地局１２０を介してＭＭＥ１３０で送信する。上記サービス要請メッセージは１つの端末に対する複数個のＰＤＮ連結要請を含む。
【００２２】
それでは、ＭＭＥ１３０はＳ２２０段階で、端末に対して現在活性化されたＡＰＮの負荷状態を確認する。本例示ではＡＰＮ Ａ及びＡＰＮ Ｃが過負荷(ｏｖｅｒｌｏａｄｅｄ)であり、ＡＰＮ Ｂが正常(ｎｏｔ ｏｖｅｒｌｏａｄｅｄ)であることを仮定する。
【００２３】
このように、一部ＡＰＮに対しては過負荷状態であり(例えば、最大活性ベアラー数以上のベアラー活性状態)、残りＡＰＮに対しては過負荷状態ではない場合、当該の端末の移動性管理制御信号をどのように処理するかに対する問題が発生することができる。
【００２４】
一方、セッション制御信号は端末１１０を現在サービングしている制御ノード(ｃｏｎｔｒｏｌ ｎｏｄｅ) すなわち、ＭＭＥ１３０で処理される。ところが、移動性管理制御信号(ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｓｉｇｎａｌ)は端末１１０の移動状況を知らせることなので、セッション制御信号処理の場合とは異なり端末１１０をサービングする ＭＭＥとは異なる新しいＭＭＥが当該の信号を処理しなければならない状況が発生することができる。すなわち、端末がＴＡＵを送信する時、上記ＴＡＵを受信したＭＭＥが従来のＭＭＥではない新しいＭＭＥであるのに、上記新しいＭＭＥが既に輻輳状態であることができる。
【００２５】
この場合、上記新しいＭＭＥは端末１１０から受信された移動性管理制御信号の処理するか否かを判断しなければならない。ところが、このような判断をＡＰＮ基盤とする場合、 上記新しいＭＭＥは端末が現在使用中のＡＰＮ関連情報を端末をサービングしたＭＭＥから獲得すべきであり、基本ＭＭＥで連結されたＳＧＷへの制御プレーン(ｃｏｎｔｒｏｌ ｐｌａｎｅ)を新しいＭＭＥに変更した後、ＡＰＮを基盤に移動性管理制御信号(例えば、 ＴＡＵ)の拒絶するか否かを決定しなければならない。したがって拒絶(ｒｅｊｅｃｔ)決定のために必要なオペレーションによる負荷(ｏｖｅｒｌｏａｄ)が発生することができる。上記の従来技術の問題点が図３に示される。
【００２６】
図３は移動性管理制御信号に対してＡＰＮに基盤した輻輳制御処理方法適用時、発生することができる従来技術の問題点を示された図面である。
【００２７】
まず、端末１１０はＳ３１０段階で、トラッキング領域アップデート(ＴＡＵ)メッセージを基地局１２０を介して新規のＭＭＥ１３０Ａに送信する。ここで、上記新規のＭＭＥ１３０Ａは端末１１０をサービングした従来のＭＭＥ１３０Ｂと異なるＭＭＥであり、輻輳状態(ｃｏｎｇｅｓｔｉｏｎ)であることを仮定する。
【００２８】
それでは新規のＭＭＥ１３０Ａは自分が輻輳状態にもかかわらず、 端末１１０から送信されたＴＡＵメッセージを処理するためにＳ３２０段階でＵＥコンテキスト要請メッセージ(ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔ)を従来のＭＭＥ１３Ｂに送信する。それでは新規のＭＭＥ１３０ＡはＳ３３０段階で、 ＵＥコンテキスト応答メッセージ(ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｓｐｏｎｓｅ)を受信し、これに対する確認メッセージをＳ３４０段階で送信する。
【００２９】
それでは新規ＭＭＥ１３０ＡはＵＥコンテキストから端末に対して現在活性化された ＡＰＮを確認することができ、Ｓ３５０段階で各ＡＰＮの負荷状態を確認する。本例示ではＡＰＮ Ａ及びＡＰＮ Ｃが過負荷状態であり、ＡＰＮ Ｂが正常状態なのを仮定する。
【００３０】
そして新規のＭＭＥ１３０Ａは従来のＭＭＥ１３０ＢとＳＧＷ１４０間に連結された制御プレーン(ｃｏｎｔｒｏｌ ｐｌａｎｅ)を解除し、自分とＳＧＷ１４０間に制御プレーンを形成するための過程をＳ３６０段階以下で行う。
【００３１】
ところで、新規のＭＭＥ１３０ＡとＳＧＷ１４０間に制御プレーンを形成すると言っても、 いずれにしても新規のＭＭＥ１３０Ａは輻輳状態なので端末１１０から送信されたＴＡＵを拒絶しなければならない。すなわち、端末１１０のＴＡＵを拒絶するため、輻輳状態である新規のＭＭＥ１３０ＡがＳ３２０以下の段階を行うべきという不合理な状況が発生するようになる。
【００３２】
本発明は図１乃至図３で記述した問題点を解決するために案出されたもので、ＡＰＮに基盤して輻輳を效率的に制御することができる方案を提案する。
【００３３】
まず、以下で記述される本発明の実施例では複数個のＡＰＮに対するＰＤＮ連結を備える端末がアイドル(ｉｄｌｅ)状態進入後また活性(Ａｃｔｉｖｅ)状態で遷移する場合、上記複数個のＰＤＮ連結を皆復旧させるか否かに対して記述する。この場合、本発明の第1 実施例では移動性管理(Ｍｏｂｉｌｉｔｙ Ｍaｎaｇｅｍｅｎｔ)を処理するコアネットワークノード(すなわち、ＭＭＥ)が変更されない場合の解決方案に対して記述する。そして本発明の第２実施例では移動性管理を処理するコアネットワークが変更された場合の解決方案に対して記述する。
<第1 実施例>
【００３４】
以下で記述される本発明の第1実施例では移動性管理(Ｍｏｂｉｌｉｔｙ Ｍaｎaｇｅｍｅｎｔ)を処理するコアネットワークノード(すなわち、ＭＭＥ)が変更されない場合の輻輳制御(ｃｏｎｇｅｓｔｉｏｎ ｃｏｎｔｒｏｌ)方法に対して記述する。特に、ＭＭＥの移動性管理制御信号処理方法によって１−Ａ実施例乃至１-Ｄ実施例で区分して記述するようにする。
【００３５】
第1 実施例では端末のサービス要請メッセージ(Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ)またはＴＡＵを受信したＭＭＥが変更されなかったので、ＭＭＥは端末の加入情報(ｓｕｂｓｃｒｉｐｔｉｏｎ)を含んだ端末のコンテキストを備えることで仮定することができる。
【００３６】
図４は本発明の１−Ａ実施例による輻輳制御方法を示した図面である。
【００３７】
上記端末の加入情報には予め決定されたデフォルトＡＰＮ(Ｄｅｆａｕｌｔ ＡＰＮ)情報が含まれる。上記デフォルトＡＰＮ情報は端末が活性状態で基本的に使用するＰＤＮ連結に対する情報である。
【００３８】
本発明の１−Ａ実施例では上記デフォルトＡＰＮの輻輳状態を基準に移動性管理制御信号処理するか否かを決定する。すなわち、端末から移動性管理制御信号を受信したＭＭＥはデフォルトＡＰＮが輻輳状態であれば、当該の移動性管理制御信号を拒絶する。そしてＭＭＥは当該の拒絶メッセージにデフォルトＡＰＮに対する輻輳が解消された時点に対する予測(ｅｓｔｉｍａｔｉｏｎ)を基盤でバック−オフタイムを提供する。
【００３９】
上記の本発明の１−Ａ実施例に対する具体的な遂行過程を図４を参考して説明する。
【００４０】
Ｓ４１０段階で、端末４１０に対して複数個のＡＰＮに対するＰＤＮ連結が形成されることを仮定する。
【００４１】
それでは、端末４１０はＳ４２０段階で、アイドル状態から活性状態に遷移するためにサービス要請メッセージ(Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ)を基地局４２０を介してＭＭＥ４３０に送信する。それでは、ＭＭＥ４３０はＳ４３０段階で、端末４１０の加入情報からデフォルトＡＰＮ及び上記デフォルトＡＰＮの状態を確認する。
【００４２】
ＭＭＥ４３０はＳ４４０段階でデフォルトＡＰＮが輻輳状態なのを確認し、Ｓ４５０段階でサービス拒絶メッセージ(Ｓｅｒｖｉｃｅ Ｒｅｊｅｃｔ)を端末４１０に送信する。上記サービス拒絶メッセージはデフォルトＡＰＮ及びバック−オフタイムを含む。端末は上記バック−オフタイムが経過した以後に、サービス要請メッセージを再送信する。
【００４３】
図５は本発明の１−Ｂ実施例による輻輳制御方法を示した図面である。
【００４４】
本発明の１−Ｂ実施例では活性化されたＡＰＮに対するＰＤＮ連結のうちのいずれか１つでも輻輳状態の場合、ＭＭＥは端末から受信した移動性管理制御信号を拒絶する。そしてＭＭＥは輻輳状態であるＡＰＮ及び上記輻輳状態であるＡＰＮそれぞれに対するバック−オフタイムを含む拒絶メッセージを端末に送信する。この場合、 ＭＭＥは拒絶するＡＰＮと、バック−オフタイムの中で最大値を有するバック−オフタイムを代表値として上記拒絶メッセージを端末に送信することができる。
【００４５】
上記の本発明の１−Ｂ実施例に対する具体的な遂行過程を図５を参考して説明する。
【００４６】
Ｓ４１０段階で、端末４１０に対して複数個のＡＰＮに対するＰＤＮ連結が形成されることを仮定する。
【００４７】
それでは、端末４１０はＳ５２０段階で、アイドル状態から活性状態で遷移するためにサービス要請メッセージ(Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ)を基地局４２０を介してＭＭＥ４３０で送信する。それでは、ＭＭＥ４３０はＳ５３０段階で、端末４１０に対して活性化されたＰＤＮ連結の状態を確認する。
【００４８】
そしてＭＭＥ４３０はＳ５４０段階で、上記活性化されたＰＤＮ連結のＡＰＮの中で少なくともいずれか１つのＰＤＮ連結が輻輳状態なのを確認する。それではＭＭＥ４３０はＳ５５０段階で、サービス拒絶メッセージ(Ｓｅｒｖｉｃｅ Ｒｅｊｅｃｔ)を端末４１０に送信する。上記サービス拒絶メッセージは拒絶されるＡＰＮ及び上記拒絶されるＡＰＮそれぞれに対するバック−オフタイムを含む。端末４１０は上記バック−オフタイムが経過した以後に、サービス要請メッセージを再送信する。
【００４９】
図６は本発明の１−Ｃ実施例による輻輳制御方法を示した図面である。
【００５０】
本発明の１−Ｃ実施例では正常状態であるＡＰＮに対するＰＤＮ連結だけ活性化させ、 輻輳状態であるＡＰＮに対するＰＤＮ連結は非活性化させる。この時、 非活性化されたＰＤＮ連結関連ＡＰＮそれぞれに対しては一部サービス拒絶または受諾メッセージ(Ｐａｒｔｉａｌ Ｓｅｒｖｉｃｅ Ｒｅｊｅｃｔ／ａｃｃｅｐｔ)にバック−オフタイムを含ませてＮＡＳメッセージを介して端末で送信する。この場合、上記一部サービス拒絶または受諾メッセージは拒絶されたＡＰＮと、上記ＡＰＮに該当するバック−オフタイムと、ＡＰＮの過負荷のため部分拒絶されたことを知らせる原因(ｃａｕｓｅ)を含む。
【００５１】
これによって、端末は受信したバック−オフタイムの間、当該のＡＰＮに対するＰＤＮ連結を要請しない。もし、ＭＭＥが端末にバック−オフタイムを提供しない場合には、 端末は予め設定されたデフォルト値を用いて、当該のデフォルト値の経過後、ＰＤＮ連結を要請する。
【００５２】
上記の本発明の１−Ｃ実施例に対する具体的な遂行過程を図６を参考して説明する。
【００５３】
Ｓ６１０段階で、端末４１０に対して複数個のＡＰＮに対するＰＤＮ連結が形成されることを仮定する。
【００５４】
それでは、端末４１０はＳ６２０段階で、アイドル状態から活性状態で遷移するためにサービス要請メッセージ(Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ)を基地局４２０を介してＭＭＥ４３０で送信する。それでは、ＭＭＥ４３０はＳ６３０段階で、端末４１０に対して活性化されたたＰＤＮ連結の状態を確認する。そしてＭＭＥ４３０はＳ６３５段階で、輻輳状態であるＡＰＮに対するＰＤＮ連結と、正常状態であるＡＰＮに対するＰＤＮ連結を分類する。本発明の実施例ではＡＰＮ Ａ及びＡＰＮ Ｃに対するＰＤＮ連結が過負荷(輻輳)状態であり、 ＡＰＮ Bに対するＰＤＮ連結は正常状態なのを仮定する。
【００５５】
そしてＭＭＥ４３０はＳ６４０段階で、初期コンテキスト設定要請メッセージを基地局４２０に送信する。上記初期コンテキスト設定要請メッセージはＡＰＮ Ｂに対するＰＤＮ連結だけ活性化させ、残りＡＰＮに対するＰＤＮ連結要請は拒絶するという一部サービス拒絶(Ｐａｒｔｉａｌ Ｓｅｒｖｉｃｅ Ｒｅｊｅｃｔ)を含む。ここで、上記一部サービス拒絶は拒絶されたＡＰＮ及び拒絶された各ＡＰＮに対するバック−オフタイムを含むことができる
【００５６】
それでは基地局４２０はＳ６４５段階で、ラジオベアラー形成メッセージ(Rａｄｉо ＢBｅｒｅｒ Ｅｓｔａｂｌｉｓｈｍｅｎｔ)を端末４１０に送信する。上記ラジオベアラー形成メッセージはＡＰＮ Ｂに対するＰＤＮ連結だけ活性化させ、残りＡＰＮに対するＰＤＮ連結要請は拒絶するという一部サービス拒絶(Ｐａｒｔｉａｌ Ｓｅｒｖｉｃｅ Ｒｅｊｅｃｔ)を含む。ここで、上記一部サービス拒絶は拒絶されたＡＰＮ及び拒絶された各ＡＰＮに対するバック−オフタイムを含むことができる
【００５７】
次いでＭＭＥ４３０は過負荷状態であるＡＰＮ Ａ及びＡＰＮ Ｃに対するＰＤＮ連結を削除する過程を行う。このために、ＭＭＥ４３０はＳ６５０段階で、 ＡＰＮ Ａに対する ＰＤＮ連結を削除するために、 セッション削除要請メッセージ(Ｄｅｌｅｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ)をＳＧＷ４４０に送信する。それではＳＧＷ４４０はＳ６５５段階乃至Ｓ６６０段階を介してセッション削除要請及び応答をＰＧＷ Ａ(４５０Ａ)と送受信する。当該のセッションが削除された後、 ＭＭＥ４３０はＳ６６５段階で、ＳＧＷ４４０からセッション削除応答メッセージを受信する。
【００５８】
同様にＭＭＥ４３０はＳ６７０段階で、 ＡＰＮ Ｃに対するＰＤＮ連結を削除するために、 セッション削除要請メッセージ(Ｄｅｌｅｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ)をＳＧＷ４４０に送信する。それではＳＧＷ４４０はＳ６７５段階乃至Ｓ６８０段階を介してセッション削除要請及び応答をＰＧＷ Ｃ(４５０Ａ)と送受信する。該当のセッションが削除された後、ＭＭＥ４３０はＳ６８５段階で、ＳＧＷ４４０からセッション削除応答メッセージを受信する。
【００５９】
一方、 １−Ｃ実施例によって、 一部サービス拒絶または受諾手続きが進行された場合、 端末４１０のＥＰＳベアラー情報も拒絶されたベアラーを削除するアップデート過程が行われるべきである。このようなアップデート過程は下記の３つ方法のうちのいずれか１つに行われることができる。
【００６０】
第１に、 端末は拒絶されたＡＰＮに対するＰＤＮ連結に該当するＥＰＳベアラーをローカリー(ｌｏｃａｌｌｙ)非活性化させることができる。第２に、一部サービス拒絶または受諾メッセージは追加的に活性化されるベアラーに対する情報または解除(ｒｅｌｅａｓｅ)されたベアラーに対する情報の中で少なくとも１つを含み、上記メッセージを受信した端末が端末内に貯蔵存されたＥＰＳベアラー情報をアップデートさせることができる。第３に、端末はＲＲＣ再設定(ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ)を介して活性化されたベアラー以外のベアラーをローカルリー非活性化させることができる。
【００６１】
図７は本発明の１−Ｄ実施例による輻輳制御方法を示した図面である。
【００６２】
本発明の１−Ｄ実施例では端末は自分が送信するデータと関連されたＡＰＮを明示してサービス要請メッセージを送信し、 ＭＭＥは上記明示されたＡＰＮに対するＰＤＮ連結の輻輳状態によってサービス要請受諾するか否かを決定する。
【００６３】
送信しようとするデータ発生時、アイドル状態の端末はサービス要請を介して活性状態に遷移されることができるが、 上記データが輻輳状態であるＡＰＮに対するＰＤＮ連結に送信されなければならない場合が発生することができる。１−Ｃ実施例によれば一部サービス要請受諾または拒絶によってベアラーが部分的に生成されるのに、 端末が送信しようとするデータに係るベアラーが形成されることができなければ、 このような一部サービス要請受諾または拒絶が意味がないことがある。
【００６４】
１−Ｄ実施例ではこのような点を考慮し、 端末はサービス要請メッセージに活性化が必要な少なくとも１つのＡＰＮを明示する。これを受信したＭＭＥは明示されたＡＰＮのうちのいずれか１つのＡＰＮでも輻輳状態であれば、当該のサービス要請を拒絶する。この場合、 拒絶メッセージは１−Ｂ実施例のように拒絶されたＡＰＮ及び拒絶されたＡＰＮそれぞれに対するバック−オフタイムまたは最も長い代表バック−オフタイムを含むことができる。
【００６５】
もし、サービス要請メッセージに明示されたＡＰＮが全部輻輳状態ではなくて、 明示されないＡＰＮだけ輻輳状態であれば、ＭＭＥは輻輳状態のＡＰＮだけ拒絶する一部サービス拒絶または受諾メッセージを端末で送信する。同時に、ＭＭＥは拒絶されたＡＰＮと拒絶されたＡＰＮそれぞれに対するバック−オフタイムを上記メッセージに含ませた後、 セッション削除要請を介して当該のＰＤＮ連結を非活性化させる。
【００６６】
上記一部サービス拒絶または受諾メッセージを受信した端末はバック−オフタイムが経過する前には、当該のＡＰＮに対するＰＤＮ連結要請を送信しない。
【００６７】
上記の本発明の１−Ｄ実施例に対する具体的な遂行過程を図７を参考して説明する。
【００６８】
Ｓ７１０段階で、 端末４１０に対して複数個のＡＰＮに対するＰＤＮ連結が形成されることを仮定する。
【００６９】
それでは、端末４１０はＳ７７２０段階で、活性化させようとする少なくとも１つのＡＰＮを明示したサービス要請メッセージ(Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ)を基地局４２０を介してＭＭＥ４３０で送信する。それでは、ＭＭＥ４３０はＳ７３０段階で、端末４１０に対して活性化されたＰＤＮ連結の状態を確認する。
【００７０】
Ｓ７４０段階で、ＭＭＥ４３０は端末４１０が明示したＡＰＮの輻輳状態であるか否かを判断する。もし、端末４１０が明示したＡＰＮのうちのいずれか１一つでも輻輳状態であれば、 ＭＭＥ４３０はＳ７５０段階で進行してバック−オフタイムを含むサービス拒絶メッセージを端末４１０に送信する。
【００７１】
もし、明示されたＡＰＮは共に正常状態であれば、ＭＭＥ４３０はＳ７６０段階で進行して明示されないＡＰＮだけ輻輳状態なのを確認する。それではＭＭＥ４３０はＳ７７０ 段階で進行し、部分サービス拒絶または受諾メッセージを端末４１０に送信する。上記部分サービス拒絶または受諾メッセージは拒絶されたＡＰＮ及び上記拒絶されたＡＰＮそれぞれに対するバック−オフタイムを含む。
【００７２】
上記の本発明の１−Ｄ実施例で、 端末４１０はサービス要請メッセージにＡＰＮの代わりに当該のＥＰＳベアラーIＤを含んで送信することもできる。この場合、ＭＭＥ４３０は貯蔵されているＵＥコンテキスト内の情報を基盤で当該のＥＰＳベアラーに該当するＡＰＮを捜した後、そのＡＰＮに対する輻輳状況を判断して受諾または拒絶を決定する。
【００７３】
もし、１−Ｄ実施例をＴＡＵに対して適用する場合、サービス要請メッセージに含まれたＡＰＮは送信のためにバッファリングされたデータを送信するＰＤＮ連結に対するＡＰＮではなく、端末で拒絶または受諾の判断基準で使用するように設定(ｃｏｎｆｉｇｕｒａｔｉｏｎ)されているＡＰＮである。
【００７４】
一方、1−Ａ実施例乃至１−Ｄ実施例に対して、ＡＰＮの輻輳状態は端末別で適用されることができる。すなわち、同一インターネットＡＰＮであっても適用料金制の加入情報(ｓｕｂｓｃｒｉｐｔｉｏｎ)にしたがって一部端末に対しては輻輳(ｃｏｎｇｅｓｔｉｏｎ)が発生したＡＰＮと判断されて他の一部端末に対しては輻輳(ｃｏｎｇｅｓｔｉｏｎ)が発生しないＡＰＮで判断されることができる。
<第２実施例>
【００７５】
以下で記述される本発明の第２実施例では移動性管理を処理するコアネットワークノード(すなわち、ＭＭＥ)が変更された場合の輻輳制御(ｃｏｎｇｅｓｔｉｏｎ ｃｏｎｔｒｏｌ)方法に対して記述する。特に、ＭＭＥの移動性管理制御信号処理方法によって２-Ａ及び２−Ｂ実施例で区分して記述する。
【００７６】
端末が移動してキャンピング(ｃａｍｐｉｎｇ)したセル(ｃｅｌｌ)が変更され、 このようなセルの変更がＭＭＥの変更を引き起こした場合を仮定する。この場合、 端末は移動性管理制御信号であるトラッキング領域アップデート要請メッセージ(ｔｒａｃｋｉｎｇ ａｒｅａ ｕｐｄａｔｅ Ｒｅｑｕｅｓｔ)を変更された新しいＭＭＥで送信する。この時、新しいＭＭＥが輻輳状態であれば、ＡＰＮの輻輳であるか否かにしたがってＴＡＵの受諾または拒絶を決めなければならないのに、 輻輳状態である新しいＭＭＥが既存ＭＭＥに端末のコンテキスト(ｃｏｎｔｅｘｔ)を取って来る前にはＴＡＵの受諾または拒絶を決定することができない。
【００７７】
また、端末のコンテキストを取って来たら既存ＭＭＥではＳＧＷとの制御信号連結を削除するはずだから、上記制御信号連結を新しいＭＭＥに変更させるアップデート作業を必ず遂行しなければならない。遂行しなかったら、 端末のベアラー情報を有するＳＧＷはどんなＭＭＥでも連結にならないからペイジング遂行が不可能になることもできる。
【００７８】
以下で記述される２−Ａ及び２−Ｂ実施例では上記の問題点を解決することができる方案を提示する。
【００７９】
図８は、本発明の２−Ａ実施例による輻輳制御方法を示した図面である。
【００８０】
端末からＴＡＵを受信した新規のＭＭＥは上記ＴＡＵに含まれたＧＵＴＩ(Ｇｌｏｂａｌｌｙ Ｕｎｉｑｕｅ Ｔｅｍｐｏｒａｒｙ ＩＤ)を利用して従来のＭＭＥを捜す。上記ＧＵＴＩはＭＭＥが端末に割り当てて、ＧＵＭＭＥI(Ｇｌｏｂａｌｌｙ Ｕｎｉｑｕｅ ＭＭＥ ＩＤ)とＭ−ＴＭＳＩ(ＭＭＥ−ＴＭＳＩ)を含む。ここで、上記ＧＵＭＭＥはＭＭＥに対する識別情報であり、 ＭＭＥ−ＴＭＳＩはＭＭＥ内にある端末に対する識別情報である。
【００８１】
そして新規のＭＭＥは従来のＭＭＥに端末のコンテキストを要請して獲得した後、 上記の１−Ａまたは１−Ｂ実施例によって輻輳を制御する。すなわち、新規のＭＭＥは端末のコンテキストに含まれたデフォルトＡＰＮが輻輳状態とか(1-Ａ実施例)、または活性ＡＰＮのうちのいずれか１つでも輻輳状態であれば、端末のＴＡＵを拒絶する。この場合、ＴＡＵ拒絶メッセージは輻輳状態であるＡＰＮ及び輻輳状態のＡＰＮそれぞれに対するバック−オフタイムを含む。
【００８２】
そして上記ＴＡＵ拒絶メッセージを送信した新規のＭＭＥは当該のＡＰＮに対するＰＤＮ連結を非活性化させる。このために、 新規のＭＭＥはセッション削除要請メッセージ(Ｄｅｌｅｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ)をＳＧＷで送信する。
【００８３】
ＴＡＵ拒絶メッセージを受信した端末はバック−オフタイム経過後、 ＴＡＵではない接続要請(Ａｔｔａｃｈ Ｒｅｑｕｅｓｔ)を介してネットワーク接続を試みる。この時、端末はＴＡＵ拒絶メッセージに複数個のＡＰＮに対するバック−オフタイムが含まれた場合、 デフォルトＡＰＮに対するバック−オフタイム経過後、接続(ａｔｔａｃｈ)を試みる。一方、 デフォルトＡＰＮがＴＡＵ拒絶メッセージに含まれない場合、端末は直ちに接続要請メッセージ(Ａｔｔａｃｈ Ｒｅｑｕｅｓｔ)を介してネットワーク接続を試みるが、拒絶されたＡＰＮに対しては決定されたバック−オフタイム経過後にだけＰＤＮ連結要請メッセージを送信する。
【００８４】
上記の本発明の２−Ａ実施例に対する具体的な遂行過程を図８を参考して説明する。
【００８５】
端末４１０が移動してキャンピングしたセル及び上記セルを担当するＭＭＥが変更された場合、端末４１０はＳ８０５段階でＴＡＵを新規のＭＭＥ４３０Ａに送信する。それでは新規のＭＭＥ４３０ＡはＳ８１０段階で、 端末４１０に対する環境情報を獲得するためにＵＥコンテキスト要請メッセージ(ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔ)を従来のＭＭＥ４３０Ｂに送信する。それでは従来ＭＭＥ４３０ＢはＳ８１５段階でＵＥコンテキストを含むＵＥコンテキスト応答メッセージ(ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｓｐｏｎｓｅ)を新規のＭＭＥ４３０Ａに送信し、Ｓ８２０段階でこれに対する応答を受信する。
【００８６】
それでは新規ＭＭＥ４３０ＡはＳ８２５段階で、端末４１０のコンテキストを介して端末４１０に対して活性化されたＰＤＮ連結及び上記ＰＤＮ連結に対する状態を確認する。そして新規のＭＭＥ４３０ＡはＳ８３０段階で、 デフォルトＡＰＮに対するＰＤＮ連結が輻輳状態とかまたはいずれか１つのＡＰＮに対するＰＤＮ連結が輻輳状態なのを確認する。
【００８７】
それでは新規のＭＭＥ４３０ＡはＳ８３５段階で、ＴＡＵ拒絶メッセージ(Ｔｒａｃｋｉｎｇ Ａｒｅａ Ｕｐｄａｔｅ Ｒｅｊｅｃｔ)を基地局４２０を介して端末４１０で送信する。この場合、ＴＡＵ拒絶メッセージは輻輳状態であるＡＰＮ及び輻輳状態のＡＰＮ それぞれに対するバック−オフタイムを含む。
【００８８】
そして新規のＭＭＥ４３０ＡはＳ８４０段階で、ＡＰＮ Ａ、Ｂ、Ｃそれぞれに対するＰＤＮ連結を削除するためのセッション削除要請メッセージ(Ｄｅｌｅｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ)をＳＧＷ４４０に送信する。それでは、ＳＧＷ４４０はＳ８４５、Ｓ８５０、Ｓ８５５それぞれの段階で、各ＰＧＷに対してベアラー修正要請メッセージ(Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ)を送信し、これに対する応答を受信して端末に対して形成されたＰＤＮ連結を削除する。
【００８９】
一方、端末４１０はバック−オフタイム経過後、 Ｓ８６０段階で接続要請メッセージ(Ａｔｔａｃｈ Ｒｅｑｕｅｓｔ)を新規のＭＭＥ４３０Ａに送信してネットワーク接続を試みる。
【００９０】
一方、上記の２−Ａ実施例に対する変形された実施例も可能である。例えば、新規のＭＭＥ４３０ＡはＴＡＵ拒絶メッセージにバック−オフタイム、またはＡＰＮとバック−オフタイムを同時に含ませることができる。これと同時に上記新規のＭＭＥ４３０ＡはＳＧＷ４４０でセッション削除要請メッセージを送信するのではなく、 ベアラーアップデート要請メッセージ(Ｕｐｄａｔｅ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ)を送信して新規のＭＭＥ４３０Ａで制御プレーンが連結されるようにアップデートすることもできる。
【００９１】
図９は本発明の２−Ｂ実施例による輻輳制御方法を示した図面である。
【００９２】
２−Ａ実施例によれば、新規のＭＭＥ４３０Ａが輻輳状態にもかかわらず、 端末のコンテキスト処理及びＳＧＷとのセッションを処理しなければならない。また、拒絶された端末はいつも接続(Ａｔｔａｃｈ)過程を遂行しなければならないのに、上記接続過程でのシグナリングはＴＡＵ処理過程でのシグナリングよりずっと複雑で負荷が多い。したがって輻輳状態を外れた新規のＭＭＥ４３０Ａが端末の接続過程を処理しながらさらに輻輳状態に進入する可能性が存在する。これを解決するためには輻輳状態の新規のＭＭＥ４３０Ａが輻輳状態から外れるまで端末関連処理を演技することができる方案が必要である。
【００９３】
本発明の２−Ｂ実施例ではこれに対する解決策を提示する。このために、新規のＭＭＥ４３０Ａは自分が輻輳状態から脱するまで端末関連処理をゆずるように、 端末に対してはバック−オフタイムを含むＴＡＵ拒絶メッセージを送信して端末が追加的な要請を送信しないようにする。これと同時に、新規のＭＭＥ４３０Ａは従来のＭＭＥ４３０Ｂに端末のベアラーを中断(ｓｕｓｐｅｎｄ)させるように要請してダウンリンクデータパケットが捨てられるようにしてペイジングオーバーヘッドが発生しないようにする。
【００９４】
上記の本発明の２−Ｂ実施例を図９を参考して説明する。
【００９５】
まず、端末４１０はＳ９０５段階で、デフォルトＡＰＮ及びＧＵＴＩ情報を含むＴＡＵを基地局４２０を介して新規のＭＭＥ４３０Ａで送信する。それでは、新規のＭＭＥ４３０ＡはＳ９１０段階で、上記デフォルトＡＰＮの輻輳状態を確認する。もし、デフォルトＡＰＮが輻輳状態であれば、新規のＭＭＥ４３０ＡはＳ９１５段階からバック−オフタイムを含むＴＡＵ拒絶メッセージを基地局４２０を介して端末４１０で送信する。
【００９６】
これと同時に、新規ＭＭＥ４３０ＡはＳ９２０段階で上記端末４１０を管理した従来のＭＭＥ４３０Ｂに中断要請メッセージ(Ｓｕｓｐｅｎｄ Ｒｅｑｕｅｓｔ)を送信する。それでは従来のＭＭＥ４３０ＢはＳ９２０段階で、ＳＧＷ４４０に中断通知メッセージ(Ｓｕｓｐｅｎｄ Ｎｏｔｉｆｉｃａｔｉｏｎ)を送信して端末４１０のダウンリンクデータを処理しない中断状態で転換する。
【００９７】
この場合、新規のＭＭＥ４３０Ａが従来のＭＭＥ４３０Ｂに送信る中断要請メッセージはバック−オフタイムをデフォルトタイム(ｄｅｆａｕｌｔ ｔｉｍｅ)で含むこともできる。上記デフォルトタイムが含まれる場合、 当該のデフォルトタイムが経過した後にも従来ＭＭＥ４３０Ｂが端末４１０のコンテキストに対する要請を受信することができなかった場合、 上記従来のＭＭＥ４３０Ｂは該当の端末４１０のコンテキストを削除し、該当のベアラーもＳＧＷで非活性化(ｄｅａｃｔｉｖａｔｉｏｎ)させて端末を登録解除状態(ｄｅ−ｒｅｇｉｓｔｒａｔｉｏｎ ｓｔａｔｅ)で転換する。
【００９８】
一方、中断要請メッセージにデフォルトタイムが含まれない場合には従来動作によって ｕｎｒｅａｃｈａｂｌｅ タイマーが満了した後、端末は登録解除状態で転換する。
【００９９】
本明細書と図面に開示された本発明の実施例は本発明の記述内容を容易に説明した発明の理解を助けるために特定例を提示したものであるだけで、 本発明の範囲を限定しようとするものではない。ここに開示された実施例以外にも本発明の技術的思想に基づいた他の変形例が実施可能であるということは本発明が属する技術分野で通常の知識を有する者に自明なものである。
【符号の説明】
【０１００】
１１０  端末（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ、ＵＥ）
１２０  基地局
１３０  移動性管理エンティティー
１４０  サービングゲートウェー（Ｓｅｒｖｉｎｇ  Ｇａｔｅｗａｙ、ＳＧＷ）
１５０  ゲートウェー（ＰＤＮ  Ｇａｔｅｗａｙ、ＰＧＷ）
４１０  端末
４２０  基地局
【図１】
0005968908.tif 000002
【図２】
0005968908.tif 000003
【図３】
0005968908.tif 000004
【図４】
0005968908.tif 000005
【図５】
0005968908.tif 000006
【図６】
0005968908.tif 000007
【図７】
0005968908.tif 000008
【図８】
0005968908.tif 000009
【図９】
0005968908.tif 000010