Attachment_0001_DoD Over Air Interface Guidelines.docx

DoD Over Air Interface Guidelines Version 5.0 22 May 2018

Introduction

This document provides DoD specific changes and clarifications to ISO/IEC 18000-7:2008 for the DoD RFID-V Active Transponder Protocol used in the DoD Radio Frequency In-Transit Visibility (RF-ITV) system. Note that no technical changes have been made to these guidelines from the DoD Over Air Interface Guidelines provided with RFID-IV.

Normative References

ISO/IEC 18000-7:2008 Information technology – Radio frequency identification for item management – Part 7: Parameters for active air interface communications at 433 MHz

DoD Interoperability Guidelines for the Over Air Interface

Document Details Terms Used in this Document

Within this document, all references to ISO/IEC 18000-7 explicitly refer to the ISO/IEC 18000-7:2008 standard.

The term RFID-V Active Transponder Protocol will be used to indicate the ISO/IEC18000-7:2008 standard with the changes and clarifications included in this document. Additional clarifications and DoD RFID-V Active Transponder Protocol specific implementation details are included in a further document; DoD Interoperability Guidelines for the Over Air Interface.

DoD RFID-V uses the term transponder to refer to the component which the ISO/IEC 18000-7 standard and related documents use the term tag. To simplify correlation with ISO/IEC 18000-7:2008 the terms tag and transponder will both be used, depending on the context.

DoD RFID-V uses the term interrogator to refer to the component which ISO/IEC 18000-7 standard and related documents use both the terms reader and interrogator. To simplify correlation with ISO/IEC18000-7:2008, this document with use both of the terms reader and interrogator, depending upon the context.

Document Organization

This document explicitly references ISO/IEC 18000-7:2008 and is organized to refer section by section to the ISO/IEC 18000-7:2008 standard. This document only includes references to sections within ISO/IEC 18000-7:2008 standard to which specific changes, clarifications, or explanatory text are provided.

This document contains tables and figures which replace those found in ISO/IEC 18000-7:2008, and within this document, the references for these tables are the same as in ISO/IEC 18000-7:2008. Only those tables and figures which are different from those in ISO/IEC 18000-7:2008 are included here. This document also contains tables, sections and figures beyond those found in the ISO/IEC 18000-7:2008. Alpha character suffixes are used to distinguish new sections, tables, and references, and to indicate where the section, table or figure should go within a unified document. Alpha suffixed sections, tables and figures should go in alpha sort order following the numerically referenced element in ISO/IEC 18000-7:2008. For example, RFID-V Active Transponder Protocol Section 6.3.1A follows ISO/IEC 18000-7:2008 section 6.3.1, and RFID-V Active Transponder Protocol Section 6.3.1B should follow ISO/IEC 18000-7:2008 Section 6.3.1 and Section RFID-V Active Transponder Protocol 6.3.1A. For clarity, the letters I, O, and Q will not be used for reference suffixes.

Each section below, which references an existing section in ISO/IEC 18000-7:2008 will be identified as a change, addition or clarification to the text of ISO/IEC 18000-7:2008. Each section not referencing an existing section of ISO/IEC 18000-7:2008 may be assumed to be new material.

Order of Precedence of Protocol Documents RFID-V Compliant Active Transponder Protocol will be used to refer to the protocol based on the ISO/IEC 18000-7:2008 standard incorporating all changes and clarifications specified in this document. In cases in which ISO/IEC 18000-7:2008 standard and this document do not agree, this document takes precedence, and in any case where the ISO/IEC 18000-7:2008 standard with incorporated changes and clarifications from this document do not agree with the Interoperability Guidelines for the Over Air Interface document, the Interoperability Guidelines for the Over Air Interface document takes precedence.

Modifications and Clarifications to ISO/IEC 18000-7:2008

ISO/IEC 18000-7 Section 6.1 Physical Layer

Clarification:

The characteristics specified following the first paragraph of section 6.1 are nominal characteristics, for detailed physical layer specifications, see section 6.6 of the standard.

ISO/IEC 18000-7 Section 6.1 Physical Layer, Paragraph 3

Change:

The Wake Up Signal shall be transmitted by the interrogator for a minimum of 2.45 seconds to wake up all tags within communication range. The Wake Up Signal consists of a 2.35 to 4.8 second 31.25 kHz square wave modulated signal called the “Wake Up Header” immediately followed by a 0.1 second 10 kHz square wave modulated signal called the “Co-Header”. Upon detection and by completion of the Wake Up Signal, all tags shall enter into the Ready state awaiting a command from the interrogator. See Figure 1.

Clarification:

A tag has two states, awake/ready and asleep. During the ready state the tags shall accept valid commands from interrogators and respond appropriately. When the tag is asleep, it shall ignore all commands.

Clarification:

Once woken up, the tag shall stay awake for 30 seconds after the last well-formed command message packet with valid protocol ID and CRC values, regardless of Manufacturer ID or Serial Number, unless otherwise commanded by the interrogator.

Figure 1 -- Wake Up Signal

ISO/IEC 18000-7 Section 6.2.1 Data Link Layer, General

A packet shall be comprised of a preamble, data bytes, and a final logic low period. The last two level changes of the preamble shall indicate the end of the preamble and beginning of the first data byte. The same two level changes of the preamble also indicate the originator of the data packet.

ISO/IEC 18000-7 Section 6.2.2 Preamble

Clarification:

The preamble shall be comprised of twenty cycles of 60 µS period, (30 µS logic high followed by 30 µS logic low), followed by two final level changes which identifies the communication direction: 42 µS high, 54 µS low (tag to interrogator); or 54 µS high, 54 µS low (interrogator to tag).

Change:

Figure 2 - Data Communication timing -- Preamble

Note: Data byte transmitted order is most significant byte first; within each byte the order is least significant bit first. A 15 µS minimum period of logic low level proceeds the first preamble cycle. Data byte shown is 0xC6.

4.4A ISO/IEC 18000-7 Section 6.2.5 Packet End Period

Figure 2A - Data Communication timing – Packet End Period

A final period of 36 µS (one bit period) of continuous logic low followed by a rising edge and a minimum of 15 µS of logic high shall be transmitted after the last Manchester encoded bit within the packet. Data byte shown is 0x73.

ISO/IEC 18000-7 Section 6.2.4 CRC Bytes

See CRC description in this document in the Interrogator Command and Tag Response sections which follow.

A CRC checksum shall be calculated as a 16-bit value for each interrogator command and each tag response message. The CRC checksum shall be initialized with all zeros (0x0000), and computed over all data bytes (excludes preamble), from the protocol ID byte up to and including any command arguments or tag response data bytes, according to the CCITT polynomial (x16 + x12 + x5 +1). Reference: ITU-T Recommendation V.41 (Extract from the Blue Book), Code-independent error-control system, Appendix I - Encoding and decoding realization for cyclic code system. The transmission order of the CRC shall be most significant byte first.

ISO/IEC 18000-7 Section 6.2.6 Interrogator-to-Tag Message Format

Change:

In Table 1 below, the fourth field is now named Session ID rather than Interrogator ID. See the discussion in Section 4.11 – ISO/IEC 18000-7 Section 6.2.6.5 Interrogator ID below.

Table 1 — Interrogator-to-tag command format (broadcast)

Options Packet Length

Code

In Table 2 below, the sixth field is now named Session ID rather than Interrogator ID. See the discussion in Section 4.11 – ISO/IEC 18000-7 Section 6.2.6.5 Interrogator ID below.

Table 2 — Interrogator-to-tag command format (point-to-point)

Options Packet Length

Code

ISO/IEC 18000-7 Section 6.2.6.1 Packet options

The Packet options field, described in Table 3, indicates the command type as either a Point-To-Point command, which contains the Tag Serial Number and Tag Manufacturer ID fields within the command message (packet), or a Broadcast command, which does not contain these fields. As indicated in Table 4, a command can be a point to point or a broadcast command. The command type is identified as follows:

· Point to Point command, the Packet option field Bit 1 must be set to 1

· Broadcast command, the Packet Option field Bit 1 must be set to 0 ISO/IEC 18000-7 Section 6.2.6.2 Protocol ID

Clarification:

The protocol ID field permits different application standards based on ISO/IEC 18000-7 (“derived application standards”) to be developed. All derived application standards shall share the same physical layer protocols, but their command/response structure/field and command sets may vary depending on the application. The three commands Collection with Universal Data Block, Sleep, and Sleep All But defined in this standard shall be supported by all derived application standards. All other commands required by this standard shall be supported by ISO/IEC 18000-7 compliant products, but not necessarily by products compliant with derived application standards.

ISO/IEC 18000-7 Section 6.2.6.3 Tag Manufacturer ID

Clarification:

This 16-bit field code is a combination of the 15963 Allocation Class “0001 0001”, as the most significant byte, and the 8-bit issuer UID “xxxxxxxx”, as the least significant byte. For example, if the assigned Issuer UID is 00000100, the Tag Manufacturer ID would be 00010001 00000100 (0x1104).

ISO/IEC 18000-7 Section 6.2.6.4 Tag Serial Number

Clarification:

The Tag Serial Number field is four bytes in length. The Tag Manufacturer ID and Tag Serial Number together form a unique Tag ID. An example of this unique ID is shown below for the Manufacturer ID 0x1104, and Tag Serial Number 0x23456789, as Tag ID of 0x110423456789:

00010001 00000100 00100011 01000101 01100111 10001001 ISO/IEC 18000-7 Section 6.2.6.5 Interrogator ID

Change:

This field has been renamed from Interrogator ID to Session ID to reflect its use.

The Interrogator ID is a 16-bit value that identifies an interrogator from any other ISO/IEC 18000-7 compliant interrogator in the local vicinity. The Session ID of an individual interrogator may be changed without restriction, but its value shall be set to a value not in use by other ISO/IEC 18000-7 compliant interrogators in the local vicinity. No two ISO/IEC 18000-7 compliant interrogators within RF range of a single tag shall have the same Session ID. At the moment Session ID is changed in an interrogator, any outgoing communication between that interrogator and any tag shall be terminated. An interrogator that receives a tag message containing a Session ID not equal to its own Session ID shall not transmit any over-air packets regarding the contents of received tag message. The Session ID of 0x0000 is reserved and shall not be used.

ISO/IEC 18000-7 Section 6.2.6.6 Command Codes

Changes:

The Collection Query command has been deprecated. Its functionality has been included in the Collection with Universal Data Block command discussed later.

Clarification:

The command codes and their function as a Read and/or Write command shall be as listed in Table 4 below. Codes not identified are reserved. The Database Table commands share a common command code, and are differentiated by a Sub Command Code as shown in Table 4A.

Table 4A — Database Table Commands

ISO/IEC 18000-7 Section 6.2.6.7 Command Arguments

Supplementary Clarification:

Some commands require arguments. For those commands where arguments are defined, argument data shall be supplied with the command. The contents and length of any required arguments are specific to each command. See Section 6.3 – Tag Commands for details.

RFID-V Active Transponder Protocol Section 6.2.6.7A Interrogator to Tag Message CRC

Additional Section as Clarification:

A CRC checksum shall be calculated as a 16-bit value for each interrogator command message. The CRC checksum shall be initialized with all zeros (0x0000), and computed over all data bytes (excludes preamble), from the protocol ID byte up to and including any command arguments, according to the CCITT polynomial (x16 + x12 + x5 +1). Reference: ITU-T Recommendation V.41 (Extract from the Blue Book), Code-independent error-control system, Appendix I - Encoding and decoding realization for cyclic code system. The transmission order of the CRC shall be most significant byte first.

ISO/IEC 18000-7 Section 6.2.7 Tag-to-Interrogator Message Format

Clarification:

The tag-to-interrogator message shall use one of two formats depending on the type of message being transmitted to the Interrogator. The tag shall always respond to a command using one of the response formats described below except in the following situations, for which the tag shall not respond:

· the command is explicitly specified in this standard as requiring no response

· the CRC bytes received in the command do not match the CRC checksum that the tag has calculated for the received command packet

· receipt of a broadcast command containing an invalid command code or other error

· the tag is asleep (in the asleep state)

There are two possible response formats:

· the Broadcast response message format

· the Point-to-Point response message format

ISO/IEC 18000-7 Section 6.2.7.1 Broadcast Response Message Format

The message format shown in Table 5 shall be used in response to Interrogator broadcast commands received by tags within the Interrogator’s communication range. Broadcast commands are identified in Table 4.

Change:

In Table 5 below, the fourth field is now named Session ID rather than Interrogator ID. See the discussion in Section 4.11 – ISO/IEC 18000-7 Section 6.2.6.5 Interrogator ID above.

Table 5 — Broadcast response message format

Status Packet Length

Session ID ID of a particular session, an integer value from 1 to 65535

CRC A CRC checksum shall be calculated as a 16-bit value for each interrogator command, and each tag response message. The CRC checksum shall be initialized with all zeros (0x0000), and computed over all data bytes (excludes preamble), from the protocol ID byte up to and including any command arguments or tag response data bytes, according to the CCITT polynomial (x16 + x12 + x5 +1). Reference: ITU-T Recommendation V.41 (Extract from the Blue Book), Code-independent error-control system, Appendix I - Encoding and decoding realization for cyclic code system.

Table 6 in the standard is replaced by Table 25C in this document.

ISO/IEC 18000-7 Section 6.2.7.2 Point-to-Point Response Message Format

Clarification:

This message format, shown in Table 7, shall be returned to the Interrogator as a response to all point-to-point commands, which require the Tag Manufacturer and Serial Number in order to access a particular tag. (Point-to-point commands are identified in Table 4).

Change:

In Table 7 below, the fourth field is now named Session ID rather than Interrogator ID. See the discussion in Section 4.11 – ISO/IEC 18000-7 Section 6.2.6.5 Interrogator ID above.

Table 7 — Tag–to-interrogator response format (point-to-point)

Status Packet Length

*This field is command dependent; some commands may or may not need this field

Session ID ID of a particular session, an integer value from 1 to 65535

CRC A CRC checksum shall be calculated as a 16-bit value for each interrogator command, and each tag response message. The CRC checksum shall be initialized with all zeros (0x0000), and computed over all data bytes (excludes preamble), from the protocol ID byte up to and including any command arguments or tag response data bytes, according to the CCITT polynomial (x16 + x12 + x5 +1). Reference: ITU-T Recommendation V.41 (Extract from the Blue Book), Code-independent error-control system, Appendix I - Encoding and decoding realization for cyclic code system.

ISO/IEC 18000-7 Section 6.2.7.3 Error Codes

Clarification:

In response to a point-to-point command, a tag may reply with one of the errors listed in Table 8. If multiple errors are detected in a point-to-point command, only the first error is reported. Errors resulting from broadcast commands do not generate responses.

Addition:

The additional Error Codes shown in Table 8A are defined as an addition to those Error Codes shown in Table 8.

Table 8A — Additional Error codes (additions to Table 8)

See the following sections for additional details on these new error codes.

Error response data shall consist of a one-byte error code; which depending upon the kind of error, may be followed by a one-byte sub-code, and possibly one or more bytes of parameter data, also depending on the error; and optionally followed by a manufacturer-defined number of additional data bytes, as shown in Table 9. In the following error definition sections, the optional, manufacturer-defined bytes are not shown.

Table 9 — General error format

Error Code a value from Table 8 identifying the kind of error

Sub-code an optional value that further refines the nature of the error and is specific to the kind of error. This field is absent if the error does not define a Sub-code. Sub-codes are specified in the error description subsections below.

Error Parameter Data N bytes of data, where N is zero or greater, whose existence, length, and content depend on the nature of the error. This field is absent if the error does not define Error Parameter Data. Error specific Error Parameter Data and length N of this field, if any, is specified in the error description subsections below.

Manufacturer Data: M bytes of data, where M is zero or greater, whose existence, field length, and content are at the discretion of the tag manufacturer

ISO/IEC 18000-7 Section 6.2.7.3.1 Invalid Command Code Error

This error as defined in Table 10 shall be generated when the tag receives a packet with a Command Code and/or Sub Command Code that is not defined in this standard.

RFID-V Active Transponder Protocol Section 6.2.7.3.2A Optional Command Not Supported

Addition, new error code:

Table 12A below shows the structure of this error code.

Table 12A - Optional Command Not Supported error Error Code

0x03

This error shall be generated when the tag receives a command, identified in this standard as optional for the tag, which is not supported on this tag.

ISO/IEC 18000-7 Section 6.2.7.3.4 Can’t Create Object Error

Clarification:

Table ID Reserved Sub-Error (Sub-Code 0x04) shall be reported when the Table Create command is received, and the Table ID specified is reserved and not available for assignment to a table.

RFID-V Active Transponder Protocol Section 6.2.7.3.6A Operation Failed Error

Addition, new error code:

Table 18A shows the structure of this error code.

Table 18A — Operation Failed error

Sub-code a code as shown in Table 18B that identifies the error more specifically. The following values are defined:

Table 18B — Operation Failed error sub-codes

This error as shown in Table 18A shall be generated upon the failure of a valid command to complete properly. This error shall only be reported if the command failed to complete and no other error response has been generated.

4.22A RFID-V Active Transponder Protocol Section 6.2.7.3.7 Implementation Dependent Error

Correction/Clarification:

Table 19 shows the structure of this error code.

Table 19— Implementation dependent error

This error code as shown in Table 19 shall be reserved for tag manufacturers or applications to define tag behavior errors not covered by this standard. At a minimum, the tag implementation must include a Sub-Code field. Additional fields of the error are left to the tag manufacturer or application to specify.

ISO/IEC 18000-7 Section 6.2.7.3.8 Sequence ID Mismatch Error

Change:

The Sequence ID Mismatch Error shall be called Stale Token Error, and shall be generated when the tag receives a Table Read Fragment or Table Write Fragment with a token which has been invalidated by an intervening table write command.

Table 20 — Stale Token error Error Code

0x40

RFID-V Active Transponder Protocol Section 6.2.7.3.9A Query Expression Incomplete Error

This error code has been deprecated.

The error condition shall be reported as an invalid parameter error, see Section 4.55 – RFID-V Active Transponder Protocol Section 6.3.10.10G Query Failures.

ISO/IEC 18000-7 Section 6.2.6.4 Tag Status

Addition, new Alarm bit; Change to Service bit:

The Tag Status field shown in Table 23, included in all tag–to-interrogator messages, shall consist of the following information:

Table 23 — Tag status field format Bit

1 = NACK

0 = ACK

Bit

Note: reserved fields are set to a value of “0” Mode field indicates the format (response to Broadcast command or response to Point-to-Point command) of the response data from the tag. The list of possible values is shown in Table 24.

Table 24 — Tag status field format

(bit 15 - 12)

Alarm bit is intended as a general status bit indicating a non-command related reportable condition. This bit is set (‘1’) to indicate the asserted condition. The interpretation, actions to retrieve data and clear the alarm bit are defined by the tag vendor.

Service bit when set (‘1’) indicates that the tag has detected a hardware-related fault condition. Additional information on the hardware fault condition may be retrieved with the Hardware Fault Data UDB Type (see Section 4.27 – RFID-V Active Transponder Protocol Section 6.3.1A Universal Data Block).

ISO/IEC 18000-7 Section 6.3.1 Collection with Universal Data Block (UDB)

Change to arguments in Collection Command; clarification to response:

The Collection with Universal Data Block command shall be used to collect Tag Manufacturer ID and Tag Serial Numbers with the contents of a specified UDB data block. The format of the Collection with Universal Data Block (Collection with UDB) command shall be as shown in Table 25, Table 25 — Collection with Universal Data Block command

Window Size The duration of the period for the interrogator to listen for tag responses in the collection algorithm. See section 6.4 for a complete of the collection algorithm. The duration is encoded as an integer multiple of 57.3 milliseconds. The field value is an unsigned 16-bit integer, with a valid range of 1 to 512.

Max Packet Length The maximum value that a tag can use as the Packet Length field of its response. Tags may select a different reply packet length as long as the length does not exceed the value of Max Packet Length. This field value is an 8-bit unsigned integer in the range 20 to 255 inclusive. The value 20, the size of a minimum tag response packet (the length 20 include 15 bytes for response packet overhead, 2 bytes for the Total UDB Length value and 2 bytes for the Requested Offset value, and 1 byte for the UDB Type Code), indicates no bytes of the UDB should be included in the tag response.

This parameter may be used to tune performance or to limit RF transmission times for compliance with regional RF regulatory requirements.

UDB Type Code Identifies the requested UDB type. See Table 25N for a list of defined UDB Type Codes and their referenced UDB Types.

The tag shall select a random time slot based upon the Window Size and Max Packet Length values received (see Section 6.4). The tag shall respond in the time slot with the Collect with Universal Data Block broadcast response message as shown in Table 25A.

Table 25A — Collection with Universal Data Block response

RFID-V Active Transponder Protocol Section 6.3.1A Universal Data Block

Substantial Changes and Additions:

The Universal Data Block contains zero, one or more data elements which are referred to as TLD (Type, Length, Data) Elements, and are formatted as shown in Table 25B. Each TLD element is identified with a UDB Element Type ID (see Table 25C). Non-present or zero length data elements shall not be included in the Universal Data Block. For example, if the length of the User ID is zero, no part of the User ID TLD shall be included in the UDB.

Table 25B — TLD element format

UDB Element Type ID identifies the specific Data element being included. UDB Element Type IDs are defined in Table 25C.

Length N, the number of bytes in length of Data element.

Data the informational content of the TLD, such as a Routing Code or User ID.

The values for the UDB Element Type ID shall be as shown in Table 25C.

Table 25C — UDB Element Type ID values UDB Element Type ID (1 byte)

The Routing Code UDB Element (0x10) shall be as shown in Table 25D.

Table 25D — Routing Code UDB Element

The User ID UDB Element (0x11) shall be as shown in Table 25E.

Table 25E — User ID UDB Element

The Optional Command List Element (0x12) shall be as shown in Table 25F. The data returned in this TLD element is a list of one byte Command Code values for the optional commands that are implemented on this tag.

Table 25F — Optional Command List Element

The Memory Size Element (0x13) shall be as shown in Table 25G. The data returned in this TLD is composed of three 4-byte values: the total number of bytes available for Read/Write Memory commands, the total number of bytes allocated for Table database memory, and the number of bytes currently available in the Table database memory (available memory size is memory space which is available for use by user data, any data required for overhead or formatting shall not be included in the Available Table Memory field value).

Table 25G — Memory Size Element

The Table Query Size Element (0x14) shall be as shown in Table 25H. The 8-bit unsigned integer value returned in this TLD element represents the number of Table Query elements supported on this tag.

Table 25H — Table Query Size Element

The Table Query Results Element (0x15) shall be as shown in Table 25J. The data returned in this TLD is available after the successful execution of a Table Query and includes a Query Status value, the Table ID for the queried table, the number of records matched in that table, and the index of the first matching record.

Table 25J — Table Query Results Element

The values of the Query Status field shall be as shown in Table 25K.

Table 25K — Query Status Values

If the tag does not support database table commands, the tag shall set the Query Status field to the value 0x02 in the Table Query Results UDB element.

The Hardware Fault Status Element (0x16) shall be as shown in Table 25L. The data returned in this TLD is composed of three 1-byte values: the lifetime count of hardware resets, the lifetime count of Watchdog (firmware) resets, and the Hardware Fault Bitmap.

Table 25L — Hardware Fault Status Element

Lifetime Count of Hardware Resets count of number of hardware resets which the tag has experienced.

Lifetime Count of Firmware Resets count of number of firmware or watchdog timer resets which the tag has experienced.

Hardware Fault Bitmap set of flags which indicate faults. The flag bits are defined as shown in Table 25M.

Table 25M — Hardware Fault Bitmap

Corruption Detected Low Battery Detected where:

Low Battery Detected when set (‘1’) indicates that the tag battery is “low.” The exact meaning of “low” is implementation defined.

Memory Corruption Detected when set (‘1’) indicates that the tag has detected a memory hardware fault condition.

Reserved reserved for future use, return clear (‘0’);

A UDB Type is a predefined collection of UDB Element Types. The Collection with UDB and Read UDB commands include a UDB Type Code argument that allows an application to select one of the available predefined collections of UDB data. All UDB Types may include additional Application Extension TLD Elements following the required TLD Elements. The values of the UDB Type Code are shown in Table 25N.

Table 25N — UDB Type Codes

Fault data Hardware Fault Status element (Element 0x16) and any Application defined UDB elements.

The Universal Data Block may optionally include one or more UDB Application Extension Blocks (see Table 25P) each encapsulating one or more TLDs which are uniquely identified by the included Application ID TLD (see Table 25R ). Any individual tag may support the extensions defined by multiple vendors (with appropriate licensing if required).

Table 25P — UDB Application Extension Block format Application Extension Type ID Application Extension Length Application ID TLD Element Application TLD Elements

the Application ID Type and Application ID value one or more Application defined TLDs

Where:

Application Extension Type ID: The Application Extension Type ID defined in Table 25C This Application Extension ID identifies that all the TLD’s included within this UDB Application Block are identified by the included Application ID.

Application Extension Length: The full length of UDB Application Extension Block in bytes, including the Application ID TLD, and the combined lengths of the included Application TLD elements.

Application ID TLD Element: The Application ID TLD Element must be formatted as described in Table 25B and consists of an Application ID Type, a one-byte length field and a data field containing the Application ID value for the entity responsible for defining the following Application defined TLD elements. Application ID Types are defined as in Table 25R.

TLD Elements: A series of one or more TLDs each consisting of a Type ID byte defined by the included Application ID, a one-byte length field and a data field. The TLD Type IDs are defined solely by the Application identified, and are not required to be made public. All of the included TLDs must be formatted as described in Table 25B, except that the Type ID is assigned by the manufacturer rather than this standard. All of the included TLDs must fit completely within the Application Element Length byte count.

Table 25R — Application ID TLD Types Application ID TLD Type code Application ID TLD value

See Figure for an example Universal Data Block of the Transit Data Type (UDB Type Code 0x00). The example includes a Routing Code element, a User ID element and an Application extension block with two application extension elements.

Figure 2A - Example Universal Data Block - UDB Type 0x00 with Application Extension

ISO/IEC 18000-7 Section 6.3.3 Sleep All But Command

Sleep All But Command field descriptions:

ISO/IEC 18000-7 Section 6.3.5.1 User ID

Clarification:

To the User ID read command the tag shall respond with a point-to-point response message with command code and data as shown in Table 39.

Field descriptions for Table 39, User ID Command format (read response)

Field descriptions for Table 40, User ID Command format (write)

To the User ID write command the tag shall respond with a point-to-point response message with command code (and no data, unless an error is encountered) as shown in Table 41.

Clarification:

The User ID is a user-readable and writeable memory whose meaning and size (up to 60 bytes) is user defined. The User ID should be used as defined in ISO/IEC 15459 series standards. This command sets and gets the size and contents of the User ID. In addition to this command, the Collection with UDB and Read Universal Data Block commands also retrieve the User ID, except that when the User ID Length parameter is set to zero, the UDB message will not contain the User ID. The default length of the User ID is zero.

An additional error response is identified in Table 42A, to those identified in Table 42. The tag may report an Operation Failed error if there was an internal failure writing User ID data on the tag, or the tag’s memory is corrupted.

Table 42A — (write) User ID command errors (additional)

ISO/IEC 18000-7 Section 6.3.5.2 Routing Code

Change; maximum length of Routing Code, relaxed contents of Routing Code:

To the Routing Code read command the tag shall respond with a point-to-point response message with command code and data as shown in Table 44.

Field descriptions for Table 44, Routing Code command format (read response) Routing Code Length: the length in bytes of the Routing Code being returned.

Routing Code: contents of the Routing Code on the tag.

To set a tag’s Routing Code the command in Table 45 shall be sent to the tag.

Field descriptions for Table 44, Routing Code command format (write) Routing Code Length: the length, N, in bytes, of the Routing Code, where N is between 0 and 50 inclusive

Routing Code: the data to be written to the Routing Code on the tag

To the Routing Code write command the tag shall respond with a point-to-point response message with command code (and no data, unless an error is encountered) as shown in Table 46.

Change; relaxed contents of Routing Code:

The Routing Code is a user-readable and writable memory whose purpose and size (up to 50 bytes) is user defined. The Routing Code should be used as defined in the ISO 17363 standard. Note that the Routing Code is part of the tag’s response to the Collection with UDB and Read Universal Data Block commands, except that when the Routing Code Length parameter is set to zero, the UDB message will not contain the Routing Code. The default length of the Routing Code is zero.

Change; new error types, and revised error descriptions

The possible error responses shall be as shown in Table 47.

Table 47 — Routing Code command errors

ISO/IEC 18000-7 Section 6.3.6.1 Firmware Version

Table 49 field description:

Firmware Version Tag firmware version from the tag, a manufacturer defined immutable value.

ISO/IEC 18000-7 Section 6.3.6.2 Model Number

Clarification:

Table 51 field description:

Model Number Tag Model Number from the tag, a manufacturer defined immutable value.

ISO/IEC 18000-7 Section 6.3.7 Memory Commands

Clarification:

This memory is independent of all other data storage concepts (such as User ID, Routing Code, and database tables) defined in this standard. Associated with every byte of this memory is an unsigned integer address, through which that memory byte can be accessed. For B bytes of memory the addresses 0 through B-1 access the full range of memory.

ISO/IEC 18000-7 Section 6.3.7.1 Write Memory

Correction:

The Number of Bytes parameter in the Write Memory command (Table 52) has the valid range of 1 to 236 bytes. The 236 value is computed as 255 minus the number of bytes in the command header, the address field, and the CRC field (totaling 19).

Change:

An additional error response is identified in Table 54A, to those identified in Table 54. The tag may report an Operation Failed error if there was an internal failure writing data on the tag, or the tag’s memory is corrupted.

Table 54A — Write Memory command errors (additional)

ISO/IEC 18000-7 Section 6.3.7.2 Read Memory

Correction:

The Number of Bytes to Read parameter in the Read Memory command (Table 55), has the valid range of 1 to 239 bytes. The 239 value is computed as 255 minus the number of bytes in the response header, the length field, and the CRC field (totaling 19).

Change:

An additional error response is identified in Table 57A, to those identified in Table 57. The tag may report an Operation Failed error if there was an internal failure reading data from onboard tag memory, or the tag’s memory is corrupted.

Table 54A — Read Memory command errors (additional)

ISO/IEC 18000-7 Section 6.3.8 Delete Writeable Data

The delete writeable data shall do the following:

· Set the length of the User ID to zero (Erases User ID).

· Remove all user database tables are deleted. See Section 6.3.10 for database table definitions.

· Delete contents of database table 0x0000 (Query results table)

· The Password Protect Mode password, if implemented, shall be reset to 0xFFFFFFFF (initial value).

· Password Protect Mode, if implemented, is reset to disabled mode.

· Any existing database table tokens shall be invalidated

Change:

An additional error response is identified in Table 60A, to that identified in Table 60. The tag may report an Operation Failed error if there was an internal failure deleting data from tag memory.

Table 60A — Delete Writeable Data command errors (additional)

ISO/IEC 18000-7 Section 6.3.9 Read Universal Data Block (UDB)

The Read Universal Data Block command is used to read the Universal Data Block (UDB). As described in section 6.3.1, the UDB can become large enough to require multiple Read Universal Data Block commands to retrieve the entire UDB. The Offset into UDB field allows an interrogator to retrieve a specific portion of the complete Universal Data Block.

Change:

Table 61 — Read UDB

UDB Type Code: Identifies the UDB type requested. Table 25N defines UDB Type Codes for this field. See Section 6.3.1A for further discussion of the UDB.

Offset into UDB: Identifies a starting offset into the UDB requested. In order to retrieve longer Universal Data Blocks, the interrogator will use multiple Read UDB commands with appropriately advanced Offset into UDB values after each successfully received tag response.

Max Packet Length: An integer in the range 21 to 255 inclusive that specifies the maximum value that a tag can use as the Packet Length field in its response. The value 21 includes the 15 bytes of response packet wrapper, one byte of UDB Type Code , two bytes of Total UDB Length value, 2 bytes for the Requested Offset value and at least one byte of UDB data. This parameter may be used to tune performance or to limit RF transmission times for compliance with regional RF regulatory requirements.

To the Read Universal Data Block command, the tag shall respond with a point-to-point response message with command code, parameters, and data as shown in Table 62.

Table 62 — Read UDB Response

Requested Offset: the value provided in the Interrogator’s command message.

Universal Data Block: A portion of the Universal Data Block. The contents and format of the Universal Data Block are described in Section 4.27 – RFID-V Active Transponder Protocol Section 6.3.1A Universal Data Block.

To read the entire UDB, an Interrogator will begin with Offset into UDB set to 0 and Max Packet Length set to the largest acceptable packet size. Tags may select a smaller packet size than the length specified by Maximum Packet Length but may not exceed that value. After successfully receiving the initial portion of the UDB, the Interrogator may continue by advancing the Offset into UDB value to the next unread data byte position and sending a second Read UDB command. The interrogator may continue this exchange until the entire UDB is successfully read from the tag, but the interrogator shall not be required to retrieve the entire UDB at any time.

An Interrogator is not required to retrieve the entire UDB. In addition, the Interrogator is not restricted to send Read UDB commands with any ordered sequence of Offset into UDB values to the tag.

The tag shall return an Invalid Command Parameter error if the Offset into UDB parameter is greater than the total length of the specified UDB, or Max Packet Length is less than 20, or the wrong number of parameters bytes was provided in the Read UDB command.

Change:

An additional error response is identified in Table 63A, to those identified in Table 63. The tag may report an Operation Failed error if there was an internal failure reading data from tag memory, or the tag’s memory is corrupted.

Table 63A — Read UDB command errors (additional)

ISO/IEC 18000-7 Section 6.3.10 Database Table Commands

Fields are numbered (indexed) sequentially, left to right, starting at 0 for the first field.

Every field in a table is untyped; that is, all field value comparisons are performed on a byte-for-byte basis, with each byte being interpreted as an 8-bit unsigned integer, and with equality being established between two fields if all bytes in each field exactly match. One field is considered “less than” a second field if for some byte position p in the two fields, all bytes in the byte range 0 to p-1 are equal in the two fields, and byte p of the first field is less than byte p of the second field.

Change:

The database tables can be divided into the following types by Table ID, as shown in Table 81.

Table 63B — Table ID space definitions

Table IDs in the “ISO Defined” range are reserved for future inclusion in the ISO/IEC 18000-7 standard. Table ID 0x0000 is reserved for the Query Results table (see section 6.3.10.10).

Table IDs in the “Solution” range are reserved for special features, functions and enhancements. In this region, the database tables are read and written with standard database commands, but the tables may have special functions and can have side effects. Table IDs within the Solution range must have published interfaces, and Table ID numbers shall be defined and assigned by the entity that owns the routing code.

Table IDs in the “Manufacturer/Vendor” range are reserved for vendor proprietary extensions, features and enhancements. In this region, the database tables are read and written with standard database commands, but the tables may have special functionality and can have side effects. Table IDs within the Manufacturer/Vendor range are available for use solely at the vendor’s discretion, with no requirements to make public the purpose or use of the interfaces within this Table ID space.

Clarification:

Commands which read and write Table data produce a data element called a “token”. The write commands (Table Add Records, Table Update Records, and Table Update Fields) declare a start location in logical terms (table ID, record #, field #), and a count (# of records, # fields) The read command, Table Get Data, declares only a start location. Upon receipt of one of these commands the tag generates a token value and returns it to the interrogator. Subsequently, the token is passed in a Table Read Fragment or Table Write Fragment command from the interrogator, back to the same tag, along with any necessary data (subject to message size restrictions). The tag then performs the read or write, also subject to message size restrictions, and generates a new token value.