Introduction to NFC (Near Field Communication) technology
Introduction to NFC (Near Field Communication) technology
NFC (Near Field Communication) is a wireless communication for devices in very close range, normally in physical contact. One of the two communicating devices may be passive, meaning that it has no energy source (no batteries, no solar cell).
The ancient relative of NFC is the anti-theft tag or security tag found in many stores. The door sensor generates a magnetic field. The tag has no batteries but can absorb field energy. This absorption is sensed and it triggers the alarm.
On top of this principle, there is the RFID technology. A RFID tag not only absorbs energy but also sends some information back. The "canonical" application of RFID is replacement or complement to barcode labels, since RFIDs can be read more easily. It creates a myriad of privacy problems e.g. you buy a T-shirt with your credit card, it has a RFID tag; you just become a person that is very easy to trace.
NFC goes one step further; the passive NFC device may be "intelligent", meaning that it possesses a tiny computer and can do some processing. The NFC potential is enormous and includes things like:
NFC allows communication between two "active" devices, e.g. two cell phones. This feature makes it easy to exchange contact cards, photos etc. The security and convenience are very nice: the interested parties just need to touch their gadgets. This still does not work as well as it should, because the standards are still emerging and there are incompatibilities between dissimilar platforms e.g. Windows Phone and Android.
In NFC jargon, the passive device (that has no source of electricity) is simply named a tag, or sometimes a "card" since it takes the form factor of a credit card in most cases. The active device is called a reader because it typically just reads tags.
The reader and the tag have coils, not antennas. When the reader coil is energized, it generates a magnetic field. When a tag gets very close, the two coils form a transformer, and the tag can draw energy from the reader.
There is an apocryphal story about a ghetto in which people could illuminate their houses by drawing energy from an AM radio station nearby. This was discovered because the signal range was getting shorter and shorter. I don't know if there is any truth in this story, but it illustrates well the difference between near field and far field.
Far field is the electromagnetic radio signal, that propagates for long distances. If I have a radio tuned at home, this won't affect my neighbor's radio. Regardless of how many radios are receiving, the load on transmitter does not change; the parts are uncoupled.
On the other hand, the near field is composed of electric and magnetic fields, that still did not combine into photons. Separately, they don't go far. They can only be detected in the vicinity of the antenna. A near-field receptor in this region can absorb a lot of energy and hurt the electromagnetic range.
The transmitter can "feel" the presence of near-field receivers because they lower antenna's impedance. As coupling between near-field transmission and reception increases, the impedance can go down to 0 ohms. (The "vacuum impedance", that is, the impedance perceived by the antenna when doing only far-field communication, is around 377 ohms.)
The size of the near field is a function of the wavelength. The AM wavelength is around 500 meters, so the mythical ghetto would have to be within 80 meters of the AM station.
NFC puts these effects into good use to limit the reach and feed the passive tag. Since a coil is a bad antenna, little energy is wasted as electromagnetic radiation.
Since the tag has no power source, it communicates with the reader by modulating its own energy consumption. The reader can detect this modulation by monitoring its own antenna's impedance.
When two active NFC devices e.g. two phones are to communicate, there are some complications because both can try to send data at the same time (collision). The protocol must detect and resolve such collisions.
For the user, NFC is perfect. For the developer, NFC can be more complicated than initially expected. This has "historical" roots: the NFC specifications inherited preexisting and incompatible flavors of NFC (from Philips, from Sony, and so on). The result is a stack with many redundannt features, and an annoying multiplicity of tag types.
There are many tag "types": Type A, Type B, Type F... as shown in Figure 1. On top of these types, we have the "technology types": Type 1, 2 e and 4. For example, "Type 1" adopts a subset of the features implemented by "Type A".
Each type has a set of capabilities and limitations, e.g. tag chip memory size, maximum size of exchanged messages and so on. By the way, the NFC Forum allows free access to all specs, you just need to identify yourself before downloading.
Commercial standards like MiFARE implement additional features, like tag-embeddded cryptography, on top of a basic type.
The good news is that NFC-capable phones like Android and Windows Phone can handle every tag type mentioned in Figure 1.
The NFC protocol stack makes the TCP/IP stack look dead simple in direct comparison. See Figure 2.
Each tag type offers a different link protocol, and each technology type extends the command list of the base protocol. For example, NFC-A offers a command set, and Type 2 extends that set (kind of an heresy for people that believe in layered protocol stacks).
Because of that, there are many link protocols (the square hooks in Figure 2), and the transport/application protocols can hook to any link protocol. Because of that, I could not put all protocols in a layered picture, like textbooks do.
Instead, I used "hooks" of different shapes to indicate who can connect with whom. For example, the NDEF transport protocol can employ any "open square" as link protocol, while the PHDC application rptocol can use either NDEF ("arrow") or LLCP ("circle") as transport.
Fortunately for us developers, NDEF (NFC Data Exchange Format) is the most often used standard. NDEF specifies the message format stored in tag, as well as the access protocol that reads from and writes to the tag.
When the developer deals with NDEF, it is freed from dealing with the multiplicity of links and types, since normally the NDEF API hides the low-level details.
Since Android is the platform that stressed NFC support since the beginning, we will look how the Android API supports the many elements of the NFC protocol stack. I tried to reuse the "hooks" in Figure 3:
NDEF support is excellent, including tag writing support for any tag type.
Thanks to the "Intents" mechanism, an application can be configured to deal with NDEF messages of some given type. When such a tag is brought in contact, the app is loaded automatically. Android also offers a complete API for MiFARE standard.
The API offers the other extreme as well: raw access to link layers. This is a way to handle proprietary protocols, not based on NDEF. But the difficulty level is high since the developer will have to craft every packet from the link layer up, with all bits in their due places... and link layer packets do have different formats for each technology type.
Android also supports the ISO-DEP protocol, a link layer of a slightly higher level that abstracts Types 4A and 4B. The PICC prtocol (from FeLiCa stack) can be supported through manual implementation, using the raw API for NFC-F.
There is no access to NFC-DEP protocol, which abstract Types 2 and 3. Likewise, there is no support do LLCP — a transport protocol that borrows concepts from Ethernet (802.3 standard) including the MAC address concept.
LLCP offers connectionless and connection-oriented services, analogous to UDP and TCP. Its interface looks much more familiar to developers that have already worked with BSD Sockets, TCP/IP and Bluetooth. LLCP aims peer communication between active NFC devices e.g. two cell phones. (Communication with passive tags tends to be very short: read one NDEF message and disconnect.)
Android does not grant access to LLCP level via API, but it does use it internally. SNEP (Simple NDEF Exchange Protocol) is the vehicle of "Android Beam" feature and uses LLCP as transport. Curiously, the payload of a SNEP communication is simply an NDEF message. Unfortunately, is not possible to establish a two-way, continuous communication channel using the SNEP API.
Since part of my current work is related to medical devices, I have added the PHDC protocol to Figure 2. PHDC has the same role as USB's PHDC class and HDP profile in Bluetooth: to carry medical data that follows the IEEE 11073-20601 standard. PHDC can employ LLCP and NDEF as transports. Since NDEF message exchanges do not establish a connection by themselves, PHDC prescribes a "telegraphy" of messages to be sent back an forth, several per second.
Normally, a medical device will have batteries and/or will be connected to mains, but NDEF transport leaves the gate open for 100% passive devices e.g. a thermometer that only functions when activated by an NFC reader.
Finally, there are some proprietary protocols, conceived directly on top of NFC link protocols. I mourn the fellow programmers that have to deal with them.
Since NDEF has a central role in NFC, it deserves a closer look. A good text about NDEF can be found here but I will mention some highlights.
A NDEF message is formed by one ore more NDEF records. Each record is a structure with many fields:
The existence of all these fields in each record solves a number of problems. A message can be sent in fragments (using MB and ME bits to fence the message boundaries). Messages of different types can be sent through the same channel and be easily separated at receiver side. Different messages can be sent at the same time, using interleaved records, as long as each message have a unique ID.
The meta-type URI leaves the barn door open for domain-specific and application-specific types. For example, I can define a type like "urn:nfc:ext:epxx.co:boo", that is employed by my own applications. Naturally, each type imposes a inner structure on the message payload.
The NDEF protocol has two basic operations: read and write messages. They are built on technology-layer operations. The normative document of each tag type (Type 1, 2, 3 and 4) specifies how an NDEF shall be read from, written to and stored in the tag.
The NDEF operations were conceived to read and, sometimes, write passive tags. The reader device must always take the initiative. If a two-way persistent connection is to be implemented on NDEF primitives, the reader will likely poll the tag often, until it gets some substantial payload. That's exactly the strategy of PHDC application protocol.
There are many projects and libraries around. One that looks the best for playing around and learning about NFC is NFCPy. It is developed in Python, does not depend on kernel-level drivers (it drives the NFC readers at user level) and works on all major operating systems.