Guard timing compensation comment resolution (CID 115) O. Omeni

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 August 2011O. Omeni (Toumaz)Slide 2

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

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 August 2011 O. Omeni (Toumaz)Slide 4

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)

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

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. August 2011 O. Omeni (Toumaz)Slide 7

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 August 2011O. Omeni (Toumaz)Slide 8

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. August 2011O. Omeni (Toumaz)Slide 9

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? August 2011O. Omeni (Toumaz)Slide 10

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 August 2011O. Omeni (Toumaz)Slide 11

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. August 2011O. Omeni (Toumaz)Slide 12