1. <month year>
doc.: IEEE
August 2014
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Discussion Points to incorporate proposals]
Date Submitted: [ 27 August, 2014]
Source1: [Noriyuki Sato, Kiyoshi Fukui] Company [OKI]
Address [2-5-7 Hommachi chuo-ku, Osaka, Japan]
Voice:[ ], FAX: [ ],
Re: [This is the original document.]
Abstract: [Summarize issues to incorporate proposals into the TG10 specification ]
Purpose: [To initiate discussions]
Notice: This document has been prepared to assist the IEEE P It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P
N. Sato and K. Fukui (OKI)
<author>, <company>

2. Discussion Points TG10 presentation 28th August 2014
<month year>
doc.: IEEE
August 2014
Discussion Points
TG10 presentation
28th August 2014
Noriyuki Sato / Kiyoshi Fukui
OKI Electric Industry Co., Ltd.
N. Sato and K. Fukui (OKI)
<author>, <company>

3. Objective Now we have individual proposals for the TG10 specification
August 2014
Objective
Now we have individual proposals for the TG10 specification
This document describes issues which need to be addressed to incorporate them into the specification
N. Sato and K. Fukui (OKI)

4. Options to develop one specification
August 2014
Options to develop one specification
Development of the one specification
Down-select one proposal (1)
Down-select for each functions by picking individual functionalities from the proposals (2)
Incorporate all proposals as options into the one specification
Just merge, and try to refine (3)
Reorganize, capture all of proposals and develop one specification in well-structured way (4)
Use cases cover many of applications and proposal are very variety. #4 may be the best choice.
N. Sato and K. Fukui (OKI)

5. Issues (1) Architecture IEs systematic structure
August 2014
Issues (1)
Architecture
We consented on using 15.5 definition as possible…
Do we define mesh layer on top of MAC (15.5 style) or 2.5 layer to provide MAC primitives to the upper layer?
IEs systematic structure
Proposals define usage of IEs in different structural ways…
If we down-select and choose one, it will not be a problem.
If we try to incorporate all of proposals into one specification, we needs consider about that.
IEs – MAC header IE or Payload IE?
In the definition, MAC header should be processed in the MAC layer and Payload be done in the upper layer – If we use MAC header IE, it may require to revise IEEE specification. The information in MAC header IE will not be provided by Data indication primitive of 15.4.
N. Sato and K. Fukui (OKI)

6. Issues (2) Common Functionalities
August 2014
Issues (2)
Common Functionalities
What shall we do for the common functionalities
Bootstraps
Security stuffs – Authentication, Key exchanges, KMP relay etc.
Address assignment, registration, DAD etc.
L2R layer management commands – FA, PIB access, diagnostic purpose
Shared command among the different proposals?
Exchange among neighbors, Exchange between PAN coordinator and individual nodes etc.
Bound Link – Virtual Link
Is this common function? - Can this function be used by another proposal?
Capability exchange
At least, a node can find what operation mode (which routing algorithm) of is running in the network
For more, a node can exchange the capability what operation mode each device can run.
N. Sato and K. Fukui (OKI)

7. Issues (3) Common functionalities (contd.) Forwarding functionality
August 2014
Issues (3)
Common functionalities (contd.)
Forwarding functionality
HOP by HOP retry
E2E retransmission
Source routing
Multicast related commands
Data aggregation
N. Sato and K. Fukui (OKI)