Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: MAC primitives for Blink Frame Date Submitted: 17 March 2010 Source:Billy Verso, DecaWave. Address: Digital Depot, Thomas Street, Dublin 8, Ireland. Voice: + 353-1-511-1232, FAX: [], E-Mail: billy.verso@decawave.com Re:[802.15.4f] MAC level API for Blink Frame. Abstract:This presentation proposes a MAC API for initiating the transmission of the Blink frame and an API for reporting blink reception in the receiving device.. Purpose:For discussion and agreement at TG4f as prelude to proposing text for the 802.15.4e Draft.. 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.

2. Introduction A blink frame format has been defined within TG4e and added into the draft standard currently being prepared. The draft has so far not included the MAC primitives needed to initiate the transmission of the Blink frame, or, for reporting its reception. This document proposes the MAC primitives for agreement at TG4f prior to submitting any text to the TG4e editor for inclusion in the draft.

3. MAC primitives required for Blink frames • The blink frame is a periodic transmission from tagged assets that is received by RFID reader infrastructure • For sending and receiving the new blink frame the following new primitives are proposed: • MCPS-BLINK.request to initiate transmission of the blink • MCPS-BLINK.confirm to report the result of the blink TX attempt • MCPS-BLINK.indication to report the reception of a blink frame • The support of these primitives shall be optional in both FFD and RFD, but for devices implementing the TG4f active RFID PHYs it shall be mandated to support the appropriate primitives , i.e. • MCPS-BLINK.request and MCPS-BLINK.confirm in tags • MCPS-BLINK.indication in reader devices

4. MCPS-BLINK.request • The blink request needs the following parameters: • AddrMode is the addressing mode: 0= none, 1= destination PAN ID only, 2= 64-bit source address only, 3= both destination PANID and 64-bit source address • NB: the 64-bit address, sent in modes 2 and 3, need not be a parameter as it given by aExtendedAddress, which is a predefined constant for the device . • DstPANId the destination PAN ID used in addressing modes 1 and 3. • SecurityLevel, KeyIdMode, KeySource and KeyIndex (as per MCPS-DATA.request) • sduLength - number of the data octets to be transmitted • sdu the octets to be transmitted • UWBPRF, UWBPreambleSymbolRepetitions and DataRate (as per MCPS-DATA.request changes made by 802.15.4a in 2007) • Extra Parameters may be needed as a result of TG4f work in defining new PHYs

5. MCPS-BLINK.request • Elements of standard MCPS-DATA.request primitive NOT included in the MCPS-BLINK.request: • msduHandle is not needed since only the blink is sent directly so MCPS-BLINK.confirm is unambiguous with respect to which blink transmission is being confirmed. • TxOptions is not requires as all blink sending is unacknowledged, direct, and applicable only in a nonbeacon-enabled PAN. • Ranging (as added by 4a) is not needed as the blink frame by definition is for ranging (so this will be logically TRUE).

6. MCPS-BLINK.confirm • The blink confirm needs the following parameters: • Status which may be one of the following values • SUCCESS, CHANNEL_ACCESS_FAILURE, INVALID_ADDRESS, FRAME_TOO_LONG, UNAVAILABLE_KEY, UNSUPPORTED_SECURITY, INVALID_PARAMETER or UNSUPPORTED_PRF • Timestamp this is a parameter in 802.15.4 standard MCPS-DATA.confirm included here for completeness although I am not sure of its utility. • RangingCounter this is the send time (ala 802.15.4a) which is retained here as it might have some utility. • Extra Parameters may be needed as a result of TG4f work in defining new PHYs

7. MCPS-BLINK.confirm • Elements of standard MCPS-DATA.confirm primitive NOT included in the MCPS-BLINK.confirm: • msduHandle is not needed since only the blink is sent directly so MCPS-BLINK.confirm is unambiguous with respect to which blink transmission is being confirmed. • RangingReceived, RangingTrackingInterval, RangingOffset and RangingFOM are not needed since they apply only to an the reception of an acknowledgement to a data frame, and the blink is unacknowledged. • RangingCounterStart and RangingCounterStop replaced by one RangingCounter value for the MCPS-BLINK.confirm

8. MCPS-BLINK.indication • The blink indication needs the following parameters: • AddrMode is the Addressing Mode: 0= none, 1= destination PAN ID only, 2= 64-bit source address only, 3= both destination PANID and 64-bit source address. • DstPANId the Destination PAN ID , which is valid for addressing modes 1 and 3. • SrcAddr is the 64-bit address, sent in modes 2 and 3 • SecurityLevel, KeyIdMode, KeySource and KeyIndex (as per MCPS-DATA.indication) • sduLength - number of the data octets received • sdu the octets received • ?SN sequence number of received frame • Question do we want a separate blink sequence number or is this same sequence as used in the rest of the MAC command frames? ...continued next slide

9. MCPS-BLINK.indication (contd.) • Parameter list continued: • pduLinkQuality • UWBPRF, UWBPreambleSymbolRepetitions and DataRate (as per MCPS-DATA.indication changes made by 802.15.4a in 2007) • RangingCounter this is the receive time (ala 802.15.4a) which is retained here as it might have some utility. • RangingTrackingInterval, RangingOffset, RangingFOM (as per MCPS-DATA.indication changes made by 802.15.4a in 2007) • Extra Parameters may be needed as a result of TG4f work in defining new PHYs

10. MCPS-BLINK.indication • Elements of standard MCPS-DATA.indication primitive NOT included in the MCPS-BLINK.indication: • SrcAddrMode and DstAddrMode – replaced by a single AddrMode • SrcPANId,DstAddr not signalled • RangingReceived implied TRUE • RangingCounterStart and RangingCounterStop replaced by one RangingCounter value for the MCPS-BLINK.indication

11. Conclusions • A new set of MAC primitives are defined for the blink based on the existing data API primitives (MCPS-DATA) • Extra Parameters may be needed as a result of TG4f work in defining new PHYs <end>