• 検索結果がありません。

ここではいくつかの基準に沿ってRUNEと先行技術の比較を行う.比較の指標 として,拡張性,実時間性,実コードの利用の可否,シミュレーション構成変更の 容易性,移動モデルと通信モデルの提供の有無を用いた.拡張性の評価は,シミュ レーションの負荷が大きくなった場合にシミュレーションの実行者がシミュレー ションに利用するノードを増すことによって克服できる場合がある場合に拡張性 が有るとした.実時間性に関してはシミュレーションの実行を実時間で行うため の機能を提供している,もしくは有している場合に実時間性が有るとした.シミュ レーション構成変更の容易性はシミュレーションの構成を変更する場合のコスト を抑える機能を提供している場合に有るとした.実コードの利用の可否はシミュ

レーション対象が利用するコードを変更することなくシミュレーションに利用す ることが可能な場合に可能であるとした.移動モデルと通信モデルの提供は,シ ミュレーション対象の移動や通信をシミュレートする際に利用可能なモデルを提 供している場合に有るとした.

拡張性の面では,MobiNetやRUNEではシミュレーションの実行者がシミュレー ションに利用するノード数を決定することが可能である.実時間性では,MobiNet はネイティブなアプリケーションをエミュレーションやシミュレーションを経ずに 実行するため,その実行は実時間であると考えることが可能である.RUNEでは

RUNE managerがノード間の同期を行いながらSpaceの周期的な呼び出しを行う

ことで実時間実行の支援を行う.シミュレーション構成変更の容易性では全てのシ ミュレータで何らかの対応が行われている.実コードの利用はTOSSIM,ATEMU,

MobiNet,RUNEで可能となっている.通信モデルはRUNE以外の全てシミュレー

タで提供されている.移動モデルに関してはMobiNet,MobiRealで提供されてお り,TOSSIM,ATEMUでは言及されていない.RUNEではこれらのいずれも直 接対応してはいないが,多目的ネットワークエミュレータQOMETがこれらの機 能を提供している.

第 7

より高度なシミュレーション環境の構 築にむけて

この章では現在までにRUNEを用いてシミュレーションを行うことによって得 られた知見から,ユビキタスネットワークシミュレーションプラットフォームが 今後備えていくべき機能に関する議論を行う.

ユビキタスネットワークに限らず,シミュレーションを行う際には,同じシミュ レーションを複数回行った場合に必要であれば同じ結果が何度でも得られること が必要である.そのためにはシミュレーションの再現性を保証する機構が必要と なる.

また,シミュレーションの結果が現実の事象やシステムの挙動に対して十分な 忠実性を有しているかを判断する機構が提供されていればシミュレーションプラッ トフォームの利用者によって大変有用である.

RUNEのように,既存のシミュレーション要素をできるだけ活用しつつ大規模 シミュレーションを行おうとするプラットフォーム上では時間に対して様々な概 念をもつシミュレーションターゲットが混在することになる.このような状況で 個々のシミュレーションターゲットが有効に働くためには何が必要かも検討が必 要となる.

以下では,こうしたより高度なシミュレーション環境を実現する機能に関する 検討を行う.

7.1 再現性の保証

シミュレーションの再現性を得るためには,再現性を損なう要素,つまりシミュ レーションの結果に乱数性をもたらす要素を制御する必要がある.シミュレーショ ンの結果に乱数性をもたらす要素には,大別して

• 情報に含まれる乱数性

• シミュレーションの実行における時間的乱数性

の二種類がある.前者は,主に統計的な性質に従うシミュレーションから生成さ れる情報が持つ乱数性である.後者は RUNEのように多数のモジュールが集合し て全体のシミュレーションを構成する場合に問題となる.これは例えば複数のモ ジュールが通信を行うシミュレーションを行う場合に,実行の順序が入れ替わって しまうとパケットの到着順序も影響を受けるといった要因から発生する.実際に はこれらの情報の乱数性と時間の乱数性を独立したものではなく,通信メディア の特性を情報的乱数性を用いて統計的にシミュレートすることによってパケット の再送率が変化し時間的乱数性を招く,時間的乱数性によってモジュールの実行 順序が前後すると取得される乱数値が変化し情報的乱数性が生じる,というよう に互いに影響を及ぼす場合がある.

こうした不必要な乱数性がシミュレーションの結果に与える影響を排除するた めにシミュレーションプラットフォームにおいて実行可能な対策としては,以下 のような方法が有効であると考えられる.

• Space毎に毎回同一の出力系列を生成可能な乱数生成機能の提供

これは例えば以下のコードのように RUNE 内部で Space 毎のコンテキス ト値を管理し,この値を用いて Space 毎に決まった系列の乱数を生成する rand() や srand()互換の関数を提供することで,Space間での実行順序が乱 数の生成に影響を及ぼさなくするもので,少なくともSpace内での乱数の生 成順序を一定とする効果が得られる.

static ctx[nspcs];

void

runeSrand(int gsid, unsigned seed)

{

ctx[gsid] = seed;

} int

runeRand(int gsid) {

return(rand_r(ctx[gsid]));

}

• 静的(オフライン)スケジューリングのサポート

静的スケジューリングのサポートを行うためには,例えば現在 RUNE にお

ける Spaceのエントリポイントの定義,

typedef struct {

void *(*init)(int gsid);

int (*step)(void *elem);

void (*fin)(void *elem);

void *(*read)(void *p, void *a);

void *(*write)(void *p, void *a);

} entryPoints;

typedef struct {

void *(*init)(int gsid);

int (*step)(void *elem);

void (*fin)(void *elem);

void *(*read)(void *p, void *a);

void *(*write)(void *p, void *a);

unsigned int interval;

} entryPoints;

のようにし,各 Spaceのエントリポイント定義時に宣言した呼び出し間隔を もとに予めスケジューリングを行うことで実現可能である.これにより,動 的な呼び出し間隔の変更は不可能となるが,時間的な変動による不必要な乱 数性の発生を抑えることが可能となる.C言語の文法では,

typedef struct {

void *(*init)(int gsid);

int (*step)(void *elem);

void (*fin)(void *elem);

void *(*read)(void *p, void *a);

void *(*write)(void *p, void *a);

unsigned int interval;

} entryPoints;

として宣言された型に対して,

entryPoints ep = { .init = myspace_init, .step = myspace_step, .fin = myspace_fin, .read = myspace_read, .write = myspace_write };

という定義を行うことは問題がなく,またこの ep は Space オブジェクト

の .data セクションに置かれるため,メンバの初期値は 0 となる.そこで,

RUNE では ep.interval の値を確認し,0 であれば通常のスケジューリング

を, 非 0であれば静的スケジューリングを行うということが可能である.

こうした対策でさえ完全には抑えられないような微小の時間的乱数性が問題に なる場合には,問題の原因に応じ

• シミュレーションの実行時間を実時間に対してn倍とする

• パケットに付けたタイムスタンプに基づく受信時キューイングを行う などの対策が考えられる.