特許 5968908 移動通信システムにおける輻輳制御方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5968908

(24)【登録日】2016年7月15日

(45)【発行日】2016年8月10日

(54)【発明の名称】移動通信システムにおける輻輳制御方法

(51)【国際特許分類】

   H04W 28/10 20090101AFI20160728BHJP

   H04W 8/06 20090101ALI20160728BHJP

   H04W 60/00 20090101ALI20160728BHJP

   H04W 48/06 20090101ALI20160728BHJP

【ＦＩ】

   H04W28/10

   H04W8/06

   H04W60/00

   H04W48/06

【請求項の数】18

【全頁数】18

(21)【出願番号】特願2013-548347(P2013-548347)

(86)(22)【出願日】2012年1月3日

(65)【公表番号】特表2014-505421(P2014-505421A)

(43)【公表日】2014年2月27日

(86)【国際出願番号】KR2012000041

(87)【国際公開番号】WO2012093832

(87)【国際公開日】20120712

【審査請求日】2015年1月5日

(31)【優先権主張番号】10-2011-0000103

(32)【優先日】2011年1月3日

(33)【優先権主張国】KR

(73)【特許権者】

【識別番号】503447036

【氏名又は名称】サムスン エレクトロニクス カンパニー リミテッド

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(72)【発明者】

【氏名】ソン・ヤン・チョ

(72)【発明者】

【氏名】ボム・シク・ペ

(72)【発明者】

【氏名】チェ・グウォン・リム

【審査官】 齋藤 浩兵

(56)【参考文献】

【文献】 特表２０１３−５２６１６０（ＪＰ，Ａ）

【文献】 国際公開第２０１１／１３０９１２（ＷＯ，Ａ１）

【文献】 3GPP TS 23.401 V10.2.0，URL:http://www.3gpp.org/ftp/Specs/archive/23_series/23.401/23401-a20.zip，２０１０年１２月，pp.20,28-33,84-90,108,109

【文献】 CATT，"Rejecting Service Request Procedure"[online]，3GPP TSG-SA WG2#81 S2-104874，URL:http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_81_Prague/Docs/S2-104874.zip，２０１０年１０月１５日

【文献】 Nokia Siemens Networks, Nokia, ETRI, Ericsson, ST-Ericsson, Alcatel-Lucent，"APN Congestion Control"[online]，3GPP TSG-SA WG2#82 S2-105494，URL:http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_82_Jacksonville/Docs/S2-105494.zip，２０１０年１１月１９日

【文献】 CATT，"Discussion on APN based congestion control"[online]，3GPP TSG-CT WG1#67 C1-103995，URL:http://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_67_Barcelona/docs/C1-103995.zip，２０１０年１０月１５日

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４− ７／２６

Ｈ０４Ｗ ４／００−９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−２

ＣＴ ＷＧ１

(57)【特許請求の範囲】

【請求項1】

移動通信システムにおける移動性管理エンティティー（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ、ＭＭＥ）の輻輳制御方法において、
端末から１つ以上のパケットデータネットワーク（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ、ＰＤＮ）連結要請受信に応答し、１つ以上のアクセスポイントネーム（Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅ、ＡＰＮ）に基づいて１つ以上のＰＤＮに対する１つ以上の連結を構築する構築段階；
前記端末から移動性管理要請信号を受信する受信段階―前記移動性管理要請信号は、前記１つ以上のＰＤＮに対する前記端末の前記１つ以上の連結と関連する；
前記移動性管理要請信号の受信に応答し、前記１つ以上のＡＰＮのうちの少なくとも１つに対応する少なくとも１つのＰＤＮの輻輳（ｃｏｎｇｅｓｔｉｏｎ）状態であるか否かを判断する判断段階；及び
前記少なくとも１つのＰＤＮが輻輳状態である場合、前記移動性管理要請信号を拒絶する拒絶段階；を含み、
前記１つ以上のＰＤＮに対する前記１つ以上の連結が構築された後、前記端末がアイドル状態に遷移すると、前記アイドル状態から活性化状態に遷移するために前記移動性管理要請信号が前記端末によって送信される
ことを特徴とする輻輳制御方法。

【請求項2】

前記移動性管理要請信号は、サービス要請（Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ）メッセージであることを特徴とする、請求項１に記載の輻輳制御方法。

【請求項3】

前記判断段階は、
前記端末に対して設定されたデフォルトＡＰＮの輻輳状態であるか否かを判断し、
前記拒絶段階は、
前記デフォルトＡＰＮが輻輳状態で判断される場合、 サービス要請拒絶メッセージを前記端末に送信することを特徴とする、請求項２に記載の輻輳制御方法。

【請求項4】

前記サービス要請拒絶メッセージは、
前記端末が前記サービス要請を再送信するために待機しなければならない時間のバック−オフタイムを含むことを特徴とする、請求項３に記載の輻輳制御方法。

【請求項5】

前記移動性管理要請信号はサービス要請であり、
前記判断段階は、
前記１つ以上のＡＰＮに対応するすべてのＰＤＮの輻輳状態であるか否かを判断し、
前記拒絶段階は、
前記すべてのＰＤＮのうちの少なくとも１つのＰＤＮであっても輻輳状態で判断される場合、サービス要請拒絶メッセージを前記端末に送信する
ことを特徴とする、請求項２に記載の輻輳制御方法。

【請求項6】

前記サービス要請拒絶メッセージは、
拒絶されるＡＰＮに対する情報と、 前記端末が前記サービス要請を再送信するために待機しなければならない時間のバック−オフタイムを含むことを特徴とする、 請求項５に記載の輻輳制御方法。

【請求項7】

前記判断段階は、
前記１つ以上のＡＰＮに対応するすべてのＰＤＮの輻輳状態であるか否かを判断し、輻輳状態のＰＤＮと正常状態のＰＤＮを分類し、
前記拒絶段階は、
前記輻輳状態のＰＤＮに対する一部サービス拒絶メッセージを前記端末に送信する
ことを特徴とする、請求項２に記載の輻輳制御方法。

【請求項8】

前記一部サービス拒絶メッセージは、
拒絶されるＡＰＮに対する情報と、 前記端末が前記サービス要請を再送信するために待機しなければならない時間のバック−オフタイムを含むことを特徴とする、 請求項７記載の輻輳制御方法。

【請求項9】

輻輳状態のＰＤＮに対するＰＤＮ連結を削除するためのセッション削除要請メッセージをサービングゲートウェーに送信する段階をさらに含む
ことを特徴とする、請求項８に記載の輻輳制御方法。

【請求項10】

前記サービス要請メッセージは端末が送信するデータに係る特定ＡＰＮを含み、
前記判断段階は、
前記サービス要請メッセージに含まれたＡＰＮの輻輳状態であるか否かを判断し、
前記拒絶段階は、
前記サービス要請メッセージに含まれたＡＰＮが輻輳状態で判断される場合、 サービス拒絶メッセージを前記端末に送信することを特徴とする、請求項２に記載の輻輳制御方法。

【請求項11】

前記移動性管理要請信号はトラッキング領域アップデート（Ｔｒａｃｋｉｎｇ Ａｒｅａ Ｕｐｄａｔｅ、ＴＡＵ）メッセージである
ことを特徴とする、請求項１に記載の輻輳制御方法。

【請求項12】

前記受信段階の以後に、
前記端末をサービングしたＭＭＥから前記端末に対するコンテキスト情報を獲得する段階をさらに含むことを特徴とする、請求項１１に記載の輻輳制御方法。

【請求項13】

前記判断段階は、
前記コンテキスト情報から前記端末に対して設定されたＡＰＮに対応するＰＤＮの輻輳であるか否かを判断し、
前記拒絶段階は、
前記端末に対するデフォルトＡＰＮに対応するＰＤＮが輻輳状態の場合、または前記端末に対して設定されたＡＰＮに対応するＰＤＮのうちの少なくとも１つのＰＤＮであっても輻輳状態の場合、ＴＡＵ拒絶メッセージを前記端末に送信する
ことを特徴とする、請求項１２に記載の輻輳制御方法。

【請求項14】

輻輳状態のＰＤＮに対するＰＤＮ連結を削除するためのセッション削除要請メッセージをサービングゲートウェーに送信する段階をさらに含む
ことを特徴とする、請求項１３に記載の輻輳制御方法。

【請求項15】

前記ＴＡＵ拒絶メッセージは前記端末がサービス要請を再送信するために待機しなければならない時間のバック−オフタイムを含むことを特徴とする、請求項１３に記載の輻輳制御方法。

【請求項16】

前記バック−オフタイム経過後、 前記端末から接続要請メッセージ（Ａｔｔａｃｈ Ｒｅｑｕｅｓｔ）を受信する段階をさらに含むことを特徴とする、請求項１５記載の輻輳制御方法。

【請求項17】

前記拒絶段階の以後、
前記端末のベアラーを中断させるための中断要請メッセージを前記端末をサービングしたＭＭＥに送信する段階をさらに含むことを特徴とする、請求項１１に記載の輻輳制御方法。

【請求項18】

移動通信システムにおける移動性管理エンティティー（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ、ＭＭＥ）において、
信号を送受信する送受信部；及び
前記送受信部を通じて端末から１つ以上のパケットデータネットワーク（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ、ＰＤＮ）連結要請受信に応答し、１つ以上のアクセスポイントネーム（Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅ、ＡＰＮ）に基づいて１つ以上のＰＤＮに対する１つ以上の連結を構築し、
前記送受信部を通じて前記端末から移動性管理要請信号を受信し―前記移動性管理要請信号は、前記１つ以上のＰＤＮに対する前記端末の前記１つ以上の連結と関連する；
前記移動性管理要請信号の受信に応答し、前記１つ以上のＡＰＮのうちの少なくとも１つに対応する少なくとも１つのＰＤＮの輻輳（ｃｏｎｇｅｓｔｉｏｎ）状態であるか否かを判断し、
前記少なくとも１つのＰＤＮが輻輳状態である場合、前記移動性管理要請信号を拒絶するように制御する制御部；を含み、
前記１つ以上のＰＤＮに対する前記１つ以上の連結が構築された後、前記端末がアイドル状態に遷移すると、前記アイドル状態から活性化状態に遷移するために前記移動性管理要請信号が前記端末によって送信される
ことを特徴とする移動性管理エンティティー。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は移動通信システムにおいて輻輳制御(Ｃｏｎｇｅｓｔｉｏｎ Ｃｏｎｔｒｏｌ)方法に関する。より具体的に本発明はアクセスポイントネーム(Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅ、ＡＰＮ)に基盤してネットワーク輻輳を制御する方法に関する。

【背景技術】

【0002】

一般的に、移動通信システムは使用者の活動性を保障しながら音声サービスを提供するために開発された。しかし移動通信システムは次第に音声のみならずデータサービスまで領域を確張しており、 現在には高速のデータサービスを提供することができる程度まで発展した。しかし現在サービスが提供されている移動通信システムでは資源の不足現象及び使用者がより高速のサービスを要求するので、より発展した移動通信システムが要求されている。

【0003】

特に、最近にはスマートフォン使用の増加で単純な通知(Ｎｏｔｉｆｉｃａｔｉｏｎ)メッセージのように少量のデータを短い時間の間隔で周期的に送信する現象が発生している。これによって、端末はアイドル状態(ｉｄｌｅ)と活性(Ａｃｔｉｖｅ)状態が持続的に変更される。このような端末の持続的な状態変化はシグナルの量を爆発的に増加させる。ところが、増加されるシグナル量に比べて送信されるデータの量は少量であるので、オペレーターの利潤(ｒｅｖｅｎｕｅ)は増加しなく、ネットワーク輻輳(ｃｏｎｇｅｓｔｉｏｎ)だけ発生するようになる。このような状況のため輻輳(ｃｏｎｇｅｓｔｉｏｎ)が発生した時、主要利潤ストリーム(ｒｅｖｅｎｕｅ ｓｔｒｅａｍ)サービスであるボイス通信のためのＩＭＳ関連フロー(ｆｌｏｗ)は継続サービスして、 利潤を創出することができないデータ通信関連フロー(ｆｌｏｗ)は選択的にサービスを中断することができる輻輳制御(ｃｏｎｇｅｓｔｉｏｎ ｃｏｎｔｒｏｌ)方法が必要である。

【発明の概要】

【発明が解決しようとする課題】

【0004】

本発明は、上記のような問題点を解決するために案出されたもので、アクセスポイントネーム(Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅ、ＡＰＮ)に基盤してネットワーク輻輳を制御する方法を提供することをその目的とする。

【課題を解決するための手段】

【0005】

上記のような問題点を解決するための本発明の移動通信システムにおいて移動性管理エンティティー(Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ、ＭＭＥ)の輻輳制御方法は少なくとも１つ以上のアクセスポイントネーム(Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅ、ＡＰＮ)に対するパケットデータネットワーク(Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ、ＰＤＮ)連結を備える端末から移動性管理要請信号を受信する受信段階、上記ＡＰＮの輻輳(ｃｏｎｇｅｓｔｉｏｎ)状態であるか否かを判断する判断段階及び輻輳状態判断時、上記移動性管理要請を拒絶する拒絶段階を含むことを特徴とする。

【発明の効果】

【0006】

本発明によれば、ＡＰＮに基盤してネットワークに発生する輻輳(ｃｏｎｇｅｓｔｉｏｎ)をより效率的に制御することができる。また、事業者側面では利潤ストリーム(ｒｅｖｅｎｕｅ ｓｔｒｅａｍ)サービスであるボイス通信のためのＩＭＳ関連フロー(ｆｌｏｗ)は継続サービスして、利潤を創出することができないデータ通信関連フロー(ｆｌｏｗ)は選択的にサービスを中断することができる。

【図面の簡単な説明】

【0007】

【図1】従来技術によってＡＰＮに基盤して端末のＰＤＮ連結要請を処理する過程を示したフローチャートである。

【図2】移動性管理制御信号であるサービス要請メッセージまたはトラッキング領域アップデートメッセージ処理において、従来ＡＰＮに基盤して輻輳を制御する方法をそのまま適用する場合、発生する問題点を示した図面である。

【図3】移動性管理制御信号に対してＡＰＮに基盤した輻輳制御処理方法適用時、発生することができる従来技術の問題点を示した図面である。

【図4】本発明の１-Ａ実施例による輻輳制御方法を示した図面である。

【図5】本発明の１-Ｂ実施例による輻輳制御方法を示した図面である。

【図6】本発明の１-Ｃ実施例による輻輳制御方法を示した図面である。

【図7】本発明の１-Ｄ実施例による輻輳制御方法を示した図面である。

【図8】本発明の２-Ａ実施例による輻輳制御方法を示した図面である。

【図9】本発明の２-Ｂ実施例による輻輳制御方法を示した図面である。

【発明を実施するための形態】

【0008】

以下で記述される本発明の輻輳(ｃｏｎｇｅｓｔｉｏｎ)は移動性管理エンティティー、 サービングゲートウェー、ＰＤＮゲートウェーなどのノードに対して単位時間当たり処理することができる作業用量(ｃａｐａｃｉｔｙ)以上の作業用量が割り当てられた場合を意味することができ、 負荷状態(ｏｖｅｒｌｏａｄ)と混用して使用することができることを仮定する。

【0009】

以下、添付された図面を参照して本発明の好ましい実施例を詳しく説明する。この時、 添付された図面で同一構成要素は可能な同一符号に示されていることに留意しなければならない。また、本発明の要旨を濁すようにできる公知機能及び構成に対する詳細な説明は省略するだろう。

【0010】

また、本発明の実施例を具体的に説明することにおいて、キャリアアグリゲーション(ｃａｒｒｉｅｒ Ａｇｇｒｅｇａｔｉｏｎ)を支援するＡｄｖａｎｃｅｄ Ｅ-ＵＴＲＡ(あるいは、「ＬＴＥ-Ａ」と称する) システムを主な対象とするはずだが、本発明の主な要旨は類似の技術的背景及びチャンネル形態を有するその他の通信システムにも本発明の範囲を大きく外れない範囲でやや変形で適用可能であり、 これは本発明の技術分野で熟練された技術的知識を有する者の判断として可能であろう。

【0011】

まず、図1は従来技術によってＡＰＮに基盤して端末のＰＤＮ連結要請を処理する過程を示したフローチャートである。

【0012】

最近、オペレーターは使用しようとするネットワークを現わすＡＰＮを基盤で負荷、 輻輳(ｏｖｅｒｌｏａｄ、 ｃｏｎｇｅｓｔｉｏｎ)を制御しようとする。このようなオペレーターの要求(ｒｅｑｕｉｒｅｍｅｎｔ)を満足させるために、現在標準では図1で示されたように、セッション制御信号(ｓｅｓｓｉｏｎ ｃｏｎｔｒｏｌ ｓｉｇｎａｌ)を上記ＡＰＮを基準でコントロールする方法を提供している。ここで、上記セッション制御信号はＰＤＮ連結要請(ＰＤＮ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔ)、 ベアラーリソース割当て要請(Ｂｅａｒｅｒ Ｒｅｓｏｕｒｃｅ Ａｌｌｏｃａｔｉｏｎ Ｒｅｑｕｅｓｔ)などを含むことができる。

【0013】

以下では図１のフローチャートを参考してＡＰＮに基盤してセッション制御信号を制御する方法に対して記述する。まず、移動性管理エンティティー(Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ、 ＭＭＥ)１３０はＳ１０５段階で、サービングゲートウェー(Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ、ＳＧＷ)(１４０)及びＰＤＮゲートウェー(ＰＤＮ Ｇａｔｅｗａｙ、ＰＧＷ)(１５０)から負荷(ｌｏａｄ)状態を報告受けると仮定する。

【0014】

端末(Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ、ＵＥ)１１０はＳ１１０段階で、連結しようとするＡＰＮを含むＰＤＮ連結要請メッセージ(ＰＤＮ ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔ)を基地局(ｅＮＢ)１２０を介してＭＭＥ１３０に送信する。それではＭＭＥ１３０はＳ１２０段階で、要請されたＡＰＮに対する負荷(ｌｏａｄ)を確認する。

【0015】

ＭＭＥ１３０は自分の負荷(ｏｖｅｒｌｏａｄ)が一定臨界値(ｔｈｒｅｓｈｏｌｄ)以上と判断した場合、音声(ｖｏｉｃｅ)通信のためのＩＭＳ関連ＡＰＮに対する要請(Ｒｅｑｕｅｓｔ)またはエンタープライズ(ｅｎｔｅｒｐｒｉｓｅ)サービスのための特定ＶＰＮ関連ＡＰＮに対する要請(Ｒｅｑｕｅｓｔ)のみを受諾(Ａｃｃｅｐｔ)できる。

【0016】

一方、ＭＭＥ１３０はウェブブラウジング(ｗｅｂ ｂｒｏｗｓｉｎｇ)関連ＡＰＮはバック−オフタイム(ｂａｃｋ−ｏｆｆ ｔｉｍｅ)を与えて拒絶(ｒｅｊｅｃｔ)できる。このために、ＭＭＥ１３０はＳ１３０段階で、ＰＤＮ連結拒絶メッセージ(ＰＤＮ ｃｏｎｎｅｃｔｉｏｎ ｒｅｊｅｃｔ)を基地局１２０を介して端末１１０に送信する。上記ＰＤＮ連結拒絶メッセージはバック−オフタイムを含み、端末１１０は上記受信したバック−オフタイムが経過した後、Ｓ１４０段階でＰＤＮ連結要請を再送信する。または、端末１１０はＳ１５０段階で拒絶されたＡＰＮ以外のＡＰＮに対するＰＤＮ連結要請を再送信することができる。

【0017】

図１で記述したＡＰＮに基盤した輻輳制御(Ｃｏｎｇｅｓｔｉｏｎ Ｃｏｎｔｒｏｌ)は特定ＡＰＮに帰属されるＰＤＮ連結関連セッション制御信号に使用が可能である。

【0018】

最近にはこのようなＡＰＮ基盤輻輳制御方法をサービス要請メッセージ(Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ)、 トラッキング領域アップデートメッセージ(Ｔｒａｃｋｉｎｇ Ａｒｅａｕｐｄａｔｅ、ＴＡＵ)のような移動性管理制御信号(ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｃｏｎｔｒｏｌ ｓｉｇｎａｌ)にも適用しようとする要求(ｒｅｑｕｉｒｅｍｅｎｔ)が発生している。

【0019】

ところで、移動性管理制御信号は図１に示されたセッション制御信号とは異なり特定ＡＰＮに帰属されるＰＤＮ連結1つにだけ連関されない。言い換えれば、移動性管理制御信号は端末単位で適用される信号(ｓｉｇｎａｌ)であるので、端末が有するすべてのセッション(ｓｅｓｓｉｏｎ)と関連されるので、少なくとも２つ以上のＡＰＮと同時に関連される現象が発生する。これは図２を参考して説明する。

【0020】

図２は移動性管理制御信号であるサービス要請メッセージ(ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ)またはトラッキング領域アップデート(Ｔｒａｃｋｉｎｇ Ａｒｅａ Ｕｐｄａｔｅ) メッセージ処理において、従来のＡＰＮに基盤して輻輳を制御する方法をそのまま適用する場合、発生する問題点を示した図面である。

【0021】

まず、端末１１０が複数個のＡＰＮに対してＰＤＮ連結を形成した後、アイドル(ｉｄｌｅ)状態で転換したと仮定する。以後、端末１１０はさらに活性(Ａｃｔｉｖｅ)状態で転換するため、Ｓ２１０段階でサービス要請(Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ)メッセージを基地局１２０を介してＭＭＥ１３０で送信する。上記サービス要請メッセージは１つの端末に対する複数個のＰＤＮ連結要請を含む。

【0022】

それでは、ＭＭＥ１３０はＳ２２０段階で、端末に対して現在活性化されたＡＰＮの負荷状態を確認する。本例示ではＡＰＮ Ａ及びＡＰＮ Ｃが過負荷(ｏｖｅｒｌｏａｄｅｄ)であり、ＡＰＮ Ｂが正常(ｎｏｔ ｏｖｅｒｌｏａｄｅｄ)であることを仮定する。

【0023】

このように、一部ＡＰＮに対しては過負荷状態であり(例えば、最大活性ベアラー数以上のベアラー活性状態)、残りＡＰＮに対しては過負荷状態ではない場合、当該の端末の移動性管理制御信号をどのように処理するかに対する問題が発生することができる。

【0024】

一方、セッション制御信号は端末１１０を現在サービングしている制御ノード(ｃｏｎｔｒｏｌ ｎｏｄｅ) すなわち、ＭＭＥ１３０で処理される。ところが、移動性管理制御信号(ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｓｉｇｎａｌ)は端末１１０の移動状況を知らせることなので、セッション制御信号処理の場合とは異なり端末１１０をサービングする ＭＭＥとは異なる新しいＭＭＥが当該の信号を処理しなければならない状況が発生することができる。すなわち、端末がＴＡＵを送信する時、上記ＴＡＵを受信したＭＭＥが従来のＭＭＥではない新しいＭＭＥであるのに、上記新しいＭＭＥが既に輻輳状態であることができる。

【0025】

この場合、上記新しいＭＭＥは端末１１０から受信された移動性管理制御信号の処理するか否かを判断しなければならない。ところが、このような判断をＡＰＮ基盤とする場合、 上記新しいＭＭＥは端末が現在使用中のＡＰＮ関連情報を端末をサービングしたＭＭＥから獲得すべきであり、基本ＭＭＥで連結されたＳＧＷへの制御プレーン(ｃｏｎｔｒｏｌ ｐｌａｎｅ)を新しいＭＭＥに変更した後、ＡＰＮを基盤に移動性管理制御信号(例えば、 ＴＡＵ)の拒絶するか否かを決定しなければならない。したがって拒絶(ｒｅｊｅｃｔ)決定のために必要なオペレーションによる負荷(ｏｖｅｒｌｏａｄ)が発生することができる。上記の従来技術の問題点が図３に示される。

【0026】

図３は移動性管理制御信号に対してＡＰＮに基盤した輻輳制御処理方法適用時、発生することができる従来技術の問題点を示された図面である。

【0027】

まず、端末１１０はＳ３１０段階で、トラッキング領域アップデート(ＴＡＵ)メッセージを基地局１２０を介して新規のＭＭＥ１３０Ａに送信する。ここで、上記新規のＭＭＥ１３０Ａは端末１１０をサービングした従来のＭＭＥ１３０Ｂと異なるＭＭＥであり、輻輳状態(ｃｏｎｇｅｓｔｉｏｎ)であることを仮定する。

【0028】

それでは新規のＭＭＥ１３０Ａは自分が輻輳状態にもかかわらず、 端末１１０から送信されたＴＡＵメッセージを処理するためにＳ３２０段階でＵＥコンテキスト要請メッセージ(ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔ)を従来のＭＭＥ１３Ｂに送信する。それでは新規のＭＭＥ１３０ＡはＳ３３０段階で、 ＵＥコンテキスト応答メッセージ(ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｓｐｏｎｓｅ)を受信し、これに対する確認メッセージをＳ３４０段階で送信する。

【0029】

それでは新規ＭＭＥ１３０ＡはＵＥコンテキストから端末に対して現在活性化された ＡＰＮを確認することができ、Ｓ３５０段階で各ＡＰＮの負荷状態を確認する。本例示ではＡＰＮ Ａ及びＡＰＮ Ｃが過負荷状態であり、ＡＰＮ Ｂが正常状態なのを仮定する。

【0030】

そして新規のＭＭＥ１３０Ａは従来のＭＭＥ１３０ＢとＳＧＷ１４０間に連結された制御プレーン(ｃｏｎｔｒｏｌ ｐｌａｎｅ)を解除し、自分とＳＧＷ１４０間に制御プレーンを形成するための過程をＳ３６０段階以下で行う。

【0031】

ところで、新規のＭＭＥ１３０ＡとＳＧＷ１４０間に制御プレーンを形成すると言っても、 いずれにしても新規のＭＭＥ１３０Ａは輻輳状態なので端末１１０から送信されたＴＡＵを拒絶しなければならない。すなわち、端末１１０のＴＡＵを拒絶するため、輻輳状態である新規のＭＭＥ１３０ＡがＳ３２０以下の段階を行うべきという不合理な状況が発生するようになる。

【0032】

本発明は図１乃至図３で記述した問題点を解決するために案出されたもので、ＡＰＮに基盤して輻輳を效率的に制御することができる方案を提案する。

【0033】

まず、以下で記述される本発明の実施例では複数個のＡＰＮに対するＰＤＮ連結を備える端末がアイドル(ｉｄｌｅ)状態進入後また活性(Ａｃｔｉｖｅ)状態で遷移する場合、上記複数個のＰＤＮ連結を皆復旧させるか否かに対して記述する。この場合、本発明の第1 実施例では移動性管理(Ｍｏｂｉｌｉｔｙ Ｍaｎaｇｅｍｅｎｔ)を処理するコアネットワークノード(すなわち、ＭＭＥ)が変更されない場合の解決方案に対して記述する。そして本発明の第２実施例では移動性管理を処理するコアネットワークが変更された場合の解決方案に対して記述する。
<第1 実施例>

【0034】

以下で記述される本発明の第1実施例では移動性管理(Ｍｏｂｉｌｉｔｙ Ｍaｎaｇｅｍｅｎｔ)を処理するコアネットワークノード(すなわち、ＭＭＥ)が変更されない場合の輻輳制御(ｃｏｎｇｅｓｔｉｏｎ ｃｏｎｔｒｏｌ)方法に対して記述する。特に、ＭＭＥの移動性管理制御信号処理方法によって１−Ａ実施例乃至１-Ｄ実施例で区分して記述するようにする。

【0035】

第1 実施例では端末のサービス要請メッセージ(Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ)またはＴＡＵを受信したＭＭＥが変更されなかったので、ＭＭＥは端末の加入情報(ｓｕｂｓｃｒｉｐｔｉｏｎ)を含んだ端末のコンテキストを備えることで仮定することができる。

【0036】

図４は本発明の１−Ａ実施例による輻輳制御方法を示した図面である。

【0037】

上記端末の加入情報には予め決定されたデフォルトＡＰＮ(Ｄｅｆａｕｌｔ ＡＰＮ)情報が含まれる。上記デフォルトＡＰＮ情報は端末が活性状態で基本的に使用するＰＤＮ連結に対する情報である。

【0038】

本発明の１−Ａ実施例では上記デフォルトＡＰＮの輻輳状態を基準に移動性管理制御信号処理するか否かを決定する。すなわち、端末から移動性管理制御信号を受信したＭＭＥはデフォルトＡＰＮが輻輳状態であれば、当該の移動性管理制御信号を拒絶する。そしてＭＭＥは当該の拒絶メッセージにデフォルトＡＰＮに対する輻輳が解消された時点に対する予測(ｅｓｔｉｍａｔｉｏｎ)を基盤でバック−オフタイムを提供する。

【0039】

上記の本発明の１−Ａ実施例に対する具体的な遂行過程を図４を参考して説明する。

【0040】

Ｓ４１０段階で、端末４１０に対して複数個のＡＰＮに対するＰＤＮ連結が形成されることを仮定する。

【0041】

それでは、端末４１０はＳ４２０段階で、アイドル状態から活性状態に遷移するためにサービス要請メッセージ(Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ)を基地局４２０を介してＭＭＥ４３０に送信する。それでは、ＭＭＥ４３０はＳ４３０段階で、端末４１０の加入情報からデフォルトＡＰＮ及び上記デフォルトＡＰＮの状態を確認する。

【0042】

ＭＭＥ４３０はＳ４４０段階でデフォルトＡＰＮが輻輳状態なのを確認し、Ｓ４５０段階でサービス拒絶メッセージ(Ｓｅｒｖｉｃｅ Ｒｅｊｅｃｔ)を端末４１０に送信する。上記サービス拒絶メッセージはデフォルトＡＰＮ及びバック−オフタイムを含む。端末は上記バック−オフタイムが経過した以後に、サービス要請メッセージを再送信する。

【0043】

図５は本発明の１−Ｂ実施例による輻輳制御方法を示した図面である。

【0044】

本発明の１−Ｂ実施例では活性化されたＡＰＮに対するＰＤＮ連結のうちのいずれか１つでも輻輳状態の場合、ＭＭＥは端末から受信した移動性管理制御信号を拒絶する。そしてＭＭＥは輻輳状態であるＡＰＮ及び上記輻輳状態であるＡＰＮそれぞれに対するバック−オフタイムを含む拒絶メッセージを端末に送信する。この場合、 ＭＭＥは拒絶するＡＰＮと、バック−オフタイムの中で最大値を有するバック−オフタイムを代表値として上記拒絶メッセージを端末に送信することができる。

【0045】

上記の本発明の１−Ｂ実施例に対する具体的な遂行過程を図５を参考して説明する。

【0046】

Ｓ４１０段階で、端末４１０に対して複数個のＡＰＮに対するＰＤＮ連結が形成されることを仮定する。

【0047】

それでは、端末４１０はＳ５２０段階で、アイドル状態から活性状態で遷移するためにサービス要請メッセージ(Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ)を基地局４２０を介してＭＭＥ４３０で送信する。それでは、ＭＭＥ４３０はＳ５３０段階で、端末４１０に対して活性化されたＰＤＮ連結の状態を確認する。

【0048】

そしてＭＭＥ４３０はＳ５４０段階で、上記活性化されたＰＤＮ連結のＡＰＮの中で少なくともいずれか１つのＰＤＮ連結が輻輳状態なのを確認する。それではＭＭＥ４３０はＳ５５０段階で、サービス拒絶メッセージ(Ｓｅｒｖｉｃｅ Ｒｅｊｅｃｔ)を端末４１０に送信する。上記サービス拒絶メッセージは拒絶されるＡＰＮ及び上記拒絶されるＡＰＮそれぞれに対するバック−オフタイムを含む。端末４１０は上記バック−オフタイムが経過した以後に、サービス要請メッセージを再送信する。

【0049】

図６は本発明の１−Ｃ実施例による輻輳制御方法を示した図面である。

【0050】

本発明の１−Ｃ実施例では正常状態であるＡＰＮに対するＰＤＮ連結だけ活性化させ、 輻輳状態であるＡＰＮに対するＰＤＮ連結は非活性化させる。この時、 非活性化されたＰＤＮ連結関連ＡＰＮそれぞれに対しては一部サービス拒絶または受諾メッセージ(Ｐａｒｔｉａｌ Ｓｅｒｖｉｃｅ Ｒｅｊｅｃｔ／ａｃｃｅｐｔ)にバック−オフタイムを含ませてＮＡＳメッセージを介して端末で送信する。この場合、上記一部サービス拒絶または受諾メッセージは拒絶されたＡＰＮと、上記ＡＰＮに該当するバック−オフタイムと、ＡＰＮの過負荷のため部分拒絶されたことを知らせる原因(ｃａｕｓｅ)を含む。

【0051】

これによって、端末は受信したバック−オフタイムの間、当該のＡＰＮに対するＰＤＮ連結を要請しない。もし、ＭＭＥが端末にバック−オフタイムを提供しない場合には、 端末は予め設定されたデフォルト値を用いて、当該のデフォルト値の経過後、ＰＤＮ連結を要請する。

【0052】

上記の本発明の１−Ｃ実施例に対する具体的な遂行過程を図６を参考して説明する。

【0053】

Ｓ６１０段階で、端末４１０に対して複数個のＡＰＮに対するＰＤＮ連結が形成されることを仮定する。

【0054】

それでは、端末４１０はＳ６２０段階で、アイドル状態から活性状態で遷移するためにサービス要請メッセージ(Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ)を基地局４２０を介してＭＭＥ４３０で送信する。それでは、ＭＭＥ４３０はＳ６３０段階で、端末４１０に対して活性化されたたＰＤＮ連結の状態を確認する。そしてＭＭＥ４３０はＳ６３５段階で、輻輳状態であるＡＰＮに対するＰＤＮ連結と、正常状態であるＡＰＮに対するＰＤＮ連結を分類する。本発明の実施例ではＡＰＮ Ａ及びＡＰＮ Ｃに対するＰＤＮ連結が過負荷(輻輳)状態であり、 ＡＰＮ Bに対するＰＤＮ連結は正常状態なのを仮定する。

【0055】

そしてＭＭＥ４３０はＳ６４０段階で、初期コンテキスト設定要請メッセージを基地局４２０に送信する。上記初期コンテキスト設定要請メッセージはＡＰＮ Ｂに対するＰＤＮ連結だけ活性化させ、残りＡＰＮに対するＰＤＮ連結要請は拒絶するという一部サービス拒絶(Ｐａｒｔｉａｌ Ｓｅｒｖｉｃｅ Ｒｅｊｅｃｔ)を含む。ここで、上記一部サービス拒絶は拒絶されたＡＰＮ及び拒絶された各ＡＰＮに対するバック−オフタイムを含むことができる

【0056】

それでは基地局４２０はＳ６４５段階で、ラジオベアラー形成メッセージ(Rａｄｉо ＢBｅｒｅｒ Ｅｓｔａｂｌｉｓｈｍｅｎｔ)を端末４１０に送信する。上記ラジオベアラー形成メッセージはＡＰＮ Ｂに対するＰＤＮ連結だけ活性化させ、残りＡＰＮに対するＰＤＮ連結要請は拒絶するという一部サービス拒絶(Ｐａｒｔｉａｌ Ｓｅｒｖｉｃｅ Ｒｅｊｅｃｔ)を含む。ここで、上記一部サービス拒絶は拒絶されたＡＰＮ及び拒絶された各ＡＰＮに対するバック−オフタイムを含むことができる

【0057】

次いでＭＭＥ４３０は過負荷状態であるＡＰＮ Ａ及びＡＰＮ Ｃに対するＰＤＮ連結を削除する過程を行う。このために、ＭＭＥ４３０はＳ６５０段階で、 ＡＰＮ Ａに対する ＰＤＮ連結を削除するために、 セッション削除要請メッセージ(Ｄｅｌｅｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ)をＳＧＷ４４０に送信する。それではＳＧＷ４４０はＳ６５５段階乃至Ｓ６６０段階を介してセッション削除要請及び応答をＰＧＷ Ａ(４５０Ａ)と送受信する。当該のセッションが削除された後、 ＭＭＥ４３０はＳ６６５段階で、ＳＧＷ４４０からセッション削除応答メッセージを受信する。

【0058】

同様にＭＭＥ４３０はＳ６７０段階で、 ＡＰＮ Ｃに対するＰＤＮ連結を削除するために、 セッション削除要請メッセージ(Ｄｅｌｅｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ)をＳＧＷ４４０に送信する。それではＳＧＷ４４０はＳ６７５段階乃至Ｓ６８０段階を介してセッション削除要請及び応答をＰＧＷ Ｃ(４５０Ａ)と送受信する。該当のセッションが削除された後、ＭＭＥ４３０はＳ６８５段階で、ＳＧＷ４４０からセッション削除応答メッセージを受信する。

【0059】

一方、 １−Ｃ実施例によって、 一部サービス拒絶または受諾手続きが進行された場合、 端末４１０のＥＰＳベアラー情報も拒絶されたベアラーを削除するアップデート過程が行われるべきである。このようなアップデート過程は下記の３つ方法のうちのいずれか１つに行われることができる。

【0060】

第１に、 端末は拒絶されたＡＰＮに対するＰＤＮ連結に該当するＥＰＳベアラーをローカリー(ｌｏｃａｌｌｙ)非活性化させることができる。第２に、一部サービス拒絶または受諾メッセージは追加的に活性化されるベアラーに対する情報または解除(ｒｅｌｅａｓｅ)されたベアラーに対する情報の中で少なくとも１つを含み、上記メッセージを受信した端末が端末内に貯蔵存されたＥＰＳベアラー情報をアップデートさせることができる。第３に、端末はＲＲＣ再設定(ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ)を介して活性化されたベアラー以外のベアラーをローカルリー非活性化させることができる。

【0061】

図７は本発明の１−Ｄ実施例による輻輳制御方法を示した図面である。

【0062】

本発明の１−Ｄ実施例では端末は自分が送信するデータと関連されたＡＰＮを明示してサービス要請メッセージを送信し、 ＭＭＥは上記明示されたＡＰＮに対するＰＤＮ連結の輻輳状態によってサービス要請受諾するか否かを決定する。

【0063】

送信しようとするデータ発生時、アイドル状態の端末はサービス要請を介して活性状態に遷移されることができるが、 上記データが輻輳状態であるＡＰＮに対するＰＤＮ連結に送信されなければならない場合が発生することができる。１−Ｃ実施例によれば一部サービス要請受諾または拒絶によってベアラーが部分的に生成されるのに、 端末が送信しようとするデータに係るベアラーが形成されることができなければ、 このような一部サービス要請受諾または拒絶が意味がないことがある。

【0064】

１−Ｄ実施例ではこのような点を考慮し、 端末はサービス要請メッセージに活性化が必要な少なくとも１つのＡＰＮを明示する。これを受信したＭＭＥは明示されたＡＰＮのうちのいずれか１つのＡＰＮでも輻輳状態であれば、当該のサービス要請を拒絶する。この場合、 拒絶メッセージは１−Ｂ実施例のように拒絶されたＡＰＮ及び拒絶されたＡＰＮそれぞれに対するバック−オフタイムまたは最も長い代表バック−オフタイムを含むことができる。

【0065】

もし、サービス要請メッセージに明示されたＡＰＮが全部輻輳状態ではなくて、 明示されないＡＰＮだけ輻輳状態であれば、ＭＭＥは輻輳状態のＡＰＮだけ拒絶する一部サービス拒絶または受諾メッセージを端末で送信する。同時に、ＭＭＥは拒絶されたＡＰＮと拒絶されたＡＰＮそれぞれに対するバック−オフタイムを上記メッセージに含ませた後、 セッション削除要請を介して当該のＰＤＮ連結を非活性化させる。

【0066】

上記一部サービス拒絶または受諾メッセージを受信した端末はバック−オフタイムが経過する前には、当該のＡＰＮに対するＰＤＮ連結要請を送信しない。

【0067】

上記の本発明の１−Ｄ実施例に対する具体的な遂行過程を図７を参考して説明する。

【0068】

Ｓ７１０段階で、 端末４１０に対して複数個のＡＰＮに対するＰＤＮ連結が形成されることを仮定する。

【0069】

それでは、端末４１０はＳ７７２０段階で、活性化させようとする少なくとも１つのＡＰＮを明示したサービス要請メッセージ(Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ)を基地局４２０を介してＭＭＥ４３０で送信する。それでは、ＭＭＥ４３０はＳ７３０段階で、端末４１０に対して活性化されたＰＤＮ連結の状態を確認する。

【0070】

Ｓ７４０段階で、ＭＭＥ４３０は端末４１０が明示したＡＰＮの輻輳状態であるか否かを判断する。もし、端末４１０が明示したＡＰＮのうちのいずれか１一つでも輻輳状態であれば、 ＭＭＥ４３０はＳ７５０段階で進行してバック−オフタイムを含むサービス拒絶メッセージを端末４１０に送信する。

【0071】

もし、明示されたＡＰＮは共に正常状態であれば、ＭＭＥ４３０はＳ７６０段階で進行して明示されないＡＰＮだけ輻輳状態なのを確認する。それではＭＭＥ４３０はＳ７７０ 段階で進行し、部分サービス拒絶または受諾メッセージを端末４１０に送信する。上記部分サービス拒絶または受諾メッセージは拒絶されたＡＰＮ及び上記拒絶されたＡＰＮそれぞれに対するバック−オフタイムを含む。

【0072】

上記の本発明の１−Ｄ実施例で、 端末４１０はサービス要請メッセージにＡＰＮの代わりに当該のＥＰＳベアラーIＤを含んで送信することもできる。この場合、ＭＭＥ４３０は貯蔵されているＵＥコンテキスト内の情報を基盤で当該のＥＰＳベアラーに該当するＡＰＮを捜した後、そのＡＰＮに対する輻輳状況を判断して受諾または拒絶を決定する。

【0073】

もし、１−Ｄ実施例をＴＡＵに対して適用する場合、サービス要請メッセージに含まれたＡＰＮは送信のためにバッファリングされたデータを送信するＰＤＮ連結に対するＡＰＮではなく、端末で拒絶または受諾の判断基準で使用するように設定(ｃｏｎｆｉｇｕｒａｔｉｏｎ)されているＡＰＮである。

【0074】

一方、1−Ａ実施例乃至１−Ｄ実施例に対して、ＡＰＮの輻輳状態は端末別で適用されることができる。すなわち、同一インターネットＡＰＮであっても適用料金制の加入情報(ｓｕｂｓｃｒｉｐｔｉｏｎ)にしたがって一部端末に対しては輻輳(ｃｏｎｇｅｓｔｉｏｎ)が発生したＡＰＮと判断されて他の一部端末に対しては輻輳(ｃｏｎｇｅｓｔｉｏｎ)が発生しないＡＰＮで判断されることができる。
<第２実施例>

【0075】

以下で記述される本発明の第２実施例では移動性管理を処理するコアネットワークノード(すなわち、ＭＭＥ)が変更された場合の輻輳制御(ｃｏｎｇｅｓｔｉｏｎ ｃｏｎｔｒｏｌ)方法に対して記述する。特に、ＭＭＥの移動性管理制御信号処理方法によって２-Ａ及び２−Ｂ実施例で区分して記述する。

【0076】

端末が移動してキャンピング(ｃａｍｐｉｎｇ)したセル(ｃｅｌｌ)が変更され、 このようなセルの変更がＭＭＥの変更を引き起こした場合を仮定する。この場合、 端末は移動性管理制御信号であるトラッキング領域アップデート要請メッセージ(ｔｒａｃｋｉｎｇ ａｒｅａ ｕｐｄａｔｅ Ｒｅｑｕｅｓｔ)を変更された新しいＭＭＥで送信する。この時、新しいＭＭＥが輻輳状態であれば、ＡＰＮの輻輳であるか否かにしたがってＴＡＵの受諾または拒絶を決めなければならないのに、 輻輳状態である新しいＭＭＥが既存ＭＭＥに端末のコンテキスト(ｃｏｎｔｅｘｔ)を取って来る前にはＴＡＵの受諾または拒絶を決定することができない。

【0077】

また、端末のコンテキストを取って来たら既存ＭＭＥではＳＧＷとの制御信号連結を削除するはずだから、上記制御信号連結を新しいＭＭＥに変更させるアップデート作業を必ず遂行しなければならない。遂行しなかったら、 端末のベアラー情報を有するＳＧＷはどんなＭＭＥでも連結にならないからペイジング遂行が不可能になることもできる。

【0078】

以下で記述される２−Ａ及び２−Ｂ実施例では上記の問題点を解決することができる方案を提示する。

【0079】

図８は、本発明の２−Ａ実施例による輻輳制御方法を示した図面である。

【0080】

端末からＴＡＵを受信した新規のＭＭＥは上記ＴＡＵに含まれたＧＵＴＩ(Ｇｌｏｂａｌｌｙ Ｕｎｉｑｕｅ Ｔｅｍｐｏｒａｒｙ ＩＤ)を利用して従来のＭＭＥを捜す。上記ＧＵＴＩはＭＭＥが端末に割り当てて、ＧＵＭＭＥI(Ｇｌｏｂａｌｌｙ Ｕｎｉｑｕｅ ＭＭＥ ＩＤ)とＭ−ＴＭＳＩ(ＭＭＥ−ＴＭＳＩ)を含む。ここで、上記ＧＵＭＭＥはＭＭＥに対する識別情報であり、 ＭＭＥ−ＴＭＳＩはＭＭＥ内にある端末に対する識別情報である。

【0081】

そして新規のＭＭＥは従来のＭＭＥに端末のコンテキストを要請して獲得した後、 上記の１−Ａまたは１−Ｂ実施例によって輻輳を制御する。すなわち、新規のＭＭＥは端末のコンテキストに含まれたデフォルトＡＰＮが輻輳状態とか(1-Ａ実施例)、または活性ＡＰＮのうちのいずれか１つでも輻輳状態であれば、端末のＴＡＵを拒絶する。この場合、ＴＡＵ拒絶メッセージは輻輳状態であるＡＰＮ及び輻輳状態のＡＰＮそれぞれに対するバック−オフタイムを含む。

【0082】

そして上記ＴＡＵ拒絶メッセージを送信した新規のＭＭＥは当該のＡＰＮに対するＰＤＮ連結を非活性化させる。このために、 新規のＭＭＥはセッション削除要請メッセージ(Ｄｅｌｅｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ)をＳＧＷで送信する。

【0083】

ＴＡＵ拒絶メッセージを受信した端末はバック−オフタイム経過後、 ＴＡＵではない接続要請(Ａｔｔａｃｈ Ｒｅｑｕｅｓｔ)を介してネットワーク接続を試みる。この時、端末はＴＡＵ拒絶メッセージに複数個のＡＰＮに対するバック−オフタイムが含まれた場合、 デフォルトＡＰＮに対するバック−オフタイム経過後、接続(ａｔｔａｃｈ)を試みる。一方、 デフォルトＡＰＮがＴＡＵ拒絶メッセージに含まれない場合、端末は直ちに接続要請メッセージ(Ａｔｔａｃｈ Ｒｅｑｕｅｓｔ)を介してネットワーク接続を試みるが、拒絶されたＡＰＮに対しては決定されたバック−オフタイム経過後にだけＰＤＮ連結要請メッセージを送信する。

【0084】

上記の本発明の２−Ａ実施例に対する具体的な遂行過程を図８を参考して説明する。

【0085】

端末４１０が移動してキャンピングしたセル及び上記セルを担当するＭＭＥが変更された場合、端末４１０はＳ８０５段階でＴＡＵを新規のＭＭＥ４３０Ａに送信する。それでは新規のＭＭＥ４３０ＡはＳ８１０段階で、 端末４１０に対する環境情報を獲得するためにＵＥコンテキスト要請メッセージ(ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔ)を従来のＭＭＥ４３０Ｂに送信する。それでは従来ＭＭＥ４３０ＢはＳ８１５段階でＵＥコンテキストを含むＵＥコンテキスト応答メッセージ(ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｓｐｏｎｓｅ)を新規のＭＭＥ４３０Ａに送信し、Ｓ８２０段階でこれに対する応答を受信する。

【0086】

それでは新規ＭＭＥ４３０ＡはＳ８２５段階で、端末４１０のコンテキストを介して端末４１０に対して活性化されたＰＤＮ連結及び上記ＰＤＮ連結に対する状態を確認する。そして新規のＭＭＥ４３０ＡはＳ８３０段階で、 デフォルトＡＰＮに対するＰＤＮ連結が輻輳状態とかまたはいずれか１つのＡＰＮに対するＰＤＮ連結が輻輳状態なのを確認する。

【0087】

それでは新規のＭＭＥ４３０ＡはＳ８３５段階で、ＴＡＵ拒絶メッセージ(Ｔｒａｃｋｉｎｇ Ａｒｅａ Ｕｐｄａｔｅ Ｒｅｊｅｃｔ)を基地局４２０を介して端末４１０で送信する。この場合、ＴＡＵ拒絶メッセージは輻輳状態であるＡＰＮ及び輻輳状態のＡＰＮ それぞれに対するバック−オフタイムを含む。

【0088】

そして新規のＭＭＥ４３０ＡはＳ８４０段階で、ＡＰＮ Ａ、Ｂ、Ｃそれぞれに対するＰＤＮ連結を削除するためのセッション削除要請メッセージ(Ｄｅｌｅｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ)をＳＧＷ４４０に送信する。それでは、ＳＧＷ４４０はＳ８４５、Ｓ８５０、Ｓ８５５それぞれの段階で、各ＰＧＷに対してベアラー修正要請メッセージ(Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ)を送信し、これに対する応答を受信して端末に対して形成されたＰＤＮ連結を削除する。

【0089】

一方、端末４１０はバック−オフタイム経過後、 Ｓ８６０段階で接続要請メッセージ(Ａｔｔａｃｈ Ｒｅｑｕｅｓｔ)を新規のＭＭＥ４３０Ａに送信してネットワーク接続を試みる。

【0090】

一方、上記の２−Ａ実施例に対する変形された実施例も可能である。例えば、新規のＭＭＥ４３０ＡはＴＡＵ拒絶メッセージにバック−オフタイム、またはＡＰＮとバック−オフタイムを同時に含ませることができる。これと同時に上記新規のＭＭＥ４３０ＡはＳＧＷ４４０でセッション削除要請メッセージを送信するのではなく、 ベアラーアップデート要請メッセージ(Ｕｐｄａｔｅ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ)を送信して新規のＭＭＥ４３０Ａで制御プレーンが連結されるようにアップデートすることもできる。

【0091】

図９は本発明の２−Ｂ実施例による輻輳制御方法を示した図面である。

【0092】

２−Ａ実施例によれば、新規のＭＭＥ４３０Ａが輻輳状態にもかかわらず、 端末のコンテキスト処理及びＳＧＷとのセッションを処理しなければならない。また、拒絶された端末はいつも接続(Ａｔｔａｃｈ)過程を遂行しなければならないのに、上記接続過程でのシグナリングはＴＡＵ処理過程でのシグナリングよりずっと複雑で負荷が多い。したがって輻輳状態を外れた新規のＭＭＥ４３０Ａが端末の接続過程を処理しながらさらに輻輳状態に進入する可能性が存在する。これを解決するためには輻輳状態の新規のＭＭＥ４３０Ａが輻輳状態から外れるまで端末関連処理を演技することができる方案が必要である。

【0093】

本発明の２−Ｂ実施例ではこれに対する解決策を提示する。このために、新規のＭＭＥ４３０Ａは自分が輻輳状態から脱するまで端末関連処理をゆずるように、 端末に対してはバック−オフタイムを含むＴＡＵ拒絶メッセージを送信して端末が追加的な要請を送信しないようにする。これと同時に、新規のＭＭＥ４３０Ａは従来のＭＭＥ４３０Ｂに端末のベアラーを中断(ｓｕｓｐｅｎｄ)させるように要請してダウンリンクデータパケットが捨てられるようにしてペイジングオーバーヘッドが発生しないようにする。

【0094】

上記の本発明の２−Ｂ実施例を図９を参考して説明する。

【0095】

まず、端末４１０はＳ９０５段階で、デフォルトＡＰＮ及びＧＵＴＩ情報を含むＴＡＵを基地局４２０を介して新規のＭＭＥ４３０Ａで送信する。それでは、新規のＭＭＥ４３０ＡはＳ９１０段階で、上記デフォルトＡＰＮの輻輳状態を確認する。もし、デフォルトＡＰＮが輻輳状態であれば、新規のＭＭＥ４３０ＡはＳ９１５段階からバック−オフタイムを含むＴＡＵ拒絶メッセージを基地局４２０を介して端末４１０で送信する。

【0096】

これと同時に、新規ＭＭＥ４３０ＡはＳ９２０段階で上記端末４１０を管理した従来のＭＭＥ４３０Ｂに中断要請メッセージ(Ｓｕｓｐｅｎｄ Ｒｅｑｕｅｓｔ)を送信する。それでは従来のＭＭＥ４３０ＢはＳ９２０段階で、ＳＧＷ４４０に中断通知メッセージ(Ｓｕｓｐｅｎｄ Ｎｏｔｉｆｉｃａｔｉｏｎ)を送信して端末４１０のダウンリンクデータを処理しない中断状態で転換する。

【0097】

この場合、新規のＭＭＥ４３０Ａが従来のＭＭＥ４３０Ｂに送信る中断要請メッセージはバック−オフタイムをデフォルトタイム(ｄｅｆａｕｌｔ ｔｉｍｅ)で含むこともできる。上記デフォルトタイムが含まれる場合、 当該のデフォルトタイムが経過した後にも従来ＭＭＥ４３０Ｂが端末４１０のコンテキストに対する要請を受信することができなかった場合、 上記従来のＭＭＥ４３０Ｂは該当の端末４１０のコンテキストを削除し、該当のベアラーもＳＧＷで非活性化(ｄｅａｃｔｉｖａｔｉｏｎ)させて端末を登録解除状態(ｄｅ−ｒｅｇｉｓｔｒａｔｉｏｎ ｓｔａｔｅ)で転換する。

【0098】

一方、中断要請メッセージにデフォルトタイムが含まれない場合には従来動作によって ｕｎｒｅａｃｈａｂｌｅ タイマーが満了した後、端末は登録解除状態で転換する。

【0099】

本明細書と図面に開示された本発明の実施例は本発明の記述内容を容易に説明した発明の理解を助けるために特定例を提示したものであるだけで、 本発明の範囲を限定しようとするものではない。ここに開示された実施例以外にも本発明の技術的思想に基づいた他の変形例が実施可能であるということは本発明が属する技術分野で通常の知識を有する者に自明なものである。

【符号の説明】

【0100】

１１０ 端末（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ、ＵＥ）
１２０ 基地局
１３０ 移動性管理エンティティー
１４０ サービングゲートウェー（Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ、ＳＧＷ）
１５０ ゲートウェー（ＰＤＮ Ｇａｔｅｗａｙ、ＰＧＷ）
４１０ 端末
４２０ 基地局

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】