ユビキタス情報家電ネットワーク委員会メンバー

(1)

(2)

ユビキタス情報家電ネットワーク委員会メンバー

委員長阪田　史郎千葉大学　大学院自然科学研究科

委員徳力　基彦アリエル・ネットワーク(株)　プロダクト･マネジメント室委員江守　拓実 (株)アルファシステムズ　経営企画本部

委員福永　茂沖電気工業(株)　研究開発本部

委員片岡　淳東芝ソリューション(株)　SI技術開発センター委員菅野　忠寛東芝ソリューション(株)　SI技術開発センター委員田島　彰二日本電気(株)

委員安東　宣善 (株)日立製作所　システム開発研究所委員神牧　秀樹 (株)日立製作所　中央研究所委員松本誠一郎エコーネットコンソーシアム

委員五十嵐達治富士通(株)　プロダクトビジネス企画本部委員奥瀬　俊哉 (株)フラクタリスト　Nomadic Node事業部委員佐藤　大介 (株)フラクタリスト　Nomadic Node事業部委員佐野　勝大マイクロソフト(株)　戦略技術室

委員冨田　克彦松下電器産業(株)　eネット事業本部委員足立　利史松下電器産業(株)　eネット事業本部委員稲坂　朋義三菱電機(株)　情報技術総合研究所オブザーバ原　誠一郎 (株)アルファシステムズ　経営企画本部オブザーバ成田　隆保エコーネットコンソーシアム

オブザーバ齊藤　　允 NTTコミュニケーションズ(株)　先端IPアーキテクチャセンタオブザーバ加藤　潤一 (有)グランテック

オブザーバ中本　滋之シスコシステムズ(株)　アライアンス＆テクノロジーオブザーバ韓　　鳳永 (株)システム・ウェアハウス

オブザーバ蓮池　裕之 (株)システム・ウェアハウスオブザーバ林　　靖彦 (株)システム・ウェアハウス

オブザーバ齋籐　光正ソニー(株)　ホームエレクトロニクスネットワークカンパニー

オブザーバ島田　博也日鉄日立システムエンジニアリング(株)　プロダクトソリューション事業部オブザーバ屋島　新平フリービット(株)　事業開発本部

執筆協力者田中　敏明松下電工(株)　情報機器事業本部執筆協力者森田　淳士三菱電機(株)　神戸製作所

事務局神原　顕文 (財)情報処理相互運用技術協会　技術部事務局小島　富彦 (財)情報処理相互運用技術協会　技術部事務局田中　省三 (財)情報処理相互運用技術協会　技術部事務局横山　昌典 (財)情報処理相互運用技術協会　技術部事務局香取　良和 (財)情報処理相互運用技術協会　技術部

(3)

第１章報告書概要

(7)

第 1 章報告書概要

本報告書は、財団法人情報処理相互運用技術協会（INTAP：Interoperability Technology Association for Information Processing, Japan）における2005年度の活動の一環として、「ユビキタス情報家電ネットワーク」委員会において調査研究を行った結果をまとめたものである。INTAPでは、2004年度に「情報家電システムの相互接続性・

運用性に関する調査」委員会の活動を行い、報告書を作成した^[1]。その中で、特に宅外

－宅内間の通信（宅外のサーバや携帯端末等から宅内の情報家電機器を制御したり、遠隔の家庭の情報家電機器間で通信したりする局面におけるネットワーク）における技術やビジネスモデルに関する課題を、種々の観点から分析した。本委員会では、2004度の検討を踏まえ、技術面、ビジネスモデルの面からさらなる詳細な調査研究を行った。その結果、本報告では、技術の詳細な記述に加えて課題の具体化、さらに課題に対する取組み、方策の提示を試みている。

第2章では、文献^[1]で報告された情報家電の利用におけるユーザニーズの分析結果について述べる。

第3章では、本報告書での検討に当たって参照モデルとなるネットワークの構成を示す。

第4章では、宅内ネットワークの技術動向として、宅内ネットワークのミドルウェアとして今後有力になると考えられる IP ネットワークをベースとする DLNA/UPnP、

Javaをベースとする OSGi、くらし家電のネットワークとして機能する ECHONET、

センサネットワークとして家庭での利用が想定されるZigBee、さらにこれらのネットワークに関して、ECHONET－UPnP 間、DLNA/UPnP－ZigBee 間の連携方式について述べる。

第5章では、宅内－宅外間のネットワーク連携の技術に関して、NAT越え、セキュリティ、モビリティ制御、ユーザ・情報家電機器の認証方式、現在までに提案されているシステム構成例を示す。

第6章では、ビジネス、コンテンツの扱い、標準化の視点から今後解決すべき課題について述べる。

第 7章では、ビジネスモデルに関して、コモンキャリア（通信事業者）、ISP／ASP、

情報家電機器ベンダ、ソフトウェア開発会社、コンテンツプロバイダなどのユビキタス情報家電ネットワークのビジネスに関わるプレイヤの立場から考察し、バリューチェーン成立に向けた方策を探る。

第8章では、情報家電ネットワークに関する各国の主要企業の最新の取組みについて述べる。

参考文献

[1] 経済産業省、平成 16 年度先導的分野戦略的情報化推進事業情報家電の普及に関わる状況調査と情報提供の基盤整備報告書

(8)

第２章ニーズ動向

(9)

第 2 章ニーズ動向

2004年度の委員会において、各委員から提出されたニーズの優先度を分析した結果、

ニーズの強い順は 1. 防犯・防災 2. 医療・介護・健康

3. 遠隔機器修理・メンテナンス 4. エンタテインメント

5. 家事支援

6. 在宅業務

7. 教育・学習・自己啓発 8. ショッピング

9. 家族や友達とのコミュニケーション 10. 環境・省エネ制御

であることが判明した。

1. 防犯・防災はいつの調査においても常に最上位である。その後の、2. 医療・介護・

健康、3. 遠隔機器修理・メンテナンス、4. エンタテインメントと、それ以下（具体的なサービスが必ずしもイメージされていない面もある）とは大きな差があり、結局、1. 防犯・防災、2. 医療・介護・健康、3. 遠隔機器修理・メンテナンス、4. エンタテインメントが重要なニーズ、ということが結論づけられた。。

また、4. エンタテインメントについては、今後遠く離れた家庭どうしで通信を行うIP 電話、TV 電話、ゲーム、チャットなどの P2P（Peer-to-Peer）による通信が基本となり、第3章以下では、NAT越えを含めSIPやP2P通信に関する課題についても詳述する。

(10)

第３章情報家電ネットワークのシステムモデル

(11)

第 3 章情報家電ネットワークのシステムモデル

現状では、宅内と宅外の連携について標準化が未整備であり、宅内で標準化が進んでいるインタフェースについてもメーカ間の相互運用性が実現できないことが多い。図 3.1 に、本検討における基本システムモデルを示す。基本システムモデルにおいては、

情報家電と宅外との接続にホームサーバ（ホームゲートウェイ）を介することで、プロトコル変換やセキュリティ確保を行う。また、サービス会社としてはISP、ASP、家電ベンダ、通信機器ベンダ、通信キャリア、コンテンツプロバイダ、さらにホームセキュリティ・警備会社、住宅ベンダ、電力会社などの様々な事業者が考えられる。本検討では、利用者自身が接続の設定や手続きを行うのが困難であること、あまりなじみのないサービス会社との接続がセキュリティ上の不安を招くことを考慮し、ポータル事業者が宅内外の接続を一括して扱うことも想定する。

無線センサ

非常ｱﾗｰﾑ無線

通信回線

（電話/ISDN/

ADSL/FTTH）

社会システム

家庭

ｶﾞｽｾﾝｻetc 宅内機器制御/表示ﾙｰﾀ/ﾒﾃﾞｨｱ変換

赤外線電灯線／無線など

STB

ﾎｰﾑｹﾞｰﾄｳｴｨ

（ﾎｰﾑｻｰﾊﾞ）

衛星/

地上波放送局ﾎｰﾑ

ｺﾝﾄﾛｰﾗ

DVDﾚｺｰﾀﾞ

情報サービス会社電話／電力／ガス会社

医療機関・勤務先

サービスポータル

（サービスサーバ）くらし家電ﾈｯﾄﾜｰｸ

くらし家電ﾈｯﾄﾜｰｸ

電話系ﾈｯﾄﾜｰｸ電話系ﾈｯﾄﾜｰｸ

パソコン系ﾈｯﾄﾜｰｸパソコン系ﾈｯﾄﾜｰｸ

ＡＶ家電系ネットワークＡＶ家電系ネットワーク監視・制御ロボット

図3.1 ホームネットワーク基本イメージ

(12)

第４章宅内ネットワーク技術動向

(13)

第 4 章宅内ネットワーク技術動向

4.1 IPネットワークと提供機能（DLNA、UPnP）

4.1.1 DLNAとは

DLNAとは、ホーム・ネットワークでデジタルAV機器同士やパソコンを連携させるための仕様を策定するために設立された業界団体の名称で「DLNA」(Digital Living Network Alliance)の頭文字を取ってDLNAと呼ばれている。

Consumers want their devices to work together

and share content Consumers want their devices to work together

and share content

MEDIA

Pre-Recorded Content Personal Media

MOBILE MULTIMEDIA

Entertainment, Personal Pictures and Video,

Services

BROADCAST

Services, Entertainment

BROADBAND

Entertainment, E-Business, Services

Consumers want their Consumers want their devices to work together devices to work together

and share content and share content

Consumers want their devices to work together

and share content Consumers want their devices to work together

and share content

MEDIA

Pre-Recorded Content Personal Media

MOBILE MULTIMEDIA

Entertainment, Personal Pictures and Video,

Services

BROADCAST

Services, Entertainment

BROADBAND

Entertainment, E-Business, Services

Consumers want their Consumers want their devices to work together devices to work together

and share content and share content

図4.1.1 DLNAの目指す姿

発足当初は、「Digital Home Working Group」(DHWG)と呼ばれ、音楽、写真、ビデオといったデジタル・コンテンツが家電、PC モバイル機器間でシームレスに共有される、相互互換性の高い家庭内外のネットワーク（有線・無線を問わず）の世界の実現を目指して、2003年6月に17社で設立された。結成から1年でガイドラインv1.0をリリースした際に団体の名称をDHWGからDLNAへ変更し現在に至っている。当時からもAV系、情報系、通信系、白物家電系、住宅設備系、セキュリティー系などのそれぞれのカテゴリー分野において、個別に開発、商品化が進められており、相互接続の問題が指摘されていたが、DHWG では、消費者視点に立って、手軽にデジタルコンテンツを創造、利用、管理、共有し、オープンかつ確立された業界標準技術を基に相互互換性の高いプラットフォームが必要との事で業界の垣根を越えた融合を目指して活動が開始された。主な活動内容は、①相互互換性の高い製品を作るための設計ガイドラインの作成 ②他の業界標準団体との連絡関係を構築・発展 ③準拠テスト並びに認定プログラムを確立・実施 ④認定製品に対し、消費者に分かりやすいロゴ・プログラムを確立・

実施等となっている。参加企業は、下記のように、マイクロソフト、インテル、松下電器、ソニーといった企業等 Promoter Member：21社、Contributor Member：235社

(14)

が参加している。（2005年9月）

図4.1.2 DLNA Promoter Member

4.1.2 DLNAで採用された技術の概要

最初の仕様である相互接続ガイドライン1.0（DLNAガイドライン）は2004年6月に策定され2005年には、Version 1.5がまとまり、現在は、Version 2.0の議論が始まっている。次ページから順次詳細の紹介をするが概要を理解する為に図 4.1.13 に示す

DLNA Ver1.0の概要を参照下さい。DLNAガイドラインでは、コンテンツを提供する

サーバーをDMS（digital media server）、再生するクライアントをDMP（digital media

player）と呼ぶ。DMSとDMPの機能をどの機器に持たせるかはメーカの自由となって

いる。また両方を1台の機器に実装することも可能となっている。DLNAガイドラインは、このDMSとDMPが連携動作するために必要な条件を定めている。このガイドラインに準拠した機器同士なら、ネットワークにつなぐだけで特別な設定なしにコンテンツをやりとりできるようになる。DMPをLANに接続すると、IPアドレスなどが自動的に割り振られ、通信できる状態になる。そしてDMPはLANにつながっているDMS を探し、そこに格納されているコンテンツのリストを取得して表示する。

DLNAガイドラインの仕様は、すでにある標準規格や汎用プロトコルを組み合わせたもので新たに作られた独自プロトコルは今のところない。例えば、伝送規格はイーサネ

ットかIEEE802.11無線LANを利用し、通信プロトコルはTCP/IP。制御メッセージの

交換やファイル転送にはHTTP（hypertext transfer protocol）を使い、メッセージは XML（extensible markup language）で記述する。動画のデータ形式はMPEG2、静止画はJPEGと規定している。このうえでガイドラインは、必ず使えるフォーマットをそれぞれのメディアごとに少なくとも一つは指定している。それ以外のフォーマットはオプションとなっていて、DMPとDMSの間であらかじめ決めておいて使う事になる。

(15)

DLNAガイドラインで中核になっているのは、図4.1.3 UPnP（Universal Plug and

Play）の仕様である。DMS や DMPにアドレスを割り当てたり、自動認識する部分に

はUPnP Device Architectureで規定されたプロトコルを使っている。持っているファ

イルの一覧情報を提供し、データを送り出すDMSにはUPnP Media Serverの仕様を使う。

0. Addressing IPv4 DHCP/Auto IP TCP UDP

HTTP 1. Discovery

SSDP

5.

Presentation HTML 3. Control

SOAP

4. Eventing GENA 2. Description

XML

Device Control Protocol

HTTPMU

0. Addressing IPv4 DHCP/Auto IP TCP UDP

HTTP 1. Discovery

SSDP

5.

Presentation HTML 3. Control

SOAP

4. Eventing GENA 2. Description

XML

Device Control Protocol

HTTPMU

図4.1.3 UPnP Device Architecture

ホーム・ネットワークに於いて、繋がる為に必要な項目を列挙すると、①お互いが繋がる ②相手を探す ③相手と話す ④機能が決まっている ⑤データの交換をする

⑥データ形式が決まっているなどが必要になる。順番にDLANで採用された技術を紹介していく。

(1) ネットワーク

お互いが繋がるネットワークとしての必要とされる項目は①高速に通信ができること

②簡単に設置、設定できること ③廉価であること ④QoS（伝送の遅延、ジッター、

帯域の保障）な画があげられるがDLNAでは、図4.1.4の様にEthernet、802.11a/b/g TCP/IP v4 (IP、TCP、UDP、ARP、ICMP、DHCP、Auto IP)が決まっている。

(16)

オプショナル^*2 オプショナル^*2 オプショナル^*2 奨励

必須必須

サポートレベル

54M IEEE 802.11g

SDTV: 3本 HDTV：1本 54M

IEEE 802.11a

SDTV：1本 11M

IEEE 802.11b 無線^*1

1000M IEEE 802.3ab (1000BASE-T)

SDTV: 10本 HDTV：３本 100M

IEEE 802.3u (100BASE-TX)

SDTV：１本 10M

IEEE 802.3i (10BASE-T) 有線^*1

参考伝送速度(bps) 規格名

オプショナル^*2 オプショナル^*2 オプショナル^*2 奨励

必須必須

サポートレベル

54M IEEE 802.11g

SDTV: 3本 HDTV：1本 54M

IEEE 802.11a

SDTV：1本 11M

IEEE 802.11b 無線^*1

1000M IEEE 802.3ab (1000BASE-T)

SDTV: 10本 HDTV：３本 100M

IEEE 802.3u (100BASE-TX)

SDTV：１本 10M

IEEE 802.3i (10BASE-T) 有線^*1

参考伝送速度(bps) 規格名

図4.1.4 ネットワーク

(2) 機器発見

必要な技術項目は、①必要な相手を探す ②探した相手の特徴を知る ③直ちに知る

③簡単設定があげられるが、DLNAでは、下記の様にUPnPで規定したSSDP (Simple Service Discovery Protocol)を使う。デバイスが自ら知らせる方法とコントローラから問い合わせる方法があり、簡単に紹介する。

① デバイスが自ら知らせる方法

デバイスはNOTIFYパケットをマルチキャストし、UDPはパケットロスする場合があるので、すこし間隔を離して複数同じパケットを送り、機器情報はHTTPにより取得する

[SSDP NOTIFY]

NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900

CACHE-CONTROL: max-age = seconds until advertisement expires LOCATION: URL for UPnP description for root device

NT: search target NTS: ssdp:alive

SERVER: OS/version UPnP/1.0 product/version USN: advertisement UUID

[SSDP NOTIFY]

NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900

[SSDP NOTIFY]

NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900 NT: search target

NTS: ssdp:byebye

[SSDP NOTIFY]

NTS: ssdp:byebye

SSDP:aliveネットワークに加わるとき

（例：電源On)

SSDP:byebyeネットワークから離れるとき

（例：電源off)

[SSDP NOTIFY]

NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900

[SSDP NOTIFY]

NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900

[SSDP NOTIFY]

NTS: ssdp:byebye

[SSDP NOTIFY]

NTS: ssdp:byebye

SSDP:aliveネットワークに加わるとき

（例：電源On)

SSDP:byebyeネットワークから離れるとき

（例：電源off)

図4.1.5 SSDP(Simple Service Discovery Protocol) デバイスが自ら知らせる方法 3. HTTP:GET Request

4. HTTP:GET Response デバイス

コントローラ 1. M-SEARCH Request

(MULTICAST)

2. M-SEARCH Response ^(UNICAST)

3. HTTP:GET Request 3. HTTP:GET Request 4. HTTP:GET Response 4. HTTP:GET Response デバイス

(MULTICAST)

1. M-SEARCH Request

(MULTICAST)

2. M-SEARCH Response ^(UNICAST) 2. M-SEARCH Response ^(UNICAST)

(17)

② コントローラから問い合わせる方法

コントローラはSSDP:M-SEARCHをマルチキャストする。また、その際に探したいデバイス、サービスの種類を指定してもよい。デバイスはSSDP:M-SEARCHをコントローラに対して送信する。

[SSDP M-SEARCH]

M-SEARCH * HTTP/1.1 HOST: 239.255.255.250:1900 MAN: "ssdp:discover"

MX: seconds to delay response ST: search target

[SSDP M-SEARCH]

[SSDP M-SEARCH Response]

HTTP/1.1 200 OK

CACHE-CONTROL: max-age = seconds until advertisement expires DATE: when response was generated

EXT:

LOCATION: URL for UPnP description for root device SERVER: OS/version UPnP/1.0 product/version ST: search target

USN: advertisement UUID [SSDP M-SEARCH Response]

HTTP/1.1 200 OK

EXT:

USN: advertisement UUID

3. HTTP:GET Request 4. HTTP:GET Response デバイス

(MULTICAST)

[SSDP M-SEARCH]

[SSDP M-SEARCH Response]

HTTP/1.1 200 OK

EXT:

USN: advertisement UUID [SSDP M-SEARCH Response]

HTTP/1.1 200 OK

EXT:

USN: advertisement UUID

3. HTTP:GET Request 4. HTTP:GET Response デバイス

(MULTICAST)

3. HTTP:GET Request 3. HTTP:GET Request 4. HTTP:GET Response 4. HTTP:GET Response デバイス

(MULTICAST)

1. M-SEARCH Request

(MULTICAST)

2. M-SEARCH Response ^(UNICAST) 2. M-SEARCH Response ^(UNICAST)

図4.1.6 SSDP(Simple Service Discovery Protocol) コントローラから問い合わせる方法

その他機器情報として、Device descriptionとしてFriendly Name（ユーザが親しみやすい名前）やアイコン、そしてどんなサービスをもっているのかやサービスを制御するメッセージのあて先を記載する。またService descriptionとして、どんな機能をサポートしているのか、サービスの能力等も記載する。

(3) メッセージング

必要な技術項目は、①多様なデータ型が表現できること ②メッセージの手順（プロトコル）が決められていること ③OSやCPUに依存しない ④簡単であることなどがあげられるが、DLNAでは、SOAPとGENAを採用している。

① SOAP (Simple Object Access Protocol)とは、

デバイスのリモートコントロール機能を行う。W3C 勧告（国際標準）となっている方式で、HTTPを使うので、Firewallを超える事が可能である。しかし、応答時間が一定でない (推奨値は30sec以下）ことや XMLの処理が重い等（組み込み式

Systemの場合では、ある程度以上のCPUパワーが必要となる。）問題点もいくつ

か指摘されている。

参考までに通信は、下記の手順で行う。

・コントローラはリクエスト(HTTP POSTのリクエスト）を送信する

・デバイスは30秒以内にレスポンス(HTTP POSTのレスポンス）を返信する

(18)

POST path of control URL HTTP/1.1 HOST: host of control URL:port of control URL CONTENT-LENGTH: bytes in body CONTENT-TYPE: text/xml; charset="utf-8"

SOAPACTION: "urn:schemas-upnp- org:service:serviceType:v#actionName"

<s:Envelope

xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"

s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<s:Body>

<u:actionName xmlns:u="urn:schemas-upnp- org:service:serviceType:v">

<argumentName>in arg value</argumentName>

other in args and their values go here, if any

</u:actionName>

</s:Body>

</s:Envelope>

<s:Envelope

<s:Body>

</u:actionName>

</s:Body>

</s:Envelope>

HTTP/1.1 200 OK

CONTENT-LENGTH: bytes in body CONTENT-TYPE: text/xml; charset="utf-8"

DATE: when response was generated EXT:

SERVER: OS/version UPnP/1.0 product/version

<s:Envelope

<s:Body>

<u:actionNameResponse xmlns:u="urn:schemas-upnp- org:service:serviceType:v">

<argumentName>out arg value</argumentName>

other out args and their values go here, if any

</u:actionNameResponse>

</s:Body>

</s:Envelope>

HTTP/1.1 200 OK

<s:Envelope

<s:Body>

</s:Body>

</s:Envelope>

1. SOAP Request 2. SOAP Response デバイス

コントローラ

<s:Envelope

<s:Body>

</u:actionName>

</s:Body>

</s:Envelope>

<s:Envelope

<s:Body>

</u:actionName>

</s:Body>

</s:Envelope>

HTTP/1.1 200 OK

<s:Envelope

<s:Body>

</s:Body>

</s:Envelope>

HTTP/1.1 200 OK

<s:Envelope

<s:Body>

</s:Body>

</s:Envelope>

1. SOAP Request 1. SOAP Request 2. SOAP Response 2. SOAP Response デバイス

コントローラ

図4.1.7 SOAP

② GENA (General Event Notification Architecture)とは TargetからControllerに状態変化を通知する機能。

主な特徴は、Target側からのPush制御が可能となっている。この事によりトラフィックを増大させるPolling 処理が不要になる。考慮が必要な項目は、Event 発生から実際に通知される時間が保証されていない事や、（SOAP 方式と比較して）

Targetの負荷が大きい。

1. GENA SUBSCRIBE Request 2. GENA SUBSCRUBE Response

デバイス

コントローラ 3. GENA Event

NOTIFYdelivery pathHTTP/1.1 HOST: delivery host:delivery port CONTENT-TYPE: text/xml CONTENT-LENGTH: Bytes in body NT: upnp:event

NTS: upnp:propchange SID: uuid:subscription-UUID SEQ: event key

<e:propertysetxmlns:e="urn:schemas-upnp-org:event-1-0">

<e:property>

<variableName>new value</variableName>

</e:property>

Other variable names and values (if any) go here.

</e:propertyset>

<e:property>

</e:property>

</e:propertyset>

1. GENA SUBSCRIBE Request 1. GENA SUBSCRIBE Request 2. GENA SUBSCRUBE Response 2. GENA SUBSCRUBE Response

デバイス

コントローラ 3. GENA Event

3. GENA Event

<e:property>

</e:property>

</e:propertyset>

<e:property>

</e:property>

</e:propertyset>

図4.1.8 GENA

(19)

(4) サービス

必要な技術項目は、①目的のユースケースを実現できる機能を持つこと ②応用、拡張が可能であることなどがあげられるが、DLNA では、UPnP Media Server

Content Directoryサービス（コンテンツの一覧、検索、メタデータの取得が行なえる）

を採用している。

Content Directory Service UPnP Media Serverの主要なサービスは、①コンテンツの閲覧、検索 ②コンテンツメタデータの編集となっており DLNA v1.0で利用する主なアクションは、①階層ディレクトリのコンテンツの閲覧を行う（CDS:Browse 必須）

②コンテンツの属性にて検索（CDS:Search オプショナル） ③サポートしているストリーミングプロトコル、コンテンツのメディアフォーマットを取得

（CDS:GetProtocolInfo 必須）

尚、参考までに図4.1.9にCDSの構成を示す。

Chloe Dancer

My Videos My Photos My Musics Root

Drown Chloe Dancer

My Videos My Photos My Musics Root

Drown

図4.1.9 例 CDS:Browse

(5) ストリーミング

必要な技術項目は、①ＡＶコンテンツの転送（転送速度、遅延、ジッター、クロック同期） ②再生方法（シーク、変速再生）に適した転送（要求の方法、転送の単位）

DLNAでは、HTTP v1.1/1.0（広く普及しており、実ベンダー間のインタオペが取りやすい）を採用している。またDLNAのヘッダー拡張として時間単位にて転送データを要求できる Time-based Seek やサーバ側での変速再生加工したデータを要求できる Server-side Trick Playなども組み込まれている。

(6) メディアフォーマット

必要な技術項目は、①高効率圧縮 ②コストが安い ③普及度が高い ④汎用性が高い DLNA のメディアフォーマットのインタオペラビリティーでは機器がサポートする必須メディアフォーマットを決め、異なるベンダー間で再生を保障する事や、多様な Profile、Parameter の組み合わせから、想定する用途、機器に適した Parameter Set を決める事になっている。

DLNAで採用された技術は図4.1.10の様になっている。

(20)

VIDEO IMAGES

AUDIO

Mandatory Format Set

MPEG4:2, MPEG4:10, WMV9 AAC, ATRAC3plus,

MP3, WMA9

Optional Format Set (DLNA Addendum) Media Class

MPEG2 LPCM JPEG

VIDEO IMAGES

AUDIO

Mandatory Format Set

MPEG4:2, MPEG4:10, WMV9 AAC, ATRAC3plus,

MP3, WMA9

Optional Format Set (DLNA Addendum) Media Class

MPEG2 LPCM JPEG

図4.1.10 メディアフォーマット

インタオペラビリティーのルール：

DLNAでは、実装するメディアクラスに於いて必ず最低一つの必須プロファイルをサポートしなければならない事が決まっている。例えばイメージクラスでは「JPEG_SM」

プロファイルが必須となっている。またオプションプロファイルをサポートすることが可能となっており、サーバーは必須プロファイルの範囲内で追加的にオプションをサポートすることになっている。また、プレーヤはオプションプロファイルを再生することが出来ない場合は、その状態を表示しなければならない事になっている。ビデオフォーマットに関しては、フォーマットプロファイルの要求に際して地域性が存在するため今後世界中のコンテンツでの相互互換の問題が課題となっている。

z

AV

z MPEG2 PS

z MP@ML

z CBR/VBR <= 10.08Mbps*

z 4:3/16:9 aspect ratios

z 30/25fps

z NTSC/PAL

z MPEG2 TS (Regional)

z MP@ML

z CBR/VBR <= 15Mbps and for HD:19.3927Mbps*

z 192 byte packet (188 TS packet + 4 bytes Time stamp)

z Single program Transport Stream

z PAT and PMT mandatory

z PSI insertion interval decided by implementers

z

Images

z JPEG SM

z 640x480 Max z JPEG MID

z 1024x768 Max z JPEG LRG

z 4096x4096 Max

zAudio

zLPCM

z1 or 2 channel z44.1 or 48Khz z16-bit

* System bit rate

z

AV

z MPEG2 PS

z MP@ML

z CBR/VBR <= 10.08Mbps*

z 30/25fps

z NTSC/PAL

z MPEG2 TS (Regional)

z MP@ML

z CBR/VBR <= 15Mbps and for HD:19.3927Mbps*

z 192 byte packet (188 TS packet + 4 bytes Time stamp)

z Single program Transport Stream

z PAT and PMT mandatory

z PSI insertion interval decided by implementers

z

Images

z JPEG SM

z 640x480 Max z JPEG MID

z 1024x768 Max z JPEG LRG

z 4096x4096 Max

zAudio

zLPCM

z1 or 2 channel z44.1 or 48Khz z16-bit

* System bit rate

図4.1.11 フォーマットプロファイル

4.1.3 DLNAガイドラインとその進捗

ガイドラインの策定プロセスについて観単に紹介する。

Promoter Member：21社、Contributor Member：235社が参加し協議を行う中で最初に討議課題の絞込みを行うが、各社がやりたいユースケースは多様であり、全てを必須で決めることは困難である。その為DLNAでは、絞込みの際に投票（得点）を行い高得点の課題を議題として決めるルールになっている。このため、決めたい事項がある場合は、他社を説得して議論にのせる活動が必要になり、まとまるまでに時間がかかって

(21)

いる。また、オプションの部分については、他社が実装するかどうかは不明となる為相互互換の問題が発生する恐れもある。ガイドライン策定のプロセスとして最初にユースケース（ユーザの想定利用環境）の検討をおこない、技術的な観点や、市場動向の観点からも協議しこの活動で絞り込まれた後、どの規格を採用するか等を協議し、また不足部分は明確化を行う。図4.1.12にそのプロセスを示す。

Use Cases 協議

技術要求仕様確定

• 物理接続:

802.3(有線LAN) 802.11（無線LAN）

• ネットワーク:

TCP/IPプロトコル群（IPｖ４,TCP,UDP, ARP, ICMP,DHCP）

• アプリケーション：

UPnP-DA, UPnP-AV, HTTP1.0/1.1

設計ガイドライン策定

• 業界標準技術規格における曖昧さの是正

• 実装を容易にする業界標準技術規格内容の制限

• ユーザの利便性向上を目的とした機能拡張

• 必須項目と選択可能項目の明確化

•

技術的観点から

•

市場動向の観点から

•

優先度付け Use Cases 協議

技術要求仕様確定

• 物理接続:

802.3(有線LAN) 802.11（無線LAN）

• ネットワーク:

TCP/IPプロトコル群（IPｖ４,TCP,UDP, ARP, ICMP,DHCP）

• アプリケーション：

UPnP-DA, UPnP-AV, HTTP1.0/1.1

設計ガイドライン策定

• 業界標準技術規格における曖昧さの是正

• 実装を容易にする業界標準技術規格内容の制限

• ユーザの利便性向上を目的とした機能拡張

• 必須項目と選択可能項目の明確化

•

技術的観点から

•

市場動向の観点から

•

優先度付け

図4.1.12 ガイドラインの策定プロセス

DLNA Ver 1.0の概要：

DLNA ガイドラインでは、コンテンツを提供するサーバーを DMS（digital media server）、再生するクライアントをDMP（digital media player）と呼ぶ。DLNAガイドラインは、この DMS と DMP が連携動作するために必要な条件を定めている。図 4.1.13にDLNA V1.0で規定されたプロトコルを示す

図4.1.13 DLNA Ver1.0 JPEG, LPCM, MPEG2

UPnP AV 1.0 (Content Directory Service)

UPnP Device Architecture 1.0

(AutoIP /DHCP, SSDP, SOAP, GENA)

HTTP 1.0/1.1

IPv4 Protocol Suite Wired: 802.3i, 802.3u Wireless: 802.11a/b/g Media Format

（メディアフォーマット）

Network Connectivity

（ネットワーク）

Media Transport

（ストリーミング）

Device Discovery, Control, and Media

Management

第2層データリンク第1層物理層

標準技術 OSI参照モデル

DLNA 分類

第4層トランスポート層第3層ネットワーク層第7層アプリケーション層第6層プレゼンテーション第5層セッション層

（機器発見、メッセージング、サービス）

JPEG, LPCM, MPEG2 UPnP AV 1.0、UPnP Printer

(Content Directory Service)

UPnP Device Architecture 1.0

(AutoIP /DHCP, SSDP, SOAP, GENA)

HTTP 1.0/1.1

IPv4 Protocol Suite Wired: 802.3i, 802.3u Wireless: 802.11a/b/g Media Format

（メディアフォーマット）

Network Connectivity

（ネットワーク）

Media Transport

（ストリーミング）

Device Discovery, Control, and Media

Management

第2層データリンク第1層物理層

標準技術 OSI参照モデル

DLNA 分類

第4層トランスポート層第3層ネットワーク層第7層アプリケーション層第6層プレゼンテーション第5層セッション層

（機器発見、メッセージング、サービス）

(22)

DLNA Ver 1.5

当初、DLNA 1.1の予定であったがVer1.5となった。新たに6つのユースケースを追加し、8つのDevice Class、5つのDevice Capabilityを追加定義している。

図4.1.14に新たに追加されたユースケースを示す。

+UP+のコンテンツをDMSに転送する DMSのコンテンツを+DN+に転送する

+PR2+を使って、DMSのイメージをDMPrでプリントする +PR1+上のイメージをDMPr1でプリントする DMCを使って、DMSのコンテンツをDMRで再生する +PU+のコンテンツをDMRで再生する

DMSのコンテンツをDMPで再生する概要

DMS or M-DMS DMS or M-DMS

DMPr and (DMS or M-DMS) DMPr

(DMS or M-DMS) and DMR DMR

DMS or M-DMS 離れたところにある機器 (コントローラされる機器）

+UP+

Upload

+DN+

Download

+PR2+

3 Box Printing

+PR1+

2 Box Printing

DMC or M-DMC 3 Box

+PU+

2 Box Push

DMP or M-DMP 2 Box Pull (v1.0)

ユーザ側の機器

（コントローラ）

ユースケース（System Usage)

+UP+のコンテンツをDMSに転送する DMSのコンテンツを+DN+に転送する

+PR2+を使って、DMSのイメージをDMPrでプリントする +PR1+上のイメージをDMPr1でプリントする DMCを使って、DMSのコンテンツをDMRで再生する +PU+のコンテンツをDMRで再生する

DMSのコンテンツをDMPで再生する概要

DMS or M-DMS DMS or M-DMS

DMPr and (DMS or M-DMS) DMPr

(DMS or M-DMS) and DMR DMR

DMS or M-DMS 離れたところにある機器 (コントローラされる機器）

+UP+

Upload

+DN+

Download

+PR2+

3 Box Printing

+PR1+

2 Box Printing

DMC or M-DMC 3 Box

+PU+

2 Box Push

DMP or M-DMP 2 Box Pull (v1.0)

ユーザ側の機器

（コントローラ）

ユースケース（System Usage)

図4.1.14 新たに追加されたユースケース

図4.1.15に新たに追加定義されたDevice Classを示す。

MIU (Media Interoperability Unit) Home Infrastructure Device Mobile Network Device

Home Network Device

M-NCF (Mobile Network Connectivity Function) M-DMC (Mobile DMC)

M-DMS (Mobile DMS) M-DMP (Mobile DMP)

DMPr (Digital Media Printer) DMC (Digital Media Controller) DMR (Digital Media Renderer) DMS (Digital Media Server) v1.0 DMP (Digital Media Player) v1.0 Device Class （単独で商品に実装）

MIU (Media Interoperability Unit) Home Infrastructure Device Mobile Network Device

Home Network Device

M-NCF (Mobile Network Connectivity Function) M-DMC (Mobile DMC)

M-DMS (Mobile DMS) M-DMP (Mobile DMP)

DMPr (Digital Media Printer) DMC (Digital Media Controller) DMR (Digital Media Renderer) DMS (Digital Media Server) v1.0 DMP (Digital Media Player) v1.0 Device Class （単独で商品に実装）

図4.1.15 新たに追加定義されたDevice Class 図4.1.16にDevice Capabilityを示す。

+UP+ (Upload Controller) +DN+ (Download Controller) +PR2+ (Printer Controller 2) +PR1+ (Printer Controller 1) +PU+ (Push Controller)

Device Capability（追加機能として実装）

+UP+ (Upload Controller) +DN+ (Download Controller) +PR2+ (Printer Controller 2) +PR1+ (Printer Controller 1) +PU+ (Push Controller)

Device Capability（追加機能として実装）

図4.1.16 Device Capability

(23)

DLNA ガイドライン v1.5では、新たなデバイスモデルの定義が行なわれている。それが、DMC(Digital Media Controllers) 、DMR(Digital Media Renderers) 、 DMPr(Digital Media Printer)。DLNAガイドラインv1.0では、デバイスモデルとして DMS(Digital Media Server)とDMP(Digital Media Player)という2つのモデル（DLNA では、2boxモデルと呼ぶ）が定義され、図4.1.17に示す様にユーザの位置によりPull、

Pushと呼んでいる。

lDMS or M-DMS lMSD

lMedia Transpor

t Server lDMP or M-DMP

lUPnP CP lConte

lMedia nt Transpor

t Client

lUPnP Device l2

l1 l3

lPush Controller lMRCP

lMedia Transp ort Server lDMR

lMRD

lUPnP Device

lCont ent

lMedia Transp ort Client

lUPnP CP l2

lDMS or M-DMS lMSD

lMedia Transpor

t Server lDMP or M-DMP

lUPnP CP lConte

lMedia nt Transpor

t Client

lUPnP Device l2

l1 l3

lPush Controller lMRCP

lMedia Transp ort Server lDMR

lMRD

lUPnP Device

lCont ent

lMedia Transp ort Client

lUPnP CP l2

図4.1.17 2box Pull 2box Push

DMSはUPnPのメディアサーバーが内蔵されているサーバー用のデバイスモデルで、

一方DMPはメディアクライアントとコントロールポイントと呼んでいる、ユーザが操作するソフトウェア（リモコンのようなもの）が内蔵された、クライアント用のデバイスモデルとなっている。DLNAの規定では、1つの機器の中にDMSとDMPが共存することも可能になっている。

次に3Boxモデルを図4.1.18に示す。

lDMS or M-DMS lMSD

lMedia Transport

Server lDMR

lMRD

lUPnP Device

lContent

Client

lUPnP Device

lDMC or M-DMC lMSCP

lUPnP CP

lIP Connectivity lMRCP

l4

l2 l1

l3

手元で操作する機器

コンテンツがたくさんある大画面、高精細、高音質

VAIO (DLNA Server)

PSP Remote BRAVIA X

lDMS or M-DMS lMSD

Server lDMR

lMRD

lUPnP Device

lContent

Client

lUPnP Device

lDMC or M-DMC lMSCP

lUPnP CP

lIP Connectivity lMRCP

l4

l2 l1

l3

手元で操作する機器

コンテンツがたくさんある大画面、高精細、高音質

VAIO (DLNA Server)

PSP Remote BRAVIA X

図4.1.18 3Box モデル

ユビキタス情報家電ネットワーク委員会メンバー