Using ISOIEC 15434 Syntax with ISOIEC 15961 and 15962

1
Using ISO/IEC 15434 Syntax with ISO/IEC 15961 and
15962

• June 8, 2009
• Rick Schuessler
• Convener, WG4/SG1

2
Background what is 15434 Support???

• ISO/IEC 15434 defines a Transfer Syntax, that can
  present
• data items from a suppliers information system
  to an encoder,
• decoded data items to a receivers information
  system
• So, what does 15434 support require of
  15961/62?
• Input users should be able to store any valid
  15434 message on an RFID tag
• Output if the supplier stored a valid 15434
  message on the tag, then a receiving system
  should be able to retrieve that message in 15434
  format if desired
• 15961/62 meets these requirements, while also
  meeting the additional RFID-centric requirements
  for random access to tag data (next slide)

3
Why dont RFID systems just use 15434?

• Both ISO and EPCglobal have built AIDC Systems
  respecting the similarities and differences
  between RFID and bar code. RFID fully supports
  existing AIDC data systems (AIs, DIs, etc), but
• Different approaches to input processing
• Bar codes are line-of-sight, so the processing
  speed is limited by how fast bar codes can be
  presented to a scanner
• Thousands of RFID tags can potentially be read
  simultaneously here the bottleneck is Air
  Interface speed
• Consequently, RFID systems should minimize air
  interface time
• Different approaches to Writing data
• Bar Codes are created all-at-once data is never
  appended to an existing optical code (instead,
  the code is reprinted)
• Users intend to add and modify RFID tag data in
  the field
• Consequently, RFID systems should support Modify
  and Delete operations, without needing to rewrite
  the entire tag memory
• Such differences led to the paradigm shift, from
  a sequential message stream such as 15434, to
  random access of individual data objects, each
  labeled with an OID.

4
So, How is ISO/IEC 15434 supported in 15961/62?

• There is complete compatibility, at the level
  that really matters to end users (database
  equivalence)
• For example, the six-digit representation for
  Expiration Date (AI 17) is identical, whether
  from a bar code or an RFID tag
• The Data System being used (DI? AI?) is
  unambiguous
• Any 15434 message can be directly represented as
  a single 15962 data object, using a DSFID of
  03hex (Format 3)
• But, 15434 transfer syntax is incompatible with
  RFID middleware systems (ALE, LLRP, RP, 15961,
  24753), which need to support random access to
  data items
• So, 15961/62 was designed so that, at any point
  in the middleware stack, the data can be
  deterministically repackaged as a 15434
  envelope, if it is desired to connect the RFID
  data into a legacy AIDC system.

5
How is RFID data repackaged to 15434 format?

• As a Prerequisite, two correspondences are
  established
• Between a 15962 Data Format and a 15434 Format
  Identifier
• Example 15434 Format 6 corresponds to 15961
  formats 10 and 13 (which are older and newer
  ways of representing the use of DIs in RFID
  systems)
• Between each legacy ID (eg, 25S or 17) and a
  15962 OID
• Using these correspondences, it is a
  deterministic and mechanical process to translate
  a 15434 envelope into a set of OID-based objects,
  or vice versa.
• 15961/62 supports three variations on how one can
  encode a 15434 envelope, with different tradeoffs
  of efficiency and random-access capabilities

6
First Method representing 15434 as a single
Object

• 1st method uses Access Method 0 and Format 3,
  both exactly as have been defined since the first
  (2004) edition of 961/62
• Memory starts with DSFID 03H, followed by a
  single 15434 Object
• The Object starts with a Precursor byte, which
  indicates
• Which 15434 Format Indicator is present (e.g.,
  6 for DIs)
• Which character-level compaction mode is used (6,
  7, 8 bit)
• The second byte is the Objects length (number of
  bytes)
• Very useful to Interrogators, esp. in poor
  signal/noise conditions
• The remainder is the meat of the 15434
  envelope, verbatim (excluding the trailing
  RS/EOT, which is implied by objects length)
• Advantage inherent direct correspondence to
  Legacy format
• Disadvantages (compared to the other two 15962
  methods)
• Individual data items are not addressable by
  their OIDs
• no Read or Write random access capability
• Compaction mode must be the lowest common
  denominator across all of the data items within
  the 15434 envelope

7
Second Method representing 15434 as a sequence
of Objects

• 2nd method uses Access Method 0 and Format n,
  where n is the equivalent of the 15434 Format
  Indicator (e.g., 9 for AIs)
• Memory starts with DSFID 0nH, followed by a
  sequence of 15962 data sets, each encoding one
  data item from the 15434 message
• Each Object starts with a Precursor, which
  indicates
• The final arc of the OID, which specifies a
  specific DI or AI
• Which character-level compaction mode is used
  (all are applicable)
• The Precursor is followed by the Objects length
  (number of bytes)
• Allows interrogator to skip over a data item not
  of interest, to conserve air interface time
• Advantages (compared to Format 3, as shown on
  previous slide)
• efficiency (each data item receives an
  appropriate compaction)
• Possible to modify one data item without needing
  to rewrite them all)

8
Third Method representing 15434 as Packed
Objects

• 3rd method uses Access Method 2 and Format n,
  where n is the equivalent of the 15434 Format
  Indicator (e.g., 9 for AIs)
• Memory starts with DSFID followed by a one or
  more Packed Objects encoding all of the data
  items from the 15434 message
• If all User data is written at once, then a
  single Packed Object would typically hold all of
  it
• Data can be written in phases, either using
  multiple Packed Objects, or a single editable
  Packed Object
• Each Packed Object starts with a
  mini-Directory, which indicates which data
  identifiers are encoded in that Packed Object
• Provides some Random-Access capability, without
  the cost of a true Directory
• Advantages (compared to approaches shown on
  previous slides)
• Best efficiency (each data item receives optimal
  compaction)
• Best random access (e.g., interrogator can
  determine whether a data item is present, by
  reading only a small percentage of the encoded
  user memory)
• Disadvantage Packed Objects were not defined by
  original 2004 spec

9
Recommendations

• Use First Method to cover the fringe cases of
  15434, such as complete EDI message, where no
  set of corresponding OIDs has been defined
• Use Second Method today, for AI and DI messages
• First Method can also be used
• For better compaction and feature set, migrate
  from Second Method to Third Method, once current
  revisions of 15961 and 15962 pass FDIS
• For comparison, resulting bit counts for Michelin
  Guides first eg
• 381 bits First Method (single Format 3 object,
  GS forces 7-bit)
• 334 bits Mr Harmons proposal (Access Method 4
  version)
• 330 bits First Method (single Format 3 object,
  six-bit with for GS)
• 216 bits Second Method (multiple Format n
  objects)
• 160 bits Third Method (single Packed Object)