JP2004517509A - 電話通信網へユーザ機器を付加する方法及び装置 - Google Patents

Abstract

本発明は、通信ネットワークに関し、ユーザ機器とゲートウェイサポートノードとの間に、中間のサービスサポートノードを迂回して、ダイレクト・トンネルを形成できる。しかしながら、ゲートウェイノードが、ユーザ機器が接続されている実際の通信ネットワークの外にある場合は、２−トンネルの概念が使用され、トンネルは、ユーザ機器とサービスサポートノードとの間に設けられる。同様に、合法的傍受に関する要求を受信すると、ユーザ機器とゲートウェイノードとの間に形成されたトンネルは、再構成されて、全てのユーザトラヒック及び制御信号をこのサービスノードを経由して導くためにサービスノードへ方向付けされる（図４）。

Description

【０００１】
（技術分野）
本発明は、トンネル接続を使用して電話通信網へユーザ機器を付加する方法及び装置に関する。
【０００２】
（背景技術）
例えば、ＧＰＲＳ（汎用パケット無線サービス；例えば、欧州規格（電話通信シリーズ）ＥＮ ３０１ １１３参照）又はＵＭＴＳ（ユニバーサル移動電話システム；例えば、ＥＴＳＩ規格ＥＳ ２０１ ３８５）規格等のＧＳＭ（移動通信用グローバルシステム）に基づく通信システムへユーザ機器を付加する場合、通常、ユーザ機器は、付加要求及びパケットデータ・プロトコル・コンテキスト起動要求をサポートノードへ送信し、その後、ＧＳＭ ＰＬＭＮ（公衆地上移動網）又はＵＭＴＳ ＰＬＭＮ等のアクセスネットワークに付加され、外部ネットワーク（例えばインターネット）に接続できるようになる。アクセスネットワークは、例えば、伝達チャンネルであるとすることで接続を可能にする。ＧＰＲＳ又はＵＭＴＳ等のパケット交換電話通信システムにおいて、ユーザトラヒックデータ及び制御（信号処理）データを含むデータは、通常、ユーザ機器からサービスサポートノードへ送信され、サービスサポートノードは、外部ネットワーク内の受信者へ通信を送信するために、このデータをゲートウェイサポートノード等の第２のサポートノードへ送信することができる。
【０００３】
更に、トンネル手法は、特にＩＰ上ではよく知られている。このトンネル手法の一例は、ＧＴＰ（ＧＰＲＳトンネルプロトコル）であり、これはバージョン１において、トンネル及びエンティティ内のトンネルを識別するトンネル終点識別子（ＴＥＩＤ）を処理する処理カードのノードを指示する宛先アドレス（トンネル終点アドレス、ＧＴＰ用Ｉｐｖ４又はＩｐｖ６）を有するトンネルを識別する。全てのエンティティは、別のトンネル終点で割り当てられたＴＥＩＤを有するパケットを受信すると共に、自分で割り当てたＴＥＩＤを有するパケットを受信する。通常、全体的には、通信ネットワーク内のトラヒック負荷を軽減する傾向にある。しかしながら、通信を別の通信ネットワークへ送信するか又はそこから受信する要求、又は関係者又はユーザ機器を監視する権限をもつ法執行機関による関係者又はユーザ機器の合法的傍受（監視）するための要求等の別の状況を考慮する必要がある。
【０００４】
（発明の開示）
本発明は、外部ネットワークへユーザ機器を接続するための方法及び装置を提供することを目的としており、ネットワークの動作性に悪影響を与えることなく又は合法的傍受可能性に影響を与えることなく、アクセスネットワーク上の負荷を軽減できることが好ましい。
本発明は、請求項で定義されるような方法及び／又は装置を提供する。
【０００５】
特に、本発明は、少なくとも２つのサポートノードを有するアクセスネットワークを経由して、ユーザ機器を外部ネットワークへ接続するための方法及び装置を提供し、通常の状態では、ユーザ機器は、自分の割当サポートノードを迂回して、トンネル接続を経由して直接第２のサポートノードへ接続できる。
【０００６】
このダイレクト・トンネル接続は、通常の状態において、第１のサポートノードがユーザ機器のユーザトラヒックを処理する必要がないので、ネットワーク内の全トラヒックを軽減する。更に、この接続は、第１のサポートノード及びその固有の（小さな）遅延が迂回されるので、全体的なトラヒック速度をある程度高くする。
【０００７】
しかしながら、動作性及び機能性を保証するために、本発明は、第１のサポートノードが、通常の状態の場合に１つのトンネルを確立する必要があるか否か、又は少なくとも１つの規定されたトリガを満足する場合に２つのトンネルを確立する必要があるか否かを判定するための規定されたトリガを検査することを提案する。
【０００８】
典型的に、適切な動作性及び機能性を保証するために、以下のトリガを検査する。
−特定のユーザに関するＣＡＭＥＬサービス等の特定のサービスのサポート、及びこれらのサービスが１つのトンネルでもって伝達されたかどうかの検査
−特定ユーザ向けの合法的傍受（ＬＩ）を実行する必要性
−選択された第２のサポートノードとＲＮＣ等の制御装置との間の、両者が同一のＧＴＰトンネルバージョンをサポートすることを保証するための相互運用性
−第１のサポートノードとして同じＰＬＭＮ内の課金データを集める必要性を決定できる、第１のサポートノード以外の別のＰＬＭＮ内の第２のサポートノードの位置
−第１のサポートノードから遠く離れた第２のサポートノードの位置、この場合、２つのトンネルは、（ユーザ移動性による）遠く離れた第２のサポートノードへのトンネルの頻繁な更新を回避することが好ましいであろう。これは階層移動性の原理である。
【０００９】
本発明は、１つ又はそれ以上の前述のトリガ（任意の組み合わせにおいて）を使用して、幾つのトンネルを確立するかを決定する。サポートノードは、これらのトリガを使用する可能性を提示する必要があり、オペレータは、どのトリガがその作動及びサービスに関連するかを設定する必要がある。
【００１０】
以下に詳細に説明する本発明の第１の実施形態は、常に第１のサポートノードとして同じＰＬＭＮ内の課金データを収集して、階層的移動性をサポートするために、最後の２つのトリガに対して如何に単純な検査を使用できるかを説明する。
【００１１】
本発明の前述又は別の実施形態において、第１のサポートノードは、第２のサポートノードが第１のサポートノードと同じネットワークの一部であるか否かを検査する。同じネットワークにある場合のみ、ダイレクト・トンネル接続が確立されることが好ましい。第２のサポートノードが別のＰＬＭＮの一部を形成する場合、ダイレクト・トンネル接続は提供されない。対照的に、ユーザデータ（ユーザトラヒックデータ）及び制御データを含む全トラヒックは第１のサポートノードへ送信され、次に、第１のサポートノードは、トンネル接続又は別の従来の方法によって、第２のサポートノード（自ネットワークの外にある）をアドレス指定できる。このことは、全トラヒックがユーザ機器に割り当てられた少なくとも１つのサポートノードへ進むことを保証し、課金及びリンクを含む全ての制御を適切に処理できるという利点をもたらす。
【００１２】
１つのトンネルを用意することは、依然としてユーザ機器からの２つのリンクが提供されることを意味することを理解されたい。一方のリンクは、ユーザ機器から第１のサポートノードへつながり、全ての制御データ（信号処理フロー）を転送する信号処理リンクであり、第２のデータリンクは、ユーザ機器と第２のサポートノード（例えば、同じＰＬＭＮにある）との間に形成され、制御データ以外の全てのユーザデータを処理するリンクである。ＵＭＴＳ等のシステムにおいて、このデータリンクは、ユーザ機器からＲＮＣへの無線伝達、及びＲＮＣと第２のサポートノードとの間のトンネルによって形成される。別のシステムにおいて、例えば、移動性に関するモバイルＩＰを利用して、トンネルは、ユーザ機器と第２のサポートノード（ホームエージェント）との間に確立することができる。
【００１３】
この２重リンク構造は、ユーザ機器と第２のサポートノードとの間のユーザデータトラヒックを、第１のサポートノードを迂回して直接処理するという利点をもたらし、このことは、それに起因する遅延を低減し、そうでなければ付加的に処理する必要があるトラヒック負荷を軽減する。一方で、第１のサポートノードは、常にユーザ機器へ又はそこからの制御データを送受信し、結果的に常にユーザ機器の作動を認識する。
【００１４】
ユーザ機器（携帯電話、ポータブルコンピュータのデータ装置等であってもよい）の合法的傍受に関する要求を受信した場合、第１のサポートノードは、ユーザ機器の接続状態を再構成できるが、このことは、それ以降はユーザデータが、その後監視用合法的傍受ゲートウェイ（ＬＩＧ）等を経由してデータを傍受機関へ送信できる第１のサポートノードを経由して送信されるといった方法で行われる。このトラヒック経路の再構成は、非常に迅速かつ有効に行うことができるので、傍受された機関はデータ伝送の変更を気付かない。
【００１５】
ＲＮＣがユーザ機器への無線リンクの解除を必要とする場合（この必要性は、無線信号処理を最適化するために、又は範囲外のＵＥ（ユーザ機器）の状態に同期させるためにＵＭＴＳ内で生じる）、ＲＮＣ等の制御装置は、第１のサポートノード（例えばＳＧＳＮ）に対する、例えばＩｕ解除手続き等の解除手続きを実行できる。この場合、ＧＧＳＮ等の第２のサポートノードへの１つのトンネルが確立されている場合、第１のサポートノードは、ユーザデータがそれ以降は第１のサポートノードを経由して送信されるように、ユーザ機器の接続状態を再構成できる。
【００１６】
ユーザデータがそれ以降は第１のサポートノードを経由して送信されるようにユーザ機器の接続状態を再構成することは、トンネルの宛先アドレスを変更するのに使用できるＧＰＲＳ／ＵＭＴＳシステムにおけるＰＤＰコンテキスト修正手続きを参照されたい。
【００１７】
（発明を実施するための最良の形態）
図１は、ＵＭＴＳシステムとして実施される電話通信網の基本構造を示す。しかしながら、ネットワークは、ＧＰＲＳのようなパケット交換データ伝送システムの全ての他の構造、又は全ての他の適切なシステム構造をもつことができる。図１のシステムは、携帯電話又はデータ装置であってもよいユーザ機器１を備える。実際には、ネットワークを経由して通信する複数のユーザ機器１が存在できる。伝送（呼び出し又はデータ伝送を開始又は終了する）を有効にするために、ユーザ機器１は、ユーザ機器アクセスを制御する制御装置、例えば、無線ネットワーク制御装置（ＲＮＣ）２（又は、基地局制御装置）を経由して、ユーザ機器１とＧＧＳＮとの間の通信を処理するサービスサポートノードとして機能する第１のサポートノード３へコマンド及びユーザデータを送受信する。例えば、呼び出し／データ伝送を公衆インターネット又はイントラネット等の外部ネットワークへ送信する場合、サービスサポートノード３は、ゲートウェイノード等の第２のサポートノード４と、又はＰＬＭＮ等の別のネットワークのゲートウェイサポートノード５と通信を行うことができる。データトラヒックは、ゲートウェイサポートノード上を移動する。
【００１８】
図２は、本発明の第１の実施形態による、ユーザ機器を付加して外部ネットワークへ接続する基本ステップを示す。ステップＳ１において、ユーザ機器１（図１）は、ＰＤＰコンテキストを付加して起動するための要求を、ＲＮＣ２等のユーザ機器に対するアクセスを行う制御装置を経由して、サービスサポートノード３へ送信する。サポートノード３は、１つ又は２つのトンネルを確立する必要があるか否かを確認するための検査を行う。
【００１９】
実行できる検査を以下に詳細に説明する。
−特定のユーザに関するＣＡＭＥＬサービス等の特定のサービスのサポート、及びこれらのサービスが１つのトンネルでもって伝達されたかどうかの検査
ＳＧＳＮ等の第１のサポートノードは、特定のサービスが起動されていれば、加入者データから検査できる。サービスの第１の例はＣＡＭＥＬプリペイドであり、第２の例はＳｏＬＳＡ（ローカライズドサービスエリアサポート）である。
【００２０】
このユーザ向けのＣＡＭＥＬの利用は、Ｃａｍｅｌ署名情報及び起動決定ポイントに示されている。ＰＤＰコンテキス起動要求をＵＥから受信すると、ＳＧＳＮは、このイベントに対して決定ポイントが起動されたか否かを検査できる。起動されていない場合、このトリガーに基づいて１つのトンネルを確立できる。起動されている場合、ＳＧＳＮは、サービス制御ポイント（ＳＣＰ）へ問い合わせを行い、処理方法を知ることができる。ＳＣＰがＳＧＳＮにデータ量の報告を要求する場合、第１の好ましい選択肢において、ＳＧＳＮは２つのトンネルを確立するので、データ量はそのデータ処理部において利用できる。
【００２１】
第２の好ましい選択肢において、ＳＧＳＮは、最初にＧＧＳＮ等の第２のノードに関するこのデータ量の報告能力を検査する。このことは、ＧＴＰ作成ＰＤＰコンテキスト要求メッセージへ、（ＳＣＰが定義するデータ量制限に基づいて）データ量報告を要求する選択フィールド「（例えば、図５に関連して定義されるデータ量閾値）」を追加することで可能になる。ＧＧＳＮがこの能力をサポートする場合、ＧＧＳＮは、ＧＴＰ作成ＰＤＰコンテキスト応答メッセージ内に、データ量報告に関する要求を受け取ったことを示す選択フィールドを追加することができる。ＧＧＳＮがこの選択フィールドを返送しない場合は、ＧＧＳＮがこの能力をサポートしていないことを示し、ＳＧＳＮは２つのトンネルを確立する。
【００２２】
第２のサービスＳｏＬＳＡの実行は、ＳｏＬＳＡが加入サービスである場合は加入者データの検査に基づく。その場合、異なるローカライズドサービスエリアに送信したデータ量を示す必要があり、ＳＧＳＮのみがＬＳＡが変わった時を検出できる。従って、ＳＧＳＮは、ＳｏＬＳＡユーザ向けに２つのトンネルを確立する必要がある。
【００２３】
−特定ユーザ向けの合法的傍受（ＬＩ）を実行する必要性
ＳＧＳＮは、付加手続き時に、新しいＵＥ（ユーザ機器）を傍受する必要があるか否かを検査する。通常の場合、ＳＧＳＮは常に傍受したＵＥのための２つのトンネルを確立するので、ＳＧＳＮは、それをＬＩＧ（合法的傍受ゲートウェイ）へ転送することができる。しかしながら、使用するＧＧＳＮが、ＬＩをサポートすると共に同じ国に配置されている場合、ＳＧＳＮは、１つのトンネルを確立することを決定できる（別のトリガーに起因する２つのトンネルをもつ必要ない場合）。
【００２４】
−選択された第２のサポートノードとＲＮＣ等の制御装置との間の、両者が同一のＧＴＰトンネルバージョンをサポートすることを保証するための相互運用性
特定の相互運用性の問題は、ＲＮＣがＧＴＰバージョン１だけをサポートし、ＧＧＳＮがＧＴＰバージョン０だけをサポートする場合に生じる。ＳＧＳＮは、ＧＴＰバージョン１を用いてＧＴＰ生成ＰＤＰコンテキストメッセージをＧＧＳＮへ送信する場合、及び「ＧＴＰメッセージバージョンがサポートされていない」ことを受信する場合にこの状況を検出する。この場合、ＧＧＳＮ及びＲＮＣは直接通信できないので、２つのトンネルを確立する必要がある。
【００２５】
−第１のサポートノードとして、同じＰＬＭＮ内の課金データを集める必要性を決定できる第１のサポートノード以外の、別のＰＬＭＮ内の第２のサポートノードの位置
別のＰＬＭＮ内のＧＧＳＮを使用してユーザ機器への無線アクセスを申し出るＰＬＭＮオペレータは、この第２のＰＬＭＮオペレータの課金情報を信用する場合、又は信用しない場合がある。従って、ＳＧＳＮは、事前に作成された信用のあるＰＬＭＮのリストから（及び、常に信用できる１つのＰＬＭＮの初期設定値によって）、信用のあるＰＬＭＮに属するか否かを検査する必要がある。リストに属していない場合、第１のＰＬＭＮオペレータが自分でユーザデータトラヒックを監視できるように２つのトンネルを確立すべきである。
【００２６】
−第１のサポートノードから遠く離れた第２のサポートノードの位置、この場合、２つのトンネルは、（ユーザ移動性による）遠く離れた第２のサポートノードへのトンネルの頻繁な更新を回避することが好ましいであろう。これは階層移動性の原理である。
ユーザ機器が移動中の場合、ユーザ機器は、自身のサービスＲＮＣを変更できるが、この変更は、新しいトンネル宛先アドレスを指示するための別のトンネル終点の更新を意味する。この更新は、別のトンネル終点が遠くにある場合、負荷が高くなり遅延をもたらすこともある。従って、遠くのＧＧＳＮに向かって１つのトンネルを確立することは有効ではない。従って、有効な移動性を維持するためには、ＳＧＳＮは、ＧＧＳＮが近くのＧＧＳＮに関する事前に作成されたリストに属するか否かを検査することになる。ＧＧＳＮがこのリストに属していない場合、２つのトンネルを確立する必要がある。
【００２７】
最後の２つの検査は、それ向かって１つのトンネルを生成できる単一のＰＬＭＮリストをもつことによって組み合わせ可能（信用があり近くのＧＧＳＮ）であることに留意されたい。
これらの検査により２つのトンネルを確立する必要がないことが分かると、ＳＧＳＮは、単一のトンネルを確立することになる。
【００２８】
この単一の又は複数の検査は、ユーザ機器１と第２のサポートノード４との間の第１のノード３によって確立されたトンネル接続が、呼び出し料金を正確に計算する等のネットワークを適切に制御して運用するのに必要な全ての情報を収集できるように、少なくとも同じネットワーク上にあるサポートノードによって処理されることを保証するために行う。
第１のサポートノード３が、呼び出しが同じネットワーク上の第２のノード４へ送信されたことを検出すると、基地局２を経由するがサポートノード３を迂回する、ユーザ機器１と第２のサポートノード４との間のダイレクト・トンネル接続が確立される（ステップＳ３）。
【００２９】
対照的に、第１のノード３が、ステップＳ２において、２つのトンネルを使用する必要があること（例えば、ゲートウェイサポートノード５が別のＰＬＭＮのノードである）を検出すると、処理はステップＳ４へ進み、ここでは第１のサポートノード３は、一方がユーザ機器（又は基地局ＲＮＣ２）からサポートノード３へつながり、他方がサポートノード３からサポートノード５等の外部サポートノードへつながる、２つのトンネルを準備する。トンネルを処理及び準備することは公知であり、例えば、欧州規格ＥＴＳＩ ＥＮ ３０１ ３４７に定義されている。
１つのトンネルだけを使用する場合、２つのトンネルをもつ場合に必要な追加の処理、及びサポートノード３の余分なノード接続点を省略でき、通信速度が上がりネットワーク負荷が軽減する。
【００３０】
図３は、合法的傍受要求を処理するための方法を示す。ここでは、通常の場合、スプリット・トンネル環境が示されており、サポートノード３は、基地局２からサポートノード４へのダイレクト・トンネルを確立する。しかしながら、このトンネルは、制御データ、即ち信号データを除く、ユーザへ送信した又はそこから受信した全てのデータであるユーザトラヒックのためだけに使用される。制御データは、依然として基地局２とサポートノード３との間で送信される。この状況を可能にするために、サポートノード３は、サービスＩｕ伝達を用意している場合、サポートノード４のアドレスをユーザトラヒックアドレスとして与える。従って、ＲＮＣ２は、依然としてサポートノード３とユーザデータを交換するが、実際のユーザデータトンネルは、直接サポートノード４へ進むと想定される。しかしながら、制御データは、依然としてサポートノード３へ直接送信され、そこで処理される。
【００３１】
合法的傍受（ＬＩ）要求の場合、例えば、ＥＴＳＩ規格を参照されたいが、サポートノード３は、単一のユーザに対して単一又は複数のＧＴＰトンネルの変更を要求する、無線アクセス伝達修正（ＲＡＮＰＡＰ）を実行することが好ましい。次に、この単一又は複数のトンネルは、サポートノード３を経由して経路付けされるので、全てのデータは、このノード３を経由して流れ、ノード３を流れるデータを監視することで合法的傍受が可能になる。トンネル終点アドレス及びＧＧＳＮに格納されているＴＥＩＤは、ＳＧＳＮ３のアドレス及びＴＥＩＤに更新される。同様に、ＲＮＣは更新され、トンネル終点アドレス及びＴＥＩＤと同様にノード３のアドレス及びＴＥＩＤを格納する。ＳＧＳＮは、上り回線及び下り回線に関する別のＴＥＩＤをもつことができる点に留意されたい。
【００３２】
図３は、前記の処理を詳細に示す。ステップＳ５において、（好ましくは、データフローの宛先をそれ自身に変えるために、常にサポートノード３がデータフローを規制できるよう、制御データのためではなくユーザデータだけのための）ユーザに関連するダイレクト・トンネルが、それぞれＲＮＣ２と第２のノード４との間に確立される。ステップＳ６において、このユーザに関するサポートノード３が合法的傍受要求を受信すると、プロセスはステップＳ７へ進む。このような要求を受信しない場合は通常の処理のままである。ステップＳ７において、ユーザ機器（詳細にはＲＮＣ２）と第２のノード４との間に存在するダイレクト・トンネルはキャンセルされる。このことは、例えば、ＲＡＮＡＰ無線アクセス伝達修正を行い、ノード４に格納されているアドレスをノード３のアドレスへ更新することによって、ノード３からＲＮＣ２への無線アクセス伝達を変更する要求を送信することで行うことができる。この要求は、ユーザトンネルの変更を必要とする。次に、サポートノード３は、自アドレスを、ＲＮＣ２から及びＲＮＣ２へ、即ちユーザ機器１から及びＲＮＣ２へ送信されることになるユーザパケットデータのアドレスとして与えることができる。次に、ユーザデータ及び制御データを含む全てのトラヒックは、第１のノード３によって処理される。従って、このノード３は、全ての送信済みユーザデータを、例えば、ＥＴＳＩ規格に定義されているような合法的傍受ゲートウェイ（ＬＩＧ）へ送信することができる。次に、ステップＳ８による合法的傍受は、ユーザ機器１へ送信され、そこで受信される全ての通信を監視てきるようになる。
【００３３】
図４は、ユーザ機器を起動する場合、ユーザ機器１（又は制御局ＲＮＣ２）と第２のサポートノード（ＧＧＳＮ）４との間にダイレクト・トンネルを確立するための信号処理及び制御フローを示す。任意のＬ３信号処理を開始する前に、ＲＲＣ接続（受信器接続状態）を公知の方法で確立しておく必要がある（ＲＲＣ手順を参照）。このＲＲＣ接続確立は、新しいコンテキスト（例えば、ＥＴＳＩ ＥＮ ３０１ ３４７規格を参照）を起動するためのユーザ機器１の決定の前後で行うことができる。図４に示す信号処理メッセージは以下の通りである。
ステップ１：
ユーザ機器１は、「起動ＰＤＰコンテキスト要求」を第１のサポートノード３へ送信するが、第１のサポートノード３は、データ項目プロトコル識別子、処理識別子、起動ＰＤＰコンテキスト要求メッセージ識別、要求ＮＳＡＰＩ、ＰＤＰ形式を含む要求ＰＤＰアドレス、要求サービスＱｏＳの品質、プロトコル構成オプション（任意）、アクセスポイント名ＡＰＮ（任意）、及び別のパラメータを含む。このメッセージは、Ｉｕインタフェース上で、ＲＡＮＡＰダイレクト転送要求メッセージ内に、ユーザに気付かれることなくカプセル化できる。また、これらは安全保障処置をサポートノード３とユーザ機器１との間で実行できる。
【００３４】
サポートノード３は、加入者の権利を検査する。「起動ＰＤＰコンテキスト要求」が有効であると判定すると、サポートノード３は、使用するＡＰＮを取得し、それを用いてＤＮＳ（ドメインネームサーバ）機能を問い合わせるが、これは、別のネットワークと通信を行うためのゲートウェイサポートノードであってもよい割り当てられた第２のサポートノード４のアドレスを知るためのものである。ＤＮＳ機能は、第２のサポートノード４のＩＰ（インターネットプロトコル）アドレスを返送する。第１のサポートノード３は、トンネルに関するＴＥＩＤを生成する。更に、サポートノード３は、要求ＱｏＳを格下げする必要があるか否かを判定する。
【００３５】
その後、サポートノード３は、ステップ５及び６の前後で以下のステップ２及び３を実行する必要があるか否かを決定する。制御装置２（例えば、無線ネットワークサブシステムであってもよく、図１のＲＮＣに対応する）は、第２のサポートノード４よりもサービスＱｏＳ品質を格下げする可能性が高いので、ステップ２及び３は、ステップ５及び６の前に実行することが好ましい。
【００３６】
ステップ２：
次に、サポートノード３は、無線アクセス伝達（ＲＡＢ）割当要求をＲＮＳ、ＲＮＣ、又はサービスＲＮＣ２等のユーザ機器アクセス制御装置へ送信し、この要求は、ＰＤＰ（パケットデータプロトコル）コンテキスト起動要求に対応し、ＩＭＳＩ、ＮＳＡＰＩ、サポートノード３用ＴＥＩＤ、サポートノード３（ＳＧＳＮ）のＩＰアドレス、１に取り決められているＱｏＳ（必須の並べ換えを含む）パラメータを含む。図４において、サポートノード３は、ＵＭＴＳネットワークの第３世代のＧＰＲＳサポートノードの仕様を定める３Ｇ−ＳＧＳＮとして指定される。しかしながら、サポートノード３は、別の世代又は汎用ＧＳＭ形式であってもよい。ステップ２で送信された情報は、Ｉｕインタフェース上のＧＴＰ（ＧＰＲＳトンネルプロトコル）トンネルを設定するために使用される。通常、ＧＰＲＳフェーズ１において、必須の並べ換えは、ゲートウェイサポートノード４によって指示される。しかしながら、ここではユーザ機器１が必須の並べ換えを要求することが好ましい。
【００３７】
ステップ３：
基地局２は、無線アクセス伝達設定手続きを使用して、ユーザ機器ＵＥ１へ確立される新しい伝達ＩＤ（識別子）、及びＲＲＣ信号をもつ対応するＮＳＡＰＩを指示する。サポートノード３は、必ずしも伝達ＩＤに関する情報を必要としないので、この情報は、望ましくは基地局２とユーザ機器１との間で直接交換される。
【００３８】
ステップ４：
基地局２は、ＲＡＢ割当完了メッセージ（即ち、ＰＤＰコンテキスト起動応答）をサポートノード３へ送信して、無線アクセス伝達設定が完了したことを知らせる。このメッセージは、以下のパラメータを含む。即ち、ＴＩＤ、ＲＮＣ２に関する下り回線フローラベル、ＲＮＣ２に関するＩＰアドレス、２に取り決められているＱｏＳ（必須の並べ換えを含む）である。次に、ＧＴＰトンネルは、Ｉｕインタフェース上で開く。
【００３９】
ステップ５：
次に、サポートノード３は、「生成ＰＤＰコンテキスト要求」メッセージを第２のサポートノード４を送信することで、Ｇｎインタフェース上のＧＴＰトンネルを設定するための手続きを開始するが、このメッセージは、ユーザＰＤＰ形式及びアドレスに関する情報、ＡＮＰ、２に取り決めされているＱｏＳ（必須の並べ換えを含む）、フィルタパラメータ、選択モード、並びにＲＮＣ２に関する下り回線ＴＥＩＤ及びＲＮＣ２のＩＰアドレスを含む。最後の２つのパラメータをＳＧＳＮのものに代えて送信することは新規性のある特徴点であることに留意されたい。しかしながら、ＧＧＳＮは、どのような差異でも通知できる。データ項目「選択モード」は、加入ＡＰＮが選択されたか否か、又はユーザ機器１等の移動局が送信した非加入ＡＰＮ、又は第１のサポートノード３が選択した非加入ＡＰＮが選択されたか否かを指示できる。
【００４０】
ステップ６：
次に、サポートノード４は、サポートノード４のＩＰアドレス、サポートノード４に関する上り回線ＴＥＩＤ、ユーザＰＤＰアドレス、３に取り決められているＱｏＳ（必須の並べ換えを含む）、ＰＤＰ構成オプション、及び課金ＩＤを含む、「生成ＰＤＰコンテキスト応答」メッセージに応答する。この場合、３に取り決められているＱｏＳは、２に取り決められているＱｏＳとは異なっており、おそらくサポートノード３は、Ｉｕトンネルを再度取り決めることができる点に留意されたい。しかしながら、このことは必要ではない。次に、ＧＴＰトンネルは、Ｇｎインタフェース上で開く。
前述のように、この応答は、特に、データ量報告等の所定の機能がＧＧＳＮによってサポートされていないか、又はサポートされているＧＴＰバージョンがＲＮＣと互換性がない場合に、トリガを起動できることに留意されたい。
【００４１】
ステップ７：
サポートノード３は、「起動ＰＤＰコンテキスト受領」メッセージをＮＳＡＰＩ（又はＴＩ）、ＰＤＰ形式、アドレス、３に取り決められているＱｏＳ、及びＰＤＰ構成オプションをもつユーザ機器へ送信する。このメッセージは、ダイレクト転送要求メッセージとしてＬｕインタフェース上で返答される。次に、ユーザ機器１は、この伝達に関するＮＳＡＰＩ、伝達ＩＤ、及びＱｏＳプロファイルを識別する。
【００４２】
ステップ８：
ステップ７と並行して、サポートノード３は、ＩｕインタフェースのＧＴＰトンネルの構成に関する、無線アクセス伝達（ＲＡＢ）確立コマンドを送信する。パラメータは、ＩＭＳＩ、ＮＳＡＰＩ、サポートノード４のＩＰアドレス、サポートノード４に関する上り回線ＴＥＩＤ、３に取り決められているＱｏＳ等である。つまり、ＲＮＣ２は、このトンネルに関する宛先ＩＰアドレス及び上り回線ＴＥＩＤを修正するので、次に、ユーザ機器１のＲＮＣ２と第２のサポートノード４との間にトンネルが直接開けられる。ＲＮＣ２は、第１のサポートノード３に対する「ＲＡＢ確立完了」メッセージに応答する。
【００４３】
この手続きは、２つのトンネルの代わりに１つのトンネルだけをもつことによって、搬送効率を最適にする。更に、課金収集及び登録は、第２のサポートノードにおいて行われ、第２のサポートノードは、ＰＬＭＮ（収集ＣＤＲが唯一のノードにおいて実行される）毎に唯一のノードである。
【００４４】
図４の信号処理図において、ステップ５及び６は、ステップ２、３、４の後に実行することもできる。更に、サポートノード３とサポートノード４との間のトンネルは、この手続きの後で修正することもできる。
【００４５】
図２のプロセスを実行するために、サポートノード３は、ステップ８を実行する前に、第２のサポートノード４が、自身のネットワークの一部か否か、又は事前に作成されたＰＬＭＮリストに属するか又は属さない別のＰＬＭＮの一部か否かを検査できる。サポートノード４がサポートノード３と同じネットワークの一部である場合、前述のようにステップ８が実行されるが、そうでなければステップ８は省略できる。更に、ステップ５は、次にサポートノード３（ＲＮＣ２の代わりに）に関するＴＥＩＤ下り回線を指示し、サポートノード３（同様にＲＮＣ２の代わりに）のＩＰアドレスを指示するように修正される。データ処理を最適化するために、図２のステップＳ２による検査は、望ましくは、ステップ５の後にサポートノード３によって実行される。
【００４６】
図３の手続きの実行に関して、ステップＳ６に示すような合法的傍受に関する要求を受信する場合、サポートノード３は、一方はＲＮＣ２とサポートノード３との間、他方はサポートノード３とサポートノード４との間に２つのトンネルが形成されるような方式でトンネルをリセットするように、ステップ８と同様の更新された無線アクセス伝達再構成手続きを実行する。
【００４７】
図５は、本発明の１つの実施形態におけるメッセージフローの詳細を示し、第１のサポートノード３（ＳＧＳＮ）、第２のサポートノード４又は５（ＧＧＳＮ）、及び本明細書ではインテリジェントネットワーク（ＩＮ）のサービス制御ポイント（ＳＣＰ）として実施される追加の制御手段６を備える。本実施形態は、例えば、ＣＡＭＥＬ環境においてダイレクト・トンネル接続（ＧＴＰ）を確立する場合でも前払いアカウントをもつ加入者に正確に課金するための解決法を提供する。『』で囲んだ文字は、新しい機能又はメッセージコンテンツを表す。
【００４８】
ＳＧＳＮ３は、「起動ＰＤＰコンテキスト要求」をユーザ機器（ＵＥ）から受信すると、メッセージ「初期ＤＰイベント／イベントレポートＧＰＲＳ」をＵＥの状態セットを検査するＳＣＰ６へ送信する。
【００４９】
ＳＣＰ６は、「付加課金ＧＰＲＳ（データ量閾値）」をＳＧＳＮ３へ送信する。次に、ＳＧＳＮ３は、「生成ＰＤＰコンテキスト要求（『データ量閾値』）をＧＧＳＮ４（又は５）へアドレス指定して、ＧＧＳＮ４にＳＣＰ６から送信されたデータ量閾値を知らせる。ＧＧＳＮ４は、コンテキスト生成ステップを実行して「生成ＰＤＰコンテキスト応答」を返送する。「生成ＰＤＰコンテキスト応答」において、ＧＧＳＮは、データ量レポート処理をサポートしているか否かの表示を送信する。これに関連して、ＳＧＳＮ３は、メッセージ「起動ＰＤＰコンテキスト受領」をＵＥへ送信する。
【００５０】
ＧＧＳＮ４は、『データ量通知要求（データ量）』を送信することで、ＳＧＳＮ３へデータ量を知らせる。ＳＧＳＮ３は、『データ量通知応答』を返送することで、このメッセージに肯定応答する。最後に、ＳＧＳＮ３は、結果的に加入者アカウントを更新する、レポート「付加課金レポートＧＰＲＳ（データ量）」をＳＣＰ６へ送信する。
【００５１】
図６は、１−トンネル解決法をもつ場合に課金基準がリセット又は変更された場合に対処する。図５の実施形態と同様に、この実施例は、第１のサポートノード３（ＳＧＳＮ）、第２のサポートノード４又は５（ＧＧＳＮ）、及びインテリジェントネットワーク（ＩＮ）のサービス制御ポイント（ＳＣＰ）である追加の制御手段６を備える。
【００５２】
ＳＣＰ６が、加入者アカウントの再変更、又は加入者が送受信する許容データ量の変更、又はＳＧＳＮ３又はＳＣＰ６が更新される等の理由で、特定の加入者を考慮して、ＳＧＳＮにデータ量閾値を知らせる必要性を決定すると、ＳＣＰ６は、実際に有効なデータ量閾値を指示するメッセージ「付加課金ＧＰＲＳ（データ量閾値）」をＳＧＳＮ３へ送信する。ＳＧＳＮ３は、直ちに「更新ＰＤＰコンテキスト要求（『データ量閾値』）」を送信することでＧＧＳＮ４（又は５）へ知らせる。ＧＧＳＮ４は、このデータ量閾値を格納して、「更新ＰＤＰコンテキスト応答」を返送することでメッセージに肯定応答する。
【００５３】
ＧＧＳＮ４が、その終了時か又は指示データ量閾値に達した場合にデータ伝送を行うユーザ機器が送受信するデータ量をＳＧＳＮ３へ知らせようとする場合、ＧＧＳＮ４は、送受信データ量に関する情報をもつＳＧＳＮ３へ『データ量通知要求（データ量）』を送信する。ＳＧＳＮ３は、『データ量通知応答』を返送することで、このメッセージに肯定応答し、正確に加入者へ課金するための、適切な課金レポートメッセージ「付加課金レポートＧＰＲＳ（データ量）」をＳＣＰ６へ送信する。
【００５４】
図７は、図５及び図６の両者に対する変形例を示す。既存のパラメータ（図５及び図６）に対する新しいパラメータ、データ量閾値を加えること、又は新しいパラメータを実行するための新しいメッセージ、更新閾値要求及び更新閾値応答を導入することが可能である。例えば、ＰＤＰコンテキスト作動停止時、及び／又はＰＤＰコンテキスト修正時のＧＧＳＮからＳＧＳＮへのデータ量を送信することが可能である。このことは、データ量パラメータを既存のメッセージへ加えることを意味している。この場合、別個のメッセージ「データ量通知要求」及び「データ量通知応答」を送信する必要はない。
【００５５】
図５及び図６で示す場合と同様に、図７の実施形態は、１−トンネル解決法をもつ場合に課金基準がセット、リセット、又は変更された場合に対処する。図５及び図６で示す実施形態と同様に、本変形例は、第１のサポートノード３（ＳＧＳＮ）、第２のサポートノード４又は５（ＧＧＳＮ）、及び追加の制御手段ＳＣＰ６を備える。ＳＣＰから送信されたデータ量閾値は、唯一のデータレポートに付加される。ＳＣＰが別のレポートを必要とする場合、同一のデータ量閾値であっても再度問い合わせを行う必要がある。
【００５６】
ＳＣＰ６が、例えば前述の理由により、特定の加入者を考慮して、ＳＧＳＮにデータ量閾値を知らせる必要性を決定すると、ＳＣＰ６は、実際に有効なデータ量閾値を指示するメッセージ「付加課金ＧＰＲＳ（データ量閾値）」をＳＧＳＮ３へ送信する。ＳＧＳＮ３は、直ちに『更新ＰＤＰコンテキスト要求（データ量閾値）』を送信することでＧＧＳＮ４（又は５）へ知らせる。ＧＧＳＮ４は、このデータ量閾値を格納して、『更新閾値応答』を返送することでメッセージに肯定応答する。ＳＧＳＮが肯定応答メッセージを受信しない場合、ＳＧＳＮは、ＧＧＳＮ４（又は５）がデータ量レポート処理をサポートしていないことを知る。
【００５７】
図５及び図６の場合と同様に、ＧＧＳＮ４が、その終了時か又は指示データ量閾値に達した場合にデータ伝送を行うユーザ機器が送受信するデータ量をＳＧＳＮ３へ知らせようとする場合、ＧＧＳＮ４は、送受信データ量に関する情報をもつＳＧＳＮ３へ『データ量通知要求（データ量）』を送信する。ＳＧＳＮ３は、『データ量通知応答』を返送することで、このメッセージに肯定応答し、正確に加入者へ課金するための、適切な課金レポートメッセージ「付加課金レポートＧＰＲＳ（データ量）」をＳＣＰ６へ送信する。
【００５８】
ＧＧＳＮは、ＰＤＰコンテキストの作動停止時にデータ量をＳＧＳＮへ送信できる。ＧＧＳＮは、データ量通知要求及びデータ量通知応答メッセージの代わりとして、例えば、ＰＤＰコンテキスト作動停止に関する既存の使用メッセージのデータ量を送信できる。ＧＧＳＮがＰＤＰコンテキスト作動停止を起こすと、ＧＧＳＮは、ＳＧＳＮへ削除ＰＤＰコンテキスト要求メッセージのデータ量を送信する。ＭＳ又はＳＧＳＮがＰＤＰコンテキスト作動停止を起こすと、ＧＧＳＮは、削除ＰＤＰコンテキスト応答メッセージのデータ量をＳＧＳＮへ送信する。
【００５９】
ＧＧＳＮは、データ量閾値が変わった場合、現在のデータ量をＳＧＳＮへ送信することができる。ＧＧＳＮは使用メッセージのデータ量を送信して、新しいデータ量閾値を肯定応答することができる。ＧＧＳＮは、更新ＰＤＰコンテキスト応答メッセージ（図６）又は更新閾値応答メッセージ（図７）のデータ量を送信することができる。
【００６０】
本発明の利用は、前述の場合に限定されるものではなく、例えば、サービスノードが別個の要素セットとして実行される場合にも適用可能である。
この実行の第１の実施例は、ポリシーサーバ内で実行されるサービスサポートノードの一部をもつ場合である。特に、本発明で説明されている検査は、このようなポリシーサーバで実行することができる。
この実行の第２の実施例は、一方が制御データ（サーバサービスサポートノード）のみを処理し、他方がユーザプレーン（ユーザデータサービスサポートノード）を処理する２つの別個の要素において実行されるサービスサポートノードをもつ場合である。このような実行において、本発明で説明されている検査は、１つのトンネル（ＲＮＣからゲートウェイサポートノードへ直接接続される）又は２つのトンネル（ＲＮＣからユーザデータサービスサポートノード、及びユーザデータサービスサポートノードからゲートウェイサポートノード）が確立されているか否かを判定するために使用される。
【図面の簡単な説明】
【図１】
電話通信網の基本構造の概略的な実施形態を示す。
【図２】
本発明の１つの実施形態の処理フローを示す。
【図３】
本発明の同じ又は別の実施形態の処理フローを示す。
【図４】
ユーザ機器を電話通信網へ取付けた場合の信号データフローを示す。
【図５】
本発明の別の実施形態における、サポートノードと制御ポイントへの又はそれらの間のメセージフローを示す。
【図６】
本発明の別の実施形態における、サポートノードと制御ポイントへの又はそれらの間のメセージフローを示す。
【図７】
図５及び図６によるサポートノードと制御ポイントへの又はそれらの間のメセージフローの変形例を示す。

Claims (43)

1. 第２のサポートノードと通信可能な少なくとも第１のサポートノードを有する通信ネットワークへユーザ機器を接続するための方法であって、
   前記ネットワークへの接続を確立するために、前記ユーザ機器は、前記ユーザ機器又は前記ユーザ機器へのアクセスを可能にする制御装置と前記第２のサポートノードとの間のダイレクト・トンネル接続を確立するか否かの検査を行う前記ネットワークの前記第１のサポートノードへ要求を送信し、
   前記第１のサポートノードは、前記検査の結果に基づいて、前記ユーザ機器又は前記制御装置と前記第２のサポートノードとの間の前記トンネル接続を確立することを特徴とする方法。
2. 前記ダイレクト・トンネル接続は、ユーザトラヒックデータのみを送信するためのトンネルであり、信号処理データは、前記ユーザ機器から前記第１のサポートノードへアドレス指定されることを特徴とする請求項１に記載の方法。
3. 前記ダイレクト・トンネル接続は、信号処理データ及びユーザデータの両方を送信するためのトンネルであることを特徴とする請求項１に記載の方法。
4. 第２のサポートノードが同じ前記通信ネットワークの一部であるか否かを検査する段階を含み、前記第２のサポートノードが同じ前記通信ネットワークの一部である場合にのみ、単一のダイレクト・トンネル接続が確立される、一方で、前記第２のサポートノードが別の通信ネットワークの一部であることが認識される場合は、一方が前記ユーザ機器から前記第１のサポートノード、他方が前記第１のサポートノードから前記第２のサポートノードである２つのトンネルが確立されることを特徴とする請求項１、２、又は３に記載の方法。
5. 前記第１のサポートノードと前記第２のサポートノードとの間の距離が所定の距離値よりも大きいか又は小さいかを検査する段階を含み、前記第１のサポートノードと前記第２のサポートノードとの間の距離が前記所定の距離値よりも小さい場合にのみ、単一のダイレクト・トンネル接続が確立され、一方で、前記距離が前記所定の距離値よりも大きいことが認識される場合は、一方が前記ユーザ機器から前記第１のサポートノード、他方が前記第１のサポートノードから前記第２のサポートノードである２つのトンネルが確立されることを特徴とする前記請求項のいずれか１項に記載の方法。
6. 前記ユーザ機器に対する合法的傍受が起動されているか否かを検査する段階を含み、前記ユーザ機器に対する合法的傍受が起動されていない場合にのみ、単一のダイレクト・トンネル接続が確立され、一方で、そうでない場合は、一方が前記ユーザ機器から前記第１のサポートノード、他方が前記第１のサポートノードから前記第２のサポートノードである２つのトンネルが確立されることを特徴とする前記請求項のいずれか１項に記載の方法。
7. 単一のダイレクト・トンネル接続を確立する場合でも所定のユーザ向けに起動される１つ又はそれ以上のサービスが提供できるか否かを検査する段階を含み、このようなトンネル接続がある場合でも前記１つ又はそれ以上のサービスが提供される場合にのみ、単一のダイレクト・トンネル接続が確立されることを特徴とする前記請求項のいずれか１項に記載の方法。
8. 前記第２のサポートノードと前記制御装置との間にダイレクト・トンネル接続がある場合に両者の相互運用性が保証されるか否かを検査する段階を含み、前記ダイレクト・トンネル接続は、相互運用性が保証される場合にのみ確立されることを特徴とする前記請求項のいずれか１項に記載の方法。
9. 前記ユーザ機器又は制御装置と前記第２のサポートノードとの間にダイレクト・トンネル接続がある場合に正確な課金レポートの作成が保証されるか否かを検査する段階を含み、前記ダイレクト・トンネル接続は、正確な課金レポートの作成が保証される場合にのみ確立されることを特徴とする前記請求項のいずれか１項に記載の方法。
10. 前記ユーザ機器の合法的傍受に関する要求を受信した場合に、前記第１のサポートノードは、確立されたダイレクト・トンネル接続をキャンセルし、結果的にユーザトラヒックデータ並びに信号処理データの両者は、その後、前記第１のサポートノードへアドレス指定されることを特徴とする前記請求項のいずれか１項に記載の方法。
11. 前記第１のサポートノードは、ユーザトラヒックデータの前記アドレスを自アドレスへ変更するための、無線アクセス伝達修正を行うことを特徴とする請求項１０に記載の方法。
12. 前記ダイレクト・トンネル接続が確立される、パケットデータ伝送は、ユーザ機器から送信されたユーザトラヒックパケットデータに前記第２のノードの前記アドレスを与えること、及び前記第２のノードから送信されたユーザトラヒックパケットデータに前記ユーザ機器の前記アドレスを与えることによって行われることを特徴とする前記請求項のいずれか１項に記載の方法。
13. 前記第１のサポートノードは、制御手段から課金関連情報を受信する場合、前記課金関連情報を知らせるメッセージを第２のサポートノードへ送信することを特徴とする前記請求項のいずれか１項に記載の方法。
14. 前記課金関連情報は、データ量閾値であることを特徴とする請求項１３に記載の方法。
15. 前記メッセージは、生成ＰＤＰコンテキスト要求、更新ＰＤＰコンテキスト要求、又は更新閾値要求であることを特徴とする請求項１３又は１４に記載の方法。
16. 前記第１のサポートノードから前記メッセージを受信した後に、前記第２のサポートノードは、データ量等の課金関連パラメータを監視し、前記第１のサポートノードへ監視した前記データ量等の課金関連情報を返送することを特徴とする請求項１３から１５のいずれか１項に記載の方法。
17. 前記課金関連情報は、データ量閾値に達した後に返送されることを特徴とする請求項１３から１６のいずれか１項に記載の方法。
18. 前記課金関連情報は、トンネル接続の変更後に返送されることを特徴とする請求項１３から１７のいずれか１項に記載の方法。
19. 前記課金関連情報は、トンネル接続の解除後に返送されることを特徴とする請求項１３から１８のいずれか１項に記載の方法。
20. 前記課金関連情報又は課金関連パラメータは、データ量通知要求メッセージ内に返送されることを特徴とする請求項１３から１９のいずれか１項に記載の方法。
21. 前記課金関連情報又は課金関連パラメータはデータ量通知応答メッセージによって肯定応答されることを特徴とする請求項１３から２０のいずれか１項に記載の方法。
22. 前記制御手段は、サービス制御ポイントであることを特徴とする請求項１３から２１のいずれか１項に記載の方法。
23. 第２のサポートノードと通信可能な少なくとも第１のサポートノードを有する通信ネットワークへユーザ機器を接続するための装置であって、
    前記ネットワークへの接続を確立するために、前記ユーザ機器は、前記ユーザ機器又は前記ユーザ機器へのアクセスを可能にする制御装置と前記第２のサポートノードとの間のダイレクト・トンネル接続を確立するか否かの検査を行うようになっている前記ネットワークの前記第１のサポートノードへ要求を送信するようになっており、
    前記第１のサポートノードは、前記検査の結果に基づいて、前記ユーザ機器又は前記制御装置と前記第２のサポートノードとの間の前記トンネル接続を確立するようになっていることを特徴とする装置。
24. 前記ダイレクト・トンネル接続は、信号処理データ及びユーザデータの両方を送信するためのトンネル、又はユーザトラヒックデータのみを送信するためのトンネルであり、後者の場合、前記信号処理データは前記ユーザ機器から前記第１のサポートノードへアドレス指定されることを特徴とする請求項２３に記載の装置。
25. 前記第２のサポートノードが同じ通信ネットワークの一部であるか否かを検査する制御手段を備え、前記第２のサポートノードが同じ通信ネットワークの一部である場合にダイレクト・トンネル接続が確立され、一方で、前記第２のサポートノードが別の通信ネットワークの一部であることが認識される場合は、一方が前記ユーザ機器から前記第１のサポートノード、他方が前記第１のサポートノードから前記第２のサポートノードである２つのトンネルが確立されることを特徴とする請求項２３又は２４に記載の装置。
26. 前記第１のサポートノードと前記第２のサポートノードとの間の距離が所定の距離値よりも大きいか又は小さいかを検査する制御手段を備え、前記第１のサポートノードと前記第２のサポートノードとの間の距離が前記所定の距離値よりも小さい場合にのみ、単一のダイレクト・トンネル接続が確立され、一方で、前記距離が前記所定の距離値よりも大きいことが認識される場合は、一方が前記ユーザ機器から前記第１のサポートノード、他方が前記第１のサポートノードから前記第２のサポートノードである２つのトンネルが確立されることを特徴とする請求項２３から２５のいずれか１項に記載の装置。
27. 前記ユーザ機器に対する合法的傍受が起動されているか否かを検査する制御手段を備え、前記ユーザ機器に対する合法的傍受が起動されていない場合にのみ、単一のダイレクト・トンネル接続が確立され、一方で、そうでない場合は、一方が前記ユーザ機器から前記第１のサポートノード、他方が前記第１のサポートノードから前記第２のサポートノードである２つのトンネルが確立されることを特徴とする請求項２３から２６のいずれか１項に記載の装置。
28. 単一のダイレクト・トンネル接続を確立する場合でも所定のユーザ向けに起動される１つ又はそれ以上のサービスが提供できるか否かを検査する制御手段を備え、このようなトンネル接続がある場合でも前記１つ又はそれ以上のサービスが提供される場合にのみ、単一のダイレクト・トンネル接続が確立されることを特徴とする請求項２３から２７のいずれか１項に記載の装置。
29. 前記第２のサポートノードと前記制御装置との間にダイレクト・トンネル接続がある場合に両者の相互運用性が保証されるか否かを検査する制御手段を備え、前記ダイレクト・トンネル接続は、相互運用性が保証される場合にのみ確立されることを特徴とする請求項２３から２８のいずれか１項に記載の装置。
30. 前記ユーザ機器又は制御装置と前記第２のサポートノードとの間にダイレクト・トンネル接続がある場合に正確な課金レポートの作成が保証されるか否かを検査する制御手段を備え、前記ダイレクト・トンネル接続は、正確な課金レポートの作成が保証される場合にのみ確立されることを特徴とする請求項２３から２９のいずれか１項に記載の装置。
31. 前記制御手段は、前記ユーザ機器の合法的傍受に関する要求を受信した場合に、前記第１のサポートノードは、確立されたダイレクト・トンネル接続をキャンセルするようになっており、結果的にユーザトラヒックデータ並びに信号処理データの両者は、その後、前記第１のサポートノードへアドレス指定されることを特徴とする請求項２５から３０のいずれか１項に記載の装置。
32. 前記第１のサポートノードは、制御手段から課金関連情報を受信する場合、前記課金関連情報を知らせるメッセージを第２のサポートノードへ送信するようになっていることを特徴とする請求項２３から３１のいずれか１項に記載の装置。
33. 前記課金関連情報は、データ量閾値であることを特徴とする請求項３２に記載の方法。
34. 前記メッセージは、生成ＰＤＰコンテキスト要求、更新ＰＤＰコンテキスト要求、又は更新閾値要求であることを特徴とする請求項２３から３３のいずれか１項に記載の装置。
35. 前記第１のサポートノードから前記メッセージを受信した後に、前記第２のサポートノードは、データ量等の課金関連パラメータを監視し、前記第１のサポートノードへ監視した前記データ量等の課金関連情報を返送するようになっていることを特徴とする請求項２３から３４のいずれか１項に記載の装置。
36. 前記課金関連情報又は課金関連パラメータは、データ量通知要求メッセージ内に返送されることを特徴とする請求項３２から３５のいずれか１項に記載の装置。
37. 前記課金関連情報はデータ量通知応答メッセージによって肯定応答されることを特徴とする請求項３２から３６のいずれか１項に記載の装置。
38. 前記制御手段は、サービス制御ポイントであることを特徴とする請求項２５から３７のいずれか１項に記載の装置。
39. 前記第１のサポートノードは、前記第２のサポートノードに１回だけデータ量レポートを送信することを要求するようになっていることを特徴とする請求項２３から３８のいずれか１項に記載の装置。
40. 前記第１のサポートノードは、前記第２のサポートノードに、制御手段から受信した課金関連情報に基づいて所定のデータ量に達する度にデータ量レポートを送信することを要求するようになっていることを特徴とする請求項２３から３８のいずれか１項に記載の装置。
41. 前記第２のサポートノードは、前記第１のサポートノードから要求があると、データ量レポートを送信するようになっていることを特徴とする請求項２３から４０のいずれか１項に記載の装置。
42. 前記第２のサポートノードは、応答メッセージ内に表示を付加することによって、データ量レポート処理のサポートに関する表示を与えるようになっていることを特徴とする請求項２３から４１のいずれか１項に記載の装置。
43. 前記第２のサポートノードは、別のノード又は手段によるデータ量制限セットに基づいて、データ量レポート処理を行うようになっていることを特徴とする請求項２３から４２のいずれか１項に記載の装置。

Images