See also: IRC log
Johannes: 3 topics on the agenda. Report on joint meeting with IRTF. Invitated talk from Sensei group. Then talk about Bluetooth profile.
[Johannes projects the report]
Johannes: meeting at IETF93 in
Prague. Joerg presented the work of the WoT IG. Heard about
work done in IRTF.
... Discussions on network management for radios and other
topics.
... as well as on the architecture we've been discussing so
far.
... Then breakout session where I gave a report on our progress
in that Task Force so far.
-> https://github.com/t2trg/2015-ietf93/blob/master/slides/21-joint-meeting-TF-AP-report.pdf Slides
Johannes: I presented the
patterns. After the F2F, when we agree on these patterns, I'll
convert them to UML and put on the Wiki.
... Focus area on providing APIs and protocol mappings that
make up the thing model.
... Brief introduction of our use case document. Introduced
building blocks that work across domains.
... Then technology pick and metric for selection together with
non-functional requirements.
... The Web Thing Model is a discussion we've been having for
some time now.
... The current agreement is that we have events that allow a
user to listen to changes.
... Then actions to operate the thing and properties.
... Then I presented the problem statement to observe things
from CoAP, as well as HTTP.
... Solution must include the possibility to subscribe to
things, where we can put things such as frequency
thresholds.
... There was agreement on the approach.
... The outcomes of these discussions are:
... 1. Formal description draft for the RESTful approach
... 2. Focus on a specific scenarion to have some kind of black
test in a future meeting to see what we need to interact with
these things.
... 3. A cookbook or best practices document on implementing
RESTful APIs
... The minutes are public on GitHub.
-> https://github.com/t2trg/2015-ietf93 IETF93 slides and minutes
Johannes: I think the cookbook
document is really good input for us. It gives a good
impression as to the intents of this RESTful modelling.
... Questions?
Kazuaki: In the architecture
model, section about Bluetooth and legacy devices. The
assumption described the GATT API, so presenting what GATT
is.
... There is a Bluetooth Core spec 4.2 (more than a thousand
pages) which defines GATT.
... GATT defines two roles for the server and client. GATT
accomodates services and associate behavior and functions with
the devices.
... Two types of services: primary and secondary, depending on
the functionality.
... The primary functionality should be contained in a primary
service with only one instance exposed to the GATT
server.
... [presenting the GATT-Based profile hierarchy]
... The point is that capabilities can change based on the
profile
... So far, the profile could not be changed.
... The Web Bluetooth Community Group at W3C is developing a
specification based on the GATT profile.
... There is already a version available. The spec is based on
BLE (low-energy) provided through GATT
Johannes: Thank you
Nimura-san!
... The GATT profile allows you to map a REST architecture into
Bluetooth, is that correct?
Kazuaki: to some extent.
Key/value pairs is possible.
... Some more thinking needed.
Johannes: possible to have retrieve/update key/value pairs?
Kazuaki: yes.
Johannes: is there a way from the server to actively notify a client? A pub-sub model?
Kazuaki: servers as clients mean
a device. It is much more primitive than the server you might
have in mind.
... GATT only deals with devices.
Johannes: A device usually has both client and server implementations?
Kazuaki: Usually, a device has server capabilities.
Johannes: I will add this to out landscape document, thanks!
[William presenting slides on Sensei/IoT]
William: Chairman of join effort
between ISO/IEC/IEEE on transport shipping.
... Our group is called P21451-4, a.k.a. Sensei/IoT
-> http://sensei-iot.org Sensei/IoT
William: One of the things that I
will keep mentioning today is XMPP. We're all using XMPP, e.g.
in WebEx right now.
... In the evolution of the Web, we're sort of at Web 2.0 based
on HTTP. As we're moving to Web 3.0, more semantic interactions
arise.
... We're moving towards the "Intelligent Web" (Web 4.0).
... The XMPP protocol, maintained by the XMPP Standards
Foundation, was developed way back in the 90s by the Jabber
Foundation.
... Many IoT protocols [presenting a short relevant list]
... We have to work with these different protocols.
... Our standard is making use of various other
standards.
... Our working group is co-sponsored by Kang Lee, NIST, and
Dan Kimball, SRA from IEEE and ISO/IEC respectively.
... About the unique identification: based on the JID (Jabber
IDentifier) used in XMPP. It looks more like an email.
... It adds a layer of security and authentication.
... Also the possibility to define additional resources on that
identifier which hasn't be used a lot by people using XMPP up
until now.
... This allows to identify Things with a globally unique
ID.
... Sensei/IoT is technology agnostic and protocol independent.
It makes use of TLS, built into the protocol to encrypt the
data traffic. The XMPP protocol is also
firewall-friendly.
... The XML in the XMPP is used for conversation between the
devices.
... The technology can use a Service Broker as intermediary to
share data between devices, applications, users.
... Lots of different security aspects.
... Meta data isolation protects against cyber-attacks.
... It can be used to map to legacy protocols and offer
additional protections.
... There are extensions known as IoT XEPs.
... [showing a list of extensions]
... I'm only going to touch on a subset of these extensions,
but will pass them over to you.
... One of the key things that we recently added, as requested
by IANA, is a new URI scheme
... This completes the unique id of the Thing. There will be
things registries across the planet where you can learn about
things.
... [showing an example of a discovery request]
... Through discovery, you can ask whether the service supports
a particular set of features.
... The reply includes some flag about interoperability. We're
going to define what interoperability means when mapped to the
different existing possibilities.
... [showing an example of a request to a particular sensor
value]
... The request could have requested more than one sensor value
at a time.
... XMPP is a service-oriented architecture so can be used for
P2P communication.
... Scaling can be done into the cloud. With regular
technology, you would setup a VPN. With XMPP, you would end up
with a federated cloud architecture.
... It really doesn't matter what type of communication you
have to share information. We are able to bridge private clouds
and public clouds.
... Another block of our standard is IoT provisioning. Many
other systems are starting to support XEPs. You will be able to
download the libraries on our Website. When systems are
interconnecting, you can share your systems through UPnP, CoAP,
etc.
... TeliaSonera is deploying a system based on this.
... You'll be able to share HTTP over XMPP, so HTTP/CoAP
traffic can leverage the XMPP architecture.
... This can be used to communicate to services behind a
firewall for instance.
... You may not really whether the Web server you're
communicating with can be trusted, so requiring this server to
register will help. New URIs to appear in a near future for
that.
... EXI allow you to enable stream compression.
... EXI was another work done jointly with Japan.
... A final XEP that I'd like to introduce here is the
Concentrator which allows you to connect various sensors from
legacy systems (e.g. PLCs)
... For those familiar with industrial protocols, OPC UA can be
integrated through XMPP.
... A lot of people may be familiar with the P21451 family of
standards.
... Relying on these standards was really useful for our
work.
... Some parts are really impressive.
... e.g. the notion of "TEDS" which can be used for transducer
self-identification and description.
... The TEDS are used basically today in millions of devices
(e.g. in airplanes), although people are unaware of them.
... I'm going to stop there. You're welcome to join any of our
meeting. It's not a close group as opposed to regulary ISO/IEEE
groups.
Johannes: Thanks a lot for this
presentation.
... I see a lot of topic in common with what we're doing
here.
Joerg: Is your main focus about XEP specifications?
William: The document that we're
preparing is being added to the P21451-1-4 standard. Different
parts, some of them more ready than others.
... A number of the things I presented are new as well (to the
point that you may be the first ones to hear about some of
them)
... In many respects, although you can use these standards
directly, we see the main interest as providing the ability to
bridge between different protocols.
Joerg: We started with use cases on our side. Do you have some sort of use cases collection?
William: A lot of use cases were
there
... [showing some on the screen, to create an instant
infrastructure when there is none, also with transportation,
smart grids...]
... We started out with existing use cases.
... XMPP has facilitated the addressing of many initial
concerns related to security.
Johannes: you mentioned that one of your focus work is also on interoperability. Could the models and interactions you're using in XEPs be mapped to HTTP and other protocols?
William: Yes. The XMPP Concentrator is a separate part of our work that defines how to do the mapping. Useful for people such as TeliaSonera.
-> http://www.iot/teliasonera.com/ TeliaSonera provisioning server
William: working on the
concentrator as the part 3 document.
... Communication with an OPC server is commonly used today.
People are building these abstractions so that you can access
the XMPP data.
... I will send over the slides later today
Johannes: Thank you very much for
the presentation, William!
... Also thanks to Nimura-san for the GATT presentation and
Francois for scribing.
... See you next week at the F2F!
[Call adjourned]