ADC 219 

Passive Radio Frequency Identification (RFID) Visibility Transactions 

1. ORIGINATOR: 

a. Service/Agency: Defense Logistics Management Standards Office (DLMSO)

b. Originator: Ms. Lori Barnhill, 703-767-9739 or e-mail: Lori.Barnhill@dla.mil

2. FUNCTIONAL AREA: Supply/Transportation 

3. REQUESTED CHANGE: 

 a. Title: PDC 236, Passive Radio Frequency Identification (RFID) Visibility Transactions 

 

b. Description of Change: This change establishes data requirements for registering passive RFID 

readers at DAAS for the purpose of identifying the location of the reader so that subsequent tag reads 

can be associated with the physical location of the read. This change also establishes data requirements 

for sending scanned tag read identification and reader identification to DAAS via middleware (e.g., Savi 

Site Manager, Globe Ranger, etc.). The goal is to associate the tag identification and location with 

previously transmitted logistics transactions containing passive RFID, e.g., 856S, Shipment Status, and 

856A, Receipt/Shipment, Consolidation/Due-in Notice. 

 c. Scope of Change: 

 (1) This change is restricted to the Alaska RFID Implementation (ARI) program; however the 

intent is to validate the process for broad use in future passive RFID implementations. The scope of the 

project includes systems that currently collect supply and transportation data for the Defense Logistics 

Agency (DLA) and United States Transportation Command (USTRANSCOM) business processes used 

to generate that data, technologies to collect new data, software to integrate the data, and tools to 

visualize the information. 

(2) The initial scope of the ARI program is limited to DOD-prepared shipment transactions 

(856S and 856A); it is anticipated that future expansion will incorporate vendor/contractor-prepared 

advance shipment notices (856) in the future. 

 d. Comments received on PDC 236, and the comment disposition: 

Name/ 

Organization # 

PDC 236 

Location 

(if 

applicable) Comment Disposition 

Mary Maurer 

Ctr./ DAASC 

1 Page 8 

C24.3.5 

"Minimum of 7 months" should 

say something like 

"Approximately seven months." 

We store the RFTag data based 

on the type of transactions 

received. There is really no 

minimum or maximum. 

Concur. DLMSO revised to read: 

"approximately seven months." 
Att 

PDC 236 

2

2 

Will this change apply to all RFID 

tagged cases and pallets shipped 

and received and observed within 

the ARI pilot, and if the concept is 

proved will this apply to rest of 

the DOD supply chain? 

All passive tagged items in the 

scope of the ARI program are 

affected by this change. 

Application to the rest of the 

supply chain will be determined 

by OSD’s Supply Chain 

Integration office. 

3 

Will middleware be designed to 

filter data to account for 

registering only 1 event per tag 

per location, to prevent multiple 

read notifications being sent to 

the DAAS? If not then the 

potential impact would be 

overload on the network. 

The various middlewares 

deployed have capabilities that 

are currently being tuned to 

control the repetition of tag 

notifications. 

4 

Is the reader identification 

number, which is the number 

assigned by to the reader by the 

site, follow a standard format 

from site to site? If a standard 

does not exist then one should be 

specified to maintain uniformity. 

Each site will determine the 

location, requirement, and 

naming of the specific readers at 

the site that will read and capture 

the visibility transaction. What 

really counts is the "Passive 

RFID Location Control Number" 

that is assigned by DAAS - this is 

what will be seen at DAAS and in 

AV. For example: there may be 

12 individual readers within a site 

that capture the visibility 

transaction - DAAS and AV will 

display the DODAAC, CAGE , 

Port code, etc...of the location - 

based on the "Passive RFID 

Location Control Number" and 

then the corresponding visibility 

transactions for that location. 

5 

Are the following elements “free 

form text”? 

• POC Name and other 

information 

• POC comm. phone number 

• POC DSN phone number 

• POC E-mail address 

A specific length and format of 

the data elements will be 

validated by DAAS. The user will 

be responsible for mapping to the 

standard format. Testing will take 

place under the ARI Program. 

6 

Will a test site be created like the 

test ITV server established by PM 

J-AIT? 

Test sites for this ARI have 

already been established under 

the RAPIDS program and have 

been transitioned to the ARI 

program manager. 

Garry Duvall, 

Civ/ 

OASD(HA)/TMA 

7 

We believe standard format 

should be specified for all the 

fields. 

We are working with the known 

ANSI standards and will have 

follow-on formats for the 

eXtensibile Mark-up Language 

(XML) very shortly. 
Att 

PDC 236 

3

8 

It references that this only applies 

to the Alaska RFID (ARI) 

Program. I don’t know what that 

is. Does that mean we (DSS) are 

inherently not impacted, or are 

we potentially impacted as a 

possible trading partner making 

shipments or accepting receipts 

from ARI? 

The ARI is a DOD level 

implementation of passive RFID 

(physically located in Alaska). 

You could think of it as a prototype, but officially it is considered 

an “implementation” – regardless, 

once this process is proven, it is 

anticipated to be rolled out across 

DOD. Initially, it was intended 

that DSS readers be included, 

but, as of right now, they are not 

since the 856S and the 856A give 

the necessary information for the 

outbound, and I don’t think 

anyone is concerned about the 

inbound for this process. 

9 

Is the initial registration of 

devices, and subsequent 

changes and deletions via email, 

web input (TBD), phone call. Or 

is it transactional. It seems to 

state transactional in a couple 

places but what would that 

transaction be? Perhaps a new 

DLMS DS for just that purpose? 

The Middleware captures this 

information already for its internal 

purposes, this transaction shares 

that data with DAAS and allows 

DAAS to provide a systematic 

identity for Asset Visibility. 

10 

In addition to the one time 

registration of devices in (above), 

is it then also saying that the 

site/device identification data 

must be sent within each 856S, 

856A, and future 856 

transactions? Meaning, we 

would need to capture that some 

how and put it into our outbound 

DLMS transactions? If so, I 

presume there will be separate 

PDCs for the 856S, 856A, 856, 

identifying the qualifiers and 

such? 

There are no changes to the 

856s. The middleware is 

supposed to send an XML 

transaction to DAASC every time 

it reads a tag. The visibility 

transaction will give the tag and 

the reader id. Then DAASC or 

other applications will have to 

match up the read location with 

the shipment info from the 

various types of 856 transactions 

to turn this into useful information. 

Also looking into queries that 

would allow someone with tagged 

material to search for what 

shipment it is. 

Reid Canning, 

Civ/ DLA 

J6UEA 

11 

It is not perhaps saying that an 

entirely new DLMS DS will be 

created that merely transmits 

RFID info to DAASC every time a 

tag is merely read/written right? 

Meaning, unrelated to the 

possible logistics transaction 

(856(s).....), but merely a 

transactions that merely states a 

device read a given tag? 

That’s it – just the reader saying a 

specific tag was read. 
Att 

PDC 236 

4

Emmet Lung/ 

SRA 

12 Page 3 

and Table 

C24.T1 

Should the a date format of 

CCYYMMDDHHmm would be 

written as 210811151456 for 

today’s date since this is the 21st

century and “CC” in the format 

stands for century. 

CCYY is understood to mean the 

four position year and not literally 

the century. Same issue applies 

to all our X12 transaction as well 

(where the CCYY construct is 

part of the standard and not 

modifiable). We have provided 

an example in the guidance. 

Supply PRC 13 

Page 3 

and Table 

C24.T1 

Location currently reads 

"DODAAC or CAGE Code of this 

location" please add Water Port 

and Aerial Port Codes also. 

Concur. DLMSO revised to read: 

"DODAAC, CAGE, Water Port or 

Aerial Port code for this location." 

ARI PMO 14 

Pages 4 

and Table 

C24.T2 

Add 'F' - Follow up with 856s; 

DAASC will return an 856A and 

856S 

DLMSO revised to add 'F - Follow 

Up' 

4. BACKGROUND: 

a. The DOD has mandated implementation of passive RFID technology in the DOD supply chain. 

To achieve this end, the ARI project demonstrated an integration of a variety of technologies including; 

passive RFID readers, RFID edgeware, ASC X12/MILS message translators, enterprise application 

integration brokers, and more. The ARI Team is specifically tasked to approach this integration project 

with an enterprise-wide view at streamlining DOD supply chain operations.

b. The DOD also tasked the ARI Team with comprehensive end-to-end mapping, measuring, and 

evaluating current end-to-end supply chain business processes. The goal was to develop streamlined 

processes as a result of implementing the new technology, resulting in more supply chain value for the 

resources consumed. (See attached Context Diagram.)

c. In October of 2006 the DLA J-3734 (ARI Program Manager) held a stakeholders meeting to 

record the functional needs of a passive RFID program and the visibility transaction was identified as a 

critical component of the project. 

5. REASON FOR CHANGE: 

 a. The U.S. Department of Defense (DOD) has mandated implementation of integrated passive RFID 

technology in the DOD supply chain. As directed by the Office of the Secretary of Defense (OSD) 

Supply Chain Integration (SCI) office, these transactions and procedures are developed to integrate the 

RFID technologies and enable visibility of shipments moving throughout the DOD supply chain using 

passive RFID. 

 b. This change is the first of several which will establish a complete business process associated with 

intransit visibility based upon passive RFID. While this change establishes the reader registration and 

visibility transaction, others will integrate the information with existing asset tracking and visibility 

applications making it possible to obtain more precise location history of tracked shipments. Query 

capability from the middleware to obtain logistics information based upon a tag read is also being 

explored. 
Att 

PDC 236 

5

6. ADVANTAGES AND DISADVANTAGES: 

 a. Advantages: Integrates the passive RFID technologies to enable visibility of shipments moving 

throughout the DOD supply chain. 

 b. Disadvantages: None known. 

7. IMPACT/INTERFACE: 

a. Data Content: 

Registration Data Requirements 

Element Description 

Mandatory, 

Optional, 

Conditional 

Min 

Length 

Max 

Length Values 

Passive RFID 

Location Control 

Number 

DAAS-assigned 

upon initial 

registration; 

required in update 

and delete; blank 

in the establish 

option C 16 16 

Reader 

Registration 

Action 

Describes 

purpose of 

registration action 

or DAAS 

response to the 

registration action 

M 

2 2 

From Site to DAAS: 

E_ - establish reader 

U_ - update reader information 

D_ - delete reader 

From DAAS to site: 

CE - establish reader confirmed 

CU - update reader confirmed 

CD – delete reader confirmed 

NE - establish reader not accepted 

NU - update reader not accepted 

ND – delete reader not accepted 

Passive RFID 

Reader Type 

Location's reader 

is fixed or mobile M 1 1 F = fixed, M = Mobile 

Reader 

Identification 

Number 

Number assigned 

to this reader or 

group of readers 

by the site M 10 10 

Location 

DODAAC, 

CAGE, Water 

Port or Aerial 

Port code for this 

location 1,2 M 5 6 

Location Text 

Further 

description of this O 1 50 

 

1

 Components must identify if other code types should be included to define reader location, e.g., airport code, port of 

embarkation code. 

2

 DAASC access to the CCR at DLIS to obtain the associated clear text address. 
Att 

PDC 236 

6

location 

Type of Location 

Code location is 

using to report by M 1 1 

D = DODAAC, V = CAGE Code, 

A = Aerial Port, W = Water Port 

Effective 

Date /Time 

Date/Time 

reported action 

took place M 12 12 

ZULU CCYYMMDDHHmm 

(example: 200612051459) 

Latitude 

Latitude of this 

location M 4 9 

CRIF or Degrees, minutes, seconds and 

direction 

Longitude 

Longitude of this 

location M 4 9 

CRIF or Degrees, minutes, seconds and 

direction 

POC name and 

other 

information 

Name and other 

information of 

POC at site M 20 100 

POC comm. 

phone number 

Comm. Phone 

number of POC 

at site M 10 15 

POC DSN phone 

number 

DSN Phone 

number of POC 

at site M 7 7 

POC E-mail 

address 

E-mail address of 

POC at site M 10 50 

Visibility Transaction 

Element Description 

Mandatory, 

Optional, 

Conditional 

Min 

Length 

Max 

Length Values 

Passive RFID Tag Tag identification value M 50 50 Expressed in hexadecimal 

RFID Location 

Control Number 

DAASC assigned during 

the registration process M 16 16 

Reader Function 

Code 

Describes process 

associated with this read M 1 1 

From Site to DAAS: 

A - Arrived 

D - Departed 

O - Observed 

F – Follow up 

From DAASC to Site: 

N- Not recorded for A, D, O 

and F (when no 856A or S 

exists for the tag.) 

DAASC will send 856A 

and S in response to the ‘F’. 

Tag Read 

Date/Time 

Date/Time reported action 

took place M 12 12 

ZULU CCYYMMDDHHmm 

(example: 200612051459) 
Att 

PDC 236 

7

b. Storage: Visibility transactions will be stored in the DAASC R table... Interface and functional 

requirements to share this information with WebVLIPS, AV, and/or GTN are currently under 

evaluation. 

c. Publications 

 (1) Passive RFID Visibility Transaction. Incorporate new data requirements into the DLMS 

and Defense Transportation Electronic Business (DTEB) libraries. The XML schema format for the 

visibility transaction is under development and will be provided separately. 

 (2) Reader Registration. The most efficient effective method for registration is currently under 

evaluation. A set of XML schema formats or on-line registration will be provided. In response to this 

PDC, Components may comment on preference for transactional exchange for registration vs. webbased registration. 

 (3) DLMS Manual. Incorporate enclosed chapter describing the procedures for registering 

passive RFID readers and furnishing passive RFID tag read information to DAAS. This chapter will be 

expanded over time as the process is defined and enhanced. 

d. Asset Visibility and Tracking Applications. Interface requirements for incorporation of tag read 

locations is under evaluation and will be provided separately. 

Enclosure 
Att 

PDC 236 

8

DOD 4000.25-M Volume 2, November 2006 

Change dd

C24. CHAPTER 24

Passive Radio Frequency Identification (RFID) Implementation 

C24.1 General. This chapter provides general information supporting the Department of Defense 

(DOD) RFID implementation. The DOD requires integration of passive RFID technology in the DOD 

Supply chain. Visibility is a critical component of this project and the Defense Logistics Management 

System (DLMS) includes the establishment of data requirements that support visibility across the DOD 

supply chain. The detailed procedures pertaining to this program are under development and this 

chapter will be expanded over time. Stakeholder information regarding this passive RFID 

implementation may be found on the DOD AIT website (URL: http://www.DODait.com). 

C24.2 Applicability and Scope. This guidance is applicable to the Alaska RFID (ARI) Program and 

may be applied to future passive RFID implementations. The scope of the project includes systems that 

currently collect supply and transportation data for the Defense Logistics Agency (DLA) and United 

States Transportation Command (USTRANSCOM) business processes used to generate that data, 

technologies to collect new data, software to integrate the data, and tools to visualize the information. 

 

C24.3 Process Overview. Participating activities will register passive RFID readers as specified below 

for the purpose of identifying the location of the reader. Once registered, scanned tag reads will be 

reported to DAAS using the Visibility Transaction which provides both the passive RFID and reader 

identification. The purpose of this is to associate the tag identification and location with previously 

transmitted logistics transactions containing passive RFID, e.g., 856S, Shipment Status, and 856A, 

Receipt/Shipment, Consolidation/Due-in Notice. Should the middleware fail to associate the tag with a 

previously transmitted 856S, Shipment Status, and 856A, Receipt/Shipment, Consolidation/Due-in 

Notice, the activity may ask for a follow-up 856A and S by sending a Visibility Transaction to DAASC 

with an action code of ‘F’. 

C24.3.1 Reader Registration. 

 C24.4.1.1. The reader registration is applicable to handheld or fixed passive RFID devices for the 

purpose of identification of its location and role in the supply chain. The term “reader” refers to a 

specific reader, group of readers, or all readers at a site, depending on how a specific site chose to 

register its readers. 

C24.4.1.2. The registering site will provide to Defense Automated Addressing System (DAAS) 

the location registration data, described below, via the site’s middleware application (Savi Site Manager, 

Globe Ranger, etc.) or via the worldwide web (to be determined). DAAS will establish that reader in a 

location table. The location control number must be used on every subsequent transaction sent to DAAS 

from the field. 

C24.4.1.3. After a reader is successfully registered; sites can update point of contact (POC) 

information or delete the reader. POC information is for restricted use and will not be displayed in 
Att 

PDC 236 

9

routine queries. Only registered readers can be updated or deleted. A previous deleted reader cannot be 

re-registered with the same location control number nor can it be updated. 

C24.4.1.4. Any time a reader or group of readers is changed, moved, or retired, the 

site must send the update to DAASC using the same location registration transaction with a delete in the 

action taken field. If the reader or group of readers is just being changed or moved and will be used at a 

different location, the reader or group of readers, after deletion, shall be registered again and receive a 

new location registration number. 

C24.4.1.5. Registration actions which are not successfully processed by DAAS will be rejected 

with the applicable reader registration action code.

C24.3.1 Reader Registration Data Requirements. Passive RFID reader registration, whether conducted 

via transaction exchange or on-line, will encompass the data requirements identified in Table C24.T1. 

 Table C24.T1. Passive RFID Reader Registration Data Requirements. 

Element Description 

Mandatory, 

Optional, 

Conditional 

Min 

Length 

Max 

Length Values 

RFID Location 

Control Number 

DAAS-assigned 

upon initial 

registration; required 

in update and delete; 

blank in the establish 

option C 16 16 

Reader 

Registration 

Action 

Describes purpose of 

registration action or 

DAAS response to 

the registration 

action 

M 

2 2 

From Site to DAAS: 

E_ - establish reader 

U_ - update reader information 

D_ - delete reader 

From DAAS to site: 

CE - establish reader confirmed 

CU - update reader confirmed 

CD - delete reader confirmed 

NE - establish reader not accepted 

NU - update reader not accepted 

ND - delete reader not accepted 

Reader Type 

Location's reader is 

fixed or mobile M 1 1 F = fixed, M = Mobile 

Reader 

Identification 

Number 

Number assigned to 

this reader or group 

of readers by the site M 10 10 

Location 

DODAAC, CAGE, 

Water Port or Aerial 

Port code for this 

location M 5 6 

Location Text 

Further description 

of this location O 1 50 

Free form text; Possible entries would be 

Area xxx, Bldg xxx, Post xxx, Door xxx, 

Floor xxx, 
Att 

PDC 236 

10

Type of Location 

Code location is 

using to report by M 1 1 

D = DODAAC, V = CAGE Code, A = 

Aerial Port, W = Water Port

Effective 

Date /Time 

Date/Time reported 

action took place M 12 12 

ZULU CCYYMMDDHHmm 

(example: 200612051459) 

latitude 

Latitude of this 

location M 4 9 CRIF3

 or degrees, minutes, seconds and direction 

longitude 

Longitude of this 

location M 4 9 CRIF or degrees, minutes, seconds and direction 

POC name and 

other 

information 

Name and other 

information of POC 

at site M 20 100 

POC comm. 

phone number 

Comm. Phone 

number of POC at 

site M 10 15 

POC DSN phone 

number 

DSN Phone number 

of POC at site M 7 7 

POC E-mail 

address 

E-mail address of 

POC at site M 10 50 

 

C24.3.3 Visibility Transaction Process. When a shipment with passive RFID arrives, departs or is 

observed at a registered reader location, the reader will send the visibility transaction to DAAS. If the 

reader has an assigned role (e.g., receiving or shipping) the transaction will report that action (e.g., 

arrived or shipped) using the appropriate action codes. If the device cannot determine arrival or 

departure, the action code observed will be used. Valid visibility transactions will be accepted and 

stored in DAAS. Visibility transactions from non-registered readers or with an invalid location control 

number will be returned to the sender with an ‘N’ in the sending location action indicating the 

transaction had an error and was not recorded at DAASC. 

Should the middleware fail to associate the tag with a previously transmitted 856S, Shipment 

Status, and/or 856A, Receipt/Shipment, Consolidation/Due-in Notice, the activity may ask for a followup 856A and S by sending a Visibility Transaction to DAASC with an action code of ‘F’. If DAAS does 

not have the information, the sender will receive an ‘N’ in the sending location action indicating the 

corresponding 856S or 856A transaction was not recorded at DAASC. If DAASC does have the 856A 

or 856S, the appropriate transaction will be sent to the requestor. 

C24.3.4 Visibility Transaction Data Requirements. Passive RFID visibility transactions must contain 

the data requirements identified in Table C24.T2. 

Table C24.T2, Passive RFID Visibility Transaction Data Requirements

Element Description 

Mandatory, 

Optional, 

Conditional 

Min 

Length 

Max 

Length Values 

Passive RFID Tag Tag identification value M 50 50 Expressed in hexadecimal 

 

3

 Enter “CRIF” for undisclosed locations 
Att 

PDC 236 

11

RFID Location 

Control Number 

DAASC assigned during the 

registration process M 16 16 

Reader Function 

Code 

Describes process 

associated with this read M 1 1 

From Site to DAAS: 

A - Arrived, 

D - Departed 

O - Observed 

F – Follow up 

From DAASC to Site: 

N- Not recorded for A, D, O, 

and F (when no 856A or S exists 

for the tag.) 

DAASC will send 856A and S in 

response to the ‘F’. 

Tag Read 

Date /Time 

Date/Time reported 

action took place M 12 12 

ZULU CCYYMMDDHHmm 

(example: 200612051459) 

 

C24.3.5 Data Storage Process. DAAS will store both the registration and the passive RFID visibility 

transaction, in addition to the already stored R table data. All error free visibility transactions arriving at 

DAAS will be stored upon arrival for approximately seven months. All error free device registrations 

will be stored until the transaction ‘cancelling’ the device is received. 
Att 

PDC 236 

12

ARI Context Diagram