Forward Vision Analytics

Errata to the RAIN Radio Protocol

July 7, 2016

Background

 

RAIN reader–tag communications use ISO/IEC 18000-63, equivalent to GS1 EPCglobal™ UHF Gen2.

The community has identified errata with ISO/IEC 18000-63REV1:2015 / UHF Gen2 V2.0.1 and sug-gests the following resolutions. The community will update this list if it finds additional issues and will submit the issues and suggested resolutions to ISO and GS1 EPCglobal™ at an appropriate time.  

 

Errata and their Resolution

Section Reference Issue Suggested Resolution
6.3.1.6.3 “Length shall comprise a 15-bit value field followed by an even parity bit…” Can length have a zero value? Length=0000h is an allowed value
6.3.2.12.3.11
6.3.2.12.3.12
6.3.2.12.3.11: “…AuthComm executed successfully, and length=0002h…”
6.3.2.12.3.12: “…SecureComm executed successfully, and length=0002h…”
6.3.2.12.3.12: “…SecureComm executed successfully, and length=0002h…”
Length requires even parity but 0002h has odd parity. Change length=0002h to length=0003h in these instances.
6.3.2.12.3.16
Annex N
“The memory that a Tag may hide includes words of EPC memory, the Tag serialization in TID memory, all of TID memory, and/or User memory… “ Can a tag optionally ignore the EPC, TID, and User fields in an Untraceable command like it can optionally ignore the U and range fields? Yes. Just like for the U and range fields, where the protocol says a tag may ignore the field but continue to process the remainder of the Untraceable, the same holds for the other fields in the command.
6.3.1.6.4 “A Tag shall set C=0 upon receiving either an access command with SenRep=0 (c.f. 6.3.2.12.3.10) or a Challenge com-mand…” Can a tag set C=0 upon receiving an access command with SenRep=1? Yes. A tag may set C=0 and deallocate its response buffer upon receiving an access command with SenRep=1, or at other times appropriate for a cryptographic suite.
6.3.2.11 ISO 18000-63 says “An Interrogator shall verify the correctness of the
handle in a Tag’s response to an access command.” This sentence is not in Gen2 V2.0.1
Will the community add this sentence to Gen2? The community will recommend adding this sentence to Gen2
Annex N a Tag shall implement the mechanisms in this protocol that prevent it from transitioning directly from the acknowledged to the secured state Does this clause require a tag’s Access password to be nonzero?  Add a note to Annex N which says “either (1) a nonzero Access password or (2) a deasserted Untraceable privilege for the Access password meet this clause’s intent”
6.3.2.12.3.11 The penultimate paragraph says, in the last sentence: “Note that this example presumes that the Tag was in the secured state; if the Tag was in the open state then the AuthComm would succeed but the reply to the Lock would be an error code.” The third paragraph says: “A Tag in the open or secured states that receives an AuthComm encapsulating a disal-lowed command, an unsupported command, or a command that does not support encapsulation (see Table 6.28) shall not execute the AuthComm and instead treat the com-mand’s parameters as unsupported (see Table C.30).” By Table 6.27, Lock is disallowed in the open state so the tag will not send an error code but instead treat the command’s parameters as un-supported. Change the last sentence in the penultimate paragraph to:
WAS: “…if the Tag was in the open state then the AuthComm would succeed but the reply to the Lock would be an error code.”
IS: “…if the Tag was in the open state then the Tag would not execute the AuthComm and instead treat the command’s parameters as unsupported.”
Figure 6.26 Flowchart notes How does a tag behave if it receives an Access command without a preceding Req_RN? Add a note 4 which says:
“[4] An Access command without a prior Req_RN is a faulty command.”