Comments
Description
Transcript
オフラインデバイスの ネットワーキング活用法の研究
平成 23 年度 修士学位論文 オフラインデバイスの ネットワーキング活用法の研究 The study of information handling architecture for network forming of offline sensing devices 1145089 森木 峻 指導教員 島村 和典 2012 年 3 月 1 日 高知工科大学大学院 工学研究科 基盤工学専攻 情報システム工学コース 要 旨 オフラインデバイスの ネットワーキング活用法の研究 森木 峻 近年，RFID タグはバーコードや QR コードといった一次元・二次元ンボルの代替として 注目されている．しかし，現在でも一次元・二次元ンボルが使用されているケースが多い． 新たに RFID タグを導入する際に必要なシステムのサーバ機器類や開発コストが高価であ り，またリンクで物理接続されていないデバイス・シンボルを相互して使用することができ るアーキテクチャが提案されていないためと考察する． 本稿では，リンクで物理接続されていない RFID タグなどのデバイスやバーコードや QR コードなどのシンボルを使用したサービスやアプリケーションにおいて，クラウドコ ンピューティングを適用可能とする実用的なネットワークアーキテクチャを提案すること を目的とした．目的を達成するために，クラウド環境下で運用する OCN(Off-Line Cloud Network) アーキテクチャを提案した．クラウドコンピューティングを採用することで， ユーザが導入する際のサーバ機器類や開発のコストを抑制できる．また，OCN アーキテク チャでは，事実上リンクで物理接続されていないデバイス群をネットワークとする必要があ るためオフラインネットワークについての定義を行った．そして，OCN アーキテクチャに おける内部処理の処理時間を計測する検証実験を行った． 検証実験を行った結果，人が利用するために実用的であると判断できる 1,000msec 以下 であることを確認した． キーワード RFID，一次元シンボル，二次元ンボル，オフラインネットワーク，クラウド –i– コンピューティング，OCN アーキテクチャ – ii – Abstract The study of information handling architecture for network forming of offline sensing devices shun MORIKI In recent years, RFID tags has been attracting attention as an alternative of previous patterns such as QR codes and two-dimensional symbols the bar code symbol of one-dimensional symbols. However, one-dimensional two-dimensional symbol is still used today in many cases. Development costs of the system and server equipment required for a new RFID tag is expensive. And consideration for the architecture to be able to use the device to each other symbols that are not physical connection in the link has not been proposed also. In this paper, services and applications using a symbol such as QR code and bar code, or devices such as RFID tags that are not physical connection on a link, to propose a network architecture a practical and applicable to cloud computing aimed at. In order to achieve the objective, here by the OCN(Off-line Cloud Network) architecture is proposed to be operated under a cloud environment. By adopting cloud computing, it is possible to suppress the cost of equipment and development server when the user is introduced. In addition, the OCN architecture was carried out the definition for off-line network because there is a need to network a group of devices that are not on the fact that physical connection in the link. And validation experiments were performed to measure the processing time for internal processing architecture in OCN. The result of experimentation clarified that the processing times gives a practical – iii – response within 1,000 msec. key words RFID，One-Dimensional Symbol，Two-Dimensional Symbol，Off-line Network，Cloud Computing，OCN Architecture – iv – 目次 第1章 序論 1 1.1 研究背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 ユビキタスネットワーク社会 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 RFID タグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.4 一次元シンボル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 EAN/UPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 ITF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 GS1-128（旧称 UCC/EAN-128） . . . . . . . . . . . . . . . . . . 5 NW-7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 CODE39 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.5 二次元シンボル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.6 クラウドコンピューティング . . . . . . . . . . . . . . . . . . . . . . . . 7 1.7 クラウドコンピューティングにおけるサービスと RFID . . . . . . . . . . 7 1.7.1 BitGate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 BitGate プラットフォーム . . . . . . . . . . . . . . . . . . . . . . 10 考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.8 研究目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.9 RFID タグと一次元シンボル・二次元シンボルを併用させる理由 . . . . . 12 1.10 本論文の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 オフラインネットワークの定義 15 オフラインデバイス・シンボルの定義の提案 . . . . . . . . . . . . . . . . 15 第2章 2.1 –v– 目次 2.2 オフラインネットワーク定義の提案 . . . . . . . . . . . . . . . . . . . . . 15 提案ネットワークアーキテクチャ 19 3.1 OCN(Off-line Cloud Network) アーキテクチャ概要 . . . . . . . . . . . . 19 3.2 OCN アーキテクチャのレイヤ構成と内容 . . . . . . . . . . . . . . . . . . 20 第3章 3.2.1 第 0 層 オフラインデバイス・シンボル・レイヤ . . . . . . . . . . 20 3.2.2 第 1 層 センシング・レイヤ . . . . . . . . . . . . . . . . . . . . . 23 3.2.3 第 2 層 コンビネーション・レイヤ . . . . . . . . . . . . . . . . . 24 3.2.4 第 3 層 コンポーネント・レイヤ . . . . . . . . . . . . . . . . . . . 25 共通コンポーネント . . . . . . . . . . . . . . . . . . . . . . . . . . 25 選択コンポーネント . . . . . . . . . . . . . . . . . . . . . . . . . . 25 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 検証評価 29 4.1 検証目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.2 検証環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.3 検証結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.3 第4章 4.3.1 各コンポーネントの処理時間による検証 . . . . . . . . . . . . . . . 30 考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 類似研究との比較検証 . . . . . . . . . . . . . . . . . . . . . . . . . 32 考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 結論 35 4.3.2 4.4 第5章 謝辞 37 参考文献 39 – vi – 目次 付録 A 拡張ヘッダタイプ (プロトコル番号) – vii – 41 図目次 1.1 RFID タグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 JAN シンボル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 ITF シンボル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4 クラウドアプリケーション環境 . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1 オフラインネットワークの概念図 . . . . . . . . . . . . . . . . . . . . . . . 17 3.1 OCN アーキテクチャの概念図 . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2 オフラインデバイス・シンボルのデータ構造 . . . . . . . . . . . . . . . . . 22 3.3 オフラインデバイス・シンボルヘッダの定義図 . . . . . . . . . . . . . . . . 27 4.1 各コンポーネントの処理時間 . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.2 OCN アーキテクチャ全体の処理時間と RIS クラウドアーキテクチャ全体の 処理時間の比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 32 RIS クラウドアーキテクチャにおけるコンポーネントのプロトタイプの処理 時間 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . – ix – 33 表目次 3.1 オフラインデバイス・シンボルと読み取り・書き込み端末との対応表 . . . . 23 4.1 サンプルアプリケーションの処理時間 . . . . . . . . . . . . . . . . . . . . 31 A.1 拡張ヘッダタイプ (プロトコル番号) . . . . . . . . . . . . . . . . . . . . . 42 – xi – 第1章 序論 本章では, 本研究の背景と目的について述べる. 1.1 研究背景 ユビキタス・ネットワーク (Ubiquitous Network) 社会を実現させるためのデバイスとし て，RFID(Radio Frequency IDentification) が注目されている．その理由として，ユビキ タスネットワーク社会では，あらゆる人とあらゆるモノが自在に接続できるとしており，モ ノがデバイスや端末でなかった場合，モノに RFID タグを張り付けることによりやりとりを 行えるとしているためである．現在では，RFID タグが使用されているシーンとして，物流 業界や流通業界におけるサプライチェーンマネジメントや製品ライフサイクル管理などに使 用されている． また，現在ではクラウドコンピューティングを適用した RFID システムが提案されてお り，クラウド化を図らないときよりサーバ等の機器のコストや開発するためのコストを削減 できるため，ユーザの敷居が引くなりつつある． しかし，RFID システムを IP ネットワークで使用するための互換性のある提案がされて いないことや，RFID は，一次元シンボル（バーコード）や二次元シンボル（QR コード） の代替品として注目はされたが，RFID とシンボルを併用して使用するための提案がされて いないため，実用的とはいえないという問題点がある． –1– 第 1 章 序論 1.2 ユビキタスネットワーク社会 近年，日本はユビキタスネットワーク社会に向かうにあたり様々な技術提案がされ，注目 を浴びている．ユビキタスネットワーク社会とは，「いつでも，どこでも，何でも，誰でも」 ネットワークにつながることを指す．『ユビキタス（Ubiquitous）』という言葉はラテン語 で「いたるところに在る．遍在する．」という意味である．ユビキタスネットワーク社会で は，数多くの様々なサービスが提供され，人々の生活をより豊かにする社会を目指している. 「いつでも」とは，日常の生活活動の何気ない時間や，移動時間等あらゆる場面・瞬間にお いてネットワークに接続できるということである．「どこでも」とは，公園や路上といった 屋外や，電車・自動車等での移動しているときのあらゆる場所においてネットワークに接続 できるということである．「何でも，誰でも」とは，人と身近な端末・家電等の物・位置情報 など，あらゆる人とあらゆるモノが自在に接続できるということである． これらを踏まえると，ユビキタスネットワーク社会とは，サービスを利用するユーザ側に ついて述べられている． 1.3 RFID タグ RFID (Radio Frequency Identification) タグは，ID 情報を埋め込んだ IC タグに無線通 信用アンテナを組み合わせた小型デバイスであり，誘導電磁界または電波によって非接触で 半導体メモリのデータを読み出し，書き込みのために近距離通信を行う物の総称である．次 世代ユビキタスネットワークにおいて，全く新しい情報処理アプリケーションを実現させる と期待されている．現在，流通分野のバーコードに変わる商品識別・管理技術や，Suica や ICOCA などの乗車カードや Edy や iD などの電子マネー，セキュリティロックなどに使わ れる社員証といった非接触 IC カードも RFID の一種に含まれる．これらから今後は情報処 理分野の基盤技術として注目が高まっている．RFID タグの写真を図 1.1 に示す．RFID タ グは，個体識別可能な微少な IC チップとアンテナから構成される． RFID タグは，パッシブタグ，アクティブタグ，セミアクティブタグの三種類に別けられ –2– 1.4 一次元シンボル 図 1.1 RFID タグ る．パッシブタグはリーダから送信された電波を電力として供給することで動作する RFID タグである．受信距離は短いが電源を内蔵する必要がなく安価であり，また，ほぼ恒久的に 動作することから，在庫管理や盗難防止のための対象の識別に用いられることが多い．アク ティブタグはタグ内に電源を内蔵した RFID タグであり，自らの電力を利用して電波を発 することができる．通信距離はパッシブタグより長く，自らのタイミングで通信を行うこと が可能であるため，センサと接続することによってセンサネットワークの端末としての利用 されることが期待されている．セミアクティブタグはパッシブタグとアクティブタグを組み 合わせた RFID タグであり，電池を内蔵しているがリーダから送信された電波によって起 動し，内蔵電源を用いて電波を発する． 1.4 一次元シンボル 一次元シンボルとは，横方向のみに情報を持つシンボルで，世間一般ではバーコードシン ボル（愛称：バーコード）こと指します．日本で主に利用され，JIS 規格となっている一次 元シンボルは 5 種類あり，以下に説明する． EAN/UPC JAN(Japanese Article Number) シンボルとは，日本独自の呼び方であり，国際的には EAN(European Article Number) シンボルと呼ばれる．JAN シンボルを図 1.2 に示す． –3– 第 1 章 序論 図 1.2 JAN シンボル JAN シンボルは，1 つの数字を表すため 7 つの帯（モジュール）を 2 本の黒バーと 2 本 の白バーを組み合わせて表現するバーコードシンボルである．JAN コードをコンピュータ や各種の情報機器に自動入力するために標準化されたバーコードシンボルです．JAN コー ドには標準タイプの 13 桁と小物商品にのみ利用できる短縮タイプの 8 桁が存在する． ITF ITF シンボルを図 1.3 に示す． 図 1.3 ITF シンボル ITF とは，Inter - Leaved（さし挟んだ）Two of Five（5 本のバーのうち 2 本のバーが太 –4– 1.4 一次元シンボル いという意味）の略称で，企業間の取引単位である集合包装（ケース，ボール，パレットな ど）に対し設定された商品識別コードである集合包装用商品コードをバーコードシンボルで 表示する場合に国際標準化されている 14 桁のシンボルのことである．主に物流分野で利用 されているシンボルである． GS1-128（旧称 UCC/EAN-128） GS1-128 とは，流通・製造・物流・サービス分野における商品関連情報や企業間取引情 報をコード番号で体系化し，その識別コード番号と商品関連情報，及び企業間取引情報を 「コード 128」というシンボルで表現したものである．コード 128 とは，アスキーコード 128 文字全てを使用できるシンボルである．バーコードの最大桁数は，数字のみであれば 48 ケ タ，英字は一文字につき 2 ケタ使用する． NW-7 Narrow（狭い）と Wide（広い）の 2 種類の，4 本のバーと 3 本のスペースの合計 7 本 で 1 つのキャラクタが構成されているため，NW-7 と呼ばれている．つまり，桁数は 7 ケタ で，0∼9 までの数字，6 個の特殊記号（−，＄，：，／，．，＋）4 個のスタート・ストップ コード（A∼D）が使用できる．比較的単純なバーの構成と，バーの間隔にゆとりがあるこ とから印刷が簡単で，特にナンバリング式印刷が容易なため， 血液の管理用，宅配便の配送 伝票，図書の管理，貸出用会員カード，書留郵便の管理用など，連番印刷の必要なものに広 く利用されている． CODE39 CODE39 は数字，アルファベットといくつかの記号の合計 43 のキャラクタをコード化し たもので，5 本の黒バーと 4 本のスペース，合計 9 本のうち 3 本が太バー又は太スペース –5– 第 1 章 序論 であることから『CODE 39』と名付けられており，4 ケタで表される．CODE39 は，自動 車・電機関係の輸出入用梱包などに使用されている． まとめ 一次元シンボルには，JIS 規格に登録されていないシンボルもいくつか存在し，それぞれ の一次元シンボルには特徴がある．一次元シンボルのシンボル番号に，年月日や時間を含ん だり，その規格内における一意な番号であったりする．また，シンボルのバーとバーの間隔 が比較的に大きいのであれば，読み取る時間が早い・誤差が少ない．一次元シンボルの種類 が多くなりすぎると，どれがユーザが持っているバーコードリーダに使用できるかがわから ないということも成りかねないため，種類が多いからといっていいとは言い切れない． 1.5 二次元シンボル 二次元シンボルは，JIS 規格において「バーコードシンボルの情報を読むために，バー コードシンボルに対し，水平および垂直の両方向を走査することによって機械読取り可能な バーコードシンボル」と定義されている．二次元シンボルにおいて JIS 規格に登録されてい るのは，QR コードだけである． 次に QR コードについて述べる．QR コードは，株式会社デンソーウェーブが開発した 縦横コードで情報を付加させているマトリクス型の二次元シンボルである．格納できる情 報量が多く，数字だけではなく英字や漢字なども格納できる．バイナリデータでは最大で 2953byte，最大で数字なら 7089 文字，英数字なら 4296 文字，漢字なら 1817 文字を表すこ とが可能付加することが出来る．日本では，カメラ付き携帯電話のほとんどで QR コードの 読み取りが可能で，幅広いところで使用されている． –6– 1.6 クラウドコンピューティング 1.6 クラウドコンピューティング クラウドコンピューティングとは，インターネット上のサーバリソースを用いて，サーバ リソースからエンドユーザに対してサービスや情報処理の環境を提供することを指す．クラ ウドコンピューティングのサービス形態として，インターネット経由でソフトウェアを提供 する SaaS (Software as a Service) や, インターネット上にソフトウェアの実行環境を提供 する PaaS (Platform as a Service) が存在する. クラウドコンピューティングの広がりとと もに, SaaS として提供されるクラウドサービスの種類は増加している. 特に近年では, 文章 作成ソフトウェアや会計ソフトウェアといった, 従来ではパッケージソフトウェアとして提 供されていたものがインターネットを通じてどこからでも利用出来る形で提供されている. また PaaS の利用形態も広がっており, 特に Google App Engine に代表される無料で使用 可能な PaaS を利用することで, 誰でも容易に SaaS によるクラウドサービスを提供するこ とができる. 1.7 クラウドコンピューティングにおけるサービスと RFID ネットワークアプリケーション環境において RFID アプリケーションを健全に動作させる ためには，各 RFID R/W や管理 PC，データベースなどに対しての高度なセキュリティ管 理や各端末の管理保守といった大きな手間が必須となる．これらの機能を各 RFID タグ読 み取り環境毎に実装する場合，それぞれの環境を構築するたびに高い技術力や高価な CPU やメモリが複数必要となり，RFID タグ読み取り環境の維持コストも膨大なものとなる．ま た，高性能な管理用 PC の設置が必須であるため，RFID タグ読み取り環境の施設により広 い面積を必要となる．つまり，ネットワークアプリケーション環境において，RFID アプリ ケーションはその規模が大きければそれに従って施設や維持に必要なコストが大きくなって しまう．また，小規模にアプリケーション環境を施設する場合であっても，RFID R/W や 管理 PC といった高価な機器を必要とするため，RFID アプリケーションの効果と費用との コストパフォーマンスの点から RFID アプリケーションは容易に導入できるものではない． –7– 第 1 章 序論 これらの問題によって，RFID アプリケーション環境の普及が本格的に進むのは困難なもの となっている． この問題を解決するための手段として，クラウドコンピューティングを利用した RFID アプリケーション環境の構築が有効であるとされている．クラウドコンピューティングを 利用したクラウドアプリケーション環境を 1.4 に示す．クラウドアプリケーション環境で は，RFID タグ読み取り環境は RFID R/W で読み取った RFID タグデータに手を加える 必要がない．フィルタリングなどの RFID タグデータの調整，加工といった処理は IP ネッ トワーク上に存在するクラウドコンピューティングインフラに設置された，RFID アプリ ケーションにおける基本機能を持つ共有基盤にて行われる．RFID タグ読み取り環境では， RFID R/W での RFID タグの読み取りと TCP/IP による RFID タグデータの送信のみを 行う．また，RFID アプリケーションサーバ環境ではすべての調整，加工といった処理を終 えた RFID タグデータのみを受け取り，アプリケーションに必要な動作のみを行う．クラウ ドアプリケーション環境は他のアプリケーション環境と異なり RFID アプリケーション管 理者は，RFID アプリケーション環境と RFID R/W，通信ユニットにのみ関与すれば良く， 個々の端末の管理や基本機能を持つ管理 PC の維持をする必要がない．従って，従来のロー カルアプリケーション環境やネットワーク環境と比べ，低コストで RFID アプリケーション 環境の構築や維持を行うことができる．また，従来の RFID アプリケーション環境では利 用される多くの RFID R/W が管理 PC との RFID タグデータの通信にシリアル通信によ るデータ転送を行っている．これを通信ユニットを利用した TCP/IP によるデータ転送に 変更することによって，データ抜けやデータ化けといったエラーを TCP/IP の下位レイヤ にて処理を行うことができるため，誤った RFID タグデータが転送されることがなく，信頼 性の向上も期待できる．しかし現状のクラウドアプリケーション環境は RFID タグ規格の 統合運用を前提としたものではなく，それぞれの RFID タグ読み取り環境や RFID アプリ ケーションは独立して運用されることを前提としている． –8– 1.7 クラウドコンピューティングにおけるサービスと RFID 図 1.4 クラウドアプリケーション環境 1.7.1 BitGate クラウドアプリケーション環境を提供するサービスとして，NEC の「BitGate」が挙げら れる．BitGate の概要について解説する． –9– 第 1 章 序論 概要 「BitGate」は 2009 年からサービス提供を始めたインターネット経由で RFID タグの ID 情報を収集し，企業の機関システムに引き渡す RFID サービスであり，RFID タグと RFID タグ読み取り環境，共通基盤サービスをパッケージ化して提供する PaaS(プラットフォー ム・アズ・ア・サービス) 型のクラウドソリューションである．BitGate は共通基盤サービ スのインフラとして，NEC の SaaS 基盤サービス「RIACUBE/SP」を採用している． BitGate プラットフォーム BitGate プラットフォームはパッケージ化された BitGate サービスを運用するプラット フォームである．BitGate プラットフォームの概要を図??に示す．BitGate プラットフォー ムは RFID タグと RFID R/W，Bitgate サーバ，RFID アプリケーションサーバ環境に よって構成されており．RFID アプリケーションサーバ環境は RFID アプリケーション利 用企業がそれぞれ独自に管理されている．RFID タグは，あらかじめ暗号化された ID 情報 を保持している．RFID R/W は暗号化された ID 情報を読み取り，そのまま BitGate サー バに送信する．この際，RFID R/W は登録されている自身の固有識別子も合わせて送信 する．BitGate で利用される RFID R/W は NEC が独自に BitGate を対象に開発したモ ジュールを搭載しており，複数の周波数帯と複数のプロトコルを同時に識別できるように されたものである．また，この RFID R/W は読み取り速度においても高速化を為されて おり，RFID タグの ID 情報を 100msec で読み取ることが可能である．BitGate サーバで は RFID R/W の固有識別子を一元管理しており，RFID R/W から受け取った固有識別子 が RFID タグの ID 情報と一致しているか確認する．対応していれば，ID 情報を RFID ア プリケーションサーバ環境に送信する．これによって，RFID アプリケーション管理者は RFID R/W 毎に RFID タグと連携できる RFID アプリケーション環境を制限することが できる．また，暗号化された RFID タグの ID 情報の復号も BitGate サーバで処理を行う． RFID アプリケーション環境への送信が許可され，更に復号された ID 情報は専用線にて – 10 – 1.8 研究目的 RFID アプリケーションサーバ環境に送信される．BitGate はそれぞれの RFID R/W の ファームウェアをリモートで管理しており，新たな規格を利用する際のファームウェアの更 新も容易に管理できる．BitGate プラットフォームは，RFID R/W での RFID タグの読み 取りから BitGate サーバでの処理，RFID アプリケーションによるサービス提供の開始ま でに約 500msec の処理時間で完了できる． 考察 BitGate では，RFID タグのみ使用をする．近年，パッシブ型の RFID タグの価格も下落 しつつも，未だにシンボルとの価格差は大きい．シンボルは印刷で良いため，数円オーダー で可能であるが，RFID タグでは未だに平均数百円という価格である．RFID タグの良さは 読み取れる環境にかざすだけで情報のやりとりが可能であることである． 本研究は，スーパーマーケットや百貨店といった小売業でも使用できることを想定してい る．小売業でも高価なのものであれば平均数百円という RFID タグを付加させることも可 能であるが，低価格な品である場合，平均数百円の RFID タグを付加させることは非常に厳 しいのが現状である． 1.8 研究目的 近年，RFID タグは一次元シンボル（バーコード）や二次元シンボル（QR コード）の代 替として移行されつつあるが，現在でも一次元シンボル・二次元シンボルが使用されている ケースが多い．新たに RFID タグを導入する際に必要なシステムのサーバ機器類や開発コ ストが高価であり，またリンクで物理接続されていないデバイス・シンボルを相互して使用 することができるアーキテクチャが提案されていないためと考察する． 本稿では，リンクで物理接続されていない RFID タグなどのデバイスやバーコードや QR コードなどのシンボルを使用したサービスやアプリケーションにおいて，クラウドコン ピューティングを適用可能とする実用的なネットワークアーキテクチャを提案することが目 – 11 – 第 1 章 序論 的である．また，事実上リンクで物理接続されていないデバイス群をオフラインネットワー クとして見なすことができるため，オフラインネットワークについて定義する．クラウドコ ンピューティングを採用することで，ユーザが導入する際のサーバ機器類や開発のコストを 抑制できる．また，RFID タグと低コストで運用できる一次元シンボル，二次元シンボルを 併用可能にすることで，ユーザのニーズに合わせてサービスを提供できる． 1.9 RFID タグと一次元シンボル・二次元シンボルを併用さ せる理由 シンボルの使われ方として，製品や梱包された箱に貼られることで用いられている．シン ボルは印刷するだけで良いためコストも非常に安いというメリットがある反面，読み取る際 はシンボルに読み取る端末を接触させるくらい近づけなければならない．人間がシンボルを 読み取るという動作を行うと，単品であれば大した時間ではないが，沢山のシンボルがある となると結構な時間がかかってしまう．RFID タグでは，タグ一つのコストはシンボルより 高価であるが，読み取る際は，R/W をかざすだけで読み取ることができ，この一連の動作 をシンボルを読み取る際と比較すると，数が多くなればなるほど差が大きく生まれると考え られる． これらを効率よく利用するために RFID タグとシンボルを併用するという方法を提案す る．例えば，サプライチェーンマネジメントにおいて，工場である商品を箱に詰め，その箱 がいくつかの物流センターを介し，小売店舗に輸送される．この一連の流れでは，いくつも の商品が入っている箱に一つの RFID タグを付加することにより，工場から小売店舗までの 情報のやり取りは，シンボルを読み取るものより手間が少ないゆえに人件費も抑えることが できる．また，多数ある同一商品を一つの RFID タグでやりとりできるため，商品一つ当た りにかかる RFID タグのコストは非常に小さい．しかし，商品一つ一つに RFID タグを付 与する場合，商品一つ当たりの RFID タグのコストが大きくなる．更に，箱に RFID タグ を付与するということであれば，回収して再度利用することが可能であるが，商品を購入さ – 12 – 1.10 本論文の構成 れた顧客までに RFID タグが渡ってしまうと，RFID タグを回収できる確率は低くなると考 える．その面からもコストに差が出る． つまり，物流の際に必要なやりとりは箱に付与された RFID タグで行い，店舗で販売する ときに商品一つ一つに付与されたシンボルを使用することで時間とコストを抑えることが可 能であると考察する． そのため，本研究では RFID タグと一次元シンボル・二次元シンボルを併用して使用する ことで，一例ではあるが，人件費やオフラインデバイス・シンボルによるコストの合計をで きるだけ抑えるようにするための提案を行う． 1.10 本論文の構成 本章では, 本研究の背景と，研究の目的について述べた．以降, 第 2 章では，オフライン ネットワークの定義について提案する．第 3 章では，クラウドコンピューティングに適用に した OCN アーキテクチャを提案する．第 4 章では，OCN アーキテクチャの検証と評価を 行う．第 5 章では，本研究の結論として提案方式の考察と今後の展望，課題を述べる． – 13 – 第2章 オフラインネットワークの定義 今後迎えるユビキタスネットワーク社会は，デバイス自体から通信要求を送ることができ ない状態が存在すると考察する．本章では，末端のアプライアンス装置から通信要求を行う ことが可能なネットワークとして，オンラインネットワークとして定義する． 2.1 オフラインデバイス・シンボルの定義の提案 オフラインネットワークを定義するにあたり，まずオフラインデバイス・シンボルを定義 する．『ネットワーク』とは複数の要素が互いに接続された網状の構造体を指す．オフライ ンデバイス・シンボルは，ネットワークの説明に当てはめると『要素』に当たる．『オフライ ン』という言葉を用いる理由として，単体から通信要求が送ることができないためである． これらのことから，本稿ではオフラインデバイス・シンボルは，単体から通信要求が不可能 な IC タグをオフラインデバイス，一次元シンボル，二次元シンボルをオフラインシンボル と定義する．例としては，オフラインデバイスでは RFID タグ，オフラインシンボルでは一 次元シンボルのバーコード，二次元シンボルの QR コードが挙げられる． 2.2 オフラインネットワーク定義の提案 最初にオンラインネットワークについて定義する．『オンライン』とは，一般的に通信回線 等を使用しホストコンピュータに接続できる状態を指し，『ネットワーク』は前節でも述べ たように，複数の要素が互いに接続された網状の構造体を指す．これらから本稿では，クラ イアントコンピュータとホストコンピュータが常にリンクで物理接続可能な状態であり，ど – 15 – 第 2 章 オフラインネットワークの定義 ちらからでも通信要求を送ることが可能なネットワークをオンラインネットワークとする． これらを踏まえ，本稿におけるオフラインネットワークの定義として，リンクで物理接続 されていないオフラインデバイス・シンボル群を一時的にリンクで物理接続させるために， 読み取り端末として RFID R/W(Reader/Writer)・バーコードリーダを用いて，読み取れ る環境を構築する．オフラインデバイス・シンボルが読み取れる環境が存在し，上位レイヤ にサービスもしくはアプリケーションが存在するときの接続状態をオフラインネットワーク と定義する． 次に，オフラインネットワークの概念図を図 2.1 に示し，次に図 2.1 の要点を記述する． 上位レイヤには，必ずサービスやアプリケーションが存在し，中位レイヤには，オフライン デバイス・シンボルを読み取れる端末を用いられれていることが図 2.1 から読み取れる．読 み取る端末の例は，RFID R/W・バーコードリーダが挙げられる．下位レイヤでは，オフ ラインデバイス・シンボルが読み取れる環境があるときの接続状態をオフラインネットワー クとしている． – 16 – 2.2 オフラインネットワーク定義の提案 図 2.1 オフラインネットワークの概念図 – 17 – 第3章 提案ネットワークアーキテクチャ 3.1 OCN(Off-line Cloud Network) アーキテクチャ概要 提案ネットワークアーキテクチャとして，クラウド環境下で運用する OCN アーキテク チャを提案する．OCN アーキテクチャは 4 階層で構成され，オフラインデバイス・シン ボルの規定からクラウドコンピューティングの構成までの設計概念である．図 3.1 に OCN アーキテクチャの概念図を示す． 図 3.1 は，階層の名称・順序と階層のどこに誰が該当するのかを視覚的に把握できる物で ある．図 3.1 について，下位から上位に向かってレイヤの内容を簡潔に説明する． OCN アーキテクチャの最下位はオフラインデバイス・シンボル・レイヤである．本レイ ヤは，ユーザがオフラインデバイス・シンボルを選択し，RFID R/W やバーコードリーダ とのやり取りを行うレイヤである．選択できるデバイス・シンボルとしては，RFID タグ・ 二次元シンボル (QR コード等)・一次元シンボル (バーコード等) があり，新たに追加するこ とも可能とする．また，RFID R/W やバーコードリーダはオフラインデバイス・シンボル が保持する固有識別番号や付加されているデータの認識や空き領域に書き込む役割がある． 次は，RFID R/W やバーコードリーダ等の読み込み・書き込み端末とオフラインデバイ ス・シンボルの対応付け，ユーザによる固有識別番号の選定を行うプレゼンス・センシング レイヤである．固有識別番号の選定は，サービス・アプリケーション単位のみで使用でき る番号，IPv6 アドレスの番号，それ意外のフリーとする一意な番号のいずれかから選択で きる． 次は，オフラインネットワークとオンラインネットワークの相互接続を可能とするための – 19 – 第 3 章 提案ネットワークアーキテクチャ コンビネーション・レイヤである．本レイヤでは，オンラインネットワークで用いるパケッ ト構成の規定を行うレイヤである．パケットは IPv6 を想定して構成している． OCN アーキテクチャの最上位は，クラウド環境の構成について明記しているコンポーネ ント・レイヤである．コンポーネント・レイヤは，サービス・アプリケーションを構築する 際に必須となる『共通コンポーネント』とユーザが必要に応じて選択できる『選択コンポー ネント』について明記している．サービス・アプリケーション事業者はコンポーネントを利 用することで，容易にサービス・アプリケーションを構築できる．また，クラウド環境を提 供するのは，クラウド環境事業者とする． 最後に，OCN アーキテクチャの上位にはサービス・アプリケーションがあり，これらを 提供するのはサービス・アプリケーション開発事業者である． 3.2 OCN アーキテクチャのレイヤ構成と内容 本節では，OCN アーキテクチャのレイヤの構成と内容について下位から順に述べる． 3.2.1 第 0 層 オフラインデバイス・シンボル・レイヤ オフラインデバイス・レイヤでは，ユーザが利用したいオフラインデバイス・シンボルを 選択するレイヤである．そのため，現時点で使用できるオフラインデバイス・シンボルにつ いて規定する．選択できるオフラインデバイス・シンボルは次の項目の通りである．また， 技術進展等で新たなオフラインデバイス・シンボルが発表された場合，そのオフラインデバ イス・シンボルに関して規定することで, 追加利用も可能とする． 1. RFID タグ（IC チップ） 2. 一次元シンボル 3. 二次元シンボル – 20 – 3.2 OCN アーキテクチャのレイヤ構成と内容 図 3.1 OCN アーキテクチャの概念図 RFID タグ，一次元シンボル，二次元シンボルの全てに，固有識別番号を付与することを 必須とする．また，それぞれのオフラインデバイス・シンボルともに仮想データ格納デー タベースとの連携が可能である．RFID タグと二次元シンボルの固有識別番号については， 16byte の固有識別番号とする．一次元シンボルの固有識別番号については，JIS 規格で採用 されている，JAN・ITF・GSI-128・NW-7 で規定されているそれぞれのバーコードのバー コード番号を使用する． – 21 – 第 3 章 提案ネットワークアーキテクチャ RFID タグと二次元シンボルの空き領域は，クラウドアプリケーションデータとしてユー ザ・サービス・アプリケーション事業者が自由に使用することが可能である．更に，RFID タグと QR コードにおいて，固有識別番号のみの場合，固有識別番号とデータの場合，どち らでも可能としている．理由として，RFID タグ内のデータ容量によって読み取り時間が大 きく変化するためである． 128byte のデータ容量を持つ RFID タグと 2,953byte のデータ容量を持つ QR コードを 想定したオフラインデバイス・シンボルのデータ構造を図 3.2 に示す． 図 3.2 について説明する．128byte のデータ容量を持つ RFID タグと 2,953byte のデー タ容量を持つ QR コードを想定しており，RFID タグについては，16byte の固有識別番号， 112byte のクラウドアプリケーションデータを保持することが可能である．また，QR コー ドについては，16byte の固有識別番号，2,937byte のクラウドアプリケーションデータを保 持することが可能である． 図 3.2 オフラインデバイス・シンボルのデータ構造 – 22 – 3.2 OCN アーキテクチャのレイヤ構成と内容 3.2.2 第 1 層 センシング・レイヤ センシング・レイヤでは，オフラインデバイスを読み取る端末の選択，固有識別番号の規 定と選択を行う．読み取る端末の選択種類を，読み取り端末とオフラインデバイスの対応表 を表 3.1 に示す． 表 3.1 では，読み取り端末・書き込み端末とオフラインデバイスの対応を示しており， RFID R/W は，RFID タグに対応，バーコードリーダは，一次元シンボル・二次元シンボ ルに対応している．最後に，携帯電話は二次元シンボルに対応している．また，技術進展等 で新たなオフラインデバイス・シンボルや読み取り端末が発表された場合，そのオフライン デバイス・シンボルに関して規定することで, 追加利用も可能とする． 表 3.1 オフラインデバイス・シンボルと読み取り・書き込み端末との対応表 読み取り・書き込み端末 オフラインデバイス・シンボル RFID R/W RFID タグ バーコードリーダ 一次元シンボル 二次元シンボル 携帯電話 二次元シンボル 固有識別番号の規定の提案として，クラウドアプリケーション内のみで使用できる一意な 番号，もしくはインフラとしての使用できる番号として IPv6 を提案する．ともにデータ容 量としては 16byte とし，適応できるオフラインデバイスは，データ容量が最低で 16byte あ る RFID タグと二次元シンボルとする．また，一次元シンボルの固有識別番号は，3.2.1 節 で述べたように，JIS 規格で採用されている，JAN・ITF・GSI-128・NW-7 で規定されて いるそれぞれのバーコードのバーコード番号を使用する． – 23 – 第 3 章 提案ネットワークアーキテクチャ 3.2.3 第 2 層 コンビネーション・レイヤ コンビネーション・レイヤでは，オフラインデバイスのデータを送るために必要なパケッ トの構造提案を行う．本稿では，近年身近になってきた IPv6 に注目し，IPv6 の拡張ヘッダ を利用して『オフラインデバイス・シンボルパケット』を提案する．オフラインデバイス・ シンボルパケットは，IPv6 ヘッダと拡張ヘッダで構成している． IPv6 ヘッダは，IPv6 規格として使用されている構成で，バージョン (4bit)，トラフィッ クスクラス (8bit)，フローラベル (20bit)，ペイロード長 (16bit)，次ヘッダ (8bit)，最大ホッ プ数 (8bit)，送信元アドレス (128bit)，宛先アドレス (128bit) である． 拡張ヘッダは，OCN アーキテクチャバージョン (4bit)，オフラインデバイス・シンボル ナンバー (4bit)，クラウドサービス・アプリケーション (24bit)，オフラインデバイス・シン ボル 固有識別番号 (128bit)，クラウドアプリケーションデータ領域 (32bit × n) で構成す る．OCN アーキテクチャバージョンは，OCN アーキテクチャのバージョンを指す．本稿 の時点では，0001 である．オフラインデバイス・シンボルナンバーは，デバイス・シンボル の種類一つ一つに番号を振った数字である．クラウドサービス・アプリケーションは，サー ビス・アプリケーションの種類一つ一つに番号を振った数字である．オフラインデバイス・ シンボル 固有識別番号は，読み取ったオフラインデバイス・シンボルの固有識別番号のこと である．クラウドアプリケーションデータ領域は，オフラインデバイス・シンボルに格納さ れているクラウドアプリケーションデータの情報が盛り込まれる．『32 × n』の n は，オフ ラインデバイス・シンボルの格納できるデータ量までを賄うものである． オフラインデバイス・シンボルヘッダの定義図を図 3.3 に示し，図 3.3 について説明する． 提案するパケット構造は，IPv6 ヘッダと拡張ヘッダを利用したオフラインデバイス・シン ボルヘッダで構成されている． まず，IPv6 基本ヘッダに関しては IPv6 規格の通りで，バージョン (4bit)，トラフィック スクラス (8bit)，フローラベル (20bit)，ペイロード長 (16bit)，次ヘッダ (8bit)，最大ホッ プ数 (8bit)，送信元アドレス (128bit)，宛先アドレス (128bit) である． – 24 – 3.2 OCN アーキテクチャのレイヤ構成と内容 TCP ヘッダは，次ヘッダ (8bit)，ヘッダ長 (8bit)，空き領域 (16bit) である． また，拡張ヘッダに関しては，OCN アーキテクチャバージョン (4bit)，オフラインデバ イス・シンボルナンバー (4bit)，クラウドサービス・アプリケーション (24bit)，オフライン デバイス・シンボル 固有識別番号 (128bit)，クラウドアプリケーションデータ領域 (32bit × n) としている．クラウドアプリケーションデータ領域での『n』はオフラインデバイス・ シンボルによって異なり，クラウドアプリケーションデータが収まる適切な数字となる． 更に，本研究では拡張ヘッダタイプ (プロトコル番号) を 150 番と想定する．拡張ヘッダ タイプを 150 番と想定することで，IPsec や認証ヘッダ等のプロトコルが使用可能となる． 3.2.4 第 3 層 コンポーネント・レイヤ コンポーネント・レイヤには，サービス・アプリケーションを構築する際に必須となる 『共通コンポーネント』とユーザが必要に応じて選択できる『選択コンポーネント』が存在 する．以下に，それぞれのコンポーネントについて述べる． 共通コンポーネント 共通コンポーネントには，『受信機能』がある．『受信機能』は下位レイヤから送信された オフラインデバイスの情報を受信するための機能である． 選択コンポーネント 選択コンポーネントには，『認証・セキュリティ機能』，『統合規格変換機能』，『仮想デー タ格納データベース』，『ロケーション情報提供機能』がある． 『認証・セキュリティ機能』はファイアウォール (DMZ) と暗号化の機能がある．ファイ アウォールを敷く理由としては不正侵入を防ぐためであり，方法としては認証を行う．用 いる認証の技術は，アクセス制御リスト（フィルタリングテーブル）を用いての認証，数 値・サインを用いるパスワード認証，指紋・指静脈・虹彩・筆跡を用いる生体認証を使用す – 25 – 第 3 章 提案ネットワークアーキテクチャ る．暗号化においては HTTPS(Hypertext Transfer Protocol over Secure socket Layer) や VPN(Virtual Private Network) で使用される IPsec(Security Architecture for Internet Protocol)，TLS/SSL(Transport Layer Security/Secure Sockets Layer) 等のプロトコルを 補完する． 『統合規格変換機能』は，RISCA 統合タグ規格や RFID ネットワーク統合規格等におい て RFID タグのデータ規格が定義されているため，統合規格を変換することを可能とする機 能である． 『仮想データ格納データベース』は，オフラインデバイスに固有識別番号以外のデータ を関連付けたい場合，RFID タグの空き領域以外の選択肢として，固有識別番号と紐付さ れたデータを格納することが可能なデータベースである．一つの固有識別番号に対して， 128byte までの領域がある． 『ロケーション情報的機能』は，オフラインデバイスに付加されている固有識別番号と，ロ ケーション情報データベースにある情報を紐付しユーザにロケーション情報を提供すること を可能とする．オフラインデバイスのデータ領域は，『固有識別番号のみ』の場合でも，『固 有識別番号と空き領域に書き込まれたデータ』の場合でも可能である．更に，仮想データ格 納データベースとも連携は可能である． また，共通コンポーネント・選択コンポーネントともに新たにコンポーネントを増設可能 にするための拡張機能がある． 3.3 まとめ 本章では，RFID タグだけではなく一次元シンボルや二次元ンボルをクラウド環境下でも 用いることができる OCN アーキテクチャを提案した．本アーキテクチャを利用すること で，それぞれの役割を独立にしていることで，互いの環境に左右されることなく連携して動 作できる実用的な利用体系を実現できる． – 26 – 3.3 まとめ 図 3.3 オフラインデバイス・シンボルヘッダの定義図 – 27 – 第4章 検証評価 本章では，本稿で提案した OCN アーキテクチャに関する検証と，検証結果からの考察を する． 4.1 検証目的 検証実験の目的は本研究の提案方式である OCN アーキテクチャに従ってクラウド環境上 で構築したコンポーネントのプロトタイプの処理時間を計測することである． 本検証実験では，OCN アーキテクチャを基にしてコンポーネントのプロトタイプを実装 した．実装先は，実際にサービスとして提供されているクラウドインフラ上に，コンポーネ ントのプロトタイプを実装し，クラウドインフラ上で動作させ，各コンポーネントの処理時 間を取得する．そして，その処理時間が実用性のあるものか評価をする．また，類似研究と の各コンポーネントにおける比較と，オフラインデバイス・シンボルの読み取りからアプリ ケーションの起動開始までのまでの処理全体をシミュレーション実験によって得た処理時間 の比較を行い評価をする． 4.2 検証環境 実験環境として，Google Inc. が提供しているクラウドサーバ環境である Google Ap- pEngine を利用する．Google App Engine では Google が検索や Google Map などへの多 大なアクセスを処理するために所持しているデータセンタ内のサーバリソースをクラウド環 境として広く提供しているものである．実際に Google AppEngine のサーバリソースを利 – 29 – 第4章 検証評価 用して自社開発のソフトウェアを動作させ，独自のサービスとして提供している企業も数多 く存在している．Google App Engine は Python 用，Java 用にそれぞれソフトウェア開 発キットが用意されている．本検証実験は Google App Enginefor Java を用いて行った． Google App Engine では，OCN アーキテクチャにおけるクラウド環境部分を実装し，処理 時間を計測する． 4.3 4.3.1 検証結果 各コンポーネントの処理時間による検証 コンポーネントのプロトタイプをクラウド環境上に実装し，一連の動作を行って得た処理 時間をコンポーネント毎に分けた結果を図 4.1 に示す． 本検証では，RFID タグを読み取られたことを想定したデータ構造で実証実験を行った． 今回は RFID タグに，固有識別番号のみ情報があり，クラウドアプリケーションデータは書 き込まれていなかったということを想定している． また，オフラインデバイス・シンボルパケットは，RFID タグの情報を踏まえ，オフライ ンデバイスナンバー (4bit)，クラウドアプリケーションナンバー (24bit)，オフラインデバ イス・シンボルの固有識別番号 (128bit) のみ情報があることを想定した． 考察 図 4.1 より，OCN アーキテクチャにおけるコンポーネントのプロトタイプの平均処理時 間は 201msec，最大処理時間は 332msec であったことが判る．この処理時間には，外部処理 時間に当たるアプリケーションの処理時間が含まれていないため，サンプルアプリケーショ ンの処理時間を加える．サンプルアプリケーションの処理時間を表 4.1 に示す．コンポーネ ントのプロトタイプとサンプルアプリケーションを考慮した平均処理時間は 313msec，最 大処理時間は 450msec であったことから，処理時間が例え最大処理時間であったとしても， – 30 – 4.3 検証結果 図 4.1 各コンポーネントの処理時間 OCN アーキテクチャは実用に耐えうる処理速度であると考察する． 表 4.1 サンプルアプリケーションの処理時間 サンプルアプリケーション 最小処理時間 平均処理時間 最大処理時間 93 msec 112msec 138msec – 31 – 第4章 4.3.2 検証評価 類似研究との比較検証 本研究で提案した OCN アーキテクチャと，類似研究である『RIS クラウドアーキテク チャ』における各コンポーネントのプロトタイプの処理時間とサンプルアプリケーションの 処理時間を用いて OCN アーキテクチャ全体の処理時間をシミュレーションによって導き， 比較を行った． シミュレーションから得られた OCN アーキテクチャ全体の処理時間と RIS クラウド アーキテクチャ全体の処理時間を図 4.2 に示す．また，RIS クラウドアーキテクチャにおけ るコンポーネントのプロトタイプの処理時間を図 4.3 に示す． 図 4.2 OCN アーキテクチャ全体の処理時間と RIS クラウドアーキテクチャ全体の処理時間の比較 – 32 – 4.3 検証結果 図 4.3 RIS クラウドアーキテクチャにおけるコンポーネントのプロトタイプの処理時間 考察 シミュレーション実験の結果，RIS クラウドアーキテクチャを用いた場合，平均処理時間 で 288msec，最大処理時間で 421msec であった．また，OCN アーキテクチャを用いた場 合，平均処理時間で 309msec，最大処理時間で 445msec であった．結果として，処理時間の 早さでいうと RIS クラウドアーキテクチャを用いた場合が早い．このような結果が出た理 由として，RIS クラウドアーキテクチャで処理した情報量は，RFID タグ内の 128byte であ り，OCN アーキテクチャでは，オフラインデバイス・シンボルパケットの情報量 132byte を用いているため，OCN アーキテクチャにおける処理時間が掛かったと考察する．処理時 間は RIS クラウドアーキテクチャと比較すると劣るが，IP ネットワークでのやりとりが可 能であることを確認できた．また，RFID タグといったデバイスだけではなくバーコードや – 33 – 第4章 検証評価 QR コードといったシンボルも扱うことが可能であることや，オフラインデバイス・シンボ ルヘッダに適応させる拡張ヘッダタイプ (プロトコル番号) を 150 番と想定したことから， IPsec や認証ヘッダを用いることができるため，セキュリティ面での課題をクリアさせる提 案をした． 4.4 まとめ 本章では，OCN アーキテクチャのコンポーネントにおける処理時間を評価することで提 案方式の実用性を計った．サンプルコンポーネントを実際のクラウド環境で動作させること によって内部処理時間の値を取得し，またシミュレーション実験によって外部・内部処理時 間を類似研究である RIS クラウドアーキテクチャと処理時間と実用性において比較を行い， 提案した OCN アーキテクチャの有用性も明らかにした． – 34 – 第5章 結論 本研究は，RFID タグだけではなく一次元シンボルや二次元ンボルをクラウド環境下でも 用いることができる OCN アーキテクチャを提案した．本アーキテクチャを利用すること で，それぞれの役割を独立にしていることで，互いの環境に左右されることなく連携して動 作できる実用的な利用体系を実現できる．また，ユーザが導入する際のサーバ機器類や開発 のコストを抑制でき，RFID タグのみならず一次元シンボル・二次元シンボルを併用可能と することで，導入する敷居を下げることができた．更に，オフラインデバイス・シンボルが 読み取れる環境が存在し，上位レイヤにサービスもしくはアプリケーションが存在するとき の接続状態をオフラインネットワークと定義した． そして，提案した OCN アーキテクチャに基づきコンポーネントのプロトタイプを実装 し，実際にインフラとしてクラウドサーバ環境を提供されている Google App Engine 上で， 動作させることによって提案方式の処理時間を検証実験した．この検証実験により，OCN アーキテクチャの最大処理時間は 450msec であった．また，RIS クラウドアーキテクチャ と処理時間と実用性で比較した結果，処理時間は RIS クラウドアーキテクチャと比較する と劣るが，OCN アーキテクチャでは，IP ネットワークでのやりとりが可能であることも確 認できた．また，RFID タグといったデバイスだけではなくバーコードや QR コードといっ たシンボルも扱うことが可能であることため，スーパーマーケットや百貨店といった小売業 界でもより幅広く使用できると考察する．さらに，オフラインデバイス・シンボルヘッダに 適応させる拡張ヘッダタイプ (プロトコル番号) を 150 番と想定したことから，IPsec や認 証ヘッダを用いることができるため，RIS クラウドアーキテクチャの課題であった IP ネッ トワーク上でのセキュリティ面の課題をクリアさせる提案をした． – 35 – 謝辞 島村研究室に配属されてから 3 年半が経過しました．大学生活及び研究室生活において沢 山の方々に，協力や援助をして頂けたおかげで，日々の苦悩を乗り越えられて来ました．学 生生活最後の本論文に，お世話になった皆様に感謝の意を表します． 本論文を完成させるにあたり，指導教員である高知工科大学情報学群 島村 和典 教授に は，常日頃から的確・丁寧な御指導賜り，また Skype というツールを駆使し何時何処からで もご教授して頂きました．研究活動だけではなく，就職活動や社会勉強において熱心にご指 導して頂きました．3 年半の間，誠にありがとうございました． 副査としてご指導して頂きました，情報学群 福本 昌弘 教授，ならびに浜村 昌則 准教授 には，大変お忙しい中，有益な御助言を頂き，心より感謝を申し上げます． 公私において，共に苦難・快楽を味わい実りある生活を送ることができた，研究室の同輩 の重松史哉氏にも厚くお礼申し上げます． 研究室の後輩として，共に研究室活動に励んだ大学院修士課程 1 年 稲葉海斗氏，野崎翔 太氏，学士 4 年 松岡奈穂氏，松野遼太氏，山下寛晃氏，和田倫弥氏，学士 3 年 大楠大志氏， 小笠原一聡氏，尾崎遼太氏，京極海氏，島田裕幸氏，辻際宗和氏，日高大樹氏に，心より感 謝致します． また，無理を言って大学院まで進学させて下さった両親に，心より感謝申し上げます．24 年間育てて頂き本当にありがとうございました． 最後に，これまでお世話になった皆様，本当にありがとうございました．また何時か何処 かでお会いしましたら，お声をおかけ下さったら幸いです． – 37 – 参考文献 [1] 森木峻，島村和典， “オフラインデバイスのネットワーキング活用方法の一提案” ，電子 情報通信学会技術報告．USN，Vol.111，pp.129-134，Jan19-20.2012. [2] 森木峻，島村和典，”オフラインデバイスのネットワーキング活用方法の一検討”，電気 関係学会四国支部連合大会講演論文集，p200，平成 2011 年 9 月 23 日． [3] 財団法人流通システム開発センター，”流通システム標準データキャリア”， http://www.dsri.jp/baredi/jan symbol.htm (2012 年 2 月 27 日現在) [4] 財団法人流通システム開発センター，”EPCglobal(電子タグ)”， http://www.dsri.jp/epcgl/epc/data.htm (2012 年 2 月 27 日現在) [5] 日本電気株式会社，”BitGate”， http://www.nec.co.jp/rfid/bitgate/ (2012 年 2 月 27 日現在) [6] サカタウエアハウス株式会社，”EPCglobal の最新動向”， http://www.sakata.co.jp/nletter/nletter 110215.html(2012 年 2 月 27 日現在) [7] IRI，ユビキタス研究所，”マスタリング TCP/IP IPv6 編”，平成 17 年 2 月 1 日初版 発行, 株式会社オーム社． [8] 川村裕介，島村和典，”クラウドインフラを利用した RFID 統合利用環境の構成に関す る研究”，高知工科大学修士学位論文，2010． [9] IANA，”Protocol Numbers”， http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml(2012 年 2 月 27 日現在) [10] 総務省，”平成 16 年版 情報通信白書”， http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h16/html/G1401000.html – 39 – 付録 A 拡張ヘッダタイプ (プロトコル番号) 2012 年 2 月 24 日現在，使用されている拡張ヘッダタイプ (プロトコル番号) を表 A.1 に 示す． – 41 – 付録 A 拡張ヘッダタイプ (プロトコル番号) 表 A.1 拡張ヘッダタイプ (プロトコル番号) Decimal Keyword Protocol 0 HOPOPT IPv6 Hop-by-Hop Option 1 ICMP Internet Control Message 2 IGMP Internet Group Management 3 GGP Gateway-to-Gateway 4 IPv4 IPv4 encapsulation 5 ST Stream 6 TCP Transmission Control 7 CBT CBT 8 EGP Exterior Gateway Protocol 9 IGP any private interior gateway(used by Cisco for their IGRP) 10 BBN-RCC-MON BBN RCC Monitoring 11 NVP-II Network Voice Protocol 12 PUP PUP 13 ARGUS ARGUS 14 EMCON EMCON 15 XNET Cross Net Debugger 16 CHAOS Chaos 17 UDP User Datagram 18 MUX Multiplexing 19 DCN-MEAS DCN Measurement Subsystems 20 HMP Host Monitoring – 42 – Decimal Keyword Protocol 21 PRM Packet Radio Measurement 22 XNS-IDP XEROX NS IDP 23 TRUNK-1 Trunk-1 24 TRUNK-2 Trunk-2 25 LEAF-1 Leaf-1 26 LEAF-2 Leaf-2 27 RDP Reliable Data Protocol 28 IRTP Internet Reliable Transaction 29 ISO-TP4 ISO Transport Protocol Class 4 30 NETBLT Bulk Data Transfer Protocol 31 MFE-NSP MFE Network Services Protocol 32 MERIT-INP MERIT Internodal Protocol 33 DCCP Datagram Congestion Control Protocol 34 3PC Third Party Connect Protocol 35 IDPR Inter-Domain Policy Routing Protocol 36 XTP XTP 37 DDP Datagram Delivery Protocol 38 IDPR-CMTP IDPR Control Message Transport Proto 39 TP++ TP++ Transport Protocol 40 IL IL Transport Protocol – 43 – 付録 A 拡張ヘッダタイプ (プロトコル番号) Decimal Keyword Protocol 41 IPv6 IPv6 encapsulation 42 SDRP Source Demand Routing Protocol 43 IPv6-Route Routing Header for IPv6 44 IPv6-Frag Fragment Header for IPv6 45 IDRP Inter-Domain Routing Protocol 46 RSVP Reservation Protocol 47 GRE General Routing Encapsulation 48 DSR Dynamic Source Routing Protocol 49 BNA BNA 50 ESP Encap Security Payload 51 AH Authentication Header 52 I-NLSP Integrated Net Layer Security TUBA 53 SWIPE IP with Encryption 54 NARP NBMA Address Resolution Protocol 55 MOBILE IP Mobility 56 TLSP Transport Layer Security Protocol using Kryptonet key management 57 SKIP SKIP 58 IPv6-ICMP ICMP for IPv6 59 IPv6-NoNxt No Next Header for IPv6 60 IPv6-Opts Destination Options for IPv6 – 44 – Decimal Keyword 61 62 Protocol any host internal protocol CFTP 63 CFTP any local network 64 SAT-EXPAK SATNET and Backroom EXPAK 65 KRYPTOLAN Kryptolan 66 RVD MIT Remote Virtual Disk Protocol 67 IPPC Internet Pluribus Packet Core 68 any distributed file system 69 SAT-MON SATNET Monitoring 70 VISA VISA Protocol 71 IPCV Internet Packet Core Utility 72 CPNX Computer Protocol Network Executive 73 CPHB Computer Protocol Heart Beat 74 WSN Wang Span Network 75 PVP Packet Video Protocol 76 BR-SAT-MON Backroom SATNET Monitoring 77 SUN-ND SUN ND PROTOCOL-Temporary 78 WB-MON WIDEBAND Monitoring 79 WB-EXPAK WIDEBAND EXPAK 80 ISO-IP ISO Internet Protocol – 45 – 付録 A 拡張ヘッダタイプ (プロトコル番号) Decimal Keyword Protocol 81 VMTP VMTP 82 SECURE-VMTP SECURE-VMTP 83 VINES VINES 84 TTP TTP 84 IPTM Protocol Internet Protocol Traffic Manager 85 NSFNET-IGP NSFNET-IGP 86 DGP Dissimilar Gateway Protocol 87 TCF TCF 88 EIGRP EIGRP 89 OSPFIGP OSPFIGP 90 Sprite-RPC Sprite RPC Protocol 91 LARP Locus Address Resolution Protocol 92 MTP Multicast Transport Protocol 93 AX.25 AX.25 Frames 94 IPIP IP-within-IP Encapsulation Protocol 95 MICP Mobile Internetworking Control Pro. 96 SCC-SP Semaphore Communications Sec. Pro. 97 ETHERIP Ethernet-within-IP Encapsulation 98 ENCAP Encapsulation Header 99 100 any private encryption scheme GMTP GMTP – 46 – Decimal Keyword Protocol 101 IFMP Ipsilon Flow Management Protocol 102 PNNI PNNI over IP 103 PIM Protocol Independent Multicast 104 ARIS ARIS 105 SCPS SCPS 106 QNX QNX 107 A/N Active Networks 108 IPComp IP Payload Compression Protocol 109 SNP Sitara Networks Protocol 110 Compaq-Peer Compaq Peer Protocol 111 IPX-in-IP IPX in IP 112 VRRP Virtual Router Redundancy Protocol 113 PGM PGM Reliable Transport Protocol 114 any 0-hop protocol 115 L2TP Layer Two Tunneling Protocol 116 DDX D-II Data Exchange 117 IATP Interactive Agent Transfer Protocol 118 STP Schedule Transfer Protocol 119 SRP SpectraLink Radio Protocol 120 UTI UTI – 47 – 付録 A 拡張ヘッダタイプ (プロトコル番号) Decimal Keyword Protocol 121 SMP Simple Message Protocol 122 SM SM 123 PTP Performance Transparency Protocol 124 ISIS over IPv4 125 FIRE 126 CRTP Combat Radio Transport Protocol 127 CRUDP Combat Radio User Datagram 128 SSCOPMCE 129 IPLT 130 SPS Secure Packet Shield 131 PIPE Private IP Encapsulation within IP 132 SCTP Stream Control Transmission Protocol 133 FC Fibre Channel 134 RSVP-E2E-IGNORE 135 Mobility Header 136 UDPLite 137 MPLS-in-IP 138 manet MANET Protocols 139 HIP Host Identity Protocol 140 Shim6 Shim6 Protocol – 48 – Decimal Keyword Protocol 141 WESP Wrapped Encapsulating Security Payload 142 ROHC Robust Header Compression 143-252 Unassigned 253 Use for experimentation and testing 254 Use for experimentation and testing 255 Reserved – 49 –