Near Field Communication (NFC) in mobile devices has been on the agenda for many years now but progress has been very slow. Lately however, there are devices with NFC chips built in comming to the market so I decided it was worth to dig a bit deeper how that works. Getting a single NFC standard accross the industry isn't quite straight forward but some progress has been made in this regard with companies such as Google, Nokia and RIM backing the NFC-Forum based standard for local information exchange and a basis for mobile payment services.
Payment and non-payment (such as receiving a URL from a poster) NFC services rely on the same NFC protocol stack and only differ in how this stack is then made use of by applications on top. I've therefore decided to split up the topic into two posts, with the first describing the basic operation of the NFC protocol stack and how that works with non-payment apps and then in a second post which then describes how NFC can be used for payment purposes.
On the physical layer, NFC uses a carrier frequency of 13.56 MHz to transmit data between two NFC devices via inductive coupling as specified in ISO/IEC 14443. Two transmission modes are specified. The passive mode is used in combination with NFC RFID (Radio Frequency ID) tags that do not have their own power source. In this mode, the originator’s RF field is used as an energy source by the passive RFID tag to return a message. The message is usually short in nature and can for example be an address of a web page (URL) or a business card entry in vCard format.
It is also possible for two active NFC devices to communicate with each other such as two mobile devices or a mobile device and a point of sales (POS) terminal. In active mode, both devices are equal and transmit and send alternatively using their own power source. The practical working distance between two NFC devices is 4 centimeters but much longer ranges can be achieved with high gain antennas. As a consequence, sensitive data exchanges must be encrypted and applications using the communication channel for such information need to authenticate each others to prevent over the air attacks such as eavesdropping, information theft and man-in-the-middle attacks. Supported data rates over the NFC air interface are 106 kbit/s, 202 kbit/s and 424 kbit/s.
The next higher level of the NFC protocol stack defines different message formats. A popular format is the NFC Data Exchange Format (NDEF) defined by the NFC forum. The format defines a general message structure and allows devices to identify what kind of information is contained in the message it has received. The following list gives some examples of message types that can be encoded in an NDEF message:
• URI (web address, email address)
• Plain text
• Smart poster = text + uri
• Bluetooth and Wi-Fi parameters
• Business card (vCard format)
• Signature
Once an NDEF message has been received, a content dispatching system forwards the content of the message to an application that has registered itself for a certain content type. This way, different applications can register themselves for different message types and the dispatching system automatically forwards the message to the application that can handle the particular message type. When several applications register themselves for the same message type a dialogue box is usually presented to the user to choose which application should receive the message. When a web address has been received for example, it could be sent to the web browser while an NDEF message containing a vCard would trigger the address book application that has previously registered itself as a receiver for this kind of content.
Applications on a mobile device can not only receive NFC messages but also transmit them. The address book application for example can be extended to send NFC messages, e.g. an address book entry to the next NFC enabled device that comes in range.
Third party applications can also register themselves as recipients of NDEF messages with a certain content type and can also trigger the transmission of messages themselves. Take Foursquare as an example. The aim of this application is to let users ‘check-in’ at certain locations and share their current location with their friends by various means. The traditional ‘check-in’ procedure uses the GPS receiver in a mobile device to pinpoint the user’s location. The location of the user is then sent to a database in the network to retrieve all places near this location that are registered with Foursquare. The user can then select the place he is visiting. With NFC tags, this process is significantly simplified as the ‘check-in’ is now performed by the user holding his device close to a Foursquare RFID tag. The type of content of the tag is then forwarded to the Foursquare application on the device which then registers the user in the network at the current location. NFC functionality can also be used to exchange information between two Foursquare apps on devices of different users to make friend requests and exchange location lists. This is done by launching the Foursquare applications on both devices and then holding the two devices close together.
So much for now. In part 2, I'll dive a bit into the additions required to use NFC for mobile payment purposes. To come soon…
great summary. waiting for part II 😉