Re: [6tisch] Comment to draft-wang-6tisch-6top-coapie-01.txt

[Tero Kivinen <[e-mail]>]

Alexander Pelov writes:
> For me the ideal solution would be if one of the 16 payload types could be
> allocated to CoAP. This way, we could use it for 6TiSCH and long-range,
> low-rate WANs. However, this would provide for a generic, extensible mechanism
> of operating these networks. Adding too much overhead (not sure how many bytes
> 802.15.9 takes) would make it impractical for LR-WANs.

If the message fits in the single frame (i.e. is less than 100 octet
long, when using PHYs with 127 octet max frame length), 802.15.9 adds
following overhead:

 * Normal MAC header
 * 2 octets for the Header Termination 1 IE
 * 2 octets for the MP IE Payload IE header
 * 1 octet for transaction control
 * 2 octets for multiplex ID (may be omitted in future for some IDs)

And thats it, i.e. 1-3 octets, I would expect it to go to 1 for CoAP.

If specify your own Payload IE, you might save 1-3 octets, depending
how you specify the IE. To support fragmentation you most likely need
at least one octet to specify whether it is in use (== transaction
control), and then you are at the same as 802.15.9.

When the frame is larger than what PHY support the overhead is:

For the first frame:

 * Normal MAC header
 * 2 octets for the Header Termination 1 IE
 * 2 octets for the MP IE Payload IE header
 * 1 octet for transaction control
 * 1 octet for fragment number
 * 2 octets for total frame size
 * 2 octets for multiplex ID

For the following and last frame

 * Normal MAC header
 * 2 octets for the Header Termination 1 IE
 * 2 octets for the MP IE Payload IE header
 * 1 octet for transaction control
 * 1 octet for fragment number

I.e. 6 octets for first frame, and 2 octets for following frames. 

> On the packet fragmentation, I like the approach taken by the 802.15.4k LECIM
> group, which introduces a new type of frame - 110  Fragment Frame - and sends
> the full 802.15.4 MAC header only in the first frame (context establishment -
> some other info is added also).

That fragmentation was completely broken, and cannot be used in
general cases. It has been removed from the generic MAC parts, and
moved to the LECIM PHY description, and it is now specified as PHY
layer fragmentation, i.e. it is below MAC and only works with LECIM
PHY. 

> Afterwards, the set of fragments is identified only through a 7 bit
> identifier assigned by the sender. In each consecutive fragment,
> only a 2 byte MAC header is included (3 bits frame type (= 110), 7
> bits frame ID, 6 bits frame counter). Extremely efficient in terms
> of overhead (e.g. MAC addresses are sent only during the context
> establishment), and particularly well adapted to infrastructure
> networks. Not sure if it would fit all 6TiSCH scenarios though.

It does not really work in general cases. The transaction id (TID) is
only 6 bits, and as there is no addresses, if two devices talking to
each other at the same time pick the same TID, this will mess up the
whole transaction for both. There was also lots of other things broken
in it... 
-- 
[e-mail]