doc.: IEEE Submission September 2011 O. Omeni (Toumaz)Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Proposed Resolutions for Clause 9 Sponsor Ballot 1 Date Submitted: 29 August, 2011 Source: Okundu Omeni, Toumaz UK Limited Re: Response to IEEE Sponsor Ballot 1 Comments Abstract:This document proposes several resolutions for CID-115 and CID-118 Purpose:For discussion by IEEE TG6 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

doc.: IEEE Submission Motivation Supporting 20/40ppm resolution requires nodes to include a 2 nd low power timing XTAL which affects cost and size of sensor node Additional guard time provides a mechanism for nodes to trade-off available bandwidth for lower duty cycle and hence they can use lower timing resolution not requiring a XTAL Unfortunately, the node has to do this computation itself as well as set aside guard times at the start and end of its required allocation This comment proposes a mechanism that removes the burden of doing this from the node and also requires only half of this drift guard time to be set aside September 2011 O. Omeni (Toumaz)Slide 2

doc.: IEEE Submission Motivation (contd.) More importantly, it allows nodes with poor timing resolution to achieve significantly better duty cycles than their resolution theoretically allows This enables a hub to support nodes with latency in minutes (temperature sensor) together with nodes with latencies of 10’s of ms (ECG sensor) on the same network This would allow small low cost nodes without CSMA support to coexist with much higher throughput nodes Also hubs can sleep when they don’t have traffic and so save power Finally, I believe this is a good enhancement of this standard and further distinguishes from other standards like BLE September 2011 O. Omeni (Toumaz)Slide 3

doc.: IEEE Submission Comments CID-115 & CID-118 Proposed resolution – Revise The following changes should be made to the existing test: 1.Add MAC capability field to Hub to indicate support for this mechanism. “500 ppm timing mode” – we can use deleted multi-node support field 2.In the Connection request, add an octet field for the node to indicate its payload size (or how many base slot units it requires per allocation) 3.Add another octet to T-Poll frame to indicate superframe length (when sending to unconnected nodes) – this is to enable more speedy connection time 4.Add new text in clause 7.11 to describe this functionality in a separate sub clause move existing functionality to Add new text for connection assignment indicating how slots are allocated September 2011 O. Omeni (Toumaz)Slide 4

doc.: IEEE Submission Suggested text for When this mode is enabled, the hub shall 1.Reduce its slot size by 500ppm, i.e. if it is using a 1us clock, instead of counting 1000 for 1ms, it counts 998 instead. 2.Set aside guard time in base unit allocation slots (500us) as required by the node’s wakeup interval (SI) and requested base unit slots. 1.SI = m*BP; GTh = SI/1e3; Nslots = (Nreq + GTh/500us)/SlotLength 2.Nalloc = ceiling(Nslots) September 2011 O. Omeni (Toumaz)Slide 5

doc.: IEEE Submission Suggested text for (contd.) A node with ~+/-500ppm resolution that shall resynchronize with the hub via T-Poll or beacon if it misses a single allocation. A hub may send additional T-Polls to this node to facilitate this synchronization. If a node has a better ppm than 500ppm, then its synchronisation interval is determined by 500/NodePPM. So if for example NodePPM = 100, then the node can miss 5 wakeup intervals before having to re- sync September 2011 O. Omeni (Toumaz)Slide 6

doc.: IEEE Submission Comments CID-115 & CID-118 Proposed resolution – Revise The following changes should be made to the existing test: 1.Add MAC capability field to Hub to indicate support for this mechanism. “500 ppm timing mode” 2.When this is set, hub emulates a -500ppm resolution for all its timing. 3.All nodes would be given allocations as if they had 500ppm resolution local clocks. Leads to about 0.1% bandwidth trade-off for nodes to achieve the same ppm as the hub even with poor clock resolution. 4.Hub shall broadcast in its beacon this capability, so other hubs and nodes are aware of its timing or joining nodes with better resolution than 500ppm. September 2011 O. Omeni (Toumaz)Slide 7

doc.: IEEE Submission Example scenarios: Scenario 1: A node has a clock resolution of 500ppm, but wants a duty cycle equivalent to 100ppm I.e.10 times its capability. Say it is trying to join a hub that has 40x2ms slots, with 10 slots set aside for RAP. Further, the node wants a wake-up interval of 20 seconds which is communicated as 250 multi-periodic (m=250). So how does the hub support this? The maximum drift for the node during this time is ~500ppm in 20secs = 20ms = 10 slots September 2011 O. Omeni (Toumaz)Slide 8

doc.: IEEE Submission Example scenarios: contd. Without timeslot adjustment, the hub would need to set aside 10 slots before the allocated slot for this node and 10 slots after the allocated slot. So if it assigns slot 15 to the node, slots 5 to 14 and 16 to 35 in the superframe of wake-up are also set aside as occupied and cannot be user by other nodes. With timeslot adjustment, if it assigns the node slot 15, it only needs to set aside slots 16 to 35 in the node's wake-up superframe. Third makes it possible for 1 periodic nodes like ECG streaming nodes to co-exist with this much lower power, longer term sensor node. September 2011 O. Omeni (Toumaz)Slide 9

doc.: IEEE Submission Example scenarios: contd. Scenario 2: A node has a clock resolution of 500ppm but wants a duty cycle equivalent to 50ppm (0.01%) which is 20x its capability. It is trying to connect to a hub that has a superframe of 100x1ms slots. The hub already has around 10 nodes connected and has a RAP2 = 50 slots. Further, this node only needs 1 slot to transmit all its payload, but according to its requirement of a duty cycle of 0.01%, it would need an m-periodic allocation where m = 20000/100 = 200 = 20 seconds. So how does the hub support this? September 2011 O. Omeni (Toumaz)Slide 10

doc.: IEEE Submission Example scenarios: contd. the node's worst case drift during this period would be 20 ms (~500ppm in 20 secs) without timeslot adjustment, the hub would need to set aside a total of 41 slots for the node with timeslot alignment, the hub needs to set aside only 21 slots for the node It could easily achieve this by reducing the number of slots for RAP2 by the number of slots this node requires (21 or 41) but only for the wake-up superframe for this node. In fact this is a mechanism the hub could use regularly. i.e. using a chunk of its available slots as RAP2/m- periodic traffic allocations September 2011 O. Omeni (Toumaz)Slide 11

doc.: IEEE Submission Example scenarios: contd. A hub using this timeslot adjustment mechanism, should where the application scenario allows, use larger slot lengths. This way it uses fewer slots to compensate for time drift. If the allocation is an uplink allocation, the hub shall listen from the allocated slot until the end of the time compensated slots until it hears the node's transmission. If it is a downlink allocation, the hub shall transmit empty data frames with more bit set to 1 and Ack policy set to I-Ack until it receives an Ack from the node or gets to the end of the allocation. For a bilink allocation, instead of a zero length data frame, this would be a T-Poll frame. September 2011 O. Omeni (Toumaz)Slide 12