論

ヒト・モノ・データをつなげるインターネットアーキテクチャ論文特集

文

CA-EXI：運用コンテキストと EXI 符号化を用いた
IEEE1888 メッセージ圧縮手法
落合秀也† a)

土井

裕介††

江崎

浩†

CA-EXI: Context-Aware Eﬃcient XML Interchange for IEEE1888
Message Compression
Hideya OCHIAI†a) , Yusuke DOI†† , and Hiroshi ESAKI†

あらまし 機械間通信での 3G 回線利用は増えてきているが，XML 通信をベースとする機械間システムでは
これまで回線上の通信量が課題となることがあった．本研究では，その課題を解決する CA-EXI と呼ぶ XML
メッセージの圧縮方式を提案し，IEEE1888 通信システムにおける，その圧縮効率の評価実験を行った．その結果，CA-EXI は，幅広いフットプリントの領域 (小さな IEEE1888XML メッセージから大きな IEEE1888XML
メッセージまで) において，従来の EXI 方式よりも強力かつ GZIP 方式に劣らないバランスの良いメッセージ
圧縮率を達成した．特にメッセージサイズの小さい領域では，GZIP 方式よりも強力な圧縮率を達成した．
キーワード

機械間通信，XML，EXI，圧縮，IEEE1888

1. ま え が きの負荷 (=通信の量) をどれだけ小さくできるかが，重機械間通信 (M2M: Machine-to-Machine)，すなわ

効率性なども考慮しておく必要があり，単に通信量を要となってくる．一方で，M2M システム全体の開発

ち，センサ・アクチュエータ機器とクラウドサーバ間減らすことだけを考えれば良いわけでもない．

の通信に，第 3 世代移動体通信システム (通称 3G 回

そこで本研究では，開発効率性などの観点で設計

線) のようなキャリアネットワークを用いるケースがされた HTTP と XML による M2M システムを想増加してきている．センサ・アクチュエータを遠隔地定した上で，狭帯域回線を通るメッセージを圧縮すに設置する際に，同時に 3G 回線を引くことによって，る Context-Aware Eﬃcient XML Interchange (CA-

既設ネットワークへの接続における諸問題（ファイヤEXI) 方式を提案する．具体的には，HTTP と XML

ウォール解放，MAC アドレス届出，IP アドレス設定，を用いる IEEE1888 通信規格 [1] を取り上げ，クライ

物理的配線など）を一気に解決し，導入を容易にでき

アントサーバ間の通信の中で，狭帯域回線部分の両端るようになる．しかし，3G 回線設備はネットワーク

で圧縮 (Encode) と展開 (Decode) を行わせる運用形

キャリアによって維持されなければならず，回線費用態に焦点を当てる．そして，その圧縮方式の一つとしが発生するという難点がある．回線の維持費用は通信て，CA-EXI を提案する．

量に左右されるところが多く，その実態は回線料金の

単に通信量を削減するのであれば，UDP データグ
ラムに必要な情報やデータをバイナリエンコードし契約形態にも反映される．
導入に関してこのように魅力的な 3G 回線であるが，て送信すれば良い．きっと，フットプリントを小さく

M2M の現実的な普及を考えた場合には，回線設備へできる効率的なメッセージ・フォーマットがあるだろう．しかし，これだけではシステム全体のソフトウェ†††

ア開発効率，メンテナンス効率などに課題を残すこ

東京大学，東京都
The University of Tokyo, Tokyo, 113–8656 Japanとになる．事実，M2M システムでの通信には HTTP（株）東芝，川崎市と XML が使われるケースが多い (oBIX [2], BACnet

Toshiba Corporation, Kawasaki-shi, 212–8531 Japana) E-mail: ochiai@vdec.u-tokyo.ac.jp1104

電子情報通信学会論文誌

Web Services [3] など) が，これはシステム開発や維c 一般社団法人電子情報通信学会 2013
B Vol. J96–B No. 10 pp. 1104–1113 

論文／CA-EXI：運用コンテキストと EXI 符号化を用いた IEEE1888 メッセージ圧縮手法

持の効率性・汎用性を求めた結果なのである．

りつつある．

本研究で提案する CA-EXI 方式では，XML の圧

なお，アプリケーション・オブジェクトのシリアル

縮符号化は，高効率 XML 交換方式 (EXI: Eﬃcient

化（符号化）の観点から考えた場合，XML は単に一XML Interchange) [4] をベースにしている．本研究

つのシリアル化方式であり，EXI も別のシリアル化方

では，EXI の本来の仕組みに加え，M2M システムな式であると言える．Doi の研究 [14] ではこの特性を利らではの特性である下記 2 点に着目し，更なる圧縮用して，組込みデバイスが直接 EXI でやり取りする

率向上 (評価実験の結果は，EXI 方式に比べ，平均で方式を提案している．

1/5.6 に，最大で 1/18.5 に圧縮した) を狙う．
• エンドノード近くのセンサ・アクチュエータやてきたが，ほとんどの研究は，単一の XML 文書を圧

データタイプの構成はほとんど変化しない（=同じ ID

縮することのみを考えていて，何度も登場する似たよ

表現や値表現が長期間に渡る複数メッセージに何度もうな XML 文書に対する圧縮は十分に検討されてはい登場する）

ない．しかし，実際には，先に述べた M2M の特性 (エ•これまで，このように XML の圧縮手法が研究されエンドノード近くのセンサ・アクチュエータや

ンドノード近くのセンサ・アクチュエータやデータタ

データタイプの構成は有限である (=登場する ID 表

イプの構成はほとんど変化しない，また，その取りう

現や値表現の空間が有限である)

る構成は有限である) があるのであり，これを想定す本研究では，このような特性に着目し，運用場面 (運用現場) という “コンテキスト” を作り，そのコンテキ
ストを利用してより高度な圧縮を実現する．
本論文の構成は，次のとおりである．2. にて関連研れば，更に圧縮が可能なはずである．我々の研究は，
この部分に着目し，検証を行ったものである．

3. システム構成

究との関係を述べる．3. にて，本研究が想定するシス本研究では，図 1 に示すように，IEEE1888 のクラテム構成を明確にし，4. 及び 5. にて本研究で提案すイアントノードとサーバノードの間に狭帯域回線がある CA-EXI 手法を説明する．6. で行った実験とそのる場合を想定し，その両端でメッセージを圧縮・展開

評価結果を述べる．7. にて一般的な M2M システムへするものとする．IEEE1888 では，遠隔手続き呼出しの応用について考察をし，8. にて本論文を締める．

(RPC: Remote Procedure Call) 方式で，クライアン

2. 関 連 研 究

トからリクエストメッセージをサーバに対して送り付

インターネット上のシステム開発で，Web サービス

実際の運用では，例えば，クライアントノード側に，(HTTP 及び XML) が主流になったことで，開発効率

電力メータや環境センサがあり，その計測値をクラウ

性やインターオペラビリティ向上の理由から，M2M

ド側のサーバに対して送り付け，その成否結果がレスシステムの分野でも Web 技術を利用することが重要ポンスとして返ってくるという形になる (あくまで一け，サーバは処理結果をレスポンスとして回答する．

になっている．しかし，Web サービスは，通信量や処理の重さに課題があるとされており，それらを軽減するために，数多くの研究が行われている ( [5]〜[8])．

XML 文 書 の 圧 縮 に 関 し て は ，EXI が 登 場 す る
以前は，Xmill [9]，xmlppm [10], [11]，Fast Infoset，

WBXML などが提案され，Christian Werner らの研究による分析 [12] では Xmill や WBXML が良いとされた．ただし，この検証には EXI は盛り込まれておらず，W3C が行った評価 [13] では，EXI が最も良いという結果となっている（注 1）．その後，W3C にて EXIの仕様化が進み，現在は EXI が圧縮方式の主流とな（注 1）：Eﬃcient XML emerges as the best performer for nearly
all test documents in all application classes とある．

図 1 システム構成と通信の全体像
Fig. 1 Overview of a target system andcommunication ﬂow.

1105

電子情報通信学会論文誌 2013/10 Vol. J96–B No. 10例である)．本研究ではクライアントサーバ間にプロ配送され，逆の演算処理を経て，元の IEEE1888 のキシノードを用意し，このプロキシノード間の通信をXML メッセージが復元される．

圧縮することを考える．つまり，TCP のレベルでは，

IEEE1888 の XML メッセージから中間 XML コー

クライアントノードは，まず，プロキシサーバノード

ドを生成する際や，中間 XML コードから元の XMLに対して，IEEE1888 のリクエストメッセージを送る．

メッセージに復元する際に，“運用コンテキスト” と呼すると，本研究で提案する CA-EXI 手法によりメッ

ぶ情報を利用する．この運用コンテキストは，その狭セージが圧縮され，対向にあるプロキシクライアント

帯域回線の両端の運用形態を反映した情報であり，自ノードに送信される．プロキシクライアントノードで動抽出させることが可能である．その抽出方法は次章メッセージを復元し，IEEE1888 サーバノードに送信

にて解説する．

する．レスポンスメッセージは，プロキシクライアン

中間 XML コードのスキーマは，IEEE1888 で使わ

トで結果が圧縮され，狭帯域回線を伝わった後，プロれる XML のスキーマを表 1 のように対応付けしたもキシサーバで展開され，IEEE1888 クライアントノーのである．IEEE1888 ではグローバル性や汎用性を高ドに届けられる．

めるために anyURI や string という形で抽象定義さ

ここで，圧縮手法としては，古典的には GZIP [15]

れていた部分を，運用コンテキストの配下で使われるがあり，近年は EXI が使われようとしている．本研究中間 XML では，よりプリミティブな型に対応付けるで提案する CA-EXI 手法は，EXI 方式をベースとしようにしている．

つつも，2 段階圧縮を行うことによって，EXI 方式よりも高い圧縮率を実現する．

4. Context-Aware Eﬃcient XML
Interchange (CA-EXI)
本提案手法では，図 2 に示すように，二段階のフェー

IEEE1888 の XML を，中間 XML コードに対応付けする際に利用する運用コンテキストは，図 3 に示す構造となっている．
図 3 の運用コンテキストの場合，図 4 の IEEE1888の XML メッセージは，図 5 の中間 XML コードに変換される．

ズによって，バイナリコードに圧縮したメッセージを

図 4 のオリジナル XML は，URI 型や文字列型を生成する．IEEE1888 の XML メッセージを，途中，多く含んでいるため，EXI 符号化による圧縮効率はあ

圧縮効率のよい中間 XML コードに変換し，その中まり期待できないが，図 5 の中間 XML コードでは，間 XML コードを EXI によりバイナリ符号化 (圧縮)する．バイナリ化されたメッセージが，デコーダまで

表 1 中間 XML のスキーマ構造
Table 1 Schema for intermediate XML.
IEEE1888 XML Schema
Element Attr
Type
key
id
anyURI
keyeq
stringkey
neq
stringkey
lt
stringkey
gt
stringkey
lteq
stringkey
gteq
stringpointSet id
anyURI
point
id
anyURI
value
content string

図 2 CA-EXI 圧縮・展開のフロー
Fig. 2 CA-EXI compression and infration.

1106

Intermediate XML Schema
Element Attr
Type
key
id
uint
key
eq
datetime
key
neq
datetime
keylt
datetime
keygt
datetime
key
lteq
datetime
key
gteq
datetimepointSet id
uint
point
id
uint
ivaluecontent integer
rvaluecontent double
evaluecontent uint
svaluecontent string

図 3 運用コンテキストの例
Fig. 3 Operational context example.

論文／CA-EXI：運用コンテキストと EXI 符号化を用いた IEEE1888 メッセージ圧縮手法

現在の運用コンテキストを C と置き，C がもっているコンテキストの 1 レコードを c とする (c ∈ Cと表現する)．そして，c.pointid，c.shortid，c.type，

c.map をそれぞれ IEEE1888 のポイント ID，中間XML コードでの対応番号，値の型 (NULL, INTEGER, REAL, ENUM, STRING のいずれか)，値表
現の数値対応集合 (ENUM 対応表) とする．値表現の数値対応集合 c.map の一要素を e(∈ c.map) とする場合，e.rawvalue で IEEE1888 XML での値表現，

e.shortvalue で中間コードでの値表現をするものとする．
図 4 IEEE1888 XML メッセージ
Fig. 4 IEEE1888 XML message.

いま，到着する IEEE1888XML メッセージの集合
を M とし，その M の一要素を m とする (m ∈ M と表現する)．このとき，m.points をメッセージ m に記載されている IEEE1888 でのポイントまたはポイント
セットの集合とする (point 要素または pointSet 要素に対応する)．各ポイント (セット) を p(∈ m.points)と表現したとき，p.id でポイント ID を，p.values でp がもつ値 (value 要素) の集合をもつものとする．実際の値は，v ∈ p.values と置いた場合に，v.content
として取り出せるものとする．
上記のように定義するとき，IEEE1888XML メッ
セージの集合 M から，運用コンテキスト C を次の方法で抽出させる．なお，C の初期値は Φ(空集合) と図 5 中間 XML コード
Fig. 5 Intermediate XML code.

する．

– 運用コンテキスト抽出アルゴリズム (ここから)–
Forall m ∈ M

これらが数値に対応付けされていたり，型明示されてForall p ∈ m.points

いたりするため，圧縮効果を期待できる．中間 XML

If ¬ exists c ∈ C(c.pointid = p.id)

コードにも文字列型が用意されているが，6. の評価実

c :=new()

験で明らかなように実際のセンサネットワークでは文c.pointid := p.id

字列型でしか扱えない値表現は多くはない．

c.shortid :=count(C)5. 運用コンテキストの抽出と共有
5. 1 抽出アルゴリズム
CA-EXI 圧縮に必要な運用コンテキストは，実際にc.type :=NULL
C := C ∪ {c}ElseIfc :=arg{c.pointid = p.id}

やり取りされる複数の IEEE1888 XML メッセージかEndIf

ら動的に抽出することができる．基本的には，CA-EXI

Forall v ∈ p.valuesのエンコーダに次々と到着する XML メッセージに，If c.type =NULL(1) 新規の IEEE1888 ポイント ID があれば，運用コ

c.type :=type(v.content)

ンテキストに新規の ID レコードを追加し，(2) 値のc.map := Φ

中身は常にチェックし，適切なデータ型を選択すればElseIf c.type =INTEGER

良い．その抽出アルゴリズムを，本研究では以下のよ

If type(v.content)=REAL

うに定義する．

c.type :=REAL
1107

電子情報通信学会論文誌 2013/10 Vol. J96–B No. 10

c.map := Φには毎回文字列を送ってしまうことになる．一方で，

ElseIf type(v.content)=ENUM

MAX ENUM の値を限りなく大きくすることもでき

c.type :=ENUMるが，本来 STRING 型と判定される ID レコードがc.map := Φ

常に ENUM 型となってしまい兼ねない．その場合，

EndIf

新しい文字列が登場するたびに，c.map 要素を追加

ElseIf c.type =REALすることになり，単に運用コンテキストのフットプリ

If type(v.content)=ENUM

ント (c.map 要素数も考慮に入れたもの) が，大きく

c.type :=ENUM

なってしまう．しかし，メモリ容量に余裕があれば，c.map := Φ

多少 MAX ENUM の設定値が大きくても，弊害はな

EndIf

く，単に，多くの文字列パターンが c.map 表により，

ElseIf c.type =ENUM

数値 e.shortvalue で表現されることになる．

If count(c.map)<MAX ENUM

5. 2 共有アルゴリズム

If ¬ exists e∈c.map (e.rawvalue = v.content)

運用コンテキストは，(1) レコードの追加，(2) 型

e :=new()の変更，(3) ENUM 型の場合は値要素の追加，のタイ

e.rawvalue := v.content

ミングで変化が発生する．これらのタイミングで，エe.shortvalue :=count(c.map)

ンコーダ側からデコーダ側に，変化の種別 (レコード

c.map := c.map ∪ {e}追加，型変更，ENUM 値要素の追加) と，それに付随

EndIf

するパラメータを渡すことで運用コンテキストの共有

ElseIfを行うことができる．

c.type :=STRING
c.map := Φ•“レ コ ー ド 追 加” の 場 合 は ，c.shortid，

c.pointid，c.type (c.type = EN U M の 場 合 は

EndIfe.shortvalue と e.rawvalue のペアも) をパラメータ

EndIfとして渡す．

EndForall•“型変更” の場合は，c.shortid，c.type (c.type

EndForall= EN U M の場合は e.shortvalue と e.rawvalue のEndForall

ペアも) をパラメータとして渡す．

– 運用コンテキスト抽出アルゴリズム (ここまで)–
ここで，各定数・オペレータ・関数は，次の意味で•“ENUM 値要素追加” の場合は，e.shortvalue，e.rawvalue のペアを，パラメータとして渡す．

ある．

上記の共有アルゴリズムは，差分情報を伝達するだ•

MAX ENUM ENUM 型の最大要素数設定値

けなので，実装時には，エンコーダ・デコーダ間での•= 両辺の値が等しいかどうかの判定

運用コンテキストの不一致検出，運用コンテキストの•< 左辺の値が右辺の値より小かどうかの判定

全転送などの仕組みも併せて必要となるかもしれない．

•:= 右辺を左辺に代入する

しかし，本研究では，上記のものを共有アルゴリズム•

new 新しい要素の生成として考えることにする．

•

count 要素数を求める•

type この値のデータ型を求める

6. 評

価

こ の ア ル ゴ リ ズ ム に よって ，通 信 路 上 を 流 れ る

本研究では，実際の通信路を流れた IEEE1888 通信

IEEE1888XML メッセージから，運用コンテキスト

メッセージを用い，(1) 運用コンテキストの抽出に関を自律的に抽出することが可能になる．
定数である MAX ENUM は，適用する現場の設備の組み合わせから ENUM 要素数 (=c.map 要素数) をする評価，(2) 圧縮率に関する評価，(3) 通信の総量に関する評価を行った．以下が，その実験方法と結果である．

推測し，それを超える値を設定する．それよりも小6. 1 データセットと実験方法

さい値を設定すると，本来 ENUM 型として判定さ東大グリーン ICT プロジェクト及び Live E!プロれる値が，STRING 型と判定されてしまい，通信時

ジェクトで運用している 6 台の IEEE1888 サーバが1108

論文／CA-EXI：運用コンテキストと EXI 符号化を用いた IEEE1888 メッセージ圧縮手法

やり取りする IEEE1888 メッセージを，それぞれのの圧縮効率，フットプリントが中の領域 (2000byte〜

IEEE1888 サーバの根元でキャプチャし，これを実験

10000byte) での圧縮効率，フットプリントが大の領のデータセットとした．データの収集期間，生データ

域 (10000byte 以上) での圧縮効率をグラフにプロッのフットプリント，ポイント ID 数を表 2 に示す．

トした．1 メッセージあたりのフットプリントの分布

それぞれのデータセットには，IEEE1888 サーバへ

(確率密度関数，累積密度関数) も分析し，どの領域をのリクエストと IEEE1888 サーバからのレスポンスの重点的に圧縮すると効果的かについても評価した．こ全てが含まれている．

こで，確率密度関数 (PDF: Probability Distribution

抽出に関する評価では，この通信メッセージを順にFunction) の計算は，各サーバでやり取りされた通処理して運用コンテキストの抽出をサーバごとに行

信メッセージ量の密度関数を，100byte 単位で区切っ

わせ，その際に発生する運用コンテキストの共有にて求め，サーバごとの平均値を取った．累積密度関

必要な通信量の推移，及び，コンテキスト情報の大き数 (CDF: Cumulative Distribution Function) の計

さの推移を評価した．コンテキスト情報の大きさは，算は，求められた PDF を積分することで求めた．本

ここでは ID 数と ENUM 対応表の数の和とした．ま

評価においては，5.1 のアルゴリズムに基づき，到着

た，抽出結果の ID 数，データタイプの内訳についてする XML メッセージごとに動的に運用コンテキストも評価した．なお，抽出アルゴリズムでの定数であるを抽出しながら，その XML メッセージを圧縮し，そMAX ENUM は，100 に設定した（注 2）．

の圧縮量を評価している．運用コンテキストの共有に

通信量を調べる際には，5.2 におけるアルゴリズムに付随する各情報量を，必要な通信量は，この分析では，切り出されている．
通信の総合量に関する評価では，全てのデータセッ•

変化の種別: 1 byte

トに対し，総合的に考えてどの程度圧縮できたかを評•

c.shortid: 2 byte

価した．すなわち，まず，CA-EXI について，運用コ•

c.pointid: c.pointid 長+2 byte

ンテキストの共有のための通信量と圧縮データ通信•

c.type: 1 byte

量の和を考え，それらの関係を分析した．その上で，•e.shortvalue: 1 byte

CA-EXI，EXI，GZIP での全通信量を比較評価した．

•

e.rawvalue: e.rawvalue 長+2 byte

6. 2 運用コンテキストの抽出の推移と置いて，発生した情報量の総和を計算した．この実

図 6 及び図 7 に，運用コンテキストの共有に使っ験では，実装に依存する各種オーバヘッド (IP ヘッダ

た通信量 (総和) の推移，及び，コンテキスト情報の大の大きさや，TCP 通信のやり取り) は除外した．

きさの推移の結果を示す．横軸は，通信開始時から到圧縮率に関する評価では，IEEE1888 メッセージを，着した IEEE1888 メッセージの数を対数スケールで表そのまま (1) EXI 方式で圧縮する場合，(2) GZIP 方

示したものである．コンテキスト情報の大きさは，エ式で圧縮する場合，(3) 提案方式の CA-EXI 方式で圧ンコーダ・デコーダで保有すべきメモリ容量の大きさ

縮する場合の 3 通りの方法を比較した．比較においに関係する．

ては，フットプリントが小の領域 (2000byte 未満) で

表 2 評価実験で使用したデータセット
Table 2 Data set for evaluation.
Servercloud
cloud2dev
live-esandboxstorage

Duration
81.5hour
81.5hour
81.5hour
81.5hour
16.5hour
81.5hourTraﬃc
446 MByte
516 MByte
884 MByte
570 MByte
17.6 GByte
22.6 GByte

Number of IDs
122
110
2353
1996
887
3634

（注 2）
：実験で用いたデータには，エアコンの動作モード，スマートタッ
プの設定モード，特殊設備の状態値など，各種実験で用いている様々なデータ表現が含まれていた．その内容を考えつつ，多少大きい分には弊害がないことを踏まえ，安全を見て 100 に設定した．

図 6 運用コンテキストの共有に必要な通信量 (情報量) の推移
Fig. 6 Transition of the total messages for
operational context sharing.

1109

電子情報通信学会論文誌 2013/10 Vol. J96–B No. 10

図8
図 7 コンテキスト情報の大きさ (ID レコード数と c.map
要素数の総和) の推移
Fig. 7 Transition of context size.

IEEE1888 メッセージ (1 個) あたりのフットプリン
トの分布 (確率密度関数 PDF，累積密度関数 CDF)
Fig. 8 Distribution of data size for one IEEE1888
message.

表 3 データタイプの内訳
Table 3 Data type distribution.
Server NULL INTEGER REAL ENUM STRING
cloud
2
41
73
2
4
cloud2
2
12
64
16
16
dev
451
640
1086
176
0
live-e
1133
71
792
0
0
sandbox
439
186
135
117
0
storage
401
872
1498
929
1

この図から，主に通信開始時に運用コンテキストの共有が行われ，その後は，時折，変化に伴う共有のための通信が発生していることがわかる．コンテキスト

図 9 フットプリントが小 (0〜2000byte) の領域での圧
縮量Fig. 9 Compression rate of IEEE1888 messages(0 - 2000 byte).

情報の大きさも，通信開始時には急速に変化するが，その後は，ほぼ変化せずに推移していることがわかるの表からわかるように，NULL を除けば，REAL 型，(横軸は対数表示であり，通信開始初期が特に引き延ばINTEGER 型，ENUM 型が大半を占めている．このされていることに注意)．なお，コンテキスト情報の大ように，実際の運用では，STRING 型は，ほとんど見きさは，時折減少しているが，これは c.type=ENUM

受けられないことが分かった．

から c.type=STRING に移行したタイミング (その6. 4 圧縮データのフットプリント

c.map 対応表がクリアされたため) で発生している．

図 8 に，IEEE1888 の XML メッセージ 1 個が，ど

この結果より，通信開始時には頻繁に運用コンテキのくらいのフットプリントをもっているかを表す確率ストの抽出・共有処理を行うことになるが，その後は密度関数 PDF 及び累積密度関数 CDF を示す．この変化が発生しにくい傾向にあることがわかる．つまり，結果から，この実験で用いたデータセットにおいては，

一度コンテキストを抽出・共有してしまえば，そのコ•

69.0%のメッセージが小領域

ンテキストを利用して CA-EXI による IEEE1888 の•9.1%のメッセージが中領域

XML メッセージ圧縮に専念することが可能になる，•

21.9%のメッセージが大領域と言える．

6. 3 運用コンテキストの抽出結果に属することがわかる．
図 9，10，11 にそれぞれ IEEE1888XML メッセー

表 3 に，抽出によって分類された各データタイプのジのフットプリントが小さい場合，中くらいの場合，内訳を示す．数値は，その型と判定された IEEE1888

大きい場合の EXI，CA-EXI，GZIP 方式での圧縮さポイントの個数を表す．NULL になっているものは，

れたメッセージのフットプリントを示す．

値が存在しなかった (あるいはポイントセットである)

図 9 の結果より，フットプリントが小の領域では，ため，値の型判定ができなかったことを意味する．こ提案手法 (CA-EXI) が EXI と GZIP 方式に比べて優1110

論文／CA-EXI：運用コンテキストと EXI 符号化を用いた IEEE1888 メッセージ圧縮手法
表4

CA-EXI での圧縮データ総量と運用コンテキスト通信総量の比較
Table 4 Size comparison of compressed data andmessages for operational context sharing in
CA-EXI.

図 10

フットプリントが中 (2000〜10000byte) の領域での圧縮量
Fig. 10 Compression rate of IEEE1888 messages(2000 - 10000 byte).

図 11

フットプリントが大 (10000byte〜) の領域での圧
縮量Fig. 11 Compression rate of IEEE1888 messages(10000byte - ).

Servercloud
cloud2dev
live-esandboxstorageFig. 12Total
62.3MByte
70.7MByte
61.5MByte
56.6MByte
823MByte
1.03GByte

Data
62.3MByte
70.7MByte
61.4MByte
56.6MByte
823MByte
1.03GByte

Context
13.1KByte
26.7KByte
141KByte
51.8KByte
111KByte
278KByte

Ratio
0.000210.00038
0.00230.00091
0.000130.00027

図 12 全データセットでの通信総量の比較
Compressed data footprint for each data set.

成した．と評価することができる．

れていることがわかる．CA-EXI 方式は，平均すると，

6. 5 通信総量の評価

EXI 方式と比べて 1/3.6 に圧縮し，GZIP 方式と比べまず，CA-EXI での圧縮データの通信量と，運用コて 1/2.8 に圧縮できていた．

ンテキスト情報の通信量を総合した際の，これらの総図 10 の結果より，フットプリントが中の領域では量及び比率を表 4 に示す．この結果から，運用コンテ

GZIP の方が，圧縮効率が良い場合があることがわか

キストの通信総量は，圧縮されたデータ量の総量と比る．しかし，EXI 単体の圧縮に比べれば，提案手法

較してほぼ無視できるほど小さいと言うことができる．

(CA-EXI) の方が圧縮効率は良い．

また，ID 数及び ENUM 要素数が多いケースほど運用

図 11 の結果より，フットプリントが大の領域では，

コンテキストの通信総量は大きくなるが，対象とする

EXI に比べて，提案手法 (CA-EXI) の方がはるかにデータの量が多ければ多いほど，全体に占める割合は圧縮できていることがわかる．その圧縮量は GZIP と小さくなる傾向にある．

さほど変わらない．

図 12 は全ての通信がそれぞれの手法でどの程度ま全体的には，CA-EXI 方式は，EXI 方式と比べて平で圧縮できたかを示している．この結果から，CA-EXI

均 1/5.6，最大で 1/18.5 に圧縮していた．また，GZIP

は (運用コンテキストの共有のための通信量も含めて)方式と比べて，平均で 1/1.16 に圧縮していた．

全てのケースにおいて，EXI や GZIP よりも優れる結以上の結果を総合すると，CA-EXI は，•

幅 広 い フット プ リ ン ト の 領 域 (小 さ な

IEEE1888XML メッセージから大きな IEEE1888XML
メッセージまで) において，十分な圧縮を実現した．

•

果となったことが読み取れる．

7. 考

察

本研究では，M2M システムでの通信メッセージ量

特に出現頻度の高い「フットプリントが小の領の削減を実現する際に，IEEE1888 通信にフォーカス域」では，EXI や GZIP 方式よりも強力な圧縮率を達を当てて，その圧縮手法として CA-EXI を提案し，そ1111

電子情報通信学会論文誌 2013/10 Vol. J96–B No. 10の効果の有効性を示した．この CA-EXI は，XML ス

用としては可能だろう．

キーマにおいて，anyURI 形式や string 形式となって

8. む す びいる部分 (すなわち EXI 符号化であまり小さくならない部分) を “運用コンテキスト” の考え方で，プリ

我々は，XML をベースとする M2M システムが狭帯

ミティブな int 形式，double 形式などに対応付ける

域回線 (e.g., 3G 回線) を利用する際に，その通信フッことが基本原理となっている．つまり，この CA-EXI

トプリントをどのように圧縮したらよいかを研究し，方式自体は，IEEE1888 以外の XML 形式 (oBIX [2]，具体的手法として CA-EXI 方式を提案した．CA-EXI

BACnet Web Service [3]，ZigBee SEP 2.0) などに

は，運用現場の構成を反映したコンテキストを利用しも応用可能であると考えられる．

て，効率的な通信メッセージの圧縮を行う．評価実験

今回の実験では，EXI よりも GZIP の方が良い圧縮で分かったように，コンテキストの抽出処理は頻繁に率を示すことがあったが，これは今回用いた IEEE1888

起こるものではなく，コンテキスト抽出及びコンテキの XML メッセージの特徴を反映した結果と言える．

スト情報のエンコーダ・デコーダ間での共有の負担はEXI では，文字列型は完全に一致する場合のみ圧縮し，

大きくはない．本研究のデータセットを用いた場合，同一 XML ドキュメントに同じ文字列が何度も登場す

高効率 XML 交換方式である EXI 手法での圧縮量にるときに効果的である．一方，IEEE1888 には一つの比べて，更に平均 1/5.6，最大 1/18.5 に圧縮した．まドキュメントに複数の ID が登場するが，個々の ID はた，70%近い通信メッセージが取りうるフットプリン

末尾がそれぞれ異なるため，EXI では圧縮できない．

ト 2000 バイト未満のメッセージに関しては，平均すしたがって，IEEE1888 の XML メッセージをそのまると，GZIP 方式と比べて 1/2.8 に，EXI 方式と比べ

ま EXI 化しても圧縮率は高くない．一方の GZIP 方て 1/3.6 に圧縮できていた．
文

式では，文字列としては相互に似ている ID が何度も登場するため，IEEE1888 のドキュメントを強力に圧落合秀也，IEEE1888 プロトコル教科書，インプレスジャ
パン，2012.

[2]“Open building information exchange.”[3]“Bacnet - A data communication protocol for build-

縮できる．この IEEE1888 の XML ドキュメントの性質が，EXI と GZIP の圧縮率の差を生み出したと考えられる．

http://www.obix.org/
ing automation and control networks.”

1. で述べたように，IEEE1888 の XML ドキュメン
トは，主に，センサ・アクチュエータの情報をやり取りするため，通常の運用では，登場する ID や値の表
現が限られてくる．一つのドキュメントでは再登場しhttp://www.bacnet.org/[4]“Eﬃcient XML interchange (EXI) format 1.0.”[5]

N.B. Priyantha, A. Kansal, M. Goraczko, and F.

http://www.w3.org/TR/exi/
Zhao, “Tiny web services: Design and implementa-

ない ID が，一つの運用コンテキストでは再登場する．

tion of interoperable and evolvable sensor networks,”

そのため，一度，運用コンテキストを抽出してしまえ
ば，それ以降，その変化はほとんど起きない (=無視

ACM SenSys, 2008.
[6]

できるレベルになってくる) と考えてよい．今回の実PERCOM, 2010.
[7]

tomata,” IEEE ICWS, 2006.
[8]

ded devices,” ACM SAC, 2004.
[9]

H. Liefke and D. Suciu, “XMill: An eﬃcient compres-[10]

J. Cheney, “Compressing XML with multiplexed hi-[11]

J. Kangasharju, S. Tarkoma, and T. Lindholm,

及びデコーダを，エンドデバイスやサーバ側にもたせることも当然，応用としては可能である．またコンテ
キストの抽出処理は，動的に行われるものを対象としていたが，静的にコンテキスト情報をサーバ側にもた

R. van Engelen, “Code generation techniques for developing light-weight XML web services for embed-

提とし，狭帯域回線を通るときだけメッセージを圧縮するというアプローチを取った．しかし，エンコーダ

C. Werner, C.B.Y. Brandt, and S. Fischer, “Compressing soap messages by using pushdown au-

な お ，本 研 究 で は ，End-to-End の 通 信 は ，IEEE1888 の XML メッセージを交換することを前

D. Schall, M. Aiello, and S. Dustdar, “Web services
on embedded systems - A performance study,” IEEE験は，このような特徴を裏付けつつ，そのような場合に，CA-EXI が強力に機能することを明らかにした．

献[1]

sor for XML data,” ACM SIGMOD, 2000.
erarchical PPM models,” IEEE DCC, 2001.
“Xebu: A binary format with schema-based opti-

せておき，エンドデバイスは中間 XML の EXI をそ

mizations for XML data,” 6th International Confer-のまま理解させるようにシステムを設計することも応

ence on Web Information Systems Engineering, vol-1112

論文／CA-EXI：運用コンテキストと EXI 符号化を用いた IEEE1888 メッセージ圧縮手法
ume 3806 of Lecture Notes in Computer Science,
pp.528–535, 2005.
[12]

C.J. Augeri, D.A. Bulutoglu, B.E. Mullins, R.O.
Baldwin, and L.C. Baird, “An analysis of XML compression eﬃciency,” ACM ExpCS, 2007.

[13]“Eﬃcient XML interchange measurements note.”[14]

Y. Doi, Y. Sato, M. Ishiyama, Y. Ohba, and K.

http://www.w3.org/TR/exi-measurements/
Teramoto, “XML-less EXI with code generation for
integration of embedded devices in web based systems,” IEEE Internet of Things, 2012.
[15]

J. loup Gailly and M. Adler, http://www.gzip.org/（平成 25 年 1 月 31 日受付，5 月 28 日再受付）

落合

秀也

（正員）

平 18 東大・工・電子情報卒．平 20 同大
大学院情報理工学系研究科修士課程了．平23 同大学院同研究科博士課程了．同年同大学大規模集積システム設計教育研究セン
ター・助教，現在に至る．博士 (情報理工学，東京大学)．設備ネットワーク，広域セ
ンサネットワーク，遅延耐性ネットワーク研究の他，IEEE1888，
ASHRAE の設備ネットワーク標準化活動に従事．

土井

裕介

（正員）

平 12 慶應義塾大学大学院政策・メディア研究科修士課程了．平 23 年 3 月東京大学大学院情報理工学系研究科博士後期課程単位取得退学．同年 9 月，博士 (情報理工学，東京大学) 取得．平 12 より，(株) 東芝研究開発センターで分散システム，ホームネットワーク，電子タグ，組み込み向け XML 処理系等の研究開発，Smart Energy Proﬁle 2.0 の標準化等に従事．

江崎

浩

（正員）

昭 62 九州大学大学院・工・電子修士課程
了．同年 (株) 東芝入社．平 2 米国ニュージャージ州ベルコア社．平 6 コロンビア大学・客員研究員．平 10 東京大学大型計算機センター・助教授．平 13 同大学大学院・情報理工学系研究科・助教授．平 17 同大
学大学院・同研究科・教授，現在に至る．博士 (工学，東京大学)．MPLS-JAPAN 代表，IPv6 普及・高度化推進協議会専務理事，WIDE プロジェクト代表，JPNIC 副理事長．

1113