HOME   Cart(0)   Quotation   About-Us Tax PDFs Standard-List Powered by Google www.ChineseStandard.net Database: 189759 (3 Nov 2024)

GB/T 29768-2013 English PDF

GB/T 29768-2013 (GB/T29768-2013, GBT 29768-2013, GBT29768-2013)
Standard IDContents [version]USDSTEP2[PDF] delivered inStandard Title (Description)StatusPDF
GB/T 29768-2013English555 Add to Cart 0--9 seconds. Auto-delivery Information technology -- Radio frequency identification -- Air interface protocol at 800/900 MHz Valid GB/T 29768-2013
Preview PDF: GB/T 29768-2013

BASIC DATA
Standard ID GB/T 29768-2013 (GB/T29768-2013)
Description (Translated English) Information technology. Radio frequency identification. Air interface protocol at 800/900 MHz
Sector / Industry National Standard (Recommended)
Classification of Chinese Standard L64
Classification of International Standard 35.220.01
Word Count Estimation 86,888
Quoted Standard GB/T 29261.3-2012
Drafting Organization National University of Defense Technology
Administrative Organization National Information Technology Standardization Technical Committee
Regulation (derived from) National Standards Bulletin No. 18 of 2013
Proposing organization National Information Technology Standardization Technical Committee (SAC/TC 28)
Issuing agency(ies) General Administration of Quality Supervision, Inspection and Quarantine of the People's Republic of China, Standardization Administration of the People's Republic of China
Summary This standard specifies the T840 MHz ~ 845 MHz and 920 MHz ~ 925 MHz band radio frequency identification system physical layer and MAC layer parameters and operating mode of the air interface protocol. This standard applies to 840 MHz ~ 845 MHz and 920 MH


GB/T 29768-2013 GB NATIONAL STANDARD OF THE PEOPLE’S REPUBLIC OF CHINA ICS 35.220.01 L 64 Information technology - Radio frequency identification - Air interface protocol at 800/900 MHz ISSUED ON: SEPTEMBER 18, 2013 IMPLEMENTED ON: MAY 01, 2014 Issued by: General Administration of Quality Supervision, Inspection and Quarantine; Standardization Administration of PRC. Table of Contents Foreword ... 5  Introduction ... 6  1 Scope ... 11  2 Normative references ... 11  3 Terms and definitions ... 11  4 Symbols and abbreviations ... 11  4.1 Symbols ... 12  4.2 Abbreviations ... 13  5 Physical layer and media access control layer ... 14  5.1 Communication interaction model ... 14  5.2 The physical layer and media access control layer from the reader to the tag ... 14  5.2.1 General requirements ... 14  5.2.2 Operating frequency ... 14  5.2.3 FHSS parameters ... 15  5.2.4 Power leakage ratio of adjacent channel ... 15  5.2.5 RF signal envelope when the reader turns-on and turns-off the carrier ... 15  5.2.6 RF signal envelope from reader to tag ... 17  5.2.7 Data encoding ... 17  5.2.8 Preamble ... 18  5.3 Physical layer and media access control layer from tag to reader ... 19  5.3.1 Tag energization ... 19  5.3.2 Modulation scheme ... 19  5.3.3 Data encoding ... 20  5.3.4 Backscatter-link frequency ... 25  5.4 Data transmission sequence ... 25  5.5 Link time-sequence ... 25  6 Working method of protocol ... 27  6.1 Anti-collision mechanism ... 27  6.2 Tag storage area structure ... 29  6.2.1 Overview ... 29  6.2.2 Tag information area ... 29  6.2.3 Coding area ... 30  6.2.4 Security area ... 30  6.2.5 User area ... 33  6.3 Tag flag ... 34  6.3.1 Match flag ... 34  6.3.2 Session and checking flag ... 34  6.4 Tag state ... 36  6.4.1 General requirements ... 36  6.4.2 State transition ... 36  6.5 Reader command set ... 37  6.5.1 General requirements ... 37  6.5.2 Sorting commands ... 39  6.5.3 Start query command ... 41  6.5.4 Repeat query commands ... 43  6.5.5 Divide command ... 44  6.5.6 Disperse commands ... 45  6.5.7 Shrink command ... 46  6.5.8 Code acquisition command ... 47  6.5.9 Reply error command ... 47  6.5.10 Security parameter acquisition command ... 48  6.5.11 Request XOR authentication command ... 49  6.5.12 XOR authentication command ... 50  6.5.13 One-way XOR authentication command ... 51  6.5.14 Two-way XOR authentication command ... 53  6.5.15 Request authentication command ... 54  6.5.16 Authentication command ... 55  6.5.17 One-way authentication command ... 57  6.5.18 Two-way authentication command ... 58  6.5.19 Secure communication commands ... 59  6.5.20 Handle refresh command ... 60  6.5.21 Random number acquisition command ... 61  6.5.22 Access command ... 62  6.5.23 Read command ... 65  6.5.24 Write command ... 67  6.5.25 Erase command ... 68  6.5.26 Lock command ... 70  6.5.27 Kill command ... 73  6.6 Security authentication protocol ... 74  6.6.1 Overview ... 74  6.6.2 One-way authentication protocol of tag to reader ... 74  6.6.3 One-way authentication protocol for tags by reader ... 76  6.6.4 Two-way authentication protocol ... 78  6.7 Secure communication protocol ... 80  7 Summary of air interface parameters ... 81  7.1 Summary of physical layer and media access control layer parameters ... 81  7.2 Summary of protocol working mode parameters ... 82  7.3 Summary of anti-collision management parameters ... 83  Appendix A (Informative) Checking end conditions ... 84  Appendix B (Normative) Tables of tag state transitions ... 85  Appendix C (Normative) Tables of command responses of tag ... 95  Appendix D (Normative) CRC calculation ... 106  Appendix E (Normative) Operation state returned by the tag ... 107  Information technology - Radio frequency identification - Air interface protocol at 800/900 MHz 1 Scope This standard specifies the physical layer and media access control layer parameters and protocol working methods of the air interface in 840 MHz ~ 845 MHz and 920 MHz ~ 925 MHz radio frequency identification system. This standard applies to the design, production, testing, use of tags and readers for radio frequency identification systems in the frequency bands of 840 MHz ~ 845 MHz and 920 MHz ~ 925 MHz. 2 Normative references The following documents are essential to the application of this document. For the dated documents, only the versions with the dates indicated are applicable to this document; for the undated documents, only the latest version (including all the amendments) are applicable to this standard. GB/T 29261.3-2012 Information technology - Automatic identification and data capture (AIDC) techniques - Vocabulary - Part 3: Radio-frequency identification 3 Terms and definitions The terms and definitions as defined in GB/T 29261.3-2012 as well as the following terms and definitions apply to this document. 3.1 Response data pack The data as sent by the tag in the specified format to the reader according to the reader command. 4 Symbols and abbreviations The following symbols and abbreviations apply to this document. TRext - Indication of leading signal; XXXXb - Binary data identification; XXXXh - Hexadecimal data identification; || - Tandem. 4.2 Abbreviations AK - Authentication key; ASK - Amplitude shift keying; BLF - Backscatter link frequency; CRC - Cyclic redundancy check; DDS-BT - Dynamic disperse shrink binary tree; DSB-ASK - Double-sideband amplitude shift keying; FHSS - Frequency-hopping spread spectrum; FT - Frequency tolerance; LSB - Least significant bit; MSB - Most significant bit; PSK - Phase shift keying; PW - Pulse width; RDP - Response data pack; RK - Root key; SK - Session key; SSB-ASK - Single-sideband amplitude shift keying; TID - Tag identifier; TPP - Truncated pulse position encoding. c) The maximum value of T2 only applies to tags in the reply state and acknowledged state. If T2 reaches its maximum value, the tag shall jump to the arbitrate state. The maximum range of the tag’s judgment of T2 timeout shall be 20 Tpri ~ 32 Tpri. d) FT is the frequency tolerance as specified in Table 4. e) T1 + T3 shall not be less than T4. 6 Working method of protocol 6.1 Anti-collision mechanism Multi-tag anti-collision uses the DDS-BT mechanism, as shown in Figure 15. In this mechanism, the initial value of the tag time slot counter is set to 0. The time slot counter is gradually adjusted according to subsequent commands. When the time slot counter is 0, the tag jumps from the Arbitrate state to the reply state and starts to respond to the reader: a) When the tag has no response: 1) When the reader cannot receive the tag response, it first judges whether to end the checking. If the criterion is true, the checking is considered to be completed. Refer to Appendix A for the judgment method; 2) If it does not end the checking, it needs to determine whether the number of consecutive idle time slots reaches CIN (continuous idle threshold, typical value is 4). If the number of consecutive idle time slots is not less than CIN, then the shrink command is sent; the tag time slot counter values of all arbitrate state and reply state are divided by 2 and rounded; 3) If the number of consecutive free time slots is less than CIN, meanwhile the previous time slot reader sends a divide command, the reader sends a divide command with the divide position "1", meanwhile all tags with a slot counter value of 1 are divide; 4) If the number of consecutive idle time slots is less than CIN, meanwhile the previous time slot reader sends a divide command, the reader will send a repeat query command, meanwhile the tag time slot counter value of all arbitrate state and reply state is reduced by 1. b) When the tag responds correctly: Tags that support security authentication leave the factory with a security mode of 01b; tags that do not support security authentication leave the factory with a security mode of 00b, which cannot be changed. When security authentication is not required, the security mode shall be kept as 01b; when security authentication is required but no secure communication is required, write the security mode as 10b; when security authentication is required and secure communication is required, write the security mode as 11b. If the tag does not require security authentication, then secure communication is not required. b) Security function: It is used to indicate the security function supported by the tag, which is defined as follows: 1) 82h: XOR one-way authentication of the tag to the reader, 0b means not supported, 1b means supported; 2) 83h: Symmetric encryption one-way authentication of the tag to the reader, 0b means not supported, 1b means supported; 3) 84h: XOR one-way authentication of the tag by the reader, 0b means not supported, 1b means supported; 4) 85h: Symmetric encryption one-way authentication of the tag by the reader, 0b means not supported, 1b means supported; 5) 86h: XOR two-way authentication, 0b means not supported, 1b means supported; 6) 87h: Symmetric encryption two-way authentication, 0b means not supported, 1b means supported; 7) 88h: Secure communication, 0b means not supported, 1b means supported. c) Encryption algorithm: It indicates the encryption algorithm used, 0h represents encryption algorithm 1, 1h represents encryption algorithm 2, and so on. The cryptographic algorithms and random numbers involved in this standard shall follow the relevant national provisions on commercial cryptography. d) Key length: The length of the authentication key, in words. e) Tsec: After the reader sends an authentication command, a one-way authentication command, a two-way authentication command or a secure communication command, the reference time for waiting for the tag response, with a unit of 10 ms. The tag shall maintain a separate checking flag for each session. The checking flag for 4 sessions can be 0b or 1b. At the beginning of each checking cycle, the reader chooses to count the tags with the 0b or 1b value checking flag under one of the four sessions. The tags that are participating in the checking cycle of a certain session can no longer be used or modified for other sessions. The checking flag is the only resource provided by the tag to a given session independently, the other tag resources are shared by each session. After the tag is singularized, the reader can issue a command to make the tag a conversion checking flag for this session. The checking flag retention time of the tag shall be as shown in Table 7. The checking flag when the tag is energized shall be set as follows: a) The S0 checking flag shall be set to 0b. b) The S1 checking flag shall be set to 0b or 1b, depending on its stored value. If the retention time is exceeded after the tag setting takes effect, the tag shall set its S1 checking flag to 0b when it is energized. Since the S1 checking flag is not automatically refreshed, it can be restored from 1b to 0b even when the tag is energized. c) The S2 checking flag shall be set to 0b or 1b, depending on the value stored. If the tag's power-off time exceeds its retention time, the S2 checking flag when the tag is powered-on is automatically set to 0b. d) The S3 checking flag shall be set to 0b or 1b, depending on the value stored. If the tag power-off time exceeds its retention time, the S3 checking flag when the tag is powered-on is automatically set to 0b. When the initial state of the tag is any value, the tag will be set to 0b or 1b within a time less than or equal to 2 ms. The tag shall refresh its S2 and S3 checking flags when it is energized, which means that every time the tag is powered off, its S2 and S3 checking flags shall have a retention time as shown in Table 7. When a tag is participating in a certain checking cycle, the value of its S1 checking flag shall not be changed due to exceeding the retention time. In an checking cycle, if the S1 retention time is exceeded, the tag will modify the S1 checking flag to 0b at the end of the checking cycle. data field of 11XXXXb, if the length data field is not 0, the tag does not match. Tags that require security authentication do not respond to the sorting command with the storage area data field of 11XXXXb. If the logical storage area is locked as unreadable, the tag does not respond to the sorting command. For tags that support security authentication, the tag does not respond to the sorting command with the storage area data field of 11XXXXb. c) Target: Instruct the tag to set a matching flag or checking flag. d) Rules: Instruct the tag to set the matching flag or checking flag rules. The meaning of the four values is explained as follows: 1) 00b: The matched tag will set the flag to 1b; the unmatched tag will set the flag to 0b; 2) 01b: The flag of the matched tag remains unchanged; the flag of the unmatched tag is set to 0b; 3) 10b: The matched tag will set the flag to 1b; the flag of the unmatched tag will remain unchanged; 4) 11b: The matched tag will set the flag to 0b; the unmatched tag will set the flag to 1b. e) Pointer: Point to the bit address of the logical storage area to start matching. If the pointer exceeds the logical storage area, the tag does not match. f) Length: The bit length to be matched. If the length is 0 and the storage area data field is not 100000b, the tag matches. If the matching length exceeds the logical storage area, the tag does not match. g) Mask: The data that needs to be matched. If the length data field is an odd number, add a 0 to the lowest bit of the mask. When the tag receives a sorting command with an odd length data field, the lowest bit of the mask is ignored. h) Check: CRC-16 calculation includes command code, storage area, target, rule, pointer, length and mask data field. See Appendix D for the calculation of CRC-16. If the check included in the command received by the tag is wrong, the tag does not respond to the command. After the tag receives the sorting command, it changes the matching flag or checking flag according to the rules; it does not send a response data pack 1) 0b: The checking flag is 0b; 2) 1b: The checking flag is 1b. e) TRext: Leading signal indication, the meaning of the two values is explained as follows: 1) 0b: Backscatter-link preamble without preamble; 2) 1b: The backscatter-link preamble has a preamble signal. f) Backscatter-link rate factor: Determine BLF, as shown in Table 4. g) Coding selection: Specifies the coding method of the backscatter-link; the meanings of the 4 values are explained as follows: 1) 00b: FM0; 2) 01b: Miller-coding, the subcarrier coefficient M is 2; 3) 10b: Miller-coding, the subcarrier coefficient M is 4; 4) 11b: Miller-coding, the subcarrier coefficient M is 8. h) Check: CRC-16 calculation includes command code, condition, session, target, TRext, backscatter-link rate factor and code selection data field. See Appendix D for the calculation of CRC-16. If the check included in the command received by the tag is wrong, the tag does not respond to the command. For tags in the ready state, arbitrate state, reply state, after receiving the start query command, if their matching flag meets the conditional data field requirements in the start query command, meanwhile the checking flag and the target data field in the start query command are equal, then set the time slot counter to 0, jump to the reply state, send a response data pack to the reader. The format of the response data pack is as shown in Table 11. If the tag in the ready state, arbitrate state, or reply state, if its matching flag does not meet the requirements of the conditional data field in the start query command, or its checking flag and the target data field are not equal, it will not respond to the start query command. In the acknowledged state, authentication state, open state and security state, after receiving the start query command, if its matching flag meets the requirement of the conditional data field in the start query command, the flag is reversed. If the reversed checking flag is equal to the target data field in the start query command, set its time slot counter to 0, jump to the reply state, immediately send a response data pack to the reader. The format of the sends a response data pack to the reader according to the format of Table 11. If the value of the changed time slot counter is not 0, the tag jumps to the arbitrate state and does not send response data packs to the reader; 3) 10b: Reserved. If the divide location data field is 10b, the tag does not respond to the divide command; 4) 11b: Reserved. If the divide location data field is 11b, the tag does not respond to the divide command. c) Session: The session number where the checking cycle is located. If the session number of the tag that received the divide command is different from the session number that has started the cycle, the command will not be executed. When the tags in the acknowledged state, authentication state, open state and security state receive the divide command, reverse the checking flag and jump to the ready state. 6.5.6 Disperse commands The disperse command is used to disperse tags. The disperse command has no parameters. The frame format of the disperse command is as shown in Table 14. Table 14 -- Frame format of disperse commands Data field Command code Session Length 4-bit 2-bit Description 1000b 00b: S0 01b: S1 10b: S2 11b: S3 The definition of each data field in the frame format is as follows: a) Command code: 1000b, disperse command’s code; b) Session: The session number where the checking cycle is located. If the session number of the tag that received the disperse command is different from the session number that has started the cycle, the command will not be executed. The tag in the arbitrate state and the reply state, after receiving the disperse command, generates a random number, the value of the time slot counter is multiplied by 2 and the random number is added. If the value of the changed time slot counter is 0, the tag jumps to the reply state and sends a response a) Command code: 10110110b, the code of XOR identification command; b) SORNt: The reader calculates SORNt = RNt' (AK' + On); c) Handle: The 11-bit random number and CRC-5 sent by the tag during the checking process, or the 11-bit random number and CRC-5 sent after receiving the handle refresh command; d) Check: CRC-16 calculation includes command code, SORNt and handle data fields. See Appendix D for the calculation of CRC-16. If the check included in the command received by the tag is wrong, the tag does not respond to the command. 6.5.12.2 Response data pack After the tag in the authentication state receives the XOR authentication command, it compares whether the SORNt RNr' and AK' + On are equal. If they are equal, the tag considers that the reader has passed the authentication, sends a response data pack to the reader, jumps to the open state. If they are not equal, the tag considers that the reader has not passed the authentication, sends a response data pack to the reader, jumps to the arbitrate state. The format of the response data pack is as shown in Table 24. Table 24 -- Response data pack format of XOR authentication command Data field Command code Handle Check Length 8-bit 16-bit 16-bit Description Command operating state handle CRC-16 The definition of each data field in the response data pack is as follows: a) Operating state: See Appendix E for the specific meaning of operating state; b) Handle: The 11-bit random number and CRC-5 sent by the tag during the checking process, or the 11-bit random number and CRC-5 sent after receiving the handle refresh command; c) Check: CRC-16 calculation includes operating state and handle data field. See Appendix D for the calculation of CRC-16. 6.5.13 One-way XOR authentication command 6.5.13.1 Command frame format The one-way XOR authentication command is used to initiate the one-way authentication protocol flow based on the XOR operation of the reader to the tag. The frame format of the one-way XOR authentication command is as shown in Table 25. Table 25 -- Frame format of one-way XOR authentication command Data field Command code SRNt Handle Check Length 8-bit 16-bit 16-bit 16-bit Description 10110111b handle CRC-16 The definition of each data field in the frame format is as follows: a) Command code: 10110111b, One-way XOR identification command code; b) SRNr: The reader generates the XOR value of the 16-bit random number RNr and the authentication key AK, that is, SRNr = (RNr + On) AK; c) Handle: The 11-bit random number and CRC-5 sent by the tag during the checking process, or the 11-bit random number and CRC-5 sent after receiving the handle refresh command; d) Check: CRC-16 calculation includes command code, SRNr, handle data fields. See Appendix D for the calculation of CRC-16. If the check included in the command received by the tag is wrong, the tag does not respond to the command. 6.5.13.2 Response data pack After the tag receives the one-way XOR authentication command, it may need to send a response data pack to the reader according to the state it is in. The format of the response data pack is as shown in Table 26; meanwhile it jumps to the open state. Table 26 -- Response data pack format of one-way XOR authentication command Data field SORNr Handle Check Length 16-bit 16-bit 16-bit Description handle CRC-16 The definition of each data field in the response data pack is as follows: a) SORNr: Tag calculation SORNr = RNr' (AK' + On), wherein RNr' and AK' respectively represent the value of RNr and AK after cyclic shifting to the left by n bits, the value of n is the number of the bits whose value is 1 in RNr; b) Handle: The 11-bit random number and CRC-5 sent by the tag during the checking process, or the 11-bit random number and CRC-5 sent after receiving the handle refresh command; c) Check: CRC-16 calculation includes SORNr and handle data field. See Appendix D for the calculation of CRC-16. The reader compares whether SORNr RNr’ is equal to AK’ + On. If they are equal, the reader considers the tag to pass the authentication; if they are not equal, the reader considers the tag to fail the authentication. 6.5.14 Two-way XOR authentication command 6.5.14.1 Command frame format The two-way XOR authentication command is used to initiate the two-way authentication protocol process based on the XOR operation. The frame format of the two-way XOR authentication command is as shown in Table 27. Table 27 -- Frame format of two-way XOR authentication command Data field Command code SRNt Handle Check Length 8-bit 16-bit 16-bit 16-bit Description 10111000b handle CRC-16 The definition of each data field in the frame format is as follows: a) Command code: 10111000b, the code of request XOR authentication command; b) SRNr: The reader generates a 16-bit random number RNr, calculates the XOR value SRNr = (RNr + On) AK of RNr and the authentication key AK; c) Handle: The 11-bit random number and CRC-5 sent by the tag during the checking process, or the 11-bit random number and CRC-5 sent after receiving the handle refresh command; d) Check: CRC-16 calculation includes command code, SRNr, handle data fields. See Appendix D for the calculation of CRC-16. If the check included in the command received by the tag is wrong, the tag does not respond to the command. 6.5.14.2 Response data pack After the tag receives the two-way XOR authentication command, it may need to send a response data pack to the reader according to its state. The format of the response data pack is as shown in Table 28. Table 28 -- Response data pack format of two-way XOR authentication command Data field SORNr SRNt Handle Check Length 16-bit 16-bit 16-bit 16-bit Description handle CRC-16 The definition of each data field in the response data pack is as follows: a) SORNr: Tag calculates RNr = SRNr AK - On; calculates SORNr: Tag calculates SORNr = RNr' (AK' + On), wherein RNr' and AK' respectively indicate that RNr and AK are cyclically shifted to the left by n bits. The value of n is the number of bits with a value of 1 in RNr; b) SRNt: The tag generates the XOR value of the 16-bit random number RNt and the authentication key AK, that is, SRNt = (RNt + On) AK; c) Handle: The 11-bit random number and CRC-5 sent by the tag during the checking process, or the 11-bit random number and CRC-5 sent after receiving the handle refresh command; d) Check: CRC-16 calculation includes SORNr, SRNt, handle data fields. See Appendix D for the calculation of CRC-16. The reader compares whether SORNr RNr’ and AK’ + On are equal. If they are equal, the reader considers the tag to pass the authentication; if they are not equal, the reader considers the tag to fail the authentication. 6.5.15 Request authentication command 6.5.15.1 Command frame format The request authentication command is used to initiate the symmetric encryption authentication process of the tag to the reader. The frame format of the request authentication command is as shown in Table 29. Table 29 -- Frame format of request authentication command Data field Command code Handle Check Length 8-bit 16-bit 16-bit Description 10100000b handle CRC-16 The definition of each data field in the frame format is as follows: a) Command code: 10100000b, the code of request identification command; b) Handle: The 11-bit random number and CRC-5 sent by the tag during the checking process, or the 11-bit random number and CRC-5 sent after receiving the handle refresh command; a) Command code: 10110011b, the code of authentication command; b) Authentication data: including the encryption result of RNt and the reader, that is, RNt‖EAK (RNt‖SK), see 6.6.2 for details. If the length of the encryption result generated by the reader is an odd number, add a bit of 0 to the lowest bit of the encryption result, that is, the authentication data is encrypted data after adding 0; c) Handle: The 11-bit random number and CRC-5 sent by the tag during the checking process, or the 11-bit random number and CRC-5 sent after receiving the handle refresh command; d) CRC-16: CRC-16 calculation includes command code, authentication data and handle data fields. See Appendix D for the calculation of CRC- 16. If the check included in the command received by the tag is wrong, the tag does not respond to the command. 6.5.16.2 Response data pack After the tag in the authentication state receives the authentication command, it first judges whether the received RNt is equal to the RNr it generated. If it is equ...... ......