１．担当ＰＭ

　竹内　郁雄 　　（電気通信大学教授）

２．採択者氏名

３．プロジェクト管理組織

　 株式会社　創夢

４． 委託支払金額

　3,000,000円

５．テーマ名

　 Relationship： インターネットを透過的な通信媒体として利用するための技術開発

６．関連Webサイト

　なし

７．プロジェクト概要

　各種デバイス技術の進歩と開発によって，現在ではさまざまな機器がネットワーク接続能力を有し，インターネット通信を利用することは，もはや珍しいことではない．これらの機器は機器間通信のプラットホームとしてインターネット通信を利用し，機器間の配線をインターネット通信として実現している．

　このとき，インターネットは透過的な通信基盤であることが望まれるが，現在のインターネット通信では，機器間での論理的な接続関係の維持，接続先の切り替え，接続先機器の状態検知，安全な接続回線を提供するための統一的な手法が用意されておらず，アプリケーションが個別実装で対応している状況である．この配線のような接続関係をインターネットの通信機能として提供することができれば，上記のネットワークアプリケーションの開発者は，インターネットをよくわからなくとも，とにかく望む通信相手との通信を実現する，便利な通信基盤として利用可能になる．

　当プロジェクトは，インターネットを配線網として利用するために通信側からアプリケーションに対してのミドルウェア技術を開発する．配線網としてのインターネットを実現するためのミドルウェアを開発し，ライブラリとして公開，提供する．ネットワークアプリケーションの製作者は，現在のソケットではなく，このライブラリの Relationship と呼ばれる接続関係を利用することで，上記の機器間配線を形成できる．この配線は，インターネット上のアプリケーション層に独立して形成される．この配線機能はアプリケーション層での通信を抽象化するミドルウェアと，そのミドルウェアによって提供されるエンドノードで動作するモジュールによって実現され， TCP/IP スタックに手を入れる必要がないこと，インターネット内に追加機構をなんら必要としないという特徴を持つことから，移植性に優れる．　このためさまざまなプラットホームに Relation アーキテクチャを移植可能なこと，インターネットであればどのネットワークであっても， Relationship 機能が利用可能という利点を生み出す．

Relationship ミドルウェアによって，誰もがインターネットを任意の機器間でのデータ伝送のために利用することが容易になる．これはインターネット上に切れない配線を用意し，配線の端子形状を統一することに相当する．配線の先は差し替えが可能である．このような通信機能を実現することで，誰もが，インターネットを機器間を接続するための「どこでもドア」のように利用することが可能となる．

８．採択理由

　そうか，こういう発想もあるのかと驚かされた提案である．アプリケーション層で個々の機器をロケーションフリーで配線する仕組みがあるといろいろと面白い使い道がありそうだ．提案を実現するための技術力もさすがこの世界で長く飯を食っている横山君のことなので心配はなさそうだ．昨年度の SoftEther に続いて，未踏ユースでこういったネットワークの基盤技術の開拓が提案されてくるのはとても喜ばしいことだ．

９．成果概要

　インターネットをユビキタス環境の通信基盤として利用するための通信技術， Relationship の開発を行った． Relationship は，機器 ( ノード ) 間の配線において必要とされる，機器間での通信相手のグループ化，通信設定の簡素化，通信接続関係の維持，通信接続先の切り替えを実現する． Relationship の機能は API として用意され，この API を用いることで，開発者に機器間通信でのインターネット利用を容易なものとする．

(1) Relationship の設計

　図 1 は， Relationship の基本構成図である． Relationship は，通信端末ノードの内部で動作する通信管理モジュールと，モジュール間で設定される通信路， Relationship からなる．通信はモジュール間の協調作業によって構成されるため， Relationship はインターネット側の通信設定と独立して設定される．

横山　図 1 RelationShip の基本構成図

　モジュール間での情報共有には，図 2 ノード間での情報交換を利用する．情報交換は，初回位置登録，端末移動時の移動先の通知，位置不明ノードの問い合わせからなる． Relationship 技術では，各ノードには， Personal Name と Family Name が与えられる． Family Name が同じノードは，初回位置登録で Relationship 関係を結ぶ．各ノードは，移動などによって通信設定が変更されると，新しい通信情報を Relationship 関係にあるグループノードへ通知する．これによって通信相手を捕捉する．通知を受信できなかったノードは，他ノードに対して問い合わせることで，通信相手を再補足する．

Relationship の通信端点は， Relationship ソケットとして扱われる．ソケット情報は，情報交換プロトコルによって，グループ内で共有される．待ち受けの受信ソケットの作成が行なわれると，その情報がグループ内で共有される．その受信ソケットへデータ送信を行ないたいノードは，そのソケット名を指定することで通信回線を設定するわけである．

　図 3 は， Relationship が提供する API の概念と API 群である．これらの API によって，表 1 の機能を利用することができる．

横山　図 2 ノード間の情報交換

横山　図 3 Relationship API 群

横山　表 1 Relationship が提供する通信機能

(2) Relationship 技術の実装と評価実験

　上記の設計に基づいて行なった実装の大枠を示すのが図 4 である ( ここでは詳細な説明は省略する ) ．

　作成した Relationship 機能を用いて，いくつかの動作実験を行なった．実験では SPEAKER ノードと PLAYER ノードを用意した．それぞれが音楽を再生するスピーカーと音声データを送信するプレイヤーとしての役割を持つ．

横山　図 4 Relationship のサブモジュール群

　実験 1: Speaker ノードと Player ノードが Relationship 関係を結ぶ． Player が Speaker へデータ送信することで，スピーカーから音声が鳴り始める．その後， Player を移動し，異なるネットワークへ接続した場合でも，再び Speaker と Player が再接続し，音楽が流れ出す ( 図 5) ．この実験によって，情報交換の機構が動作し，ノードの移動時においても Relationship 関係を維持することが可能なことを示した．

横山　図 5 　実験環境 1

　実験 2: Speaker と Player ノードがいったん関係を結び，音楽を鳴らす．そのあと Player はネットワークから切断され，移動される ( 図 6 の離脱 ) ．ここで他の Player ノードが Speaker に近づく ( 図 6 の接続 ) と， Speaker は新たな Player と Relationship 関係を結び，スピーカーからは新しい音楽が鳴る．この実験によって，ソケット名を基にした通信回線の切り替えが可能になったことを示した．

横山　図 6 　実験環境 2

１０． ＰＭ評価とコメント

　これはとても面白い，新しいネットワークインフラにつながる提案だと PM は思った．しかし，世の中的にはモバイル IP とどこが違うのとかいう反応が多いらしい．実際の応用を考えるとモバイル IP とは一味違うぞとすぐ主張できるように思えるのだが，横山君は博士の最終学年ということもあるのか，やや慎重な物言いをする傾向がある．学位を取るためには，あまり教祖的な振る舞いができないのだろうか…．

　ここで提案された Relationship は，実は Inter-device Imprinting on the Internet (III ，または I3 ，または i-cube ，このあたりの略語はまだ安定していないようだ ) という名前に変わっている．ただし，公式の報告書等では，計画書に合わせて，古い Relationship という名前のままになっている．ここで重要なのは Imprinting ( 刷り込み ) という言葉である．まさにこれが「名は体を表す」である．すなわち，複数の情報通信機器 ( 今後はそれに限定されることなく，すべての器具や装置になると思う ) に，お互いは近親関係であるという刷り込みを一度行なうと，遠くに離れてしまっても，インターネットという共通「物理層」につながると，近親関係のもの同士が論理的に簡単につながってしまうということなのである．

　これとてモバイル IP とどこが違うかと聞くと，なかなか決定的な答えが横山君から返ってこないのだが， PM はセキュリティがらみで絶対なにかあると睨んでいる．どこでも家族がつながっているとか，装置の盗難防止に使えるとか，分散共同作業をやりやすくするとか，いくらでもあると思うのだけれど…．やっぱり，こういった network on the Internet は，すべての計算モデルはチューリングマシンと等価だ，といって片付けられるのと似たように，要するにどこが違うの？言われると答えにくいものなのだろうか．

　そうと割り切れば，実使用における快適性，利便性，安全性，速度，などなど，人がそれを使いたいと思う性能や付加価値的機能をもっているかどうかで勝負すればいいのではないかと思うのだが，さて，横山君はどうする？ 世の中，ユビキタスと言っているうちに勝負してほしい．このプロジェクトの中でも，勝負の姿勢がもっと強く出ていたらなあ，と思う．

　横山君は，プログラムをガンガン書くというより，ネットワークの仕様設計といったところに本領を発揮するタイプなので，未踏のようなソフトウェア集団の中では新鮮な思いをしたらしい．この集団では，実使用における快適性，利便性，安全性，速度などが重要な指標になる．そのあたりを盗んでほしい．というのも，横山君の発表は，インプリの詳細に割合すぐ踏みこむようなところがあり，それって文化がちょっと違うぞと思ったからである．

　横山君は年々平均年齢が下がっている未踏ユースにあって，最年長組である．それもあってか，未踏ユースでプロジェクト開始時に行っている「未踏ユースブースト会議」では若い人に対して参考になる発言が多く， PM としてはとてもありがたかった．