RFID File System Requirements and Suggestions

1
RFID File System Requirements and Suggestions

• Farron Dacus
• Jan van Niekerk
• Alfonso Rodriguez-Herrera
• MAXIM
• May 29, 2008

2
Executive Summary 1/2

• Since very low cost tags and 96 bit EPC codes
  have been the industry focus to date, there has
  not been much attention paid to more expensive
  tags acting as data carriers of general files
• But addition of batteries and sensors to tags
  greatly alters the cost structure and the
  assumptions about memory management
• Short term tag pricing for Class 3, 3, and 4
  tags as a function of time and tag features is
  likely to be in the 1 to 10 range
• EEPROM Memory cost is approximately 0.002 to
  0.004 per kB (0.2 to 0.4 U.S. cents per kB)
• Hence kBs to hundreds of kBs of memory are
  affordable on these tags and generally will exist
  (and more in the future for Class 4 tags)
• Historically, media with such memory size has
  usually had file management directories on
  board the media
• The fundamental purposes of a file management
  system are file integrity and fast access
• But, both of these major purposes are challenged
  by the unreliable and slow RFID link, and must be
  accounted for in the design of the filing system
• Sensor data is still just data, and is best
  managed by re-use of generalized file structures
• The current standard set provides no such file
  management
• Requiring directory information to be in the
  infrastructure only is not the wisest decision
  since not all readers are networked all the time,
  and some tags self update their files

3
Executive Summary 2/2

• Hence, a significant improvement (and perhaps a
  long term requirement) is for file management on
  the battery supported RFID tag, with the
  following features
• General enough to reuse for all types of files
• Specifically designed for the RFID application
• Not dependent upon stored directories in
  infrastructure that cannot always be up to date
• Achieves file integrity via Journaling
• Stores written information in a buffer before
  final write to ensure all packets are received
  (this has been found to be essential even in
  systems with a far more reliable connection to
  the media than RFID provides)
• Requires a new Write to Journal command
• Supports a packetized communication link with
  minimum redundant data flow
• The only way to get large files across a hostile
  radio link
• Full support requires several new commands
• Packet size must be adaptable and often cannot be
  the block size selected for convenience of
  EEPROM memory design (so BlockWrite is not
  adequate)
• Directories must provide fast access to essential
  file data such as page/block links (cannot afford
  time to read whole file to see structure)
• Appending to files must require only write of
  essential data and updating a page/block pointer

4
Specific Memory Problems

• No file structure in data storage
• No memory map of used space
• No addressing
• Basically, no directory of used space and
  particular file attributes
• No specialized commands tailored to overcome RFID
  link limitations (suggestions are made later)

5
RFID File System Requirements

• Not overly dependent upon data in network
  infrastructure
• Allows file access and modification by readers
  that are not real time network enabled (requires
  a real directory on tag)
• Fast read and write of a known file
• Requires ability to append to a file without
  reading the file, which in turn requires quick
  read of location of files last page
• A special Append to File command is ideal for
  max speed
• A similar Update from Last Read command is
  ideal for updating the network (especially for
  logged sensor files)
• Works with regularly interrupted communication
• A journaling file system that saves written
  data and updates file at the end of successful
  communication
• Packetized communication with CRC checks
• Ideally, adaptable packet size where each packet
  may be Acknowledged, which leads to the next
  packet being sent
• Special packetized Read and Write commands could
  pass parameters and set this up

6
RFID File System Requirements

• Needs to be efficient for memory usage relative
  to application and tag memory size
• Wide range of apps implies page/block size should
  be adaptable
• Journal file size should be similarly adaptable
• Must have a directory structure that quickly
  reveals current memory usage so that reader does
  not need to waste time walking the memory
• Bitmap of all currently used pages must be
  quickly accessible
• List of links for a file must be fully
  accessible, cannot keep links just in each
  page/block
• Should allow nested Sub-directories
• Sub-directories should have option of password
  protection
• Keeps Behavior Codes, Tag Capabilities, Tag
  Settings in files that follow the used file
  structure
• Exception Behavior Codes that indicate the file
  structure used should use a basic file structure
  that transcends the adaptable file structure of
  various standard versions

7
What logically goes in an RFID directory?

• Identity of directory as root or sub-directory
• List of files with attributes
• File name, file size, file type, page size, time
  last read and written, last page read and
  written, list of links comprising total file,
  unused words in last page/block of file
• Memory map file for this directory
• The root directory maps all used unused memory

8
What logically goes in a file?

• Each file is made of vendor defined blocks of
  up to 256 words (current standard)
• A large memory could need a larger size for
  optimum design
• These blocks are for EEPROM design reasons, and
  are not usually
• the optimum size for a communications data packet
• The block size for a file is indicated in the
  directory
• Each block has a structure similar to that shown
  below

Length (words actually written)
Data
Possibly Unused Part of Block
Continuation Pointer (EBV)
9
Possible New Commands 1/2

• Directory Read back directory as specified by
  parameters such as root only, all sub-directories
  also, particular sub-directory, or attributes of
  particular file
• Option to packetize the read back according to
  passed parameters
• Lots of functionality, might break into several
  commands
• TagAck, TagNak, ReaderAck, ReaderNak
• Nothing to do with the Ack command that
  acknowledges the reader got the RN-16 that the
  tag sends after its slot counter hits zero in the
  Reply state, and that commands the tag to go to
  Acknowledged state and report its PC, XPC, and
  EPC
• To support packetized communication in the Open
  or Secured state
• Ack has parameter to continue or terminate to
  allow reader to adjust communications, such as
  change data rate or sub-carrier
• Append This command uses the file name on the
  tag as a parameter, and passes a data block to be
  added to that file, without the need for
  addressing
• Option to packetize transmitted data
• Option to append to a new block, or to fill any
  empty space in current last block

10
Possible New Commands 2/2

• WriteJournal Write to journal file according to
  passed parameters such as address or file name
• Necessary for a journaling file system to avoid
  unreliable/partial updates to a file
• Standard Write is one word at a time, and
  BlockWrite moves each block to permanent memory
  immediately
• Option to packetize
• End of file or last packet triggers tag to move
  data to permanent file
• ReadUpdate Requests a whole or partial file
  using name and other parameters
• Allows addressing file by name and not address
• May update from a passed time, or from last read
  of the file, or from passed block or word address
  to end of file
• Option to packetize
• Lots of functionality, might break into several
  commands

11
Conclusions 1/2

• The fundamental assumption of very limited memory
  and mostly network file management is altered by
  the addition of battery tags
• Optimum system design would allow for larger
  memory tags to have on-board file management and
  directories
• File structures take the nature of RFID links
  into account
• The filing system should be reused for all types
  of files, including
• System and control files such as Tag Capabilities
  and Settings files
• Reader written data files
• Tag to tag data files (Class 3 and Class 4)
• Sensor data files

12
Conclusions 2/2

• Programmatically the file structure should be
  defined in ISO 1596X set on data encoding and
  memory control, then reused by RFID sensor
  standards IEEE1451.7 and ISO 24753
• This future addition to higher layer standards
  can be allowed for in the case of battery tags by
  addition of several optional commands to ISO
  18000-6C Chapter 10 and Annex P in this version
• Directory To read back directory,
  sub-directory, and file information
• WriteJournal To set up and conduct packetized
  writes to a buffer file in User memory
• Tag and reader Acks and Naks For packetized
  communications
• Append To add to an existing file