AFSCM TECH - LIVBL - Interface Specification - V1.2

INTERFACE SPECIFICATION Between Telecom Operators and NFC Service Providers
RELEASE 1.2
Date Reference 20/10/2009 AFSCM_Specification_Interface_V12 20091020.doc
AFSCM Interface Specification V1.2 November 2009 AFSCM Confidential & Proprietary
p1/98
Name
Company
Authors
Ccile Bailoni Antoine Jacob Sbastien Gauthier Laurence Becq Gal Grard Susana Oliver-Pastor Rolla Lamaa SFR AFSCM SFR AFSCM Orange Bouygues Telecom
Editor Document manager Approval
Evelyne Babel Olivier Tessier Olivier Tessier
Document management
Version Date Chapters Modification
0.1 0.2 0.3 1.0 1.01
19/01/2009 26/02/2009 18/03/2009 10/04/2009 15/05/2009
All All All All
Document creation Internal review Comments from associate members Final review
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 3.4.4 MNO_ACKNOWLEDGE and SP_ACKNOWLEDGE: Removed COMPL_RESPONSE and added reference to EXCEPTION Added a paragraph to define EXCEPTION
3.4.8, 3.4.12 The elements COMPL_RESPONSE and RESPONSE_CODE are removed from the synchronous responses (ID_TECH_RESP, A2.3.2 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 Added EXCEPTION to the List of requests, responses and notifications. Removed Response code table restricted to asynchronous responses Created this appendix to described ERROR_TYPE used in the EXCEPTION Included feedback from associate member and industry partners
A1.2 A1.4 0 1.2 20/10/2009 All
p2/98
TABLE OF CONTENTS ____________________________________________________________ 1

1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8
INTRODUCTION ................................................................................................................... 7
Context .................................................................................................................................................. 7 Purpose of the interface specification .................................................................................................. 8 Content of the interface specification................................................................................................... 8 How to use this specification?............................................................................................................... 9 Reference to the other AFSCM guidelines .......................................................................................... 10 References ........................................................................................................................................... 11 Acronyms and abbreviations ............................................................................................................... 11 Definitions ........................................................................................................................................... 12
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 2.3.2.2 Process 1 - Inquiry to the Service Provider .................................................................................. 17 Process 2 Inquiry to the Mobile Network Operator .................................................................. 17
2.3.3
2.3.3.1 2.3.3.2
Step 2: Subscription ................................................................................................................18

Process 3 Subscription at Service Provider's local office or on web site ................................... 18 Process 3 WAP Subscription via a WAP session ....................................................................... 20
2.3.4
2.3.4.1 2.3.4.2 2.3.4.3
Step 3: Installation of Mobile NFC Service..............................................................................21

Process 4 Mobile NFC UICC application installation................................................................. 21 Process 4 Update - Mobile NFC UICC application update ........................................................... 24 Process 5 Service Provider MMI installation ............................................................................ 25
2.3.5
Step 4: Use mobile NFC Service ..............................................................................................28

Process 6 Change UICC ................................................................................................................ 28 Process 7 Change mobile phone number .................................................................................... 29 Process 8 Change mobile handset ............................................................................................... 30 Process 9 Lost or stolen mobile equipment, end user contacts Mobile Network Operator ........ 31 Process 10 Lost or stolen mobile equipment, end user contacts Service Provider ...................... 33 Process 11 Recover mobile equipment after a loss (or theft)...................................................... 34 Process 12 Get a new mobile equipment after a loss of theft..................................................... 35 Process 13 End user swaps Mobile Network Operator ............................................................ 35 Process 16 End User requests temporary mobile service suspension....................................... 36 Process 17 End user calls the Service Providers customer service ........................................... 37 Process 18 - End user calls the Mobile Network Operators customer service ............................ 38 Process 14 Termination by end user of Mobile subscription or NFC option ............................. 39 Process 15 - Termination of mobile service by Mobile Network Operator .................................. 40 Process 19 Mobile NFC service termination ............................................................................. 42
2.3.5.1 2.3.5.2 2.3.5.3 2.3.5.4 2.3.5.5 2.3.5.6 2.3.5.7 2.3.5.8 2.3.5.9 2.3.5.10 2.3.5.11
2.3.6
2.3.6.1 2.3.6.2 2.3.6.3
Step 5 Termination of mobile NFC service ..........................................................................39
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
AFSCM Interface Specification V1.2 November 2009 AFSCM Confidential & Proprietary p3/98
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 users request.................................57 3.3.18 Process 17 End user calls the Service Providers customer service .................................58 3.3.19 Process 18 End user calls the Mobile Network Operators 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
p5/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 users 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
p6/98
1
1.1
INTRODUCTION
Context
The Mobile Network Operators Bouygues Telecom, Orange and SFR have founded the AFSCM (Association Franaise du Sans Contact Mobile) to foster the development of mobile contactless services. The Service Providers Credit Mutuel, Socit Gnrale and Volia 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.
p7/98
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.
p8/98
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 Business Data Domain / Task Functional principles and basic assumptions Roles and Responsibilities Process and constraints Protocol Requests format Data structure Reference chapter
2.1 Functional Principles 2.2 Basic assumptions 2.3 Process description 3.3 Processes supporting customer journey 3.2 Interface Connection and Exchange Protocol 3.4 Detailed Commands Description Appendix 1 Data dictionary
Business Process
Data Exchange
p9/98
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. .
p10/98
1.6
References
The following documents are available for the Service Providers: AFSCM [R1] [R2] [R3] [R4] [R5] NFC Applications Validation Process MIDlet Development Guide Cardlet Development Guide Secure Services Management Role Guidelines for interconnection of Service Providers' and MNOs' Information Systems
Payez Mobile (AEPM) [R6] [R7] [R8] [R9] 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 Book 0 - General Description v1.1 Book 1 - Mobile Handset UICC Applications v1.1 Book 2 - Payment Service Delivery & Management v1.1 Book 3 - Payment Processing v1.1
1.7
Acronyms and abbreviations

ACF AEPM AFSCM BIP DM ISD KIC KID KIK MMI MNO NFC RFU SP SSD UICC Access Control File Association Europenne Payez Mobile Association Franaise du Sans Contact Mobile Bearer Independent Protocol Delegated Management Issuer Security Domain SSD key for encrypting data exchanged OTA via the SSD SSD key for signing data exchanged OTA via the SSD SSD key for encrypting keys to be loaded in the SSD Man Machine Interface Mobile Network Operator Near Field Communication Reserved for Future Use Service Provider Supplementary Security Domain Universal Integrated Circuit Card (usually known as SIM card)
p11/98
1.8
Definitions
Application Delegated management ID_TECH Mobile equipment Mobile NFC service Opt-in SERV_ID Simple SD SSD_Manager Short name for the UICC application Pre-authorized Card Content changes performed by an approved Service Provider defined in Global Platform Technical Identifier of the line (unique for a given line and a given mobile NFC service) Represents the combination of a mobile handset and a UICC Represents the combination of a UICC application and a MMI Invitation presented to the end user for getting his approval or rejection for instance for downloading the MMI. Identifier a mobile NFC service SSD management only performed by the MNO mentioned as "SSD without Application Management Privileges" in GlobalPlatform Entity that manages the NFC platform and technical interface on behalf of a Service Provider
p12/98
2
2.1
FUNCTIONAL REQUIREMENTS
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.
p13/98
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 Providers 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.
p14/98
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 Operators 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.
p15/98
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 Choice Covers a process already described
Optional action or process
End of a process
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.
Process global mapping
Step 1 Inquiry
Inquiry to Service Provider Process 1
Inquiry to MNO Process 2
Step 2 Subscription
Subscription at SPs local office or web site Process 3
Subscription from mobile handest via WAP session Process 3 WAP
Optional process Service Provider decision to use one or many of these channels
Install UICC application Process 4
Update UICC application Process 4 Update
Optional process if SP wants to do OTA update
Step 3 Installation
Install / Update MMI Process 5
Conditional Process Mandatory if MMI is necessary
Change UICC Process 6
Lost/stolen Mobile equipment. Contact MNO Process 9
Lost/stolen Mobile equipment. Contact SP Process 10
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
Step 4 - Usage
Change Mobile Phone Number - Process 7
Change Mobile Handset - Process 8
Recover Mobile equipment Process 11
Get a new Mobile equipment Process 12
Step 5 Termination
Termination of Mobile subscription or NFC option by end user - Process 14
Termination of Mobile service by MNO - Process 15
Termination of mobile NFC service Process 19
p16/98
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 users 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.
Process N1 End user asks his Service Provider about available mobile NFC services End user Service Provider
Inform the End user about: - mobile NFC services - subscription requirements
Step 1 : Inquiry
Is the End user eligible?
No
Ask the end user to contact his MNO
Step 2: Subscription
Process n3 SUBSCRIBE to a mobile NFC service
Yes
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 users 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.
p17/98
Process N2 - End user asks his MNO about available mobile NFC services End user Mobile Network Operator
Step 1: Inquiry
End user inquires about mobile NFC services
Inform the end user about contractual and technical prerequisites as well as Service Provider requirements
Step 2 Intermediate step: provide end user with NFC device Subscription
Does the end user wish to buy one? No Yes End
No
Does end user have an NFC device?
Sell an NFC device
Yes No Does the end user wish to subscribe to the offer ? No Does the current end user offer allow the access to NFC services?
Yes Yes Sell appropriate offer
Ask the end user to contact his targeted Service Provider to subscribe to a mobile NFC service
Process n3 SUBSCRIBE to a mobile NFC service
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 users 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.
p18/98
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.
Process N3 Subscription at Service Providers local office or on web site End user
Case 1 Case 2
Service Provider
Mobile Network Operator
Scoring by Service Provider (optional)
End No
No
Service Provider approval ?
Yes Ask the End users mobile phone number and his approval for checking its elibigility to NFC service (legal impacts)
End user approval?
Yes Example of end user and mobile authentication by the mean of an authentication key
Step 2: Subscribe to a mobile NFC service
SMS reception. Communicate the authentication key to the Service Provider
Short leadtime (except if network troubles)
Send SMS containing an authentication key to end user
Authentication key match?
No
Yes
Request for eligibility of end user
Verify eligibility for this mobile phone number
Inform End user to contact his MNO, specifying the reason why he is not eligible
No
Is end user eligible from MNO perspective? Yes
Step 3
Process n4 Install the mobile NFC service
p19/98
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. Restrictions specific to version 1 The restrictions regarding the eligibility check and memory space mentioned in process 3 also apply for this process.
Process N3 Subscription via a WAP session End user Service Provider (WAP site) Mobile Network Operator
Case 1 Case 2
Access to WAP site. The Service Provider collects the mobile handset identifier from the WAP session data
Step 2: Subscribe to a mobile NFC service
Scoring by Service Provider (optional)
End
No
Service Provider approval ?
Yes Verify eligibility for this mobile handset, based on provided technical identifier
Request for eligibility of end user
No
Is end user eligible from MNO perspective?
Yes
Step 3
Process n4 Install the mobile NFC service
p20/98
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 users 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 users 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 Providers 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
Package
Instance 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 users 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.
p21/98
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 users mobile handset, therefore highlighting all the items that will need to be installed OTA.
ISD
SP SSD
Package
Instance
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 users UICC. [Note] For this Full preloaded scenario, the Service Provider only needs to send an activation request to the MNO.
ISD
SP SSD
Package
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. 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.
ISD
Restrictions specific to version 1 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 Operators 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.
p22/98
Process N4 Installation of UICC application End user Service Provider

Install the mobile NFC service on the UICC
Initiate installation
Inform End user of failure
Inform Service Provider of failure
No
Successful installation?
Yes
Inform SP of successful installation Application personalisation
Step 3 Mobile NFC service installation
Notify the MNO about the personalisation completion
Request for activation
Activate the mobile NFC service
Inform Service Provider of failure
No
Successful activation? Yes Inform Service Provider of successful activation
Yes
Process 5 MMI installation
p23/98
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 Providers decision. If not implemented it means that the application deployed in the UICC cannot be updated OTA.
Process N4 Update Update of UICC application End user Service Provider Mobile Network Operator
Update of the mobile NFC service by the Service Provider
Replace/renewal of NFC offer (upon request of end user or SP)
Inform end user about temporary service suspension
After some leadtime, request application deletion
Delete application and inform SP
Subscription process Request for elegibility
Step 3 Install Mobile NFC Service
No
Sign contract or contract amendment is necessary
Process n4 Install UICC application
p24/98
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 Providers 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 dont 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 Providers MMI server in order to load the MMI application on the end users 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 Providers 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. The MMI code (.JAD) includes an url to which a notification message is sent once the MMI is installed on a mobile handset.
[Note]
p25/98
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 Providers responsibility to decide: i. to suppress or not the UICC application, ii. to inform the end user in case of installation failure.
p26/98
MMI update When the Service Provider needs to update the MMI on the end users 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.
p27/98
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 Providers customer service (Process 17) End user calls the Mobile Network Operators customer service (Process 18)
The support of all these processes is mandatory to implement a mobile NFC service and ensure a consistent end users 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 users 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. Restrictions specific to version 1 Pre notification to inform Service Providers before UICC change is not available in version 1.
p28/98
Process N6 Change UICC
Before UICC end of life
End user
Service Provider
Change of a UICC that is still working
Step 4: Use mobile NFC service
UICC out of order needs to be replaced
Deactivate previous UICC and activate new UICC
Destroy previous UICC (as mentionned in contract) Further steps to be defined by each Service Provider Deployment of Service Provider policy
Inform end user that his mobile NFC services need to be reinstalled and will be resintalled
Notify Service Provider about UICC change
Step 3
Process n4 Install a mobile NFC service
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;
Process n7 Change mobile phone number (without changing UICC, mobile handset or MNO) End user Service Provider Mobile Network Operator
End user wants to change his mobile phone number and contacts his MNO
Provide a new mobile phone number to the end user
Notify Service Provider about the change of ID_TECH for the end user
End
p29/98
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 users 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.
p30/98
Process N8 End user changes his mobile handset End user

End user inserts his SIM into the new NFC mobile handset
Service Provider
Mobile Operator
Local detection that MMI are missing ?
No
Remote detection of the change of handset
Is the new mobile handset NFC compliant? Yes Yes
No
End user can not benefit from his mobile NFC services.
No
Do you want to load missing MMI ?
Invite end user to download MMI
Notify Service Providers about new mobile handset
Yes Process n5 Install a mobile NFC MMI
End user can not benefit from full capacity of 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 Operators 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 users 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.
p31/98
[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.
Process N9 End users mobile equipment was lost or stolen. End user contacts his MNO End user
End user contacts his MNO
Service Provider

Identify End user of mobile NFC service
Launch appropriate process (blacklist)
Notify lost/stolen mobile to the Service Provider(s)
Contact his Service Provider
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. Try to lock the mobile NFC services OTA if possible before line suspension
Suspend the mobile connection
No
Was blocking successful ?
Notify the Service Providers 1) About end of mobile connection 2) and the locking status
Blacklist the end users mobile NFC service
Yes
Launch appropriate process (blacklist)
[Note] The actions identified with * are processed in parallel
Confirm the request for blacklisting the mobile NFC service
Notify MNO about applicative locking
p32/98
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 users 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
Process N10 End users mobile equipment was lost or stolen. End user contacts his Service Provider End user Service Provider MNO
End user contacts his Service Provider
Identify and authenticate End user for mobile NFC service. Inform end user to contact his MNO
Service Provicer launches appropriate process (on hold )
Attempt to lock OTA the mobile NFC application
Notify MNO about locking status
Is mobile NFC service blocking effective?
Yes
End of Process
No
Confirm to Service Provider the request for blacklisting the mobile NFC service
Service Provider update information system
p33/98
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 users 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.
Process n11 After a loss or theft, the End user recovers his mobile equipment and UICC End user Service Provider Mobile Network Operator
Restore the mobile connection and inform End User
Try to unlock the mobile NFC services OTA
Notify the Service Provider(s)
No
Was the mobile NFC Service blacklisted?
Unlock service on Information System
Yes Delete previous application
Was the mobile NFC Service OTA locked ? No Yes OTA Unlock mobile NFC service
Reinstall mobile NFC service
Process n4 Install mobile NFC service
Notify MNO
Inform End user that mobile NFC service is ready to use
p34/98
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.
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 End user Service Provider Mobile Network Operator
Restore end users mobile connection
Check End users mobile equipement
Get a NFC mobile equiment
No
Is new mobile equipement NFC compliant? Yes
Process N2 End user inquires to MNO (intermediate step to get a mobile NFC device) Service Provider wants to contact End user before loading ? No Yes
Notify Service Provider to launch installation process
Communication with Service Provider
Process n4 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) Restrictions specific to version 1 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.
p35/98
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. Restrictions specific to version 1 In version 1, Mobile Network Operators do not have the possibility to send forecast notifications to the Service Providers.
Process N16 End User requests temporary mobile service suspension End user Service Provider Mobile Network Operator
Acknowledge end users request and agree on suspension date and restore date
End User requests temporary mobile service suspension
Transfer entitlements and applicative lock of service on SP information system
At suspension date, suspend the line and notify the Service Providers
Notify MNO End User requests line restore before or at earlier agreed date At restore date, restore the line and notify the Service Providers
Unlock service on SP information system
Notify MNO
p36/98
2.3.5.10 Process 17 End user calls the Service Providers customer service The end user contacts his Service Providers 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. Restrictions specific to version 1 The information exchanged for customer service purpose (NFC customer file) is handled by employees and not on the IT interface described in this document.
Process N17 End user calls the Service Providers customer service End user Service Provider Mobile Network Operator
End user contacts Service Provider
Initiate customer care process
No
Issue related to Service Provider?
Contact MNO
No
End user already called MNO? Yes
Yes
Analyse the issue
Issue solved by Service Provider?
No No
Issue related to MNO?
Yes. Send a NFC Customer Care file Yes Initiate customer care process
No
Issue solved? Yes
End
Inform end-user
Inform Service Provider that the issue is solved
p37/98
2.3.5.11 Process 18 - End user calls the Mobile Network Operators customer service The end user contacts his Mobile Network Operators 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. Restrictions specific to version 1 The information exchanged for customer service purpose (NFC customer file) is handled by employees and not on the IT interface described in this document.
Process N18 End user calls the MNOs customer service End user Service Provider Mobile Network Operator
End user contacts MNO
Initiate customer care process
No
Issue related to MNO?
Contact Service Provider
No
End user already called Service Provider? Yes
Yes
Analyse the issue
No
Issue solved by MNO?
No
Issue Related to Service Provider ?
Analyse the issue
Yes Open a NFC customer care file
Yes
No Issue solved
Yes
Inform MNO that the issue is solved End
Inform End user
p38/98
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. Restrictions specific to version 1 Pre notification to inform Service Providers before Mobile subscription or NFC option termination is not available in version 1.
Process N14 Termination of Mobile line subscription OR NFC option by end user End user
End user wants termination of its mobile subscription or NFC option
Service Provider

Acknowleldege request for termination And agree with end user on termination date
[Note] Proposition for a reflexion time of minimum 10 days between customer request and termination date Reflexion time
Inform End user that he should either use the remaining rights in his mobile or contact his Service Providers for transferring his rights to another support
At termination date
At termination date, definitely stop mobile service or NFC option
Transfer end users entitlements
Notify Service Provider about line or NFC option termination
Step 5: Termination
Applicative lock of service on SP Information System
End user is responsible for destroying his UICC in case of mobile service termination
Notify MNO about lock status
p39/98
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 users 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 users 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. Restrictions specific to version 1 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.
p40/98
Process n15 Termination of mobile service by MNO End user

End user doesnt respect the MNOs contract conditions
Service Provider
Initiate the dispute process
Notify End user about related risks and inform about suspension date of mobile service
End user settles the situation
No
Initiate process for mobile service suspension and notify again the end user
Suspension
Yes End Suspend End users line and notify Service Provider about line suspension
End user settles the situation
No
Initiate process for End users mobile service termination
Yes
Restore the line and Notify Service providers
Definitly stop End users line access to mobile NFC services
Step 5: Termination
End user is responsible for destroying his UICC in case of mobile service termination
Transfer entitlements and applicative lock on SP information system
Notify Service Providers about end of mobile service,
Notify MNO about locking
p41/98
2.3.6.3 Process 19 Mobile NFC service termination Two reasons can lead to the mobile NFC service termination: - Upon end users 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.
Process n19 Termination of mobile NFC service / Process n19 End user Service Provider Mobile Network Operator
End user wants to suppress mobile NFC service from his mobile
Service Provider terminates the End users mobile NFC service
Step 5: Termination
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
Inform End user about end of mobile NFC service
End of mobile NFC service on Information System
p42/98
3
3.1
INTERFACE SPECIFICATION
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
SERVICE PROVIDER / MOBILE OPERATOR INTERFACE
MOBILE OPERATOR DOMAIN

Network Access
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.
p43/98
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. 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. 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
3.2.2
3.2.3
Generate a request and a unique transaction identifier Receives acknowledgement
CREATE_SSD_REQ (abc)
Receives the request
ACKNOWLEDGE
Acknowledge the reception of the request Perfoms the actions for SSD creation
Receives response Acknowledge the reception of response
CREATE_SSD_RESP (abc)
Send response with the transaction identifier
ACKNOWLEDGE
Receives acknowledgement
[]
Sends a notification after end user call to declare mobile phone lost NOTIF_CALL_ENDUSER ACKNOWLEDGE
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.
Request an ID_TECH
ID_TECH_REQ
Receives the request Generates the ID_TECH
Receives response
ID_TECH_RESP
Send response with the ID_TECH
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. 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)
p45/98
3.2.6
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.
p46/98
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:
Service Provider Mobile Operator UICC
Asynchonous REQUEST Asynchonous RESPONSE
Synchronous REQUEST or NOTIFICATION Synchronous RESPONSE
Action on Mobile Operator information system
Action on Service Provider information system
OTA action of Mobile Operator
OTA action of Service Provider Or reference to an entire process
Optional or conditional step
Optional Process
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. 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.2
p47/98
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_REQ ID_TECH Generation 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 Providers 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 Operators platform before submitting requests for loading the package. Once the UICC application is installed, the Service Provider installs the MMI Process 5. Restrictions specific to version 1 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
Service Provider
Option: can be done in factory and attributed in advance SSD Creation SSD_CREATION_RESP
Mobile Operator
UICC
SSD_CREATION_REQ SSD Creation
Option: If SSD not already available on UICC
SSD Key Replacement
Option: upon SP decision
Option: for banking application
LONG_AID_REQ
Long AID Generation
LONG_AID_RESP
Option: can be done in factory
INSTALL_REQ (LOAD) Package Loading INSTALL_RESP Option: package can be preloaded on UICC
Application package loading
Application installation
INSTALL_REQ (INSTALL) Application Instance Creation and Extradition INSTALL_RESP Option: instance can be pre loaded on UICC
Application Personalization Application personalisation and activation
Option: personalisation can be done in factory
INSTALL_REQ (ACTIVATE) Application Activation INSTALL_RESP
Figure 9 - Process 4 Installation of UICC application in Simple SD
p49/98
3.3.5
Process 4 Update UICC application update This process for OTA update is optional upon Service Providers 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.
Service Provider
Mobile Operator
UICC
Suppress previous UICC application
SUPPRESS_REQ (Application and instance) Delete application instance and package if possible SUPPRESS_RESP
ID_TECH_REQ Request for eligibility
Keep same ID_TECH, check memory space available
ID_TECH_RESP
INSTALL_REQ (LOAD) Application package loading INSTALL_RESP Package Loading
INSTALL_REQ (INSTALL) Application installation Application Instance Creation and Extradition INSTALL_RESP
Application personalisation and activation
Application Personalization INSTALL_REQ (ACTIVATE) Application activation INSTALL_RESP
Figure 10 - UICC application update
p50/98
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 Providers 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 Providers 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.
p51/98
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.
Mobile handset
Service Provider
Mobile Operator
Option: if ACF is used
INSTALL_MMI_REQ (ACF) ACF loading in UICC INSTALL_MMI_RESP
SMS push WAP
MMI installation NOTIF_SP_ACTION (Download MMI OK, MMI version)
Figure 13 - Process 5 MMI Installation launched by Service Provider
p52/98
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 users 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
Service Provider Mobile Operator UICC Mobile handset
Lock UICC application NOTIF_SP_ACTION (Application locked) MMI Installation Case 1 or Case 2
Unlock UICC application NOTIF_SP_ACTION (Application unlocked)
Figure 14 - Critical MMI update
p53/98
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.
Old UICC deactivation New UICC activation NOTIF_NEW_DEVICE (UICC) Process 4 - Install the mobile NFC service
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 users 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
p54/98
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.
NOTIF_CALL_ENDUSER_TO_SP (Loss or Theft) NOTIF_CHANGE_TO_SP (App locked and Line suspended) Applicative lock on IT system if OTA lock failed
MNO tries to lock application via OTA AND suspends phone line
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).
NOTIF_CALL_ENDUSER_TO_MNO (Loss or Theft) Service Provider attemps to lock application via OTA Applicative lock on IT system if OTA lock failed
NOTIF_SP_ACTION (Application locked)
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 users 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.
p55/98
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 users 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).
Reactivation of the end users line Provide new UICC and new mobile phone to end user
UICC
NOTIF_NEW_DEVICE (UICC+Mobile phone)
Process 4 Mobile NFC application Installation
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 Restrictions specific to version 1 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 users 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.
p56/98
Service Provider
Mobile Operator
UICC
Terminate line or NFC option NOTIF_CHANGE_TO_SP (Line or NFC option terminated) 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 users 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 users 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).
Inform end user about suspension date At suspension date Suspend end users line
UICC
NOTIF_CHANGE_TO_SP (Line suspended)
REGULATION
Restore end users line NOTIF_CHANGE_TO_SP (Line activated)
Option: If end user regulates situation
Transfer entitlements Applicative lock of the service on SP Information System
NOTIF_CHANGE_TO_SP (Line Terminated) NOTIF_SP_ACTION (Locked on IT system)
At termination date Definitely stop end users line
Figure 23 - Process 15 Termination of mobile service by MNO
3.3.17 Process 16 Suspension of mobile service upon end users request At suspension date agreed with the end user, the Mobile Network Operators suspends the end users 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).
p57/98
At restore date, the Mobile Network Operator restores the end users 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.
At suspension date agreed with end user Suspend end users line NOTIF_CHANGE_TO_SP (Line suspended) Transfer entitlements Applicative lock of the service on SP Information System NOTIF_SP_ACTION (Locked on IT system) At restore date agreed with end user Restore end users line
NOTIF_CHANGE_TO_SP (Line restored) Applicative unlock of the service on SP Information System NOTIF_SP_ACTION (Unlocked on IT system)
Figure 24 - Suspension of mobile service upon end users request 3.3.18 Process 17 End user calls the Service Providers 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 Operators 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_REQ (ID_SERV) Delete application instance, SSD, ACF if relevant and package if possible SUPPRESS_RESP
Figure 25 - Process 19 Termination of mobile NFC service
p58/98
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 SERV_ID SERV_VERSION ID_MNO ID_TECH SSDM_ID PRIORITY_INDEX Description Mobile NFC Service Identifier Mobile NFC Service version MNO Identifier Technical Identifier of the line SSD Manager Identifier Index of priority. Default value set to 0 Type Mandatory Optional (1) Mandatory Mandatory Optional (RFU) 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. Name REQUEST_ID SERV_ID SERV_VERSION ID_MNO ID_TECH SSDM_ID PRIORITY_INDEX Description Transaction identifier (unique) Service Identifier Mobile NFC Service version MNO Identifier Technical Identifier of the line SSD Manager Identifier Index of priority. Default value set to 0 Type Mandatory Mandatory Optional (1) Mandatory Mandatory Optional (RFU) 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.
p59/98
HEADER_3 Header for ID_TECH_REQ This header is applicable to the ID_TECH_REQ synchronous request. Name SERV_ID SERV_VERSION ID_MNO SSDM_ID PRIORITY_INDEX Description Mobile NFC Service Identifier Mobile NFC Service version MNO Identifier SSD Manager Identifier Index of priority. Default value set to 0 Type Mandatory Optional (1) Mandatory Optional (RFU) 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.
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 SP Name
SYNCH_STATUS
MNO_ACKNOWLEDGE Exchange Mode : Description Set to 0 to confirm that the synchronous controls are OK. Synchronous Presence 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 MNO SP_ACKNOWLEDGE Exchange Mode : Synchronous
p60/98
Name
SYNCH_STATUS
Description Set to 0 to confirm that the synchronous controls are OK.
Presence 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.
p61/98
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 Name
ERROR_TYPE ERROR_DETAILS
EXCEPTION Exchange Mode : Synchronous Presence Mandatory

Optional
MNO SP or SPMNO Description
Indication of the type of error encoutered. Possible values described in 0. Indication of the data that failed the control. Data identifier (ex : MNO_ID, ID_TECH, AID_SSD_INST,.)
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.
p62/98
Service Provider
Mobile Operator
CREATE_SSD_REQ (abc)
Controls OK on NFC platfom OK Acknowledge the reception of the request
ACKNOWLEDGE
CREATE_SSD_RESP (abc) ACKNOWLEDGE
Perfoms the actions for SSD creation and sends response with the transaction identifier
INSTALL_REQ (bcd)
Controls NOK on NFC platfom Sends an EXCEPTION with information on the error decetected Controls OK on NFC platfom OK
B
EXCEPTION
ID_TECH_REQ
C
ID_TECH_RESP Generates the ID_TECH Send response with the ID_TECH
LONG_AID_REQ
Controls NOK on NFC platfom Sends an EXCEPTION with information on the error decetected
D
EXCEPTION
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 users 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.
p63/98
ID_TECH Life Cycle The table below summarizes impacts of end user cases on ID_TECH life cycle. End User Cases
Service activation Termination, deactivation mobile services UICC 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) MSISDN modification Former MNO suppress old Suppress old ID_TECH. ID_TECH. Receive new ID_TECH New MNO generate new ID_TECH Suppress old ID_TECH Generate new ID_TECH Suppress old ID_TECH. Receive new ID_TECH No change No change
ID_TECH Status (MNO)

Generate Suppress
ID_TECH Status (SP)

Receive Suppress
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.
p64/98
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 users MSISDN - Subscription via a WAP session (Process 3 WAP) send end users mobile ALIAS - In case of application update (Process 4 Update) send end users 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 SP MNO Name HEADER_3 CUSTOMER_ID_TYPE ID_TECH_REQ Exchange Mode : Description Synchronous Message Header for ID_TECH_REQ Customer Identifier Type
Possible values: 01 02 03 MSISDN ALIAS ID_TECH
Synchronous Presence Mandatory Mandatory Mandatory
CUSTOMER_ID
Customer Identifier value
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. 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.
p65/98
3.4.8
ID_TECH_RESP
Description and prerequisites 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 MNO SP Name ID_TECH ICC_ID CARD_PROFILE ID_TECH_RESP Synchronous Description Presence Technical Identifier of the line Conditional UICC identifier Optional (1) Reference to a smart card manufacturer and operating Conditional (2) system Exchange Mode :
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 Description and prerequisites 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 Name Description Presence 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
p66/98
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 Description and prerequisites 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 MNO SP Name REQUEST_ID SSD_TABLE SSD_CREATION_RESP Exchange Mode: Description Transaction identifier (unique) Up to 2 occurences of :
AID_SSD_INST KEY_TABLE AID of the SSD 3DES key. 3 occurences one per key transmitted. Attributes: TYPE 0:KIC, HEX (1) 1:KID 2:KIK 3:MAC 4:KEK 5:ENC 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 (16)
Asynchronous Presence
Mandatory Conditional (2)
RESPONSE_CO DE
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 Description and prerequisites 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 SP MNO Name HEADER_1 AID_SHORT_TABLE Example: AID_APP_SHORT 12 34 56 AB CD EF 11 22 33 44 55 66 Description Synchronous Message Header Up to 5 short AIDs can be sent.
AID_APP_SHORT Nb of expected Long AIDs
LONG_AID_REQ Exchange Mode : Synchronous Presence Mandatory Mandatory
Number of expected corresponding Long AIDs 2 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 Description and prerequisites [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 MNO SP Name AID_LONG_TABLE
AID_APP_SHORT
LONG_AID_RESP Exchange Mode: Description Up to 10 short AIDs can be sent

AID_APP_INST
Synchronous Presence Mandatory
Resulting actions The Service Provider updates its information system with the long AIDs received. Example:
AID_APP_SHORT
12 34 56 AB CD EF 12 34 56 AB CD EF 11 22 33 44 55 66
Long AIDs corresponding = AID_APP_INST 12 34 56 AB CD EF 00 00 00 00 00 00 00 00 00 01 12 34 56 AB CD EF 00 00 00 00 00 00 00 00 00 02 11 22 33 44 55 66 00 00 00 00 00 00 00 00 00 01
p68/98
3.4.13 INSTALL_REQ Description and prerequisites [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 Operators 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.
p69/98
FUNCTION SP MNO Name HEADER_2 INSTALL_STEP
INSTALL_REQ Exchange Mode : Description Message Header for Asynchronous Request Defines the different installation steps applicable to the request INSTALL_REQ.
Possible values: 01 02 03 LOAD INSTALL ACTIVATE
Asynchronous Presence Mandatory Mandatory
INSTALL_TABLE
Up to 10 occurrences of following records

AID
Optional (1) and (2)
INSTALL_PARAM_INDEX Refers to a set of GP installation parameters DAP DAP Signature value 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.
p70/98
3.4.14 INSTALL_RESP Description and prerequisites [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 not sufficient. FUNCTION MNO SP Name REQUEST_ID RESPONSE_CODE INSTALL_RESP Exchange Mode: Description Transaction identifier (unique) See section A1.2 (Response Code Table) Asynchronous Presence Mandatory Mandatory space
p71/98
Resulting actions LOADING STEP Once the Service Provider has confirmation that the package is available on the end users 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 Description and prerequisites 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. -
p72/98
FUNCTION SP MNO Name HEADER_2 MMI_ACTION
INSTALL_MMI_REQ Exchange Mode : Description Message Header for Asynchronous Request List the action to be done by the MNO:
Possible values: 01 02 03 MMI only MMI with retries ACF only
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 Providers MMI server. 3.4.16 INSTALL_MMI_RESP Description and prerequisites 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 MNO SP Name REQUEST_ID RESPONSE_CODE INSTALL_MMI_RESP Exchange Mode: Description Transaction identifier (unique) See section A1.2 (Response Code Table) Asynchronous Presence Mandatory Mandatory
Resulting actions In case 1, the MMI download is done from the Service Providers 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).
p73/98
3.4.17 SUPPRESS_REQ Description and prerequisites 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 SP MNO Name HEADER_2 DELETE_SSD SUPPRESS_REQ Exchange Mode : Description Message Header for Asynchronous Request To indicate whether MNO should try or not to delete the SSD.
Possible values: 0 1 0 1 Do not delete SSD Delete SSD if possible For termination For update
DELETE_REASON To indicate the reason of the removal.

Possible values:
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 Description and prerequisites 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 SP MNO Name REQUEST_ID RESPONSE_CODE SUPPRESS_RESP Exchange Mode : Description Transaction identifier (unique) See section A1.2 (Response Code Table) Asynchronous Presence Mandatory Mandatory
Resulting actions The Service Provider can delete the information related to this end user from his information system.
p74/98
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 Description and prerequisites 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 users 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 SP MNO Name HEADER_1 ACTION_STATUS NOTIF_SP_ACTION Exchange Mode : Description Synchronous Message Header 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 00 10 DOWNLOAD MMI GP LOCKED APPLICATION GP UNLOCKED APPLICATION LOCKED on IT system UNLOCKED on IT system Applicative LOCKED Applicative UNLOCKED OK Failed MMI_VERSION N(2)
Synchronous Presence Mandatory Mandatory
STATUS COMPL
N(2) Hex (var)

p75/98
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 Description and prerequisites This notification is used by the Service Provider receiving the end users call in case of loss of theft of his mobile equipment to inform the Mobile Network Operator (Process 10). FUNCTION SP MNO Name HEADER_1 REASON DATE_TIME_CALL NOTIF_CALL_ENDUSER_TO_MNO Exchange Mode : Description Synchronous Message Header Operation justification
Possible values: 11 13 Mobile loss Mobile theft
Synchronous Presence Mandatory Optional Mandatory
Date / time of the declaration call
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 Description and prerequisites 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 MNO SP Name HEADER_1 DEVICE [Note] NOTIF_NEW_DEVICE Exchange Mode : Description Synchronous Message Header To list which device was changed:
Possible values: 01 02 03 UICC Mobile handset UICC + mobile handset
The reception of this notification for a new UICC implicitely means that the previous UICC is deactivated.
p76/98
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 Description and prerequisites 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 MNO SP Name HEADER_1 NEW_ID_TECH NOTIF_CHANGE_ID_TECH Exchange Mode: Description Synchronous Message Header New Technical Identifier of the line Synchronous Presence Mandatory 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 Description and prerequisites This notification is used by the Mobile Network Operator receiving the end users call in case of loss of theft of his mobile equipment to inform the Service Provider (Process 9). FUNCTION MNO SP Name HEADER_1 REASON DATE_TIME_CALL LINE_STATE NOTIF_CALL_ENDUSER_TO_SP Exchange Mode: Description Synchronous Message Header Operation justification
Possible values: 11 13 Mobile loss Mobile theft
Synchronous Presence Mandatory Optional Mandatory Mandatory
Date / time of the declaration call Define the MNOs line state
Resulting actions The Service Provider keeps record of this information related to the end user in his information system.
p77/98
3.4.24 NOTIF_CHANGE_TO_SP Description and prerequisites 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 users 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 MNO SP Name HEADER_1 NEW_STATUS NOTIF_CHANGE_TO_SP Exchange Mode: Description Synchronous Message Header Gives the new status of the mobile service or NFC service after an action. Up to 4 occurences.
Possible values: 01 02 03 04 10 11 12 20 21 Line ACTIVATED Line RESTRICTED Line SUSPENDED Line TERMINATED Application UNLOCKED Application LOCKED Application DELETED NFC option activated NFC option terminated
DATE_TIME_CHANGE Allow to retrieve the effective date of the application and / or line status changing REASON Operation justification. See A1.1 for possible values
Mandatory 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.
p78/98
Appendix 1
A1.1 List of data
Name ACTION_STATUS
DATA DICTIONARY
Description Application installation status Up to 5 occurences STEP 01 LOAD APPLICATION 02 INSTALL APPLICATION 03 PERSONALISATION 04 ACTIVATE APPLICATION 05 DELETE APPLICATION 06 DOWNLOAD MMI 07 GP LOCKED APPLICATION 08 GP UNLOCKED APPLICATION 09 LOCKED on IT system 10 UNLOCKED on IT system 11 Applicative LOCKED 12 Applicative UNLOCKED STATUS 00 OK 10 Failed COMPL Complementary information: - GP response if appropriate - Token receipt - MMI_VERSION Application Instance AID Payment Application Short Identifier SSD Instance AID Customer Identifier Type Possible values: 01 MSISDN 02 ALIAS 03 ID_TECH Customer Identifier value DAP signature Date / time of the declaration call Allow to retrieve the effective date of the application and / or line status changing Format Length Critical
N(2)
N(2) Hex (var)
AID_APP_INST AID_APP_SHORT AID_SSD_INST
CARD_PROFILE
CUSTOMER_ID_TYPE
Reference to a smart card manufacturer and operating system
Hex (5 to 16) Hex (5 to Hex (5 to 16) AN (16) N (2)
X X X
CUSTOMER_ID DAP DATE_TIME_CALL DATE_TIME_CHANGE
To be defined Hex (var) AN (19) AN (19) N (1)
DELETE_REASON
To indicate the reason of the removal.

Possible values: 0 1 For termination For update
DELETE_SSD
To indicate whether MNO should try or not to delete the SSD.

0 Do not delete SSD 1 Delete SSD if possible To list which device was changed: Possible values: 01 UICC 02 Mobile handset 03 UICC + mobile handset Indication of the type of error encountered. Exclusively used in the synchronous response EXCEPTION. Possible values described in 0. Possible values:
N (1)
DEVICE
N (2)
ERROR_TYPE
N (3)
p79/98
Name ERROR_DETAILS GP_COMMAND HEADER_1 HEADER_2 HEADER_3 ICC_ID ID_MNO
Description Indication of the data that failed the control. Data identifier (ex : MNO_ID, ID_TECH, AID_SSD_INST,.) GP command to be signed by a token calculation Message Header for Synchronous Request cf description in 3.4.1 Message Header for Asynchronous Request cf description in 3.4.1 Message Header for ID_TECH_REQ cf description in 3.4.1 Unique value per UICC containing card profile. Can be used in the keys diversification process 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 MNC MNO Code true to the ITU E.212 Norm. RFU Reserved For Future Use N(3)
Format Length AN (var) Hex (var)
Critical
N(20) N (var 8 or 9)
N (var 2 or 3) N (3) AN (max 16) Hex (1) X
ID_TECH INSTALL_PARAM_IND EX INSTALL_STEP
Technical Identifier of the line Refers to a set of GP installation parameters
Defines the different installation steps applicable to the request N(2) INSTALL_REQ. Possible values: 01 LOAD 02 INSTALL 03 ACTIVATE
INSTALL_TABLE
Up to 10 occurrences of following records

AID
Hex (var)
INSTALL_PARAM_INDEX Refers to a set of GP installation parameters DAP DAP Signature value

KEY_TABLE
Up to 2 occurences of :
AID_SSD_INST KEY_TABLE AID of the SSD
Hex (var) Hex (16)
3DES key. 3 occurences one per key transmitted. Attributes: TYPE 0:KIC, HEX (1) 1:KID 2:KIK 3:MAC 4:KEK 5:ENC INDEX Key index Hex (1) VERSION Key version Hex (1) KEY_VALU Value of key (not Hex (16) E encypted) KEY_KCV Check sum of the key Hex (8) N (2)
LINE_STATE
MMI_ACTION
Defines the MNOs line state Possible values: 01 Line ACTIVATED 02 Line RESTRICTED 03 Line SUSPENDED 04 Line TERMINATED List the action to be done by the MNO: Possible values: 01 MMI only
N(2)
p80/98
Name
Description 02 MMI+ACF 03 MMI only including retries 04 MMI including retries +ACF 05 ACF only Version of the Service Provider MMI application Mobile number (country code included)
Format Length
Critical
MMI_VERSION MSISDN NEW_ID_TECH NEW_STATUS
Hex (3) AN (max 15) X
New Technical Identifier linked to the mobile line AN (max 16) Gives the new status of the mobile service or NFC service after an action. N (2) 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 Index of priority. Default value set to 0 Possible values: 0 No priority defined 1 Highest priority 2 Intermediate priority 3 Lowest priority 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 Response code (OK, warning or error). See section A1.2 (Response Code Table). Used in the asynchronous responses. N (1)
PRIORITY_INDEX
REASON
N (2)
RESPONSE_CODE
SC_MANUF
SERV_ID
Identifider of Smart Card Manufacturer

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. Version of the service SSD Manager Identifier Set to 0 to confirm that the synchronous controls are OK. Possible value: 0 Successful processing Token composed of TLV format data 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
Hex (1) N (5)
SERV_VERSION SSDM_ID SYNCH_STATUS TOKEN REQUEST_ID
N (3) N (1) Hex (var) AN (26 max) X X
p81/98
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.
Conditional
Mandatory
Optional
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.
p82/98
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. Mandatory
Service Provider notification to Mobile Network Operator
NOTIF_CALL_ENDUSER_TO_MNO
NOTIF_SP_ACTION
To notify Mobile Network Operator that end user has called the Service Provider in case of lost or stolen mobile equipment 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
NOTIF_CHANGE_ID_TECH NOTIF_CHANGE_TO_SP
To notify Service Providers that that end user has called the Service Provider in case of lost or stolen mobile equipment To notify Service Providers about change of ID_TECH 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 To notify Service Providers about device change (UICC and/or mobile handset)
NOTIF_NEW_DEVICE
Acknowledgment and Exception Mandatory
Acknowledge MNO_ACKNOWLEDGE SP_ACKNOWLEDGE EXCEPTION MNO acknowledges request or notification received from the Service Provider Service Provider acknowledges response or notification received from the MNO Synchronous response to signal a data or format error on the received request
p83/98
A1.3 List of processes
Conditional
Mandatory
Optional
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 Providers 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 Providers customer service Process 19 End user calls the Mobile Network Operators customer service
p84/98
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.
SSD_CREATION_RESP
INSTALL_MMI_RESP
RESPONSE_CODE
Description
000 020 042 090 200 202 204 220 221 222 224 225
K C C F F F F W W W W W
OK UICC not accessible Connection between MMI service and mobile handset failed Card fatal error Memory space not sufficient Error during application package loading Error during ACF loading Application Package already loaded Application already installed Application already activated Package absent on the UICC Application not installed
X X
X X
X X X
X X
X X X
X X X X X X
SUPPRESS_RESP
INSTALL_RESP
CODE_TYPE
X X
p85/98
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.
SSD_CREATION_REQ
INSTALL_MMI_REQ
LONG_AID_REQ
Description Value error Format error Service not provisioned Mandatory data missing Presence of unexpected data Unknown identifier Incompatible identifier with the requested action Not coherent with SSD privilege (1) Memory space not sufficient SSD already created/allocated for this Service Provider No SSD attributed to this Service Provider on UICC Application package already loaded Application already installed Application already activated Package absent on the UICC Application not installed NFC service not activated for this CUSTOMER_ID Incompatible with NFC services UICC not compliant with NFC services Mobile handset not compliant with NFC services Offer not compliant with NFC services Unexpected server error Quota overcome
001 002 003 004 005 006 007 012 200 210 211 220 221 222 224 225 400 401 402 403 404 900 901
D D D D D D D D F W W W W W W W I I I I I F F
X X X X X X X
X X X X X X X
X X X X X X X
X X X X X X X X
X X X X X X X X X
X X X X X X X
X X X X X X X
X X X X(1) X(1) X(1) X X X X X X X X X X X X X X X
X X X X X
X X
X X
X X
1. Optional, such controls depend on the Mobile Network Operator

SUPPRESS_REQ
ID_TECH_REQ
INSTALL_REQ
ERROR_TYPE
TOKEN_REQ
CODE_TYPE
A1.4.2
Error Response Code management Error description Connection error code Retries policy 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 The request was not necessary or the AFSCM sequence was not respected. The SP can continue or retry with the expected request. Definitive Error, no need to retry. SP should inform the end user and contact the MNO through After Sales services procedures. The parameters given in the request doesn't match with the expected by the MNO. The request can be retry with the correct parameters Definitive Error, no need to retry. The end user cannot benefit from NFC offer.
Code type C
Warning code
Fatal error code
Data error code
Incompatible Error code
p87/98
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).
p88/98
Process N4 Installation of UICC application Delegated Management Mode End user Service Provider
Request authorisation from the MNO

Deliver, if authorized, the tokens to the Service Provider
Initiate installation
Inform End user of failure
Install the mobile NFC service on the UICC
Notify MNO about failure No Successful installation?
Yes
Notify MNO about successful installation and send the receipts
Application personalisation
Notify the MNO about the personalisation completion and ask for activation authorization
Deliver, if authorized, a token to SP
Step 3 Mobile NFC service installation
Activate the mobile NFC service
Successful activation? Yes
No
Notify MNO about failure
Notify MNO about successful activation and send the receipt Yes
Process 5 MMI installation
p89/98
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.
Process N4 Update Update of UICC application Delegated Management Mode End user Service Provider Mobile Network Operator
Update of the mobile NFC service by the Service Provider Replace/renewal of NFC offer (upon request of end user or SP)
Inform end user about temporary service suspension
Request application deletion authorisation
Delete application and send a receipt to the MNO
Subscription process
Step 3 Install Mobile NFC Service
Request for elegibility
No
Sign contract or contract amendment is necessary
Process n4 Install UICC application
p90/98
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.
Process n19 Termination of mobile NFC service / Process n19 DM Mode End user Service Provider Mobile Network Operator
End user wants to suppress mobile NFC service from his mobile
Service Provider terminates the End users mobile NFC service
Launch process for mobile NFC service termination and request MNO authorisation to delete application
Application deletion
Notify and send receipt tokens to MNO
Step 5: Termination
Request Service deletion
Deletion of SSD and ACF if relevant
Inform End user about end of mobile NFC service
End of mobile NFC service on Information System
p91/98
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. 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.
[Note]
p92/98
Service Provider
Mobile Operator
UICC
SSD_CREATION_REQ SSD Creation SSD Creation SSD_CREATION_RESP
Option: If SSD not already available on UICC
SSD Key Replacement
Option: for banking application
LONG_AID_REQ
Long AID Generation
LONG_AID_RESP
TOKEN_REQ Request for token, n occurences TOKEN_RESP
Tokens calculation
Application Loading
Application Installation and Extradition
Application Personalization and Activation NOTIF_SP_ACTION (Token receipts)
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.
p93/98
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.
Service Provider
Mobile Operator
UICC
TOKEN_REQ For application instance + package deletion Suppress previous UICC application TOKEN_RESP
Delete application instance and package NOTIF_SP_ACTION (Token receipt) ID_TECH_REQ Request for eligibility Keep same ID_TECH, check memory space available ID_TECH_RESP
Repeated for: loading installation and extradition activation
TOKEN_REQ
TOKEN_RESP
Application Loading
Application Installation and Extradition
Application Personalization and Activation
NOTIF_SP_ACTION (Token receipt)
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.
p94/98
Service Provider
TOKEN_REQ
Mobile Operator
Token calculation
UICC
TOKEN_RESP
Delete application instance and package if possible NOTIF_SP_ACTION (Token receipt) SUPPRESS_REQ (ID_SERV) Delete SSD SUPPRESS_RESP
Figure 29 - Process 19 Mobile NFC service termination in Delegated Management
A2.3 Detailed commands

A2.3.1 TOKEN_REQ
Description and prerequisites [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 SP MNO Name HEADER_1 GP_COMMAND TOKEN_REQ Exchange Mode : Description Synchronous Message Header GP command to be signed by a token calculation Synchronous Presence Mandatory 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.
p95/98
A2.3.2
TOKEN_RESP
Description and prerequisites [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 SP MNO Name TOKEN TOKEN_RESP Exchange Mode : Description Token composed of TLV format data Synchronous Presence 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 Description and prerequisites 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
p96/98
FUNCTION SP MNO Name HEADER_1 ACTION_STATUS
NOTIF_SP_ACTION Exchange Mode : Description Synchronous Message Header Up to 5 occurences

STEP 01 02 03 04 05 06 07 08 00 10 LOAD APPLICATION INSTALL APPLICATION PERSONALISATION ACTIVATE APPLICATION DELETE APPLICATION DOWNLOAD MMI LOCK APPLICATION UNLOCK APPLICATION OK Failed Complementary information: N(2)
STATUS COMPL
N(2) Hex (var)
Token receipt. If the receipt was lost by the SP, the value could be null. This case shall be exceptional
Resulting actions The Mobile Network Operator updates the information for this end user in his information system. A2.3.4 SUPPRESS_REQ Description and prerequisites 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.
p97/98
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
p98/98

AFSCM TECH - LIVBL - Interface Specification - V1.2

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AFSCM TECH - LIVBL - Interface Specification - V1.2

Uploaded by

Copyright:

Available Formats

INTERFACE SPECIFICATION Between Telecom Operators and NFC Service Providers

Editor Document manager Approval

Evelyne Babel Olivier Tessier Olivier Tessier

0.1 0.2 0.3 1.0 1.01

19/01/2009 26/02/2009 18/03/2009 10/04/2009 15/05/2009

All All All All

A1.2 A1.4 0 1.2 20/10/2009 All

TABLE OF CONTENTS ____________________________________________________________ 1

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

Step 2: Subscription ................................................................................................................18

Step 3: Installation of Mobile NFC Service..............................................................................21

Step 4: Use mobile NFC Service ..............................................................................................28

Step 5 Termination of mobile NFC service ..........................................................................39

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

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

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

TABLE OF FIGURES ______________________________________________________________

Purpose of the interface specification

Content of the interface specification

How to use this specification?

Reference to the other AFSCM guidelines

Acronyms and abbreviations

Process description and flow chart

Optional action or process

Process global mapping

Inquiry to Service Provider Process 1

Inquiry to MNO Process 2

Subscription at SPs local office or web site Process 3

Subscription from mobile handest via WAP session Process 3 WAP

Install UICC application Process 4

Update UICC application Process 4 Update

Optional process if SP wants to do OTA update

Install / Update MMI Process 5

Conditional Process Mandatory if MMI is necessary

Change UICC Process 6

Lost/stolen Mobile equipment. Contact MNO Process 9

Lost/stolen Mobile equipment. Contact SP Process 10

End user requests Temporary mobile service supsension - Process 16

Change Mobile Phone Number - Process 7

Change Mobile Handset - Process 8

Recover Mobile equipment Process 11

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

Termination of mobile NFC service Process 19

Is the End user eligible?

Ask the end user to contact his MNO

Process n3 SUBSCRIBE to a mobile NFC service

End user inquires about mobile NFC services

Does the end user wish to buy one? No Yes End

Does end user have an NFC device?

Sell an NFC device

Yes Yes Sell appropriate offer

Process n3 SUBSCRIBE to a mobile NFC service

Mobile Network Operator

Scoring by Service Provider (optional)

Service Provider approval ?

End user approval?

Step 2: Subscribe to a mobile NFC service

SMS reception. Communicate the authentication key to the Service Provider

Short leadtime (except if network troubles)

Send SMS containing an authentication key to end user

Authentication key match?