JP2009508242A

JP2009508242A - Ｉｍｓクライアントにおいて情報を保持する方法及び装置

Info

Publication number: JP2009508242A
Application number: JP2008530336A
Authority: JP
Inventors: クリステルボーベルイ，; カール，アンデシュリンドグレン，; フーベルトプルジビーズ，
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2005-09-15
Filing date: 2005-09-15
Publication date: 2009-02-26
Also published as: BRPI0520536A2; US20080256177A1; EP1925140A1; EP1925140B1; WO2007031115A1

Abstract

ＩＰマルチメディア・サブシステムのクライアントにおいて格納されているデータを前記ＩＰマルチメディア・サブシステムのＳＩＰアプリケーションサーバにおいて格納されているデータと実質的に同期させる方法に関する。本方法は、前記アプリケーションサーバにおいて、前記クライアントから送信された前記データの要求を受信するステップと、前記クライアントにおいて格納されているデータに関する現在の状態を特定する状態情報を前記要求が含むか否かを判断するステップと、前記アプリケーションサーバにおいて、特定された何らかの状態情報に基づいて、前記クライアントに対して更なるデータを送信するか否かを判断するステップと、前記判断の結果次第でデータを送信するステップと、を備える。

Description

本発明は、ＩＭＳクライアントにおいて情報を保持する方法及び装置に関し、より詳しくは、ＩＭＳクライアントにおいて最新の情報を保持する方法及び装置に関する。

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

ＩＰマルチメディア・サブシステム（ＩＭＳ）は、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）によって規定された技術であり、移動体通信ネットワークを介してＩＰマルチメディアサービスを提供する（３ＧＰＰＴＳ２２．２２８、ＴＳ２３．２２８、ＴＳ２４．２２９、ＴＳ２９．２２８、ＴＳ２９．２２９、ＴＳ２９．３２８、及びＴＳ２９．３２９リリース５−７）。ＩＭＳは、新しいリッチなパーソン・トゥ・パーソン（クライアント・トゥ・クライアント）通信サービスと共にＩＰベースのネットワークを介したパーソン・トゥ・コンテンツ（クライアント・トゥ・サーバ）サービスを促進する、標準化されたＩＭＳサービスイネーブラの使用を介してエンドユーザのパーソン・トゥ・パーソンの通信の体験を豊かにする重要な特徴を提供する。ＩＭＳは、ユーザ端末間（又はユーザ端末とアプリケーションサーバとの間）の呼又はセッションを確立して制御するために、セッション開始プロトコル（ＳＩＰ）を使用する。セッションのメディアコンポーネントを記述して交渉するために、ＳＩＰシグナリングによって搬送されるセッション記述プロトコル（ＳＤＰ）が使用される。ＳＩＰはユーザ・トゥ・ユーザプロトコルとして創り出されたが、ＩＭＳによれば、オペレータ及びサービスプロバイダは、サービスに対するユーザのアクセスを制御し、それに従ってユーザに課金することが可能である。

一例として、図１は、ＧＰＲＳ／ＰＳアクセスネットワークの場合にＩＭＳがどのように移動体ネットワークアーキテクチャに適合するかを概略的に示す（ＩＭＳはもちろん、他のアクセスネットワーク上でも動作可能である）。呼セッション制御機能（ＣＳＣＦ）は、ＩＭＳ内でＳＩＰプロキシとして動作する。３ＧＰＰアーキテクチャは、３種類のＣＳＣＦを定義する。即ち、ＳＩＰ端末にとってＩＭＳ内の最初のコンタクトポイントであるプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）と、ユーザに対してそのユーザが加入しているサービスを提供するサービングＣＳＣＦ（Ｓ−ＣＳＣＦ）と、正しいＳ−ＣＳＣＦを特定し、Ｐ−ＣＳＣＦを介してＳＩＰ端末から受信した要求をそのＳ−ＣＳＣＦへ転送する役割を担うインテロゲーティングＣＳＣＦ（Ｉ−ＣＳＣＦ）と、である。

ユーザは、規定のＳＩＰＲＥＧＩＳＴＥＲメソッドを使用してＩＭＳに登録する。これは、ＩＭＳにアタッチし、ＳＩＰユーザアイデンティティに到達可能なＩＭＳアドレスをアナウンスするメカニズムである。３ＧＰＰでは、ＳＩＰ端末が登録を実行する際に、ＩＭＳはユーザを認証し、そのユーザに対してＳ−ＣＳＣＦを一連の利用可能なＳ−ＣＳＣＦから割り当てる。Ｓ−ＣＳＣＦを割り当てる基準は３ＧＰＰでは規定されていないが、負荷分散及びサービス要件が基準として含まれ得る。なお、Ｓ−ＣＳＣＦの割り当ては、ＩＭＳベースのサービスに対するユーザのアクセスを制御する（そしてそれに対して課金する）ためのカギである。オペレータは、Ｓ−ＣＳＣＦをバイパスしてしまうようなユーザ・トゥ・ユーザの直接のＳＩＰセッションを阻止するメカニズムを提供することができる。

登録プロセスの間、Ｓ−ＣＳＣＦがまだ選択されていない場合にＳ−ＣＳＣＦを選択するのは、Ｉ−ＣＳＣＦの責務である。Ｉ−ＣＳＣＦは、ホームネットワークのホーム加入者サーバ（ＨＳＳ）から必要とされるＳ−ＣＳＣＦの能力を受信し、受信した能力に基づいて適切なＳ−ＣＳＣＦを選択する。（なお、ユーザが他のパーティーから呼び出され、その時点でそのユーザにＳ−ＣＳＣＦが割り当てられていない場合にも、Ｓ−ＣＳＣＦの割り当てがＩ−ＣＳＣＦによってそのユーザのために実行される。）登録されたユーザが続いてセッション要求をＩＭＳに対して送信する場合、Ｐ−ＣＳＣＦは、登録プロセスの間にＳ−ＣＳＣＦから受信した情報に基づいて、その要求を選択されたＳ−ＣＳＣＦに対して転送することができる。

ＳＩＰアプリケーションサーバにおいて保持されるデータに実質的に同期したデータをＩＭＳクライアント端末が保持したいと欲する状況が多数存在する。例えばプレゼンスサービスを考えると、ＩＭＳ加入者は自分のプレゼンス情報（例えば、現在の連絡先や所在など）をＳＩＰアプリケーションサーバにおいて保持されるデータベース内に発行する。この情報は、適切なアクセス許可（パーミッション）を持つ他のユーザにとって利用可能である。ユーザとＳＩＰアプリケーションサーバとの間での情報の交換は、ＳＩＰＰＵＢＬＩＳＨメソッド、及びＳＩＰＳＵＢＳＣＲＩＢＥ／ＮＯＴＩＦＹメソッドを使用して実現可能である。

現在規定されているように、ＳＩＰＳＵＢＳＣＲＩＢＥ／ＮＯＴＩＦＹメソッドによれば、ＩＭＳクライアントは、ＳＵＢＳＣＲＩＢＥメソッド中で特定されたある情報を通知して欲しいと要求することができるだけである。それゆえ、クライアントが同一の情報を最後に要求してからその情報が変化したか否かに関わらず、特定された情報がＮＯＴＩＦＹメッセージ中でクライアントに対して送信されることになる。従来の技術は、変化した情報や新たな情報のみをクライアントに対して送信可能にするメカニズムを何ら提供しない。

本発明の第１の態様によれば、ＩＰマルチメディア・サブシステムのクライアントにおいて格納されているデータを前記ＩＰマルチメディア・サブシステムのＳＩＰアプリケーションサーバにおいて格納されているデータと実質的に同期させる方法であって、前記アプリケーションサーバにおいて、前記クライアントから送信された前記データの要求を受信するステップと、前記クライアントにおいて格納されているデータに関する現在の状態を特定する状態情報を前記要求が含むか否かを判断するステップと、前記アプリケーションサーバにおいて、特定された何らかの状態情報に基づいて、前記クライアントに対して更なるデータを送信するか否かを判断するステップと、前記判断の結果次第でデータを送信するステップと、を備えることを特徴とする方法が提供される。

本発明の一実施形態において、前記要求はＳＩＰＳＵＢＳＣＲＩＢＥメッセージである。前記状態情報はＳＩＰメッセージのヘッダ又は当該メッセージのペイロード内に含まれてもよい。

本発明の一実施形態において、データはＳＩＰＮＯＴＩＦＹ中で前記アプリケーションサーバから前記クライアントへ送信される。

本発明の一実施形態において、前記クライアントにおいて現在格納されているデータが最新であると判断された場合に、前記アプリケーションサーバは、ＳＩＰＮＯＴＩＦＹ又は４００シリーズのメッセージのうちの一方を送信することにより、前記クライアントにその旨を通知する。

前記クライアントにおいて格納されているデータの現在の状態を特定する前記状態情報は、タイムスタンプ又はバージョン番号のうちの一方であり得る。前記状態情報は、前記アプリケーションサーバによって現在格納されているデータが前記クライアントに対して送信される前又は送信される時に生成されたものであってもよいし、或いは、他の何らかのデータソースによって生成されたものであってもよい。

本発明の第２の態様によれば、ＩＰマルチメディア・サブシステムのクライアント端末であって、データを当該データに関する現在の状態を特定する状態情報と共に格納するメモリと、前記格納されているデータをリフレッシュする要求であって前記状態情報を含む要求を生成し、前記ＩＰマルチメディア・サブシステムのＳＩＰアプリケーションサーバに対して送信する手段と、を備えることを特徴とするクライアント端末が提供される。

本発明の第３の態様によれば、ＳＩＰアプリケーションサーバであって、データを当該データに関する現在の状態を特定する状態情報と共に格納するメモリと、ＩＰマルチメディア・サブシステムのクライアントにおいて格納されているデータをリフレッシュする要求であって前記クライアントにおいて格納されているデータの現在の状態を特定する状態情報を含む要求を、前記クライアントから受信する手段と、前記受信した状態情報を、前記メモリ内に格納されている前記データのための前記状態情報と比較する手段と、前記各状態情報が異なる場合に、当該アプリケーションサーバにおいて格納されているデータを前記クライアントに対して送信する手段と、を備えることを特徴とするアプリケーションサーバが提供される。

ＩＰマルチメディア・サブシステム（ＩＭＳ）の一般的なアーキテクチャは３Ｇネットワークの文脈において既に説明した（図１）。ＩＭＳベースのネットワークでは、クライアントは、種々のアプリケーションサーバによって制御されるネットワーク内のリソースに関するデータを要求することができる。クライアントは、不定期の基準でデータを取る（フェッチする）こともできるし、定期的な基準でネットワークをポーリングすることもできるし、或いは、概ねリアルタイムにクライアントへ送信されるべき変化を購読（サブスクライブ）することもできる。要求されたデータにおける変化が発生した時にネットワークがクライアントに通知するというフォーマー・プッシュ・ソリューションを使用することを好むクライアントも存在するかもしれない。必要な時だけデータをフェッチ又はポーリングすることを好むクライアントも存在する。ＩＭＳネットワークは、内在するＳｕｂｓｃｒｉｂｅ／Ｎｏｔｉｆｙフレームワーク（ＲＦＣ３２６５）によってこれらの機能をサポートする。

プッシュアプローチを考えると、ＩＭＳクライアントにおいて既にキャッシュされている情報を送信する必要を回避するために、ここでは、クライアントから送信される購読要求（サブスクリプションリクエスト）内に新しい状態情報(condition)を含めることを提案する。それは、ＳＩＰアプリケーションサーバに対して、ＩＭＳクライアントにおいてキャッシュされているデータの現在の状態を示すものである。この状態情報は、バージョン番号やタイムスタンプなどの様々なタイプのインジケータに基づくことができる。アプリケーションサーバは購読要求内に含まれる状態情報をチェックし、クライアントが最新バージョンのデータを持っているか否かを判断する。キャッシュされているデータが最新であるとアプリケーションサーバが判断した場合、サーバはクライアントに対してデータが最新である旨を通知し、実際のデータは送信されない。クライアント内に格納されているデータが古いものであるとサーバが判断した場合、サーバは最新のデータ、又は代わりにデータに対する変更、を含む通知を送信する。その通知はまた、例えばバージョン番号やタイムスタンプのような、新しい通知のバージョンを特定する状態情報を含む。

この振る舞いは、リフレッシュ購読メッセージに対しても可能である（現在の標準は、例えクライアントのデータが最新のものであっても、アプリケーションサーバがクライアントに対して完全な通知を常に送信することを要求する）。プッシュメソッドを使用するクライアント、即ちアプリケーションサーバに対する継続的な購読を生成するクライアントは、アプリケーションサーバにおいて購読を有効に保つために、定期的に購読をリフレッシュする必要がある。現在は、（Ｅｘｐｉｒｅｓ＞０のＳＵＢＳＣＲＩＢＥを送信することによって）クライアントが購読をリフレッシュした場合、アプリケーションサーバは格納されているデータをＮＯＴＩＦＹメッセージ中で返す。ここで説明する状態情報によるメカニズムを適用すると、最新のデータの不必要なダウンロードをせずにそのようなリフレッシュを行うことが可能になる。このソリューションは、あらゆるＳＩＰベースの購読に対して有効である。

図２は、２つのＩＭＳクライアント（ユーザＡ及びユーザＢ）の間での情報交換に関連する、ＩＭＳ関連のＳＩＰシグナリングを示す。ここでは、ユーザＡによって提供されたデータが、ユーザＢによるダウンロードのためにＳＩＰアプリケーションサーバにおいて保持される。ユーザＡは、ステップ１乃至３において自分のデータを（Ｐ−ＣＳＣＦ及びＳ−ＣＳＣＦを介して）ＳＩＰアプリケーションサーバへ送信するために、ＳＩＰＰＵＢＬＩＳＨメソッドを使用する。この例では、ユーザＢはユーザＡのデータについていかなるバージョンもこの時点ではまだ受信していないものとする。ステップ４で、ユーザＢはＳＩＰアプリケーションサーバに対してＳＵＢＳＣＲＩＢＥメッセージを送信することにより、ユーザＡのデータを要求する。（「Ｅｘｐｉｒｅｓ」ＳＩＰヘッダの値は、ＩＭＳクライアントがデータを取得するために使用するメソッドを決定する。「Ｅｘｐｉｒｅｓ＝０」はデータをフェッチ（プル）するために使用され、一方、「Ｅｘｐｉｒｅｓ＞０」はクライアントに対してプッシュされるデータにおける変化を取得するために使用される購読を確立するために使用される。）ユーザＢは、ユーザＡのデータに関するいかなる状態情報も、ＳＵＢＳＣＲＩＢＥメッセージ内に含めない。アプリケーションサーバがＳＵＢＳＣＲＩＢＥメッセージを受信すると、アプリケーションサーバは、状態情報が存在しないことから、ユーザＡのデータを全てユーザＢへ送信しなければならないと判断する。アプリケーションサーバはこれを、ステップ５で、ＳＩＰＮＯＴＩＦＹメッセージ中にペイロードとしてデータを含めることにより実行する。

ステップ６で、ユーザＢは何らかの理由により、ユーザＡのデータが変化したか否かを判断するためにアプリケーションサーバにコンタクトしなければならないと判断する。ユーザＢはこれを、更なるＳＵＢＳＣＲＩＢＥメッセージを送信することにより実行する。しかしながら、今回は、ユーザＢによってキャッシュされているユーザＡのデータに関する現在の状態を特定する状態情報を、ユーザＢはメッセージ中に含める。この状態情報は全てのパーティーによって認識可能なように指定されるが、例えば、ＳＩＰメッセージヘッダ又はペイロード中に含まれてもよい。状態情報に基づいて、アプリケーションサーバは、保持するデータをユーザＢへ送信すべきか否かを判断することができる。この例では、データに対していかなる変更も加えられていないため、アプリケーションサーバはユーザＢに対して「４ｘｘ」（即ち、４００シリーズの）メッセージ、又は空のＮＯＴＩＦＹメッセージを返す。

続いて、ユーザＡは、ステップ８乃至１０で、更新されたデータを含む更なるＰＵＢＬＩＳＨメッセージをアプリケーションサーバへ送信する。ステップ１１でユーザＢが更なるＳＵＢＳＣＲＩＢＥメッセージをアプリケーションサーバへ送信する時、これは、ユーザＡについて保持するデータの現在のバージョンを特定する状態情報（「ｘ」）を含む。ＳＩＰアプリケーションサーバがＳｕｂｓｃｒｉｂｅメッセージを受信すると、状態情報ｘから、サーバは、ユーザＢが保持するデータは古いものであると判断する。サーバはユーザＢに対して、ＳＩＰＮＯＴＩＦＹメッセージ中で、ユーザＡについての新しいデータを返す。

本発明の範囲から逸脱すること無しに上述した実施形態に対して多用な変更を加えることが可能であるということを、当業者であれば理解できるであろう。

３Ｇネットワーク内のＩＭＳアーキテクチャを概略的に示す図である。ＩＭＳ内でのデータ発行及びデータリフレッシュの手順に関連するシグナリングを示す図である。

Claims

ＩＰマルチメディア・サブシステムのクライアントにおいて格納されているデータを前記ＩＰマルチメディア・サブシステムのＳＩＰアプリケーションサーバにおいて格納されているデータと実質的に同期させる方法であって、
前記アプリケーションサーバにおいて、前記クライアントから送信された前記データの要求を受信するステップと、
前記クライアントにおいて格納されているデータに関する現在の状態を特定する状態情報を前記要求が含むか否かを判断するステップと、
前記アプリケーションサーバにおいて、特定された何らかの状態情報に基づいて、前記クライアントに対して更なるデータを送信するか否かを判断するステップと、
前記判断の結果次第でデータを送信するステップと、
を備えることを特徴とする方法。
前記要求はＳＩＰＳＵＢＳＣＲＩＢＥメッセージであることを特徴とする請求項１に記載の方法。
前記状態情報はＳＩＰメッセージのヘッダ又は当該メッセージのペイロード内に含まれることを特徴とする請求項１又は２に記載の方法。
前記データはＳＩＰＮＯＴＩＦＹ中で前記アプリケーションサーバから前記クライアントへ送信されることを特徴とする請求項１乃至３のいずれか１項に記載の方法。
前記クライアントにおいて現在格納されているデータが最新であると判断された場合に、前記アプリケーションサーバは、前記クライアントに対してＳＩＰＮＯＴＩＦＹ又は４００シリーズのメッセージのうちの一方を送信することにより、前記クライアントにその旨を通知することを特徴とする請求項１乃至４のいずれか１項に記載の方法。
前記クライアントにおいて格納されているデータの現在の状態を特定する前記状態情報は、タイムスタンプ又はバージョン番号のうちの一方であることを特徴とする請求項１乃至５のいずれか１項に記載の方法。
前記状態情報は、前記アプリケーションサーバによって現在格納されているデータが前記クライアントに対して送信される前又は送信される時に生成されたか、或いは、他の何らかのデータソースによって生成されたことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
ＩＰマルチメディア・サブシステムのクライアント端末であって、
データを当該データに関する現在の状態を特定する状態情報と共に格納するメモリと、
前記格納されているデータをリフレッシュする要求であって前記状態情報を含む要求を生成し、前記ＩＰマルチメディア・サブシステムのＳＩＰアプリケーションサーバに対して送信する手段と、
を備えることを特徴とするクライアント端末。
ＳＩＰアプリケーションサーバであって、
データを当該データに関する現在の状態を特定する状態情報と共に格納するメモリと、
ＩＰマルチメディア・サブシステムのクライアントにおいて格納されているデータをリフレッシュする要求であって前記クライアントにおいて格納されているデータの現在の状態を特定する状態情報を含む要求を、前記クライアントから受信する手段と、
前記受信した状態情報を、前記メモリ内に格納されている前記データのための前記状態情報と比較する手段と、
前記各状態情報が異なる場合に、当該アプリケーションサーバにおいて格納されているデータを前記クライアントに対して送信する手段と、
を備えることを特徴とするアプリケーションサーバ。