fマルチメディア通信と分散処理ワークショップj 平成 16年 12月
拡張メディアストリームによる相互通信セッションの動的構成法
橋本浩二
柴田義孝
岩手県立大学ソフトウェア情報学部
プロードバンドネットワークのす」ピスとして，テレピ趨昔やビデオ会議などの通信ザーピスは実用的なものとなった. しか し通信端末倒揺を将l開可能な帯樹立，網開者の通信環境によって異なるので，適切なフォーマットによる相互通信を実現 するための倣E
みが必要となる.悶?で定義されているトランスコーディング機能比和問者似劃言環境を考慮した相互通信 を実現するために有効な機信であるが，通信環境の異なる複数の参加者を想定したトランスコーディング機能の観的な利用方 法やシステムは確立していない.そこで本稿では利用者環境に応じてトランスコーディング機能をネットワーク上《勘的に 配置し，適切なフォーマットによる相互通信セッションを実現するためのミドノレウェアを提案する.A
D
y
n
a
m
i
c
C
o
n
f
i
g
u
r
a
t
i
o
n
M
e
t
h
o
d
f
o
r
I
n
t
e
r
c
o
m
m
u
n
i
c
a
t
i
o
n
S
e
s
s
i
o
n
b
y
E
x
t
e
n
d
a
b
l
e
M
e
d
i
a
S
t
r
e
a
m
s
K
o
j
i
H
a
s
h
i
m
o
t
o
Y
o
s
h
i
t
a
k
a
S
h
i
b
a
t
a
F
a
c
u
l
t
y
o
f
S
o
f
t
w
a
r
e
a
n
d
I
n
f
o
n
阻t
i
o
nS
c
i
e
n
c
e
，
I
w
a
t
e
P
r
e
f
e
c
t
u
r
a
l
U
n
i
v
e
r
s
i
t
y
o
n
br但dband networks， we can cαmruni伺tewith each other by intercαnnunication services such as video phone， teleconference and so on. However， our cαnputer' s ca開hilities and available network bandwidths are different respectively.Therefore， it is irr脚rtantfor the cαnnunication syst叩 touse suitable fon田tsaccording to users' cαnnunication environments. Although the transcoding function defined by悶P
is a useful function to realize intercαmrunication a也ptedusers' c叩nuni伺tionenvirorm剛 ts，
dynamic transcoding1胞chanismshave not established for multi-user environments. In this paper， we propose a middleware syst伺 torealize interc叩 nunicationservices wi th sui table media fonnat according to users' envirorunents.The middleware syst倒 integratesmul ti但st0αmrunication sessions by凶ingrelocatable transooding functions. 1.はじめに 近年におけるネットワーク技術の進歩により，インターネ ットの末端において利用可能な帯樹高も急速に増加し，映像 や音声を扱う大容量のデータ転送を必要とするアプリケーシ ョンが日常的に利用されるようになった.蓄積型ビデオスト リームの配信に加え，テレビ電話やビデオ会議など相互通信 を実現するシステムも多数存在し，遠隔地問でのコミュニケ ーションが容易に行えるようになった. しかしながら既存の相互通信システム比比3幻 やSIP[l] によるシグナリングプロトコル上でH.263/264， MPEG4などの ビデオフォーマットを用いるものが多く，利用者の通信環境 や 伽S要求に応じて複数のビデオフォーマットを用いた相互 通信を実現するための十分な白調みは実現されていない.例 えば既存の相互通信システムを利用して，DVによる通信セッ ションと MPEG4による通信セッションを動的に統合し， 1つ の相互通信を実現することは困難である. ここで，悶P[2]で定義されているトランスコーディングや ミキシングの機能が利用できれば，例えばDVストリームを MP国4ビデオストリームにトランスコーディングすることに より，利用者の通信環境や伽S要求に応じて適切なフォーマ ットを用いた相互通信が可能となる.しかしながら，複数の 参加者を想定した相互通信におけるトランスコーディングや ムは確立していない.そこで本稿では，利用者環境に応 じてトランスコーディング機能をネットワーク上へ動的 に配置し，適切なフォーマットによる相互通信セッショ ンを実現するためのミドノレウェアを提案する. これまで筆者らは，柔軟な相互通信環境構築のために 必要とされる機能をミド/レウェアとして実現するアーキ テクチャを考案し， トランスコーディングエージェント の動的な配置に関する報告[5]をしてきた.本稿では，柔 軟な相互通信機能を実現するために移動エージェントベ ースのトランスコーディング機能を利用し，複数のマル チキャストセッションを動的に接続する位姐みを実現す る. 2.MidFieldシステム概要 筆者らの提案する MidField (Middleware for Flexible interc咽nunicationenviro鵬 ntby relo回 国ble伽 ision) システムの機能モジュール構成を図 1に示す.本システ ムは，ネットワーク接続されたコンビュータシステムの トランスポート層より上位に位置し，アプリケーション プログラムに対してマルチメディア通信機能を提供する. Stre田IPlaneはマルチメディアストリーム転送処理を 行い， Session Plane は通信セッションの管理を行う.口市申
I
Jn払司兄のI
荘視を行い， システム利用者が嬰求するQ
O
S
に対するアドミッションテストを実行する そして Event ProccssPlancでは，"/ステム内部で発生する各種のイベン トを処理する己
こ
蜘 刷lonPIOg酬帥
胴
"
'
，
加
S~ssJon 伽，~プ4符e S凶lemInlerface MidFieldSystem 図1: MidFieldシステム俄能モジューノレ栴成 Stream Agentは，RTPストリーム処浬を実現するために Strearn50伊entを利J
H
L
-
R
TPストリームの送受信およびトラ ン ス コ ー デ ィ ン グ を 行 う ScssionAgcnt は Session Pro凹rty を所布し，複数0)IlTl'-
t
ッションを統合して MidPieldセシションを実現するためσJ管理機能を実現する また，SystcmAgcntはローカルコンピュータシステムの C間 資i!i.やヰットワークトラフィックを監視し，システム利用者 がMidFieldセッション〈多加する際にはアドミッションテ ストを実符する 一方， AgentPlaccはエージェントの生成・ 起動，移動，終了処理を行い，ローカノレシステム内のエージ ェントを管理する そして，エージェントの移動を実現する ための AgcntLoadcr とAgcntServcrを利用する Agent Place もMidFieldシステムにおけるエージェントのlつで ある これらのエージェントはそれぞれ，コンピュータネットワ ーク上で拐糊する MidFieldシステムI
llJでメッセージの送受 信 が 可能である EventProccssPlancの C onnection Managcrは，MidFicld~ステム nnを接続したソケットインタ ーフェースを保持L，エージェJト間メ、ノセージ通信の排他 的制御を行う また，Syst聞 EventManagcrは，各エージェ ントが発行するνステム内部イベントを Evcnt恥eueに格 納L.Event Processorの TIlreadでイベントを処理する仕 組みを実視する ここで，MidPieldシステムにおける相互通信セッションを MidFieldセッションと呼ぶ lつのMidPieldセッションは観 数の<"1げ キ ャ ストセシションで桝成され，各マノレずーキャス トセッションで利用するメディアストリームを，動的に配位 される1
ランスコーディング機能を用いて中継することで， 利用者の通指m
m
とイリーピス品質1Jl!求に応じた相互通信を実 現する 図2では，2つのマノレチキャストセシションで梢成される MidFieldセッションに3つの利用者端末(MP，肌， MP""MP"，)が 参加している MFUIとW胞は共に，DVストリームによる相 互通信が可能であるが，Mf悶は，flF域不足または DV送受 信-
8
4
処理に井t"f"るα
'U!'i淑不足のため，DVストリームを川い た通信が不可能であるとする そこで.MFUIとMF胞の 通信セッションに参加寸るために MFIOは，MI'EG4ストリ ームによる送受信を要求したとする ここで MidField システムは，必要となるトランスコーディング処理モジ ューノレを，適 切 な ト ラ ン ス コ ー デ ィ ン グ ノ ー ド (MFド，MFr)Iこ動的に配也する図2では，~lFf]I MF.ηがυ
v
ストリームを MI'EG4ビデオストリームヘトランスコー ディングするとともに，MJ¥3が送信する附図4ピデォース トリームをMFnが中継することにより，閥、も相互通信 が可'
i
t
e
となる。 、AdooS曾・~4
圃 { ・g，OIl) _ (o.g.MPE白)回
出
図2: MidFicldScssion概要 3.MidFieldセッション 上述したMidFieldセッションを実現するために，セッ ションエージェントが利用するセッションプロパティの データ構造を図3に示す at.lidflfld1:!フション欄健 ・セフyョンオーナーがaaしているホスト署長 NidFieldSes制時".A周 " 亨 殉 Se$sionI'foperl，通知，III1P?J1o.多キ，ストアト'"ス ， ..，..，ノシヨ，.‘【
・
的
.
.
‘
1 RTP1:!~シヨンクラス IIA lIJ lr字凋 {鋼 一隔仰~.WNormal"田L...-l . '11'セフ...!I;..oへの医大審 λ 呈[b~l.
'J II!I可飽.スドI)_~フォーマットめ組合 . '11'スド')-L.IIIIP"マルチキ.ストアドレ九 {園"な慣帽1-
.・
'11'唱:!'lションへの現毛主遺入掴
.
.
.
a
"
図書1 .スドJーム入出力側‘ 図3 セッションプロパティのデータ構造 セッションプロパティはMidFieldセッyョン毎に l つ桝主L，1つのMidFieldセッション情報と桜数のR1l' Eツションt
N
i
曜により構成される MidFicldセッション を生成するセッションエージェントを Eッν
ョンオ」づ ーと呼び，セッションオーナーがセッションプロパティ を管理する MidFicldセッション!i'HUは，セッションガーナーが稼 動しているホスト名と MidPieldセッション総別Jn文字 列，そしてセッションプロパティ通知用 11'<"ノレチキャス トアドレスで構成される これらのデータは MidFicld セッンョン生成時にセッションオーナーが決定L，。輔、... ISTAT1!:OP割 印 } アドミ型ションテスト このように， MidFieldシステムにおける相互通信は， セッションオーナーが管理するセッションプロパティを もとに行われる.セッ、ンョンへの参加/退出，ストリーム の追加/削除要求を参加者から受信する毎に，セッション オーナーはセッションプロノξティを更新して， MidField セッションの参加者全てにその更新内容を通知する.更 新されたセッションプロパティを受信した参加者はスト リームの到達確認を行い，必要に応じてストリームの拡 張と縮退を実行する. MidFieldセッション終了時まで変更されない静的な情報で ある. 一方， RTPセッション情報は静的な情報と動的な情報によ り構成される.静的な情報には， RTPセッションクラスを識 別する文字列， RTPセッションへのストリームの最大流入量
[
b
p
s
]
と利用可能なストリームフォーマットの集合，そして利 用するI
P
マルチキャストアドレスが含まれる.各町P
セッシ ョンにおけるメディアデータ転送は，このI
P
マルチキャスト アドレスを用いて行われる.参加者は，利用可能なストリー ムフォーマットと最大流入量を参照することにより，各自の 相互通信環境に応じて適切なRTPセッションを選択すること が可能となる.動的な情報には，町Pセッションへの参加者 数，町?セッションで用いられているストリームの現在流入 量[
b
p
s
]
とストリームの入出力情報が含まれる.これらの動的 な情報は，セッションオーナーにより適宜更新され，更新さ れたセッションプロパティはセッションプロパティ通知用I
P
マルチキャストアドレスを用いて参加者全てに通知され る. 3. 2 ストリームの拡張と織昼 更新されたセッションプロパティを受信した各参加者 はストリームの到達確認をし，必要に応じてストリーム の拡張と縮退を行う.その概略を図6に示す.ご
弔
問
iE
E
;
;
噴
"
芯
仁
F7F-3. 1セッションへの参加とストリームの追加 MidFieldセッションを開員合するためには，まずアプリケー ションがセッションプロパティを用意する.次に，セッショ ンオーナーへセッションプロパティを与えることによって， セッションオーナーはMidFieldセッションを生成し，相互通 信が可能となる.一方， MidFieldセッションハ夢加するため には，セッションオ}ナーが稼動しているMidFieldシステム よりセッションプロパティを取得し，適切な町Pセッション への参加要求をセッションオーナーへ送信する.MidFieldセ ッションへ参加する際のメッセージフローを図4に示す.参 加者からの要求に対し，セッションオーナーはセッションプ ロパティを更新し，その参加者へ応答を返す.一方，更新さ れたセッションプロパティは全ての参加者へマルチキャスト にて通知される.セッションからの退出とストリームの削除 に関するセッションオ}ナーと参加者間のメッセージフロー もほ悶司じ流れとなる. 図6(a)に示す通り，参加者のいるRTPセッションへス トリームが到達していない場合，ストリームを拡張する. 一方，ストリーム到達確認の結果，参加者のいない悶? セッションヘストリームを拡張している場合，図6(b)に 示す通りストリームを縮退させる. ストリームを拡張する際は，各RTPセッションへ追加 すべき出力フォーマットを，セッションプロパティをも' とにセッションエージェント(参加者)が決定し，適切な トランスコーディングノードをストリームエージェント が選択する.そしてストリームエージェントは，自身の 出力を入力とするトランスコーディングエージェントを 生成し，選択したトランスコーディングノードへトラン スコーディングエージェントが移動する. 図7は，ストリーム拡張時のストリームエージェント の処理フローを示している.まず初めに，資源利用状況 (b)ストリームの縮退 図6
:ストリームの拡張と縮退 owner (STAT1!:O陀 腿Dl 図4:
セッションへの参加 ストリーム追加に関するメッセージフローを図5に示す. 参加者がストリームを追加する場合は，追加するRTPセッシ ョンにおける最大流入量を超えぬよう，セッションオーナー がアドミッションテストを実行する.アドミッションテスト の結果ストリームが追加可能である場合，それ以降のフロー は図4と同様のものとなる.を収集するための要求メッセージを稼働中のトランスコーデ イングノードへマルチキャストする.これに対して，稼働中 のトランスコーディングノードにおける Syst側 Agentは現 在の資源利用状況を返信する.資源切j用状況には，各トラン スコーディングノードにおいて利用可能な入出力帯樹高の上 限値と利用状況[bps]および侃j和朋率聞が含まれる.資源 利用状況を受信したストリームエージェントは，各トランス コーディングノードの資源利用状況を要素とする稼動システ ムリストを生成し，資源利用状況を受信する毎に追加更新す る" ストリーム自主強開始 I剥周可能なノード敏=0 1 I I利用可飽なノード敏=0 lタイマーイベント発生図偉くHJ
，
、
i 1.:タイマーイベント発生図敏注叫 [利用可総なノード敏〉伺 トランスコーディングエージエントの移動 巾 例利用車のIIU.¥..で1
.
.
.
.
.
.
.
.
.
.
A
[
全てのノ-t:1こ対して移動矧 穆111を鼠みる. ~鉱混成功 図7:ストリームの拡張 一方，ストリーム拡張開始時にストリームエージェントは タイマーを起動し，一定間隔で発生するタイマーイベントを 受け取る.タイマーイベントを受け取ったストリームエージ ェントは，利用可能なトランスコーディングノードのリスト を稼動システムリストをもとに生除する.リストの要素は， 必要な送受信帯墳福と十分な倒j資源をもっノードの資源利 用状況である.そして，C
P
U
利用率の低いトランスコーディ ングノードから順番に移動を試みる. もし，タイマーイベント発生回数が一定の値制)未満で，か っ，利用可能なトランスコーディングノードが存在しない場 合，ストリームエージェントは資源利用状況を収集するため の要求メッセージを再度マルチキャストする.また，利用可 能なトランスコーディングノードが存在せず，タイマーイベ ント発生回数が一定の値を超えた場合，必要な資源が確保で きないと判断し，ストリームの拡張は失敗となる.次章て池 ベるプロトタイプシステムでは，タイマーイベントの発生間 隔を1秒とし，発生回数の上限は3固としている. トランスコーディングエージェントがストリーム拡張のた めに移動する際のフローは図8に示す通りである.まず，移 動先のトランスコーディングノードにおける Syst叩 Plane のエンティティに対し，ストリームエージェントはトランス コーディング処週のための入出力情報を送信する.次にトラ ンスコーディングノードでは， トランスコーディング処理に 必要となる例資源と送受信帯樹高に対してアドミッション テストを新子し，確保可能であれば資源の予約を行う.そし て， トランスコーディングエージェントがトランスコーディ ングノードハヰ鋤し，処躍を開始する. 図8:トランスコーディングエージェントの移動 一方，各町?セッションで利用可能なストリームフォ ーマット全てに対してストリームの拡張が失敗した場合， MidFieldシステムを利用するアプリケーションへ失敗 の原因を含むイベントが通知され，ストリーム拡張処理 は終了する.3
.
3
C
P
U
利用率の計測 ストリーム拡張時におけるトランスコーディングノー ドの選択には，稼働中のシステムにおける利用可能な入 出力帯域幅と倒j利用率を用いる.ストリームの入出力 情報から必要な帯域幅を見績もることは可能であるが， 必要となるC
P
U
資源はトランスコーディングノードの性 能によって異なる.そこで， MidFieldシステムにおける トランスコーディングノードは， トランスコーディング 処理に必要となるC問資源を予め測定しておき，テープ ルとして利用する. C問利用率は，ノードの負荷を測る 1つの値となる一 方，一定の負荷状態においてもその値にばらつきが見ら れるので，平滑化した値を用いる必要がある.そこで， MidFieldシステムでは，対象となるメディア処理のみを 実行させたノードでσU利用率の1分間の移動平均をと り，移動平均の標準偏差が1未満となった時刻の移動平 均値を必要なσU資源とする簡単な方法を導入した. 4. プロトタイプシステム MidFieldシステムのプロトタイプと簡単なビデオ会 議アプリケーションを， Windows XP上に Java，C， C++ 言語を用いて実装した.プロトタイプシステムの実装に 利用した陀は， Dell WORKSTATI側 阿S360，Intel (R) Pentium(R) 43.2∞
hz， 2.0∞
BRAMのマシンで，ネット ワークアダプタは Intel(R) PRO/IOOO町 Network Connectionを使用している. MidFieldシステムはトランスコーディング処理に必 要となる倒j資源を予め計測し，その結果を保持する. 表1はプロトタイプシステムにおける計測結果の一部を 示している.ここで，ピデオのフレームサイズはDV(720 X480 [pixel])を基準とし，則PEGとM
P
仰のフレーム サイズはDVの1!4(360X240[pixel]) としている.PQd のフォーマットは，量子化ピット数 16[bit]，サンプリ ング周波数32[kHz] ，チャンネパ敬を 2(ステレオ)とした.-86-表 1:トランスコーディング処還と CPU利用率 MPEG4/RTP + PCM/RTP 1.0‘￨λ自力: 釣O.5Mbp・ 入出力 1.o24M切・ 入力: 鈎28.8Mbp・ 出力: 約20.0Mbp・ 入力: 約28.8Mbpa 出力: 鈎1.5Mbp・ 表 1より，プロトタイプシステムの実装で用いた陀では， DVストリームを則P回+PCMストリームへトランスコーディン グするために約 38.1%の 倒j資源を必要とし， DVストリーム をMP邸4+PCMストリームにトランスコーディングするために は約 20.部の σU資源を必要とする.これより， CPU資源のみ を考慮するなら， DVストリームを町P邸+PCMストリームにト ランスコーディングする場合， 1台の陀で 2本分， MP脳 + 附 ストリームにトランスコーディングするのであれば， 1台の 陀でも4本分の処還を受け持つことが可能であると期待でき る. そこで， MidFieldセッションの動的構成機能を評価するた めに， DVストリームと MP回
4
+1明ストリームを用いた相互通 信実験を行った.実験環境を図 9(a)に示す. 1台のギガピッ トスイッチングハプに 6台の利用者端末(MFu.--MFU;>と 2台の トランスコーディングノード (MFTJ，MF'12)を接続した環境で， 図 9(b)に示すMidFieldセッションを構成した.また，この MidFieldセッションは 2つの悶?セッション(
r
s
.
，r
s
2)から構 成される.rS1で利用可能なフォーマットは DV，MP邸4，1'01 とし， rS2て利用可能なフォーマットは即倒，聞とした. 【8)鈎理.Iit MIdF凶 匂 蜘m: I MFTITnm凶l噌 N剖~e;困
u脚 S帥 n I MFu111MFu211MFU311MFU41E
司
IMFT21匠司匪司
(b) MIc!Flaldおaslon.成 図9
:評価実験環境 ここで， MFU1吋凡は悶?セッション rSIを利用して相苛. 通信を行い，MF1由と MFa は 町Pセッション rS2を利用して 相互通信を行う.必要に応じてトランスコーディングエージ エントがトランスコーディングノード (MFTJ，MF12)へ移動し， rSIとrS2を動的に接続することにより ，DVストリームと 即 捌+1明ストリームによる6者開通信を行う. 以下 (s1)'" (S8)は実験のシナリオである. (S1) MF'U¥ ... MFl14がrSIで相互通信を開始する. (S2) MF，凶がrS2へ参加する. (S3)府出がストリームを追加し送信を開姶する. (S4)MFaがrS2へ参加する. (S5)MF，慣がストリームを追加し送信を開企合する. (S6) MFaがrS2から退出する. (S7)肺慌がrS2から退出する. (S8)MF'U¥ ... MFu.t ~~ rS1から退出する. 実験結果として，MFU¥と MFTJおよびMF，国と即官におけ る 倒j利用率と入出力ピットレートを，図 10から図 13 に示す. まず，シナリオ(S1)の結果， 4本の DVマルチキャスト ストリームがrS1に流れる.図 10の(S1)...(S2)にかけて， MFU¥ はDVストリームを 1本送信し，その送信したストリ ームを含めて4本分のDVストリームの受信を開始したこ とがわかる. 次にシナリオ(S2)の結果，図Uより， ~lFn が rSI
から 4本分の DVストリームを受信し，脚部4+PCMストリーム へトランスコーディングし，rS2への送信を開始したこと がわかる.これは，MF凶が1 rS2へ参加したことにより ，MFU¥ --MF，闘がrSzへストリームを拡張する際，トランスコーデ イングノードとして MFTJを選択したことを意味する. MFTJがトランスコーディング処理を始めたことにより， 町Pセ ッ シ ョ ン 同 へ MPEG判明ストリームが4本流れ 始める.これは，図 12(S2)で師団が rSzへ参加した後， 入力ピットレートが約6Mbpsで推移していることから確 認できる.本プロトタイプで用いている MP郎4+PCMスト リームのピットレートは最大約1.5Mbps程度なので， W削+悶ストリームを 4本受信すると，約 6蜘psとな る. 次にシナリオ(S3)の結果， MF凶が1 rS1へストリームの 拡張を行った.この場合トランスコーディング処理は必 要ではなく，中継のみが行われる.図 13の(S3)より，そ の中継処理を Wη が担当していることがわかる.ここで， Wηは 旧 制+PCMストリーム 1本をr
Szからr
s
.
へ中継 するが，図 13の通り MF12は 5本分の W郎判明ストリ ームを受信し，1本分の即郎4+PQdストリームを送信し てしも.これは， MFηが中継先日里を行うために rS2で利 用されている 1Pマルチキャストセッションに参加した ため， rS2へ流入する全てのトラフィックを受けている ことを意味する.一方，MFηの中継した MPEG4+附スト リームを ~IFU\が受信していること l主図 10 の (S3) から確 認できる.図 10と図 11に対し，図 12と図 13の入出力 ピットレートのスケールが異なることに注意し，図 10 の(S3)以降の入力ヒ'ットレートを見てみると，若干(約 1.5Mbps)噌加している.また，受信した MP印判明スト リームを再生表示するためにC問利用率も増加している. シナリオ(臼)では MFl6がrSzへ参加する.しかしな がら，既に rSzには MFu5が参加しており ，rSzに対し てストリームの拡張が行われているので，各図とも (S4) の時点では変化が見られない.続くシナリオ(S5)の結果， MFl6はMPEG4(360X 240)+PCMストリームの送信を開始し， rSIへストリームを拡張する.中継ノードには MFηが選 択され，その結果は各図の (S5)より確認できる. 次に MFI魁は，シナリオ(S6)で退出する.これにより， MFl6が送信していた MP脳 +P側ストリームが削除され る.そして，シナリオ (S7)で MFII5が退出する.ここで，r~ の参加者数は 0 となり. MFU1から MF，酬はそれぞれ r~ へ 拡張していたストリームを縮退させる.ストリームが縮退し た結果.MFTlにおけるトランスコーディング処理は終了する. これは図 11の(S7)より確認できる. 最後に，シナリオ(S8)でMFU('"'-'MFlJ.tがrS1から退出し，相互 通信セッションも終了する. 今回の翻面実験に用いたMidFieldセッションの構成では， 貯Pセッションが 2つであり，利用可能なフォーマットも限 定されたものである.しかしながら， トランスコーディング エージェントを必要に応じて動的に配置することにより，利 用者の通信環境や伽S要求に応じて適切なフォーマットを用 いた相互通信サービスの某盤となる機能が実現されたことを 確認した.
