Imagine you’re sitting on your porch at night. You turn on the porch light, and you can see your neighbor as he passes close to your house because the light reflects off him back to your eyes. That’s passive RFID. The radio signal from a passive RFID reader reaches a tag, the tag absorbs the energy and “reflects” back its identity.

Now imagine you turn on your porch light, and your neighbor in his home sees it and flicks on his porch light so that you can see him waving hello from his porch. That’s active RFID. It can carry a longer range, because the receiver has its own power source, and can therefore generate its own radio signal rather than relying on the energy it absorbs from the sender.

RFID is a lot like those two porches. You and your neighbor know each other’s faces, but you don’t really learn a lot about each other that way. You don’t exchange any meaningful messages. RFID is not a communications technology; rather, it’s designed for identification. RFID tags can hold a small amount of data, and you can read and write to them from RFID readers, but the amount of data we’re talking about is trivial, a thousand bytes or less.

Now imagine another neighbor passes close, and when you see her, you invite her on to the porch for a chat. She accepts your invitation, and you sit together, exchange pleasantries about your lives, and develop more of a relationship. You talk with each other and you listen to each other for a few minutes. That’s NFC.

NFC is designed to build on RFID by enabling more complex exchanges between participants. You can still read passive RFID tags with an NFC reader, and you can write to their limited amount of memory. NFC also allows you to write data to certain types of RFID tags using a standard format, independent of tag type. You can also communicate with other NFC devices in a two-way, or duplex, exchange. NFC devices can exchange information about each other’s capabilities, swap records, and initiate longer term communications through other means.

For example, you might tap your NFC-enabled phone to an NFC-enabled stereo so that they can identify each other, learn that they both have WiFi capability, and exchange credentials for communication over WiFi. After that, the phone will start to stream audio over WiFi to the stereo. Why doesn’t the phone stream its audio over the NFC connection? Two reasons: first, the NFC connection is intentionally short range, generally 10cm or less. That allows it to be low-power, and to avoid interference with other radios built into devices using it. Second, it’s relatively low-speed compared to WiFi, Bluetooth, and other communications protocols. NFC is not designed to manage extended high-speed communications. It’s for short messages, exchanging credentials, and initiating relationships. Think back to the front porch for a moment. NFC is the exchange you have to open the conversation. If you want to talk at length, you invite your neighbor inside for tea. That’s WiFi, Bluetooth, and other extended communications protocols.

What’s exciting about NFC is that it allows for some sophisticated introductions and short instructions without the hassle of exchanging passwords, pairing, and all the other more complicated steps that come with those other protocols. That means that when you and your friend want to exchange address information from your phone to his, you can just tap your phones together. When you want to pay with your Google Wallet, you can just tap as you would an RFID-enabled credit card.

When you’re using NFC, your device doesn’t give the other device to which it’s speaking access to its whole memory—it just gives it the basics needed for exchange. You control what it can send and what it can’t, and to whom.

An RFID exchange involves two actors: a target and an initiator. The initiator, a tag reader or reader/writer device, starts the exchange by generating a radio field and listening for responses from any target in the field. The target, a tag, responds when it picks up a transmission from an initiator. It will respond with a unique identifier number (UID). RFID has two communication modes: active and passive. Passive RFID exchanges involve a reader/writer and a tag that has no power source on board. The tags get their power from the energy of the radio field itself. It’s generally a very small amount, just enough to send a signal back to the reader. Active RFID exchanges involve a target that’s an independently powered device. Because the target is powered, its reply to the reader can travel a much greater distance. E-ZPass and other traffic ID systems use active RFID.

RFID tags have a small amount of memory on board, usually less than 1 kilobyte. An initiator device can read this data, and if it’s a reader/writer device, it can write to the tag as well. This allows you to store small amounts of information associated with the card. For example, it’s sometimes used in transit systems that use RFID, to keep track of how much value is left on the card. However, since RFID systems generally are networked to a database, it’s more common to store a data record indexed by the tag’s UID in a remote database, and store all information about the tag in that remote database.

NFC can be thought of as an extension of RFID. NFC exchanges also involve an initiator and a target like RFID. However, it can do more than just exchange UIDs and read or write data to the target. The most interesting difference between RFID and NFC is that NFC targets are often programmable devices, like mobile phones. This means that rather than just delivering static data from memory, an NFC target could actually generate unique content for each exchange and deliver it back to the initiator. For example, if you’re using NFC to exchange address data between two phones, the NFC target device could be programmed to only provide limited information if it’s never seen this particular initiator before.

NFC devices have two communications modes. If the initiator always supplies the RF energy and the target gets powered by the initiator’s field, they’re said to be engaging in passive communication mode. If both target and initiator have their own energy sources, they’re in active communication mode. These modes are the same as regular RFID communication modes.

NFC devices have three operating modes. They can be reader/writers that read data from a target and write to it. They can be card emulators, acting like RFID tags when they’re in the field of another NFC or RFID device. Or they can operate in peer-to-peer mode, in which they exchange data in both directions.

In order to understand NFC in depth, it helps to have a mental model of the architecture. There are several layers to consider. The lowest layer is the physical, namely your CPU and the radios that are doing the communication. In the middle, there are data packetization and transport layers, then data format layers, and finally, your application code. Figure 2-1 shows the various layers of the NFC stack.

Figure 2-1. The NFC protocol stack

At the physical layer, NFC works on an RFID radio specification, ISO-14443-2, that describes low-power radios operating at 13.56MHz. Next comes a layer that describes the framing of data bytes sent over the radio, ISO-14443-3. Any of the radios you might use are separate hardware components, either inside your phone or tablet, or attachments to your microcontroller or personal computer. They communicate with the main processor of your device using one or more standard inter-device serial protocols: universal asynchronous receive-transmit (UART), serial peripheral interface (SPI), inter-integrated circuit communication (I2C), or universal serial bus (USB). If you’re a hardware enthusiast, you probably know the first three, but if your focus is software, you may only know USB.

Above that are several RFID command protocols, based on two specifications. The original RFID control specification that NFC tag reading and writing is built on is ISO-14443A. The Philips/NXP Semiconductors Mifare Classic and Mifare Ultralight and NXP DESFire protocols are compatible with ISO-14443A. The NFC peer-to-peer exchange is built on the ISO-18092 control protocol. Sony FeliCa RFID cards and tags, mostly available in Japan, are based on this standard as well. You can read from and write to tags using these standards and still not be using NFC, however.

The first major difference between NFC and RFID is the peer-to-peer communications mode, which is implemented using the ISO-18092 standard. There are two protocols, a logical link control protocol (LLCP) and a simple NDEF exchange protocol (SNEP) that manage peer-to-peer exchanges. These are shown in the stack alongside the control protocols, since they operate on the same standard as one of them.

The second major difference between RFID and NFC, the NFC Data Exchange Format (NDEF), sits atop these control protocols. NDEF defines a data exchange in messages, which are composed of NDEF records. There are several different record types, which you’ll learn more about in Chapter 4. NDEF makes it possible for your application code to deal with data from NFC tag reading and writing, peer-to-peer exchanges, and card emulation all the same way.

Most of this book focuses on the use of NDEF messaging. Although we’ll discuss the lower layers so that you understand them, we think that the advantage to NDEF is that it frees you from thinking about them.

Not all NFC-compatible tags work with all NFC devices. In the course of working on this book, we’ve tested many different devices and tags, and have found some combinations work, and some don’t. Though Table 2-1 isn’t an exhaustive table, it’s intended to give you enough information to choose your devices and tags appropriately.

The most common issue you’ll run into is that some devices will read Mifare Classic tags, while others won’t. Mifare Classic is not actually an NFC Forum standard tag type, and recently, major hardware vendors like Broadcom and Samsung have started to drop support for it on their devices. You’re likely to get unpredictable results when you try to read Mifare Classic tags with some of these newer tags. For example, the Nexus 4 will read Mifare Classic as a generic tag, but the Samsung S4 (Google Edition) displays an error saying it can’t handle the tag. When possible, we recommend going with one of the official NFC Forum tag types. In the chapters ahead, we’ll make more specific recommendations where appropriate.

If you’re coming to NFC because you’re interested in using it for embedded hardware projects on the Arduino, Raspberry Pi, or BeagleBone Black (which you’ll learn more about in Chapter 7 and Chapter 9), you should make sure you have both NFC tags and Mifare Classic tags. The libraries for those platforms were developed starting with Mifare Classic support, and as of this writing, they don’t handle all the NFC Forum types. We’ve added Mifare Ultralight (NFC type 2) read support for the Arduino NDEF library (which Don wrote), and there is partial Ultralight and DESFire support (NFC types 2 and 4) in libfreefare, one of the libraries we’ll show you in Chapter 9.

While we hope to see additions to those libraries to support all of the NFC Forum tag types, it’s not there yet. Growing pains like these are common with emerging technologies, but so far, signs point to the industry moving toward a standardized set of tag types.

There are many possible applications for NFC. Its tag emulation functionality is showing up in monetary transactions like Google Wallet, and in payment and ticketing systems for public transport. There are several mobile phone apps that allow you to save configuration data for your phone to a tag, and use the tag to automatically change the context of your phone (e.g., set the quiet settings for meetings, turn on WiFi and configure for a given network by tapping a tag). Home audio equipment is coming on the market that allows you to automatically pair your phone or tablet with your audio player or TV, to use the former as a remote control for the latter. Healthcare systems have implemented patient ID and record linking using NFC, and the NFC Forum recently released a Personal Health Device Communication (PHDC) technical specification to aid in that development. Inventory management can be improved by using NDEF records written to the goods being shipped, about their journey, shipping times, and so forth. Fleet tracking can also be enhanced using NFC tags and readers by storing route information, travel times, mileage, maintenance, and fuel information on tags, or transferring it from vehicle to mobile device through peer-to-peer.

In the course of working on this book, we’ve seen NFC-compatible tags in many locations, from New York City’s Citi Bike key fobs to metro passes in China and Norway to hotel room keys, and more. Although not all of these applications are using the tags to the full potential NFC affords, they all could be enhanced or simplified through some of its features.

The combination of peer-to-peer messaging between devices with minimal negotiation, and a common data format between device and tag messages makes NFC a potentially powerful tool for data-intensive applications in the physical world.

Near field communication adds some promising new functionality to RFID technologies. Most notable of these is the NFC Data Exchange Format, NDEF, which provides a common data format across the four different NFC tag technologies. NDEF can be used for both tag-to-device data exchange and for device-to-device data exchange. This distinguishes NFC as more than just an identification technology; it is also a useful technology for short data exchanges. The method by which NFC devices and tags interact—by means of a single tap—affords a spontaneity of interaction between users.

There are four physical NFC tag types. These are based on existing RFID standards; three of the tag types are based on the ISO-14443A standard, and the fourth is based on the ISO-18092 standard. This makes NFC tags at least partially compatible with many existing Mifare and FeliCa RFID systems. Although these older systems do not support NDEF, they can still identify those NFC Tags that are compatible with them. An RFID reader that can read Mifare Ultralight tags, for example, would still be able to read the UID of an NFC type 2 tag, even though it couldn’t read any NDEF data encoded on the tag.

In its current state, there are some incompatibilities between some NFC devices and older Mifare Classic tags. Some NFC radios support Mifare Classic as an unofficial fifth tag type, while others don’t. As NFC matures and more devices come on the market, these incompatibilities will hopefully come to affect users less. For now, however, it’s best to check the compatibility between the readers and tags you plan to use in a given application.