インターネット前提のサービス・製品の企画・開発におけるStarBED活⽤事例
2015年10月20日
パナソニック株式会社 先端研究本部 知能研究室 村本衛一
北陸先端科学技術⼤学院⼤学/情報通信研究機構 知念賢一

1

内容
• パナソニックの事業領域• サービス・製品の企画・開発工程でのStarBED活用事例• インターネット前提商品開発（HDコム）• バーストロス耐性• 重複排除機能を有するデータ保管サービス検討• 企画前段階でのフィージビリティ確認• まとめ2

パナソニックの事業領域
エコソリューションズ社（ＥＳ）

アプライアンス社（ＡＰ）

レコーダ

ＡＶＣネットワークス社（ＡＶＣ）

HDコム

オートモーティブ＆インダストリアルシステムズ社（ＡＩＳ）

法人向けタブレット

3

インターネット前提のサービス・製品
エコソリューションズ社（ＥＳ）

アプライアンス社（ＡＰ）

サービス化

エネマネ

・IP再送信・配信
・アラート
・レコメンド

・HEMS
・BEMS

レコーダ

ＡＶＣネットワークス社（ＡＶＣ）

オートモーティブ＆インダストリアルシステムズ社（ＡＩＳ）

ソリューション
提供
HDコム

法人向けタブレット

Connected Car

Industrial 4.04

本日のStarBED活用事例紹介エコソリューションズ社（ＥＳ）

アプライアンス社（ＡＰ）

サービス検討
（企画前）

②
レコーダ

レコーダ
ＡＶＣネットワークス社（ＡＶＣ）

商品開発工程（企画後）オートモーティブ＆インダストリアルシステムズ社（ＡＩＳ）

①
HDコム
HDコム

法人向けタブレット

5

StarBED技術活⽤事例①6

インターネット前提商品開発（HDコム）

商品企画後の活用• HDコム– テレビ会議システム– 開発開始：2006年～2009年（１号機商品化）• 課題– インターネット越しの映像音声伝送で「他社機以上の性能」

帯域が変動
パケットロス発生

どんな変動？
どんなロス？

インターネット

端末間で帯域を推定エンコーダを制御
パケットロスの発生頻度、許容される遅延でFEC,ARQ制御
7

商品開発工程とStarBED技術活用シーン（ロス回復方式の選定）
工程：

目標仕様の設定
・市場調査
・ベンチマーク

採用する要素技術の決定・開発

機能性能検証・要素技術評価、システム設計
・ハード・ソフト設計開発

・商品の機能性能検証

課題：どんなロス？
方式選定：バーストロス耐性と低遅延伝送の両立
・長期TCP（FTP)、短期TCP（HTTP）の混在でバーストロス発生確率が異なる[YJOO]・ロス回復能力（FECブロック：大、再送：多）と低遅延伝送はトレードオフ
XOR-FEC（RFC2733- base)
DATA1

DATA2

DATA3

FEC1DATA1

DATA2DATA3FEC1DATA4DATA5DATA6FEC2DATA4DATA5DATA6FEC2FEC3FEC4FEC5FEC6FEC3FEC4FEC5FEC6[YJOO] Y. Joo,et al.,” TCP/IP Traffic Dynamics and Network Performance: A Lesson in Workload
Modeling, Flow Control, and Trace-driven Simulations.”, CCR, April 2001.

8

商品開発工程とStarBED技術活用シーン（ロス回復方式の選定）
StarBED技術活用シーン 現実的なバーストロスを長短TCPの混在で再現

評価パラメータ

評価レンジ

ボトルネックリンクの帯域1Gbps

長短TCP混在率

HTTP とFTP の混在率＝0, 0.25, 0.5, 0.75, 1 (ex. 混在
率0 のとき,HTTP 0%,FTP100%)

総TCP本数

120本, 480本, 1920本, 3000本

RTT

10ms(東京-大阪の理論値)

我々の実装（TCP４８０本競合時）

他社機（TCP４８０本競合時）

村本衛一，米田孝弘，小西一暢，蓑田佑紀，知念賢一: エンコーダ，デコーダ制御によるインターネット経由の映像音声ストリームの高信頼，低遅延伝送制御の実現, インターネットコンファレンス2010 (2010).

9

A社（FECのみ）と当社の比較
遅延100ms, パケットロス3%で画像が乱れる
遅延100ms, パケットロス5%で画像がかなり乱れる、顔の表情が識別しにくい
音切れあり

会議での使用は可能だが、不快感あり。
長時間の会議ではストレスあり。
（実証データ）A社（パケットロス5%）

当社（パケットロス5%）

B社（FEC、ARQ併用）との比較
パケットロス0%の回線では、画像きれい
遅延100ms, パケットロス3%で映像の抜けが目立ち、やがて映像がフリーズ。
音声のみ聞こえている状態になる。

会議での使用は困難（実証データ）B社（パケットロス3%）

当社機（パケットロス3%）

StarBED技術活⽤事例②12

重複排除機能を有するデータ保管サービス検討 サービス企画前の活用
工程：

目標仕様の設定
・市場調査
・ベンチマーク

採用する要素技術の決定・開発

機能性能検証・要素技術評価、システム設計・ハード・ソフト設計開発

・商品の機能性能検証

目的： 重複排除機能を有するデータ保管サービスの実現性の検証
背景：• 情報端末の普及＆同じコンテンツを個別の端末で処理・保存– 例： 動画データ（同報メディア）、音楽データ• クラウドを用いた記憶容量貸出しサービスの普及– 例： dropbox、skydrive

想定する潜在要望：
手元にデータ・保存機器を持ちたくない（故障/データ移行）
場所に依存せずに自分のデータにアクセスしたい

13

想定するシステム と 課題
大規模にコンテンツを収集・保存可能なシステム
サーバの特徴： 重複したコンテンツが多数のユーザから送信されてくるネットワーク

記憶装置

待受け

データ
書込み

upload（HTTP）

端末端末

端末

端末

端末

ユーザ単位で別領域を用意すると、記憶容量が浪費

クライアント数に依存し、サーバ直下の帯域が増加

数万～数十万クライアント

コンテンツ保存サーバ

要求 と 重複排除のアイデア• 要求
1. 大規模（クライアント数）への適用
2. 重複データの排除
3. 通信失敗への耐性• 重複排除のアイデア– 2段階重複排除

リクエスト単位の処理
1. コネクション受付（receipt）
2. リクエスト解釈・アクション判定（parse&descion）
コンテンツテーブルを参照し、uploadあり/なしを判定

3. アップロード/ダウンロード処理

応答シーケンス

C：Client
S：Server

即座に応答すればアップロード発生しない

応答が遅れるとアップロードが発生帯域削減評価

限界を超えると１０Gbpsでる。
つまり、ネットワーク処理はボトルネックではない24,000接続(12台で模擬）まで、サーバ処理は耐えた重複排除しない場合に比べ、1/17000 に帯域削減

コネクション処理性能評価
24,000接続(12台で模擬）50Kcpsまで、サーバ処理は耐えた

重複排除機能を有するデータ保管サービス検討• 検証結果のまとめ– 2段階重複排除機構をStarBEDで評価– 重複排除により、1万7千の1の帯域削減効果– サーバ1台で50Kcps（24,000接続）まで動作サービスを実現するコア技術（重複排除）の実現性（性能）を確認

クラウドサービス化した場合のコスト試算（市場性）の評価
目標仕様の設定
・市場調査
・ベンチマーク

採用する要素技術の決定・開発

機能性能検証・要素技術評価、システム設計
・ハード・ソフト設計開発

・商品の機能性能検証

まとめ• インターネット前提のサービス、製品が当たり前– HDコム：インターネット越しの映像音声の伝送性能が差別化要素– 重複排除SV： 多数のユーザのアクセスを想定した性能確保が鍵• サービス・製品の様々な工程でStarBED技術を利用– 企画前の事例： HDコム開発 （目標性能の達成）– 企画前の事例： 重複排除SV （実現性の確認）• 目標性能の達成– 現実的なトラフィックの模擬にStarBED技術を利用• 実現性の確認– 大規模なインターネットユーザの挙動の模倣にStarBED技術を利用• 今後– 複数の搬送ロボット（無線環境）の企画前、後工程でStarBED技術活用を検討中• アクセス集中、ハンドオフ、遮蔽物の移動

21

• 以下22