AFSCM TECH - LIVBL - Interface Specification - V1.2

AFSCM Interface Specification V1.2 – November 2009 – AFSCM Confidential & Proprietary p1/98

INTERFACE SPECIFICATION

Between Telecom Operators and NFC Service Providers

RELEASE 1.2

Date 20/10/2009

Reference AFSCM_Specification_Interface_V12 20091020.doc


Name Company

Authors Cécile Bailoni

Antoine Jacob

Sébastien Gauthier

Bouygues Telecom

Laurence Becq

Gaël Gérard

Susana Oliver-Pastor

Orange

Rolla Lamaa SFR

Editor Evelyne Babel AFSCM

Document manager Olivier Tessier SFR

Approval Olivier Tessier AFSCM

Document management

Version Date Chapters Modification

0.1 19/01/2009 All Document creation

0.2 26/02/2009 All Internal review

0.3 18/03/2009 All Comments from associate members

1.0 10/04/2009 All Final review

1.01 15/05/2009 Modifications in the Detailed Commands Description (chap 3.4 and appendices) in order to introduce the use of EXCEPTION.

List of modified paragraphs below.

3.4.2 and 3.4.3

MNO_ACKNOWLEDGE and SP_ACKNOWLEDGE: Removed COMPL_RESPONSE and added reference to EXCEPTION

3.4.4 Added a paragraph to define EXCEPTION

3.4.8, 3.4.12

A2.3.2

The elements COMPL_RESPONSE and RESPONSE_CODE are removed from the synchronous responses (ID_TECH_RESP, LONG_AID_RESP and TOKEN_RESP). In case any error is detected, the system will throw an EXCEPTION.

A1.1 Removed from the list of data: INSTALL_PARAMETER, SC_MANUF and COMPL_RESPONSE

SYNCH_STATUS only possible value is set to 0

A1.2 Added EXCEPTION to the List of requests, responses and notifications. Removed

A1.4 Response code table restricted to asynchronous responses

0 Created this appendix to described ERROR_TYPE used in the EXCEPTION

1.2 20/10/2009 All Included feedback from associate member and industry partners


TABLE OF CONTENTS ____________________________________________________________

1 INTRODUCTION ................................................................................................................... 7

1.1 Context .................................................................................................................................................. 7

1.2 Purpose of the interface specification .................................................................................................. 8

1.3 Content of the interface specification................................................................................................... 8

1.4 How to use this specification?............................................................................................................... 9

1.5 Reference to the other AFSCM guidelines .......................................................................................... 10

1.6 References ........................................................................................................................................... 11

1.7 Acronyms and abbreviations ............................................................................................................... 11

1.8 Definitions ........................................................................................................................................... 12

2 FUNCTIONAL REQUIREMENTS ................................................................................................. 13

2.1 Functional Principles ........................................................................................................................... 13

2.2 Basic assumptions ............................................................................................................................... 14

2.3 Process description and flow chart ..................................................................................................... 16 2.3.1 Process overall mapping ......................................................................................................... 16 2.3.2 Step 1: Inquiry about mobile NFC service ............................................................................... 17

2.3.2.1 Process 1 - Inquiry to the Service Provider .................................................................................. 17 2.3.2.2 Process 2 – Inquiry to the Mobile Network Operator .................................................................. 17

2.3.3 Step 2: Subscription ................................................................................................................ 18 2.3.3.1 Process 3 – Subscription at Service Provider's local office or on web site ................................... 18 2.3.3.2 Process 3 WAP – Subscription via a WAP session ....................................................................... 20

2.3.4 Step 3: Installation of Mobile NFC Service .............................................................................. 21 2.3.4.1 Process 4 – Mobile NFC UICC application installation ................................................................. 21 2.3.4.2 Process 4 Update - Mobile NFC UICC application update ........................................................... 24 2.3.4.3 Process 5 – Service Provider MMI installation ............................................................................ 25

2.3.5 Step 4: Use mobile NFC Service .............................................................................................. 28 2.3.5.1 Process 6 Change UICC ................................................................................................................ 28 2.3.5.2 Process 7 Change mobile phone number .................................................................................... 29 2.3.5.3 Process 8 Change mobile handset ............................................................................................... 30 2.3.5.4 Process 9 Lost or stolen mobile equipment, end user contacts Mobile Network Operator ........ 31 2.3.5.5 Process 10 Lost or stolen mobile equipment, end user contacts Service Provider ...................... 33 2.3.5.6 Process 11 Recover mobile equipment after a loss (or theft) ...................................................... 34 2.3.5.7 Process 12 Get a new mobile equipment after a loss of theft..................................................... 35 2.3.5.8 Process 13 – End user swaps Mobile Network Operator ............................................................ 35 2.3.5.9 Process 16 – End User requests temporary mobile service suspension....................................... 36 2.3.5.10 Process 17 – End user calls the Service Provider’s customer service ........................................... 37 2.3.5.11 Process 18 - End user calls the Mobile Network Operator’s customer service ............................ 38

2.3.6 Step 5 – Termination of mobile NFC service .......................................................................... 39 2.3.6.1 Process 14 – Termination by end user of Mobile subscription or NFC option ............................. 39 2.3.6.2 Process 15 - Termination of mobile service by Mobile Network Operator .................................. 40 2.3.6.3 Process 19 – Mobile NFC service termination ............................................................................. 42

3 INTERFACE SPECIFICATION ..................................................................................................... 43

3.1 Introduction ......................................................................................................................................... 43

3.2 Interface Connection and Exchange Protocol ..................................................................................... 44 3.2.1 Protocol ................................................................................................................................... 44 3.2.2 Interface .................................................................................................................................. 44 3.2.3 Synchronous and Asynchronous ............................................................................................. 44 3.2.4 Presentation of the exchanges ............................................................................................... 45


3.2.5 Elementary requests ............................................................................................................... 45 3.2.6 Retry management ................................................................................................................. 45 3.2.7 Load control ............................................................................................................................ 46 3.2.8 HEART_BEAT ........................................................................................................................... 46

3.3 Processes supporting customer journey ............................................................................................. 47 3.3.1 Process 1 – Inquiry to the Service Provider ............................................................................ 47 3.3.2 Process 2 – Inquiry to the Mobile Network Operator ............................................................ 47 3.3.3 Process 3 - Subscription to a mobile NFC Service ................................................................... 48 3.3.4 Process 4 – Installation of mobile NFC service ....................................................................... 48 3.3.5 Process 4 Update – UICC application update ......................................................................... 50 3.3.6 Process 5 – Service Provider MMI installation / Update ........................................................ 51 3.3.7 Process 6 – Change UICC ........................................................................................................ 54 3.3.8 Process 7 – Change mobile phone number ............................................................................ 54 3.3.9 Process 8 – Change mobile handset ....................................................................................... 54 3.3.10 Process 9 – Lost or stolen mobile equipment, end user contacts Mobile Network Operator 55 3.3.11 Process 10 – Lost or stolen mobile equipment, end user contacts Service Provider ......... 55 3.3.12 Process 11 – Recover mobile equipment after a loss ......................................................... 55 3.3.13 Process 12 – Get new mobile equipment after a loss or theft ........................................... 56 3.3.14 Process 13 – End user swaps Mobile Network Operator .................................................... 56 3.3.15 Process 14 – Termination by end user of Mobile subscription or NFC option ................... 56 3.3.16 Process 15 – Termination of mobile service by Mobile Network Operator ....................... 57 3.3.17 Process 16 – Suspension of mobile service upon end user’s request ................................. 57 3.3.18 Process 17 – End user calls the Service Provider’s customer service ................................. 58 3.3.19 Process 18 – End user calls the Mobile Network Operator’s customer service ................. 58 3.3.20 Process 19 – Termination of mobile NFC service ................................................................ 58

3.4 Detailed Commands Description ......................................................................................................... 59 3.4.1 HEADER ................................................................................................................................... 59 3.4.2 MNO_ACKNOWLEDGE ............................................................................................................ 60 3.4.3 SP_ACKNOWLEDGE ................................................................................................................. 60 3.4.4 EXCEPTION .............................................................................................................................. 62 3.4.5 Technical Identifier ID_TECH .................................................................................................. 63 3.4.6 Service Identifier SERV_ID ...................................................................................................... 64 3.4.7 ID_TECH_REQ .......................................................................................................................... 65 3.4.8 ID_TECH_RESP ........................................................................................................................ 66 3.4.9 SSD_CREATION_REQ ............................................................................................................... 66 3.4.10 SSD_CREATION_RESP .......................................................................................................... 67 3.4.11 LONG_AID_REQ ................................................................................................................... 68 3.4.12 LONG_AID_RESP.................................................................................................................. 68 3.4.13 INSTALL_REQ ....................................................................................................................... 69 3.4.14 INSTALL_RESP ...................................................................................................................... 71 3.4.15 INSTALL_MMI_REQ ............................................................................................................. 72 3.4.16 INSTALL_MMI_RESP ............................................................................................................ 73 3.4.17 SUPPRESS_REQ .................................................................................................................... 74 3.4.18 SUPPRESS_RESP .................................................................................................................. 74 3.4.19 NOTIF_SP_ACTION .............................................................................................................. 75 3.4.20 NOTIF_CALL_ENDUSER_TO_MNO ...................................................................................... 76 3.4.21 NOTIF_NEW_DEVICE ........................................................................................................... 76 3.4.22 NOTIF_CHANGE_ID_TECH ................................................................................................... 77 3.4.23 NOTIF_CALL_ENDUSER_TO_SP ........................................................................................... 77 3.4.24 NOTIF_CHANGE_TO_SP ...................................................................................................... 78

APPENDIX 1 DATA DICTIONARY ................................................................................................... 79


A1.1 List of data ................................................................................................................................... 79

A1.2 List of requests, responses and notifications .............................................................................. 82

A1.3 List of processes .......................................................................................................................... 84

A1.4 Response codes ........................................................................................................................... 85 A1.4.1 Exceptions ........................................................................................................................... 86 A1.4.2 Error Response Code management .................................................................................... 87

APPENDIX 2 INFORMATIVE APPENDIX ON DELEGATED MANAGEMENT ................................................... 88

A2.1 Process description and flow chart ............................................................................................. 88 A2.1.1 Process 4 – Installation of UICC application ........................................................................ 88 A2.1.2 Process 4 – Update of UICC application .............................................................................. 90 A2.1.3 Process 19 – Mobile NFC service termination .................................................................... 91

A2.2 Processes supporting customer journey ..................................................................................... 92 A2.2.1 Process 4 – Installation of UICC application ........................................................................ 92 A2.2.2 Process 4 – Update UICC application .................................................................................. 93 A2.2.3 Process 19 – Mobile NFC service termination .................................................................... 94

A2.3 Detailed commands .................................................................................................................... 95 A2.3.1 TOKEN_REQ ......................................................................................................................... 95 A2.3.2 TOKEN_RESP ....................................................................................................................... 96 A2.3.3 NOTIF_SP_ACTION .............................................................................................................. 96 A2.3.4 SUPPRESS_REQ .................................................................................................................... 97 A2.3.5 SUPPRESS_RESP .................................................................................................................. 97

APPENDIX 3 WSDL .................................................................................................................. 98


TABLE OF FIGURES ______________________________________________________________

Figure 1 - Legend for the process description .............................................................................................. 16

Figure 2 – Example of representation of the UICC application .................................................................... 21

Figure 3 - Overview of architecture .............................................................................................................. 43

Figure 4 – Example of detailed exchanges ................................................................................................... 44

Figure 5 – Example of synchronous request ................................................................................................ 45

Figure 6 - Simplified representation used in flow charts ............................................................................. 45

Figure 7 - Legend of flow charts ................................................................................................................... 47

Figure 8 - Process 3 Subscription .................................................................................................................. 48

Figure 9 - Process 4 Installation of UICC application in Simple SD ............................................................... 49

Figure 10 - UICC application update ............................................................................................................. 50

Figure 11 - Process 5 MMI installation managed by MNO ........................................................................... 51

Figure 12 - Process 5 MMI installation launched by MNO ........................................................................... 52

Figure 13 - Process 5 MMI Installation launched by Service Provider ......................................................... 52

Figure 14 - Critical MMI update .................................................................................................................... 53

Figure 15 - Process 6 Change UICC ............................................................................................................... 54

Figure 16 - Process 7 Change mobile phone number ................................................................................... 54

Figure 17 - Process 8 Change mobile handset .............................................................................................. 54

Figure 18 - Process 9 Lost or stolen mobile equipment, end user contacts MNO ....................................... 55

Figure 19 - Process 10 Lost or stolen mobile equipment, end user contacts SP .......................................... 55

Figure 20 - Process 11 Recover mobile equipment after a loss ................................................................... 56

Figure 21 - Process 12 Get new mobile equipment after a loss or theft...................................................... 56

Figure 22 - Process 14 Termination by end user of Mobile subscription or NFC option ............................. 57

Figure 23 - Process 15 Termination of mobile service by MNO ................................................................... 57

Figure 24 - Suspension of mobile service upon end user’s request ............................................................. 58

Figure 25 - Process 19 Termination of mobile NFC service .......................................................................... 58

Figure 26 – Examples of exchanges .............................................................................................................. 63

Figure 27 - Process 4 Installation in Delegated Management ...................................................................... 93

Figure 28 – Process 4 Update UICC application in Delegated Managed ...................................................... 94

Figure 29 - Process 19 Mobile NFC service termination in Delegated Management ................................... 95


1 INTRODUCTION

1.1 Context

The Mobile Network Operators Bouygues Telecom, Orange and SFR have founded the AFSCM (Association Française du Sans Contact Mobile) to foster the development of mobile contactless services.

The Service Providers Credit Mutuel, Société Générale and Véolia have already joined the AFSCM as associate members.

The AFSCM objective is to support the inception of new contactless services for mobile phone users. In particular, AFSCM endeavors:

- To support service providers such as banks or transit authorities in the definition and deployment of contactless solutions suited for mobile subscribers to any available mobile network;

- To specify technical guidelines for the development of mobile contactless services to ensure seamless installation and consistent user experience;

- To promote the benefits of the mobile phone platform for contactless service providers, for technology providers and for end users.

To define a mutually beneficial mobile contactless eco-system, AFSCM will propose a shared mobile contactless target mark and a shared brand that will distinguish those contactless services that are available to mobile phone users.

AFSCM constituency will include all companies involved in the development of a sustainable market for mobile contactless services such as Service Providers, handset makers, smart card manufacturers, Mobile Network Operators, MVNOs. Together, AFSCM members will contribute to the definition of innovative industry standards and best practices.

The stated objective of the AFSCM is to facilitate the development of mobile contactless services.

To this end, the founding members recognize the significance of the following success factors:

- Virtuous eco-system in which all parties involved can develop a sustainable market position,

- Efficient customer support,

- Smooth customer experience,

- State-of-the art application life cycle management,

- Service portability in the event of a mobile equipment swap,

- Service portability in the event of a Mobile Network Operator swap.


1.2 Purpose of the interface specification

The purpose of this document is to make possible a short term deployment (expected beginning of 2010) of multiple mobile NFC services involving the three French Mobile Network Operators.

To this end, AFSCM members have recognized the definition of a standardized interface between the Mobile Network Operators' and the Service Providers' information systems as a critical success factor to ensure interoperability between the actors, to simplify the deployment and to avoid redundancy in a multi-actors environment.

From the point of view of a Service Provider, this interface specification ensures that the same mechanisms and the same server will be applicable regardless of whatever the mobile network selected by the end user.

From the point of view of a Mobile Network Operator, this interface specification provides a unified way of exchanging data with any Service Providers of mobile NFC services.

Furthermore, this specification covers the entire life cycle of a mobile NFC service from the perspective of the end user.

1.3 Content of the interface specification

In order to meet the short term requirement, this document takes into account existing technical capabilities and limitations of the different components of the NFC ecosystem including the NFC mobile handset, the UICC and the MNO information systems at the target date. These capabilities and limitations are summarized in chapter 2.1 Functional Principles and 2.2 Basic assumptions.

This document then describes in chapter 2.3 Process description and flow chart the processes for every step of the customer path: inquiry of information, subscription, installation of the mobile NFC service, use of the mobile NFC service and termination of the service.

Then, the document presents the specification for the interface between Mobile Network Operators and Service providers. This interface is described in three distinct paragraphs:

- Chap 3.2 Interface Connection and Exchange Protocol describes the exchange protocol and the connection between the information systems of both actors that are the Mobile Network Operator and the Service Provider,

- Chap 3.3 Processes supporting customer journey presents the exchanges on the SP/MNO interface for supporting every step of the customer path,

- Chap 3.4 Detailed Commands Description describes in details each request, response and notification that can be exchanged between the information systems to manage a mobile NFC service life cycle.

Version 1 of this specification is designed to meet the requirements for short term deployments expected at the beginning of 2010.


1.4 How to use this specification?

Mandatory, conditional and optional functionalities

In the specifications below, some optional functionalities and conditional functionalities are described. They are represented in dotted line in the flow charts and are mentioned in the description.

The options are proposed to the decision of the Service Provider, except for the ACF, the implementation of which is a decision of the MNO.

Each Service Provider is responsible for selecting within the optional and conditional functionalities proposed in this specification the ones that are the most appropriate for its mobile NFC service thus resulting in a fine tuned configuration. From this perspective, this specification can be considered as a tool box in which the Service Provider selects the set of functionalities that he best suited for its mobile NFC service.

Yet, a minimum of mandatory functionalities must be implemented by each Service Provider in order to be “AFSCM compatible”. These minimum mandatory functionalities must be implemented by a Service Provider. They are highlighted with the warning sign as is this paragraph.

The MNO platform is ready to manage all the possible Service Provider configurations provided that they are compliant with the current interface specification.

Appendix A1.2 and A1.3 present in a table a synthetic view of the mandatory, conditional or optional criteria for each process and request.

Level of information

This interface specification covers three levels of information as described in the table below.

Level Domain / Task Reference chapter

Business Data Functional principles and basic assumptions

2.1 Functional Principles

2.2 Basic assumptions

Business Process Roles and Responsibilities

Process and constraints

2.3 Process description

3.3 Processes supporting customer journey

Data Exchange Protocol

Requests format

Data structure

3.2 Interface Connection and Exchange Protocol

3.4 Detailed Commands Description

Appendix 1 Data dictionary


Versions

The current version, version 1 is designed for the first commercial deployments that are expected at the beginning of 2010.

It is clearly identified that the Business Data and the Business Process will evolve from version 1 to the next versions of the interface specification in order to integrate more elaborate functionalities (such as Mandated DAP, Delegated Management, forecast notifications …) that are expected by different actors within MNO and Service Providers.

The subjects related to data exchange including protocol, request format and data structure are designed to be stable in the future versions of the interface specification. Some limited modifications will be possible:

- Introduction of additional parameters in a request or notification,

- Introduction of an additional request or notification.

1.5 Reference to the other AFSCM guidelines

The definition of the Service Provider/MNO interface is essential to ensure the interoperability. This specification is coherent with the other guidelines of the AFSCM that are related to:

- The NFC applications validation process. The purpose of this document is to provide the Service Providers with a unique process and rules for elaborating NFC applications taking into account the MNO requirements.

- The NFC applications (Cardlet and MIDlet) development guidelines. The rules for elaborating NFC applications are fully detailed in a guidelines book that gather all the functional, technical and security requirements regarding the process for validation, loading and hosting of NFC applications.

- The definition of Secure Service Management roles,

- The guidelines for interconnection of Service Providers' and MNOs' Information Systems. This document is the continuation of the interface specification, providing information on the process to be applied and the data that must be exchanged prior to establishing any connection between information systems.

.


1.6 References

The following documents are available for the Service Providers:

AFSCM

[R1] NFC Applications Validation Process

[R2] MIDlet Development Guide

[R3] Cardlet Development Guide

[R4] Secure Services Management Role

[R5] Guidelines for interconnection of Service Providers' and MNOs' Information Systems

Payez Mobile (AEPM)

[R6] Book 0 - General Description v1.1

[R7] Book 1 - Mobile Handset UICC Applications v1.1

[R8] Book 2 - Payment Service Delivery & Management v1.1

[R9] Book 3 - Payment Processing v1.1

Ulysse

[R10] Contactless transport ticketing using mobile phones - General Specifications V1.1

[R11] Contactless transport ticketing using mobile phones - Technical Specifications V1.1

GlobalPlatform

[R12] Global Platform Card Specification 2.2

[R13] UICC configuration 1.0

1.7 Acronyms and abbreviations

ACF Access Control File

AEPM Association Européenne Payez Mobile

AFSCM Association Française du Sans Contact Mobile

BIP Bearer Independent Protocol

DM Delegated Management

ISD Issuer Security Domain

KIC SSD key for encrypting data exchanged OTA via the SSD

KID SSD key for signing data exchanged OTA via the SSD

KIK SSD key for encrypting keys to be loaded in the SSD

MMI Man Machine Interface

MNO Mobile Network Operator

NFC Near Field Communication

RFU Reserved for Future Use

SP Service Provider

SSD Supplementary Security Domain

UICC Universal Integrated Circuit Card (usually known as SIM card)


1.8 Definitions

Application Short name for the UICC application

Delegated management

Pre-authorized Card Content changes performed by an approved Service Provider – defined in Global Platform

ID_TECH Technical Identifier of the line (unique for a given line and a given mobile NFC service)

Mobile equipment Represents the combination of a mobile handset and a UICC

Mobile NFC service Represents the combination of a UICC application and a MMI

Opt-in Invitation presented to the end user for getting his approval or rejection – for instance for downloading the MMI.

SERV_ID Identifier a mobile NFC service

Simple SD SSD management only performed by the MNO – mentioned as "SSD without Application Management Privileges" in GlobalPlatform

SSD_Manager Entity that manages the NFC platform and technical interface on behalf of a Service Provider


2 FUNCTIONAL REQUIREMENTS

2.1 Functional Principles

The processes described below were designed based on the following principles to the MNO processes and to the Service Provider processes.

End or suspension of Mobile NFC services in case of handset THEFT, LOSS, or UICC CHANGE

In those cases, the former UICC is left in an uncontrolled environment. Therefore the Mobile NFC services have to become inoperative as quickly as possible in the UICC in order to protect the end user against unlawful use of their potential existing entitlements that may be stored in the UICC.

In case of theft or loss, the mobile NFC service is made inoperative through the following actions:

- Attempt to lock OTA of UICC applications by the MNO,

- Additionally an applicative lock by Service Providers on their IT system may be requested in case OTA lock failed,

In case of a UICC change, the mobile NFC service is made inoperative through the following actions:

- OTA removal of UICC applications (to be applied in future steps),

- Additionally, destruction of the former UICC by the end-user is recommended in order to avoid leaving it in uncontrolled environment.

Reload and reactivation of Mobile NFC services after a THEFT, LOSS, or UICC CHANGE

It is essential to ensure the operation continuity of mobile NFC service after a loss, theft or UICC change. Once he/she gets a new UICC, the end user needs to retrieve his/her full Mobile NFC services in the same configuration as they were before. Therefore Service Providers have to load and activate again the services on the new UICC and new mobile handset.

Depending on Service Provider environment, the entitlements that were stored in the previous UICC will then be reloaded into the new UICC.

End of Mobile NFC services in case of Mobile services TERMINATION or SUSPENSION

The access to Mobile NFC service is conditioned to the complete availability of both mobile services and Service Provider service. Mobile line suspension or termination therefore directly impacts the life cycle of the Mobile NFC service and requires its termination.

In the present specification, the MNO cannot inform the Service Providers in advance but can notify them once the mobile service is suspended or terminated. Upon reception of this information, the Service Provider organizes the transfer of entitlements available in the current UICC. Once this transfer is done and within a limited period of time agreed between the Service Provider and the MNO, the Service Provider makes an applicative lock of the service on its IT system.


2.2 Basic assumptions

The work of the Process and Technical committees of the ASFCM, resulting in the current document, has been based on two sources of information:

- On one hand, the existing specifications of Mobile NFC services. These specifications target implementation for dedicated service domains:

o Ulysse specifications for mobile NFC transport ticketing services,

o and Payez Mobile specifications for mobile NFC payment services.

- And on the other hand, the technical capabilities of the different components of the NFC ecosystem including the NFC mobile handset, the UICC and the MNO information systems.

A key driver is to propose a simple and efficient solution applicable for the first deployments.

The current paragraph summarizes the main technical features that are required to deploy NFC services within a short term expected beginning 2010 and also the main features that will not be available for version 1.

The AFSCM also specifies high level requirements for both UICC and mobile handset in separate documents. These documents are only provided to the relevant suppliers on request.

UICC technology

The NFC application is hosted on the UICC of the mobile equipment.

The UICC uses JavaCard 2.2.2 technology and implements GlobalPlatform 2.2.

Supported GlobalPlatform functionalities

Within the functionalities defined by GlobalPlatform for remote application management, only the Simple SD management is considered with DAP as an option. Delegated Management and Confidential Loading are not supported yet.

Mandated DAP is not supported in Version 1. Mandated DAP is a functionality that automatically ensures that the applications loaded on the UICC were previously validated. AFSCM specifies an application validation process [R1] that can be considered as a temporary workaround. This “manual” validation process ensures that all the Service Provider’s applications loaded on the UICC were previously validated.

UICC memory size

In the early NFC deployment, the UICC memory size allocated to NFC services will be limited.

OTA capabilities

The SSD are created in the UICC. SSD can be created in two different ways:

- SSD creation in factory in this case, the SSD root keys may not be managed by the MNO.

- Or SSD creation OTA in this case, the SSD temporary keys are managed by the MNO.

The application package is loaded in the UICC. It can be loaded either in factory or OTA. Once the application is available in the UICC, the application activation (or deactivation) is performed upon request of the Service Provider at any moment during the life cycle of the UICC.

The MMI is loaded on the NFC mobile handset. The MMI can be downloaded OTA.


Process and Information Systems

The following assumptions are made based on the current Information System limitations:

- In version 1, the Mobile Network Operators cannot send notifications in advance to the Service Providers, for instance in case of line suspension or termination. The Service Providers are informed once the suspension or termination is effective.

- The protocol used to exchange on the Service Provider / Mobile Network Operator interface is described in this specification (chap 3 Interface Specification) and is designed to be able to support not only the first phases but also the future phases of mobile NFC services deployment.

- A technical identifier is used to identify the end user in the communication between Mobile Network Operator and Service Providers. In France, it is the ALIAS already used by each Mobile Network Operator for WAP services and SMS premium. The Mobile Network Operator is identified in the header of each request, response and notification with the data ID_MNO.

- In version 1, it is not possible to manage memory space booking on a UICC as described in Payez Mobile.

- Another restriction is related to the synchronisation of actions in case of urgent situations such as loss or theft. The AFSCM functional principles require the application to be locked or deleted before the line is suspended or terminated to avoid having on the field “not under control” applications. Yet, it relies on the capacity of the Mobile Network Operator’s information system to synchronise the locking before line suspension or termination which is not guaranteed in version 1.

[Note] There is not guaranty that it is possible to reach the mobile handset for locking an application. This is a de facto limitation – in case mobile handset is not under mobile network coverage or switched off.

Interoperability and multi application management

The support of multi applications is possible thanks to the Java Card technology ensuring secure partition between applications.

The AFSCM development guides ([R2] MIDlet Development and [R3] Cardlet Development ) define rules regarding interaction between homepage application and the Service Providers' applications.


2.3 Process description and flow chart

This paragraph presents all the user experiences as they can be implemented in version 1. The restrictions compared to the mid term and long term target as defined for instance in Payez Mobile or Ulysse are highlighted.

Action or process

End of a process

Choice

Optional action or

process

Covers a process already

described

Notifications

Figure 1 - Legend for the process description

2.3.1 Process overall mapping

This diagram presents the five steps and all the processes that are described in this document. The optional or conditional processes are represented in dotted line in the mapping below.

Ste

p 5

Te

rmin

atio

n

Process global mapping

Ste

p 1

Inq

uiry

Ste

p 2

Su

bscrip

tio

n

Ste

p 3

Insta

llatio

nS

tep

4 -

Usa

ge

Inquiry to Service

Provider – Process 1

Inquiry to MNO

Process 2

Subscription at SP’s

local office or web site

Process 3

Subscription from mobile

handest via WAP session

Process 3 WAP

Install UICC application

Process 4

Install / Update MMI

Process 5

Update UICC application

Process 4 Update

Lost/stolen Mobile

equipment. Contact MNO

Process 9

Recover Mobile

equipment

Process 11

Lost/stolen Mobile

equipment. Contact SP

Process 10

Get a new Mobile

equipment

Process 12

Termination of Mobile

subscription or NFC option by

end user - Process 14

Termination of Mobile service

by MNO - Process 15

End user requests

Temporary mobile service

supsension - Process 16

End user contacts SP

customer service

Process 17

End user contacts MNO

customer service

Process 18

Termination of mobile NFC service

Process 19

Change UICC

Process 6

Change Mobile Phone

Number - Process 7

Change Mobile

Handset - Process 8

Optional process

Service Provider decision to use

one or many of these channels

Conditional Process

Mandatory if MMI is necessary

Optional process

if SP wants to do OTA update


2.3.2 Step 1: Inquiry about mobile NFC service

For this step, the end user contacts either the Service Provider (Process 1) or the Mobile Network Operator (Process 2). Both processes are mandatory.

2.3.2.1 Process 1 - Inquiry to the Service Provider

The end user is asking the Service Provider about a mobile NFC service.

The Service Provider is responsible for the way of delivering information regarding the mobile NFC service to his customers. Upon the end user’s request, the Service Provider verifies that this end user is eligible for NFC service with regards to its internal policy and strategy.

The Service Provider can mention that there are pre requisites on the UICC and mobile NFC handset for accessing a mobile NFC service – and explain that ultimately this subject will be handled by the Mobile Network Operator who will propose if necessary the proper mobile equipment to the end user.

If the Service Provider estimates that this end user is eligible, the end user is invited to subscribe the mobile NFC service (Process 3).

This step does not impact the interface between the Mobile Network Operator and the Service Provider.

Ste

p 2

:

Su

bscrip

tio

n

Process N°1 – End user asks his Service Provider about available mobile NFC services

Ste

p 1

: In

qu

iry

Service ProviderEnd user

Inform the End user about:

- mobile NFC services

- subscription requirements

Yes

No

Ask the end user to

contact his MNO

Process n°3 SUBSCRIBE to a

mobile NFC service

Is the End user eligible?

2.3.2.2 Process 2 – Inquiry to the Mobile Network Operator

In case the end user asks the Mobile Network Operator about mobile NFC services, the MNO presents the pre requisites for accessing mobile NFC service and can already check if the end user’s mobile equipment and his mobile offer are eligible for mobile NFC service. In case it is not, the Mobile Network Operator proposes the end user to subscribe the appropriate offer and/or to buy the appropriate mobile equipment.

Then the end user is invited to contact the Service Provider for initiating the subscription to the mobile NFC service (Process 3).

[Note] In case the end user gets mobile equipment outside the Mobile Network Operators' point of sales, the mobile NFC services cannot be guaranteed.


Ste

p 2

Su

bscrip

tio

nProcess N°2 - End user asks his MNO about available mobile NFC services

Ste

p 1

: In

qu

iry

Inte

rme

dia

te s

tep

: p

rovid

e e

nd

use

r w

ith

NF

C d

evic

e

Mobile Network OperatorEnd user

Inform the end user about contractual and

technical prerequisites as well as Service

Provider requirements

Does end user have an

NFC device?No

Does the end user wish to

buy one?

No

End

Yes Sell an NFC device

Does the current end user

offer allow the access to NFC

services?

Yes

No

No

Does the end user

wish to subscribe to the

offer ?

Yes Sell appropriate offer

Yes

Ask the end user to contact his targeted

Service Provider to subscribe to a mobile NFC

service

Process n°3 SUBSCRIBE to a

mobile NFC service

End user inquires about mobile

NFC services

2.3.3 Step 2: Subscription

The subscription for a new or an additional mobile NFC service can take place via different channels:

- Service Provider's local office or web site Process 3

- From the mobile handset via a WAP session Process 3 WAP

It is a decision of the Service Provider to use at least one or several of these channels.

2.3.3.1 Process 3 – Subscription at Service Provider's local office or on web site

The same process applies for the first subscription to a mobile NFC service (case 1) and for the subscription to an additional mobile NFC service (case 2).

For this process, the end user is requested to give his mobile phone number to the Service Provider. The Service Provider can make its own internal scoring for eligibility to mobile NFC service before asking the end user’s mobile phone number and approval for submitting eligibility request to the Mobile Network Operator.

Then the Service Provider asks the MNO for the eligibility for the mobile phone number of the end user. If the answer is positive, the next step is the installation (Process 4). If the answer is negative, the Service Provider informs the end user to contact the MNO.


Eligibility

The eligibility check is based on the three following criteria:

- Commercial (end-user known by the Mobile Network Operator, and has access to NFC services)

- Technical (UICC and mobile handset NFC capable)

- Available memory space on UICC

Restrictions specific to version 1

In version 1, the way to perform the eligibility check might differ from one MNO to another especially regarding the available memory space on UICC, and the information regarding the available memory space is not guaranteed.

In version 1, it is not possible to manage memory space booking on the UICC.

Ste

p 3

Process N°3 Subscription at Service Provider’s local office or on web site

Ste

p 2

: S

ub

scrib

e to

a m

ob

ile N

FC

se

rvic

e

End user

Example of end user and mobile authentication by the mean of an authentication key

Service Provider Mobile Network Operator

No

No

Yes

Yes

Short leadtime

(except if network troubles)

Yes

Yes

No

No

Scoring by Service Provider (optional)

Send SMS containing an

authentication « key »to

end user

Is end user

eligible from MNO

perspective?

Inform End user to contact his MNO,

specifying the reason why he is not

eligible

Verify eligibility for this mobile

phone number

Service Provider approval ?

Request for eligibility of end user

Authentication key

match?

End user approval?

SMS reception.

Communicate the

authentication key to the

Service Provider

Ask the End user’s mobile phone number

and his approval for checking its elibigility

to NFC service (legal impacts)

Process n°4 « Install the mobile NFC

service »

End

Case 1

Case 2


2.3.3.2 Process 3 WAP – Subscription via a WAP session

When the end user subscribes on a WAP site, the process is similar to the one described in previous paragraph except that the end user does not need to communicate his mobile phone number. The Service Provider receives a technical identifier from the WAP session and sends the request for eligibility to the Mobile Network Operator with this technical identifier.


The restrictions regarding the eligibility check and memory space mentioned in process 3 also apply for this process.

Ste

p 3

Process N°3 Subscription via a WAP session

Ste

p 2

: S

ub

scrib

e to

a m

ob

ile N

FC

se

rvic

e

Mobile Network OperatorService Provider (WAP site)End user

No

Yes

Yes

No

Scoring by Service Provider (optional)

Is end user

eligible from MNO

perspective?

Service Provider

approval ?

Access to WAP site. The Service

Provider collects the mobile handset

identifier from the WAP session data

Process n°4 « Install the mobile NFC

service »

Verify eligibility for this mobile

handset, based on provided

technical identifier

End

Request for eligibility of end user

Inform End user to contact his MNO,

specifying the reason why he is not

eligible

Case 1

Case 2


2.3.4 Step 3: Installation of Mobile NFC Service

As mentioned in the definitions, a mobile NFC service consists of the combination of one (or several) UICC application and a MMI.

The installation is considered as completed once both UICC application(s) and MMI are loaded on the end user’s mobile equipment.

Therefore, Step 3 Installation of Mobile NFC service is composed of two processes:

- Installation of UICC application (s) Process 4. This process is mandatory.

- Installation of MMI on the mobile handset of the end user Process 5. This process is conditional. It is possible that some mobile NFC services do not require a MMI. In this case the process 5 is not applicable.

[Note] In the mobile NFC service lifetime, it might happen that the MMI is deleted from the end user’s mobile handset. It is under the Service Provider responsibility to decide whether he tolerates or not that his mobile NFC service is used without the MMI on the mobile handset. In case he tolerates, it is recommended to inform the end user that he cannot benefit from full capacity of his mobile NFC service. In case the Service Provider does not tolerate this situation, he either launches the MMI installation or initiates the lock or suppression of the UICC application.

The update of application is also included in step 3. It is described in:

- Process 4 Update for the UICC application update. This process is optional. It is upon Service Provider’s decision to have the capacity to update OTA its UICC application.

- Process 5 for the MMI update. This process is mandatory when there is a MMI.

2.3.4.1 Process 4 – Mobile NFC UICC application installation

The UICC application, also named application, is composed of one or several packages, one or several instances and personalisation data hosted in the UICC as represented below. The drawing below is an example of representation of all that is necessary on the UICC before the mobile NFC service can be used.

ISD SP SSD

PackageInstance

Perso Data

Figure 2 – Example of representation of the UICC application

The Service Provider is responsible for initiating the installation of the mobile NFC service on the End user’s mobile equipment. Due to Simple SD management, the MNO actually performs the loading, installation and activation of the application on the UICC upon request of the Service Provider.


Three different scenarios are considered in these specifications for the UICC application installation. For each scenario, the content of the UICC is represented before any OTA operation as available in the end user’s mobile handset, therefore highlighting all the items that will need to be installed OTA.

ISD SP SSD

PackageInstance

FULL PRELOADED

The SSD is created in factory. The application is loaded, instantiated and extradited in factory. The personalisation is done by the Service Provider either in factory or OTA. After the application personalisation and upon request of the Service Provider the MNO simply needs to activate the application on the end user’s UICC.

[Note] For this Full preloaded scenario, the Service Provider only needs to send an activation request to the MNO.

ISD

Package

SP SSD

PARTIAL OTA

In this scenario, the application is loaded in factory. The SSD may be created in factory (as represented) or OTA. Upon installation request of the Service Provider, the Mobile Network Operator instantiates and extradites the package to the security domain of the Service Provider. The Service Provider does the personalisation OTA. After the personalisation, the Service Provider requests for the application activation. Upon reception of the activation request, the Mobile Network Operator activates the mobile NFC service.

ISD

FULL OTA

Upon request of the Service Provider, the Mobile Network Operator performs OTA loading of the package, the instantiation and extradition to the security domain of the Service Provider. The SSD might also be created OTA. The Service Provider does the personalisation OTA. After the personalisation, the Service Provider requests for the application activation. Upon reception of the activation request, the Mobile Network Operator activates the mobile NFC service.


In version 1, only Simple SD Management is available, therefore the Mobile Network Operator performs the following actions upon request of the Service Provider:

- Application loading

- Instance creation, extradition and activation

- Application deletion

[Note] In simple SD, when the package needs to be loaded OTA, it is mandatory to have the application certified package(s) and the corresponding installation parameters available on Mobile Network Operator’s platform before submitting requests for loading the package.

[Note] Installation parameters are critical information for the application instanciation. They are stored on the MNO platform and are pre validated by the MNO.


Ste

p 3

– M

ob

ile N

FC

se

rvic

e in

sta

llatio

nProcess N°4 – Installation of UICC application

Mobile Network OperatorService ProviderEnd user

Yes

No

Install the mobile NFC service on

the UICC

Inform SP of successful

installation

Successful installation?Inform Service

Provider of failure

Inform End user of

failure

Process 5 – MMI installation

Application personalisation

Notify the MNO about the

personalisation completion

Activate the mobile NFC

service

Successful

activation?

Yes

NoInform Service Provider of

failure

Initiate installation

Inform Service Provider of

successful activationYes

Request for activation


2.3.4.2 Process 4 Update - Mobile NFC UICC application update

This process applies for each of the following circumstances:

- The end user replaces or updates his mobile NFC service requiring the installation of a new NFC application,

- The Service Provider wants to update the existing end user NFC service, or wants to propose a new service,

- The Service Provider wants to update its mobile NFC service for all end users.

It is first necessary to delete the existing application and then check again the eligibility to ensure that there is enough memory space in the UICC for the new application, and finally install the new application. Optionally the end user might have to sign a new contract or contract amendment. The installation process is similar to the one described in Process 4.

[Note] This process for OTA update of the UICC application is optional upon Service Provider’s decision. If not implemented it means that the application deployed in the UICC cannot be updated OTA.

Ste

p 3

In

sta

ll M

ob

ile N

FC

Se

rvic

e

Process N°4 Update – Update of UICC application

Service Provider

Subscription process

End user Mobile Network Operator

No

Yes

Inform end user about temporary

service suspension

Delete application and

inform SP

Is end user

eligible from MNO

perspective?

Replace/renewal of NFC offer

(upon request of end user or

SP)

Update of the mobile NFC service

by the Service Provider

After some leadtime, request

application deletion

Request for elegibility

Sign contract or contract

amendment is necessary

Process n°4 « Install UICC application»

Inform End user to contact his

MNO, specifying the reason why

he is not eligible


2.3.4.3 Process 5 – Service Provider MMI installation

This process is conditional. It is mandatory when a MMI is necessary for the mobile NFC service.

Once the UICC application installation is successfully completed, the end user is invited to load the MMI of the Service Provider. Depending on the capacity of the Service Provider to operate himself the initiation of MMI download, there are two ways to initiate this process:

- Case 1: Upon Service Provider request, the MNO launches the MMI installation or update,

- Case 2: the Service Provider launches the MMI installation or update.

In both cases, the assumption is that the MMI server is under the Service Provider’s responsibility.

Case 1

In case 1, the Service Provider requests the MNO for launching the installation of the MMI, and if used, for loading the ACF. This case corresponds to Service Providers who don’t want to manage the establishment of an OTA connection with the mobile handset.

The Mobile Network Operator first loads the ACF in the UICC (if ACF is used) and then initiates the connection between the mobile handset and the Service Provider’s MMI server in order to load the MMI application on the end user’s mobile handset.

Depending on the agreement between the Service Provider and the MNO, there are two possibilities:

i. The MNO manages the entire installation including retries if necessary.

The MNO informs the Service Provider once the ACF and the MMI are effectively loaded in the mobile handset. In case of connection interruption during the MMI loading, the MNO manages the retries.

This situation corresponds to the case where there is a local synchronisation mechanism in the mobile handset to ensure the MMI download. This application is an option that can be proposed by the MNO. It can only be available on NFC mobile handsets that are sold by the MNOs who implement it.

ii. Or the MNO only manages ACF loading and sends a SMS push WAP to the handset to establish a connection with the Service Provider’s MMI server. The Service Provider needs to manage retries in case of connection interruption.

The Service Provider can receive the confirmation of MMI download from its MMI server and from the MMI code (see note below). In case the MMI download fails due to connection interruption for instance, the Service Provider manages the retry by sending a new request to the MNO for initiating the MMI download.

[Note] ACF is a way of securing the access of MMIs to the UICC. The use of ACF or not is a decision of the Mobile Network Operator. The MNO informs the Service Provider about this choice during the information systems interconnection preparation.

[Note] The MMI code (.JAD) includes an url to which a notification message is sent once the MMI is installed on a mobile handset.


Case 2

In case 2, the Service Provider is almost autonomous to download the MMI, except for the ACF which, if used, must be loaded by the MNO.

Once the MMI is downloaded, the Service Provider notifies the MNO and informs the end user that the mobile NFC service is ready for use.

[Note] Several reasons might cause failure of the MMI download (interruption in network coverage, mobile handset switched off, end user rejects or does not approve opt-in …). It is recommended to attempt several consecutive times to download the MMI before considering that it has failed.

[Note] In case the MMI is never installed, the Service Provider notifies the MNO. It is under the Service Provider’s responsibility to decide:

i. to suppress or not the UICC application,

ii. to inform the end user in case of installation failure.


MMI update

When the Service Provider needs to update the MMI on the end user’s mobile handset, the two processes described above (case 1 and case 2) also apply.

In case the Service Provider estimates that it is urgent and mandatory, ie “critical”, to update the MMI for using the mobile NFC service, the Service Provider might decide to lock the service until the MMI update is effective. The Service Provider is responsible for such a decision and must notify the MNO.


2.3.5 Step 4: Use mobile NFC Service

The step 4, Use of mobile NFC Service, covers a large number of processes:

- Change UICC (Process 6)

- Change mobile phone number (Process 7)

- Change mobile handset (Process 8)

- Lost or stolen mobile equipment, end user contacts Mobile Network Operator (Process 9)

- Lost or stolen mobile equipment, end user contacts Service Provider (Process 10)

- Recover mobile equipment after a lost or theft (Process 11)

- Get a new mobile equipment after a lost of theft (Process 12)

- End user changes Mobile Network Operator (Process 13)

- End User requests temporary mobile service suspension (Process 16)

- End user calls the Service Provider’s customer service (Process 17)

- End user calls the Mobile Network Operator’s customer service (Process 18)

The support of all these processes is mandatory to implement a mobile NFC service and ensure a consistent end user’s experience.

2.3.5.1 Process 6 Change UICC

Changing UICC can be proposed to the end user either because the UICC is out of order or to get larger memory space or additional functionalities.

Changing the UICC requires to reinstall the application package, whereas the MMI is not impacted.

Upon reception of the end user’s request, the Mobile Network Operator deactivates the former UICC on the mobile network, provides a new UICC to the end user and activates this UICC on the mobile network.

The MNO informs in parallel the end user that his mobile NFC services must be reinstalled and the Service Providers that the UICC has been changed. Upon reception of this notification, the Service Provider applies his own policy regarding the mobile NFC application re installation.

The end user is requested to destroy the former UICC.

[Note] It is not possible to manage OTA the UICC end of life. This requires mentioning the responsibility of the end user in MNO and Service Provider contracts regarding the destruction of the old UICC.


“Pre” notification to inform Service Providers before UICC change is not available in version 1.


S

tep

3

Process N°6 Change UICC

Be

fore

UIC

C

en

d o

f lif

eS

tep

4: U

se

mo

bile

NF

C s

erv

ice


Deactivate previous UICC

and activate new UICC

Notify Service Provider

about UICC change

Inform end user that his mobile

NFC services need to be

reinstalled and will be resintalled

Deployment of Service

Provider policy

Process n°4 « Install a mobile

NFC service»

Destroy previous UICC (as

mentionned in contract)

Further steps to be defined by

each Service Provider

Change of a UICC that is still

working

UICC out of order needs to be

replaced

2.3.5.2 Process 7 Change mobile phone number

The end user wants to change his mobile phone number without changing UICC, mobile phone or Mobile Network Operator.

The Mobile Network Operator provides a new mobile phone number to the end user.

This change results in a change of the technical identifier (ID_TECH) used to identify the end-user between Mobile Network Operator and Service Providers. The Mobile Network Operator notifies the Service Provider about the change of ID_TECH. If needed the Service Provider can ask the end user his new mobile phone number;

Ste

p 4

: U

se

mo

bile

NF

C s

erv

ice

Process n°7 Change mobile phone number

(without changing UICC, mobile handset or MNO)


Provide a new mobile phone number

to the end user

End

Notify Service Provider about the

change of ID_TECH for the end user

End user wants to change his

mobile phone number and

contacts his MNO


2.3.5.3 Process 8 Change mobile handset

When the end user changes his mobile handset, it is convenient to provide him with assistance for launching the installation of the MMI for each mobile NFC service hosted in his UICC. Yet, as the mobile change may be temporary, an Opt-in is presented to the end user so that he can decide whether downloading of MMI is necessary or not on this mobile handset.

Once the end user inserts the UICC in a new mobile handset:

- Either a local detection is done on the mobile handset to identify that MMI are missing compared to the content of the UICC.

- Or the Mobile Network Operator remotely detects that the mobile handset has changed.

[Note] The application for local detection of missing MMI on the mobile handset is an option that can be proposed by the Mobile Network Operator. It can only be available on the mobile handsets sold by the MNOs who implemented this option.

If there is a local application for detection of missing MMI, an opt-in is presented to the end user to propose him to load the missing MMI. If the end user approves, the “local detection application” operates so that the end user’s mobile handset connects to the Service Provider server for downloading the MMI.

In case the detection is done remotely on the MNO information system, the Mobile Network Operator checks if this mobile handset is NFC compliant. If this new mobile handset is NFC compliant, the MNO notifies all the relevant Service Providers about the new handset so that each Service Provider can invite the end user to download the MMI to benefit from full capacity of his mobile NFC service.

When the end user validates the Opt-in, the MMI download process is initiated (Process 5).

In case the end user does not accept the Opt-in, or the new mobile handset is not NFC compliant, the end user is informed that he cannot use his mobile NFC services or at least cannot benefit from full capacity of the mobile NFC service.

[Note] The Mobile Network Operator will inform the End User that the mobile NFC services cannot be guaranteed if he purchases a mobile handset outside the Mobile Network Operator stores.

[Note] In version 1 the mobiles phones that are not bought in Mobile Network Operator stores will be considered as NFC not compliant even if they are NFC capable.

[Note] The MMI is specific for each mobile handset. Therefore the Service Provider must manage a database in order to download the appropriate MMI on a given handset.

[Note] The application for local detection on the mobile handset is an option that can be proposed by the Mobile Network Operator. It can only be available on the mobile handsets sold by the MNOs who implemented this option.


S

tep

4: U

se

mo

bile

NF

C s

erv

ice

Process N°8 – End user changes his mobile handset

Mobile OperatorService ProviderEnd user

No

Yes

No

Yes

No

Yes

End user inserts his SIM into the

new NFC mobile handset

Local detection that

MMI are missing ?

End user can not benefit from full

capacity of his mobile NFC

services.

Is the new mobile handset

NFC compliant?

Process n°5 « Install a

mobile NFC MMI»

Invite end user to

download MMI

Remote detection of the

change of handset

Do you want to load

missing MMI ?

Notify Service Providers

about new mobile handset

End user can not benefit

from his mobile NFC

services.

2.3.5.4 Process 9 Lost or stolen mobile equipment, end user contacts Mobile Network Operator

The mobile equipment was lost or stolen and the end user contacts the Mobile Network Operator’s customer service. The Mobile Network Operator Customer Service shall first authenticate the end-user and shall identify that this end user is a mobile NFC service end user in order to launch in parallel the three following actions:

- Notify the event to all concerned Service Providers,

- Explain to the end user that the Service Providers are informed, but still recommend to also contact directly the Service Providers in case of critical application such as payment,

- Attempt to lock OTA all mobile NFC services hosted on the end user’s mobile if possible before line suspension.

After attempting the OTA locking of the service, the MNO suspends the line and notifies each Service provider about the line suspension and the application status (lock or unlock) for this end user.

Upon reception of this information, whether the OTA lock has succeeded or not, the Service Provider must make an applicative lock of the service on its information system and he applies his own appropriate policy (on hold, blacklist …).

[Note] It is important to guide the End user to the right entry point within customer service able to manage the blocking process of mobile NFC service

[Note] For information: Locking and on hold are processes that can be reversed. Whereas blacklist is a definitive process and cannot be reversed.


[Note] It is recommended that only the party which locked an application is in charge of unlocking when necessary. Therefore, when an application is locked, it is recommended to each party to clearly register in its information system who locked the application.

[Note] When the mobile NFC service needs to be locked, all the UICC applications, in case there are several, that compose the service are locked.

Ste

p 4

: U

se

mo

bile

NF

C s

erv

ice

Process N°9 End user’s mobile equipment was lost or stolen. End user contacts his MNO


*

*

Suspend the mobile connection

Inform End user that the Service

Provider(s) were notified and

recommend to also directly contact the

Service Provider in case of « critical »

mobile NFC service.

Notify the Service Providers

1) About end of mobile

connection

2) and the locking status

Identify End user of

mobile NFC service

End user contacts his

MNO

Contact his Service

Provider

Launch appropriate process

(blacklist…)

Confirm the request

for blacklisting the

mobile NFC service

Notify lost/stolen mobile to the

Service Provider(s) *

[Note] The actions identified with * are

processed in parallelLaunch appropriate

process (blacklist…)

Notify MNO about

applicative locking

Try to lock the mobile NFC

services OTA if possible before

line suspension

Was blocking

successful ?

Blacklist the end

user’s mobile NFC

service

No

Yes


2.3.5.5 Process 10 Lost or stolen mobile equipment, end user contacts Service Provider

The mobile equipment was lost or stolen and the end user contacts his Service Provider. The Service Provider shall first authenticate the end-user and then identify that this end user is a mobile NFC service end user in order to launch two actions in parallel:

- Apply the appropriate internal policy (on hold, or backlist …) on his information system for this end user and recommend the end user to also contact his Mobile Network Operator,

- As an option, the Service Provider can attempt to lock OTA the mobile NFC application hosted on the end user’s UICC.

Then the Service Provider notifies the Mobile Network Operator about the locking operation status (lock on information system, and if relevant OTA locking). Depending on the status of the OTA locking operation, the Service Provider might want to update the status of this end user in his information system.

[Note] It is important to guide the End user to the right entry point within customer service able to manage the blocking process of mobile NFC services

Ste

p 4

: U

se

mo

bile

NF

C s

erv

ice

Process N°10 End user’s mobile equipment was lost or stolen. End user contacts his Service Provider

MNOService ProviderEnd user

Identify and authenticate End user for mobile NFC

service. Inform end user to contact his MNO

Attempt to lock OTA the

mobile NFC application

Service Provicer launches

appropriate process (on hold

…)

Notify MNO about locking

status

Is mobile NFC service blocking

effective?

Yes

No

Confirm to Service Provider

the request for blacklisting the

mobile NFC service

End user contacts his Service

Provider

End of Process

Service Provider update

information system


2.3.5.6 Process 11 Recover mobile equipment after a loss (or theft)

After a loss (or theft), the End user recovers his mobile phone and UICC and contacts his Mobile Network Operator who notifies each Service Provider after having unlocked OTA all mobile NFC services if previously locked (see 2.3.5.4Process 9 Lost or stolen mobile equipment, end user contacts Mobile Network Operator). Upon reception of the line restore information:

- If the service was black listed, the Service Provider needs to entirely reinstall the mobile NFC Service on end user’s mobile equipment. In this case, it is necessary to previously suppress the old version of the service.

- If the service was simply locked, the Service Provider unlocks the application on its information system. Once the service is unlocked, the Service Provider notifies the MNO about the unlocking of the mobile NFC service (on Information System). Finally, the Service Provider informs the end user that the mobile NFC service is ready to use again.

[Note] In case some services cannot be loaded OTA, the end user might have to change the UICC.

Ste

p 4

: U

se

mo

bile

NF

C s

erv

ice

Process n°11 – After a loss or theft, the End user recovers his mobile equipment and UICC


Restore the mobile connection

and inform End User

Notify the Service Provider(s)

Was the mobile NFC

Service OTA locked ?

No

OTA Unlock mobile NFC

service

YesProcess n°4 « Install mobile

NFC service »

Notify MNO

Was the mobile NFC

Service blacklisted?

Yes

No

Reinstall mobile NFC service

End user contacts his

MNO

Inform End user that mobile

NFC service is ready to use

Delete previous application

Unlock service on

Information System

Try to unlock the mobile NFC

services OTA


2.3.5.7 Process 12 Get a new mobile equipment after a loss of theft

After a loss or theft, the End user has a new NFC mobile phone and UICC and wants to restore his mobile NFC services.

The Mobile Network Operator restores the mobile connection and checks if the new mobile equipment of the end user is NFC compliant. In case the mobile equipment is not NFC compliant, the end user is invited to get an appropriate device.

When the Mobile Network Operator is sure that the end user has both NFC mobile handset and UICC, he notifies the Service Provider that he can launch the mobile NFC service installation process, after communicating with the end user if necessary.

[Note] A risk is identified on the fact that End user might get a mobile handset that is not NFC compatible and will contact the customer service.

Ste

p 4

: U

se

mo

bile

NF

C s

erv

ice

Process 12: After a loss or theft, the End user has a new NFC mobile handset and UICC and

wants to restore his mobile NFC service


Check End user’s mobile

equipement

Is new

mobile equipement NFC

compliant?

Get a NFC mobile equiment No

Restore end user’s mobile

connection

Yes

Notify Service Provider to launch

installation process

Yes

Communication with Service

Provider

Process N°2 End user inquires to

MNO (intermediate step to get a

mobile NFC device)

Service Provider wants

to contact End user before

loading ?No

End user contacts his MNO

Process n°4 « Install mobile

NFC service »

2.3.5.8 Process 13 – End user swaps Mobile Network Operator

The end user changes Mobile Network Operator keeping the same phone number and wants to keep the mobile NFC services. The customer has to go through two consecutive steps:

- Mobile subscription termination (Process 14) with the first Mobile Network Operator,

- and then service installation with the new Mobile Network Operator (Process 4)


Automated portability inter- Mobile Network Operator mechanism of mobile NFC services is out of scope for the first phase of NFC deployment and is therefore not described in the current document. End user support and minimum set of facilities will be proposed apart from this IT interface document.


2.3.5.9 Process 16 – End User requests temporary mobile service suspension

The end user requests the Mobile Network Operator for a temporary line suspension. The MNO agrees with the end user on the suspension date and the restore date.

At suspension date, the Mobile Network Operator suspends the line and notifies the Service Providers.

Upon reception of the notification for line suspension, the Service Provider can organize the transfer of entitlements available in the current UICC. Once this transfer is done, and within a limited period of time agreed between the Service Provider and the MNO, the Service Provider makes an applicative lock of the service on its IT system and notifies the MNO with the locking confirmation.

At restore date, the Mobile Network Operator restores the line and in parallel notifies the Service Providers.

The Service Provider unlocks the mobile NFC service on its information system and notifies the MNO to confirm that the service is ready again for use.


In version 1, Mobile Network Operators do not have the possibility to send forecast notifications to the Service Providers.

Ste

p 4

: U

se

mo

bile

NF

C s

erv

ice

Process N°16 – End User requests temporary mobile service suspension


At suspension date, suspend the line

and notify the Service Providers

Acknowledge end user’s request and

agree on suspension date and restore

date

At restore date, restore the line and

notify the Service Providers

End User requests temporary

mobile service suspension

End User requests line restore

before or at earlier agreed date

Transfer entitlements and

applicative lock of service on SP

information system

Notify MNO

Notify MNO

Unlock service on SP information

system


2.3.5.10 Process 17 – End user calls the Service Provider’s customer service

The end user contacts his Service Provider’s customer care. A first level of diagnostic is performed to identify if the issue is related to the Service Provider. If it is confirmed that the Service Provider is responsible, the analysis is launched by the Service Provider.

If the problem does not come from the Service Provider, the end user is invited to call the Mobile Network Operator, unless he already did it.

During the detailed analysis, once the Service Provider solves the issue, he informs the end user. If the issue appears to be related to Mobile Network Operator, the Service Providers creates a “NFC customer care file” stating that he is responsible for informing the customer, and he sends this information to the Mobile Network Operator. Then the MNO launches the analysis and notifies the Service Operator once the problem is solved, who will finally inform the customer.

[Note] The “NFC customer care file” is used in case both Mobile Network Operator and Service Provider customer services are involved to solve the problem faced by the end user.

[Note] One AFSCM functional principle is that the entity who was contacted by the end user is in charge of informing the end user at the end of the process.


The information exchanged for customer service purpose (NFC customer file) is handled by employees and not on the IT interface described in this document.

Ste

p 4

: U

se

mo

bile

NF

C s

erv

ice

Process N°17 – End user calls the Service Provider’s customer service


Yes

No

Yes

No

Yes. Send a NFC

Customer Care file

No

Yes

No

YesInitiate customer care

process

Initiate customer care process

End user already

called MNO?

End Inform Service Provider

that the issue is solved

Issue solved?

Contact MNO

Inform end-user

Analyse the issue

Issue related to Service

Provider?

Issue related

to MNO?

End user contacts Service

Provider

Issue solved by Service

Provider?

No


2.3.5.11 Process 18 - End user calls the Mobile Network Operator’s customer service

The end user contacts his Mobile Network Operator’s customer care. A first level of diagnostic is performed to identify if the issue is related to MNO. If it is confirmed that the Mobile Network Operator is responsible, the analysis is launched by the MNO. If the problem does not come from the Mobile Network Operator, the end user is invited to call the Service Provider, unless he already did it.

During the detailed analysis, once the Mobile Network Operator solves the issue, he informs the end user. If the issue appears to be related to Service Provider, the MNO creates a “NFC customer care file” stating that he is responsible for informing the customer, and he sends this information to the Service Provider. Then the Service Provider launches the analysis and notifies the Mobile Network Operator once the problem is solved, who will finally inform the customer.

[Note] The “NFC customer care file” is used in case both Mobile Network Operator and Service Provider customer services are involved to solve the problem faced by the end user.


The information exchanged for customer service purpose (NFC customer file) is handled by employees and not on the IT interface described in this document.

Ste

p 4

: U

se

mo

bile

NF

C s

erv

ice

Process N°18 – End user calls the MNO’s customer service


Yes

No

Yes

No

Yes

Open a NFC

customer care file

No

Yes

No

No

Yes

Analyse the issue

Analyse the issue

Issue solved

Inform End user

Issue

Related to Service

Provider ?

End user already

called Service

Provider?

Issue related to MNO?

Initiate customer care process

End

Contact Service Provider

Inform MNO that the issue

is solved

Issue solved by MNO?

End user contacts MNO


2.3.6 Step 5 – Termination of mobile NFC service

The step 5, Termination of mobile NFC Service, covers three processes:

- Termination of mobile subscription or NFC option by end user (Process 14)

- Termination of mobile service by Mobile Network Operator (Process 15)

- Mobile NFC service termination (Process 19)

2.3.6.1 Process 14 – Termination by end user of Mobile subscription or NFC option

The end user wants to terminate his mobile subscription or the NFC option. The Mobile Network Operators agrees with him on the termination date and informs the End user that he should either use the possible remaining entitlements in his mobile or contact his Service Providers for transferring his entitlements to another support.

At termination date, the Mobile Network Operator definitely stops the mobile service or the NFC option and notifies the Service Providers.

Upon reception of this notification, the Service Provider can organize the transfer of entitlements available in the current UICC. Once this transfer is done and within a limited period of time agreed between the Service Provider and the MNO, the Service Provider makes an applicative lock of the service on its IT system and notifies the MNO with the locking confirmation.

[Note] The end user is responsible for destroying his UICC in case of mobile service termination.

[Note] A lead time of minimum 10 days between customer request and termination date is proposed in case he changes his mind.


“Pre” notification to inform Service Providers before Mobile subscription or NFC option termination is not available in version 1.

Ste

p 5

: T

erm

ina

tio

n

Process N°14 – Termination of Mobile line subscription OR NFC option by end user

End user Mobile Network OperatorService Provider

Inform End user that he should either use

the remaining rights in his mobile or

contact his Service Provider’s for

transferring his rights to another support

At termination date, definitely stop mobile

service or NFC option

Notify Service Provider about line or

NFC option termination

Acknowleldege request for termination

And agree with end user on termination

date

End user is responsible for

destroying his UICC in case of

mobile service termination

End user wants termination of

its mobile subscription or NFC

option

[Note] Proposition for a reflexion time

of minimum 10 days between

customer request and termination date

Reflexion time

At termination date

Transfer end user’s

entitlements

Applicative lock of service on

SP Information System

Notify MNO about lock

status


2.3.6.2 Process 15 - Termination of mobile service by Mobile Network Operator

When the end user does not respect the access conditions to the NFC offer, the Mobile Network Operator is entitled to initiate a dispute process. The Mobile Network Operator informs the End user about the risk of such a situation and communicates the scheduled date for the line suspension.

If the end user settles the situation, no other action is done.

If the end user does not settle the situation, the Mobile Network Operator suspends the end user’s line and notifies the Services Providers about the line suspension.

If the end user settles the situation at that point, the Mobile Network Operator will restore the line and notify the Service Providers.

Otherwise, the Mobile Network Operator definitely stops the end user’s line and the access to Mobile NFC services and notifies the Service Providers about the end of mobile service

Upon reception of this notification, the Service Provider can organize the transfer of entitlements that were available in the current UICC. Once this transfer is done, and within a limited period of time agreed between the Service Provider and the MNO, the Service Provider makes an applicative lock of the service on its IT system and notifies the MNO with the locking confirmation. The Service Provider might do this action earlier, upon reception of the notification for line suspension.

[Note] End user is responsible for destroying his UICC in case of mobile service termination.

[Note] A line which is suspended can be restored, whereas line termination or stopping is irreversible.


“Pre” notification to inform Service Providers before Mobile service suspension or termination is not available in version 1.

For the first phases, it is not possible to manage the intermediate status of the line “restricted”.


Ste

p 5

: T

erm

ina

tio

n

Process n°15 – Termination of mobile service by MNO

Su

sp

en

sio

n

End user Service Provider Mobile Network Operator

No

Yes

No

Yes

Notify Service Providers about

end of mobile service,

Initiate the dispute process

Initiate process for mobile service suspension

and notify again the end user

Suspend End user’s line and notify Service

Provider about line suspension

Initiate process for End user’s mobile

service termination

End user settles the

situation

Definitly stop End user’s line access to

mobile NFC services

End user is responsible for

destroying his UICC in case of

mobile service termination

End

Notify End user about related risks and inform

about suspension date of mobile service

End user settles the

situation

Restore the line and

Notify Service providers

End user doesn’t respect the

MNO’s contract conditions

Transfer entitlements and

applicative lock on SP

information system

Notify MNO about locking


2.3.6.3 Process 19 – Mobile NFC service termination

Two reasons can lead to the mobile NFC service termination:

- Upon end user’s request who wants to suppress the application from his mobile handset or to terminate the mobile NFC service,

- Or from the Service Provider who wants to terminate the mobile NFC service for this end user.

Once the Service Provider launches the termination process, he requests the Mobile Network Operator for deleting the service on the UICC. The MNO communicates to the service provider the application deletion status. At this stage the Service Provider must stop the mobile NFC service for this end user on its information system, and finally inform the end user about the end of the mobile NFC service.

Ste

p 5

: T

erm

ina

tio

n

Process n°19 – Termination of mobile NFC service / Process n°19

Mobile Network OperatorEnd user Service Provider

Inform End user about end of

mobile NFC service

End of mobile NFC service on Information

System

Launch process for mobile NFC service

termination and notify MNO to delete

application

Application deletion (and SSD if

relevant)

Inform about deletion status Service

Provider

Service Provider terminates the End user’s

mobile NFC service

End user wants to suppress

mobile NFC service from his

mobile


3 INTERFACE SPECIFICATION

3.1 Introduction

The current specification focuses on one core interface between the Service Provider (and possibly his subcontracting company acting as Secure Service Manager) and the Mobile Network Operator. All the requests related to the management of the mobile NFC services are handled on this interface.

This interface processes the following types of requests:

- Request for eligibility of the end user for mobile NFC service,

- Requests and responses related to the installation, activation and deletion of the Mobile NFC service application,

- Notifications between Service Provider and Mobile Network Operator related to the life cycle of the UICC, mobile handset, mobile NFC service application, mobile subscription …

Requests are always issued by the Service Provider and responses are generated by the MNO. Some notifications are sent by the Service Provider to the MNO, and some notifications are sent by the MNO to the Service Providers.

SERVICE PROVIDER DOMAIN

MOBILE OPERATOR DOMAIN

Network Access

SERVICE PROVIDER / MOBILE OPERATOR

INTERFACE

Figure 3 - Overview of architecture

All the actions that require remote access to the UICC or the mobile handset are not handled on this interface and therefore not described in this document:

- Sending OTA GlobalPlatform commands to the UICC (for installation, activation, personalisation, deletion …),

- Loading of the MMI on the mobile handset,

- Sending applicative commands via the MMI.


3.2 Interface Connection and Exchange Protocol

The entire content of this paragraph must be implemented by Service Providers.

3.2.1 Protocol

The requests, responses and notifications are exchanged on web services with XML on http. The AFSCM provides the description file (WSDL) for each request, response and notification.

Reference documents: SOAP document 1.2 and WSDL 2.0.

3.2.2 Interface

Service Provider and Mobile Network Operator need to establish a point to point VPN connection. One VPN is established between each MNO and Service Provider or SSD Manager.

This process will be detailed in a dedicated AFSCM document.

3.2.3 Synchronous and Asynchronous

The requests that do not need any remote access to the UICC or mobile handset are synchronous request as well as the notifications whereas the other requests/responses exchanged on this interface are asynchronous.

The asynchronous treatment requires sending a transaction unique identifier (REQUEST_ID). The transaction identifier is generated by the party sending the request. The same transaction identifier is sent in the response to the request. This ensures a simple traceability of the requests and can be used in the retry management. The transaction identifier (REQUEST_ID) is composed of three data and two separators:

- SERV_ID– numeric up to 5 digits

- Timestamp in milliseconds- – numeric on 19 digits

- Additional diversifier – numeric on 2 digits

Value example: 14560:223372036854:21

Service Provider Mobile Operator

CREATE_SSD_REQ (abc)

CREATE_SSD_RESP (abc)

ACKNOWLEDGE

ACKNOWLEDGE

Generate a request and a

unique transaction identifier

Receives the request

Acknowledge the reception of the request

Perfoms the actions for SSD creation

Send response with the transaction identifier

Receives acknowledgement

Receives response

Acknowledge the reception of

responseReceives acknowledgement

NOTIF_CALL_ENDUSER

ACKNOWLEDGE

Sends a notification after end user

call to declare mobile phone lost

[…]

Figure 4 – Example of detailed exchanges

The asynchronous REQUESTS and RESPONSES as well as NOTIFICATION sent by one party require the other party to send a synchronous acknowledgement.

In case format error or data error is identified on a request, the synchronous acknowledgement contains an error code and the complementary information (COMPL_RESP). The asynchronous response to the request is not sent.


In case format error or data error is identified on a notification, the same synchronous acknowledgement is sent, containing an error code and the complementary information. Thus, the Service Provider is aware that this notification was not taken into account.

The synchronous requests (ID_TECH_REQ, LONG_AID_REQ and TOKEN_REQ) do not require acknowledgment, but instead expects directly the RESPONSE. The exchange of request and response is presented below.


ID_TECH_REQ

ID_TECH_RESP

Request an ID_TECH Receives the request

Generates the ID_TECH

Send response with the ID_TECHReceives response

Figure 5 – Example of synchronous request

3.2.4 Presentation of the exchanges

To simplify the representation of the exchanges in the diagrams of chapter 3.3, the acknowledgments will not be explicitly represented in the diagrams. Thus, the process described in details in Figure 4 – Example of detailed exchanges will look as described below in a simplified manner. In other word, asynchronous or synchronous exchanges look similar. But the feature synchronous or asynchronous is mentioned in the description of each request or notification.


CREATE_SSD_REQ

CREATE_SSD_RESP

NOTIF_CALL_ENDUSER

Figure 6 - Simplified representation used in flow charts

3.2.5 Elementary requests

Each request, response or notification concerns one single end user (ID_TECH) and are said to be “elementary”. When a Service Provider estimates relevant to process some requests in a batch of n requests, it will send n elementary requests consecutively.

3.2.6 Retry management

Each party must be able to reissue all the requests for which it does not receive an acknowledgment.

In case a party does not send acknowledgment, the other party uses the HEART_BEAT query as described in 3.2.8.

The implementation of retry mechanism must take into account two points:

- Limitation to N retry cycles. After that limit, the absence of answer can be considered as an incident and the receiving party technical teams must be alerted.

- Progressive increment of time between two cycles.

The GP errors are managed by Mobile Network Operator and may not be communicated to the Service Provider.

In case of connection disruption betweens platforms, the Mobile Network Operator or the Service Provider shall use the Heart Beat mechanism (see 3.2.8)


For more details about the retries policy depending on the type of errors, see at Error Response Code management

3.2.7 Load control

It is required to apply flow control mechanisms in order to avoid overload situations. MNO establishes load limitation criteria related to:

1. Instantaneous load: Limitation of number of simultaneous requests to the MNO platform. This is a server based control.

In case of overload, http error responses will be received as an answer to the SP requests.

2. Global load: limitation of number of on going treatments via a buffer size limitation for each Service Provider.

In case of overload, an error code is sent in the response without any other parameters.

In case of overload for synchronous request, an error code is sent in the response without any other parameters.

This implies that the Service Provider platforms must control the number of simultaneous and on going requests and, in case of reception of an overload error code, stop sending new requests until receiving a positive acknowledgement or response to the previous request.

The reception of an overload error code in the acknowledgement means that the request has not been stored and the Service Provider needs to send it again to the Mobile Network Operator once the overload is solved.

The MNO will apply flow control mechanisms on outgoing notifications in order to avoid overload situations on the Service Provider server.

The values for the maximum acceptable instantaneous load and global load are to be exchanged during the provisioning phase between each MNO and Service Provider.

3.2.8 HEART_BEAT

The HEART_BEAT service is used to know or update the status of the Service Provider or MNO server.

In case (1) , when a Service Provider is declared as unavailable during flow (acknowledgment other than HTTP 200), the MNO uses the HEART_BEAT query to know if it is newly available or not. As long as the retry cycle is not finished, the MNO continues the HEART_BEAT query. Once the HEART_BEAT answer is” OK”, the MNO considers that the Service Provider server is available again and sends all the stored requests that were dedicated to this MNO.

In case (2), the Service Provider uses the same query HEART_BEAT when the MNO server does not answer to the HTTP request.

In case 1 the Service Provider (case 1) and in case 2 the MNO replies.

[Note] This is a http request and not a webservice. It is therefore not described in the WSDL.


3.3 Processes supporting customer journey

This chapter presents the process of exchanging requests and responses between the IT systems of the Service Provider and the Mobile Network Operator in the implementation of the customer journey described in chapter 2.3. Even though this specification focuses on the interface between the Service Provider and the Mobile Network Operator, the actions between the information systems on one hand and either the UICC or the handset on the other hand are also presented for information purpose to describe the customer path from end to end.

The legend used in the diagrams is presented below:

Optional or conditional stepOptional Process


Action on Mobile Operator

information system

Synchronous REQUEST

or NOTIFICATION

Action on Service Provider

information system

Synchronous RESPONSE

OTA action of Mobile Operator

OTA action of Service Provider

Or reference to an entire process

UICC

Asynchonous REQUEST

Asynchonous RESPONSE

Figure 7 - Legend of flow charts

Some parameters can be presented, mostly for notifications, to illustrate the use of a notification in a process.

3.3.1 Process 1 – Inquiry to the Service Provider

This step does not require any exchange between the Mobile Network Operator and the Service Provider.

3.3.2 Process 2 – Inquiry to the Mobile Network Operator

This step does not require any exchange between the Mobile Network Operator and the Service Provider.


3.3.3 Process 3 - Subscription to a mobile NFC Service

When end user requests for a mobile NFC service, the Service Provider sends the eligibility request (ID_TECH_REQ) to the Mobile Network Operator that responds, if positive, with the ID_TECH for this end user.

This flow is applicable for the three different channels available for subscription to a mobile NFC service at the Service Provider's local office or from its web site of via a WAP session from the mobile handset and is also applicable for the update of NFC application.

ID_TECH Generation


ID_TECH_REQ

ID_TECH_RESP

Figure 8 - Process 3 Subscription

3.3.4 Process 4 – Installation of mobile NFC service

The installation process is a succession of several requests on the Service Provider / Mobile Network Operator interface.

The first one is the request SSD_CREATION_REQ for SSD creation, or at least for the attribution of a SSD to the Service Provider. Upon reception of this request, the Mobile Network Operator might have to create OTA the SSD on the UICC, unless it was done in factory. Regarding the key set for securing the access to the SSD, either they were previously exchanged between authorised parties during the provisioning phase, or the MNO sends a key set in the response. The Service Provider is responsible for replacing this key set to his own key set if he estimates necessary.

This request is conditional. It is mandatory for each of the following condition:

- The SSD needs to be created OTA,

- The Service Provider needs to receive the SSD key set.

The next step is the request for long AID (LONG_AID_REQ). This step is an option only applicable for banking applications. For these applications, the same short AID is used by several banks (CB AID, MasterCard AID, VISA AID …). Therefore, the MNO is requested to generate a long AID unique for each combination of bank and short AID.

[Note] For short term implementation, long AID values will be allocated statically for each banking service. Thus, there will be no need in this case to use the LONG_AID_REQ.

For the next steps, the Service Provider uses the same request INSTALL_REQ with the appropriate value of parameter INSTALL_STEP.

- The Service Provider requests for loading the application package on the UICC (INSTALL_REQ for LOAD). The Mobile Network Operator loads the package(s) associated to the requested service, unless it was pre loaded in factory in this UICC.

This request is conditional. It is mandatory if some of the package(s) associated to the NFC service was not previously loaded in factory.

- Once the Service Provider receives confirmation that the package is available in the UICC, it requests for its installation (INSTALL_REQ for INSTALL), that is the creation of an instance and its extradition to the Service Provider’s SSD. Due to Simple SD management, the Mobile Network Operator realises theses steps.

This request is conditional. It is mandatory if the application was not previously installed in factory.

- Then the Service Provider does the personalisation of the application.


- After this step, the Service Provider requests for the activation of the application (INSTALL_REQ for ACTIVATE). The Mobile Network Operator activates the application(s).

[Note] The requests INSTALL_REQ with step LOAD and step INSTALL are optional as it can be done in factory in the full preloaded and partial OTA scenario.

[Note] In simple SD, when the package needs to be loaded OTA, it is mandatory to have the application certified package and related installation parameters available on Mobile Network Operator’s platform before submitting requests for loading the package.

Once the UICC application is installed, the Service Provider installs the MMI – Process 5.


Only the Simple SD management is considered in version 1. Yet the detailed requests exchange for UICC application installation in Delegated Management is provided in appendix. This information is already presented in the interface specification in order to be able to anticipate on the functionalities that will be necessary for Delegated Management

SSD Creation

SSD_CREATION_REQ

SSD_CREATION_RESP

Long AID Generation

Mobile Operator

LONG_AID_REQ

LONG_AID_RESP

INSTALL_REQ

(LOAD)

INSTALL_RESP

INSTALL_REQ

(INSTALL)

INSTALL_RESP

Service Provider UICC

Application Personalization

INSTALL_REQ

(ACTIVATE)

INSTALL_RESP

Application Instance Creation and

Extradition

Package Loading

SSD Creation

SSD Key Replacement

Option: package can be

preloaded on UICC

Option: for banking application

Option: If SSD not already

available on UICC

Option: instance can be

pre loaded on UICC

Option: personalisation

can be done in factory

Application

package loading

Application installation

Application

personalisation and

activation

Option: can be done in factory

Option: upon SP decision

Option: can be done in factory

and attributed in advance

Application Activation

Figure 9 - Process 4 Installation of UICC application in Simple SD


3.3.5 Process 4 Update – UICC application update

This process for OTA update is optional upon Service Provider’s decision. If not implemented it means that the application deployed in the UICC cannot be updated OTA. When implemented, all the requests mentioned are mandatory.

The Service Provider needs to update the UICC application of its mobile NFC service.

The Service Provider first requests for the deletion of the service on the UICC and then sends a request for eligibility ID_TECH_REQ for this ID_TECH so that the MNO can check that there is enough memory space for the new application.

After the positive response of the MNO, the Service Provider initiates the installation process, similar to the one described in previous paragraph, except that all the requests must be implemented to perform the actions OTA.

Mobile OperatorService Provider UICC

SUPPRESS_RESP

Delete application instance and

package if possible

SUPPRESS_REQ

(Application and instance)

ID_TECH_REQ

ID_TECH_RESP

Request for

eligibility

Suppress previous

UICC application

Keep same ID_TECH, check

memory space available

INSTALL_REQ

(LOAD)

INSTALL_RESP

INSTALL_REQ

(INSTALL)

INSTALL_RESP

Application Personalization

INSTALL_REQ

(ACTIVATE)

INSTALL_RESP

Application activation

Application Instance Creation and

Extradition

Package LoadingApplication

package loading

Application installation

Application

personalisation and

activation

Figure 10 - UICC application update


3.3.6 Process 5 – Service Provider MMI installation / Update

This process is conditional. It is mandatory when a MMI is necessary for the mobile NFC service.

Two possibilities are proposed to the Service Provider to initiate the process for MMI loading or update:

- Case 1: Upon Service Provider request, the MNO launches the MMI installation or update. This case is mandatory if MMI is used.

- Case 2: the Service Provider launches the MMI installation or update. This case is an option.

In both cases, the assumption is that the MMI server is under the Service Provider’s responsibility.

Case 1

Once the UICC application installation is successfully completed, the Service Provider sends a request to the MNO for launching the MMI installation INSTALL_MMI_REQ.

Option i: local mechanism for MMI download

The Service Provider sends the parameter set to “MMI with retries” and the version of the MMI to be loaded. In this case, the MNO manages the entire installation. The MNO informs the Service Provider once the ACF and the MMI are effectively loaded in the mobile handset with INSTALL_MMI_RESP. In case of connection interruption during the MMI loading, the MNO manages the retries.

Figure 11 - Process 5 MMI installation managed by MNO

Option ii

The Service Provider sends the parameter set to “MMI only” and optionally the version of the MMI to be loaded. The MNO answers INSTALL_MMI_RESP once the ACF is loaded and a SMS push WAP is sent to the mobile handset to establish a connection with the MMI server.

In parallel, the MMI is downloaded from the Service Provider’s MMI server.

The Service Provider receives the confirmation of MMI download from its MMI server and/or from the MMI code. The Service Provider needs to manage retries in case of connection interruption by sending a new request INSTALL_MMI_REQ with parameter set to “MMI only” to the MNO for initiating the MMI download.

Once the MMI is installed on the mobile handset, the Service Provider notifies the MNO (NOTIF_SP_ACTION).

[Note] The MNO is responsible for loading the ACF in the UICC. It must be loaded prior to the MMI download on the mobile handset.


Figure 12 - Process 5 MMI installation launched by MNO

Case 2

In Case 2, the use of the request INSTALL_MMI_REQ is optional, it is only necessary if the MNO uses ACFs.

Once the UICC application is successfully installed,

- If the MNO uses ACF, the Service Provider sends to the MNO a request for the MMI installation INSTALL_MMI_REQ with the parameter set to “ACF only”. When the ACF is loaded, the MNO informs the Service Provider with INSTALL_MMI_RESP. Then, the Service Provider can load the MMI on the mobile handset and notifies the MNO once it is done with NOTIF_SP_ACTION along with the parameters “Download MMI OK” (or failed) and the version of the MMI loaded.

- If ACF is not necessary, the Service Provider invites the end user to load the MMI on the mobile handset with a SMS push WAP and notifies the MNO once it is done with NOTIF_SP_ACTION and the parameters set to “Download MMI OK” (or failed). In this case the request INSTALL_MMI_REQ is not necessary.

NOTIF_SP_ACTION

(Download MMI OK, MMI version)

Service Provider Mobile OperatorMobile

handset

INSTALL_MMI_REQ

(ACF)

ACF loading in UICC

INSTALL_MMI_RESP

Option:

if ACF is used

SMS push WAP

MMI installation

Figure 13 - Process 5 MMI Installation launched by Service Provider


Requirement on the Service Provider Information System

The MMI is specific for each mobile handset. Therefore the Service Provider must manage a database with all the MMIs for each available NFC mobile handset. During the MMI installation process, the Service Provider or the MNO retrieves the type of mobile handset (http user agent) in the http request in order to identify the type of mobile handset and select the appropriate MMI to be downloaded.

In both cases 1 and 2 (MNO initiates the MMI download or SP directly performs the MMI download), the Service Provider is responsible for managing the MMI database.

MMI update

When the Service Provider needs to update the MMI on the end user’s mobile handset, the two processes described above (case 1 and case 2) also apply.

In the update context, the Service Provider is responsible for explicitly requesting for the update of the ACF when it is necessary (for instance in case a new version is provisioned on the MNO platform). The MNO always loads the most recent certificate available.

Critical Update

In case the Service Provider estimates that it is urgent and mandatory, ie “critical”, to update the MMI for using the mobile NFC service, the Service Provider might decide to lock the service until the MMI update is effective. The Service Provider is responsible for such a decision and must notify the MNO using NOTIF_SP_ACTION:

- when the service is locked - with parameter ACTION_STATUS set to “Application locked”,

- when the MMI is loaded - with parameter ACTION_STATUS set to “Download MMI OK”,

- when the service is unlocked - with parameter ACTION_STATUS set to “Application unlocked”

NOTIF_SP_ACTION

(Application locked)

Service Provider Mobile OperatorUICC

Mobile handset

Lock UICC application

MMI Installation

Case 1 or Case 2

Unlock UICC application

NOTIF_SP_ACTION

(Application unlocked)

Figure 14 - Critical MMI update


3.3.7 Process 6 – Change UICC

The Mobile Network Operator deactivates the old UICC and activates a new UICC for the end user. Then he informs the Service Provider about this change of UICC with the notification NOTIF_NEW_DEVICE and the parameter set to “UICC”. The Service Provider will then have to go through the process 4 for installing the Mobile NFC application on the new UICC.

[Note] In case of banking application, the MNO must ensure that the same long AID as on previous UICC can be used. It is therefore not necessary to request again for the long AID.

Service Provider Mobile Operator UICC

Old UICC deactivation

New UICC activation

Process 4 - Install the mobile NFC service

NOTIF_NEW_DEVICE

(UICC)

Figure 15 - Process 6 Change UICC

3.3.8 Process 7 – Change mobile phone number

When the Mobile Network Operator needs to change the end user’s mobile phone number, he generates a new ID_TECH and sends a notification with both old ID_TECH and new ID_TECH to the Service Provider (NOTIF_CHANGE_ID_TECH).


NOTIF_CHANGE_ID_TECH NEW ID_TECH generation

Figure 16 - Process 7 Change mobile phone number

3.3.9 Process 8 – Change mobile handset

Once the Mobile Network Operator detects that the end user has changed his mobile handset, he can send a notification to the Service Provider NOTIF_NEW_DEVICE with the parameter set to “MOBILE” as it will be necessary to download the MMI on this new mobile.


NOTIF_NEW_DEVICE

(Mobile)

Process 5 - Install the MMI application

Figure 17 - Process 8 Change mobile handset


3.3.10 Process 9 – Lost or stolen mobile equipment, end user contacts Mobile Network Operator

When the Mobile Network Operators receives a call for lost or stolen mobile handset, he launches in parallel the following tasks:

- Notification to the Service Provider (NOTIF_CALL_ENDUSER_TO_SP) with information on the context (Loss or theft),

- And the attempt to lock the service before line suspension. After which he informs the Service Provider about the new status of the application and the line (NOTIF_CHANGE_TO_SP).

- If the application is still unlocked, upon reception of NOTIF_CHANGE_TO_SP, the Service Provider makes an applicative lock of the mobile NFC service on its information system.

Mobile Operator UICCService Provider

NOTIF_CHANGE_TO_SP

(App locked and Line suspended)

NOTIF_CALL_ENDUSER_TO_SP

(Loss or Theft)

MNO tries to lock application via OTA

AND suspends phone line

Applicative lock on IT

system if OTA lock failed Figure 18 - Process 9 Lost or stolen mobile equipment, end user contacts MNO

3.3.11 Process 10 – Lost or stolen mobile equipment, end user contacts Service Provider

When the Service Provider receives a call for lost or stolen mobile equipment, he notifies to the Mobile Network Operator (NOTIF_CALL_ENDUSER_TO_MNO) with information on the context (Loss or theft). Then the Service Provider attempts to lock OTA the service. If the OTA lock fails, the Service Provider makes an applicative lock of the mobile NFC service on its IT system. Then it informs the Mobile Network Operator about the new status of the application (NOTIF_SP_ACTION).

Mobile Operator UICCService Provider

NOTIF_CALL_ENDUSER_TO_MNO

(Loss or Theft)

Service Provider attemps to lock application via OTA

NOTIF_SP_ACTION

(Application locked)

Applicative lock on IT

system if OTA lock failed

Figure 19 - Process 10 Lost or stolen mobile equipment, end user contacts SP

3.3.12 Process 11 – Recover mobile equipment after a loss

When the end user recovers his mobile equipment after a loss (or theft), the Mobile Network Operator restores the end user’s line and inform the Service Providers (NOTIF_CHANGE_TO_SP) with the parameter Line Activated. Then, the next steps depend on the context:

- If the service was blacklisted, the Service Provider first requests for the deletion of the existing service and then needs to reinstall the application on the UICC, but not the MMI, as described in Process 4,

- If the Service was locked OTA by the Service Provider, the Service Provider unlocks the service and informs the Mobile Network Operator NOTIF_SP_ACTION with the appropriate parameter “Application unlocked”.

Each solution is optional, but the Service Provider must implement one of them.


Figure 20 - Process 11 Recover mobile equipment after a loss

3.3.13 Process 12 – Get new mobile equipment after a loss or theft

When the end user gets a new mobile handset and UICC after a loss or theft, the Mobile Network Operator reactivates the end user’s line and notifies the Service Providers with NOTIF_NEW_DEVICE and the parameter set to UICC+mobile handset.

Then the Service Provider initiates the UICC installation process (Process 4) and continues with the MMI installation process (Process 5).


Process 4 – Mobile NFC application Installation

Reactivation of the end user’s lineNOTIF_NEW_DEVICE

(UICC+Mobile phone) Provide new UICC and new mobile

phone to end user

Process 5 – MMI Installation

Figure 21 - Process 12 Get new mobile equipment after a loss or theft

3.3.14 Process 13 – End user swaps Mobile Network Operator


The portability of mobile NFC services is out of scope for the first phase of NFC deployment and is therefore not described in the current document.

3.3.15 Process 14 – Termination by end user of Mobile subscription or NFC option

At termination date, the Mobile Network Operator effectively terminates the end user’s line or NFC option. The MNO sends a notification to the Service Providers (NOTIF_CHANGE_TO_SP) to inform them about line or NFC option status.

Upon reception of this notification, the Service Provider can organize the transfer of entitlements available in the current UICC. Once this transfer is done and within a limited period of time agreed between the Service Provider and the MNO, the Service Provider makes an applicative lock of the service on its IT system and notifies the MNO (NOTIF_SP_ACTION) with the locking confirmation.



NOTIF_CHANGE_TO_SP

(Line or NFC option terminated)

Terminate line or NFC option

Transfer entitlements

Applicative lock of the service

on SP Information System NOTIF_SP_ACTION

(Locked on IT system)

Figure 22 - Process 14 Termination by end user of Mobile subscription or NFC option

3.3.16 Process 15 – Termination of mobile service by Mobile Network Operator

At suspension date, the Mobile Network Operator effectively suspends the end user’s line notifies the Service Providers about the line suspension (NOTIF_CHANGE_TO_SP).

In the mean time, if the end user regulates the situation, the Mobile Network Operator restores the line and notifies the Service Providers (NOTIF_CHANGE_TO_SP).

Otherwise, at termination date the Mobile Network Operator definitely stops the end user’s line and notifies the Service Providers about the line termination (NOTIF_CHANGE_TO_SP).

Upon reception of this notification, the Service Provider can organize the transfer of entitlements available in the current UICC. Once this transfer is done, and within a limited period of time agreed between the Service Provider and the MNO, the Service Provider makes an applicative lock of the service on its IT system and notifies the MNO with the locking confirmation (NOTIF_SP_ACTION).


At suspension date

Suspend end user’s lineNOTIF_CHANGE_TO_SP

(Line suspended)

Inform end user about suspension

date

NOTIF_CHANGE_TO_SP

(Line activated)

Restore end user’s line

NOTIF_CHANGE_TO_SP

(Line Terminated)

Option: If end user

regulates situation

RE

GU

LA

TIO

N

At termination date

Definitely stop end user’s line



on SP Information System NOTIF_SP_ACTION


Figure 23 - Process 15 Termination of mobile service by MNO

3.3.17 Process 16 – Suspension of mobile service upon end user’s request

At suspension date agreed with the end user, the Mobile Network Operators suspends the end user’s line and sends a notification to the Service Providers to inform them about the line suspension (NOTIF_CHANGE_TO_SP).

Upon reception of the line suspension notification, the Service Provider can organize the transfer of entitlements available in the current UICC. Once this transfer is done, and within a limited period of time agreed between the Service Provider and the MNO, the Service Provider makes an applicative lock of the service on its IT system and notifies the MNO with the locking confirmation (NOTIF_SP_ACTION).


At restore date, the Mobile Network Operator restores the end user’s line and sends a notification to the Service Providers (NOTIF_CHANGE_TO_SP).

The Service Provider unlocks the mobile NFC service on its information system and notifies the MNO to confirm that the service is ready again for use.


NOTIF_CHANGE_TO_SP

(Line suspended)

At suspension date agreed with end user

At restore date agreed with end userNOTIF_CHANGE_TO_SP

(Line restored) Restore end user’s line

Suspend end user’s line



on SP Information SystemNOTIF_SP_ACTION


Applicative unlock of the service on

SP Information System NOTIF_SP_ACTION

(Unlocked on IT system)

Figure 24 - Suspension of mobile service upon end user’s request

3.3.18 Process 17 – End user calls the Service Provider’s customer service

The information exchanged for customer service purpose (NFC customer file) is not handled on the interface described in this document.

3.3.19 Process 18 – End user calls the Mobile Network Operator’s customer service

The information exchanged for customer service purpose (NFC customer file) is not handled on the interface described in this document.

3.3.20 Process 19 – Termination of mobile NFC service

In Simple SD, the Service Provider simply requests the deletion of his service identified by the SERV_ID in the request SUPPRESS_REQ and the Mobile Network Operator performs OTA the deletion in the following order:

- Instance and associated ACF file

- package if possible (no remaining instance linked to it)

- SSD if possible (empty)

The response code is OK if at least instance and ACF file are deleted.


SUPPRESS_RESP

Delete application instance, SSD, ACF if relevant

and package if possible

SUPPRESS_REQ

(ID_SERV)

Figure 25 - Process 19 Termination of mobile NFC service


3.4 Detailed Commands Description

Naming convention

Request NAME_OF_REQUEST_REQ

Response NAME_OF_RESPONSE_RESP

Notification NOTIF_NAME_OF_NOTIFICATION

The mandatory, optional or conditional characteristic of each request is reminded with the appropriate pictogram in the left margin of its description paragraph. It is also summarised in the table in appendix A1.2 List of requests, responses and notifications.

3.4.1 HEADER

HEADER_1 – Header for Synchronous Requests

This header is applicable to synchronous requests (ID_TECH_REQ, LONG_AID_REQ, TOKEN_REQ and notifications).

Name Description Type

SERV_ID Mobile NFC Service Identifier Mandatory

SERV_VERSION Mobile NFC Service version Optional (1)

ID_MNO MNO Identifier Mandatory

ID_TECH Technical Identifier of the line Mandatory

SSDM_ID SSD Manager Identifier Optional (RFU)

PRIORITY_INDEX Index of priority. Default value set to 0 Mandatory

1. If SERV_VERSION not communicated, by default the latest version available is used

[Note] The priority index is a mandatory field but is not used in the first implementations. Default value is set to “0”.

[Note] For the optional item, it is the choice of the Service Provider to communicate these data in the request header. There is no functional impact.

HEADER_2 – Header for Asynchronous Requests

This header is applicable to asynchronous requests. It requires a transaction identifier.


REQUEST_ID Transaction identifier (unique) Mandatory

SERV_ID Service Identifier Mandatory



ID_TECH Technical Identifier of the line Mandatory






HEADER_3 – Header for ID_TECH_REQ

This header is applicable to the ID_TECH_REQ synchronous request.


SERV_ID Mobile NFC Service Identifier Mandatory







[Note] For the optional item, it is the choice of the Service Provider to communicate these data in the request header. There is no functional impact.

3.4.2 MNO_ACKNOWLEDGE

The acknowledgments are synchronous responses.

The Mobile Network Operator sends an acknowledgement MNO_ACKNOWLEDGE as a synchronous answer to each asynchronous request or notification received from the Service Provider.

By default, the only data in the acknowledgement is a STATUS set to 00 when everything “looks” OK on the server that receives the request or the notification.

In case a format or data error is detected on the server, it sends the STATUS set to 100 and the complementary information (COMPL_RESP) to inform what data is identified as incorrect (format, value, presence). In case such an error is identified on a request, the associated response is not sent, as the acknowledgement communicates all the relevant information.

When the provisioning of a service is not completed on the MNO platform (package not certified for instance), the error type 03 is returned.

FUNCTION MNO_ACKNOWLEDGE

MNO SP Exchange Mode : Synchronous

Name Description Presence

SYNCH_STATUS Set to 0 to confirm that the synchronous controls are OK. Mandatory

In case a format or data error is detected on the server, the server sends an exception acknowledgement (EXCEPTION) to indicate what type of error is detected and optionally on which data.

[Note] When an EXCEPTION is thrown, the response associated to the original request is not sent.

3.4.3 SP_ACKNOWLEDGE

The Service Provider sends an acknowledgement as a synchronous answer to each asynchronous response or notification received from the MNO.

FUNCTION SP_ACKNOWLEDGE

SP MNO Exchange Mode : Synchronous



SYNCH_STATUS Set to 0 to confirm that the synchronous controls are OK. Mandatory

In case a format or data error is detected on the Service Provider's server, the server throws an EXCEPTION to indicate what type of error is detected and optionally on which data.


3.4.4 EXCEPTION

The EXCEPTION is a synchronous response used in case a format or data error is detected on the server receiving a request. It contains information about the type of error detected and optionally which data failed.

An EXCEPTION can be thrown by the MNO and by the Service Provider.

The EXCEPTION is used in case a control fails upon reception of a synchronous or asynchronous request. When an EXCEPTION is thrown, it cancels the process and no asynchronous response will be sent corresponding to this request.

FUNCTION EXCEPTION

MNO SP or SPMNO Exchange Mode : Synchronous


ERROR_TYPE Indication of the type of error encoutered. Possible values described in 0.

Mandatory

ERROR_DETAILS Indication of the data that failed the control. Data identifier (ex : MNO_ID, ID_TECH, AID_SSD_INST,….)

Optional

The diagram below illustrates the use of EXCEPTION in different configurations:

A. Asynchronous request CREATE_SSD_REQ with the transaction identifier abc

ACKNOWLEDGE is a synchronous response sent to confirm the reception of this request and to inform that the controls on the reception server are OK.

Once the appropriate actions are done, the server sends the asynchronous response (CREATE_SSD_RESP) with the transaction identifier abc. The Service Provider sends ACKNOWLEDGE to confirm the reception of this response.

B. Asynchronous request INSTALL_REQ with the transaction identifier bcd

Because the controls on the request format or data fail on the reception server, the MNO throws an EXCEPTION containing detailed information on the error detected. Due to the error, there will be no asynchronous response corresponding to this request.

The Service Provider will have to send the request again after correction.

C. Synchronous request ID_TECH_REQ

The MNO server controls the request and sends a synchronous response (ID_TECH_RESP) with the ID_TECH.

D. Synchronous request LONG_AID_REQ

Because the controls on the request format or data has failed on the reception server, the MNO throws an EXCEPTION containing detailed information on the error detected.

The Service Provider will have to send the request again after correction.



CREATE_SSD_REQ (abc)

CREATE_SSD_RESP (abc)

ACKNOWLEDGE

ACKNOWLEDGE

Controls OK on NFC platfom OK

Acknowledge the reception of the request

Perfoms the actions for SSD creation and sends

response with the transaction identifier

INSTALL_REQ (bcd)

EXCEPTION

Controls NOK on NFC platfom

Sends an EXCEPTION with information on the

error decetected

ID_TECH_REQ

ID_TECH_RESP Generates the ID_TECH

Send response with the ID_TECH

Controls OK on NFC platfom OK

LONG_AID_REQ Controls NOK on NFC platfom

EXCEPTION

A

Sends an EXCEPTION with information on the

error decetected

B

C

D

Figure 26 – Examples of exchanges

3.4.5 Technical Identifier ID_TECH

For regulatory and confidential reasons the MSISDN cannot be transmitted by the Mobile Network Operators. Thus, in the earlier steps of a mobile NFC service installation, the MNO will convert the MSISDN into a technical identifier named ID_TECH to communicate with the Service Providers.

The ID_TECH shall be generated by the Mobile Network Operator respecting the following rules:

- It shall be a unique intra MNO identifier of variable length depending on the Mobile Network Operator, with a maximum length of 16 alphanumeric characters.

- The ID_TECH shall enable the Mobile Network Operator and the Service Provider to address the end user’s mobile handset or UICC via a mobile network access platform, for instance to send SMS PUSH BIP and SMS PUSH WAP. In France, it corresponds to the data known as the ALIAS.

ID_TECH Distribution Mode

Distribution of the ID_TECH by the Mobile Network Operator shall be executed prior to the installation of NFC services on the mobile handset as its value is requested in all the subsequent request, responses and notifications.

The ID_TECH is generated upon reception by the Mobile Network Operator of the eligibility request described in the next paragraph.


ID_TECH Life Cycle

The table below summarizes impacts of end user cases on ID_TECH life cycle.

End User Cases ID_TECH Status (MNO)

ID_TECH Status (SP)

Service activation Generate Receive

Termination, deactivation mobile services Suppress Suppress

UICC change

No change No change

Resuming the end user contract after it has been suspended

Change of mobile handset

Mobile handset lost or stolen

Mobile services temporary suspension

Terminate current mobile services contract in the event of the end user opening a new mobile services contract with the same MNO or another MNO (the end user may keep their MSISDN)

Former MNO suppress old ID_TECH. New MNO generate new ID_TECH

Suppress old ID_TECH. Receive new ID_TECH

MSISDN modification Suppress old ID_TECH

Generate new ID_TECH

Suppress old ID_TECH. Receive new ID_TECH

Table 1: ID_TECH life cycle

3.4.6 Service Identifier SERV_ID

As already mentioned earlier in the document (2.3.4), a mobile NFC service consists of the combination of one or several UICC applications and a MMI.

Each mobile NFC service is identified by a service identifier SERV_ID. It is a unique value for a combination of a Service (of a given Service Provider) and a set of UICC applications (packages + instances), known that a given package can be shared between several SERV_ID. By default the service identifier is generated by the MNO. It could be generated by a common entity but this is not defined yet.

UICC application packages and their associated installation parameters can evolve. It is therefore necessary to also manage a service version (SERV_VERSION) in order to accurately identify the version of each application package and installation parameters that are requested by the Service Provider to run the service.

The SERV_ID and SERV_VERSION are essential data on the Service Provider / MNO interface and are therefore exchanged in the header of all the requests and notifications. Using this SERV_ID and SERV_VERSION precisely identifies a service and the associated technical data that are provisioned on the MNO platform. It therefore avoids sending in each request AIDs and other technical details.


3.4.7 ID_TECH_REQ

Description and prerequisites

ID_TECH_REQ is the eligibility request prior to any exchange for a new mobile NFC service end user during the subscription process (Process 3). The Service Providers requests to the Mobile Network Operator the ID_TECH for an end user. Depending on the context, the Service Provider sends appropriate information (CUSTOMER_ID_TYPE) in the eligibility request:

- Subscription at Service Provider's local office or on web site (Process 3) Send end user’s MSISDN

- Subscription via a WAP session (Process 3 WAP) send end user’s mobile ALIAS

- In case of application update (Process 4 Update) send end user’s current ID_TECH

[Note] This request is exchanged in synchronous mode as it is important to provide a prompt answer to the end user.

FUNCTION ID_TECH_REQ



HEADER_3 Synchronous Message Header for ID_TECH_REQ Mandatory

CUSTOMER_ID_TYPE Customer Identifier Type Possible values: 01 MSISDN 02 ALIAS 03 ID_TECH

Mandatory

CUSTOMER_ID Customer Identifier value Mandatory

Resulting actions

The Mobile Network Operator checks the eligibility of the end user according to the following criteria:

- Commercial (access to NFC services),

- Technical (mobile handset and UICC NFC capable),

- And available memory space on UICC.

If the end user is eligible the Mobile Network Operator generates the ID_TECH.


In version 1, the way to perform the eligibility check might differ from one MNO to another especially regarding the available memory space on UICC, and the information regarding the available memory space is not guaranteed.


3.4.8 ID_TECH_RESP


After the generation of the ID_TECH, the Mobile Network Operator sends the response ID_TECH_RESP.

[Note] This response is exchanged in synchronous mode as it is important to provide a prompt answer to the end user.

The applicable error codes for this request are related to the eligibility for a mobile NFC service (memory space not sufficient, NFC option not activated, or device not compliant with NFC service).

FUNCTION ID_TECH_RESP



ID_TECH Technical Identifier of the line Conditional

ICC_ID UICC identifier Optional (1)

CARD_PROFILE Reference to a smart card manufacturer and operating system

Conditional (2)

1. Presence depends on the process agreed between SP and MNO.

2. Presence depends on agreement between SP and MNO

[Note] The ICC_ID can be used for the diversification of the SSD key set. Its presence depends on the process agreed between Service Provider and MNO.

Resulting actions

The Service Provider and the Mobile Network Operator now share a unique and anonymous technical identifier for the end user of mobile NFC services. The Service Provider can proceed to the next steps for the mobile NFC service installation.

In case the MNO answers with an error code between 400 and 404 (both included), the Service Provider invites the end user to contact his Mobile Network Operator to get the appropriate device or contract option.

3.4.9 SSD_CREATION_REQ


The request for SSD creation is the first step of the installation process (Process 4). The Service Provider must have the ID_TECH for the end user in order to send this request.

This request is conditional. It is mandatory if the SSD needs to be created OTA or if the Service Provider needs to receive the SSD key set.

FUNCTION SSD_CREATION_REQ

SP MNO Exchange Mode : Asynchronous


HEADER_2 Message Header for Asynchronous Request Mandatory

[Note] This request is optional in case the SSD is loaded in factory and attribued in advance to the Service Provider


Resulting actions

If the SSD is already present in the UICC, because created in factory, no OTA action needs to be done. Otherwise, the Mobile Network Operator sends OTA the GP commands to create a SDD in the UICC.

3.4.10 SSD_CREATION_RESP


The Mobile Network Operator might have sent GP commands OTA to create the SSD if it was not already present in the UICC. The MNO sends in the answer SSD_CREATION_RESP the AID of the SSD that is attributed to the Service Provider and also, if applicable, the encrypted keys to access the SSD.

When the MNO does not manage the SSD key set, the SSD_CREATION_RESP does not contain any keys. A process is set up during the provisioning phase between the authorised parties for the SSD keys exchange (described in [R5] Guidelines for interconnection of Service Providers' and MNOs' Information Systems).

The applicable error codes for this request are sent in case the UICC is not accessible (020) or memory space is not sufficient (200). The MNO sends the warning response code 210 in case a SSD is already created or allocated for this Service Provider.

FUNCTION SSD_CREATION_RESP

MNO SP Exchange Mode: Asynchronous



SSD_TABLE Up to 2 occurences of :

AID_SSD_INST AID of the SSD Hex (16)

KEY_TABLE 3DES key. 3 occurences – one per key transmitted. Attributes: TYPE 0:KIC,

1:KID 2:KIK 3:MAC 4:KEK 5:ENC

HEX (1)

INDEX Key index Hex (1) VERSION Key version Hex (1) KEY_VALUE Value of key (not encypted) Hex (16) KEY_KCV Check sum of the key Hex (8)

Conditional (2)

RESPONSE_CODE

See section A1.4(Response Code Table) Mandatory

1. Presence of a second SSD AID depends on agreement between SP and MNO

2. Mandatory if key set managed or loaded OTA by MNO

Note : The TAR is composed of bytes 13, 14 and 15 of the AID.

Resulting actions

Upon reception of this response, the Service Provider can send GP commands OTA to replace the SSD key set with his own key set.

Refer to section Response codes for a list of possible error returned by this request and for error management.


3.4.11 LONG_AID_REQ


The use of this request and associated response is restricted to banking applications compliant to Payez Mobile in the installation process (Process 4). For these applications, the same short AID is used by several banks (CB AID, MasterCard AID, VISA AID …). Therefore, the MNO is requested to generate a long AID unique for each combination of bank and short AID. There are also circumstances, where the MNO is requested to generate several long AIDs for one single short AID. The request contains a table that lists for each short AID the number of expected long AIDs.

FUNCTION LONG_AID_REQ



HEADER_1 Synchronous Message Header Mandatory

AID_SHORT_TABLE Up to 5 short AIDs can be sent.

AID_APP_SHORT Nb of expected Long AIDs

Mandatory

Example:

AID_APP_SHORT Number of expected corresponding Long AIDs

12 34 56 AB CD EF 2

11 22 33 44 55 66 1

Resulting actions

The Mobile Network Operator generates a long AID for this Service Provider and warranties that this AID will be unique on the UICC.

[Note] This Request is not used for short term implementation since long AID are assigned statically for each banking service

3.4.12 LONG_AID_RESP


[Note] The use of this response is restricted to banking applications compliant to Payez Mobile.

The Mobile Network Operator sends to the Service Provider the long AID that he attributed to each short AID for this Service Provider.

FUNCTION LONG_AID_RESP

MNO SP Exchange Mode: Synchronous


AID_LONG_TABLE Up to 10 short AIDs can be sent

AID_APP_SHORT AID_APP_INST

Mandatory

Resulting actions

The Service Provider updates its information system with the long AIDs received. Example:

AID_APP_SHORT Long AIDs corresponding = AID_APP_INST

12 34 56 AB CD EF 12 34 56 AB CD EF 00 00 00 00 00 00 00 00 00 01

12 34 56 AB CD EF 12 34 56 AB CD EF 00 00 00 00 00 00 00 00 00 02

11 22 33 44 55 66 11 22 33 44 55 66 00 00 00 00 00 00 00 00 00 01


3.4.13 INSTALL_REQ


[Note] This request and associated response are restricted to the Simple SD management.

INSTALL_REQ is used in the installation process (Process 4). Depending on the scenario, it can be sent up to three consecutive times to perform the different steps of the installation process in the following order:

- First the application loading with INSTALL_STEP=LOAD,

- Then the application installation with INSTALL_STEP=INSTALL,

- Finally, the application activation with INSTALL_STEP=ACTIVATE.

[Note] It is mandatory to support at least the installation request INSTALL_REQ with INSTALL_STEP=ACTIVATE.

LOADING STEP

This step is conditional. It is mandatory if the package was not previously loaded in factory.

Once the Service Provider has a dedicated SSD on the UICC, and after securing the access with his own key set, it requests for the loading of the application. The Service Provider sends in the header of the request the service identifier and its version which correspond on the Mobile Network Operator platform to a unique set of application(s) and installation parameters. The Service Provider also sends in the request the INSTALL_STEP parameter set to “LOAD”, and if he uses it the DAP signature.

[Note] In simple SD, when the package needs to be loaded OTA, it is mandatory to have the application certified package available on Mobile Network Operator’s platform before submitting requests for loading the package.

[Note] The use of DAP is optional. In case DAP signature is used,

i. The DAP signature can be the same for all the UICC (key for DAP not diversified in the UICC). In this case, it is possible to provision the DAP signature on the MNO platform together with all the other technical details, or the DAP signature can be sent in the INSTALL_REQ request.

ii. In case the key for DAP is diversified for each UICC, the DAP signature must be calculated for each UICC. In this case the DAP signature can only be sent in the INSTALL_REQ request.

INSTALLATION STEP

This step is conditional. It is mandatory if the application was not previously installed in factory.

Once the application is loaded in the UICC, the Service Provider requests an instance for the creation of the application in the SSD that has been attributed to this Service Provider during previous request (SSD_CREATION_REQ). The SERV_ID and SERV_VERSION correspond to a set of installation parameters that the MNO will use in the generation of the GlobalPlatform commands.

[Note] Installation parameters are critical information for the application instanciation. They must be verified and validated by the MNO prior to any request. Therefore, they must be provisionned in advance on the MNO platform together with the application package.

ACTIVATION STEP

This step is mandatory. After the personalisation of the application, the Service Provider explicitly requests for the application activation. This request implicitly means that the personalisation was successful.


FUNCTION INSTALL_REQ




INSTALL_STEP Defines the different installation steps applicable to the request INSTALL_REQ.

Possible values: 01 LOAD 02 INSTALL 03 ACTIVATE

Mandatory

INSTALL_TABLE Up to 10 occurrences of following records

AID

INSTALL_PARAM_INDEX Refers to a set of GP installation parameters

DAP DAP Signature value

Optional

(1) and (2)

1. INSTALL_PARAM_INDEX: Used if several sets of parameters are available on the MNO platform

2. DAP : Optional data when INSTALL_STEP=LOAD and DAP is used

Resulting actions

LOADING STEP

Upon reception of this request, the Mobile Network Operator makes a set of verifications on the UICC context:

- Check that the requested service (SERV_ID+SERV_VERSION) is provisioned and activated on its platform with all the necessary data.

[Note] This control is made on each request or notification reception.

- Check that a SSD is effectively attributed to this Service Provider on this UICC.

- Check if the package is already loaded in the UICC in which case the MNO does not need to perform any OTA actions.

When all the controls are OK, the Mobile Network Operator loads OTA the application in the UICC.

INSTALLATION STEP

The Mobile Network Operator generates the GlobalPlatform commands using the installation parameters and sends them OTA to the UICC.

If the application instance is already present in the UICC, the Mobile Network Operator does not need to perform any OTA actions to the UICC and sends a warning response code to the Service Provider. Otherwise, the Mobile Network Operator creates the application instance and extradites it to the SSD attributed to this Service Provider.

ACTIVATION STEP

The Mobile Network Operator sends the GlobalPlatform command for application activation and if necessary loads the appropriate ACF file on the UICC.


3.4.14 INSTALL_RESP


[Note] This response is restricted to the Simple SD management.

INSTALL_RESP is used in the installation process (Process 4). Like the associated request INSTALL_REQ, it is sent three different times with the appropriate parameter:

- First the application loading with INSTALL_STEP=LOAD

- Then the application installation with INSTALL_STEP=INSTALL

- Finally, the application activation with INSTALL_STEP=ACTIVATE

LOADING STEP

The Mobile Network Operator sends this response after:

- Verifying the UICC context:

o If no SSD is attributed to this Service Provider on this UICC, the operation is aborted, and the response code "211 No SSD attributed to this SP on UICC" is returned to the Service Provider in the INSTALL_RESP response.

o If the application package is already loaded on the UICC, the MNO sends the warning response code “220 Application Package already loaded” to inform the Service Provider. The process can continue.

- And carrying out the OTA loading of the application if it was necessary.

o If the package loading fails, the MNO sends the error code “202 Error during application package loading”.

INSTALLATION STEP

With this response, the Mobile Network Operator informs the Service Provider about the status of the application installation.

ACTIVATION STEP

With this response, the Mobile Network Operator confirms whether activation is performed or not. If the answer is positive, it means that both application activation and optional ACF download were successful. A specific response code is available in case just optional ACF download failed.

In case the MNO does not manage to access the UICC OTA for one of the step listed above, the MNO sends the error code “020 UICC not accessible”. The MNO sends this error code after several attempts failed.

If memory space in the UICC is not sufficient, the MNO sends the error code “200 Memory space not sufficient”.

FUNCTION INSTALL_RESP




RESPONSE_CODE See section A1.2 (Response Code Table) Mandatory


Resulting actions

LOADING STEP

Once the Service Provider has confirmation that the package is available on the end user’s UICC, it requests for the installation of the package.

In case the error code "211 No SSD attributed to this SP on UICC" is returned, the Service Provider must send again the request SSD_CREATION_REQ.

In case the error code “202 Error during application package loading” is returned, the Service Provider initiates a manual process in order to analyse and solve the problem.

INSTALLATION STEP

When the answer is OK, the Service Provider establishes an OTA connection with the UICC to personalise the application.

ACTIVATION STEP

At this stage, the application installation on the UICC is completed. The Service Provider proposes to the end user to download the MMI on his mobile handset.

In case the UICC is not accessible (020), the Service Provider should preferably fist contact the end user, to invite him to switch on the mobile for instance, before sending again the request.

In case the memory space is not sufficient (200), the Service Provider invites the end user to contact his Mobile Network Operator.

3.4.15 INSTALL_MMI_REQ


INSTALL_MMI_REQ is used in the process for the Service Provider MMI installation or update (Process 5). The implementation of this request is conditional. It is mandatory if MMI is used. Two cases are described:

- In case 1, the Service Provider requests the MNO to initiate the MMI download. The Service Provider sends the request with the MMI_ACTION set to:

Option i “MMI with retries” and the version of the MMI to be loaded.

Option ii “MMI only” and the version of the MMI to be loaded

- In case 2, the Service Provider initiates the MMI download. In this case, the use of this request is optional and only necessary when the ACF is used. The MNO is responsible for loading the ACF in the UICC. The Service Provider uses INSTALL_MMI_REQ with the parameter MMI_ACTION set to “ACF only” is order to request the MNO to load or updated the ACF in the UICC.

In case of MMI update, the Service Provider is responsible for explicitly requesting for the update of the ACF when it is necessary (in case a new version is provisioned on the MNO platform). The MNO always loads the most recent certificate available.


FUNCTION INSTALL_MMI_REQ




MMI_ACTION List the action to be done by the MNO: Possible values: 01 MMI only 02 MMI with retries 03 ACF only

Mandatory

MMI_VERSION Version of the Service Provider MMI application Optional

”

Resulting actions

The MNO first performs the loading or update of the ACF if applicable. If the ACF loading fails, the MNOs stops there. Then, the MNO sends a SMS push WAP to the mobile handset to establish a connection with the Service Provider’s MMI server.

3.4.16 INSTALL_MMI_RESP


INSTALL_MMI_RESP is used in the process for the MMI installation or update (Process 5).

The implementation of this response is conditional. It is mandatory if MMI is used.

The response is used to inform the Service Provider about the result of the ACF loading and the sending of a SMS push WAP to the mobile handset.

If the ACF loading fails, the MNO stops there and sends the error code “204 Error during ACF loading”.

In case the MNO sends the error code “042 Connection between MMI service and mobile handset failed”, it implicitly means that the ACF, if used, is correctly loaded. Therefore, the Service Provider will request “MMI only” in the retry.

FUNCTION INSTALL_MMI_RESP





Resulting actions

In case 1, the MMI download is done from the Service Provider’s MMI server in parallel. Once the MMI is downloaded the Service Provider notifies MNO (NOTIF_SP_ACTION).

In case 2, upon reception of this response, the Service Provider initiates the MMI download, and then notifies the MNO (NOTIF_SP_ACTION).


3.4.17 SUPPRESS_REQ


The Service Provider sends this request to the Mobile Network Operator in case it is necessary to update the application (Process 4 Update) or in case of Mobile NFC service termination (Process 19). Due to Simple SD management, the Mobile Network Operator is responsible for deleting all that is related to the targeted service (SERV_ID and SERV_VERSION in the header) including the application instance, the application package and if required and possible the SSD. In case of application update, it is recommended not to delete the SSD, therefore set to parameter DELETE_SSD to 0

FUNCTION SUPPRESS_REQ




DELETE_SSD To indicate whether MNO should try or not to delete the SSD. Possible values: 0 Do not delete SSD 1 Delete SSD if possible

Mandatory

DELETE_REASON To indicate the reason of the removal. Possible values: 0 For termination 1 For update

Optional

1. Present if Service Provider wants it to be deleted

Resulting actions

Upon reception of this request, the Mobile Network Operator makes several controls in order to analyse what can and must be suppressed or not according to the following rules:

- Do not delete a package if there is still another instance linked to this package,

- Do not deleted a SSD if it is not empty

- Do not delete a package that cannot be OTA loaded

- Delete ACF related to the suppressed mobile NFC service (if ACF are used).

3.4.18 SUPPRESS_RESP


Once all the possible deletion is done, the Mobile Network Operator informs the Service Provider. Provided that the application instance and related ACF are suppressed, the response code is OK.

In case the MNO does not manage to access the UICC OTA after several retries, the MNO sends the error code “020 UICC not accessible”.

In case no application corresponding to this SERV_ID is on the UICC, the MNO sends the error code 224 Package absent on the UICC

FUNCTION SUPPRESS_RESP





Resulting actions

The Service Provider can delete the information related to this end user from his information system.


In case the UICC is not accessible (020), the Service Provider should preferably fist contact the end user before sending again the request.

3.4.19 NOTIF_SP_ACTION


In case of Simple SD management, the Service Provider uses this notification to inform the MNO either about a new MMI installation, or about the lock/unlock of the UICC application. It is used in the following contexts:

- To inform about a new MMI download, with the MMI version (Process 5),

- When the Service Provider had to lock and then unlock the UICC application due to a “critical MMI” update (Process 5),

- When the end user calls the Service Provider for loss or theft (Process 10), with the parameters related to the application lock/unlock,

- When the end user recovers his mobile equipment after a loss (Process 11), with the parameters related to the application lock/unlock,

- To confirm to the MNO the application lock done by the Service Provider:

o In case of termination by end user of Mobile subscription or NFC option (Process 14),

o In case of termination of mobile service by MNO (Process 15),

o In case of temporary suspension of mobile service upon end user’s request (Process 16)

Several steps values are available to track the different possibilities of application lock:

- GlobalPlatform lock/unlock of the UICC application done OTA (07, 08)

- Applicative lock/unlock of mobile NFC service on the Service Provider Information System (09, 10)

- Applicative lock of the UICC application done OTA (11, 12) for instance with an EMV script processing command APPLICATION BLOCK.

[Note] In case of delegated management, this notification is also used to communicate to the Mobile Network Operator the result of each installation step and sends the corresponding token receipt (see in appendix A2.3.1 ).

FUNCTION NOTIF_SP_ACTION




ACTION_STATUS Application installation status. Detailed in A1.1. Up to 2 occurences in this notification.

Possible values in Simple SD management : STEP 06

07 08 09 10 11 12

DOWNLOAD MMI GP LOCKED APPLICATION GP UNLOCKED APPLICATION LOCKED on IT system UNLOCKED on IT system Applicative LOCKED Applicative UNLOCKED

N(2)

STATUS 00 10

OK Failed

N(2)

COMPL MMI_VERSION Hex (var)

Mandatory


CRITICAL_LEVEL 00 01

Default value

Critical (1)

(1) This value is only used in the case of a lock (GP, IT or applicative lock).

Resulting actions

The Mobile Network Operator updates the information for this end user in his information system.

3.4.20 NOTIF_CALL_ENDUSER_TO_MNO


This notification is used by the Service Provider receiving the end user’s call in case of loss of theft of his mobile equipment to inform the Mobile Network Operator (Process 10).

FUNCTION NOTIF_CALL_ENDUSER_TO_MNO




REASON Operation justification

Possible values: 11 Mobile loss 13 Mobile theft

Optional

DATE_TIME_CALL Date / time of the declaration call Mandatory

Resulting actions

The Mobile Network Operator keeps record of this information related to the end user in his information system.

3.4.21 NOTIF_NEW_DEVICE


The Mobile Network Operator sends this notification to inform the Service Provider in case the end user gets new devices: UICC, mobile, or both new UICC and mobile.

This notification is used in the following processes:

- Process 6 – Change UICC DEVICE set to 01

- Process 8 – Change Mobile handset DEVICE set to 02

- Process 12 – Get a new mobile equipment after a lost of theft DEVICE set to 03

FUNCTION NOTIF_NEW_DEVICE




DEVICE

To list which device was changed: Possible values: 01 UICC 02 Mobile handset 03 UICC + mobile handset

Mandatory

[Note] The reception of this notification for a new UICC implicitely means that the previous UICC is deactivated.


Resulting actions

Upon reception of this notification, the Service Provider launches the appropriate action:

- Installation of application if new UICC – Process 4,

- Installation of the MMI if new mobile – Process 5,

- Entire new installation if new UICC + Mobile – Process 4 and Process 5.

3.4.22 NOTIF_CHANGE_ID_TECH


When the end user wants to change his phone number, the Mobile Network Operator gives a new phone number and generates a new ID_TECH and notifies the Service Provider with the value of the NEW_ID_TECH.

FUNCTION NOTIF_CHANGE_ID_TECH




NEW_ID_TECH New Technical Identifier of the line Mandatory

Resulting actions

The Service Provider updates his information system with the NEW_ID_TECH for this end user. No other action is necessary.

3.4.23 NOTIF_CALL_ENDUSER_TO_SP


This notification is used by the Mobile Network Operator receiving the end user’s call in case of loss of theft of his mobile equipment to inform the Service Provider (Process 9).

FUNCTION NOTIF_CALL_ENDUSER_TO_SP




REASON Operation justification

Possible values: 11 Mobile loss 13 Mobile theft

Optional

DATE_TIME_CALL Date / time of the declaration call Mandatory

LINE_STATE Define the MNO’s line state Mandatory

Resulting actions

The Service Provider keeps record of this information related to the end user in his information system.


3.4.24 NOTIF_CHANGE_TO_SP


The Mobile Network Operators uses this notification to inform the Service Providers about status changes on the line or the NFC option.

This notification is used in several contexts:

- When the end user calls the Mobile Network Operator for loss or theft (Process 9), with the parameters related to application status and the line status.

- Once the end user recovers his mobile phone, the Mobile Network Operator restores the end user’s mobile connection (Process 11), with the parameters related to the line status.

- When the end user wants to terminate mobile subscription or NFC option (Process 14), with the parameters related to the line status or NFC option status.

- When the Mobile Network Operator terminates the mobile service (Process 15), with the parameters related to the line status.

- When the end user wants to temporary suspend the mobile service (Process 16) with the parameters related to the line status.

FUNCTION NOTIF_CHANGE_TO_SP




NEW_STATUS Gives the new status of the mobile service or NFC service after an action. Up to 4 occurences.

Possible values: 01 Line ACTIVATED 02 Line RESTRICTED 03 Line SUSPENDED 04 Line TERMINATED 10 Application UNLOCKED 11 Application LOCKED 12 Application DELETED 20 NFC option activated 21 NFC option terminated

Mandatory

DATE_TIME_CHANGE Allow to retrieve the effective date of the application and / or line status changing

Mandatory

REASON Operation justification. See § A1.1 for possible values Optional

Resulting actions

The Service Provider updates the information related to this end user in his information system.

In case the line is suspendede or terminated, but the MNO did not manage to lock the application, the Service Provider makes an applicative lock of the mobile NFC service on its information system.


Appendix 1 DATA DICTIONARY

A1.1 List of data

Name Description Format

Length

Critical

ACTION_STATUS Application installation status

Up to 5 occurences STEP 01

02 03 04 05 06 07 08 09 10 11 12

LOAD APPLICATION INSTALL APPLICATION PERSONALISATION ACTIVATE APPLICATION DELETE APPLICATION DOWNLOAD MMI GP LOCKED APPLICATION GP UNLOCKED APPLICATION LOCKED on IT system UNLOCKED on IT system Applicative LOCKED Applicative UNLOCKED

N(2)

STATUS 00 10

OK Failed

N(2)

COMPL Complementary information:

- GP response if appropriate

- Token receipt

- MMI_VERSION

Hex (var)

AID_APP_INST Application Instance AID Hex (5 to 16) X

AID_APP_SHORT Payment Application Short Identifier Hex (5 to X

AID_SSD_INST SSD Instance AID Hex (5 to 16) X

CARD_PROFILE Reference to a smart card manufacturer and operating system AN (16)

CUSTOMER_ID_TYPE Customer Identifier Type Possible values: 01 MSISDN 02 ALIAS 03 ID_TECH

N (2)

CUSTOMER_ID Customer Identifier value To be defined

DAP DAP signature Hex (var) X

DATE_TIME_CALL Date / time of the declaration call AN (19)

DATE_TIME_CHANGE Allow to retrieve the effective date of the application and / or line status changing

AN (19)

DELETE_REASON To indicate the reason of the removal. Possible values: 0 For termination 1 For update

N (1)

DELETE_SSD To indicate whether MNO should try or not to delete the SSD. Possible values: 0 Do not delete SSD 1 Delete SSD if possible

N (1)

DEVICE To list which device was changed: Possible values: 01 UICC 02 Mobile handset 03 UICC + mobile handset

N (2)

ERROR_TYPE Indication of the type of error encountered. Exclusively used in the synchronous response EXCEPTION. Possible values described in 0.

N (3) X



Length

Critical

ERROR_DETAILS Indication of the data that failed the control. Data identifier (ex : MNO_ID, ID_TECH, AID_SSD_INST,….)

AN (var)

GP_COMMAND GP command to be signed by a token calculation Hex (var)

HEADER_1 Message Header for Synchronous Request – cf description in § 3.4.1

HEADER_2 Message Header for Asynchronous Request – cf description in §3.4.1

HEADER_3 Message Header for ID_TECH_REQ – cf description in § 3.4.1

ICC_ID Unique value per UICC containing card profile. Can be used in the keys diversification process

N(20)

ID_MNO Identification of the Owner and Manager of the UICC

Attributes : CC Country Code of the Owner and Manager of

the UICC in accordance with the ISO 3166 norm

N(3)

MNC MNO Code true to the ITU E.212 Norm. N (var 2 or 3) RFU Reserved For Future Use N (3)

N (var 8 or 9)

ID_TECH Technical Identifier of the line AN (max 16) X

INSTALL_PARAM_INDEX

Refers to a set of GP installation parameters Hex (1)

INSTALL_STEP Defines the different installation steps applicable to the request INSTALL_REQ.

Possible values: 01 LOAD 02 INSTALL 03 ACTIVATE

N(2)

INSTALL_TABLE Up to 10 occurrences of following records

AID

INSTALL_PARAM_INDEX Refers to a set of GP installation parameters

DAP DAP Signature value

Hex (var)

KEY_TABLE Up to 2 occurences of :

AID_SSD_INST AID of the SSD Hex (16)

KEY_TABLE 3DES key. 3 occurences – one per key transmitted. Attributes: TYPE 0:KIC,

1:KID 2:KIK 3:MAC 4:KEK 5:ENC

HEX (1)

INDEX Key index Hex (1) VERSION Key version Hex (1) KEY_VALUE

Value of key (not encypted)

Hex (16)

KEY_KCV Check sum of the key Hex (8)

Hex (var) X

LINE_STATE Defines the MNO’s line state Possible values: 01 Line ACTIVATED 02 Line RESTRICTED 03 Line SUSPENDED 04 Line TERMINATED

N (2)

MMI_ACTION List the action to be done by the MNO: Possible values: 01 MMI only

N(2)



Length

Critical

02 MMI+ACF 03 MMI only including retries 04 MMI including retries +ACF 05 ACF only

MMI_VERSION Version of the Service Provider MMI application Hex (3)

MSISDN Mobile number (country code included) AN (max 15) X

NEW_ID_TECH New Technical Identifier linked to the mobile line AN (max 16)

NEW_STATUS Gives the new status of the mobile service or NFC service after an action. Possible values: 01 Line ACTIVATED 02 Line RESTRICTED 03 Line SUSPENDED 04 Line TERMINATED 10 Application UNLOCKED 11 Application LOCKED 12 Application DELETED 20 NFC option activated 21 NFC option terminated

N (2)

PRIORITY_INDEX Index of priority. Default value set to 0 Possible values: 0 No priority defined 1 Highest priority 2 Intermediate priority 3 Lowest priority

N (1)

REASON Presents the reason that justifies a request or a notification. Possible values: 01 Line release 02 Line suspension 03 Line termination 11 Mobile loss 12 Mobile recovery 13 Mobile theft 21 End user request 31 SP request

N (2)

RESPONSE_CODE Response code (OK, warning or error). See section A1.2 (Response Code Table). Used in the asynchronous responses.

SC_MANUF Identifider of Smart Card Manufacturer Hex (1)

SERV_ID Service Identifier: unique value for a combination of Service Provider + Application. The SERV_ID is generated by the Mobile Network Operator. The SERV_ID is static when the application package version increases. Whereas its associated version SERV_VERSION increases.

N (5)

SERV_VERSION Version of the service

SSDM_ID SSD Manager Identifier N (3)

SYNCH_STATUS Set to 0 to confirm that the synchronous controls are OK. Possible value: 0 Successful processing

N (1) X

TOKEN Token composed of TLV format data Hex (var) X

REQUEST_ID Transaction identifier (unique) composed of three data and two separators:

SERV_ID N(5) Timestamp in milliseconds N(19) Additional diversifier N(2)

Example : 10:223372036854:21

AN (26 max)


A1.2 List of requests, responses and notifications

Requests and responses

The requests are always issued by the Service Provider and the responses are always issued by the MNO.

Some requests are optional or conditional.

Man

dat

ory

Co

nd

itio

nal

Op

tio

nal

Request Response

Description and comments

ID_TECH_REQ ID_TECH_RESP Eligibility request

SSD_CREATION_REQ SSD_CREATION_RESP Request for SSD creation

[Note] Mandatory if SSD needs to be created OTA or Service Provider needs to receive the SSD key set.

LONG_AID_REQ LONG_AID_RESP Request for generation of a long AID

[Note] Only applicable for banking applications

INSTALL_REQINSTALL_RESP Request applicable for 3 steps

1. Loading

[Note] Mandatory if the package was not previously loaded in factory

2. Installation

[Note] Mandatory if the application was not previously installed in factory.

3. Activation

INSTALL_MMI_REQ INSTALL_MMI_RESP Request for loading ACF and initiating MMI download.

Case 1 – Upon Service Provider request, the MNO launches the MMI installation or update

[Note] Mandatory when MMI is used

Case 2 – The Service Provider launches the MMI installation or update

MMI critical update

SUPPRESS_REQ SUPPRESS_RESP Request for deletion

TOKEN_REQ TOKEN_RESP Request for token.

[Note] Not applicable in version 1. Specific to Delegated Management.


Notifications

The support of all the notifications is mandatory.

The Service Provider must be able to send the two SP MNO notifications and in reverse, must be able to receive the MNOSP notifications.

Man

dat

ory

Service Provider notification to Mobile Network Operator

NOTIF_CALL_ENDUSER_TO_MNO To notify Mobile Network Operator that end user has called the Service Provider in case of lost or stolen mobile equipment

NOTIF_SP_ACTION To notify Mobile Network Operator about actions done by the Service Provider: MMI installation, lock/unlock of the UICC application, and in Delegated Management the result of all the actions with a token.

Mobile Network Operator notification to Service Providers

NOTIF_CALL_ENDUSER_TO_SP To notify Service Providers that that end user has called the Service Provider in case of lost or stolen mobile equipment

NOTIF_CHANGE_ID_TECH To notify Service Providers about change of ID_TECH

NOTIF_CHANGE_TO_SP To notify Service Providers about changes related to one or several of the following items: the application hosted on the UICC, the line, the NFC option and the MMI

NOTIF_NEW_DEVICE To notify Service Providers about device change (UICC and/or mobile handset)

Acknowledgment and Exception

Man

dat

ory

Acknowledge

MNO_ACKNOWLEDGE MNO acknowledges request or notification received from the Service Provider

SP_ACKNOWLEDGE Service Provider acknowledges response or notification received from the MNO

EXCEPTION Synchronous response to signal a data or format error on the received request


A1.3 List of processes

Man

dat

ory

Co

nd

itio

nal

Op

tio

nal

Process

Process 1 – Inquiry information to the Service Provider

Process 2 – Inquiry information to the Mobile Network Operator

Process 3 – Subscription at Service Provider's local office or on web site

Process 3 WAP – Subscription via a WAP session

[Note] At least one must be implemented

Process 4 – Mobile NFC UICC application installation

Process 4 Update – Mobile NFC UICC application update

[Note] It is upon Service Provider’s decision to have the capacity to update OTA its UICC application.

Process 5 – Service Provider MMI installation (or update

[Note] This process is conditional. It is possible that some mobile NFC services do not require a MMI. In this case the process 5 is not applicable.

Process 6 – Change UICC

Process 7 – Change mobile phone number

Process 8 – Change mobile handset

Process 9 – Lost or stolen mobile equipment, end user contacts Mobile Network Operator

Process 10 – Lost or stolen mobile equipment, end user contacts Service Provider

Process 11 – Recover mobile equipment after a lost or theft

Process 12 – Get a new mobile equipment after a lost of theft

Process 13 – End user changes Mobile Network Operator

Process 14 – Termination of Mobile subscription or NFC option by end user

Process 15 – Termination of mobile service by Mobile Network Operator

Process 16 – End User requests temporary mobile service suspension

Process 18 – End user calls the Service Provider’s customer service

Process 19 – End user calls the Mobile Network Operator’s customer service


A1.4 Response codes

The response codes are used in the asynchronous responses. The response codes are composed of six categories:

- Response code OK (K): The answer is positive.

- Warning (W) response code: The warning response informs the Service Provider that the request was in fact not necessary for this End User or that the correct sequence for this request was not fulfilled. Warning codes are preferably thrown on synchronous response defines in 0

- Connection (C) Error code: after several retries, the MNO didn't succeed to reach the mobile handset or the connection was broken.

- Incompatible (I) Error code: the end user mobile equipment is not compliant with NFC requirements.

- Data (D) error code: the parameters given in the request doesn't match with the MNO data.

- Fatal Error (F) response code: all the other response codes. The answer is negative. See Erreur ! Source du renvoi introuvable. the error response code management for retries policy.

The table below presents the relationship between each response code and the applicable response.

RES

PO

NSE

_CO

DE

CO

DE_

TY

PE

Description

SSD

_CR

EATI

ON

_RES

P

INST

ALL

_RES

P

INST

ALL

_MM

I_R

ESP

SUP

PR

ESS_

RES

P

000 K OK X X X X

020 C UICC not accessible X X X X

042 C Connection between MMI service and mobile handset failed

X

090 F Card fatal error X X X X

200 F Memory space not sufficient X X

202 F Error during application package loading X

204 F Error during ACF loading

220 W Application Package already loaded X

221 W Application already installed X

222 W Application already activated X

224 W Package absent on the UICC X X

225 W Application not installed X


A1.4.1 Exceptions

When an error is detected on the reception server, the server throws an EXCEPTION with an appropriate ERROR_TYPE.

The table below lists all the possible values for ERROR_TYPE and the request for which they are applicable.

ERR

OR

_TY

PE

CO

DE_

TY

PE

Description

ID_

TEC

H_R

EQ

SSD

_CR

EATI

ON

_REQ

LON

G_

AID

_REQ

TOK

EN_R

EQ

INST

ALL

_REQ

INST

ALL

_MM

I_R

EQ

SUP

PR

ESS_

REQ

001 D Value error X X X X X X X

002 D Format error X X X X X X X

003 D Service not provisioned X X X X X X X

004 D Mandatory data missing X X X X X X X

005 D Presence of unexpected data X X X X X X X

006 D Unknown identifier X X X X X X X

007 D Incompatible identifier with the requested action X X X X X X X

012 D Not coherent with SSD privilege (1) X X

200 F Memory space not sufficient X X

210 W SSD already created/allocated for this Service Provider X

211 W No SSD attributed to this Service Provider on UICC X X X

220 W Application package already loaded X(1) X

221 W Application already installed X(1) X

222 W Application already activated X(1) X

224 W Package absent on the UICC X X

225 W Application not installed X

400 I NFC service not activated for this CUSTOMER_ID X

401 I Incompatible with NFC services X

402 I UICC not compliant with NFC services X

403 I Mobile handset not compliant with NFC services X

404 I Offer not compliant with NFC services X

900 F Unexpected server error X X X X X X X

901 F Quota overcome X X X X X X X

1. Optional, such controls depend on the Mobile Network Operator


A1.4.2 Error Response Code management

Code type Error description Retries policy

C Connection error code Considering the MNO made several retries before returning this type of response code, the Service Provider should preferably contact the end user before sending the request again

W Warning code The request was not necessary or the AFSCM sequence was not respected. The SP can continue or retry with the expected request.

F Fatal error code Definitive Error, no need to retry. SP should inform the end user and contact the MNO through After Sales services procedures.

D Data error code The parameters given in the request doesn't match with the expected by the MNO. The request can be retry with the correct parameters

I Incompatible Error code Definitive Error, no need to retry. The end user cannot benefit from NFC offer.


Appendix 2 INFORMATIVE APPENDIX ON DELEGATED MANAGEMENT

This appendix presents all the information that are related to Delegated Management. As presented in the beginning of this specification, Delegated Management is not supported in the version 1.

Yet it was estimated relevant to already present this information in the interface specification, so that the requests dedicated to Delegated Management can already be considered in the platform development projects.

A2.1 Process description and flow chart

A2.1.1 Process 4 – Installation of UICC application

To install the mobile NFC service in Delegated Management, the Service Provider requests to the MNO a token for each action to be done on the UICC (package loading, application installation and extradition).

Once it has the tokens, the Service Provider sends OTA the GlobalPlatform commands to the UICC and informs the MNO with a notification that contains the token receipts of the action previously done on the UICC.

Then the Service Provider performs OTA the personalisation of the application and notifies the MNO about the status of the personalisation.

Last, the Service Provider requests an additional token for the application activation. Then it does the OTA activation of the application and notifies the MNO with the token receipt.

The next step is the installation of the MMI (Process 5).


Ste

p 3

– M

ob

ile N

FC

se

rvic

e in

sta

llatio

n

Process N°4 – Installation of UICC application – Delegated Management Mode


Yes

No

Yes

No

Yes

Notify the MNO about the

personalisation completion and

ask for activation authorization

Application personalisation

Inform End user of

failure

Notify MNO about successful

activation and send the receipt

Deliver, if authorized, the tokens to

the Service Provider

Successful installation?

Successful

activation?

Process 5 – MMI installation

Deliver, if authorized, a

token to SP

Notify MNO about

failure

Notify MNO about

failure

Activate the mobile NFC

service

Install the mobile NFC

service on the UICC

Notify MNO about successful

installation and send the receipts

Request authorisation

from the MNO Initiate installation


A2.1.2 Process 4 – Update of UICC application

Like in Simple SD, this process applies for each of the following circumstances:

- The end user replaces or updates his mobile NFC service requiring the installation of a new NFC application,

- The Service Provider wants to update the existing end user NFC service, or wants to propose a new service,

- The Service Provider wants to update its mobile NFC service for all end users.

The Service Provider informs the end user about a temporary service suspension and after some leadtime, it initiates the update process. The first step is to delete the existing application before loading the new application. The Service Provider requests a token for the application deletion (package and instance). It performs the deletion and notifies the MNO with the result of the deletion.

Then, the Service Provider sends a request for eligibility for this end user so that the MNO can check that there is enough memory space on the UICC for the new version of service.

If the answer is positive, the end user might have to sign a new contract or contract amendment and the subsequent installation process is similar to the one described in Process 4.

Ste

p 3

In

sta

ll M

ob

ile N

FC

Se

rvic

e

Process N°4 Update – Update of UICC application – Delegated Management Mode


No

Request for elegibility

Inform End user to contact his

MNO, specifying the reason why

he is not eligible

Sign contract or contract

amendment is necessary

Replace/renewal of NFC

offer (upon request of end

user or SP)

Subscription process

Delete application and send a

receipt to the MNO

Update of the mobile NFC service

by the Service Provider

Deliver, if authorized, a token to

SP

Inform end user about temporary

service suspension

Is end user

eligible from MNO

perspective?

Request application deletion

authorisation

Process n°4 « Install UICC

application»

Yes


A2.1.3 Process 19 – Mobile NFC service termination

Once the Service Provider launches the termination process, he requests to the MNO a token for deleting the UICC application. The MNO sends the token and the Service Provider does the deletion on the UICC and notifies the MNO about the status of the deletion.

Finally, the Service Provider request for the suppression of the service to the MNO so that the MNO suppress the SSD.

At this stage the Service Provider can stop the mobile NFC service for this end user on the information system, and informs the end user about the end of the mobile NFC service.

Ste

p 5

: T

erm

ina

tio

n

Process n°19 – Termination of mobile NFC service / Process n°19 – DM Mode


Inform End user about end of

mobile NFC service

End of mobile NFC service on

Information System

End user wants to suppress

mobile NFC service from his

mobile

Launch process for mobile NFC

service termination and request MNO

authorisation to delete application

Deliver, if authorized, a token to

SP

Service Provider terminates the End

user’s mobile NFC service

Application deletion

Notify and send

receipt tokens to MNO

Deletion of SSD and ACF if

relevantRequest Service deletion


A2.2 Processes supporting customer journey

A2.2.1 Process 4 – Installation of UICC application

In Delegated Management, the Service Provider is “authorised” to perform all the steps related to the application loading and installation. The authorisation consists in requesting a token to the MNO for each action to be done on the UICC.

For the first steps, the same process in Simple SD applies:

- For the SSD creation and/or attribution, the Service Provider uses the request SSD_CREATION_REQ,

- SSD key replacement,

- Request for Long AID if applicable.

Then the Service Provider sends request TOKEN_REQ for each action that will need to be done: package loading, application installation and extradition and application activation.

Once it has the necessary tokens, the Service Provider sends OTA the GlobalPlatform commands in order to load the application package, install and extradite the application, perfom the personalisation and finally activate the application.

[Note] It is recommended to first request for all the tokens before establishing the OTA connection with the UICC.

When these steps are completed, the Service Provider notifies the MNO with all the token receipt to inform about the status of the steps achieved.

[Note] The same notification NOTIF_SP_ACTION can be used to communicate the result of several steps (up to 5).

Once all these steps are achieved, the Service Provider launches the MMI installation (Process 5). The same process applies as for Simple SD.


SSD Creation

Service Provider

SSD_CREATION_REQ

SSD_CREATION_RESP

Long AID Generation

Mobile Operator

LONG_AID_REQ

LONG_AID_RESP

NOTIF_SP_ACTION

(Token receipts)

Tokens calculationTOKEN_REQ

TOKEN_RESP

Request for token,

n occurences

UICC

Application Loading

Application Installation and Extradition

Application Personalization and Activation

SSD Creation

SSD Key Replacement

Option: for banking application

Option: If SSD not already

available on UICC

Figure 27 - Process 4 Installation in Delegated Management

A2.2.2 Process 4 – Update UICC application

The Service Provider needs to update the UICC application of its mobile NFC service.

The first step for the Service Provider is to request a token for the deletion of the existing UICC application (TOKEN_REQ).

Then, it sends OTA the GlobalPlatform commands in order delete the application instance and package and notifies the MNO with the token receipt (NOTIF_SP_ACTION) so that the MNO can update its information system accordingly.

The Service Provider sends a request for eligibility so that the MNO can check that there is enough memory space available in the UICC for this version of the service (SERV_VERSION in the header of the request).

If the answer is positive, the Service Provider sends several consecutive requests TOKEN_REQ, one request per action: package loading, application installation and extradition, and application activation.

Once it has the necessary tokens, the Service Provider sends OTA the GlobalPlatform commands in order to load the application package, install and extradite the application, perfom the personalisation and finally activate the application.

[Note] It is recommended to first request for all the tokens before establishing the OTA connection with the UICC.


When these steps are completed, the Service Provider notifies the MNO with all the token receipt to inform about the status of the steps achieved.

[Note] The same notification NOTIF_SP_ACTION can be used to communicate the result of several steps (up to 5).

Once all these steps are achieved, the Service Provider launches the MMI installation (Process 5). The same process applies as for Simple SD.

Mobile OperatorService Provider UICC

ID_TECH_REQ

ID_TECH_RESP

Request for

eligibility

Keep same ID_TECH, check

memory space available

TOKEN_REQ

For application instance + package deletion

TOKEN_RESP

Delete application instance and package

NOTIF_SP_ACTION

(Token receipt)

Suppress previous

UICC application

TOKEN_REQ

TOKEN_RESP

NOTIF_SP_ACTION

(Token receipt)

Application Loading

Application Installation and Extradition

Application Personalization and Activation

Repeated for: loading

installation and extradition

activation

Figure 28 – Process 4 Update UICC application in Delegated Managed

A2.2.3 Process 19 – Mobile NFC service termination

The Service Provider requests one or several tokens (TOKEN_REQ) for the deletion of the application instance and optionally for the package deletion. After receiving each requested token, the Service Provider sends the appropriate commands and tokens to the UICC. The Service Provider notifies the MNO with the result of each action by sending the token receipt in the NOTIF_SP_ACTION.

Finally, the Service Provider requests the deletion of the SSD using the same request SUPPRESS_REQ as for simple SD management.


Token calculationTOKEN_REQ

TOKEN_RESP


Delete application instance and package if possible

SUPPRESS_RESP

Delete SSD

SUPPRESS_REQ

(ID_SERV)

NOTIF_SP_ACTION

(Token receipt)

Figure 29 - Process 19 Mobile NFC service termination in Delegated Management

A2.3 Detailed commands

A2.3.1 TOKEN_REQ


[Note] The use of this request and associated response is mandatory in case of Delegated Management. Even though Delegated Management are not used in version 1 deployments, the request and its associated response must already be considered in the interface.

TOKEN_REQ is used in the following context:

- UICC application installation (Process 4),

- UICC application update (Process 4 Update)

- Mobile NFC service termination (Process 19)

The Service Provider prepares the Global Platform commands that is necessary for the application installation and sends one token request per GP command.

FUNCTION TOKEN_REQ




GP_COMMAND GP command to be signed by a token calculation Mandatory

Resulting actions

The Mobile Network Operator checks that this SSD is configured in Delegated Management, and that the package requested to be loaded is certified.

If the answer to theses verifications is positive, the Mobile Network Operator generates the token and sends it to the Service Provider in the TOKEN_RESP response.

- Otherwise, it returns TOKEN_RESP with an error code.


A2.3.2 TOKEN_RESP


[Note] The use of this response is mandatory in case of Delegated Management.

The pre requisites to the TOKEN_RESP response is the reception of a request for token and the results of the appropriate verifications as described in previous paragraph.

The Mobile Network Operator sends either the token or an error code in the TOKEN_RESP response.

FUNCTION TOKEN_RESP



TOKEN Token composed of TLV format data Conditional (1)

Resulting actions

Upon reception of the token the Service Provider can establish an OTA connection to the UICC in order to send the GP command.

It is recommended to request all the tokens necessary for a UICC before establishing the OTA connection.

A2.3.3 NOTIF_SP_ACTION


This notification is already described in the core of this specification because it is used to inform the Mobile Network Operator about the MMI installation and the UICC lock/unlock(3.4.19 NOTIF_SP_ACTION).

In case of delegated management, this notification is also used to communicate to the MNO the result of each installation step and send the corresponding token receipt. One notification can be used to communicate several token receipts, because it is possible to send up to 5 occurrences of the ACTION_STATUS.

In Delegated Management, this notification is used in the following processes:

- Process 4 UICC application installation

- Process 4 Update UICC application update

- Process 5 MMI installation

- Process 19 Mobile NFC service termination


FUNCTION NOTIF_SP_ACTION




ACTION_STATUS Up to 5 occurences STEP 01

02 03 04 05 06 07 08

LOAD APPLICATION INSTALL APPLICATION PERSONALISATION ACTIVATE APPLICATION DELETE APPLICATION DOWNLOAD MMI LOCK APPLICATION UNLOCK APPLICATION

N(2)

STATUS 00 10

OK Failed

N(2)

COMPL Complementary information:

- Token receipt. If the receipt was lost by the SP, the value could be null. This case shall be exceptional

Hex (var)

Mandatory

Resulting actions

The Mobile Network Operator updates the information for this end user in his information system.

A2.3.4 SUPPRESS_REQ


In Delegated Management, the Service Provider first requests tokens for deleting the application instance and the application package before sending the SUPPRESS_REQ to the Mobile Network Operator who is then responsible for deleting the SSD. The deletion of the SSD is necessary in case of Mobile NFC service termination (Process 19).

The request SUPPRESS_REQ is exactly the same than earlier described in the specification.

Resulting actions

Upon reception of this request, the Mobile Network Operator makes several controls in order to analyse what can and must be suppressed or not according to the following rules:

- Do not deleted a SSD if it is not empty

- Delete ACF related to the suppressed mobile NFC service (if ACF are used).

A2.3.5 SUPPRESS_RESP

The response SUPPRESS_RESP is exactly the same than earlier described in the specification.


Appendix 3 WSDL

The AFSCM provides the WSDL for the requests, responses and notifications exchanged on the SP/MNO interface. The files are provided in electronic version upon request to the AFSCM.

The first version will be enriched and fine tuned during the first connection trials between Service Provider and MNO platforms.

General description of the files, applicable to all the wsdl:

- afscmSchema.xsd.

For the MNO platform:

- lifecycleNotifications.wsdl

- requestMno.wsdl

For the Service Provider platform:

- spInterface.wsdl

END OF DOCUMENT

Documents

AFSCM TECH - LIVBL - Interface Specification - V1.2