特許第6065189号(P6065189)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 華為技術有限公司の特許一覧

特許6065189トンネル管理システム及びトンネル管理方法
<>
  • 特許6065189-トンネル管理システム及びトンネル管理方法 図000002
  • 特許6065189-トンネル管理システム及びトンネル管理方法 図000003
  • 特許6065189-トンネル管理システム及びトンネル管理方法 図000004
  • 特許6065189-トンネル管理システム及びトンネル管理方法 図000005
  • 特許6065189-トンネル管理システム及びトンネル管理方法 図000006
  • 特許6065189-トンネル管理システム及びトンネル管理方法 図000007
  • 特許6065189-トンネル管理システム及びトンネル管理方法 図000008
  • 特許6065189-トンネル管理システム及びトンネル管理方法 図000009
  • 特許6065189-トンネル管理システム及びトンネル管理方法 図000010
  • 特許6065189-トンネル管理システム及びトンネル管理方法 図000011
  • 特許6065189-トンネル管理システム及びトンネル管理方法 図000012
  • 特許6065189-トンネル管理システム及びトンネル管理方法 図000013
  • 特許6065189-トンネル管理システム及びトンネル管理方法 図000014
  • 特許6065189-トンネル管理システム及びトンネル管理方法 図000015
  • 特許6065189-トンネル管理システム及びトンネル管理方法 図000016
  • 特許6065189-トンネル管理システム及びトンネル管理方法 図000017
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6065189
(24)【登録日】2017年1月6日
(45)【発行日】2017年1月25日
(54)【発明の名称】トンネル管理システム及びトンネル管理方法
(51)【国際特許分類】
   H04W 76/02 20090101AFI20170116BHJP
   H04W 24/08 20090101ALI20170116BHJP
   H04W 92/24 20090101ALI20170116BHJP
【FI】
   H04W76/02
   H04W24/08
   H04W92/24
【請求項の数】18
【全頁数】21
(21)【出願番号】特願2015-88137(P2015-88137)
(22)【出願日】2015年4月23日
(62)【分割の表示】特願2013-245533(P2013-245533)の分割
【原出願日】2009年5月26日
(65)【公開番号】特開2015-156712(P2015-156712A)
(43)【公開日】2015年8月27日
【審査請求日】2015年5月21日
(31)【優先権主張番号】200810132421.4
(32)【優先日】2008年7月16日
(33)【優先権主張国】CN
(73)【特許権者】
【識別番号】503433420
【氏名又は名称】華為技術有限公司
【氏名又は名称原語表記】HUAWEI TECHNOLOGIES CO.,LTD.
(74)【代理人】
【識別番号】100146835
【弁理士】
【氏名又は名称】佐伯 義文
(74)【代理人】
【識別番号】100140534
【弁理士】
【氏名又は名称】木内 敬二
(72)【発明者】
【氏名】イン、ユ
【審査官】 松野 吉宏
(56)【参考文献】
【文献】 国際公開第2005/013514(WO,A1)
【文献】 Samsung,Clarification of default PDN and standardized Default APN,S2-080574,フランス,3GPP,2008年 1月 9日,paragraph 5.10.2
【文献】 Ericsson,Changes for dual stack in GERAN/UTRAN,S2-080731,フランス,3GPP,2008年 1月18日,paragraph 5.10.2
【文献】 Huawei,Several FFS clean-up,S2-080870,フランス,3GPP,2008年 1月17日,paragraph 5.10.2
【文献】 Ericsson,TFT handling,S2-085106,フランス,3GPP,2008年 6月27日,paragraph 9.2.2.1A
【文献】 Ericsson,AMBR additions,S2-085153,フランス,3GPP,2008年 6月27日,paragraph 9.2.2.1A
【文献】 Ericsson,Corrections for handover from Non-3GPP to GERAN/UTRAN access,S2-085272,フランス,3GPP,2008年 6月27日,paragraph 9.2.2.1A
(58)【調査した分野】(Int.Cl.,DB名)
H04B 7/24 − 7/26
H04W 4/00 − 99/00
3GPP TSG RAN WG1−4
SA WG1−4
CT WG1、4
(57)【特許請求の範囲】
【請求項1】
開始ノードと、トンネル管理ノードと、リモートノードと、を含むトンネル管理システムであって、
前記開始ノードは、第1のトンネル管理要求を前記トンネル管理ノードに送信するよう構成され、
前記トンネル管理ノードは、前記第1のトンネル管理要求を処理し、前記第1のトンネル管理要求の処理に成功した場合、第2のトンネル管理要求を前記リモートノードに送信するよう構成され、
前記リモートノードは、前記第2のトンネル管理要求を処理し、前記第2のトンネル管理要求の処理に失敗した場合、前記第2のトンネル管理要求の処理に失敗したことを示す第2の応答を、前記トンネル管理ノードに送信するよう構成され、
前記トンネル管理ノードは更に、失敗を引き起こした前記リモートノードを識別するノード情報を含む第3の応答を、前記開始ノードに送信するよう構成された、
トンネル管理システム。
【請求項2】
前記開始ノードが、モビリティ管理エンティティ(MME)又はパケットデータネットワークゲートウェイ(PGW)である、請求項1に記載のトンネル管理システム。
【請求項3】
前記トンネル管理ノードは、前記第1のトンネル管理要求の処理に失敗した場合、失敗を引き起こした前記トンネル管理ノードを識別するノード情報を含む第1の応答を、前記開始ノードに送信するよう構成された、
請求項1又は請求項2に記載のトンネル管理システム。
【請求項4】
前記第1の応答が、前記トンネル管理ノードが引き起こした失敗の理由を示す原因値を更に含む、請求項3に記載のトンネル管理システム。
【請求項5】
前記第1の応答に含まれるノード情報が、フラグビットである、請求項3又は請求項4に記載のトンネル管理システム。
【請求項6】
前記リモートノードが、パケットデータネットワークゲートウェイ(PGW)又はモビリティ管理エンティティ(MME)である、請求項1〜5のいずれか一項に記載のトンネル管理システム。
【請求項7】
前記第3の応答に含まれるノード情報が、フラグビットである、請求項1〜6のいずれか一項に記載のトンネル管理システム。
【請求項8】
前記第3の応答が、前記リモートノードが引き起こした失敗の理由を示す原因値を更に含む、請求項1〜7のいずれか一項に記載のトンネル管理システム。
【請求項9】
前記トンネル管理ノードがサービングゲートウェイ(SGW)である、請求項1〜8のいずれか一項に記載のトンネル管理システム。
【請求項10】
開始ノードが、第1のトンネル管理要求をトンネル管理ノードに送信し、
前記トンネル管理ノードが前記第1のトンネル管理要求を処理し、
前記トンネル管理ノードが、前記第1のトンネル管理要求の処理に成功した場合、第2のトンネル管理要求をリモートノードに送信し、
前記リモートノードが、前記第2のトンネル管理要求を処理し、
前記リモートノードが、前記第2のトンネル管理要求の処理に失敗した場合、前記第2のトンネル管理要求の処理に失敗したことを示す第2の応答を、前記トンネル管理ノードに送信し、
前記トンネル管理ノードが、前記第2の応答に基づき、失敗を引き起こした前記リモートノードを識別するノード情報を含む第3の応答を、前記開始ノードに送信する
ことを含む、トンネル管理方法。
【請求項11】
前記開始ノードが、モビリティ管理エンティティ(MME)又はパケットデータネットワークゲートウェイ(PGW)である、請求項10に記載のトンネル管理方法。
【請求項12】
前記トンネル管理ノードが、前記第1のトンネル管理要求の処理に失敗した場合、が失敗を引き起こした前記トンネル管理ノードを識別するノード情報を含む第1の応答を、前記開始ノードに送信する、請求項10又は請求項11に記載のトンネル管理方法。
【請求項13】
前記第1の応答が、前記トンネル管理ノードが引き起こした失敗の理由を示す原因値を更に含む、請求項12に記載のトンネル管理方法。
【請求項14】
前記第1の応答に含まれるノード情報が、フラグビットである、請求項12又は請求項13に記載のトンネル管理方法。
【請求項15】
前記リモートノードが、パケットデータネットワークゲートウェイ(PGW)又はモビリティ管理エンティティ(MME)である、請求項10〜14のいずれか一項に記載のトンネル管理方法。
【請求項16】
前記第3の応答に含まれるノード情報が、フラグビットである、請求項10〜15のいずれか一項に記載のトンネル管理方法。
【請求項17】
前記第3の応答が、前記リモートノードが引き起こした失敗の理由を示す原因値を更に含む、請求項10〜16のいずれか一項に記載のトンネル管理方法。
【請求項18】
前記トンネル管理ノードがサービングゲートウェイ(SGW)である、請求項10〜17のいずれか一項に記載のトンネル管理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、通信ネットワーク技術、詳細には、通信ネットワークにおけるトンネル管理方法、トンネル管理装置および通信システムの分野に関する。
【背景技術】
【0002】
既存のパケット切り替え通信ネットワークでは、サービスパケットを転送するために、ネットワークノード間に転送経路を設定しなればならない。転送経路は、トンネル管理手順を通して実現され、トンネル管理要求を通してネットワーク要素間に生成されるかまたは更新される。しかし、トンネル管理要求は何らかの理由のために失敗する可能性がある。例えば、要求メッセージ内にエラーが発生するか、または関連ネットワークノードのリソースを使い切っている場合である。従来技術では、一般に原因値が、トンネル管理要求の処理結果を示すのに使用される。原因値は、トンネル管理要求の処理が成功したかまたは失敗したかを示すとともに、トンネル管理要求が失敗したときの失敗の理由を示す。
【0003】
EPS(進化型パケットシステム)において、モビリティ(移動性)管理は、MME(モビリティ管理エンティティ)であり、MMEとPDN−GWまたはP−GW(パケットデータネットワークゲートウェイ)間で交換される信号はS−GW(serving gateway:サービングゲートウェイ)を横断しなければならない。移動端末は、EPS接続、ルーティングエリア更新、トラッキングエリア更新、ハンドオーバまたは外部PDN接続手順などの、モビリティ管理またはセッション管理手順を開始すると、MMEはトンネル管理要求を送信し、S−GWとPDN−GWは協働してトンネル管理要求を処理する。トンネル管理要求の処理の成功または失敗に関係なく、S−GWは、原因値を含む応答をMMEに送信し、MMEに対して処理結果を示す。
【0004】
しかしながら、本発明者はトンネル管理手順において、従来技術に少なくとも以下の問題を見出している。
【0005】
トンネル管理要求が失敗した場合、トンネル管理要求を開始したノードは応答を受信するが、その応答からは、どのノードのエラーがトンネル管理要求の失敗を引き起こしたかを判断することができない。結果として、トンネル管理要求を開始するノードは、様々なノードにより引き起こされるトンネル管理の失敗に対応するための処理を実行することができない。
【発明の概要】
【発明が解決しようとする課題】
【0006】
本発明の実施形態は、トンネル管理要求を開始するノードがトンネル管理要求の失敗を引き起こすノードを正しく判定し、それに応じて処理を実行することを可能にする、トンネル管理方法、トンネル管理装置および通信システムを提供する。
【課題を解決するための手段】
【0007】
上記の目的を達成するために、以下の技術的手法が提供される。すなわち、
トンネル管理方法であって、前記方法は
開始ノードからトンネル管理要求を受信し、
トンネル管理要求が失敗すると、トンネル管理要求の失敗を引き起こしたノードの情報を含む応答メッセージを開始ノードに送信すること、を含む。
【0008】
トンネル管理方法であって、前記方法は
トンネル管理要求をトンネル管理ノードに送信し、
トンネル管理要求が失敗すると、トンネル管理要求の失敗を引き起こしたノードの情報を含む応答メッセージをトンネル管理ノードから受信し、
前記ノード情報にもとづいて、トンネル管理要求の失敗を引き起こしたノードを探し出すステップと、を含む。
【0009】
トンネル管理装置であって、前記装置は、
開始ノードからトンネル管理要求を受信するように構成された、受信ユニットと、
トンネル管理要求が失敗すると、トンネル管理要求の失敗を引き起こしたノードの情報を含む応答メッセージを開始ノードに送信するように構成された、送信ユニットと、を含む。
【0010】
トンネル管理装置であって、前記装置は、
トンネル管理ノードにトンネル管理要求を送信するように構成された、送信ユニットと、
トンネル管理ノードからのノード情報を含む、応答メッセージを受信するように構成された、受信ユニットと、
前記ノード情報にもとづいて、トンネル管理要求の失敗を引き起こしたノードを探し出すように構成された、探索ユニットと、を含む。
【0011】
通信システムであって、前記システムが、
トンネル管理要求を送信するように構成された、開始ノードと、
開始ノードからトンネル管理要求を受信し、ノード情報を含む応答を開始ノードに返送するように構成された、トンネル管理ノードと、を含み、
前記開始ノードはさらに、前記ノード情報にもとづいて、トンネル管理要求の失敗を引き起こすノードを探し出すように構成されている。
【0012】
本発明の実施形態では、開始ノードで受信された応答メッセージがノード情報を含むので開始ノードがノード情報にもとづいてトンネル管理要求の失敗を引き起こすノードを探し出すことができるため、トンネル管理ノードがトンネル管理要求をさらにリモート(遠隔)ノードに送信したとしても、開始ノードは、ノード情報にもとづいて、トンネル管理要求の失敗がトンネル管理ノードより引き起こされたか、またはリモートノードにより引き起こされたかを区別することが可能である。したがって、開始ノードは、より簡便に、より効果的に、より迅速に、トンネル管理要求の失敗を処理することができる。本発明の実施形態により、従来の通信システムにおける開始ノードが、どのノードがエラーを引き起こしたかを判定し、有効な処理を実行できないという、従来技術における問題点を解決できる。
【図面の簡単な説明】
【0013】
図1】本発明の実施形態によるEPSネットワークのアーキテクチャを示している。
図2】本発明の第1の実施形態によるトンネル管理方法のフローチャートである。
図3】本発明の第1の実施形態による別のトンネル管理方法のフローチャートである。
図4】本発明の第1の実施形態によるトンネル管理装置のブロック図である。
図5】本発明の第1の実施形態による別のトンネル管理装置のブロック図である。
図6】本発明の第1の実施形態による通信システムのアーキテクチャを示している。
図7】本発明の第2の実施形態によるユーザ接続手順を示している。
図8】本発明の第2の実施形態による接続の失敗したトンネル管理手順を示している。
図9】本発明の第3の実施形態によるトラッキングエリアの更新手順を示している。
図10】本発明の第3の実施形態によるルーティングエリアの更新手順を示している。
図11】本発明の第4の実施形態による無線アクセスネットワークにおけるハンドオーバ手順を示している。
図12】本発明の第5の実施形態によるPDN接続手順を示している。
図13】本発明の第6の実施形態によるP−GW開始のベアラ更新手順を示している。
図14】本発明の第7の実施形態によるトンネル管理装置のブロック図である。
図15】本発明の第7の実施形態による別のトンネル管理装置のブロック図である。
図16】本発明の第8の実施形態による通信システムのアーキテクチャを示している。
【発明を実施するための形態】
【0014】
図1は、本発明の実施形態によるEPS(進化型パケットシステム)を示している。EPSは、移動端末、無線アクセスネットワーク、S‐GW(サービングゲートウェイ)、モビリティ管理要素、PDN‐GWまたはP‐GW(パケットデータネットワークゲートウェイ)およびポリシー制御エンティティを含む。モビリティ管要素がMME(モビリティ管理エンティティ)である場合、MMEとPDN‐GW間で交換される信号はS‐GWを横断しなければならない。モビリティ管理要素がSGSN(サービングGPRSサポートノード)である場合、SGSNもまたS‐GWにトンネル管理要求を送信し、S‐GWと協働して、PDN‐GWにより開始されるトンネル管理要求を処理する。
【0015】
本発明のトンネル管理方法、装置およびシステムの実施形態は、添付図面を参照して詳細に説明される。
実施形態1
【0016】
第1の実施形態はトンネル管理方法に関する。図2に示したように、上記方法は以下のステップを含む。
【0017】
201:通信システムにおいて、ユーザプレーン転送経路を管理することが必要な場合、開始ノードはトンネル管理要求をトンネル管理ノードに送信する。
202:トンネル管理ノードは、開始ノードからトンネル管理要求を受信し、適切な処理を実行し、トンネル管理要求の成功または失敗を示す原因値を含む応答を開始ノードに送信する。応答メッセージはまたトンネル管理要求の失敗を引き起こしたノードの情報も含む。
【0018】
本実施形態は、別のトンネル管理方法を提供する。図3に示したように、上記方法は以下のステップを含む。
【0019】
301:通信システムにおいて、ユーザプレーン転送経路を管理することが必要な場合、開始ノードはトンネル管理要求をトンネル管理ノードに送信する。
302:トンネル管理ノードは、開始ノードからトンネル管理要求を受信し、適切な処理を実行し、トンネル管理要求の成功または失敗を示す原因値を含む応答を開始ノードに送信する。処理失敗後に返送される応答メッセージはまたノード情報も含む。
303:開始ノードは、ノード情報にもとづいてトンネル管理要求の失敗を引き起こしたノードを見出す。実際には、失敗の理由は様々であり、したがってトンネル管理要求の失敗を引き起こしたノードが特定された後に、様々な処理が要求される。本発明の以下の実施形態は、4つのエラーの原因に関する処理を説明する。
【0020】
図2に示したトンネル管理方法によると、本発明の実施形態はトンネル管理装置を提供する。図4に示すように、この装置は受信ユニット41および送信ユニット42を含む。
【0021】
受信ユニット41は、開始ノードからトンネル管理要求を受信するように構成されている。トンネル管理要求の処理が失敗すると、送信ユニット42は、ノード情報を含む応答を開始ノードに送信するように構成されている。ノード情報は、トンネル管理要求の失敗を引き起こしたノードの情報であって、開始ノードは、ノード情報にもとづいて、トンネル管理要求の失敗を引き起こしたノードを見出すことができる。
【0022】
図3に示したトンネル管理方法によると、本発明の実施形態は、トンネル管理装置を提供する。図5に示したように、この装置は、送信ユニット51、受信ユニット52および探索ユニット53を含む。
【0023】
送信ユニット51は、トンネル管理要求をトンネル管理ノードに送信するように構成されている。トンネル管理ノードは、トンネル管理要求を処理した後に、ノード情報を含む応答をトンネル管理装置に返送する。受信ユニット52は、トンネル管理ノードにより返送されるノード情報を含む応答を受信するように構成されている。探索ノード53は、ノード情報にもとづいて、トンネル管理要求の失敗を引き起こしたノードを見出すように構成されている。
【0024】
本実施形態はまた通信システムを提供する。図6に示したように、通信システムは、開始ノード61およびトンネル管理ノード62を含む。通信システムにおいては、ユーザプレーン転送経路を管理することが必要な場合、開始ノード61は、トンネル管理要求を送信するように構成され、また、トンネル管理ノード62は、開始ノード61からトンネル管理要求を受信し、ノード情報を含む応答を開始ノード61に返送するように構成され、さらに、開始ノード61は、ノード情報にもとづいて、トンネル管理要求の失敗を引き起こすノードを見出し、その後それに応じて処理、例えば、有効なエラーチェック指令を選択するかまたは新しいノードを選択する等を実行するように構成されている。詳細には、エラーチェックでは、受信された応答に含まれるエラーの原因が「情報要素の紛失」または「情報要素デコードエラー」などの原因値を含む、情報要素(IE)関連エラーである場合、エラーがローカル装置実装により引き起こされているかどうかをチェックし、また、ローカル装置実装が正常である場合、応答メッセージ内に示されたエラーノードの装置実装をチェックする。これは、ノードがエラーの原因を迅速に特定することに役立ち、それによりその後の手順の正しい進行を保証する。
【0025】
本発明の実施形態では、ノード情報にもとづいて、トンネル管理要求の失敗が、トンネル管理ノードより引き起こされたか、またはリモートノードにより引き起こされたかを判定し、それにより開始ノードがより簡便に、より効果的におよびより迅速に、トンネル管理要求の失敗を処理することができるようにする。
【0026】
実施形態2
本実施形態を利用する環境はEPSネットワークである。図7は、特にトンネル管理要求が失敗した場合の、EPSネットワークにおける接続手順におけるネットワークの処理方法を示している。上記方法は以下のステップを含む。
【0027】
701:ユーザ装置(UE)は添付要求をMMEに送信する。
702:MMEは、ID要求をUEに送信する。
703:UEは、MMEのID要求に応答して、ID応答をMMEに送信する。
本実施形態では、ステップ702および703は任意選択的に(オプションとして)実施されてよい。
704:MMEおよびHSS(ホーム加入者サーバ)は共にUEの認証を完了する。
705:MMEおよびEIR(装置識別レジスタ)は共にUEのIMEIチェックを完了する。
706:MMEは、HSSにロケーション更新要求を送信する。
707:HSSは加入者データ挿入をMMEに送信する。
708:MMEは加入者データACK挿入をHSSに返送する。
709:HSSは、MMEが加入者データを認識した後、ロケーションACKの更新をMMEに返送する。
710:MMEはロケーション更新情報を受信した後、MMEは、デフォルトベアラ生成要求をS‐GWに送信して、ベアラを生成する。
711:トンネル管理ノードとして、S‐GWはMMEから送信されたデフォルトベアラ生成要求を処理する。S‐GWがデフォルトベアラ生成要求の処理に成功した場合、ステップ712、713、714、716および後続のステップが実行される、そうでない場合は、ステップ715および後続のステップが実行される。
712:S‐GWは、デフォルトベアラ生成要求をP‐GWに送信する。
713:P‐GWは、S‐GWから送信されたデフォルトベアラ生成要求を処理し、デフォルトベアラ生成要求をS‐GWに送信する。応答メッセージは、デフォルトベアラ生成要求の処理が成功または不成功であったかどうかを示し、不成功であった場合、処理の失敗の理由を示す原因値を含む。
714:S‐GWは、P‐GWから応答を受信した後に、デフォルトベアラ生成応答をMMEに返送し、デフォルトベアラ生成要求の処理が成功または不成功であったどうかを原因値によって示す。そしてP‐GWから受信した応答が処理の失敗を示す場合、MMEに返送される応答には、デフォルトベアラ生成要求の失敗を引き起こしたノードを識別する、P‐GWのノード情報を含む。ノード情報は、トンネル管理要求の失敗原因のフィールド(項目)または応答メッセージ内のIEにより示されることができる。
715:S‐GWは、デフォルトベアラ生成要求の処理に失敗した場合、原因値によってデフォルトベアラ生成要求の失敗の理由を示す、デフォルトベアラ生成応答をMMEに送信する。応答メッセージは、デフォルトベアラ生成要求の失敗を引き起こしたノードを識別するS‐GWのノード情報を含む。ノード情報は、トンネル管理要求のエラー原因の中のフィールドまたは応答メッセージ内のIEにより示されることができる。
【0028】
MMEが、デフォルトベアラ生成要求の失敗に関するさらなる情報を取得することを可能にするために、返送ステップにおいて返送される応答はさらに、デフォルトベアラ生成要求の失敗の理由を識別する追加的なロケーション情報を含むことができる。
【0029】
716:MMEは、デフォルトベアラ生成応答を受信した後、応答メッセージに含まれるノード情報と追加のロケーション情報とにもとづいて処理を実行する。
【0030】
図8に示したように、MMEの処理は以下のステップを含む。
801:MMEは、受信されたデフォルトベアラ生成応答をデコードして、応答に含まれるノード情報と追加のロケーション情報とを取得する。
802:MMEは、取得されたノード情報にもとづいてデフォルトベアラ生成要求の失敗を引き起こしたノードを見出す。
803:MMEは、原因値にもとづいてデフォルトベアラ生成要求の失敗の理由を分析する。要求の失敗の理由がリソースの不足または装置の故障である場合、処理はステップ804に進む。リソースの不足には、帯域幅の不足およびメモリの不足が含まれる。要求の失敗の理由がIEの欠落またはIEのデコードエラーである場合、例えば、デフォルトベアラ生成要求におけるIEが欠落しているまたはIEが正しくデコードされない場合、ステップ807が実行される。
804:MMEは、デフォルトベアラ生成要求の失敗を引き起こしたノードが、S‐GWまたはP‐GWのいずれであるかを判定する。ノードがS‐GWである場合、ステップ805が実行される。P‐GWである場合、ステップ806が実行される。
805:MMEはP‐GWを変更することなく新しいS‐GWを選択し、別のデフォルトベアラ生成要求を続行する。
806:MMEはS‐GWを変更することなく新しいP‐GWを選択し、別のデフォルトベアラ生成要求を続行する。
807:MMEは、追加のロケーション情報にもとづいて、欠落しているIEまたは誤ってデコードされたIEを特定する。オペレータは最初に、MMEにおいてエラーが発生しているかどうか、例えば、送信された要求メッセージ内のIEが正しいかどうかをチェックすることができる。IEが正しくない場合、オペレータはMMEをチェックして、MMEが次の接続手順において正しいデフォルトベアラ生成要求を送信するようにすることができる。IEが正しい場合、オペレータは、デフォルトベアラ生成要求の失敗を引き起こしたノードにおいてエラーが発生しているかどうかをチェックすることができる。
【0031】
実際には、デフォルトベアラ生成要求の失敗の理由は様々であるため、MMEはそれに応じた様々な処理を実行する必要がある。
【0032】
本実施形態におけるS‐GWとP‐GW間のインタフェースプロトコルは、GTP(GPRSトンネリングプロトコル)である。実際には、S‐GWおよびP‐GWは、PMIP(プロキシモバイルIPプロトコル)を介して通信されてもよく、この場合、上記のステップ712およびステップ713は以下のように修正される。
712’:S‐GWは、プロキシバインディング更新要求をP‐GWに送信する。
713’:P‐GWは、S‐GWからのプロキシバインディング更新要求を処理し、P‐GWがプロキシバインディング更新要求の処理に失敗した場合、応答をS‐GWに送信する。この応答は詳細にはプロキシバインディングACKであり、これは処理の失敗を示す原因値を含む。
【0033】
S‐GWから返送される応答に含まれるノード情報によって、MMEは、デフォルトベアラ生成要求の失敗を引き起こしたノードを認識する。デフォルトベアラ生成要求が失敗した場合、MMEは、失敗を引き起こしたノードを時間内に調整して、後続の手順が正しく実行されるようにすることができる。
【0034】
実施形態3
本実施形態はトラッキングエリア更新手順に適用可能である。図9に示したように、トンネル管理要求が失敗した場合、ネットワーク側における処理は以下の手順を含む。
【0035】
901:UEは、eNodeB(evolved NodeB:進化型NodeB)にトラッキングエリア更新要求を送信し、eNodeBは新しいMMEにトラッキングエリア更新要求を送信する。
902:新しいMMEはトラッキングエリア更新要求を受信し、古いMMEからコンテキストを取得する。
903:新しいMMEは、eNodeBから送信されたユーザ位置情報にもとづいて、新しいS‐GWを選択するかどうかを決定する。新しいMMEが新しいS‐GWを選択しないことを決定した場合、新しいMMEはベアラ更新要求を古いS‐GWに送信する。
904:トンネル管理ノードとして、古いS‐GWは新しいMMEから送信されたベアラ更新要求を処理する。古いS‐GWがベアラ更新要求の処理に成功した場合、ステップ905、906、907、909および後続のステップが実行される。そうでない場合は、ステップ908および後続のステップが実行される。
905:古いS‐GWは、ベアラ更新要求をP‐GWに送信する。
906:P‐GWは、古いS‐GWからのベアラ更新要求を処理し、ベアラ更新要求を古いS‐GWに送信する。応答メッセージは、ベアラ更新要求の処理が成功または不成功であるかどうかを示し、不成功である場合は、処理の失敗の理由を示す、原因値を含む。
907:古いS‐GWは、P‐GWからベアラ更新応答を受信し、ベアラ更新応答を新しいMMEに送信し、その原因値によってベアラ更新要求の処理が成功または不成功であるかどうかを示し、P‐GWから返送されたベアラ更新応答に含まれる原因値が、処理の失敗を示す場合、新しいMMEに返送する応答は、ベアラ更新要求の失敗を引き起こしたノードを識別するP‐GWのノード情報を含む。ノード情報は、トンネル管理要求の失敗原因のフィールドまたは応答メッセージ内のIEにより示されることができる。
【0036】
新しいMMEがベアラ更新要求の失敗に関するさらなる情報を取得することを可能にするために、前述のステップにおいて返送される応答はさらに、ベアラ更新要求の失敗の理由を識別する追加的なロケーション情報を含んでもよい。
【0037】
908:古いS‐GWがベアラ更新要求の処理に失敗した場合、古いS‐GWは、ベアラ更新応答を新しいMMEに送信し、この応答は、原因値によってベアラ更新要求の失敗の理由を示し、またベアラ更新要求の失敗を引き起こしたノードを識別する古いS‐GWのノード情報を含む。
909:新しいMMEは、ベアラ更新応答を受信し、応答メッセージ内のノード情報にもとづいて処理を実行する。例えば、IE関連エラーの場合には新しいMMEは最初にローカルノードのエラーをチェックし、次に、エラー発生を引き起こしたノードのエラーをチェックする。
【0038】
本実施形態では、MMEのみがトラッキングエリア更新手順において更新されるが、場合により、S‐GWも更新される。S‐GWの更新が必要な場合、更新処理は図9に示されるものと同様であるが、唯一の相違は、古いS‐GWにより行われた機能は、破線により示されるように、新しいS‐GWにより行われる。
【0039】
新しいMMEがコンテキストを取得するステップは、ステップ901および902と同一である。新しいMMEがコンテキストを取得した後、新しいMMEは、新しいS‐GWを選択するかどうかを決定する。新しいS‐GWが選択された場合、新しいMMEは、ベアラ作成要求を新しいS‐GWに送信する。新しいS‐GWがベアラ作成要求の処理に成功した場合、新しいS‐GWは、ベアラ更新要求をP‐GWに送信する。そうでない場合は、新しいS‐GWは、ベアラの更新の失敗が新しいS‐GWにより引き起こされていることを示す新しいS‐GWのノード情報を含むベアラ作成応答を、新しいMMEに返送する。ベアラ更新要求を処理した後、P‐GWはベアラ更新応答を新しいS‐GWに返送する。P‐GWがベアラ更新要求の処理に失敗すると、P‐GWは、エラー原因を含むベアラ更新応答を新しいS‐GWに返送する。新しいS‐GWもまたベアラ作成応答を新しいMMEに送信する。P‐GWから受信された応答メッセージが処理の失敗を示している場合、新しいMMEに返送される応答は、ベアラ更新の失敗がP‐GWにより引き起こされていることを示すP‐GWのノード情報を含む。
【0040】
実際には、第2および第3の実施形態ではこれらと同様の手順が、多くのシナリオにおいて、例えば、ルーティングエリア更新およびPDN接続において、トンネル管理要求の失敗通知のために採用される。
【0041】
UEからのルーティングエリア更新要求に関しては、ルーティングエリア更新シナリオでは、以下の2つの場合が存在する。
【0042】
第1の場合では、S‐GWが変更される。この場合、新しいSGSNは、ベアラ作成要求の開始ノードとして動作し、新しいS‐GWは、ベアラ作成要求のトンネル管理ノードとして動作し、P‐GWはリモートノードとして動作する。手順は図10の実線により示される。
【0043】
UEはルーティング領域更新要求を新しいSGSNに送信する。新しいSGSNは古いSGSNからコンテキストを取得し、その後ベアラ作成要求を新しいS‐GWに送信する。新しいS‐GWがベアラ作成要求を正しく処理した場合、新しいS‐GWは、ベアラ更新要求をP−GWに送信する。そうでない場合は、新しいS‐GWは、ベアラ生成の失敗が新しいS‐GWにより引き起こされたことを示す新しいS‐GWのノード情報を含む、ベアラ作成応答を新しいSGSNに送信する。ベアラ更新要求を処理した後、P‐GWは、原因値によって処理の成功または失敗を示すベアラ更新応答を新しいS‐GWに返送する。P‐GWがベアラ更新要求の処理に失敗した場合、P‐GWは、失敗を示すベアラ更新応答を新しいS‐GWに返送する。新しいS‐GWはまた、新しいSGSNにベアラ作成応答を送信し、P‐GWから返送されたメッセージが処理の失敗を示す場合、新しいSGSNに返送されるメッセージには、ベアラ生成の失敗がP‐GWにより引き起こされたことを示すP‐GWのノード情報を含む。
【0044】
第2の場合では、S‐GWは変更されない。この場合、古いSGSNはルーティング領域更新要求の開始ノードとして動作し、古いS‐GWはルーティング領域更新要求のトンネル管理ノードとして動作し、P‐GWはリモートノードとして動作する。手順は図10における破線により示される。
【0045】
UEはルーティング領域更新要求を古いSGSNに送信する。古いSGSNはベアラ更新要求を古いS‐GWに送信する。古いS‐GWがベアラ更新要求を正しく処理した場合、古いS‐GWはベアラ更新要求をP‐GWに送信する。そうでない場合は、古いS‐GWは、ベアラの更新の失敗が古いS‐GWにより引き起こされたことを示す古いS‐GWのノード情報を含む、ベアラ更新応答を古いSGSNに返送する。ベアラ更新要求を処理した後、P‐GWは、原因値によって処理の成功または失敗を示すベアラ更新応答を古いS‐GWに返送する。P‐GWがベアラ更新要求の処理に失敗した場合、P‐GWは、失敗を示すベアラ更新応答を古いS‐GWに返送する。古いS‐GWはまた、ベアラ更新応答を古いSGSNに送信し、P‐GWから返送されたメッセージが処理の失敗を示した場合、古いSGSNに返送されるメッセージは、ベアラの更新の失敗がP‐GWにより引き起こされたことを示すP‐GWのノード情報を含む。
【0046】
上記の説明から明らかなように、本実施形態における方法によれば、トラッキングエリア更新またはルーティングエリア更新の手順における、トラッキングエリア更新またはルーティングエリア更新の失敗を引き起こしたノードを示すことができ、それによりトラッキングエリア更新またはルーティングエリア更新の失敗を引き起こしたノードを時間内に調整して、後続の手順が正しく進行するようにすることができる。
【0047】
実施形態4
第4の実施形態のシナリオは、進化型UMTS地上無線アクセスネットワーク(E−UTRAN)から、UMTS地上無線アクセスネットワーク(UTRAN)へのハンドオーバである。図11に示したように、トンネル管理要求が失敗した場合、ネットワークの処理は以下のステップを含む。
【0048】
1101:UEは、無線アクセスネットワークのターゲットSGSNとの間にダウンリンクサービスパケットのための転送トンネルを生成し、サービング無線ネットワークサブシステム(SRNS)コンテキストをターゲットSGSNに送信する。
1102:ターゲットSGSNはSRNSコンテキストを受信し、ベアラ更新要求をターゲットS‐GWに送信する。
1103:トンネル管理ノードとして、ターゲットS‐GWはターゲットSGSNから送信されたベアラ更新要求を処理する。ターゲットS‐GWがベアラ更新要求の処理に成功した場合、ステップ1104、1105、1107および後続のステップが実行される。そうでない場合は、ステップ1106および1108が実行される。
1104:ターゲットS‐GWは、ベアラ更新要求をP‐GWに送信する。
1105:P‐GWは、ターゲットSGSNから送信されたベアラ更新要求を処理し、処理の成功または失敗を示す原因値を含むベアラ更新応答をターゲットS‐GWに返送する。P‐GWがベアラ更新要求の処理に失敗した場合、P‐GWは、エラー原因およびP‐GWのノード情報を含むベアラ更新応答をターゲットS‐GWに返送する。
1106:ターゲットS‐GWがベアラ更新要求の処理に失敗すると、ターゲットS‐GWは、ベアラ更新応答をターゲットSGSNに送信し、この応答は、原因値によってベアラ更新要求の失敗の理由を示し、またベアラ更新要求の失敗を引き起こしたノードを識別するターゲットS‐GWのノード情報を含む。
1107:ターゲットS‐GWは、P‐GWから応答を受信し、そしてベアラ更新要求の処理が成功または不成功であるかどうかを示す原因値を含む、ベアラ更新応答をターゲットSGSNに送信する。P‐GWから受信された応答に含まれる原因値が処理の失敗を示す場合、ターゲットS‐GWは、P‐GWからの応答内のノード情報をターゲットSGSNに透過的に送信する。ノード情報は、トンネル管理要求の失敗原因のフィールドまたは応答メッセージ内のIEにより示されることができる。
【0049】
ターゲットSGSNが、ベアラ更新要求の失敗に関するさらなる情報を取得することを可能にするために、前述のステップにおいて返送される応答はさらに、ベアラ更新要求の失敗の特定の理由を識別する追加のロケーション情報を含むことができる。
【0050】
1108:ターゲットSGSNは、ベアラ更新応答を受信した後、応答メッセージに含まれるノード情報と追加のロケーション情報とにもとづいて処理を実行する。IE関連エラーの場合は、ターゲットSGSNは最初にローカルノードにおけるエラーをチェックする。SGSNの処理が正しいことが決定された後、エラー発生を引き起こしたノードがエラーをチェックし、それにより後続の手順が正しく進行するようにすることができる。リソースの不足の場合、ノード情報がターゲットS‐GWのエラーを示すと、ターゲットSGSNは新しいS‐GWを選択して、トンネル管理手順を開始することができる。
【0051】
上記の説明から明らかなように、本発明の実施形態における方法によれば、E‐UTRANからUTRANへのハンドオーバの間においてベアラ更新の失敗を引き起こしたノードが、ターゲットS‐GWまたはP‐GWのいずれであるかを示し、それによりターゲットSGSNが時間内にベアラ更新の失敗を引き起こしたノードを調整して、後続の手順が正しく進行するようにすることができる。
【0052】
実施形態5
第5の実施形態のシナリオはPDN接続手順である。図12に示したように、手順が失敗した場合、本実施形態の方法は以下のステップを含む。
【0053】
1201:UEは、PDN接続要求をMMEに送信する。
1202:MMEはPDN接続要求を受信し、デフォルトベアラ作成要求をS‐GWに送信して、ベアラを生成する。
1203:トンネル管理ノードとして、S‐GWはデフォルトベアラ作成要求を処理する。S‐GWがデフォルトベアラ作成要求の処理に成功した場合、ステップ1204からステップ1210および1212が実行される。そうでない場合は、ステップ1211および1212が実行される。
1204:S‐GWは、デフォルトベアラ作成要求をP‐GWに送信する。
1205:トンネル管理ノードとして、P‐GWはデフォルトベアラ作成要求を処理する。P‐GWがデフォルトベアラ作成要求の処理に成功した場合、ステップ1206からステップ1208、1210および1212が実行される。そうでない場合は、ステップ1209、1210および1212が実行される。
1206。P‐GWは、PCRF(Policy and Charging Rules Function:ポリシーおよび課金ルール機能)によってIP‐CAN(IP接続アクセスネットワーク)セッションを生成する。
1207:PCRFは、IP‐CANセッションの生成が成功または不成功かどうかを示す原因値を含む応答メッセージをP‐GWに送信する。
1208:P‐GWは、PCRFから応答を受信し、デフォルトベアラ作成要求の処理に成功または失敗したかどうかを示す原因値を含む、デフォルトベアラ作成応答をS‐GWに返送する。PCRFから受信された応答における原因値が処理の失敗を示す場合、S‐GWに返送された応答は、デフォルトベアラ作成要求の失敗を引き起こすノードを識別するPCRFのノード情報を含む。
1209:P‐GWは、デフォルトベアラ作成応答をS‐GWに送信し、この応答は、デフォルトベアラ作成要求が失敗したことを示す原因値と、デフォルトベアラ作成要求の失敗を引き起こすノードを識別するP‐GWのノード情報とを含む。
ノード情報は、トンネル管理要求の失敗原因のフィールドまたは応答メッセージ内のIEにより示されることができる。
【0054】
S‐GWがデフォルトベアラ作成要求の失敗に関するさらなる情報を取得することを可能にするために、ステップ1208および1209において返送される応答はさらに、デフォルトベアラ作成要求の失敗の理由を識別する追加のロケーション情報を含んでもよい。追加のロケーション情報は、トンネル管理要求の失敗原因のフィールドまたは応答メッセージ内のIEにより示されてもよい。
【0055】
1210:S‐GWはデフォルトベアラ作成応答をMMEに送信し、この応答は、デフォルトベアラ作成要求が失敗したことを示す原因値と、デフォルトベアラ作成要求の失敗を引き起こしたノードを識別するノード情報とを含む。ノード情報は、P‐GWから受信された応答に含まれる情報である。
【0056】
ノード情報は、トンネル管理要求の失敗原因のフィールドまたは応答メッセージ内にIEにより示されてもよい。MMEがデフォルトベアラ作成要求の失敗に関連するさらなる情報を取得することを可能にするために、前述のステップにおいて返送される応答はさらに、デフォルトベアラ作成要求の失敗の特定の理由を識別する追加のロケーション情報を含むことができる。追加のロケーション情報は、S‐GWにより受信された応答に含まれる追加のロケーション情報であってよい。追加のロケーション情報はまた、トンネル管理要求の失敗原因のフィールドまたは応答メッセージ内のIEにより示されることができる。
【0057】
1211:S‐GWはデフォルトベアラ作成応答をMMEに送信し、この応答は、デフォルトベアラ作成要求が失敗したことを示す原因値と、デフォルトベアラ作成要求の失敗を引き起こしたノードを識別するS‐GWのノード情報とを含む。
1212:MMEは、デフォルトベアラ作成応答を受信した後、応答メッセージに含まれるノード情報と追加のロケーション情報とにもとづいて処理を実行する。IE関連エラーの場合、MMEは最初にローカルノードにおけるエラーをチェックする。ローカルノードの処理が正しいことが判断された後、エラー発生を引き起こしたノードがエラーをチェックし、それにより次の手順が正しく進行させることができる。リソースの不足の場合、ノード情報がP‐GWのエラーを示すと、MMEは新しいP‐GWを選択し、新しいトンネル管理要求手順を開始することができる。特定のエラー原因、例えばIEが欠落している、IEが誤ってデコードされているなどは、追加のロケーション情報から知ることができる。
【0058】
上記の説明から明らかなように、PDN接続手順において、本発明の実施形態における方法によれば、PDN接続の失敗を引き起こしたノードが、S‐GW、P‐GWまたはPCRFのいずれであるかを示し、それにより、MMEがPDN接続の失敗を引き起こしたノードを調整することができ、後続手順を正しく進行させることができる。
【0059】
実施形態6
第6の実施形態のシナリオは、P‐GWにより開始されるベアラの生成である。図13に示したように、ベアラ生成の失敗を示す方法は以下のステップを含む。
【0060】
1301:P‐GWは、専用ベアラ作成要求をS‐GWに送信する。
1302:トンネル管理ノードとして、S‐GWは専用ベアラ作成要求を処理する。S‐GWが専用ベアラ作成要求の処理に成功した場合、ステップ1303からステップ1310およびステップ1312が実行される。そうでない場合は、ステップ1311および1312が実行される。
1303:S‐GWは専用ベアラ作成要求をMMEに送信する。
1304:MMEは専用ベアラ作成要求を受信し、MMEは専用ベアラ作成要求を処理する。MMEが専用ベアラ作成要求の処理に成功した場合、ステップ1305からステップ1308、1310および1312が実行される。そうでない場合は、ステップ1309、1310および1312が実行される。
1305:MMEは、ベアラ作成要求をUEのeNodeBに送信して、ベアラを生成する。
1306:eNodeBはUEとのRRC(無線リソース接続)を構成する。
1307:eNodeBはベアラ作成応答をMMEに返送する。RRC構成が失敗するか、またはeNodeBとS‐GW間のベアラが失敗する場合、eNodeBによってMMEに返送される応答には失敗の原因値が含まれる。
1308:MMEは専用ベアラ作成応答をS‐GWに返送し、この応答は、専用ベアラ生成の失敗の原因値と、専用ベアラ生成の失敗がeNodeBにより引き起こされたことを示すeNodeBのノード情報とを含む。ノード情報は、ベアラ生成の失敗原因のフィールドまたは応答メッセージ内のIEにより示されることができる。
1309:MMEは専用ベアラ作成応答をS‐GWに返送し、この応答は、専用ベアラ生成の失敗の原因値と、専用ベアラ生成の失敗がMMEにより引き起こされたことを示すMMEのノード情報とを含む。ノード情報は、ベアラ生成の失敗原因のフィールドおよび応答メッセージ内のIEにより示されることができる。
1310:S‐GWは専用ベアラ作成応答をP‐GWに送信し、この応答は、専用ベアラ作成要求が失敗したことを示す原因値と、専用ベアラ作成要求の失敗を引き起こしたノードを識別するノード情報とを含む。ノード情報はMMEから送信する応答メッセージに含まれる。ノード情報は、ベアラ作成要求の失敗原因のフィールドまたは応答メッセージ内のIEにより示されることができる。
1311:S‐GWは専用ベアラ作成応答をP‐GWに送信し、この応答は、専用ベアラ作成要求が失敗したことを示す原因値と、専用ベアラ作成要求の失敗を引き起こしたノードを識別するS‐GWのノード情報とを含む。
【0061】
P‐GWが専用ベアラ作成要求の失敗に関連するさらなる情報を取得することを可能にするために、前述のステップにおいて返送される応答はさらに、専用ベアラ作成要求の失敗の理由を識別する追加のロケーション情報を含むことができる。追加のロケーション情報もまた、トンネル管理要求の失敗原因のフィールドまたは応答メッセージ内のIEにより示されることができる。
【0062】
1312:P‐GWが専用ベアラ作成応答を受信した後、P‐GWは、応答メッセージに含まれる、ノード情報と追加のロケーション情報とにもとづいて処理を実行する。IE関連エラーの場合は、P‐GWは最初にローカルノードにおけるエラーをチェックする。ローカルノードの処理が正しいことが判定された後、エラー発生を引き起こしたノードがエラーをチェックして、次の手順が正しく進行するようにすることができる。
【0063】
上記の説明から明らかなように、専用ベアラ生成の手順において、本発明の実施形態の方法によれは、専用ベアラ生成の失敗を引き起こしたノードが、S‐GW、MMEまたはeNodeBのいずれであるかを示し、それにより、P‐GWが専用ベアラ生成の失敗を引き起こしたノードを調整して、後続の手順が正しく進行するようにすることができる。
【0064】
実施形態7
第2〜第6の実施形態によると、本発明の実施形態はトンネル管理装置を提供する。図14に示したように、上記装置は受信ユニット141および送信ユニット142を含む。
【0065】
受信ユニット141は、開始ノードからトンネル管理要求を受信するように構成されている。開始ノードのトンネル管理要求の処理に失敗した場合、送信ユニット142は、トンネル管理要求の失敗を引き起こしたノードのノード情報を含む応答を開始ノードに送信するように構成されている。
【0066】
トンネル管理要求の失敗を引き起こしたノードは、ローカルノードまたはリモートノードである可能性がある。失敗を引き起こしたノードがローカルノードである場合、トンネル管理装置の正しい処理を保証するために、送信ユニット142は判定モジュール1421および送信モジュール1422を含む。
【0067】
判定モジュール1421は、ローカルノードがトンネル管理要求を完了することができるかどうかを判定するように構成されている。送信モジュール1422は、判定モジュール1421が、ローカルノードがトンネル管理要求を完了することが不可能であると決定すると、トンネル管理要求の失敗の原因値とローカルノード情報とを含む応答メッセージを開始ノードに送信するように構成されている。ここで、ローカルノード情報はトンネル管理要求の失敗を引き起こしたノードのノード情報である。
【0068】
トンネル管理要求の失敗を引き起こしたノードがリモートノードである場合、2つの場合が存在する。
【0069】
第1の場合では、トンネル管理要求の失敗を引き起こしたノードは、ローカルノードに直接接続されている。ローカルノードがトンネル管理要求を正しく処理すると、送信ユニット142はさらに、トンネル管理要求をリモートノードに送信するように構成されている。リモートノードがトンネル管理要求を処理した後、リモートノードはトンネル管理応答をローカルノードに返送する。応答メッセージは、処理が成功または不成功であるかどうかを示す原因値を含む。ローカルノードの受信ユニット141はまた、リモートノードから応答を受信するように構成されている。リモートノードの処理が不成功である場合、応答はトンネル管理要求の失敗の原因値を含む。したがって、送信ユニット142によって開始ノードに送信される応答は、トンネル管理要求の失敗の原因値とリモートノードの情報とを含む。これは、リモートノードの情報を示す応答が、トンネル管理要求の失敗を引き起こしたノードのノード情報であることを意味する。
【0070】
第2の場合では、トンネル管理要求の失敗を引き起こしたノードは、他のリモートノードを介してローカルノードに接続されているリモートノードである。この場合、送信ユニット142はさらに、該他のリモートノードにトンネル管理要求を送信するように構成されている。他のリモートノードによってローカルノードに返送される応答は、トンネル管理要求の失敗の原因値と、リモートノードの情報であるノード情報とを含む。受信ユニット141はさらに、他のリモートノードから応答を受信するように構成されている。応答は、トンネル管理要求の失敗の原因値とノード情報とを含む。送信ユニット142は、失敗の原因値と受信されたノード情報とを含む応答を開始ノードに送信する。これは、ローカルノードが、トンネル管理要求の失敗の受信された原因値とノード情報とを開始ノードに透過的に転送することを意味する。
【0071】
トンネル管理要求の失敗の特定の理由を明確に区別するために、本実施形態において受信ユニット141により受信される応答はさらに、トンネル管理要求の失敗の特定の理由を識別する追加のロケーション情報を含んでいてよい。例えば、追加のロケーション情報には、IEが欠落しているかまたは誤ってデコードされていること、および必須IEが欠落していることが含まれていてよい。同様に、本実施形態において、送信ユニット142によって開始ノードに送信される応答にはまた、追加のロケーション情報を含むことができ、それにより開始ノードが失敗の正しい原因を見出すことができる。
【0072】
実際には、本発明の実施形態におけるトンネル管理装置は、S‐GW、P‐GW、MMEおよびSGSNなどの、多くのネットワークデバイスで構成されうる。
【0073】
第2の実施形態において図8に示したトンネル管理方法に従って、本発明の実施形態は、別のトンネル管理装置を提供する。図15に示したように、上記装置は送信ユニット151、受信ユニット152および探索ユニット153を含む。
【0074】
送信ユニット151は、トンネル管理ノードにトンネル管理要求を送信するように構成されている。トンネル管理ノードはトンネル管理要求を処理した後、トンネル管理応答を装置に返送する。処理が不成功である場合、装置に返送される応答はノード情報と追加のロケーション情報とを含む。ノード情報は、トンネル管理要求の失敗を引き起こすノードを識別する。追加のロケーション情報は、トンネル管理要求の失敗の特定の理由を識別する。受信ユニット152は、トンネル管理ノードにより返送されるノード情報を含む応答を受信するように構成されている。探索ユニット153は、ノード情報にもとづいてトンネル管理要求の失敗を引き起こすノードを見出すと共に、追加のロケーション情報にもとづいてトンネル管理要求の失敗の特定の理由を見出すことにより、エラーのチェックを促進するように構成されている。
【0075】
本実施形態の装置がエラーのチェックを正しく実行することを保証するために、トンネル管理装置はさらに処理ユニット154を含む。処理ユニット154は、トンネル管理要求の失敗の原因がリソースの不足または装置の故障である場合、新しいノードを選択して、トンネル管理要求の失敗を引き起こしたノードと置き換えるように構成されている。または、処理ユニット154は、トンネル管理要求の失敗の原因がIEの欠落またはIEのデコードエラーである場合、ローカルノードのエラーをチェックするか、あるいはトンネル管理要求の失敗を引き起こしたノードに対してエラーをチェックすることを指示するように構成されている。
【0076】
ネットワークデバイスが開始ノード、中間ノードおよびリモートノードとして定義されると、ローカルデバイスが要求を処理することができるかどうかを決定する、図14に示したトンネル管理装置の機能は、中間ノードまたはリモートノード上に構成することができる。リモートノードから応答を受信した後に、エラーノード指示を開始ノードに送信または透過的に転送する機能は、中間ノード上にのみ実装できる。図15に示したトンネル管理装置は、開始ノード上にのみ構成されている。特定の種類のトンネル管理要求に依存して、開始ノードは、MMEまたはP‐GWまたはSGSNであってもよい。
【0077】
本実施形態では、中間ノードによって開始ノードに返送される応答はノード情報を含み、この情報により、開始ノードはトンネル管理要求の失敗を引き起こしたノードを見出し、それに応じてノード調整を行うことにより、後続の手順が正しく進行するようにすることができる。
【0078】
実施形態8
第8の実施形態は通信システムを提供する。図16に示したように、通信システムは、開始ノード161およびトンネル管理ノード162を含む。ユーザプレーン転送経路を管理することが必要な場合、開始ノード161はトンネル管理要求をトンネル管理ノード162に送信するように構成されている。トンネル管理ノード162は、開始ノード161からトンネル管理要求を受信し、トンネル管理ノードがトンネル管理要求を完了することが可能であるかどうかを決定するように構成されている。トンネル管理ノード162がトンネル管理要求を完了することが不可能である場合、トンネル管理ノード162は、トンネル管理要求の失敗の原因値と、そのトンネル管理ノードがトンネル管理要求の失敗を引き起こしたノードであることを示すトンネル管理ノードの情報とを含む、応答を開始ノード161に送信する。開始ノード161はさらに、トンネル管理ノードによって返送される応答内のノード情報にもとづいて、トンネル管理要求の失敗を引き起こしたノードを見出し、関連エラーのチェックを実行するように構成されている。
【0079】
上記の通信システムは一般に、2つのネットワークデバイス、例えば、MMEとS‐GWの間およびS‐GWとP‐GWの間の通信に関する。
【0080】
第3のネットワークデバイスが通信システムに存在する場合、本実施形態の通信システムはさらにリモートノード163を含む。
【0081】
トンネル管理ノード162がトンネル管理要求を正しく処理できる場合、トンネル管理ノード162は、ローカルノードのエラーなどのある特定の理由によりトンネル管理要求の失敗を引き起こしうるリモートノード163に、トンネル管理要求を送信する。リモートノード163はさらに、トンネル管理要求の失敗の原因値を含む応答をトンネル管理ノード162に返送するように構成されている。この場合、トンネル管理ノード162はさらに、トンネル管理要求の失敗の原因値と、リモートノードがトンネル管理要求の失敗を引き起こしているノードであることを示すリモートノードの情報とを含む、応答を開始ノード161に送信するように構成されている。
【0082】
リモートノードが接続処理デバイスに接続され、開始ノードからのトンネル管理要求が接続処理デバイスにより処理される必要がある場合、およびトンネル管理要求の失敗を最終的に引き起こしたデバイスが接続処理デバイスである場合、通信システムの処理は以下のようになされる。
【0083】
トンネル管理ノード162がトンネル管理要求を処理することができる場合、トンネル管理ノード162は、トンネル管理要求をリモートノード163に送信する。リモートノード163が要求を正しく処理するので、トンネルリモートノードは要求を接続処理デバイスに送信する。接続処理デバイスが要求の処理に失敗すると、失敗の原因値をリモートノードにのみ返送する。したがって、リモートノード163によってトンネル管理ノード162に返送される応答は、トンネル管理要求の失敗の原因値と、接続処理デバイスのノード情報であるノード情報とを含む。この場合、トンネル管理ノード162はさらに、トンネル管理要求の失敗の原因値と受信されたノード情報とを含む応答を開始ノード161に送信するように構成されている。受信されたノード情報は、トンネル管理要求の失敗を引き起こしたノード、すなわち接続処理デバイスと一致する。本実施形態では、トンネル管理ノード162は、トンネル管理要求の失敗の原因値と受信されたノード情報とを開始ノードに透過的に転送する。
【0084】
本実施形態は、ユーザプレーン転送経路の管理中に予想される様々な失敗の原因について通信システムに適用可能であり、失敗の原因を開始ノードに示すことにより、開始ノードは適切な処理を実行する。
【0085】
開始ノードにより受信された応答がノード情報を含み、開始ノードが、ノード情報にもとづいてトンネル管理要求の失敗を引き起こしたノードを見出すことができるので、トンネル管理ノードがさらにトンネル管理要求をリモートノードに送信するとしても、開始ノードは、トンネル管理要求の失敗がトンネル管理ノードまたはリモートノードのいずれにより引き起こされたかを区別することができる。したがって、開始ノードは、より簡便に、より効果的に、より迅速にトンネル管理要求を処理することができる。
【0086】
前述の実施形態の説明によって、当業者であれば、本発明がハードウェアのみにより、またはソフトウェアと必要な汎用ハードウェアプラットフォームとにより実現されうることを理解されたい。しかしながら、ほとんどの場合は、ソフトウェアと必要な汎用ハードウェアプラットフォームとを使用することが好ましい。このような理解に基づくと、従来技術に貢献する本発明における技術的な解決方法のすべてまたは一部は、基本的に、ソフトウェアプロダクトの形式で具体化されうる。ソフトウェアプロダクトは、ハードディスク、コンパクトディスク読出し専用メモリ(CD‐ROM)およびフロッピー(登録商標)ディスクなどの、コンピュータ可読記憶媒体に格納される。ソフトウェアプロダクトは、コンピュータデバイス(パーソナルコンピュータ、サーバまたはネットワークデバイス)が本発明の実施形態において提供される方法を実行できるようにする、複数の命令を含む。
【0087】
本発明をいくつかの例示的な実施形態により説明してきたが、本発明はこのような実施形態に限定されない。当業者であれば、本発明の範囲から逸脱することなく本発明の様々な変更形態および代替形態を実現可能であることは明らかである。したがって、本発明の保護の範囲は添付の特許請求の範囲に従う。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16