Protocol

The protocol used by RAIN RFID is a slotted ALOHA protocol. That means that the available air-time is divided into time-slots. The reader determines how many time-slots there are available, and each tag will use one time-slot. The inventory for the reader, is divided in query rounds. In each query round, the reader determines how many time slots are available. If the reader expects a lot of tags, there will be a large number of time slots (but it will take more time to complete the query round), and if the reader expects a small number of tags there will be less time slots (and it will be faster to complete the round). However, if the reader expects a small number of tags (few time slots), and there are a lot of tags, they will collide with each other - causing collisions and a reduction in performance. This all is to be managed in the protocol.

The query command

In this command, the reader states a number of available time-slots for replies from labels. This can be anywhere between 1 and 65536 time-slots. The number of time-slots is automatically determined by the reader (or can be set by the user).

If a label receives such a command, it throws a dice with numbers between 1 and the maximum number of time-slots. This determines in which time-slot the label will answer. If the reader has completed sending the query command, it will continue asking 'is there a label in timeslot 1?'. There are now multiple possibilities:

No label replies. It could be that when having 16 time-slots and only 8 labels, no label has thrown 1 for its time-slot.
One label replies.
Multiple labels reply, a collision. In this case the reader is not able to distinguish between the tags, and the responses from both tags will be lost.
If there is one label in the time-slot, the label will sent out its EPC code, which is the main identifier for a tag. If the reader received this EPC code successfully, the reader moves on to the next time-slot. This will continue until all time-slots in the original command have been done. If not the reader might try again, and if that fails, it will continue to the next slot.

If there is a collision or the response from the tag is not well received by the reader, those tags are not 'read'. The reader still needs to read them in a next try. To efficiently use the available air-time, it doesn't make sense for the reader to read again all the tags that were successfully read. Therefore each tag keeps track of whether it was read by using inventoried flags.

The process continues after all time slots have been tried.

Flags

An RFID tag has inventoried flags that are set to either A or B. When the tag is first powered-up, the flag is set to A. When the tag is successfully read by the reader, the flag changes from A to B. After a certain amount of time, the flag returns from B to A again.

If the reader only wants to read the tags that it hasn't read before, it can specify in the Query command that only tags with its flag set to A should respond. Then, the tags that have been read before (where the flag has changed into B) will not respond.

The reader can also be set to target on tags with their flag set to B, to only read tags that were read recently. In that case, the tags will flip their flags back to A after they have been read. Some readers also support targeting both A and B flag in an alternating, first read all tags in A (that move to B), then read all tags in B (that move back to A afterwards), and so on.

Sessions

If the tags have their flag set to B, they need to return that back to A after some time, to allow for re-reading the same tag another time. However, some applications require a tag to be required continuously ("is it still there?"), while other tags want to optimise the reading performance for a large number of tags, and only want each tag to respond exactly once. That's why there is the concept of sessions in the communication protocol.

Each tag has in total four sessions. Each session has its own flag, that can be set to A or B. The difference between each session, is the way the flag when set to B returns back to A. The session in which the reader operates, is communicated in the query command. The behaviour is different when the tag is in the radio field of the reader, or outside the radio field.

Session	Returns to 'A' when in the field	Return to 'A' when not in the field
0	Never	Directly
1	Between 500 ms and 5 seconds	Between 500 ms and 5 seconds
2	Never	After more than 2 seconds
3	Never	After more than 2 seconds

Two readers can operate at the same time, using different sessions, and still make sure they both reliably read the tags.