<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>