doc.: IEEE 802.15-<doc#> <month year> doc.: IEEE 802.15-<doc#> May 11, 2009 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [IEEE 802.15rfid Application Considerations] Date Submitted: [May 11, 2009] Source: [René Struik] Company [Certicom Research] Address [5520 Explorer Drive, Fourth Floor, Mississauga, ON, L4W 5L1, Canada] Voice: [+1 (905) 501-6083], FAX: [+1 (905) 507-4230], E-Mail: [rstruik@certicom.com] Re: [IEEEE 802.15rfid - Call for Applications (09/0059r03)] Abstract: [This document suggests consideration of some lifecycle aspects and pleas for enforcing bidirectional communication capabilities for all devices enabled by the IEEE 802.15f effort. ] Purpose: [Promote RFID devices that facilitate ease of use and low lifecycle cost.] 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. René Struik (Certicom Research) <author>, <company>

IEEE 802.15.4rfid Application Considerations <month year> doc.: IEEE 802.15-<doc#> May 11, 2009 IEEE 802.15.4rfid Application Considerations René Struik (Certicom Research) René Struik (Certicom Research) <author>, <company>

IEEE 802.15rfid Application Requirements <month year> doc.: IEEE 802.15-<doc#> May 11, 2009 IEEE 802.15rfid Application Requirements Ultra-low energy consumption (low duty cycle) Low PHY transmitter power Both one-way and two-way communications (simplex and duplex transmission) High tag density (large tag population of many thousands) Reader to tag and tag to tag (meshing) communication (unicast) One to many communication (multicast) Authentication Sensor integration Accurate location determination capability 100m read range Global availability (with our without licensing) Narrow bandwidth PHY channels less than 3MHz wide Capable of avoiding, or operating in the presence of interference from other devices operating within the Active RFID’s frequency band of operation References: [1] 15-09-0059-03-004f-call-for-applications-tg4f.doc [2] 15-09-0203-03-004f-tg4f-draft-key-applications-requirements.ppt René Struik (Certicom Research) <author>, <company>

RFID Tag Communication Patterns <month year> doc.: IEEE 802.15-<doc#> May 11, 2009 RFID Tag Communication Patterns Definition Active RFID tag ([2, Slide 3]): Device, typically associated with asset or entity, with unique identification and with capability of producing its own radio signal, unassisted by external radio sources. […] Tag features ([2], Slide 10): – Baseline: transmitter; – Optional features: two-way communications. Minimum cost tag (baseline) ([2], Slide 4): Tag does not require every optional feature and functionality. Transmit-only devices do not have a standardized feedback channel: – no capability to reuse RF channel used for Tx for Rx traffic; – no feedback on reliability of channel, health of device, last ‘gasp of breath’, etc.; – initial device provisioning and device management require out of band channel; – network management costly, since seemingly assuming human intervention; – no capability for remote device diagnostics, dynamic device queries, or device alerts; – no capability for challenge/response protocols, thereby jeopardizing secure deployment. René Struik (Certicom Research) <author>, <company>

doc.: IEEE 802.15-<doc#> <month year> doc.: IEEE 802.15-<doc#> May 11, 2009 RFID Tag Reliability Transmit-only devices do not have a standardized feedback channel: – No capability for parameter updates, including trust material and, e.g., time information, thereby jeopardizing on-going security, complicating secure device replacement, and providing hurdles for overhead reduction and low-energy and low-latency transmissions. Lack of consideration for reliability of received data: – No explicit requirement for data authenticity (if not, uncontrolled state changes possible) Bottom line: Need more consideration for following aspects: – Need for two-way communication (even if one direction would have ‘crappy’ QoS); – Need to facilitate security and reliability (using 802.15.4e-style security functionality); – Need for loosely synchronized notion of time (to allow low-energy/low-latency comm.); – Need to facilitate network management (e.g., device role, flexible parameter changes). Wishlist: capture these considerations adequately into requirements documents. René Struik (Certicom Research) <author>, <company>