[wi-sun rlmmwg] Discussion on Frame Format

Wed Sep 16 19:49:06 PDT 2015

Dear RLMM WG members,

In the RLMM WG TC today, there was a question asking for example of 
Command in NWK layer. One of the example of Command in NWK layer is the 
HELLO frame described in the proposal from Fujitsu which we shared in 
the call on Aug. 27th. The slide is available from here and HELLO frame 
is described in page 8 and 9: 
https://dms.wi-sun.org/htcomnet/Handlers/Download.ashx?action=download&file=M2MIG%2F20150827%20RLMM%20WG%20FUJITSU_DFF.pptx

Best regards,
Ryota

On 2015/09/17 11:37, Ryota Yamada wrote:
> Dear Ben-san,
>
> Thank you very much for your input. I will put my response between lines
> below.
>
>
> On 2015/09/11 12:56, Benjamin A. Rolfe wrote:
>> 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?
>
> In the first version of the Wi-SUN RLMM ProfileTechnical Specification,
> we just support single hop star network. In this case, the 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?
>
> In the first version of the Wi-SUN RLMM ProfileTechnical Specification,
> we do not support IPv6 and 6LoWPAN. In future version, when we add
> support for 6LoWPAN, we may put different value in this part.
>
>
>> 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.
>
> We would like to distinguish "Data" and "Command" in NWK layer. In my
> understanding, the frame type field in the MHR is intended to be used
> for distinguishing data and command in MAC layer.
>
>
>> It also  seems that these conditions are mutually exclusive
>> and  so a single bit could be used to  differentiate.
>
> In the current version of the draft, there are three different type of
> drames:
>   - Data Frame
>   - Command Frame
>   - Command Response Frame
>
> To distinguish these three, 2 bits are used.
>
> However, as there are no strong requirement to distinguish Command Frame
> and Command Response Frame in RLMM Dispatch, we will change to use only
> 1bit as you suggested to distinguish mutually exclusive Data Frame or
> Command Frame. Command Response Frame will be handled as a Command Frame.
>
>
>> 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.
>
> Thank you very much for your suggestion.
>
>  From the viewpoint of distinguishing protocols, it is expected that
> RLMM Dispatch will work. As RLMM is intended to support low power
> consumption and limited devices, it is preferred to keep overhead as low
> as possible.
>
> Now we are having discussion and some members need more time to
> consider. I will share discussion through e-mail reflector and if you
> have any further comment or suggestion, please let me know.
>
>
>> Hope that these comments help!
>
> Thank you very much.
>
> Best regards,
> Ryota
>
>
>> 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
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> rlmmwg mailing list
>> rlmmwg at wi-sun.org
>> https://lists.wi-sun.org/listinfo/rlmmwg
>>
>> Copyright (C) 2014 Wi-SUN Alliance. The contents of this email are
>> confidential and may not be disclosed to non-members without prior
>> written consent of an authorised representative of Wi-SUN Alliance.
>>
>

-- 
+--------------------------------
| Ryota Yamada <ryamada at ari.ncl.omron.co.jp>
|
| OMRON Corporation
| Technology Marketing and Development Center
|
| Tel: +81-774-74-2158 (Ext: 7-232-6558)