JP2010541361A - データベース、並びにかかるデータベースを用いてｉｍｓネットワークにおけるサービス品質及び課金管理エンティティのアドレスを得るための方法 - Google Patents

Abstract

ＩＭＳネットワークにおけるアクセス可能なデータベース（５１、５２）であって、該データベースは、
・ トランスポート・プレーンにおける端末（１０）の識別子；
・ シグナリング・プレーンにおける前記端末（１０）の識別子；及び
・ 前記ネットワークにおけるサービスの品質及び課金管理エンティティ（４０、４１、４２）の少なくとも１つのアドレス
を含む少なくとも１つのレコードを含む。

Description

本発明の分野は、第三世代のパートナーシップ・プロジェクト（３ＧＰＰ）によって限定されるＩＰマルチメディア・サブシステム（ＩＭＳ）アーキテクチャに順応する遠隔通信ネットワークのものである。

ＩＭＳリリース７は、サービス品質及び課金（チャージング）管理のためのポリシ及びチャージング（課金）・ルール・ファンクション（ＰＣＲＦ）エンティティを限定する。ＩＭＳネットワークにコール（呼出し）がセットアップされるとき、プロキシ・コール・セッション管理ファンクション（Ｐ−ＣＳＣＦ）エンティティは、アプリケーション・セッションに関する情報を通信するためのリクエストをＰＣＲＦに送り、ＰＣＲＦは、引き続き、この情報を用いて、セッションのためのリソースの活性化に関するサービス品質（ＱＯＳ）及び課金（チャージング）の決定を行う。

この観点から、Ｐ−ＣＳＣＦエンティティは、アプリケーション・ファンクション（ＡＦ）のように振舞い、アプリケーション・ファンクションは、この明細書では、また、アプリケーション・エンティティとも称する。

このリクエストの受信時に、ＰＣＲＦは、アプリケーション・セッションが、それらのための一組のポリシ・ルールに影響を与えて限定する送信リンクを識別する。

上述の基準は、リソースの活性中に、トランスポート・プランにおける終端、すなわち、背後で端末がＩＭＳネットワークにアクセスするゲートウェイ（ＵＭＴＳネットワークにおけるゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）、Ｉ−ＷＬＡＮネットワークにおけるパケット・データ・ゲートウェイ（ＰＤＧ）エンティティ）が、セッションをセットアップする時点においてアプリケーション・エンティティＡＦによって交信されるＰＣＲＦを選択するということを仮定している。

この観点から、ゲートウェイは、ＱＯＳ及び課金ポリシを行うポリシ及びチャージング（課金）・インフォースメント・ファンクション（ＰＣＥＦ）のように振舞う。

一層詳細にするために、文献ＴＳ２３．２０３Ｖ７．３．０のセクション６．２．２．１及び６．２．２．３は、それぞれ、ゲートウェイによって及びアプリケーション・エンティティＡＦによって、ＰＣＲＦの選択の方法を特定する：
・ ゲートウェイは、パケット・データ・ネットワーク（ＰＤＮ）と、ユーザのアイデンティティに関する情報、例えば、それらのＩＭＳＩまたはＭＳＩＳＤＮとを用い；そして
・ アプリケーション・エンティティＡＦは、ユーザ端末のＩＰアドレスまたは端末のもう１つの識別子を用いる。

ゲートウェイ及びアプリケーション・エンティティＡＦによって用いられる情報が、同じＰＣＲＦと交信するのが確かであるように、同一であるもしくは良く同期されていることが必要であるということは、当業者には明瞭である。

現在の基準は、このことを保証しない。ある製造者によって構想される解決法は、ユーザ端末のＩＰアドレスをＰＣＲＦ選択規準として用いることである。この解決法は、もし、ゲートウェイによって見られるユーザ端末のＩＰアドレスがアプリケーション・エンティティＡＦによって見られるものと異なっているならば、特に、もし、ネットワーク・アドレスが移動式ＩＰ型の移動性プロトコルの使用によってマスキングされているならば、同じＰＣＲＦを選択することを可能としないので、不満足なものである。

文献ＷＯ ２００７／０９０４６３は、この課題を解決することを目的とした方法を記載している。その方法においては、ゲートウェイは最初にＰＣＲＦを選択し、その後、アプリケーション・ファンクションＡＦが、ユーザ端末に割当てられたＩＰアドレスに基づいて利用可能なＰＣＲＦを選択する。もし、選択されたＰＣＲＦがすでに（そのＩＰアドレスによって識別された）端末に奉仕しているならば、次に、該ＰＣＲＦは、セッションのために用いられる。奉仕していないならば、エラーで選択されたＰＣＲＦは、エラー・メッセージを送り返し、そしてアプリケーション・ファンクションＡＦは、再度端末のＩＰアドレスに基づいてもう１つのＰＣＲＦを選択し、そしてこのプロセスは、それが選択された端末に奉仕するＰＣＲＦであるまで続く。

当該方法は、もし、ゲートウェイ及びアプリケーション・エンティティＡＦによって見られる端末のＩＰアドレスが異なっているならば、アプリケーション・ファンクションＡＦがゲートウェイによって選択されたＰＣＲＦを最終的に選択するであろうということを保証しない。ＰＣＲＦ選択がＩＰアドレスに基づいており、この方法は、ユーザが同じセッション中にＩＰアドレスを変化するという移動性シナリオにおいて、オペレータが同じＰＣＲＦを維持することを追及するという状況をカバーすることができないということが当業者には明瞭である。

最後に、しかし決してどうでもよいことではないが、当該方法は、ゲートウェイによって選択されたＰＣＲＦが選択されるまで、すでに述べたように、アプリケーション・ファンクションＡＦが潜在的なＰＣＲＦを選択することを系統的に試みるという理由で、多くのＰＣＲＦを配備するオペレータ・ネットワークにおいて特に、システムの全体性能に影響を与える欠点を有している。

本発明は、上述の欠点をもたない解決法を提案する。

本発明は、ＩＭＳネットワークにおけるアクセス可能なデータベースであって、
・ トランスポート・プレーンにおける端末の識別子；
・ シグナリング・プレーンにおける前記端末の識別子；及び
・ 前記ネットワークにおけるサービスの品質及び課金管理エンティティの少なくとも１つのアドレス
を含む少なくとも１つのレコードを含むデータベースの使用に基づいている。

ＰＣＲＦエンティティは、本発明の意味において、特に、サービスの品質及び課金管理エンティティを構成する。以下、このようなエンティティをＰＣＲＦエンティティと称し、一層頻繁には、単にＰＣＲＦと称する。

固定アクセス・ネットワークのためのＳＰＤＦエンティティも、本発明の意味において、サービスの品質及び課金管理エンティティを構成する。

本発明の第１の変形例において、データベースは、各ゲートウェイに、かつオペレータのネットワークの各アプリケーション・エンティティＡＦに接続される。

このデータベースのフォーマットに関する制限はない。

同様に、このデータベースに質問するためにゲートウェイ及びＡＦアプリケーション・エンティティによって用いられるプロトコルは、オペレータの選択にまかされる。

この第１の変形例において、ＰＣＲＦエンティティのアドレスは、永久にかまたは一時的にかのいずれかでデータベースに記憶され得る。

データベースは、各ＩＭＳ加入者に対し以下のデータを含む：
・ トランスポート・プレーンにおけるユーザの識別子、例えば、国際移動加入者識別子（ＩＭＳＩ）またはそれらの移動ＩＳＤＮ（ＭＩＳＤＮ）；及び
・ アプリケーション・シグナリング・プレーンにおけるユーザの識別子、例えば、彼等のプライベート（私設）アイデンティティまたはＩＭＳユーザのパブリック（公衆）アイデンティティ。

データベースは、これら２つの識別子を有する端末を管理するＰＣＲＦエンティティのアドレスに関連する。

データベースは、与えられたユーザに対して、任意選択的に、ユーザが加入するアクセスのタイプの関数として、異なったＰＣＲＦアドレスを含み得る。

データベースが、一時的なＰＣＲＦアドレス、すなわち、セッションの期間の間ゲートウェイによって動的に割当てられるアドレス、を含むならば、データベースは、さらに、現在のセッションの識別子を含む。

セッションの識別子は、オペレータが各セッションにおけるＰＣＲＦを選択することを追及する場合には必須であるが、オペレータがすべてのユーザのセッションに対して同じＰＣＲＦを用いる場合には無益である、ということが当業者には明瞭である。

ＰＣＲＦエンティティを記憶することは、複数の長所を有する。

第１に、オペレータは、データベースにそれらのネットワークのＰＣＲＦエンティティの管理を集中させ、このことは、各ゲートウェイ及び各アプリケーション・エンティティＡＦと関連したＰＣＲＦアドレスの局部構成よりも維持するために一層容易である。

永久記憶の状況において、オペレータは、さらに、例えば、ＰＣＲＦごとのユーザの数を平衡させるために新しいＰＣＲＦがネットワークに導入される場合に、ネットワークの種々のＰＣＲＦエンティティに渡ってユーザの配分を改善するために、任意の時刻において、ＰＣＲＦエンティティの割当てを変更することができる。

本発明の第２の変形例において、本発明のデータベースは、オペレータの選択にまかされたプロトコル及びインターフェースを用いてＰＣＲＦエンティティの各々に直接接続される。

このデータベースは、次に、セッションをセットアップする際に交信されるＰＣＲＦと、該セッションのためのリソースをセットアップするために交信されるＰＣＲＦとの間の中継として働く。該データベースは、セッションのための各ＰＣＲＦエンティティのアドレスを含み、該ＰＣＲＦエンティティは、アプリケーション・エンティティＡＦレベル及びゲートウェイ・レベルにおいて独立して選択される。これらの選択は、特に、ランダムに為され得、またはアクセス・タイプを考慮して決定論的に為され得る。

この解決法において、オペレータは、従って、これらのネットワークを柔軟に構成することができ、その理由は、それらが、異なったアクセス・タイプに対して（すなわち、異なったゲートウェイ・タイプに対して）異なったＰＣＲＦエンティティを接続することができるからである。

この第２の変形例において、ＰＣＲＦエンティティは、オペレータのネットワークにおける、すべてのゲートウェイに及びすべてのアプリケーション・ファンクションＡＦに必ずしも接続されない。

この変形例において、データベースは、各ＩＭＳ加入者に対して以下のデータを含む：
・ 永久データ、例えば、それらのＩＭＳＩまたはそれらのＭＳＩＳＤＮ、もしくは、一時的データ、例えば、トランスポート・プレーンにおけるユーザのＩＰアドレス、を構成する、トランスポート・プレーンにおけるユーザの識別子；
・ 永久データ、例えば、ＩＭＳユーザのプライベート・アイデンティティまたはパブリック・アイデンティティ、もしくは、一時的データ、例えば、アプリケーション・シグナリング・プレーンにおけるユーザのＩＰアドレス、を構成する、アプリケーション・シグナリング・プレーンにおけるユーザの識別子；
・ ゲートウェイによって選択されるＰＣＲＦのアドレス；及び
・ アプリケーション・エンティティＡＦによって選択されるＰＣＲＦのアドレス。

これらの２つのアドレスは、セッションの期間の間有効な一時的データを構成する。

データベースは、また、セッションの期間の間も有効な一時的データを構成する、現在のセッションの識別子をも含む。

現在のアプリケーション・セッションのためのサービス情報は、任意選択的にデータベースにも記憶され、アプリケーション・セッションの期間の間有効でもある一時的データを構成する。

この第２の変形例は、トランスポート・プレーンにおけるユーザの識別子及びシグナリング・プレーンにおけるユーザの識別子が異なっている場合に有利である。

本発明のデータベースは、データが静的であり永久的に記憶されると言う理由でか、またはデータが動的であるが同じセッションと関連しているという理由でかのいずれかの理由で、これら２つの識別子を関連させることができる。

双方の変形例は、オペレータが、同じユーザに対し、トランスポート・プレーンにおいて及びアプリケーション・シグナリング・プレーンにおいて異なったＩＰアドレスを用いるという状況において適切である。

それらは、端末がアプリケーション・ファンクションまたはゲートウェイ及びセッション中のＩＰアドレスを変更する場合ですら、特に、移動状況において適切である。

本発明は、また、ＰＣＲＦのアドレスが永久に記憶される場合に、本発明の第１の変形例に用いられ得るゲートウェイ及びアプリケーション・エンティティにも関係する。

このゲートウェイは、ＩＭＳネットワークにおける端末によって送られたトランスポート・レベルにおけるセッションをセットアップするためにリクエストを受信するための手段を含む。それは、
・ トランスポート・プレーンにおける前記端末の識別子を含むリクエストを上で限定されたデータベースに送るための手段；及び
・ 前記リクエストに応答して前記ネットワークにおけるサービスの品質及び課金管理のエンティティのアドレスを得るための手段
を含む。

アプリケーション・エンティティは、ＩＭＳネットワークにおける端末によって送られるシグナリング・プレーンにおけるセッションをセットアップするためにリクエストを受信するための手段を含む。それは、また、
・ シグナリング・プレーンにおける前記端末の識別子を含むリクエストを上で限定されたデータベースに送るための手段；及び
・ 前記リクエストに応答に応答して前記ネットワークにおけるサービスの品質及び課金管理エンティティのアドレスを得るための手段
を含む。

一実施形態においては、ゲートウェイによって及びアプリケーション・エンティティＡＦによって送られる上述のリクエストは、また、端末によって用いられるアクセスのタイプをも示す。

端末を含むセッションのためのＰＣＲＦエンティティのアドレスを得るために、本発明のゲートウェイ及びアプリケーション・エンティティは、それぞれ、トランスポート・プレーンにおける及びシグナリング・プレーンにおける端末の識別子を含むリクエストを、本発明のデータベースに送る。

本発明は、また、ＰＣＲＦのアドレスが一時的に記憶される場合、第１の変形例において用いられ得るゲートウェイ及びアプリケーション・エンティティにも向けられている。

一層詳細には、このゲートウェイは、ＩＭＳネットワークにおける端末によって送られたトランスポート・レベルにおけるセッションをセットアップするためにリクエストを受信するための手段を含む。それは、また、
・ ネットワークにおけるサービスの品質及び課金管理エンティティを選択するための手段；及び
・ 上で限定されたデータベースにリソース活性化メッセージを送るための手段を含み、前記リクエストは、前記エンティティのアドレス、トランスポート・プレーンにおける前記端末の識別子及び前記セッションの識別子を含む。

このように、ゲートウェイは、例えばランダムに、または前記端末によって用いられる前記ネットワークへのアクセスのタイプの関数として、ネットワークにおけるＰＣＲＦを選択し、そして該ＰＣＲＦのアドレスを記憶のためにデータベースに送る。

一実施形態において、このＰＣＲＦのアドレスを得るために、アプリケーション・エンティティは、シグナリング・プレーン及び前記セッションの識別子における前記端末の識別子を含むリクエストをデータベースに送る。データベースは、アプリケーション・エンティティＡＦによってアプリケーション・シグナリング・レベルで受信されたセッション識別子を、ゲートウェイＧＷによってトランスポート・レベルで受信されたセッション識別子と相関させることができる。

本発明の第１の変形例の１つの特定の実施形態においては、ゲートウェイは、また：
リソースを解放するために、メッセージを上で限定したデータベースに送るための手段を含み、リクエストは、トランスポート・プレーンにおける端末の識別子及びセッション識別子を含む。データベースは、次に、端末のためのセッション識別子及びＰＣＲＦのアドレスを削除する。

この実施形態は、ＰＣＲＦのアドレスが一時的に記憶される場合に、特に有利である。

本発明は、また、第２の変形例において用いられ得るサービスの品質及び課金管理エンティティ、例えば、ＰＣＲＦエンティティまたはＳＰＤＦエンティティ、にも向けられている。

このエンティティは、端末に関係するセッションの初期設定のためのリクエストを受信するための手段を含む。それは、また、前記エンティティのアドレス、前記セッションの識別子、及び前記端末の識別子を含むメッセージを上で限定されたデータベースに送るための手段をも含む。

このように、それがゲートウェイによって交信されるとき、本発明のＰＣＲＦまたはＳＰＤＦエンティティは、そのアドレス、トランスポート・プレーンにおける端末の識別子、及びセッション識別子を送信するために、本発明のデータベースと交信する。データベースは、このＰＣＲＦアドレス及びこのセッション識別子を、トランスポート・プレーンにおける端末の識別子と関連させる。

それがアプリケーション・エンティティＡＦによって交信されるとき、本発明のＰＣＲＦまたはＳＰＤＦエンティティは、そのアドレス、アプリケーション・シグナリング・プレーンにおける端末の識別子、セッション識別子、及び任意選択的にセッション情報を送るために、本発明のデータベースと交信する。

データベースは、このＰＣＲＦアドレス及び任意選択的にこのセッションのためのサービス情報を、アプリケーション・シグナリング・プレーンにおける端末の識別子と関連させる。データベースは、アプリケーション・エンティティＡＦによってアプリケーション・シグナリング・レベルにおいて受信されたセッション識別子を、ゲートウェイＧＷによってトランスポート・レベルにおいて受信されたセッション識別子と相関させることができる。

端末の識別子は、それらが永久的でない場合に、データベースにおいて創成される。

オペレータが、ＰＣＲＦエンティティまたは本発明のデータベースのいずれにサービス情報を記憶することを追及するかに従って、本発明の第２の実施形態において２つの選択肢がある。

１つの特定の実施形態において、本発明の管理エンティティは、
・ トランスポート・プレーンにおける前記セッションの識別子及び前記端末の識別子を含むリクエストを上で限定されたデータベースに送るための手段；及び
・ 前記リクエストに対する応答から直接にか、または前記リクエストに対する応答に含まれるアドレスにおいてもう１つのサービスの品質及び課金管理エンティティに質問することによるか、のいずれかで、前記セッションに関するサービス情報を得るための手段；
を含む。

これらの２つの選択肢は、オペレータが、ＰＣＲＦエンティティまたは本発明のデータベースのいずれかにサービス情報を記憶するのを可能とする。サービス情報がＰＣＲＦに記憶される場合、データベースは、それを第２のＰＣＲＦに通信させるために、第１のＰＣＲＦ（プロキシ・モード）からそれ自身のためにそれを得るか、または第２のＰＣＲＦに第１のＰＣＲＦのアドレスを与える（リダイレクト・モード）かのいずれかをすることができる。リダイレクト・モードにおいて、第１のＰＣＲＦは、ＰＣＲＦエンティティ間のインターフェースを必要とする、セッションのためのサービス情報を得るために、第２のＰＣＲＦと交信する。

本発明の第２の変形例の一実施形態において：
ゲートウェイは、また、セッションのリソースを解放するために、データベースにメッセージを送るための手段をも含み、リクエストは、トランスポート・プレーンにおける端末の識別子及びセッション識別子を含む。

アプリケーション・エンティティＡＦは、また、セッションのリソースを解放するために、データベースにメッセージを送るための手段をも含み、リクエストは、アプリケーション・シグナリング・プレーンにおける端末の識別子及びセッション識別子を含む。

データベースは、次に、アプリケーション・シグナリング・プレーンにおけるＰＣＲＦのアドレスを、及び、もしデータが一時的であるならば、アプリケーション・シグナリング・プレーンにおける端末の識別子を削除し、そしてまた、それがデータベースに記憶される該変形例のためのサービス情報をも削除する。

本発明は、また、ＩＭＳネットワークにおけるサービスの品質及び課金管理エンティティのアドレスを得る方法をも提供する。この方法は、１つのセッションの識別子及び１つの端末の識別子を含むリクエストを上で限定されたデータベースに送るステップを含む。

１つの特定の実施形態において、アドレスを得る方法の種々のステップがコンピュータ・プログラム命令によって決定される。

それ故、本発明は、さらに、情報媒体上のコンピュータ・プログラムを提供し、該プログラムは、アドレスを得るための装置において、もしくは一層一般的には、コンピュータにおいて実行されるよう適合されており、このプログラムは、アドレスを得るための上述の方法のステップを実行するよう適合された命令を含む。

このプログラムは、任意のプログラミング言語を用いることができ、そしてソース・コード、オブジェクト・コード、もしくは部分的にコンパイルされた形態または任意の他の所望の形態のような、ソース・コード及びオブジェクト・コード間の中間のコードの形態を取ることができる。

本発明は、さらに、上に言及したコンピュータ・プログラムの命令を含むコンピュータ読み取り可能な情報媒体を提供する。

該情報媒体は、プログラムを記憶することができる任意のエンティティまたは装置であることができる。例えば、該媒体は、例えば、ＣＤ ＲＯＭまたはマイクロ電子回路ＲＯＭであるＲＯＭ、もしくは例えば、フロッピ・ディスクまたはハード・ディスクである磁気記憶手段のような記憶手段を含み得る。

さらに、情報媒体は、無線によってまたは他の手段によって、電気的または光ケーブルを介して経路付けられ得る、電気または光信号のような送信可能媒体であることができる。本発明のプログラムは、特に、インターネット・タイプのネットワークを介してダウンロードされ得る。

代替的には、情報媒体は、プログラムを組み込み、問題の方法を実行するようもしくはその実行において用いられるよう適合された集積回路であり得る。

本発明の他の特徴及び長所は、制限的でない例による添付図面を参照して以下に与えられる説明から明瞭となるであろう。図面において、図１乃至図７は、本発明の第１の変形例を示し、図８乃至図１４は、本発明の第２の変形例を示す。

本発明の第１の変形例のゲートウェイ及びアプリケーション・エンティティをそれらの環境において示す図である。 ＵＭＴＳネットワークの文脈において第１の変形例を示す図である。 本発明の第１の変形例の第１の実施形態における（トランスポート・レベルでの）セッションをセットアップするためのメッセージの交換を示す図である。 本発明の第１の変形例の第１の実施形態における（アプリケーション・レベルでの）セッションをセットアップするためのメッセージの交換を示す図である。 本発明の第１の変形例の第２の実施形態における（トランスポート・レベルでの）セッションをセットアップするためのメッセージの交換を示す図である。 本発明の第１の変形例の第２の実施形態における（アプリケーション・レベルでの）セッションをセットアップするためのメッセージの交換を示す図である。 ＰＣＲＦエンティティのアドレスが本発明のデータベースに一時的に記憶されているときに第１の変形例におけるセッションを終結するためのメッセージの交換を示す図である。 本発明の第２の変形例のＰＣＲＦサービス品質及び課金管理エンティティをそれらの環境において示す図である。 ＵＭＴＳネットワークの文脈における第２の変形例を示す図である。 本発明の第２の変形例の種々の実施形態におけるセッションをセットアップするためのメッセージの交換を示す図である。 本発明の第２の変形例の種々の実施形態におけるセッションをセットアップするためのメッセージの交換を示す図である。 本発明の第２の変形例の種々の実施形態におけるセッションをセットアップするためのメッセージの交換を示す図である。 本発明の第２の変形例の種々の実施形態におけるセッションをセットアップするためのメッセージの交換を示す図である。 本発明の第２の変形例の種々の実施形態におけるセッションをセットアップするためのメッセージの交換を示す図である。

本発明の第１の変形例の説明
（図１乃至図７）
図１は：
・ 本発明のゲートウェイ２０；
・ 本発明のアプリケーション・エンティティＡＦ３０；
・ 本発明のデータベース５１；及び
・ 従来技術のＰＣＲＦエンティティ４０、
を示す。

この第１の変形例において、本発明のデータベース５１は、ゲートウェイ２０によって及びアプリケーション・エンティティＡＦ３０によってアクセスされる。

当該技術において知られているように：
・ ＰＣＲＦエンティティ４０及びアプリケーション・エンティティＡＦ３０間のインターフェースは、Ｒｘタイプのインターフェースである；
・ ＰＣＲＦエンティティ４０及びゲートウェイ２０間のインターフェースは、Ｇｘタイプのインターフェースである；及び
・ アプリケーション・エンティティＡＦ３０及びゲートウェイ２０間のインターフェースは、Ｇｉ／Ｗｉタイプのインターフェースである。

図２は、ＵＭＴＳネットワークの文脈における本発明の第１の変形例の一実施形態を示す。

この図において、端末１０は、本発明のゲートウェイ２０、すなわちこの例においてはゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）ゲートウェイ、とそれ自身通信するＵＴＲＡＮネットワーク２０１を介してサービングＧＰＲＳサポート・ノード（ＳＧＳＮ）２０２に付与される。

本発明のＧＧＳＮゲートウェイ２０は、本発明のアプリケーション・エンティティ３０、ここではプロキシ−コール・セッション・コントロール・ファンクション（Ｐ−ＣＳＣＦ）エンティティ、と通信する。

本発明のＧＧＳＮゲートウェイ２０及び本発明のＰ−ＣＳＣＦエンティティ３０は、図１に示されるように、ＰＣＲＦエンティティ４０にそして本発明のデータベース５１に接続される。

ここに記載された実施形態において、本発明のＰ−ＣＳＣＦエンティティ３０は、インテロゲーティング（質問）−コール・セッション・コントロール・ファンクション（Ｉ−ＣＳＣＦ）エンティティ２１６と通信し、該エンティティ２１６の主な目的は、端末１０に奉仕するサービング−コール・セッション・コントロール・ファンクション（Ｓ−ＣＳＣＦ）エンティティ２１８の場所を識別するために、ホーム・サブスクライバ・サーバ（ＨＳＳ）２２０に質問することである。

このエンティティ２１８は、ＩＭＳネットワーク上のセッション、特に、ＩＰ２３４ネットワーク・タイプの他のネットワークとのインターフェースを管理する。

ＵＭＴＳネットワークのアーキテクチャに関するもっと多くの情報については、ｈｔｔｐ／／：ｗｗｗ．３ｇｐｐ．ｏｒｇにおいて入手可能なＵＭＴＳ仕様文献、特に、文献ＴＳ ２３．２２８を参照されたし。

図３及び４を参照して、ＰＣＲＦ４０のアドレスがデータベース５１に永久に記憶されている本発明の第１の変形例の一実施形態におけるメッセージの交換が以下に説明される。

図３は、本発明を組み込むために、文献ＴＳ２３．２０３によって限定されるＩＰ−ＣＡＮセッション・セットアップ手順の適合を表わす。

この例においては、端末１０が、送信リンク（例えば、シグナリング・リンク）をセットアップするために、本発明のゲートウェイ２０にリクエストＲＱ１を送ると仮定する。このメッセージは、“ＩＰ−ＣＡＮベアラ・リクエスト”タイプのものであり得る。

このリクエストＲＱ１を受信すると、本発明のＧＧＳＮゲートウェイ２０は、本発明のデータベース５１にリクエストＲＱ２を送る。

該リクエストは、リクエストＲＱ１を送る端末のトランスポート・プレーン（面）における識別子と、任意選択的に、この端末が使用するＩＭＳネットワークへのアクセスのタイプとを含む。

リクエストＲＱ２を受信すると、本発明のデータベース５１は、この端末の識別子とまたは対（端末識別子、端末によって用いられるアクセスのタイプ）と関連したＰＣＲＦエンティティ４０のアドレスを調べる。

データベース５１は、次に、リクエストＲＱ２に応答して、トランスポート・プレーンにおけるユーザの識別子及びＰＣＲＦ４０のアドレスを含むメッセージＲＰ２を送る。

セッションは、次に、ここで要約したように、当該技術において既知の態様でセットアップされる。

本発明のＧＧＳＮゲートウェイ２０は、それが先にアドレスを得ていたＰＣＲＦ４０に、サービス品質及び課金の決定を要求するリクエストＲＱ３を送る。

このリクエストＲＱ３を受信すると、ＰＣＲＦエンティティ４０は、決定ステップＥ２を実行し、次に、ゲートウェイ２０に、応答ＲＰ３における決定を送る。

リクエストＲＱ３が“ＩＰ−ＣＡＮセッション・イスタブリシュメント”タイプのものであり得、応答ＲＰ３が“アクノリジュドＩＰ−ＣＡＮセッション・イスタブリシュメント”タイプのものであり得るということは、当業者に明瞭である。

応答ＲＰ３を受信すると、ゲートウェイ２０は、送信チャンネル（例えば、ＧＰＲＳにおけるＰＤＰ文脈）の活性化のためのリクエストを受付け、そして、端末１０に応答ＲＰ１を送ってこれについてそれに通知する。

図４は、本発明を組み込むために、文献ＴＳ ２９．２１３に限定されたＡＦセッション・セットアップ手順の適合を表わす。

ステップＥ３の間、本発明のアプリケーション・エンティティＡＦ３０は、端末１０からリクエストを受信して、セッション、代表的には、ＳＩＰインバイト・メッセージをセットアップすることが考慮される。

このメッセージを受信すると、アプリケーション・エンティティ３０は、必要なサービス情報を限定する。

本発明のこの実施形態において、アプリケーション・エンティティＡＦ３０は、アプリケーション・シグナリング・プレーンにおけるユーザの識別子及びおそらくはアクセス・タイプを含むリクエストＲＱ４をデータベース５１に送る。

ステップＥ４の間、データベース５１は、ユーザの識別子、及び適用可能な場合はアクセス・タイプ、の関数としてデータベース５１におけるＰＣＲＦエンティティ４０のアドレスを調べる。

このアドレスが識別されてしまうと、本発明のデータベース５１は、アプリケーション・シグナリング・プレーンにおけるユーザの識別子及びＰＣＲＦエンティティ４０のアドレスを含む応答ＲＰ４をアプリケーション・エンティティ３０に送る。

手順の残りは、当業者にとって知られている。

特に、アプリケーション・エンティティ３０は、ＰＣＲＦエンティティ４０に、リクエストＲＱ５、すなわち、ここで説明する実施形態においては、ダイアミタ・プロトコルに順応するオーソライゼーション・アプリカント・リクエスト（ＡＡＲ）、を送る。

このリクエストを受信すると、ＰＣＲＦ４０は、ステップＥ５１の間のサービス情報を記憶し、次に、ステップＥ５２の間、トランスポート・プレーンの当該のセッションを識別する。

ＰＣＲＦは、次に、ＰＣＲＦがプッシュ・モードにある場合に、ＱＯＳ及び課金ルールを送るために、一般ステップＥ６の間にゲートウェイ２０と相互作用（対話）し得る（図３を参照して上述した相互作用は、ＰＣＲＦがプル・モードにある場合にリソースの活性化中にメッセージＲＦＰ５の後に適用される）。

ＰＣＲＦ４０は、応答メッセージＰＲ５を、アプリケーション・エンティティ３０に送る、すなわち、ここで説明する例においては、ダイアミタ・プロトコルに順応するオーソライゼイション・アプリケーション・アンサ（ＡＡＡ）応答を送る。

ＰＣＲＦ４０のアドレスがデータベース５１に一時的に記憶される本発明の第１の変形例の実施形態を、図５及び６を参照して以下に説明する。

図５及び６は、この実施形態を組み込むよう、文献ＴＳ ２３．２０３及びＴＳ ２９．２１３に限定されるようなセッション・セットアップの適合をそれぞれ表わす。

ゲートウェイ２０が、すでに記載されたシグナリング送信リンクをセットアップするためにリクエストＲＱ１を受信するとき、それはステップＥ０中にネットワークのＰＣＲＦエンティティを選択する。このエンティティは、例えば、ランダムに選択され得る。

ゲートウェイ２０は、次に、トランスポート・プレーンにおけるユーザの識別子と、ステップＥ０において選択されたＰＣＲＦのアドレスと、セッション識別子とを含むリクエストＲＱ６を、データベース５１に送る。

ここに記載された実施形態において、データベース５１は、ステップＥ７の間に、ＰＣＲＦのアドレスとセッション識別子とを記憶する。

データベース５１は、次に、トランスポート・プレーンにおけるユーザの識別子とセッション識別子とを含む応答ＲＰ６を、ゲートウェイ２０に送る。

セッション・セットアップは、次に、従来技術におけるようにかつ図３を参照して上述したように続く。

図６を参照すると、アプリケーション・エンティティＡＦ３０がセッション・セットアップ・リクエスト（ＳＩＰインバイト・メッセージ）を受信するとき、それは、リクエストＲＱ４’をデータベース５１に送り、該リクエストＲＱ４’は、アプリケーション・シグナリング・プレーンにおけるユーザの識別子を含むが、また、ＰＣＲＦ４０のアドレスがこのセッションのために一時的であるという理由で必要とされるセッション識別子をも含む。

上述したように、この情報を用いて、データベース５１は、ＰＣＲＦ４０のアドレスを識別し、アプリケーション・シグナリング・プレーンにおけるユーザの識別子及びセッション識別子と一緒に、ＰＣＲＦ４０のアドレスを、応答メッセージＲＰ４’においてアプリケーション・エンティティ３０に戻す。

セッション・セットアップ手順の残りは、当該技術分野で既知の態様で、かつ図４を参照して上述したように進行する。

図７は、文献ＴＳ ２９．２１３において限定されるＩＰ−ＣＡＮセッション終結手順への適合を表わす。

ここでは、本発明のゲートウェイ２０は、セッションを終了させるために、端末１０からリクエストＲＱ６を受信すると仮定される。このリクエストＲＱ６は、“リムーブＩＰ−ＣＡＮベアラ・リクエスト”タイプのものであり得る。

当該技術分野で既知の態様において、かかるリクエストＲＱ６を受信することは、インディケーション・メッセージＲＱ７のＰＣＲＦ４０への送信をトリガする。このメッセージＲＱ７は、“ＩＰ−ＣＡＮセッション・ターミネーションのインディケーション”タイプのものであり得る。

従来技術におけるように、ＰＣＲＦエンティティ４０は、ステップＥ８の間にこのターミネーション（終結）・リクエストによりどのルールが影響されるかを識別する。ゲートウェイは、ステップＥ９の間にこれらのすべてのルールを破壊する。

本発明によれば、ＰＣＲＦエンティティ４０は、このユーザのためのセッション識別子及びＰＣＲＦのアドレスを削除するために、データベース５１にリクエストＲＱ８を送る。

このリクエストＲＱ８は、トランスポート・プレーンにおけるユーザの識別子と、セッション識別子とを含む。

これらの動作が行われてしまうと、データベース５１は、ＰＣＲＦ４０に応答メッセージＲＰ８を送る。当該技術で既知の態様において、ＰＣＲＦ４０は、応答ＲＰ７をゲートウェイ２０に送る。この応答ＲＰ７は、“アクノリジュＩＰ−ＣＡＮセッション・ターミネーション（終結）”タイプのメッセージであり得る。

ゲートウェイ２０は、次に、メッセージＲＰ６を送ることにより、端末１０によって送られたリクエストＲＱ６を肯定応答（アクノリジュ）する。この応答ＲＰ６は、“リムーブＩＰ−ＣＡＮベアラ・レスポンス（応答）”タイプのメッセージであり得る。

本発明の第２の変形例の説明
（図８乃至図１４）
図８は、本発明の第２の変形例のＰＣＲＦのサービス品質及び課金管理のエンティティ４１、４２をそれらの環境において表わす。

これらの図が上述の図１及び図２と比較される場合、本発明のデータベース５２がＰＣＲＦエンティティ４１及び４２に直接接続されるということ、並びにゲートウェイ２０（ＧＧＳＮ）及びアプリケーション・エンティティ３０（Ｐ−ＣＳＣＦ）の各々が異なったＰＣＲＦ４２、４１を用いるということが見られる。

図９は、ＵＭＴＳネットワークの文脈における本発明の第１の変形例の実施形態を示す。

図１０は、本発明のこの第２の変形例を組み込むために、文献ＴＳ ２９．２１３に限定されるＩＰ−ＣＡＮセッション・セットアップ手順の適合を示す。

ゲートウェイ２０が、シグナリング送信リンクをセットアップするためにリクエストＲＱ１を受信するとき、それは、ステップＦ１の間にＰＣＲＦエンティティ４２を選択し、そのアドレスを、ユーザ識別子及びセッション識別子と関連させて記憶する。

次に、当該技術で既知の態様において、ゲートウェイ２０は、セッションのセットアップを示すために、このＰＣＲＦエンティティ４２にリクエストＲＱ２を送る。

この変形例において、ＰＣＲＦエンティティ４２は、トランスポート・プレーンにおけるユーザの識別子と、ＰＣＲＦエンティティ４２のアドレスと、セッション識別子とを含むリクエストＲＱ９を、本発明のデータベース５２に送る。

ステップＦ２の間、データベース５２は、該データが永久でない場合、ＰＣＲＦエンティティ４２のアドレスと、ユーザのためのセッションの識別子と、トランスポート・プレーンにおけるユーザの識別子と、を記憶する。

データベース５２は、次に、ＰＣＲＦエンティティ４２に応答メッセージＲＰ９を送る。

手順の残りは、標準の態様で進行する（図３参照）。

特に、ステップＥ２の間、ＰＣＲＦエンティティ４２は、その決定ポリシを選択し、次に、リクエストＲＱ２を肯定応答（アクノリジュ）するためにゲートウェイ２０にメッセージＲＰ２を送る。

ゲートウェイ２０は、セッション・セットアップ・リクエストＲＱ１を肯定応答（アクノリジュ）するために、端末１０にメッセージＲＰ１を送る。

図１１を参照すると、ステップＥ３の間、本発明のアプリケーション・エンティティ３０が、端末１０から来るセッション・セットアップ・リクエストを受信すると仮定される。

このリクエストを受信すると、アプリケーション・エンティティ３０は、必要なサービス情報を限定し、次に、ステップＦ３の間、ＰＣＲＦエンティティ４１を選択し、そしてそのアドレスをユーザ識別子及びセッション識別子と関連させて記憶する。

次に、上述したように（図４参照）、アプリケーション・エンティティ３０は、ＰＣＲＦエンティティ４１に、リクエストＲＱ５、すなわち、この例では、ダイアミタＡＡＲメッセージ、を送る。

このリクエストを受信すると、ＰＣＲＦエンティティ４１は、ステップＥ５１の間、サービス情報を記憶する。

本発明のこの実施形態において、ＰＣＲＦエンティティ４１は、ＰＣＲＦエンティティ４１のアドレスと、シグナリング・プレーンにおけるユーザの識別子と、セッション識別子と、任意選択的にサービス情報とを含むリクエストＲＱ１０をデータベース５２に送る。

ステップＦ４の間、リクエストＲＱ１０を受信すると、データベース５２は、ユーザ及びセッションのためのこの情報、すなわち、少なくともＰＣＲＦ４１のアドレスを記憶する（サービス情報は、任意選択的であり、ユーザの識別子は、おそらくすでに存在する永久データである）。

データベース５２は、次に、リクエストＲＱ１０を肯定応答（アクノリジュ）するために、ＰＣＲＦエンティティ４１にメッセージＲＰ１０を送る。

ＰＣＲＦエンティティ４１は、上述したように、ステップＥ５２の間、当該のトランスポート・プレーン・セッションを識別することができる。

次に、一般ステップＦ５の間、ゲートウェイ２０は、図１０を参照して上述した動作を行う。

新しくセットアップされたセッションのためのリソースのリザーベーション（保留）を要求する端末１０に対する本発明のこの第２の変形例の応答を以下に説明する。

本発明のこの第２の変形例の３つの実施形態が構想されており、それぞれ図１２、図１３及び図１４を参照して以下に説明する。

図１２及び図１３の実施形態において、サービス情報は、プロキシ・モード（図１２）でデータベースＤＢ５２を介してかまたはリダイレクト・モード（図１３）で直接にか、のいずれかで、ＰＣＲＦ４１からＰＣＲＦ４２に送られる。

図１４の実施形態において、このサービス情報は、データベース５２から送信される。

これら３つの実施形態は同じ方法で開始する：端末１０は、“ＩＰ−ＣＡＮセッション・イスタブリシュメントのインディケーション”タイプのリクエストＲＱ３をＰＣＲＦエンティティ４２に送るゲートウェイ２０に、“イスタブリシュＩＰ−ＣＡＮベアラ・リクエスト”タイプのリソース活性化リクエストＲＱ１を送る。

このリクエストＲＱ３を受信すると、サービス情報を得るために、ＰＣＲＦエンティティ４２は、トランスポート・プレーンにおけるユーザの識別子及びセッション識別子を示すリクエストＲＱ１１をデータベース５２に送る。

このリクエストは、関係している実施形態に従って、異なって処理される。

１．プロキシ・モード（図１２）
この実施形態においては、データベース５２は、ＰＣＲＦ４１と交信し、そのリクエストにおいて、シグナリング・プレーンにおけるユーザの識別子と、セッション識別子とを送る。

プル・モードにおいて、ステップＦ６の間、ＰＣＲＦ４１は、このユーザとこのセッションのためのサービス情報を検索する。ＰＣＲＦ４１は、データベース５２（メッセージＲＰ１２）に応答し、その応答は、ユーザ及び要求されたセッションのためのサービス情報を含む。

データベース５２は、ユーザの識別子及びセッションに関係するサービス情報でもってＰＣＲＦに応答する（メッセージＲＰ１１）。

もう１つの実施形態（図１１におけるステップＦ５）では、プッシュ・モードにおいて、ＰＣＲＦ４２は、データベース５２にリクエストを自発的に送り、データベース５２は、それをＰＣＲＦ４１にリダイレクト（再方向付け）する。

２．リダイレクト（再方向付け）モード（図１３）
この実施形態においては、データベースは、ＰＣＲＦ４２に応答し、それにＰＣＲＦ４１のアドレスを与える（メッセージＲＰ１１’）。ＰＣＲＦエンティティ４１及び４２は、互いに接続される。

プル・モードにおいてＰＣＲＦ４２はＰＣＲＦ４１と交信し（リクエストＲＱ１３）、それにシグナリング・プレーンにおけるユーザの識別子とセッション識別子とを送る。ＰＣＲＦ４２は、ユーザ識別子及びセッション識別子にリンクされたＰＣＲＦ４１のアドレスを未来の使用のために局部的に記憶することができる。

ステップＦ７の間、ＰＣＲＦ４１は、このユーザのためのサービス情報を検索し、それを応答ＲＰ１３においてＰＣＲＦ４２に送る。

もう１つの実施形態では、プッシュ・モードにおいて、ＰＣＲＦ４１は、データベースからのそのアドレスを得た後、ＰＣＲＦ４２にサービス情報を自発的に送る。

ＰＣＲＦ４２は、データベース５２にリクエストを自発的に送る。

３．データベース５２に記憶されたサービス情報（図１４）
この実施形態においては、データベース５２は、それ自体、このユーザ及びこのセッションのためのサービス情報を検索する（ステップＦ８）。データベース５２は、ユーザの識別子及びセッションに関係するサービス情報（メッセージＲＰ１１）でもってＰＣＲＦ４２に応答する。

ここに説明する３つの例において、ＰＣＲＦ４２は、このように、ＰＣＲＦ４１からかまたはデータベース５２からかのいずれかから、要求されたサービス情報を得る。

これがどうあろうと、すでに説明したステップＥ２の間、それはそのＱＯＳ及び課金ポリシを創設し、次に、リクエストＲＱ３に応答して“アクノリジュド（肯定応答された）ＩＰ−ＣＡＮセッション・イスタブリシュメント”タイプのメッセージＲＰ３を送る。

ゲートウェイ２０は、リクエストＲＱ１に応答して“イスタブリシュＩＰ−ＣＡＮベアラ・レスポンス”タイプのメッセージＲＰ１を送ることができる。

図７を参照して説明したものと同様の方法で、ＩＰ−ＣＡＮセッションを終結するために、ＰＣＲＦ４２は、ユーザ識別子及びセッション識別子でもってデータベース５２と交信する。

トランスポート・プレーンにおけるセッションを終了させるために、データベース５２は、ユーザのためのＰＣＲＦ４２のアドレスを削除する。それは、また、該データが一時的であるならば、トランスポート・プレーンにおけるユーザ識別子をも削除する。

ゲートウェイ２０は、ユーザ識別子、セッション識別子、及びセッションのために記憶されていたＰＣＲＦ２のアドレスを削除する。

図１３を参照して説明したリダイレクト（再方向付け）・モードにおいて、ＰＣＲＦ４２は、ユーザ識別子、セッション識別子、及びこの情報がセッションのために記憶されていたならば、ＰＣＲＦ４１のアドレスを削除する。

アプリケーション・シグナリング・プレーンにおけるセッションを終結させるために、データベース５２は、ＰＣＲＦ４１のアドレス、並びに必要な場合にはユーザ及びセッションのためのサービス情報を削除する。

データベース５２はまた、該データが一時的ならば、シグナリング・プレーンにおけるユーザ識別子をも削除する。

アプリケーション・エンティティ３０は、ユーザ識別子、セッション識別子、及びセッションのために記憶されたＰＣＲＦエンティティ４１のアドレスを削除する。

上述したゲートウェイ２０及びアプリケーション・エンティティ３０は、通常のコンピュータのハードウェア・アーキテクチャを有する。

それらは、本発明のコンピュータ・プログラムが記憶されたＲＯＭを含む。それが実行されるとき、このプログラムは、アドレスを得るための本発明の方法の命令を実行する。

該方法は、セッション識別子と、シグナリング・プレーンまたはトランスポート・プレーンにおける端末１０の識別子と、おそらくはアクセス・タイプとの中のデータを少なくとも含む、リクエストＲＱ２、それぞれＲＱ４を、データベース５１に送ることを特に含む。

ゲートウェイ２０及びアプリケーション・エンティティ３０は、それぞれそれらのリクエストＲＱ２、ＲＱ４に応答して、データベース５１からＰＣＲＦエンティティ４０のアドレスを得る。

上述したＰＣＲＦエンティティ４２は、通常のコンピュータのハードウェア・アーキテクチャを有する。

それは、本発明のコンピュータ・プログラムを記憶するＲＯＭを含む。それが実行されるとき、このプログラムは、アドレスを得るための本発明の方法の命令を実行する。

そのリクエストＲＱ１１に応答して、ＰＣＲＦエンティティ４２は、リダイレクト（再方向付け）モードにおけるデータベース５２からまたはプロキシ・モードにおけるサービス情報からＰＣＲＦエンティティ４１のアドレスを得る。

本発明は、また、ＩＭＳネットワークにおいてアクセス可能でかつ以下を含む少なくとも１つのレコードを含むデータベースに向けられている：
・ トランスポート・プレーンにおけるセッションの少なくとも１つの識別子；
・ 前記ネットワークにおけるサービス品質及び課金管理エンティティの少なくとも１つのアドレス；及び
・ シグナリング・プレーンにおける前記セッションの識別子を含むリクエストを受信することに応答して管理エンティティの前記アドレスを送るための手段。

セッション識別子は、トランスポート・プレーンまたはシグナリング・プレーンにあり得る。

このデータベースは、ユーザ識別子を含まない。

この実施形態は、ユーザが移動状況にない場合にのみ使用可能である。

１０ 端末
２０ ゲートウェイ
３０ アプリケーション・エンティティＡＦ
４０ ＰＣＲＦエンティティ
５１ データベース

Claims (15)

1. ＩＭＳネットワークにおけるアクセス可能なデータベース（５１、５２）であって、
   ・ トランスポート・プレーンにおける端末（１０）の識別子；
   ・ シグナリング・プレーンにおける前記端末（１０）の識別子；及び
   ・ 前記ネットワークにおけるサービスの品質及び課金管理エンティティ（４０、４１、４２）の少なくとも１つのアドレス
   を含む少なくとも１つのレコードを含むことを特徴とするデータベース。
2. 前記レコードは、さらに、セッション識別子を含む請求項１に記載のデータベース。
3. 前記レコードは、さらに、前記ネットワークにおけるセッションに関するサービス情報を含む請求項１または２に記載のデータベース。
4. 前記ネットワークにおけるサービスの品質及び課金管理エンティティ（４１）を質問することにより、前記ネットワークにおけるセッションに関するサービス情報を得るための手段を含むことを特徴とする請求項１乃至３のいずれか１項に記載のデータベース。
5. ＩＭＳネットワークにおける端末（１０）によって送られたトランスポート・レベルにおけるセッションをセットアップするためにリクエスト（ＲＱ１）を受信するための手段を含むゲートウェイ（２０）であって、
   ・ トランスポート・プレーンにおける前記端末（１０）の識別子を含むリクエスト（ＲＱ２）を請求項１乃至３のいずれか１項に記載のデータベース（５１）に送るための手段；及び
   ・ 前記リクエスト（ＲＱ２）に応答（ＲＰ２）して前記ネットワークにおけるサービスの品質及び課金管理のエンティティ（４０）のアドレスを得るための手段
   を含むことを特徴とするゲートウェイ。
6. ＩＭＳネットワークにおける端末によって送られるセッションをセットアップするためにリクエストを受信するための手段を含むアプリケーション・エンティティ（３０）であって、
   ・ シグナリング・プレーンにおける前記端末の識別子を含むリクエスト（ＲＱ４）を請求項１乃至３のいずれか１項に記載のデータベース（５１）に送るための手段；及び
   ・ 前記リクエスト（ＲＱ４）に応答（ＲＰ４）に応答して前記ネットワークにおけるサービスの品質及び課金管理エンティティ（４０）のアドレスを得るための手段
   を含むことを特徴とするアプリケーション・エンティティ。
7. ＩＭＳネットワークにおける端末（１０）によって送られたトランスポート・レベルにおけるセッションをセットアップするためのリクエスト（ＲＱ１）を受信するための手段を含むゲートウェイ（２０）であって、請求項１乃至３のいずれか１項に記載のデータベース（５１）にリソース活性化メッセージ（ＲＱ６）を送るための手段を含み、前記リクエストは、前記ネットワークにおけるサービスの品質及び課金管理エンティティ（４０）のアドレス、トランスポート・プレーンにおける前記端末（１０）の識別子及び前記セッションの識別子を含むことを特徴とするゲートウェイ。
8. ランダムに、または前記端末によって用いられる前記ネットワークへのアクセスのタイプの関数として、前記エンティティを選択することを特徴とする請求項７に記載のゲートウェイ。
9. ＩＭＳネットワークにおける端末（１０）によって送られるセッションをセットアップするためにリクエストを受信するための手段を含むアプリケーション・エンティティ（３０）であって、
   ・ シグナリング・プレーン及び前記セッションの識別子における前記端末の識別子を含むリクエスト（ＲＱ４’）を請求項２に記載のデータベース（５１）に送るための手段；及び
   ・ 前記リクエスト（ＲＱ４’）に応答（ＲＰ４’）に応答して前記ネットワークにおけるサービスの品質及び課金管理エンティティ（４０）のアドレスを得るための手段
   を含むことを特徴とするアプリケーション・エンティティ。
10. 端末（１０）に関係するセッションを初期設定するためにリクエストを受信するための手段を含む、ＩＭＳネットワークにおけるサービスの品質及び課金管理エンティティ（４１、４２）であって、前記エンティティ（４１、４２）のアドレス、前記セッションの識別子、及び前記端末（１０）の識別子を含むメッセージ（ＲＱ９、ＲＱ１０）を請求項１乃至３のいずれか１項に記載のデータベース（５２）に送るための手段を含むことを特徴とする管理エンティティ。
11. 前記メッセージは、さらに、前記セッションに関する情報を含むことを特徴とする請求項１０に記載の管理エンティティ。
12. ・ トランスポート・プレーンにおける前記セッションの識別子及び前記端末（１０）の識別子を含むリクエスト（ＲＱ１１）を請求項２または３に記載のデータベース（５２）に送るための手段；及び
    ・ 前記リクエスト（ＲＱ１１）に対する応答（ＲＰ１１）から直接にか、または前記リクエスト（ＲＱ１１）に対する応答（ＲＰ１１’）に含まれるアドレスにおいてもう１つのサービスの品質及び課金管理エンティティ（４１）を質問することによるか、のいずれかで、前記セッションに関するサービス情報を得るための手段；
    を含むことを特徴とする請求項１０または１１に記載の管理エンティティ。
13. ＩＭＳネットワークにおけるサービスの品質及び課金管理エンティティのアドレスを得る方法であって、端末（１０）の少なくとも１つの識別子を含むリクエスト（ＲＱ２）を請求項１乃至３のいずれか１項に記載のデータベース（５１）に送るステップを含むことを特徴とする方法。
14. コンピュータ・プログラムであって、該プログラムがコンピュータによって実行されるときに、請求項１３に記載のアドレスを得る方法のステップを実行するための命令を含むコンピュータ・プログラム。
15. 請求項１３に記載のアドレスを得る方法のステップを実行するための命令を含むコンピュータ・プログラムを記憶するためのコンピュータ読取り可能な記憶媒体。

Images