GB/T 29768-2013 (GB/T29768-2013, GBT 29768-2013, GBT29768-2013)
Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Standard Title (Description) | Status | PDF |
GB/T 29768-2013 | English | 555 |
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
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......
......
|