doc.: IEEE <doc#1>

Slides:



Advertisements
Similar presentations
Doc.:IEEE Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title:
Advertisements

Doc.:IEEE Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title:
Doc.: IEEE Submission, Slide 1 NOTE: Update all red fields replacing with your information; they are required. This is a manual.
Submission Title: [Add name of submission]
June 2006 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposed Scenarios for Usage Model Document.
doc.: IEEE <doc#>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
Submission Title: [Multi-band OFDM Proposal References]
<month year> doc.: IEEE <030158r0> March 2004
doc.: IEEE <doc#>
March 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Toumaz response to TG6 Call for Applications]
<May,2009> doc.: IEEE <doc .....> <July 2009>
doc.: IEEE <doc#1>
doc.: IEEE <doc#>
<month year> doc.: IEEE <xyz> January 2001
Submission Title: IEEE : Management Slots in the MAC.
doc.: IEEE <doc#>
< November, 2011 > Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [More Low Energy Mechanism Details]
November 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [ Shared Group Timeslots ] Date Submitted:
Submission Title: [Common rate resolution]
doc.: IEEE <doc#>
<month year> doc.: IEEE <030158r0> November 2003
Submission Title: IEEE : Management Slots in the MAC.
<month year> doc.: IEEE <030158r0> September 2003
<month year> doc.: IEEE < e> <January 2019>
<month year> doc.: IEEE <xyz> November 2000
Sept 2010 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Proposed MAC Comment Resolutions Date Submitted:
doc.: IEEE <doc#>
doc.: IEEE /XXXr0 Sep 19, 2007 June 2009
doc.: IEEE <doc#>
November 2006 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Simplified geometry for the usage model.
<month year>20 Jan 2006
<month year> doc.: IEEE <030158r0> January 2004
doc.: IEEE <doc#1>
doc.: IEEE <doc#>
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Analysis of Wakeup Frame Based MICS Band Communications.
September 2000 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: TG3 Rank Order Voting Process Description.
doc.: IEEE <doc#1>
April 19 July 2010 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: WNG Closing Report for San Diego.
doc.: IEEE <doc#1>
doc.: IEEE <doc#1>
September 2018 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Discussion on MAC functionalities Date.
doc.: IEEE <doc#1>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
doc.: IEEE <doc#1>
<month year> doc.: IEEE <030158r0> November 2003
10 May 2000 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Open Issues with the TG3 Criteria Document]
Submission Title: [Extend-Superframe and GTS Structure]
doc.: IEEE <doc#1>
January 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG3c Project Plan] Date Submitted: [17.
June, 2010 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [OFDM PHY Mode Representation] Date Submitted:
November 2007 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG3c Project Plan] Date Submitted: [15.
September 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Suggested TG3c PAR Changes] Date Submitted:
Mar 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolution for Comment 70 ] Date Submitted:
Mar 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolution for Comment 70 ] Date Submitted:
doc.: IEEE <doc#1>
November 2007 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG4c Project Plan] Date Submitted: [15.
doc.: IEEE <doc#1>
August, 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Improve the latency between GTS request.
doc.: IEEE <doc#1>
Doc.: IEEE Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Summary.
Submission Title: [Common rate resolution]
Submission Title: [Common rate resolution]
Submission Title: TG9ma Agenda for September Meeting
Jan 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: TeraHertz Closing Report Date Submitted: January.
12/15/2019 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [AWGN Simulation Results] Date Submitted:
Presentation transcript:

doc.: IEEE 802.15-<doc#1> <September 2010> doc.: IEEE 802.15-<doc#1> <September 2010> Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolution of Wakeup Related Issues ] Date Submitted: [10 November, 2010] Source: [Rick Powell] Company [Zarlink] Address [15822 Bernardo Center Dr, Ste B, San Diego, CA, 92127] Voice:[+1 858-675-3485], FAX: [+1 858-675-3450], E-Mail:[rick.powell@zarlink.com] Re: [Wakeup Related Issues ] Abstract: [This document describe the need for a Wakeup Frame mechanism for performing Wakeup] Purpose: [Resolve Wakeup Related Issues] Notice: This document has been prepared to assist the IEEE P802.15. 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 P802.15. <Rick Powell>, <Zarlink> <Rick Powell>, <Zarlink>

Problems with using a poll frame for wakeup: <September 2010> Problems with using a poll frame for wakeup: When a node wakes up, it has no information about the nature of the network: Superframe or non-superframe Slot Size and Superframe Size HUB IEEE Address Hub MAC Capability Hub PHY Capability The Poll and T-Poll Frames do not supply this information. The T-Poll frame cannot be used for timing when the node does not know the slot size or superfame size. Polls cannot provide Type-I allocation intervals until timing information is provided. Therefore, only Type-II Polls can be used, whether in superframe or non-superframe mode. <Rick Powell>, <Zarlink>

Problems with using a poll frame for wakeup (continued): <September 2010> Problems with using a poll frame for wakeup (continued): Per Figure 72, Without sending the Hub IEEE address, the unconnected node cannot wakeup without contention. When multiple nodes receive the Wakeup Poll frame, the contention can take a long time to resolve. This requires nodes to stay on for long periods of time. Nodes do not know how long to stay on. If a node is the last in a series to successfully transmit its connection request frame, the time it needs to remain in the contention process in indeterminate. For nodes that are in the contention process, after the desired node has successfully connected, there is no mechanism to tell the other nodes to go back to sleep efficiently. The node has no Hub IEEE address for the connection request frame. <Rick Powell>, <Zarlink>

<September 2010> Figure 72 -- Unconnected mutual discovery and frame exchange in the MICS band T-Poll cannot be used because node does not know Slot Size or Superframe size. Type-I Poll cannot be used because there is no timing information to define an allocation interval. Without a HUB IEEE address, the contention process can go on indefinitely. <Rick Powell>, <Zarlink>

Proposed Format of Long Wakeup Frames for Unconnected Wakeup: <September 2010> Proposed Format of Long Wakeup Frames for Unconnected Wakeup: Proposed Format of Short Wakeup Frames for Connected Wakeup: Recipient Address: IEEE Address of Node (avoids contention) Sender Address: IEEE Address of Hub Session Start Time Offset: Absolute Time from Start of Wakeup Frame to Start of Session (100’s uSec). Contention Phase Length: Absolute Time, after Start of Session, that nodes content for sending Connection Request Frames. (mSec or Sec, depending on MSB  MSB = 0 means mSec) <Rick Powell>, <Zarlink>

Unconnected Wakeup with unknown Node IEEE Address: <September 2010> Unconnected Wakeup with unknown Node IEEE Address: Long Wakeup Frame is sent with Ack Policy set to N-Ack Long Wakeup Frame is a Poll for a Connection Request Frame Receiver IEEE address = 0 Session Start Time defines when nodes should start contending Contention Phase Length gives time when other nodes should shut off Explicit Shut off sent after connection for early shut off, format TBD. <Rick Powell>, <Zarlink>

Unconnected Wakeup with Known Node IEEE Address: <September 2010> Unconnected Wakeup with Known Node IEEE Address: Long Wakeup Frame is sent with Ack Policy set to N-Ack Wakeup Frame is a Poll for a Connection Request Frame No contention because Wakeup Frame contains Node IEEE Address Long Session Start Time defines when the node should send Connection Request Contention Phase Length = 0 <Rick Powell>, <Zarlink>

Connected Wakeup with Known Node NID Address: <September 2010> Connected Wakeup with Known Node NID Address: Short Wakeup Frame is sent with Ack Policy set to N-Ack Short Wakeup Frame is an allocation for a future Post/Poll No contention because Wakeup Frame Header contains Node NID Session Start Time defines when the node should listen for Post/Poll <Rick Powell>, <Zarlink>

Multicst Connected Wakeup with Known Node NID Addresses: <September 2010> Multicst Connected Wakeup with Known Node NID Addresses: Short Wakeup Frame is an allocation for a future Post/Poll Short Wakeup Frame is sent with Ack Policy set to N-Ack No contention because Wakeup Frame Header contains Multicast NID Session Start Time defines when the nodes should listen for Post/Poll <Rick Powell>, <Zarlink>