JP2005223909A

JP2005223909A - 無線通信システムにおいてプロトコル・サポートを検出する方法

Info

Publication number: JP2005223909A
Application number: JP2005025767A
Authority: JP
Inventors: Alessio Casati; カサティアレッシオ
Original assignee: Lucent Technologies Inc
Current assignee: Nokia of America Corp
Priority date: 2004-02-02
Filing date: 2005-02-02
Publication date: 2005-08-18
Also published as: EP1560381A3; KR20060042907A; EP1560381A2; US20050172012A1; US7440459B2; EP1560381B1; KR101107846B1

Abstract

【課題】無線通信システムにおいてプロトコル・サポートを検出する方法を提供すること。
【解決手段】所与のノードが所与のプロトコル・バージョンをサポートしているかどうかを検出する方法において、送信元ノードが、第１のプロトコル・バージョンに基づいて要求メッセージを宛先ノードに送信する。送信元ノードは、要求に対する応答として指示メッセージを受信し、その指示メッセージに基づき、宛先ノードが第１のプロトコル・バージョンをサポートしていないことを検出することができる。したがって、送信元ノードと宛先ノードを介して、無線ネットワークのユーザと外部ネットワークの間で通信を確立することができる。
【選択図】図２

Description

本発明は、一般に、無線通信システムに関する。

汎用パケット無線サービス（ＧＰＲＳ）は、移動局と、インターネットなどのネットワーク間で短いデータ・バーストを可能にする２．５Ｇ技術（音声中心の第２世代（２Ｇ）無線技術と３Ｇ無線通信技術の間の間隙を埋める）である。短い伝送は、常時接続よりも低費用の接続を可能にするが、そのようなタイプの通信向けに設計された専用サービスで最もうまく機能する。ＧＰＲＳは、リリース９７（Ｒ９７）から始まった２Ｇ技術であるグローバル・システム・フォー・モバイル（ＧｌｏｂａｌＳｙｓｔｅｍｆｏｒＭｏｂｉｌｅ）通信（ＧＳＭ）、および第３世代パートナーシップ・プロジェクト（３ＧＰＰ）リリース９９（Ｒ９９）で始まった３Ｇユニバーサル・モバイル・テレコミュニケーションズ・サービス（ＵｎｉｖｅｒｓａｌＭｏｂｉｌｅＴｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎＳｅｒｖｉｃｅ）（ＵＭＴＳ）によってサポートされてきた。

ＧＰＲＳのサポートは、サービングＧＰＲＳサポート・ノード（ＳＧＳＮ）とゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）が、ＧＰＲＳトンネリング・プロトコル（ＧＴＰ）として知られるプロトコルを使用して、互いの間でパケットをトンネリングすることを要求する。一般に、ＳＧＳＮは、無線アクセス網（ＲＡＮ）およびＧＧＳＮを介して移動局とパケットを交換する。つまり、ＧＧＳＮは、ＳＧＳＮ、ならびにパケット・データ網と呼ばれる他のインターネット・プロトコル（ＩＰ）ネットワークとパケットを交換する。ＳＧＳＮとＧＧＳＮは、ＳＧＳＮとＧＧＳＮの間で交換されるパケットをトンネリングして、移動局がネットワークに対する接続地点を変更した場合（モバイルが移動した、つまり、モバイルが、あるＳＧＳＮから、モバイルが位置している別のＳＧＳＮに切り替えた場合のように）、パケットがＭＳに送信され、ＭＳによって受信されることが可能であるようにする。ＧＴＰは、ＧＴＰトンネルの独自の信号を介して、ＧＴＰトンネルのセットアップおよび維持を可能にする。ＧＴＰトンネルは、外部パケット・データ網と、ＧＰＲＳネットワーク内およびＵＭＴＳネットワーク内のＭＳユーザとの間におけるパケットの転送において必要な機構である。

Ｒ９９以前には、ＧＰＲＳのサポートは、ＧＴＰｖ０として知られるＧＴＰバージョンの使用に基づいていた。ＧＴＰｖ０は、「ＧＰＲＳＴｕｎｎｅｌｌｉｎｇＰｒｏｔｏｃｏｌ（ＧＴＰ）ａｃｒｏｓｓｔｈｅＧｎａｎｄＧｐＩｎｔｅｒｆａｃｅ，（Ｒｅｌｅａｓｅ１９９８）」という名称の３ＧＰＰ技術仕様書、３ＧＴＳ０９．０６０、バージョン７．９．０（２００２−６）、および３ＧＴＳ０９．０６０の以前のバージョンで規格が定められている。ＵＭＴＳなどの３Ｇシステム群の導入によって可能にされた追加の特徴をサポートする必要性により、ＧＴＰｖ１として知られる改訂されたプロトコル・バージョンが開発された。ＧＴＰｖ１は、「ＧＰＲＳＴｕｎｎｅｌｌｉｎｇＰｒｏｔｏｃｏｌ（ＧＴＰ）ａｃｏｒｓｓｔｈｅＧｎａｎｄＧｐＩｎｔｅｒｆａｃｅ（Ｒｅｌｅａｓｅ６）」という名称の３ＧＰＰ技術仕様書、３ＧＴＳ２９．０６０、Ｖ６．３．０（２００３−１２）、および３ＧＴＳ２９．０６０の以前のバージョンおよびリリースで規格が定められている。

ＧＴＰｖ０プロトコルは、ユーザ・データグラム・プロトコル（ＵＤＰ）ポート３３８６を介するトンネリング・トラフィック（ＭＳトラフィックを伝送するのに使用されるＧＴＰトンネル）およびトンネリング信号（ＭＳトラフィックを伝送するのに使用されるＧＴＰトンネルをセットアップし、維持するのに使用されるＧＴＰ）をサポートした。ＧＴＰｖ１プロトコルは、ＵＤＰポート２１５２を介するトンネリング・トラフィック、およびポート２１２３を介するトンネリング信号（ＧＴＰ−Ｃとして知られる）をサポートする。ＧＴＰ−Ｕメッセージが、パス内のＧＳＮペア間、またはＧＳＮ／ＲＮＣペア間で交換される。ＧＴＰ−Ｕメッセージは、ユーザ・データ・パケット、およびパス管理および誤り指示に関する信号メッセージを伝送するユーザプレーンメッセージである。ＧＴＰ−Ｃメッセージが、パス内のＧＳＮ／ＲＮＣペア間で交換される。ＧＴＰ−Ｃメッセージは、例えば、ＧＳＮペア間でＧＳＮ能力情報を転送すること、ＧＴＰトンネルを作成すること、更新すること、および削除すること、ならびにパス管理のために使用される制御プレーンメッセージである。

無線システムおよび無線技術が、デュアル・モード端末装置をサポートすることができ（つまり、２ＧのＧＳＭ移動局と３ＧのＵＭＴＳモバイル端末装置をともにサポートすることができ）、ＧＴＰｖ１とＧＴＰｖ０をともにサポートするＳＧＳＮが、ＧＴＰｖ０だけをサポートするＧＧＳＮにコンタクトできることも可能にして、ＧＳＭからＵＭＴＳへの円滑な移行を可能にするようにしなければならないという現在の市場の必要条件が存在する。

しかし、ＧＴＰｖ０とＧＴＰｖ１をともにサポートするノードの場合、ＧＴＰｖ０だけのノードにコンタクトしようと試みた後にＧＴＰｖ０に「フォールバック」する現在のやり方は、所与の回数のタイムアウトが経過するのを待ち、ＧＴＰｖ１を使用する数回の試みが失敗するのを待ってから、ＧＴＰｖ０を使用することができることによる。この手続きは、「ＤｉｆｆｅｒｅｎｔＧＴＰＶｅｒｓｉｏｎｓ」という名称のＴＳ２９．０６０のセクション１１．１．１に記載されている。

これは、ＧＴＰｖ０が、ポート３３８６だけをリッスンし、ＧＴＰｖ１対応ノードがＧＴＰｖ１通信を送るのに使用するポート２１２３はリッスンしないという事実に起因することに留意されたい。つまり、ＧＴＰｖ１は、ＧＴＰｖ０とは異なるＵＤＰ／ＩＰポート上で実行され、３ＧＰＰ標準（３ＧＰＰＴＳ２３．０６０および３ＧＰＰＴＳ２９．０６０）は、別のＧＳＮ（ＧＧＳＮなどの）がＧＴＰｖ１をサポートしているか否かを、ＧＳＮ（ＳＳＧＮなどの）がどのように知るかを明確に定義していない。

標準における曖昧さが、過度のタイムアウトの問題と相俟って、望ましくない遅延を生じさせる可能性がある。２つのバージョンで通信を交換するのに同一のポートが使用されていたとすれば、ＧＴＰｖ０ノードが、ＧＴＰｖ１の着信するＧＴＰパケットを検出し、ＴＳ２９．０６０のセクション７．２．３に記載される「バージョンサポートなし（ＶｅｒｓｉｏｎｎｏｔＳｕｐｐｏｒｔｅｄ）メッセージ」を送り返すことが可能であっただろう。２つの完全に異なるポートが使用されているため、ＧＴＰｖ０ノード（ＳＧＳＮであるか、ＧＧＳＮであるかに関わらず）は、ＧＴＰｖ０ノードからのＧＴＰトラフィックを検出することだけしかできない（ポート３３８６上で）。このシナリオからもたらされる遅延が、業界における懸念の元になっており、６００を超えるＧＳＭモバイル事業者の利益を代表する世界的な同業者団体であるＧＳＭ協会（ＧＳＭＡ）によって近年、研究されてきた。この団体からの「ＤｉｓｃｕｓｓｉｏｎＰａｐｅｒｏｎｐｒｏｂｌｅｍｓｆｏｕｎｄｗｈｅｎｉｎｔｅｒｗｏｒｋｉｎｇＧＳＮｓｏｆｄｉｆｆｅｒｅｎｔＧＴＰｖｅｒｓｉｏｎｓ」という名称の、次のリンク、ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇ／ｆｔｐ／ｔｓｇ＿ｃｎ／ＷＧ４＿ｐｒｏｔｏｃｏｌｌａｒｓ／ｔｓｇＮ４＿２１＿Ｂａｎｇｋｏｋ／Ｔｄｏｃｓ／Ｎ４−０３１２８２．ｚｉｐで見られる２００３年１０月の論文が、以上の懸念を記録に残し、以上の問題を説明している。この論文は、「ＳＧＳＮが、特定のタイムアウトを待ってからでないと、より低いプロトコル・バージョンに引き返すことができない可能性があるという事実は、容認できない（ＴｈｅｆａｃｔｔｈａｔｔｈｅＳＧＳＮｐｏｔｅｎｔｉａｌｌｙｈａｓｔｏｗａｉｔｆｏｒａｓｐｅｃｉｆｉｃｔｉｍｅ−ｏｕｔｂｅｆｏｒｅｄｒｏｐｐｉｎｇｂａｃｋｔｏａｌｏｗｅｒｐｒｏｔｏｃｏｌｖｅｒｓｉｏｎｉｓｎｏｔａｃｃｅｐｔａｂｌｅ）」と結論している。
３ＧＰＰ技術仕様書、「ＧＰＲＳＴｕｎｎｅｌｌｉｎｇＰｒｏｔｏｃｏｌ（ＧＴＰ）ａｃｒｏｓｓｔｈｅＧｎａｎｄＧｐＩｎｔｅｒｆａｃｅ，（Ｒｅｌｅａｓｅ１９９８）」３ＧＴＳ０９．０６０、バージョン７．９．０（２００２−６）、および以前のバージョン３ＧＰＰ技術仕様書、「ＧＰＲＳＴｕｎｎｅｌｌｉｎｇＰｒｏｔｏｃｏｌ（ＧＴＰ）ａｃｒｏｓｓｔｈｅＧｎａｎｄＧｐＩｎｔｅｒｆａｃｅ，（Ｒｅｌｅａｓｅ６）」３ＧＴＳ２９．０６０、Ｖ６．３．０（２００３−１２）、ならびに以前のバージョンおよびリリースＧＳＭＡｓｓｏｃｉａｔｉｏｎ、「ＤｉｓｃｕｓｓｉｏｎＰａｐｅｒｏｎｐｒｏｂｌｅｍｓｆｏｕｎｄｗｈｅｎｉｎｔｅｒｗｏｒｋｉｎｇＧＳＮｓｏｆｄｉｆｆｅｒｅｎｔＧＴＰｖｅｒｓｉｏｎｓ」、２００３年１０月、ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇ／ｆｔｐ／ｔｓｇ＿ｃｎ／ＷＧ４＿ｐｒｏｔｏｃｏｌｌａｒｓ／ｔｓｇＮ４＿２１＿Ｂａｎｇｋｏｋ／Ｔｄｏｃｓ／Ｎ４−０３１２８２．ｚｉｐ３ＧＰＰ技術仕様書、「ＴｅｃｈｎｉｃａｌＳｐｅｃｉｆｉｃａｔｉｏｎＧｒｏｕｐＳｅｒｖｉｃｅｓａｎｄＳｙｓｔｅｍＡｓｐｅｃｔｓ；ＧｅｎｅｒａｌＰａｃｋｅｔＲａｄｉｏＳｅｒｖｉｃｅ；Ｓｅｒｖｉｃｅｄｅｓｃｒｉｐｔｉｏｎ；Ｓｔａｇｅ２（Ｒｅｌｅａｓｅ６）」ＲＦＣ７９２−ＩｎｔｅｒｎｅｔＣｏｎｔｒｏｌＭｅｓｓａｇｅＰｒｏｔｏｃｏｌ（ＩＣＭＰ）

本発明の典型的な実施形態は、プロトコル・サポートの欠如を検出する方法、所与のプロトコル・バージョンがサポートされていないことを示す方法、およびアクティブ化ルーチンを円滑にして、無線ネットワークのユーザが、ユーザの存在を所与の外部ネットワークに知らせることができるようにする方法を対象とする。一般に、各方法の一環として、送信元ノードが、第１のプロトコル・バージョンに基づいて要求メッセージを宛先ノードに送信する。送信元ノードは、その要求に対する応答として指示メッセージを受信し、その指示メッセージに基づき、宛先ノードが第１のプロトコル・バージョンをサポートしていないことを検出することができる。したがって、送信元ノードと宛先ノードを介して、無線ネットワークのユーザと外部ネットワークの間で通信がより迅速に確立されることが可能である。

本発明の典型的な実施形態は、本明細書で以下に提供する詳細な説明、および添付の図面からより十分に理解されることになろう。単に例示として提供しており、そのため、本発明の典型的な実施形態を限定するものではないこの図面では、同様の要素を同様の符号で表している。

本発明の以下の説明は、次世代の広帯域符号分割多重アクセス（ＷＣＤＭＡ）無線インタフェース技術を実装するユニバーサル・モバイル・テレコミュニケーション・システムズ（ＵＭＴＳ）ネットワークに基づくが、本明細書で示し、説明する典型的な実施形態は、例示することだけを意図しており、全く限定するものではないことに留意されたい。このため、様々な改変形態が、当業者には明白となろう。

以下に使用する場合、基地局サブシステム（ＢＳＳ）、基地トランシーバ局（ＢＴＳ）、およびノードＢは、同義であり、インターネットなどのパケット交換データ網（ＰＳＤＮ）と１つまたは複数の移動局の間でデータ接続を提供する無線アクセス設備を表すことが可能である。さらに、以下で使用する場合、ユーザ機器（ＵＥ）および移動局（ＭＳ）という用語は、互いに区別なしに使用される可能性がある。ＵＥおよびＭＳは、ユーザ、加入者、無線端末装置、および遠隔局と同義であり、無線通信網における無線リソースの遠隔ユーザを表す。

図１は、本発明の典型的な実施形態によるＵＭＴＳアーキテクチャの高レベル図を示す。このＵＭＴＳアーキテクチャは、単に典型的なネットワーク・アーキテクチャまたは典型的なシステム・アーキテクチャとして提供しており、本発明の典型的な実施形態は、ＧＰＲＳにも適用可能であるものと理解されたい。ＵＭＴＳアーキテクチャは、一つには、例えば、ＧＰＲＳとＵＭＴＳに共通であることが可能なコア・ネットワークのパケット交換側を例示するために提供している。

図１を参照すると、ＵＭＴＳアーキテクチャ１００が、ＵＭＴＳ地上無線アクセス網（ＵＴＲＡＮ）１５０と呼ぶことができる無線アクセス網部分を含む。ＵＴＲＡＮ１５０は、Ｕｕ無線インタフェースを介して無線インタフェース部分１０１、すなわち、移動局のようなユーザ機器（ＵＥ）とインタフェースをとる。Ｕｕ無線インタフェースは、ＵＴＲＡＮ１５０と１つまたは複数のＵＥ１０５の間の無線インタフェースである。Ｕｕ無線インタフェースは、例えば、ノードＢがＵＥと互に接続することを可能にする。

ＵＴＲＡＮ１５０は、例えば、インタフェース、Ｉｕ−ｃｓおよびＩｕ−ｐｓを介して１つまたは複数のコア・ネットワーク（ＣＮ）１７５（簡潔にするため、１つだけを図１に示す）ともインタフェースをとる。インタフェース・ユニット（回線交換）インタフェースの略であるＩｕ−ｃｓは、ＲＮＣを移動交換センタ（ＭＳＣ）にリンクするＵＭＴＳにおけるインタフェースである。インタフェース・ユニット（パケット交換）インタフェースの略であるＩｕ−ｐｓは、ＲＮＣをサービングＧＰＲＳサポート・ノード（ＳＧＳＮ）にリンクするＵＭＴＳにおけるインタフェースである。Ｉｕモードは、Ｉｕインタフェースの両部分のサポートとは独立であり、例えば、ＩｕモードのＳＧＳＮ（またはＧＧＳＮ）が、Ｉｕ−ｐｓインタフェースだけを使用するのに対して、ＩｕモードのＭＳＣは、Ｉｕ−ｃｓ（回線交換）インタフェースを使用する。

ＣＮ１７５は、移動交換センタ（ＭＳＣ）１８０、ＳＧＳＮ１８５、およびゲートウェイＧＰＲＳサービング／サポート・ノード群（ＧＧＳＮ）１８８を含むことが可能である。ＧＧＳＮ１８８は、外部ネットワーク１９０へのゲートウェイである。ＳＧＳＮ１８５およびＧＧＳＮ１８８が中心とされる。というのは、典型的な実施形態は、パケット交換アプリケーションのために実施されることが可能な方法を対象とするからである。ＳＧＳＮおよびＧＧＳＮは、ＧＰＲＳ構造の一部としてであるか、ＵＭＴＳ構造の一部としてであるかに関わらず、ＵＴＲＡＮなどのＲＡＮを介して移動局とパケットを交換し、他のインターネット・プロトコル（ＩＰ）網（パケット・データ網）ともパケットを交換する。外部ネットワーク群１９０は、パケット交換電話網（ＰＳＴＮ）１９３またはデジタル総合サービス網（ＩＳＤＮ）、およびパケット・データ網１９５などの様々な回線ネットワーク１９３を含むことが可能である。ＵＴＲＡＮ１５０は、例えば、Ｔ１／Ｅ１、ＳＴＭ−ｘなどの迂回中継設備（図示せず）を介してＣＮ１７５にもリンクされることが可能である。

ＵＴＲＡＮ１５０は、一般に、Ｕｕインタフェース・プロトコルを使用して、一群のＵＥ１０５にサービスを提供することが可能な、ノードＢ１１０と呼ばれるセル・サイト群を含むことが可能である。ノードＢ１１０は、Ｉｕプロトコルを使用して、ＵＴＲＡＮ１５０内のネットワーク・コントローラ群（ＲＮＣ）１１５を通信する無線トランシーバ群を含むことが可能である。

ＵＴＲＡＮ１５０内のＲＮＣ群１１５は、例えば、Ｉｕ−ｒプロトコルを使用して互いに通信することができる。Ｉｕ−ｒは、ＲＮＣ群が互いに接続することを可能にする。いくつかのノードＢ１１０が、単一のＲＮＣ１１５とインタフェースをとることが可能であり、ＲＮＣ１１５において、呼び出しセットアップおよび制御活動に加えて、無線リソース管理や、ソフト・ハンドオフにおけるフレーム選択などのタスクが実行されることが可能である。ノードＢ群１１０とＲＮＣ群１１５は、例えば、ＡＴＭベースのパケット・トランスポートを使用するリンクを介して接続されることが可能である。

以下に説明する典型的な検出方法は、例えば、パケット領域において実施することができる。一般に、パケット領域は、パケット・モード技術を使用して、高速および低速のデータおよび信号を効率的な形で転送する。パケット領域は、ネットワーク・リソースおよび無線リソースの使用を最適化するように設計される。無線サブシステムとネットワーク・サブシステムの間の厳密な分離が、通常、維持され、ネットワーク・サブシステムが、他の無線アクセス技術で再使用されることを可能にしている。

共通のパケット領域コア・ネットワーク（例えば、ＵＭＴＳとＧＰＲＳに共通の）が、ＧＥＲＡＮとＵＴＲＡＮなどの両方の無線アクセス網（ＲＡＮ）のために使用されることが可能である。この共通コア・ネットワークが、これらのＲＡＮと一緒になって、ＧＰＲＳサービスを提供する。共通コア・ネットワークは、リアルタイムでないトラフィック（例えば、断続的なデータ転送およびバースト性の強いデータ転送、大量データの不定期の伝送）とリアルタイムのトラフィック（例えば、音声、ビデオ）の効率的な転送を可能にするいくつかのサービス品質（ＱｏＳ）レベルをサポートするように設計される。標準のデータ・プロトコルに基づくアプリケーション、およびショート・メッセージ・サービス（ＳＭＳ）がサポートされることが可能であり、インターネット・プロトコル（ＩＰ）網との相互動作が定義されることが可能である。

ＳＧＳＮ／ＧＧＳＮ一般機能
ＳＧＳＮは、個別のＭＳの位置を常に把握しており、セキュリティ機能およびアクセス制御を実行する。ＳＧＳＮは、Ｇｂインタフェース（ＢＳＳとＳＧＳＮの間のインタフェース）またはＩｕインタフェースを介してＧＥＲＡＮ基地局サブシステム（ＢＳＳ）に接続されることが可能であり、かつ／またはＩｕインタフェースを介してＵＴＲＡＮに接続されることが可能である。ＧＧＳＮは、パケット・データ網との相互動作を提供し、ＩＰベースのパケット領域公共陸上移動ネット（ＰＬＭＮ）バックボーン・ネットワークを介してＳＧＳＮに接続される。

ＧＰＲＳサービスを使用すること
ＧＰＲＳサービスを使用するため、ＭＳはまず、ＧＰＲＳアタッチと呼ばれるものを実行することにより、ＭＳの存在をネットワークに知らせる。アタッチは、ＭＳが、例えば、ＧＰＲＳを介するＳＭＳ、ＳＧＳＮを介するページング、および着信パケット・データの通知に応対可能であるようにする。ＧＰＲＳサービスを使用してパケット・データ送受信するため、ＭＳは、ＭＳが使用することを望むパケット・データ・プロトコル（ＰＤＰ）コンテキストを活動化する。ＰＤＰは、ＧＰＲＳとインタフェースをとる外部パケット・データ網によって使用されるネットワーク・プロトコルである。この動作は、対応するＧＧＳＮ内でＭＳを認知させ、データ網との相互動作が開始されることが可能である。

ユーザ・データは、カプセル化およびトンネリングとして知られる方法を使用して、ＭＳとパケット・データ網の間でトランスペアレントに転送されることが可能である。すなわち、データ・パケットは、ＧＰＲＳ特有のプロトコル情報を備え、ＭＳとＧＧＳＮの間で転送される。このトランスペアレントな転送方法により、ＰＬＭＮが外部データ・プロトコルを解釈する必要が軽減され、将来、追加の相互動作プロトコルを容易に導入することができるようになる可能性がある。

ＧＰＲＳ加入は、１つまたは複数のＰＤＰアドレスの加入を含む。各ＰＤＰアドレスは、ＰＤＰコンテキストの要素である。ＰＤＰコンテキストは、例えば、ＰＤＰアドレスに関してＭＳおよびＧＳＮにおいて保持される情報セットとして説明することができる。同一のＰＤＰアドレスが、ＭＳ、ＳＧＳＮ、およびＧＧＳＮにおける１つまたは複数のＰＤＰコンテキストの中で出現することが可能である。各ＰＤＰコンテキストは、トラフィック・フロー・テンプレート（ＴＦＴ）に関連することが可能である。ＴＦＴは、ＧＧＳＮによって、異なるユーザ・ペイロード・パケットを区別し、異なるＰＤＰコンテキストを介して異なるＱｏＳ要件で、ただし、同一のＰＤＰアドレスにパケットを伝送するために使用される。すべてのＰＤＰコンテキストは、２つの状態（アクティブまたは非アクティブ）のどちらかで、独立に存在する。ＰＤＰ状態は、そのＰＤＰアドレスおよびＴＦＴに関して、データ転送が可能にされているか否かを示す。

ＧＴＰｖ１サポートの欠如の検出
図２は、本発明の典型的な実施形態による方法を示す信号の流れ図である。図２は、ＧＴＰｖ１などの所与のプロトコル・バージョンが、宛先ノードにおいてサポートされていないかどうかを検出する方法、ならびに宛先ノードが、例えば、ＧＴＰｖ１などの所与のプロトコル・バージョンのサポートの欠如を明示的に示すことができる方法を説明するために提供している。さらに、図２は、ＭＳがＭＳの存在を、例えば、外部ネットワークに知らせるために使用するＰＤＰコンテキスト活動化手続きを円滑にする方法を示す。以上の方法のそれぞれが、前述したとおり、例えば、プロトコル・バージョン・サポートの欠如を検出する際の遅延を短縮することができる。

図２は、典型的な実施形態による方法の典型的な応用例として、特定の応用例（ＭＳが開始したＰＤＰコンテキスト活動化）を示す。方法は、任意のＧＳＮペアの間で、いずれの方向で開始された通信にも適用可能であることを理解されたい。１つのプロトコル・バージョンを使用するＧＧＳＮから、別のプロトコル・バージョンを使用するＳＳＧＮに対して開始されたメッセージや、異なるバージョンをそれぞれがサポートする２つのＳＳＧＮの間で開始されたメッセージなどである。

図２を参照すると、ＭＳがＰＤＰコンテキスト活動化手続きを試みる文脈でネットワークにおけるＭＳとＳＧＳＮおよびＧＧＳＮの間の流れが示されている。ＭＳは、最初、ＰＤＰコンテキストを活動化しようと試みる（機能２１０）。例えば、ＭＳは、ＰＤＰコンテキスト活動化要求メッセージをＳＧＳＮに送信する。これに関するアクティブ化手続きは、例えば、「ＴｅｃｈｎｉｃａｌＳｐｅｃｉｆｉｃａｔｉｏｎＧｒｏｕｐＳｅｒｖｉｃｅｓａｎｄＳｙｓｔｅｍＡｓｐｅｃｔｓ；ＧｅｎｅｒａｌＰａｃｋｅｔＲａｄｉｏＳｅｒｖｉｃｅ（ＧＰＲＳ）；Ｓｅｒｖｉｃｅｄｅｓｃｒｉｐｔｉｏｎ；Ｓｔａｇｅ２（Ｒｅｌｅａｓｅ６）」という名称の３ＧＰＰ技術仕様書の条項９．２．２．２、３ＧＰＰＴＳ２３．０６０Ｖ６．３．０（２００３−１２）、および３ＧＴＳ２９．０６０の以前のバージョンおよびリリースに記載されるとおりであることが可能である。

ＧＰＲＳＰＤＰコンテキスト活動化手続きの一部として、ＳＧＳＮは、ＧＴＰｖ１を使用してＰＤＰ作成要求（機能２２０）をＧＧＳＮに送信することにより、ＰＤＰコンテキストをセットアップしようと試みる。これは、予約されたＵＤＰポート２１２３上で行われる。ＰＤＰコンテキスト作成要求メッセージを送信した後、ＳＧＳＮは、ＰＤＰコンテキストに「応答待ち」とマークを付ける。この状態では、ＳＧＳＮは、ＧＧＳＮからＧ−ＰＤＵを受け入れるが、それらのＧ−ＰＤＵをＭＳに送信することはしない。有効な要求は、ＳＧＳＮにおけるＰＤＰコンテキストとＧＧＳＮにおけるＰＤＰコンテキストの間でトンネルの作成を開始する。

このシナリオでは、ＧＧＳＮは、ＧＴＰｖ０だけをサポートし、したがって、ポート２１２３上ではリッスンしておらず、ＧＴＰｖ０用のポート、ポート３３８６上でリッスンしている。標準において現在、指定されているとおり、手続きが正常に完了しなかった場合（このケースでは、正常に完了しない）、ＳＧＳＮは、ＩＰアドレスのリストの中に次のＧＧＳＮアドレスが存在する場合、そのアドレスに対してＰＤＰコンテキスト作成要求を繰り返すことをつづける。

しかし、本発明の典型的な実施形態によれば、図２で、ＧＧＳＮは、ＧＴＰｖ０ノードが、ＧＴＰｖ１対応ノードによって使用されるポートであるポート２１２３上でリッスンしていないという積極的なインジケータ・メッセージを戻す。この積極的なインジケータは、例えば、ＳＧＳＮに送信される「ＩＣＭＰ宛先到達不能−ポート到達不能」メッセージ（機能２３０）として実現されることが可能である。これは、ＲＦＣ７９２−ＩｎｔｅｒｎｅｔＣｏｎｔｒｏｌＭｅｓｓａｇｅＰｒｏｔｏｃｏｌ（ＩＣＭＰ）で指定された標準の挙動である。

一般に、ＧＧＳＮのようなゲートウェイまたは宛先ホストは、送信元ホスト（ＳＳＧＮ）と通信して、例えば、処理における誤りを報告することができる。ＩＣＭＰが、この目的で使用されることが可能である。「ＩＣＭＰ宛先到達不能−ポート到達不能」メッセージは、何らかの誤りが存在することを送信元ホスト（ＳＳＧＮ）に知らせる。この例では、ＳＧＳＮは、ＩＣＭＰメッセージを受信し、解釈する準備ができており、したがって、ＳＳＧＮは、ＧＴＰｖ１予約ポート２１２３上でアプリケーションが全く実行されていないことを検出する。これが、ＧＴＰｖ１がサポートされていないという明示的な指示として解釈されることが可能である。したがって、ＳＳＧＮは、ポート３３６８上でＧＴＰｖ０を使用して、ＧＧＳＮに対するＰＤＰ作成要求を即時に開始することができる（機能２４０）。

ＧＧＳＮは、ポート３３８６上でＰＤＰ作成要求を受信し、ＧＴＰｖ０に基づいてセットアップされたＰＤＰコンテキストを受け入れることにより、その要求に即時に応答する（機能２５０）。ＰＤＰコンテキスト活動化が、ＭＳに対して確認される（機能２６０）。図２では、これが、ＳＧＳＮからＭＳへの「ＰＤＰコンテキスト活動化承認」メッセージで示されている。以上のメッセージの機能の詳細な説明は、本発明の対象ではないが、例えば、３ＧＰＰＴＳ２３．０６０Ｖ６．３．０（２００３−１２）のセクション９．２に記載されるとおり実施することができる。

以上に説明した方法は、ネットワークが開始した通信に適用できることが可能であり、例えば、「ネットワークが開始したＰＤＰコンテキスト活動化」が存在するケースで、ＧＧＳＮが、ＳＧＳＮに向かって手続きを開始する。いずれのＳＧＳＮにＭＳが接続されているかをＧＧＳＮが知る（ＨＬＲから）ようなケースでは、ＧＧＳＮは、ＰＤＵ通知メッセージなどの適切なメッセージを送信する。ＧＧＳＮとＳＧＳＮが異なるプロトコル・バージョンをサポートしている（すなわち、ＳＧＳＮがＧＴＰｖ０だけをサポートしている）場合、図２に示したのと同一の状況が生じる。したがって、この状況には、図２に概要を示した機能に関して説明したとおりに対処することができる。

同様に、２つのＳＧＳＮの間のノード対ノードの通信において、例えば、ＧＴＰｖ１を使用するＳＧＳＮが、ＧＴＰｖ０だけをサポートするＳＧＳＮにＳＧＳＮコンテキスト要求を送信した場合に、プロトコル・バージョン間の同じ不適合が生じる可能性があるケースが存在する。したがって、本明細書で説明する方法は、互いに通信しようと試みる２つのＳＧＳＮが異なるプロトコルをサポートするケースにも対処できることを理解されたい。

したがって、典型的な実施形態は、業界が直面しているいくつかの問題を解決することができる方法を説明している。「ＩＣＭＰ宛先到達不能−ポート到達不能」などのインジケータまたは誤りメッセージを使用して、ＧＴＰｖ１サポートの欠如を検出することは、これまで、研究されてこなかったものと考えられる。ＧＰＲＳサポート・ノード間の通信に基づくＧＴＰｖ１サポートの欠如の迅速な検出、およびＧＴＰｖ０へのフォールバックは、ＰＤＰコンテキスト・セットアップにおける長い遅延を回避するのに役立つ可能性がある。これにより、ユーザ体験が向上する可能性がある。ＰＤＰコンテキスト・セットアップ待ち時間の短縮は、潜在的に極めて大幅（数桁など）である可能性がある。

以上、本発明の典型的な実施形態を説明したが、実施形態は、多くの仕方で変更することができることが明白であろう。そのような変形形態は、本発明の典型的な実施形態の趣旨および範囲からの逸脱と見なされるべきではなく、当業者に明白であるようなすべてのそのような変更形態が、以下の特許請求の範囲に含まれるものとする。

本発明の典型的な実施形態によるＵＭＴＳアーキテクチャを示す高レベルの図である。本発明の典型的な実施形態による方法を示す信号フローの図である。

Claims

宛先ノードが所与のプロトコル・バージョンをサポートしているかどうかを無線ネットワークの送信元ノードが検出して、前記送信元ノードと前記宛先ノードを介して前記無線ネットワークのユーザと外部ネットワークの間で通信を確立するようにする方法であって、
前記宛先ノードによってサポートされていない第１のプロトコル・バージョンに基づき、前記送信元ノードから前記宛先ノードに要求メッセージを送信するステップと、
前記送信元ノードにおいて、前記要求に対する応答として指示メッセージを受信するステップ及び、
前記指示メッセージに基づき、前記宛先ノードが前記第１のプロトコル・バージョンをサポートしていないことを検出するステップからなる方法。
請求項１記載の方法において、前記指示メッセージが、前記要求メッセージを送信するために使用される前記第１のプロトコル・バージョンとは無関係のプロトコルに属する方法。
請求項１記載の方法であって、さらに、
前記要求メッセージを前記送信元ノードから前記宛先ノードに、前記宛先ノードによってサポートされている第２のプロトコル・バージョンとして再送信して、前記ユーザと前記ネットワークの間における通信の前記セットアップを円滑にするようにするステップからなる方法。
請求項３記載の方法において、前記第１のプロトコル・バージョンが、第３世代無線通信システムにおいて汎用パケット無線サービス（ＧＰＲＳ）をサポートするためのＧＰＲＳトンネリング・プロトコル、バージョン１（ＧＴＰｖ１）であり、前記第２のプロトコル・バージョンが、グローバル・システム・フォー・モバイル・コミュニケーションズ（ＧＳＭ）システムにおいてＧＰＲＳをサポートするための（ＧＴＰｖ０）である方法。
請求項１記載の方法において、前記指示メッセージが、インターネット制御メッセージ・プロトコル（ＩＣＭＰ）「宛先到達不能−ポート到達不能」メッセージである方法。
請求項５記載の方法において前記検出するステップが、前記ＩＣＭＰメッセージの受信に基づき、前記第１のプロトコル・バージョンが前記宛先ノードにおいてサポートされていないと判定するステップを含む方法。
請求項１記載の方法において、前記無線ネットワークが、少なくとも汎用パケット無線サービス（ＧＰＲＳ）サービスをサポートするように構成されたコア・ネットワークを含む方法。
請求項１記載の方法において、前記送信元ノードと前記宛先ノードが、異なるプロトコル・バージョンをサポートするＳＧＳＮである方法。
請求項１記載の方法において、前記送信元ノードが、ＳＧＳＮまたはＧＧＳＮのどちらかであり、前記宛先ノードが、ＧＧＳＮまたはＳＧＳＮのどちらかである方法。
請求項１記載の方法であって、さらに
前記宛先ノードによってサポートされている第２のプロトコル・バージョンで、前記送信元ノードから前記宛先ノードに前記要求メッセージを再送信するステップと、及び
前記送信元ノードに承認メッセージで応答して、前記ユーザの存在が前記外部ネットワークに知られるようにするステップからなる方法。