日立、松下、NTTの家電を視野に入れたBBサービスプロトコル。製品は来春以降か | RBB TODAY

日立、松下、NTTの家電を視野に入れたBBサービスプロトコル。製品は来春以降か

ブロードバンド その他

 光サービスアーキテクチャコンソーシアム(HSAC)をスタートにしてコマースにシフトしたプロトコル開発を続けている光サービスセットアッププロトコル(HSSP)の成果報告とデモ実演が実施された。同研究は日立、松下、NTT持株の3社によるもので、端末の違いをプロトコルが支援することでその差を吸収し、もっともベストな状態でコンテンツやサービスを利用できるようにしようとした共同研究となる。

 HSSPは、日立がVoD、松下がSTB、NTT持株がオンラインコマース部分の開発を主に担当しており、それぞれの得意分野を生かして端末の差をプロトコルで吸収し、サーバ側で動的にリクエストに応えようとしたもの。HSPPは2つのプロトコルを規定しており、端末ごとに利用可能なサービス名を戻すHSDP(HIKARI Service Discovery Protocol)と、端末能力に合わせた内容でサービスにネゴシエーションするHSNP(HIKARI Service Negotiation Protocol)から成り立つ。あくまでも端末の能力や属性に合わせて最適なコンテンツやサービスを配信することを目的としたプロトコル開発で、細かなサービス部分は、既存のプロトコルを利用する。

 具体的な姿としてHSSPが今回デモしたものは、一般のPC、STBを含めた各種家電、PDAを意識したもの。その表示や処理能力をあらかじめ規定化することにより、HSDPリクエストでは各端末ごとに実現できるサービス名一覧を表示し、HSNPを使って各端末ごとにもっとも適した形のコンテンツ配信をするといったもの。利用者は端末の違いを意識することなく同じユーザインターフェイスで利用できることが最大の特徴だ。

 それれのプロトコルの役割は、具体的に次のような形になる。プロトコルには、あらかじめ規定された形で端末属性が含まれており、HSDPのリクエストを出すと、端末の持つ能力に合わせて再現できるサービス一覧だけを返す。つまり、プロセッサの能力やプラグインが装備できないために端末側で再生できないサービスは、HSDPがあらかじめ利用できるサービスとして戻さない。つまり、メニューに含まれないため、再生できないサービスを選ぶことがなくなる。なお、プラグインのようなサポートアプリケーションを使ったりハードウェアの拡張をすることで再生できるサービスは、そのための情報付きでサービス一覧に含まれる。そうした拡張により対応できるサービスは、端末側のUIでダウンロードやインストール処理をすることで、サービスの再生を実現する。

 HSDPにより得られたサービス一覧は、ネゴシエーションプロトコルであるHSNPを使ったリクエストで、最適なコンテンツを入手して端末ごとに表示処理をすることになる。HSNPは、各端末の能力属性に合わせてコンテンツサイズをコントロールする。すぐに思い浮かぶものは端末の画面解像度とプロセッサ能力に合わせて一覧表示するカラム数のコントロールや送信するストリーミングデータを切り替える。結果として、端末やネットワークは帯域の無駄使いをすることなく、最適なレスポンスが得られる。つまり、HSNPは帯域を有効活用するプロトコルともいえる。

 HSDP、HSNP共にすでに各種評価も終わらせ、製品装備に向けた実装レベルに入ってきた。そして、これからが本格的な普及に向けたアプローチの開始となる。仕様的には一般的なPCが利用するというよりも、家電製品を中心としたサービスとなり、STB的な利用をしているPCあたりがそのサービス範疇に入るといえる。今後、各家電メーカや通信系企業のつながりにより、標準の地位を獲得することが、スケールするための条件となる。

 今回共同研究をしている三社は、製品の投入時期として来年春以降を検討しているもよう。初期の製品はおそらくSTBのようなTV受像器に近いところで動くものやPDAのようなものと思われるが、PCについで非PCの姿をしたものがいよいよネットワークに加わる可能性が出てきた。
《RBB TODAY》

編集部のおすすめ記事

特集

page top