Hi Pat, thanks for the clarifying this!
If so, I would like to suggest we use the option that omitting the
terminator to make it easier for the plugtest. The format of 6P will be :
*Bits: 0-10*
*11-14*
*15*
*16-23*
*24-27*
*28-31*
*32-39*
*octets*
Payload IE Content Length
Group ID
Type
As per 802.15.4-2015, the only time the Payload Termination IE is required is
when both the Payload IE and Data Payload are present. Given that there is no
payload following the 6P payload IE, the terminator may be omitted.
Pat
On 18, Jan2016, at 13:19, Tengfei Chang wrote:
Hi all,
Sorry
Hi all,
Sorry to ask question again on the recommends document! I still have a
question about why the payload IE is terminated by a termination IE?
According to the IEEE802.15.4e-2012 on section 5.2.4.22.
*5.2.4.22 IE List Termination IE*
*..*
* If an unformatted payload follows the Payload
Dear all
The picture below illustrates how the RH3 6LoRH works with draft 03 in a case
like Root -> A -> B -> C -> leaf
[cid:image003.png@01D15221.72C5D060]
The first 6LoRH is expected to be a full address (128 bits) to set up a
reference and the next 6LoRH are expected to be smaller and just
Dear all:
Please find below a tentative agenda for the next interim call, including
connection through webex, voice and etherpad.
Connection details
* Date: 7-8AM Pacific:
http://www.worldtimebuddy.com/?qm=1&lid=100,12,5392171,1850147&h=100&date=2016-01-22&sln=15-16
* Webex link:
https:
I agree with this format! +1
Tengfei
On Mon, Jan 18, 2016 at 9:41 AM, Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:
> Dear TengFei:
>
>
>
> I agree that the draft is lacking description when there is no IP in IP.
> I’ll create a ticket.
>
>
>
> When there is no IP in IP present in the 6
Dear TengFei:
I agree that the draft is lacking description when there is no IP in IP. I’ll
create a ticket.
When there is no IP in IP present in the 6LoRH, then the headers compressed by
6LoRH are considered placed right after the IP header compressed by IPHC, and
considered as compressed. It