QoS マルチキャスト ルータを用いたインターネット 放送システムの設計と実装
外池昌嗣3

古村隆明 y3y

京都大学

藤川賢治 3

岡部寿男 3

京都高度技術研究所z

池田克夫 z

大阪工業大学QoS マルチキャストルータを用いたインターネット放送システムを設計し実装する。このルータは本研究プロジェクトの一環として開発され，資源予約とマルチキャストを実現するためのプロトコルとして SRSVP を用いる。今本研究では、回実装するシステムでは、単独で放送するだけでなく、他の放送局の放送を中継し、加工して放送することを目指す。これにより、他国の放送に自国の音声を付加して放送することができる。また、他国から受信した動画像を再編集して放送することも考慮している。本稿では、放送の受信に必要な情報を記述するためのibcast URI を定義し、インターネット放送の外観を示し、システムの設計と実装及び行った実験について述べる。

Design and Implementation of an Internet
Broadcasting System using QoS Multicast Router
TONOIKE Masatsugu3 KOMURA Takaakiy FUJIKAWA Kenji3
OKABE Yasuo3 IKEDA Katsuoz
3Kyoto University yASTEM RI zOsaka Institute of Technology
We design and implement an Internet broadcasting system using QoS multicast router. This router was developed
form a part of this research project and use SRSVP as a resource reservation and multicast signaling protocol. We
aim not only to broadcast streams solely but also to relay and edit other broadcast streams. This enables adding avoice of the mother tongue to the broadcast of another country. Editing and broadcasting the video streams received
from another country is also considered. We de ne ibcast URI, which describes information for receiving broadcasts,
outline an Internet broadcasting system, and describe the design and implementation of the system and experiments.

1

はじめにて，やはり本研究プロジェクトの一環として開発された

SRSVP[1][2] を用いる．これにより，TV 品質で膨大な受RealPlayer や MediaPlayer の普及が示すように，近年信者数に対応できるインターネット放送システムのインフ放送がインターネットに移行してきている．現在のインラが整いつつある．

ターネット放送システムの問題点は，まずストリームの送そこで本研究では，このルータと信がユニキャストであるため，膨大な受信者数に対応できSRSVP を用いて膨ない点が挙げられる．したがって，放送局は受信者数に比大な受信者数に対応できるインターネット放送システムを例してサーバを用意しなければならない．次に，設計し実装する．このシステムは，マルチキャスト対応な

QoS 保などの低速のアクセス網を想定しているため，低品質の放ので，膨大な数の受信者に対して，PC クラスの計算機が1 台あれば，個人でも容易に放送できるようになる．そして QoS 保証対応なので，他のフローの影響を受けず，安送をせざるを得ないという問題がある．

定して放送を受信できる．

証が行われていない点が挙げられる．このためストリームを安定して受信できない．さらに，アナログ電話やISDNタをハード ウェアに実装し，完成間近である．また，資源2
3
QoS マルチキャストルータと資源予約と SRSVP について，4 章で設計について，5 章で実装について，6 章で実験についてそれぞれ述べ，7 章をまと予約とマルチキャストを実現するためのプロトコルとしめと今後の課題とする．

一方，近年のインターネットは，光ファイバなどアクセ以下では， 章でインターネット放送実現のための要件

ス網が高速化されつつある．そして，本研究プロジェクト
では，マルチキャストとについて， 章ではQoS 保証を同時に実現するルー1

2

マルチキャストフローを 1000 フローを扱うことが可能とインターネット 放送実現のための要件なった．

本章ではインターネット放送実現のための要件について述べる．

3 QoS マルチキャスト ルータと資源予約プロト コル SRSVP

2.1 マルチキャスト
マルチキャストは，パケットを必要なときだけルータで3.1 QoS マルチキャスト ルータコピーして数多くの受信者に送信する技術である．送信者

本研究プロジェクトの一環として開発された，QoS マ

はマルチキャストアドレスあてにパケットを 1 回送信する

ルチキャストルータについて説明する．このルータは，前だけでよい．この技術を使えば送信者は同じストリームを大量に同時に送信する必要がなくなり，放送サーバの負荷節で述べた PPQ により QoS 保証を実現している．また，もユニキャストストリームを一組送信するのと同程度まで資源予約及びマルチキャストのプロトコルとして，次節で述べる SRSVP を用いる．

軽減される．したがって，マルチキャストは放送という形態に適した送信方法と言える．

3.2 SRSVP の概要

しかし，マルチキャストは現行の TV 放送と同様に不特SRSVP(Simple Resource ReSerVation Protocol) [1][2] は本研究の一環として開発されたインターネット上でマ定多数に対してストリームを送信しているという性格上，パケットが一部届かなかった受信者に対して個別にパケッ

ルチキャスト，資源予約，課金を実現するためのプロトコトの再送を行うことはできない．パケットの喪失はストルである．SRSVP で資源予約するには，ルータが SRSVPリームの再生を乱す．したがって，高品質なインターネッ対応である必要がある．SRSVP は RSVP[5] と PIM[6] のト放送を行うには，パケットが失われないようにするため機能を併せ持ち，不要な機能は削られ，かつ必要な機能がの仕組みも同時に用意する必要がある．この例として，エ追加されている．資源を予約すれば，帯域，遅延，パケッラー訂正符合や，後述する QoS 保証の技術があげられる．

トロス率といった QoS が一定の値に保証される．SRSVP
ではフローを個別に管理しているのでマルチキャストに対2.2 QoS 保証と PPQ応できる．

QoS(Quality of Service) 保証とは，帯域，遅延，パケッSRSVP では PIM と同様にランデブーポイントがマル

トロス率などの通信品質を保証する技術で，この機能はチキャスト木の根となる．ランデブーポイントは，送信者ルータに実装される．ルータはキューを持っており，受信しからストリームを受信し，これをマルチキャスト送信するたパケットをキューに格納し，スケジューリングアルゴリためのものである．送信者自身がランデブーポイントとズムにしたがって送信処理を行っていく．このときキューなってもよい．資源予約は受信者主導で動的に行われる．

があふれるとパケットが失われる．一般的な QoS 保証技

ただし，SRSVP では QoS 情報は送信者もしくはランデ術ではフロー毎にキューを用意し，他のフローからの影響ブーポイントが指定するものであり，受信者はそれに従わを排除することによって QoS を保証している．しかしななければならない．

がら，保証できる遅延が大きい，フロー毎にバッファを用

3.3 ランデブーポイント

意しなければならず，コストがかかり実装が難しいという問題点がある．

ランデブーポイントは，送信者からストリームを受信し，本研究では，PPQ(Policed Priority Queuing)[3][4] のこれをマルチキャスト送信するためのものである．また，機能を持つルータを使用する．PPQ は QoS 保証のためス受信者からの資源予約メッセージに対して応答する．PIM

ケジューリングアルゴリズムの技術の一つで，フロー毎にのランデブーポイントはルータであるのに対し，SRSVPキューを用意せず，インターフェイス毎にベストエフォー

ではランデブーポイントはアプリケーションゲートウェイ

ト用と QoS 保証用の二つのキューを用意している．そしである．このため，送信者の認証や，ストリーム転送の開てフローを監視し帯域違反したパケットをキューに格納始及び停止，スト リーム送信先に対する資源予約，遠隔する前に廃棄する．特徴として，バースト性の低いトラ操作など，様々な機能を目的に応じて付加することができフィックを対象としていて，あらかじめ予約した帯域幅以下での利用に対して，パケットロス率が 1005 以下になるる．本研究でも，この特徴を利用し，ランデブーポイントことを保証するものである．予約帯域以上のパケットが送と，放送サーバの IP アド レスとポート番号の指定と，送信されたときは，ルータでパケットが破棄されるので，予信の開始及び停止を行う．

を遠隔操作し，送信先の IP アド レスとポート番号の指定約帯域を守って送信されているストリームは保護されるこ3.4 資源予約方法とになる．保証できる遅延は，フロー毎にキューを用意す

SRSVP の資源予約は受信者主導である．資源予約とスる手法に比べると小さく，フロー毎にバッファを用意せず

ト リームの受信の様子を図 1 に示す．資源予約は受信者に済むという利点がある．

PPQ を採用することにより，1Gbps の高速リンクでがランデブーポイント宛に資源予約メッセージを送信する

2

ことにより始まる（図 1 1 ）．この図では，送信者は直接キャスト放送し，同時に，他の放送局にもストリームをマ

マルチキャストアドレスに対してストリームを送信するのルチキャストで送信する．日本にある放送局は，オーストではなく，ランデブーポイントに対して送信している（図ラリアの放送局からストリームを受信し，日本語の音声に1 2 )．送信者よりストリームを受信しているランデブーポ

よる解説を付け，日本語のテロップを受信した試合の映像

イントは，受け取ったストリームをマルチキャストアド レに付加し，日本の視聴者に放送すると同時に，国内の他のス宛に転送している（図 1 3 ）．さらに別の受信者が資源放送局にもストリームを送信する．視聴者は最寄りの放送予約を行うと（図 1 4 ），ルータで予約がマージされ，こ局だけでなく，好きな放送局からの放送を受信できる．の受信者にもストリームが届くようになる（図 1 5 ）．こ

上の図でこのモデルの全体の様子を提示したが，以下の例では T1，T3 間に予約できる帯域が残っていなかっではまず放送に必要となる情報を記述する ibcast URI をたので，この経路は使わず，T1，T2 間の経路が選択され定義し，次に視聴者が見たい番組を見るまでの操作と，受た．これは SRSVP が QoS ルーティング機能を持つこと

信アプリケーションが行うべき動作を明らかにし，最後にによる．

放送局の詳細な構成と個々の構成要素の果たすべき役割とその動作を明らかにする．

ランデブーポイント

ルータ

RVP

3ルータ

11

T1

1

受信者

T2

4.2 ibcast URI

R13

本節では，放送の受信に必要な情報を記述する ibcastURI(Internet BroadCAST Uniform Resourse Identier) を設計する．使用できる帯域や目的などによって，

32

54

様々なフォーマットや品質で放送は行われる．また，放送

4S

送信者

T3

資源予約メッセージ

ルータ

映像・音声ストリーム（マルチキャスト)映像・音声ストリーム（ユニキャスト)

5

R2の開始時刻，終了時刻を知らないと，番組の録画予約を受信者することができない．したがって，放送を受信するためには，受信アプリケーションにそれらの情報を渡す必要があ

数字る．その手段として，SAP[7] という手法が提案されていたが，放送数に対するスケーラビリティーに問題がある．
放送の受信に必要な情報を定期的に広告する必要はない

図 1: SRSVP マルチキャスト資源予約点，放送を受信したい人だけが情報を受け取ればよい点を考慮すると，ウェブのように，見たい人が見るシステムによって情報を受け渡しするのがもっともよい方法であると4考えられる．

インターネット 放送システムの設計「 セッションの責本研究では，SDP[7] の項目を参考に．
任者の連絡先」など不要な項目を削除し，かつ SRSVP の4.1 全体像

手続きに必要な項目を付加する形で，ibcast URI を設計

インターネット放送の例を図 2 に示し，それについてした．URI に記載される情報としては，マルチキャスト解説する．

アド レス，ポート番号，放送の開始及び終了時刻，繰り返し間隔，繰り返し回数，ストリームのフォーマット，パラ

サウンドサーバ

ビデオサーバフランス

メータ及び QoS となる．その構文は図 3 のようになる．

マルチキャスト A
(UDP)
受信者

受信者

ただし，[ ] は省略可能を表し，*は直前の項目の 0 回以上

受信者
マルチキャスト B(UDP)の繰り返しを，+は 1 回以上の繰り返しを表す．

ランデブーポイント
ユニキャスト(UDP)
サウンドサーバ

ビデオサーバランデブーポイント

受信者

受信者

受信者

オーストラリア
受信者

受信者







ibcast://<IP アド レ ス>/[t=<開 始 時 刻>:<終 了 時 刻>&[r=<繰り返し間隔>:<繰り返し回数>&]*] [m=rtp:<ポート番号>:<ペイロード タイプ >:<エンコーデ ィング名>:<クロックレート >[:<パラメータ>]*]+

日本

受信者

図 2: インターネット放送システムの全体像

図 3: ibcast URI の構文
図 2 は全体の様子の例であり，オーストラリアからオリンピックのサッカーの生中継を想定している．まず，オー

例として，マルチキャストアドレスが 224.130.54.22 でストラリアの放送局はオーストラリアの視聴者にマルチ

CD 音質 2ch の音声スト リームがポート番号 9000 番に，
3

30fps の JPEG ストリームがポート番号 9001 番に放送さ

れていることを示す ibcast URI を図 4 に示す．

ibcast://224.130.54.22/m=rtp:9000:96:X-S16LE:44100:2&m=rtp:9001:97:JPEG:30



図 4: ibcast URI の例

5

インターネット 放送システムの実装
本章では，前章での設計を元にインターネット放送システムを実装する．
本研究では，放送を加工して再放送することを目指す
ので，フレーム単位の処理がしやすい JPEG を用いることとする．

5.1 仕様 動画{ 320x240 の JPEG ストリームを毎秒 30 フレー

4.3 受信アプリケーション

ム流す．消費する帯域は約 4Mbps である．

受信アプ リケーションの設計は，受信者に SRSVP を{ リアルタイム圧縮で上記の仕様を満たすように意識させずに，普通のテレビやビデオの感覚で使えるようする．にすることを重視する．ブラウザで番組表を見て，見たい 音声

番組や予約したい番組をクリックすると，受信アプリケーションが起動，もしくは予約される．放送の受信開始時に{ 16bit，44100Hz，ステレオでサンプ リングし資源予約の確認メッセージを表示する．

IBCAST番組表
ファイル 編集 表示

た音声を無圧縮で送信する．

{ 消費する帯域は，約 1400kbps である．
受信アプリケーション起動

ジャンプ

5.2 実装するもの

URL http://www.hogehoge.com/soccer/today.html

実装するものは表 1 の通りである．

IBCAST番組表
サッカー 日本対オーストラリア

19:00~22:30

放送中!

表 1: 実装するモジュール

見る

放送局側

Click

図 5: 受信側

受信者側

オーデ ィオサーバ

オーデ ィオクライアント

ビデオサーバ

ビデオクライアント

ランデブーポイント

ibcast URI パーサ

サーバ，クライアントは FreeBSD 4.2[8] 上に実装する．

4.4 放送局

画面表示には SDL ライブラリ [9] を用いる．JPEG 圧縮には libjpeg[10] を用いる．

放送局はスト リームを送信する．放送局は，サウンドサーバ，ビデオサーバ，ランデブーポイントで構成される．

5.3 バースト の抑制

サウンド サーバ及びビデオサーバがランデブーポイン
トに送信するコンテンツは，サーバがリアルタイムにキャSRSVP 対応ルータは 2.2 節で述べた PPQ を行っていプチャしたもの，サーバのディスク装置に蓄積されているる．帯域違反したフローがあるとキューがあふれる原因にもの，もしくは他の放送局からリアルタイムに受信したもなるので，帯域違反しているパケットを検出し破棄する必のなどである．ランデブーポイントは放送局からストリー要がある．これを行うのがポリサー (policer) である．帯

ムを受け取り，指定されたマルチキャストアド レスとポー

域違反には短期的なバーストと長期的な違反のに種類があト番号に対してストリームを送信する．また，受信者からり，どちらもキューをあふれさせる原因となるので，違反の資源予約メッセージを受け取り，返答メッセージを受信として検出される．今回実装したビデオサーバは当初，動画をキャプチャして，その後圧縮してから，1 フレーム分者に返すことにより，資源予約を成立させる．

まとめて送信していた．実際に放送を始めるとバーストし4.5 放送の中継た送信となり，ルータでパケットが破棄されてしまった．

放送局が放送を受信，デコードして，それを加工し，再したがって，本研究で実装するインターネット放送では，

びエンコード して放送する機能を設計する．これにより，送信がバーストしないようにする必要がある．

野球の二元中継のような複数ストリームの合成や，テロッ

そこで，バーストしないように，パケットが等間隔に送プの挿入や，画像サイズの縮小などの操作ができるように信されるようにする，シェイパー (shaper) という機能をなる．

ビデオサーバに実装した．

4

ビデオサーバがバーストしないように送っていても，ネットワークの遅延などの影響でランデブーポイントに到着するまでにバーストすることがある．このため，ランデブーポイントにも同様のシェイパー機能を付加した．
テロップ挿入

5.4 放送の中継
放送局が放送を受信，デコードして，それを加工し，再加工前加工後

びエンコード して放送する.

図 6: ストリームの流れ

5.4.1 libjpeg の調査
今回，実装に先だって，MMX 命令対応の libjpeg である MMX Jpeg 0.1.2[11] の圧縮速度の調査を行った．

中継サーバ

なお，この libjpeg は pgcc(Pentium GNU C Compiler)
2.95.2[12]JPEG
ストリームを用いて，-O6 -march=pentiumpro オプショ

受信 →JPEG解凍 →

プロセス1

加工

RGB
ストリーム

JPEG圧縮 →

送信

プロセス2

JPEG
ストリーム

ンを付けてコンパイルした．調査方法はバッファに格納された 320x240 の RGB 形式で表された画像を圧縮し，結図 7: ストリームの流れ果が別のバッファに格納されるまでの時間を 1000 回測定し，その平均を求めた．その結果を表 2 に示す．

6 実験と評価

表 2: jpeg 圧縮及び解凍に要する時間

6.1 実験環境
実験では，図 8 に示すようにストリームを送信する．な

スペック

jpeg

圧縮jpeg

解凍

お，クライアントはどのエリアの放送も受信できる．京都

PentiumIII 750MHz Dual

17932 usec

7864 usecのエリアでは，VOD のストリームをマルチキャスト送信

Athlon 850MHz

18591 usec

7852 usecする．東京のエリアでは，二種類の放送をする．一つは，PentiumII 333MHz

33289 usec

18185 usec

東京の映像と音声を一つの放送としたものである．もう一つは，シド ニーの放送を受信して動画を加工して，音声を別のものに差し替えて中継したものである．シド ニーのエ

秒間 30 フレームの圧縮を達成するためには，1 フレーム

リアではシド ニーの映像と音声のスト リームを一つの放あたり 33msec 以内で処理する必要があるが，高速な CPU送とする．システム上の複数の送信者に帯域を違反させてを用いれば，リアルタイムでキャプチャして放送することも，帯域を守って送信しているストリームは影響を受けなが可能である．さらに，PentiumIII 750MHz DUAL のマいことも検証する．

シンでは，圧縮プロセスと解凍プロセスを同時に実行して6.2 実装したシステムの検証と評価も，それぞれ別に行ったときとほぼ同じ時間で終了した．
これにより解凍と圧縮を別プロセスとして同一ホストで実設計したものが有効に機能するかの実験である．まず行し，放送を受信しそれを加工して再放送することもでき放送局側で，コントローラを使ってビデオサーバ及びオーるようになることが確認された．

ディオサーバを起動し，ランデブーポイントを制御して放送を始められることを確認する．

5.4.2 中継サーバの設計

次に，受信者側で，ウェブの ibcast URL のアンカーを

今回は図 6 のように受信したスト リームにテロップをクリックすると受信アプリケーションが起動し，放送の受挿入して再放送するサーバを設計する．実装次第で，野球信が始まることを確認する．の二元中継のような二つのストリームの合成もできるであ

さらに，放送の中継が機能するかどうかも確認する．図ろう．

8

ハード ウェアは PentiumIII 750MHz DUAL のマシンのように，東京のビデオサーバがシド ニーからの放送を受信し，これにテロップを挿入して再放送できることを確を用いる．プロセスは図 7 のように二つ用いることとする．

認する．

一つは放送の受信及びデコード 及びテロップの挿入を

この結果，設計したものが，有効に機能することが確認行う．もう一つは，エンコード 及び送信を行う．テロップできた．

挿入部をデコード のプロセスに含めたのは，エンコード よ6.3 ユニキャスト の放送との比較実験

りデコード の方が処理時間が短いからである．二つのプロセスは，ソケットペアを用いてストリームの受け渡しをマルチキャストの放送はユニキャストの放送に比べて行う．

サーバに負荷がかからず，ネットワークの帯域も消費しな5を設計したことにより，柔軟な形態で放送することが可能
シドニー京都AS
VS

受信者側では，ブラウザで番組表を開き，受信したい放RVP

送の ibcast URI をクリックすれば，受信アプ リケーショ

C

ASC
VOD

映像のみ中継東京
VSンが適切なパラメータで起動し，放送を受信することがでCきた．したがって，設計したものは有効に機能した．
実験により，今回の設計した方法でインターネット放送

CRVP

CRVP

Cを行えば，数多くの受信者に対する高品質な放送が，簡単ASな放送設備でできることが実証された．
今後の課題として，まず本研究で実装できなかった，放送サーバをコントロールするための GUI の実装があげられる．個人が容易に放送を行うためには，使いやすいGUI が必須である．次に，受信アプ リケーションの精錬があげられる．そして，現在広く使われている OS である Windows に対応することがあげられる．これらのことを実現できたとき，このシステムが広く使われると確信する．

CVS

VOD

VODサーバAS

オーディオサーバ

RVP

ランデブーポイント

VS

ビデオサーバ

Cとなった．

Cクライアント

ユニキャストストリーム
マルチキャストストリーム

参考文献

図 8: ネットワークの概要[1]

K. Fujikawa and K. Ikeda.
(rim).

[2]いことを実証するための比較実験を行った．

Rsvp integrated multicast

INET'99, June 1999.

K. Fujikawa, M. Ohta, and K. Ikeda.

Integration ofmulticast routing and qos routing. Proc. of INET2000,

この結果，従来のユニキャストの方式に比べて，マルチJuly 2000.

キャストの方式の方が優れていることが確認できた．
[3]

6.4 資源予約の有効性の検証実験

K. Fujikawa, Y. Fujimoto, K. Ikeda, N. Matsufuru, andM. Ohata.

Comfortable service:

A new type of inte-

情報処理学会研究報告 2000-DPS-98, pages pp.25{30, June

grated services based on policed priority queuing.

資源予約された放送は他のフローの影響を受けないことを，資源予約されていない放送と比較して検証する実験2000.

である．受信ホストを 2 台，放送局を 1 組．また大量のス[4]トリームを発生させる VOD サーバを 15 台用意する．放送局はマルチキャストで放送を始め，1 台の受信ホストは

藤川 賢治, 藤本 義人, 太田 昌孝, 岡部 寿男, and 池田克夫. Policed priority queuing (ppq) を用いたフローごとの qos 保証のための comfortable service (cs) の提案.
DICOMO2001, June 2001.

資源予約をして，もう 1 台のホストは資源予約をせずに放送を受信する．そして，両方の受信ホスト宛に，VOD

[5]

R.

Braden,S. Jamin.

サーバから大量の放送を送信する．

L.

Zhang,

S.

Berson,sion 1 functional speci cation.

この結果，資源予約なしで放送を受信した場合，VOD[6]

サーバからの大量のストリームが送信されると，多数のコ

S.

Herzog,andResource reservation protocol (rsvp) { ver-RFC2205, 1997.

D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, andマ落ちや音飛びが発生した．一方資源予約をして放送を受L. Wei.

信した場合は，VOD サーバからの大量のストリームが送Protocol independent multicast-sparse mode

(pim-sm): Protocol speci cation.

信されても，同じ品質で受信することができた．したがっ[7]て，放送のストリームが他のフローの影響を受けないこと

RFC2362, 1998.

M. Handley and V. Jacobson. Sdp: Session description
protocol [rfc 2327], April 1998.

が確認できた．

[8]

The FreeBSD Pro ject.

(freebsd).

htp://www.freebsd.org.

7 おわりに[9]

本研究では，柔軟な放送に対応できる高品質で数多くのSam

Lantinga.

Simpledirectmedia

layer(sdl).

http://libsdl.org/.

受信者に対応できるインターネット放送システムを QoS[10]

マルチキャストルータを用いて設計し，実装した．このシIndependent JPEG Group.

(lib jpeg).

http://www.ijg.org/.

ステムを用いれば一般の PC で放送ができるため，個人[11]が簡単に放送できるようになる．そして，マルチキャスト

The MJPEG/Linux square.

(mmxjpeg).

http://sourceforge.net/projects/mjpeg/.と QoS 保証を前提としているので，高品質な放送を安定[12]して送信することができる．さらに，放送を受信しこれをPentium Compiler Group.

http://www.goof.com/pcg/.

解凍し，加工を加え，再び圧縮して再放送する中継サーバ

6(pgcc).