Input Paper
NFC Forum Technical Committee
Title:
Better Use of SENS_RES in NFC-A Collision
Resolution Activity
To:
Mode Switching Task Force
Submitting
Companies:
QUALCOMM, Inc.
Contact
Details:
John Hillan: jhillan@qualcomm.com
Date:
3rd February, 2012
Replaces:
N/A
This input paper proposes a modification to the Collision Resolution Activity for NFC-A that
improves the quality of the polling device’s understanding of the resolved devices.
Background of this Input Paper
[ACTIVITY] section 9.3.4 defines the procedure for resolving NFC-A devices in the
operating volume of a polling device. As written, although a SENS_REQ is sent every time
around the loop that there are more devices to resolve, the information in the SENS_RES
is never used.
IPR
Input in this document is subject to the Intellectual Property Rights Policy of NFC Forum,
Inc which may be found at http://www.nfcforum.org/members/legaldocs/NFC_Forum_IPR_Policy.pdf. A member who is submitting
technology for inclusion in a Specification must confirm that all controlled necessary claims
included in this submission will be licensed on RAND conditions.
Requested Action
The submitter requests the Mode Switching Task Force to consider this proposed
improvement to NFC-A Collision Resolution for inclusion in the next version of [ACTIVITY].
© 2008, NFC Forum Inc. All rights reserved.
Page 1 of 5
Submission Details
The following diagram shows the relevant part of figures 5 and 7 (Technology Detection, and Collision
Resolution for NFC-A).
Note that the value of SENS_RES held in greedy collection GRE_POLL_A[0] is only updated in Technology
Detection, even though in general it will contain collisions if there are multiple NFC-A devices in the
operating volume.
Note also, that every time collision resolution goes around the loop because at least one device remains to
be resolved, another SENS_REQ is sent, and another SENS_RES is received. Remembering that every time
around the loop, one more remote device is asleep and therefore not responding to the SENS_REQ, it is
clear that the number of collisions in the SENS_RES will reduce over time. It would be an improvement to
the activity as presently defined if GRE_POLL_A[0] were updated during collision resolution, as shown in
the modified diagram below.
Input Paper
© 2008, NFC Forum Inc. All rights reserved.
Page 2 of 5
Now when the Collision Resolution terminates, the value of GRE_POLL_A[0] will be collision free (unless
devices limit is reached, but even so it is likely to have fewer collisions than after Technology Detection). If
all devices are resolved, GRE_POLL_A[0] actually corresponds exactly to the last tag that was resolved.
Taking this a step further, if instead of overwriting the GRE_POLL_A[0] value in greedy collection, the
polling device were allowed to keep an array of SENS_RES, and to store each incoming one in a new
element (in the same way that it presently does with the NFCID1 values), at the end of Collision Resolution
it can infer what some of the bits were in earler SENS_RES.
An example may help clarify this. Consider the case where there were 3 NFC-A devices that were
successully resolved, and each SENS_RES was stored in an array.
Input Paper
© 2008, NFC Forum Inc. All rights reserved.
Page 3 of 5
After Technology Detection:
SENS_RES = 000*0000 00001*00 << Two collisions detected
After Collision Resolution loop 1:
SENS_RES[0] = 000*0000 00001*00 << Two collisions detected again
NFCID1[0] is now known
After Collision Resolution loop 2:
SENS_RES[1] = 00000000 00001*00 << One collision has now disappeared
NFCID1[1] is now known
After Collision Resolution loop 3:
SENS_RES[2] = 00000000 00001100 << Other collision has now disappeared
NFCID1[2] is now known
No further devices to resolve.
So now we have 3 NFCID1 values, and a SENS_RES array that looks like this:
SENS_RES[0] = 000*0000 00001*00
SENS_RES[1] = 00000000 00001*00
SENS_RES[2] = 00000000 00001100
Now, because you know that the final device responded “1” in the third bit from the right, you know that
the device before that must have responded with a “0” in that bit position (otherwise there would have
been no collision). Thus you can deduce that
SENS_RES[1] = 00000000 00001000
Then you continue onwards. Because device 1 responded “0” in the 4th bit from the left, device 0 must
have responded with a “1” there, so you know that
SENS_RES[0] = 00000000 00001*00
You can’t tell whether it responded 0 or 1 in the other bit, but at least you know more about it than you did
before.
Input Paper
© 2008, NFC Forum Inc. All rights reserved.
Page 4 of 5
Thus the polling device can gain an even better understanding of the devices that it has resolved than if it
just overwrites the SENS_RES in GRE_POLL_A[0].
The proposed changes to the specification are very minor.
For the “overwriting only” change, section 9.3.4, requirement 9.3.4.22 would become:
Symbol 21:
The NFC Forum Device MUST send the SENS_REQ Command and it MUST wait for the SENS_RES afterward,
as specified in [DIGITAL].
The NFC Forum Device MAY overwrite the value of GRE_POLL_A[0] with the SENS_RES Response.
The NFC Forum Device MUST proceed to Symbol 3.
For the “SENS_RES history” change, there main changes are:
In Table 15, include GRE_POLL_A[] as an output, and describe it as “Each element contains a SENS_RES
from an identified NFC-A device.”
Symbol 21:
The NFC Forum Device MUST send the SENS_REQ Command and it MUST wait for the SENS_RES afterward,
as specified in [DIGITAL].
The NFC Forum Device MUST store the SENS_RES Response in GRE_POLL_A[device counter].
The NFC Forum Device MUST proceed to Symbol 3.
Whether or not we include any text on the possible use of the array of SENS_RES values is a matter for
discussion.
Input Paper
© 2008, NFC Forum Inc. All rights reserved.
Page 5 of 5