JP2009544202A - データベースクライアントとデータベースサーバとの間での通信のためにｓｈインタフェースを使用するための方法、装置、及びプログラム - Google Patents

Abstract

通信ネットワークのデータベースクライアント（２２）とデータベースサーバ（２０）との間の通信のためにＳｈインタフェースが使用される前記通信ネットワークにおいて使用される方法が提供される。前記データベースサーバは、前記ネットワークの様々なユーザに関連づけられたリポジトリデータやユーザプロファイルデータなどのユーザデータを格納するための少なくとも１つのデータベースにアクセスする。前記Ｓｈインタフェースは、複数の所定のタイプの拡張データ管理情報のうちの少なくとも１つを前記データベースクライアント（２２）と前記データベースサーバ（２０）との間で搬送するために使用される。前記複数の所定のタイプの拡張データ管理情報とは、前記ユーザデータの単数又は複数の部分に対するデータベース操作を実行するために前記データベースクライアント（２２）が前記データベースサーバを使用することを可能にする第１の情報と、前記データベースサーバ（２０）が前記データベースクライアント（２２）からのユーザデータの要求に対する部分的な応答を提供することを可能にする第２の情報と、前記データベースサーバ（２０）が前記データベースクライアント（２２）からの要求のフローを制御することを可能にする第３の情報と、前記データベースサーバが前記データベースクライアント（２２）から受信したユーザデータを格納するために使用されるデータベースの種類を前記データベースサーバ（２０）が選択することを可能にする第４の情報と、である。

Description

本発明は、通信ネットワークにおいて使用する方法及び装置に関する。

ＩＰマルチメディア・サービスは、音声、ビデオ、メッセージング、データ等の動的な組み合わせを、同一セッション内で提供する。基本的なアプリケーション、及び組み合わせ可能なメディアの数が増えることによって、エンドユーザに提供されるサービスの数が増え、個人間の通信エクスペリエンスが豊かになるであろう。このことは、所謂「組み合わせＩＰマルチメディア」サービスを含む、パーソナライズされた豊かなマルチメディア通信サービスに関する新しい世代を導くことになろう。

背景として、ＵＭＴＳ（ユニバーサル・モバイル・テレコミュニケーション・システム）は、加入者に対してより高いデータレートと豊かなサービスとを提供するように設計された第３世代の無線システムである。ＵＭＴＳは、汎欧州デジタル移動電話方式（ＧＳＭ）の後継であり、ＧＳＭとＵＭＴＳとの間にある重要な進化段階は、汎用パケット無線サービス（ＧＰＲＳ）である。ＧＰＲＳは、ＧＳＭコアネットワーク内にパケット交換方式を導入し、パケットデータネットワーク（ＰＤＮ）への直接アクセスを可能にした。これにより、ＩＳＤＮの６４ｋｂｐｓという限界をはるかに超える高いデータレートのパケット交換方式の通信がＧＳＭ呼ネットワークを介して可能になり、このことは２Ｍｂｐｓにも及ぶＵＭＴＳデータ通信レートにとって不可欠である。ＵＭＴＳは第３世代パートナーシップ・プロジェクト（３ＧＰＰ）によって標準化された。３ＧＰＰは、欧州電気通信標準化協会（ＥＴＳＩ）や電波産業会（ＡＲＩＢ）などのような地域の標準化団体の集合体である。更なる詳細については３ＧＰＰ ＴＳ２３．００２を参照のこと。

ＵＭＴＳの標準化は段階的に進んできた。最初の段階はリリース’９９として知られていた。リリース’９９の仕様は、ＵＭＴＳ地上無線アクセスネットワーク（ＵＴＲＡＮ）、回線交換方式のコアネットワーク（ＣＳ−ＣＮ）、及びパケット交換方式のコアネットワーク（ＰＳ−ＣＮ）から成る基本的なアーキテクチャを規定する。リリース’９９の仕様は、伝統的な回線交換方式のサービスに並んでパケット交換方式のサービスも提供する。標準化プロセスにおける次の段階はリリース４であり、’９９のアーキテクチャに対して新しいサービスを追加するものであった。リリース５は重要な転換を表し、単一の集中型パケットベースネットワーク上で、伝統的な電話サービスに並んでパケット交換方式のサービスも提供するものであった。

ＵＭＴＳのリリース５のアーキテクチャでは、伝統的な電話サービスに並んで新しいマルチメディアサービスを提供するために、ＩＰマルチメディア・サブシステム（ＩＭＳ）として知られる新しいサブシステムがＰＳ−ＣＮに対して追加された。ＩＭＳは、移動通信ネットワークを介してＩＰマルチメディア・サービスを提供する（３ＧＰＰ ＴＳ２２．２２８、ＴＳ２３．２２８、ＴＳ２４．２２９、ＴＳ２９．２２８、ＴＳ２９．２２９、ＴＳ２９．３２８、及びＴＳ２９．３２９のリリース５から７）。ＩＭＳは、標準化されたＩＭＳサービス・イネーブラの利用を通じて、エンドユーザの個人対個人の通信エクスペリエンスを豊かにする主要な特徴を提供する。ＩＭＳサービス・イネーブラは、ＩＰベースのネットワーク上で、個人対コンテンツ（クライアント対サーバ）のサービスと共に新しい豊かな個人対個人（クライアント対クライアント）の通信サービスを促進する。ＩＭＳは、ＰＳＴＮ／ＩＳＤＮ（公衆交換電話網／サービス総合デジタル網）に並んでインターネットにも接続可能である。

ＩＭＳは、ユーザ端末間（又は、ユーザ端末とアプリケーションサーバとの間）の呼又はセッションをセットアップして制御するために、セッション開始プロトコル（ＳＩＰ）を利用する。セッションのメディアコンポーネントについて記述及び交渉を行うために、ＳＩＰシグナリングによって搬送されるセッション記述プロトコル（ＳＤＰ）が使用される。ＳＩＰはユーザ対ユーザのプロトコルとして作成されたが、ＩＭＳでは、オペレータ及びサービスプロバイダがユーザによるサービスへのアクセスを制御し、それに応じてユーザに料金を請求することができる。３ＧＰＰは、ユーザ装置（ＵＥ）とＩＭＳとの間のシグナリングに並んで、ＩＭＳ内のコンポーネント間のシグナリングのためにも、ＳＩＰを選択した。

図１は、在圏ネットワーク２０２内に位置するユーザ装置（ＵＥ）２０４を含むＵＭＴＳ通信ネットワーク２００を示す概略図である。ＵＥ２０４は、ＵＴＲＡＮ２０６を介してサービングＧＰＲＳサポートノード（ＳＧＳＮ）２０８にアタッチしており、ＵＴＲＡＮ２０６は次にゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）２１０と通信する。在圏ネットワーク２０２内で、ＧＧＳＮ２１０はプロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）２１２と通信する。Ｐ−ＳＣＳＦ２１２は、ＵＥ２０４のための在圏ＩＭＳネットワークにおける最初の接点である。Ｐ−ＣＳＣＦ２１２はＳＩＰ登録メッセージ及びセッション確立メッセージをホームネットワーク２１４へ転送する。

ホームネットワーク２１４内の最初の接点はインテロゲーティング呼セッション制御機能（Ｉ−ＣＳＣＦ）２１６であり、Ｉ−ＣＳＣＦ２１６は、ＩＭＳアーキテクチャにおいてはオプションのノードであり、その主たる目的は、サービング呼セッション制御機能（Ｓ−ＣＳＣＦ）２１８の所在を見つけるためにホーム加入者サーバ（ＨＳＳ）２２０に対する問合せを行うことである。Ｓ−ＣＳＣＦ２１８は、ＩＭＳネットワークのためのセッション管理を行い、ネットワーク内にはいくつかのＳ−ＣＳＣＦが存在してもよい。ＨＳＳ２２０は、中央集中型の加入者データベースであり、以前のＵＭＴＳリリースからのホーム・ロケーション・レジスタ（ＨＬＲ）から発展したものである。ＨＳＳ２２０はＩ−ＣＳＣＦ及びＳ−ＣＳＣＦとインタフェースして、加入者の位置及び加入者の加入契約情報に関する情報を提供する。

通信ネットワーク２００は、ホームネットワーク２１４内に位置する、アプリケーションサーバ２２２と、データベース２２４と、メールサーバ２２６とを更に備える。Ｓ−ＣＳＣＦ２１８から、シグナリングメッセージが、ＵＥ２３０を含んだリリース５のＩＭＳネットワーク２２８かもしれない意図された宛先へと、又は、メディアゲートウェイ制御機能（ＭＧＣＦ）を介してインタフェースされるＰＳＴＮを含んだレガシネットワーク２３２へと、又は、ＩＰネットワーク２３４へと、と渡される。

ＵＭＴＳ通信ネットワーク２００の動作、並びにそのようなネットワーク内の多様なコンポーネントの動作に関する詳細は、http://www.3gpp.orgから入手可能な、ＵＭＴＳのための技術仕様から見つけることができる。ＵＭＴＳ内でＳＩＰを使用することに関する更なる詳細は、３ＧＰＰ技術仕様ＴＳ２４．２２８ Ｖ５．８．０（２００４−０３）から見つけることができる。

ＩＭＳサービスネットワーク内で、アプリケーションサーバ（ＡＳ）はＩＭＳサービス機能を実装するためのものである。アプリケーションサーバは、ＩＭＳシステム内のエンドユーザに対してサービスを提供し、３ＧＰＰで規定されるＭｒインタフェースを介してエンドポイントとして接続されてもよいし、３ＧＰＰで規定されるＩＳＣインタフェースを介してＳ−ＣＳＣＦによって「連結され(linked in)」てもよい。後者の場合、ＳＩＰセッションの確立中にどのアプリケーションサーバが「連結され」るべきかを決定するために、Ｓ−ＣＳＣＦによって初期フィルタ基準（ＩＦＣ）が使用される（或いは、実際のところ、セッションが関連しようがしまいが、あらゆるＳＩＰメソッドを目的として）。ＩＦＣは、ＩＭＳ登録手順の間に、ユーザのユーザプロファイルの一部として、Ｓ−ＣＳＣＦによってＨＳＳから受信される。

ＩＭＳは、ＳＩＰアプリケーションサーバ（ＡＳ）及びＯＳＡ（オープンサービスアクセス）サービス能力サーバ（ＳＣＳ）がホーム加入者サーバ（ＨＳＳ）内に格納されたエンドユーザのプロファイルデータにアクセスすることを可能にする、インタフェース及びメカニズムを規定する。このインタフェースは「Ｓｈ」インタフェースと呼ばれ、３ＧＰＰ ＴＳ２９．３２８（"IP Multimedia (IM) Subsystem Sh interlace; Signalling flows and message contents"; http://www.3 gpp.org/ftp/Specs/html- info/29328.htm）及び３ＧＰＰ ＴＳ２９．３２９（"Sh Interface based on the Diameter protocol; Protocol details"; http://www.3gpp.org/ftp/Specs/html-info/29329.htm）において規定されている。これは、ＩＥＴＦ ＲＦＣ３５５８によって仕様が定められたＤｉａｍｅｔｅｒベースのプロトコルの上で実行されるアプリケーションである。Ｓｈインタフェースは、図２においてＩＭＳアーキテクチャ内に図解されている。

本発明の実施形態は、以下に説明するように、Ｓｈインタフェースに関連する１以上の技術的欠点に対処することを意図している。

本発明の第１の態様によれば、通信ネットワークのデータベースクライアントとデータベースサーバとの間の通信のためにＳｈインタフェースが使用される前記通信ネットワークにおいて使用される方法であって、前記データベースサーバは、前記ネットワークの様々なユーザに関連づけられたリポジトリデータやユーザプロファイルデータなどのユーザデータを格納するための少なくとも１つのデータベースにアクセスし、前記方法は、複数の所定のタイプの拡張データ管理情報のうちの少なくとも１つを前記データベースクライアントと前記データベースサーバとの間で搬送するために前記Ｓｈインタフェースを使用するステップを備え、前記複数の所定のタイプの拡張データ管理情報とは、前記ユーザデータの単数又は複数の部分に対するデータベース操作を実行するために前記データベースクライアントが前記データベースサーバを使用することを可能にする第１の情報と、前記データベースサーバが前記データベースクライアントからのユーザデータの要求に対する部分的な応答を提供することを可能にする第２の情報と、前記データベースサーバが前記データベースクライアントからの要求のフローを制御することを可能にする第３の情報と、前記データベースサーバが前記データベースクライアントから受信したユーザデータを格納するために使用されるデータベースの種類を前記データベースサーバが選択することを可能にする第４の情報と、であることを特徴とする方法が提供される。

前記第１の情報は、実行される前記データベース操作を示してもよい。

前記第１の情報は、前記リポジトリデータの単数又は複数の部分を取り出すデータベース操作を示してもよい。

前記第１の情報は、前記リポジトリデータのサービスデータ部分の単数又は複数の部分を取り出すデータベース操作を示してもよい。

前記第１の情報は、前記ユーザデータの単数又は複数の部分を修正するデータベース操作を示してもよい。

前記第１の情報は、前記データを格納するために使用されるデータモデルスキームと前記データベースの種類とのうちの少なくとも１つを示してもよい。

前記第２の情報は、前記部分的な応答がデータの前記要求のどの単数又は複数の部分に関連するかを示してもよい。

前記第２の情報は、前記部分的な応答では返答されなかった前記要求の単数又は複数の部分に関する情報を示してもよい。

前記要求が複数のデータタイプに関連する場合に、前記第２の情報は、それぞれのデータタイプについての優先度を示し、前記データベースサーバが前記要求の部分に対して優先度の順序で応答することを可能にしてもよい。

前記方法は、例えば以前の要求に対して部分的な応答が提供された場合に、前記データベースサーバが前記データベースクライアントからのデータの要求に対する延期された応答を提供することを可能にする情報を搬送するために、前記Ｓｈインタフェースを使用するステップを備えてもよい。

前記第３の情報は、前記データベースサーバがサービス提供可能な前記データベースクライアントからの要求の数の限界を示してもよい。

前記第３の情報は、前記示された限界に対して適用可能な有効期間を示してもよい。

前記第３の情報は、複数のデータタイプに関連する要求が許可されているか否かを示してもよい。

前記第４の情報は、前記データベースクライアントに対して、使用されるデータベースの種類を通知し、これは後で第１の情報として使用されてもよい。

前記情報は少なくとも１つの属性−値ペアを含んでもよい。

前記ネットワークは、ユニバーサル・モバイル・テレコミュニケーション・システムであってもよい。

前記ネットワークは、ＩＰマルチメディア・サブシステムを含んでもよい。

前記データベースサーバは、前記ユニバーサル・モバイル・テレコミュニケーション・システムのホーム加入者サーバを含んでもよい。

前記データベースクライアントは、前記ユニバーサル・モバイル・テレコミュニケーション・システムのアプリケーションサーバを含んでもよい。

前記少なくとも１つのデータベースは、前記データベースサーバの外部に備えられてもよい。

本発明の第２の態様によれば、通信ネットワークのデータベースクライアントとデータベースサーバとの間の通信のためにＳｈインタフェースが使用される前記通信ネットワークにおいて使用される装置であって、前記データベースサーバは、前記ネットワークの様々なユーザに関連づけられたリポジトリデータやユーザプロファイルデータなどのユーザデータを格納するための少なくとも１つのデータベースにアクセスし、前記方法は、複数の所定のタイプの拡張データ管理情報のうちの少なくとも１つを前記データベースクライアントと前記データベースサーバとの間で搬送するために前記Ｓｈインタフェースを使用する手段を備え、前記複数の所定のタイプの拡張データ管理情報とは、前記ユーザデータの単数又は複数の部分に対するデータベース操作を実行するために前記データベースクライアントが前記データベースサーバを使用することを可能にする第１の情報と、前記データベースサーバが前記データベースクライアントからのユーザデータの要求に対する部分的な応答を提供することを可能にする第２の情報と、前記データベースサーバが前記データベースクライアントからの要求のフローを制御することを可能にする第３の情報と、前記データベースサーバが前記データベースクライアントから受信したユーザデータを格納するために使用されるデータベースの種類を前記データベースサーバが選択することを可能にする第４の情報と、であることを特徴とする装置が提供される。

前記装置は、前記データベースクライアントを備えてもよい。

前記装置は、前記データベースサーバを備えてもよい。

本発明の第３の態様によれば、ユニバーサル・モバイル・テレコミュニケーション・システムのホーム加入者サーバによって使用される方法であって、前記ユニバーサル・モバイル・テレコミュニケーション・システムのアプリケーションサーバから受信した、アプリケーションによって定義されたリポジトリデータを格納するために使用されるデータベースの種類を、サイズのような前記リポジトリデータの１以上の特徴、サービス指示子、及び前記データに対する操作の数に基づいて選択するステップを備えることを特徴とする方法が提供される。

前記データベースの種類には、内部のデータベースと外部のデータベースとが含まれてもよい。

前記方法は、行われた前記選択に関する情報を、前記アプリケーションサーバに対して提供するステップを備えてもよい。

前記方法は、Ｓｈインタフェースを介して前記情報を提供するステップを備えてもよい。

本発明の第４の態様によれば、ユニバーサル・モバイル・テレコミュニケーション・システムのホーム加入者サーバであって、前記ユニバーサル・モバイル・テレコミュニケーション・システムのアプリケーションサーバから受信した、アプリケーションによって定義されたリポジトリデータを格納するために使用されるデータベースの種類を、サイズのような前記リポジトリデータの１以上の特徴、サービス指示子、及び前記データに対する操作の数に基づいて選択する手段を備えることを特徴とするホーム加入者サーバが提供される。

本発明の第５の態様によれば、装置上で実行された場合に、当該装置に、本発明の第１又は第３の態様に従う方法を実行させる動作プログラムが提供される。

本発明の第６の態様によれば、装置にロードされた場合に、当該装置を、本発明の第２又は第４の態様に従う装置にする動作プログラムが提供される。

前記動作プログラムは、キャリア媒体上で搬送されてもよい。前記キャリア媒体は、伝送媒体であってもよい。前記キャリア媒体は、記憶媒体であってもよい。

前述したように、ＵＭＴＳネットワークの一部を図解する概略図である。 やはり前述したように、ＳｈインタフェースがどのようにしてＩＭＳアーキテクチャ内に適合するかを図解する図である。 どのデータタイプに対してどのＳｈ操作を実行可能であるかを述べたテーブルを示す図である。 透過データのＵＭＬ形式を図解する図である。 現在のＳｈインタフェースにおいて特定されるいくつかの問題を図解する図である。 本発明の実施形態を概略的に図解する図である。 本発明の実施形態の一部において可能な透過データ格納アルゴリズムを図解する図である。

上ではＳｈインタフェースについて手短に紹介してきた。Ｓｈインタフェースに関する更なる説明をここでは提供し、併せて、本願が特定した、Ｓｈインタフェースに関連する或る欠点についての説明を提供する。

３ＧＰＰは、どのデータタイプに対してどのＳｈ操作を実行可能であるかを指定しており、図３に示すテーブルは、データタイプごとのこれらの操作を図解している。以下の２つの汎用データタイプが規定されている（３ＧＰＰ ＴＳ２９．３２８ ｖ６．４．０、及び３ＧＰＰ ＴＳ２９．３２９ ｖ６．３．０を参照のこと）。
・透過データ： 「０」を含むデータ参照ＡＶＰ（属性−値ペア）によって特定される
・非透過データ： 「１ｘ」（「ｘ」は０と７の間で変化する）を含むデータ参照ＡＶＰによって特定される

３ＧＰＰ仕様は、文書３ＧＰＰ ＴＳ２９．３２８ ｖ６．４．０において、Ｓｈ操作は透過データ及び非透過データに対して同時に実行されてもよいし、一方のデータタイプに対してのみ実行されてもよいと述べている。一例として、Ｓｈ−Ｐｕｌｌ操作、及びＳｈ−Ｓｕｂｓ−Ｎｏｔｉｆ操作は、３ＧＰＰ ＴＳ２９．３２８において以下のように説明されている。
・指定されたユーザのための透過データ及び非透過データのうちの一方又は両方をＨＳＳから読み出す
・指定されたユーザのための特定の透過データ及び非透過データのうちの一方又は両方が更新された場合のＨＳＳからの通知に対してサブスクライブする

図３に示すテーブルによれば、メッセージの実際の構造は、文書３ＧＰＰ ＴＳ２９．３２９ ｖ６．３．０において、あらゆる所与のＳｈ操作について１つのデータタイプのみが３ＧＰＰによって許可され実装されることを提案している（即ち、上の説明における「一方」の部分のみが用意されている）。このことにより、ＡＳ又はＳＣＳは、同一の操作において２以上のデータタイプについて操作を行うことに関する複雑さを理由として、それぞれ別個のデータ参照のためにいくつかの別個のＳｈデータ要求を実行することを要求されるであろう。その結果、ネットワークトラヒックの増加が生じることになろう。というのも、ユーザごとに２以上のデータタイプに対して操作することを望む場合、ＡＳはいくつかのＳｈ操作を実行しなければならないからである。しかしながら、「両方」の部分についてもどのように処理するかがその後に提案されてきており、３Ｇアプリケーションサーバは、単一のＳｈ要求を介して複数のユーザ・データタイプを要求することが可能になり、３Ｇホーム加入者サーバ及び関連するユーザ情報サーバは、単一の応答内で複数の様々なユーザ属性（複数のデータ参照）を提供することが可能になっている（3GPP TS 29.329 V7.2.0 (2006-06) TS 3GPP; Sh Interface based on the Diameter protocol; Protocol details (Release 7)を参照のこと）。

本願によって特定される、既存のソリューションにおける問題の１つは、透過データはＨＳＳによって構文上は理解されるが意味上は理解されないという事実に関係する。透過データは、自分のサービスロジックをサポートするためにＡＳがＨＳＳ内に格納可能なデータである。一例として、ＨＳＳをリポジトリの一種として使用してＡＳがＨＳＳ内に格納するデータが挙げられる。透過データは、標準においてリポジトリデータとも呼ばれ、サービス指示子(Service-Indication)、シーケンス番号(Sequence-Number)、及びサービスデータ(Service-Data)という３つの属性を含む。この最後の属性であるサービスデータは、自分のサポートロジックをサポートするためにＡＳが定義する全ての透過データを格納する属性である。透過データのＵＭＬ（統一モデリング言語）形式が、３ＧＰＰ ＴＳ２９．３２８から持ってきた図４に描写されている。

サービスデータは構造を含むことができる。例えば、これはＸＭＬ（拡張マークアップ言語）スキームに準拠していてもよい。しかし、ＨＳＳはこの構造について何も知らない（それゆえ、「透過的な」性質なのである）。従って、現在はＡＳがサービスデータ全体のコンテンツに対して操作（読み出し、書き込み、又は通知の送信）を実行する必要がある。このことはネットワークの性能にとって極めて有害になり得るものであり、既に、ユーザごとに透過データを２００キロバイトまでしか格納しないように要求しているオペレータもある。サービスデータ内で１バイトを占める単一の値のみをＡＳが読み出したいと望む場合であっても、現在は、全体の２００キロバイトを読み出すことが要求される場合もある。同様に、サービスデータ内の１つの小さな値を更新すること（例えば、ＹＥＳをＮＯに変更すること）をＡＳが望む場合、この更新を実行するためにサービスデータ全体の新しいバージョン（即ち、２００キロバイト）送信することが必要な場合もある。サービスデータフィールド内の値の変化に関する通知をＡＳが受信することを望む場合、現在は、サービスデータ全体のコンテンツを受信することになる場合もある。サービスデータに関連する部分又は特定の属性のみをＳｈメッセージ内で搬送できないことが、この問題の根源である。

これに関連して、ユーザデータに関するＳｈインタフェースを介した現在の３ＧＰＰによる処理は、特に透過データの場合に、データが格納されている物理的なデータベースに関連する性質を考慮していない。そのような性質として、データモデリングスキーム及び言語、使用されるデータベースプロトコル、及びそのデータベースプロトコルに特有の操作が挙げられる。このため、オペレータの中には、ＳｈインタフェースをバイパスしてＨＳＳの代わりに標準化されていない商用データベースを使用する試みを推進しているものもある。このことは、標準化の視点からは望ましくない状況であると見なされる。というのも、アプリケーションサーバと透過データのリポジトリとの間（場合によっては、非透過データのリポジトリとの間も）のインタフェースの数を倍増させ（即ち、Ｓｈとそれ以外とで）てしまい、それゆえ、データベースの管理及びデータの矛盾における複雑性を増加されるからである。

本願によって特定される更なる問題は、現在のソリューションが、それぞれの特定のＳｈ操作（又は要求）が操作の性質又は緊急性に応じて異なるように処理されることを可能にするメカニズムを含んでいないことである。しかも、標準によって提案されている現在のソリューションは、ＡＳによってＨＳＳへと送信されるＳｈ要求の流れ（フロー）を制御するメカニズムを何も規定していない。このことは実際に、複数のＡＳが同一のＨＳＳに同時にアクセスすることを考慮すると、ＨＳＳにおける輻輳を生み出し得るｍのである。

上で特定した問題を、図５に要約する。

以下に更なる詳細を説明するように、本発明の実施形態は、以下の１つ以上を可能にする、Ｓｈインタフェースにおけるメカニズムを提案する。

・透過データ内のサービスデータの特定の部分、値、又は属性に対して３ＧアプリケーションサーバがＳｈ操作を実行する。このことはまた、サービスデータの属性についてのきめ細かい構文構造を提供することをも示唆する。
・実際のデータベースの性質及び特徴とユーザデータを格納するために使用されるデータモードとに関する情報を、Ｓｈプロトコルの一部として３Ｇホーム加入者サーバが提供する。これにより、例えばＳＱＬ ＪｏｉｎやＬＤＡｐ Ｃｒｅａｔｅのような、データベース固有の操作をアプリケーションサーバが実行することが可能になる。
・複数のユーザ・データタイプの要求に対する部分的な応答を３Ｇホーム加入者サーバが提供することが可能になる。
・（例えば、以前の要求に対して部分的な応答が与えられた場合に）延期された応答を３Ｇホーム加入者サーバが送信することが可能になる。
・所与のアプリケーションサーバから来る要求のフローを制御することの限界を３Ｇホーム加入者サーバが設定することが可能になる。

本発明の実施形態は、データベース操作及び他の種類の拡張データ管理情報を搬送するためのプロトコルとしてＳｈインタフェースを使用する、拡張データ管理プロトコルを提供する。これが意味することは、加入者データに対する操作を目的としてＨＳＳと通信する際にアプリケーションは依然として単一のプロトコル及びアドレス（即ち、Ｓｈインタフェース及びＨＳＳ ＵＲＬ）を使用できるが、このプロトコルの中により広範な操作及び特徴を埋め込むことができるということである。以下に説明するように、Ｓｈ Ｄｉａｍｅｔｅｒメッセージ要求におけるＡＶＰ又はフィールドの新しいセットが提案される。この新しいセットは、ＨＳＳサーバの全体的な技術上の利点を高めるために、Ｓｈインタフェースが機能及び特徴の新しいセットを組み込むことを可能にするものである。

本発明の実施形態を図６に概略的に示す。図６は、両者の間で拡張データ管理情報を搬送するためにＳｈインタフェースを使用する、アプリケーションサーバ（データベースクライアント）２２とホーム加入者サーバ（データベースサーバ）２０とを示す。

この目的のために、以下に示す多数の新しいＡＶＰを提案する。
・被影響データ参照ＡＶＰ。このＡＶＰは、要求によって影響を受けるデータタイプの数を示すことになる。これは以下の値を取り得る。
・Ｓｉｎｇｌｅ： データタイプを示す（この場合、１つのみ）。
・Ｃｏｍｂｉｎｅｄ： どの別々のデータタイプが操作によって影響を受けるかを示す。これは、どのデータタイプに対して操作が最初に行われなければならないかなどを示す「順序(order)」属性を含み得る。
・透過データタイプリストＡＶＰ。このＡＶＰは、要求によって影響を受ける透過データタイプの数を一覧にする（それぞれの影響を受けるサービス指示子(Service Indicator)を示す）。これは、要求が「Ｓｉｎｇｌｅ」及び「透過データタイプ」に関連するということを以前のＡＶＰが表す場合にのみ、存在することになる。
・非透過データタイプリストＡＶＰ。このＡＶＰは、要求によって影響を受ける非透過データタイプの数を一覧にする。これは、数値（要求内に存在する非透過データタイプの数）であってよく、要求が「Ｓｉｎｇｌｅ」及び「非透過データタイプ」に関連するということを以前のＡＶＰが表す場合にのみ、存在することになる。
・優先度ＡＶＰ。このＡＶＰは、それぞれの特定のデータ参照セット内に含まれ、様々なデータ参照について要求の中で処理される必要のある順序を示す。これにより、ＨＳＳは、トラヒックが多い場合は低い優先度に関連するＳｈ要求を破棄して、より高い優先度を持つ要求にのみ応答することが可能になる。単一のＳｈ操作において全てのデータ参照が同一の優先度を持つことを回避するために、同一の要求内では或る優先度値の繰り返しは許可されないことが要求されてもよいであろう。
・サービスデータ特定要素パスＡＶＰ。これは、透過データに関連する操作のために存在し得る。パスは、所与のサービス指示子(Service Indicator)及びユーザの透過データ内に含まれるデータのブロックにおける、特定の要素、属性、フィールド、値、又はバイナリ位置を特定する。このようにして、Ｓｈ操作は、サービスデータ全体のコンテンツではなく、サービスデータのその部分にのみ影響を与えるように指定可能である。サービスデータ要素パスの実際の形式は、（透過データがＸＭＬスキームに従う場合は）Ｘｐａｔｈでもよいし、（透過データがＬＤＡＰ ＤＩＴに従う場合は）ＬＤＡＰ ｐａｔｈでもよいし、単純にサービスデータフィールドの中で検索される値でもよい。異なるシナリオに対しては他の可能性が適用されるであろう。
・フロー制御ＡＶＰ。所与のＡＳからの要求のフローを制御するために、ＨＳＳは全ての応答の中に、所与の期間にＡＳが発行すべき要求の最大数を示したり、又は、（関与する他の処理の結果として）「Ｃｏｍｂｉｎｅｄ」データタイプの操作が許可されるか否かを示したりするＡＶＰを含めることができる。ＡＳがその限界を超えた場合、いくつかの要求が拒絶されたり、又は、いくつかの要求が遅い応答時間に直面したりするということに、ＡＳは気付くことができる。より高い優先度を持つ要求が最初に処理されることになろう。

（限定はしないが特に透過データの場合に）ＨＳＳ内に格納されているユーザデータに対してより広範なセットの操作をアプリケーションサーバが実行することを可能にするために、以下の追加のＳｈ ＡＶＰを提案する。
・データモデルスキームＡＶＰ。このＡＶＰは、関連するデータスキームについて言及する。これは単に、データモデルが格納されている場所を指し示すＵＲＬ又はＵＲＮであってもよい。例えば、これはＸＭＬデータスキームを指し示してもよいし、ＬＤＡＰデータ情報ツリー（ＬＤＡＰ ＤＩＴ）を指し示してよいし、それ以外を指し示してもよい。この情報によって、アプリケーションサーバは、上述した「サービスデータ特定要素パス」ＡＶＰにおける詳細な（又は存在する(populate)）パスを提供することが可能になる。
・バックエンドデータベースタイプＡＶＰ。このＡＶＰは、ユーザデータを格納するＨＳＳによって使用されるバックエンドデータベースタイプ（並びにプロトコル）を示す。この値が空の場合、この情報はアプリケーションサーバにとって利用可能ではない。このＡＶＰに関する典型的な値は、ＬＤＡＰｖ２、ＬＤＡＰｖ３、ＳＱＬ−１９９９、ＳＱＬ−２００３などである。
・バックエンドデータベース固有操作ＡＶＰ。このＡＶＰは、バックエンドデータベースによって使用されるプロトコルに特有の操作を示す。これにより、アプリケーションサーバは、Ｓｈインタフェースによって現在規定されている極めて縮小されたセットの場合よりも広範なデータベース操作を（ＨＳＳによって許可されれば）実行することが可能になる。

アプリケーションサーバがＳｈインタフェースを介してこれらのＡＶＰを使用するために、アプリケーションサーバは、例えばどれが正しいデータモデルスキームであるか、どのバックエンドデータベースがＨＳＳによって使用されているか、そしてどの操作がサポートされているかなどの、或る種のポイントを認識していなければならない。原則として、この情報はそれぞれのアプリケーションサーバによってオフラインで設定され得る。

これらのＡＶＰの例は、以下の通りである。
・データモデルスキームＡＶＰ： ｓｑｌ＿ｔａｂｌｅ１、ｓｑｌ＿ｔａｂｌｅ２
・バックエンドデータベースタイプ： ＳＱＬ
・バックエンドデータベース固有操作：
ＳＥＬＥＣＴ ｆｉｅｌｄ１，ｆｉｅｌｄ２，ｆｉｅｌｄ３
ＦＲＯＭ ｓｑｌ＿ｔａｂｌｅ１
ＬＥＦＴ ＪＯＩＮ ｓｑｌ＿ｔａｂｌｅ２ＯＮ ｓｑｌ＿ｔａｂｌｅ１．ｋｅｙｆｉｅｌｄ＝ｓｑｌ＿ｔａｂｌｅ２．ｆｏｒｅｉｇｎ＿ｋｅｙｆｉｅｌｄ

ＨＳＳがＡＳからのデータ要求に対する部分的な応答を提供することを可能にするために、以下のメカニズムを提案する。

ＨＳＳが複数のデータタイプの要求を受信すると、ＨＳＳは、要求された全ての情報要素を（入手可能であるならば）まとめることが可能であるか、それとも、いくつかの情報要素は他よりも長い処理時間を必要とするかを評価する（後者は、例えば、他のネットワークノードへ要求を送信することを含有することが理由である。このことが要求において発生するのは、回線交換方式及びパケット交換方式のうちの少なくとも一方のユーザの状態及び場所が要求され、ＨＳＳがその情報についてＨＬＲに尋ねる必要がある場合である）。

全ての情報が即座に返され得る訳ではない場合、ＨＳＳは、部分的な応答を生成する。部分的な応答は、入手可能な情報要素と、残りの情報要素についてＡＳが何を予期すべきであるかに関する指示子(indication)とを伴う。そのような指示子は、ＡＳに対して、（例えば、ＨＳＳにおいてその情報を入手可能でなかったり、又は、ＨＳＳがその情報を取得する術を持たなかったりすることが原因で）その情報の返答を妨げる永続的な状態が存在するか、それとも、その情報が別のメッセージ内で送信される予定であるかを説明する。

延期された応答は、１イベントの通知として処理され得る。通知は、要求された情報を含めることがエラーによって妨げられた場合であっても、送信され得る。

ＡＳとＨＳＳとの間のデータ管理インタフェースに影響を与える上の改良に加えて、ＨＳＳは、アプリケーションによって定義された透過データを動的に格納し、基準のセットに基づいて別のデータ格納技術（即ち、ディスクデータベース、ファイルシステム、メモリ等）に再分配することを可能にする、データ格納決定のメカニズム及びアルゴリズムも含んでもよい。（アプリケーションサーバは、何らのプロビジョニングシステムも使用せずに、新しい透過データをＳｈインタフェースを介してＨＳＳ内に直接定義して作成することができる。）

可能な透過データ格納アルゴリズムの一例を、図７に提供する。内部のＨＳＳメカニズムは、アプリケーションによって定義された透過データのそれぞれのタイプにとってどのデータ格納技術が最も適切であるかを選択する。このメカニズムは、どこにデータが格納されたかを制御し続ける。また、状況が変化した場合に透過データを動的に再分配することもできる。例えば、或るユーザセット(a set of user)のための透過データに関するトラヒックが極めて高くなり、データが最初はディスクに格納されていた場合、ＨＳＳのデータ格納決定メカニズムは、新しい状況を再評価し、より適切な高速アクセスデータベースへとデータをシフトさせる。

本発明の実施形態は、１以上の以下の利点をもたらす。

ＡＳ及びＨＳＳによって課された負荷と要求を処理する優先度とを制御するメカニズムを含めることは、ＨＳＳの効率性という点での利点を表す。ＨＳＳは、自分自身を保護し、実行しなければならない重要なアプリケーションの性能が所与の閾値を下回らないことを保証する。

内部のデータ格納決定アルゴリズムをＨＳＳに含めることにより、ＨＳＳは、自分の全体の性能と自分のリソースの利用とが常に最適になることを保証するために、多様な異種のデータ格納リソースを動的に使用することが可能になる。このアプローチは、他の技術において現在仕様が定められている全体のデータ管理アーキテクチャに適合するものである。

アプリケーションサーバが透過データに対してきめ細かい操作を実行することを可能にすると共に、データが格納されているデータベースの種類、使用されているプロトコル、及び従っているデータモデルをＡＳに対して知らせるということは、ネットワーク上でより少ないデータしか伝送されないということを意味し、しかも、アプリケーションが自分のリポジトリとしてＨＳＳを使用することしか要求されないことを保証する。

Ｓｈインタフェースには、その価値を高める操作のセットが備えられる。数ある種類の情報の中でもデータベース操作を搬送するプロトコルとしてＳｈインタフェースを使用する拡張データ管理プロトコルが提案される。これが意味することは、加入者データに対する操作を目的としてＨＳＳと通信する際にアプリケーションは１つのプロトコル及びアドレスを知る必要があるのみであるのに、このプロトコルの中に広範な操作及び特徴を埋め込むことができるということである。これにより、アプリケーションサーバがＨＳＳをバイパスして複雑な格納及び取り出しのデータベース操作を可能にする必要性が減じられる。このことは、標準化にとって利点である。

既存のソリューションには、複数のデータタイプの要求を可能にする利点と、負荷、要求の処理の優先度、及び部分的な応答並びに延期された応答を返す可能性を制御するメカニズムとを組み合わせたものは、存在しない。加えて、単一のプロトコル（この場合、Ｓｈインタフェース）を介して多数のデータバース操作を送信する可能性も、存在しない。データベース格納メカニズムを動的に選択する可能性も存在しない。

上の説明はＨＳＳを参照して本発明の実施形態を説明してきたが、本発明は、データベースサーバがＨＳＳと呼ばれようと呼ばれまいと、そしてデータベースクライアントがアプリケーションサーバと呼ばれようと呼ばれまいと、データベースサーバがＳｈインタフェースを使用してデータベースクライアントと通信する一般的なシナリオに対して適用可能であるということが理解できよう。

１以上の上述したコンポーネントの動作は、デバイス又は装置の上で動作するプログラムによって制御可能であるということが理解できよう。そのような動作プログラムは、コンピュータ可読媒体に格納されてもよいし、或いは、例えば、インターネットのウェブサイトから提供されるダウンロード可能なデータ信号のような信号内に収録されてもよい。添付の請求の範囲は、それ自体で動作プログラムをカバーするものとして、又は、キャリア上の記録として、又は、信号として、又は、何らかの他の形式として、解釈されるものである。

Claims (33)

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. 前記キャリア媒体は、記憶媒体であることを特徴とする請求項３１に記載の動作プログラム。