前節の課題を解決するシステムアーキテクチャを具備した P2P 型プレゼンスシステム を含む分散プレゼンスサービスのアーキテクチャとしてField Castの実装を提案する。プ レゼンスサービスを向上させるために、刻一刻と変わる位置情報や回線状況をプレゼンス 情報に組み込むには、多くの情報の伝達と、短い時間での更新が求められるため、プレゼ ンスサーバの処理能力が課題となる。さらに、プライバシ情報のフィルタリングをコント ロールする要求は、中央サーバに追加の負荷を生じさせる。
図3-2で示されるように、ユビキタスデバイスから生成される情報によってユーザのコ ンテキスト情報の変更が起こる。図中のユビキタスデバイスの例は、環境センサやネット ワークアクセスポイントや GPS や機器の加速度センサなどが想定される。現在の中央サ ーバによるプレゼンスサーバでのユーザコンテキスト情報の交換は、コンテキストを生成 するクライアントとプレゼンスサーバとの通信と、プレゼンスサーバとプレゼンスを確認 するクライアントとの通信の両者を必要とするので、変更が頻繁に起きるケースでは、サ ーバの負荷集中を引き起こす懸念がある。
Presence server
Presence viewer client
Presence viewer client
Presence viewer client
Presence Protocol
-Buddy list -User status
-Buddy list -User status -Buddy list
-User status
Ubiquitous devices
Ubiquitous devices
Ubiquitous devices
Service Provider administrative domain
図3-2 従来の中央サーバ型プレゼンスシステム
3.3.1. P2P 型プレゼンスサーバ
コンテキスト情報が頻繁に交換される際の高負荷への懸念に対して、本論文ではプレゼ ンスサービスのためのP2Pアーキテクチャを提案する。提案方式では、プレゼンス情報の 交換は、それぞれのユーザのコンピューターリソース上のプレゼンスサービスを用いたプ レゼンスサーバグループによって処理される。プレゼンス情報は中央サーバの処理を介さ ずに直接エンドノード間で交換される。
図3-3で示されるように、我々の提案するシステムアーキテクチャではそれぞれのノー ドにプレゼンスサーバ機能を配備する。プレゼンス情報はプレゼンスエンジンと呼ばれる 独立した機能要素によって、生成され端末間で共有が行われる。
Presence server
Presence Engine
-Buddy list -User status
Ubiquitous devices
Ubiquitous devices Presence Engine
-Buddy list -User status
Presence server
-Buddy list -User statusPresence server
Ubiquitous devices
Presence Protocol
図3-3 P2P型プレゼンスシステム
プレゼンスサーバはユーザのコンテキスト情報をそれぞれの端末のネットワークデバ イスなどから収集し、XML タグによる標準化された方法によってプレゼンス情報[23]に 変換し、相互に交換する。
スケーラビリティの観点から、我々の提案するP2Pアーキテクチャと中央サーバ方式で のプレゼンス交換の負荷の量を比較する。中央サーバベースのシステムでは情報処理の負 荷の総量は、全ユーザ数と各ユーザのbuddy member（公開相手として登録ユーザ）の平 均数の積に影響される。この値が大きくなり、サーバリクエストが過負荷になると、サー ビス品質の低下を生じ、それを回避するための負荷分散などのための追加投資が必要とな る。
我々の提案するP2Pアーキテクチャでは、それぞれのノード上のプレゼンスサーバの負 荷は系全体のユーザ数には大きく影響されず、それぞれのユーザの登録ユーザ数に影響さ れると考えられる。この前提に立つと、我々の提案方式は、プレゼンスサービスの利用ユ ーザ数の増加に対するスケーラビリティの点での優位性がある。
3.3.2. P2P での情報共有の既存研究
多くのコンテキスト情報を高い頻度で送るとネットワークの利用効率が下がるため、コ
ンテキスト情報のフィルタリングは帯域幅を管理する上でも重要である。こうした観点か ら中央サーバ方式によるアプローチだけでなく情報共有のための、アーキテクチャとして、
P2Pアーキテクチャの評価が行われている。データ共有におけるサーバ志向とP2P アーキテ クチャの比較検討をM. Margaritisらが行っており[24]、N. Daswaniらはデータ交換のサー ビス品質と負荷分散の観点から比較し[25]、Peer to Peerによる情報交換のメリットが示され ている。一方で、負荷分散の観点だけでなく、カスタマイズ性とプライバシ保護の観点でから エ ン ド ノ ー ド で の コ ン テ キ ス ト 情 報 の 加 工 の 優 位 性 に つ い て は 、 C. Mascolo[26]、L.
Capra[27]の提案がなされている。彼らはユーザコンテキストのポリシ制御の管理にミドルウ ェアを用いるコンセプトを適用している。コンテキスト情報のコミュニケーションとそれをサ ポートするフレームワークは実際の使用法とともに議論されている[28]。これらの先行研究結 果に基づき、この論文での研究は P2P の実装アーキテクチャで、インターフェースデザイン とプライバシ保護のポリシ制御を満たすモジュールを端末に載せる構造を採用することで、分 散処理とプライバシコントロールの両方を成立させることができると考えられる。
3.3.3. SIMPLE プロトコルの採用
開発するプレゼンスエンジン間の通信に関しては、IETF SIMPLE[11]プロトコルをア プリケーション間の転送プロトコルとして用いる。プレゼンスエンジンは SIMPLE の標 準的なシーケンスを適用し、さらに、情報要求への応答の可否についてユーザと対話的に 決める機能を追加する。この機能は図3-4にあるようにSUBSCRIBEを受け取ったプレゼ ンスエンジンは次の3つの選択肢からひとつを選ぶようにユーザに求める。
・ ケース１ メンバーシップの拒否：ユーザはSCURIBEメッセージを廃棄する。
・ ケース２ send onlyのメンバーシップを許可：SUBSCRIBE を受け入れるが相手に はSUBSCRIBEメッセージを返さない。
・ ケース３ メンバーシップを許可：ユーザは UBSCRIBE を受け入れ、双方向のプレ ゼンス情報の交換を開始するためにSUBSCRIBEメッセージを送り返す
こうした対話的なインターフェースでは、上記のプレゼンス情報の公開についての選択を ユーザ端末の上で行う際に、操作を容易にすることが求められる。
Presence Viewer 1
Presence Engine 1
Presence Engine 2
SUBSCRIBE 200 OK（respond immediately）
PAM:
CreateIdentity
SUBSCRIBE 200 OK
PAM:
getIdentityAttribute PAM:deleteIdentity
NOTIFY
NOTIFY Create
Buddy
PAM:
setIdentityAttribute
PAM:setIdentityAttribute State:
“No
reachablity”
State:
“Unidirectional communication”
State:
“Bidirectional communication”
． ．
．
Presence Viewer 2
． ．
．
<case 1>
Membership denial
<case 2>
Membership Acceptance (send only)
（no message to be sent）
<case 3>
Membership Acceptance (send/receive) 図3-4 P2P型プレゼンスシステムでのSIMPLEのシーケンス