Dear all,
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.
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). 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.
Best,
Alexander
Le 25/09/2015 12:31, Thomas Watteyne a écrit :
We need to discuss this point urgently, and do the work to ask the
IEEE for carve out some IE space for IETF/6TISCH if applicable.
On Thu, Jul 23, 2015 at 4:28 PM, Qin Wang <[email protected]
<mailto:[email protected]>> wrote:
Hi Pat,
Since there are two approaches mentioned in the discussion, i.e.
(1) containing 6top-to-6top message in a specific payload IE
(coapie), (2) using the mechanism provided by IEEE802.15.9 to
convey the 6top-to-6top message, I would like to do more
evaluation. I couldn't find the IEEE802.15.9 spec on IEEE802
website. Can you tell me how to get it?
Thanks
Qin
On Tuesday, July 21, 2015 8:59 PM, Tero Kivinen <[email protected]
<mailto:[email protected]>> wrote:
This draft plans to put the coap messages directly on the payload IEs
in the 802.15.4. The problem is that we only have 16 payload IE types
in total for 802.15.4, so reserving one number for coap might be hard.
On the other hand IEEE 802.15.9 needed to have solution to this same
problem, i.e how to multiplex upper layer data packet over 802.15.4
frames and how to fragment them so they can fit on the 802.15.4
frames.
The 802.15.9 is split in two layers, first one is the multiplexed data
service, which takes 16-bit MultiplexId and the data packet to be sent
to the other end, and it will fragment and deliver it to the other
end. The MultiplexId is used to separate different protocols using
this mechanism. One of those protocols is the key management protocols
providing KMP for 802.15.4, which is the second part of the 802.15.9.
Instead putting the coap messages in the payload IEs, it would
possible to allocate one MultiplexId for coap messages, and then coap
messages could be transmitted using multiplexing layer of 802.15.9.
This would also take care of fragmentting the messages (with PHY using
127 octet PSDU, the maximum size of the data packet is around 24kB).
The 802.15.9 recommended practice is already past the working group
letter ballots, and is starting its sponsor ballot soon. It is
expected to come out around the end of year. The draft will be
available on the ieee document store after the sponsor ballot starts,
i.e. very soon.
--
[email protected] <mailto:[email protected]>
_______________________________________________
6tisch mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
