<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Hello Ryota, all<br>
I am sorry I have not been attending the RLMM teleconference calls
and so some of my questions may have been answered during
discussion, but for the chance that it helps I will offer them
here.<br>
<br>
Addressing: It appears that the RLMM header always contains a
destination and source address. Is there a case (single hop?)
where these address values would be identical to the addresses
contained in the MHR? <br>
<br>
The first 2 bits of the dispatch appear always set to NALP in the
figure as no other values are specified. Are there to be other
states?<br>
<br>
We have 2 bits to signal that a frame is a command frame or a data
frame. I am possibly confused by the use of "data frame" and
"command frame" as there is a frame type field in the MHR that
distinguishes between data frames and command frames. I am not
sure if this is meant to echo what is in the MHR or is it is
intended to signal something different. It also seems that these
conditions are mutually exclusive and so a single bit could be
used to differentiate.<br>
<br>
General comment on dispatch: There has been quite some history
of discussion on protocol differentiation with 802.15.4 MAC
payload content. The general issue arises when there is a
reasonable expectation that some devices may be in the same radio
SOI are not running the same higher layer protocol and so it is
likely that valid MAC frames may be received that contain payload
field content which does not include the "header" you are
expecting, a condition not detectable without some common
signalling mechanism between "your" protocol and the "other"
protocol. One solution which has come out of the 802.15 Working
Group and been adopted by the Wi-SUN FAN specification is to
encapsulate the differentiated protocol content in an Information
Element which includes a standardized means to signal
differentiated protocol. The advantage of this method is that a
device that does not implement the IE will of course never
generate a frame containing it. The disadvantage is 3 octets of
overhead to encapsulate the content. <br>
<br>
Hope that these comments help!<br>
<br>
Ben<br>
<br>
</font>
<div class="moz-cite-prefix">On 9/10/2015 5:30 PM, Ryota Yamada
wrote:<br>
</div>
<blockquote cite="mid:55F2208F.40800@ari.ncl.omron.co.jp"
type="cite">Dear RLMM WG members,
<br>
<br>
In the RLMM WG TC yesterday, I shared two discussion points
regarding frame format. From page 7 through 9 in the slide which
we used yesterday, the discussion points are summarized. The slide
is available from here:
<a class="moz-txt-link-freetext" href="https://dms.wi-sun.org/htcomnet/Handlers/Download.ashx?action=download&file=M2MIG%2F20150910%20RLMM%20WG%20TC%200v00.pptx">https://dms.wi-sun.org/htcomnet/Handlers/Download.ashx?action=download&file=M2MIG%2F20150910%20RLMM%20WG%20TC%200v00.pptx</a><br>
<br>
If you have any question or comment, please let me know. If you
provide your feedback by the end of Sep. 16th (Wed.) JST, that
will be very helpful for discussion in the next call to be held on
Sep. 17th (Thu) JST.
<br>
<br>
Best regards,
<br>
Ryota
<br>
<br>
<br>
</blockquote>
<br>
</body>
</html>