JP5209640B2 - 移動体ネットワークにおけるサービス品質の向上 - Google Patents

Description

本発明は、一般的に、通信システムに関し、特に、通信システムに関連するローミングをするアプリケーションにおけるサービス品質（ＱｏＳ：Quality of Service）を向上させるための方法及びシステムに関する。

携帯電話技術は、その始期において、音声通信のために設計され使用されるのみであった。消費者向けの電子機器産業が成熟を続け、プロセッサの機能が高まるにつれ、より多くのデバイスが公衆の用に供されるようになった。そして、それによりデバイス間でのデータ転送が可能となり、その転送されたデータに基づいて動作するより多くのアプリケーションが利用可能となった。特に注目すべきは、インターネット及びローカルエリアネットワーク（ＬＡＮ）である。これら２つの技術革新は、複数のユーザ及び複数のデバイスが、様々なデバイス及びデバイスの種類の間において通信及びデータ交換をすることを可能にした。そして、これらデバイス及び機能の出現により、（ビジネスの及び家庭の）ユーザは、移動可能な場所からデータ及び音声を送信することの必要性を見出した。

これは、コストの低さとより広いカバレージに加えて、次世代の携帯型デバイスがデータを送受信する能力を有することを後押しした。例えば、携帯電話技術の第２世代の実装の１つは、ＧＳＭ（Global System for Mobile communications）であった。ＧＳＭは、もともとはデジタル音声技術であった。そして、そのシステムに対して、第２．５世代とも呼ばれるデータ送受信のための能力が移植された。かかる能力とは、ＧＳＭシステムと組み合わせてＧＰＲＳ（General Packet Radio Services）を使用することを通してのものである。ＧＰＲＳは、ＧＳＭシステムを用いる携帯電話がＩＰ（Internet Protocol）パケットを送信することを可能にする。また、ＧＳＭシステムの一部を継承する第３世代システムは、ＵＴＭＳ（Universal Mobile Telecommunications System）と呼ばれる。ＵＭＴＳは、ＧＳＭ／ＧＰＲＳよりも高いデータ送信レートを有し、例えば携帯型ビデオ会議など、携帯ユーザにとっての新規かつ改善された選択肢の実現を可能とする。

また、その他の特徴の中でも、ＵＭＴＳネットワークは、ユーザが通常の地理的領域の外部にいる間にもユーザに改善されたサービスを提供する。ユーザがホームネットワークの外部にいる間にサービスへアクセスするための能力は、典型的には、ローミングとして知られている。ユーザがローミングしている間にデータサービスにアクセスためには、ユーザのシグナリングは、まずユーザのホームネットワーク内に位置するゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ：Gateway GPRS Support Node）ルータに転送され、それによりユーザは自身が登録した特定のサービスにアクセスすることができる。そして、ユーザのシグナリングは、所望の宛て先へ転送される。ルーティング及び携帯ユーザのための転送を管理するＧＧＳＮルータは、ユーザの携帯機器により、アクセスポイント名（ＡＰＮ：Access Point Name）を用いて特定される。

ＡＰＮは、ユーザの携帯機器から送信されるパケットデータプロトコル（ＰＤＰ：Packet Data Protocol）のコンテキストの活性化（activate）を要求するメッセージの一部となる。このメッセージは、サービス提供ＧＰＲＳサポートノード（ＳＧＳＮ：Serving GPRS Support Node）へと送信される。ＡＰＮは、ＧＰＲＳのためのアクセスポイントの名前を有し、典型的には、携帯機器が接続可能なＩＰネットワークを含む。ＡＰＮが充足する２つの主要な機能は、次の通りである：即ち、（１）ＡＰＮは、携帯ユーザにより通信の到達（reach）が望まれるパケットデータネットワーク（ＰＤＮ）を曖昧でないように示す。（２）ＡＰＮは、携帯ユーザがアクセスすることを望むサービスを特定する。ＰＤＮとは、データサービスを提供するネットワークであって、例えばインターネットなどである。各一般陸上移動体ネットワーク（ＰＬＭＮ：Public Land Mobile Network）は、１つ以上のＧＧＳＮを通して、複数のＰＤＮに接続され得る。ＡＰＮによれば、特定のＰＬＭＮ内のＰＤＮへのアクセスポイントは、所与のＧＧＳＮのためのネーミングシステムであるドメインネームシステム（ＤＮＳ）に準拠した名前を用いて特定され得る。

より具体的には、ＡＰＮは、１００以下のオクテットにより構成され（１オクテットは８ビット即ちバイトに等しい）、２つの部分からなる。ＡＰＮのその２つの部分とは、必須のネットワーク識別子と、任意のＡＰＮ運用者（operator）識別子である。ＡＰＮネットワーク識別子は、ＧＧＳＮが接続される外部ネットワーク、及び任意に携帯端末により要求されるサービスを表現する。ＡＰＮネットワーク識別子は、最大で６３バイト（又は６３アスキー文字）の長さを有する。さらに、ＰＬＭＮ内でのネットワーク識別子の一意性を担保するために、全てのネットワーク識別子は、ＰＬＭＮにより割当てられるインターネットドメイン名に相当する１つ以上のラベルであって、そのラベルを予約した組織を特定することを目的とするラベルを含む。

各運用者は、３つのフィールドよりなるデフォルトＡＰＮ運用者識別子を有する。第１及び第２のフィールドは、合わせてＰＬＭＮネットワークを一意に表現する。第３のフィールドは、“gprs”でなければならない。より具体的には、第１のフィールドは、３つの数字を含み、携帯国コード（ＭＣＣ：Mobile Country Code）を表す。第２のフィールドは、やはり３つの数字を含み、携帯ネットワークコード（ＭＮＣ：Mobile Network Code）と呼ばれ、携帯によるホームＰＬＭＮネットワークを特定する。従って、ＡＰＮ運用者識別子の標準的なフォーマットの一例は、ＭＣＣ＝３４５、ＭＮＣ＝１２とすると、“mcc.345.mncO12.gprs”である。この一例としてのＡＰＮ運用者識別子は、ＰＬＭＮ間のローミング中に使用され、その際ホームＰＬＭＮからのＧＧＳＮのＩＰ（Internet Protocol）アドレスへのＡＰＮの変換が行われる。

それに加えて、ＡＰＮは通常は地理的条件に依存しており、それにより、ＡＰＮは、携帯ユーザがローミングしているネットワーク内ではなく、多くの場合ホームネットワーク内に位置するＧＧＳＮを参照する。この地理的条件の基準は、その伝播距離による遅延を引き起こし得る。例えば、携帯ユーザが米国内を基準とする自身のローカルサービスを有しており、スウェーデンを旅行していると仮定する。そして、携帯ユーザが国内電話をかけると、ユーザの携帯ユニットが米国をローカルとしているために、その呼（call）は、スウェーデン国内の番号へ転送される前にまず米国内のホーム基地（ＧＧＳＮ）にルーティングされる。この遅延は、例えば、送信されるデータの種類／サイズに依存して増加する。それに加えて、ユーザのホームアドレス／送信元アドレスがローミングアドレスとは異なるために、セキュリティ機能によりパケットが破棄され得るというような問題にも遭遇し得る。より多くのユーザが移動体ネットワークのメンバーとなり、そのユーザのうちの何人かはホームアドレスからより遠く離れて移動をするため、ユーザのサービス品質（ＱｏＳ）に与える（否定的な）影響は増加していくことが予想される。

従って、本発明は、移動体ネットワークにおけるＱｏＳを向上させる必要性を解決するものである。

一例としての実施形態によれば、通信ノードは、データサービスを要求するメッセージを受信するプロセッサ、を備え、上記メッセージは、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）に上記データサービスをサポートさせるか否かを上記通信ノードが判定するために使用されるサービス識別番号を含む。

他の一例としての実施形態によれば、通信方法は、データサービスを要求するメッセージを受信するステップ、を含み、上記メッセージは、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）に上記データサービスをサポートさせるか否かを通信ノードが判定するために使用されるサービス識別番号を含む。

さらなる一例としての実施形態によれば、携帯機器は、データサービスを要求するメッセージを送信する送受信部、を備え、上記メッセージは、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）に上記データサービスをサポートさせるか否かを判定するために使用されることができるサービス識別番号を含む

さらに別の一例としての実施形態によれば、通信方法は、データサービスを要求するメッセージを送信するステップ、を含み、上記メッセージは、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）に上記データサービスをサポートさせるか否かを判定するために使用されることができるサービス識別番号を含む。

また別の一例としての実施形態では、通信ノードは、ルータ通知（ＲＡ）メッセージを受信し、及びデータサービスの要求をローカルでサポートするＧＧＳＮの割当てに使用されるゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）リストを更新するためのプロセッサ、を備え、上記プロセッサは、上記要求がローカルでサポートされ得ない場合には、ホームＧＧＳＮのＩＰアドレス発見の仕組みを起動する。

他の一例としての実施形態によれば、通信方法は、ルータ通知（ＲＡ）メッセージを受信するステップと、上記ＲＡメッセージを用いて、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）リストを更新するステップと、データサービスの要求をローカルでサポートするＧＧＳＮを割当てるステップと、上記要求がローカルでサポートされ得ない場合に、ホームＧＧＳＮのＩＰアドレス発見の仕組みを起動するステップと、を含む。

次の添付図面は、本発明の一例としての実施形態を説明するためのものである。

２つのＰＬＭＮを含む一例としてのＵＭＴＳ（Universal Mobile Telecommunications System）を示している。 図１ａのシステムの一部をより詳細に示している。 図１ａのシステム内で動作し得る一例としてのユーザ機器（例えば携帯デバイス）を示している。 図１ａのシステム内で動作し得る一例としての通信ノード（例えばＧＧＳＮ／ＳＧＳＮ）を示している。 一実施形態に係る移動体通信のローミングを含む第１のシナリオを示している。 一実施形態に係るＧＧＳＮリストを構築するための方法を描いたフローチャートである。 一実施形態に係るＧＧＳＮ選択の仕組みを描いたフローチャートである。 一実施形態に係る移動体通信のローミングを含む第２のシナリオを示している。 一実施形態に係る移動体通信のローミングを含む第３のシナリオを示している。 ＰＤＰコンテキスト要求メッセージを生成するか活性化されたＰＤＰコンテキスト要求メッセージを拒絶するかを判定する一実施形態に係る方法を示すフローチャートである。

これ以降に一実施形態についての詳細な説明を添付図面を参照しながら行う。異なる図面についての同一の符号は、同一の又は同様の要素を特定するものである。また、これ以降の詳細な説明は、本発明を限定するものではない。その代わりに、本発明の範囲は、添付された特許請求の範囲により定義される。

この議論のいくつかの前後関係を提供するために、本発明が実装され得る一例としての統合移動体システムについて、まず図１ａ〜１ｄに関連して説明する。しかしながら、当業者であれば、本発明はこのような種類の移動体システムでの実装に限定されるものではなく、及びより多くの又はより少ない構成要素がそこに含まれてもよいことを理解するであろう。

本実施形態において、図１ａに示したＵＭＴＳ（Universal Mobile Telecommunications System）ネットワークは、それぞれ多くの異なるＵＭＴＳ管理ドメイン１１６を有する２つの一般陸上移動体ネットワーク（ＰＬＭＮ）Ａ及びＢを含む。管理ドメイン１１６は、さらに、図１ｂに示したように、複数のＵＭＴＳ無線アクセスネットワーク（ＵＴＲＡＮ）１１２及びコアネットワーク（ＣＮ）１１４の２つのセグメントに分解することができる。ＵＴＲＡＮ１１２は、ノードＢ１０４と通信するユーザ機器（ＵＥ：User Equipment）１０２を含む。ユーザ機器１０２は、例えば、ＵＭＴＳ標準により規定された空中インタフェースを介して、無線ネットワークコントローラ（ＲＮＣ）１０６と通信する。ＣＮ１１４は、（そのＣＮ内の）ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１１０及びＲＮＣ１０６の双方と通信するＳＧＳＮ１０８から構成される。さらに、図示されていないが、図１ｂに示されたリンクは、一方向又は双方向の通信を表す。

図１ｃは、本実施形態が実装され得る一例としてのＵＥを示している。ここでは、ＵＥ１０２は、送受信部１２２と接続されたプロセッサ１２０を含む。送受信部１２２は、順に、空中インタフェースとアンテナ１２４を介して接続される。典型的には、ＵＥ１０２が例えばディスプレイ及びメモリデバイスなどの他の要素を含んでもよいことは理解されるであろう。同様に、例えばＧＧＳＮ及びＳＧＳＮなどの通信ノードは、図１ｄに示したようなプロセッサ１３０及びメモリデバイス１３２を、後述する様々な機能を実行するために含んでもよい。

本発明の一実施形態によれば、ＵＭＴＳシステムにおけるＱｏＳを向上させるために、背景において説明したアクセスポイント名（ＡＰＮ）は、サービス識別番号（サービスＩＤ）に置き換えられる。このサービスＩＤは、後述する他の特徴と共に、ＡＰＮの機能を充足する。より具体的には、サービスＩＤは、携帯ユーザにより通信の到達が望まれるパケットデータネットワーク（ＰＤＮ）を指し示すための仕組みであって、ユーザが使用を望むサービスのクラスを代替的に特定する。

本実施形態によれば、サービスＩＤは、数字であって、表１に示したような５バイトを用いたフォーマットを有する。

表１のサービスＩＤの一例としての数字は、２つの部分あるいはフィールドにおいて説明され得る。第１の部分はファンクションフィールドであり、第２の部分は、自律システム番号（ＡＳＮ：Autonomous System Number）あるいはサービスクラスフィールドである。この例では、第１のバイトは、特定のインスタンスにおけるサービスＩＤを記述するためのものであり、例えば所望のＰＤＮの識別又は所望のサービスの特定など、機能を区別するために使用されるファンクションフィールドを構成する。即ち、例えば、本実施形態によれば、ファンクションフィールドは、次の値のうちの１つをとることができる：
・０（ObOOOOOOOO）：この値は、サービスＩＤのワイルドカードに相当する。
・１（ObOOOOOOOOl）：この値は、サービスＩＤがＰＤＮを指すことを表す。
・３（ObOOOOOOOl1）：この値は、サービスＩＤがサービスを指すことを表す。

本実施形態にとっては、これらのみが、ファンクションフィールドがとり得る値である。従って、本実施形態については、ファンクションフィールドがこれら定義以外の値を含む場合には、サービスＩＤは無効又はエラーであると見なされるであろう。しかしながら、将来において、他の選択肢が利用可能となり、これらフィールドの値が望まれるように修正され得ることは理解されるであろう。他の実施形態によれば、当該ファンクションフィールドは、より多くの又はより少ない数の値を有してもよい。

次に、サービスＩＤの第２のフィールド（ＡＳＮあるいはサービスクラス）に移り、ファンクションフィールドが値０を有する場合には、後半の４バイトにより表される数は、ゼロとなる。また、ファンクションフィールドが値１を含む場合には、データサービスを提供するネットワークである所望のＰＤＮを指し示す。従って、ファンクションフィールドの値１を伴うサービスＩＤは、ＰＬＭＮに独立的なＰＤＮへのアクセスポイントを記述する。より具体的には、ファンクションフィールドが値１を有している場合、サービスＩＤの後半の４バイトは、所与のＰＤＮを指し示す３２ビットのＡＳＮを表す。ＡＳＮとは、各自律システム（ＡＳ）を一意に特定できるようにするための数である。ＡＳとは、１つだけのルーティングポリシーを共有する１つ以上の運用者により管理されるＩＰネットワークの集合である。ＡＳＮは、ＩＡＮＡ（Internet Assigned Number Authority）により割当てられる。

また、サービスＩＤのファンクションフィールドが値３を有する場合、サービスＩＤの第２のフィールドは、多数の異なるサービスクラスの１つを記述するために使用される。これらサービスクラスは、例えば、潜在的なトラフィックの遅延に対する感度に基づく４つのＱｏＳクラスに分類され得る。本実施形態によれば、サービスＩＤがサービスを指し示す場合、サービスＩＤのその後半の４バイトは、次の４つのＵＭＴＳサービスクラスに正確に対応する：
・1.0.0.0（ObOOOOOOOl.00000000.00000000.00000000）:この値は、“対話型（conversational）”クラスに相当する。
・3.0.0.0（ObOOOOOOl1.00000000.00000000.00000000）：この値は、“ストリーミング”クラスに相当する。
・7.0.0.0（ObOOOOOl11.00000000.00000000.00000000）：この値は、“双方向型（interactive）”クラスに相当する。
・15.0.0.0（ObOOOOl111.00000000.00000000.00000000）：この値は、“バックグラウンド”クラスに相当する。

本発明の一実施形態により、例えばネットワーク内及びユーザ機器内の双方において上述したサービスＩＤがどのように使用されるかをよりよく理解するために、次の詳細な例は、ローミングするユーザがサービスＩＤを用いてネットワークにアクセスするいくつかの使用場面を示している。より具体的には、これら実施形態に従ってサービスＩＤを用いて移動体ネットワークにアクセスするための、本発明に係る３つのシナリオの例が以下に説明される。これら３つのシナリオは、一般的には、次のように説明される：即ち、（１）ローミングするユーザによる通信が、訪問先のＧＧＳＮにより管理される場合、（２）ローミングするユーザによる通信が、例えば訪問先のＧＧＳＮからの許可を得られないことからホームＧＧＳＮにより管理される場合、（３）ローミングするユーザによる通信が、訪問先ネットワークが要求を扱うことが不能であるために、ホームＧＧＳＮにより管理される場合、である。

第１のシナリオでは、ローミングするユーザの通信は、訪問先のＧＧＳＮ（ＶＧＧＳＮ：Visited GGSN）により管理される。その際、ユーザは、図２に示したように訪問先のＰＬＭＮ（ＶＰＬＭＮ：Visited PLMN）にいる。本シナリオにおいて、携帯ユーザは、訪問先のＰＬＭＮのサービスの使用（即ち、許可されたＶＰＬＭＮアドレスを有する）、及び当該ＶＰＬＭＮアクセスポイントへのアクセスの双方の権限を有する。予備的なステップ２０２は、各ＳＧＳＮ１０８の内部での（サービスＩＤによりインデックス付けされる）ＧＧＳＮリストの構築を含む。この構築ステップ２０２は、定期的に実行されることができ、図２の残りの部分に示したＰＤＰコンテキストの活性化の手続からは独立している。より具体的には、ＧＧＳＮリスト構築ステップ２０２は、各ＳＧＳＮ１０８の内部におけるデータ構造であって、要求されたサービスを提供するためにどのＧＧＳＮを割当てるべきかの決定に用いることのできる当該データ構造を提供する。本発明の一実施形態に係る一例としてのＧＧＳＮリストの構築方法は、図３のフローチャートに描かれている。

そこでは、ステップ３００において、特定のＰＬＭＮ内の各ＧＧＳＮ１１０は、同じＰＬＭＮ内の様々なＳＧＳＮ１０８に対し、本明細書でルータ通知（ＲＡ：Router Advertisement）メッセージとして言及されるメッセージを定期的にブロードキャストする。このルータ通知メッセージは、ＳＧＳＮ１０８に、利用可能なＧＧＳＮ１１０及び各ＧＧＳＮ１１０がユーザに提供可能なサービスの識別情報を通知する。一実施形態によれば、ルータ通知メッセージは、モバイルＩＰバージョン６（ＭＩＰｖ６）において記述された近傍発見手続と同様の手法で実装されてもよい。かかるＭＩＰｖ６は、例えば１９９８年の標準ドキュメントＲＰＣ２４６１“Neighbor Discovery for IPv6”において説明されており、その開示内容は参照によりここに取り入れられる。ＳＧＳＮ１０８がルータ通知メッセージを受信すると、ＳＧＳＮ１０８は、それを用いて、特に各ＧＧＳＮのＩＰアドレス及びサービスを含むように、ローカルに保存しているＧＧＳＮリストを更新する。これは、ステップ３１０においてサポートされる。

図３に示したＧＧＳＮリスト構築の仕組みに関連する機能をサポートするために、参照により取り入れられたドキュメントにおいて記述されたルータ通知手続には、いくつかの修正が加えられ得る。例えば、ＭＩＰｖ６のＲＡメッセージのフォーマットは、例えば、“Ｇ”及び“Ｈ”フラグという２つの新たなフラグを加えられるように修正されてもよい。フラグＧは、特定のルータ通知メッセージに関連付けられた送信エンティティがＧＧＳＮとして振舞うことができることを表している。一方、フラグＨは、メッセージを送信するルータが所与のリンク上のホームエージェントとして使用されることを表している。本実施形態に係る修正されたＲＡメッセージのフォーマットは、表２により表される。

追加的に、上の表２のＲＡメッセージにおいて示されたオプションフィールドは、ＧＧＳＮリストを構築する目的で当該メッセージをブロードキャストするＧＧＳＮについての関連する情報、例えば、特定のルータ機能についての特定の情報を運ぶような手法で定義されてもよい。このオプションのフォーマットは、表３に示されている。

次に、表３に示したような本実施形態に係るＧＧＳＮ情報のオプションフォーマットにおいて使用される特有のフィールドについて説明する。ここで、タイプフィールドは、上記参照により取り入れられたドキュメントにおいて説明されている近傍発見（Neighbor Discovery）のオプションである。長さフィールドは、例えば当該オプションの長さを示す８ビットの符号なし整数を含む。ＧＧＳＮプリファレンスフィールドは、例えばＧＧＳＮのプリファレンスを示す１６ビットの符号なし整数を含む。この後者のフィールドは、その値が高ければ高い可用性を示し、受信側のＳＧＳＮにより図３において生成されたＧＧＳＮリストを順序付けるために使用され得る。例えば、ＳＧＳＮは、特定のサービスクラスを提供可能なＧＧＳＮ又はＡＳＮを、可用性が高い順にランク付けしてもよい。このオプションがフラグＧを有するＲＡに含まれていない場合には、ＧＧＳＮプリファレンスフィールドの値はゼロに設定される。ＲＡを送信するＧＧＳＮは、例えば、現在サービスを受けている携帯ユーザ数又は他の携帯ユーザへのサービスに依然として利用可能なリソースの量などに応じて、ＧＧＳＮプリファレンスフィールドの値を動的に決定してもよい。

ＧＧＳＮライフタイムフィールドは、例えばＧＧＳＮのライフタイムを秒数で示す１６ビットの符号なし整数を含む。初期設定では、このフィールドは、ＲＡメッセージの主要部において特定されるようなルータのライフタイムの値をとる。ゼロの値は、好ましくない。ＧＧＳＮライフタイムフィールドは、本実施形態によれば、ＧＧＳＮとしてのルータの機能のみに適用され、他のフィールド又はＲＡメッセージのオプション内の情報には適用されない。サービスＩＤフィールドは、当該ＲＡメッセージを送信するＧＧＳＮが提供可能なサービスクラスあるいはＡＳＮに関連するサービスＩＤのリストである。複数のサービスＩＤは、ＲＡのオプション部のサービスＩＤフィールド内に隣り合うように配置され、例えば５バイトごとなどの既知の長さに基づいて受信側のＳＧＳＮによりパースされ得る。

ここまで、ステップ２０２として実行され得る一例としてのＧＧＳＮリスト構築方法を説明したが、次に、図２のシナリオに戻り、ステップ２０４において、携帯ユーザは、（上述したサービスＩＤを含む）ＰＤＰコンテキスト活性化要求メッセージを、携帯ユニットが現在位置しているＰＬＭＮのＳＧＳＮ１０８へ送信する。携帯ユーザはローミングをしているため、そのＰＤＰコンテキスト活性化要求メッセージをステップ２０４において処理するのは、訪問先ネットワーク（ＶＳＧＳＮ）のＳＧＳＮである。ＰＤＰコンテキスト活性化要求メッセージを受信した後、ＶＳＧＳＮは、ユーザの登録レコードをチェックしてその要求の妥当性を確認する。そして、一度携帯ユーザの要求の妥当性が確認されると、ＶＳＧＳＮは、それぞれステップ２０６及び２０８において、ＧＧＳＮ選択の仕組みを適用し、及びＧＧＳＮリストを検索することにより、データサービスについてのその特定の要求にどのＧＧＳＮを割当てるかを決定する。一例としてのＧＧＳＮ選択の仕組みは、図４のフローチャートにおいて描かれている。

ステップ４００では、その特定のＧＧＳＮの選択を処理するように動作可能なＧＧＳＮ選択モードが決定される。これら実施形態の固有の実装に依存して、様々なＧＧＳＮ選択モードが提供されてもよい。一実施形態によれば、ステップ４００において選択され得る３つのＧＧＳＮ選択モードが存在する：即ち、（１）サービスＩＤがＰＤＰコンテキスト活性化要求メッセージにおけるサービスＩＤである場合の、ＭＮによる選択（移動体ネットワーク（ＭＮ：Mobile Network）又はユーザ機器による選択）、（２）サービスＩＤが既知のＰＤＰの種類に関連する初期値としてのサービスＩＤである場合の、ＳＧＳＮによる選択、（３）サービスＩＤがＰＤＰコンテキストから抽出される場合の、登録（Subscribed）、である。特定のモードは、ＰＤＰコンテキスト活性化要求メッセージ内のパラメータ及び／又は当該要求メッセージを送信した携帯ユーザに関連付けられたホームロケーションレジスタ（ＨＬＲ）内のレコードに基づいて、ネットワークにより選択される。いずれにしろ、ステップ４００のＧＧＳＮ選択の仕組みは、サービスＩＤの選択の手法（即ち、携帯ユーザからの送信又は他の手法）であって、特定のＧＧＳＮを選択して要求されたサービスを提供するために使用される。

次に、ステップ４１０において、どのＰＬＭＮ、即ち訪問先のＰＬＭＮ又はホームＰＬＭＮがサービスＩＤにより特定されたデータサービスを提供するかが決定される。図２の一例としてのシナリオでは、携帯ユーザが訪問先のＰＬＭＮのサービスを使用する権限を有する（即ち、許可されたＶＰＬＭＮアドレスを有する）ことから、上記決定は訪問先のＰＬＭＮであるとなされる。より詳細には、ステップ４１０を実装する一例としての方法は、図７に関連して後に説明される。そして、ステップ４２０において、サービスＩＤによりインデックス付けされたＧＧＳＮリスト内で検索が実行され、サービスを提供するための特定のＧＧＳＮ（図２の例におけるＶＧＧＳＮ）が選択される。ここで適切なＧＧＳＮを検索の結果として特定できない場合には、ＰＤＰコンテキスト活性化要求は拒絶される。

図２に戻り、一度ＶＧＧＳＮが選択されると、ステップ２１０において、ＶＳＧＳＮは、ステップ２０８において取得されたＩＰアドレスを有する当該ＶＧＧＳＮに、ＰＤＰコンテキスト生成要求メッセージを送信する。そうすると、ＶＧＧＳＮは、そのＰＤＰコンテキストのテーブル内に新たなエントリを生成し、ＨＳＧＳＮとネットワークＰＤＮとの間でユーザのパケットをルーティングすることを可能にする。ステップ２１２では、ＶＧＧＳＮは、ＶＳＧＳＮにＰＤＰコンテキスト生成応答メッセージを返送する。ここで、ＶＧＧＳＮがＰＤＰアドレスの許可についての責任を有していれば、当該アドレスがそのＰＤＰコンテキスト生成応答メッセージに含められる。そうでなければ、対応するフィールドは、本手続の後に携帯ユーザがＰＤＰアドレスについて外部のＰＤＮと交渉する必要があることを示す０．０．０．０に設定される。

次に、ステップ２１４において、無線アクセスベアラのセットアップ（Radio Access Bearer Setup）手続が開始される。ステップ２１４は、ＱｏＳの修正を含んでもよい。ステップ２１４においてＱｏＳパラメータが修正された場合には、ＶＳＧＳＮ及びＶＧＧＳＮは、ＰＤＰコンテキスト内のＱｏＳパラメータを修正するために、ステップ２１６及び２１８において、それぞれＰＤＰコンテキスト更新要求メッセージ及びＰＤＰコンテキスト更新応答メッセージを交換する。そして、ＶＳＧＳＮは、ステップ２２０において、ＰＤＰコンテキスト活性化容認（accept）メッセージをＭＮ（又はユーザ機器）へ送信し、手続を終了する。

図５は、ユーザが本実施形態に係る訪問先のＰＬＭＮにいる場合において、ローミングするユーザの通信がホームＧＧＳＮにより管理される場合の第２のシナリオを描いている。本シナリオでは、携帯ユーザの通信は、例えば訪問先ネットワークのサービスの使用を拒否されたことなどの理由で、ＨＧＧＳＮにより管理される。上述した一実施形態のように、例えば上述したその手法を用いて、ＧＧＳＮリスト構築ステップ２０２がＳＧＳＮにより定期的に実行される。そして、ステップ５０４において、携帯ユーザは、携帯ユニットが現在位置しているＰＬＭＮのＳＧＳＮへＰＤＰコンテキスト活性化要求メッセージを送信する。ここで、携帯ユーザはローミングしているため、そのＰＤＰコンテキスト活性化要求メッセージを処理するのは、訪問先ネットワーク（ＶＳＧＳＮ）のＳＧＳＮである。

その後、ＶＳＧＳＮは、その要求の妥当性を確認するために、当該ユーザの登録レコードをチェックする。そして、一度携帯ユーザの要求の妥当性が確認されると、ＶＳＧＳＮは、ステップ５０６において、（図４に示された）ＧＧＳＮ選択の仕組みを適用する。但し、上述した実施形態とは異なり、処理が図４のＧＧＳＮ選択の仕組みにおけるステップ４１０に到達すると、関連付けられるＰＬＭＮは訪問先のＰＬＭＮよりもむしろホームＰＬＭＮであると判定される。これは、今回の場合携帯ユーザが訪問先ＰＬＭＮのサービスを使用する権限を持たず（即ち、許可されたＶＰＬＭＮアドレスを有しない）、及び／又はＶＰＬＭＮアクセスポイントへのアクセス手段も持たないためである。

本シナリオにおいて、サービスを提供するローカルＧＧＳＮを使用するための許可がシステムから得られないことから、ＶＳＧＳＮは、その携帯ユーザと関連付けられたホームＧＧＳＮのＩＰアドレスを取得する必要がある。ステップ２０２において構築されたＧＧＳＮリストは、ローカルＧＧＳＮのリスト及びその属性を提供する。しかしながら、他のＰＬＭＮにおいて動作するＧＧＳＮのリストは、ＳＧＳＮにはアクセスできない。それに加えて、ＰＤＰコンテキスト活性化要求において携帯ユーザにより提供されるサービスＩＤはＤＮＳアドレスではなくむしろ番号であるため、サービスＩＤはＨＳＧＳＮへアクセスするための直接的な仕組みを提供しない。従って、本実施形態では、このような状況を処理するための、ホームＧＧＳＮのＩＰアドレスの発見の仕組みを提供する。かかる仕組みは、例えば図５に描かれているような仕組みであり、ホームシステムへの信号の返送が必要となる。上述したような要求に応じてではなく定期的に実行されるＧＧＳＮリスト構築手続と対比すると、このホームＧＧＳＮのＩＰアドレス発見の仕組みは、本実施形態に係る図４のＧＧＳＮ選択の仕組みの一部としてホームＰＬＭＮによるアクセスが選択された場合にのみ介在する。

一実施形態によれば、ホームＧＧＳＮのＩＰアドレス発見手続５０８は、訪問先ＰＬＭＮのＳＧＳＮ（ＶＳＧＳＮ）と携帯ユーザのホームＰＬＭＮのＳＧＳＮ（ＨＳＧＳＮ）との間のメッセージの交換の形で実行される。このアドレス発見の目的でＶＳＧＳＮにより送信されるメッセージ５０８ａは、ＧＧＳＮが提供しなければならないサービスのサービスＩＤを含み、ホームＰＬＭＮの全てのＳＧＳＮの参加を可能とするためのアドレスを宛て先とする。一実施形態によれば、そのメッセージの形式は、上記参照により取り入れられた近傍発見プロトコルにおいて使用されるルータ要請メッセージ（Router Solicitation message）と同様であってもよいが、サービスＩＤの使用についての修正がなされ得る。このメッセージ５０８ａは、ここでは、ＩＣＭＰ（Internet Control Message Protocol）によるホームＧＧＳＮアドレス発見要求という。当該ＩＣＭＰによるホームＧＧＳＮアドレス発見要求のフォーマットは、表４に表されている。

表４において、本実施形態に従い、タイプフィールドの値は、本ＩＣＭＰメッセージを他のＩＣＭＰメッセージから区別するために１５４に設定される。コードフィールドは、ゼロに設定される。チェックサムフィールドは、ＩＣＭＰチェックサムに設定される。識別子フィールドには、ＩＣＭＰによるホームＧＧＳＮアドレス発見要求メッセージを、対応するＩＣＭＰによるホームＧＧＳＮアドレス発見応答メッセージとペアリングすることをシステムにとって可能とする識別子が用いられる。予約フィールドは、将来の使用のために予約されているが、当初はゼロに設定される。サービスＩＤフィールドは、この発見の仕組みによりホームＰＬＭＮ内で特定されるＧＧＳＮにより提供されるべきサービスのサービスＩＤを表示する。

ＩＣＭＰによるホームＧＧＳＮアドレス発見要求メッセージは、ローミングしているユーザのホームＳＧＳＮのユニキャストアドレスへ、訪問先ネットワークのＳＧＳＮから送信される。そのＩＣＭＰによるホームＧＧＳＮアドレス発見要求メッセージを受信するＳＧＳＮは、ステップ５０８ｂにおいて当該メッセージに含まれていたサービスＩＤを用いて、自身のＧＧＳＮリスト内での検索を実行する。そして、そのＳＧＳＮは、ＩＣＭＰによるホームＧＧＳＮアドレス発見応答メッセージ５０８ｃを用いて応答する。検索が成功したと仮定すると、ＩＣＭＰによるホームＧＧＳＮアドレス発見応答メッセージ５０８ｃは、その成功を示すコードに加えて、発見されたＧＧＳＮのＩＰアドレス含む。そうでない場合には、メッセージ５０８ｃは、失敗及び失敗の理由を示すコードを含む。ＩＣＭＰによるホームＧＧＳＮアドレス発見応答メッセージ５０８ｃは、ローミングするユーザのホームネットワークにより、ホームＧＧＳＮのＩＰアドレス発見の仕組みを開始した訪問先ネットワークのＳＧＳＮへ回答をするために使用される。一例としてのメッセージ５０８ｃのフォーマットは、表５に表されている。

表５において、タイプフィールドは、本ＩＣＭＰメッセージを他のＩＣＭＰメッセージから区別するために１５５に設定される。コードフィールドは、ＧＧＳＮリスト内の検索が成功したか否かを示す。本実施形態によれば、０から１２７までの値は成功を示し、その場合には例えば所望のＧＧＳＮのＩＰアドレスがホームＧＧＳＮアドレスフィールドに含まれている。一方、検索に失敗した場合には、当該コードの値は、ホームＧＧＳＮアドレスフィールドにエラーがあったことを示す１２８から２５５までの値となる。チェックサムフィールドは、ＩＣＭＰチェックサムを示す。識別子フィールドには、ＩＣＭＰによるホームＧＧＳＮアドレス発見要求メッセージに由来する識別子が含まれ、それにより受信者は当該応答をメッセージ５０８ａにおける前の要求と関連付けることができる。予約フィールドは、将来の使用のために予約されているが、当初はゼロに設定される。ホームＧＧＳＮアドレスフィールドは、ＧＧＳＮリストの検索により見つけ出されたＧＧＳＮのＩＰアドレス、又は検索失敗となったエラーの原因を含む。

ＩＣＭＰによるホームＧＧＳＮアドレス発見応答メッセージ５０８ｃがＨＧＧＳＮのＩＰアドレスを含んでいる場合には処理は継続し、そうでなければＰＤＰコンテキスト活性化手続は終了する。ステップ５１０において、ＶＳＧＳＮは、ステップ５０８で取得されたＩＰアドレスを有するＨＧＧＳＮへ、ＰＤＰコンテキスト生成要求メッセージを送信する。そうすると、ＨＧＧＳＮは、そのＰＤＰコンテキストのテーブル内に新たなエントリを生成し、ＶＳＧＳＮとネットワークＰＤＮとの間でユーザのパケットをルーティングすることを可能にする。ステップ５１２では、当該ＧＧＳＮは、ＶＳＧＳＮにＰＤＰコンテキスト生成応答メッセージを返送する。ここで、ＨＧＧＳＮがＰＤＰアドレスの許可についての責任を有していれば、それはそのＰＤＰコンテキスト生成応答メッセージに含められる。そうでなければ、対応するフィールドは、本手続の後に携帯ユーザがＰＤＰアドレスについて外部のＰＤＮと交渉する必要があることを示す０．０．０．０に設定される。次に、ステップ５１４において、無線アクセスベアラのセットアップ手続が開始される。ステップ５１４は、ＱｏＳの修正を含んでもよい。ステップ５１４においてＱｏＳパラメータが修正された場合には、ＶＳＧＳＮ及びＨＧＧＳＮは、ＰＤＰコンテキスト内のＱｏＳパラメータを修正するために、ステップ５１６及び５１８において、それぞれＰＤＰコンテキスト更新要求メッセージ及びＰＤＰコンテキスト更新応答メッセージを交換する。そして、ＶＳＧＳＮは、ステップ５２０において、ＰＤＰコンテキスト活性化容認メッセージをＭＮ（又はユーザ機器）へ送信し、手続を終了する。

当業者であれば、説明したこの第２のシナリオは、２つの状況のうちの少なくとも１つによって生じることを理解するであろう。より具体的には、この第２のシナリオにおいて説明したメッセージの交換は、（例えば禁止されたＶＰＬＭＮなどにより）ユーザが訪問先ネットワークのサービスを使用する権利を有していない場合、又は携帯ユーザがそのサービスを使用する権利を有しているものの携帯ユーザのＶＰＬＭＮのアクセスポイントへのアクセスが拒否された場合、である。

図６に示したように、第３のシナリオでは、ユーザが本実施形態に係る訪問先のＰＬＭＮにいる場合において、ローミングするユーザの通信は、ホームＧＧＳＮにより管理される。本シナリオでは、図５に関連して上で説明したシナリオと異なり、ＭＮは訪問先のＰＬＭＮのサービスを使用する権利及びＶＰＬＭＮのアクセスポイントまで到達する（reach）権限を有するものの、ＶＳＧＳＮのＧＧＳＮリストの検索は失敗に終わる。上述した一実施形態のように、ＧＧＳＮリスト構築ステップ２０２は、例えば上述した手法により、定期的に実行され得る。

そして、ステップ６０４において、携帯ユーザは、携帯ユニットが現在位置しているＰＬＭＮのＳＧＳＮへＰＤＰコンテキスト活性化要求メッセージを送信する。ここで、携帯ユーザはローミングしているため、そのＰＤＰコンテキスト活性化要求メッセージを処理するのは、訪問先ネットワーク（ＶＳＧＳＮ）のＳＧＳＮである。その後、ＶＳＧＳＮは、その要求の妥当性を確認するために、当該ユーザの登録レコードをチェックする。そして、一度携帯ユーザの要求の妥当性が確認されると、ＶＳＧＳＮは、ステップ６０６において、上述したＧＧＳＮ選択の仕組みを適用する。ステップ６０８では、選択されたサービスＩＤを有するサービスを提供しようとするＶＧＧＳＮのＩＰアドレスが、事前に構築されたＧＧＳＮリスト内で検索される。ここで、ステップ６０８では、ＶＳＧＳＮのＧＧＳＮリストの検索は、失敗に終わる。この検索失敗の結果、ＶＳＧＳＮは、第２のシナリオに関連して上述した手法と同様に、ＨＳＧＳＮと相互通信することが必要となる。

よって、ステップ６１０において、３つのステップによるホームＧＧＳＮのＩＰアドレス発見の仕組みが開始される。第１の部分、ステップ６１０ａでは、ＶＳＧＳＮは、選択されたサービスＩＤを含むＩＣＭＰによるホームＧＧＳＮアドレス発見要求メッセージを、携帯ユーザのホームＰＬＭＮのＳＧＳＮのユニキャストアドレスへ送信する。ホームＰＬＭＮのＳＧＳＮは、ステップ６１０ｂにおいて、そのＩＣＭＰによるホームＧＧＳＮアドレス発見要求メッセージを受信し、受信したサービスＩＤを用いて自身のＧＧＳＮリスト内での検索を実行する。ステップ６１０ｃでは、ＨＧＧＳＮのＩＰアドレス又はエラーメッセージのいずれかを含むＩＣＭＰによるホームＧＧＳＮアドレス発見応答メッセージが、もとのＶＳＧＳＮへと返送される。ここで、ＩＣＭＰによるホームＧＧＳＮアドレス発見応答メッセージがＨＧＧＳＮのＩＰアドレスを含んでいる場合には処理は継続し、そうでなければＰＤＰコンテキスト活性化手続は終了する。

ステップ６１２では、ＶＳＧＳＮは、ステップ６１０で取得されたＩＰアドレスを有するＨＧＧＳＮへ、ＰＤＰコンテキスト生成要求メッセージを送信する。そうすると、ＨＧＧＳＮは、そのＰＤＰコンテキストのテーブル内に新たなエントリを生成し、ＶＳＧＳＮとネットワークＰＤＮとの間でユーザのパケットをルーティングすることを可能にする。ステップ６１４では、当該ＧＧＳＮは、ＶＳＧＳＮにＰＤＰコンテキスト生成応答メッセージを返送する。ここで、ＨＧＧＳＮがＰＤＰアドレスの許可についての責任を有していれば、それはそのＰＤＰコンテキスト生成応答メッセージに含められる。そうでなければ、対応するフィールドは、本手続の後に携帯ユーザがＰＤＰアドレスについて外部のＰＤＮと交渉する必要があることを示す０．０．０．０に設定される。次に、ステップ６１６において、無線アクセスベアラのセットアップ手続が開始される。ステップ６１６は、ＱｏＳの修正を含んでもよい。ステップ６１６においてＱｏＳパラメータが修正された場合には、ＶＳＧＳＮ及びＨＧＧＳＮは、ＰＤＰコンテキスト内のＱｏＳパラメータを修正するために、ステップ６１８及び６２０において、それぞれＰＤＰコンテキスト更新要求メッセージ及びＰＤＰコンテキスト更新応答メッセージを交換する。そして、ＶＳＧＳＮは、ステップ６２２において、ＰＤＰコンテキスト活性化容認メッセージをＭＮ（又はユーザ機器）へ送信し、手続を終了する。

ここまでに説明した実施形態によれば、１つのユーザ機器からのネットワークへのアクセスについてのシナリオであって、ＡＰＮの代わりにサービスＩＤを使用してサービスをサポートするＧＧＳＮを選択する３つのシナリオが説明された。これら実施形態によれば、システムは、図４において一般的に描かれた、受信されたサービスＩＤに基づいてＧＧＳＮを特定するためのＧＧＳＮ選択の仕組みを使用する。また、図７には、特定の携帯ユーザに認められた権限及び受信側のＳＧＳＮにおけるＧＧＳＮリストの検索の結果に基づいて、ＰＤＰコンテキスト要求メッセージを生成し又はＰＤＰコンテキスト活性化要求メッセージを拒否するかを決定するための、いくつかの例示的なロジックが示されている。

まず、ステップ７０２において、ＳＧＳＮ１０８は、１つのユーザ機器からサービスＩＤを受信する。そして、ＳＧＳＮ１０８は、ステップ７０４において、ホームＰＬＭＮに携帯ユーザがいるかどうかをチェックし判定する。ステップ７０４の結果がＹｅｓであれば（即ち、携帯ユーザがそのホームＰＬＭＮ内にいれば）、ステップ７０６において、ＳＧＳＮ１０８は、受信したサービスＩＤに基づいて、自身のＧＧＳＮリスト内での検索を実行する。そして、ステップ７０６における検索の結果が肯定的であれば、ステップ７０８においてＰＤＰコンテキスト要求メッセージが生成される。また、ステップ７０６における検索の結果が否定的であれば、ＰＤＰコンテキスト活性化要求は、ステップ７１０において拒否される。

また、ステップ７０４へ戻り、その結果がＮｏであれば、ユーザはＶＰＬＭＮに位置する。ステップ７１２では、ＳＧＳＮは、ＶＰＬＭＮにより提供されるサービスを使用することができるか否かを判定する。ステップ７１２のその結果がＹｅｓであれば、ＳＧＳＮは、ステップ７１４において、さらにＶＰＬＭＮのアクセスポイントへのアクセスが承認されているかを判定する。そして、ステップ７１４の結果がＹｅｓであれば、ＳＧＳＮは、ステップ７１６において、受信したサービスＩＤに基づいて自身のＧＧＳＮリスト内を検索する。ここでステップ７１６において肯定的な検索結果が得られれば、ステップ７０８に示したように、ＰＤＰコンテキスト要求メッセージが生成される。

また、ステップ７１２、７１４又は７１６のいずれかの結果がＮｏ又は否定的な判定であった場合には、ステップ７１８において、ＳＧＳＮは、携帯ユーザにホームＰＬＭＮアクセスポイントへのアクセスが許可されているかをチェックする。そして、ステップ７１８での結果がＹｅｓであれば、ＳＧＳＮは、ステップ７２０において、前に受信したサービスＩＤを用いて、ホームＧＧＳＮのＩＰアドレス発見の仕組みを開始する。そして、ＨＧＧＳＮのＩＰアドレスの受信に成功すると、ステップ７２２において、ＰＤＰコンテキスト活性化要求メッセージが生成される。また、ステップ７１８又は７２０のいずれかの間に結果としてＮｏ又は否定的な結果が得られた場合には、ステップ７１０において、ＰＤＰコンテキスト活性化要求は拒否される。

上述した実施形態は、例えば、ＵＭＴＳシステム内でのローミングをサポートするためにＡＰＮの代わりにサービスＩＤを使用することに関連する様々な利益を提供する。例えば、上述したように、サービスＩＤは、地理的基準に基づくＡＰＮに含まれるＤＮＳアドレスの代わりに、数字を使用する。この違いは、典型的には、ローミングサービスの使用における効率性の向上をもたらす。なぜならば、もはやホームＧＧＳＮを通してルーティングされるべきデータについての要求ではない状況において、データパスから少なくとも１つの送信ステップが取り除かれるためである。

上述した例示的な実施形態は、本発明を限定するものではなく、むしろあらゆる観点において説明を目的としたものである。従って、本発明について、ここに含まれる説明から当業者により導き出し得る詳細な実装における多くの変形が可能である。全てのそうした変形及び修正は、次の特許請求の範囲により定義される本発明の範囲及び思想に含まれるものと考えられる。本応用の説明において使用されたどのような要素、動作又は指示も、そのような明示的な記述がない場合には、本発明にとって重大又は欠かすことのできないものではない。また、ここで用いられている通り、冠詞“ａ”は１つ以上のアイテムを含むことを意図している。

Claims (13)

1. データサービスを要求するメッセージを受信し又は送信するステップと、
   前記メッセージは、パケットデータプロトコルのコンテキストの活性化を要求するメッセージであり、ドメイン名を有するアクセスポイント名（ＡＰＮ）の代わりに、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）に前記データサービスをサポートさせるか否かを通信ノードが判定するために使用されるサービス識別番号を含むことと、
   前記サービス識別番号は、前記データサービスを提供するパケットデータネットワーク（ＰＤＮ）、又は前記データサービスのサービスクラスを示すことと、
   前記通信ノードの一般陸上移動体ネットワーク（ＰＬＭＮ）内のＧＧＳＮによる前記データサービスの提供が許可されている場合に、前記データサービスを提供する前記通信ノードのＰＬＭＮ内のＧＧＳＮを特定するために、前記サービス識別番号を用いて、サービスによりインデックス付けされたＧＧＳＮリストを検索するステップと、
   を含む通信方法。
2. 前記通信方法は、データサービスを要求するメッセージを受信する前記ステップを含み、さらに
   ＧＧＳＮにより提供されるサービス及び当該ＧＧＳＮに関連付けられたＩＰアドレスを示すメッセージを当該ＧＧＳＮから定期的に受信するステップと、
   前記ＧＧＳＮからの前記メッセージに基づいて前記ＧＧＳＮリストを構築するステップと、
   を含む、請求項１に記載の通信方法。
3. さらに、前記通信方法は、
   前記通信ノードのＰＬＭＮ内のＧＧＳＮによる前記データサービスの提供が許可されているか、又は前記データサービスがホームＰＬＭＮにより提供されるべきか、を判定するステップ、
   を含む、請求項２に記載の通信方法。
4. さらに、前記通信方法は、
   前記通信ノードのＰＬＭＮ内のＧＧＳＮによる前記データサービスの提供が許可されていないと判定された場合に、ホームＰＬＭＮ内のＧＧＳＮから前記データサービスを提供するために、当該ホームＧＧＳＮのＩＰアドレス発見の仕組みを開始するステップ、
   を含む、請求項３に記載の通信方法。
5. さらに、前記通信方法は、
   前記通信ノードのＰＬＭＮ内のＧＧＳＮによる前記データサービスの提供が許可されていると判定された場合であって、前記データサービスを提供するローカルＧＧＳＮのための前記ＧＧＳＮリストの検索が失敗したときに、ホームＰＬＭＮ内のＧＧＳＮから前記データサービスを提供するために、当該ホームＧＧＳＮのＩＰアドレス発見の仕組みを開始するステップ、
   を含む、請求項３に記載の通信方法。
6. 前記サービス識別番号は、第１のフィールドと第２のフィールドとを含む、請求項１に記載の通信方法。
7. 前記第１のフィールドは、ワイルドカード、パケットデータネットワーク及びサービスのうちの１つに対応する第１の番号を含むファンクションフィールドである、請求項６に記載の通信方法。
8. 前記第１の番号が前記パケットデータネットワークに対応する場合には、前記第２のフィールドは自律システム番号を含む、請求項７に記載の通信方法。
9. 前記第１の番号が前記サービスに対応する場合には、前記第２のフィールドはサービスクラス番号を含む、請求項７に記載の通信方法。
10. 前記サービスクラス番号は、対話型サービス、ストリーミングサービス、双方向型サービス、及びバックグラウンドサービスのうちの少なくとも１つに対応する、請求項９に記載の通信方法。
11. データサービスを要求するメッセージを受信するためのプロセッサを含む通信ノードであって、請求項１〜１０のいずれかに記載の方法を実行するように構成される、
    通信ノード。
12. 前記プロセッサは、さらに、ＧＧＳＮにより提供されるサービス及び当該ＧＧＳＮに関連付けられたＩＰアドレスを示すメッセージを当該ＧＧＳＮから定期的に受信し、
    前記通信ノードは、さらに：
    前記ＧＧＳＮからの前記メッセージに基づいてサービスによりインデックス付けされたＧＧＳＮリストを記憶するためのメモリ、
    を含む、請求項１１に記載の通信ノード。
13. データサービスを要求するメッセージを送信する送受信部、
    を備え、
    前記メッセージは、パケットデータプロトコルのコンテキストの活性化を要求するメッセージであり、ドメイン名を有するアクセスポイント名（ＡＰＮ）の代わりに、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）に前記データサービスをサポートさせるか否かを通信ノードが判定するために使用されるサービス識別番号を含み、
    前記サービス識別番号は、前記データサービスを提供するパケットデータネットワーク（ＰＤＮ）、又は前記データサービスのサービスクラスを示し、
    前記通信ノードの一般陸上移動体ネットワーク（ＰＬＭＮ）内のＧＧＳＮによる前記データサービスの提供が許可されている場合に、前記データサービスを提供する前記通信ノードのＰＬＭＮ内のＧＧＳＮを特定するために、前記サービス識別番号を用いて、サービスによりインデックス付けされたＧＧＳＮリストが検索される、
    携帯機器。
    

Images