**DoD 4000.25-M, Vol 3**

**DRAFT**

DLM 4000.25, Volume 3, March 23, 2012

# C3. CHAPTER 3

# passive radio frequency identification transactions

C3.1.  GENERAL.  This chapter provides procedures for reader registration and visibility**processing supporting DoD Radio Frequency Identification (RFID) implementation.  The Department of Defense requires integration of passive RFID (pRFID) technology in the DoD Supply chain.  Visibility is a critical component of this requirement.**The Defense Logistics Management Standards (DLMS) includes the establishment of data requirements that support**shipment**visibility across the DoD supply chain.  The detailed procedures pertaining to these requirements are provided in**this chapter.  DoD policy regarding this pRFID implementation is located on the DoD Automatic Identification Technology (AIT) Web site.

C3.2.  APPLICABILITY AND SCOPE.  This guidance is applicable to DoD pRFID system implementations.  The scope includes systems that send, receive, and/or collect supply and transportation data and the**business processes used to generate that data, technologies to collect new data, software to integrate the data, and tools to visualize the information.

C3.3.  PROCESS OVERVIEW

	C3.3.1.  Participating activities shall register pRFID Readers per the guidance in Section C3.4 for the purpose of identifying the Reader location.

	C3.3.2.  Once registered, scanned tag reads shall be reported either by a DoD system or middleware to the Defense Automatic Addressing System (DAAS) using the Visibility Transaction which provides the pRFID tag and Reader identification; the data elements for the Visibility Transaction are defined in Section C3.7.  The purpose of this process is to associate the tag identification and location with previously transmitted logistics transactions containing pRFID, e.g., DLMS 856S, Shipment Status; Defense Transportation Electronic Business (DTEB) Implementation Convention (IC) 856A, Receipt/Shipment Consolidation/Due-in Notice; and any others defined in the future.

	C3.3.3.  If the middleware fails to associate the tag with a previously transmitted logistics transaction, the activity will ask for a follow-up by sending a Visibility Transaction to DAAS with Reader Function Code F (Follow-Up), and DAAS shall transmit a Visibility Response Transaction containing the data elements defined in Section C3.9.

**C3.3.4.  There are three transactions[footnoteRef:1] to support this process; one is used for****sending Reader Registration data, a second for sending Visibility data, and****a third for****DAAS to respond to inquiries for unmatched tag reads.  The transaction details are covered in the following paragraphs. [1:  The schema files (XSD) can be viewed on the DLMS IC page.] 

C3.4.  READER REGISTRATION**PROCESS

**C3.4.1.  The Reader Registration**Transaction**is applicable to handheld or fixed pRFID devices for the purpose of identifying their 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 upon how the site chose to register its Readers.

	C3.4.2.  The registering site shall provide to DAAS the location registration data defined in Table C3.T1. via the site’s middleware application (e.g., Savi Site Manager, Globe Ranger) or via the World Wide Web (to be determined).  DAAS shall establish the Reader in a location table, assign a location control number (LCN), and send the Reader Registration Transaction back to the originator with the LCN.  The LCN shall be used on every subsequent transaction sent to DAAS from the field.

	C3.4.3.  After a site has successfully registered a Reader’s location, it is responsible for maintaining current point of contact (POC) information and deleting the Reader when no longer required.  POC information is for restricted use and shall not be displayed in routine queries.  Only registered Readers can be updated or deleted.  A previously deleted Reader cannot be re-registered with the same LCN, nor can it be****updated.

****C3.4.4 . Any time a Reader or group of Readers is updated, moved, or retired, the registering site shall send the update Reader Registration Transaction to DAAS using the original LCN with a delete in the Action Taken field.  If the Reader or group of Readers is just being updated or moved and will be used at a different location, a new Reader Registration Transaction shall be transmitted to DAAS with the new registration data, at which DAAS will assign a new LCN and send a Reader Registration Transaction back to the originator with the new LCN.  

	C3.4.5.  Registration actions that are not successfully processed by DAAS shall be rejected and a response sent with the applicable Reader registration action code.

C3.5.  READER REGISTRATION DATA REQUIREMENTS.  Passive RFID Reader Registration shall encompass the data requirements identified in Table C3.T1.

C3.6.  VISIBILITY TRANSACTION PROCESS

	C3.6.1.  When a shipment with pRFID arrives, departs, or is observed at a registered Reader location, the Reader shall communicate with the middleware, which shall send the Visibility Transaction to DAAS with a Reader Function Code of A (Arrived), D (Departed), or O (Observed).  If the Reader has an assigned role (e.g., receiving or shipping) the transaction shall be used to report that action (e.g., arrived or departed) using the appropriate action codes.  If the device cannot determine arrival or departure, the action code for Observed shall be used.

	C3.6.2.  At those sites electing to provide pRFID support for local deliveries, use the new Reader Function Codes in Table C3.T2.  For local delivery with pRFID, the Reader shall either record a delivery event or an undelivered (e.g., attempted delivery) event.  “Delivered” is defined as the customer accepting the materiel from the shipping entity.  “Undelivered” is defined as during normal operating hours and at no fault of the shipping entity, a shipment cannot be delivered.  When a local delivery with pRFID is delivered or undelivered using a mobile handheld Reader, the Reader information shall be uploaded to the middleware at the home base, which shall send the Visibility Transaction to DAAS with a Reader Function Code of X (Delivered) or U (Undelivered/Attempted Delivery).

	C3.6.3.  If the middleware fails to associate the tag with a previously transmitted logistics transaction, the activity will ask for a follow-up by sending a Visibility Transaction to DAAS with a Reader Function Code of F (Follow-Up).

	C3.6.4.  Valid Visibility Transactions shall be accepted and stored in DAAS.  Visibility Transactions from non-registered Readers or with an invalid LCN shall be returned to the sender with an ‘N’ in the sending location action indicating the transaction had an error and was not recorded at DAAS.

C3.7.  VISIBILITY TRANSACTION DATA REQUIREMENTS.  Passive RFID Visibility Transactions shall contain the data requirements identified in Table C3.T2.

C3.8.  VISIBILITY RESPONSE TRANSACTION PROCESS

	C3.8.1.  If the middleware fails to associate the tag with a previously transmitted DLMS 856S or DTEB IC 856A, the activity will send a Visibility Transaction to DAAS with a Reader Function Code of F (Follow-Up).

	C3.8.2.  If the requested information is found, DAAS shall transmit a Visibility Response Transaction containing the data elements defined in Section C3.9.

	C3.8.3.  If DAAS does not have the information, DAAS shall transmit to the sender a Visibility Response Transaction with N in the Reader Function Code field, indicating that the corresponding DLMS 856S or DTEB 856A transaction was not recorded at DAAS.

C3.9.  VISIBILITY RESPONSE TRANSACTION DATA REQUIREMENTS.  Passive RFID Visibility Response Transactions shall contain the data requirements identified in Table C3.T3.

C3.10.  DATA STORAGE PROCESS

	C3.10.1.  DAAS shall store the Reader Registration Transaction and the pRFID Visibility Transaction in addition to the “R Table” data.

	C3.10.2.  All error-free Visibility Transactions arriving at DAAS shall be stored upon arrival for approximately seven months.

	C3.10.3.  All error-free device registrations shall be stored until a Reader Registration Action**value of D (Delete Reader) is received by DAAS in a Reader Registration Transaction ‘cancelling’ the device.

	C3.10.4.  Figure C3.F.1 summarizes the general transaction process flow between a pRFID system and DAAS.

Figure C3.F1.  pRFID Data Flow (Between Site and DAAS)

**Passive RFID Server**

**System/ User**

DAAS

**Middleware**

**To DAAS**

**Visibility**

**Transactions**

**DB**

**Tag Data**

**Passive RFID Reader**

**To DAAS**

**Reader Registration**

**Transactions**

**From DAAS**

**Visibility**

**Response**

**Transactions**

**From DAAS**

**Visibility**

**Transactions**

C3.11.  PASSIVE RFID AND SHIPMENT STATUS

	C3.11.1.  DAAS “L Table”.  All pRFID readers are required to be registered in DAAS.  This is accomplished through use of the standard XML Reader Registration transaction, in which a unique LCN is assigned to the reader and its information is stored in the DAAS “L Table”.

	C3.11.2.  DAAS “R Table”.  When a shipment of DoD stocked materiel has pRFID tags applied to it, the association of the pRFID tag to a particular document number is identified in the DLMS 856S.  For Materiel Returns Program, retrograde, and directed returns with pRFID, the association of the pRFID tag to a particular document number is identified in the DLMS 856R.  In addition to these transactions being routed under normal MILSTRIP business rules, a copy is stored in the DAAS “R Table” as extended shipment data.

	C3.11.3.  DAAS “V Table”.  When the pRFID tag is subsequently read by a registered Reader, the standard XML Visibility Transaction is transmitted to DAAS to identify the LCN and the pRFID tag number that was read; this data is subsequently stored in the “V Table”.

	C3.11.4.  The fusion of the data in the “L”, “R”, and “V” tables enables enterprise visibility systems (e.g., Asset Visibility and WebVLIPS) to provide in-transit visibility in response to queries by associating the pRFID tag read to an LCN and a particular document number and/or transportation control number.

	C3.11.5.  Customer supply receiving business processes can be triggered by the pRFID tag read, by fusing the pRFID tag number with the matching DLMS 856S or DLMS 856R.

	C3.11.6.  This process works well for stocked shipments and shipments moving through a DLA Containerization and Consolidation Point (CCP).  However, the process delineated above has a gap when transportation offices are trans-shipping/cross-docking shipments for local delivery manifesting to on-base customers; deliveries to Materiel Processing Centers (MPC); outbound MILSTRIP shipments on behalf of on-base customers; re-warehousing actions between distribution depots; and outbound non-MILSTRIP shipments to off-base customers.  For local delivery manifested shipments, deliveries to MPC, and outbound MILSTRIP shipments on behalf of on-base customers, the ICP may already have sent a shipment status message; however, the pRFID tag information and updated transportation data may be absent from the message.  For re-warehousing actions and outbound non-MILSTRIP shipments, normally there is no supply shipment status message; therefore, the pRFID tag and transportation data are not transmitted to the receiving activity to facilitate use of pRFID tagging to trigger the receipt take-up process.  For requirements when transportation offices are trans-shipping/cross-docking shipments, other shipment status reporting procedures are followed.  These scenarios include local delivery manifesting to on-base customers; deliveries to MPC; outbound MILSTRIP shipments on behalf of on-base customers; re-warehousing actions between distribution depots; and outbound non-MILSTRIP shipments to off-base customers.

		C3.11.6.1.  For local delivery manifested shipments, deliveries to MPC, and outbound MILSTRIP shipments for on-base Customers, the DLMS 856S will need to use the transaction status reason code (BSN07 = “091” Trans-ship/Cross-dock Shipment Status (non-CCP)) to denote that the shipment status is being provided by a location performing trans-shipping/cross-docking subsequent to the original shipment.  The RIC From will be the RIC of the activity executing the local delivery manifest.  The remaining data elements for a shipment status message will be ascertained from the pack list/shipping documentation accompanying the shipment.  If the shipment already has a pRFID tag on it, no additional DLMS 856S is required; the existing pRFID tag will just need to be read and an XML Visibility Transaction sent to DAAS recording the tag read event.  If there is no document number on either the inbound data or on the pack list/shipping documentation, then do not generate the DLMS 856S for conveying the pRFID tag.  This is to preclude a data mismatch with the original DLMS 856S transmitted by the ICP, which will have a document number.

		C3.11.6.2.  For re-warehousing actions/transshipments between Distribution Depots in support of ‘Home’ Industrial Activity site and ‘Forward Support’ Industrial Activity site materiel requirements, a normal DLMS 856S should be generated and transmitted to DAAS.  This transaction should carry the normal shipment status message data along with the pRFID tag identification numbers and any extended transportation data (e.g., bill of lading number, commercial carrier tracking numbers).  Since there will never be a Materiel Receipt Acknowledgement (MRA) for these re-warehousing actions/transshipments between the Home and Forward Industrial Activities, a status reason code (BSN07=”048” Industrial Activity Re-Warehousing/Trans-ship Shipment Status) shall be included so that DAAS can flag these DLMS 856S instances and prevent them from triggering the MRA Report.

		C3.11.6.3.  For Outbound Non-MILSTRIP shipments documented on a DD1149, a DLMS 856S will be created by the shipping activity.  See the DLMS Manual, DLM 4000.25, Volume 2, Chapter 5, Status Reporting, Table C5.T.1. for the minimum data elements that should be included in the shipment status message; sources of the data are the DD1149 and pRFID tag information.

**C**

C3-10	CHAPTER 3