Related to this, see Mobility 2011: The Year of NFC.

To get an idea of what is possible with NFC see eZee inc. Mobile Coupon and Payment Vision, a video of what I was doing back in 2007 with NFC.

Overview

“RFID” is a broad term that refers to Radio frequency ID. But not all RFIDs are created equal with differences in range and frequencies, and some are in fact proprietary. But there are number of main standards out there, for example FeliCa (made by Sony and very popular in Japan) and MIFARE (made by NXP and very popular in transportation and elsewhere) with tons of deployments. The Oyster card is based on MIFARE for example.

In addition to the new NFC standard (that defines the NFC scheme, frame formats, frequency and so on), the NFC forum define support for 4 tag-types that represent *existing* RFID technologies and that maps to Topaz, MIFARE UltraLight, FeliCa, MIFARE DESFire types of tags. For more information see sections below.

When referring to phones working with RFID, we must talk about specific RFID technologies, and in the case of NFC, today is about NFC implementations that implement specific tags, and in the future maybe we get to speak about a single near-field technology which is NFC.

The idea of NFC is to simplify the soup (or sea) of RFID technologies into a single one, NFC as defined by the NFC Forum. Support for existing RFID technologies is meant as a migration path until standardization occurs which will take a long time. In the meantime, applications must query/discover NFC vs. RFID/other and process accordingly, but the beauty is that APIs such as the Java Contact-less communication API hides some of the complexity.

Near-Field Communication — Touch is the next Click!

There are a number of very short-range (near field) communication standard solutions such as the MIFARE and FeliCa platforms. Both are very similar in range, frequency and operation. Near Field Communication (NFC) is the latest attempt to create a single standard for near-field communication. NFC (see NFC at Wikipedia) will be as pervasive as Bluetooth is today — but we are three to five years away.

The use-cases and benefits of near-field communication (that goes beyond payments) have been proven in regions such as Japan; short near-field communication is about fast and convenient interactions by consumer. NFC will enable for a new breed of “Touch”-based applications, effectively adding a new dimension to mobility and click-through. NFC-based Touch for payments, using your mobile handset. Touch for learning about your surroundings. Touch for exchanging information. Touch for associating (connecting) the physical and the digital worlds. See Near Field Communication, CES 2007, Mobile Payments and other possibilities.

But the deployment of NFC within handsets have been a very slow process. This is happening due to multiple reasons, including: 1) complex ecosystem (many players), 2) business model focused on payment mainly, 3) MNOs are not ordering the handsets and are stuck doing trials after trials. This also makes the business models hard: the MNO, the banks, the stores, the 3rd party vendors. Everyone wants it, and the big players don’t want to share. Because of this, MNOs are not ordering the handsets fast enough,

See article An Introduction to Near-Field Communication and the Contactless Communication API.

Explore the future…

Developing NFC-based Applications | Android

The Android NFC API was introduced with API Level 9 (Android 2.3). The NFC API itself is defined in the android.nfc package.

The API follows the NFC Forum concepts such as NDEF Messages, Records and Tags. The API defines an NfcAdapter class that represent the actual NFC adapter and related state and an NfcManager which is a factory class. The table below shows the Android NFC classes:

(Source Android Developer Site)

NdefMessage Represents an NDEF (NFC Data Exchange Format) data message that contains one or more NdefRecords. 
NdefRecord Represents a logical (unchunked) NDEF (NFC Data Exchange Format) record. 
NfcAdapter Represents the local NFC adapter. 
NfcManager High level manager used to obtain an instance of an NfcAdapter. 
Tag Represents an NFC tag that has been discovered. 

The API uses Intents to wake the appropriate NFC-based applications when a NDEF payload or a Tag, or a Tag by supported technology have been discovered.

Because the NFC API is only supported on API Level 9 and above, you must ensure to limit your app to such devices by defining a minSdkVersion on your manifest: uses-sdk android:minSdkVersion="9" />

I will be writing some tutorials on Android NFC, but in the meantime, you can see the NFC Demo by Google.

Related to this see Google I/O 2011: How to NFC (Nick Pelly, Jeff Hamilton).

Developing NFC-based Applications | J2ME

Note: For now until I update, feel free to read the following sections knowing that it was written some years ago and might need update.

Developing NFC-based applications for Java handsets is based on the Mobile Information Device Profile together with Contactless API (JSR 257) for contacless I/O, and SATSA (JSR 177) for secure element capabilities. You can read more about SATSA at my Mobile Security page.

The following diagram shows on An Exploration of the NFC-related Elements on Mobile Handsets (click to enlarge):

Elements of NFC Apps

The above illustrates the elements of a Java-based handset that supports NFC. On the top of the illustration is the Java runtime and APIs for accessing SIM cards and Contact-less communication channels, as well as the Java MIDlet application. Note that the application consists of two parts, the MIDlet and a Java Card application that may reside on a SIM card or a smart-card, and perhaps uses memory for the keystore. Below we see the NFC controller, Baseband processor and RF Unit and there is the antenna. Externally to the handset are readers, tags and smart-cards with which the handset communicates with.

To develop applications you can use a set of resources for NFC development by Nokia in support for their 6131 NFC handset:

GSM Association Reference and Device Functional Architectures

The following diagram depicts the GSMA Mobile NFC device functional architecture:


(source: GSM Association)

The following diagram depicts the GSMA Mobile NFC reference architecture:


(source: GSM Association)

Key Findings by the GSM Association

  • Mobile NFC will be successful, provided that the mobile NFC ecosystem is steady and provides value for all participants, in which the new role of the Trusted Service Manager is central.
  • Mobile Operators promote and recommend the UICC (Universal Integrated Circuit Card) as the most appropriate NFC ‘secure element’ in mobile phones, offering many unique advantages for mobile users, including: universal deployment, portability, remote management, standards based solution and a long operational lifecycle.
  • Inter-operability, backwards compatibility and hence standardisation are essential to provide convenient and cost-effective mobile NFC services.

GSM Association NFC Resources

NFC Forum issues specifications for four tag types

The NFC Forum has mandated that the four tag types be operable with NFC devices.

The tag specifications are the most recent in a series of specifications being developed by the NFC Forum. The NFC Data Exchange Format (NDEF) specification and four Record Type Description (RTD) specifications were released in 2006. These specifications are also available for download at www.nfc-forum.org/specs.

The operation specifications for the NFC Forum tag types, numbered 1-4, provide the technical information required to implement the reader/writer and associated control functionality of the NFC device, enabling interaction with the tags. The four tag type specifications are:

  • NFC Forum Type 1 Tag Operation Specification – Type 1 tag is based on ISO14443A. Tags are read and re-write capable; users can configure the tag to become read-only. Memory availability is 96 bytes and expandable to 2 kbyte; communication speed is 106 kbit/s.
  • NFC Forum Type 2 Tag Operation Specification – Type 2 tag is based on ISO14443A. Tags are read and re-write capable; users can configure the tag to become read-only. Memory availability is 48 bytes and expandable to 2 kbyte; communication speed is 106 kbit/s.
  • NFC Forum Type 3 Tag Operation Specification – Type 3 tag is based on the Japanese Industrial Standard (JIS) X 6319-4, also known as FeliCa. Tags are pre-configured at manufacture to be either read and re-writable, or read-only. Memory availability is variable, theoretical memory limit is 1MByte per service; communication speed is 212 kbit/s or 424 kbit/s.
  • NFC Forum Type 4 Tag Operation Specification – Type 4 tag is fully compatible with ISO14443A and B standards. Tags are pre-configured at manufacture to be either read and re-writable, or read-only. Memory availability is variable, up to 32 KBytes per service; communication speed is up to 424 kbit/s.

The Touch Project

Other Resources

ceo