Subject: [6lo] big frame support in 802.15.4G

From: Michael Richardson <[email-masked]>
Date: Fri, 04 Mar 2016 15:30:00 -0500

Can 802.15.4g with 2048 byte frames exist in an LLN along with nodes using
802.15.4-2012 classic 127 byte frames?

There are three questions embedded here:
1) are there radios issues that would prevent this from ever being an issue?

2) assuming that 15.4g radios can communicate with 15.4 radios, is there
   something that would permit one 15.4g radio to realize it was talking
   to another 15.4g radio at the L2 (frame) level?

3) if the answer to #2 is no, then is this akin to ethernet with jumbo
   frames, where the MTU (and fraglettation method) to each destination needs
   to go into the neighbour cache?

RFC4681 section 4.6.4 specifies an MTU value for the network as a whole
        in the RA.  https://tools.ietf.org/html/rfc4861#section-4.6.4

I thought that I'd see an option to put the MTU into the NA as well, but
I don't see that specified, so how can jumbo ethernet work today?
(maybe that's why it isn't on by default more often...)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Robert Moskowitz <[email-masked]>
Date: Sun, 6 Mar 2016 08:00:58 -0500

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.

Note that Wi-Sun devices all support the larger frame size, natch.

But is your radio environment one that will allow the larger frame size 
to work, or will they be lost in the industrial noise and you would be 
better off with the smaller frames.  Perhaps 10 small frames will all 
get through where one big frame would not.  4g was developed thinking 
about outdoors communication for smart-grid.

On 03/04/2016 03:30 PM, Michael Richardson wrote:
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: "Turner, Randy" <[email-masked]>
Date: Sun, 6 Mar 2016 15:04:37 +0000

The ZigBee NAN also supports 4g larger frames as well - specifically to address the IPv6 min MTU

R.

On Mar 6, 2016, at 8:01 AM, Robert Moskowitz <[email-masked]<mailto:[email-masked]>> 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.

But is your radio environment one that will allow the larger frame size to work, or will they be lost in the industrial noise and you would be better off with the smaller frames.  Perhaps 10 small frames will all get through where one big frame would not.  4g was developed thinking about outdoors communication for smart-grid.

--
Michael Richardson <[email-masked]><mailto:[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

_______________________________________________
6lo mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6lo

_______________________________________________
6lo mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6lo

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Mar 2016 11:25:13 -0500

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

---

From: Don Sturek <[email-masked]>
Date: Mon, 07 Mar 2016 08:53:28 -0800

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

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 7 Mar 2016 16:06:32 -0500

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

---

From: Alexander Aring <[email-masked]>
Date: Tue, 8 Mar 2016 09:22:08 +0100

Hi,

On Mon, Mar 07, 2016 at 04:06:32PM -0500, Robert Moskowitz wrote:
> I was thinking that there is also some difference in the physical header to
> support the larger PPU?
> 

I copy&paste here some parts which I already wrote in another mailing
thread:

---
Looking again into 802.15.4g-2012 there stands on page (not pdf page)
95:

"For the 780 MHz, 915 MHz, and 2450 MHz frequency bands, the MR-O-QPSK
 PHY supports communication with legacy devices according to the
 specifications in Clause 10, as described in 18.3.3."

so somewhat with "Clause 10" and at 18.3.3 the standard says:

"18.3.3 Support of legacy devices of the 780 MHz, 915 MHz, and 2450 MHz
 O-QPSK PHYs" ... the lot of copy&pasting witht the same sentences but
 different frequencies. :-)

Then looking into 802.15.4-2011 for Clause 10, the standard says:

"10. O-QPSK PHY"

so Clause 10, they mean all other PHYs. For me it looks like it is
possible to communicate with "legacy device according to the
specifications in Clause 10".
---

That means for me:

MR-O-QPSK is compatible with O-QPSK.

The question which follows is:
How 6LoWPAN for 802.15.4g devices deals with 802.15.4g and 802.15.4-2011
(legacy devices) in one 6LoWPAN network, if this handling is supported
somehow?

Is there some mechanism on for getting the capabilities "MTU" and
Modulation for each neighbor?

Then you could start always with a O-QPSK modulation and 127 bytes MTU,
if you know your 6LoWPAN network is a complete 802.15.4g only network,
then simple use 802.15.4g features.

If not: exist there some mechanism (Option-Field in NA) to see, this
neighbor is a SUN Phy and I could change the MTU/modulation for this
neighbor.

btw: for broadcast frames you should need then 127 bytes and O-QPSK
only.

- Alex

---

From: Robert Cragie <[email-masked]>
Date: Tue, 8 Mar 2016 11:12:48 +0000

It is possible for an 802.15.4g device using O-QPSK modulation and a
compatible channel to communicate with a legacy device, however it can only
use the PHY PDU format specified for the legacy device, i.e. up to 127. The
PHY PDU for the 2047-byte frame is different, with a different SFD and PHR.

So:

1) is it physically possible for a 15.4g device to send both 15.4g frames
and 15.4-2011 frames?

Yes, in theory. The PHY would have to support both the SUN-O-QPSK and the
O-QPSK PHYs, the intersecting frequencies, rates and spreading mode and
somehow be selectable on Tx and discriminate on Rx (accept both PPDU
formats)

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.

Yes, this would need to be known so the appropriate PHY can be selected.

There are obviously potential issues to be considered with PAN-wide frames
e.g. beacons etc. It is likely that legacy devices would only really be
able to effectively act as RFDs, although some sort of more complex
PAN-wide dual mode of operation doesn't seem impossible.

I don't know the word "fraglettation"; I assume this is the same as
"fragmentation"? The device would need to invoke 6LoWPAN fragmentation if
the target device is a legacy device and the IPv6 frame is too large to fit
into the MSDU.

Robert

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Mar 2016 09:09:16 -0500

Robert Moskowitz <[email-masked]> wrote:
    > I was thinking that there is also some difference in the physical
    > header to support the larger PPU?

Yeah, but you guys seem to be stuck thinking about whether 802.15.4-2011
PHYs/MACs would be able to receive 15.4g packets.

That's not the question.

The question is again:

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Mar 2016 09:13:47 -0500

Robert Cragie <[email-masked]> wrote:
    > "fragmentation"? The device would need to invoke 6LoWPAN fragmentation
    > if the target device is a legacy device and the IPv6 frame is too large
    > to fit into the MSDU.

I thought that 6lowpan adopted the term "fraglet" to mean fragmentation below
IPv6, such that the term "fragment" could continue to refer to what happens
above IPv6 using the Fragmentation Header.

I see that I've mis-reremembered, and the term became "link fragment".

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Mar 2016 09:17:44 -0500

> Yes, in theory. The PHY would have to support both the SUN-O-QPSK and
    > the O-QPSK PHYs, the intersecting frequencies, rates and spreading mode
    > and somehow be selectable on Tx and discriminate on Rx (accept both
    > PPDU formats)

Thank you for this answer.

Alex is trying to make the lowpan code for the Linux kernel more flexible,
and the question of whether we need to include a way to use different MTUs on
a per-destination basis has come up, and we had no clear answer.

We now know that this is physically possible; we don't know if chipsets will
implement this, or whether it SHOULD be possible.

This is now a technical policy question for 6lo, in my opinion.

---

From: Gerson Fernando Budke <[email-masked]>
Date: Wed, 9 Mar 2016 23:16:54 -0300

I was intrigued by this question and researched in the AT86RF215 ATMEL
datasheet

In section 6.12.3 Receive Operation and Configuration
...
As shown in Figure 6-28, the O-QPSK baseband sub-core of the AT86RF215
contains two specific receiver units, RX_0 for the receiving of MR-O-QPSK
frames and RX_1 for the receiving of legacy O-QPSK frames. Both units share
the same I/Q data interface and, consequently, the same receiver frontend.*
The transceiver can simultaneously listen for both PHY types at the same
channel.* This feature is restricted to chip rates of 1000kchip/s and
2000kchip/s ..."

Yes, ATMEL AT86RF215 does, the user must configure the mode. (780/915MHz
use 1000kchip/s, 2400MHz use 2000kchip/s)

ATMEL AT86RF215 indicate if frame was received by MR-O-QPSK or legacy
O-QPSK.

Plus:

This transceiver has two baseband core units and can operate both Sub-1GHz
and 2.4GHz simultaneous.
So, the sw need known if will send to sub-1G or 2.4G and MR-O-QPSK or
legacy.

http://www.atmel.com/devices/AT86RF215.aspx

Gerson