debiancdn

AWS, Content Delivery Network and Debian

日別アーカイブ: 2007/09/14

BS-10-13 Study on Sensor Applications based on Event Driven Framework (電機大 iwaki yoichi)

センサーアプリケーションをつくるフレームワークがないのでセンサーアプリをJAIN SLEEの上でApplication Model実装するようにしようという話。

まずはデザインの話、次にJAIN SLEEの紹介。

プロトタイプ:ヘルスマネージメントサービス。心拍センサーをつかったもの。

今後:センサーフレームワークをつかってアプリ統合、アプリモデルをもっと他につかってみる、プロトタイプの評価

Q:リソースアダプタをつくったのか?

A:ハートビートセンサーがSIPをしゃべってくれるので別に何も。

Q:JAIN SLEEの本来の目的に使う気はないのか?

A:まだ考えてない。

Rhinoをつかって作ったようだ。

B-6-42 検疫ネットワークにおけるパッチ分散ダウンロードの研究 早稲田大学GITS 林 urano lab

今回の研究対象はDHCP型の検疫ネットワーク。同時に1000台のMS updateするとどうなるのか。治療中は端末に接続できず、仕事できない。物理的には同じネットワークなので正常PCの業務妨害になる。そこで物理的にも切り離してパッチ配布サーバにハブまるごとつながせる方法を考える

安いハブでもできる。

Q:うごいているのか?サーバの条件は?

A:MS updateは動く。配布されるものが配布元認証などしていると動かない。

Q:どんなパッチ配布サーバで動く?

A:どんな場合でも動くとは限らない。

B-6-41 webサーバ機能を持つ多機能コンセントの開発 鳥取大学

webによる遠隔制御、RFIDタグを利用機器につけてsecurityもOKをはかる。

応用:盗電防止、器具利用状況の管理、遠隔地からの電源制御

実験してみた。電圧を10bit分解能で1秒ごとに測定した。

Q:電流を測るべきじゃないのかなあ。

Q:何も無いプラグは拒否すべきでは

Q:PLCにしたら?

とりあえず突っ込みどころは満載だけどブツができたらアイディアは浮かんでくるものと思われる。

B-6-40 複数NICを用いた仮想化技術の考察 ドコモ総合研究所 永田

Linux Bondingについて、リンク資源の独立性

vmwareやXenではNICの共有のみで、複数あるのをうまくわけるようなものは扱えない

Linux Bondingをつかうと利用可能帯域をふやし、負荷分散し、冗長性向上する。

リンク資源独立性を定義:他のサービスに影響されないリンク、あいているリンクがあれば必要に応じて使う。隔離されていないサービスについてはあいてるNICを使う。

課題と問題点:サービス単位でNICをきめなければならない。重くなる。

受信についてはどうするのか:SWの設定をする?

今後:実装と評価

Q:NECのひと:同じようなことをやっている。47番で講演する。L2(スイッチ?)で輻輳制御した。

A:できるだけ物理的に分割したい。

Q:座長:順序制御はどうするんだ

A:フローレベルで同じ物理インタフェースを使う

B-6-39 Cell Broadcast Serviceにおける配信制御方式 NTTドコモ

3gppのCBS:SMSを拡張して同報配信に対応した方式。緊急地震速報など。

CBEからきたメッセージをCBCが送出する。これを速くする必要がある。ただし無駄なメッセージは送出しないようにしないといけない。さらに負荷分散も重要。

CBE->LB->CBCの流れを工夫した。CBE→CBCで一定時間有効な仮想パスが張られる。

Q:一定時間の基準は?

A:CBEユーザごとにチューニングする。

Q:なぜ一定時間きめないといけないのか

A:CBCがかわるとまずいメッセージがある

Q:LBがボトルネックにならんか

A:たしかにLBはそうならないという前提

B-6-38 メディアサービス開発のためのコンポーネントベースのメディア処理モデル NTTSI研 入江

IVR,電話会議、留守番などをメディアサービスとして定義。メディアサーバ製品を利用して作られることが多い。今後のNGN開放でどうなるか?

デコ映話:今の気分を絵でオーバーレイ。ヘッドシミュレータ:  とかは既存のメディアサーバではできない。インターネットではできる。

メディア加工機能の組み合わせであたらしいサービスを!

メディア加工処理のコンポーネント化をはかる。たとえばmixer, multiplexer, switchなど。これらのAPI呼び出しGUI開発環境を提供する。

実現システム:万能メディアサーバを作るのではなく、ゲートウェイをつかって単機能メディアサーバを複数呼び出す。SIPできめてRTPで流す形。

今後:実装と測定、実用性評価

Q:どう分離するの?オーバーヘッドふえるだけでは。負荷分散にはならなそう

A:本当はすごいサーバがあるとうれしい

Q:負荷分散のためはかんがえてないの?

A:考えてない

Q:顔認識とかしてたけど考えてるの?

A:あれは例

とりあえずコンセプトだけに見えるな。SAINTで似たのを見た気がする。

B-6-37 NTTドコモ 桜井 複数プロファイルサービス

背景:一台のケータイに複数の番号をつけれるようになったので複数のサービス制御装置にまたがったサービス制御が必要になった

既存の方式:使用番号、端末、SCPが1-1-1。

契約情報と在圏情報は共通要素。

個別要素:設定情報

3つの解決法:1)全要素を各番号の収容SCPで保持する。同期する。2)参照方式:共通要素を契機にして基本番号収容SCPに問い合わせる。3)リルーティング方式:呼制御時に再問い合わせがあるが、リソースは効率化

今後CS通信とSMSだがそれ以外のPS通信などに対する本方式の適用

Q:創価大学:固定電話に電話番号を複数つけるサービスが昔あった。

A:参考にする

Q:座長:物理的なものと論理的なものをわければいいんじゃないか

A:参考にする

ちょっと前のドコモのテクニカルレポートにあった内容そのままかな。

B-6-36 動的ユーザコンテキスト利用サービスのためのロケーション情報記述形式 NTT network service systems lab 小川さん

背景:NWサービスの多様化に伴い、様々な状況においてサービスを利用する機会が増加

検討方針:多様なユーザ情報を統合的に管理する。

関連技術:foaf, 位置場所属性はユーザ状況記述における主要属性である。今後Geocodingなどの座標変換技術が重要になると想定。これらの技術を有機的に連携させる

ユーザ情報の記述:has_a, belongs_toを意識した管理。

rarr: room and room relation というのを提案。場所に様々な属性情報を付加。地図のような二次元情報+擬似的な三次元情報を与える。形式はRDF。ランドマーク 隣接 ニアステーション 移動方法など

実装:動的コンテキスト管理システム client layer, context mangement layer, resource layer

  • CML: RDF情報として保持
  • RL: センサDB

デモアプリ例:動的プレゼンス生成、センシング情報RSS,Context Visualizer(ユーザの状態や周囲環境を視覚的に表示)

ロケーションの付加情報としてmoodプレゼンス(IETF)の適用を検討している。

今後はサービスを志向した語彙体系の拡張

Q:おれ:センサの語彙体系はやるの?

A:RDFで整理するレベルではやる

Q:ロケーションのスケールは?

A:人間がリンク関係を書いていくかんじ。いまのところは集められるものを集めていくというかんじ。人間が書く。

Q:セマンティックが重要なんでは

A:いまのところフォーマットだけを考えている

B-6-35 統合レジストリの研究開発 NTTコミュニュケーションズ 田原聡士さん

背景:地域情報化プラットフォーム 自治体とそこの住民支援。自治体間の統合もある。たとえば転居のときの面倒さがなくなる。

課題:デザインパターン生成技術、サービスレジストリの管理制御、プライバシ、サービスモニタリング ということで情報通信研究機構から委託研究

概要:レジストリとエージェント

流れ:

  1. サービスをレジストリに登録
  2. 利用者が検索
  3. 合意交渉
  4. サービス利用(サービス間で共有できるようなものはエージェントがかわりに提供するのもある)

エージェントの例:暗号化、ロードバランスなどの使いまわしできるもの

UDDIと合意交渉レジストリからWSを自動生成する。利用者やサービスはSOAPでつながる。

今後:合意項目の追加、レジストリ+エージェント+サービスの構成、レジストリの管理すべき情報はなんだろうか、実証実験

Q:利用者はエンドユーザなのか

A:住民というよりは、地域ポータルの管理者とか。サービス側も利用者になれる。一般住民がSOAPつかうのではなくてウェブサーバ経由。サーバがSOAP使う。

Q:合意の単位は?

A:合意の数はサービスと利用者の数だけありえるので構成を考える

Q:実際バリエーションないんじゃないか。システムの目標はどこにあるのか

A:まさに検討課題

BT-3-5 The Challenge Issues for IEEE 802.11s Standard (NICT, Azman Osman LIMさん)

802.11s D1.06 draft standard準拠の話。ESS=BSS1+BSS2

APの上にのっかったMP。MP間ワイヤレスマルチホップで結果として802.11s Mesh Networkができる。Mesh Portal Pointがインターネットへの口になる、Mesh Point, Mesh Access Pointが他にあり。

802.11sはWDSを拡張:automatic topology learning, dynamic path configurationあり。11e(QoS), 11i(Security)とも関係あり。

11sのヘッダ構成解説:

ここからチャレンジ

Multi-rate and Multi-Channel Operation: Unified Channel Graphがサムスンが出しているが、いまのところ1つだけ

Path Selection Protocol: Hybrid Wireless Mesh ProtocolとRadio Aware OLSR(RA-OLSR)

HWMPはモトローラRM-AODVベースのオンデマンド)シスコProactive

RA-OLSR

スケーラビリティ32MPに制限。他のMACとの関係が考慮されていない。複数のルーティングセットは併用できない。

Fast Handoff Scheme:proxy updateとかあるが。。

Mesh Deterministic Access:オプショナル

QoS and Security: マルチホップなので難しいが、SoftQoSということでやっている

Mutiple MPP: 現在は一つだけしか使えないが

そのほか:link quolity 測定とか、Intra-mesh congestion control, Synchronization using beacon frame is optional in 802.11s, multicast(どう使うかもまだわからない、今は言葉だけ書いてある)

タイムライン的には2008にはでてくるかな

NICTとの協力:日本ではnict+ATR+新潟大学+沖電気 STM,サムスン、Kiyon, UCLA, Cisco, Fujitsu

Q:Shortest Path Firstは考えているか? 

A:いろいろ考えている。パワーセーブモードを考えたりもしている。ホップ数だけではなく、無線の環境を利用して決めようとしている。