JP4638816B2

JP4638816B2 - 初期フィルタ条件を展開、準備、及び記憶するための方法

Info

Publication number: JP4638816B2
Application number: JP2005371535A
Authority: JP
Inventors: ハッセオリヴァー; ムラカミカズタカ
Original assignee: アルカテル−ルーセントユーエスエーインコーポレーテッド
Priority date: 2004-12-27
Filing date: 2005-12-26
Publication date: 2011-02-23
Anticipated expiration: 2025-12-26
Also published as: DE602005000984D1; KR20060074847A; US20060140385A1; DE602005000984T2; EP1675347B1; CN1798160A; CN1798160B; US7643626B2; EP1675347A1; KR101208933B1; JP2006217574A

Description

本発明は、オールＩＰモバイル・ネットワーク（all-IP Mobile Network）に関し、より詳細には、３ＧＰＰＩＭＳネットワーク中における、初期フィルタ条件を展開し、準備し、記憶するための方法に関する。

３ＧＰＰ（3^rd Generation Partnership Project第３世代パートナーシップ・プロジェクト）は、現在のところＩＭＳ（IP Multimedia SubsystemＩＰマルチメディア・サブシステム）、すなわち次世代オールＩＰモバイル・ネットワークのためのアーキテクチャを定義している。ＣＤＭＡ（code division multiple access符号分割多重接続）分野において、３ＧＰＰ２（3^rd Generation Partnership Project 2第３世代パートナーシップ・プロジェクト２）は、将来のオールＩＰＣＤＭＡ２０００ネットワークについて、ＭＭＤ（Multimedia Domainマルチメディア・ドメイン）の名の下の同じアーキテクチャを適合させてきている。このＩＭＳアーキテクチャは、商用無線ネットワークの特有のニーズに対してＳＩＰフレームワークを適用することによって、ＳＩＰ（Session Invitation Protocolセッション招待プロトコル）に基づいたものになっている。これらのニーズは、とりわけアクセス・ネットワークとコア・ネットワークの両方、負荷バランシング、ならびに請求書発行および課金についてのサポートにおけるＱｏＳ（Quality-of Serviceサービス品質）制御を含んでいる。

簡潔に言えば、ＩＭＳサービスは、専用のアプリケーション・サーバ上で実行され、これらのユーザのコール制御プロキシ（call control proxy）によって実行するためにトリガされる。コール制御プロキシは、このそれぞれのサービスに関連するトリガ条件にマッチするＳＩＰシグナリング・メッセージを受信するときに、サービスの実行をトリガする。すなわち、あるユーザのためのＳＩＰメッセージがこのユーザのコール制御プロキシに到達するたびごとに、このプロキシは、このユーザが加入しているすべてのサービスのトリガ条件に対してこのメッセージをチェックする。満たされ開始されるトリガ条件ごとに、このサーバは、この実際のサービス・ロジックを実行するアプリケーション・サーバに制御を任せる。トリガ・ポイントは、いわゆるｉＦＣ（initial Filter Criteria初期フィルタ条件）の主要コンポーネントである。ユーザが加入しているサービスごとに、これらのユーザ・プロファイルは、１つのｉＦＣを含んでいる。各ｉＦＣは、少なくとも１つのトリガ・ポイント、連絡すべきアプリケーション・サーバのアドレス、万一このアプリケーション・サーバに到達できない場合におけるデフォルト処理、ならびにサービスがトリガされるとすぐに、このコール制御プロキシがこのアプリケーション・サーバに送信する何らかのユーザ特有のサービス・データを含んでいる。このＩＭＳは、初期フィルタ条件を形成するための言語、これらのｉＦＣが２つのネットワーク・エレメント間で交換されるこのＸＭＬ方言、このサービス・トリガリング・メッセージのフォーマット（ＳＩＰ）、およびアプリケーション・サーバが、ＨＳＳ（Home Subscriber Serverホーム加入者サーバ）、すなわち中央加入者データ・リポジトリからのユーザ特有のサービス・データにアクセスするためのメカニズムを含めて、サービス実行のためのフレームワークを指定する。しかし、このＩＭＳは、具体的なサービスを指定することもないし、また具体的なトリガ条件を指定することもない。どのような特定のサービスを提供するか、どのようにしてこれらのサービスを実施し、準備し、トリガするかについては、このＩＭＳの活動の範囲外である。かかるアーキテクチャにより、これらのサービス・プロバイダにとってのサービスの差別化についてのかなりの柔軟性および機会が可能になる。

マイナス面については、この柔軟性により、ＩＭＳサービスの展開および準備（ならびに特にその関連するｉＦＣ）が複雑で困難なタスクになってしまう。この３ＧＰＰが（サービスの展開および準備でなくサービスの実行に焦点を当てて）、ｉＦＣを純粋にユーザ・レベルの概念として定義するので、これは特に当てはまる。しかし、現在のところ、ＩＭＳサービスの展開および準備についての、また特にこれらに関連するｉＦＣについての効率的な方法およびシステムは存在していない。すなわち、現行のアーキテクチャにおいては、ｉＦＣは、すべてのユーザにとって、ユーザが加入しているサービスごとに記憶する必要がある。

本発明は、ＩＰマルチメディア・サブシステム（ＩＭＳ）サービスの効率的な展開および準備のための方法を提供することにより、従来技術の様々な欠点に対処している。より詳細には、本発明は、ｉＦＣをユーザに特有の部分と、ユーザに独立した部分に分解することにより、例えばモバイルＩＰネットワークにおける初期フィルタ条件（ｉＦＣ）を展開し、準備し、記憶するための方法を提供している。

本発明の一実施形態においては、トリガ・ポイント・テンプレートが、サービス展開時にこのＨＳＳと呼ばれる中央ＩＭＳ加入者ベース上で、定義され記憶される。サービス加入時に、ユーザ特有のパラメータが準備され、このＨＳＳからこのＳ−ＣＳＣＦへのユーザ・プロファイル・ダウンロードの時に、トリガ・ポイント・テンプレートおよびユーザ・パラメータは、具体的なトリガ・ポイントにアセンブルされる。この比較分析により、本発明のトリガ・ポイント・テンプレートは、サービスを準備するもっともな方法であるだけでなく、ストレージ効率とランタイム効率の両方の観点からも非常に効率的なメカニズムであることが示される。

本発明の一実施形態によれば、プロバイダ・ネットワークにおけるそれぞれのユーザ・サービスの展開および準備についての初期フィルタ条件（ｉＦＣ）の効率的ストレージのための方法は、このストレージ・デバイスにアクセスすることができ、これらのサービスの実行を望んでいるすべてのユーザについて、それぞれのユーザ・サービスに関連した各ｉＦＣを、１回しかストレージ・デバイスに記録する必要がないように、これらのｉＦＣをユーザ特有のサービス・パラメータと、このそれぞれのユーザ・サービスの実行に関連したグローバル・サービス・データに分解するステップを含んでいる。本発明のこの実施形態においては、プレースホルダ（placeholder）が、このユーザ特有のパラメータごとに記憶され、これらのユーザ特有のパラメータは、このサービスの実行時に、各ユーザによる各ユーザ・サービスの実行のためにこれらのｉＦＣにそれぞれ提供される。
本発明の教示については、添付図面に関連して以下の詳細な説明を考察することにより、簡単に理解することができる。

理解を容易にするために、同じ参照数字を、可能な場合には使用して、これらの図面に共通となる同じエレメントを指し示している。
本発明は、ＩＰマルチメディア・サブシステム（ＩＭＳ）サービスの効率的な展開および準備のための方法を有利に提供している。すなわち、本発明は、例えばモバイルＩＰネットワークにおいて初期フィルタ条件（ｉＦＣ）を展開し、準備し、記憶する方法の様々な実施形態を提供している。本発明の様々な実施形態は、本明細書中においてはモバイルＩＰネットワークに関して説明されているが、本発明のこれらの特定の実施形態は、本発明の範囲を限定するものとして取り扱うべきではない。本発明の概念は、ＩＭＳサービスを利用した実質的に任意のネットワーク・アーキテクチャにおいて適用できることが、当業者には理解され、また本発明の教示によって通知されよう。

一般的に、ＩＭＳネットワークは、必ずしもそのすべてが本発明の説明の文脈に関連するとは限らない多岐にわたるネットワーク・エレメントを含んでいる。したがって、以下の説明は、サービスの実行において役割を果たし、または本発明の例示の実施形態を説明する目的のための一般的なＩＭＳアーキテクチャの理解に不可欠なこれらのエレメントに限られる。図１は、本発明の概念を適用することができるＩＭＳネットワーク１００の高位ブロック図を示している。図１のＩＭＳネットワーク１００は、ホーム加入者サーバ（ＨＳＳ）１２０およびアプリケーション・サーバ（ＡＳ）１３０を含んでいる。図１は、さらにモバイル端末１５２を含む訪問先（visited）ＩＭＳドメイン１５０を示している。

図１のＩＭＳネットワーク１００および訪問先ＩＭＳドメイン１５０は、例証としてセッション招待プロトコル（ＳＩＰ）プロキシとして動作し、ＳＩＰプロキシを使用してモバイル端末１５２と、またこのＩＭＳネットワークの外部の他のエレメント（図示せず）と互いに通信を行うＣＳＣＦ（Call Session Control Functionコール・セッション制御ファンクション）をさらに含んでいる。より詳細には、図１のＩ−ＣＳＣＦ（Interrogating CSCF問合せＣＳＣＦ）１１２は、所与のＩＭＳドメインに対する進入ルータ（ingress router）（すなわち、このネットワークの外部からの任意の通信についての最初の連絡ポイント）としての機能を果たす。一般的に、図１のＩＭＳネットワーク１００など、あらゆるＩＭＳネットワークは、少なくとも１つのＩ−ＣＳＣＦ１１２を含んでいるが、ＩＭＳネットワークが複数のＩ−ＣＳＣＦを含むことも可能であり、これらのＩ−ＣＳＣＦは、ＤＮＳ（Domain Name Serverドメイン名サーバ）中でドメインのＳＩＰプロキシとしてリストアップすることができる。

さらに、あらゆるユーザには、登録時に各ＳＩＰレジストラ（SIP registrar）としての役割を果たすＳ−ＣＳＣＦ（Serving CSCFサービングＣＳＣＦ）１１４が割り当てられる。各着信ＳＩＰメッセージは、このユーザの各Ｓ−ＣＳＣＦ１１４を横切り、このＳ−ＣＳＣＦは、必要な場合および必要なときに、サービス実行を任せ、このＳＩＰメッセージをＰ−ＣＳＣＦ１５４に伝える。同様に、モバイルを起源とするメッセージもまた、同様にサービスを実行するためにユーザのＳ−ＣＳＣＦ１１４に転送される。Ｓ−ＣＳＣＦ１１４は、データを記憶し、サービス実行を実施するための関連するサーバ１１０を有する（以下でさらに詳細に説明する）。

図１２は、図１のＩＭＳネットワーク１００中で使用するのに適したＳ−ＣＳＣＦサーバの一実施形態の高位ブロック図を示している。図１２のＳ−ＣＳＣＦサーバ１１０は、プロセッサ１２１０、ならびにこれらのアルゴリズムおよび制御プログラムを記憶するためのメモリ１２２０を備える。プロセッサ１２１０は、電源、クロック回路、キャッシュメモリなど、従来のサポート回路１２３０、ならびにメモリ１２２０に記憶されたソフトウェア・ルーチンを実行する際に役立つ回路と協力する。したがって、本明細書中でソフトウェア・プロセスとして説明している一部のプロセス・ステップは、ハードウェア内に、例えばプロセッサ１２１０と協力して様々なステップを実施する回路として実施することもできることが企図されている。Ｓ−ＣＳＣＦサーバ１１０はまた、Ｓ−ＣＳＣＦサーバ１１０と通信を行う様々な機能エレメント間のインターフェースを形成する入出力回路１２４０も含んでいる。

図１２のＳ−ＣＳＣＦサーバ１１０は、プログラムして、本発明による様々な制御ファンクションを実施する汎用コンピュータとして示されているが、本発明は、ハードウェアの形でも、例えばＡＳＩＣ（application specified integrated circuit特定用途向け集積回路）として実施することもできる。したがって、本明細書中で説明しているプロセス・ステップは、ソフトウェア、ハードウェア、またはこれらの組合せによって等価的に実施されるものとして広範に解釈すべきことが意図されている。

図１に戻って参照すると、Ｐ−ＣＳＣＦ（Proxy CSCFプロキシＣＳＣＦ）１５４は、モバイル端末１５２にトポロジ的に最近接のプロキシである。一般的に、Ｐ−ＣＳＣＦ１５４は、基礎となっているＧＰＲＳ（General Packet Radio Service汎用パケット無線サービス）ネットワーク（図示せず）のＧＧＳＮ（Gateway GPRS Support NodeゲートウェイＧＰＲＳサポート・ノード）と一緒に配置される。Ｐ−ＣＳＣＦ１５４は、訪問先ドメイン１５０中で実行され、このアクセス・ネットワーク中のＱｏＳ制御や課金記録の生成などのサービスを担っている。

ホーム加入者サーバ（ＨＳＳ）１２０は、図１のＩＭＳネットワーク１００など特定のＩＭＳネットワークのためのすべての加入者データおよびこれらの加入者のサービス・データの中央リポジトリである。ＨＳＳ１２０は、各登録ユーザについての、現在このユーザにサービスを行っている各Ｓ−ＣＳＣＦ１１４のアドレスも含んでいる。このようにして、ＨＳＳ１２０は、Ｉ−ＣＳＣＦ１１２を助けて、着信コールについての適切なＳ−ＣＳＣＦ１１４を見出すことができる。さらに、ＨＳＳ１２０は、登録時にＳ−ＣＳＣＦ１１４に対して各ユーザ・プロファイルをダウンロードし、要求に応じてこのユーザのサービス・データをアプリケーション・サーバ（ＡＳ）１３０に戻す。

アプリケーション・サーバ（ＡＳ）１３０は、このサービスについてのコードのホストとして機能し、これらのサービスを実行する。より詳細には、サービスは、コール転送、コール締出し（call barring）、ボイス・メールなどのよく知られているサービスだけでなく、メディア・ストリーミング（media streaming）、アクセス・ネットワーク選択、自動再接続など、より進んだまたはＩＰ中心のサービスも含めて標準的なコール・セットアップ動作を超えるすべての機能となる。サービス実行は、Ｓ−ＣＳＣＦ１１４がＳＩＰ招待メッセージ（SIP INVITE message）をＡＳ１３０に送信することによってトリガされる。サービス実行後に、ＡＳ１３０は、他のＳＩＰ招待メッセージを用いて各Ｓ−ＣＳＣＦ１１４に対して応答する。ＡＳ１３０は、要求に応じてＨＳＳ１２０からダウンロードすることができるサービス・データについてのリポジトリとしてＨＳＳ１２０を使用することができる。

このＩＭＳサービス実行モデルは、登録およびコール・セットアップを調べることにより、最もよく説明される。登録時に、登録中のユーザのサービス・プロファイルが各Ｓ−ＣＳＣＦ１１４にダウンロードされるので、登録は重要である。次いで、コール・セットアップ時に、このユーザ・サービスを実行することができる。図２ａは、図１のＩＭＳネットワーク１００中のＩＭＳ登録の高位機能図を示しており、それに対して図２ｂは、図１のＩＭＳネットワーク１００中の着信コール・セットアップの高位機能図を示している。しかし、両方のシナリオは、共に簡略化されていることに留意されたい（すなわち、登録認証については、それが本発明を開示する目的には関連しないので、示されていない）。

図２ａに示すように、登録中に、モバイル端末１５２は、訪問先ネットワーク１５０中のローカルＰ−ＣＳＣＦ１５４と連絡をとり、このＰ−ＣＳＣＦのアドレスについては、このモバイル端末は、ＩＰ接続確立時に知ったものである。Ｐ−ＣＳＣＦ１５４は、登録すべきＳＩＰＵＲＩ（Uniform Resource Identifierユニフォーム・リソース識別子）のドメイン名を調べ、このＤＮＳ（図示せず）におけるこのドメインについてのＩ−ＣＳＣＦ１１２を調べ、このＳＩＰ登録要求（SIP REGISTER request）をモバイル端末のホーム・ドメインに転送する。このＩ−ＣＳＣＦは、ＨＳＳ１２０からユーザ情報をダウンロードして、このユーザがすでに登録済みであるか否かを判定し、このユーザに対してサービスを行うことができるようにするためにはＳ−ＣＳＣＦがどのような機能を実施する必要があるかを知る。最初の登録であると仮定すると、次いでこのＩ−ＣＳＣＦは、適切なＳ−ＣＳＣＦを選択し、この登録メッセージをこのＳ−ＣＳＣＦに転送する。この新しく割り当てられたＳ−ＣＳＣＦは、そのアドレスをＨＳＳ１２０に登録し、各ユーザ・プロファイルをダウンロードする。このプロファイルは、このＰ−ＣＳＣＦのアドレスと一緒にＳ−ＣＳＣＦのローカル・サーバ１１０に記憶される。

図２ｂに示すように、コール・セットアップ中に、着信コールは、まずＳＩＰ着信プロキシとして機能するＩ−ＣＳＣＦ１１２に到着する。Ｉ−ＣＳＣＦ１１２は、このユーザのＳ−ＣＳＣＦのアドレスについてＨＳＳ１２０に問い合わせ、この招待要求（INVITE request）を各Ｓ−ＣＳＣＦに転送する。このＳ−ＣＳＣＦは、このユーザが加入している、すべてのサービスのトリガ条件に対してこの招待メッセージ（INVITE message）をチェックする。識別されたトリガ条件ごとに、このＳ−ＣＳＣＦは、（優先順位付けされ、シーケンシャルな順序で）サービスの実行をＡＳ１３０に任せる。必要な場合には、ＡＳ１３０は、サービス・データをＨＳＳ１２０からダウンロードすることができる。すべてのサービスが実行された後に、このＳ−ＣＳＣＦは、招待要求をこのＰ−ＣＳＣＦに転送し、このＰ−ＣＳＣＦは、次にこの招待要求をモバイル端末１５２に伝える。このモバイルを起源とするコールは、これらのコールが遠端の宛先に向かって経路指定される前に、このＰ−ＣＳＣＦからこのＳ−ＣＳＣＦへと転送されることに留意されたい。この結果、モバイルを起源とするコールについてのサービス実行は、前述のモバイル終端される場合と実質上同様にして機能する。

前述のように、Ｓ−ＣＳＣＦは、登録時にユーザ・プロファイルをＨＳＳ１２０からダウンロードする。ユーザごとのユーザ・プロファイルは、とりわけ加入サービスごとの初期フィルタ条件（ｉＦＣ）を含んでいる。図３は、本発明の一実施形態によるＩＭＳｉＦＣの高水準のＵＭＬ（Unified Modeling Language統一モデリング言語）表現を示している。図３のｉＦＣ３００に示すように各ｉＦＣは、割り当てられた優先順位３０２を有する。優先順位値３０２を使用して、このＳ−ＣＳＣＦにおいてＳＩＰメッセージを受信するとすぐにいくつかのｉＦＣが識別される場合には、サービスを実行する順序を決定する。各ｉＦＣは、このサービスを実行するＡＳ名からなるちょうど１つのApplication Server（アプリケーション・サーバ）コンポーネント３０４、このアプリケーション・サーバに連絡することができない場合に、このセッションをリリースすべきか否かを示すDefault Handling（デフォルト処理）コンポーネント、および場合によってはService Infoキャラクタ・ストリングを含むService Information（サービス情報）コンポーネント３０６をさらに含んでいる。このＳ−ＣＳＣＦは、サービス実行がトリガされるときに、このストリングをこのＡＳに送信する。このService Info（サービス情報）キャラクタ・ストリングを使用して、コール転送番号などのユーザ特有のサービス・データをこのＡＳに対して移送することができる。

各ｉＦＣは、例えばゼロまたは１のトリガ・ポイント３０８をさらに含んでいる。トリガ・ポイントは、場合によってはＳＩＰメッセージ上の複雑な論理状態となる可能性がある。技術的には、トリガ・ポイントは、ＣＮＦ（conjugative normal form論理積標準形）またはＤＮＦ（disjunctive normal form論理和標準形）（すなわち、原子的状態（atomic condition）のＯＲ集合のＡＮＤ集合、または原子的状態のＡＮＤ集合のＯＲ集合）の形のブール表現である。このConditionTypeCNF（状態タイプＣＮＦ）フィールドは、これらの２つの標準形のいずれかを示す。トリガ・ポイントは、単一の原子的状態を表す１つまたは複数のサービス・ポイント・トリガ３１０から構成される。例えば、このConditionNegated（否定状態）フィールドは、否定の可能性を示し、このGroup（グループ）フィールドは、この原子的状態が参加するすべての集合（ＣＮＦについてのＯＲ集合、ＤＮＦについてのＡＮＤ集合）をリストアップする。論理状態の正規化では、異なるＯＲ集合またはＡＮＤ集合についての同じ原子的状態が、複数回発生する傾向があるので、これは冗長性を低下させる有用な特徴である。

一般的に、５つのあらかじめ定義された原子的状態、すなわち（１）メッセージの要求ＵＲＩについての原子的状態、（２）ＳＩＰメソッドについての原子的状態、（３）ＳＩＰヘッダの有無ならびに内容についての原子的状態、（４）このサービスを着信コールまたは発信コールのいずれについて実行すべきか、というセッション・ケースについての原子的状態、および（５）このメッセージのＳＤＰ（Session Descriptionセッション記述）フィールドの内容についての原子的状態が存在する。このＨＳＳからこのＳ−ＣＳＣＦへのｉＦＣのダウンロードについてのオンライン（on-the-wire）フォーマットとして、３ＧＰＰは、以上の構造を１組のＸＭＬエレメントにマッピングするＸＭＬ（Extensible markup Language拡張マークアップ言語）方言を定義している。このＨＳＳと、このＳ−ＣＳＣＦの両方についての内部ストレージ・フォーマットについては、３ＧＰＰ規格の範囲外であり、プロバイダに任されている。明らかに、どのようなデータが、ｉＦＣを含んでおり、ＨＳＳとＳ−ＣＳＣＦの間で、どのようなフォーマットでデータが交換されるかに３ＧＰＰの主要な焦点は当てられている。しかし、プロバイダの観点からは、同様に重要な問題は、このデータがどのようにして準備されるかである。これについての発明の方法が、本明細書中において以下で本発明者らによって提示される。

一部のサービスでは、このサービスに加入するすべてのユーザが使用するトリガ・ポイントを定義することが可能である。以下は、かかるあらかじめ定義されたトリガ条件の一実施例である。以下の実施例は、（疑似自然言語で）ユーザのすべての発信の（モバイルを起源とする）コールについてのサービス実行をトリガする条件を記述している。
（１）Method = "INVITE" and Session Case = "Originating".

しかし、他のサービスは、サービス展開時に明白には知られていないユーザ特有の設定も含むトリガ条件を必要とする。両方の種類のサービスをカバーするために、本発明者らは、本明細書中で、本発明によるトリガ・ポイント・テンプレート（ＴＰテンプレート）を使用することを提案している。すなわち、本発明者らは、少なくともストレージ効率およびランタイム効率が改善されるように、初期フィルタ条件の記憶、準備、およびダウンロードを実行するためにｉＦＣをユーザ特有の部分とユーザに独立な部分とに分解することを提案している。コールが特定のユーザ定義された呼出し側から着信するときに、トリガすべきコール・スクリーニング・サービスの実施例について考察する。サービス展開時に、スクリーニングすべき呼出し側の名前は知られていないが、このコール・スクリーニング・サービスに関連するトリガ・ポイントの一般的な構造については知られている。さらに明確にするためには、このコール・スクリーニング・サービスは、<user-param>をユーザの実際の設定のためのプレースホルダとして、以下の条件の下で、トリガする必要がある。このプレースホルダは、サービス加入時に入力される（fill in）。このトリガ・ポイント・テンプレートは、以下のように特徴づけることができる。
（２）Method = "INVITE" and Session Case = "Terminating" and (Header = "from" and content = <user-param>).
上記「ホール（hole）を有するトリガ・ポイント」は、本発明者らがトリガ・ポイント・テンプレート（ＴＰテンプレート）として定義するものの例示の実施形態であり、これは、このトリガ・ポイントが、１つ（または複数）のプレースホルディング・パラメータ（place-holding parameter）を１つ（または複数）の実際の値で置き換えることによって実際のトリガ・ポイントになるようにインスタンス化することができるテンプレートを定義するからである。

以下は、トリガ・ポイントの一部分がユーザに独立であり、一部分がユーザに特有である例示の部分リストである。
１．このトリガ・ポイントの構造（すなわち、ある種の原子的状態の有無）は、ユーザに独立である。したがって、このTrigger Point（トリガ・ポイント）コンポーネントのフィールドConditionTypeCNF、ならびにConditionNegatedおよびService Point Trigger（サービス・ポイント・トリガ）のグループは、同様にすべてユーザに独立であり、これは、これらがこのトリガ・ポイントの構造に関連しているからである。
２．原子的トリガ条件のレベルでは、それぞれ、SIP Method（ＳＩＰメソッド）、SIP Header（ＳＩＰヘッダ）、Session Case（セッション・ケース）、およびSession Description（セッション記述）というこれらのコンポーネント内のフィールド、SIPMethod、Header（ヘッダ）、SessionCaseおよびLine（ライン）は、構造的であり、したがってユーザに独立である。
３．このRequest URI（要求ＵＲＩ）コンポーネントのRequestURIフィールド、このSIP Header（ＳＩＰヘッダ）コンポーネントのContent（内容）フィールド、およびこのSession Description（セッション記述）コンポーネントのContentフィールドはすべて、場合によってはユーザ特有のデータを含む可能性がある。

図４は、本発明の一実施形態によるトリガ・ポイント・テンプレートの高水準の統一モデリング言語（ＵＭＬ）表現を示している。図４のトリガ・ポイント・テンプレート４００は、上記パラグラフ３にリストアップしたユーザ特有のデータ・フィールドなど、ユーザ特有のデータ・フィールドが不足している点を除いて図３のｉＦＣのＵＭＬ表現のトリガ・ポイント部分に類似している。図４のトリガ・ポイント（ＴＰ）テンプレート４００中へのこれらのフィールドの追加は、本発明のＴＰテンプレートを実際のトリガ・ポイントにする。本発明の様々な実施形態によれば、このＴＰテンプレートは、図１のＩＭＳネットワーク１００のＨＳＳ１２０などのＨＳＳに記憶することができる。このＨＳＳ上にＴＰテンプレートを記憶するために、本発明者らは、本発明の一実施形態において、ユーザ特有のデータの形の入力を可能にし、したがってこれらを（その標準化されたＸＭＬ方言で）実際のトリガ・ポイントに非常に効率よくインスタンス化するＸＭＬ表現を提案している。前述の本発明の実施形態においては、本発明者らは、このＨＳＳ上にＴＰテンプレートを記憶するためにＸＭＬ表現を提案しているが、他の様々なフォーマットを使用して、このＨＳＳ上にこのＴＰテンプレートを記憶することもできることが、本発明の教示を知る当業者には理解されよう。例えば、本発明のＴＰテンプレートは、ＸＭｉｌｌなどを使用してさらに圧縮することもできる。

本発明の前述の実施形態のＴＰテンプレートのＸＭＬ表現は、トリガ・ポイントについてのＸＭＬ表現を実施し、不足しているユーザ特有のエレメント（すなわち、Request-URI（要求−ＵＲＩ）エレメントの要求ＵＲＩ、およびSIP Header（ＳＩＰヘッダ）エレメントおよびSessionDescription（セッション記述）エレメント内で使用されるContent（内容）エレメントの実際の内容）を省略する。しかし、Contentエレメントについての<content>開始タグ、</Content>終了タグは省略されない。これにより、ユーザ特有のデータを入力してこのＴＰテンプレートを具体的なトリガ・ポイントにインスタンス化するインスタンス化ルーチンが簡略化される。

図５は、本発明の一実施形態によるサンプルＴＰテンプレートの高水準ＸＭＬ表現を示している。図５において空のContentエレメントについてのタグは、簡単に識別できるようにするために太字化されている。ユーザ特有のデータで埋める必要があるＴＰテンプレート中のホールは、プレースホルダを用いてマーク付けされるので、このＸＭＬ表現を使用して、このインスタンス化オペレーションが、非常に簡単で効率的になる。しかし、ＸＭＬは、データ交換用であるがストレージ用ではない非常に冗長なフォーマットであるが、プロバイダが提供するサービス数は、（せいぜい１００個に）かなり制限されていることを予想することができ、変換の容易さおよび速度が明らかにストレージ効率を支配するので、ＸＭＬフォーマットでＴＰテンプレートを記憶することは、ストレージ効率の観点からは最適ではないことに留意されたい。

図６は、本発明の一実施形態による、プロバイダ・ネットワーク中で新しいサービスを展開するための方法の高位ブロック図を示している。方法６００は、ステップ６０２から開始され、ここで、新しいサービスを求める要求がプロバイダ・ネットワークによって受信される。次いで方法６００は、ステップ６０４へと進む。

ステップ６０４において、この新しいサービス要求に関連するサービス・コードが、このプロバイダ・ネットワーク中の少なくとも１台のアプリケーション・サーバ、または負荷の分配が望ましい場合には数台のアプリケーション・サーバ上で展開される。次いで方法６００は、ステップ６０６へと進む。

ステップ６０６において、この新しいサービスをホストするすべてのアプリケーション・サーバ名が、このプロバイダ・ネットワークのＨＳＳに記憶される。次いで方法６００は、ステップ６０８へと進む。

ステップ６０８において、このサービスについてのＴＰテンプレートが、定義され、論理積標準形または論理和標準形のいずれかでＸＭＬに変換され、このＨＳＳに記憶される。次いで方法６００は、ステップ６１０へと進む。

ステップ６１０において、デフォルト値が、このＴＰテンプレート中の各仮パラメータに割り当てられる。次いで、方法６００は、ステップ６１２へと進む。
ステップ６１２において、仮パラメータごとに、サービス加入時における準備インターフェース中で使用されることになるテキスト記述が記憶される。上記のサンプルＴＰテンプレート中の仮パラメータは、例えばCalling Party's SIP URI（呼出し側パーティのＳＩＰＵＲＩ）と名前をつけることができる。このテキスト記述は、このユーザのために役割を果たす準備機構（provisioner）に、どのデータが入力されることが想定されるかを指し示すことになる。次いで方法６００は、ステップ６１４へと進む。

ステップ６１４において、このService InformationコンポーネントのService Infoフィールドが準備される。最も簡単な場合には、これは、単にCall Forwarding Number（コール転送数）やSIP URIなどのService Infoキャラクタ・ストリングについての名前を記憶することを必要とする。しかし、このService Infoフィールドを使用してより複雑な構造化情報を記憶する場合には、完全な準備スクリーンがサービス展開時に記憶される必要がある。次いで方法６００は、ステップ６１６へと進む。

ステップ６１６において、このサービスの優先順位が、プロバイダの他のサービスに対して相対的に決定される。簡単に言えば、これにより、すでに展開済みのサービスの順序づけされたリスト中における位置を決定することが必要になる。これらの各サービスには、一意の優先順位値が割り当てられているので、これらのサービスは、リスト化された順序を表す。プロバイダは、２つの隣接するサービスの優先順位値の間に十分大きなギャップを残して、ますます多数のサービスが展開されるときに、これらの値を再割当てすることを回避するように助言される。次いで方法６００は、ステップ６１８へと進む。

ステップ６１８において、このサービスのデフォルト処理が決定され、記憶される。この値は、それが使用可能でなければこのセッションを終了すべき不可欠なサービスでは、SESSION_TERMINATED（セッション終了）であり、その使用可能性がそれほど不可欠ではないサービスでは、SESSION_CONTINUED（セッション継続）とすることができる。次いで、方法６００は、終了させられる。

ユーザがサービスに加入するときに、展開時に例えばＴＰテンプレートに記憶されるグローバル・サービス・データ（すなわち、このユーザに独立なサービス・データ）は、ユーザ特有のサービス・データを用いて補完して、完全なｉＦＣを形成する必要がある。例えば、図７は、本発明の一実施形態による、ユーザ特有のサービス・データを用いてこのグローバル・サービス・データを補完して、完全なｉＦＣを形成するための加入方法の高位ブロック図を示している。図７の方法７００は、ステップ７０２から開始され、ここで、あるユーザが、まずサービスに加入する。次いで方法７００は、ステップ７０４へと進む。

ステップ７０４において、複数のアプリケーション・サーバが、この新しいサービスをホストする場合、このアプリケーション・サーバ・ホストのうちの１つが選択され、このApplication ServerコンポーネントのServer Name（サーバ名）フィールドとして記憶される。本発明の代替実施形態においては、このステップは、異なるアプリケーション・サーバに異なる加入者を割り当てることにより、アプリケーション・サーバ間で負荷を分配するように実施することができる。次いで方法７００は、ステップ７０６へと進む。

ステップ７０６において、このサービスのＴＰテンプレートの仮パラメータが、ユーザ特有の実際のパラメータを用いて準備される。仮パラメータごとに、この準備機構には、存在する場合には、（すなわち、方法６００のステップ６１２において前述したような）このパラメータ名、およびデフォルト値が提示される。デフォルト値が無効にされる場合には、この実際の値が記憶され、そうでなければこのフィールドは、空のままである。次いで方法７００は、ステップ７０８へと進む。

ステップ７０８において、このService InformationコンポーネントのService Infoフィールドが準備される。このService InformationコンポーネントのService Infoフィールドの準備は、１つの名前だけか、あるいは準備スクリーン全体が、展開時に記憶されたかに依存する。前者の場合には、このService InformationコンポーネントのService Infoフィールドの準備は、前述のようなＴＰテンプレート仮パラメータの１つを準備することに類似している。後者の場合には、この記憶された準備スクリーンを使用して、このService Infoフィールドをユーザ特有のデータで埋める。次いで方法７００は、終了させられる。

図８は、図６および図７のサービス展開方法および加入方法の実行後のこのＨＳＳの内容の高位ブロック図を示している。例示のコール・スクリーニング・サービスについての本発明の展開方法の結果は、図８の右側に示され、この新しく展開されたサービスに関連したグローバル・データ部分を例示している。例示の目的のために、このService Infoフィールドは、スクリーニングされたコールを再経路指定するかどうか、およびどこに再経路指定するかを指定するためにユーザにとって使用可能にされていることに留意されたい。図８に示す本発明の実施形態に示すように、このデフォルトは、他に指定されていない限り、スクリーニングされたコールが再経路指定されないことである。

あるユーザ、ＪｏｈｎＤｏｅについての本発明の加入方法の結果が、図８の左側のこのＨＳＳのユーザ・データ部分に示されている。例示の目的では、図８において、このユーザ、ＪｏｈｎＤｏｅは、このコール・スクリーニング・サービスについてアプリケーション・サーバＡＳ１に割り当てられることが仮定される。さらに、このユーザは、「Ｎ．Ｅ．Ｂｏｄｙ」という名前の呼出し側からの着信コールをスクリーニングしたいと望んでいること、およびこれらのコールは、このユーザのボイス・メールへと再経路指定すべきであることが仮定される。

前述のように、ユーザ・プロファイルは、登録時にこのＨＳＳからこの割り当てられたＳ−ＣＳＣＦへとダウンロードされる。とりわけ、このユーザ・プロファイルは、このユーザが加入しているサービスごとに１つのｉＦＣを含んでいる。このユーザ・プロファイルの、したがってこのｉＦＣの交換フォーマットは、うまく定義されたＸＭＬ方言である。１つのｉＦＣのこれらの異なるコンポーネントは、２つの異なるレイヤ（すなわち、グローバルな、ユーザに独立なレイヤ、およびユーザに特有なレイヤ）に記憶されるので、これらのコンポーネントは、このＳ−ＣＳＣＦへのこれらのダウンロードの前に、１つの同種のＸＭＬドキュメントにアセンブリする必要がある。

トリガ・ポイントに関する限り、このアセンブリは、ＴＰテンプレートの具体的なトリガ・ポイントへのインスタンス化に対応する。ある種のサービスについてのユーザ特有のパラメータが、適切なエントリ数を有するアレイUserParam（ユーザ・パラメータ）に記憶されることを仮定すると、本発明の一実施形態においては、このオペレーションは、以下の擬似コードの形で記述することができる。
let index←1
scan TP template for first occurrence of XML tag <RequestURI> or <Content>
while tag found, do
if <RequestURI> tag found, then
insert UserParam[index] between <RequestURI> and </RequestURI> tags
else
insert UserParam[index] between the <Content> start tag and the </Content> end tag.
let index←index+1
scan TP template for next occurrence of XML tag <RequestURI> or <Content>.
ｉＦＣの残りのコンポーネント、例えばアトリビュートServerName（サーバ名）、DefaultHandling（デフォルト処理）、ならびにServiceInfo（サービス情報）をそれぞれ有するApplicationServer（アプリケーション・サーバ）コンポーネントおよびServiceInformation（サービス情報）コンポーネントのアセンブリは、直截的である。より詳細には、アトリビュートServerNameおよびServiceInfoは、このＨＳＳのユーザ・データ部分から取得されるのに対して、アトリビュートDefaultHandlingは、図８に示すようにこのグローバル・データ部分から取得される。

本発明者らは、トリガ・ポイント・テンプレートは、サービス展開および準備のための普通の方法であるだけでなく、これらはＩＭＳユーザ・プロファイルの非常にメモリ効率の良いストレージを可能にもすることを明らかにした。データ圧縮の観点からは、ＴＰテンプレートとユーザ特有の設定へのトリガ・ポイントの分離は、グローバル・ディクショナリを形成する１組の記憶されたＴＰテンプレートを用いたディクショナリベースの圧縮技法である。ＴＰテンプレート・アプローチのストレージ効率を定量化するために、本発明者らは、３つの代替技法、すなわち非圧縮ＸＭＬストレージ、単純ＸＭＬタグ圧縮、およびＸＭｉｌｌ圧縮のストレージ効率を用いて本発明のＴＰテンプレート・アプローチを分析し比較した。

サービス加入時に、このユーザ特有の設定がこのＴＰテンプレートに埋められ、結果としての具体的なトリガ・ポイントが、ユーザ・データ・レベル上に普通のＸＭＬストリングとして記憶されているものと想定する。これは、ｉＦＣアセンブリについてのインスタンス化プロセスが、サービス加入時に１度しか実施される必要がないことを意味する。普通のＸＭＬストリングとしてのトリガ・ポイントのこの結果としてのストレージは、本発明者らが非圧縮ＸＭＬストレージとして考えるものである。これらのトリガ・ポイントは、すでにこのＳ−ＣＳＣＦに対してダウンロードするための適切なフォーマットになっているので、このアプローチは、最もランタイム効率の良いアプローチであるが、非圧縮ＸＭＬストレージにおいては、この同じＴＰテンプレートがこのサービスに加入するあらゆるユーザごとに複製されるので、最もストレージ効率の悪いアプローチでもある。したがって、このアプローチは、代替ストレージ・オプションについてのベンチマークとしての役割を果たすことができる。

対照的に、単純ＸＭＬタグ圧縮メカニズムの基本的なアイデアは、トリガ・ポイント中の非常に長いＸＭＬタグを短い短縮形で置き換えることである。ＸＭＬ表現中のトリガ・ポイントについての１組の許可されたタグが、あらかじめ定義され非常に制限されているので、これは可能である。より具体的には、全体のトリガ・ポイントの語彙は、たった２６個の異なるタグを圧縮するにすぎない。したがって、１つの印刷可能なキャラクタは、これらの２６ストリングのうちのどれかを表現するのに十分に大きいことになる。かかるマッピング表現の一実施例を以下の表１に示す。

ＸＭＬのタグおよびラベルを自由テキストから区別できるように保持するために、これらのブラケット「<」および「>」は、置き換えられない。これらのタグおよびラベルの内側部分だけが置き換えられるにすぎない。例えば、図９は、このユーザ・パラメータ「alice@home」でインスタンス化された、図５に示すようなＸＭＬタグを使用して以前に圧縮された、図４のＴＰテンプレートについての単純ＸＭＬタグ圧縮表現を示している。図９から明らかなように、図５の以前のＸＭＬ表現中のブラケットは、この単純ＸＭＬタグ圧縮表現では置き換えられず、または取り除かれないが、その代わりにこれらのコードは、これらの以前に適用された非常に長いＸＭＬタグの代わりに置かれる。

さらに対照的なことに、ＸＭｉｌｌ圧縮は、この同じタイプのエレメントを一緒にグループ化し圧縮する公共的に使用可能なＸＭＬドキュメント圧縮機構である。ＸＭｉｌｌ圧縮は、たとえ最もストレージ効率の良い一般的なＸＭＬ圧縮メカニズムでないとしても、最良のメカニズムのうちの１つとして広く知られている。ＸＭｉｌｌは、ドキュメントのＸＭＬエレメントを同じタイプのエレメントのグループに再順序付けし、次いでこの再順序付けされたドキュメント上でＧＺＩＰ圧縮を実施する。この再順序付けされたドキュメント上で、ＧＺＩＰは、この元のドキュメント上に比べて、より多くの類似性を見出すことができ、したがってより良好な圧縮レートを達成することができる。大規模なＸＭＬドキュメントでは、ＸＭｉｌｌは、一般的に汎用ＧＺＩＰ圧縮の圧縮レートの２倍の、８０％を超える圧縮レートを達成する。ＸＭｉｌｌは、非常に良好な圧縮レートを達成する高度なＸＭＬ圧縮メカニズムを表している。

前述の様々な圧縮方法の比較のために、本発明者らは、ある複雑さの１つのトリガ・ポイントを記憶するのに必要な平均ストレージ空間を評価する。トリガ・ポイントの複雑さを評価するためには、その原子的状態（サービス・ポイント・トリガ）数、ｎが使用される。焦点は、トリガ・ポイント・ストレージだけに当てられ、ｉＦＣの他のコンポーネントは、無視される。これについての理由は、以下のように２つある。

１．このトリガ・ポイント・ストレージは、ｉＦＣの他の部分が記憶される方法と直交している。すなわち、トリガ・ポイントは、このユーザ・レベルの非圧縮ＸＭＬドキュメントとして記憶することができ、依然として共用されるグローバル・データとしてこのデフォルト処理を記憶する。したがって、公平な比較のためには、この比較は、トリガ・ポイント・ストレージだけに限定される。
２．トリガ・ポイントは、圧倒的にｉＦＣの最もストレージを消費するコンポーネントである。より詳細には、ｉＦＣの非トリガ・ポイント・コンポーネントは、ストレージ消費量の以下の範囲内にある。

ａ．Priority（優先順位）：キャリアのネットワーク中のすべてのサービスに異なる優先順位を割り当てるためには、２バイトもあれば十分である。
ｂ．Server Name：すべてのアプリケーション・サーバが、キャリアの信頼されるドメイン内で実行されるので、これらの数は制限され、すべてのサーバは、一般的にこのＨＳＳ上のグローバル・コンフィギュレーション・テーブル中にリストアップされることになる。実際のネットワーク中で、２バイト長のインデックスは、特定のＩＭＳネットワーク中で実行されるすべてのアプリケーション・サーバについて言及するのに十分に長いことになる。
ｃ．Default Handling（デフォルト処理）：このフィールドは、２つの異なる値（SESSION_CONTINUED、SESSION_TERMINATED）しかもたないようにすることができるので、これは１ビットで記憶することができる。
ｄ．ServiceInfo：これは、ただ１つの可変長のフィールドである。このサイズは、特定のサービスについてこれがどのような情報を含むかに依存する。しかし、このＩＭＳは、データのより大きなブロブをＨＳＳからＳ−ＣＳＣＦにダウンロードする工夫された別のメカニズムを有するので、このフィールド・サイズは、安全に制限されるものと仮定することができる。したがって、例えばコール転送番号についての数十バイトの平均長が、現実的に見える。
ｅ．合計すると、ｉＦＣの非トリガ・ポイント・コンポーネントのための平均の必要とされるストレージ空間が、数十バイトの範囲内にあることを予想することができる。

これらの圧縮方法の比較を実施するために、本発明者らは、ジェネレータを使用して、ランダムＴＰテンプレートを作成した。このランダムＴＰテンプレートにおいては、すべてのサービス・ポイント・トリガは、同じ相対的確率で発生する。２重の否定表現は、許可しないで、意図的に複雑な述語を回避している。このジェネレータは、入力として所望のＴＰテンプレートの複雑度ｎを取得し、ｎ個の原子的状態（サービス・ポイント・トリガ）から構成される組合せ論理述語を作成し、この述語を論理積標準形と論理和標準形の両方に正規化し、これらをそのＸＭＬ表現に変換し、この短い方を選択する。

ＴＰテンプレート・ジェネレータを使用して、１と２０の間の各複雑度値ｎについて１０００個のＴＰテンプレートが生成された。次いで、これらのアプローチ、非圧縮ＸＭＬストレージ、単純ＸＭＬタグ圧縮、およびＸＭｉｌｌについて、各ＴＰテンプレートが具体的なトリガ・ポイントにインスタンス化され、この結果としてのトリガ・ポイントが、（非圧縮ＸＭＬストレージの場合を除いて）圧縮され、複雑度ｎについての１０００個のすべての結果としてのトリガ・ポイントの長さが平均化された。ユーザ特有のデータに関する限り、本発明者らは、長さ１０のキャラクタ・ストリングを仮定した。前述のパラメータは、ワイルドカードを含むＳＩＰＵＲＩやユーザ名などのフィールドについての実際の平均値である。しかし、この全体トリガ・ポイントの長さは、このユーザ特有の部分によっては支配されず、このＴＰテンプレート長によって強く支配されるので、その重要性はかなり限られる。

本発明のＴＰテンプレート・アプローチでは、これらの生成されたＴＰテンプレートは、インスタンス化されず、これらの長さが、固定された複雑度値ｎについて平均化された。同時に、各ＴＰテンプレートの中のユーザ・パラメータ数が、このユーザ特有のストリングが必要とするストレージ空間が計上されるように平均化される。

図１０は、これら３つの圧縮方法、すなわち非圧縮ＸＭＬストレージ、単純ＸＭＬタグ圧縮、ＸＭｉｌｌのそれぞれ、ならびに本発明のＴＰテンプレート方法についての、所与の複雑度についてのトリガ・ポイントの平均長のグラフ表現を示している。ＴＰテンプレート・アプローチでは、いくつかの異なるＴＰテンプレート・ディクショナリ対加入者ベースのコンフィギュレーションについてのグラフについても（以下でさらに詳細に説明するように）示されている。前述のように、このトリガ・ポイントの複雑度は、ｎ＝１から２０まで変化させられ、このｙ−軸の最大値は、２０００バイトに設定された。実際のシステムにおいては、平均複雑度は、通常低い側、おそらく数個の原子的状態の範囲内にあるが、複雑度の大きな範囲も、これらの異なる圧縮方法の漸近的振舞いを示し比較するために示されている。

図１０から明らかなように、非圧縮ＸＭＬについてのグラフは、ほぼｎ＝１４の複雑度において、２０００バイトのｙ−軸最大値を超過してしまう。ｎ＝２０では、この平均トリガ・ポイント長は、約３１８０バイト（図示せず）である。１と１４の間のｎの図示した範囲では、このグラフは、ほとんど直線的に増大するように見える。しかし、このグラフは、図１０の範囲外では、直線的な変化率よりもずっと速い変化率で増大することに留意されたい。例えば、ｎ＝３０では、トリガ・ポイントの平均長は、６６４０バイトに等しくなり、これは直線外捜法が示すはずの値よりもかなり大きくなる。

単純タグ圧縮では、図１０に示すように、非圧縮ＸＭＬ表現に比べて約６４％の圧縮率が、達成された。
ＸＭｉｌｌ圧縮についてのグラフは、ｎ＝１では１２６バイトのトリガ・ポイント長から開始され、次いでｎ＝２０では、３６４バイトの平均長までゆっくりと増大する。実際、ｎが増大するにつれ、この増大率は減少する。例えば、ｎ＝１からｎ＝３までこの平均トリガ・ポイント長は、５０バイト分だけ増大するのに対して、ｎ＝１８からｎ＝２０まではこの増大率は、２６バイトまで低下している。明らかに、このトリガ・ポイントが長くなればなるほど、ＸＭｉｌｌを用いて達成することができる圧縮率は、より良好になる。１つの理由は、このＸＭＬドキュメントが、大規模になればなるほど、このＸＭｉｌｌ圧縮方法は、より多くの類似性を見出し、これらを圧縮することができるようになることである。

本発明のＴＰテンプレート方法を用いて、トリガ・ポイントのユーザ特有の部分だけがこのユーザ・レベル上に記憶されるのに対して、これらのすべてのＴＰテンプレートは、共通のグローバル・テーブルに記憶される。しかし、このセクションにおける比較のためにこのユーザ・レベル・データだけを考慮することは、公平でないはずである。その代わりにこのグローバルＴＰテンプレート・ストレージのために必要とされる空間も同様に考慮する必要がある。したがって、本発明者らは、ＴＰテンプレートのサイズｓ_ｔｍｐｌを、それを使用する加入者数ｎ_{ｔｍｐｌ＿ｕｓｅｒ}によって除算し、この値をこのユーザ特有のパラメータのサイズｓ_{ｐａｒａｍｓ}に加えた。そうすることによって、このＴＰテンプレートの負担がそのユーザのすべてにわたって等しく分散される。さらに、本発明者らは、このユーザ・レベル上に記憶され、このグローバルＴＰテンプレート・ディクショナリを指し示すインデックスのために２バイトを加えた。６４Ｋのこの結果としてのアドレス空間は、どのような現実的なＴＰテンプレート・ディクショナリについても十分すぎる。したがって、トリガ・ポイントのサイズｓ_ｔｐは、以下の式（１）に従って計算することができる。

平均して、所与のＴＰテンプレートのユーザ数ｎ_{ｔｍｐｌ＿ｕｓｅｒ}は、ユーザ数ｎ_{ｕｓｅｒｓ}をこのディクショナリ中のテンプレート数ｎ_ｔｍｐｌで割った比率にユーザ当たりの加入サービスの平均数ｎ_ｓｅｒｖを掛けたものであり、これは、式（２）に従って特徴づけられ、以下のようになる。

本明細書中で説明しているシミュレーションでは、本発明者らは、前述と同じＴＰテンプレート・ディクショナリを使用した。すなわち、固定された複雑度ｎでは、１０００個のトリガ・ポイントがランダムに生成され、この長さを平均して、ｓ_ｔｍｐｌを決定し、またユーザ・パラメータ数を使用してｓ_{ｐａｒａｍｓ}を取得した。ファクタｎ_{ｔｍｐｌ＿ｕｓｅｒ}に関する限り、本発明者らは、図１０において４つの値、すなわち２、１０、１００、および１００００についてのグラフを示している。これらの４つのグラフは、「ＴＰテンプレート、２」、「ＴＰテンプレート、１０」、「ＴＰテンプレート、１００」、「ＴＰテンプレート、１００００」とそれぞれラベル付けされている。ｎ_{ｔｍｐｌ＿ｕｓｅｒ}についての最小の実現可能な値は、１であり、あらゆるＴＰテンプレート、およびしたがってあらゆるサービスがただ１人のユーザによって使用される状況を説明している。この場合には、本発明のＴＰテンプレート・ストレージについてのグラフは、本発明によるグローバルＴＰテンプレート・テーブル中を参照するために必要とされる２バイトを除いて、普通のＸＭＬストレージについてのグラフとほぼ類似している。これは、グローバルＴＰテンプレート・ストレージについてのコストが、ただ１人のユーザによって負担されるからであり、ＴＰテンプレートとユーザ・パラメータとの組合せは、このユーザ・レベル上に記憶される普通のＸＭＬトリガ・ポイントに等しくなる。

ｎ_{ｔｍｐｌ＿ｕｓｅｒ}＝２の値（すなわち、あるサービスに、たった２人のユーザしか加入していないとき）では、ストレージの節約は、ほぼ５０％である。しかし、以上の式（１）におけるｎ_{ｔｍｐｌ＿ｕｓｅｒ}に独立なファクタｓ_{ｐａｒａｍｓ}＋２が、このゲインをわずかに減少させる。ｎ_{ｔｍｐｌ＿ｕｓｅｒ}を１０に増大させることにより、ｎ_{ｔｍｐｌ＿ｕｓｅｒ}＝２に比べて約５７％の別のストレージ・ゲインがもたらされる。この領域において、このファクタｓ_{ｐａｒａｍｓ}はトリガ・ポイントの合計サイズにかなりの影響を持ち始める。最終的に、ｎ_{ｔｍｐｌ＿ｕｓｅｒ}＝１００とｎ_{ｔｍｐｌ＿ｕｓｅｒ}＝１００００についての曲線は、互いに非常に近接して位置する。これは、ｎ_{ｔｍｐｌ＿ｕｓｅｒ}の増大する値について、式（１）を支配するファクタｓ_{ｐａｒａｍｓ}に起因している。したがって、ｎ_{ｔｍｐｌ＿ｕｓｅｒ}のさらなるどのような増大も、さらにほんのわずかなストレージ・ゲインしかもたらさないはずである。

この場合にも、前述の実験では、発明者らは、１０バイトの平均長を有するユーザ特有のパラメータを仮定した。これは、妥当な値に見えるけれども、異なる平均値により、この結果に対して変化する影響があるはずである。例えば、これら３つの圧縮方法、すなわち非圧縮ＸＭＬストレージ、単純ＸＭＬタグ圧縮、およびＴＰテンプレート・ディクショナリは、すべて絶対項におけるより小さなユーザ・パラメータから同じ恩恵を受けるはずである。しかし、相対的には、このゲインが、あまり効率的でないメカニズムに比べてすでに効率的なメカニズムに、より大きな利益をもたらすので、これらの曲線は、もう少し離れるはずである。同様に、３つのすべてのアプローチは、より大きなユーザ・パラメータから同様な量の影響を受けるはずであるが、これらの曲線は、集まってより近接したものになるはずである。しかし、ＸＭｉｌｌは、ユーザ特有のパラメータを含むこれらすべてのトリガ・ポイント・データを圧縮するので、ＸＭｉｌｌは、ユーザ・パラメータの小さいところからは、あまり恩恵を受けないはずであり、他の諸アプローチに比べてその曲線を上方に移動させる。他方、ＸＭｉｌｌは、より大きなパラメータによってはあまり打撃を受けないはずであり、他の諸アプローチに比べてその曲線を下方に移動させる。

実施された実験から、本発明のＴＰテンプレート方法は、このＩＭＳにおけるサービス準備のためのもっともな基礎となるだけでなく、この中央ＨＳＳにおける数百万のトリガ・ポイントの効率的ストレージのためのもっともな基礎ともなることが明らかである。ＨＳＳが数千万人までのユーザについての中央リポジトリとして存在し、各ユーザが一般的にいくつかのサービスに加入することを考慮すれば、トリガ・ポイントの平均ストレージ消費量のそれほど大きくない差が、合計ストレージ要件の非常に大きな差へと増大してしまう可能性がある。さらに、（どのようなＨＳＳ実施形態でも、厳しい信頼性要件を達成するために使用する必要がある）データの複製が、さらにこの合計ストレージ空間を増大させてしまうことを考慮されたい。

本発明者らは、さらにこれらの同じ圧縮方法、すなわち非圧縮ＸＭＬストレージ、単純ＸＭＬタグ圧縮、ＸＭｉｌｌ、および本発明のＴＰテンプレート・ディクショナリを使用して、本発明のＴＰテンプレート方法のランタイム効率について調査した。１と２０の間のトリガ・ポイント複雑度値ｎごとに、本発明者らは、（１）ファイルから（圧縮された）トリガ・ポイントに読み込み、（２）それをこのＨＳＳからこのＳ−ＣＳＣＦにダウンロードするための準備ができている普通のＸＭＬ表現に変換するための各アプローチでかかる時間を測定した。この第１のステップは、この同じエントリをディスクベースのデータベース・システムから読み出すためにかかるはずの時間におおむね匹敵する。明らかに、非圧縮ＸＭＬストレージ・アプローチを用いると、このトリガ・ポイントが、ＨＳＳとＳ−ＣＳＣＦの間で交換される同じフォーマットで記憶されているので、この第２のステップは、非圧縮ＸＭＬストレージでは、必要とされない。非圧縮ＸＭＬストレージについてのこの結果は、このタスクの純粋なデータ読取り部分を示し、したがって他のすべてのアプローチについての低い方の限界を提供することになる。

本発明者らは、一実施形態においてこのＴＰテンプレート実施形態を書くためにＪａｖａ（登録商標）を実施したので、これらの他のアプローチのＪａｖａ（登録商標）実施形態も、これらの比較を公平なものにするためには必要になった。非圧縮ＸＭＬストレージならびに単純タグ圧縮では、これらの実施形態は、直截的であった。対照的に、ＸＭｉｌｌは、Ｃ＋＋コードとして使用可能であるにすぎず、これは使用することができなかった。しかし、ＸＭｉｌｌは、最初にＸＭＬドキュメントを再順序付けし、次いでその上でＧＺＩＰを実行するので、この追加の再順序付けプロセスは、純粋なＧＺＩＰ実行に対して約１０％のオーバーヘッドを追加することが知られている。したがって、Ｊａｖａ（登録商標）開発ツールキットが付属するＪａｖａ（登録商標）ＧＺＩＰ実施形態の性能をまず評価し、次いでこの結果に１０％を追加して、このＸＭｉｌｌ性能を算出した。

このオペレーション・システムが、定期的なＪａｖａ（登録商標）ガーベージ・コレクションなどを実行する並行プロセスに起因する時折起きる性能スパイクの効果を緩和するために、本発明者らは、これらのテストが実施される順序に２レベルのランダム性を導入し、その結果、定期的な任意のＣＰＵオーバーロード状況が、すべての評価されたコンフィギュレーションにわたって等しく分散された。より詳細には、このテストは、２００００回の連続した実行から構成された。各実行において、１から２０の複雑度値が、ランダムに生成され、この複雑度の５０個のＴＰテンプレートが生成され、これらのＴＰテンプレートがインスタンス化され、これらのＴＰテンプレートが、変換され記憶され、次いでこれらを読み込み、これらをダウンロード可能なＸＭＬフォーマットに変換するアプローチごとにかかった時間が測定された。このＴＰテンプレート・アプローチでは、このＨＳＳがこのＴＰテンプレート・ディクショナリを主記憶装置に保持することができるものと仮定して、これらのユーザ・パラメータだけが２次ストレージに記憶された。これらのユーザ・パラメータを読み込み、これらのユーザ・パラメータをこの正しいＴＰテンプレートに埋めるための時間が測定された。各実行中の複雑度値をランダムに選択することにより、定期的なバックグラウンド実行スパイクは、各複雑度値がほとんど同じ程度まで影響を与えるようになされた。２００００回の実行後には、複雑度値あたりに平均１０００回の実行が行われていた。

実行ごとに、非圧縮ＸＭＬ、単純タグ圧縮、ＸＭｉｌｌ、ＴＰテンプレートの読込みおよび変換が実施される順序が、ランダムに決定された。このようにして、アプローチ当たりのトリガ・ポイント複雑度当たりに平均１０００個の測定値が取得され、これらの測定値については、アプローチあたりの１つのランタイム対トリガ・ポイント複雑度値を示すために平均が出された。

図１１は、これらの圧縮方法、非圧縮ＸＭＬストレージ、単純ＸＭＬタグ圧縮、ＸＭｉｌｌ、およびＴＰテンプレートのそれぞれについて以上で説明したランタイム性能テストの結果のグラフ表現を示すものである。図１１には、このランタイム（アクセス時間＋変換時間）が、この複雑度値に対してプロットされている。図１１に示すように、トリガ・ポイントの読込みおよび変換がこのタスクの読込み部分まで減少させられるので、ほとんどの部分では、非圧縮ＸＭＬが最速のアプローチである。しかし、１と３の間の小さな複雑度値では、このアプローチよりもこのＴＰテンプレート・アプローチの方が、性能が優れている。非圧縮ＸＭＬストレージについてのグラフは、トリガ・ポイント当たり、０．９ｍｓから、１．１７ｍｓへとゆっくりと増大している。トリガ・ポイント複雑度を増大させることに対しての実行時間のゆっくりした増大は、トリガ・ポイントが消費し、読み込む必要があるブロック数の増大に起因している。

単純ＸＭＬタグ圧縮は、非圧縮ＸＭＬよりも悪いが、この考慮している複雑度の範囲ではＸＭｉｌｌよりも良好である。その速く増大する漸近的振舞いにより、単純タグ圧縮は、非常に複雑なトリガ・ポイントでは、ＸＭｉｌｌに向かって収束するが、図１１の考慮している複雑度の範囲内ではＸＭｉｌｌに達してはいない。

ＸＭｉｌｌは、これら考慮しているすべてのアプローチのうちで最悪のランタイム性能を示している。ＸＭｉｌｌは、複雑度ｎ＝１のトリガ・ポイントでは１．３３ｍｓから開始され、ｎ＝２０では１．７９ｍｓまで増大する。しかし、これらの値の比率を取ると、性能ペナルティは、非圧縮ＸＭＬストレージに比べて、３０〜３５％の実行時間の増大の範囲であることに留意されたい。

図１１に示すように、１と３の間の小さな複雑度値では、非圧縮ＸＭＬストレージ・アプローチが全く変換を必要とせず、このトリガ・ポイントに読み込むためのファイル・アクセスしか必要としないことに留意しても、このＴＰテンプレート・アプローチは、非圧縮ＸＭＬストレージよりも性能が優れてさえいる。この説明は、本発明のＴＰテンプレート方法では、ユーザ特有のデータしか、ファイルに記憶されないが、一方でＴＰテンプレート・ディクショナリは、主記憶装置中に保持されるからである。一部の低複雑度のトリガ・ポイント・テンプレートは、ユーザに依存するどのデータも含まず、したがってこのＴＰテンプレートがすでに、具体的なトリガ・ポイントになっているので、ファイル・アクセスは必要とされない。これらの場合には、ＴＰテンプレート・ストレージは、非圧縮ＸＭＬストレージよりも速いことさえある。しかし、複雑度値がより大きい場合には、トリガ・ポイントがユーザ特有のデータを含まない可能性はゼロに近づき、したがって、ファイル・アクセスが必要になり、非圧縮ＸＭＬストレージに比べて５％の範囲内で悪い性能がもたらされることになる。

したがって図１１に示すように、本発明のＴＰテンプレート方法では、３より大きな複雑度値についてのランタイムに関して非圧縮ＸＭＬストレージとほぼ同様に実施されることが明らかである。１と３の間の複雑度では、このＴＰテンプレート方法では、あるパーセンテージの単純なトリガ・ポイントについてのファイル・アクセスが完全になくなるので、本発明のＴＰテンプレート方法は、非圧縮ＸＭＬストレージよりも性能が優れていることさえある。

要約すれば、本発明のＴＰテンプレート方法は、高いストレージ効率を非常に良好なランタイム性能と組み合わせている。この組合せは、本発明のＴＰテンプレート方法をこの効率の観点からの、トリガ・ポイント・ストレージにとっての好ましいアプローチにする。

本発明の代替実施形態においては、本発明のＴＰテンプレート方法が、パラメータ圧縮と組み合わされて、本発明のストレージ効率をさらに増大させることができる。例えば、前述の本発明の概念内においては、ユーザ・レベル・パラメータが、小さなストレージ空間を消費することが想定されるので、これらのユーザ・レベル・パラメータは、圧縮されずに記憶される。しかし、本発明の代替実施形態においては、これらのユーザ・パラメータは、市販の任意の圧縮アルゴリズム（例えば、ＧＺＩＰ）を使用して圧縮することができる。

前記のものは、本発明の様々な実施形態を対象としているが、本発明の他のさらなる実施形態についても、本発明の基本的な範囲を逸脱することなく考案することができる。したがって、本発明の適切な範囲については、特許請求の範囲に従って決定すべきである。

本発明の概念を適用することができる、ＩＭＳネットワークの高位ブロック図である。図１のＩＭＳネットワークにおけるＩＭＳ登録の高位機能図を示す図である。図１のＩＭＳネットワークにおける着信コール・セットアップの高位機能図である。ＩＭＳ初期フィルタ条件（ｉＦＣ）の高水準の統一モデリング言語（ＵＭＬ）表現を示す図である。本発明の一実施形態によるトリガ・ポイント（ＴＰ）テンプレートの高水準の統一モデリング言語（ＵＭＬ）表現を示す図である。本発明の一実施形態によるサンプルＴＰテンプレートの高水準の拡張マークアップ言語（ＸＭＬ）表現を示す図である。本発明の一実施形態による、プロバイダ・ネットワーク中で新しいサービスを展開するための方法の高位ブロック図である。本発明の一実施形態による、ユーザ特有のサービス・データを用いてこのグローバル・サービス・データを補完して、完全なｉＦＣを形成するための加入方法の高位ブロック図である。図６および図７のサービス展開方法およびサービス加入方法の実行後のこのＨＳＳの内容の高位ブロック図である。図５に示すようなＸＭＬタグを使用して、あらかじめ圧縮された、図４のＴＰテンプレートについての単純ＸＭＬタグ圧縮表現を示す図である。４つの圧縮方法、すなわち非圧縮ＸＭＬストレージ、単純ＸＭＬタグ圧縮、ＸＭｉｌｌ、および本発明のＴＰテンプレート方法のそれぞれについて、所与の複雑さについてのトリガ・ポイントの平均長のグラフ表現を示す図である。各圧縮方法、すなわち非圧縮ＸＭＬストレージ、単純ＸＭＬタグ圧縮、ＸＭｉｌｌ、および本発明のＴＰテンプレート方法についてのランタイム性能テストの結果のグラフ表現を示す図である。図１のＩＭＳネットワーク１００中で使用するのに適したＳ−ＣＳＣＦサーバの一実施形態の高位ブロック図である。

Claims

プロバイダ・ネットワーク中の各ユーザ・サービスに関連した初期フィルタ条件（ｉＦＣ）の効率的な実施のための方法であって、
新しいサービスを求める要求を受信するとすぐに、各サービス・コードを少なくとも１台のアプリケーション・サーバに展開し、前記サービス・コードをホストする前記少なくとも１台のアプリケーション・サーバの識別子をメモリ・デバイスに記憶するステップ、及び
前記ｉＦＣをユーザ特有のパラメータとユーザに独立なパラメータに分解するステップからなる方法。
請求項１記載の方法において、各ユーザ特有のパラメータが、前記サービスへの加入時に、各ユーザによる前記ユーザ・サービスの実行のために、前記ｉＦＣ中で使用するために提供される方法。
請求項１記載の方法において、前記ユーザに独立なパラメータが、グローバル・サービス・データからなる方法。
請求項１記載の方法において、前記ｉＦＣが、前記ストレージ・デバイスにアクセスすることができ、前記サービスの実行を望む、前記プロバイダ・ネットワークのすべてのユーザごとに、１回しかストレージ・デバイスに記録する必要がなく、前記ｉＦＣが、前記ストレージ・デバイスからダウンロードされ、実行ユーザ・サービスを任せるコール・セッション制御ファンクション（ＣＳＣＦ）サーバに記録される方法。
プロバイダ・ネットワーク中の各ユーザ・サービスに関連する初期フィルタ条件（ｉＦＣ）の効率的なストレージのための方法であって、
新しいサービスを求める要求を受信するとすぐに、各サービス・コードを少なくとも１台のアプリケーション・サーバに展開し、前記サービス・コードをホストする前記少なくとも１台のアプリケーション・サーバの識別子をメモリ・デバイスに記憶するステップ、及び
各ユーザ・サービスに関連した前記各ｉＦＣが、ストレージ・デバイスにアクセスすることができ、前記サービスの実行を望むすべてのユーザごとに１回しか前記ストレージ・デバイスに記録する必要がないように、前記各ユーザ・サービスの実行に関連したユーザ特有のサービス・パラメータとユーザに独立なサービス・パラメータに前記ｉＦＣを分解するステップからなり、プレースホルダが、前記ユーザ特有のパラメータごとに記憶され、前記ユーザ特有のパラメータが、それぞれ前記サービスの実行時に各ユーザによる前記各ユーザ・サービスの実行のために、前記ｉＦＣに提供される方法。
プロバイダ・ネットワーク中において新しいサービスを展開するための方法であって、
新しいサービスを求める要求を受信するとすぐに、各サービス・コードを少なくとも１台のアプリケーション・サーバに展開し、前記サービス・コードをホストする前記少なくとも１台のアプリケーション・サーバの識別子をメモリ・デバイスに記憶するステップ、及び
前記新しいサービスについての、グローバル・サービス・データおよびユーザ特有のサービス・パラメータを含むトリガ・ポイント（ＴＰ）テンプレートを定義し、前記ＴＰテンプレートを前記メモリ・デバイスに記憶するステップ、及び
前記ＴＰテンプレート中の前記ユーザ特有のサービス・パラメータごとに、デフォルト値、およびどのようなユーザ特有のデータを前記ＴＰテンプレート中に挿入すべきかを示す記述を割り当てるステップ
からなる方法。
請求項６記載の方法であって、さらに、
前記ＴＰテンプレートのサービス情報フィールドを準備するステップ
からなる記載の方法。
請求項６記載の方法であって、さらに、
サービスを求めるユーザの加入要求を受信するとすぐに、前記サービスをホストする少なくとも１台のアプリケーション・サーバをホスト・サーバとして割り当て、前記少なくとも１台のアプリケーション・サーバについての識別子をメモリ・デバイスに記憶するステップ、及び
前記加入要求中に受信されるユーザ特有の実際のパラメータを用いて前記ＴＰテンプレートを準備するステップ
からなる方法。
メモリ及びプロセッサからなる装置であって、該装置が以下の、
新しいサービスを求める要求を受信するとすぐに、各サービス・コードを少なくとも１台のアプリケーション・サーバに展開し、前記サービス・コードをホストする前記少なくとも１台のアプリケーション・サーバの識別子をメモリ・デバイスに記憶するステップと、
前記新しいサービスについての、グローバル・サービス・データおよびユーザ特有のサービス・パラメータを含むトリガ・ポイント（ＴＰ）テンプレートを定義し、前記ＴＰテンプレートを前記メモリ・デバイスに記憶するステップ、及び
前記ＴＰテンプレート中の前記ユーザ特有のサービス・パラメータごとに、デフォルト値、およびどのようなユーザ特有のデータを前記ＴＰテンプレート中に挿入すべきかを示す記述を割り当てるステップ
を実施するように適合されている装置。
請求項９記載の装置であって、さらに、以下の、
サービスを求めるユーザの加入要求を受信するとすぐに、前記サービスをホストする少なくとも１台のアプリケーション・サーバをホスト・サーバとして割り当て、前記少なくとも１台のアプリケーション・サーバについての識別子をメモリ・デバイスに記憶するステップ、及び
前記加入要求中に受信されるユーザ特有の実際のパラメータを用いて前記ＴＰテンプレートを準備するステップ
を実施するように適合されている装置。