Supporting IATA RP1740

1
Supporting IATA RP1740 RP1745 Through SC31
RFID Standards
2
OPEN SYSTEM APPLICATION STANDARDSLegacy
Considerations

• Globally billions invested in AIDC related data
  elements that form building blocks of databases
• Migration to a new data carrier can take 3 to 7
  years
• Integration between RFID and bar code is highly
  likely, so cannot depend exclusively on the new
  technology
• Integration Issues
• The proportion of the item range with RF tags
• The migration period
• Integration restricts RFID options
• For RFID there is no fundamental requirement to
  encode data the same way, but data output can
  emulate bar code

3
OPEN SYSTEM APPLICATION STANDARDS The Issue of
Legacy Data Formats

• There are many different code structures in use
  for logistics that vary by sector, function, or
  country. EAN.UCC is one of many supported by bar
  code.
• Auto industry ? blood transfusion ? electronics
  ? military
• ? paper ? pharmaceutical ? postal an so on
• Pharmaceutical codes in Germany ? Italy ? UK ?
  USA
• Many logistic systems have established
  infrastructure of data formats
• Many depend on some form of item attendant data
  because of network problems, industrial and field
  operations or because the logic is to capture
  data and or timeline info

4
Stages to Develop an International Standard
5
Stages to Develop an EPCglobal Standard
6
ISO/IEC 15961 15962 Connectivity
ModelIntegrating the Real World
ISO/IEC 15459
ANS MH10 Data Identifiers
ISBT blood transfusion
OTHERS..
7
EPC as a Code

• As there is nothing in front of the Header, the
  set of
• header codes defines the total system space

8
EPC Connectivity Model

• All tags have to be compliant
• Applications have to be within the prescribed
  domain

9
EPCglobal Standards RFID Systems Architecture
10
ISO/IEC JTC1/SC31Support for Unique Identifier

• EPC is one of a number of such codes
• ISO/IEC 18000 series have air interface commands
  to read blocks 1n
• The data protocol standards have an application
  command to read the first object
• Therefore can support
• unique identifier
• unique identifier attribute (concept close to
  EAN.UCC Composite Symbology)
• have option for directory and no-directory
  structure

11
ISO/IEC JTC1/SC31 Logical Tag Structure
12
ISO/IEC Air Interface Data ProtocolSystem
Information

• System information is like Function Code 1 in
  UCC/EAN 128, except many times more powerful
• This provides a protocol level - not data -
  method for managing the interface between
  application and RF tag, and includes
• Application Family to enable a subset of RF tags
  to be in the communication channel
• Data Format to specify the interpretative nature
  of the encoded bytes on the RF tag
• Access Method to create a logical structure of
  the bytes encoded on the RF tag

13
ISO/IEC Air Interface Data ProtocolSystem
Information Application Family

• Addresses real need to manage the transactions
  across the air interface
• with large population of tags
• where there is a risk of different types of tag
  being present
• To be compatible with smart card rules (SC17),
  RFID for Item Management has 60 Application
  Family codes
• Application Family codes to be allocated to focus
  on a meaningful subset within the system, thus
  excluding RF tags from other systems
• So far only 14 codes have been assigned covering
  all major RFID for Item Management applications,
  leaving 75 spare capacity of the initial block

14
ISO/IEC Air Interface Data ProtocolSystem
Information Data Format

• Full feature - any combination of Object ID
• Application specific to include
• EANUCC
• Data Identifiers for primary industry e.g.
  Automotive
• IATA for baggage handling and freight
• Universal Postal Union
• ISO/IEC 15459 unique identifiers
• Blood transfusion (ISBT)
• EPC Global?
• The list can be extended to bring RFID benefits
  to different applications without abandoning
  legacy data

15
ISO/IEC Air Interface Data ProtocolSystem
Information Access Method

• Access Method specifies the literal structure of
  bytes on the RF tag
• Access Methods defined
• no directory
• directory
• self-organising tag (near future development)
• data sensory information (near future
  development)
• Future developments are dependent on new
  functionality and application requirements

16
ISO/IEC Data ProtocolObject Identifiers

• Object identifiers used for selective read /
  write
• Based on ISO/IEC 9834-1 established rules and
  structures
• ISO/IEC 9834-1 allows systems to define objects
  to any level of granularity - just need an object
  ID
• The object tree ensures uniqueness of objects
• Therefore, possible to encode different data,
  including closed system objects with no risk of
  corruption
• Extension techniques make the system totally
  expandable
• It would be relatively easy to accommodate an EPC
  code

17
ISO/IEC JTC1/SC31 Approach to Legacy Data Formats

• Can accommodate EANUCC SSCC for transport units
  - no need to change data only to migrate data
  carrier
• IATA may continue to use its bag tag Id and other
  attribute data
• ISBT may continue to use its alphanumeric 14
  character code for the blood transfusion service
• Various other ISO formats can be supported that
  enable RFID or alternative data carriers to be
  integrated
• New data formats have been accepted from Japan to
  support new applications. This type of process
  will continue e.g. US DoD has a different request
  in the pipeline

18
JTC1/SC31 RFID For Item ManagementAn Integrated
RFID System

• ISO/IEC 18000 air interface supports legacy and
  provides a bridge for future code structures
• This includes anything developed by EPC Global
• ISO/IEC 15961 15962 data protocol supports
  unique identifiers (legacy and new - like EPC),
  and attribute data in a seamless manner
• Together they are an integrated RFID system
  supporting
• efficient select of relevant tags, allowing
  different applications to be supported
• efficient support of different data and different
  formats completely unambiguously

19
Thank You

• Any questions?