モバイルマルチメディア信号処理技術特集 マルチメディア

New Technology Report
モバイルマルチメディア信号処理技術特集
マルチメディア配信技術
本稿では，音楽や映像などのマルチメディア配信技術として，マルチメディアトランスポ
ート技術や配信制御技術，マルチメディアコンテンツのメタデータを記述する MPEG − 7 に
ついて触れる．マルチメディア配信は次世代移動網における主要なアプリケーションとして
期待されており，これらの諸技術がいずれも重要となる．
よしむら
たけし
かわはら
吉村
健
河原 敏朗
としろう
せきぐち
しゅんいち
関口 俊一
え と う
みのる
栄藤
稔
∏ ペイロードタイプの指定
1. まえがき
2. マルチメディア
トランスポート技術
ーネット上のさまざまなコンテンツを
ている符号化アルゴリズムを指定す
る．
携帯電話によるインターネットアク
セスが i モードにより実現し，インタ
RTP ペイロードの符号化に用いられ
2.1 リアルタイムトランスポート
E − mail や Web ブラウジングでは，
π シーケンスナンバーの付与
インターネットでは順番どおりのパ
携帯電話を介して見ることができるよ
ある程度の伝送遅延は許容できるもの
ケット伝送を保証しないため，受信者
うになってきている．現時点では E −
のパケットロスのない信頼性の高いパ
が送信順番どおりに並び替えることが
mail の送受信や Web ブラウジングが主
ケット伝送が要求される．このような
できるようにしている．
な利用形態であるが，次世代移動網に
アプリケーションに対し，再送により
より高伝送レートの無線アクセスが可
信頼性の高いパケット伝送を提供する
能になれば，これらに加えて音楽やビ
TCP（Transmission Control Protocol）
デオなどのマルチメディアコンテンツ
が用いられている．
へのアクセスも一つの主要なアプリケ
一方，マルチメディアコンテンツの
∫ タイムスタンプの付与
インターネット上で伝送遅延ゆらぎ
（ジッタ）が生じても，受信者が適切
なタイミングでマルチメディアデータ
を再生することを可能とする．
伝送には，ある程度のパケットロスは
RTP はそれ自身では単独では動作し
許容できるものの伝送遅延の少ないパ
ないプロトコルのフレームワークであ
ア配信を可能とする諸技術について紹
ケット伝送が要求される．そのため，
り，ペイロードタイプとペイロードフ
介および解説する．2 章では，インタ
このようなアプリケーションに対して
ォーマットのマッピングを決めるプロ
ーネット上で所望の品質を満たしなが
は TCP ではなく UDP（User Datagram
ファイル文書と，アプリケーションご
ら，マルチメディアコンテンツの伝送
Protocol）と RTP（Real−time Transport
とにペイロードフォーマットを記述す
を可能とするトランスポート技術につ
Protocol）[1]が一般に用いられる．
る文書によって完全に規定される．現
いて説明する．3 章では，マルチメデ
UDP は TCP のように再送による信頼
在，次世代移動網における音声・映像
ィアセッションを制御する諸技術を紹
性は提供せず，パケットを配送するの
符号化である適応マルチレート
介し，4 章ではマルチメディアコンテ
みの非常に単純なプロトコルである．
（ AMR ： Adaptive Multi Rate） や
ンツ記述用メタデータの国際標準であ
それに対し，RTP は音声や映像な
MPEG − 4 の RTP ペイロードフォーマ
る MPEG（ Moving Picture Experts
どのリアルタイム性を有するメディ
ッ ト も IETF の AVT（ Audio Video
Group）−7 を解説するとともに，その
アの伝送を目的として IETF（Internet
Transport）WG（Working Group）で規
マルチメディア配信への応用について
Engineering Task Force） の RFC
格化に向けて作業中である．
述べる．最後に 5 章において本稿のま
（Request for Comment）1889 で規定さ
また，RTP のセッション情報を伝達
れているプロトコルである．RTP の主
するためにRTCP（RTP Control Protocol）
な機能として以下の機能が挙げられ
が RTP とともに規定されている．RTP
る．
セッション参加者は定期的に RTCP パ
ーションになると思われる．
本稿では，このようなマルチメディ
とめを行う．
NTT DoCoMo テクニカル • ジャーナル Vol.8 No.4
43
ケットを送信し，各参加者固有の情報
を伝達する．加えて，RTCP の受信者
RTPメディアストリーム
QoS制御
レポートによりパケットロス数やジッ
タといった受信品質情報を伝達できる
ため，これらの情報から通信状況を把
握し，送信レート制御などのサービス
品質（QoS ： Quality of Service）制御
に活用することができる（図 1）
．IETF
ルータ
サーバ
の AVT WG では，RTCP の情報を基に
ルータ
クライアント
RTP パケットの再送や音声／映像符号
化パラメータの変更も可能とするよう
RTCP（受信者レポート）
パケットロス・
ジッタ計算
に RTCP の拡張について検討が始めら
QoS：Quality of Service（サービス品質）
RTP：Real−time Transport Protocol
RTCP：RTP Control Protocol
れている．
2.2 ロバストヘッダ圧縮
図1
RTP パケットは，UDP および IP
RTP ・ RTCP によるマルチメディアパケット伝送
（Internet Protocol）ヘッダも含めると，
その合計のヘッダ長が 40 バイトにも
達する．音声パケットの場合，1 パケ
ットあたりのペイロード長は 20 ∼ 30
バイト程度であり，RTP/UDP/IP ヘッ
ダのオーバヘッドの占める割合が非常
0
15
バージョン ヘッダ長
データグラム長
識別子
生存時間（TTL）
31
サービスタイプ
フラグ
プロトコル
ヘッダチェックサム
に大きい．特に，低速なモデム回線や
送信元アドレス
移動通信回線を介して通信を行う際に
宛先アドレス
は，このヘッダのオーバヘッドのため
効率的な通信を行うことができない．
そのため，ネットワーク資源の有効利
送信元ポート番号
宛先ポート番号
UDPデータグラム長
UDPチェックサム
V P X CC M
[2]で規定されている RTP/UDP/IP
IPヘッダ
UDPヘッダ
シーケンス番号
RTPヘッダ
同期送信元識別子
ッダ圧縮）が注目を集めている．
定したものとして，IETF の RFC2508
ペイロードタイプ
タイムスタンプ
用の観点から RTP/UDP/IP CRTP（ヘ
現在，モデムなどの低速リンクを想
フラグメントオフセット
常に一定であることが予想されるフィールド
他のフィールド値から算出されるフィールド
パケットごとに変化が予想されるフィールド
CRTP がある．CRTP は，図 2 に示すよ
うに RTP/UDP/IP ヘッダ情報の大部分
が一定もしくはその差分値が一定であ
ることを利用し，1 つ前のヘッダ情報
をもとに差分をとることで効率的なヘ
ッダ圧縮を可能としている．CRTP に
M：Marker（マーカビット）
P：Padding（パディングビット）
CC：Contributing Source Count
（寄与送信元カウント）
IP：Internet Protocol
より 40 バイトの RTP/UDP/IP ヘッダ
図2
V：Version（バージョン番号）
X：Extension（拡張ビット）
RTP：Real−time Transport Protocol
UDP：User Datagram Protocol
RTP/UDP/IPv4 ヘッダ
を 2 ∼ 4 バイトにまで圧縮することが
トロスにより送信側と受信側で同期は
伝送効率を大きく低下させることにな
しかし，CRTP はパケットロスなど
ずれが生じ，以降のパケットを正しく
る．
の伝送路誤りを想定しておらず，その
復元することができなくなる．そのた
このような状況を受けて，IETF の
まま移動通信環境へ適用することは困
め，1 つのパケットロスが受信側での
ROHC（Robust Header Compression）
難である．すなわち，CRTP では 1 つ
バースト的なパケット廃棄につなが
WG での活動など，パケットロス耐性
前の非圧縮ヘッダ情報をもとにヘッダ
り，特に移動通信環境のように誤りの
のある RTP ヘッダ圧縮方法の検討が進
圧縮を行っているため，1 つのパケッ
多い環境では，頻繁なパケットロスが
められている．ROHC WG で検討され
できる．
NTT DoCoMo テクニカル • ジャーナル Vol.8 No.4
44
New Technology Report
セッションごとに
リソース予約
R
サーバ
ルータ
ルータ
R
ルータ
R
ルータ
ルータ
R
セッション
R
クライアント
予約帯域
図3
ているヘッダ圧縮方法は，以下の特徴
IntServ による QoS 制御
規格化される予定である．
の問題点が指摘されている．
2.3 QoS 制御
各セッション単位で QoS 制御をするの
一方DiffServ [4]は，IntServのように
により，パケットロス耐性を高めて
いる．
A ある特定のフィールド値にイレ
現状のインターネットはベストエフ
ではなく，あらかじめ限定された数の
ギュラーな変更があった際に，該
ォート型のネットワークであり，スル
サービスクラスごとに QoS 制御をおこ
当フィールドの差分値そのもので
ープットや遅延，パケットロスなど
なうため，スケーラブルなネットワー
はなく，フィールド値の下位数ビ
QoS の制御は何もしていない．しか
クモデルとなっている．図 4 に
ットを複数回伝達することによ
し，スループットや遅延要求の厳しい
DiffServ における QoS 制御を示す．
り，1 つ前のパケット以外からも
マルチメディアコンテンツの伝送には
DiffServ では，DiffServ を提供するネッ
復元を可能とする．
なんらかの QoS 制御が必要となる．そ
トワークドメイン（Diffserv ドメイン）
B 圧縮前のRTP/UDP/IPヘッダか
のため，QoS を制御するネットワーク
の端に位置するエッジルータにおい
ら算出されたチェックサムを圧縮
アーキテクチャが数多く検討されてお
て，送信元ホストとのサービスレベル
ヘッダに付加し，受信側で当該チ
り，中でもIntServ（Integrated Service）
契約（SLA：Service Level Agreement）
ェックサムを用いて正しく復元で
と DiffServ（Differentiated Service）が
や各パケットのヘッダ情報などから当
きたかどうかをチェックする．
注目を集めている．
該パケットのサービスクラスを決定
C 完全なパケットロス耐性を要求
IntServ は RSVP（Resource Reser-
し ， IPv4 ヘ ッ ダ の TOS（ Type of
する場合には，受信側から送信側
vation Protocol）[3]というシグナリン
Service）フィールドまたはIPv6ヘッダ
へ ACK（Acknowledgment）を返
グプロトコルを用いてセッションごと
の Traffic Class フィールド（これらを
送し，送信側では ACK 対象のパ
にバッファや帯域などのネットワーク
DS フィールドという）にサービスク
ケットから復元を可能とするだけ
資源を予約し，この予約資源により所
ラスをマークする．DS ドメイン内で
の情報を圧縮ヘッダに付加し，送
望の QoS を満足するネットワークモデ
は同一のサービスクラスのセッショ
信する．
ルである（図 3）
．IntServ により End−
ンは集約され，サービスクラスごと
これらに加え，送受信局間で同期は
to −End の遅延を保証する Guaranteed
に異なる転送処理（PHB ： Per Hop
ずれが生じた際でも同期回復後に逆向
Service などの提供が可能となるもの
Behavior）が適用される．
きにヘッダ復元をすることでパケット
の，RSVP のシグナリングトラヒック
これによりサービスクラス単位で異
ロス数を低減する手法をドコモから
が多いことや各ルータですべてのセッ
なる QoS 制御を実現することができ
ROHC WG へ提案し，本提案も含めて
ション状態を管理する必要があるなど
る．現在，IETF の DiffServ WG におい
NTT DoCoMo テクニカル • ジャーナル Vol.8 No.4
45
SLAやヘッダ情報から
サービスクラスを決定
DSフィールドをマーキング
DSドメイン
サーバ
エッジルータ
エッジルータ
DSフィールドにした
がってパケット転送
コアルータ
エッジルータ
エッジルータ
セッション
SLA：Service Level Agreement
クライアント
図4
表1
DiffServ による QoS 制御
するクライアントから制御するプロト
RTSP メソッド一覧
コルである．RTSPクライアントはメソ
説 明
メソッド
ッドを記述したリクエストメッセージ
SETUP
リソース確保，セッション開始
PLAY
再生開始
PAUSE
一時停止
スメッセージを返送するとともにメソ
TEARDOWN
リソース解放，セッション終了
ッドに対応する処理を行う．RFC2326
RECORD
記録開始
で規定されているメソッドを表 1 に示
DESCRIBE
デスクリプション取得
す．これらのメソッドに加えて，再生
ANNOUNCE
デスクリプション更新（セッション中のメディア追加など）
時間や再生速度などをメッセージヘッ
OPTIONS
使用可能なオプション問合せ
REDIRECTION
他サーバ接続指示（負荷分散，コンテンツ移動など）
GET_PARAMETER
パラメータの取得
SET_PARAMETER
パラメータの設定
をサーバへ送信し，サーバはレスポン
ダで記述することにより，さらに詳細
な指示をすることができる．
図 5 に RTSP のシーケンス例を示す．
クライアントはDESCRIBEメソッドを
含むリクエストメッセージを送信する
て，低遅延・低ジッタ・低パケットロ
テンツの視聴の場合，ファイルのダウ
と，サーバは対象となるメディアのセ
スでのパケット伝送を提供する EF
ンロードとは異なり，途中からの再生
ッション記述を SDP（Session
（Expedite Forwarding）クラスや，4 つ
や一時停止，さらには早送りやスロー
Description Protocol）[6]などを用いて
の異なる優先度クラスと各優先度クラ
再生などユーザからのさまざまなリク
返送する．そして，クライアントが
スごとに 3 つの廃棄クラスを有する AF
エストをリアルタイムに処理すること
SETUP メッセージを送信することに
が望まれる．
より，サーバのリソースが確保され，
（Assured Forwarding）クラスが規定さ
れている．
3. マルチメディア
配信制御技術
3.1 セッション制御
音楽や映像などマルチメディアコン
そのようなマルチメディアセッショ
同時にセッションが開始する．続いて
ンの制御を可能とするプロトコルとし
PLAY メッセージによりメディアデー
て RTSP（ Real Time Streaming
タの伝送が開始され，PAUSE メッセ
Protocol）[5]が IETF の RFC2326 で規
ージによりメディアデータ伝送が中断
定されている．
される．最後に，TEARDOWN メッセ
RTSP は，サーバからのマルチメデ
ィアコンテンツの伝送を，遠隔に位置
NTT DoCoMo テクニカル • ジャーナル Vol.8 No.4
46
ージによりサーバのリソースが解放さ
れ，セッションが終了する．
New Technology Report
も注目されている．SDP は 3.1 節で述
クライアント
べた RTSP の中で送受信間でのメディ
サーバ
ア再生能力の交換に用いられるほか，
DESCRIBE
SMIL の次期バージョンの中でメディ
description
デスクリプションの取得
SETUP
ア記述言語の一部として統合される動
リソース確保，セッション開始
きもある．
再生開始
3.3 ファイルフォーマット
PLAY
RTP
マルチメディア配信では，マルチメ
RTP
ディアコンテンツをサーバにファイル
RTCP
として蓄積しておき，それをユーザの
PAUSE
要求に応じて伝送するという手順とな
一時停止
る．したがって，サーバに蓄積するフ
TEARDOWN
ァイルのフォーマットも，伝送プロト
リソース解放，セッション終了
コルと同様に規定される必要がある．
マルチメディアコンテンツのパケット
リクエスト
伝送のプロトコルは，2 章で述べたよ
レスポンス
うに伝送目的に特化したプロトコルを
RTP：Real−time Transport Protocol
用い，ビデオ，オーディオなどの情報
図5
が同期のための情報が付加されて独立
RTSP シーケンス例
にパケット化されて伝送されるのが一
3.2 メディア記述
マルチメディアの配信はインターネ
すでに実用化されている SMIL1.0 勧
告に続いて，次バージョン（SMIL2.0）
ット上の HTML（Hyper Text Markup
では XHTML との統合やモバイル用サ
Language）コンテンツをきっかけとし
ブセットなどの検討が進められてい
て普及してきた．今後は，オーディオ
る．
般的である．このため，サーバに蓄積
するファイルフォーマットには
A マルチメディアコンテンツの同
期情報保持
B 伝送プロトコルの規定する形式
ビジュアルを含むあらゆるメディアを
一方，ISO（International Organization
統合してプレゼンテーションを行うた
for Standardization）/MPEG でも，
めのメディア記述言語の重要性が高ま
MPEG−4 において，メディアオブジェ
重化（単独のファイルでの複数メ
っている．インターネットにおけるメ
クトのプレゼンテーション記述として
ディアコンテンツの保持）
ディア記述言語は主として W3C
BIFS（Binary Format for Scene）が規
（World Wide Web Consortium）にて策
格化されている[9]．これは，VRML
ISO/MPEGでは，このような要求を
定されており，XML（Extensible
（Virtual Reality Modeling Language）を
満たすファイルフォーマットの標準と
Markup Language）[7]をベースとして
ベースとしており，シーン空間中にお
して，MPEG−4 ファイルフォーマット
柔軟かつ拡張性の高い言語仕様へ進化
けるオブジェクトの時空間配置をバイ
（MP4 File Format）をMPEG−4システ
しつつある．HTML は XML ベースの
ナリ表現する．ユーザインタラクショ
ムバージョン 2 で規定している．本フ
XHTML へ置き換えられ，HTML には
ンを取り入れたマルチメディアプレゼ
ォーマットは，上記要求条件のうち特
もともと備わっていなかったメディア
ンテーションが特徴である．BIFS を
にB）を重視した構成となっており，
プレゼンテーション機能を他の言語か
XML 表記するとともに SMIL のコンポ
メディアデータは‘mdat’と呼ばれる
ら補完して利用できるようになる．マ
ーネントなどと統合したテキスト記述
領域にフリーフォーマットで格納，メ
ルチメディアという観点から重要なの
フォーマットの検討も現在 MPEG で
ディアデータ間の時間間隔，メディア
は SMIL（Synchronized Multimedia
進められている．4 章に述べるMPEG−
データサイズ，サンプル数，およびフ
Integration Language）[8]であり，コ
7 も XML 表記が基本であり，上記のよ
ァイル先頭からのオフセットなどの情
ンテンツのメディア間同期の規定やコ
うな XML ベースのメディア記述言語
報は，
‘moov’と呼ばれるヘッダ領域
ンテンツ視聴環境に応じて選択可能な
と統合して用いられる可能性がある．
に格納される．
コンテンツ選択肢記述などの機能を備
このほか，メディアの送受信能力の
この他に同様の目的をもったデファ
ネゴシエーション情報として SDP[6]
クトの規格としては，ASF（Advanced
える．
へのパケット化の容易性
C マルチメディアコンテンツの多
が必要となる．
NTT DoCoMo テクニカル • ジャーナル Vol.8 No.4
47
Streaming Format, Microsoft 社 ），
QuickTime（Apple社）などがある．
4. MPEG−7
4.1 概要
具体的に標準化される項目を図 6 に
（頭出し）を効率化したり，ユーザの
示す．MPEG − 7 では，メタデータを
好みや視聴環境（端末性能やネットワ
XML 文書としてインスタンス化する
ーク QoS など）に応じてコンテンツの
ことを基本としており，各メタデータ
見せ方をカスタマイズするなどの用途
のフォーマット（またはシンタック
が考えられている．
ス）を定義する言語として DDL
また，D や DS を実際に運用する場
ISO/MPEG では，MPEG −4 標準化
（Description Definition Language）を標
合にシステムとして必要な要素は
に引き続き，MPEG−7 [10]の標準化活
準の一部として規格化する．DDL は
Systems パートとして規格化される．
動を行っている．MPEG−7 では，従来
W3C で標準化作業中の XML スキーマ
たとえば，D/DS の伝送効率を向上す
の MPEG シリーズのようなメディア
をベースとする．
るためのバイナリ表現，アクセスユニ
ットなどの単位で D/DS を伝送するた
の符号化方式から離れ，マルチメディ
また，メタデータの種別として D
アコンテンツへのアクセス（検索，フ
（ D e s c r i p t o r ）， D S （ D e s c r i p t i o n
ィルタリング，ブラウジング）を効率
Scheme）を標準化する．D は主として
化する目的に使用されるメタデータフ
信号レベルで捉えられるメディアの特
ォーマットの標準化を行っている．主
徴（feature）を記述するものであり，
なマイルストーンとしては，2001 年 3
DS は種々の D または DS を組み合わせ
に渡る．詳細な D/DS の定義は文献
月にFCD（最終委員会草案）を発行し
ることによってメディアの持つ時空間
[10]などに譲るが，MPEG−7 の実用化
技術仕様を凍結する．
的構造（structure）を記述しようとす
にあたって技術的なポイントとなるの
めの規定などがこれに該当する．
4.2 主な技術要素
D/DS の記述対象範囲は非常に多岐
標準化完了は 2001 年 9 月を予定して
るものである．D の事例としては画像
は D/DS 記述の獲得技術と，実際のア
いる．MPEG−7で標準化されたメタデ
の色ヒストグラム，DS の事例として
プリケーションにおける D/DS の利用
ータをコンテンツに関連付けることに
はビデオプログラムの構造記述（シー
技術である．これらはいずれも標準化
より，さまざまなプラットフォームに
ン，ショットなどの定義）などが挙げ
対象外であるため，実装に依存する．
分散配置されるコンテンツへのアクセ
られる．一般に，D は画像検索や類似
D/DS の獲得については膨大な情報量
スを標準的な手順に従って実行可能と
コンテンツの分類などへの利用が想定
のコンテンツに対してメタデータを付
なり，コンテンツの利用価値を高める
されている．DS は長時間のコンテン
与するためにメディア特徴や構造など
ことが可能となる．
ツに対して必要な部分へのアクセス
の自動抽出処理が必要となる．たとえ
DS
DDL
D
MPEG−7
データ生成
入力メディア
MPEG−7
データ
パーサ
出力メディア
検索，ブラウズ，フィルタリング
アプリケーション
DDL：Description Difinition Language
MPEG：Moving Picture Experts Group
図6
MPEG − 7 標準化範囲
NTT DoCoMo テクニカル • ジャーナル Vol.8 No.4
48
D：Descriptor
DB：Data Base
DS：Description Scheme
MPEG−7データ伝送システム
MPEG−7
データ
メディアデータ
MPEG−7
メディア
DB
New Technology Report
MPEG−7
要約
コンテンツ
MPEG−7サマリー生成
ストリーミング
メディア
？
位置情報サービス
1．要約コンテンツ配信
モバイル網
ユーザ記述
（位置情報，プレファレンス）
ユーザインタラクション
インターネット
2．リッチコンテンツ
ストリーミング
MPEG：Moving Picture Experts Group
図7
MPEG − 7 のモバイルマルチメディア配信応用事例
ば映像の構造を抽出するために映像中
信することによってユーザにコンテン
ィアトランスポート技術として，リア
のキーフレームを自動検出する[11]な
ツの概要を伝達する．今後は移動携帯
ルタイムメディアの伝送を目的とした
どの処理が必要である．また，得られ
端末のサービスとして位置情報の活用
RTP やヘッダのオーバヘッドを削減す
た D/DS を有効に活用するアプリケー
が期待されており，本システムにおい
るロバストヘッダ圧縮，さらには
ション・システムの開発も重要とな
ても端末の位置情報に応じて適切なコ
DiffServ などの QoS 制御技術について
る．画像検索システムにおいては，シ
ンテンツをプッシュするなどの応用が
解説した．また，マルチメディア配信
ステムの要求条件に合致する検索結果
考えられる．ユーザはあらかじめ端末
制御技術として，遠隔からのセッショ
を導くための D/DS マッチング処理ア
に入力済みのユーザプレファレンスと
ン制御を可能にする RTSP や，メディ
ルゴリズムが必要となる．また，1 ソ
要約コンテンツが提供するリッチコン
アプレゼンテーション機能を提供する
ース・マルチユース環境の実現におい
テンツの MPEG−7 記述とに基づいて，
SMIL，サーバに蓄積するためのファ
ても MPEG−7 は重要な役割を果たす．
ユーザの好みにカスタマイズされたコ
イルフォーマットなどを紹介した．最
付加された MPEG − 7 記述をヒントに
ンテンツの部分視聴が行えるようにな
後に，メタデータフォーマットを規定
して，コンテンツをさまざまな異種イ
る．このような段階的なマルチメディ
する MPEG − 7 の概要と標準化動向に
ンフラへ自動的に適応化して配送する
アコンテンツの提供手段が与えられれ
ついて説明するとともに，マルチメデ
技術などが重要となる．
ば，ユーザもコンテンツプロバイダも
ィア配信への応用について述べた．
4.3 マルチメディア配信への応用
MPEG−7 のモバイル活用としては，
端末のメディア表示・再生能力，ネッ
必要な情報を必要に応じて提供・収集
モバイル環境においてマルチメディ
することができ，モバイルネットワー
ア配信を実現するためには，いずれも
クにおけるマルチメディア配信の促進
重要な技術であり，今後の動向が注目
が期待される．
される．
トワーク資源の制約の中でマルチメデ
ィアコンテンツを効率良く配信するサ
5. あとがき
文 献
[1] H.Schulzrinne, S.Casner, R.Frederick, and
ービスへの応用が考えられる．図 7 に
V.Jacobson: RTP: A Transport Protocol for
具体的な活用事例を示す．本システム
本稿ではマルチメディア配信に関わ
では，MPEG−7 メタデータを用いてマ
るトランスポート技術や制御技術，そ
ルチメディアコンテンツの要約を生成
して MPEG − 7 を紹介し，標準化動向
IP/UDP/RTP headers for low-speed serial
し，要約コンテンツだけをプッシュ配
についても簡単に触れた．マルチメデ
links, RFC2508, Feb.1999.
Real-Time Applications, RFC1889, Jan.1996.
[2] S.Casner and V.Jacobson: Compressing
NTT DoCoMo テクニカル • ジャーナル Vol.8 No.4
49
20001006).
[3] R.Braden, L.Zhang, S.Berson, S.Herzog,
and S.Jamin: Resource ReSerVation
[8] Synchronized Multimedia Integration
Language (SMIL) 1.0 Specification, W3C
Protocol (RSVP), RFC2205, Sep.1997.
Recommendation 15 June 1998 (http://
[4] S.Blake, D.Black, M.Carlson, E.Davies,
www.w3.org/TR/REC-smil/).
Z.Wang, and W.Weiss: An Architecture for
Differentiated Services, RFC2475, Dec.1998.
[9] Information technology − Coding of audio-
[5] H.Schulzrinne, A.Rao, and R.Lanphier: Real
visual objects − Part 1: Systems, ISO/IEC
14491-1.
Time Streaming Protocol, RFC2326,
[10] Introduction to MPEG-7, ISO/IEC
Apr.1998.
JTC1/SC29/WG11/N3545, July, 2000.
[6] M.Handley and V.Jacobson: SDP: Session
[11] R.Brunelli et.al,“ A Survey on the
Description Protocol, RFC2327, Apr.1998.
[7] Extensible Markup Language (XML) 1.0,
Automatic Indexing of Video Data” ,
W3C Recommendation, 6 Oct.2000
Journal of Visual Communication and
(http://www.w3.org/TR/2000/REC-xml-
Image Represenation 10, 78-112, 1999.
用語一覧
ACK ： Acknowledgment
AF ：Assured Forwarding
AMR ：Adaptive Multi Rate（適応マルチレート）
ASF ：Advanced Streaming Format
AVT ： Audio Video Transport
BIFS ：Binary Format of Scence
CC ： Contributing Source Count（寄与送信元
カウント）
CRTP ：ヘッダ圧縮
DDL： Description Difinition Language
DiffServ ：Differentiated Service（優先度処理）
EF ：Expedite Forwarding
FCD ：最終委員会草案
HTML ：Hyper Text Markup Language
IETF ： Internet Engineering Task Force
IntServ ：Integrated Service
IP ：Internet Protocol
ISO ： International Organization for Standardization
（国際標準化機構）
MPEG ： Moving Picture Experts Group
PHB ：Pre Hop Behavior（転送処理）
QoS ：Quality of Service（サービス品質）
RFC ： Request for Comment
ROHC ：Robust Header Compression
RSVP ： Resource Reservation Protocol（帯域保
証）
RTCP ：RTP Control Protocol
RTP ：Real−time Transport Protocol
RTSP ：Real−Time Streaming Protocol
SDP ： Session Description Protocol
SLA ： Service Level Agreement
SMIL ： Synchronized Multimedia Integration
Language
TCP ： Transmision Control Protocol
TOS ：Type of Service
UDP ： User Datagram Protocol
VRML ：Virtual Reality Modeling Language
W3C ：World Wide Web Consortium
WG ：Working Group
XML ：Extensible Markup Language
NTT DoCoMo テクニカル • ジャーナル Vol.8 No.4
50