Minutes of Meeting
Internet of Thing Working Group
17th March 2013
Chair: Balamuralidhar, TCS
1. Introduction by Chair
welcomes all participants
recap if work done within the WG
Reference architecture
usecases: potential of identifying opportunities in standardization
Reviews the TR on interface capabilities, baseline requirements, desirable requirements optional
now looking for proposals and contributions to continue with the technical specifications.
discussions ongoing on few contributions. IoT security related contributions,.
Lightweigth protocols, identity mechanism for IOT applications. some good contributions on
device management aspects.
we actively pursue the agenda with participants to contribute to the stack specifications.
also focus on one vertical application as a case study and validation
one candidate application : Healthcare / Smart city
Timeline
Specification document first draftr 15,16
Prototyping GISFI 14,15,16
Spec. doc release GISFI 16
Action items from previous meeting
DOT M2M questionanire - Sivabalan organizing the reviews and inputs. KRishna for
coordination and review.
PEnding action items from previous meeting
-prototyping
- Focus group ad interim discussion towards formulation of an approach to healthcare
Krishna: relation with academic institute feasible. Prof. Inamdar should give inputs.
Last 2 meetings, intersted to keep the items open in future to proceed. Keep it within the
target.
proposal is it is not tractable items. it is not figuring in priority list.
Prof. Prithviraj : CDAC Chennai interested in this topic.
Suresh CDAC: submitted proposals to Govt. Women safety, rural areas and north east.
looking for mass deployment. there are prototypes. Looking at GISFI as consultant.
Officially collaboration is possible.
Bala: POC is basically based on discussion and joint development of standards. even if it is
used in some of the project and share the experience and jointly buid and enrich the
specifications, that is also good. not required to do framework.
cross referenceing is possible on how the specification is being used.
Krishna: Take this proposal forward through formal letter to CDAC proposing as this is
what the wG is doing and relavant to the project you are doing. Let Suresh take it up
internally and arrange GISFI-CDAC meeting.
Agenda:
Dr. Parikshit Mahale "Identity management for IOT"
Efficient, Attack resistent and lightweight methods
Decision theory based device classification
need of context management in IOT.
Device classfication
Idm FRamework and context management was discussed.
Bala noted that naming and addressing is a very key area. some of the research utcomes of
Dr. Mahalle can fit with that. how to trust a sensor, how to trust a sensor data.
Contribution on Lightweight security for IOT : Arpan PAL
Platform arachitectural layers
RIPSAC: real time integrated platform for services and Analytics
use case: intelligent transportation
I2 interface: lightweight appplication protocol - COAP
home energy management
ubiquitous healthcare - patient monitoring
HTTP vs COAP vs MQTT
HTTP consumes 10 times more bandwidth and has 19 times more latency than COAP for
same payload and network condition
IETF-COAP proposal
The proposal is accepted as a WG work item
Secure COAP - MOTIVATION
COAP currently considera DTLS as option. LArge overhead, PKI nased, Symmetric key
cryptosystem needed for suitable applications
Authentication very important. Secure COAP - proposal "Authlite"
AES symmetric based authentication with integrated key management
thanks all
security and cryptosystem must eb chosen based on requirement.
sensor to gateway and gateway to cloud. the second interfaceis more vulnerable.
tiny os and others are sensor stack.
bala: 3 meetings back ECC based identity based encryption technique. ECC algorithm in
lightweigth fashion by modifying prime number payers based ona logic. if the no. of
computations reduced then usable in Id. based encryption scheme.
anand: what is the second requirementArpan: authentication and encryption
anand: you require integrity protection
Bala: this is a contribution idea, need to develop it further and request to bring for next
meeting
mahale: ECC is heavy on reqource constrined device. shift this computation to a more
powerful device.
bala: there are vulnerabilities if you split coputation
suresh-cdac: AES 128 bit if in future upgrade requirement what are the challenges
anand: what is the proposal?
bala: integrate as ts..
arpan: 2 parts i2 interface COAP, Authlite on top of COAP.
Modified COAP useful when server overload small packets.
Krishna: IETF proposal can be given as GISFI contributions.
Arpan:W3C OGC is also very active in this IOT field for geospacial applications. standards
kind of recommended by W3C and will go to ITU T.
TCS member og OGC consortium. internet and IOT part of IOT will be taken care of there.
Krishna: would be good to establish these relationship with these organizations. intent to
work together and areas for potential contribution.
-----------------------------------------Sivabalan, NEC
Device management in IOT
last spoec on i2 interface. this one on i1 interface
how to manage the device.
relate to last speaker: how to monitor a bus?
this contribution aims to reduce the data traffic when not required.
intelligent function in gateway to effectively manage the data traffic.
functionality I1b needs control signal handler
dynamically tune the ADC etc.
need not communicate always. like 2 way or 1 way.
adaptive data sampling.
protection system for higher layers.
Trigger from application, Trigger by the user, Trigger generated by intelligent functionality
Control Signal format example : proposal to be introduced
Bala: configuring the sensor device for operational parameters proposal specific format that
can be used for that =kind of a device configuration/management
Siva: one of the requirement in the technical report for configutration.
Bala: any qns / comments
Krishna: limitations on gateways for adaptability?
arpan: sometime programming the intelligence in the system
may be complex.
krishna: gateway can have different capability. we dont want to load the gateway too much.
so use this capability. some gateways may have this function / some may not have this
function. gateway also needs to be configuration..not always high capability..wherever high
capability required, you can use it.
bala: probably that can be an addiotnal requirement. more dynamism in end sensor device.
framework need to have a capability to configure that. communication only half dupex/
sporadic like RFID etc . but still from standards perspective there should be an API to do
this configuration. coming to the gateway, we didnot find a application that required a
reconfigurable gateway. if new use cases are defined these can be included in the
requirement document. probably consult the work from OMA..DMS is directly under that
topic. other place also people not much looking into that and directly adopting. Is there a
specific novelty that OMA has not looked at. second thing, sampling frequency , ADC
resolution can be two such parameters. how many such parameters can be configured.
probably more such parameters can exist. number of parameters can be configurable for
future adaptation like voltage etc.
Arpan: horizontally across sensors parameters can change, how do you want to take care of
that in a n automated or machine executable way. where is the placeholder to mandate this
kind of information to be put.
seensor registration also should be specified. all the information of configuration should be
included in the registration.
Krishna: in the format, what is the requirement for 32 bits
Siva: to differentiate between channels to be used
Bala: 2 contributions in this meeting. can we accept this work in the specification? any
uggestions
These two contributions can be included in the specifications
Ramjee: what document to present to outside world
Bala: with this inputs to the workgroup is competed. what is the roadmao? plan for next
meeting suggestions.
krishna: scan through m2m presentation
bala : we will circulate that. each requirement, bring possible solutions---TS and release it.
2nd approach - IOT security proposal can be drafted by next meeting.
anand: put both proposals and check right way to proceed.