<July 2009> 15-09-0500-00-004f- 433 MHz PHY and MAC for TG4f - Preliminary Proposal July 2009 Project: IEEE P802.15 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:[604-998-4018], E-Mail:[dalibor.pokrajac@guardrfid.com] 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 802.15.4e standard development process] 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. Dalibor Pokrajac, Guard RFID Solutions <Dalibor Pokrajac>, <Guard RFID Solutions>

15.4 MAC Changes Needed for 15.4f 15-09-0591-00-004e- 15.4 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>

15-09-xxxx-00-004f- MAC Frame Changes Required for 15.4f <July 2009> 15-09-xxxx-00-004f- 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>

15-09-xxxx-00-004f- MAC Frame Changes Required for 15.4f <July 2009> 15-09-xxxx-00-004f- 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>

Proposed Frame Changes <July 2009> 15-09-xxxx-00-004f- 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>

15-09-xxxx-00-004f- MAC Frame Changes Required for 15.4f <July 2009> 15-09-xxxx-00-004f- 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>

15-09-xxxx-00-004f- MAC Frame Changes Required for 15.4f <July 2009> 15-09-xxxx-00-004f- 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

15-09-xxxx-00-004f- MAC Frame Changes Required for 15.4f <July 2009> 15-09-xxxx-00-004f- 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

15-09-xxxx-00-004f- MAC Frame Changes Required for 15.4f <July 2009> 15-09-xxxx-00-004f- 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>

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