Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO 28560-3:2024 — Fixed Length Encoding for Library RFID Tags
Understanding the basic block and extension block architecture for interoperable library RFID
Introduction to ISO 28560-3:2024 Fixed-Length Encoding
ISO 28560-3:2024 specifies a fixed-length encoding scheme for RFID tags used in library environments. Unlike the flexible object-identifier-based approach of ISO 28560-2, this part defines a compact, predictable data structure centered on a 272-bit basic block. This fixed-length design enables simpler and faster decoding, making it particularly well-suited for high-throughput library operations such as automated sorting, bulk inventory scanning, and self-service kiosks where rapid tag processing is essential.
The fixed-length encoding of ISO 28560-3 is optimized for speed and simplicity. The basic block occupies the first 272 bits of the RFID tag and contains the most frequently accessed data elements in predefined positions, allowing readers to extract critical information with minimal processing.
The standard is part of the ISO 28560 series developed by ISO/TC 46/SC 4 (Technical Interoperability) and applies to all types of libraries. It operates at 13.56 MHz using ISO/IEC 18000-3 Mode 1 air interface. This fourth edition (2024) supersedes the 2023 edition with corrections to the extension block type identifiers.
Memory Architecture: Basic Block and Extension Blocks
The memory layout defined in ISO 28560-3 follows a hierarchical structure:
| Block Type | Size | Content | Mandatory |
|---|---|---|---|
| Basic block | 272 bits (34 bytes) | Primary item ID, content parameter, owner institution (ISIL), set info, type of usage, shelf location, media format | Yes |
| Library extension block | Variable | Additional library-specific data elements | Optional |
| Acquisition extension block | Variable | Supplier ID, order number, invoice number, supply chain stage | Optional |
| ILL block | Variable | ILL borrowing institution, ILL transaction number | Optional |
| Title block | Variable | Bibliographic title of the item | Optional |
| Library supplement block | Variable | Additional optional data elements | Optional |
| Unstructured extension blocks | Variable | Proprietary or vendor-specific data | Optional |
| Filler data block | Variable | Page alignment padding | Optional |
| End block | Variable | Terminates the encoding sequence | Conditional |
Basic Block Structure
The basic block is the heart of the fixed-length encoding scheme. It occupies the first 272 bits of the tag’s user memory and contains a predefined set of data elements at fixed positions. For tags limited to 256 bits (32 bytes), the basic block is truncated. The content parameter (a 4-bit unsigned integer at the start of the block) identifies the version of the encoding rules and enables backward compatibility detection.
Extension Blocks
For tags with memory greater than 256 bits, extension blocks may follow the basic block. Each extension block begins with a length byte followed by a 2-byte block type identifier. The standard defines six types: library extension block (type 1), acquisition extension block (type 2), ILL block (type 4), title block (type 5), library supplement block (type 6), and unstructured extension blocks (type 3). Filler blocks can be inserted for page alignment, and an end block signals the termination of the data sequence.
The CRC in the basic block is calculated for the full 272-bit length even on 32-byte tags where the last two bytes are physically absent. Those two missing bytes are assumed to be 00HEX for CRC computation. This ensures CRC consistency across tags of different memory sizes.
Encoding Rules and Data Integrity
String and Integer Encoding
All strings are encoded in UTF-8 per ISO/IEC 10646, with the first character stored in the lowest memory location. String termination is handled through null bytes (00HEX), fixed-length field bounds, or the end of a structured extension block. Integer-encoded fields use 4-bit, 8-bit, or 16-bit unsigned integers as specified in the data element table.
Cyclic Redundancy Check (CRC)
The CRC mechanism is critical for data integrity. For the basic block, the CRC is calculated over the entire block including the content parameter. For extension blocks, each block carries its own CRC. The polynomial and calculation method are specified in Annex C of the standard. This layered CRC approach ensures that data corruption — whether from manufacturing defects, electrostatic discharge, or reader interference — is reliably detected.
Distinguishing Encodings with AFI and DSFID
The Application Family Identifier (AFI) distinguishes library tags from other RFID applications. Within the library domain, the DSFID register is programmed with the value 3EHEX to identify tags encoded per ISO 28560-3. Tags without a programmable DSFID register are distinguished by verifying the CRC in the basic block, since the content parameter value 6 is reserved exclusively for ISO 28560-2 encoding.
The fixed-length basic block enables what engineers call “single-pass decoding” — a reader can extract the primary item identifier, owner institution, and media format in a single read operation without parsing complex OID structures. This translates directly to faster transaction times at self-checkout stations.
Engineering Design Insights
Tag Memory Selection
Selecting the appropriate RFID tag memory size is a critical engineering decision. A 32-byte (256-bit) tag can only store the truncated basic block, limiting data to the most essential elements. A 64-byte (512-bit) or larger tag accommodates extension blocks for richer data sets. Engineers should evaluate the library’s specific requirements: a public library with high-volume circulation may prioritize speed and use 32-byte tags, while a research library with complex inter-library loan workflows may need the additional data capacity of larger tags.
Reading Optimization
Annex D of the standard provides detailed guidelines for reading optimization. Key strategies include: aligning data blocks to page boundaries to minimize read commands, placing the most frequently accessed data elements early in the basic block, and using null-byte filling consistently to enable predictable memory scanning.
Regional Profiling
Annex E addresses regional profiling — the practice of defining national or consortium-specific subsets of the standard. For example, a national library network might mandate specific data elements in the basic block while leaving extension blocks for local use. The standard provides a framework for creating such profiles while maintaining global interoperability.
One common implementation error is failing to set unused bytes to 00HEX as required by the standard. Non-compliant readers may misinterpret residual data from previous write operations as valid data elements, leading to incorrect item identification and potential collection management errors.
Frequently Asked Questions
Q1: When should a library choose ISO 28560-3 over ISO 28560-2?
A: ISO 28560-3 is ideal for high-throughput environments where fast decoding is paramount — such as public libraries with high circulation volumes, automated sorting systems, and self-service kiosks. ISO 28560-2 is preferred when maximum data flexibility is needed, such as in research libraries with complex metadata requirements.
A: ISO 28560-3 is ideal for high-throughput environments where fast decoding is paramount — such as public libraries with high circulation volumes, automated sorting systems, and self-service kiosks. ISO 28560-2 is preferred when maximum data flexibility is needed, such as in research libraries with complex metadata requirements.
Q2: Can extension blocks be used on 32-byte tags?
A: No. Tags limited to 32 bytes (256 bits) can only store a truncated basic block. The basic block itself is 34 bytes in the full version, so on 32-byte tags the last two bytes are omitted. Extension blocks require tags with at least 512 bits (64 bytes) of user memory.
A: No. Tags limited to 32 bytes (256 bits) can only store a truncated basic block. The basic block itself is 34 bytes in the full version, so on 32-byte tags the last two bytes are omitted. Extension blocks require tags with at least 512 bits (64 bytes) of user memory.
Q3: How does the CRC ensure data integrity in multi-block encodings?
A: Each data block — basic block and every extension block — carries its own CRC. This allows the reader to validate each block independently. If a single block becomes corrupted (e.g., due to electrostatic discharge), the other blocks can still be read reliably. The reader can also identify which specific block is corrupted for diagnostic purposes.
A: Each data block — basic block and every extension block — carries its own CRC. This allows the reader to validate each block independently. If a single block becomes corrupted (e.g., due to electrostatic discharge), the other blocks can still be read reliably. The reader can also identify which specific block is corrupted for diagnostic purposes.
Q4: What is the purpose of the filler data block?
A: Filler data blocks are used to align subsequent extension blocks to page boundaries. RFID tags typically have a minimum read/write unit called a “page.” By inserting filler blocks, engineers ensure that extension blocks start at page boundaries, minimizing the number of read commands needed and improving overall system performance.
A: Filler data blocks are used to align subsequent extension blocks to page boundaries. RFID tags typically have a minimum read/write unit called a “page.” By inserting filler blocks, engineers ensure that extension blocks start at page boundaries, minimizing the number of read commands needed and improving overall system performance.
