For sensitive applications such as secure payment exchanges, AES and triple DES encryption can be added at higher layer using the same techniques employed by standard smart card technologies. NFC's negotiation phase establishes parameters which define the upcoming transaction such as link speed, device ID, application, transfer size, and action requested.
NFC can be used to configure and initiate other wireless network connections such as Bluetooth, Wi-Fi or Ultra-wideband. An example of the efficiency of NFC's handshaking protocol, is a comparison with Bluetooth. Whereas a normal "pairing" operation between Bluetooth devices usually takes five or six seconds (and up to 30 seconds in congested environments), NFC's streamlined single-link protocol completes the same task in 100-200 ms.
Next step: Phone integration
The GSM Association started its Mobile NFC project early in 2006. The next significant milestone for design engineers is a Mobile NFC technical guidelines document, which is due in the second quarter of 2007. Formal standards-making activities will begin in earnest after the guidelines document is published but liaisons with the major standards groups has already begun.
Clearly, a great deal of work is required on many fronts to produce a Mobile NFC phone that operates virtually anywhere in the world. Figure 2 shows the basic players and interfaces for the phone or other mobile device.
Click here for Figure 2
Figure 2: Typical conceptual view of a NFC mobile device and its interfaces.
Focusing first on the mobile device itself, the major hardware components are: The antenna (a loop antenna built into the mobile device's case); the NFC chip; and, a so-called "secure element," which is expected to be a separate smart card-like chip in early production modelsbut its functionality will eventually migrate into the mobile phone's SIM card.
Software on the device will consist of a number (perhaps an very large number) of applications that will require between 50 and 200 kbytes. For example, credit card companies typically require different types of encryption and all will be supported by a different application. Applications will most likely be downloaded by the phone's owner and not pre-loaded on the phone when it is purchased.
The number of applications ramps steeply as individual retailers also provide applications that promote and support loyalty programs such as coupons and vouchers, or, provide access to their services such as purchasing a ticket to a theater performance or sporting event. In other words, the consumer will shop for the ticket(s) remotely over the air using an application supported by a company like TicketMaster, pay for them using a credit or debit card application, and, then download the electronic ticket to the phone. To gain access to the event, the consumer will use the phone's NFC (tap-and-go) functionality.
The primary challenge for Mobile NFC is to create a robust ecosystem consisting of MSOs, mobile device designers and manufacturers, financial institutions, retailers and similar entities, and one or more (probably more) service managers that will manage and provide a secure over-the-air link.
The GSM Association has proposed this role for a Trusted Service Manager (TSM). The
TSM's role would be to:Provide a point of contact for the service providers to access customers through the MNOs.
Manage the secure download and life-cycle management of the mobile NFC application for the service provider.
The TSM would not participate in the transaction stage of the service because that would likely disrupt the service provider's existing business model. TSM's could be one of several types of entities: it might be managed by one MNO, a consortium of MNOs, or by independent trusted third parties. The first independent TTP to appear is Venyon Oy, a Helsinki-based joint venture of Nokia and Munich based Giesecke & Devrient GmbH.
In addition to sorting out the secure OTA challenge, Mobile NFC will have to deal with some more mundane problems as well.
For example, existing contactless infrastructure implementations are based on different ISO standards (e.g. ISO/IEC 14443) and a few proprietary solutions. In the vast majority of cases service providers will not be willing or able to change or upgrade their existing contactless infrastructure.
This is a problem because existing systems are almost always mono-applications. For example, contactless access to public transportation in London is known as Oyster but it has a different protocol than NaviGo in Paris. A mechanism must be found to choose the right NFC application within the context of the appropriate NFC system.
These challenges are not, however, particularly daunting because the various stakeholders have so much to gain by working together to solve them. From a design engineer's perspective, Mobile NFC is likely to open a whole new market for devices that interact with the mobile phone. There is also a strong possiblity that devices other than mobile phones can be Mobile-NFC enabled. Finally, the very large number of applications that will run on the phone will provide plenty of opportunity for software engineeers.
Stay tuned to WirelessNetDesignline for further developments on this high-potential technology.
About the author
Jack Shandle is the site editor of WirelessNetDesignline. He holds BS in Electrical Engineering from the University of Pennsylvania and a MS in Communications from Temple University. Presently a freelance writer and editor, he formerly held high-level editorial management positions in several electronics publications. He can be reached at firstname.lastname@example.org.