W3C

- DRAFT -

WoT Protocol Mapping - Ideas based on Gateway Model Breakout

9 Nov 2015

Attendees

Present
Kazuo_Kajimoto(Panasonic), Kaz_Ashimura(W3C), Claes_Nilsson(Sony), Matsuki_Yoshino(Hitachi), Ryuichi_Matsukura(Fujitsu), Kunihiko_Toumura(Hitachi), Shinichiro_Chiba(Sharp), Takeshi_Kutsuno(SoftBank), Riko_Yagiu(Observer), Masami_Matsubara(Mitubishi_Electric), Yoshiyuki_Kato(Mitsubishi_Electric), Ari_Keraenen(Ericsson), Yukio_Tada(AMEI), Sangjo_Park(LG_Electronics), Toru_Matsushima(Panasonic), Katsuhiko_Hiramatsu(Panasonic), Dave_Raggett(W3C), Masato_Ohura(Panasonic), Peter_Winzell(Mitsubishi_Electric), Saki_Homma(NTT), Yoshiaki_ohsumi(Panasonic), Kosuke_Nagano(ACCESS), Masaru_Kurabayashi(Yahoo!_Japan), Keisuke_Minami(Toshiba), Bill_Rose(Comcast), Katsuyoshi_Naka(Panasonic), Yasunori_Seto(Panasonic), Yoshikazu_Ishii(Panasonic), Toru_Kawaguchi(Panasonic), Joerg_Heuer(Siemens), Fumitaka_Watanabe(Tomo-Digi), Hiroto_Inoshita(Keio), Andrew_Hutton(Unify), Milan_Patel(Huawei), Tomohiro_Yamada(NTT), Hironori_Tanaka(Panasonic), Jean_Michel_Rouger(Orange), Lyo_Kato(Recruit), Shoko_Okuma(Tomo-Digi), Louay_Bassbouss(Fraunhofer_FOKUS), Taketoshi_Yamane(Sony)
Regrets
Chair
Yoshikazu_Ishii
Scribe
kaz

Contents


<scribe> scribenick: kaz

Opening

opening remark from Mr. Yoshiaki Ohsumi, the AC Rep. from Panasonic

WoT Servient Mapping Models (Kazuo Kajimoto)

kajimoto-san goes through his slides

kazuo: Hub-centric model is already implemented
... another is Cloud-centric model

Web of Things mapping ideas based on gateway model (Kawaguchi)

kawa: various products connected with several existing protocols
... e.g., Echonent, ZigBee, dlna, allseen, knx, ...
... using multiple protocols cause higher costs
... safety, security and robustness
... risks of connected home include privacy leakage, hazardous operations
... would enable emergency operation in case of disaster
... possible solutions
... 1. gateway model
... 2. Wot API mapping
... defining WoT API absorbing the device difference
... service examples
... immediate control any device from anywhere
... using various underlying protocols
... second example is reducing electric power consumption
... by demand response
... third example is automatic adjust
... choosing preferred options based on who is staying at home
... Demonstration
... components of the demo
... - WoT client, WoT server in the cloud, home gateway, Things (air conditioners)
... remote access using a smartphone app
... lights and air conditioners
... shows the actual interface data for the demo
... things description written by JSON-LD
... device can be controlled using this mechanism
... next demo is notification of energy consumption
... can turn on/off based on the notification
... next is personal adaption
... personal preference can be handled by this system
... we have some more scenarios
... please come to the demo booth at the entrance of the demo hall
... and see our demos
... Conclusion
... let's work together!

claes: question
... configuration of the home gateway

(p10: 2-2. Solution 1: Gateway model)

claes: handling underlying protocols
... how the server talks with the home gateway?

kawa: now using HTTP for the communication

claes: and the local server communication is also HTTP

kawa: yes

claes: what is done by the gateway
... and what is done by the server?

kaji: thing description is described at the gateway

ECHONET Lite example (Naka)

naka: used for various services
... object-orient model
... ECHONET is an international standard
... air conditioner has several capabilities
... those capabilities are modeled using the object model
... can be used for the WoT API

Discussion

ishii: comments, questions?

dsr: structure of the mechanism?

kaji: suffered from various legacy protocols
... WoT API could be a wrapping mechanism for the legacy protocols
... WoT API is a very high-level abstract interface

joerg: you can break down into different aspects
... different interaction models
... notion of what the semantics is like
... more tricky part
... manage using some kind of dictionary?
... we WoT IG is thinking of Thing Description
... and would split the issues

<dsr> Set of high level messages for the Web of Things abstraction layer, e.g. property update, event, action, response, register proxy for a thing, unregister proxy, and so forth.

kaji: there are many legacy protocols
... the functionality depends on the air conditioners model type

<dsr> ... some airconditioners only provide cooling not heating

kaji: common API can be defined regardless of the types

louay: regarding this picture
... (hub-centric vs cloud-centric)
... might want to think about sense vs service
... accessible services

kaji: current legacy protocols are designed for each device
... user experience is very important as you mentioned

<dsr> … by its manufacturer

joerg: claes already touched but
... even the first f2f had some discussion on the architecture
... how to connect basic legacy devices
... the model using servient
... our issues are already captured by these models?
... or something missing?

kaji: a bit confusing
... implementations of current Panasonic products
... gateway provides the functionality of WoT servient
... we must provide cloude-based APIs
... a WoT servient is implemented withing the Hub (gateway)

joerg: virtual representations
... not up to the implementation decision?

kaji: regardless of the actual implementations

<dsr> Implementation decision as to whether things are placed in cloud, gateway or the home devices

nagano: what the TD would return?
... what kind of TD?

<dsr> (does this depend on whether the thing is in the cloud, gateway or device?)

nagano: if the GW function handles multiple devices
... what kind of TD will be sent as the response?

kaji: some specific session is created for each communication
... between devices

<dsr> [Dave thinks the thing description can be the same, but the communications metadata may vary according to which server hosts the thing]

kaz: so the GW function handles multiple connections using some identification mechanism like IPv6

kaji: yes

<dsr> Note that a device inside a firewall can register a proxy in the cloud by which others can find and interact with that device.

[ adjourned ]

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2015/11/09 08:24:21 $