[wi-sun rlmmwg] Discussion on Frame Format

[Benjamin A. Rolfe]

Hello Ryota, all
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.

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?

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?

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.

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.

Hope that these comments help!

Ben

On 9/10/2015 5:30 PM, Ryota Yamada wrote:
> Dear RLMM WG members,
>
> 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: 
> https://dms.wi-sun.org/htcomnet/Handlers/Download.ashx?action=download&file=M2MIG%2F20150910%20RLMM%20WG%20TC%200v00.pptx
>
> 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.
>
> Best regards,
> Ryota
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wi-sun.org/pipermail/rlmmwg/attachments/20150910/29795805/attachment.html>