New developments in RFID label ICs: an overview
In the past few months all three major label IC vendors announced new products. Impinj launched the Monza R6-A, NXP the UCODE 8 and Alien the Higgs EC. As those products are likely to start appearing in actual RFID labels over the next few months, it is good to understand what the new features are and how they can benefit an RFID deployment.
Sensitivity trends
The first thing to consider is the sensitivity of the label IC. The sensitivity is (currently) one of the most influential parameters towards the reading distance you can obtain between a tag and a reader. I say ‘currently’ because this might change going forward, but that is topic for another post. The lower the sensitivity, the less power an IC needs to get turned on by a reader, the longer the reading distance. Moreover, an improved sensitivity also leads to better readability of ‘stacked’ labels when they are close together.
The chart below shows the IC sensitivity versus the year of introduction of the IC. Roughly, there is a 0.5 dB improvement in label sensitivity per year. For reference, an improvement of 3 dB in label sensitivity results in a 40% increase in reading distance. This thus happens about every six years currently.
While Impinj can be considered trendsetting, Alien and NXP are quickly following up on sensitivity. The newly introduced NXP UCODE 8 currently touts market leading sensitivity. Impinj’s latest development — the Monza R6-A — builds on the existing Monza R6 platform — not giving any improvements in this area.
Auto Tune and Self Adjust
Theoretical sensitivity is one thing, but the actual sensitivity (and thus reading distance) wildly varies depending on many factors. The radio frequency the tag is powered with (which depends from one region to another), the design of the antenna in the label, the material the label is applied on, etc. all matter. Optimization in one area can lead to less performance in another.
To overcome this, Impinj introduced the ‘Auto Tune’ functionality with the Monza R6 platform in 2015. As the name suggests, it automatically tunes (‘matches’) the radio frequency interface of the chip with the antenna on the label, and thus also the environment. The matching happens every time the label is powered by the reader. This mechanism ensures that the ‘peak sensitivity’ is available in a broader range of operating frequencies and applications. NXP recently introduced a similar functionality which they call ‘Self Adjust’.
The chart below shows the sensitivity of a label IC without and with this feature across frequency ranges. It is clearly visible that a label with this functionality, has a much wider valley, which results in a better performance over a larger frequency range.
The auto-matching functionality results in two significant benefits:
- With previous generations, the label sensitivity (and thus reading distance) would significantly change based on the environment the label was in. When a label was on a pair of jeans, a different reading distance would be observed than when the label was on a carton package. Auto-matching is able to reduce this variability, resulting in better readability of labels in varying conditions.
- An RFID label used to be optimized for a specific region, as each region in the world uses a specific frequency band to radiate power to the tag. This resulted in — for example — a larger reading distance in Europe compared to the Americas and Asia. The adjusting/tuning feature mitigates this effect, such that reading distance is optimized around the globe.
This is especially beneficial for fashion/apparel retail, as those companies operate on a global scale and have to work with many different product types.
Improve privacy: Untraceable
Privacy is a growing concern in the world, and the European Union is taking significant steps to ensure this is taken care of by means of the General Data Protection Regulation (GDPR). The main privacy challenge regarding the use of RFID labels is the fact that you are able to read the EPC from at least several meters away. As the EPC is serialized and in principle globally unique, this poses a risk to privacy — an individual could theoretically be linked to one or more EPCs. Most retailers solve this by integrating the RFID label in a swing ticket, that will be removed upon sale.
However, when additional use cases are considered (like brand protection or electronic article surveillance), further integration in the product makes sense. A solution is then needed to ensure privacy requirements for the customers are met, as they are not able anymore to easily remove the RFID labels from the product after purchase.
With the introduction of the Gen2v2 standard in 2014, ‘untraceable’ became part of the standard. The feature enables retailers to do the following:
- Significantly reduce the reading distance of the label.
- Hide parts of the EPC, such that (for example) the serial number cannot be read, and thus reduce the uniqueness of labels.
All those features are reversible, meaning that if the item is returned to a store, the regular reading distance can be restored. A password is put in place such that not everybody is able to change the reading distance.
‘Untraceable’ significantly reduces the privacy risks associated with using RAIN RFID labels and it is good to see that vendors are starting to implement it.
Reducing memory: no kill
The ‘kill’ functionality was long part of the standard feature set of label ICs. However, Impinj changed that with the introduction of the Monza R6: it removed the kill feature altogether. It can safely be assumed that this was a cost reduction effort. Not needing to store a kill password and an access password on a chip saves 64 precious bits, and memory storage is the most expensive part on a label IC.
However, there are use cases in retail where the ability to kill labels is a necessity. Therefore, it is not strange that the ability to kill labels is now possible again with the introduction of the Monza R6-A, in combination with 96 bits of EPC memory — the minimum required for retail applications.
NXP seems to take the more expensive route with the UCODE 8 — having 128 bits available for usage, combined with the ability to kill labels. The 128 bits are divided in 96 bit for the EPC and 32 bit user memory (the ‘8m’ variant), or 128 bit in total for the EPC (the ‘8’ variant). The Alien Higgs EC features the largest memory footprint: 128 bit EPC memory and 128 bit user memory.
Memory quality check
It is always assumed that once the EPC is programmed, the contents will never change. Unfortunately, reality is a bit more complicated. It can happen — in a very rare occasions — that one bit (out of the 96) changes value (from ‘0’ to ‘1’, or the other way around) — a so-called ‘bit-flip’. Depending on where this happens in the EPC, it can have some strange effects in practise: either the EPC is ignored, has a different GTIN or maybe a different serial number. The main reason for a bit-flip is the fact that the IC has not been programmed correctly during encoding: not enough power is captured to hold the value of the bit.
While it is difficult to assess how often this happens, and likely not often, it is better to be safe than sorry. Especially as the scale of deployments is increasing significantly. Therefore IC vendors are starting to build in mechanisms in the IC to cope with this. Unfortunately, this is not (yet) part of the standard, so implementations vary slightly from vendor to vendor. The most two common solutions are:
1. Error correcting codes. An error of one bit in the EPC is automatically corrected (without the user noticing), whether a second error results in an unreadable EPC.
2. Programming verification. When the EPC is programmed, it is possible to verify that the programming is strong enough to survive for long enough to outlive the lifetime of the product.
Error correcting codes that automatically correct the EPC are provided by NXP and Alien. With regard to programming verification, NXP has chosen an implementation where this is verified automatically upon locking the EPC. The implementation of Impinj requires a specific command, that requires additional implementation on the encoding side.
Feature overview per vendor and IC
The below table provides an overview of all the features for the different ICs and different vendors.
What’s next?
It is expected that the ‘race to the bottom’ for lower sensitivity will continue for the foreseeable future. As Impinj now relatively runs the oldest platform of label ICs, it is expected that they will be the next one to announce a successor. An ever improving sensitivity will enable use cases like continuous inventory with ceiling readers in the next few years.
What feature would you want to see in a next-generation label IC?
