Encoding of Elements in WUR Wake-up Trigger Frame Month Year May 2017 Encoding of Elements in WUR Wake-up Trigger Frame Date: May 2017 Authors: Name Affiliations Address Phone Email James Lepp BlackBerry Limited 1001 Farrar Road, Ottawa, ON, Canada (+1) 613-595-4156 jlepp@blackberry.com James Lepp, BlackBerry Limited John Doe, Some Company
Summary Proposal to use TLV format for WUR elements May 2017 Summary Proposal to use TLV format for WUR elements Add a vendor specific element Discussion about maximum length James Lepp, BlackBerry Limited
Example TLV as used in Beacon/Probe May 2017 Example TLV as used in Beacon/Probe See IEEE 802.11-2016 James Lepp, BlackBerry Limited
Vendor Specific Element May 2017 Vendor Specific Element For extensibility of the WUR, a TLV structure can be used similarly to Beacon and Probe Request frames TLV Structure (Type, Length, Value) 1 byte element ID (typically #221) 3 byte OUI plus a variable length payload Receiver Transmitter Vendor Specific Element James Lepp, BlackBerry Limited
May 2017 TLV Length Benefit of TLV is it allows variable length fields. This is very flexible, but the downside is it allows long lengths which may be undesirable for the WUR Wakeup Frame. What kind of length limit is reasonable for WUR frame? Should we specify a max length per element? Or a total max length per frame for all elements summed up? Or leave it to implementers to be reasonable with their designs? James Lepp, BlackBerry Limited
May 2017 Strawpoll #1 Should WUR Wake-up Trigger Frame use elements with the common 802.11 TLV format? Use the TLV style for elements similar to Beacons/Probes etc. Use something else for encoding elements Abstain James Lepp, BlackBerry Limited
May 2017 Strawpoll #2 Should the maximum length of the WUR Wake-up Trigger frame be specified by: Defining max length per element (defined elements and vendor specific elements) Defining max length of total frame Don’t define max length (leave it up to implementers to be reasonable) Abstain James Lepp, BlackBerry Limited