(57)【特許請求の範囲】
【請求項１】
あるネットワークにおける２つのサービス機器要素を結ぶデータ経路上に配置された複数のサービス機器要素を設定する方法であって、前記ネットワークが複数の管理サーバを含んでおり、各管理サーバがそれぞれに異なる複数のサービス機器要素の設定を担当しており、前記２つのサービス機器要素は、発呼者が直接接続している第１のネットワーク・アクセス・サーバと、被発呼者が直接接続している第２のネットワーク・アクセス・サーバとであり、
前記データ経路に沿ってトライアル・バルーン・メッセージを送信するステップであって、前記トライアル・バルーン・メッセージは、前記データ経路上に配置された複数のサービス機器要素の設定を開始するためのものであり、前記トライアル・バルーン・メッセージは、発呼者と被発呼者との間のセッションに関連する情報と、そのセッションにおけるサービスに関連する情報とを含み、前記トライアル・バルーン・メッセージは、前記データ経路上のあるサービス機器要素によって受信されるとその受信したサービス機器要素を対応する管理サーバにコンタクトさせるとともに、前記受信したサービス機器要素によって前記データ経路上にある次のサービス機器要素に転送されるものである、ステップを含んでおり、
前記管理サーバは、該管理サーバのそれぞれのサービス機器要素によってコンタクトされるとそれに応えて、前記管理サーバで受信されたコンテクスト情報に従って前記サービス機器要素を設定するものであり、
前記サービス機器要素は、メータリング機能を有しており、
前記サービス機器要素は、前記管理サーバにより設定されることによって、サービス品質がサービス品質保証契約（ＳＬＡ）を順守しているかどうかに関して前記サービス品質を前記データ経路上でモニタするために使用することができるメータリング機能を実行することができるようになっており、
前記トライアル・バルーン・メッセージは、前記トライアル・バルーン・メッセージを識別するホップ・バイ・ホップ・オプション・ヘッダを含み、前記第１及び第２のネットワーク・アクセス・サーバは、前記ホップ・バイ・ホップ・オプション・ヘッダを有するメッセージが移動端末から来ている場合には、該ホップ・バイ・ホップ・オプション・ヘッダを有するメッセージをブロックするものである、サービス機器要素を設定する方法。
【請求項２】
前記サービス機器要素がそれらのそれぞれの管理サーバに前記トライアル・バルーン・メッセージを転送するステップと、
前記管理サーバの１つが監査及び／または課金プロセスに参加することを決めた場合において、前記管理サーバが、発呼者がそこで当該ネットワークに接続されているネットワーク接続サーバを管理するサーバであるマネージング管理サーバへ、インフォーム・マネージング・アドミニストレーション・サーバ・メッセージを転送するステップと、
前記インフォーム・マネージング・アドミニストレーション・サーバ・メッセージに応えて、前記マネージング管理サーバがコンテクスト情報を伝達するためのコンテクスト・トランスファー・メッセージを前記参加を決めた管理サーバへ送信して、前記管理サーバが前記コンテクスト情報によって示されている監査及び／または課金要件に従って前記サービス機器要素を設定することができるようにする、ステップと
を更に含む請求項１に記載のサービス機器要素を設定する方法。
【請求項３】
前記トライアル・バルーン・メッセージに対する確認応答メッセージが前記第２のネットワーク・アクセス・サーバから所定の期間内に前記第１のネットワーク・アクセス・サーバに返信されない場合には、前記第１のネットワーク・アクセス・サーバが前記トライアル・バルーン・メッセージを再送する、請求項１または２に記載のサービス機器要素を設定する方法。
【請求項４】
設定されるべきサービス機器要素は、発呼者と送信先との間もしくは発呼者と被発呼者との間で進行するセッションの監査及び／または課金に参加しており、
前記トライアル・バルーン・メッセージは、前記発呼者が接続する前記ネットワーク・アクセス・サーバによって発信され、前記サービス機器要素が参加すべき監査及び／または課金セッションのセッションＩＤを含むものである、請求項１乃至３のいずれか１項に記載のサービス機器要素を設定する方法。
【請求項５】
前記トライアル・バルーン・メッセージの発信は、前記発呼者が接続する前記ネットワーク・アクセス・サーバの前記マネージング管理サーバから前記ネットワーク・アクセス・サーバへ発送されたセンド・トライアル・バルーン・トリガリング・メッセージに応えて実行される、請求項４に記載のサービス機器要素を設定する方法。
【請求項６】
前記トライアル・バルーン・メッセージは、ユーザが移動端末からサービスを要求し且つ／又は別のユーザへの接続をセットアップするときに、前記ネットワーク・アクセス・サーバによって生成される、請求項１乃至５のいずれか１項に記載のサービス機器要素を設定する方法。
【請求項７】
発呼者と被発呼者とを結ぶデータ経路上に配置された複数のサービス機器要素を含むネットワーク内に配置されているネットワーク・アクセス・サーバ装置であって、該ネットワーク・アクセス・サーバ装置は、発呼者あるいは被発呼者に直接接続しているものであり、
前記データ経路に沿ってトライアル・バルーン・メッセージを送信する送信ユニットであって、前記トライアル・バルーン・メッセージは、前記データ経路上に配置された複数のサービス機器要素の設定を開始するためのものであり、前記トライアル・バルーン・メッセージは、発呼者と被発呼者との間のセッションに関連する情報と、そのセッションにおけるサービスに関連する情報とを含み、前記トライアル・バルーン・メッセージは、前記データ経路上のあるサービス機器要素によって受信されるとその受信したサービス機器要素を対応する管理サーバにコンタクトさせるとともに、前記受信したサービス機器要素によって前記データ経路上にある次のサービス機器要素に転送されるものである、送信ユニットを具備し、
前記トライアル・バルーン・メッセージは、前記トライアル・バルーン・メッセージを識別するホップ・バイ・ホップ・オプション・ヘッダを含み、当該ネットワーク・アクセス・サーバ装置は、前記ホップ・バイ・ホップ・オプション・ヘッダを有するメッセージが移動端末から来ている場合には、該ホップ・バイ・ホップ・オプション・ヘッダを有するメッセージをブロックするものである、
ネットワーク・アクセス・サーバ装置。
【請求項８】
前記トライアル・バルーン・メッセージに対する確認応答メッセージが被発呼者側のネットワーク・アクセス・サーバ装置から所定の期間内に当該ネットワーク・アクセス・サーバ装置に返信されない場合には、前記トライアル・バルーン・メッセージを再送する手段を具備するものである請求項７に記載のネットワーク・アクセス・サーバ装置。
【請求項９】
設定されるべきサービス機器要素は、発呼者と送信先との間もしくは発呼者と被発呼者との間で進行するセッションの監査及び／または課金に参加しており、
前記トライアル・バルーン・メッセージは、前記発呼者が接続する前記ネットワーク・アクセス・サーバによって発信され、前記サービス機器要素が参加すべき監査及び／または課金セッションのセッションＩＤを含むものである、請求項７又は８に記載のネットワーク・アクセス・サーバ装置。
【請求項１０】
前記トライアル・バルーン・メッセージの発信は、前記発呼者が接続する前記ネットワーク・アクセス・サーバの前記マネージング管理サーバから前記ネットワーク・アクセス・サーバへ発送されたセンド・トライアル・バルーン・トリガリング・メッセージに応えて実行される、請求項７乃至９のいずれか一項に記載のネットワーク・アクセス・サーバ装置。
【請求項１１】
コンピュータ上で実行させる際に請求項１乃至６のいずれか１項に記載された方法を実行させるためのコンピュータ実行可能コードを含むコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークにおけるサービス機器を設定する方法及び装置に関する。
【背景技術】
【０００２】
現在、移動体無線ネットワークが広く普及している。これらはグローバルな複数のプロバイダ環境において運営管理される必要がある。このことは、複数の移動体ネットワーク・オペレータが含まれ、移動ユーザが異なる通信路を利用し、しかしその一方でオペレータが保障されたサービス課金のほかにサービス品質を監査するための基準もまだ必要としている環境を生んでいる。
【０００３】
移動体無線データ通信の分野では、一定レベルのＱｏＳ（Quality-of-Service）が保障されることが約束されている必要がある。斯かる保障が仮に技術的に可能であっても、ネットワークの稼働には、アンテナの間欠的エラーまたは故障の可能性がつきまとう。このため、商用サービスに対しては、現在提供中のサービス品質が、サービス品質保証契約（ＳＬＡ：Service Level Agreement）における、通常は法的に縛られた、事前の取り決めに従っているかどうかを、プロバイダ及びユーザが検証することを可能にする測定とモニタリングの仕組みが求められている。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
斯かる検証は、使用されるデータ経路に沿って行われる必要があるとともに、そのデータ経路に配置され、サービスがＳＬＡに従って提供されているかどうかを検証することが可能になるように１つ以上のサービス・パラメータ（例えば帯域幅、データレートなど）を測定することが可能なサービス機器（service equipment）を含む必要がある。サービス・プロビジョニングがＳＬＡを順守しているかどうかを調べる斯かる検査は、監査（auditing）と呼ばれている。このため、監査（auditing）及び課金（accounting）が、最小の労力で実施でき、含まれる最小数のネットワーク運営コンポーネントで実施できるように、事前にデータ経路を決定する必要性があり、さらにそのデータ経路において任意のサービス機器を設定する必要性がある。こうしたことは、例えば、サービス機器に対して、測定または監視すべきサービス・パラメータのタイプ（例えばデータレート）について通知するために、また、監査が実行される場合には測定されたパラメータがＳＬＡに従っているかどうかをサービス機器がチェックすることができるようにするためにＳＬＡの詳細について通知するために必要である。
【課題を解決するための手段】
【０００５】
上記課題を解決するため、本発明は、あるネットワークにおける２つのサービス機器要素（service equipment elements）を結ぶデータ経路に沿って配置された複数のサービス機器要素を設定する方法を提供しており、前記ネットワークが、複数の管理サーバ（administration server）を含み、各管理サーバがそれぞれに異なる複数のサービス機器要素の設定を担当するものであり、本方法は、
前記データ経路に沿ってトライアル・バルーン・メッセージを送信するステップであって、前記トライアル・バルーン・メッセージは、前記データ経路上のあるサービス機器要素によって受信されるとその受信したサービス機器要素をその対応する管理サーバにコンタクトさせるとともに、前記受信したサービス機器要素によって前記データ経路内にある次のサービス機器要素に転送されるものである、ステップを含んでおり、
前記管理サーバは、該管理サーバのそれぞれのサービス機器要素によってコンタクトされるとそれに応えて、前記サービス機器要素を経由して前記管理サーバが受信したコンテクスト情報に従って前記サービス機器要素を設定するものである、方法。
【０００６】
本発明のメカニズムは、データ経路に沿って伝送される一種のプローブ（probe）であって、そのデータ経路に沿ったサービス機器要素の自動化された設定の実行を開始する“トライアル・バルーン（trial-balloon）”を利用する。これは、データ経路に固有なコンテクスト情報に従って実行することができ、それにより、サービス機器要素の動作を要件に従って分散的かつ適応的なやり方で設定することができる。
【０００７】
本方法において、その一態様として、前記サービス機器要素は、メータリング（metering）機能を有しており、前記管理サーバによる前記サービス機器要素の設定は、サービス品質がサービス品質保証契約（ＳＬＡ：Service Level Agreement）を順守しているかどうかに関してそのサービス品質を前記データ経路上でモニタするために使用することができるメータリングを前記サービス機器要素が実行することができるように、前記サービス機器要素を設定することを含んでいる。
【０００８】
本方法は、その一態様として、前記サービス機器要素がそれらのそれぞれの管理サーバに前記トライアル・バルーン・メッセージを転送するステップと、
前記管理サーバの１つが監査及び／または課金プロセスに参加することを決めた場合において、その管理サーバが、発呼者（caller）がそこで当該ネットワークに接続されているネットワーク接続サーバ（network attachment server）を管理するサーバであるマネージング管理サーバ（managing administration server）へ、inform-managing-administration-serverメッセージを転送するステップと、
前記 inform-managing-administration-serverメッセージに応えて、前記マネージング管理サーバがコンテクスト情報を前記参加を決めた管理サーバへ送信して、前記管理サーバがそのコンテクスト情報によって示されている監査及び／または課金要件に従って前記サービス機器を設定することができるようにするステップとを更に含む。
【０００９】
このマネージング管理サーバの情報により、課金及び監査プロセスに加わりたいと思っているあるいは加わることができる任意の追加のサービス機器要素を通知することが可能となる。さらに、それにより、マネージング管理サーバは、必要なコンテクスト情報を（前記プロセスへの参加を決めた）管理サーバへ送信してそれを受け取った管理サーバがその対応するサービス機器要素をＳＬＡに従って設定することが可能になる。
【００１０】
本方法において、その一態様として、前記トライアル・バルーン・メッセージに対する回答が所定の期間内に送信者に返信されない場合においては、そのトライアル・バルーン・メッセージは再送される。これは最初の送信で起こりえる任意のエラーを補償する。
【００１１】
本方法において、その一態様として、各トライアル・バルーン・メッセージはそのトライアル・バルーン・メッセージを識別するホップ・バイ・ホップ・オプション・ヘッダ（hop-by-hop options header）を含み、各ネットワーク・アクセス・サーバ（network access server）は、このホップ・バイ・ホップ・オプション・ヘッダを有するメッセージが移動端末から来ている場合には、このホップ・バイ・ホップ・オプション・ヘッダを有するメッセージをブロックする。これは、トライアル・バルーン・メッセージを生成する移動ノードによって実行され得る攻撃を防止することができる。
【００１２】
本方法において、その一態様として、設定されるべきサービス機器要素は、発呼者（caller）と送信先との間、もしくは発呼者と被発呼者（callee）との間で進行するセッションの監査及び／または課金に参加しており、
前記トライアル・バルーン・メッセージは、前記発呼者が接続する前記ネットワーク・アクセス・サーバによって発信され、前記サービス機器要素が参加すべき監査及び／または課金セッションのセッションＩＤを含んでいる。
【００１３】
このメカニズムは特に、発呼者とその送信先（被発呼者または任意のサービス・プロバイダまたは他の通信相手）との間の通信セッションに適用され得る。発呼者のＮＡＳによるトライアル・バルーン・メッセージの発信は好ましい。なぜなら、この発呼者のＮＡＳは通信路における、移動端末より後の、最初のノードであるからである。さらに、その発呼者のＮＡＳは、トライアル・バルーン・メッセージの生成及び処理をネットワーク内部にそしてマネージング管理サーバの制御下に保持するようマネージング管理サーバによってトリガーされることが可能であり、それによりその発呼者のＮＡＳを攻撃に用いることが困難となる。
【００１４】
本方法において、その一態様として、前記トライアル・バルーン・メッセージの発信は、発呼者が接続する前記ネットワーク・アクセス・サーバの前記マネージング管理サーバから前記ネットワーク・アクセス・サーバへ発送されたsend-trial-balloonコマンドに応えて実行される。これはマネージング管理サーバにトライアル・バルーン・メカニズムの制御を与える。それと同時に、各管理サーバはそれが発呼者に対するマネージング管理サーバである場合においてはマネージング管理サーバとして機能することができるため、トライアル・バルーン・メカニズムはなお分散型である。
【００１５】
本発明は、あるネットワークにおける２つのサービス機器要素を結ぶデータ経路上に配置された複数のサービス機器要素を設定する装置であって、前記ネットワークが複数の管理サーバを含み、各管理サーバがそれぞれに異なる複数のサービス機器要素の設定を担当するものである、装置も提供する。本装置は、
前記データ経路に沿ってトライアル・バルーン・メッセージを送信する送信ユニットであって、前記トライアル・バルーン・メッセージは、前記データ経路上のあるサービス機器要素によって受信されるとその受信したサービス機器要素をその対応する管理サーバにコンタクトさせ、前記トライアル・バルーン・メッセージは更に、その受信したサービス機器要素によって前記データ経路上にある次のサービス機器要素に転送されるものである、送信ユニットを具備し、
前記管理サーバは、該管理サーバのそれぞれのサービス機器要素によってコンタクトされるとそれに応えて、前記管理サーバで受信されたコンテクスト情報に従って前記サービス機器要素を設定するように適合される。
【００１６】
斯かる装置は本発明を実施するのに適した形態である。
【００１７】
本発明は、あるネットワークにおける２つのサービス機器要素を結ぶデータ経路上に配置されたサービス機器要素（サービス機器要素装置）を提供する。前記ネットワークは複数の管理サーバを含み、各管理サーバがそれぞれに異なる複数のサービス機器要素の設定を担当し、本装置は、
トライアル・バルーン・メッセージを受信する受信ユニットと、
前記トライアル・バルーン・メッセージを当該サービス機器要素から次のサービス機器要素へ前記データ経路に沿って転送する送信ユニットとを具備し、
本装置は、前記トライアル・バルーン・メッセージを受信するとそれに応えて自分の対応する管理サーバにコンタクトするよう構成されており、
本装置は更に、前記管理サーバが当該サービス機器要素によってコンタクトされるとそれに応えて、前記管理サーバによって受信されたコンテクスト情報に従って前記管理サーバによって設定されるように適合されている。
【００１８】
本発明は、２つのサービス機器要素を結ぶデータ経路上に配置された複数のサービス機器要素を含むネットワーク内に配置された管理サーバ装置であって、該管理サーバ装置は１つ以上のサービス機器要素の設定を担当するものである、管理サーバ装置を提供する。本装置は、
トライアル・バルーン・メッセージを前記サービス機器要素が受信したらそれに応えて、前記サービス機器要素の１つ以上からコンタクト・メッセージ（contacting message）を受信する受信ユニットであって、前記トライアル・バルーン・メッセージは、前記データ経路上のあるサービス機器要素によって受信されるとその受信したサービス機器要素をその対応する管理サーバにコンタクトさせ、前記トライアル・バルーン・メッセージは更に、その受信したサービス機器要素によって前記データ経路上にある次のサービス機器要素に転送されるものである、受信ユニットと、
前記受信ユニットが前記コンタクト・メッセージによってそれぞれの前記サービス機器要素によってコンタクトされたらそれに応えて、当該管理サーバで受信されたコンテクスト情報に従って前記サービス機器要素を設定するように適合された設定ユニット（configuration unit）とを具備する。
【００１９】
上記いずれかの装置において、その一態様として、前記サービス機器要素は、メータリング機能を有しており、前記管理サーバによる前記サービス機器要素の設定は、サービス品質がサービス品質保証契約（ＳＬＡ）を順守しているかどうかに関してそのサービス品質を前記データ経路上でモニタするために使用することができるメータリングを前記サービス機器要素が実行することができるように、前記サービス機器要素を設定することを含んでいる。
【００２０】
上記いずれかの装置は、その一態様として、
前記管理サーバの１つが監査及び／または課金プロセスに参加することを決めた場合において、その管理サーバが、発呼者がそこで当該ネットワークに接続されているネットワーク接続サーバを管理するサーバであるマネージング管理サーバへ、inform-managing-administration-serverメッセージを転送するトライアル・バルーン・メッセージ手段と、
前記inform-managing-administration-serverメッセージに応えて、前記マネージング管理サーバが前記管理サーバへコンテクスト情報を送信して、その参加を決めた管理サーバがそのコンテクスト情報によって示されている監査及び／または課金要件に従って前記サービス機器を設定することができるようにする手段とを更に具備する。
【００２１】
本発明は、コンピュータ上で実行した際に上記いずれかの態様にある方法を実行させるためのコンピュータ実行可能コードを含むコンピュータ・プログラムを提供する。
【００２２】
一態様として、メッセージのデータ経路内に配置されるとともにＱｏＳ対応サービスの課金及び監査のサポートに必要とされる情報の適切な測定を保証するためのメータリング機能を有する、ルータ及びメータ（routers and meters）などのサービス機器要素の自動設定が実行され得る。本メカニズムは、送信元デバイスから送信先デバイスまでのデータ経路を決めるために適用可能である。それと同時に、データ経路上にある一般的なルータ及びメータといった全ての測定ポイントのほかにそれらのそれぞれのマネージングＡ４Ｃ（Authentication、Authorisation、Accounting、Auditing and Charging）といった管理サーバも適切な課金及び監査の測定を設定するために選択される。本方法は、異なる管理ドメインに配置され得る斯かる測定ポイントの自動設定もサポートする。
【００２３】
本方法は、その一態様として、ダイアメータ（Diameter）ベースのプロトコルに対して定義された拡張に基づいており、ダイアメータベースのプロトコルは追加的に新しく定義された属性値ペアとそれらの分散利用とを含んでいる。この場合、本メカニズムは、データの分配に対して基礎となるプロトコル・アルゴリズム（Diameterメッセージ転送）を利用する。これは十分に分散したやり方で適用可能であり、全ての参加者（例えば、ローカル・ドメインと遠隔ドメインとにおける管理サーバあるいはＡ４Ｃサーバ、さらに、選択されたデータ経路上にあるルータ及びメータ）の間の通信及びメッセージ交換に対して規定される情報の特別な属性値ペアを指定する。
【００２４】
一態様として、前記トライアル・バルーン・メッセージは、ユーザがその移動端末からサービスを要求し且つ別のユーザへの接続をセットアップするときに、ネットワーク・アクセス・サーバによって生成される。トライアル・バルーン・メッセージを転送するとき、そのメッセージは、ルータ及びメータ（routers and meters）によってインターセプトされ、ルータ及びメータは、そのメッセージのコピーをそれらの管理サーバ（例えばマネージング４ＡＣ）に転送するだけでなくコピーを送信先へのデータ経路上にある次のルータ及びメータに転送する。Ａ４Ｃサーバは課金及び監査プロセスに参加し、ルータ及びメータをそれぞれ設定する。
【００２５】
本発明の上記態様のメカニズムは、セッション指向の課金及び監査に利用可能な技術である。
１．本プロセスは、収集データをセッションと相互に関連付けることを可能にする。
２．そのおかげでオペレータは、全てのセッションについてのデータを収集するのとは対照的に以下を決定することが可能になる。
ａ）より多数のセッションに対して課金及び監査をサポートすること、または、
ｂ）よりシンプルで、従ってより安価なハードウェアを利用すること、または、
ｃ）正確で価値のある、詳細な課金及び監査データを提供すること
【発明を実施するための最良の形態】
【００２６】
課金と、より重要なことに監査は、送信元モバイル機器から送信先モバイル機器までのデータ経路上にあるネットワーク装置で実行されているタスクである。ネットワーク装置はルータ及び他のパケット転送装置である。斯かる装置が課金及び監査タスクをサポートする場合には、この装置はメータと呼ばれる。これから説明する実施形態は移動体ネットワーク・オペレータのための課金及び監査のサポートに使用することができるが、そのプロセスは固定ネットワーク・オペレータにも等しく適用することができる。さらに、その方法は、複数の送信先モバイル機器への複数のデータ経路が考慮される必要があるマルチキャスト通信にも適用することができる。
【００２７】
ここで、以下の説明の全体を通して使用される専門用語と定義とを記載する。
【００２８】
Ａ４Ｃサーバ：これらはサービス機器要素（service equipment elements）を担当する管理サーバである。このＡ４Ｃサーバは、オペレータ・ドメイン内及び間のサービス・セッションにおける、ユーザ認証（Authentication）と、認可（Authorisation）と、課金（Accounting）と、監査（Auditing）と、（支払い）請求（Charging）とを担当している４ＡＣサーバ（認証、認可、課金、監査、および請求サーバ）の形態をとり得る。しかしながら、以下の記載の焦点は、課金及び監査機能、特に監査機能及びそれらの基礎となるメータリング機能に置かれている。
【００２９】
Ａ４Ｃサーバは、通信の課金プロセスにおいて階層を形成し得る。この階層はオペレータ間の相互作用をより容易な方法でサポートするのに役立つ。つまり、オペレータは、ある特定のサーバ（つまりゲートウェイ）を定義して、他のオペレータまたはあるオペレータのセットへのインタフェースを形成することができ、これによりドメイン間通信に対する設定（configuration）の労力を軽減することができる。
【００３０】
Ａ４Ｃサーバの役割：Ａ４Ｃサーバは、課金及び監査プロセスにおける責務に応じて３つの異なる役割を有することができる。ホーム・オペレータ（ＨＯ）のドメイン内にあるＡ４Ｃサーバは、ユーザがネットワークに最初に接続する際にユーザ認証とユーザ認可とを実行し、課金プロセスと監査プロセスとを調整する。このＡ４Ｃサーバは、ＨＯにおけるサーバ（server at HO）と呼ばれる。このサーバはサービス・セッション全体を通して変わることはない。
【００３１】
ユーザの移動端末が現在そこでネットワークに接続しているネットワーク・アクセス・サーバ（ＮＡＳ：Network Access Server）を担当するＡ４Ｃサーバは、マネージングＡ４Ｃサーバ（またはマネージング管理サーバもしくは単にマネージング・サーバ）と呼ばれる。マネージング・サーバは、ユーザがある１つのＮＡＳから別のＮＡＳに移れば変更される。マネージング・サーバの役割は、管理労力をユーザの現在位置の近くに保って、信号伝達を減らしスケーラビリティを改善することにある。
【００３２】
第３の役割として、遠隔Ａ４Ｃサーバと呼ばれ、課金及び監査プロセスに参加するが現在のマネージング・サーバ以外のＡ４Ｃサーバに付随し、設定される必要があるサービス機器要素（ＳＥ：Service equipment element）を管理するＡ４Ｃサーバを参照する。
【００３３】
サービス機器要素（ＳＥ：Service equipment elements）は、ネットワークにおいて異なる種類のサービスを提供する。それらの一部はサービス・プロビジョニングに能動的に参加し、ユーザはそれらの存在、例えばウェブサーバを認識する。他のＳＥはユーザには直接見えないが、それでもサービス・プロビジョニング・プロセス、例えばルータ、トラフィック・メータ及びネットワーク・アクセス・サーバＮＡＳ（ここで移動端末が識別され、ネットワーク・アクセスが許可される接続（attachment）ポイント）になお必要とされる。
【００３４】
本発明の実施形態によれば、メータであるＳＥは、課金及び監査に参加するため特に重要である。後でより詳しく説明するトライアル・バルーン・プロセスの目的は、送信元移動端末から送信先移動端末へのデータ経路上のメータを識別することにある。メータが一旦識別されたならば、次に課金及び監査のためにこれらのメータの設定が行われ得る。
【００３５】
ダイアメータ・コマンド（Diameter command）：ダイアメータ・プロトコル（Diameter protocol）は、非特許文献１に定義されている。このプロトコルは、ダイアメータピア（Diameter peers）（つまりＡ４ＣサーバまたはＳＥ）によって開始される多数のコマンドを定義する。コマンドは常に、要求及び回答ペア（Request and Answer pairs）として定義される。コマンドは、属性値ペア（attribute-value-pairs）として定義されたパラメータを運ぶ。
【非特許文献１】Calhoun, P.; Loughney, J.; Guttman, E.; Zorn, G. and Arkko, J.,"RFC 3855-Diameter Base Protocol", 2003
【００３６】
属性値ペア（ＡＶＰ：Attribute-Value-Pair）：ダイアメータ・プロトコルは、ヘッダとそれに続く１つ以上のＡＶＰとから成る。各ＡＶＰは、ヘッダを含み、プロトコルに固有なデータのほかに、認証、認可または課金及び監査情報をカプセル化する。
【００３７】
・Ａ４Ｃ（Authentication, Authorisation, Accounting, Auditing, and Charging）：認証、認可、課金、監査及び請求
・ＦＯ（Foreign Operator）：フォーリン・オペレータ
・ＨＯ（Home Operator）：ホーム・オペレータ
・Ａ４Ｃ（Authentication, Authorisation, Accounting, Auditing, and Charging）：認証、認可、課金、監査及び請求
・ＮＡＳ（Network Access Server）：ネットワーク・アクセス・サーバ
・Ｒ＋Ｍ（Router with metering capability）：メータリング機能付きルータ
・ＱｏＳ（Quality-of-Service）：サービス品質
・ＳＬＡ（Service Level Agreement）：サービス品質保証契約
【００３８】
本発明の実施形態の動作を詳細に説明する前に、本発明の実施形態が利用できる環境について説明する。
【００３９】
図１にユーザＡの移動端末からユーザＢの移動端末までのデータ経路を示す。このデータ経路は第１の移動体ネットワーク・オペレータ（ＭＮＯ：mobile network operator）Ａと、第２の移動体ネットワーク（ＭＮＯ：mobile network operator）Ｂと、それらの間に位置する中継オペレータ（transit operator）とにおけるそれぞれのカバレッジ・エリアに沿って延びる。ユーザＡとユーザＢとの間の接続は、図１に同じく示された付加価値サービス・プロバイダ（value-added services provider）によって提供されるサービスを更に含むことができる。
【００４０】
接続が以前にＳＬＡで同意した一定のサービス品質を維持すべき場合においては、サービス品質はモニタされるべきである。斯かるモニタリング・プロセスは“監査”と呼ぶこともできる。この監査を実行するには、データ経路に沿った通信のパラメータ（例えばスループットまたはデータレート、場合によっては他のパラメータも）を測定することが必要である。
【００４１】
次に図２を参照して、斯かる監査を実行することができる設定についてより詳しく説明する。ユーザＡは、図の左側に示されたネットワーク・アタッチメント・サーバＮＡＳを通じて移動体ネットワーク（ＭＮＯ）Ａに接続する。一方、ユーザＢは、図の右側に示された別のネットワーク・アタッチメント・サーバＮＡＳを通じて移動体ネットワーク（ＭＮＯ）Ｂに接続する。両方のユーザを結ぶデータ経路は、いくつかのＲ＋Ｍを経由する。これらのＲ＋Ｍは、ルーティング機能に加えてデータレートなどのパラメータをＲ＋Ｍが測定することができるようにするメータリング機能を有するルータである。斯かる測定は、特にあるセッションに対して、メータが適宜に設定されている場合に実行することができる。図２には示されてはいないが、データ経路に沿って、ルーティング機能は持たないがメータリング機能だけを持つ追加のメータが更に配置され得る。簡潔に示しているため、図２では中継オペレータは示されていないが、場合によっては、１つ以上の中継オペレータが含まれ得る。
【００４２】
ルータ及びメータ（Ｒ＋Ｍ）は、それぞれの異なる管理サーバによって管理及び設定される。管理サーバは、図２の実施形態においてはいわゆるＡ４Ｃ（authentication, authorization, accounting, auditing and charging）サーバである。各Ａ４Ｃサーバは、複数のルータ及びメータ（Ｒ＋Ｍ）を担当するが、それに対し各ルータ及びメータは、それを担当しその設定を実行するただ１つの管理サーバ（Ａ４Ｃサーバ）を有する。図２からわかるように、Ａ４Ｃサーバは、相互に通信し得る。斯かる相互通信は、ネットワーク・ドメイン内において、特にフォーリンドメイン（foreign domain）が含まれる場合において課金を実行するために必要な場合がある。
【００４３】
ユーザＡからユーザＢへのデータ経路に沿った接続がＳＬＡを順守しているかどうかをチェックすることを可能にする適切なメータリングを実行するために、ルータ及びメータは設定される必要がある。これはトライアル・バルーン・プロセスと呼ばれる後述する本発明の実施形態による方法によって遂行される。トライアル・バルーン・プロセスという呼称は、データ経路に沿ってトライアル・バルーンのように進む“トライアル・バルーン（trial-balloon）”と呼ばれるメッセージに由来する。トライアル・バルーン（メッセージ）はその伝達経路に沿って、測定とまではいかなくとも、測定または測定の設定、すなわちルータ及びメータの設定を開始する動作を少なくとも実行する。このように、トライアル・バルーンは、データ経路に沿って置かれた特定タイプのサービス機器要素であるルータ及びメータの設定の開始をトリガーするために最初に発信される一種の“プローブ（probe）”である。
【００４４】
図３には、トライアル・バルーン・メッセージが利用される、２つのドメインＡ及びＢが相互接続された状況にあるネットワーク構成が概略的に示されている。ドメインＡのネットワーク構成は、３つのＮＡＳと、３つのルータ及びメータ（Ｒ＋Ｍ）と、１つのルータ（Ｒ）と、２つのＡ４Ｃサーバとから成る。データベースは、ユーザデータと、ＳＬＡ（一般に複数）と、課金及び監査の設定データなどとを保持している。Ａ４Ｃサーバは、ＮＡＳと、Ａ４Ｃサーバが管理しているルータ及びメータ（Ｒ＋Ｍ）とリンクしており、Ａ４Ｃサーバは、例えば課金及び監査プロセスを設定し、課金及び監査の記録を収集するといったことなどに利用される。本実施形態におけるトライアル・バルーン・メッセージは、移動端末を管理するＮＡＳから発し、データ経路（点線）に沿って転送される。トライアル・バルーン・メッセージを受け渡された第１のルータ及びメータ（Ｒ＋Ｍ）は、捕捉したトライアル・バルーン・メッセージについてそのマネージングＡ４Ｃサーバへ通知するメッセージ＃１（Trial-Balloon-Captured-Requestと呼ばれるメッセージ）を生成する。メッセージ＃１を受け取るＡ４Ｃサーバ、本ケースでは移動端末を管理するＮＡＳを管理するマネージングＡ４Ｃサーバは、Ｒ＋Ｍを設定するためのＳＥ設定要求（SE-Configure-Request）をできる限りデータ経路上の第２のＲ＋Ｍにも発行する。本ケースにおいて、第２のＲ＋Ｍは、そのＡ４Ｃサーバにもう何も通知する必要はなく、第３のＲ＋Ｍへトライアル・バルーン・メッセージを受け渡すだけである。その他のケースにおいては、Trial-Balloon-Captured-Requestは、第２のＲ＋ＭからもそのＡ４Ｃサーバへ送信され、そのＡ４Ｃサーバは続いて第２のＲ＋Ｍを設定する。
【００４５】
トライアル・バルーン・メッセージがデータ経路上の第３のＲ＋Ｍに到達する場合には、第３のＲ＋Ｍは、図３に示すようにその対応するＡ４Ｃサーバ（図３ではドメインＡ内の第２のＡ４Ｃサーバ）へ通知するためのメッセージ＃２（trial-balloon captured message）を生成し、そのメッセージ＃２をその対応するＡ４Ｃサーバへ送信する。受信メッセージに含まれる移動端末のＩＰアドレスに基づいて、（メッセージ＃２を受信した）Ａ４Ｃサーバは、どのＡ４Ｃサーバがどの範囲のＩＰアドレスを管理しているかについての情報を含むレルム（領域）ベースのルーティング・テーブル（Realm Based Routing table）をチェックする。このルーティング・テーブルに基づいて、メッセージ＃２を受信したＡ４Ｃサーバは、第１のＡ４Ｃサーバがユーザ端末／送信元モバイル機器を管理していることを判断し、メッセージ＃２を受信したＡ４Ｃサーバは、第１のＡ４Ｃサーバのセッション定義テーブル（Session Definitions table）に第２のＡ４ＣサーバのＩＰアドレスを含むエントリを付け加える第１のＡ４Ｃサーバに向けたメッセージを生成する。このようにして、Ａ４Ｃサーバは互いに通信し合うことができる。
【００４６】
別のドメインにおける手続き（メッセージ＃３参照）は、Ａ４Ｃサーバ（遠隔のマネージングＡ４Ｃサーバ）が互いに直接通信し合うことが許されない場合があることを除いて、メッセージ＃２に対する手続きと等しい。
【００４７】
トライアル・バルーン・プロセス、すなわち関連するＡ４Ｃサーバとメータとの間の一連のコマンドを図４に概略的に示す。送信元モバイル機器から送信先モバイル機器へ向かうデータ経路に沿っていわゆるトライアル・バルーン・メッセージが送信される。実施の一形態において、このトライアル・バルーン・メッセージは、そのマネージングＡ４Ｃサーバのリクエストに応じて、送信元モバイル機器のネットワーク接続点（図４における発呼側のＮＡＳ（NAS caller））によって生成され、このトライアル・バルーン・メッセージは、送信先モバイル機器のネットワーク接続点（図４における被発呼側のＮＡＳ（NAS callee））（ここでそれは削除され、trial-balloon answerが返信される）に到達するまでデータ経路に沿って前方へ次のＳＥ（つまり図４におけるＲ＋Ｍ）に受け渡される。セッション中にデータ経路が変わる場合、トライアル・バルーン・プロセスはメータを新しく確立されたデータ経路上で設定するためにリスタートされる必要がある。
【００４８】
送信先へ向かう経路上において、ルータ及びメータ（Ｒ＋Ｍ）といった各サービス機器要素ＳＥは、図４に示すようにトライアル・バルーン・メッセージを転送する前にトライアル・バルーンのローカルコピーを作成する。このローカルコピーは後述するＳＥ（図４におけるＲ＋Ｍ）のほかにＡ４Ｃサーバが更なる意志決定を行うために使用することができる。実施の一形態によれば、ＳＥ及びＡ４Ｃサーバが課金及び監査プロセスに参加する場合において、trial-balloon captured messageを受信したＡ４Ｃサーバは、特定のコマンド、すなわちInform-Managing-Server-Requestコマンド（図４参照）を、トライアル・バルーン・プロセスを開始したマネージングＡ４Ｃサーバへ返信する。そのマネージング・サーバのアドレスは、Inform-Managing-Server-Requestをそのマネージング・サーバへ直接送ることができるようにするために、トライアル・バルーン・メッセージのペイロード（payload）に格納され得る。
【００４９】
これに応えて、トライアル・バルーン・プロセスを開始したマネージングＡ４ＣサーバはInform-Managing-Server-Requestの受信を確認し、（Context-Transfer-Requestコマンドを送信することによって）Inform-Managing-Server-Requestを送ったＡ４Ｃサーバへの設定データ（configuration data）の転送を開始する。受信した設定データを用いて、Ａ４Ｃサーバはユーザデータ・トラフィックの課金及び監査に対してＳＥの設定を開始する。
【００５０】
図４には示されていない実施の更なる一形態によれば、Ａ４ＣサーバはＳＥによってtrial-balloon captured requestを通じて通知されたらすぐにそのＳＥを設定する。この設定は、ＳＬＡに従って実行できるようにＳＬＡの詳細を規定するコンテクスト・データに基づく。このコンテクスト・データは、実施の一形態によれば、すでにトライアル・バルーン・メッセージに含まれている場合がある。実施の更なる一形態によれば、ＳＥは、例えば、トライアル・バルーン・メッセージを受信してそれをＡ４Ｃサーバへ転送するときにマネージングＡ４Ｃサーバあるいはデータベースからコンテクスト・データを取得する場合がある。
【００５１】
図５には、ルータ及びメータ（Ｒ＋Ｍ）として示されたＳＥにおけるトライアル・バルーン・メッセージの転送が概略的に示されている。また図５は、トライアル・バルーン・メッセージに含まれる情報（trial-balloon-request（TBR））も示している。このＴＢＲは、実施の一形態によれば、Session-ID（セッションＩＤ）と、Origin-NAS-IP-pool（ＮＡＳのマネージング・サーバが管理するアドレスのプール）と、Origin-Realm/Domainと、Service-Definition（接続に含まれるサービスの定義）と、Accounting-Application-Id（課金アプリケーションＩＤ）と、Accounting-Application-Id（監査アプリケーションＩＤ）とを含むことができる。課金及び監査に関係のある通信パラメータは、セッションとともに指定され得る。ＴＢＲは、被発呼側ＮＡＳ（callee ＮＡＳ）に到達するまで各Ｒ＋Ｍによって変更されずそのまま転送される。被発呼側ＮＡＳからは被発呼側（callee）及び送信先のレルム（領域）にあるＮＡＳのマネージング・サーバのNAS-IP-pool（図ではDestination-NAS-IP-pool）を含み得るtrial-balloon-answerが返信される。このNAS-IP-poolを用いて、クライアントＩＰアドレスベースのメッセージ・ルーティングが実行できる。発呼側ＮＡＳ（caller ＮＡＳ）及び被発呼側ＮＡＳ（callee ＮＡＳ）のマネージングＡ４Ｃサーバの送信元アドレスまたは送信先アドレスの代わりに、クライアントＩＰアドレスが送信可能である。これらの情報は、属性値ペア（ＡＶＰ：attribute value pairs）として送信することができる。trial-balloon-requestまたはtrial-balloon-answerまたはinform-managing-server-requestといったメッセージは、NAS-IP-poolを調べてクライアントＩＰアドレスがそれに属し、メッセージをそれに転送するＮＡＳを特定することによって、その経路を見つけることができる。そのＮＡＳにおいて、メッセージは担当のマネージング・サーバに転送され得る。クライアントＩＰアドレスに基づくこのルーティングは、クライアントＩＰアドレスベースのメッセージ・ルーティング（client IP address based message routing）と呼ばれる。それに関するより包括的な説明は本願と同じ出願者によって本願と同日に出願された特許出願明細書「Method and Apparatus for hiding Network Topology」を参照されたい。なお、この参照によってその特許文書の開示内容は本願に含まれるものとする。
【００５２】
次に本発明の実施の一形態によるトライアル・バルーン・プロセスの開始について説明する。
【００５３】
トライアル・バルーン・プロセスは、Ａ４ＣサーバがSend-Trial-Balloon AVP（address value pair）が設定されたSE-Configure-Request（図６におけるコマンド１）を生成することによって開始される。SE-Configure-Requestは、送信元モバイル機器が接続するＳＥ（ここではＮＡＳcaller）に送信される。ＳＥ（ＮＡＳcaller）はTrial-Balloon-Requestを生成し、そのTrial-Balloon-Requestを送信先モバイル機器に送信する。ＳＥ（ＮＡＳcaller）はSE-Configure-Answer（図６におけるコマンド２）を返信し、トライアル・バルーンのリクエストの処理を確認する、あるいはトライアル・バルーンが成功しなかった場合にはそれぞれのエラーを確認する。
【００５４】
実施の一形態によれば、トライアル・バルーン・プロセスで使用されるメッセージはDiameterプロトコルに基づくアドレス値ペア（address value pairs）である。ダイアメータ・プロトコル（Diameter protocol）については例えば、非特許文献２を参照されたい。これはラディアス・プロトコル（RADIUS protocol）の後継で、認証、認可及び課金用に開発された。以下の説明では、ダイアメータ・プロトコルに基づくトライアル・バルーン・プロセスを引き合いに出すことがあるが、当業者であれば、同じメカニズムが他のプロトコルに基づいて行われ得ることは明らかであろう。
【非特許文献２】Calhoun, P.; Loughney, J.; Guttman, E.; Zorn, G. and Arkko, J.,"RFC 3855 - Diameter Base Protocol", 2003
【００５５】
実施の一形態によるSend-Trial-Balloon AVPは、アドレスタイプ（Address type）であり、送信先モバイル機器のＩＰアドレスを保持する。実施の一形態におけるトライアル・バルーン・メッセージはＵＤＰパケットに入れられ、ＵＤＰパケットはＩＰパケットに入れられる。このＩＰパケットにおいてＩＰアドレスはSend-Trial-Balloon AVPから引き出される。トライアル・バルーン・メッセージの送信元ＩＰアドレスは、ＳＥ（図４におけるＮＡＳ caller）に接続する送信元モバイル機器のＩＰアドレスである。
【００５６】
ルータ及びメータ（図４におけるＲ＋Ｍ）は、全ての通過データ・トラフィックを走査してトライアル・バルーン・メッセージを探す。斯かるメッセージが受信された場合にはこのメッセージを転送する前にローカルコピーが作成される。Ｒ＋Ｍは、コピーされたトライアル・バルーン・メッセージのペイロードを解析し、（例えば、オプションではあるが、Ｒ＋Ｍが保持するトポロジー・データに基づいて）もう何のアクションも必要がないことがはっきりわかれば、Ｒ＋Ｍはパケットのローカルコピーを破棄する。しかしながら、全ての他のケースでは、トライアル・バルーン・メッセージは、Trial-Balloon-Capsule AVPにカプセル化され、図７に示すように、Ａ４Ｃサーバに送られるTrial-Balloon-Captured-Requestに含まれる。トライアル・バルーン・メッセージのペイロードは、すでにダイアメータに準拠しており単にTrial-Balloon-Capsule AVPのコンテンツと見なすことができるので、トライアル・バルーン・プロセスがダイアメータ・プロトコルに基づく場合のカプセル化は直接的（straightforward）である。
【００５７】
Trial-Balloon-Captured-Requestを受信するＡ４Ｃサーバは、その受信したRequestを解析し直し、課金及び監査プロセスに参加するかどうかを最終的に決める。実施の一形態によるこの二重の判断プロセスは、Ｒ＋Ｍがそのシンプルな構成のデータベースのせいで全てのケースで決定できないことから必要とされる。従って、実施の一形態において、それはファーストレベルのフィルタリングのみを実行することができる。Ａ４Ｃサーバは即座にTrial-Balloon-Captured-AnswerをＲ＋Ｍへ返信する。この結果、Ｒ＋Ｍは、Ａ４Ｃサーバで受信されたRequestが処理されていることを知る。次にＡ４Ｃサーバはトライアル・バルーン・メッセージの処理を開始する。
【００５８】
メータはTrial-Balloon-Captured-Answerが受信された後はトライアル・バルーン・メッセージに関するいかなる状態も保存することを要しない。それは実施の一形態によれば再送を認識するために、（Origin-NAS-IP-Pool（または送信元アドレス），End-To-End Identifier）タプルのリストを保持する。これらのタプルは再送が識別できるようにトライアル・バルーン・メッセージの一部である場合があり、従って、すでに受信かつ処理されたトライアル・バルーン・メッセージは無視される。メータが斯かる高々一度の動作を実行しない場合において、実施の一形態によれば少なくともＡ４Ｃサーバはそれをサポートする必要がある。実施の一形態によれば、トライアル・バルーン・メッセージの全ての参照は最初のトライアル・バルーン・メッセージが受信されてからリトライ時間（Retry-Time）ミリ秒の時間期間後に安全に破棄される。
【００５９】
Ａ４ＣサーバはTrial-Balloon-Captured-Requestを受信した後、このリクエストに含まれるTrial-Balloon-Capsule AVPと、特に、実施の一形態としてそこに含まれるSession-Container AVPを解析する。それらはセッションについての情報、つまりセッションＩＤだけでなくリクエストされたサービス及びＳＬＡ及びサービス・プロビジョニングの要件、例えば要求されるデータレート、についての情報を含むことができる。
【００６０】
Ａ４Ｃサーバがローカル設定（例えば、それに割り当てられたＲ＋Ｍの能力及び負荷）に基づいて監査プロセスに参加することを決める場合には、Ａ４Ｃサーバは、図８に概略的に示すようにInform-Managing-Server-Requestを生成する。図８にはＡＶＰの形でこのコマンドに含められる情報、例えば、Session-ID（セッションＩＤ）と、Origin-A4C-IP（メッセージがそこから発信されるＡ４ＣサーバのＩＰアドレス）と、Origin-A4C-realm/domain（送信元のＡ４Ｃのレルム／ドメイン）と、Inform-Action（とるべきアクションについての情報）と、Destination-NAS-IP-Pool（送信先のマネージング・サーバが管理するアドレスのプール）あるいはこのIP-Poolがトライアル・バルーン・メッセージに含まれている場合にはそのアドレスと、Destination-realm/domain（送信先のマネージング・サーバのレルム／ドメイン）とが示されている。
【００６１】
図８においてアクションについての情報は、AVP Inform-Actionで示されている。Ａ４Ｃサーバが参加する場合のInform-Actionは、例えば、REMOTE-A4C-JOINに設定され得る。（プロセスに参加することを決めた）Ａ４Ｃサーバは、このリクエスト（Inform-Managing-Server-Request）をマネージングＡ４Ｃサーバに送ってマネージングＡ４Ｃサーバにそれが監査に参加しようとしていることを通知する。アドレス情報は、Trial-Balloon-Capsule AVPに含まれるOrigin-NAS-IP-Pool AVPとOrigin-Realm AVPとから得られる。メッセージは、マネージングＡ４Ｃサーバへルーティングされ、そのサーバからInform-Managing-Server-Answerが返信される。マネージングＡ４Ｃサーバは、まだContext-Transfer-RequestコマンドがTrial-Balloon-Requestに含まれていない場合においては、次にリクエストされた課金及び監査の設定をContext-Transfer-Requestコマンドで送る。Context-Transfer-RequestはInform-Managing-Server-Requestに対する応答であるので、マネージングＡ４ＣサーバはＡ４Ｃプロセスに参加する全てのＡ４Ｃサーバを管理するという役割を保持し、設定データのコピーを遠隔のＡ４Ｃサーバに送信するだけである。
【００６２】
マネージングＡ４Ｃサーバから設定データを受信した後、遠隔のＡ４Ｃサーバは、トライアル・バルーン・メッセージを捕捉したＲ＋ＭへSE-Configuration-Requestを発行する。SE-Configuration-Requestを受信したＲ＋Ｍは、SE-Configuration-Requestに含まれる課金及び監査の定義が要求するように自身を設定する。次にＲ＋Ｍは、SE-Configuration-AnswerをＡ４Ｃサーバへ返信して設定の変更を通知する。
【００６３】
実施の一形態によれば、トライアル・バルーン・メッセージに対するanswerがｔTrial-Blloon-Timeoutミリ秒のタイムアウト期間内に送信者に返信されない場合、ＳＥはトライアル・バルーン・メッセージを再送する。リトライ回数（retry-count）ｎretry-Trial-Balloonsは、ＳＥがトライアル・バルーン・メッセージを有限回数だけ再送するように定義される。リトライ回数メッセージが回答されなかった場合、ＳＥはＡ４Ｃサーバにエラー・メッセージを返信する。
【００６４】
セキュリティの理由から実施の一形態によれば次のような問題が考慮される。
・メッセージはネットワーク内部を明らかにしてはならない。
・ユーザはトライアル・バルーン・メッセージを生成し、送信することによってネットワークを攻撃する可能性がある。
【００６５】
最初の問題に対する対処法としては、送信ＳＥ（すなわちNAS caller）は、それ自身のＩＰアドレスを使用せず、監査セッション（to-be-audited sessions）を開始した接続ユーザの移動端末のアドレスを使用すればよい。
【００６６】
接続されている移動端末のＩＰアドレスが使用されるために、ユーザは、これらのメッセージを自分で生成することにより、トライアル・バルーン・プロセスを悪用することができないことが保証されるはずである。このような種類の攻撃は実施の一形態によれば、全てのトライアル・バルーン・メッセージをＩＰｖ６拡張ヘッダでラベルすることによって回避することが可能である。ＩＰｖ６の記述については、非特許文献３を参照されたい。
【非特許文献３】Deering, S. and Hinden R., "RFC 2460-Internet Protocol, Version 6 (IM)", 1998
【００６７】
その目的のため、非特許文献４に記載されているメカニズムを利用することができる。このメカニズムは、ＩＰデータグラム（IP datagram）のコンテンツを調べるように中継ルータ（transit routers）に注意を喚起するための手段を規定する。ＩＰｖ６パケット・ヘッダは、非常にシンプルで、パケット転送に絶対に必要なフィールドだけを提供する。このおかげでルータにおいてパケットの効率的な処理ができるようになる。追加の情報、例えば暗号化、認証、ソースルーティングまたは上位プロトコル（ＴＣＰ、ＵＤＰ及びＩＣＭＰ）のヘッダはいわゆる拡張ヘッダに格納され、それらは基本ＩＰｖ６パケット・ヘッダによって参照される。中継ルータは、これらの拡張ヘッダの１つであるホップ・バイ・ホップ・オプション・ヘッダ（Hop-by-hop Options header）を処理するだけでよい。このヘッダは、可変数のＴＬＶ（type-length-value）符号化オプションから成る。これらのオプションは、どのパケットがあらゆるルータで処理されるかを記述する。ＲＦＣ２７１１は、ホップ・バイ・ホップ・オプション・ヘッダのオプションタイプを定義しており、このホップ・バイ・ホップ・オプション・ヘッダは、あらゆるデータグラムを調べる必要なく、ルータがそれらにアドレス指定されていないデータグラムをインターセプトするための有効なメカニズムを提供する。オプションタイプ０００００１０１2は、２オクテット値（two octet value）を必要とし、それはデータグラムのペイロードのタイプを示す。この値フィールドの数字はＩＡＮＡが保有する。
【非特許文献４】Partridge, C and Jackson, A.,"RFC 2711-IPv6 Router Alert Option", October 1999
【００６８】
トライアル・バルーン・メッセージは、パケットを調べるように中継ルータに注意を喚起するためにこのメカニズムを利用する。トライアル・バルーン・メッセージを含むあらゆるパケットは、オプションタイプ０００００１０１2とトライアル・バルーン・メッセージを示す値とを備えるホップ・バイ・ホップ・オプション・ヘッダを有することが要求される。この値の数字は、実施の一形態によれば、リクエストされるとともに、アイアナＩＡＮＡ（Internet Assigned Numbers Authority IANA、www.iana.org参照）によって割り当てられる必要がある。各ＮＡＳは、移動端末からのオプションタイプ０００００１０１2のＩＰｖ６ホップ・バイ・ホップ・オプション・ヘッダを含むパケットをブロックし、ＩＣＭＰパラメータプロブレムとコード２とメッセージとを、パケットの送信元アドレスへ返信する役割を担う。ネットワーク・オペレータは、そのネットワークを保護するためにどうにかしてこのヘッダをフィルタリングするので、ホップバイホップオプションは追加の処理オーバヘッドを起こすことはない。
【００６９】
トライアル・バルーン・プロセスをサポートするために使用されるコマンドがダイアメータ・プロトコルに基づいているような実施形態について、以下により詳細に説明する。以下に、トライアル・バルーン・プロセスで使用されているコマンドとＡＶＰ（commands and AVPs）とをまとめる。ダイアメータ仕様書にまだ記述されていないがトライアル・バルーン・メカニズムを実施する上で特有なコマンド及びＡＶＰについて主に記述する。
【００７０】
これらのコマンド及びＡＶＰを記述するため、ダイアメータ・プロトコルへの全ての拡張に対してＲＦＣ３８５５で必要とされるＡＢＮＦ構文が使用される。ＡＢＮＦの記述については、非特許文献５が参照可能である。ダイアメータ・プロトコルによれば、各コマンドはRequestとそれに対応するanswerメッセージとから成る。
【非特許文献５】Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997, and section 3.2. of RFC3855
【００７１】
実施の一形態によれば、各コマンド及びＡＶＰは、ＩＡＮＡが保有する固有のコマンドごとのＡＶＰコードが割り当てられる。コマンド及びＡＶＰの以下の記述において、コードはまだ割り当てられていないときはＴＢＤ（to be determined）と表記される。
【００７２】
SE-Configure-Request/-Answer
SE-Configure-Request及びSE-Configure-Answerのペアは、新しく定義されたコマンドである。このコマンドはＡ４Ｃサーバによってそれに関連するＳＥ（例えば、添付図面ではNAS caller）へ送信される。SE-Configure-Requestコマンドは、ＳＥに課金及び監査に必要とされる情報の収集を指令するためにＡ４Ｃサーバによって送信される。
【００７３】
実施の一形態によれば、重要なＡＶＰはSend-Trial-Balloon AVPである。これはSE-Configuration-Container AVPに埋め込まれる。SE-Configuration-Container AVPはConfiguration-Definition AVPを含み、Configuration-Definition AVPはDefinition-Parameter AVPを含み、Definition-Parameter AVPは最後にSend-Trial-Balloon AVPを含む。これらのＡＶＰの詳細な定義は以下の通りである。
【００７４】
SE-Configure-Request(SCR)コマンドのフォーマットは次の通りである。
<SC-Request>::=<Diameter Header:TBD, REQ, PXY>
<Session-Id>
[Origin-Host]
[Origin-Realm]
[Destination-Realm]
[SE-Configuration-Cmd-Type]
1*[SE-Configuration-Container]
[Destination-Host]
[Destination-NAS-IP-Pool]
*[Proxy-Info]
*[Route-Record]
*[AVP]
【００７５】
SE-Configure-Answer(SCA)コマンドのフォーマットは次の通りである。
<SC-Answer>::=<Diameter Header:TBD, PXY>
<Session-Id>
[Result-Code]
[Origin-Host]
[Origin-Realm]
[Origin-State-Id]
[Error-Message]
[Error-Reporting-Host]
*[Failed-AVP]
*[Proxy-Info]
*[AVP]
【００７６】
Inform-Managing-Server-Request/-Answer
Inform-Managing-Server-Requestコマンドは、トライアル・バルーン・プロセスによって発見されたＡ４Ｃサーバによって送信される。このコマンドは、マネージングＡ４Ｃサーバに対して別のＡ４Ｃサーバが課金または監査プロセスに参加していることを通知するために使用される。
【００７７】
Inform-Managing-Server-Request(IMR)コマンドのフォーマットは次の通りである。
<IM-Request>::=<Diameter Header: TBD, REQ, PXY>
<Session-Id>
[Origin-Host]
[Origin-Realm]
[Destination-Realm]
[Destination-NAS-IP-Pool]
[Inform-Action]
[Parent-Session-Id]
*[Session-Container]
[Destination-Host]
[Origin-State-Id]
*[Proxy-Info]
*[Route-Record]
*[AVP]
【００７８】
Inform-Managing-Server-Answer(IMA)コマンドのフォーマットは次のように定義される。
<IM-Answer>::=<Diameter Header: TBD, PXY>
<Session-Id>
[Result-Code]
[Origin-Host]
[Origin-Realm]
[Origin-State-Id]
[Error-Message]
[Error-Reporting-Host]
*[Failed-AVP]
*[Proxy-Info]
*[AVP]
【００７９】
Context-Transfer-Request/-Answer
Context-Transfer-Requestコマンドは、マネージングＡ４Ｃサーバによって、トライアル・バルーン・メカニズムによる発見後に設定される必要があるＡ４Ｃサーバへ送信される。このコマンドは、必要とされる課金及び監査データを新しいＡ４Ｃサーバへ送信するために使用される。
【００８０】
Context-Transfer-Request(CTR)コマンドは次の通りである。
<CT-Request>::=<Diameter Header: TBD, REQ, PXY>
<Session-Id>
<Parent-Session-Id>
[Origin-Host]
[Origin-Realm]
[Destination-Realm]
*[Service-Configuration-Container]
[SLA-Id]
[Destination-Host]
[Origin-State-Id]
*[Proxy-Info]
*[Route-Record]
*[AVP]
【００８１】
Context-Transfer-Answer(CTA)コマンドは、このRequestを送信したＡ４Ｃサーバへの確認応答である。Context-Transfer-Answer(CTA)コマンドのフォーマットは次の通りである。
<CT-Answer>::=<Diameter Header: TBD, PXY>
<Session-Id>
[Result-Code]
[Origin-Host]
[Origin-Realm]
[Origin-State-Id]
[Error-Message]
[Error-Reporting-Host]
*[Failed-AVP]
*[Proxy-Info]
*[AVP]
【００８２】
Trial-Balloon-Request/-Answer
Trial-Balloon-Request(TBR)コマンド及びTrial-Balloon-Answer(TBA)コマンドはすでに述べた。Trial-Balloon-Requestコマンドは、Ａ４Ｃサーバのリクエストに応えてＮＡＳによって生成され、接続の他端にある移動端末のＩＰアドレスに向けてＵＤＰによって送信される。それは開始されるべき課金及び監査セッションのセッションＩＤを含む。このコマンドは発信ＮＡＳの実際のアドレスを含む必要はない。内部のネットワーク構造を開示しないため、受信者（addressee）として移動端末のＩＰアドレスをOrigin-NAS-IP-Pool AVPに含ませることが可能である。以前すでに述べたセキュリティの理由から、発信ＮＡＳは、移動端末のＩＰアドレスをコマンドのソースＩＰとして使用し得る。
【００８３】
Origin-Realmには、このメッセージを生成する領域名が設定される。Origin-NAS-IP-Pool AVPと一緒になって、そのOrigin-Realmは、その返ってくる経路（way back）を見つけるためにanswerのためのアドレスを形成する。これは、ＮＡＳが担当するＩＰアドレスのプールである。
【００８４】
代わりに、ＴＢＲはＮＡＳのアドレスを直に含み得る。あるいは別の実施形態では、ＮＡＳを管理するマネージングＡ４ＣサーバのＩＰアドレスを追加的もしくは代替的に含み得る。
【００８５】
Retry-Time AVPは、ｔTrial-Balloon-Timeoutとｎretry-Trial-Balloonsとの積を含む。このＡＶＰは、メータ（meters）とＡ４Ｃサーバ（servers）とに、再送は最悪の場合どの程度待たないといけないか、それらがこのトライアル・バルーン・メッセージについての全ての情報をキャッシュから一斉消去できる最も早い時点はいつかといった、ヒントを与える。
【００８６】
Acct-Application-Idと、Audit-Application-Idと、Vendor-Specific-Application-Id AVP（Session-Container grouped AVPにカプセル化される）とは、このリクエストを解釈するために必要なアプリケーションの識別子を含む。メータが全てのアプリケーションをサポートしない場合、Ａ４Ｃサーバがそれらのアプリケーションをサポートしていることがあるので、メータはそのＡ４Ｃサーバにそのリクエストを転送する。
【００８７】
ＴＢＡのＡＶＰはＴＢＲのものに類似している。
<TB-Request>::=<Diameter Header: TBD, REQ>
[Parent-Session-Id]
[Origin-NAS-IP-Pool]
[Origin-Realm]
1*[Session-Container]
[Retry-Time]
<TB-Answer>::=<Diameter Header: TBD>
[Parent-Session-Id]
[Origin-NAS-IP-Pool]
[Origin-Realm]
1*[Session-Container]
[Destination-Realm]
[Destination-NAS-IP-Pool]
【００８８】
Trial-Balloon-Capture-Request/-Answer
Trial-Balloon-Captured-Requestコマンドは、ＳＥによってこのＳＥを担当するＡ４Ｃサーバへ送信され、そのＡ４Ｃサーバにトライアル・バルーン・メッセージを受信したことを通知する。Trial-Balloon-Capsule AVPは、トライアル・バルーン・メッセージを含んでいる。
【００８９】
Trial-Balloon-Captured-Request(TCR)コマンドのフォーマットは次の通りである。
<TC-Request>::=<Diameter Header: TBD, REQ>
<Session-Id>
[Origin-Host]
[Origin-Realm]
[Destination-Realm]
[Trial-Balloon-Capsule]
[Destination-Host]
[Origin-State-Id]
*[AVP]
【００９０】
Trial-Balloon-Captured-Answer (TCA)は、先ほどのＡ４Ｃサーバから発信元（originating）ＳＥへ返信される。このコマンドのフォーマットは次のように定義される。
<TC-Answer>::=<Diameter Header: TBD>
<Session-Id>
[Result-Code]
[Origin-Host]
[Origin-Realm]
[Origin-State-Id]
[Error-Message]
[Error-Reporting-Host]
*[Failed-AVP]
*[AVP]
【００９１】
上で導入されたコマンドはＲＦＣ３８５５に定義された属性値ペア（AVP：attribute-value-pairs）から構築される。トライアル・バルーン・プロセスに特有なＡＶＰについて次に議論する。それらのＡＶＰはアルファベット順に記載される。
【００９２】
Audit-Application-Id AVP
Audit-Application-Id AVPは、Unsigned32タイプであり、アプリケーションの監査部分のサポートを広告するために使用される。Audit-Application-Idは、全ての監査メッセージに存在する。それはAcct-Application-Id AVPと同様に定義される。
【００９３】
Configuration-Definition AVP
Configuration-Definition AVPは、groupedタイプであり、課金及び監査がどのように行われるかの詳細な情報を含む。その定義は、Ｉｄと、タイプと、パラメータとを含む。Definition-Type AVPは、その設定が課金に対するものなのか監査に対するものなのかを指定する。Definition-Parameter AVPは、課金及び監査に特有の設定データを定義する。加えて、Acct-Application-Id AVPとAudit-Application-Id AVPとVendor-Specific-Application-Id AVPは、その定義を解釈するために必要とされるアプリケーションを指定する。
<Configuration-Definition>::=<AVP Header: TBD>
[Definition-Id]
[Definition-Type]
[Definition-Parameter]
[Acct-Application-Id]
[Audit-Application-Id]
[Vendor-Specific-Application-Id]
【００９４】
Definition-Parameter AVP
Definition-Parameter AVPはgroupedタイプであり、課金及び監査に特有な設定データを含む。以下のリストは定義パラメータのいくつかの例を含む。
[Send-Trial-Balloon]
[Audit-Realtime-Required]
[Audit-Interim-Interval]
[Accounting-Realtime-Required]
[Acct-Interim-Interval]
[Acct-Session-Time]
[Accounting-Input-Octets]
[Accounting-Input-Packets]
[Accounting-Output-Octets]
[Accounting-Output-Packets]
【００９５】
Inform-Action AVP
Inform-Action AVPは列挙（enumerated）タイプであり、マネージングＡ４ＣサーバがInform-Managing-A4C-Requestを受信した際に実行すべきアクションを含む。
・TRANSER-COMPLETE-CONTEXT：Ａ４Ｃサーバは、移動端末の完全なコンテクストを送信し、全てのＳＥから設定（configurations）を取り除き、コンテクストをローカルに広告するものとする。
・REMOTE-A4C-JOIN：遠隔のＡ４Ｃサーバが課金及び監査プロセスに参加を望んでいる。マネージングＡ４Ｃサーバは、ＳＬＡのそれぞれの部分を送信し、遠隔Ａ４Ｃサーバのリストへ発信サーバ（sending server）を加えるものとする。
【００９６】
Origin-NAS-IP-Pool AVP
Origin-NAS-IP-Pool AVPはAddressタイプである。ダイアメータピアは、それ自身のアドレスを指定したくなければこのＡＶＰを送信者のアドレスとして含むことができる。
【００９７】
SE-Configuration-Container AVP
SE-Configuration-Container AVPは、groupedタイプであり、ＳＥにおいて課金及び監査をセットアップするために必要とされる全ての設定情報を含む。このＡＶＰは、ＳＥに送信されるSE-Configure-Requestコマンドに含まれる。containerは、Session-IdとParent-Session-Id AVPとによって指定される１セッションに対する設定を定義する。その結果として、SE-configuration-Requestコマンドは、SE-Configuration-Container AVPを幾度も含むことができる。Service-Id AVPのおかげでＳＥは設定データをユーザがリクエストしたサービスに対応付けることができるようになる。これは、サービス・プロビジョニング以外にジョイント・メータリング機能を含むＳＥにおいて、課金及び監査の設定をより容易にすることができる。この場合、ＩＰフローの仕様はもはや使用できなくなる。Configuration-Definition AVPは、課金及び監査に特有の設定データを含む。Flow-Filter AVPは、課金及び監査でモニタされるＩＰフローを指定する。Idle-Timeout AVPは、セッションが終了する前にユーザに許容されるアイドル接続の最大連続秒数を設定する。
<SE-Configuration-Container>::=<AVP Header:TBD>
<Session-Id>
<Parent-Session-Id>
[Service-Id]
*[Configuration-Definition]
*[Flow-Filter]
[Idle-Timeout]
【００９８】
Send-Trial-Balloon
Send-Trial-BalloonはAddressタイプである。このＡＶＰがSE-Configure-Requestに含まれる場合、受信ダイアメータ・クライアント（Diameter client）は、トライアル・バルーン・メッセージを所定のアドレスに送信することを要求される。
【００９９】
Session-Container AVP
Session-Container AVPは、groupedタイプであり、Session-IdとParent-Session-IdとService-Id AVPとによる実行中のセッションの記述を含む。Acct-Application-Id、Audit-Application-Id及びVendor-Specific-Application-Id AVPは、所定のセッションをサポートするために必要とされるダイアメータ・アプリケーションを指定する。
<Session-Container>::=<AVP Header:TBD>
[Acct-Application-Id]
[Audit-Application-Id]
[Vendor-Specific-Application-Id]
[Parent-Session-Id]
[Session-Id]
[Service-Id]
【０１００】
Trial-Balloon-Capsule AVP
Trial-Balloon-Capsule AVPは、groupedタイプであり、トライアル・バルーン・メッセージをカプセル化する。Parent-Session-Id AVPは、セッションのルート・セッション識別子ＳＩＤを含む。
<Trial-Balloon-Capsule>::=<AVP Header:TBD>
[Parent-Session-Id]
[Origin-NAS-IP-Pool]
[Origin-Realm]
1*[Session-Container]
【０１０１】
Vendor-Specific-Application-Id AVP
Vendor-Specific-Application-Id AVPは、groupedタイプであり、ベンダーに特有のダイアメータ・アプリケーションのサポートを広告するために使用される。それはAudit-Application-Id AVPによって拡張される。
<Vendor-Specific-Application-Id>::=<AVP Header:TBD>
1*[Vendor-Id]
0*1[Auth-Application-Id]
0*1[Acct-Application-Id]
【０１０２】
これまで本発明を例示的な実施形態を使って説明してきた。しかし当業者であれば、本発明の範囲を逸脱することなくこれらの実施形態に修正または変更を加えることができることは理解されよう。
【０１０３】
例えば、パケットは、送信元から送信先まで経路が送信先から送信元までの経路とは異なる非対称経路を利用することが可能である。従って、トライアル・バルーン・プロセスは逆方向の経路（送信先から送信元までの経路）にも適用可能である。この場合の手続きは送信先の接続ポイントであるネットワーク・アクセス・サーバに近い管理サーバによって開始されること以外は同じである。
【０１０４】
さらに、上記実施形態では各メッセージはrequest/answerの形を採るが、この場合のanswerはrequestが受信されたことを確認するために送信される。これにとらわれず確認応答が要求されない他のメッセージング・スキームも適用され得る。
【０１０５】
当業者であれば、上記実施形態は、コンピュータ・ハードウェア、コンピュータ・ソフトウェア、またはそれらの組み合わせで実施できることは理解されよう。特に、上記実施形態の述べた特定の機能を実行する機器要素またはモジュールは適切にプログラムされたコンピュータまたはソフトウェア・モジュールを通じて実施され得る。
【図面の簡単な説明】
【０１０６】
【図１】本発明の実施の一形態の概略構成図である。
【図２】本発明の実施の一形態によるネットワーク構成の概略図である。
【図３】本発明の実施の一形態による更なるネットワーク構成とメッセージの流れを示す図である。
【図４】本発明の実施の一形態によるトライアル・バルーン・プロセスのシーケンス図である。
【図５】本発明の実施の一形態によるトライアル・バルーン・メッセージの転送の様子を示す図である。
【図６】本発明の実施の一形態によるトライアル・バルーン・プロセスの具体例を示す図である。
【図７】本発明の実施の一形態によるTrial-Balloon-Capture-Request/-Answerコマンドを説明するための図である。
【図８】本発明の実施の一形態によるInform-Managing-Server-Requestコマンドを説明するための図である。
【符号の説明】
【０１０７】
Ａ４Ｃ  Ａ４Ｃ（認証、認可、監査、課金及び請求）サーバ
ＭＮＯ  移動体ネットワーク・オペレータ
ＮＡＳ  ネットワーク・アクセス・サーバ
Ｒ＋Ｍ  ルータ及びメータ
【図３】
0004463838.tif 000002
【図４】
0004463838.tif 000003
【図１】
0004463838.tif 000004
【図２】
0004463838.tif 000005
【図５】
0004463838.tif 000006
【図６】
0004463838.tif 000007
【図７】
0004463838.tif 000008
【図８】
0004463838.tif 000009