Article published in COMPRION Customer Magazine “Testability Times“, September 2014
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.
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
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.
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:
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.
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.
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
Alien eUICC profiles are “invading” your test space constantly. They are sent to you from different partners (MNOs) and consequently have very...