Linux IEEE 802.15.4 and 6LoWPAN development
 help / color / mirror / Atom feed
From: Robert Moskowitz <rgm-ietf@htt-consult.com>
To: Don Sturek <d.sturek@att.net>,
	Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Alexander Aring <alex.aring@gmail.com>,
	linux-wpan@vger.kernel.org, 6lo@ietf.org
Subject: Re: [6lo] big frame support in 802.15.4G
Date: Mon, 7 Mar 2016 16:06:32 -0500	[thread overview]
Message-ID: <56DDED58.5060500@htt-consult.com> (raw)
In-Reply-To: <D302EF45.3625F%d.sturek@att.net>

I was thinking that there is also some difference in the physical header 
to support the larger PPU?

On 03/07/2016 11:53 AM, Don Sturek wrote:
> Hi Michael,
>
> I was not clear on what you were asking.  Here are a couple of points:
> 1)  IEEE 802.15.4g was an amendment to IEEE 802.15.4-2011 where the main
> contributions were to the PHY (not so much the MAC).   There is nothing in
> 4g that would make it incompatible with IEEE 802.15.4-2011
> 2)  IEEE 802.15.4-2011 has a field called "frame version" that denotes
> special processing for the 2003, 2006 and 2011 versions of the
> specification.  That is one place where a packet may be dropped but that
> would not apply to MAC versions that are based on 2011 alone
> 3)  If you were asking whether a 4g MAC/PHY implementation could send
> payloads of varying sizes then I think the answer is "yes" with the
> following caveats:
>        I.     Since IEEE 802.15.4 never had a propoer protocol dispatch
> until IEEE 802.15.9 came along, there would have to be some special vendor
> extensions to denote where a full IPv6 frame was present or when a 6LoWPAN
> fragment was present.  It is possible with the Multiplex ID/EtherType in
> IEEE 802.15.9 to make that distinction.
>
> I think in some implementations you would see a varying payload size.  For
> example, when transferring packets over a good radio link, the payload
> size might be set to 1280 bytes or better and a full IPv6 frame would be
> present.  In cases where the link is poor, the two communicating devices
> may choose to use shorter packets and 6LoWPAN to fragment/reassemble,
> however, keep in mind there are only MAC retries to ensure delivery.
>
> Don
>
>
>
>
> On 3/7/16 8:25 AM, "6lo on behalf of Michael Richardson"
> <6lo-bounces@ietf.org on behalf of mcr+ietf@sandelman.ca> wrote:
>
>> Robert Moskowitz <rgm-ietf@htt-consult.com> wrote:
>>     > The difference is in the header bits. A 802.15.4-2011 device would
>> see
>>     > the bits set in the header that 4g uses and drop the packet
>>     > immediately. Pat would have to pipe in here, and there may be some
>>     > issues around super frames and intergap timings that result in
>>     > interesting behaviour, better to be avoided.
>>
>> Right, but the question is:
>>
>> 1) is it physically possible for a 15.4g device to send both 15.4g
>>    frames and 15.4-2011 frames?
>>    Another email suggests that this can never happen because frequencies
>>    are never the same.  If so, end of problem.
>>
>> 2) if the answer to question 1 is yes, then 15.4g devices need to know
>>    if they are speaking to 15.4-2011 devices, and
>>       a) adjust their frame header bits appropriately.
>>       b) to 6lowpan fraglettation.
>>
>>
>> --
>> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>>
>>
>>
>> _______________________________________________
>> 6lo mailing list
>> 6lo@ietf.org
>> https://www.ietf.org/mailman/listinfo/6lo
>


  reply	other threads:[~2016-03-07 21:06 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-25 18:22 802.15.4G support? Remi Philippe
2016-02-28 14:07 ` Alexander Aring
2016-03-01  9:17   ` Stefan Schmidt
2016-03-03 14:26   ` Michael Richardson
2016-03-04  8:35     ` Alexander Aring
2016-03-04 15:52       ` Michael Richardson
2016-03-04 16:37         ` Alexander Aring
2016-03-04 20:16           ` Michael Richardson
2016-03-14 15:34             ` Stefan Schmidt
2016-03-14 23:11               ` Michael Richardson
2016-03-15  5:19                 ` Remi Philippe
2016-03-30  8:54                   ` Stefan Schmidt
2016-03-30 17:18                     ` Remi Philippe
2016-03-30 21:00                       ` Stefan Schmidt
2016-03-04 20:30           ` big frame support in 802.15.4G Michael Richardson
     [not found]             ` <56DC2A0A.6070906@htt-consult.com>
2016-03-07 16:25               ` [6lo] " Michael Richardson
2016-03-07 16:53                 ` Don Sturek
2016-03-07 21:06                   ` Robert Moskowitz [this message]
2016-03-08  8:22                     ` Alexander Aring
     [not found]                       ` <CADrU+dKHiNd2xW0Nd=ZWJCAZQ_PbWXwNFo_V2u4nd7A_ccfwCw@mail.gmail.com>
2016-03-08 14:13                         ` Michael Richardson
2016-03-08 14:17                         ` Michael Richardson
2016-03-08 14:09                     ` Michael Richardson
     [not found]           ` <CAH+RWqFmxcNxtzTjkcR+Z3dmCdkB5HU-=668rmXMiVaDVZUymg@mail.gmail.com>
2016-03-06 10:17             ` 802.15.4G support? Alexander Aring
2016-03-01  9:15 ` Stefan Schmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56DDED58.5060500@htt-consult.com \
    --to=rgm-ietf@htt-consult.com \
    --cc=6lo@ietf.org \
    --cc=alex.aring@gmail.com \
    --cc=d.sturek@att.net \
    --cc=linux-wpan@vger.kernel.org \
    --cc=mcr+ietf@sandelman.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox