2003s Term Project 機器の切り替えにおける時間的連続性を目的としたサービスローミング機構 B3 mics 所属KG move! 目指す世界テレビ電話やストリーミング番組などのリアルタイム性サービスが機器間を移動。その移動時間を皆無とし、ユーザは視点を切り替えるような感覚でサービスを移動させられる世界を目標とする。 Term Project 2003s 目標に向けての今期のアプローチ問題点の明確化 • ブランクタイム  ユーザにサービスが提供されない時間と定義 • 時間的連続性の必要性  ブランクタイムがないことと定義 NAGORIモデルの提案実験用ストップウォッチと評価 • 本モデルの有効性 NAGORIモデルを用いたマルチメディアアプリケーション「BREEZE」β版の作成想定する環境現在の問題点サービスが端末間を移動する際の時間移動する際にサービスは一度停止されるため、停止から再開までの無駄な時間（ブランクタイム）がある。もし時間軸に大きく関係するサービスであった場合、ブランクタイムがユーザの活動を妨害しかねない。端末の切り替えにおける時間的連続性が必要！！解決案 1. サービスが移動し終わるまで、元のサービスを継続させる Copy：移動させるサービスを、元サービスのコピーにすることで可能 2. ライブ性サービスでなかった場合、移動時間分の誤差を考慮する Synchronize：移動元と移動先でサービスの再生や受信開始時間を同期 NAGORIモデル（名残モデル） 5:Resume 3:Prepare 6:Destroy 1:Copy Object A Object B Object B 2:Move 4:Synchronize 実装実験・評価用ストップウォッチ Java1.4.1 移動型マルチメディアアプリケーション「BREEZE」 Java 1.4.1 & JMF 2.1.1e 今回は試作版評価（計測）ブランクタイムがどれだけ減らせたかオブジェクトの大きさによる移動時間の変化ブランクタイムと時間軸の誤差(1) 現実の時間と、ストップウォッチが刻む時間を計測。ストップウォッチを開始するとともに現実の時間を計測開始移動前と移動後の時間を比較。ブランクタイムと時間軸の誤差(2) NAGORIモデルを用いない移動の場合 NAGORIモデルを用いた移動の場合ブランクタイムと時間軸の誤差(3) 本モデルを用いた場合、ブランクタイムと誤差を大幅に抑えることが可能時間的連続性を実現する場合に、 NAGORIモデルは有効な手段であると言えるオブジェクトのサイズ変化による移動時間増加率(1) オブジェクトが大きくなるにつれて、オーバーヘッドがどれほど増えるか。 CopyとShynchronizeが本モデルによって加えられた機能計測方法ストップウォッチに１KBずつ、１０KBまでの重さをつけて端末間を移動させた。（５００回の平均値） Copyからresumeまでの各シーンにおける時間を計測 • • • • • copy writeObject(=move) readObject(=move) arrive(=prepare) resume オブジェクトのサイズ変化による移動時間増加率(2) オブジェクトのサイズ変化による移動時間増加率(3) シリアライズとデシリアライズ時間オブジェクトのサイズ変化により変化 copyとsynchronizeに必要とされる時間サイズの大きなオブジェクトでも、それほど所要時間は変化しない。 →ある程度固定のオーバーヘッドでブランクタイムをなくすことができる。応用例時間的連続性をもった移動型マルチメディアアプリケーション「BREEZE」 β版を作成 • 各端末のローカルファイルの再生。前提：ローカルに同じファイルがある • ビデオのようなストック型ファイルのストリーミングへの対応策の例示デモ応用例での評価移動時間：１．５秒アプリケーションのサイズが大きくなることによって移動時間も増えていく動画のズレ：０．７秒ファイルをシークして再生するにかかる時間と考えられるアプリケーションサイズが大きくなっても、このズレはあまり大きくならない結論 NAGORIモデルのようなシンプルな構造で、サービスの時間的連続性を実現することが可能である。今回のストップウォッチの場合、移動前後の誤差は、わずかな差まで減らすことができた。終わり