Re: [6lowapp] Fwd: New Version Notificationfordraft-shelby-core-coap-req-00

["Charles Palmer" <[e-mail]>]

Dear 6lowapp team

Andreas suggests that knowledge shared by both parties can allow much
reduced message sizes: "I think a header format that allows omitting
information that is known a priori (e.g. from a subscription) is a
promising approach for reducing message overheads."

Has anyone looked at the approach adopted by the IEEE 11073 standards
for exchange of messages between Personal Health Devices and their
"Managers"? This transport-agnostic set of standards is designed to
connect a wide variety of wireless personal health devices and assisted
living devices - so far using Bluetooth and ZigBee but (who knows) maybe
6lowpan in the future. When I have time I will finish this Wikipedia
introduction article:
http://en.wikipedia.org/wiki/User:Acutetech/ISO/IEEE_11073_Personal_Heal
th_Data_%28PHD%29_Devices

IMHO the IEEE 11073 standards for Personal Health Devices could easily
be generalised to support any class of M2M device.

The IEEE 11073-20601 standard uses several techniques to reduce message
size, and to simplify "discovery" - these might be worth considering for
6lowapp. (The terminology is different but the problems are the same).
Two techniques are:

1	A personal health device ("Agent" in IEEE11073 parlance) may
either implement one or more standard configurations, or may implement
an extended (custom) configuration. When an Agent first associates with
a PC, smart phone etc ("Manager" in IEEE 11073 parlance) it states its
configuration code. Usually the Manager will already have knowledge of
the object model of Agents with this configuration code - either because
it was given this knowledge at birth, or because it has previously
associated with this Agent and has already learnt its object model. If
the Manager does not have knowledge of this configuration it asks the
Agent to describe its characteristics (by listing its objects).

The use of standard configurations, and the exchange of object models
when an Agent with a new configuration appears for the first time,
significantly reduces the exchange of data required when an Agent
associates with a Manager.

2	During this configuration phase the Agent and Manager also agree
one or more "attribute-value-maps". These pre-define the format of
subsequent data exchanges. The standard says this:

"The fixed format event report is optimized by defining the message
format in the Attribute-Value-Map of the object in a previous
configuration message before transfer commences. When an agent transmits
data in a fixed format event report, it shall report the object handle
and the attribute values in the same order and size as specified in the
Attribute-Value-Map. In this way, the overhead of sending attribute
identification and length in each event report is avoided. On receipt of
a fixed format event report, the manager uses the object handle to
retrieve the Attribute-Value-Map previously given at configuration time
to know how to extract the data."

Also - I don't know if it is too late to suggest that 6lowapp
reconsiders the merits of ASN.1 rather than EXI. IEEE 11073 has adopted
ASN.1 to encode messages for transmission. This allows for very simple
"canned" messages from constrained devices, in which the variable data
is inserted at defined offsets into fixed-format ASN.1 binary message
strings. ASN.1 is also used by DLMS - one of the smart meter standards.
A challenge: write practical implementations of EXI and ASN.1 encoding
and decoding routines in C, then compare the size and complexity of the
code, and of the message strings. 

Regards - Charles Palmer 
Onzo Limited (Project Hydra Project Manager) 
Woodthorpe, Calver Road, Baslow, Derbyshire, DE45 1RR, United Kingdom 
Ph: [phone], Mob: [phone] 
Email: [e-mail] Skype: Acutetech

--------------------------------
Onzo is a limited company number 06097997 registered in England & Wales. The    
registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom.

This email message may contain confidential and/or privileged information, and
is intended solely for the addressee(s). If you have received this email in     
error, please notify Onzo immediately. Unauthorised copying, disclosure or 
distribution of the material in this email is forbidden.
--------------------------------