情報通信インフラの構築に向けてー ネットワーク上の情報共有技術 ー2004年5月27日
川原崎 雅敏インターネットの進化？？インターネット

高速インターネット① Internet for All② 高度な情報インフラ•情報への接続•複数機器間の情報共有① Internet for PC② 高速化と品質向上
初期のインターネット① Internet for PC② ベストエフォート

1990

時系列
2000

2010

Agenda1. 情報へのアクセス
naming & resolution
2. 情報の利用
context-aware service
seamless service
3. 情報の配信
QoS routing

情報へのアクセス
情報を取り出すためにつなぐとは、基本的に何をすることか？
 接続の仕方の質は何で決まる？ 尺度は？
アクセス名称（１）アクセス時に人間が意識する

意味的名称

コンテンツに関わるキーワード

論理名称

情報や人の名前しない

物理アドレスまたはそれに準ずるもの

物理的な経路を接続するためのアドレスアクセス名称（２）

意味的名称：
コンテンツに直接関わる→同義/類似などの意味的分類（例：同義の外国語名称にもアクセス⇒意味的名称の翻訳サービス）
エッフェル塔、パリ、ヨーロッパ、
フランス、名所、建物、建築、・・・

論理的名称：
１つの対象に複数の名称を許容⇒ニックネームサービス（名称毎にセキュリティレベル/アクセスレベルを変える）
アクセス元毎にアクセス先名称を変える⇒プライベートネームサービス■意味的名称および論理的名称は原則的にユーザに開放（ユーザが自由に名称変更する）■意味的名称および論理的名称の階層化

長嶋、ミスター、３番、・・・

「何と通信する」ネットワーク
ロケーションフリーな情報提供サイト
 複数の情報提供点からの情報を1つのサービスとするサービス


「どこと通信」から「何と通信」への要求の変化
この変革を実現するネットワーク「何と通信」ネットワークの構成要素
 アクセス名称の多様化
 名称空間のユーザ解放 「どこに」ではなく「何と」に基づく料金体系

アドレス・名前解決■接続相手や情報（コンテンツ）の識別「名前」またはサービスアドレス

電話サービス ⇒ 電話番号

電子メール ⇒ メールアドレス
WWW ⇒ URL（Uniform Resource Locator)■「名前」からネットワーク内装置が理解できるアドレスや識別子（ルーチングアドレス）への変換「名前解決」。名前解決装置を「リゾルバ」と呼ぶ。
「名前」と「名前解決」の技術を用いることで、リソースの「名前」を記憶していれば、実際のネットワークアドレスを知ることなく、サービスを利用できる。

「名前」の構造 ⇔ ユーザから見たサービス性「名前解決」の手段と、解決後のルーチングアドレスの構造⇔ ネットワークの形成電話サービスの番号とアドレッシング■電話番号 （エリアコード＋局コード＋加入者番号）
０２９
８５９
１３４３
「ルーチングアドレスと着信先を指定する名前が一体」
1.
例）一般の電話番号
2. 「ルーチングアドレスと着信先を指定する名前が分離」
例）携帯電話番号、番号ポータビリティ
3． 「サービス識別子の導入」 ０１２０−＊＊＊＊
フリーダイヤル番号から一般電話番号に変換して接続
一般電話番号の特徴は、階層化と位置依存性
これに対して、携帯番号やフリーダイヤルは位置透過（非依存）。

インターネットの名前・名前解決









現行インターネットは、FQDN（Full Qualified Domain Name）という名前付けを利用。
slis.tsukuba.ac.jp 「ホスト名、組織名、所属機関、国」
FQDNで指定されるのは単なるネットワーク上の位置のみ。
DNSが、FQDNをIPアドレスに対応付ける。
WWWでは、リソースの名前にURL（Uniform
Resource Locator)を用いる。
URL=FQDN＋パス名＋アクセス方法
ロケーション（ノード内のリソース位置）（HTTP等のデータ転送プロトコル）

ＵＲＬ，メールアドレス
DNS

ネットワークＩＰアドレスARPURLはDNSによる名前解決を前提にしているにも拘らず、位置依存型の「名前」になっており、かつ階層的な名前空間になっている。

物理網

MACアドレス

望ましい名前・名前解決■URLの問題点

リソースが移動する、あるいはリソースを保持するノードが変更になると、名前が無効になる。

同一リソースが複数ノードに複製されると、それぞれ別々の名前が付けられ、名前から同一性が判断できない。
■名前、名前解決への要求条件

移動性（モビリティ）
リソースの移動に対応 ⇒ 位置透過な「名前」

スケール性（スケーラビリティ）
超大な名前空間に対応 ⇒ 階層化された名前空間
柔軟性（フレキシビリティ）
１つのリソースを指定すると、ある領域のリ ソース群や一定の基準を満たすリソース群を指定できる。 ⇒ 属性に基づく柔軟な「名前」

位置透過な名前： URN
位置に依存しない位置透過な「名前」として、IETF(Internet Engineering Task Force)でURN(Uniform Resource Name)を定義。
1.
2.
3.




位置に依存せず、永続的にノード／リソースの指定が可能となる名前の表記法を規定
複数の名前空間で共用されるようにURNを定義
個々の名前空間はIANA (Internet Assigned Numbers
Authority)への登録制で、名前空間ごとに名前の一意性を確保
現在、登録されている名前空間はISBN (International StandardBook Number)など10種
現時点のURNでは、「名前」からルーチングアドレスに直接変換する
例はない。名前から別の名前を解決するだけ。

URL⇒URI⇒???
XDI:
何らかの条件に応じて動的に機能するデータ共有関係、つまりDatawebを築く技術
OASIS (Organization for the
Advancement of Structured
Information Standards)

OASISで検討中
XDI
XRI Data Interchange
ネットワーク上でデータを結びつけるためのスキーマ

XRI

eXtensible Resource Identifier
物理的に異なる場所に存在する論理的同一なリソースを特定可能

URI
URL
URN

URN (Universal Resource Name)
永続性が保障された名前<URN> ::= "urn:" <NID> ":" <NSS>

URL

登録主体が管理
IANAへの登録制
例） urn:isbn:4-8399-0454-5
urn:ietf:rfc:2141

TV Anytimeのモデル
Service providers
Content Providers
Network operators■ストレッジとネットワークを利用した
放送・通信融合型のマルチメディア
コンテンツサービス

Networks

ProviderGateway

ProviderIn-home
Network

PDR

Storage◆メタデータとCRIDを利用してコンテンツの探索、配信、消費を制御
Content description Metadata： ﾀｲﾄﾙ、ｼﾞｬﾝﾙ、ｻﾏﾘｰ
Instance description Metadata： ﾛｹｰｼｮﾝ、配信ﾌﾊﾟﾗﾒｰﾀ
Consumer Metadata： ﾕｰｻﾞ嗜好、視聴履歴
Segmentation Metadata： ｾｸﾞﾒﾝﾄのﾀｲﾄﾙ、ｼﾞｬﾝﾙ、ｻﾏﾘｰ
Targeting Metadata： 年齢、性別、趣味
Right Management Metadata： 権利者、利用条件、料金

TV-Anytimeでの名前・名前解決■TV-Anytime Forum（蓄積型放送サービス）が規定する位置に依存しないコンテンツ参照子CRID://<authority>/<data>（例）CRID://company.com/foobar“company.com”という authority がCRIDを作成し，“foobar”というデータを持つ．

<authority>=<DNS name><name extension>（例）www.broadcaster.com;electronics
Locator=<transport mechanism>:<transport specific system>（例）ftp://oobar.net/mirror/def123.mov
dvb://123.5ac.100:1e4a@2002-05-03T21:00:00.00+091P2:20

TV-Anytime： コンテンツ参照子（CRID)
スターウォーズ
CRID

CRID

CRID

スターウォーズ（特別編）

コンテンツの
選択，探索

コンテンツ
の利用

入力
入力

所望の
所望の
コンテンツ
コンテンツ

コンテンツ参照
ロケータ
CRID

CRID

スターウォーズ（特別編）
CRID ５月３日放送分

アプリケーション
CRID

CRID

CRID
CRID

ﾛｹｰﾀ
ﾛｹｰﾀ

ﾛｹｰﾀ

ロケータ
ロケータ

ロケータ ロケータ
Webサーバ
日本テレビ

1.
2.

3.

コンテンツ
コンテンツ
選択
選択

ロケーション
ロケーション
リゾルブ
リゾルブ

コンテンツ
コンテンツ
取得
取得

１．

２．

３．

好みの番組の探索と選択を終え、希望する番組のCRID（Content Reference ID）を取得
CRIDから最終的なLocator（配信情報）を取得•目的の番組が複数の番組から構成されている場合には、あるCRIDに対して複数のCRIDを得た後で個々のLocatorを取得する。
あるCRIDに対して複数の取得手段が選択できる場合には、複数のLocatorが一度に得られる場合もある。
Locatorにしたがって目的のコンテンツを取得

Content Referencing
Client (PDR)

Authoritative DNS server
for domain xxxx

CRID Authority nameLR server
searchingprocess

SRV request

Host name of LR server
Host name of LR server

Conventional
hostname to IP
address request

IP address of LR server

CRID
Locationresolution
process

Locators or CRIDs

Optional associated metadata

LR server

名前解決機構の諸形態
1.

2.
3.

4.

ルーチングアドレスを名前として用い、リゾルバが不要 （例：一般の電話番号）
固定的に配置されたリゾルバによる （例：DNS)
リゾルバを用いず、リソースを有すると思われる
ノードに目的リソースの有無を問い合わせる （例：ARP)
自律的に構成されるリゾルバおよびリゾルバ間のネットワークを利用して、目的リソースの名前解決を行う （例：INS）

属性ベースの名前、名前解決
移動性とスケール性に優れたユビキタスサービスの「名前」 と、「名前」に対する効率的な名前解決機構が、RFIDの分野で検討されている。


位置透過な「名前」をつける方法として、「目的のリソースがどのようなものか」を直接表現する。 ⇒ 属性ベースの名前 (attribute-based name)
名前解決は、ONS (Object Naming Service)と呼ばれるDNSと同様のリゾルバで実現する。
（例１）INS（International Naming Service)• 属性ベースの名前を用いる。
• ネットワーク内に複数のリゾルバを用意し、各リゾルバがネットワーク内の全リソースを網羅する名前とルーチングアドレスの対応表を管理する。
（例２）CAN (Content Addressable Network), Chord• ハッシュ法を用いて名前空間を機械的に分割することで、リゾルバを用いた名
前解決を効率化する。
• P2Pによるファイル共有や分散ストレッジなどのアプリケーションで用いられる。

INSの名前構造、名前抽出
ホワイトハウスに設置された監視カメラの静止画像を指定する例
root

paris

city

service

accessibility

washington

camerapublicbuilding
capitolwhitehouse

floor

wing

1

west

room

room

chamberoval

data-typeprivateresolution

movie

picture検証

640*480

マッチング

640*800
属性ベースの「名前」
Name specifier
属性
av-pair
属性値

名前解決
Name-record•サービスの所在場所（IPアドレス）•サービスの平均負荷（メトリック）

INSの名前解決INSのリゾルバはINR (International Name Resolver)と呼ばれる。
INRの所在はブートストラップサーバ（bootstrap server）が一括管理する。
各serviceは、提供するリソースのnamespecifierとname-recordを帰属するINRへ周期的に送信して、リソースを登録する。

Bootstrap server
INRのリストを入手

service

INR

新規に参加するノード

INR
簡単な名前解決要求を出し、処理遅
延時間が最小のINRを隣接するリゾルバとする。

INR
INR
INR

最寄のリゾルバを選択する

INR

client①②

service

最適なサービスにアクセスする属性ベースの名前・名前解決のための通信プロトコル
属性ベースの名前を記述する言語： XML リソース間のメッセージ交換技術： SOAP
 ネットワーク上のリソースを探索・発見する技術： UDDI


プログラマブルAPI（XML要素）Webサービスのユーザ属性による問合せ（XML要素）XML文書

UDDIによる探索・発見
属性ベースの名前解決機構

SOAP
ネットワークのユーザ

回答
XML文書

対応表
対応表
対応表
（XML文書）（XML文書）（XML文書）

レジストリ（XML文書）

名前解決は、Webサービスと基本的に同じ構造になっている。

利用環境を意識した名前解決
複製コンテンツ・派生コンテンツがNW上に多数存在する場合において、ユーザの利用環境（端末能力、地理的位置、利用可能帯域）まで意識した最適な名前解決を行う。
コンテンツ要求

Titanic, documentary⇒CRIDa⇒（CRIDa, IMI1)⇒（CRIDa, IMI2)

TVA機構

探索・ナビゲーション
選択

PC/ADSL(26Mbps)/東京から要求
FOMA/WCDMA/大阪から要求
CRID

CRID/IMI

CRIDa

Locator

ロケーション解決

IMI1 IMI2 IMI3
MPEG-2 MPEG-4

Originインターネット等
IMI2

CRIDb

CDN

Copy

IP転送網（ISP/地域網）

Copy
IMI1

Agenda1. 情報へのアクセス
naming & resolution
2. 情報の利用
context-aware service
seamless service
3. 情報の配信
QoS routing日本のインターネットの現状

インターネット利用者数： 7,730万（H15.12)
人口比60%を突破
携帯電話によるインターネット利用者： 6,870万 （H16.2)
ブロードバンドインターネット利用者数： 1,450万 （H16.2)
ADSL： 1,090万、FTTH： 104万 （H16.2)
携帯電話契約者： 8,150万 （H16.3)
第三世代携帯電話： 1,670万 （H16.3)
このようなＩＴサービスの普及状況は単に情報通信の量的拡大にとどまらず質的変化をもたらそうとしている。

多様化するネットワーク環境■ユーザは状況に応じて複数の端末を使い分ける。

The
Internet
The
Internet
アクセスネットワーク

公共エリア
モバイルアクセス

オフィス
固定/モバイルアクセス

空港、駅, etc.
ノマディックモバイル
アクセス(NWA)家
固定/モバイルアクセス

何をしたいのか

ユーザは自分が携帯する端末に加えて、その場で利用可能な最も使いやすい端末(群)から情報を入手したい。
端末を切り替えても再接続・再設定なしに、シーム
レスにサービスを継続したい。
情報は利用する環境に応じて最適な表現手段（メディア、精細度）で入手したい。

Context-awareサービス
ユーザが意識しなくても、ネットワークがその場の状況や環境条件、ユーザの嗜好や意図を理解（context awareness）し、それに応じた最適なサービスを提供する。

Context-awarenessContext-awarenessDiscovery
Discovery

Adaptation
Adaptation- Callee- Terminal- Content- Content- Media

Resource
Resource
control
control- Bandwidth- RouteContext-awareサービスへの課題
Contextを取得する技術
 Contextを記述する技術
 Contextを管理する技術
 Contextを解釈する技術⇒ Contextに応じた優しいサービス

既存の実現技術（１）
Example 1

Presence Basic Sequence
IETF
Presence
ServerWatcherPresentity(1) SUBSCRIBE(2) NOTIFY(3) PUBLISH(4) NOTIFY•Online / Offline•Availability
通信相手の存在や状態、位置や利用環境を事前に把握し、最適な通信手段を選択する。

ＳＩＰ対応ネットワーク/サービス
現時点の相手所在地へSIPメッセージ
を差し戻す

FORK

相手がいる可能性のある複数の場所へ同時にリクエストを送る

SIPﾒｯｾｰｼﾞを処理し、端末の代理としてｾｯｼｮﾝを制御REDIRECT

ロケーション
サーバ

着端末のユーザ名から現時点の所在
地を導出

ＩＮＶＩＴＥDNSＩＮＶＩＴＥSIPプロキシ

ＩＮＶＩＴＥ/ＳＵＢＳＣＲＩＢＥ
ユーザエージェント

SIPプロキシ

ＩＮＶＩＴＥ
メディア、メッセージ

レジストラ

ユーザの位置情報をロケーション
サーバに登録REGISTER

ＡＣＫ， ＮＯＴＩＦＹ
ユーザエージェント

IETF

既存の実現技術（２）Example 2

W3C
CC/PP (Composite Capabilities/ Preference Profiles)
Content
Server(2) Query
CC/PP
Repository(1) Request
with profile(3) Adapted
Content

User
Agent

端末能力やユーザ嗜好（RDFで記述）に応じてコンテンツを変換する。

CC/PP

W3Cドキュメントより

シームレスサービス
現状： NW環境や端末を変える毎に、サービスを一旦切断 し、接続し直す。
 目標： 切断や再接続を陽に意識することなくシー
ムレスにサービスを継続する。
■端末モビリティ
ユーザの移動に合わせ、同一端末を利用しながらアクセスするNWを移動 （例： モバイルIP）■サービスモビリティ
利用目的に合わせ、通信サービスをある端末から異なる端末に移動

シームレスサービスの実現<Phase<Phase1>1>
移動対象端末の検移動対象端末の検索・発見索・発見•• 利用可能性
利用可能性•• 物理的位置
物理的位置•• 利用権
利用権
NW
が候補端末を検索
NWが候補端末を検索

し推奨。
し推奨。

•自己所有端末•公共端末<Phase<Phase2>2>
サービス状態引継ぎ
サービス状態引継ぎ（＋状況適応）（＋状況適応）•• サービス状態、中断点
サービス状態、中断点•• ネット環境、物理環境
ネット環境、物理環境•• ユーザの嗜好、目的
ユーザの嗜好、目的
NW
NWが移動先環境に合が移動先環境に合わせてコンテンツを変換
わせてコンテンツを変換

•通信継続
•視聴継続

<Phase<Phase3>3>
移動先端末でのサー
移動先端末でのサー
ビス自動再開ビス自動再開•• 移動先端末起動
移動先端末起動•• サービス移動
サービス移動NWから移動対象アプリ
NWから移動対象アプリの起動を指示し再開。
の起動を指示し再開。

シームレスハンドオーバシステム（MetaPORT）
目 的
シームレスなコンテンツ視聴サービスを実現するアーキテクチャを検討し、プロトタイプシステム（MetaPORT）を開発する。
RFIDで

入店検出

③ネットカフェのPCで続きを見る①家でテレビを見ている

PDAから、選択したPCにハンドオーバ
ピィ！
テレビからPDAにハンドオーバピィ！

②外出時、続きをPDAで見る

ネットカフェ内で利用可能な端
末を表示
PC1

PC2

PC3

PC4

コンテンツ配信高度化のフレームワーク
与えられた条件下で最適化

ポリシー

コンテンツ
コンテンツ
側の条件
側の条件

コンテキスト理解とコンテキスト理解とコンテンツ適応コンテンツ適応整合・ストリーム属性
・ファイル属性

ネットワークネットワーク側の条件
側の条件

メタデータによる条件記述

ユーザ
ユーザ
側の条件
側の条件
・端末属性 （種別、能力、状態）
・アクセス属性 （形態、契約帯域）
・ユーザ嗜好 （配信形態、品質）・SLA（Service Level Agreement)・サービスクラス・利用可能帯域

MetaPORTでの実現形態
コンテンツ
コンテンツ側の条件• コンテンツ属性（ﾀｲﾄﾙ、ｼﾞｬﾝﾙ、利用条件）• インスタンス属性（ﾛｹｰｼｮﾝ、配信ﾊﾟﾗﾒｰﾀ）

TV-Anytime
システム（TVA)

コンテキスト制御

シームレス
ハンドオーバシステム（SHS)

コンテンツ配信

メタデータによる条件記述

ユーザ側
の条件
• 端末属性（種別、能力、状態）• ネットワーク属性（ｱｸｾｽ形態、利用可能帯域）• ユーザ属性（嗜好、ﾌﾟﾛﾌｧｲﾙ）プレゼンス管理システム（TIM）

プレゼンス管理システム (PIM)
他システム■アプリケーション機能
・条件に合う端末の検索・プレゼンス変化の通知、等
アプリケーション
PAMおよび拡張API

W3C
CC/PP

IETF
ﾌﾟﾚｾﾞﾝｽ
情報■スタティック情報
・端末種別
・画面サイズ・搭載アプリケーション
・ユーザ嗜好、等■ダイナミック情報
・オンライン／オフライン状態
・利用可能帯域
W3C RDF
・位置、等

プレゼンス
管理機能

IMPPﾒｯｾｰｼﾞにより、プレゼンス情報を通知TVAシステムの拡張 （TVA)
中断点
中断点
検出機能
検出機能
ﾛｸﾞｻｰﾊﾞ
権利管理
サーバ

ハンドオーバ時の視聴中断点を検出

コンテンツ
メタデータ
サーバ

端末種別
端末種別
解決機能
解決機能

ロケーション
解決
サーバ

CRID
権利情報
メタデータ
CRID
CRID
ロケータ

コンテンツ
サーバ

検索・選択
サーバ
要求・選択

ﾒﾀﾃﾞｰﾀ
＆ﾛｹｰﾀ

ユーザ端末

ﾛｹｰﾀ

ｺﾝﾃﾝﾂ

アプリケーション
アプリケーション
制御機能
制御機能
中断点からの再生再開機能端末能力に合ったコンテンツの所
在場所を解決MetaPORTのシステムアーキテクチャ
TVAシステム （TVA)

SOAP

プレゼンス管理システム (PIM)

Ａｐｐｌｉｃａｔｉｏｎ•コンテンツ情報収集•端末属性を考慮したﾛｹｰｼｮﾝ解決•中断点検出Ａｐｐｌｉｃａｔｉｏｎ

Ｐｌａｔｆｏｒｍ

Ｐｌａｔｆｏｒｍ

RMP
ｻｰﾊﾞ

LR
ｻｰﾊﾞ

ｺﾝﾃﾝﾂ
ﾒﾀﾃﾞｰﾀｻｰﾊﾞ•端末情報収集•利用環境に整合した端末検索

Log
ｻｰﾊﾞ

UEM
ｻｰﾊﾞ

ハンドオーバ支援システム (SIM)CDN

ＴＶＡｱﾌﾟﾘｹｰｼｮﾝ
ＴＶＡｱﾌﾟﾘｹｰｼｮﾝ
制御
制御

PＩＭｱﾌﾟﾘｹｰｼｮﾝ
PＩＭｱﾌﾟﾘｹｰｼｮﾝ
制御
制御

ハンドオーバ制御
ハンドオーバ制御

IMPP（Presence
Notification)

端末ｱﾌﾟﾘｹｰｼｮﾝ制御
端末ｱﾌﾟﾘｹｰｼｮﾝ制御

HTTP
ﾋﾞﾃﾞｵ
ﾌﾟﾚｰﾔ

ｱﾌﾟﾘｹｰｼｮﾝ
制御

ﾌﾟﾚｾﾞﾝｽ
ｸﾗｲｱﾝﾄ

端末（TV,PDA,PC)

処理シーケンス（TV→PDAへのハンドオーバの場合）①①PDAよりハンドオーバ要求
PDAよりハンドオーバ要求②②プレゼンスサーバにユーザ
プレゼンスサーバにユーザ
及び端末の情報を問合せ
及び端末の情報を問合せ

ﾛｹｰｼｮﾝ
解決
サーバ⑥③③切替元TVの選択
切替元TVの選択

コンテンツ
メタデータ
サーバ

④

ﾊﾝﾄﾞｵｰﾊﾞｻﾎﾟｰﾄ
サーバ※複数TV所有の場合※複数TV所有の場合④④ログサーバに視聴中の番組ID
ログサーバに視聴中の番組ID（CRID）及び中断点を問合せ（CRID）及び中断点を問合せ

ログ
サーバ（RMPｻｰﾊﾞ） ⑤

コンテンツ
サーバ ⑦

①③

②

プレゼンス
サーバ

プレゼンス通知（随時）

ﾊﾝﾄﾞｵｰﾊﾞｻﾎﾟｰﾄｸﾗｲｱﾝﾄ⑤コンテンツメタデータサーバに⑤コンテンツメタデータサーバに
番組概要を問合せ、PDAに表示
番組概要を問合せ、PDAに表示

ストリーム配信

ハンドオーバ実行⑥ユーザのハンドオーバ実行後、⑥ユーザのハンドオーバ実行後、LRサーバに切替先PDAに適合する
LRサーバに切替先PDAに適合するコンテンツロケーションを問合せ
コンテンツロケーションを問合せ⑦PDAにロケーションに応じた⑦PDAにロケーションに応じた
ストリーム配信の実行
ストリーム配信の実行

他端末

PDA

ユーザ
ユーザ
ﾊﾝﾄﾞｵｰﾊﾞｻﾎﾟｰﾄ

TVAインフラ

端末

プレゼンスインフラパフォーマンス評価

ハンドオーバ時間は10秒以下
20%

メッセージシーケンス処理

40%

ストリームコンテンツのバッファリング

40%

ビデオプレーヤの起動

コンテンツの継続視聴サービスに供しうる性能

ネットワーク用メタデータの標準化に
向けて




コンテンツを利用する側の条件や状態、嗜好などをメタデータで記述し、ネットワークがそれらを利用してcontext-awareサービスを提供するためのAPI機構を規定する。
新しいメタデータを規定することではなく、各機関が規定しているメタデータの通信に関する機能を整理し、メタデータと通信機能の参照モデル、APIフレー
ムワークを構築する。

ネットワーク情報ディレクトリ機能■ネットワーク情報（ユーザID, ユーザ属性管理情報、
端末ID, 端末属性管理情報など）の抽出と実現- SIPを使えば、プレゼンス情報まで含む統一的なディレクトリサービスが可能になる。
端末からの
自動登録

Proxyによる網のﾌﾟﾚｾﾞﾝｽ代行登録

Proxy
NW情報
管理サーバ

ユーザによる
ﾌﾟﾚｾﾞﾝｽ直接登録

関連標準
カテゴリ

データ記述
（メタデータ）標 準
コンテンツ側

ユーザ側• ISO/IEC MPEG-7
Multimedia description
Variation description• W3C CC/PP
Terminal capability
User preference• IETF IMPP
Presence description• MPEG-7
User preference
Usage history• MPEG-21
Usage environment• TV-Anytime Forum
Content description
Instance description

API
プロトコル

Unspecified• TV Anytime Forum
Metadata transport protocol(SOAP/HTTP)• Parlay PAM API(see Table X)• IETF IMPP
Protocol for instant messaging
and presence exchangePAM-API、拡張API
カテゴリー

PAM APIs

拡張APIs

APIの概要Identity (user) andidentity presence
management•Create/delete group identity•Create/delete identity•Set/get identity attributes•Set/get identity presence, etc

Agent (terminal) andagent presence
management•Create/delete agent•Assign/un-assign agent to identity•Set/get agent attributes•Set/get agent presence, etc.

Event management•Register event•Notify application of an event, etc

Identity and identity
presence management•Get list of identities that meet specificconditions

Agent and agent
presence management•Get list of agents that meet specificconditions

Data description

Handle above data in metadata format

ITU-T Metadata Framework
AP

AP

AP

Extended API

MD-GW Application Platform

PolicyServerMetadata GW-API

Metadata Gateway

NW info.
directory

Metadata
Framework

Metadata DBs
ServerNetwork
Network

Terminal
DeviceMetadata Gateway Architecture
based on PAM-API
Metadata Gateway
AP
#1

AP
#2

APL#2
AP
#3

PAM
API Platform
DB

Metadata sharing acrossdifferent domains
DB

DB

Metadata Collection
and management

Network A (Ex.: Internet)
Availability
Management

Monitoring
terminal

Registration

User（Presentity）

Metadata
Gateway

Exchange &Integration

Metadata
Gateway

Query

User
（Watcher）

Network B(Ex. Mobile)

User

User

Metadata Gateway Functions
Metadata Gateway provides following four functions
through its open API.
1. Metadata disclosure control
2. Metadata storing and gathering
3. Metadata transform and sharing
4. Metadata distributed management

Agenda1. 情報へのアクセス
naming & resolution
2. 情報の利用
context-aware service
seamless service
3. 情報の配信
QoS routing転送制御の標準化
W3C発足▼

IETF発足
▼
1990

1985

1995

End-to End
制御ﾌﾟﾛｸﾞﾗﾑ

2000

▼
▼
▼
RTP/ SDP RTSP
RTCP▼▼
IntServ▼
MPLS
ﾈｯﾄﾜｰｸ内制御ﾌﾟﾛｸﾞﾗﾑ /RSVP DiffServ

OSI（HTTP） （FTP）（RTP）（TCP) (UDP)（HTTP） （FTP）（RTP）（TCP) (UDP)

IP layer

IP layer
LL

IP layer
LL

RouterIP layer
LL

Routerポリシーに基づくQoS制御
Condition

認証ｻｰﾊﾞ

ビジネスアワー
かつ 音声トラヒック
かつ 顧客対応部門関連

PolicyRepository

Attach ビジネスアワー-ment

ﾎﾟﾘｼｰｻｰﾊﾞ

Action List
DiffServ音声クラスで処理

曜日が月から金
時間が9:00〜18:00

音声トラヒック

プロトコルがRTP

顧客対応部門
関連

送信元か送信先が所定のIPｱﾄﾞﾚｽ

Reusablecondition

機器ﾊﾟﾗﾒｰﾀ設定
QoS制御要求/ﾎﾟﾘｼｰ判定結果

Core
Node

注１）QoS制御要求は、ｴｯｼﾞﾙｰﾀを経由してﾎﾟﾘｼｰｻｰﾊﾞに送られる。

A
注１）

Edge
Node

Core
Node
Edge
Node

B

Policy Based QoS Control(Hierarchical Model)

Policy Control

Metadata

User / Application Requirement
Translate

Application QoS Class (Rec. G.1010)

Mapping
Set-up

Network QoS Class (Rec.Y.1541/ DiffServ)P
IP network cloudEnd
SystemNetwork
Section
UNI

Netwrok
SectionEnd
SystemUNI

多様なトラヒックの制御
輻輳/異常トラヒックの多様な発生メカニズム
メタデータ
メタデータ
・ID
・ダウンロード
・輻輳後配信・ID・普通配信
・------

メタデータ

優先すべきものは何？
一様な規制でよいか？

「普通配信」のコンテンツは、トラヒックの集中していない経路を選択「ダウンロードコンテンツ」は輻輳解消後に接続

ネットワークネットワーク・ID
・位置登録
・少し待てる

メタデータ
・ID
・緊急通信
・------

メタデータ
・ID
・速達配信
・------「速達配信」のコンテンツは、最短経路かつ広帯域な経路を優先的に転送「緊急通信」のトラヒックは他を押しのけて経路を確保•「優先トラヒック」や「優先着信者」の概念の導入•輻輳時に通信を控えるメカニズム

ポリシー制御の新たな課題
エンド・エンドでのQoSの計測技術
 ネットワークの状況に応じたダイナミックな経路制御技術
 着信者の優先度に応じたトラヒックの規制制
御技術Thankyou