1. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
May 11, 2009
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [IEEE rfid 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) ], FAX: [+1 (905) ],
Re: [IEEEE rfid - 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 f effort. ]
Purpose: [Promote RFID devices that facilitate ease of use and low lifecycle cost.]
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
René Struik (Certicom Research)
<author>, <company>

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

3. IEEE 802.15rfid Application Requirements
<month year>
doc.: IEEE <doc#>
May 11, 2009
IEEE rfid 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] f-call-for-applications-tg4f.doc
[2] f-tg4f-draft-key-applications-requirements.ppt
René Struik (Certicom Research)
<author>, <company>

4. RFID Tag Communication Patterns
<month year>
doc.: IEEE <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>

5. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <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 e-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>