KR20110035828A - Mobile rfid device and data communication method thereof - Google Patents

Abstract

PURPOSE: A mobile RFID(Radio Frequency IDentification) device and a data communication method thereof are provided to reduce the errors of a command or response received and transmitted between a mobile communication terminal unit and an RFID reader. CONSTITUTION: A mobile communication terminal(111) provides a command, and an mRFID(mobile RFID) reader unit(112) provides the mobile communication terminal with the response for the command provided from the mobile communication terminal. The mobile communication terminal and the mRFID reader unit respectively include a CRC circuit for inspecting whether or not there is an error in a protocol message of the command or response. The mobile communication terminal unit retransmits the command to the mRFID reader unit according to the inspection result.

Description

Mobile radio frequency recognition device and data communication method thereof

The present invention relates to a mobile electronic device, and more particularly, to a mobile radio frequency identification device (hereinafter, referred to as a mobile RFID device) using RFID technology and a data communication method thereof.

RFID (Radio Frequency IDentification) technology is a technology that can read or record information in a non-contact manner from a tag having unique identification information using radio frequency. RFID technology can recognize, track, and manage tagged objects, animals, and people. Such RFID technology has a plurality of tags (electronic tags or transponders) (hereinafter referred to as 'tags') attached to an object or animal with unique identification information and RFID readers for reading or writing information contained in the tags. Interrogator (hereinafter referred to as RFID reader).

Disclosure of Invention An object of the present invention is to provide a mobile RFID device and a data communication method thereof capable of reducing errors in commands and responses transmitted and received between a mobile communication terminal and an RFID reader.

A data communication method of a mobile RFID device according to an embodiment of the present invention, the mobile communication terminal unit providing a command (command) to the mRFID reader unit; Providing, by the mRFID reader unit, a response to a command to the mobile communication terminal unit; And checking whether there is an error in the protocol message of the command or the response, and retransmitting the command to the mRFID reader unit according to a test result.

In an embodiment, the command and response include a CRC field for checking an error of a protocol message. The CRC field is located after the endmark field of the protocol message. The number of retransmissions of the command may be limited to K (K is a natural number).

Mobile RFID device according to an embodiment of the present invention comprises a mobile communication terminal for providing a command (command); And an mRFID reader unit for providing a response to a command provided from the mobile communication terminal unit to the mobile communication terminal unit. Here, the mobile communication terminal unit and the mRFID reader unit includes a CRC circuit for checking whether there is an error in the protocol message of the command or the response. The mobile communication terminal may retransmit the command to the mRFID reader according to the error check result.

In an embodiment, the command and response include a CRC field for checking an error of a protocol message.

In another embodiment, the command is a set security key command, and the set security key command may include information about an ESN, a phone number, and a user-specified key. The command is a set frequency mode command, and the set frequency mode command may include information about a frequency hopping mode, an LbT mode, or a specific frequency use. The command is a set MAC control command, and the set MAC control command may include information on whether to use medium access control (MAC). The command is a start auto read command, and the start auto read command may include information about a maximum number of tags that can be read, a tag maximum duration, and a repetition cycle.

According to the present invention, malfunction of the mobile RFID device due to an error in a command or a response can be prevented.

1 is a block diagram illustrating a mobile RFID device according to an embodiment of the present invention.
2 and 3 show the protocol message structure of the command and response shown in FIG.
4 and 5 show the payload type of the command and response shown in FIG.
FIG. 6 is a flowchart illustrating a method of operating the mobile RFID device shown in FIG. 1.
7 through 9 show set security key commands and responses by way of example.
10 and 11 exemplarily show a set frequency mode command and response.
12 and 13 exemplarily show a set MAC control command and response.
14-16 illustrate a start automatic read command and response by way of example.
17 to 22 exemplarily illustrate a start automatic read2 command and a response.
23 and 24 exemplarily show a stop automatic read2 command and response.
25 to 28 exemplarily illustrate a start automatic read 3 command and a response.
29 and 30 exemplarily show a stop automatic read 3 command and response.
31 and 32 exemplarily illustrate a read type C TID command and a response.
33 and 34 are flowcharts illustrating a data communication method between a mobile communication terminal unit and an mRFID reader unit.

DETAILED DESCRIPTION Hereinafter, exemplary embodiments or application examples of the present invention will be described with reference to the accompanying drawings so that those skilled in the art may easily implement the technical idea of the present invention. Shall be.

Ⅰ. Mobile RFID Device

1 is a block diagram illustrating a mobile RFID device according to an embodiment of the present invention. Referring to FIG. 1, the mobile RFID device 100 includes a mobile RFID phone 110 (hereinafter referred to as mRFID phone) and a plurality of tags 121 to 12N. In addition to the mRFID phone 110, the mobile RFID device 100 may also use other electronic devices such as a PDA, a PMP, a notebook computer, or the like using RFID technology.

Referring to FIG. 1, the mRFID phone 110 includes a mobile communication terminal 111 and a mobile RFID reader 112 (hereinafter referred to as mRFID reader). The mobile communication terminal 111 may be connected to the mRFID reader 112 through a hardware interface such as UART, I2C, SPI, or the like. The mobile communication terminal 111 provides a command to the mRFID reader 112 and receives a response from the mRFID reader 112. Commands and responses transmitted and received between the mobile communication terminal 111 and the mRFID reader 112 are defined by the protocol.

 The mRFID reader unit 112 may communicate with the plurality of tags 121-12N by using the UHF (860-960 MHz) band among various radio frequency bands for RFID / USN. On the other hand, the mRFID reader unit 112 can also be used in combination with the UHF (860-960 MHz) band and the HF (13.56 MHz) band. The mRFID reader 112 may use a frequency occupation scheme such as frequency hopping (FH) or listen before talk (LbT).

1, the mRFID phone 110 may include CRC circuits 101 and 102 in the mobile communication terminal 111 or the mRFID reader 112. In addition, the mRFID phone 110 may have a separate CRC circuit (not shown) outside the mobile communication terminal 111 and the mRFID reader 112. Meanwhile, the mRFID reader 112 may be built in the mRFID phone 110 (see FIG. 1) or may be connected to the outside of the mRFID phone 110 in a dongle type (not shown).

The conventional mRFID phone may exchange an incorrect command or response between the mobile communication terminal and the mRFID reader when the cellular phone battery is weak. Incorrect commands or responses can cause mRFID phones to malfunction. Since the mobile RFID device 100 according to the embodiment of the present invention includes the CRC circuits 101 and 102, a command or a response between the mobile communication terminal 111 and the mRFID reader 112 is performed. Malfunctions caused by errors can be prevented.

2 and 3 show the structure of a protocol message of a command and a response of the mRFID phone 110 shown in FIG. 1. 2 is a protocol message structure when the CRC circuit is not used, and FIG. 3 is a protocol message structure when the CRC circuit is used. In the case of FIG. 3, the CRC field is separately included in the protocol message. Referring to FIG. 3, the protocol message includes a preamble, a header, a payload, an end mark, and a CRC field.

The preamble and endmark fields indicate the start and end of the protocol message. The preamble and the endmark field may consist of 8 bits each. The preamble field is located at the beginning of the protocol message. The end mark field may be located at the end of the protocol message (see FIG. 2) or at the front of the CRC field (see FIG. 3). The preamble and the endmark field may have a constant value. For example, the preamble field may have 0xBB, and in the case of an endmark field, it may have 0x7E. Here, 0xNNNN stands for hexadecimal notation.

With continued reference to FIG. 3, the header field consists of a message type, code, and payload length field. The message type field indicates whether the protocol message is a command, a response, or a notification, and consists of a total of 8 bits. The code field contains information for identifying the type of command or response. Commands to be processed by the mRFID reader unit (see FIG. 1, 112) vary, and responses thereto also vary. Therefore, when codes are assigned according to the type of command or response, the mRFID reader 112 may distinguish them by referring to the message type field and the code field. The payload length field indicates the length of the payload field located immediately after the header field and is composed of 16 bits.

The payload field is where various types of data are stored. The payload field may include an argument related to a command or a response. In the payload field, various kinds of payload types may be used to fit various commands or responses.

The protocol message may include a Cyclic Redundancy Check (CRC) field after the endmark field. The CRC field is used to verify errors in message bits included in commands and responses.

Referring back to FIG. 1, the mRFID reader 112 calculates a CRC value of a command using the CRC circuit 102, and checksums or CRC values included in the command are valid. Hanji can be verified. If the CRC value is not valid, the mRFID reader 112 may discard the command, stop responding, or take no action. In this case, the mRFID reader 112 may send a response including a code field and a result code (for example, 0xFF) to the mobile communication terminal (see FIG. 1). In this case, the mobile communication terminal 111 may retransmit a command.

Similarly, the CRC circuit (see FIG. 1, 101) of the mobile communication terminal 111 calculates the CRC value of the response and verifies whether the checksum or CRC value included in the response is valid. can do. If the CRC value is not valid, the mobile communication terminal 111 may discard the response or retransmit the command within a limited number of retransmissions.

CRC values can be calculated in several ways. For example, a 16 bit CRC value (CRC-16) may be calculated using all message bits from the message type to the endmark field. For example, the CRC value may be calculated using a polynomial such as Equation 1 below.

In a 16-bit register (not shown) in the CRC circuits 101 and 102, the CRC value may be preloaded to 0xFFFF. The CRC value may be inverted, added after the endmark field, and transmitted. The CRC value may be transmitted with the most significant byte first. The most significant bit of each byte may be transmitted first.

4 exemplarily shows various payload types from Type A to Type AC. As shown in Figs. 4 and 5, payload types A to AC each include their own fields.

Referring to FIG. 4, payload type A consists of 8 bit arguments. Payload type B consists of arguments of variable size. Payload type C consists of an 8-bit modulation index, a byte mask, and an address. Payload type W consists of a 32 bit access password, a 16 bit UII length (unique item identifier length), a variable size UII, and 24 bit lock data.

Referring to FIG. 5, payload type Y is composed of an 8-bit argument Arg1 and a variable size argument Arg2. Payload type Z is composed of 8-bit arguments 1 to 3 (Arg1 to Arg3) and 16-bit arguments (Arg4). The payload type AA is composed of arguments 1 to 21 (Arg1 to Arg21). In payload type AA, argument 1 (Arg1) means the number of tags, and one message should have less than 10 tags. Payload type AB is composed of arguments 1 to 5 (Arg1 to Arg5). Arguments Arg1 to Arg5 indicate the maximum number of tags to read, the maximum tagging time, the read cycle, the access mode, and the TID start address. Payload type AC is composed of arguments 1 to 31 (Arg1 to Arg31). Arguments Arg1 to Arg31 include a maximum number of tags to be read, a PC, a UII, a content name, and the like.

FIG. 6 is a flowchart illustrating a communication method between the mobile communication terminal 111 and the mRFID reader 112 of the mobile RFID device 100 shown in FIG. 1. 1 and 6, a method of operating the mobile RFID device 100 according to an embodiment of the present invention will be described.

In step S110, the mobile communication terminal 111 provides a power on command to the mRFID reader 112 according to a user's request. The mRFID reader 112 is powered on in response to the power on command (S115).

In step S120, the mobile communication terminal 111 configures a command to be sent to the mRFID reader 112. Here, the command has the protocol message structure described in FIG. Commands may include things like reader control / management, tag reading, tag writing, tag lock / unlock, tag erasing, and additional functions.

In step S130, the mobile communication terminal 111 adds a CRC field to the command (command). The CRC field may be added after the endmark field as described in FIG. 3. In step S140, the mobile communication terminal 111 transmits a command (command + CRC) including a CRC field to the mRFID reader 112.

In step S141, the mRFID reader 112 receives a command from the mobile communication terminal 111 and performs a CRC check. The mRFID reader 112 determines whether there is a CRC error.

If there is no CRC error, step S142 is performed. In step S142, the mRFID reader 112 performs a command received from the mobile communication terminal 111. In step S143, the mRFID reader unit 112 constructs a response (hereinafter referred to as CMD_response) according to the command execution. The mRFID reader 112 adds a CRC field to the CMD_Response. The CRC field may be added after the endmark field as described in FIG. 3. In step S145, the mRFID reader unit 112 transmits a CRC_response (CMD_response + CRC) including a CRC field to the mobile communication terminal unit 111.

In step S141, if there is a CRC error, step S144 is performed. In step S144, the mRFID reader 112 configures a response (hereinafter referred to as ERR_response) according to the CRC error. The mRFID reader 112 adds a CRC field to the ERR_response. In step S145, the mRFID reader unit 112 transmits an ERR_response (ERR_response + CRC) including a CRC field to the mobile communication terminal unit 111.

In step S150, the mobile communication terminal 111 receives a response (ERR_response or CMD_response) from the mRFID reader 112 and performs a CRC check. The mobile communication terminal 111 determines whether there is a CRC error in the response (ERR_response + CRC or CMD_response + CRC) received from the mRFID reader 112.

If there is no CRC error (that is, there is no error in ERR_Response + CRC or CMD_Response + CRC), step S160 is performed. In step S160, the mobile communication terminal 111 determines whether the response received from the mRFID reader 112 is an ERR_ response. If it is not the ERR_ response, that is, the CMD_ response, the result is stored (S180). If there is a CRC error in step S150 or ERR_response in step S160, a process of sending a command (steps S170 and S140) is performed.

In step S170, it is determined whether the number of command retransmissions is less than or equal to the maximum number of retransmissions. The mobile communication terminal 111 stores the maximum retransmission number in advance and counts the number of retransmission commands. If the number of retransmissions is less than or equal to the maximum number of retransmissions, the command including the CRC field is retransmitted (S140). If the number of retransmissions is greater than the maximum number of retransmissions, the result is stored (S180).

In step S190, the mobile communication terminal 111 provides a power off command to the mRFID reader 112 in response to a user request. The mRFID reader 112 turns off the power in response to the power off command (S195).

Referring back to FIG. 1, the mobile RFID device 100 according to an embodiment of the present invention checks an error of a command or a response by using the CRC circuits 101 and 102 and the CRC field. )can do. According to the present invention, a malfunction of the mobile RFID device 100 due to an error in a command or a response can be prevented.

Hereinafter, various embodiments of a command and a response between the mobile communication terminal 111 and the mRFID reader 112 shown in FIG. 1 will be described. The protocol message of the command and response may include a CRC field.

II. Examples of Commands and Responses

1.Set Security Key

7 through 9 show set security key commands and responses by way of example. 7 to 9, the set security key command and response may include an CRC field after the endmark field. The value of the CRC field is exemplarily indicated by 0xNNNN.

7 and 8, the set security key command relates to the ISO 18000-6 Type C protocol and is used to set a security key or access a password. Set security key commands include a message type, code, payload length, and arguments. The message type is represented by 0x00 indicating the command. The code is represented by 0x18, which indicates a set security key. The payload type may be represented by payload type Y (see FIG. 5).

The argument consists of an 8-bit select security mode (SelSeM) to be sent to the tag and a 32-bit security key value (SeKey, see FIG. 7) or an access password (see FIG. 8). Referring to FIG. 7, the selection security mode (SelSeM) value is represented by 0x00 when the data security mode is disabled (default). If the data security mode is enabled, it is represented by 0x01. In FIG. 7, the selection security mode SelSeM is represented by 0x01.

Referring to FIG. 8, the Select Secure Mode (SelSeM) value is expressed as 0 × 10 when accessing a password for a reserved memory bank of a tag while the secure mode is disabled. While the security mode is enabled, it is represented by 0x11 when accessing the tag's password. In FIG. 8, the selection security mode SelSeM is represented by 0x01.

In FIG. 7, the security key value SeKey may be an electronic serial number (ESN), a phone number, and a user defined key. Referring to FIG. 7, a security key SeKey is represented by 0x80202180. Referring to Fig. 8, the access password is represented by 0x12345678.

9 exemplarily shows a structure of a response protocol message for a set security key command. The response to the set security key command includes a message type, code, payload length, and arguments. The message type is represented by 0x01 indicating the response. The code is represented by 0x18 in case of success and 0xFF in case of failure. The payload type may be represented by payload type A (see FIG. 4).

The argument is represented by the result code 0x00 if the set security key command is successful, and the result code 0x21 if the set security key command fails. In the case of a not supported command, the argument is represented by 0x17. In FIG. 9, the code is represented by 0x18 and the argument is represented by 0x00.

2. Set Frequency Mode

10 and 11 exemplarily show a set frequency mode command and response. 10 and 11, the set frequency mode command and response may include an CRC field after the endmark field. The set frequency mode command is used to set a frequency mode or set a special frequency.

Referring to FIG. 10, the set frequency mode command includes a message type, a code, a payload length, and an argument. The message type (msg type) is represented by 0x00 indicating the command. Code is represented by 0x19 indicating the set frequency mode. The payload type may be represented by payload type O (see FIG. 4, not shown). Payload type O consists of an 8 bit argument Arg1 and an 8, 16, 24, or 32 bit argument Arg2.

Referring to FIG. 10, the argument consists of 8-bit Arg1 (SelFM) and 24-bit Arg2. Arg1 represents the selected frequency mode (SelFM). For example, Arg1 is expressed as 0x00 when the selected frequency mode (SelFM) is in frequency hopping mode (default), 0x01 when in the LbT mode, and 0x02 when in a special frequency. do. It is represented by 0x02 in FIG. Arg2 defines an LbT dress (dBm unit) when Arg1 is 0x01, and defines a frequency (kHz unit) when Arg1 is 0x02. In FIG. 10, the frequency is represented by 0x0E0A3D (920.125 MHz).

11 exemplarily shows a structure of a response protocol message for a set frequency mode command. The response to the set frequency mode command includes a message type, a code, a payload length, and an argument. The message type is represented by 0x01 indicating the response. The code is represented by 0x19 in case of success and 0xFF in case of failure. The payload type may be represented by payload type A (see FIG. 4).

Argument Arg is represented by result code 0x00 in case of success and result code 0x22 in case of failure. In the case of a not supported command, the argument is represented by 0x17.

3.Set MAC Control

12 and 13 exemplarily show a set MAC control command and response. 12 and 13, the set MAC control command and response may include an CRC field after the endmark field.

12 exemplarily shows a structure of a protocol message for a set MAC control command. The set MAC control command is used to set a medium access control (MAC), particularly related to ISO / IEC 29143. The set MAC control command includes a message type, a code, a payload length, and an argument. The message type (msg type) is represented by 0x00 indicating the command. The code is represented by 0x1A indicating set MAC control. The payload type may be represented by payload type O (see FIG. 4, not shown).

The argument consists of 8-bit Arg1 (EnMAC) and 8-bit Arg2. Arg1 is used to enable or disable the MAC function (EnMAC). For example, Arg1 is represented by 0x00 when enabling the MAC function (default) and 0x01 when disabling the MAC function. In FIG. 12, EnMAC is indicated as 0x00.

The MSB 4 bits of Arg2 are used to represent the amplitude threshold of the interference interrogator, ranging from 0x0 (0%) to 0xA (100%, default). The LSB 4 bits of Arg2 are used to represent the average threshold of collision count, ranging from 0x0 to 0xF (default = 0x7). FIG. 12 shows a protocol message when EnMAC is 0x00, amplitude threshold of interference interrogator is 0xA, and average threshold of collision count is 0x7.

13 exemplarily shows a structure of a response protocol message for a set MAC control command. The response to the set MAC control command includes a message type, a code, a payload length, and an argument. The message type is represented by 0x01 indicating the response. The code is represented by 0x1A in case of success and 0xFF in case of failure. The payload type may be represented by payload type A (see FIG. 4).

Argument Arg is represented by result code 0x00 in case of success and result code 0x23 in case of failure. In the case of a not supported command, the argument is represented by 0x17.

4.Start Automatic Read

14-16 illustrate a start automatic read command and response by way of example. 14 to 16, a start automatic read command and a response may include a CRC field after an endmark field.

14 exemplarily shows a structure of a protocol message for a start auto read command. The start auto read command is used to start the auto tag read operation. The start auto-read command includes a message type, code, payload length, and arguments. The message type (msg type) is represented by 0x00 indicating the command. The code is represented by 0x27, indicating the start auto read. The payload type may be represented by payload type O (Arg2 is 16 bits).

The argument consists of an 8-bit command code (SelCode) and a 16-bit repeat cycle (RC). The 8 bit command code (SelCode) is for performing an automatic read operation. The range of command code is 0x21 to 0x26, and the auto read operation is not performed for other values. The number of read cycles is equal to the number of inventory rounds for the tag. The repetition cycle RC indicates the number of repetitions of the read cycle. In FIG. 14, a protocol message when the instruction code SelCode is 0x26 and the repetition cycle RC is 0x0064 is illustrated.

15 exemplarily shows a structure of a response protocol message for a start auto read command. The response to the start auto-read command includes the message type, code, payload length, and arguments. The message type is represented by 0x01 indicating the response. The code is represented by 0x27 in the case of success and 0xFF in the case of failure. The payload type may be represented by payload type A (see FIG. 4).

Argument Arg is represented by result code 0x00 in case of success and result code 0xOA in case of failure. The argument Arg is expressed as a result code 0x0E when the command code SelCode is not in the range of 0x21 to 0x26. Also, the argument Arg is represented by the result code 0x0E when the repetition cycle RC is not '0'. And the argument Arg is represented by result code 0x0B when the automatic read operation is being performed.

16 exemplarily shows a structure of a notification protocol message informing that the automatic read operation is completed. When data read from the tag is delivered, the notification protocol message matches the response corresponding to command codes 0x21-0x26.

A notification message includes a message type, a code, a payload length, and arguments. The message type (msg type) is represented by 0x02 indicating a notification. The code matches the code used in the start auto-read command. When data read from a tag is passed, the payload type matches the response corresponding to command codes 0x21-0x26. When the auto read operation is completed a predetermined number of times and the auto read operation is completed, the payload type is represented as payload type A (see FIG. 4).

When data read from a tag is passed, the arguments match the response corresponding to command codes 0x21-0x26. When the auto read operation is completed by a predetermined number of times and the auto read operation is completed, the argument includes the result code 0x1F. When there are no more tags to read, the argument contains result code 0x20.

5.Start Automatic Read2

17 to 20 exemplarily illustrate a start automatic read2 command and a response. 17 to 20, the start auto-read2 command and response may include a CRC field after the endmark field.

17 exemplarily shows a structure of a protocol message for a start auto-read2 command. The start auto read2 command is an auto read operation used to read all types of tags. In particular, the response to this command can send IDs for up to 10 tags simultaneously to the mobile communication terminal (see FIG. 1, 111).

The start auto-read2 command includes the message type, code, payload length, and arguments. The message type (msg type) is represented by 0x00 indicating the command. The code is represented by 0x38, which indicates the starting autoread2. The payload type may be represented by payload type Z (see FIG. 5).

The argument consists of four arguments: an 8-bit tag type (TagType), a maximum number of tag reads (MTNU), a maximum length of tag reads (MTIME), and a repeat cycle (RC). TagType is represented as 0x01 when reading the UID (unique identifier) of Type B tag, 0x02 when reading the UII (unique item identifier) bank of Type C tag, and all types of tags are automatically displayed. In case of reading with 0xFF.

The maximum number of tag read MTNU is expressed as 0x00 (default) when tagging as many times as the repetition cycle regardless of the number of tags. The other values indicate the maximum number of tags to read. The maximum tag read duration (MTIME) is expressed as 0x00 when tagging by repeated cycles regardless of this field. 0x01 to 0xFE represents the tagging duration in seconds. OxFF is used for tagging without being time-limited until a stop automatic read2 command. The repetition cycle RC is the same as that of the start auto read command, and indicates the number of repetitions of the read cycle. The priority between MTNU, MTIME and RC is MTNU> MTIME> RC. MTMU has the highest priority.

In FIG. 17, the tag type TagType is 0x02, the maximum number of tags to read (MTNU) is 0x03 (3 tags), the maximum tag reading duration MTIME is 0x0A (10 seconds), and the repetition cycle (RC). Repeat Cycle) shows a protocol message when 0x0F.

On the other hand, there are two types of response and one type of notification in the message transmitted from the mRFID reader unit (see FIG. 1, 112) to the mobile communication terminal unit (see FIG. 1, 111). 18 and 19 show examples of responses, and FIG. 20 shows examples of notifications.

18 shows the structure of the protocol message of the start auto read 2 response when the RFID reader succeeds in tagging. The response to the start auto-read2 command includes the message type, code, payload length, and arguments. The message type is represented by 0x01 indicating the response. The code is represented by 0x38 in case of success and 0xFF in case of failure. The payload type may be represented by payload type AA (see FIG. 5).

In the payload, TNUM, the first argument Arg1, indicates the number of tags included in the response message. Therefore, the size of the response message depends on TNUM. TNUM is less than 10 If the RFID reader 112 reads ten or more tags, the RFID reader 112 must send a response message for every ten tags. For example, when the RFID reader 112 reads 35 tags, the mRFID reader 112 should send four response messages to the mobile communication terminal 111.

The second argument Arg2, TTSZ, consists of 8 bits. Of the 8 bits, 3 bits indicate the tag type and 5 bits indicate the tag byte size. The 3 bit tag type is represented by 0x01 in the case of a type B tag, 0x02 in the case of a type C tag, and other values are reserved for future.

In FIG. 18, the number TNUM of tags is 0x03. The type and size (TTSZ) of tag 1 is 0x4E, the PC of tag 1 is 0x2000, and the UII of tag 1 is 0x300000009800000000000001. The type and size (TTSZ) of tag 2 is 0x4E, the PC of tag 2 is 0x2000, and the UII of tag 2 is 0x300000009800000000000002. The type and size (TTSZ) of tag 3 is 0x4E, the PC of tag 3 is 0x2000, and the UII of tag 3 is 0x300000009800000000000003.

19 shows the structure of the protocol message of the start auto read 2 response when the mRFID reader fails in tagging. Referring to Fig. 19, the code is 0xFF. Arg is a result code 0x0E if it is an invalid parameter, a result code 0x15 if a tag is not detected, a result code 0x17 if an unsupported command, and a command failure Is represented by the result code 0x24. In Fig. 19, the argument Arg is represented by 0x24.

20 exemplarily shows a structure of a notification protocol message informing that the automatic read 2 operation is completed. A notification message can be used for the start auto read2 operation. A notification message includes a message type, a code, a payload length, and arguments.

Referring to FIG. 20, a message type (msg type) is represented by 0x02 indicating a notification. When the auto read operation is completed under the predefined condition and the auto read operation is completed, the mRFID reader 112 transmits an argument Arg including the result code 0x1F to the mobile communication terminal 111. If there are no more tags to read, the argument contains result code 0x20. In Fig. 20, the argument Arg is represented by 0x1F.

FIG. 21 is a flowchart for explaining an operation of starting automatic reading 2 between the mobile communication terminal 111 and the mRFID reader 112 when the starting automatic reading 2 command is successful. Referring to FIG. 21, the start auto read 2 operation proceeds in the following order.

In the step 1), the start auto-read 2 command is provided from the mobile communication terminal 111 to the mRFID reader 112. In the step 2), the inventory round is performed between the mRFID reader 112 and the tag according to the condition of the command. In step 3), the start auto-read 2 response including the tag information is provided from the mRFID reader unit 112 to the mobile communication terminal unit 111. If the number of tags in step 3) is more than 10, the start auto read 2 response is repeatedly provided in units of 10 tags. In step 4), a start auto-read2 response containing tag information is finally provided. In step 5), a notification is provided from the mRFID reader unit 112 to the mobile communication terminal unit 111 indicating that the start auto-read 2 operation is completed.

FIG. 22 is a flowchart for explaining an operation of starting automatic reading 2 between the mobile communication terminal 111 and the mRFID reader 112 when the starting automatic reading 2 command fails.

Referring to FIG. 22, the start auto read 2 operation proceeds in the following order. In the step 1), the start auto-read 2 command is provided from the mobile communication terminal 111 to the mRFID reader 112. In step 2), the start auto-read2 response by payload type A (see FIGS. 4 and 20) is provided from the mobile communication terminal 111 to the mRFID reader 112.

6.Stop Automatic Read2

23 and 24 exemplarily show a stop automatic read2 command and response. Referring to FIGS. 23 and 24, the stop auto-read2 command and response may include a CRC field after the endmark field.

23 exemplarily shows a structure of a protocol message for an abort auto read2 command. Abort The autoread2 command is used to interrupt the autoread2 operation. The abort autoread2 command includes the message type, code, and payload length (PL) but no arguments. The message type (msg type) is represented by 0x00 indicating the command. The code is represented by 0x39, which indicates an interruption auto read2.

FIG. 24 shows the structure of a protocol message of aborted automatic read 2 response when the RFID reader unit succeeds in tagging. The response to the abort autoread2 command includes the message type, code, payload length, and arguments. The message type is represented by 0x01 indicating the response. The code is represented by 0x39 in the case of success and 0xFF in the case of failure. The payload type may be represented by payload type A (see FIG. 4).

The argument Arg is represented by 0x00 in case of success, 0x0C in case of Connot Stop Automatic Read, and 0x0D in case automatic read2 operation is not performed. In Fig. 24, the argument Arg is represented by 0x00.

7.Start Automatic Read3

25 to 28 exemplarily illustrate a start automatic read 3 command and a response. 25 to 28, the start auto-read3 command and response may include a CRC field after the endmark field.

25 exemplarily shows a structure of a protocol message for a start auto-read3 command. The start auto-read3 command is an auto-read operation that is used to read the tag's UII and special data in user memory, associated with the Type C tag. In particular, the response to this command can simultaneously send information on up to 10 tags to the mobile communication terminal (see FIG. 1, 111).

The start auto-read3 command includes a message type, code, payload length, and arguments. The message type (msg type) is represented by 0x00 indicating the command. The code is represented by 0x3A, which indicates the start auto read3. The payload type may be represented as payload type AB (see FIG. 5).

Arguments Arg1 to Arg5 include a maximum number of tag reads MTNU, a maximum number of tag read durations MTIME, an iteration cycle RC, a memory access mode AM, and a TID memory start address TSA.

The maximum number of tag read MTNU is expressed as 0x00 (default) when tagging as many times as the repetition cycle regardless of the number of tags. Other values indicate the number of tags to read.

The maximum tag read duration (MTIME) is expressed as 0x00 when tagging by repeated cycles regardless of this field. 0x01 to 0xFE represents the tagging duration in seconds. OxFF is used for tagging without being time-limited until a stop automatic read3 command.

The repetition cycle RC is the same as that of the start auto read command, and indicates the number of repetitions of the read cycle. The priority between MTNU, MTIME and RC is MTNU> MTIME> RC. MTMU has the highest priority.

Memory access mode (AM) is composed of 8 bits, in the case of an indirect access method (indirect access method) to perform separate inventory and read (expressed as 0x00), flex_query command of the mRFID reader unit (see Fig. 1, 112) In the case of the direct access method used, it is represented by 0x01, in the case of the auto accessing method, it is represented by 0x02, and other values are reserved for future.

The TID Start Address (TSA) consists of 16 bits and represents the start address in the TID memory bank. The 32 bit data at the start address of the TID memory contains a pointer to a content name field in the user memory bank. Therefore, in the indirect memory access method, the TSA is needed to locate the content name in user memory. However, in the direct memory access method, the TSA is ignored.

In FIG. 25, the maximum number of tags to read (MTNU) is 0x03 (3 tags), the maximum tag reading duration (MTIME) is 0x0A (10 seconds), the repeat cycle (RC) is 0x0F, and access mode. (AM) is 0x00 (indirect access mode) and a protocol message is shown when the TDI start address is 0x0300.

On the other hand, there are two types of response and one type of notification in the message transmitted from the mRFID reader 112 to the mobile communication terminal 111. 26 and 27 show examples of responses, and FIG. 28 shows examples of notifications.

FIG. 26 shows the structure of the protocol message of the start auto-read 3 response when the mRFID reader 112 succeeds in tagging. The response to the start auto-read3 command includes the message type, code, payload length, and arguments. The message type is represented by 0x01 indicating the response. The code is represented by 0x3A in case of success and 0xFF in case of failure. The payload type may be represented by payload type AC (see FIG. 5).

In the payload, TNUM, the first argument Arg1, indicates the number of tags included in the response message. Therefore, the size of the response message depends on TNUM. TNUM is less than 10 If the mRFID reader 112 reads more than 10 tags, the tags must send a response message every 10 tags. For example, when the mRFID reader 112 reads 35 tags, the mRFID reader 112 must send four response messages to the mobile communication terminal 111.

From the second argument Arg2, a 16 bit PC, a 96 bit UII, a variable content name, and the like are represented. The MSB 8 bits of T1CN contain the length of the content name in the first tag, and the next 8 bits represent the ASCII code type of content name characters. Arguments such as T1PC, T1UII, and T1CN can be repeated within 10 times in one message.

 Referring to FIG. 26, the number of tags (TNUM) is 0x03. The PC (T1PC) of tag 1 is 0x2000, the UII (T1UII) of tag 1 is 0x300000009800000000000001, and the content name (T1CN) of tag 1 is 0x05110000000002. The tag 2 PC (T2PC) is 0x2000, the tag 2 UII (T2UII) is 0x300000009800000000000002, and the tag 2 content name (T2CN) is 0x05110000000002. The tag 3 PC (T3PC) is 0x2000, the tag 3 UII (T3UII) is 0x300000009800000000000003, and the tag 3 content name (T3CN) is 0x05110000000002.

FIG. 27 shows the structure of the protocol message of the start auto read 3 response when the mRFID reader 112 fails in tagging. Referring to Fig. 27, the code is 0xFF. The argument Arg is represented by 0x0E if it is an invalid parameter, 0x15 if a tag is not detected, or as a result code 0x17 if an instruction is not supported. command failure) is expressed as 0x25. In Fig. 27, the argument Arg is represented by 0x25.

FIG. 28 exemplarily shows a structure of a notification protocol message informing that the automatic read3 operation is completed. A notification message can be used for the start auto read3 operation.

A notification message includes a message type, a code, a payload length, and arguments. The message type (msg type) is represented by 0x02 indicating a notification. The argument Arg is expressed as 0x1F when the autoreading 3 operation is performed under a predefined condition and the autoreading operation is completed, and 0x20 when there is no tag to read. In Fig. 28, the argument Arg is represented by 0x1F.

8.Stop Automatic Read3

29 and 30 exemplarily show a stop automatic read 3 command and response. 29 and 30, the abort automatic read3 command and response may include a CRC field after the endmark field.

29 exemplarily shows a structure of a protocol message for an abort automatic read3 command. Abort The autoread3 command is used to interrupt the autoread3 operation. The stop auto-read3 command includes the message type, code, and payload length (PL). However, the abort autoread3 command does not include arguments. The message type (msg type) is represented by 0x00 indicating the command. The code is represented by 0x3B, which indicates an interruption auto read3.

30 shows the structure of a protocol message of an abort auto-read 3 response when the mRFID reader 112 succeeds in tagging. The response to the stop auto-read3 command includes the message type, code, payload length, and arguments. The message type is represented by 0x01 indicating the response. The code is represented by 0x3B in case of success and 0xFF in case of failure. The payload type may be represented by payload type A (see FIG. 4).

The argument Arg is represented by 0x00 in case of success, 0x0C in case of Connot Stop Automatic Read3, and 0x0D in case automatic read3 operation is not performed. In Fig. 30, the argument Arg is represented by 0x00.

9. Read Type C TID

31 and 32 exemplarily illustrate a read type C TID command and a response. 31 and 32, a read type C TID command and response may include a CRC field after an endmark field.

31 exemplarily shows a structure of a protocol message for a read type C TID command. Read Type C The TID instruction is used to read the TID memory bank area of an ISO / IEC 18000-6 type C tag. The TID memory bank area is read through its length from the start address. When a protocol message for a read type C TID instruction is written, it needs a UII or a UII Set that points to a tag to read the TID memory bank. UII or UII Set has a variable length. While other arguments have a fixed length. Therefore, payload length should be added to UII or UII Set.

The read type C TID instruction includes a message type, code, payload length, and arguments. The message type (msg type) is represented by 0x00 indicating the command. The code is represented by 0x3C, which indicates a read type C TID. The payload type may be represented by payload type J (see FIG. 4, not shown). Payload type J consists of variable size argument 1 (Arg1), 16 bit argument 2 (Arg2) and 16 bit argument 3 (Arg3).

Referring to FIG. 31, an argument includes a 96 bit UII or UII Set, a 16 bit start address (TSA) of a TID memory bank area, and a 16 bit length (TDL; TID Data Length, in bytes). In Fig. 31, the UII is 0x30F4257BF4625F8000000002, the TID start address is 0x0300, and the length is 4 bytes.

32 exemplarily shows a structure of a response protocol message for a read type C TID command. The response to the read type C TID command includes the message type, code, payload length, and arguments.

The message type is represented by 0x01 indicating the response. The code is represented by 0x3C in case of success and 0xFF in case of failure. The payload type is represented by payload type G (see FIG. 4, not shown) in case of success, and by payload type A (see FIG. 4) when no failure or tag is detected or there is no TID data. Can be. Payload type G consists of 32 bit arguments.

The argument Arg contains the contents of the TID memory bank if successful, 0x15 if no tag is detected, 0x26 if the read fails, and 0x1C if there is no TID data. do. In Fig. 32, the content of the TID memory bank is 0x10000030.

III. Application examples of commands and responses

FIG. 33 is a flowchart illustrating a data communication method between a mobile communication terminal unit 111 (see FIG. 1) and an mRFID reader unit (see FIG. 1, 112). 33 shows an example of a Start Automatic Read command. Referring to FIG. 33, the CRC field is not included in the response provided from the mRFID reader 112 to the mobile communication terminal 111.

According to the method shown in FIG. 33, even if there are no more tags to read, the operation is stopped after unconditionally executing the designated number of times until the user is forcibly terminated. In addition, since only one response is possible to one tag, a large load of a processor in the RFID device may cause a malfunction when a large number of tags are recognized. And because of the redundancy of data, it takes a long time.

34 is a flowchart for explaining another example of the data communication method between the mobile communication terminal unit (see FIG. 1, 111) and the mRFID reader unit (see FIG. 1, 112). 34 shows an example of a Start Automatic Read 2 command.

Referring to FIG. 34, the CRC field is included in the response provided from the mRFID reader 112 to the mobile communication terminal 111. According to the method illustrated in FIG. 34, since the CRC field is included at the end of the protocol message, it may be determined whether there is an error in the corresponding message. Therefore, it is possible to prevent a serious error such as registering the tag information received in response from the mRFID reader unit 112 to the server.

Referring to FIG. 34, a read cycle (read cycle, 1 read cycle = 1 inventory round) from the mobile communication terminal 111 to the mRFID reader 112 before sending an automatic tag read command to the mRFID reader 112. , Parameters such as delay time (delay time between read cycles). Then, the ACK response is sent from the mRFID reader 112 to the mobile communication terminal 111.

From the mobile communication terminal 111 to the mRFID reader 112, a start auto-read2 command including a repeat cycle (repeat cycle, read cycle repeat count), tag read maximum duration, maximum number of tags to read, and the like is provided. . The mRFID reader unit 112 satisfies any one of the predetermined conditions (read inventory and repeat cycle as many as the read cycle and repeat cycle, read the tag for the maximum time set, recognize the tag for the maximum number of tags set), or read any more If no tag is found or the user is forced to quit, the tag stops being read.

In addition, the mRFID reader unit 112 reads the tag at a predetermined time interval (for example, one second) while reading the tag and transmits the tag to the mobile communication terminal unit 111 in one message at a time. When the start auto read 2 operation stops, a completion response is sent to the mobile communication terminal 111. This is an improvement of an inefficient method for the mRFID reader 112 to execute the inventory round unconditionally for a predetermined number of times.

According to the method illustrated in FIG. 34, when the number of tags that can be recognized by the mRFID reader unit 112 is small, the tag recognition operation of the mobile communication terminal 111 and the mRFID reader unit 111 is reduced. Tag recognition time can be minimized. For example, when the maximum number of tags that can be read is three, the maximum tag count is set to 3 in the mobile communication terminal 111, and when the three tags are recognized, the start auto read 2 operation is performed. Will be terminated automatically.

The mobile RFID device according to an embodiment of the present invention includes a CRC field in a command or response to check an error in a command or response transmitted and received between the mobile communication terminal and the mRFID reader. Can be. According to the present invention, a malfunction of the mobile RFID device 100 due to an error in a command or a response can be prevented.

Meanwhile, in the detailed description of the present invention, specific embodiments have been described, but various modifications are possible without departing from the scope of the present invention. Therefore, the scope of the present invention should not be limited to the above-described embodiments, but should be defined by the equivalents of the claims of the present invention as well as the following claims.

100; Mobile RFID device
110; mRFID Phone
111; Mobile communication terminal
112; mRFID reader
101, 102; CRC circuit 121-12N; tag

Claims (10)

In the data communication method of a mobile RFID device:
A mobile communication terminal providing a command to an mRFID reader, and receiving a response to the command from the mRFID reader; And
Checking whether there is an error in a protocol message of the command or the response, and resending the command to the mRFID reader unit according to a test result. The method of claim 1,
And the command and response include a CRC field for checking for errors in a protocol message. The method of claim 2,
Wherein the CRC field is located after an endmark field of a protocol message. The method of claim 1,
The number of retransmissions of the command is limited to K (K is a natural number). A mobile communication terminal unit providing a command; And
Including an mRFID reader for providing a response to the command provided from the mobile communication terminal to the mobile communication terminal,
The mobile communication terminal unit and the mRFID reader unit include a CRC circuit for checking whether there is an error in a protocol message of the command or the response;
And the mobile communication terminal retransmits the command to the mRFID reader according to an error check result. The method of claim 5, wherein
And the command and response include a CRC field for checking an error of a protocol message. The method according to claim 6,
The command is a set security key command,
The set security key command includes information on an ESN, a phone number, and a user specified key. The method according to claim 6,
The command is a set frequency mode command,
The set frequency mode command includes information on frequency hopping mode, LbT mode, or specific frequency usage. The method according to claim 6,
The command is a set MAC control command,
The set MAC control command includes information on whether to use medium access control (MAC). The method according to claim 6,
The command is a start auto read command,
And the start auto-read command includes information about the maximum number of tags that can be read, the maximum tagging duration, and the repetition cycle.

Images