性能測定

5.4.2.節で示したシナリオ（1）における処理プロセス B，C&D，E，F の性能 測定結果を示す．それぞれのプロセスを 5 回実行しその平均を求めた．その結 果，ぞれぞれのプロセスは 1 秒前後で完了しており，ストレスなく実行できる ことが分かった（図 5.9）．

さらに，スケーラビリティに関する評価実験を行った．実験は，4.4.3.節で 示したスケーラビリティの実験と同様に，5 台の実機（Real Terminal）にそれ ぞれ 10 台の仮想端末(Virtual Terminal)を実装し，計 50 台の仮想端末を利用

した．そして，指数分布に基づく利用者の到着率λ（到着利用者数／ms）によ り仮想的な利用者を生成し仮想端末に割り当てる利用者割り当て機能(Guest Dispatch Terminal)を有するシミュレータ(図 4.19)を用いた．それぞれの装置 スペックは，表 4.10 で示したものである．

スケーラビリティの評価に利用したシナリオは，5.4.2.節で示したシナリオ

（1）である．評価手順を以下に示す．

① インターネットカフェにおけるＮＷアクセスを利用するため，ローカル UAG 上の IP フィルタリング AP を予約する（5.3.2.節のプロセス D に相当）．

② インターネットカフェにおける共用端末を利用するため，共用端末を予約す る（5.3.2.節のプロセス D に相当）．

③ 会社内の Web サーバを利用するため，Web サーバを予約する（5.3.2.節のプ ロセス D に相当）．

④ IP フィルタリング AP 資源と共用端末資源を組み合わせる（5.3.2.節のプロ セス E に相当）．

⑤ ④で組合わせた IP フィルタリング AP 資源，共用端末資源と Web サーバ資源 を組み合わせる（5.3.2.節のプロセス E に相当）．

⑥ ⑤で組み合わせが完了した資源を起動する（5.3.2.節のプロセス F に相当）．

⑦ ⑥で実行した組み合わせ資源を停止する（5.3.2.節のプロセス G に相当）．

実際の利用シーンでは，利用者が資源アイコンを操作することで，上記の手 順を実施するため，①～⑥の各手順の時間間隔は，固定的に 2 秒と設定した．

また，サービス利用による待ち時間の影響を抑えてサービス認可装置に負荷を かける必要があることから，手順⑥と⑦に該当するサービス利用時間を 3 秒と 固定して評価を行った．

上記の手順により資源の予約，組み合わせ，起動，停止の各処理を連続して 実行した場合のスケーラビリティを評価した結果を図 5.10 に示す．その結果，

λ＝0.0003 の時，つまり 3 秒当たり 1 人の利用者が到着する場合，全体の処理

111

時間は約 20 秒であった．また，λ＝0.001 の時，すなわち 1 秒当たり 1 人の利 用者が到着する場合，全体の処理時間は約 26 秒であった．これらの処理時間に は，固定設定した各手順間の操作待ち時間とサービス利用時間，合わせて 13 秒 が含まれている．そのため，実質的な利用者の待ち時間は，それぞれ，約 7 秒，

約 13 秒となる．

今回は，システム全体のスケーラビリティを評価するという目的から，サー ビス利用時間を極端に短い時間に設定し，利用者の到着率も想定する利用シー ンに比較して大きな値を前提とした．それでも，利用者が資源を指定して，実 際にサービスを受けるまでに実質的に待たされる時間は，10 秒前後であること が分かった．実際の利用シーンでは，サービス利用時間が利用者の待ち時間に 対して支配的な要因となるとともに，利用者の到着率も低い値になると想定さ れることから，スケーラビリティに関しては，実用的には問題ないと考える．

0 200 400 600 800 1000 1200 1400 1600

(ms)

B C&D E F

Resource display

Resource booking

Combination verification

Execution

(Process)

0 200 400 600 800 1000 1200 1400 1600

(ms)

B C&D E F

Resource display

Resource booking

Combination verification

Execution

(Process)

図 5.9 性能評価結果

λ （到着率＝到着利用者数／ms）

Process time (mｓ）

図 5.10 スケーラビリティ評価結果

5.5 考察

5.5.1. 要求条件の達成度

PURE では,4 章で示した分散認証方式をリモート資源にまで拡張し，ローカル 資源とリモートの資源の利用認証とその組み合わせ，さらに組み合わせ資源の 実行制御を実現している．したがって，PURE で満足すべき【要件１】～【要件 ７】の内，４章で示したように【要件１】～【要件 5】までは，満足している．

113

一方， UAG の位置を論理的に示すエリア ID を導入することで，利用権の提示 を受けたローカル UAG は，利用権 ID からリモート UAG の物理アドレスが解決可 能となる．その後は，ローカル UAG とリモート UAG が連携することで，それぞ れの資源利用認証，および資源間の組み合わせ，組み合わせた資源の実行制御 を実施する．これらの処理は，5.3.3.節に示した GUI により利用者からは隠蔽 される．つまり，利用者は，アイコンとして表示される資源を直接，直感的に 操作するだけでよく，煩雑な手順や専門知識を持たなくても，ローカル資源と リモート資源とが連携されたサービスを利用することができる．

このことから，提案する方式は，【要件 6】，【要件 7】を満足している．また，

他の利用者の IC チップ付き携帯電話や IC カードを操作端末付属の IC カードリ ーダ上に載せかえれば，操作端末上に表示されるアイコン，特にリモート資源 のアイコンは一瞬で変わる．これは，利用者によって，取得している利用権が 異なるためである．これはまさに，外出先の環境を利用した個人のホーム環境 のローミングといえる．

以上より，PURE は，本研究の目的である個人適応型ユビキタス環境ローミン グを実現可能なアーキテクチャである．