Using the right NFC tag type for the right NFC application

Article courtesy of Innovision

Introduction

This article follows on from Part I of Innovision's "NFC in the real world"- which took a high-level look at NFC applications, technology and markets - and aims to help NFC product and service developers identify the suitability of the four NFC Forum-mandated tag types for various applications.

Near Field Communication (NFC) is set for widespread adoption in a whole range of applications. NFC makes people's lives easier and more convenient by building on existing systems and human behaviour. It will make accessing new media and content services more intuitive; make it easier to pay for things; easier to discover, synchronize and share information; and easier to use transport and other public services.

NFC opens up new product and service opportunities for many players: from network operators and handset device manufacturers, through application and service developers, to service providers and enterprises. But for the NFC mass market to take off - and for profitable businesses to be built around the technology - it is important that designers and manufacturers make the right technology choices. This is especially true for the NFC tag, where features and capabilities need to match the needs of the application - at a price level that is appropriate for mass-market deployment.

The initial mass-market applications of NFC are likely to build on existing communications infrastructure and user behaviour, where the user benefits are most compelling, the business case is strongest, and the commercial risks are lowest. This implies a need for low-cost NFC integrated circuits (ICs) that can be applied to a broad range of uses cost-effectively, in a way that is compatible with the broadest range of devices and reader infrastructure.

Innovision sees three key areas of application for NFC: service initiation, where the technology is used to "unlock" another service (such as opening another communication link for data transfer); peer-to-peer, where NFC is used to enable communication between two devices; and payment & ticketing, where NFC will build on the emerging smart ticketing and electronic payment infrastructures.

 

Key NFC applications

The first mass-market applications for NFC will almost certainly be in relatively low-financial value applications - with low risk of fraud - that do not require large investment in new back-end infrastructure. These applications are likely to build on existing payment and communications infrastructure and user behaviour, where the user benefits are most compelling, the business case is strongest, and the commercial risks are lowest.

The key initial applications for NFC technology fall into three categories:

• peer-to-peer, where NFC is used to enable communication between two devices
• payment & ticketing, where NFC will build on the emerging smart ticketing and electronic payment infrastructures
• service initiation, where NFC is used to perform service discovery or to "unlock" another service (such as opening another communication link for data transfer).

In peer-to-peer applications, NFC can be used to set up local communication between two devices. For relatively small amounts of information (up to a few kilobytes), NFC can be used to transmit the data itself, as this can be exchanged during the short period of time the NFC devices are touching each other. However, for larger amounts of data, NFC is more likely to be used to establish a separate wireless connection (such as Bluetooth or WiFi) to carry the content to be exchanged. A typical peer-to-peer application would be printing photos straight from a picture phone or digital camera: the user would simply select the photo or folder to be printed and then touch the device against the NFC-enabled printer to establish a Bluetooth connection to transmit the digital photos.

Credit card merchants, banks and mobile network operators see value in putting payment and ticketing applications on NFC-enabled mobile phones, and this was one of the drivers for the creation of the NFC standard. For the credit card merchants, NFC-enabled payments are much easier and less costly to handle than cash and other traditional payment methods. In addition, users will have a record of even the smallest payments, which they do not with cash today. Initially, NFC-enabled devices are likely to be used for low-fraud, limited-value payment situations, such as quick-serve restaurants, kiosks, vending machines and parking meters.

With service initiation, the user touches an NFC-enabled device against an NFC tag, which then transfers a small amount of information to the NFC device, which may be some lines of text, a web address (URL), phone number or other simple piece of data. Smart posters promoting new products, services or events are examples of this type of application. By touching an NFC-enabled mobile phone against the NFC tag embedded in the poster, the user may be directed to a web site for further information or to book tickets without the need to key anything into the phone to open the browser or input the URL.

NFC mandated tag types

The service initiation use case requires two devices to communicate using NFC, one device is an NFC reader/writer and the other a passive NFC tag.

In June 2006, the NFC Forum introduced standardized technology architecture, initial specifications and tag formats for NFC-compliant devices. These include Data Exchange Format (NDEF), and three initial Record Type Definition (RTD) specifications for smart poster, text and Internet resource reading applications.

Related In-Depth Articles:

» RFID Standards 101

» ISO RFID Standards:    A Complete List

In addition, the NFC Forum announced the initial set of four tag formats that all NFC Forum-compliant devices must support. These are based on ISO 14443 Types A and B (the international standards for contactless smartcards) and FeliCa (conformant with the ISO 18092, passive communication mode, standard). Tags compatible with these mandatory formats are available initially from Innovision, Philips, and Sony, and already more than one billion tags of this kind have been deployed globally, albeit for non-NFC applications like mass transit and access control.

The NFC Forum chose the initial tag formats to cater for the broadest possible range of applications and device capabilities:

• Type 1 is based on ISO 14443 A and is currently available exclusively from Innovision Research & Technology (Topaz). It has a 96-byte memory capacity, which makes it a very cost-efficient tag for a wide range of NFC applications
• Type 2 is also based on ISO 14443 A and is currently exclusively available from Philips (MIFARE UltraLight). It has half the memory capacity of Type 1 tags
• Type 3 is based on FeliCa and is currently exclusively available from Sony. It has a larger memory (currently 2kbyte) and operates at a higher data rate (212kbit/s), which means it is suitable for more complex applications
• Type 4 is fully compatible with ISO 14443A/B and is available from a number of manufacturers, including Philips (typical product example is MIFARE DESFire). It offers large memory-addressing capability with read speeds of between 106kbit/s and 424kbit/s - making it suitable for multiple applications.

It is worth noting that Type 1 and 2 tags and Type 3 and 4 tags are two very different groups, with very different memory capacities. There is very little overlap in the types of applications they are likely to be used for.

The right tag for the job

With four NFC Forum-mandated tag types to choose from, designers need to consider carefully the relative merits of each before committing to one type or another. With initial mass-market deployments likely to be in low-financial value, low-risk applications, it is important that NFC tags meet the requirements with the right balance of cost and performance. There will also be more specialist applications that require greater tag capabilities, and that are less sensitive to cost and size considerations. Table 1 shows some key NFC applications and the suitability of each of the four NFC Forum-mandated tag types, according to the following features and capabilities.

In the smart poster application, the user touches his or her mobile phone against a tag embedded in the poster itself, which triggers the transmission of a URL to the phone. This URL could be used, for example, to direct the user to a web site where he or she can find out further information or download a special coupon or token. The trade-off here is to have a tag that is small and low-cost enough for mass deployment, but with sufficient memory to contain a reasonably long URL and some additional security features.

In the SMS or phone number shortcut use case, the user can automatically send a text message or phone number by touching the phone against a tag that could be embedded in all sorts of objects. One possibility is the provision of "tags in a box" with new mobile phones. The user would be able to save a phone number or text message on the tag, which is embedded in a sticker. Tags could be affixed to photo frames and used to obtain the phone number of the person in the picture, which could be for fun or be a very useful facility for the elderly or disabled. Tags containing SMS text could be stuck just inside the front door at home so that children returning from school could touch their phones and automatically send a text message to their parents. In this case, small size and low cost are the main considerations, as the memory requirements are small.

Bluetooth pairing is essentially a "handshake" between two devices - for example, a mobile phone and a hands-free headset, or a digital camera and a printer. This is a fairly infrequent occurrence, but is made much more convenient by NFC. Generally, only a small amount of memory is required, and small size, low cost - with low risk of "tearing" the data transfer - are also the watchwords here. Larger memory may be useful in applications that also involve the automatic transfer of some data between the two devices.

With MMS or ringtone downloads the user could touch a product or promotional piece, for example, to get an associated picture message or ringtone automatically transferred to his or her phone. Once again, small size is important, but so are sufficient memory and security features. The larger the memory capacity on the tag, the more information that can be transferred directly to the phone. However, one has to consider the limitations arising from the short "touch time" between the NFC device and the tag. In practice, this sets an upper limit for the amount of data exchanged to just a few kilobytes during the touch.

Application	Features	Type 1	Type 2	Type 3	Type 4
Smart poster (URL shortcut)	UID	Yes	Yes		Yes
	Read/write memory capacity	96 bytes + 6-byte OTP + 2 bytes metal ROM	48 bytes	1kbyte	Variable
	Lockable to read only?	Yes	Yes	Yes	Yes
	Turn off after usage limit	Yes, 48 bits OTP + r/w	No, 0 bits available
	Security	Capability for 16- or 32-byte digital signature	Unsecure	Capability for 16- or 32-byte digital security signature	Variable
	Unit price	Lowest	Low	Higher	Higher
	Die size area	*****	****	*	*
	Read speed	*** (read all)	**		***
SMS or phone number shortcut	UID	Yes	Yes		Yes
	Read/write memory capacity	96 bytes + 6-byte OTP + 2 bytes metal ROM	48 bytes	1kbyte	Variable
	Lockable to read only?	Yes	Yes	Yes	Yes
	Turn off after usage limit	Yes, 48 bits OTP + r/w	No, 0 bits available
	Security	Capability for 16- or 32-byte digital signature	Unsecure	Capability for 16- or 32-byte digital security signature	Variable
	Unit price	Lowest	Low	Higher	Higher
	Die size area	*****	****	*	*
	Read speed	*** (read all)	**		***
Bluetooth pairing	UID	Yes	Yes		Yes
	Read/write memory capacity	96 bytes + 6-byte OTP + 2 bytes metal ROM	48 bytes	1kbyte	Variable
	Lockable to read only?	Yes	Yes	Yes	Yes
	Turn off after usage limit	Yes, 48 bits OTP + r/w	No, 0 bits available
	Security	Capability for 16- or 32-byte digital signature	Unsecure	Capability for 16- or 32-byte digital security signature	Variable
	Unit price	Lowest	Low	Higher	Higher
	Die size area	*****	****	*	*
	Read speed	*** (read all)	**		***
MMS or ringtone download	UID	Yes	Yes		Yes
	Read/write memory capacity	96 bytes + 6-byte OTP + 2 bytes metal ROM	48 bytes	1kbyte	Variable
	Lockable to read only?	Yes	Yes	Yes	Yes
	Turn off after usage limit	Yes, 48 bits OTP + r/w	No, 0 bits available
	Security	Capability for 16- or 32-byte digital signature	Unsecure	Capability for 16- or 32-byte digital security signature	Variable
	Unit price	Lowest	Low	Higher	Higher
	Die size area	*****	****	*	*
	Read speed	*** (read all)	**		***

	Less strong
	Usable but limited
	Usable and Key strength

More * = better features

Table 1. Application suitability of the four mandated NFC tag types.

Type 1 and 2 tags are dual state, which means that they can be read/write or read-only (as shown in Figure 1). Type 3 and Type 4 tags are single-state, which means that they can only ever be read-only, rather like officially published CDs or DVDs. This means that in applications such as the ‘tags in a box’ one described above, only Type 1 or 2 tags can be used, as Type 3 and 4 tags cannot be personalized by the user.

Dual State

Read/Write: for example, personalize a tag by a user or a company

Read-Only: for example, the user can write data and then ‘lock’ the tag to be ‘read-only’ thereafter

Figure 1. Dual-state tag types.

The read/write memory capacity offered by the NFC tag is an important consideration, particularly in mass-market applications, as more memory comes at the expense of unit price and footprint. For example, in smart poster applications, greater memory translates into longer URLs and greater security options. The larger memory offered by Type 3 and 4 tags could be useful in certain applications - for example, for high data content downloads such as MMS or ringtones - but is overkill for smart posters, Bluetooth pairing or low-data shortcut applications like SMS text or phone numbers.

However it is important to balance cost with capability in this area, especially when some level of security is required. For example, it will be desirable to protect smart posters from fraudulent copying or tampering to change the URL or phone number provided in public environments. There needs to be sufficient memory to provide a full URL even when a digital signature is required. Type 1 tags offer 96 bytes of read/write memory, while the nearest comparable competitor product (Type 2 tag) offers only 48 bytes. This could be crucial - as illustrated with the sample URL lengths shown in Figure 2 - when one considers that the NDEF overhead occupies six bytes in Type 1 and two bytes in Type 2, the URL NDEF overhead occupies 10 bytes and a digital signature requires either 16 or 32 bytes plus a six-byte header. With a 16-byte digital signature, a Type 1 tag would have 58 bytes (characters) left for the URL itself, while the Type 2 tag would have only 14. With a 32-byte digital signature, Type 1 tags would be left with 42 characters, while Type 2 would be unusable.

Example 1 – 58 characters available for URL using Type 1 tag with 16-byte digital signature:

http://www.innovision-group.com/index.cfm________________

Example 2 – 14 characters available for URL using Type 2 tag with 16-byte digital signature:

http://www.innovision-group.com/index.cfm

Example 3 – 42 characters available for URL using Type 1 tag with 32-byte digital signature:

http://www.innovision-group.com/index.cfm_

Example 4 – 0 characters available for URL using Type 2 tag with 32-byte digital signature:

http://www.innovision-group.com/index.cfm (no unusable bytes)

 

Figure 2. Examples of URL lengths available (highlighted characters) with different tag types and different digital signatures.

After writing data to a tag, it can be locked to read-only mode to prevent it being overwritten or altered in any way. Locking the tag to read-only means no-one can modify the tag once it has been published, and is an irreversible process. This is an important security and privacy feature that only Type 1 and 2 tag formats offer.

The unit price of NFC tags is influenced by a number of factors, including memory capacity, the number of additional features and IC complexity. The price of the tag is naturally a key factor in determining its suitability for certain applications. For example, if the IC is only to be used for Bluetooth pairing in a hands-free headset - which users only need to do on a handful of occasions - features like high read speed and large memory are irrelevant.

The die size area of the NFC tag is influenced by the amount of memory, the complexity of the chip and the efficiency of the IC design. Compact tags are clearly better for applications where unobtrusive positioning is important, and where integration on to other chipsets may be required. In smart poster applications, Type 1 and 2 can provide a much more appropriate balance of cost, size and memory capacity than Type 3 and 4 tags.

The read speed offered by a tag is an important factor. The higher the read speed, the less chance there is of a read/write "tear" occurring, where data is not fully or properly transferred while the tag and reader are in close proximity. Therefore the read speed has a direct impact on system reliability and user experience. In smart poster applications this will be important, as users will appreciate speed and convenience and not wish to keep trying and retrying. The proprietary "Read All" command in Type 1 tags enables the whole content of the tag to be read in one shot, rather than a block at a time - which improves read performance considerably.

Summary

The large-scale success of NFC is dependent on the availability of NFC tags with the right capabilities and the right price point. It is important for designers to consider what the best balance of tag capabilities and cost is for their applications.

It is likely that the first mass-market applications for NFC will build on existing infrastructure, initially in relatively simple shortcut, identification, service discovery/initiation or device pairing applications. This implies the need for a standardized tag format that is small, low-cost and flexible enough to be successfully integrated into existing form factors and integrated circuitry.

Read the final article in the series: Near Field Communication in the Real World, Part 3