2004年度 森泰吉郎記念研究振興基金 研究助成金 報告書

携帯マルチメディア端末のためのネットワークアーキテクチャ

慶應義塾大学大学院 政策・メディア研究科 博士課程1年

三屋光史朗


概要

本研究では、携帯可能なマルチメディア端末をインターネットに接続し、マル チメディアコンテンツを自由に交換するためのネットワークアーキテクチャを 提案する。ユニキャスト通信は数多くの先行研究が議論提案されているが、イ ンターネット放送で必要になるマルチキャスト通信に関する研究があまりなさ れていないのが現状である。したがって、携帯マルチメディア端末上でのマル チキャスト通信を実現することを目的とする。アプローチとしては、 Consistent Hashingを応用したアプリケーションレイヤマルチキャストおよび Fast Handover for Mobile IPv6を応用したアプリケーションレイヤマルチキャ ストの最適化を提案する。また、テストベット構築を行い、提案技術の評価を 行った。


はじめに

本研究では、携帯可能なマルチメディア端末をインターネットに接続し、マル チメディアコンテンツを自由に交換す るためのネットワークアーキテクチャを 提案する。ここで言う携帯可能なマルチメディア端末とは、例えばPDAや携帯 電話等を指し、手のひらサイズの小型計算機で所有者と共に自由に移動する。 この端末は、無線LANや携帯電話 網を利用しながら移動中も常にインターネッ トに接続されていて、IP電話やVideo会議、オンデマンドストリーミングな ど と言ったマルチメディアアプリケーションが利用できる。

現在の携帯電話でのマルチメディアサービスは、各携帯電話キャリアが保守し ている通信網内でのコンテンツ配信に限られている。ホームページ閲覧や電子 メールなどの一般に広く普及しているインターネットサービスに比べると非常 に閉鎖的な形態を採っている。これは、我々が切望する自由な情報の交換とは 程遠い。例えば、携帯電話と自 宅のパソコン間のTV電話が可能であってもいい のではないか。したがって、携帯マルチメディア端末をインターネッ トに接続 し、キャリアや端末形態の違いを意識せずに、自由にマルチメディアコンテン ツを交換する潜在的にニーズ は非常に大きいと考える。今後、より多種多様な 携帯マルチメディア端末が利用されるとすると、その重要性は更に高くなるだ ろう。

本研究では携帯マルチメディア端末上でのマルチキャスト通信を実現すること を目的とする。一般に通信形態とし て、1対1のユニキャストと、1対多や多対 多のマルチキャスト通信がある。インターネットは終端ノード同士のユニキャ スト通信を基本的に保障しているし、ネットワークへの接続点を変更しながら 端末が移動したとしても、Mobility 技術 [mip][nemo]を利用することでユニキャ スト通信が保障できるためである。

一般的にマルチキャスト通信は、特定多数を対象にデータを送信する際に有用 である。本研究で提案する機構は、

等のサービスへの応用が期待される。

なお、本年度は、

を目標とする。助成 金は、テストベットを構築する際の機材購入費に当てる。


携帯マルチメディア端末上でマルチキャスト通信を行う際の問題点

携帯マルチメディア端末上でマルチキャスト通信を行う際には、次のような問 題がある。

  1. 不安定なマルチキャストツリー
    マルチキャスト通信は、データグ ラムの複製を中継ノードで行うことで実現される。この情報の伝送路はマルチ キャスト ツリー呼ばれ、マルチキャストツリーを効率的に構築するために様々 なマルチキャスト経路制御技術が考案されてい る。携帯マルチメディア端末は ネットワークの接続点を変更しながら移動することが想定されるが、移動の度 にマルチ キャストツリーの再構成が必要になる。したがって、マルチキャスト ツリーは常に不安定な状態になり、携帯マルチメデ ィア端末へのマルチキャス ト通信が非常に困難になっている。
  2. ハンドオーバーのオーバーヘッド
    一般的にハンドオーバー、つま りネットワークへの接続点の変更の際に、ある一定時間ネットワークから遮断 された状 態になる。その状態時に発生するパケットロスや通信遅延はビデオ会 議などの双方向リアルタイムストリーミングアプ リケーションにとって好まし くない。
  3. 運用経験の欠如
    インターネットは固定ノードによるユニキャスト 通信の手段として広く長く使われてきた。しかし、ネットワークの接続点 を変 更しながら移動するノードやマルチキャスト通信に対するノウハウが絶対的に 少ないのが現状である。携帯マル チメディア端末のように移動もマルチキャス ト通信も必要とするサービスは、正に未知の領域である。

解決へのアプローチ

上記の問題を解決するために、次のようなアプローチをとる。


携帯マルチメディア端末システム概要

図1に、携帯マルチメディア端末の構成概要を示す。ボックスは各機能を表 し、矢印は情報の流れを表している。

携帯マルチメディア端末スタック概要 図1:携帯マルチメディア端末スタック概要

携帯マルチメディア端末は、無線LANを搭載するPDAとする。そのPDAはTCP/IPス タックを搭載し、MIPやFMIP 機能を追加搭載する。TCP/IPスタック上では、ア プリケーションレイヤマルチキャストを実現するALMミドルウェアが 搭載され、 アプリケーションはそのミドルウェアをAPIに、矢印で示しているとおりマルチ キャスト通信を行う。点線矢印 で示したとおり、各ALMミドルウェア同士はマ ルチキャスト経路制御のために情報交換を行っている。


MIPv6 プラットホームの設計と実装

携帯マルチメディア端末は、無線LAN等の通信インターフェースと搭載して、基 地局を切替えながら移動する。基地局の移動に起因して、IPアドレスが変化す る。IPアドレスはインターネットノードの論理識別子であり、IPアドレスの変 化は、通信の遮断や通信のエンドポイントの変更を意味する。この問題を解決 するために、インターネットの標準化策定団体であるIETFにて、Moible IPv6 (MIPv6) という技術が標準化された。今後、移動ノードにこのMIPv6の機能が実 装されていくことが予想されるが、現地点で、自由に利用可能で安定して動作 するMIPv6の実装が存在しない。そこで、本研究では、BSD系のフリーUNIX上で 動作するMIPv6プラットホーム SHISA [shisa] を設計および実装し、世の中に 広く公開した。本研究で提案する機構に必須なFMIPv6プラットホームは、この SHISAを基に実装した。

なお、MIPv6の詳細については[mip]を参照していただきたい。

図2に、SHISAプラットホームの設計概要を示す。図中の丸はアプリケーション デーモンを示し、円筒はデータベースを示す。また、矢印はカーネルユーザラ ンド間のインターフェースを示し、四角はカーネル内のファンクションを示し ている。

SHISA プラットホーム概要 図2: SHISAプラットホーム概要

MIPv6では、Mobile Node (MN)、Home Agent (HA)、およびCorrespondent Node (CN)という特殊なノードが新たに定義されている。SHISAではパケット処理およ びパケット処理に必要最低限のデーターベースのみをkernel部に保持し、シグ ナリグやデータベースの管理等のその他をユーザランドとして実装した。すべ てのノードは同一カーネル上で動作し、対応するユーザランドデーモンを選択 起動することで、ノードの振る舞いを変えることができる。ユーザランドとカー ネル間のインターフェースとして、PF_MOBILITYを新たに定義し、Binding Cache (BC)やBinding Update List (BUL)の同期を行っている。アドレスの取得 や解放等の情報は既存のPF_ROUTEインターフェースから取得し、移動検知を実 現した。

SHISAで現状サポートしている規格は、RFC3775, RFC3776およびRFC3963である。 また、サポートしているプラットホームは、FreeBSD 4系 5系およびNetBSD 1系 2系である。


FMIPv6 プラットホームの設計と実装

携帯電話マルチメディア端末は、基地局の切替えを行いながら移動する。基地 局の切替えに起因して、MIPv6を利用にも関わらず、パケットロスが発生する。 これは、新しい基地局に接続するまでに時間がかかったり、アドレスを取得す るために時間がかかったりするためである。この問題を解決するために、IETF ではFast Handover for Mobile IPv6 (FMIPv6) が標準化が勧められいる。 FMIPv6は、特別なシグナリングで新しく移動する基地局の情報を取得し、実際 に接続するために経路やアドレスの設定を行うことで、移動時間を短縮する。

本研究では、FMIPv6が利用する高速移動設定の仕組みや、事前に基地局情報を 取得する枠組を利用し、マルチキャストツリーの高速最適化を狙う。

現時点で、自由に利用可能で安定して動作するFMIPv6の実装が存在しない。そ こで、本研究では、BSD系のフリーUNIX上で動作するFMIPv6プラットホーム TARZANを設計実装し、世の中に広く公開した。TARZANは、SHISAの拡張として、 設計実装した。なお、FMIPv6の仕様については、[fmip]を参照すること。

図3にTARZANプラットホームの概要を示す。図中、丸および四角は各機能モジュー ルを表し、円筒は各種データーベースを表している。

TARZAN プラットホーム概要 図3: TARZANプラットホーム概要

RtsolPr/PrRtAdvモジュールは、アクセスルータ(基地局)とメッセージをやりと りし、次にハンドオフするアクセスルータの情報を交換している。DriverがL2 的なハンドオフを検知すると、LIES機構を通してFMIPv6モジュールにそれを通 知する。それをトリガーにFMIPv6は移動後の処理をaddress/route management モジュールにて実行する。


テストベット構成

本研究で開発したFMIPv6機構がマルチキャストツリーの高速最適化に有用であ ることを確認するために、テストベットを構築した。図4にテストベットのトポ ロジを示す。図中の丸はノードを表し、矢印はマルチキャストツリーを示して いる。

テストベット トポロジ図 図4: テストベット概要図

テストベットをインターネットに接続するGWおよび、SHISAをインストールした HAとMNを用意した。また、MNとAR1、AR2には、TARZANをインストールした。マ ルチキャストのソースとしてMulticast senderを用意した。Multicast sender 上ではVLCを用い、マルチキャストストリーミング機能を実装した。OS はすべ てFreeBSD 5.3を仕様している。

MNはhome linkからマルチキャストパケットを受信しながらforeign link1およ びforeign link2へと移動する。その際にマルチキャストツリーは、線から点線、 点線から長破線へと変化する。


評価

テストベットの評価を用いて、FMIPv6機構のマルチキャストツリー高速最適化 の評価を示す。図5は、ハンドーオーバー時のMN側で送受信したパケットのシー ケンスを示している。

テストベット評価 図5: TARZANを用いたネットワークハンドオーバーの評価

一般に、通常のマルチキャストのツリー最適化には、

MP = L2 association + DAD + PIM HELLO from nbr on new link (1)
とした時に、
MAX(MP, MLD report from MNN) + PIM Join (2)
であることが知られている。これは各タイマーの値に左右されるが、一般的に 4秒から30秒かかる。これに対し、本研究で提案する機構では、2.8秒とより高 速にツリー最適化できたことが確認できた。また、2.8秒のうち1.8秒はイーサー ネットのauto negotiationにかかった時間で、実装上の不都合で生じたが本来 不要のものである。よって、さらに高速化できることが予想される。


まとめ

本研究では、携帯可能なマルチメディア端末をインターネットに接続し、マル チメディアコンテンツを自由に交換するためのネットワークアーキテクチャを 提案する。本年度の活動として、Fast Handover for Mobile IPv6を応用したア プリケーションレイヤマルチキャストの最適化を提案した。また、テストベッ ト構築を行い、提案技術の評価を行った。その結果、本提案が有用であること が確認できた。

今後の課題として、L2 driver周りの実装最適化による高速化および、L3 multicast機構およびアプリケーションレイヤ機構との連係を行う。


参考文献

[mip] D. Johnson, “Mobility Support for IPv6”, Internet-Draft, IETF, March 2004.
[nemo] V. Devarapalli, “Network Mobility(NEMO) Basic Support Protocol”, Internet-Draft, IETF, June 2004.
[ggcast] K. Mitsuya, "GGCAST - A Location Based Multicasat -", Master thesis, Keio University, March 2004.
[fmip] R. Koodli, “Fast Handovers for Mobile IPv6”, Internet-Draft, IETF, Jan 2004.
[shisa] SHISA: Opensource MIPv6 implementation for BSD, http://wwww.mobileip.jp/, Feb 2005.


Copyright 2004 Koshiro Mitsuya. All rights reserved.