1. <July 2009>
f- 433 MHz PHY and MAC for TG4f - Preliminary Proposal
July 2009
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [15.4 MAC Changes Needed for 15.4f]
Date Submitted: [10 Sep, 2009]
Source: [Dalibor Pokrajac] Company [Guard RFID Solutions]
Address [#8 – 1600 Derwent Way, Delta, BC, V3M 6M5, Canada]
Voice:[ ],
Re: [Initial proposal of MAC changes needed to support 15.4f PHY(s)]
Abstract: [Proposed MAC changes to support Transmit Only Tags]
Purpose: [To be considered during e standard development process]
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
Dalibor Pokrajac, Guard RFID Solutions
<Dalibor Pokrajac>, <Guard RFID Solutions>

2. 15.4 MAC Changes Needed for 15.4f
e MAC Changes Needed for 15.4f
<July 2009>
July 2009
15.4 MAC Changes Needed for 15.4f
Dalibor Pokrajac, Guard RFID Solutions
<Dalibor Pokrajac>, <Guard RFID Solutions>

3. 15-09-xxxx-00-004f- MAC Frame Changes Required for 15.4f
<July 2009>
15-09-xxxx f- MAC Frame Changes Required for 15.4f
July 2009
15.4f Current State
15.4f has started later than peer groups 4e and 4g
4 months behind 4e
2 months behind 4g
All MAC changes required are not defined yet
There is indication that several proposals (different PHYs) will use Transmit Only Tags
Transmit Only nodes are not well represented in current 15.4 MAC
All 15.4f proposals were not presented yet
Final Proposals to be presented in September
PHY selection (in November) will enable complete definition of MAC changes required to support PHY(s)
Dalibor Pokrajac, Guard RFID Solutions
<Dalibor Pokrajac>, <Guard RFID Solutions>

4. 15-09-xxxx-00-004f- MAC Frame Changes Required for 15.4f
<July 2009>
15-09-xxxx f- MAC Frame Changes Required for 15.4f
July 2009
MAC Frame Changes
General 15.4 MAC Frame format
Blink Frame format
2 Octets
Frame Control
Sequence Number
Dest. PAN ID
Dest. Address 1
Source PAN ID
0/2
0/2/8
Source Address
Security Header
0/5/6/10
Payload
Variable
CRC 2 2
Dest. PAN ID
Source Address
Payload
0/2/8
CRC
Variable 1
Sequence Number
2 Octets
Frame Control
Optional Fields outside IEEE control
Variable
Alternative ID
Sensor Data 1
Device Type
1 Octet
Device Class
Dalibor Pokrajac, Guard RFID Solutions
<Dalibor Pokrajac>, <Guard RFID Solutions>

5. Proposed Frame Changes
<July 2009>
15-09-xxxx f- MAC Frame Changes Required for 15.4f
July 2009
Proposed Frame Changes
Frame Control  Add “Blink” frame type
000 = Beacon
001 = Data
010 = Acknowledgement
011 = Command
100 = 1 Octet MHR
101 = CSL Wakeup
110 = Secure Acknowledgement
111 = Blink
Addressing
0 bit: Payload addressing used
16 bit: Dynamic addressing for Tags with 2-way communication
64 bit: Full EUI-64 address
Payload (optional):
Device Class, Alternate ID, Sensor data (includes alternate location methods: LF, IR, ultrasound,…)
New 4e frames, already defined
Dalibor Pokrajac, Guard RFID Solutions
<Dalibor Pokrajac>, <Guard RFID Solutions>

6. 15-09-xxxx-00-004f- MAC Frame Changes Required for 15.4f
<July 2009>
15-09-xxxx f- MAC Frame Changes Required for 15.4f
July 2009
Blink Frame Options
0-bit Addressing Blink Frame format
Minimal message size, no security, no IEEE addressing
Source Address (Defined by industry association) is specified in Payload field (presumably shorter than 64 bits)
Frame Control Field could be 1 octet (Short Frame Control as per 4e)
64-bit Addressing Blink Frame format
Normal 15.4 addressing
Payload
CRC
Variable 2 1
Sequence Number
2 Octets
Frame Control 2
Source PAN ID
Source Address
Payload 8
CRC
Variable 1
Sequence Number
2 Octets
Frame Control
Dalibor Pokrajac, Guard RFID Solutions
<Dalibor Pokrajac>, <Guard RFID Solutions>

7. 15-09-xxxx-00-004f- MAC Frame Changes Required for 15.4f
<July 2009>
15-09-xxxx f- MAC Frame Changes Required for 15.4f
July 2009
Why “Blink” frame type?
15.4f requires Transmit Only frame
Modifying one of existing frames (e.g. one of Command Frames) may be possible, but would probably create more problems than it would solve
Transmitting a frame in ALOHA network should be possible without association and/or acknowledgement
New frame type decouples unique 4f functionality from core 15.4 functionality which is in nature 2-way communication
Allows definition of Payload fields which allow interoperability
Definition of Payload content is outside 15.4 scope
RFID / RTLS has very limited “upper protocol layers”. Blink Frame should satisfy most of protocol requirements.
Dalibor Pokrajac, Guard RFID Solutions

8. 15-09-xxxx-00-004f- MAC Frame Changes Required for 15.4f
<July 2009>
15-09-xxxx f- MAC Frame Changes Required for 15.4f
July 2009
Addressing Scheme
64-bit address
Useful, unique and simple addressing mechanism for many Tag applications
Unnecessarily long for some other applications which are extremely sensitive to air time and power consumption
16-bit address doesn’t satisfy needs of large scale Tag deployments.
It is suitable as temporary assigned (dynamic) address, but not permanent Tag ID
Can be used for some Tag applications which use classic 15.4 communication
0-bit address
Allows addressing through address specified in payload
Allows generation of short and efficient frame per industry requirements
Can be controlled by industry association built on top of 15.4f
Dalibor Pokrajac, Guard RFID Solutions

9. 15-09-xxxx-00-004f- MAC Frame Changes Required for 15.4f
<July 2009>
15-09-xxxx f- MAC Frame Changes Required for 15.4f
July 2009
The intent of this proposal
Provide MAC infrastructure which can be utilized by all 15.4 PHYs which could be used for Transmit Only active RFID / RTLS devices
UWB
2.4 GHz
860 / 915 MHz
433 MHz
15.4 MAC should remain decoupled from any PHY specifics (as it is now)
“Payload” field in Blink Frame should be PHY independent and provide a framework for higher level standardization
Potential future “Active RFID / RTLS” industry association
Enabling interoperability within a PHY and across multiple PHYs
Dalibor Pokrajac, Guard RFID Solutions
<Dalibor Pokrajac>, <Guard RFID Solutions>

10. Additional changes Primitives PIB Attributes Channel access
July 2009
Additional changes
Primitives
Will need PLME-BLINK and MLME-BLINK primitives
PIB Attributes
May need new PHY and MAC PIB attributes
Channel access
Variations in ALOHA protocol to increase probability of Blink message reception
Potentially others currently unknown
Dalibor Pokrajac, Guard RFID Solutions