JP4753316B2 - プレゼンス情報の負荷を分散管理する負荷分散サーバ及びプログラム - Google Patents

プレゼンス情報の負荷を分散管理する負荷分散サーバ及びプログラム Download PDF

Info

Publication number
JP4753316B2
JP4753316B2 JP2007174983A JP2007174983A JP4753316B2 JP 4753316 B2 JP4753316 B2 JP 4753316B2 JP 2007174983 A JP2007174983 A JP 2007174983A JP 2007174983 A JP2007174983 A JP 2007174983A JP 4753316 B2 JP4753316 B2 JP 4753316B2
Authority
JP
Japan
Prior art keywords
message
server
subscribe
presence server
presence information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2007174983A
Other languages
English (en)
Other versions
JP2009015485A (ja
Inventor
学 磯村
尚樹 今井
和之 田坂
彰 井戸上
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
KDDI R&D Laboratories Inc
Original Assignee
KDDI R&D Laboratories Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by KDDI R&D Laboratories Inc filed Critical KDDI R&D Laboratories Inc
Priority to JP2007174983A priority Critical patent/JP4753316B2/ja
Priority to US12/142,219 priority patent/US7885191B2/en
Publication of JP2009015485A publication Critical patent/JP2009015485A/ja
Application granted granted Critical
Publication of JP4753316B2 publication Critical patent/JP4753316B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks

Description

本発明は、ＳＩＰ(Session Initiation Protocol)／ＳＩＭＰＬＥ(SIP for Instant Messaging and Presence Leveraging Extensions)を用いたプレゼンスシステムに関する。特に、プレゼンス情報の負荷を分散管理する負荷分散サーバ及びプログラムに関する。
ＳＩＭＰＬＥは、インスタントメッセージ及びプレゼンスサービスを実現するために、ＳＩＰを拡張した技術である（例えば非特許文献１、２及び３参照）。プレゼンスサービスとは、ユーザ（端末）の状態（「オンライン」「オフライン」「ビジー」「不在」等）を、他のユーザ（端末）へ向けて、プッシュ的に通知するものである。現在では、ユーザの状態だけでなく、端末の能力や位置など様々な情報（プレゼンス情報）を扱うことができる。尚、３ＧＰＰ(3rd Generation Partnership Project)では、ＳＩＰ／ＳＩＭＰＬＥを用いたＩＭＳ(IP Multimedia Domain)におけるプレゼンスシステムを標準化している（例えば非特許文献４参照）。
図１は、従来技術におけるプレゼンスシステムの構成図である。
図１によれば、複数のユーザ端末は、１台のプレゼンスサーバ２と通信をすることができる。ここで、複数のユーザ端末は、プレゼンティティ(Presentity)機能及び／又はウォッチャ(Watcher)機能を有する。プレゼンティティとは、Presence＋Entityの造語であって、プレゼンス情報の所有者を表す。ウォッチャとは、SUBSCRIBER（購読者）を意味し、プレゼンティティに対応する用語である。
（Ｓ１０１）プレゼンス情報を生成するプレゼンティティ３は、プレゼンスサーバ２へ、プレゼンス情報を登録するためのPUBLISHメッセージを送信する。これに対し、プレゼンスサーバ２は、プレゼンティティ３へ200OKメッセージを返信する。プレゼンス情報の登録はソフトステートで管理される。従って、プレゼンスサーバ２は、有効期間内に、再登録(REFRESH)のPUBLISHメッセージが受信されない限り、そのプレゼンス情報の登録を破棄する。
（Ｓ１０２）ウォッチャ４を操作するユーザは、他のユーザの所持するプレゼンティティ３のプレゼンス情報を購読したいとする。そのとき、ウォッチャ４は、プレゼンスサーバ２へ、そのプレゼンティティ３のプレゼンス情報の購読を要求するSUBSCRIBEメッセージを送信する。これに対し、プレゼンスサーバ２は、ウォッチャ４へ200OKメッセージを返信する。
プレゼンス情報は、PRS-URI(PReSence - Uniform Resource Identifier、プレゼンティティのプレゼンス情報に対する識別子)及びEvent（イベント名、イベントパッケージ）の組み合わせによって識別される。プレゼンス情報の購読も、ソフトステートで管理される。従って、プレゼンスサーバ２は、有効期間内に、再購読(SUBSCRIBE)メッセージが受信されない限り、そのプレゼンス情報の購読を破棄する。再購読の場合、初回の購読と同じダイアログを含むSUBSCRIBEメッセージを送信する必要がある。即ち、To tag、From tag、Call-ID及びEventヘッダフィールドのidパラメータが、一致する必要がある。
（Ｓ１０３）SUBSCRIBEメッセージを受信したプレゼンスサーバ２は、そのプレゼンス情報を含むNOTIFYメッセージを、ウォッチャ４へ返信する。これに対し、ウォッチャ４は、プレゼンスサーバ２へ200OKメッセージを返信する。
また、プレゼンティティ３が、プレゼンス情報の内容変更(MODIFY)のPUBLISHメッセージをプレゼンスサーバ２へ送信した場合、そのプレゼンス情報を購読している全てのウォッチャ４へ、更新されたプレゼンス情報を含むNOTIFYメッセージが送信される。
"SessionInitiation Protocol (SIP)-Specific Event Notification", RFC3265 "SessionInitiation Protocol (SIP) Extension for Event State Publication", RFC3903 "A PresenceEvent Package for the Session Initiation Protocol (SIP)", RFC3856 "Presenceservice using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3(Release 7)", 3GPP TS 24.141 V7.3.0 (2006-12)
前述したプレゼンスシステムによれば、プレゼンス情報が増加することによって、プレゼンスサーバ及びネットワークの負荷も増加する。具体的には、プレゼンス情報を含むPUBLISHメッセージの送信回数が多いほど、NOTIFYメッセージの送信回数も増加する。特に、１つのプレゼンス情報に対するSUBSCRIBEメッセージの送信回数が多いほど、１つのPUBLISHメッセージに対してNOTIFYメッセージの送信回数も増加する。
NOTIFYメッセージ数＝SUBSCRIBEメッセージ数×PUBLISHメッセージ数
将来的にユーザ端末数が増加した場合、このような問題は、プレゼンスシステムにおける拡張性の制約となる。
従来、ＳＩＰメッセージの内容を参照する経路制御によって、負荷分散を実現するレイヤ７スイッチがある。これをプレゼンスシステムに適用する場合、例えばPRS-URI及びEvent毎に、そのプレゼンス情報を含むPUBLISHメッセージを経路制御し、プレゼンスサーバへ送信することも考えられる。
しかしながら、ウォッチャは、SUBSCRIBEメッセージを、PUBLISHメッセージによってプレゼンス情報が登録されたプレゼンスサーバへ送信する必要がある。なぜなら、それ以外のプレゼンスサーバは、そのプレゼンス情報を保持していないからである。従って、ある特定のプレゼンス情報を保持したプレゼンスサーバに、多数のSUBSCRIBEメッセージが集中して送信され、負荷が集中するという問題がある。
従って、本発明は、複数のプレゼンスサーバを備えた場合に、プレゼンス情報の負荷を分散管理することができる負荷分散サーバ及びプログラムを提供することを目的とする。
本発明によれば、ＳＩＰ(Session Initiation Protocol)／ＳＩＭＰＬＥ(SIP for Instant Messaging and Presence Leveraging Extensions)を用いたプレゼンスシステムに備えられたサーバであって、
プレゼンス情報を登録するためのPUBLISHメッセージを送信する第１の通信装置と、
プレゼンス情報を購読するためのSUBSCRIBEメッセージを送信する第２の通信装置と、
受信したPUBLISHメッセージに含まれるプレゼンス情報を登録し、受信したSUBSCRIBEメッセージの送信元装置へプレゼンス情報を含むNOTIFYメッセージを送信する複数のプレゼンスサーバと
の間で通信可能な負荷分散サーバにおいて、
プレゼンス情報毎のエントリに、当該プレゼンス情報を登録したプレゼンスサーバの識別子のリストを記録したパブリッシュ用データベースと、
プレゼンスサーバ毎に、購読(SUBSCRIBE)メッセージ受信率を記録したサブスクライブ用データベースと、
SUBSCRIBEメッセージ又はPUBLISHメッセージを受信した際に、当該プレゼンス情報に基づくエントリに含まれたリストの中のプレゼンスサーバについて、購読メッセージ受信率が最も低いプレゼンスサーバを選択するエントリ検索手段と、
選択されたプレゼンスサーバに基づく購読メッセージ受信率が所定閾値Ｔｓよりも高い場合、購読メッセージ受信率が所定閾値Ｔｓ以下となるいずれか１つの追加プレゼンスサーバを選択するプレゼンスサーバ選択手段と、
選択されたプレゼンスサーバへ、PUBLISHメッセージを送信するメッセージ送受信制御手段と
を有することを特徴とする。
本発明の負荷分散サーバにおける他の実施形態によれば、プレゼンスサーバ選択手段は、
プレゼンス情報の一部を引数とするハッシュ関数によって、複数のプレゼンスサーバの中からいずれか１つのプレゼンスサーバを選択し、
選択された当該プレゼンスサーバに対する購読メッセージ受信率が所定閾値Ｔｓ以下か否かを判定し、
その判定を真とするプレゼンスサーバが検出されるまで、プレゼンスサーバの選択を繰り返す
ことも好ましい。
本発明の負荷分散サーバにおける他の実施形態によれば、
メッセージ送受信制御手段は、第２の通信装置から受信したSUBSCRIBEメッセージをプレゼンスサーバへ送信するために、
プレゼンスサーバのアドレスを含むリダイレクト要求を、第２の通信装置へ返信するか、ＤＳＲ(Direct Server Return)方式によってプレゼンスサーバへSUBSCRIBEメッセージを送信するか、又は、ＮＡＴ(Network Address Translation)方式によってプレゼンスサーバへSUBSCRIBEメッセージを送信する
ことも好ましい。
本発明の負荷分散サーバにおける他の実施形態によれば、
SUBSCRIBEメッセージを受信した際に、追加プレゼンスサーバへPUBLISHメッセージを送信する場合、
メッセージ送受信制御手段は、当該プレゼンス情報に基づくエントリに含まれるリストの中のいずれか１つのプレゼンスサーバへPUBLISHメッセージを送信し、該プレゼンスサーバからNOTIFYメッセージによってプレゼンス情報を受信し、該プレゼンス情報を含むPUBLISHメッセージを、追加プレゼンスサーバへ送信する
ことも好ましい。
本発明の負荷分散サーバにおける他の実施形態によれば、
PUBLISHメッセージを受信した際に、追加プレゼンスサーバへPUBLISHメッセージを送信する場合、
メッセージ送受信制御手段は、当該プレゼンス情報に基づくエントリに含まれるリストの中の全てのプレゼンスサーバへPUBLISHメッセージを送信すると共に、追加プレゼンスサーバへPUBLISHメッセージを送信する
ことも好ましい。
本発明の負荷分散サーバにおける他の実施形態によれば、
サブスクライブ用データベースは、プレゼンス情報毎に、更に有効期間を含んでおり、
エントリ検索手段は、サブスクライブ用データベースに記憶されたSUBSCRIBEメッセージの有効期間が、現在時刻を過ぎたプレゼンスサーバについて、エントリリストから削除することも好ましい。
本発明によれば、ＳＩＰ／ＳＩＭＰＬＥを用いたプレゼンスシステムに備えられたサーバであって、
プレゼンス情報を登録するためのPUBLISHメッセージを送信する第１の通信装置と、
プレゼンス情報を購読するためのSUBSCRIBEメッセージを送信する第２の通信装置と、
受信したPUBLISHメッセージに含まれるプレゼンス情報を登録し、受信したSUBSCRIBEメッセージの送信元装置へプレゼンス情報を含むNOTIFYメッセージを送信する複数のプレゼンスサーバと
の間で通信可能なサーバに搭載されたコンピュータを機能させる負荷分散プログラムであって、
プレゼンス情報毎のエントリに、当該プレゼンス情報を登録したプレゼンスサーバの識別子のリストを記録したパブリッシュ用データベースと、
プレゼンスサーバ毎に、購読(SUBSCRIBE)メッセージ受信率を記録したサブスクライブ用データベースと、
SUBSCRIBEメッセージ又はPUBLISHメッセージを受信した際に、当該プレゼンス情報に基づくエントリに含まれたリストの中のプレゼンスサーバについて、購読メッセージ受信率が最も低いプレゼンスサーバを選択するエントリ検索手段と、
選択されたプレゼンスサーバに基づくSUBSCRIBEメッセージ受信率が所定閾値Ｔｓよりも高い場合、購読メッセージ受信率が所定閾値Ｔｓ以下となるいずれか１つの追加プレゼンスサーバを選択するプレゼンスサーバ選択手段と、
選択されたプレゼンスサーバへ、PUBLISHメッセージを送信するメッセージ送受信制御手段と
してコンピュータを機能させることを特徴とする負荷分散プログラム。
従って、本発明の負荷分散サーバ及びプログラムによれば、ある特定のプレゼンス情報に対して多くのSUBSCRIBEメッセージが集中して送信される場合であっても、そのプレゼンス情報を登録するプレゼンスサーバの数を増加させることにより、プレゼンス情報の負荷を分散管理することができる。
以下では、図面を用いて、本発明を実施するための最良の形態について詳細に説明する。
図２は、本発明におけるシステム構成図である。
本発明の重要な構成要素は、ＳＩＰ／ＳＩＭＰＬＥを用いたプレゼンスシステムに搭載された負荷分散サーバ１である。図２によれば、プレゼンティティ又はウォッチャとして機能する複数のユーザ端末は、負荷分散サーバ１と通信する。負荷分散サーバ１は、ネットワークを介して複数のプレゼンスサーバ２と接続されている。負荷分散サーバ１は、プレゼンス情報を複数のプレゼンスサーバに登録することにより、プレゼンスシステムにおけるSUBSCRIBEメッセージの分散処理を可能とする。
本発明における負荷分散サーバ１は、プレゼンティティ３から、プレゼンス情報を含むPUBLISHメッセージを受信した際に、プレゼンスサーバに対するメッセージの集中の程度から負荷分散の必要性を判定する。負荷分散が必要と判定した際に、負荷分散サーバ１は、複数のプレゼンスサーバ２へPUBLISHメッセージを送信する。これにより、そのプレゼンス情報が、複数のプレゼンスサーバ２によって登録される。
また、負荷分散サーバ１は、ウォッチャ４からSUBSCRIBEメッセージを受信した際に、特定のプレゼンスサーバ２に負荷が集中しないように、負荷の軽いプレゼンスサーバへ、そのSUBSCRIBEメッセージを経路制御する。
プレゼンスサーバ２は、受信したSUBSCRIBEメッセージを経路制御してプレゼンスサーバ２へ送信する。例えば、プレゼンスサーバのアドレスを含むリダイレクト要求をウォッチャ４へ返信するか、ＤＳＲ方式又はＮＡＴ方式によってプレゼンスサーバへSUBSCRIBEメッセージを送信する。これによって、プレゼンスサーバ２は、そのプレゼンス情報を含むNOTIFYメッセージを、ウォッチャ４へ転送することができる。ウォッチャ４は、負荷分散サーバ１を介しているにもかかわらず、既存のプレゼンスサーバ２と直接的にSUBSCRIBEメッセージを送受信している場合と、何ら違いがない。
負荷分散サーバ１は、全てのプレゼンスサーバ２の識別子（プレゼンスサーバＵＲＩであって、例えばSIP-URI）のリストを保持する。本発明によれば、特定のプレゼンス情報に対してSUBSCRIBEメッセージが多数発生した場合、そのプレゼンス情報を登録するプレゼンスサーバ２を増加させていくことによって、特定のプレゼンスサーバ２に集中する負荷を分散させることができる。
図３は、本発明における負荷分散サーバの機能構成図である。
負荷分散サーバ１は、データ蓄積のために、プレゼンスサーバリスト蓄積部１０１と、パブリッシュ用データベース１０２と、サブスクライブ用データベース１０３とを有する。
プレゼンスサーバリスト蓄積部１０１は、利用可能な全てのプレゼンスサーバにおけるプレゼンスサーバＵＲＩ(SIP-URI)と、それに対応するハッシュ値とを蓄積する。ハッシュ値は、SIP-URIを引数としてハッシュ関数から得た値である。
パブリッシュ用データベース１０２は、プレゼンス情報毎のエントリに、当該プレゼンス情報を登録したプレゼンスサーバのSIP-URIのリスト（エントリリスト）を記録する。パブリッシュ用データベース１０２は、プレゼンティティにおけるプレゼンス情報の識別子(PRS-URI)及びイベント名(Event)毎に、以下のようなデータを蓄積する。
Figure 0004753316
表１によれば、PRS-URI及びEvent（例えばpresence）毎に、「有効期間」と、「代表エンティティタグ」と、「プレゼンスサーバＵＲＩ及びエンティティタグのリスト」とを有する。
「有効期間」は、そのプレゼンス情報の登録がプレゼンスサーバによって保持される時間を表す。「代表エンティティタグ」は、プレゼンティティへ返信した200OKメッセージにおけるExpiresヘッダフィールドの値である。「エントリリスト」は、そのプレゼンス情報を登録しているプレゼンスサーバのSIP-URI及びエンティティタグのリストである。
サブスクライブ用データベース１０３は、プレゼンスサーバ毎に、SUBSCRIBE受信率を記録する。サブスクライブ用データベース１０３は、302 Moved Temporarily方式と、ＤＳＲ／ＮＡＴ方式とで、蓄積するデータ構造が異なる。
302 Moved Temporarily方式とは、Ｗｅｂサーバからの応答であるＨＴＴＰリダイレクト(Hyper Text Transfer Protocol redirect)用のコードを、ＳＩＰの応答メッセージに適用したものであり、本来は、ページが一時的に別の場所に用意されていることを意味する。ＨＴＴＰでは、ユーザ端末のＷｅｂブラウザは、自動的にこのコードを認識し、リダイレクト先のＵＲＬを読みに行く。これをSIPに適用した場合、ウォッチャ４−プレゼンスサーバ２間のSUBSCRIBEメッセージ及びNOTIFYメッセージは直接的に送受信され、負荷分散サーバ１を全く経由しない。また、ＤＳＲ方式は、直接サーバ返答方式であり、ＮＡＴ方式とは、アドレス書き換え方式である。
サブスクライブ用データベース１０３は、302 Moved Temporarily方式の場合、以下のようなデータを蓄積する。
Figure 0004753316
データ構造１によれば、PRS-URI及びEvent毎に、「プレゼンスサーバＵＲＩ、有効期間」のリストを有する。ここで、有効期間とは、各プレゼンスサーバにおいて、そのプレゼンス情報に対するSUBSCRIBEメッセージの有効期間の中で、最長の有効期間のもの示す。
また、データ構造２によれば、プレゼンスサーバＵＲＩ毎に、SUBSCRIBE受信率を蓄積する。SUBSCRIBE受信率とは、単位時間当たりのSUBSCRIBE数を意味し、これによって、発生したSUBSCRIBEの数が多いか少ないかを判定することができる。
更に、サブスクライブ用データベース１０３は、ＤＳＲ／ＮＡＴ方式の場合、以下のようなデータを蓄積する。
Figure 0004753316
データ構造１によれば、プレゼンスサーバへ送信したSUBSCRIBEメッセージにおけるプレゼンス情報のEvent、ダイアログ（Toタグ、Fromタグ、Call-ID）、有効期間、プレゼンスサーバの識別子の組み合わせを記録する。
また、データ構造２によれば、プレゼンスサーバ毎に、総サブスクライブ数を記録する。ＤＳＲ／ＮＡＴ方式では、SUBSCRIBE受信率の代わりに、有効なダイアログの数をカウントした総サブスクライブ数を用いる。
負荷分散サーバ１は、更に、プレゼンスサーバ選択部１０４と、エントリ検索部１０５と、SUBSCRIBE受信率判定部１０６と、メッセージ送受信制御部１０７と、エントリ更新部１０８と、通信インタフェース部１０９とを有する。これら機能構成部は、サーバに搭載されたコンピュータを機能させるプログラムを実行することによって実現される。
プレゼンスサーバ選択部１０４は、プレゼンスサーバに基づくSUBSCRIBE受信率が所定閾値Ｔｓよりも高い場合、SUBSCRIBE受信率が所定閾値Ｔｓ以下となるいずれか１つの追加プレゼンスサーバを選択する。
エントリ検索部１０５は、当該プレゼンス情報に基づくエントリに含まれたリストの中のプレゼンスサーバについて、SUBSCRIBE受信率が最も低いプレゼンスサーバを選択する。
SUBSCRIBE受信率判定部１０６は、プレゼンスサーバにおけるSUBSCRIBE受信率が所定閾値Ｔｓ以下か否かを判定する。
メッセージ送受信制御部１０７は、プレゼンスサーバ２と、プレゼンティティ３と、ウォッチャ４との間でメッセージを交換する。
尚、各機能構成部の詳細な動作は、後述する図８及び図９に記載されたフローチャートに、番号を付して明確にしている。
図４は、本発明における第１のシーケンス図である。
（Ｓ４０１）最初に、プレゼンティティ３は、プレゼンス情報を登録するためにPUBLISH(INITIAL)メッセージを負荷分散サーバ１へ送信する。PUBLISH(INITIAL)メッセージを受信した負荷分散サーバ１は、そのプレゼンス情報を登録すべきプレゼンスサーバＰを選択する。このとき、SUBCRIBE受信率が所定閾値Ｔｓ以下となるプレゼンスサーバＰが選択される。そして、そのPUBLISH(INITIAL)メッセージは、そのプレゼンスサーバ２へ送信される。これにより、プレゼンスサーバ２は、プレゼンティティ３のプレゼンス情報を登録する。
以下は、この場合のPUBLISHメッセージのフォーマット例である。
PUBLISH sip:presentity@example.com SIP/2.0 ［PRS-URI］
Via SIP/2.0/UDP
Event: ［イベント名］
To:<sip:presentity@example.com> ［PRS-URI］
From:<sip:presentity@example.com> ［PRS-URI］
Expires: ［登録の有効期間］
Call-ID:
CSeq: 1 PUBLISH
（Ｓ４０２）これに対し、プレゼンスサーバ２は、200OKメッセージを負荷分散サーバ１へ返信する。200OKメッセージを受信した負荷分散サーバ１は、その200OKメッセージを、プレゼンティティ３へ返信する。これにより、プレゼンティティ３は、プレゼンスサーバ２へのプレゼンス情報の登録を完了する。
（Ｓ４０３）次に、ウォッチャ４が、プレゼンティティ３のプレゼンス情報を購読したいとする。このとき、ウォッチャ４は、SUBSCRIBE(INITIAL)メッセージを負荷分散サーバ１へ送信する。
以下は、この場合のSUBSCRIBEメッセージのフォーマット例である。
SUBSCRIBE sip:presentity@example.com SIP/2.0 ［PRS-URI］
Via SIP/2.0/UDP
Event: ［イベント名］
To:<sip:presentity@example.com> ［PRS-URI］
From:<sip:watcher@example.com> ［ウォッチャのSIP URI］
Expires: ［購読の有効期間］
Call-ID:
CSeq: 1 SUBSCRIBE
（Ｓ４０４）これに対し、負荷分散サーバ１は、ＳＩＰのリダイレクトの応答である302 Moved Temporarilyをウォッチャ４へ返信する。302 Moved Temporarilyは、そのプレゼンス情報を登録しているプレゼンスサーバ２のSIP-URIを含む。
（Ｓ４０５）ウォッチャ４は、リダイレクトによって、302 Moved Temporarilyに含まれるプレゼンスサーバ２のSIP-URIへ向けて、SUBSCRIBE(INITIAL)メッセージを送信する。
（Ｓ４０６）プレゼンスサーバ２は、ウォッチャ４からSUBSCRIBEメッセージを受信すると、既存のプレゼンスサーバと同様に、200OKメッセージをウォッチャ４へ返信する。プレゼンスサーバ２は、既に、負荷分散サーバ１からPUBLISH(INITIAL)メッセージを受信しており、そのプレゼンス情報を登録している。
（Ｓ４０７）次に、プレゼンスサーバ２は、NOTIFYメッセージを、ウォッチャ４へ送信する。NOTIFYメッセージは、プレゼンティティ３のプレゼンス情報を含む。
以下は、この場合のNOTIFYメッセージのフォーマット例である。
NOTIFY sip:watcher@example.com SIP/2.0 ［ウォッチャのSIP URI］
Via SIP/2.0/UDP
Event: ［イベント名］
To:<sip:watcher@example.com> ［ウォッチャのSIP URI］
From:<sip:presentity@example.com> ［PRS-URI］
Call-ID:
CSeq: 1 NOTIFY
Subscription-Status: active; expires= ［購読の状態、有効期間］
<中略>
<プレゼンス情報>
（Ｓ４０８）NOTIFYメッセージを受信したウォッチャ４は、そのプレゼンス情報を取得する。そして、200OKメッセージを、プレゼンスサーバ２へ返信する。
（Ｓ４０９）その後、そのプレゼンス情報の購読を要求するSUBSCRIBEメッセージが、複数のウォッチャ４から多数送信されたとする。プレゼンスサーバ２に対するSUBSCRIBE受信率は、負荷分散サーバ１によって監視されている。このとき、プレゼンスサーバ２に対する負荷が集中しているために、以下では、そのプレゼンス情報を、他のプレゼンスサーバ２へ登録するように動作する。
（Ｓ４１０）ウォッチャ４が、プレゼンティティ３のプレゼンス情報に対するSUBSCRIBEメッセージを、負荷分散サーバ１へ送信したとする。負荷分散サーバ１は、新たにプレゼンティティ３のプレゼンス情報を持つプレゼンスサーバを追加する。まず、プレゼンティティ３のプレゼンス情報を取得するため、負荷分散サーバ１は、Expires（有効期間）ヘッダを０に設定したプレゼンティティ３のプレゼンス情報に対するSUBSCRIBEメッセージを、プレゼンスサーバ２へ送信する。これは、有効期間の更新を意味しない。
以下は、この場合のSUBSCRIBEメッセージのフォーマット例である。
SUBSCRIBE sip:presentity@example.com SIP/2.0 ［PRS-URI］
Via SIP/2.0/UDP
Event: ［イベント名］
To:<sip:presentity@example.com> ［PRS-URI］
From:<sip:load-balance@example.com> ［負荷分散サーバのSIP URI］
Expires: 0 ［購読の有効期間＝０］
Call-ID:
CSeq: 1 SUBSCRIBE
（Ｓ４１１）これに対し、プレゼンスサーバ２は、200OKメッセージを負荷分散サーバ１へ返信する。
（Ｓ４１２）次に、プレゼンスサーバ２は、NOTIFYメッセージを、負荷分散サーバ１へ送信する。NOTIFYメッセージは、プレゼンティティ３のプレゼンス情報を含む。
以下は、この場合のNOTIFYメッセージのフォーマット例である。
NOTIFY sip:load-balance@example.com SIP/2.0 ［負荷分散サーバのSIP URI］
Via SIP/2.0/UDP
Event: ［イベント名］
To:<sip:load-balance@example.com> ［負荷分散サーバのSIP URI］
From:<sip:presentity@example.com> ［PRS-URI］
Call-ID:
CSeq: 1 NOTIFY
Subscription-Status: terminated; expires=timeout［購読の状態、有効期間］
<中略>
<プレゼンス情報>
（Ｓ４１３）NOTIFYメッセージを受信した負荷分散サーバ１は、そのプレゼンス情報を取得することができる。そして、200OKメッセージを、プレゼンスサーバ２へ返信する。
（Ｓ４１４）ここで、負荷分散サーバ１は、そのプレゼンス情報を登録すべき別のプレゼンスサーバＰを選択する。このプレゼンスサーバＰは、そのSUBSCRIBE受信率が所定閾値Ｔｓ以下であることを要する。そして、負荷分散サーバ１は、そのプレゼンス情報を含むPUBLISH(INITIAL)メッセージを、選択されたプレゼンスサーバＰへ送信する。これにより、処理負荷の小さいプレゼンスサーバＰに対して、そのプレゼンス情報を登録することができる。尚、登録の有効期間は、パブリッシュ用データベースから、該当するプレゼンス情報を持つ他のプレゼンスサーバと同じ有効期間を設定する。
以下は、この場合のPUBLISHメッセージのフォーマット例である。
PUBLISH sip:presentity@example.com SIP/2.0 ［PRS-URI］
Via SIP/2.0/UDP
Event: ［イベント名］
To:<sip:presentity@example.com> ［PRS-URI］
From:<sip:presentity@example.com> ［PRS-URI］
Expires: ［登録の有効期間］
Call-ID:
CSeq: 1 PUBLISH
（Ｓ４１５）これに対し、プレゼンスサーバＰは、200OKメッセージを負荷分散サーバ１へ返信する。
（Ｓ４１６）次に、負荷分散サーバ１は、プレゼンスサーバＰから200OKメッセージを受信すると、ＳＩＰの302 Moved Temporarilyをウォッチャ４へ返信する。302 Moved
Temporarilyは、新たにプレゼンス情報を登録したプレゼンスサーバＰのSIP-URIを含む。
（Ｓ４１７）302 Moved Temporarilyを受信したウォッチャ４は、リダイレクトによって、302 Moved Temporarilyに含まれるプレゼンスサーバＰのSIP-URIへ向けて、SUBSCRIBEメッセージを送信する。即ち、SUBSCRIBEメッセージは、負荷分散サーバ１を介することなく、直接的にプレゼンスサーバへ送信される。
（Ｓ４１８）プレゼンスサーバＰは、ウォッチャ４からSUBSCRIBEメッセージを受信すると、既存のプレゼンスサーバと同様に、200OKメッセージをウォッチャ４へ返信する。プレゼンスサーバＰは、既に、負荷分散サーバ１からPUBLISH(INITIAL)メッセージを受信しており、そのプレゼンス情報を登録している。
（Ｓ４１９）次に、プレゼンスサーバＰは、NOTIFYメッセージを、ウォッチャ４へ送信する。NOTIFYメッセージは、プレゼンティティ３のプレゼンス情報を含む。
（Ｓ４２０）NOTIFYメッセージを受信したウォッチャ４は、そのプレゼンス情報を取得する。そして、200OKメッセージを、プレゼンスサーバ２へ返信する。
図４によれば、ある特定のプレゼンス情報に対して多くのSUBSCRIBEメッセージが集中して送信される場合であっても、そのプレゼンス情報を登録するプレゼンスサーバの数を増加させることにより、プレゼンス情報の負荷を分散管理することができる。
図５は、本発明における第２のシーケンス図である。
PUBLISHメッセージは、新規登録のためのINITIALと、プレゼンス情報の登録における有効期限の更新のためのREFRESHと、プレゼンス情報の内容変更のためのMODIFYとに分類される。PUBLISH(REFRESH／MODIFY)メッセージには、SIP-If-Matchヘッダが付加されており、PUBLISH(INITIAL)メッセージには、SIP-If-Matchヘッダが付加されていない。PUBLISH(REFRESH／MODIFY)メッセージは、そのSIP-If-Matchヘッダに、INITIAL（初回）登録時に対する200OKメッセージのSIP-ETagヘッダフィールドのエンティティタグを格納する。これによって、プレゼンスサーバ２及び負荷分散サーバ１は、登録済みのプレゼンス情報に対するPUBLISHメッセージであると認識することができる。
「SIP-If-Match」ヘッダは、以前に発行したイベントステートに関するPUBLISHレスポンス(200OK)で指定されたSIP-ETagヘッダ値を指定する。これは、以前に発行されたイベントステートを更新する場合に、PUBLISHメッセージによって更新、修正又は削除させる特定のイベントステートを識別するものである。
「SIP-ETag」ヘッダは、PUBLISHメッセージを受信した場合に、ＥＳＣ(Event State Compositor)が生成したエンティティタグ（リクエスト識別子）である。
図５によれば、PUBLISH(REFRESH/MODIFY)メッセージを受信した場合のシーケンスについて表している。
（Ｓ５０１）プレゼンティティ３は、既に登録したプレゼンス情報の再登録及び内容変更について、PUBLISH(REFRESH/MODIFY)メッセージを負荷分散サーバ１へ送信する。負荷分散サーバ１は、そのプレゼンス情報を既に登録しているプレゼンスサーバＰを検索し、そのプレゼンスサーバＰへそのPUBLISH(REFRESH/MODIFY)メッセージを送信する。
（Ｓ５０２）これに対し、プレゼンスサーバＰは、プレゼンティティ３のプレゼンス情報の再登録及び内容変更をする。そして、プレゼンスサーバＰは、200OKメッセージを負荷分散サーバ１へ返信する。
（Ｓ５０３）このとき、負荷分散サーバ１は、そのプレゼンス情報を既に登録しているプレゼンスサーバＰにおけるSUBSCRIBE受信率を検索する。SUBSCRIBE受信率が、所定閾値Ｔｓ以下でない場合、即ち、そのプレゼンスサーバＰの処理負荷が高い場合には、他のプレゼンスサーバ２へ、そのプレゼンス情報を登録する。
ここで、プレゼンスサーバＰのSUBSCRIBE受信率が、所定閾値Ｔｓ以下でないとする。このとき、負荷分散サーバ１は、そのプレゼンス情報を登録すべき別のプレゼンスサーバＰnewを選択する。このプレゼンスサーバＰnewは、そのSUBSCRIBE受信率が所定閾値Ｔｓ以下であることを要する。そして、負荷分散サーバ１は、そのプレゼンス情報を含むPUBLISH(INITIAL)メッセージを、選択されたプレゼンスサーバＰnewへ送信する。この際、SIP-If-Matchヘッダは含めないことに注意されたい。これにより、処理負荷の小さいプレゼンスサーバＰnewに対して、そのプレゼンス情報を登録することができる。
（Ｓ５０４）プレゼンスサーバＰnewは、200OKメッセージを負荷分散サーバ１へ返信する。また、負荷分散サーバ１は、その200OKメッセージのSIP-ETagヘッダフィールドのエンティティタグを、サブスクライブ用データベースに格納する。そして、200OKメッセージは、プレゼンティティ３へ返信される。このプレゼンティティ３は、代表エンティティタグをSIP-If-Matchヘッダに付与したPUBLISH(REFRESH/MODIFY)メッセージの送信元である。代表エンティティタグは、あるプレゼンス情報に対して最初にPUBLISHメッセージを受信したプレゼンスサーバからの200OKメッセージに含まれるSIP-ETagヘッダフィールドのエンティティタグを用いてもよい。例えば、この場合は、プレゼンスサーバＰの200OKメッセージが該当する。また、負荷分散サーバ１が独自に生成してもよい。
（Ｓ５０５）その後、プレゼンスサーバ２に対して、そのプレゼンス情報の購読を要求するSUBSCRIBEメッセージの数が減少してきたとする。そのプレゼンスサーバ２に対する購読の有効時間の最大値は、負荷分散サーバ１によって監視されている。
SUBSCRIBEメッセージの数が減少することによって、サブスクライブ用データベース１０３に記憶されたSUBSCRIBEの有効期間が、現在時刻を過ぎる場合がある。これは、プレゼンスサーバ２においてそのプレゼンス情報に対する有効な購読がないことを意味する。このとき、負荷分散サーバ１は、SUBSCRIBEの有効期間が現在時刻を過ぎたプレゼンスサーバ２について、エントリリストから削除する。これにより、負荷分散サーバ１は、その後、プレゼンティティ３からのPUBLISH(REFRESH/MODIFY)メッセージ及びウォッチャ４からのSUBSCRIBEメッセージを受信しても、エントリリストから削除されたプレゼンスサーバ２へ、メッセージを送信することはない。但し、負荷分散サーバ１は、各プレゼンス情報について、最低１つはそれを登録するプレゼンスサーバを残すものとする。
（Ｓ５０６）プレゼンティティ３は、既に登録したプレゼンス情報の再登録及び内容変更について、PUBLISH(REFRESH/MODIFY)メッセージを負荷分散サーバ１へ送信する。負荷分散サーバ１は、そのプレゼンス情報を既に登録しているプレゼンスサーバＰを検索し、そのプレゼンスサーバＰへそのPUBLISH(REFRESH/MODIFY)メッセージを送信する。
（Ｓ５０７）これに対し、プレゼンスサーバＰは、そのプレゼンス情報を登録する。そして、プレゼンスサーバＰは、200OKメッセージを負荷分散サーバ１へ返信する。また、負荷分散サーバ１は、その200OKメッセージを、PUBLISH(REFRESH/MODIFY)メッセージを送信したプレゼンティティ３へ返信する。
ここで、PUBLISHメッセージ及び200OKメッセージの送受信方法について説明する。ここで、ＭＡＣ(Media Access Control)アドレス変換によるＤＳＲを用いる場合と、ＩＰアドレス変換ＮＡＴを用いる場合とがある。
［ＭＡＣアドレス変換によるＤＳＲを用いる場合］
負荷分散サーバ１及びプレゼンスサーバ２は、同一リンク上に接続される。
（１）負荷分散サーバ１が、プレゼンスサーバ２へ送信するPUBLISHメッセージ
PUBLISHメッセージの送信先ＭＡＣアドレス：プレゼンスサーバ２のＭＡＣアドレス
送信先ＩＰアドレス：負荷分散サーバ１のＩＰアドレス
プレゼンスサーバ２のループバックインタフェースには、負荷分散サーバ１と同じＩＰアドレスが付与されている。従って、プレゼンスサーバ２は、このPUBLISHメッセージを受信することができる。
（２）プレゼンスサーバ２が、プレゼンティティ３へ送信する200OKメッセージ
200OKメッセージの送信元ＭＡＣアドレス：プレゼンスサーバＰのＭＡＣアドレス
送信元ＩＰアドレス：負荷分散サーバ１のＩＰアドレス
送信先ＩＰアドレスは、プレゼンティティ（又はそのプロキシサーバ）とするために、200OKメッセージは、プレゼンティティ３へ直接到達する。
［ＩＰアドレス変換によるＮＡＴを用いる場合］
（１）負荷分散サーバ１が、プレゼンスサーバ２へ送信するPUBLISHメッセージ
ウォッチャから送信されるSUBSCRIBEメッセージの送信先ＩＰアドレス：
プレゼンスサーバ２のＩＰアドレス
（２）プレゼンスサーバ２が、プレゼンティティ３へ送信する200OKメッセージ
負荷分散サーバ１は、プレゼンスサーバ２のデフォルト経路、又はプレゼンスサーバ２におけるPUBLISHメッセージに対する200OKメッセージのSIPプロキシとして動作する。
負荷分散サーバ１は、プレゼンスサーバから受信した200OKメッセージを、プレゼンティティへ送信する場合、200OKメッセージの送信元ＩＰアドレスを、負荷分散サーバのＩＰアドレスに変換する。
次に、SUBSCRIBEメッセージ及びNOTIFYメッセージの送受信方法について説明する。
［ＭＡＣアドレス変換によるＤＳＲを用いる場合］
（１）SUBSCRIBEのダイアログが生成されていない場合、302 Moved Temporarilyの場合と同様の方法で、SUBSCRIBEメッセージを送信するプレゼンスサーバ２を決定する。
（２）SUBSCRIBEのダイアログが生成されている場合、ダイアログに対応するプレゼンスサーバ２をサブスクライブ用データベース１０３（表４参照）から検索する。
（３）負荷分散サーバ１が、プレゼンスサーバ２へ送信するSUBSCRIBEメッセージ
SUBSCRIBEメッセージの送信先ＭＡＣアドレス：プレゼンスサーバＰのＭＡＣアドレス
送信先ＩＰアドレス：負荷分散サーバ１のＩＰアドレス
プレゼンスサーバ２のループバックインタフェースには、負荷分散サーバと同じＩＰアドレスが付与される。そのために、負荷分散サーバは、SUBSCRIBEメッセージを受信することができる。
（４）負荷分散サーバ１は、プレゼンスサーバ２へSUBSCRIBEメッセージを送信した後、ダイアログの情報をサブスクライブ用データベース１０３に記録する。
（５）プレゼンスサーバＰが、ウォッチャへ送信する200OKメッセージ
200OKメッセージの送信元ＭＡＣアドレス：プレゼンスサーバ２のＭＡＣアドレス
送信元ＩＰアドレス：負荷分散サーバ１のＩＰアドレス
送信先ＩＰアドレスは、ウォッチャ（又はそのプロキシサーバ）とするため、200OKメッセージは、ウォッチャへ直接到達する。
［ＩＰアドレス変換ＮＡＴを用いる場合］
（１）SUBSCRIBEのダイアログが生成されていない場合、302 Moved Temporarilyの場合と同様の方法で、SUBSCRIBEメッセージを送信するプレゼンスサーバ２を決定する。
（２）SUBSCRIBEのダイアログが生成されている場合、ダイアログに対応するプレゼンスサーバ２をサブスクライブ用データベース１０３（表４参照）から検索する。
（３）負荷分散サーバ１が、プレゼンスサーバＰへ送信するSUBSCRIBEメッセージ
SUBSCRIBEメッセージの送信先ＩＰアドレス：
ダイアログに対応したプレゼンスサーバＰのＩＰアドレス
（４）プレゼンスサーバＰが、ウォッチャへ送信する200OKメッセージ
負荷分散サーバ１は、プレゼンスサーバＰのデフォルト経路として動作し、200OKメッセージを受信した際に、送信元IPアドレスを負荷分散サーバ１のものに変換してウォッチャへ送信する。
図６は、本発明におけるプレゼンスサーバ選択部のフローチャートである。
プレゼンスサーバ選択部には、PRS-URI及びEventを入力する。
（Ｓ６０１）最初に、Numフラグを０に設定する。
（Ｓ６０２）ハッシュ値Hash(PRS)を導出する。ハッシュ関数への引数は、例えば以下のようなものである。
Hash(PRS)＝Hash（PRS-URI／Event／Num）
”／”は区切り文字
ここで、プレゼンスサーバリスト蓄積部１０１を検索する。プレゼンスサーバＵＲＩ(SIP-URI)に対応付けて、そのSIP-URIを引数とするハッシュ値Hash(SIP-URI)が記録されている。
（Ｓ６０３）次に、Hash(PRS)に最も近いHash(SIP-URI)を有するプレゼンスサーバを検索する。検索されたプレゼンスサーバを、プレゼンスサーバＰと設定する。
（Ｓ６０４）次に、負荷分散サーバ１は、サブスクライブ用データベース１０３に記録されたプレゼンスサーバＰにおける、SUBSCRIBE受信率（単位時間当たりの総SUBSCRIBE数）が所定閾値Ｔｓ以下か否かを判定する。ここで、所定閾値Ｔｓよりも高い場合は、そのプレゼンスサーバＰに対してSUBSCRIBEメッセージが集中しているために、他のプレゼンスサーバを選択する必要があると考える。
（Ｓ６０５）SUBSCRIBE受信率が所定閾値Ｔｓより高い場合、Numを１増分する。これによって、次に算出されるハッシュ値Hash(PRS)が異なる値となり、他のプレゼンスサーバＰが選択されることとなる。このように、SUBSCRIBE受信率が所定閾値Ｔｓ以下であるプレゼンスサーバＰが検出されるまで、Numを１増分しつつ繰り返す。
最終的に、SUBSCRIBE受信率が所定閾値Ｔｓ以下となるプレゼンスサーバＰが選択さることとなる。
図７は、本発明におけるエントリ検索部のフローチャートである。
エントリ検索部には、PRS-URI、Event及びSIP-If-Matchヘッダフィールドのエンティティタグを入力する。
（Ｓ７０１）最初に、パブリッシュ用データベース１０２から、PRS-URI、Event及びエンティティタグに一致するエントリを検索する。このとき、現在時刻が、そのエントリに含まれる有効期間内であることも要する。尚、SIP-If-Matchヘッダフィールドのエンティティタグは、エントリの代表エンティティタグと一致していることを要する。
（Ｓ７０２）パブリッシュ用データベース１０２から、対象となるエントリが検索されなかった場合、402 Conditional Request Failedをプレゼンティティ３へ返信する。
（Ｓ７０３）パブリッシュ用データベース１０２によって、対象となるエントリが検索された場合、そのエントリのエントリリストに含まれるプレゼンスサーバの中で、最もSUBSCRIBE受信率が少ないプレゼンスサーバＰを、サブスクライブ用データベース１０３を用いて検索する。
図８は、PUBLISHメッセージを受信した場合における負荷分散サーバのフローチャートである。
（Ｓ８０１）受信したPUBLISHメッセージが、INITIALであるか、又はREFRESH／MODIFYであるかを判定する。SIP-If-Matchヘッダが無いPUBLISHメッセージは、INITIALと判定される。
（Ｓ８０２）PUBLISH(INITIAL)メッセージである場合、そのプレゼンス情報は未登録であるので、プレゼンスサーバ選択処理（図６参照）によって、プレゼンスサーバＰを選択する。プレゼンスサーバＰによれば、SUBSCRIBE受信率は所定閾値Ｔｓ以下である。
（Ｓ８０３）そのプレゼンスサーバＰへ、PUBLISH(INITIAL)メッセージを送信する。
（Ｓ８０４）そして、負荷分散サーバ１は、プレゼンスサーバＰからの200OKメッセージの受信を待つ。
（Ｓ８０５）プレゼンスサーバＰから200OKメッセージを受信すると、負荷分散サーバ１は、プレゼンティティ３へ200OKメッセージを返信する。
（Ｓ８０６）これによって、負荷分散サーバ１は、プレゼンスサーバＰに、プレゼンティティのプレゼンス情報が登録されたと認識する。このとき、負荷分散サーバ１のパブリッシュ用データベース１０２において、そのPRS-URI及びEventのエントリを検索する。そして、そのエントリのエントリリストの中に、そのプレゼンスサーバＰのSIP-URIと、200OKメッセージのSIP-ETagヘッダフィールドに含まれるエンティティタグとを記録する。
また、現在時刻に、200OKメッセージのExpiresヘッダフィールドの値を加えた値が、有効期間（＝初期値０）よりも大きい場合、その値を有効期間に入力する。また、代表エンティティタグには、プレゼンティティへ送信した200OKメッセージのExpiresヘッダフィールドの値を入力する。
（Ｓ８１２）PUBLISH(REFRESH／MODIFY)メッセージである場合、エントリ検索処理（図７参照）によって、プレゼンスサーバＰを選択する。
（Ｓ８１３）次に、サブスクライブ用データベース１０３に記録されたプレゼンスサーバＰにおける、SUBSCRIBE受信率が所定閾値Ｔｓ以下か否かを判定する。
（Ｓ８１４）プレゼンスサーバＰのSUBSCRIBE受信率が所定閾値Ｔｓ以下でない場合、即ち、プレゼンスサーバＰにSUBSCRIBEメッセージが集中して受信されている場合、プレゼンスサーバ選択処理（図６参照）をする。これによって、追加プレゼンスサーバＰnewが選択される。
（Ｓ８１５）パブリッシュ用データベース１０２及びサブスクライブ用データベース１０３について、当該プレゼンス情報に基づくエントリのエントリリストに、追加プレゼンスサーバＰnewの識別子(SIP-URI)を追加する。このとき、エンティティタグは空である。
（Ｓ８１６）追加プレゼンスサーバＰnewへ、PUBLISH(INITIAL)メッセージを送信する。そのPUBLISHメッセージのSIP-If-Matchヘッダは、削除する。
（Ｓ８１７）Ｓ８１３によってプレゼンスサーバＰにおけるSUBSCRIBE受信率が所定閾値Ｔｓ以下である場合、又は、追加プレゼンスサーバＰnewが選択された場合、パブリッシュ用データベース１０２を用いて、当該プレゼンス情報に基づくエントリのエントリリスト内に記録された全てのSIP-URIへ、即ち、全てのプレゼンスサーバへ、PUBLISHメッセージを送信する。但し、パブリッシュ用データベース１０２から、プレゼンスサーバ毎に対応したエンティティタグを検索し、そのエンティティタグを、そのPUBLISHメッセージのSIP-If-Matchヘッダフィールドに格納する。
（Ｓ８１８）いずれか１つのプレゼンスサーバからの200OKメッセージの受信を待つ。
（Ｓ８１９）いずれか１つのプレゼンスサーバから、200OKメッセージを受信した場合、その200OKメッセージを、プレゼンティティ３へ返信する。このとき、200OKメッセージのSIP-ETagヘッダフィールドには、代表エンティティタグを格納する。
（Ｓ８２０）最後に、パブリッシュ用データベース１０２及びサブスクライブ用データベース１０３に対して、PRS-URI及びEventに基づいて、プレゼンスサーバURIに該当する有効期間を更新する。これは、現在時刻に、200OKメッセージのExpiresヘッダフィールドの値を加えたものである。また、追加プレゼンスサーバＰnewのエンティティタグには、追加プレゼンスサーバＰnewから受信した200OKメッセージに含まれるSIP-ETagヘッダフィールドのエンティティタグを格納する。
図９は、SUBSCRIBEメッセージを受信した場合における負荷分散サーバのフローチャートである。
負荷分散サーバ１は、ウォッチャ４から、プレゼンス情報を購読するためのSUBSCRIBEメッセージを受信する。
（Ｓ９０１）SUBSCRIBEメッセージに含まれるPRS-URI及びEventに基づいて、エントリ検索処理（図７参照）によって、プレゼンスサーバＰを検索する。
（Ｓ９０２）検索されたプレゼンスサーバＰについて、SUBSCRIBE受信率が所定閾値Ｔｓ以下であるか否かを判定する。
（Ｓ９０３）検索されたプレゼンスサーバＰについて、SUBSCRIBE受信率が所定閾値Ｔｓよりも高い場合、そのプレゼンス情報を保持するプレゼンスサーバを追加し、そのプレゼンス情報に対する負荷を分散させるように動作する。即ち、プレゼンスサーバＰに対してSUBSCRIBEメッセージが集中して受信されている場合、追加プレゼンスサーバを選択する。ここでは、プレゼンスサーバ選択処理（図６参照）がなされる。これによって、追加プレゼンスサーバＰnewが選択される。
（Ｓ９０４）追加プレゼンスサーバＰnewへ、当該プレゼンス情報を含むPUBLISH(INITIAL)メッセージを送信する。このとき、図４のＳ４１０〜Ｓ４１４のように、プレゼンスＰへSUBSCRIBEメッセージ(Expires＝０)を送信することも好ましい。これによって、ウォッチャ４からのPUBLISH(REFRESH／MODIFY)を受信すること待たずに、受信されるNOTIFYメッセージのボディ部に含まれるプレゼンス情報を取得することができる。
また、負荷分散サーバ１が、各代表エンティティタグに対応するプレゼンス情報について、ウォッチャ４から最後に受信したPUBLISHメッセージを保持しておくものであってもよい。このとき、そのPUBLISHメッセージから、SIP-If-Matchヘッダを削除し、INITIALとする。また、Expiresヘッダフィールドの値には、パブリッシュ用データベース１０２における有効期間から、現在の時間を差し引いた値を格納する。
（Ｓ９０５）追加プレゼンスサーバＰnewからの200OKメッセージの受信を待つ。
（Ｓ９０６）追加プレゼンスサーバＰnewから200OKメッセージを受信すると、パブリッシュ用データベース１１２及びサブスクライブ用データベース１０３に対して、PRS-URI及びEventに基づくエントリのエントリリストに、追加プレゼンスサーバＰnewのSIP-URIを追加する。また、200OKメッセージのSIP-ETagヘッダフィールドのエンティティタグも追加する。
（Ｓ９０７）検索されたプレゼンスサーバＰについて、SUBSCRIBE受信率が所定閾値Ｔｓ以下である場合、又は、追加プレゼンスサーバＰnewを追加した場合、ウォッチャ４へ、プレゼンスサーバＰ又はＰnewに対する302 Moved Temporarilyを送信する。これによって、ウォッチャ４に対して、プレゼンスサーバＰ又はＰnewへのリダイレクトを促す。
（Ｓ９０８）サブスクライブ用データベース１０３に対して、SUBSCRIBE受信率を更新する。また、プレゼンスサーバＰ又はＰnewにおける有効期間も更新する。現在時刻に、SUBSCRIBEメッセージのExpiresヘッダフィールドの値を加えた時刻が、有効期間（＝初期値０）よりも大きい場合、その時刻を有効期間として入力する。
以上、詳細に説明したように、本発明の負荷分散サーバ及びプログラムによれば、ある特定のプレゼンス情報に対して多くのSUBSCRIBEメッセージが集中して送信される場合であっても、そのプレゼンス情報を登録するプレゼンスサーバの数を増加させることにより、プレゼンス情報の負荷を分散管理することができる。
前述した本発明の種々の実施形態において、本発明の技術思想及び見地の範囲の種々の変更、修正及び省略は、当業者によれば容易に行うことができる。前述の説明はあくまで例であって、何ら制約しようとするものではない。本発明は、特許請求の範囲及びその均等物として限定するものにのみ制約される。
従来技術におけるプレゼンスシステムの構成図である。 本発明におけるシステム構成図である。 本発明における負荷分散サーバの機能構成図である。 本発明における第１のシーケンス図である。 本発明における第２のシーケンス図である。 本発明におけるプレゼンスサーバ選択部のフローチャートである。 本発明におけるエントリ検索部のフローチャートである。 PUBLISHメッセージを受信した場合における負荷分散サーバのフローチャートである。 SUBSCRIBEメッセージを受信した場合における負荷分散サーバのフローチャートである。
符号の説明
１ 負荷分散サーバ
１０１ プレゼンスサーバリスト蓄積部
１０２ パブリッシュ用データベース
１０３ サブスクライブ用データベース
１０４ プレゼンスサーバ選択部
１０５ エントリ検索部
１０６ SUBSCRIBE受信率判定部
１０７ メッセージ送受信制御部
１０８ エントリ更新部
１０９ 通信インタフェース部
２ プレゼンスサーバ
３ プレゼンティティ
４ ウォッチャ

Claims (7)

  1. ＳＩＰ(Session Initiation Protocol)／ＳＩＭＰＬＥ(SIP for Instant Messaging and Presence Leveraging Extensions)を用いたプレゼンスシステムに備えられたサーバであって、
    プレゼンス情報を登録するためのPUBLISHメッセージを送信する第１の通信装置と、
    前記プレゼンス情報を購読するためのSUBSCRIBEメッセージを送信する第２の通信装置と、
    受信した前記PUBLISHメッセージに含まれる前記プレゼンス情報を登録し、受信した前記SUBSCRIBEメッセージの送信元装置へ前記プレゼンス情報を含むNOTIFYメッセージを送信する複数のプレゼンスサーバと
    の間で通信可能な負荷分散サーバにおいて、
    前記プレゼンス情報毎のエントリに、当該プレゼンス情報を登録したプレゼンスサーバの識別子のリストを記録したパブリッシュ用データベースと、
    前記プレゼンスサーバ毎に、購読(SUBSCRIBE)メッセージ受信率を記録したサブスクライブ用データベースと、
    前記SUBSCRIBEメッセージ又は前記PUBLISHメッセージを受信した際に、当該プレゼンス情報に基づくエントリに含まれた前記リストの中のプレゼンスサーバについて、前記購読メッセージ受信率が最も低いプレゼンスサーバを選択するエントリ検索手段と、
    選択された前記プレゼンスサーバに基づく前記購読メッセージ受信率が所定閾値Ｔｓよりも高い場合、前記購読メッセージ受信率が所定閾値Ｔｓ以下となるいずれか１つの追加プレゼンスサーバを選択するプレゼンスサーバ選択手段と、
    選択された前記プレゼンスサーバへ、前記PUBLISHメッセージを送信するメッセージ送受信制御手段と
    を有することを特徴とする負荷分散サーバ。
  2. 前記プレゼンスサーバ選択手段は、
    前記プレゼンス情報の一部を引数とするハッシュ関数によって、前記複数のプレゼンスサーバの中からいずれか１つのプレゼンスサーバを選択し、
    選択された当該プレゼンスサーバに対する購読メッセージ受信率が所定閾値Ｔｓ以下か否かを判定し、
    その判定を真とする前記プレゼンスサーバが検出されるまで、プレゼンスサーバの選択を繰り返す
    ことを特徴とする請求項１に記載の負荷分散サーバ。
  3. 前記メッセージ送受信制御手段は、第２の通信装置から受信した前記SUBSCRIBEメッセージを前記プレゼンスサーバへ送信するために、
    前記プレゼンスサーバのアドレスを含むリダイレクト要求を、第２の通信装置へ返信するか、ＤＳＲ(Direct Server Return)方式によって前記プレゼンスサーバへ前記SUBSCRIBEメッセージを送信するか、又は、ＮＡＴ(Network Address Translation)方式によって前記プレゼンスサーバへ前記SUBSCRIBEメッセージを送信する
    ことを特徴とする請求項１又は２に記載の負荷分散サーバ。
  4. 前記SUBSCRIBEメッセージを受信した際に、前記追加プレゼンスサーバへ前記PUBLISHメッセージを送信する場合、
    前記メッセージ送受信制御手段は、当該プレゼンス情報に基づくエントリに含まれる前記リストの中のいずれか１つのプレゼンスサーバへ前記PUBLISHメッセージを送信し、該プレゼンスサーバから前記NOTIFYメッセージによってプレゼンス情報を受信し、該プレゼンス情報を含むPUBLISHメッセージを、前記追加プレゼンスサーバへ送信する
    ことを特徴とする請求項１から３のいずれか１項に記載の負荷分散サーバ。
  5. 前記PUBLISHメッセージを受信した際に、前記追加プレゼンスサーバへ前記PUBLISHメッセージを送信する場合、
    前記メッセージ送受信制御手段は、当該プレゼンス情報に基づくエントリに含まれる前記リストの中の全てのプレゼンスサーバへ前記PUBLISHメッセージを送信すると共に、前記追加プレゼンスサーバへ前記PUBLISHメッセージを送信する
    ことを特徴とする請求項１から４のいずれか１項に記載の負荷分散サーバ。
  6. 前記サブスクライブ用データベースは、前記プレゼンス情報毎に、更に有効期間を含んでおり、
    前記エントリ検索手段は、前記サブスクライブ用データベースに記憶されたSUBSCRIBEメッセージの有効期間が、現在時刻を過ぎたプレゼンスサーバについて、エントリリストから削除することを特徴とする請求項１から５のいずれか１項に記載の負荷分散サーバ。
  7. ＳＩＰ／ＳＩＭＰＬＥを用いたプレゼンスシステムに備えられたサーバであって、
    プレゼンス情報を登録するためのPUBLISHメッセージを送信する第１の通信装置と、
    前記プレゼンス情報を購読するためのSUBSCRIBEメッセージを送信する第２の通信装置と、
    受信した前記公開メッセージに含まれる前記プレゼンス情報を登録し、受信した前記購読メッセージの送信元装置へ前記プレゼンス情報を含むNOTIFYメッセージを送信する複数のプレゼンスサーバと
    の間で通信可能なサーバに搭載されたコンピュータを機能させる負荷分散プログラムであって、
    前記プレゼンス情報毎のエントリに、当該プレゼンス情報を登録したプレゼンスサーバの識別子のリストを記録したパブリッシュ用データベースと、
    前記プレゼンスサーバ毎に、購読(SUBSCRIBE)メッセージ受信率を記録したサブスクライブ用データベースと、
    前記SUBSCRIBEメッセージ又は前記PUBLISHメッセージを受信した際に、当該プレゼンス情報に基づくエントリに含まれた前記リストの中のプレゼンスサーバについて、前記購読メッセージ受信率が最も低いプレゼンスサーバを選択するエントリ検索手段と、
    選択された前記プレゼンスサーバに基づく前記SUBSCRIBEメッセージ受信率が所定閾値Ｔｓよりも高い場合、前記購読メッセージ受信率が所定閾値Ｔｓ以下となるいずれか１つの追加プレゼンスサーバを選択するプレゼンスサーバ選択手段と、
    選択された前記プレゼンスサーバへ、前記公開メッセージを送信するメッセージ送受信制御手段と
    してコンピュータを機能させることを特徴とする負荷分散プログラム。
JP2007174983A 2007-07-03 2007-07-03 プレゼンス情報の負荷を分散管理する負荷分散サーバ及びプログラム Expired - Fee Related JP4753316B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2007174983A JP4753316B2 (ja) 2007-07-03 2007-07-03 プレゼンス情報の負荷を分散管理する負荷分散サーバ及びプログラム
US12/142,219 US7885191B2 (en) 2007-07-03 2008-06-19 Load balance server and method for balancing load of presence information

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007174983A JP4753316B2 (ja) 2007-07-03 2007-07-03 プレゼンス情報の負荷を分散管理する負荷分散サーバ及びプログラム

Publications (2)

Publication Number Publication Date
JP2009015485A JP2009015485A (ja) 2009-01-22
JP4753316B2 true JP4753316B2 (ja) 2011-08-24

Family

ID=40221334

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007174983A Expired - Fee Related JP4753316B2 (ja) 2007-07-03 2007-07-03 プレゼンス情報の負荷を分散管理する負荷分散サーバ及びプログラム

Country Status (2)

Country Link
US (1) US7885191B2 (ja)
JP (1) JP4753316B2 (ja)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4925130B2 (ja) * 2007-12-14 2012-04-25 Ｋｄｄｉ株式会社 通信制御方法およびシステム
WO2010040893A1 (en) * 2008-10-10 2010-04-15 Nokia Corporation System and method for re-publication of information in a network-based communication system
EP2222106A1 (en) * 2009-02-24 2010-08-25 Research In Motion Limited Method and system for registering a presence user with a presence service
EP2222056A1 (en) * 2009-02-24 2010-08-25 Research In Motion Limited Method and system for updating a virtual business card
US8606233B2 (en) * 2009-02-24 2013-12-10 Blackberry Limited Content-based publication-subscription system for presence information
US8060572B2 (en) * 2009-02-24 2011-11-15 Research In Motion Limited Subscription management for a content-based presence service
JP5633457B2 (ja) * 2011-03-30 2014-12-03 富士通株式会社 基地局、通信システム、及び通信方法
US10104131B2 (en) * 2011-05-06 2018-10-16 International Business Machines Corporation Managing session initiation protocol subscription dialog state loss
US8661108B2 (en) 2011-05-26 2014-02-25 International Business Machines Corporation Status determination in computer network-based communications system
US9253278B2 (en) * 2012-01-30 2016-02-02 International Business Machines Corporation Using entity tags (ETags) in a hierarchical HTTP proxy cache to reduce network traffic
US9043415B2 (en) 2012-05-09 2015-05-26 International Business Machines Corporation Managing a subscription hierarchy in presence systems
JP5928148B2 (ja) * 2012-05-18 2016-06-01 株式会社リコー 伝送管理システム、伝送システム、及び伝送管理システム用プログラム
US9055118B2 (en) * 2012-07-13 2015-06-09 International Business Machines Corporation Edge caching using HTTP headers
US9299111B2 (en) * 2012-09-04 2016-03-29 Futurewei Technologies, Inc. Efficient presence distribution mechanism for a large enterprise
US10454802B2 (en) * 2015-06-30 2019-10-22 T-Mobile Usa, Inc. Backend polling based on nonzero SIP subscribe expiration
CN107948088B (zh) * 2018-01-05 2021-10-01 宝牧科技（天津）有限公司 一种网络应用层负载均衡的方法

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3502009B2 (ja) * 2000-04-14 2004-03-02 日本電信電話株式会社 負荷分散制御装置および方法ならびに記録媒体
JP2002163241A (ja) * 2000-11-29 2002-06-07 Ntt Data Corp クライアントサーバシステム
US20040024861A1 (en) * 2002-06-28 2004-02-05 Coughlin Chesley B. Network load balancing
US20040059781A1 (en) * 2002-09-19 2004-03-25 Nortel Networks Limited Dynamic presence indicators
US7421454B2 (en) * 2004-02-27 2008-09-02 Yahoo! Inc. Method and system for managing digital content including streaming media
US8089972B2 (en) * 2004-05-03 2012-01-03 Level 3 Communications, Llc Registration redirect server
US7676577B2 (en) * 2004-12-21 2010-03-09 Alcatel Lucent Scalable presence distribution system and method
JP4460512B2 (ja) * 2005-05-06 2010-05-12 株式会社日立製作所 計算機システムおよび計算機制御方法
JP2006352662A (ja) * 2005-06-17 2006-12-28 Matsushita Electric Ind Co Ltd サーバ装置、参照端末装置、および通信方法
JP2007004361A (ja) * 2005-06-22 2007-01-11 Mitsubishi Electric Corp 負荷分散装置
JP4241760B2 (ja) * 2006-05-18 2009-03-18 株式会社日立製作所 負荷分散システム

Also Published As

Publication number Publication date
US7885191B2 (en) 2011-02-08
US20090010163A1 (en) 2009-01-08
JP2009015485A (ja) 2009-01-22

Similar Documents

Publication Publication Date Title
JP4753316B2 (ja) プレゼンス情報の負荷を分散管理する負荷分散サーバ及びプログラム
JP4856179B2 (ja) Ｉｍｓにおけるアプリケーションサーバの割当方法および装置
EP1759513B1 (en) Method, system and computer program to enable querying of resources in a certain context by defining a sip event package
US8254288B2 (en) Method and an arrangement for handling a service request in a multimedia network
US20060123116A1 (en) Service discovery using session initiating protocol (SIP)
CN101326493B (zh) 用于多处理器服务器中的负载分配的方法和装置
JP4749469B2 (ja) Ｘｄｍサービス情報管理システム及び方法
EP2173115A1 (en) Method for obtaining device information of a user terminal and communication service function entity thereof
US20040128344A1 (en) Content and service registration, query and subscription, and notification in networks
EP2741541B1 (en) Capability inquiry method, communication terminal and application server
EP1634427A1 (en) Service registration, subscription and notification across local service discovery domains
CN101388837A (zh) 路由选择方法、业务网络、网络设备及终端
KR20090087790A (ko) 통합 메시징 서비스의 인터워킹 방법
KR101375983B1 (ko) 멀티미디어 서브시스템, 시그널링 메시지 전송 방법, 질의 기능 엘리먼트 및 연합 기능 엘리먼트
EP1925140B1 (en) Method and apparatus for keeping information up to date at an ims client
WO2009015587A1 (fr) Procédé, système et appareil de routage soap
EP2068524A1 (en) A method and a system for acquiring the transmission path of the sip message
KR20090087791A (ko) 비통합메시징 서비스와 인터워킹하기 위한 통합메시징서비스 제공 시스템 및 방법
EP2845359B1 (en) Call routing for ip multimedia subsystem users
US20110289195A1 (en) Method and server for accessing and providing presence information in a communications network
CN101889426A (zh) 减小存在消息的大小的方法
EP2210400B1 (en) A method for event packet handling
CN101102266B (zh) 基于分组网络的路由方法及系统
EP2242242B1 (en) Call control device, call control system, call control method, and call control program
KR20120094809A (ko) 리스트 조회를 이용한 프레즌스 관리 시스템 및 관리 방법

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100121

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110407

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110414

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110425

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110519

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110519

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140603

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees