NFC is on everyone’s lips. Terminal and card vendors, network operators, financial institutions, and many others have been discussing the benefits and limits of contactless communication for quite some time. The number of people who have to contribute something to the topic of NFC seems to be growing almost every day. Experience has shown that new lucrative technologies attract many new players. Consequently, rules are indispensable.

The GSMA TS.27 NFC Handset Test Book is a collection of test cases that verify mobile devices supporting UICC-based NFC services. The underlying device requirements are defined in the document GSMA TS.26 NFC Handset Requirement. Both documents are developed within GSMA as a joint effort between network mobile operators, mobile device and chipset vendors, and the test industry. The history behind the creation of these documents and a detailed view into the current release state is given in the following article written by Katrin Jordan (Deutsche Telekom AG).

The test cases contained in the test book are either defined directly in the test book or mentioned by references to test specifications defined by ETSI, 3GPP or SIMalliance.

 

TS.27 NFC Handset Test Book Structure

The structure of the test book is focused around the mobile device with references to the main components of an NFC-enabled device. Testing is defined as testing the device and its key components
with supporting equipment from NFC tag, card readers and the mobile network.

The test cases themselves arise from the requirements of the different NFC services. Both, the individual services and the requirements are described in the following chapters.

 

 

Figure 1: The structure of the test book follows the general NFC device architecture

 

NFC Services

Around the world, there is a great number of different NFC services launched or on trial which cover many different types of use cases. NFC services can be categorized from many different angles. We will make a simple categorization which relates to the use cases and related requirements defined in TS.26. We will look at the following two types of NFC services:
1. Secured services using a secure element (SE) on the UICC
2. Non-secured services

A typical use case for secured services is a payment service where a credit card or debit card is replaced by a mobile device simulating the card. This is called card emulation mode. When the device offers the card emulation mode, users are able to make payment using their mobile devices via Near-Field Communication at an NFC-enabled payment terminal in a shop or restaurant. The user
normally enters the PIN on the mobile device user interface. However, many payment providers offer
payment of limited amounts without PIN query.

A non-secured NFC use case can be a ticketing service in public transportation where a purchased ticket is downloaded to the device instead of the physical ticket. Especially in mass transportation, it can be crucial for the flow of people that the NFC transaction time fulfils minimum requirements. Just imagine what happens to the queue if the reaction time is 2 seconds instead of 0.5 seconds.

Another typical use case would be reading and writing NFC tags, for example for “Touch & Order”, where the user reads an NFC tag to start a purchase process via internet or simply reads
a business card to be stored in the phonebook. This mode is called reader/writer mode where
the device acts like an NFC tag reader.

 

NFC Handset Requirements

A big amount of device (that means handset) requirements that shall enable a failure-free NFC operation (interoperability between device and NFC Tag/reader) are described in the TS.26 NFC
Handset Requirements document. Examples of requirements are:
 

• Tag Reading and Writing
  Tag reading and writing requires the device to support and handle the available NFC tag formats and to work at a defined distance between device and tag of 0-4 cm. Currently 0-1 cm is mandatory and 1-4 cm is optional.
  
  The device is required to support NFC Forum Tag Types 1, 2, 3 and 4 which provide different functions and memory sizes. All of the tag types have their own NDEF (NFC Data Exchange Format) and can be personalized with different contents and formats, for example vCard, SMS or URL. The test book includes various test scenarios to ensure that the device is able to read and write the different tag types and contents.
   
• Card Emulation Mode
  A device that supports card emulation mode is required to activate the card emulation mode as soon as NFC is activated so that the user is able to make payments or buy tickets. In order to ensure positive user experience, the card emulation mode must work even when the battery is low. Additionally, it is required that card emulation mode works at a defined distance between device and terminal of 0-2 cm.
   
• Low Battery
  It is important for the user that the NFC functionality related to payment or ticketing services works independently of the device battery level. If the user’s device is turned off due to low battery, an NFC transaction must still be possible. In such a case, it is important that the device works correctly when the NFC controller is powered by the electromagnetic field from the card reader. The test book includes several test scenarios with battery low or battery off.
   
• Switching Operation Modes
  The two different modes, card emulation mode and reader/writer mode, have to co-exist. They must be available “simultaneously” for the user either to make a payment or read a tag. Therefore, it is important that the device switches correctly between the two modes in order to provide the user with both functionalities. The third common mode – peer-to-peer  communication – is currently not covered by the test book.
   
• Open Mobile API (OMAPI)
  The OMAPI is specified by SIMalliance and enables the device applications (e.g. wallet) to have access to the secure element on the UICC.
  The OMAPI is an Application Programming Interface which provides application developers with a set of standardized functions to get access to a secure element applet on the UICC. This API is a transport mechanism between the user application and the secure element applet which allows the user application to exchange messages (APDUs: Application Protocol Data Units) with the secure element applet in a well-defined way (ISO 7816-4). In relation to secure NFC services, the SIMalliance OMAPI is vital and needs to be tested to ensure reliable security.
  
  
  
  
  Figure 2:
  The test specification for OMAPI is developed by SIMalliance. COMPRION provides a test solution for the required simulation tasks plus monitoring of the complete communication between UICC and handset (Prove 2). A test executor is a mobile application installed on the device and controlled by the host PC to test the relevant functions of the OMAPI. The COMPRION test solution and the device under test are connected via USB in order to control the test executor and the device’s ISO 7816 interface.
  The SEAC test cases also include event transactions via NFC interface to trigger the application level which gets testing close to a real use case for a payment activity. For this purpose, an NFC simulation tool has to be added to the setup (CLT One).
   
• Secure Element Access Control (SEAC)
  Secure Element Access Control is a security layer acting as a gatekeeper between the mobile applications and UICC applets. By evaluating the access rules stored on the UICC, the SEAC mechanism decides whether a mobile application is allowed to access a UICC applet or not. The purpose is to prevent unauthorized access to the UICC and especially to prevent attacks by malicious applications. The SEAC specification is defined by GlobalPlatform and the corresponding test cases are defined by the test book.
   
• Remote Management of NFC Services
  Remote management of NFC services is important for operators and service providers in order to install and update applications on the UICC. These UICC applets are required to enable the device with the UICC-secured NFC service. The UICC provided by an operator does not necessarily contain all relevant applications when delivered to the user. Therefore it is important that remote UICC management works correctly. The operator can use various data channels to download the applets. The interaction between device and UICC is tested by means of the test cases defined by the test book as well existing 3GPP test cases.
   
• SWP/HCI Interface Support
  The UICC uses one card contact to communicate with the CLF (Contactless Frontend) of the handset which is the central control unit for NFC communication. The communication protocol used is called SWP (Single Wire Protocol, defined by ETSI in TS 102 613) and a related logical interface is the HCI (Host Controller Interface, defined within ETSI TS 102 622). There are several test cases to check that this important interface works properly against interoperability standards. The handset test book references test cases defined by ETSI TC SCP and  supplements with additional test cases defined by the test book.  Although this is a contact-based interface, many of these test cases require the assistance of synchronized NFC tools. COMPRION offers several test solutions for this purpose (see figure 2+3).
  
  Figure 3: COMPRION’s Universal Terminal Testing Tool – UT³ Platform – is able to replace host PC, Prove 2 and CLT One. This way, the operator is significantly relieved as he or she only has to operate one single device for controlling the application on the phone, the contactless NFC and the UICC interface.

 

GSMA API Requirements

Any handset is required to provide a set of APIs to support functions in relation to the UICC-based NFC services. These functions are used by application developers and ensure that the industry has a standardized and stable programming interface as a basis for mobile application development. Such a set of APIs is specific to each mobile operating system – e.g. Android, Mobile Windows and BlackBerry.

The functions of the API defined by GSMA are intended to control the core NFC functions on the handset, e.g. enabling and disabling NFC, selecting and switching between different secure elements. In addition, they provide various applications functions querying which NFC-related features are supported by the handset. Currently, test cases for OS-specific APIs are under development and start to be available from coming releases of the test book.

 

Industry Alignment

Global deployment of UICC-based NFC services, especially for payment, is developing rapidly. By
the end of 2014, it is expected that more than 150 UICC-based NFC services will have been launched
with more than 60 commercial services. (Source: www.gsma.com/digitalcommerce/global-nfc-deployments)

The deployment of commercial NFC services without a coordinated approach for standardization is quite challenging, because the NFC ecosystem is strongly fragmented between many stakeholders and uses many different and complex technologies. COMPRION considers the GSMA approach for
standardization of requirements and testing of UICC-based NFC services as a big leap towards
improved interoperability independent of devices, secure elements and service providers. Bringing
the testing forward to global device certification schemes like GCF and PTCRB, enables the device vendors and the operators to establish common agreed testing of devices before service and devices are launched. This also leads to reduction of costly vendor- and operator-specific testing before and after product launch.

 

 

Figure 4
COMPRION offers a test solution based on the SIMfony system integrating both the UICC and the network simulator. UICC simulation takes place on IT³ Prove or UT³ Platform and network simulation is performed by Anritsu, Spirent or Rohde & Schwarz network simulators.

 

Author: Claus Andre Madsen, Business Development Manager

 

Download Testability Times 2014

---

• GSMA NFC Handset Test Book
• GSMA
• NFC
• SWP/HCI
• SEAC
• OMAPI