Future-proofing RAIN Connectivity
Mar 14, 2019
The RAIN RFID market has been growing nicely throughout the latest years. The latest news is that last year a total of 15.4 billion RAIN ICs were sold – and we are nicely on track for more than 20 billion in 2020. At the same time, the market penetration is still very low. According to IdTechEx, in the most successful market segment, retail, we are at around 10% of the total accessible market, and with other segments, such as Industry 4.0, aviation, and food it is even lower. So, there is plenty of room to grow.
We can already see 100 billion tags a year in the horizon. I don’t know if it will be in 8 or 10 years, but we are getting there. Then maybe another ten more years, and we will be at 1 trillion. However, several things in our thinking will need to change for that to happen.
I can see three obstacles that we need to overcome.
- We need to think about what happens when applications overlap. We are already starting to reach the situation where tags from one application are entering the read zones of other applications, and it is causing problems.
- We need to prepare for people intentionally messing with the applications. This is something that has not been a big problem for now, but it will increase as RAIN RFID spreads wider.
- We need to stop thinking in terms of tags and start thinking about RFID enabled items. There will not always be a separate tag that is attached to a product.
Since the industry has accepted that source tagging is the way to go, there needs to be a way for the party that owns the RAIN system to specify to the party that tags the product, how to tag.
For that I propose the Tagging Specification.
The specification is a common language between the parties, and it could also work as a checklist to make sure that all aspects have been considered. But what should be in a tagging specification? This is my proposal:
Geographic Region
In which geographic regions does the tagged item need to be identifiable? This could be for example ETSI, FCC, or global; and this choice will affect the tuning of the tag. With the upcoming upper ETSI band we have more and more countries working around 915 MHz.
Tag Numbering Scheme
How do we encode the tags? This is one of the areas where we need to look into the future. When there are more and more tags out there, the applications start to overlap.
For example, in a running race we have tags in the bibs of the runners provided by the timing system provider. But we also have tags integrated in some of the garments or accessories of the runners, courtesy of the sports retailer. When the runners pass the RFID readers, there is a limited amount of time to detect each runner – or even get several readings for reliable timing – if there are tags around that don’t belong to that application. Juho’s blog post about tag flooding talks more about this. The radio protocol provides ways to ignore the irrelevant tags, but it takes more time, and it requires that all parties think about the numbering.
Security
One action that is closely related to encoding the tag data, is securing it. At the moment, RAIN RFID is not everywhere, and most RAIN RFID readers are professional equipment. But, we are already close to the time when different electronics enthusiasts get their hands on RAIN reader modules. It may take some more time, but at some point we will have more RAIN readers integrated in mobile phones. And when there is an opportunity, there will be sabotage and people trying to get gains for themselves by affecting the RAIN RFID systems.
Of course, different applications have different security needs. There are still surprisingly many applications out there, where there is zero security – the EPC is encoded and that’s it. Most applications lock the EPC memory and passwords. That may work for a while, but in the long run, you need a way to manage passwords, and Nedap’s Danny Haak’s proposal for managing RAIN passwords could be a solution. Finally, in some application there might be a need for authentication functionalities.
Tagging Method
There is a fundamental shift in the industry, where more and more tags are integrated either into the packaging or into the products themselves, be it a running backpack or a tire. Thus the specification is no longer about the tag itself but about the RAIN-enabled product – or maybe a smart product. So, another line in the tagging specification would be tagging method. Is the tag a sticker applied to the product? Is it a hang tag? Is the tag applied to the package? Or is it integrated somewhere inside the product? Perhaps it is up to the supplier to decide? This all depends on whether there is a use for the tag after the point of sale; for example for product returns, warranty etc.
Tag Size
Tag size is often the first specification that comes up. Usually we want the tag to be as small as possible. But there is a compromise between the bandwidth of the tag which affects the geographic range; its performance – how far it can be read from; and size. You can choose any two, but the third one will be a compromise.
Tagged Item Performance
Radio performance matters as well. But it is not the performance of the tag, it is the performance of the entire RAIN-enabled product. And that’s where inlay lists widely used in retail will be insufficient. Still several retailers maintain lists of inlays that are allowed for products sold in their stores. And Auburn University is certifying tags for different product categories. That is an ok starting point, if you want to do hang tagging. But not everyone does.
Determining radio performance for RAIN-enabled products is somewhat more difficult than for just inlays or tags; and the testing methodology should be thought out for each industry. The TIPP methodology was developed for retail several years ago, and now there is an ISO standard family coming out for RFID in tires. The application determines whether in the typical reading scenario there are multiple tags close to each other and from which directions the products need to be identifiable. The reader type used in the application, on the other hand, may determine the requirements for sensitivity and backscatter strength.
It is extremely important that the tagging specification includes a clear verifiable performance requirement – and that it is vendor agnostic. That is the only way that the industry can improve and innovate.
The tagging specification is my proposal for overcoming the obstacles we are facing – and this is my idea about what should be in the specification. Let us hear what do you think should be there!
