1. <doc.: IEEE 802.15-doc>
<month year>
<doc.: IEEE doc>
November 2014
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [ TG8 approved motions ]
Date Submitted: [November 6th, 2014]
Source: [Marco Hernandez]
Company: [NICT]
Address: [3-4 Hikarino-oka, Yokosuka, , Japan]
Voice:[ ] Fax: [ ] []
Re: [In response to technical contributions to TG8]
Abstract: [ ]
Purpose: [Material for discussion in TG]
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
Hernandez (NICT)
<author>, <company>

2. Approved motions during the July 2014 Meeting
November 2014
Approved motions during the July 2014 Meeting
Hernandez (NICT)

3. <July 2014>
Motion 1: Frame
Frame: the structure is defined as the following periods in order
Synchronization period, Discovery period, Peering period, Contention Access period, and Contention Free period.
The duration of a frame is also the synchronization interval which is fixed with a value of TBD.
The duration of each period is fixed and the values are TBD.
<TG8 Group>

4. Motion2: Working Assumptions for a Superframe
<July 2014>
Motion2: Working Assumptions for a Superframe
Superframe: contains multiple frames which will be considered as an optional feature on the condition that the following are proved
Creating and maintaining Superframe can be performed with reasonable overhead.
Creating and maintaining Superframe over a large area is possible especially with multi-hop.
Not having the knowledge about the Superframe structure does not affect a PD’s capability of discovery and peering.
Having Superframe structure provides substantial benefit that outweighs the overhead required to create and maintain Superframe.
<TG8 Group>

5. Motion 3: Synchronization Procedure
<July 2014>
Motion 3: Synchronization Procedure
Synchronization Procedure includes the following sub-procedures:
Initial Synchronization procedure
Maintaining Synchronization procedure
Re-Synchronization procedure
A PD starts Initial Synchronization procedure if the PD does not have its own reference timing.
e.g. when the PD powers on, etc.
After successful Initial Synchronization procedure, a PD makes a transition to Maintaining Synchronization procedure.
A PD may make a transition to Re-synchronization procedure from Maintaining Synchronization procedure according to a triggering condition.
TBD: a triggering condition
<TG8 Group>

6. Motion 4: Initial Synchronization
<July 2014>
Motion 4: Initial Synchronization
To acquire a reference timing, a PD scans for the existing synchronization signals during a TBD time.
If it detects the synchronized condition, it derives its own timing from the detected synchronization signal.
The synchronized condition is determined from a synchronization signal or multiple synchronization signals with the same timing detected during the scanning period.
If it detects multiple synchronization signals with different timing during the scanning period, it performs a synchronization procedure based on the timings derived from the detected synchronization signals.
The synchronization procedure includes at least adjusting its own timing based on the derived timings.
If it fails to detect any synchronization signal, it starts to send synchronization signal with its own timing.
<TG8 Group>

7. Motion 5: Maintaining Synchronization
<July 2014>
Motion 5: Maintaining Synchronization
A PD maintains its own timing reference based on measurement of synchronization signals.
Maintaining Synchronization procedure includes at least fine adjustment of timing reference and triggering of Re-Synchronization procedure.
If unsynchronized condition for fine adjustment is met, it adjusts its own timing based on the detected synchronization signal during Synchronization period.
If unsynchronized condition for Re-Synchronization is met, it makes a transition to Re-Synchronization procedure.
TBD: details of unsynchronized conditions
<TG8 Group>

8. Motion6: PHY Discovery Signal
<July 2014>
Motion6: PHY Discovery Signal
Discovery signal is transmitted via UWB, OFDM, or DFT-S OFDM .
DFT-S OFDM or OFDM
Discovery information bits are mapped onto one or more discovery resource blocks (DRBs). The preambles are included (not shown).
A Discovery Resource Block comprises one or multiple of time resources or time and frequency resources.
UWB (TBD)
Fairness
PDs
<TG8 Group>

9. Motion7: Information for Discovery
<July 2014>
Motion7: Information for Discovery
For the purpose of discovery of PDs, the discovery information represents one or more of the following IDs
Device ID, Device Group ID, Application type ID, Application-specific ID, Application-specific user ID, Application-specific group ID.
The discovery information is not limited to IDs mentioned above.
<TG8 Group>

10. Motion8: Discovery Type
<July 2014>
Motion8: Discovery Type
The Discovery type is defined by a higher layer.
The MAC messages should support at least the following discovery types:
Advertisement: In Advertisement type discovery, a PD broadcasts its own discovery information and does not expect responses.
Publish/Subscribe: In Publish/Subscribe type discovery, a PD broadcasts its own discovery information and expects responses from PDs that have discovered the broadcast message(s).
Query/Reply: In Query/Reply type discovery, a PD broadcasts the discovery information of the PD or PDs being queried and expects a response or responses from the PD or PDs, accordingly.
<TG8 Group>

11. Motion9: MAC Discovery Messages
<July 2014>
Motion9: MAC Discovery Messages
MAC shall support at least the following discovery messages:
Discovery Request message
Discovery Response message
<TG8 Group>

12. Motion10: Re-Synchronization
<July 2014>
Motion10: Re-Synchronization
It performs a synchronization procedure based on the timings derived from the detected synchronization signals.
The synchronization procedure includes at least adjusting its own timing based on the derived timings.
<TG8 Group>

13. Motion11: Peering /Re-peering/De-peering
<July 2014>
Motion11: Peering /Re-peering/De-peering
MAC shall support the following procedures:
Peering
Re-peering
De-peering
Peering is the procedure to establish a link between a pair of PDs or links among multiple PDs discovered during the discovery procedure.
Re-peering is the procedure to re-establish a link between a pair of PDs or links among multiple PDs which peered previously. In the re-peering procedure, peering may be simplified.
De-peering is the procedure to disconnect the link established by peering.
<TG8 Group>

14. Motion12: Peering Messages
<July 2014>
Motion12: Peering Messages
MAC shall support the following peering messages:
Peering Request message
Peering Response message
<TG8 Group>

15. Motion13: Re-peering Messages
<July 2014>
Motion13: Re-peering Messages
MAC shall support the following re-peering messages:
Re-peering Request message
Re-peering Response message
<TG8 Group>

16. Motion14: De-peering Messages
<July 2014>
Motion14: De-peering Messages
MAC shall support the following De-peering messages:
De-peering Request message
De-peering Response message
<TG8 Group>

17. Motion15: Peering Procedure
<July 2014>
Motion15: Peering Procedure
The peering procedure is initiated by sending a peering request message including peering information.
Responder shall send a peering response message to requestor to indicate whether the peering request is accepted or rejected.
The response message may include peering information if the request is accepted.
<TG8 Group>

18. Motion16: Re-peering Procedure
<July 2014>
Motion16: Re-peering Procedure
Re-peering procedure is similar to peering procedure. The main differences are:
1) some of the previous peering information may not be included in request and response messages;
2) the PD receiving the re-peering request validates re-peering information with the corresponding peering information before it accepts the re-peering request.
TBD: parameters for validation may be Peering IDs, or Link IDS, etc.
<TG8 Group>

19. Motion17: De-peering Procedure
<July 2014>
Motion17: De-peering Procedure
De-peering procedure starts with a de-peering request. De-peering response is optional.
<TG8 Group>

20. Motion18: Working Assumption PHY Peering Procedure
<July 2014>
Motion18: Working Assumption PHY Peering Procedure
The following proposals are working assumptions and the final procedure is TBD.
ETRI: PPDU Format for Peering Request in PSDU
NICT: the peering request is implemented as Random Access Preamble illustrated
<TG8 Group>

21. Motion19: Communication Period
<July 2014>
Motion19: Communication Period
Communication period comprises Contention Access period (CAP) and Contention-free period (CFP).
CAP is located prior to CFP in a Frame.
The durations of CAP and CFP are fixed.
Unicast, multicast, or broadcast data packets are transmitted during Communication period.
Control packets may be transmitted during Communication period.
E.g. Control packets for scheduling, group management, etc.
<TG8 Group>

22. <July 2014>
Motion20: CAP
A PD transmits control/data packets during CAP period using the following access scheme:
LBT (Listen-before-Talk)
CSMA-CA
The conditions to increase Contention Window (CW) are TBD:
For example:
when it does not receive an ACK after transmitting a unicast packet and
when it detects a collision after transmitting a multicast/broadcast packet.
The conditions to decrease Contention Window (CW) are TBD.
when detecting no collision for TBD time.
Any further enhancement is not limited.
<TG8 Group>

23. <July 2014>
Motion21: CFP
CFP comprises Scheduling Request period, Scheduling Response period, Resource slots (RSs).
Only a PD with Link ID shall exchange Scheduling Request and Scheduling Response messages.
The scheduled PD transmits one or more data packets in scheduled RS(s).
Any further enhancement is not limited.
TBD: Other possibilities to reuse RS by non-scheduled PDs.
<TG8 Group>

24. Approved motions during the September 2014 Meeting
November 2014
Approved motions during the September 2014 Meeting
Hernandez (NICT)

25. Motion 22: Discovery Request Message
<September 2014>
Motion 22: Discovery Request Message
Discovery Request Message shall include source address. Source address type and length are TBD.
Moved: Huan-Bang Li
Second: Marco Hernandez
Yes: 6
No: 0
Abstain: 0
<TG8 Group>

26. Motion 23: Multi-hop Support
<September 2014>
Motion 23: Multi-hop Support
Background
For the sake of progress and to avoid layer-violation,
Proposed Motion
Any identification, context or etc. to represent multi-hop link is not specified.
Any procedure to establish and manage multi-hop link is not specified.
Other possibilities to support multi-hop protocol in higher layer is not limited and needs further discussion.
<TG8 Group>

27. Approved motions during the November 2014 Meeting
Hernandez (NICT)

28. Approved motions during the sessions
November 2014
Approved motions during the sessions
Motion to accept the harmonized text in DCN r4 “PAC Spec for Discovery and Peering” into the Draft Specification v0.3.
Motion to update the Draft Specification from v0.3 (working version) to v0.4 (agreed version).
Motion to approve the harmonized text in DCN r0 “Draft text of UWB PHY for TG8” into Draft Specification v0.5.
Motion to approve the harmonized text in DCN r0 “Harmonized text for distributed power control during CFP” into the Draft Specification v0.5.
Hernandez (NICT)

29. Approved motions during the sessions
November 2014
Approved motions during the sessions
Motion to approve the harmonized text in DCN r1 “Harmonized PHY Proposal from ETRI and NICT” into the Draft Specification v0.5.
Motion to confirm the TG decisions made during the AM1 session (procedural).
Motion to approve frame structure in DCN r1 “Proposed Frame Structure for PAC” into the Draft Specification v0.5.
Motion to approve DCN r1 "PAC Agenda" to revise the TG timeline.
Hernandez (NICT)

30. Approved motions during the sessions
November 2014
Approved motions during the sessions
Motion to approved the text in DCN r0 “UWB PHY text for integration into draft” into the Draft specification v0.5.
Motion to approve the text in DCN r1 “TG agreed Text For Frequency Channel Selection” into the Draft specification v0.5.
Motion to approve the text in DCN r2 “Proposed Text for Fully Distributed Initial Synchronization” into the Draft specification v0.5.
Hernandez (NICT)