INTERFACE SPECIFICATION between Telecom Operators and NFC Service Providers

RELEASE 2.1
Date Reference 13/02/2012 120213 - AFSCM TECH - LIVBL - Interface Specification - V2.1.doc

AFSCM Interface Specification V2.1 – February 2012 – AFSCM Confidential & Proprietary

p1/102

Name

Company

Authors

Jean-François Roueche Evelyne Babel Gaël Gérard, Mayss Chahid, Julian Alvero, Susana Oliver-Pastor Rolla Lamaa

Bouygues Telecom NRJ mobile Orange SFR AFSCM AFSCM Orange

Editor Document manager Approval

Sébastien Gauthier Sébastien Gauthier Laurence Becq

Document management
Version Date Chapters Modification

1.2.1 2.0 DRAFT (1.9.16)

03/12/2010 29/04/2011 -

Latest revision of the 1.X interface specification New features & major changes: Subscription and installation processes loosened Compatibility responsibility detailed Delegated management support More refined eligibility control functions Support the use of a single call to perform multiple installation step Registry update support

2.0

04/07/2011 -

Major changes since DRAFT: New types defined, some functions and parameters renamed Introduced the msId and removed the idTechHeader installMmiReq can now handle several MMI Section 5 detailed (retry management, load control, heart beat)

2.0.1

13/09/2011 -

Minor fixes: XML files described in appendix 1 Types mobileHandsetId and uiccProfile added; some types and data names slightly modified to reflect the XML files notifChangeIdTech renamed to notifChangeMsId

2.1

02/02/2012 2.2 2.5.1 2.6.4 2.7.3 2.7.5

Minor fixes: Use of Process 1 in first use case Process 4 entry point precised Removed retry from figure 16 Process 7 is optional in process 8 Added binding (process 7) at end of process 10
p2/102

AFSCM Interface Specification V2.1 – February 2012 – AFSCM Confidential & Proprietary

Version

Date

Chapters

Modification

3.9.1 4.5.3 4.6.6 All 2.1 09/02/2012 All 3.9.2 3.9.3

iccId: replaced AN(1) with [0-9A-F] as in the XSD file Process 6: added MMI ID Fixed process 13 (works with DM now) Fixed some broken links Error codes updates Error codes descriptions have been detailed. Added “S” code type for Sequence errors Deprecated unused code 042 Deprecated codes 202, 204 Added code 223 Reclassified codes 224, 225, 226 as “S” errors (instead of W)

3.9.4

Deprecated codes 005, 006, 007 Added codes 013 to 017 Added code 210, 223 Reclassified code 211, 224, 225, 226 as a “S” error Precised definition of codes 401, 900

Version 2.1: Note on deprecated error codes: In version 2.1 of this document, some error codes have been deprecated. There may be a slight delay between the implementation of version 2.0.1 and version 2.1 of this specification; Service Providers are thus encouraged to implement the error codes of version 2.1 of the specification, but still support the deprecated codes until all implementations are up-to-date with version 2.1.

AFSCM Interface Specification V2.1 – February 2012 – AFSCM Confidential & Proprietary

p3/102

TABLE OF CONTENTS ____________________________________________________________ 1
1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9

INTRODUCTION ................................................................................................................... 9
Context .................................................................................................................................................. 9 Purpose of the interface specification ................................................................................................ 10 Content of the interface specification................................................................................................. 10 Assumptions ........................................................................................................................................ 10 How to use this specification?............................................................................................................. 11 Reference to the other AFSCM guidelines .......................................................................................... 12 References ........................................................................................................................................... 12 Acronyms and abbreviations ............................................................................................................... 13 Definitions ........................................................................................................................................... 13

2

FUNCTIONAL REQUIREMENTS: PROCESS DESCRIPTION AND FLOWCHARTS ........................................... 14

2.1 Process overall mapping...................................................................................................................... 14 2.2 Service discovery, subscription and installation sequences ............................................................... 15 2.3 Eligibility and scoring sub-processes ................................................................................................... 16 2.3.1 Eligibility and compatibility: definitions .................................................................................16 2.3.2 Sub-process A – MNO eligibility..............................................................................................17 2.3.3 Sub-process B – SP compatibility ............................................................................................17 2.3.4 Sub-process C – SP scoring .....................................................................................................18 2.4 Service discovery and inquiry processes ............................................................................................. 18 2.4.1 Process 1 – Online service discovery ......................................................................................19 2.4.2 Process 2 – Inquiry to the Service Provider ............................................................................19 2.4.3 Process 3 – Inquiry to the Mobile Network Operator ............................................................20 2.5 Subscription processes ........................................................................................................................ 21 2.5.1 Process 4 – Subscription to a mobile NFC Service ..................................................................21 2.6 Installation processes .......................................................................................................................... 23 2.6.1 Definition of the mobile NFC service ......................................................................................23 2.6.2 Installation processes sequencing ..........................................................................................23 2.6.3 UICC and UICC application architecture .................................................................................24 2.6.4 Process 5 – Mobile NFC UICC application installation ............................................................26 2.6.5 Process 5 Update – Mobile NFC UICC application update......................................................28 2.6.6 Process 6 – Service Provider MMI installation / update.........................................................29 2.6.7 Process 7 – MMI and UICC application binding ......................................................................33 2.7 Life cycle processes ............................................................................................................................. 33 2.7.1 Locking a mobile NFC service..................................................................................................34 2.7.2 Suspended line and restricted line .........................................................................................34 2.7.3 Process 8 – Change UICC ........................................................................................................34 2.7.4 Process 9 – Change mobile phone number ............................................................................35 2.7.5 Process 10 – Change mobile handset .....................................................................................36 2.7.6 Process 11 – Lost or stolen mobile equipment, end user contacts MNO ..............................38 2.7.7 Process 12 – Lost or stolen mobile equipment, end user contacts Service Provider .............38 2.7.8 Process 13 – Recover mobile equipment after a loss (or theft) .............................................39 2.7.9 Process 14 – Get a new mobile equipment after a loss or theft ............................................40 2.7.10 Process 15 – End User requests temporary mobile service suspension .............................41 2.7.11 Process 16 – Change in contract ownership .......................................................................42 2.7.12 Process 17 – End user swaps Mobile Network Operator ....................................................43
AFSCM Interface Specification V2.1 – February 2012 – AFSCM Confidential & Proprietary p4/102

2.8 Termination processes ........................................................................................................................ 43 2.8.1 Process 18 – Termination of Mobile subscription or NFC option by end user .......................43 2.8.2 Process 19 – Mobile service termination by Mobile Network Operator................................44 2.8.3 Process 20 – Mobile NFC service termination ........................................................................45

3

INTERFACE SPECIFICATION ..................................................................................................... 48

3.1 Introduction......................................................................................................................................... 48 3.1.1 Implementation ......................................................................................................................48 3.1.2 Elementary requests / batch ..................................................................................................48 3.1.3 Naming conventions ...............................................................................................................48 3.1.4 Data types ...............................................................................................................................49 3.1.5 Synchronous and Asynchronous.............................................................................................49 3.1.6 Retries and validity period management for asynchronous requests....................................50 3.2 Headers ............................................................................................................................................... 50 3.2.1 syncHeader – Header for Synchronous Requests...................................................................50 3.2.2 asyncHeader – Header for Asynchronous Requests...............................................................51 3.3 Acknowledgments and exceptions...................................................................................................... 51 3.3.1 acknowledge ...........................................................................................................................51 3.3.2 acknowledgeWithValidityPeriod ............................................................................................52 3.3.3 faultMsg ..................................................................................................................................52 3.4 Identifiers ............................................................................................................................................ 52 3.4.1 Technical Identifier idTech......................................................................................................52 3.4.2 Service Identifiers: serviceId and serviceVersion ...................................................................53 3.5 Control functions ................................................................................................................................. 54 3.5.1 getUICCProfile .........................................................................................................................54 3.5.2 getMobileHandsetProfile........................................................................................................55 3.5.3 isEligible ..................................................................................................................................55 3.5.4 getIdTech ................................................................................................................................56 3.5.5 fullEligibilityCheck ...................................................................................................................56 3.6 Installation requests ............................................................................................................................ 58 3.6.1 createOrAllocateSsdReq and createOrAllocateSsdResp ........................................................58 3.6.2 getTokens................................................................................................................................59 3.6.3 installReq and installResp .......................................................................................................61 3.6.4 installMmiReq and installMmiResp ........................................................................................64 3.6.5 bindMmiReq and bindMmiResp .............................................................................................65 3.6.6 suppressReq and suppressResp..............................................................................................66 3.7 Notifications ........................................................................................................................................ 67 3.7.1 notifStateChangeToMno ........................................................................................................67 3.7.2 notifCallEndUserToMno .........................................................................................................69 3.7.3 notifNewDevice ......................................................................................................................69 3.7.4 notifChangeMsId ....................................................................................................................70 3.7.5 notifCallEndUserToSp .............................................................................................................71 3.7.6 notifStateChangeToSp ............................................................................................................71 3.8 Script sending ...................................................................................................................................... 72 3.8.1 sendScriptsReq and sendScriptsResp .....................................................................................72 3.9 Data dictionary .................................................................................................................................... 74 3.9.1 Data types ...............................................................................................................................74 3.9.2 Response and exception types ...............................................................................................79 3.9.3 Response codes to asynchronous requests ............................................................................80 3.9.4 Exceptions ...............................................................................................................................81

4

PROCESS IMPLEMENTATION REFERENCE..................................................................................... 84
p5/102

AFSCM Interface Specification V2.1 – February 2012 – AFSCM Confidential & Proprietary

4.1 Representation of the exchanges........................................................................................................ 84 4.2 Eligibility and scoring sub-processes ................................................................................................... 84 4.2.1 Sub-process A – MNO eligibility..............................................................................................84 4.2.2 Sub-process B – SP compatibility ............................................................................................85 4.2.3 Sub-process C – SP scoring .....................................................................................................85 4.3 Service discovery and inquiry processes ............................................................................................. 85 4.3.1 Process 1 – Online service discovery ......................................................................................85 4.3.2 Process 2 – Inquiry to the Service Provider ............................................................................85 4.3.3 Process 3 – Inquiry to the Mobile Network Operator ............................................................85 4.4 Subscription processes ........................................................................................................................ 85 4.4.1 Process 4 – Subscription to a mobile NFC Service ..................................................................85 4.5 Installation processes .......................................................................................................................... 85 4.5.1 Process 5 – Mobile NFC UICC application installation ............................................................85 4.5.2 Process 5 Update – Mobile NFC UICC application update......................................................89 4.5.3 Process 6 – Service Provider MMI installation / Update ........................................................90 4.5.4 Process 7 – MMI and UICC application binding ......................................................................92 4.6 Life cycle processes ............................................................................................................................. 92 4.6.1 Process 8 – Change UICC ........................................................................................................92 4.6.2 Process 9 – Change mobile phone number ............................................................................93 4.6.3 Process 10 – Change mobile handset .....................................................................................93 4.6.4 Process 11 – Lost or stolen mobile equipment, end user contacts MNO ..............................93 4.6.5 Process 12 – Lost or stolen mobile equipment, end user contacts Service Provider .............94 4.6.6 Process 13 – Recover mobile equipment after a loss .............................................................94 4.6.7 Process 14 – Get new mobile equipment after a loss or theft ...............................................95 4.6.8 Process 15 – End User requests temporary mobile service suspension ................................95 4.6.9 Process 16 - Change in contract ownership............................................................................95 4.6.10 Process 17 – End user swaps Mobile Network Operator ....................................................96 4.7 Termination processes ........................................................................................................................ 96 4.7.1 Process 18 – Termination of Mobile subscription or NFC option by end user .......................96 4.7.2 Process 19 – Mobile service termination by Mobile Network Operator................................96 4.7.3 Process 20 – Mobile NFC service termination ........................................................................97

5
5.1 5.2 5.3 5.4 5.5 5.6

WEB SERVICE IMPLEMENTATION ............................................................................................. 99
Protocol ............................................................................................................................................... 99 Interface .............................................................................................................................................. 99 HEART_BEAT........................................................................................................................................ 99 Protocol retry management ................................................................................................................ 99 Load control....................................................................................................................................... 100 Request sender authentication ......................................................................................................... 101

APPENDIX 1 XSD AND WSDL FILES ............................................................................................ 102

AFSCM Interface Specification V2.1 – February 2012 – AFSCM Confidential & Proprietary

p6/102

........................................................................................................................................27 Figure 18 – Flowchart of process 5 Update – Mobile NFC UICC application update in Simple SD mode ...............44 Figure 34 – Flowchart of process 19 – Mobile service termination by Mobile Network Operator .................................................................................18 Figure 9 – Flowchart of process 1 – Online service discovery ................................................................................................................................................................................................................................................................................................1 – February 2012 – AFSCM Confidential & Proprietary p7/102 ............................................................................................................................................................................36 Figure 26 – Flowchart of process 10 – Change mobile handset .............................14 Figure 3 – Service discovery and subscription: from a mobile web site ....................................................................................................35 Figure 25 – Flowchart of process 9 – Change mobile phone number ..............................................................................................................................................................31 Figure 22 – Flowchart of process 6 – Service Provider MMI installation..........27 Figure 17 – Flowchart of process 5 – Mobile NFC UICC application installation in Delegated Management mode..........................................26 Figure 16 – Flowchart of process 5 – Mobile NFC UICC application installation in Simple SD mode – personnalisation after activation .....17 Figure 7 – Flowchart of sub-process B – SP compatibility ..37 Figure 27 – Flowchart of process 11 – Change UICC Lost or stolen mobile equipment............................41 Figure 31 – Flowchart of process 15 – End User requests temporary mobile service suspension ......... end user contacts SP .................................................................................................................33 Figure 24 – Flowchart of process 8 – Change UICC ........30 Figure 21 – Flowchart of process 6 – Service Provider MMI installation...........16 Figure 6 – Flowchart of sub-process A – MNO eligibility.....................................................................................20 Figure 11 – Flowchart of process 3 – Inquiry to the Mobile Network Operator ............................................ case 3 ..................29 Figure 20 – Flowchart of process 6 – Service Provider MMI installation....................................... case 2 ........................................................18 Figure 8 – Flowchart of sub-process C – SP scoring .................19 Figure 10 – Flowchart of process 2 – Inquiry to the Service Provider ........................43 Figure 33 – Flowchart of process 18 – Termination of mobile subscription or NFC option by end user .....................................................15 Figure 4 – Service discovery and subscription: from an application store ........................................................................................... case 1 ...................................................45 Figure 35 – Flowchart of process 20 – Mobile NFC service termination in Simple SD mode ....................................................15 Figure 5 – Service discovery and subscription: at the Service Provider’s office ..................................................................42 Figure 32 – Flowchart of process 16 – Change in contract ownership ..........38 Figure 28 – Flowchart of process 12 – Change UICC Lost or stolen mobile equipment..................40 Figure 30 – Flowchart of process 14 – Get a new mobile equipment after a loss of theft ..................................................................21 Figure 12 – Flowchart of process 4 – Subscription to a mobile NFC Service................................... end user contacts MNO ..22 Figure 13 – Mobile phone number authentication example ........................46 Figure 36 – Flowchart of process 20 – Mobile NFC service termination in Delegated Management mode46 AFSCM Interface Specification V2.............................................32 Figure 23 – Flowchart of process 7 – MMI and UICC application binding ........................................................................................................................................22 Figure 14 – Representation example of the UICC application .......39 Figure 29 – Flowchart of process 13 – Recover mobile equipment after a loss (or theft) ....TABLE OF FIGURES ______________________________________________________________ Figure 1 – Process flowcharts legend ..................................................28 Figure 19 – Flowchart of process 5 Update – Mobile NFC UICC application update in Delegated Management mode .......................................................14 Figure 2 – Process overall mapping ............................................................................24 Figure 15 – Flowchart of process 5 – Mobile NFC UICC application installation in Simple SD mode – personnalisation before activation ......................

..............90 Figure 50 .......................85 Figure 43 – Sequence diagram of Sub-process B – SP compatibility.....94 Figure 60 .............................Sequence diagram of Process 11 – Lost or stolen mobile equipment.........Sequence diagram of Process 13 – Recover mobile equipment after a loss ............................................................Sequence diagram of Process 20 – Mobile NFC service termination in DM mode ..........................Sequence diagram of Process 20 – Mobile NFC service termination in Simple SD mode ...........85 Figure 44 ..................................................48 Figure 38 – Sample sequence diagram of synchronous and asynchronous exchanges ....100 AFSCM Interface Specification V2...................................84 Figure 41 – Legend of sequence diagrams .....................................93 Figure 59 .97 Figure 66 ..................1 – February 2012 – AFSCM Confidential & Proprietary p8/102 .........Sequence diagram of Process 10 – Change mobile handset .............Sequence diagram of Process 5 – Installation of UICC application in Simple SD mode (personalization then activation) ...........96 Figure 64 .........92 Figure 56 ...........Sequence diagram of Process 6 – MMI installation managed by MNO ....Sequence diagram of Process 6 – End user installs the MMI from an application store .................95 Figure 63 ........................................49 Figure 39 – Validity period management .................. end user contacts SP ................................................97 Figure 67 ......................................................Sequence diagram of Process 5 UICC application update in Delegated Management mode .....Sequence diagram of Process 6 – MMI Installation launched by Service Provider .....................................87 Figure 46 ..............Sequence diagram of Process 5 – UICC application update in Simple SD mode.........................................90 Figure 51 ..................................................................................................................Sequence diagram of Process 6 MMI installation launched by MNO ................89 Figure 48 ...............................................................50 Figure 40 – Simplified representation used in sequence diagrams ...............................Sequence diagram of process 15 – Suspension of mobile service upon end user’s request .Sequence diagram of Process 14 – Get new mobile equipment after a loss or theft.....................................................Sequence diagram of Process 9 – Change mobile phone number........................Sequence diagram of Process 19 – Mobile service termination by MNO .............................95 Figure 62 .............................................................................96 Figure 65 ....................................92 Figure 55 .........................................................86 Figure 45 – Sample sequence diagram of Process 5 – Installation of UICC application in Simple SD mode using grouped requests (activation then personalization).................................................Sequence diagram of Process 6 – Critical MMI update........................94 Figure 61 ...........................................................................................................................................................97 Figure 68 – Retry management illustration ............88 Figure 47 ................................91 Figure 52 ...........93 Figure 58 ........................................92 Figure 54 – Sequence diagram of Process 7 – MMI and UICC application binding ..............................................................93 Figure 57 ..............................................91 Figure 53 ......89 Figure 49 ................................Sequence diagram of Process 5 Installation of UICC application in Delegated Management mode.....Sequence diagram of Process 18 – Termination of mobile subscription or NFC option by end user ..........................................................................................................84 Figure 42 – Sequence diagram of Sub-process A – MNO eligibility .....Sequence diagram of process 16 – Change in contract ownership .....................Sequence diagram of Process 8 – Change UICC ..................................Sequence diagram of Process 12 – Lost or stolen mobile equipment.................................................Figure 37 – Architecture overview ........... end user contacts MNO ............................

To specify technical guidelines for the development of mobile contactless services to ensure seamless installation and consistent user experience. Orange and SFR have founded the AFSCM (Association Française du Sans Contact Mobile) to foster the development of mobile contactless services. 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. Service portability in the event of a Mobile Network Operator swap. To define a mutually beneficial mobile contactless eco-system. In particular. AFSCM members will contribute to the definition of innovative industry standards and best practices. smart card manufacturers.1 – February 2012 – AFSCM Confidential & Proprietary p9/102 . Société Générale and Véolia have already joined the AFSCM as associate members.1 1. Efficient customer support. To this end. handset makers. Smooth customer experience. Mobile Network Operators. AFSCM endeavours: 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. The AFSCM objective is to support the inception of new contactless services for mobile phone users. - To promote the benefits of the mobile phone platform for contactless service providers. Together. 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. AFSCM Interface Specification V2. The Service Providers Credit Mutuel.1 INTRODUCTION Context The Mobile Network Operators Bouygues Telecom. MVNOs. Service portability in the event of a mobile equipment swap. The stated objective of the AFSCM is to facilitate the development of mobile contactless services. for technology providers and for end users. AFSCM constituency will include all companies involved in the development of a sustainable market for mobile contactless services such as Service Providers. State-of-the art application life cycle management.

the UICC and the MNO information systems. AFSCM Interface Specification V2.4 Assumptions The work of the Process and Technical committees of the ASFCM.3 Content of the interface specification This document describes in chapter 2 Functional Requirements: process description and flowcharts the processes for every step of the customer journey: inquiry of information. this interface specification ensures that the same mechanisms and the same server will be applicable regardless of the mobile network selected by the end user. subscription and installation of the mobile NFC service. Web service implementation. the existing specifications of Mobile NFC services. Section 4 Process implementation reference presents the exchanges on the SP/MNO interface for all processes of the customer journey.And on the other hand. From the point of view of a Service Provider. use and termination of the mobile NFC service. The AFSCM also specifies high level requirements for both UICC and mobile handsets in separate documents. UICC technology The NFC application is hosted on the UICC of the mobile equipment. the technical capabilities of the different components of the NFC ecosystem including the NFC mobile handset. resulting in the current document.1.2. which covers all identified NFC use cases for a UICC centric model. That ensures interoperability between the actors simplifies the deployment and avoids redundancy in a multi-actors environment. The UICC uses JavaCard 2. 1. o and Payez Mobile specifications for mobile NFC payment services.2 Purpose of the interface specification The purpose of this document is to facilitate a deployment of mobile NFC services involving the French Mobile Network Operators and various profiles of Service Providers. It is a more mature solution than version 1 and targets large commercial deployments. AFSCM members have recognized the definition of a standardized interface and processes. this interface specification provides a unified way of exchanging data with any Service Providers of mobile NFC services. has been based on two sources of information: . this specification covers the entire life cycle of a mobile NFC service from the perspective of the end user. A key driver is to propose a simple and efficient solution. exchange protocol and the connection between the information systems of both actors are described in section 5 Web service implementation. . Confidential Loading for packages is not supported in this version of the specification. Supported GlobalPlatform features Within the features defined by GlobalPlatform for remote application management. Then. Furthermore.2. To this end. These documents are only provided to the relevant suppliers on request. From the point of view of a Mobile Network Operator. the document presents the detailed specification of the interface between Mobile Network Operators and Service providers in section 3 Interface Specification.2 technology and implements GlobalPlatform 2. These specifications target implementation for dedicated service domains: o Ulysse specifications for mobile NFC transport ticketing services.1 – February 2012 – AFSCM Confidential & Proprietary p10/102 .On one hand. 1. both Simple SD management (with DAP as an option) and Delegated Management are supported.

it is not possible to manage memory space booking on a UICC as described in Payez Mobile. Mandated DAP is a feature that automatically ensures that the applications loaded on the UICC were previously validated. the implementation of which is a decision of the MNO. the SSD root keys may not be managed by the MNO. This specification requires the UICC application to be locked or deleted before the line is suspended or terminated in order to avoid “uncontrolled” applications in the wild. OTA capabilities The SSD are created in the UICC. 1. some features are optional or conditional. the application activation (or deactivation) is performed upon request of the Service Provider.5 How to use this specification? Mandatory. These features are optional or conditional for the Service Provider. They are represented in dotted line in the flowcharts and the conditions are mentioned in the description. AFSCM Interface Specification V2. .Or SSD creation OTA  in this case. The Service Providers are informed once the suspension or termination is effective.Another restriction is related to the synchronisation of actions in case of urgent situations such as loss or theft. Interoperability and multi application management The support of multi applications is possible thanks to the Java Card and GP technologies ensuring secure partition between applications. SSD can be created in two different ways: . the SSD temporary keys are managed by the MNO.The Mobile Network Operators will not send notifications to the Service Providers prior to line suspension. which is not guaranteed in version 2 of this specification.SSD creation in factory  in this case. Each Service Provider is responsible for selecting within the optional and conditional features proposed in this specification the ones that are the most appropriate for its mobile NFC service thus resulting in a fine tuned configuration. The Mobile Network Operator is identified in the header of each request. Process and Information Systems The following assumptions are made based on the current Information System limitations: .1 – February 2012 – AFSCM Confidential & Proprietary p11/102 . this specification can be considered as a tool box in which the Service Provider selects the set of features that is best suited for its mobile NFC service. UICC memory size In version 2 of the specification. response and notification with the mnoId data. . From this perspective. except for the MMI and UICC application binding. The application package is loaded in the UICC. Once the application is available in the UICC.Mandated DAP is supported but has no impact on this interface specification. conditional and optional features In the specifications below.A technical identifier is used to identify the end user in the communication between Mobile Network Operator and Service Providers. termination or UICC change for instance. It can be loaded either in factory or OTA. The AFSCM development guides ([R2] MIDlet Development Guide and [R3] Cardlet Development Guide) define rules regarding interaction between NFC homepage application and the Service Providers' applications. Yet. . it relies on the capacity of the Mobile Network Operator’s information system to perform the locking actions before line suspension or termination.

retries…) 1.The NFC applications validation process.6 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: . This document is the continuation of the interface specification.Mobile Handset UICC Applications v1. .1 – February 2012 – AFSCM Confidential & Proprietary . This document specifies the provisioning mechanisms for compatibility.1 Book 1 .1 p12/102 AFSCM Interface Specification V2. providing information on the process to be applied and the data that must be exchanged prior to establishing any connection between information systems. Version 2 is designed for commercial deployment and improves on version 1 by .Improving reliability mechanisms (validity period. 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.7 References The following documents are available for the Service Providers: AFSCM [R1] [R2] [R3] [R4] [R5] [R6] NFC Applications Validation Process MIDlet Development Guide Cardlet Development Guide Secure Services Management Role Guidelines for interconnection of Service Providers' and MNOs' Information Systems Customer support guidelines Payez Mobile (AEPM) [R7] [R8] Book 0 . Versions Version 1 of this specification was designed to meet the requirements for short term deployments in 2010.The guidelines for interconnection of Service Providers' and MNOs' Information Systems.The definition of Secure Service Management roles. while retaining the simplicity of version 1.bringing new features such as Delegated Management support. which are more modular. technical and security requirements regarding the process for validation.The customer support guidelines 1. .adding more functions. They must be implemented by each Service Provider in order to be “AFSCM compatible”. The rules for elaborating NFC applications are fully detailed in a guidelines book that gather all the functional. . . The MNO platform is ready to manage all the possible Service Provider configurations provided that they are compliant with the current interface specification. . loading and hosting of NFC applications. . .All features that are not explicitly optional or conditional are mandatory features.General Description v1.including various feedbacks from Service Provider and industry partners following the 2010 short term deployments.The NFC applications (Cardlet and MMI) development guidelines.

1 Ulysse [R11] Contactless transport ticketing using mobile phones .Payment Service Delivery & Management v1.8 Acronyms and abbreviations ACF AEPM AFSCM BIP CCM DM ISD KIC KID KIK MMI MNO NFC RFU SP SSD UICC Access Control File Association Européenne Payez Mobile Association Française du Sans Contact Mobile Bearer Independent Protocol Card Content Management 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) 1. 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 AFSCM Interface Specification V2.6.2.1 1.1 Invitation presented to the end user for getting his approval or rejection – for instance for downloading the MMI.[R9] Book 2 .1 [R14] UICC configuration 1.1 GlobalPlatform [R13] Global Platform Card Specification 2.1 [R12] Contactless transport ticketing using mobile phones .1 [R10] Book 3 .Payment Processing v1.Technical Specifications V1.1 – February 2012 – AFSCM Confidential & Proprietary p13/102 .9 Definitions Application Delegated management Mobile equipment Mobile NFC service Opt-in Simple SD SSD Manager Short name for the UICC application Pre-authorized Card Content changes performed directly by a Service Provider upon a MNO authorisation– defined in Global Platform Represents the combination of a mobile handset and a UICC see section 2.0.General Specifications V1.

1 Process overall mapping The following chart presents the processes that are described in this document.2 FUNCTIONAL REQUIREMENTS: PROCESS DESCRIPTION AND FLOWCHARTS This section presents all the user experiences as they can be implemented in version 2. only if SP wants to update OTA Install / Update MMI Process 6 Conditional. Global process mapping Online service discovery – Process 1 Inquiry to Service Provider Process 2 Inquiry to MNO Process 3 Inquiry Sub-processes MNO eligibility Sub-process A SP compatibility Sub-process B SP scoring Sub-process C Subscription Service subscription Process 4 Subscription is mandatory but can come before or after some installation processes Installation Install UICC application Process 5 Update UICC application Process 5 Update Optional. Optional or conditional processes are represented with a dotted outline.Process 18 Mobile service termination by MNO .Process 15 Recover mobile equipment Process 13 Get new mobile equipment Process 14 Optional process Not supported yet Change in contract ownership .Process 7 Change UICC Process 8 Change Mobile Phone Number .1 – February 2012 – AFSCM Confidential & Proprietary p14/102 . user contacts MNO .Process 19 Mobile NFC service termination . Action Choice Covers a process already described Optional action or process Process Notifications Figure 1 – Process flowcharts legend 2. The restrictions compared to the mid term and long term target as defined for instance in Payez Mobile or Ulysse are highlighted. mandatory only if MMI is necessary Conditional. user contacts SP . grouped in categories.Process 9 Change Mobile Handset Process 10 Use Lost/stolen Mobile equipment. mandatory when MNO supports it MMI and UICC application binding .Process 20 Figure 2 – Process overall mapping AFSCM Interface Specification V2.Process 16 End user swaps MNO Process 17 Termination Termination of Mobile subscription or NFC option by end user .Process 11 Lost/stolen Mobile equipment.Process 12 End user requests Temporary mobile service supsension .

1 – February 2012 – AFSCM Confidential & Proprietary p15/102 . subscription and installation sequences There are several ways to sequence the inquiry. Process 1 can be accessed from the MNO wallet for instance.2. Use case example #2: service discovery from a mobile application store and subscription from inside the MMI Process 1 – Online service discovery Process 6 – Service Provider MMI installation The end user launches his MMI.2 Service discovery. subscription and installation steps. that initiates the subscription Process 4 – Subscription to a mobile NFC Service Process 5 – Installation of UICC application Notify MNO about MMI installation/update Process 7 – MMI and UICC application binding Service available for use Figure 4 – Service discovery and subscription: from an application store AFSCM Interface Specification V2. The Service Provider must be compliant with either of the possibilities presented in the following diagrams: Figure 3 – Service discovery and subscription: from a mobile web site In the diagram above.

3 Eligibility and scoring sub-processes This section presents sub-processes regarding eligibility and scoring.1 – February 2012 – AFSCM Confidential & Proprietary p16/102 .Use case example #3: subscription in the service provider’s offices The end user goes at the service provider’s office to subscribe Process 2 – End user asks his Service Provider about available mobile NFC services Process 4 – Subscription to a mobile NFC Service OR Process 5 – Installation of UICC application Process 6 – Service Provider MMI installation Process 7 – MMI and UICC application binding Process 5 – Installation of UICC application Process 6 – Service Provider MMI installation Process 7 – MMI and UICC application binding Service available for use Figure 5 – Service discovery and subscription: at the Service Provider’s office 2. Inform the end user about new services now available for his mobile handset. A sub-process has been created to handle compatibility checks (see Sub-process B – SP compatibility) In order to provide the best user experience to the end-user. Eligibility is still the responsibility of the MNO.1 Eligibility and compatibility: definitions This version of the specification introduces the notion of compatibility. 2. in order to be able to manage a growing number of UICC and handset models. A given mobile NFC service may for instance be available for a handset model and not for another. etc…). AFSCM Interface Specification V2. Present to the end user only the services that are compatible with his device during service discovery. that will be used further in several processes. or that his MMI is available for this reference. Compatibility is the responsibility of the Service Provider.3. it is important for the MNO to be able to: Inform the end user about the available services on his mobile handset at the earliest stage of his subscription. who ensures a handset model and a UICC model are compatible with his services (the SP assures that he has tested his service on this mobile reference. and ensures an end user’s equipment is eligible to mobile NFC services (see Sub-process A).

the accuracy of the information regarding the available memory space is not guaranteed. The SP will provide the MNO with a list of compatible devices/operating systems with its services. the MNO cannot guarantee its eligibility.Available memory space on UICC [Note] Should the end user gets his mobile equipment outside of the Mobile Network Operators' point of sales network.This will be achieved at provisioning stage. 2.UICC eligibility . this will help the Service Provider avoid compatibility issues or end user complaints.mobile handset eligibility .Technical: UICC and mobile handset are NFC capable . In addition to helping the end user find the services compatible with his handset. the way the eligibility check works might differ from one MNO to another especially regarding the available memory space on UICC. Restrictions specific to Version 2 In Version 2 of this specification.Commercial contract: the end-user has a contract with the Mobile Network Operator.3. and has access to NFC services . even if it is NFC capable. This provisioning solution is described in [R5] Guidelines for interconnection of Service Providers' and MNOs' Information Systems. 2. the MNO is responsible for ensuring the said eligibility.3 Sub-process B – SP compatibility Flowchart AFSCM Interface Specification V2.1 – February 2012 – AFSCM Confidential & Proprietary p17/102 . based on the information at his disposal and the following criteria: .MNO offer eligibility Request for eligibility of end user MNO eligibility End user is eligible Yes Is end user eligible from MNO perspective? End user is not eligible (reason) No Figure 6 – Flowchart of sub-process A – MNO eligibility Description This sub-process is used whenever the SP needs to ensure an end user’s equipment is eligible to the mobile NFC service.2 Sub-process A – MNO eligibility Flowchart Sub-process A – MNO eligibility Service Provider Mobile Network Operator Check eligibility of the end user (based on the technical identifier provided) to the service: .3. In this sub-process. moreover.

AFSCM Interface Specification V2. The Service Provider is responsible for maintaining a list of mobile handsets and UICC models that are compatible with his mobile NFC service.1 – February 2012 – AFSCM Confidential & Proprietary p18/102 . he discovers a mobile NFC service on an online application store. In the Process 1.3. 2. In this sub-process.4 Service discovery and inquiry processes In these processes.Sub-process B – SP compatibility Service Provider Request detailed information about the end user’s mobile equipment (UICC and/or mobile handset) Mobile Network Operator Provide detailed information about the end user’s UICC and/or mobile handset Is the mobile equipment compatible with the service? SP compatibility Yes Mobile equipment is compatible No Mobile equipment is not compatible (reason) Figure 7 – Flowchart of sub-process B – SP compatibility Description This sub-process is used whenever the SP needs to ensure that an end user’s equipment is technically compatible with his mobile NFC service. This process is optional. the MNO provides the necessary technical information to the SP. the end user discovers the NFC services. 2.4 Sub-process C – SP scoring Flowchart Sub-process C – SP scoring End user Provide information Service Provider Ask necessary information for user subscription Perform internal service scoring SP scoring Positive End user can subscribe to the service Negative End user cannot subscribe to the service (reason) Figure 8 – Flowchart of sub-process C – SP scoring Description This sub-process includes the verifications that the SP requires to allow user subscription. and the SP checks the said technical compatibility. The MNO takes no part in this process.

or the mobile handset OS provider. 2.1 Process 1 – Online service discovery Flowchart Process 1 . Both processes are mandatory. the end user inquires about a mobile NFC service and contacts either the Service Provider (Process 2) or the Mobile Network Operator (Process 3). MNO application stores contains applications that are showcased by the MNO . the MNO is able to perform a pre-emptive eligibility and compatibility check (the SP provides the compatibility information) [Note] In order for the MNO to provide more compatibility information to the end user.2 Process 2 – Inquiry to the Service Provider Flowchart AFSCM Interface Specification V2.Online service discovery End user Mobile Network Operator Check services to which the end user’s equipment is eligible End user browses an application store Inquiry End user chooses to intall the MMI of the mobile NFC service Check services with which the end user’s equipment is compatible [Note] On a MNO application store. the MNO may only present eligible and compatible services to the end user Proceed to subscription or installation processes Figure 9 – Flowchart of process 1 – Online service discovery Description There are two kinds of application stores that the end user can use: Independent application stores are set up and maintained by the mobile handset maker.4. in this case. The provisioning of this information is described in [R5].1 – February 2012 – AFSCM Confidential & Proprietary p19/102 . the SP needs to provide the MNO its service compatibility information. 2.4.In the other processes.

subscription requirements User eligible User not eligible Sub-process A MNO eligibility Ask the end user to contact his MNO Process 4 – Subscription to a mobile NFC Service Figure 10 – Flowchart of process 2 – Inquiry to the Service Provider Description The Service Provider is responsible for the information regarding the mobile NFC service and its delivery to his customers.mobile NFC services . 2. the Service Provider can mention that there are pre requisites on the UICC and mobile NFC handset for accessing a mobile NFC service – and invite the end user to contact his Mobile Network Operator (Process 3) to get proper mobile equipment.1 – February 2012 – AFSCM Confidential & Proprietary p20/102 .Process 2 – End user asks his Service Provider about available mobile NFC services End user Inquiry Service Provider MNO End user inquires about mobile NFC services Inform the End user about: . Shoud the end user not be eligible.3 Process 3 – Inquiry to the Mobile Network Operator Flowchart AFSCM Interface Specification V2.4. The Service Provider verifies the end user’s equipment eligibility and invites him to subscribe.

propose the appropriate mobile equipment and offer.5. 2. if it has already been installed) The Service Provider must use at least one of these channels. The MNO can invite the end user to contact the Service Provider for additional information about the service (Process 2) or subscription (Process 4).5 Subscription processes The subscription to a new or to an additional mobile NFC service can take place through different channels: .The Service Provider's local office or web site . the MNO will thus check the end user’s eligibility and. should the end user not be eligible.1 Process 4 – Subscription to a mobile NFC Service Flowchart AFSCM Interface Specification V2.Process 3 – End user asks his MNO about available mobile NFC services End user Mobile Network Operator Inform the end user about contractual and technical prerequisites as well as Service Provider requirements Inquiry End user inquires about mobile NFC services No Provide end user with NFC device Does the end user wish to buy one? No Does end user have an NFC device? Yes Yes Inform the end user about the services compatible with the mobile device No Does the end user wish to subscribe to the offer ? No Does the current end user offer allow the access to NFC services? Sell an NFC device Yes Yes Sell appropriate offer End user is not eligible to mobile NFC services Ask the end user to contact his targeted Service Provider to subscribe to a mobile NFC service Process 2 – End user asks his Service Provider about available mobile NFC services Figure 11 – Flowchart of process 3 – Inquiry to the Mobile Network Operator Description The Mobile Network Operator is responsible for informing about mobile NFC services and their requirements.1 – February 2012 – AFSCM Confidential & Proprietary p21/102 .From the mobile handset in a WAP session (in a WAP browser or through the MMI. 2.

Figure 12 – Flowchart of process 4 – Subscription to a mobile NFC Service The following diagram is an example of how the Service Provider can ensure the authentication of the mobile phone number provided by the end user. the Service Provider must identify the end user in order to be able to communicate with the MNO. Communicate the authentication key to the Service Provider Short leadtime (except if network troubles) Send SMS containing an authentication « key »to end user No Authentication key match? MSISDN authenticated Figure 13 – Mobile phone number authentication example Description The same process applies whether it is the end user’s first subscription to a mobile NFC service or a subscription to an additional mobile NFC service.1 – February 2012 – AFSCM Confidential & Proprietary p22/102 . During the course of this process. several possibilities exist: AFSCM Interface Specification V2. The SP needs to get and authenticate the MSISDN (for eligibility purposes for instance) Get the end user MSISDN to check its elibigility (sub-process example) User refuses Ask the end user’s mobile phone number and his approval for checking its elibigility to NFC service (legal impacts) User agrees Example of end user and mobile authentication using an authentication key SMS reception.

A service can only be installed once. a mobile NFC service is identified by a serviceId.A single MMI instance can use several UICC application instances with different serviceId identifiers .1 Definition of the mobile NFC service A mobile NFC service is constituted by one or several UICC applications and may include one or several mobile applications (MMI.2 Installation processes sequencing The mobile NFC services installation process is divided in three steps: Mobile NFC UICC application installation (Process 5): this process is mandatory and depending on the implementation decided by the Service Provider.6 Installation processes 2. 2.A UICC application can be used by several MMI that have the same serviceId . provided upon agreement by the MNO) 2.A single UICC application instance cannot be used by 2 different services The following precisions are made regarding the MMI in a mobile NFC service: . In this case the Process 6 is not applicable. but with a different serviceId for each instance : the package is then shared between services . more information about MMI formats for compatibility can be found in [R5] Guidelines for interconnection of Service Providers' and MNOs' Information Systems . can be done using the Simple SD mode or the Delegated Management mode. It is possible that some mobile NFC services do not require a MMI. and in only one serviceVersion. the SP has to implement this process. which are optional).The evolution of the versioning of the MMI has no impact on the evolution of the serviceVersion parameter (if the version of the mobile application of a service is incremented.- - The Service Provider can ask the end user’s mobile phone number and his approval for submitting an eligibility request to the Mobile Network Operator (this case is presented in Figure 13) The Service Provider can use the MNO WAP alias (technical identifier from a WAP session.All application instances of a mobile NFC service identified by the same serviceId are in the same SSD .1 – February 2012 – AFSCM Confidential & Proprietary p23/102 . - - AFSCM Interface Specification V2. The following precisions are made concerning this identifier: . MMI and UICC application binding (Process 7): this process is conditional: if the MNO implements bindings. Service Provider MMI installation / update (Process 6): this process is conditional.6. on a given UICC . In this specification. the serviceVersion must be incremented . it does not increment the serviceVersion of the service) .A single UICC application package can be used to instantiate several cardlet applications.If the SP updates one of his UICC application packages. but direct implementation of this installation is not detailed.6.The MMI can be available in different formats and versions in order to address different handset models.This document takes MMI installation into account.

Process 5 Update for the UICC application update. Implementation of this process is optional. The drawing below is an example of representation of all that is necessary on the UICC before the mobile NFC service can be used. Implementation of this process is mandatory when there is a MMI. that the Service Provider notifies the MNO of the MMI installation progress. the SP requests a token from the MNO for each action to be done on the UICC (package loading.2 Service discovery. is composed of one or several packages. the MMI might be deleted from the end user’s mobile handset. the SP should either launch the MMI installation or lock or delete the UICC application. 2. In case the SP tolerates such use.1 – February 2012 – AFSCM Confidential & Proprietary p24/102 .These steps may be performed in the order of preference of the Service Provider. AFSCM Interface Specification V2. The Service Provider is responsible for the tolerance or not that his mobile NFC service is used without the MMI on the mobile handset. once the UICC application(s) AND the MMI are installed: it is thus imperative. the MNO sends the CCM commands to the UICC upon request of the Service Provider. also named application. In the Delegated Management mode. the Service Provider sends the CCM commands to the UICC after having been authorized by the MNO: Before sending an OTA command. particularly for the customer services. The installation sequences are detailed in section 2. it is recommended to inform the end user that he cannot benefit from full capacity of his mobile NFC service. and is indeed fully operational for the End user.3 UICC and UICC application architecture The UICC application. described by the following processes: . the only condition being that Process 7 must always come after Process 5 or Process 5 Update. subscription and installation sequences . one or several instances and personalisation data hosted in the UICC as represented below. this process can be implemented using the Simple SD mode or the Delegated Management mode . [Note] In the mobile NFC service lifespan. depending on the Service Provider’s decision to be able to update OTA its UICC application.Process 6 for the MMI update. ISD SP SSD Package Instance Perso Data Figure 14 – Representation example of the UICC application In Simple SD management mode. A mobile NFC service is considered completely installed. the Service Provider is authorized by the MNO and sends OTA the GlobalPlatform commands to the UICC The SP must notify the MNO of the status of the OTA actions and send the token receipts. As for the installation of the UICC application. application installation).6. Once it has the tokens. These installation processes also include the update of applications. If not.

1 – February 2012 – AFSCM Confidential & Proprietary p25/102 . it is done by the SP After the UICC application personalisation. For each scenario. ISD SP SSD Package or ISD SP SSD PARTIALLY OTA In this scenario. either by the MNO (upon SP request. only the SSD may be created in factory. Delegated Management mode). ISD SP SSD Package Instance Or ISD SP SSD Package Instance FULLY PRELOADED The SSD is created in factory. only the activation of the application remains to be done OTA on the end user’s UICC. the Service Provider only needs to send an activation request to the MNO.The SSD may be created in factory (as represented) or OTA (by the MNO). The personalisation can be done by the Service Provider in factory. the SSD may be created OTA by the MNO Package loading. The following operations are to be done OTA: If UICC application personalisation was not done in factory. the application is loaded in factory. The following operations are to be done OTA: UICC application instantiation and extradition to the security domain of the SP in simple SD are done by the MNO UICC application instantiation in DM is done by the SP UICC application personalisation is done by the SP Mobile NFC service activation is done either by the MNO (Simple SD) or the SP (DM) Package ISD Or ISD SP SSD FULLY OTA In this scenario. [Note] For this Fully preloaded scenario. Simple SD mode) or the SP (upon MNO authorization. the content of the UICC is represented before any OTA operation as available in the end user’s mobile handset.Three different scenarios are considered in these specifications for the UICC application installation. UICC application instantiation and extradition to the security domain of the SP in simple SD are done by the MNO UICC application instantiation in DM is done by the SP UICC application personalisation is done by the SP Mobile NFC service activation is done either by the MNO (Simple SD) or the SP (DM) AFSCM Interface Specification V2. all operations are performed OTA: If necessary. The application is loaded. therefore highlighting all the items that will need to be installed OTA. instantiated and extradited in factory.

First in Simple SD mode o With the personalisation step before the activation step o With the personalisation step after complete installation and activation .4 Process 5 – Mobile NFC UICC application installation Flowchart The following flowcharts present the UICC application installation process: .Then.2. in Delegated Management mode o With the personalisation step after complete installation and activation (A personalisation step before the activation step is also possible but is not represented) Process 5 – Installation of UICC application – Simple SD mode – personnalisation before activation Service Provider Mobile Network Operator Install the mobile NFC service on the UICC Initiate installation Request installation Inform Service Provider of failure No Successful installation? Installation Application personalisation Inform SP of successful installation Yes Notify the MNO about the personalisation completion Request application activation Activate the mobile NFC service Inform Service Provider of failure Inform end user of failure No Successful activation? Inform Service Provider of successful activation Yes Proceed to next steps Figure 15 – Flowchart of process 5 – Mobile NFC UICC application installation in Simple SD mode – personnalisation before activation AFSCM Interface Specification V2.1 – February 2012 – AFSCM Confidential & Proprietary p26/102 .6.

the personalisation step may also occur after the activation.1 – February 2012 – AFSCM Confidential & Proprietary p27/102 . the package is loaded OTA by the MNO: it is thus mandatory that the application certified package(s) and the corresponding installation parameters are available on the MNO’s platform before submitting requests for loading the package. AFSCM Interface Specification V2. the token(s) to the Service Provider Initiate installation Installation Install and activate the mobile NFC service on the UICC No Successful installation & activation? Application personalisation Notify MNO about failure Notify the MNO about the installation.Figure 16 – Flowchart of process 5 – Mobile NFC UICC application installation in Simple SD mode – personnalisation after activation Process 5 – Installation of UICC application – Delegated Management Mode Service Provider Request authorization(s) from the MNO Mobile Network Operator Deliver. In both modes. if authorized. The installation parameters are pre validated by the MNO. personalisation and send the receipts [Note] The activation step may be performed before or after application personnalisation Inform End user of failure Proceed to next steps Figure 17 – Flowchart of process 5 – Mobile NFC UICC application installation in Delegated Management mode Description In simple SD mode.

1 – February 2012 – AFSCM Confidential & Proprietary p28/102 .6.First in Simple SD mode .5 Process 5 Update – Mobile NFC UICC application update Flowchart The following flowcharts present the UICC application update process: .Then. specifying the reason why he is not eligible Process 5 – Installation of UICC application – Simple SD mode Process 3 .2. in Delegated Management mode Process 5 Update – Update of UICC application – Simple SD mode End user Service Provider Initiates update of the mobile NFC service by the Service Provider Mobile Network Operator Installation Replace/renewal of NFC offer (upon request of end user or SP) Sub-process B SP compatibility End user cannot update UICC to service Not compatible Compatible Inform end user about temporary service suspension After some leadtime.End user asks his MNO about available mobile NFC services Figure 18 – Flowchart of process 5 Update – Mobile NFC UICC application update in Simple SD mode AFSCM Interface Specification V2. request application deletion Delete application and inform SP Eligible Not eligible Sub-process A MNO eligiblity Sign contract or contract amendment is necessary Inform end user to contact his MNO.

request application deletion authorization Deliver. .6. .The Service Provider wants to update his NFC service or deploy a new service for one or all of his end users It should be noted that: . It applies in following circumstances: .Since it is necessary to delete the existing application.Process 5 Update – Update of UICC application – Delegated Management Mode End user Service Provider Initiates update of the mobile NFC service by the Service Provider Replace/renewal of NFC offer (upon request of end user or SP) Sub-process B SP compatibility Mobile Network Operator Installation End user cannot subscribe to service Not compatible Compatible Inform end user about temporary service suspension After some leadtime.The eligibility check after the MMI application deletion allows the SP to ensure that there is enough memory space in the UICC for the new application.1 – February 2012 – AFSCM Confidential & Proprietary p29/102 . the SP must first check the compatibility of the end user’s mobile equipment with the new version of the service.6 Process 6 – Service Provider MMI installation / update This process is conditional. The installation process is otherwise similar to the one described in Process 5. specifying the reason why he is not eligible Process 5 – Installation of UICC application – Delegated Management Mode Process 3 . a token to SP Delete application and send a receipt to the MNO Eligible Not eligible Sign contract or contract amendment is necessary Sub-process A MNO eligiblity Inform end user to contact his MNO. .End user asks his MNO about available mobile NFC services Figure 19 – Flowchart of process 5 Update – Mobile NFC UICC application update in Delegated Management mode Description This process is optional and allows the SP to update deployed UICC application OTA.Optionally the end user might have to sign a new contract or contract amendment. if authorized.The end user replaces or updates his mobile NFC service requiring the installation of a new NFC application. 2. It is mandatory when a MMI is necessary for the mobile NFC service. AFSCM Interface Specification V2.

The MNO informs the Service Provider once the MMI is actually loaded in the mobile handset. using the same UICC applications: in this case. Case 3: the end user installs the MMI from an application store In all cases. The MNO manages the entire installation including retries if necessary. There might be several MMIs in a service. Case 2: the Service Provider launches the MMI installation or update. Depending on the agreement between the Service Provider and the MNO. AFSCM Interface Specification V2. It can only be available on NFC mobile handsets sold by the MNOs implementing it. it is not the Service Provider. MNO launches MMI installation/update End user Service Provider MMI needs to be installed MMI needs to be updated MNO MMI needs to be re-installed Installation Option i Accept MMI download ? No MMI installation aborted Yes Request MMI installation Trigger MMI loading on mobile handset Load MMI application Option ii Installation mode Option i Inform SP about MMI triggering MMI loaded Wait for local synchro install notification Is a local synchro mechanism ? No (option ii) Yes (option i) Notify MNO about MMI installation/update Inform SP about MMI loading Proceed to next steps Figure 20 – Flowchart of process 6 – Service Provider MMI installation. the MNO launches the MMI installation or update. case 1 Case 1: description In this case.1 – February 2012 – AFSCM Confidential & Proprietary p30/102 . the MNO manages the retry policy. should several MMIs be installed. it is assumed that the MMI hosting is not under the responsibility of the MNO. in order to load the MMI application on the end user’s mobile handset. there are two possibilities: i. The MMI may be specific to each mobile handset model: the Service Provider is responsible for keeping an up-to-date database of compatible handset models and the associated MMI applications. but the MNO who initiates the OTA connection with the mobile handset. In this situation. this process may be repeated as many times as necessary. This mechanism is an option that can be proposed by the MNO. In case of connection interruption during the MMI loading. there is a local synchronisation mechanism in the mobile handset to ensure the MMI download.There are three ways to initiate this process: Case 1: Upon Service Provider request. Case 1: flowchart Process 6 – Service Provider MMI installation/update Case 1: Upon Service Provider’s request.

the SP notifies the MNO and may: suppress the UICC application. Several reasons might cause failure of the MMI download (network coverage loss. inform the end user in case of installation failure. Case 3: flowchart AFSCM Interface Specification V2. Or the MNO sends a WAP push SMS to the handset to establish a connection with the Service Provider’s MMI server. the SP manages the retry policy. Case 2: flowchart Process 6 – Service Provider MMI installation/update Case 2: Service Provider launches MMI installation/update End user Service Provider MMI needs to be installed MMI needs to be updated Installation Accept MMI download ? Yes No MMI installation aborted Trigger MMI loading on mobile handset Load MMI application MMI loaded Notify MNO about MMI installation/update Proceed to next steps Figure 21 – Flowchart of process 6 – Service Provider MMI installation. In case of connection interruption during the MMI loading. case 2 Case 2: description In this case. It is recommended to attempt several consecutive times to download the MMI before considering that it has failed. the Service Provider is fully in charge of the MMI download and installation.1 – February 2012 – AFSCM Confidential & Proprietary p31/102 .ii. In case the MMI is never installed. end user rejects or does not approve opt-in …). by sending a new request to the MNO. mobile handset switched off.

Process 6 – Service Provider MMI installation/update Case 3: End user installs the MMI from an application store End user End user installs the MMI on an application store Service Provider MMI installation Installation End user launches the application The MMI notifies the Service Provider of the installation Has the end user already subscribed? No Yes Notify MNO about MMI installation/update [Note] Once the end user has subscribed. case 3 Case 3: description In case 3. the end user directly installs his MMI from an application store. during the MMI installation process. the SP must notify the MNO about the MMI installation status Proceed to next steps Notify MNO about MMI installation/update Figure 22 – Flowchart of process 6 – Service Provider MMI installation. the standard update mechanisms used by the application store apply. the SP must build a notification inside the MMI to be triggered at first launch. Thus. because the MMI is already installed (no installation is needed) MMI update completion Failure MMI update [Note] In some cases.1 – February 2012 – AFSCM Confidential & Proprietary p32/102 . MMI update When the Service Provider needs to update the MMI on the end user’s mobile handset. the handset is able to notify the installation to the SP (see installation notification in JAD files for instance). in absence of any such mechanism. the two processes described above (case 1 and case 2) also apply. For case 3. the Service Provider must notify the MNO of the following events: MMI installation completion Failure during MMI installation No MMI has been installed. MMI installation notification In all cases. AFSCM Interface Specification V2. the SP must notify the MNO of the installation or update status: this is particularly important for the MNO to have the correct information in order to deliver the best customer service possible.

to update the MMI for using the mobile NFC service.1 – February 2012 – AFSCM Confidential & Proprietary . This process is conditional since MMI and UICC application binding support is optional for the MNO.6. The Service Provider should use this process when the UICC applications are installed and active. The Service Provider is responsible for such a decision and must notify the MNO.7 Life cycle processes The following processes can be encountered during the use of a mobile NFC service. The MNO always loads the most recent bindings available for this service version.In case the Service Provider estimates that it is urgent and mandatory. the Service Provider is responsible for explicitly requesting the update of the bindings when it is necessary (in case a new version is provisioned on the MNO platform. 2. Their support is mandatory to implement a mobile NFC service and ensure a consistent end user’s experience.7 Process 7 – MMI and UICC application binding Flowchart Process 7 – MMI and UICC application binding MMI & UICC app binding End user Service Provider Request MMI and UICC application binding Mobile Network Operator Load required bindings Inform end user of failure No Binding successful? Yes Proceed to next steps Figure 23 – Flowchart of process 7 – MMI and UICC application binding Description This process is used during the installation process: the SP asks the MNO to bind the MMI and the UICC application. ie “critical”. end user contacts Mobile Network Operator (Process 11) Lost or stolen mobile equipment. end user contacts Service Provider (Process 12) Recover mobile equipment after a lost or theft (Process 13) Get a new mobile equipment after a lost of theft (Process 14) End User requests temporary mobile service suspension (Process 15) p33/102 AFSCM Interface Specification V2. Change UICC (Process 8) Change mobile phone number (Process 9) Change mobile handset (Process 10) Lost or stolen mobile equipment. In case of MMI update. the Service Provider might decide to lock the service until the MMI update is effective. or when the MMI bears a new certificate). 2. This binding adds further security to the MMI access to the UICC applications and could be implemented using ACF files in the UICC for instance.

7. Each party must thus clearly register in its Information System the responsibility of each lock.Set the GlobalPlatform status of SD or the UICC application(s) to LOCKED . PoR messages are blocked) 2. for instance with an EMV script processing command APPLICATION BLOCK) .IS locks o The SP blocks the use of the end user’s service in its Information Systems (IS). the MNO suspends the end user’s line. The locks performed by the Mobile Network Operator are OTA locks.When a user’s line is suspended. They can be of two kinds: .2 Suspended line and restricted line In some situations.OTA locks o The SP sets the GlobalPlatform status of the UICC application(s) of the service to LOCKED o If the UICC application(s) of the service has a built-in lock feature. But it can also be useful to only “restrict” the line in some cases: . [Note] It is recommended that only the party which locked an application is in charge of unlocking it when necessary. This could happen following a theft.- Change in contract ownership (Process 16) End user swaps Mobile Network Operator (Process 17) 2. the SP locks it by sending it the appropriate OTA command (referred to as ‘OTA applicative lock’. he cannot access at all the MNO’s network and thus has no access to any telecom service. blacklist.Use a OTA command which blocks the contactless interface of the UICC The locks performed by the Service Provider could be: . incoming calls or messages are enabled but no outgoing communication is allowed.1 Locking a mobile NFC service The processes in this specification use several ways to lock a mobile NFC service.1 – February 2012 – AFSCM Confidential & Proprietary p34/102 . .When a user’s line is restricted.3 Process 8 – Change UICC Flowchart AFSCM Interface Specification V2. data and SMS (particularly. etc… [Note] There is no guaranty that an OTA lock can be successfully achieved since it requires that the mobile handset be under mobile network coverage and switched on. The SP is then responsible for the corresponding lock policy: temporary or definitive lock. 2.7. like voice.7. loss or in any other process that requires it.

the Service Provider should transfer the entitlements that were stored in the former UICC in the new one. [Note] It is not possible to manage the UICC end of life OTA. to get larger memory space or to get additional features. in order to ensure service continuity after a UICC change. In addition. 2.Figure 24 – Flowchart of process 8 – Change UICC Description Changing UICC can be proposed to the end user either because the UICC is out of order.1 – February 2012 – AFSCM Confidential & Proprietary p35/102 . regarding the destruction of the old UICC. The responsibility of the end user must thus be mentioned in MNO and Service Provider contracts. Changing the UICC requires to reinstall the UICC application.4 Process 9 – Change mobile phone number Flowchart AFSCM Interface Specification V2.7.

mobile handset or MNO) End user Mobile Network Operator Use 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 Figure 25 – Flowchart of process 9 – Change mobile phone number Description The end user changes his mobile phone number without changing his UICC. mobile phone or Mobile Network Operator.7. If needed. The Mobile Network Operator notifies the Service Provider about the change of idTech.Process 9 – Change mobile phone number (without changing UICC. 2. This change results in a change of the technical identifier (idTech) that can be used to identify the end-user between Mobile Network Operator and Service Providers.5 Process 10 – Change mobile handset Flowchart AFSCM Interface Specification V2. the Service Provider must contact the end user to get his new mobile phone number.1 – February 2012 – AFSCM Confidential & Proprietary p36/102 .

the “local detection application” operates connects to the Service Provider’s servers to download the MMI. Once the end user inserts the UICC in a new mobile handset: . It can only be available on mobile handsets sold by the MNOs supporting it.Or the Mobile Network Operator remotely detects that the mobile handset has changed.Either a local detection is done on the mobile handset to identify that MMI are missing compared to the content of the UICC.) If there is a local application for detection of missing MMI. Yet.1 – February 2012 – AFSCM Confidential & Proprietary p37/102 . an opt-in is presented to the end user: if the end-user opts in. as the mobile change may be temporary.Figure 26 – Flowchart of process 10 – Change mobile handset Description When the end user changes his mobile handset. 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. (An application detecting missing MMIs on the mobile handset is an option that can be implemented by the MNO. . it is convenient to provide him with assistance for launching the installation of the MMI for each mobile NFC service hosted in his UICC. AFSCM Interface Specification V2. the MNO notifies all relevant Service Providers about the end user’s new handset so that each Service Provider can invite the end user to download the MMI again and benefit from full capacity of his mobile NFC service. In case the detection is done remotely on his information system.

.. 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 his services and existing entitlements. 2.) If not already done. end user contacts MNO Flowchart Process 11 – End user’s mobile equipment was lost or stolen. End user End user contacts his MNO Service Provider Mobile Network Operator Identify End user of mobile NFC service Launch appropriate process (IS lock or black/grey-list. the Service Provider must apply a IS lock on the end user’s service and apply his own loss or theft policy.7 Process 12 – Lost or stolen mobile equipment.1 – February 2012 – AFSCM Confidential & Proprietary p38/102 . some MNO may restrict the line instead of suspending it. End user contacts his MNO. OTA lock.. contacts his Service Provider(s) Notify lost/stolen mobile to the Service Provider(s) * Use Invite the end user to contact his Service Provider(s) * Try to lock the mobile NFC services OTA if possible before line suspension * Suspend the mobile connection Launch appropriate process (IS lock or black/grey-list. . Figure 27 – Flowchart of process 11 – Change UICC Lost or stolen mobile equipment. OTA lock. The SP will then be notified of a line restriction instead of a line suspension.) Notify the Service Providers 1) About end of mobile connection 2) and the OTA lock status Notify MNO about applicative locking [Note] Actions identified with * are processed simultaneously Process 12 – End user’s mobile equipment was lost or stolen. definitive IS lock. End user contacts his Service Provider. The MNO will thus attempt to lock OTA all mobile NFC services hosted on the end user’s mobile equipment or its UICC NFC interface before line suspension..6 Process 11 – Lost or stolen mobile equipment.7. end user contacts MNO Description Since the lost / stolen UICC is left in an uncontrolled environment. [Note] In some cases. end user contacts Service Provider Flowchart AFSCM Interface Specification V2.2. . definitive IS lock. Regardless of the success or not of the OTA lock performed by the MNO.7.

The SP must thus authenticate the end-user before notifying the MNO. OTA lock.Process 12 – End user’s mobile equipment was lost or stolen.1 – February 2012 – AFSCM Confidential & Proprietary p39/102 . definitive IS lock.. End user Service Provider End user contacts his Service Provider Use Identify and authenticate End user for mobile NFC service. End user contacts his MNO.7. end user contacts SP Description The Service Provider must set up appropriate entry points within its customer service to ensure the correct management of mobile NFC services in case of loss or theft. 2. End user contacts his Service Provider.. contacts his MNO Launch appropriate process (IS lock or black/grey-list. Invite end user to contact his MNO Notify MNO about End user’s call If not already done.) Attempt to lock OTA the mobile NFC application Notify MNO about lock status Process 11 – End user’s mobile equipment was lost or stolen.8 Process 13 – Recover mobile equipment after a loss (or theft) Flowchart AFSCM Interface Specification V2. Figure 28 – Flowchart of process 12 – Change UICC Lost or stolen mobile equipment. .

there are two possibilities on line restoration: . the SP unlocks it on its IS.If the service was reversibly locked.9 Process 14 – Get a new mobile equipment after a loss or theft Flowchart AFSCM Interface Specification V2. the End user recovers his mobile equipment and UICC End user End user contacts his MNO Service Provider Mobile Network Operator Restore the mobile connection and inform End User Try to unlock the mobile NFC services OTA Use Unlock service on Information System No Was the mobile NFC service permanently locked on IS? Notify the Service Provider(s) No Was the mobile NFC Service OTA locked ? Yes OTA Unlock mobile NFC service Yes Notify MNO Inform End user that mobile NFC service is ready to use Delete previous application(s) Proceed to mobile NFC service installation Figure 29 – Flowchart of process 13 – Recover mobile equipment after a loss (or theft) Description After a loss or theft.If the service was permanently locked. It is thus necessary to suppress the old version of the service.1 – February 2012 – AFSCM Confidential & Proprietary p40/102 . 2.Process 13 – After a loss or theft.7. . the SP must entirely reinstall the mobile NFC Service.

7.1 – February 2012 – AFSCM Confidential & Proprietary p41/102 . the SP should proceed to the eligibility and installation steps after the reactivation notification. the Service Provider should transfer the entitlements that were stored in the former UICC in the new one. the End user has a new NFC mobile handset and UICC and wants to restore his mobile NFC service End user End user contacts his MNO Provide end user’s new equipement Restore end user’s mobile connection Service Provider Mobile Network Operator Use Notify Service Provider of new equipment Mobile equipment eligibility and compatibility check Eligible Sub-process A MNO eligiblity Not eligible Notify Service Provider of line reactivation Not compatible Sub-process B SP compatibility Compatible End user cannot benefit from service Inform End user to contact his MNO. In order to ensure service continuity. specifying the reason why he is not eligible Proceed to mobile NFC service installation Figure 30 – Flowchart of process 14 – Get a new mobile equipment after a loss of theft Description The SP is notified of the end user’s new equipment and of its line re-activation. 2. It must be noted that eligibility and compatibility check are required since the notification does not imply that the new equipment is NFC compatible.Process 14 – After a loss or theft.10 Process 15 – End User requests temporary mobile service suspension Flowchart AFSCM Interface Specification V2.

7. or don’t know End users agree to transfer mobile NFC service contract ownership Yes No No SP contacts the old and new contract owners SP update its Information System Process 20 – Termination of mobile NFC service AFSCM Interface Specification V2.Process 15 – End User requests temporary mobile service suspension End user Service Provider Mobile Network Operator Acknowledge end user’s request and agree on suspension date and restore date End User requests temporary mobile service suspension Transfer entitlements and lock of service on information system At suspension date.1 – February 2012 – AFSCM Confidential & Proprietary p42/102 .11 Process 16 – Change in contract ownership Flowchart Process 16 .Change in contract ownership End user Contract owner contacts his MNO to transfer his ownership Does the mobile NFC service support ownership transfer? Yes No Service Provider Mobile Network Operator Transfers contract ownership Notifies the SP of the contract ownership change Termination Was the new owner of the contract the end user of the line? Yes. restore the line and notify the Service Providers Notify MNO Figure 31 – Flowchart of process 15 – End User requests temporary mobile service suspension Description At the request of the end user. suspend the line and notify the Service Providers Use Notify MNO End User requests line restore before or at earlier agreed date Unlock service on SP information system At restore date. 2. he and the MNO agree on a suspension date and a restoration date. The Service Providers are notified after the suspension and restoration performed by the MNO at these dates.

2.7. It should be noted that in all termination processes.8 Termination processes There are three mobile NFC service termination processes: . He has to go through two consecutive steps: . while keeping the same phone number and wants to keep the mobile NFC services.8. 2.Mobile subscription or NFC option termination by end user (Process 18) .Figure 32 – Flowchart of process 16 – Change in contract ownership Description The owner of the contract with the MNO changes. a line termination is permanent.Mobile subscription termination (Process 18) with the first Mobile Network Operator.12 Process 17 – End user swaps Mobile Network Operator Description The end user changes Mobile Network Operator.and then service installation with the new Mobile Network Operator (Process 5) Restrictions specific to version 2 Automated inter-MNO portability of mobile NFC services is out of scope of version 2 of this specification.1 – February 2012 – AFSCM Confidential & Proprietary p43/102 .1 Process 18 – Termination of Mobile subscription or NFC option by end user Flowchart AFSCM Interface Specification V2.Mobile service termination by Mobile Network Operator (Process 19) . . the end user is responsible for destroying the UICC 2. Two cases occur: The new owner of the contract was the end user of the phone line. the MNO may not be able to know if the new end user is habilitated to use the mobile NFC services of the previous end user. and thus the user of the mobile NFC services (which usually happens when a parent passes the contract on to a child who comes of age) The new owner of the contract was not the end user of the phone line Restrictions specific to Version 2 In Version 2 of this specification.Mobile NFC service termination (Process 20) Unlike a suspension or a restriction.

2 Process 19 – Mobile service termination by Mobile Network Operator Flowchart AFSCM Interface Specification V2.8. permanently stop mobile service or NFC option Transfer end user’s entitlements Notify Service Provider about line or NFC option termination Service lock on Information System End user is responsible for destroying his UICC in case of mobile service termination Notify MNO about lock status Figure 33 – Flowchart of process 18 – Termination of mobile subscription or NFC option by end user Description Termination of the mobile subscription or of the NFC option takes place at a termination date. try to lock the mobile NFC services OTA At termination date.1 – February 2012 – AFSCM Confidential & Proprietary p44/102 .Process 18 – 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 Mobile Network Operator Acknowledge request for termination And agree with end user on termination date Cooling-off period [Note] The end user has a cooling-off period to cancel the termination Inform End user that he should either use the remaining rights in his mobile or contact his Service Provider’s for transferring his rights to another support At termination date Termination At termination date. 2. Upon reception of the termination notification. agreed between the end user and the MNO. the Service Provider can organize the transfer of entitlements available in the current UICC.

respectively.1 – February 2012 – AFSCM Confidential & Proprietary p45/102 . try to lock the mobile NFC services OTA Definitly stop End user’s line access to mobile NFC services Transfer entitlements and applicative lock on SP information system End user is responsible for destroying his UICC in case of mobile service termination Notify Service Providers about end of mobile service. The Service Provider might do this action earlier. AFSCM Interface Specification V2. Notify MNO about locking Figure 34 – Flowchart of process 19 – Mobile service termination by Mobile Network Operator Description Upon reception of the termination notification. in Simple SD mode and Delegated Management mode. the Service Provider can organize the transfer of entitlements that were available in the current UICC.Process 19 – Mobile service termination by MNO End user End user doesn’t respect the MNO’s contract conditions Service Provider Mobile Network Operator Initiate the dispute process Subscription Notify End user about related risks and inform about suspension/restriction date of mobile service Initiate process for mobile service suspension/restriction and notify again the end user Suspend End user’s line and notify Service Provider about line suspension/ restriction End user settles the situation Yes End No End user settles the situation No Initiate process for End user’s mobile service termination Yes Restore the line and Notify Service providers Termination At termination date.3 Process 20 – Mobile NFC service termination Flowchart The following figures present the mobile NFC service termination process.8. upon reception of the notification for line suspension. 2.

AFSCM Interface Specification V2. Once the Service Provider launches the termination process: . and that he should delete the MMI Figure 36 – Flowchart of process 20 – Mobile NFC service termination in Delegated Management mode Description Two reasons can lead to the mobile NFC service termination: . and that he should delete the MMI Figure 35 – Flowchart of process 20 – Mobile NFC service termination in Simple SD mode Process 20 – Mobile NFC service termination – Delegated Management Mode End user Service Provider Service Provider terminates the End user’s mobile NFC service Mobile Network Operator End user wants to suppress mobile NFC service from his mobile Termination Launch process for mobile NFC service termination and request MNO authorisation to delete application Application deletion Deliver. if authorized.in Simple SD mode.Process 20 – Mobile NFC service termination – Simple SD Mode End user End user wants to suppress mobile NFC service from his mobile Service Provider Service Provider terminates the End user’s mobile NFC service Mobile Network Operator Termination Launch process for mobile NFC service termination and request MNO to delete application UICC application deletion (and SSD deletion if relevant) End of mobile NFC service on Information System Deletion of bindings if necessary Inform End user about end of mobile NFC service. the MNO performs the deletion of the service on the UICC and notifies the deletion status to the SP.The end user’s wants to suppress the application from his mobile handset or to terminate the mobile NFC service.1 – February 2012 – AFSCM Confidential & Proprietary p46/102 . a token to SP Notify and send receipt tokens to MNO Deletion of bindings if necessary Request SSD deletion (if the SSD is not used anymore) Deletion of SSD End of mobile NFC service on Information System Inform End user about end of mobile NFC service. .Or the Service Provider wants to terminate the mobile NFC service for this end user.

The Service Provider is responsible for asking the deletion of the SSD. the SP performs the deletion using the tokens provided by the MNO and notifies the MNO about the status of the deletion.1 – February 2012 – AFSCM Confidential & Proprietary p47/102 .in Delegated Management mode. - AFSCM Interface Specification V2.

mobile subscription … Functions and requests are always issued by the Service Provider and their responses are generated by the MNO.1. All the requests related to the management of the mobile NFC services are handled on this interface.1.1 – February 2012 – AFSCM Confidential & Proprietary p48/102 . response or notification concerns one single end user (msId). This interface defines the following types of requests: .Control functions used to query the eligibility of the end user for mobile NFC service.3 Naming conventions Synchronous function  Asynchronous request  Asynchronous response  Notification  functionName requestNameReq responseNameResp notifNotifName AFSCM Interface Specification V2.Notifications between Service Provider and Mobile Network Operator related to the life cycle of the UICC.2 Elementary requests / batch Each request. and must be implemented by Service Providers. except when explicitly written otherwise. Figure 37 – Architecture overview 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. 3.1. Notifications can be sent both ways. 3. mobile handset. .1 Implementation The entire content of this section is implemented by MNO.3 3. mobile NFC service application. activation and deletion of the Mobile NFC service application.Requests and responses related to the installation. . No request is provided to handle batch processing.

– numeric on 19 digits o Additional diversifier – numeric on 2 digits For instance: 14560:223372036854:21 The asynchronous requests and their responses require a synchronous acknowledgement. The transaction identifier (requestId) is composed of three data blocks separated by colons: o serviceId– numeric up to 5 digits o Timestamp in milliseconds. Functions require a direct and synchronous answer.1 Data types.1.4 Data types This specification uses standard data types such as integer. These data types are defined in section 3. In case an exception is thrown. Representation The following sequence diagram illustrates the various synchronous and asynchronous exchanges.5 Synchronous and Asynchronous Synchronous functions and notifications The functions in the interface that do not need any remote access to the UICC or mobile handset. Those requests use a unique transaction identifier (requestId).1 – February 2012 – AFSCM Confidential & Proprietary p49/102 . ask the MNO for the idTech of the and user createOrAllocateSsdResp (abc) acknowledge (…) getIdTech getIdTech output Sends idTech in the synchronous answer Synchronous function and notification Sends a notification after end user call to declare mobile phone lost notifCallEndUserToMno acknowledge (…) Asynchronous request call Asynchronous request and functions may receive exceptions Perform error management createOrAllocateSsdReq (abc) faultDetails Detects an error in the request Throws an exception. or an exception. generated by the party sending the request. Service Provider Mobile Operator Generate a request and a unique transaction identifier Asynchronous request and its response Receives acknowledgement createOrAllocateSsdReq (abc) acknowledgeWithValidityPeriod Receives the request Acknowledge the reception of the request Perfoms the actions for SSD creation Send response with the transaction identifier Receives acknowledgement Receives response Acknowledge the reception of response Gets a phone call. which can be an exception in case a format error or a data error is identified in the parameters of the request.3. no asynchronous response will be sent Detects an error in the function call Throws an exception Synchronous function call getIdTech faultDetails Figure 38 – Sample sequence diagram of synchronous and asynchronous exchanges AFSCM Interface Specification V2.1. as well as the notifications. Notifications require a synchronous acknowledgment.9. string. no asynchronous response will be sent. etc… and defines custom data types. 3. Asynchronous requests and responses The requests in the interface that do require remote access to the UICC or mobile handset are asynchronous. are synchronous and require synchronous answers. The same transaction identifier is sent in the asynchronous response to match responses to requests.

TYPE syncHeader Header for Synchronous Requests p50/102 AFSCM Interface Specification V2.1.1 – February 2012 – AFSCM Confidential & Proprietary . generated by the Service Provider. When receiving this retry attempt. it is important to define how to manage the retries. SP sends asynchronous request (SP validity period = SP vp) MNO check: is request is a retry? No MNO checks SP validity period SP validity period compatible with MNO policy Yes. then the MNO shall refuse the new call. which is passed in the asyncHeader header. The period starts at the time the function call was received by the MNO and ends a number of seconds later.6 Retries and validity period management for asynchronous requests When using asynchronous requests. the MNO has the responsibility to execute all the individual execution steps that are required to complete the request. in the asyncHeader header. This field defines the length of the period (provided as a number of seconds) during which the request is valid. When sending a retry of a request. which entail OTA commands execution.2 Headers 3.2. the identifier must be the same as the one that has been sent first. with execution status Agreed validity period expires before end of request execution MNO sends response. with status « Validity period expired » Figure 39 – Validity period management 3. Validity period Each asynchronous request has an optional validity period that can be set by the Service Provider. this is a retry of a still ongoing request Exception: Request is still being processed No SP vp or SP vp not compatible with MNO policy MNO send acknowledgment with SP validity period MNO send acknowledgment with MNO vp Request execution with agreed validity period Execution finishes before expiration of agreed validity period MNO sends response. During this period. the Mobile Network Operator is able to track retries.3. The following flowchart details how the validity period is to be implemented. Request identifier Each asynchronous request is marked with a unique identifier. and if a call to a request is performed with an identifier of a request already in progress in its system.1 syncHeader – Header for Synchronous Requests This header is applicable to synchronous requests and notifications.

duration in seconds. Providing data in this field will have no impact 3.1 – February 2012 – AFSCM Confidential & Proprietary p51/102 . for more details. There are two different types of acknowledgments: o A simple HTTP acknowledgment o An acknowledgment with a validity period . see section Retries and validity period management Service Identifier Mobile NFC Service version Header for Asynchronous Requests Presence Mandatory Mandatory Mandatory Mobile subscription identifier SSD Manager Identifier Validity period of the request.The exception is used in case an error is detected 3. It requires a transaction identifier.The acknowledgments are used to acknowledge the successful reception of a request. The SP sends a standard acknowledgement as a synchronous answer to each notification received from the MNO.2 asyncHeader – Header for Asynchronous Requests This header is applicable to asynchronous requests. see section Retries and validity period management Mandatory Optional (RFU) (1) Optional 1. Providing data in this field will have no impact 3.3.Data name serviceId type: N(5) serviceVersion type: version msId type: msId ssdmId type: N(3) Description Mobile NFC Service identifier Mobile NFC Service version Presence Mandatory Mandatory Mobile subscription identifier SSD Manager Identifier Mandatory Optional (RFU) (1) 1.2. . For more information. No particular structure is defined for this simple HTTP acknowledgment. This item is reserved for future use. This item is reserved for future use.3 Acknowledgments and exceptions The acknowledgments and exceptions are synchronous responses to requests or notifications.1 acknowledge The MNO sends a standard acknowledgement as a synchronous answer to each notification received from the Service Provider. AFSCM Interface Specification V2. TYPE asyncHeader Data name requestId type: requestId serviceId type: N(5) serviceVersion type: version msId type: msId ssdmId type: N(3) validityPeriod type: N Description Transaction identifier (unique) This identifier enables the implementation of retry policies.

duration in acceptedValidityPeriod seconds.Alias: identifier usually linked to the WAP or mobile internet . synchronous Description Presence Indication of the type of error encoutered.1 Technical Identifier idTech Mobile Subscription identifier Most headers in the interface specification identify the mobile subscription using a mobile subscription identifier call msId.3 faultMsg The MNO throws an exception faultMsg as a synchronous answer to each synchronous or asynchronous request when a format or data error is detected.3. An exception (faultMsg) can be thrown by the MNO and by the Service Provider. The exception (faultMsg) contains information about the type of error detected and optionally which data failed.4 Identifiers 3. which can take be one of the following: . dedicated to mobile NFC services IdTech introduction For regulatory and confidentiality reasons. synchronous Data name Description Presence Accepted validity period of the request. in the earlier steps of a mobile NFC service installation. it cancels the process and no asynchronous response corresponding to this request will be sent. Data identifier (ex : Optional mnoId.4 Exceptions Indication of the data that failed the control.1 – February 2012 – AFSCM Confidential & Proprietary p52/102 . Mandatory Possible values are listed in section 3. ACKNOWLEDGEMENT acknowledgeWithValidityPeriod MNO  SP. idTech. For more information. it is recommended that. When an exception (faultMsg) is thrown in response to an asynchronous request. the MSISDN may be transmitted by the Mobile Network Operators. EXCEPTION faultMsg Data name errorType type: N(3) errorDetails type: char(var) SP  MNO or MNO  SP.4.9.3.2 acknowledgeWithValidityPeriod The MNO sends an acknowledgement acknowledgeWithValidityPeriod as a synchronous answer to each asynchronous request received from the Service Provider. …) 3. The idTech shall be generated by the Mobile Network Operator respecting the following rules: AFSCM Interface Specification V2. Thus. in some countries. see section Retries and Mandatory type : N validity period management 3. the MNO will convert the MSISDN into a technical identifier named idTech to communicate with the Service Providers.MSISDN: the phone number of the user .3.idTech: a technical identifier.

. It is a unique value for a combination of a Service (of a given Service Provider) and a set of UICC applications (packages + instances). as described in section 2. for instance to send SMS PUSH BIP and SMS PUSH WAP. In France. idTech life cycle The table below summarizes impacts of end user cases on idTech life cycle. due to legal restrictions.4. the MNO will enforce the use of idTech and diversify the idTech identifier using the end user’s MSISDN and either the Service Provider ID or the service’s serviceId idTech use When the idTech is used as the identifier between MNO and SP. AFSCM Interface Specification V2. the service identifier is attributed by the AFSCM. is identified by a service identifier serviceId.1. Receives new idTech Table 1: idTech life cycle 3. when another identifier than the idTech is used in the other methods. with a maximum length of 16 alphanumeric characters. known that a given package can be shared between several serviceId.It shall be a unique intra MNO identifier of variable length depending on the Mobile Network Operator. the Unsupported identifier exception must be thrown by the MNO. Receives new idTech No change No change idTech Status (MNO) Generates Suppresses idTech Status (SP) Receives Suppresses Suppresses old idTech. only the getIdTech and the fullEligibilityCheck methods can be used with another identifier such as the MSISDN or the alias. [Note] In France. The idTech is generated upon reception by the Mobile Network Operator of an eligibility request or the getIdTech request described in the next paragraphs. End User Cases Service activation Termination. the idTech identifier can be identical to the WAP ALIAS identifier.2 Service Identifiers: serviceId and serviceVersion Each mobile NFC service. By default.The idTech shall enable the Mobile Network Operator and the Service Provider to address the end user’s mobile handset or UICC via a mobile network access platform. idTech distribution mode Distribution of the idTech 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. 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 suppresses old idTech. responses and notifications. In this case. New MNO generates new idTech Suppresses old idTech Generates new idTech Suppresses old idTech.1 – February 2012 – AFSCM Confidential & Proprietary p53/102 .6.

synchronous Input data name Description Presence syncHeader Synchronous Message Header Mandatory Output data name Description Presence iccId UICC identifier.1 – February 2012 – AFSCM Confidential & Proprietary p54/102 . for compatibility checking or key set diversification for instance.5 Control functions There are several control functions. each one serving a different purpose: getUICCProfile: the MNO provides the SP details about the end user’s UICC getMobileHandsetProfile: the MNO provides the SP details about the end user’s handset isEligible : the MNO checks the end user’s eligibility to the service getIdTech: the MNO provides the SP with the end user’s idTech fullEligibilityCheck requires the MNO to perform all of the above controls in one single step. When requiring operations on an installed service. Conditions of use It may be called anytime and only depends on the SP knowing an end user’s subscription identifier. Unique value per UICC that can be used Mandatory in the SSD keys diversification process.UICC application packages and their associated installation parameters can evolve. It is therefore necessary to also manage a service version (serviceVersion) 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. 3.5.1 getUICCProfile Use This function is to be used by the SP needing information on the end user’s UICC. The serviceVersion in particular must be use cautiously: When requiring the MNO to install its mobile NFC service. type: iccId uiccProfile Reference to a smart card manufacturer and operating Mandatory type: uiccProfile system Resulting actions The Mobile Network Operator does not perform any eligibility check and only returns the required information. The serviceId and serviceVersion are essential data on the Service Provider / MNO interface: They precisely identify a service and its associated technical data that is provisioned on the MNO platform They are exchanged in the header of all the requests and notifications. Description FUNCTION getUICCProfile SP  MNO. AFSCM Interface Specification V2. and to return the end user’s idTech 3. all synchronous. avoiding the use of AID or other technical details. the SP must provide the correct serviceVersion of the service that is installed. the SP must provide the serviceVersion of the service to be installed.

for compatibility checking for instance. an exception of type “Service already installed” will be thrown.3 isEligible Use This function is to be used by the SP needing information on the end user’s eligibility.If the UICC is not NFC compliant. It only depends on the SP already knowing an end user’s subscription identifier. 3. 3. the Service Provider should then resume the installation.end user’s mobile ALIAS: Subscription via a WAP session (Process 4) for instance . an exception of type “Installation in progress” will be thrown. synchronous Input data name Description Presence syncHeader Synchronous Message Header Mandatory Output data name Description Presence mobileHandsetId Reference TAC code or IMEI of the end user’s handset Mandatory type: mobileHandsetId Resulting actions The Mobile Network Operator does not perform any eligibility check and only returns the required information.end user’s current IdTech: In case of application update (Process 5 Update) for instance Conditions of use Its purpose is to be called during the subscription process (Process 4) in case the Service Provider needs the eligibility status.1 – February 2012 – AFSCM Confidential & Proprietary p55/102 . .If an installation is already in progress for this service. the MNO may throw an exception with the 402 code. If the mobile handset is not NFC compliant.If the service is already installed in this version. It may be called anytime except in the following cases: . the Service Provider can use this function using the following end-user identifiers: . the MNO may throw an exception with the 403 code.2 getMobileHandsetProfile Use This function is to be used by the SP needing information on the end user’s handset.5.end user’s MSISDN: Subscription at Service Provider's local office or on web site (Process 4) for instance . Depending on the context.5. Conditions of use It may be called anytime and only depends on the SP already knowing an end user’s subscription identifier. Description FUNCTION getMobileHandsetProfile SP  MNO. Description AFSCM Interface Specification V2.

Technical (mobile handset and UICC NFC capable).5. If the end user is eligible the Mobile Network Operator generates the idTech. If the end user is not eligible. an exception is thrown SP  MNO. available memory space on UICC. . synchronous Presence Mandatory Presence Mandatory Resulting actions The Mobile Network Operator checks the eligibility of the end user to the service according to the following criteria: . synchronous Presence Mandatory Presence Mandatory Resulting actions The Mobile Network Operator does not perform any eligibility check and only returns the required information.5 fullEligibilityCheck Use fullEligibilityCheck is a request cumulating the features of the more modular functions: AFSCM Interface Specification V2. . particularly regarding the available memory space on the UICC. 3. Description FUNCTION getIdTech Input data name syncHeader Output data name idTech type: idTech Description Synchronous Message Header Description Technical Identifier of the line SP  MNO. the MNO will throw an exception of type “Incompatibility” (see section 3. Conditions of use It may be called anytime and only depends on the SP already knowing either the end user’s MSISDN or alias identifier. the way the eligibility check is performed might differ from one MNO to another. 3. Restrictions specific to version 2 In version 2 of this specification. if supported by the MNO.3 Response codes to asynchronous requests).Commercial (access to NFC services). If not.FUNCTION isEligible Input data name syncHeader Output data name eligible type: boolean Description Synchronous Message Header Description True if the end user is eligible.9.1 – February 2012 – AFSCM Confidential & Proprietary p56/102 .5.And.4 getIdTech Use This function is to be used by the SP needing to get an end user’s IdTech corresponding to another known identifier.

if supported by the MNO.getUICCProfile getMobileHandsetProfile isEligible getIdTech Depending on the context. It only depends on the SP already knowing an end user’s subscription identifier.1 – February 2012 – AFSCM Confidential & Proprietary p57/102 . available memory space on UICC. synchronous Input data name Description Presence syncHeader Synchronous Message Header Mandatory Output data name Description Presence idTech Technical Identifier of the line Mandatory type: idTech iccId UICC identifier Mandatory type: iccId uiccProfile Reference to a smart card manufacturer and operating Mandatory type: uiccProfile system mobileHandsetId Reference of the mobile handset model. If not. It may be called anytime except in the following cases: . the Service Provider should then resume the installation. . the Service Provider can use this function using the following end-user identifiers: . Restrictions specific to version 2 AFSCM Interface Specification V2.9.If the service is already installed in this version. Description FUNCTION fullEligibilityCheck SP  MNO. .end user’s current IdTech: In case of application update (Process 5 Update) for instance Conditions of use Its purpose is to be called during the subscription process (Process 4) in case the Service Provider only needs an “all-in-one” request. If the end user is eligible the Mobile Network Operator generates the idTech. the MNO will throw an exception of type “Incompatibility” (see section 3. an exception of type “Service already installed” will be thrown.And.end user’s MSISDN: Subscription at Service Provider's local office or on web site (Process 4) for instance .Commercial (access to NFC services).If an installation is already in progress for this service. . a TAC or IMEI type: mobileHandsetId Mandatory Resulting actions The Mobile Network Operator checks the eligibility of the end user to the service according to the following criteria: .Technical (mobile handset and UICC NFC capable).3 Response codes to asynchronous requests).end user’s mobile ALIAS: Subscription via a WAP session (Process 4) for instance . an exception of type “Installation in progress” will be thrown.

Description REQUEST createOrAllocateSsdReq Input data name Description asyncHeader Message Header for Asynchronous Request parentAid AID of the parent SSD of the SSD to be created type: aid Output data name Description acknowledgeWithValidityPeriod MNO acknowledgment of the request RESPONSE createOrAllocateSsdResp Input data name requestId type: requestId responseCode type: responseCode Description Transaction identifier (unique) SP  MNO. the createOrAllocateSsdResp does not contain any keys.3 Response codes to asynchronous requests for a list of possible error returned by this request and for error management.6 Installation requests 3. 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 way the eligibility check is performed might differ from one MNO to another. the Service Provider must have the idTech of the end user in order to send this request. Once the Service Provider has a SSD assigned.6. the MNO returns 210 as a response code and may or may not send the SSD keys.1 createOrAllocateSsdReq and createOrAllocateSsdResp Use This request is used by the Service Provider to request a SSD creation or a SSD assignation. When the MNO does not manage the SSD keyset.9. depending on a separate agreement between the SP and the MNO.1 – February 2012 – AFSCM Confidential & Proprietary .or if the Service Provider needs to receive the SSD key set.if the Service Provider has not been allocated a SSD yet (whether the SSD needs to be created OTA or not) .In version 2 of this specification. When the idTech is used as the mobile subscription identifier. This request is conditional. Conditions of use The request for SSD creation is the first step of the installation process. In case the Service Provider already has a SSD assigned and calls again the createOrAllocateSsdReq request. asynchronous Presence Mandatory Optional (1) Presence Mandatory MNO  SP. use of this request is not necessary anymore. it is mandatory only: . asynchronous Presence Mandatory List of elements named “ssdInfo”of type ssdInfo Mandatory Refer to section 3. key value length depends p58/102 AFSCM Interface Specification V2. particularly regarding the available memory space on the UICC. 3. Conditional (3) A list (2) of elements of type ssdInfo SSD keys may be encrypted (on agreement between SP and MNO).

14 and 15 of the AID.2 getTokens Use The getTokens function is used by the Service Provider to get the authorization from the MNO to execute GP commands on the UICC. if necessary. For more details. It is recommended that the keys be encrypted with AES.e banking SPs) need to change those keys after NFC service installation. The mechanism that has been chosen by French MNOs is based on the “Push 2-B” scenario and does not require any technical interface between SP Platform and MNO Platform. the keyset of the SSD. Global Platform defines several mechanisms described in [R14] UICC configuration 1. 3. Mandatory if key set managed or loaded OTA by MNO and required by SP. and assigns it to the service of the SP In its response. please refer to [R14] UICC configuration 1. The MNO may create more than one SSD: presence of additional SSD AID depends on agreement between SP and MNO 3.1. the MNO sends the AID of the SSD and.1 and based on the support of GP 2.1 – February 2012 – AFSCM Confidential & Proprietary p59/102 . Initially (before SSD allocation). KeyTable presence depends on an agreement between SP and MNO [Note] The TAR is composed of bytes 13. Several token can be retrieved in a single getTokens request and it is recommended to request all the tokens necessary for a UICC before establishing the OTA connection. The privilegies given to the SSD associated with the Service Provider are defined by the MNO at provisioning time. The Service Provider prepares the Global Platform Card Content Management commands that are necessary and sends token requests for these CCM commands.6. [Note] The algorithm to be used for KCV (key check value) depends on the card profile. with a key length of 256 bits Description SP acknowledgment of the response Presence Mandatory 1.0. Presence indicates that the SSD is to be created in a hierarchy as a sibling of the parentAid SSD. 2.2 Amendment A. these keysets are considered to be sensitive data that only SPs should have access to. Thus.Output data name acknowledge on the encryption. In order to secure the process of renewing SSD Keysets and prevent the MNO from decrypting the new keysets enciphered with the previous ones that he may know. SSD keyset renewal In order to secure communications between SP Platforms and their NFC applications on the UICC. All data exchanges are done on the interface between the SP platform and the UICC. keysets could be managed by the MNO (for pre-created SSDs for instance). the MNO only assigns a SSD to the service of the SP if a SSD was created in factory and available sends OTA a command to create a SSD in the UICC.0. Therefore some SPs (i. AFSCM Interface Specification V2. The information will be exchanged between MNO and SP during the provisioning phase Resulting actions Upon reception of the createOrAllocateSsdReq request. the sender (SP Platform) uses SSD SCP 80 and SCP 02 keysets to encrypt OTA commands.

1 – February 2012 – AFSCM Confidential & Proprietary p60/102 .Conditions of use getTokens can only be used in Delegated Management mode. add "Card Image Number" or "Token identifier" in order to insure Token diversification). UICC application update (Process 5 Update) Mobile NFC service termination (Process 20) The following restrictions will be applied to the tokens delivered by the MNO: A token can be used with one and only one UICC: for instance. getTokens is used in the following context: UICC application installation (Process 5). Description FUNCTION getTokens Input data name syncHeader List of elements named “ccmCommand” of type ccmCommand SP  MNO. updated by the MNO to comply with security rules (for instance. the Service Provider must contact the MNO. when the token key is not diversified for each card. Each token is a HEX(var) composed of Mandatory “token” of type HEX(var) TLV format data The length of the output tokens list is the same as the length of the input ccmCommands list List of elements named A list of one or several ccmCommand representing the Conditional (2) “updatedCcmCommand” Card Content Management commands to be of type ccmCommand delivered/ executed in the UICC. synchronous Description Presence Synchronous Message Header Mandatory A list of one or several ccmCommand representing the Mandatory Card Content Management commands to be delivered/ executed in the UICC (1) The APDU are the commands to be signed by a token calculation APDU format should follow the following rules: token length SHALL NOT be included LC byte shall be adapted in consequence Description Presence Output data name List of elements named A list of tokens. Should such need arise. the CIN will be added in the GP Command before token generation A token can be used only to execute the command it has been requested for A token can only be used once: a command that has been executed with a token cannot be executed again with the same token SSD creation in Delegated Management mode will not be authorized in this version of the specification: SSD with Delegated Management privileges will be either created in factory or OTA by the MNO The Mobile Network Operators will not allow use of tokens targeting several UICC. AFSCM Interface Specification V2.

ACTIVATE . . (3) 1. the CCM commands must be given in the order they are intended to be delivered/executed in the Secure Element.6.3 installReq and installResp Use This request and associated response are restricted to the Simple SD management. . 2. The number of APDUs of the updated CCM commands is potentially higher than the number of APDU of the original ones. installReq is used in the installation process (Process 5) to perform the different steps of the installation process. an exception is thrown with an error code. INSTALL. The SP must already have a SSD assigned on this UICC (see createOrAllocateSsdReq and createOrAllocateSsdResp). The steps sequence shall be compliant with GP lifecycle state transition. ACTIVATE . 3. Several occurrence of this field enables the specification of several CCM commands for which a token is to be generated.Application parameters setting with installStep=REGISTRY_UPDATE These steps can be executed one at a time using several requests or several steps can be sequentially executed by the MNO in a single request. which are: . ACTIVATE Conditions of use: installReq with “LOAD” STEP This step is mandatory if at least one of the packages of the service was not previously loaded in factory. for instance: . Upon reception of the token the Service Provider can establish an OTA connection to the UICC in order to send the GP command.Application activation with installStep=ACTIVATE (this step is mandatory in the installation process) . Present if the APDU command is modified by the MNO. 3. Otherwise.1 – February 2012 – AFSCM Confidential & Proprietary p61/102 . Resulting actions If the given parameters of the tokens request are compatible with its internal policies. INSTALL. Depending on the SP application and whether it is pre-loaded or pre-instantiated.LOAD. AFSCM Interface Specification V2.Application installation with installStep=INSTALL. The package will be loaded by the MNO in the SSD assigned for this service on this UICC.REGISTRY_UPDATE.LOAD.Application loading with installStep=LOAD. the installation step sequence could be.The APDU are also updated with a token. REGISTRY_UPDATE. due to the inclusion of the token itself.INSTALL. the Mobile Network Operator generates the tokens and returns them to the Service Provider. If so. ACTIVATE .

i. the package(s) of the application(s) must already be loaded on the UICC and the application must already be installed. The SP must already have a SSD assigned on this UICC (see createOrAllocateSsdReq and createOrAllocateSsdResp). With this response. The registry update parameters must be verified and validated by the MNO prior to any request and must therefore be provisioned in advance on the MNO platform together with the application. The application instantiated in the SSD assigned for this service on this UICC will be activated by the MNO. In case DAP signature is used. These installation parameters must be provisioned in advance on the MNO platform together with the application package. Conditions of use: installReq with “INSTALL” STEP This step is mandatory if at least one of the applications of the service was not previously installed in factory. In case the key for DAP is diversified for each UICC. The use of DAP is optional. the Service Provider may change the parameters of its application. Conditions of use: installReq with “REGISTRY_UPDATE” STEP This step is optional. Url…) or the contactless parameters. ii. and verified and validated by the MNO. The SP must already have a SSD assigned on this UICC (see createOrAllocateSsdReq and createOrAllocateSsdResp) and the package(s) of the application(s) must already be loaded on the UICC. Once the application is installed on the UICC. In this case. This command can be used anytime. asynchronous Presence p62/102 AFSCM Interface Specification V2. the DAP signature must be calculated for each UICC. The application will be installed by the MNO in the SSD assigned for this service on this UICC. Conditions of use: installReq with “ACTIVATE” STEP This step is mandatory. it is mandatory to have the application certified package available on Mobile Network Operator’s platform before submitting requests for loading the package. or the DAP signature can be sent in the installReq request.2.1 – February 2012 – AFSCM Confidential & Proprietary . application image. The serviceId and serviceVersion parameters correspond to a set of installation parameters that the MNO will use in the generation of the GlobalPlatform commands. These parameters are detailed in [R13] Global Platform Card Specification 2. the Mobile Network Operator confirms whether activation is performed or not.Since the package needs to be loaded OTA. In this case the DAP signature can only be sent in the installReq request. as part of the installation process or not (if the application is “installed” or “activated”) Description REQUEST installReq Input data name Description SP  MNO. Especially it may change the user interaction parameters (display message. The DAP signature can be the same for all the UICC (key for DAP not diversified in the UICC). Amendment C. it is possible to provision the DAP signature on the MNO platform together with all the other technical details.

9. AFSCM Interface Specification V2. Resulting actions with “INSTALL” STEP After the necessary verifications (package loaded.Checks if the package is already loaded in the UICC in which case the MNO does not need to perform any OTA actions. Parameter installStep Type installStep Description defines an installation step the MNO has executed Refer to section 3. . responseCode) tuples reporting the execution status related to an installation request.asyncHeader Message Header for Asynchronous Request List of elements named An ordered list of installInfo. “installInfo” of type installInfo Output data name Description acknowledgeWithValidityPeriod MNO acknowledgment of the request RESPONSE installResp Input data name requestId type: requestId List of elements named “responseCode” of type (installStep. the response shall contain the results of all executed steps up to the one that failed. responseCode) Description Transaction identifier (unique) An ordered list of (installStep. Description SP acknowledgment of the response Presence Mandatory Resulting actions with “LOAD” STEP Upon reception of this request. the Mobile Network Operator: . the Mobile Network Operator loads OTA the package (or packages if there are several packages in the service) in the UICC. Mandatory Mandatory Presence Mandatory MNO  SP.Checks that a SSD is attributed to this Service Provider on this UICC. application not already installed …). to be executed sequentially. the SP can proceed to the next step of the installation process: the application installation. Once the package is available on the end user’s UICC. the Mobile Network Operator generates the GlobalPlatform commands using the installation parameters and sends them OTA to the UICC for execution (instantiation and extradition of the application or applications if there are several packages in the service). asynchronous Presence Mandatory Mandatory responseCode responseCode Output data name acknowledge In case all steps requested could not be executed.1 – February 2012 – AFSCM Confidential & Proprietary p63/102 . When all the controls are OK.3 Response codes to asynchronous requests for a list of possible error returned by this request and for error management.

In case the service has several MMIs (not including the several versions of the same MMI). asynchronous Presence Mandatory Conditional Mandatory Output data name Description acknowledgeWithValidityPeriod MNO acknowledgment of the request RESPONSE installMmiResp Presence Mandatory MNO  SP. in case the application is fully operational . 3. the Service Provider requests the MNO to initiate the MMI download.Else it has not. Possible values are: 1 2 MMI only MMI with retries SP  MNO. and the next step is to personalise the application Resulting actions with “REGISTRY_UPDATE” STEP After the necessary verifications. package loaded. the MNO will provide an identifier for each MMI. asynchronous p64/102 AFSCM Interface Specification V2.Either personalisation has already been done by the SP. Description REQUEST installMmiReq Input data name asyncHeader mmiId type: N mmiAction type: N(1) Description Message Header for Asynchronous Request Identifier of the MMI. Resulting actions with “ACTIVATE” STEP After the necessary verifications (SSD assigned. The Service Provider sends the request with mmiAction set to:  Option i “MMI with retries” and the version of the MMI to be loaded.Once the application is installed on the end user’s UICC. the Mobile Network Operator sends the GlobalPlatform command for application (or applications if there are several applications in the service) activation. …). application installed and not activated. when the MNO is involved in the MMI installation: . the Mobile Network Operator sends the GlobalPlatform command to the targeted application.6. mandatory in case there are several MMI for the service Action to be done by the MNO. Conditions of use installMmiReq is used in Process 6.4 installMmiReq and installMmiResp Use installMmiReq is used by the SP to ask the MNO to initiate the MMI installation. A call to the installMmiReq request only handles the installation of one MMI.In case 1.  Option ii “MMI only” and the version of the MMI to be loaded The response is used to inform the Service Provider about the result of MMI download initiation. and this mmiId shall be provided in the installMmiReq input. the SP can proceed to the next step of the installation process: the personalisation or the activation of the application. Once the application(s) is (are) activated: .1 – February 2012 – AFSCM Confidential & Proprietary .

the MNO will use the TAC of the mobile handset of the end user to identify the corresponding URI.1 – February 2012 – AFSCM Confidential & Proprietary . Description REQUEST bindMmiReq SP  MNO. the SP asks the MNO to bind the MMI of the mobile NFC service to the UICC application.9. asynchronous Input data name Description Presence Mandatory requestId Transaction identifier (unique) type: requestId responseCode type: responseCode Refer to section 3.5 bindMmiReq and bindMmiResp Use Using bindMmiReq.Input data name requestId type: requestId responseCode type: responseCode Description Transaction identifier (unique) Refer to section 3. The URI indicated in the SMS must have been provided by the SP to the MNO and may depend on the mobile handset model. Conditions of use bindMmiReq can only be used once the UICC application are installed and active. the Service Provider must notify the MNO using notifStateChangeToMno.3 Response codes to asynchronous requests for a list of possible error returned by this request and for error management Description SP acknowledgment of the response Mandatory Output data name acknowledge Presence Mandatory p65/102 AFSCM Interface Specification V2. It should be used.9. 3. see [R5]Guidelines for interconnection of Service Providers' and MNOs' Information Systems.6. If several URI have been provided by the SP. For more information on the compatibility information provisioning. when possible. Once he is aware of the result of the installation process. before MMI installation. asynchronous Input data name Description Presence asyncHeader Message Header for Asynchronous Request Mandatory Output data name Description Presence acknowledgeWithValidityPeriod MNO acknowledgment of the request Mandatory RESPONSE bindMmiResp MNO  SP.3 Response codes to asynchronous requests for a list of possible error returned by this request and for error management Description SP acknowledgment of the response Presence Mandatory Mandatory Output data name acknowledge Presence Mandatory Resulting actions The MNO sends a push SMS to the mobile handset of the end user allowing him to install the MMI or triggering the MMI installation.

package and the SSD  In Delegated Management mode. 3. but will use suppressReq with the DELETE_SSD action to ask the MNO to delete the SSD.Delete all UICC content related to the target service (serviceId and serviceVersion) including the application instance. the MNO loads or updates the ACF and always loads the more recent certificate.9.Delete the Service Provider’s SSD on the UICC Conditions of use This request can be called in the following situations: The Service Provider needs to update the application (Process 5 Update) in Simple SD mode: in that case.6.Resulting actions The MNO performs the binding. asynchronous Presence Mandatory Mandatory p66/102 AFSCM Interface Specification V2. In the case of ACF files.1 – February 2012 – AFSCM Confidential & Proprietary . it is recommended not to delete the SSD. the application package and the associated bindings . In case of Mobile NFC service termination (Process 20)  In Simple SD mode.6 suppressReq and suppressResp Use This request is used by the SP to ask the MNO to .3 Response codes to asynchronous requests for a list of possible error returned by this request and for error Optional Presence Mandatory MNO  SP. the Mobile Network Operator is responsible for deleting the application instance. the Service Provider is responsible for the deletion of the application(s) and package(s) on the UICC. asynchronous Presence Mandatory Mandatory deleteReason type: N(1) Indicates the reason of the removal. REQUEST suppressReq Input data name asyncHeader List of elements named “deleteAction” of type N(1) Description Message Header for Asynchronous Request List of suppression actions among Value 0 1 Description Delete the application and package in Simple SD mode Delete SSD if possible - SP  MNO. Possible values are: 0 for termination 1 for update Output data name Description acknowledgeWithValidityPeriod MNO acknowledgment of the request RESPONSE suppressResp Input data name requestId type: requestId responseCode type: responseCode Description Transaction identifier (unique) Refer to section 3. and therefore not to use the DELETE_SSD action.

for any reason. application installation and activation o reason is “Token used” (when the token has been used. or about the lock/unlock of the UICC application.Delete MMI and UICC application bindings related to the suppressed mobile NFC service (if such bindings are used). confirmationData and receipt must be present .Do not deleted a SSD if it is not empty . step can be either of the values already listed above o reason is “Token not used” (when. 3. and confirmationData and receipt must be filled) or “Token not used” (when. Once the service has been deleted.1 notifStateChangeToMno Use The Service Provider uses this notification to inform the MNO either about the MMI installation status.management Output data name acknowledge Description SP acknowledgment of the response Presence Mandatory Resulting actions Upon reception of this request.Do not delete a package if there is still another instance linked to this package. the Service Provider can delete the information related to the service of this end user from his information system. the SP has / could not use the token: confirmationData and receipt should not be present) o status is  “OK” since the token has been successfully used o aid. to notify the MNO that a token has not been / could not be used o Depending on the context. step can be  UICC package loading  UICC application installation  UICC application extradition  UICC application extradition  UICC application deletion  UICC registry update  UICC application installation and activation  UICC package loading. about command execution in Delegated Management mode. Conditions of use The notifStateChangeToMno notification is used in the following contexts: . o Depending on the context. the SP has / could not use the token: confirmationData and receipt should not be present) AFSCM Interface Specification V2. Process 5 Update and Process 20).7 Notifications 3. the Mobile Network Operator makes several controls in order to analyse what can and must be suppressed or not according to the following rules: . to send the token receipts of OTA commands to the MNO (Process 5.In Delegated Management mode.In Delegated Management mode.7.1 – February 2012 – AFSCM Confidential & Proprietary p67/102 . for any reason. .Do not delete a package that cannot be OTA loaded .

the status is either “OK”.- - - - status is  “Already performed” when the token has been used but the action has not been performed because it was already done. and even when no installation was necessary because the MMI was already installed. “Failed” or “Already performed” To notify to the MNO that a token has not been used: o The step depends on the context. reason is “Token not used”. step can be  MMI installation  MMI update o reason is “end user request” or “SP request” o Depending on the information the SP wants to transmit to the MNO. In this case. To notify the MNO about the installation status of the MMI (Process 6): in the installation process. “Failed” or “Already performed” o aid. or SP request o Depending on the context. whether the installation/update was successful or not. the status is either “OK”. and status is “OK” o Description NOTIFICATION notifStateChangeToMno Input data name Description syncHeader Synchronous Message Header AFSCM Interface Specification V2. in case of loss or theft (Process 12)  “mobile recovery “ when the end user recovers his mobile equipment after a loss or theft (Process 13)  “line suspension “ in case of temporary suspension of mobile service upon end user’s request (Process 15)  “line termination “ in case of termination by end user of Mobile subscription or NFC option (Process 18)  “line termination” in case of mobile service termination by MNO (Process 19) o Depending on the information the SP wants to transmit to the MNO. synchronous Presence Mandatory p68/102 . to notify to the MNO the status of the personalisation applied to the UICC application.  Or “Failed” in other cases. the step is:  UICC application GP lock  UICC application GP unlock  Service lock on IT  Service unlock on IT  UICC application applicative lock  UICC application applicative unlock o reason is:  “MMI update” when the Service Provider had to lock and then unlock the UICC application due to a “critical MMI” update (Process 6)  “mobile loss” or “mobile theft”. depending on the type of lock. the step is “UICC application personalisation” and the reason is “SP request” To notify to the MNO the locks applied or removed by the Service Provider: o In any case. the MNO must be notified of the MMI installation status after.1 – February 2012 – AFSCM Confidential & Proprietary SP  MNO. confirmationData and receipt must be present In Process 5. and whether it is applied or removed.

if the SP does not send the receipt associated with the execution of the command(s).7. enabling the SP to notifiy several messages to the MNO. end user contacts Service Provider.1 – February 2012 – AFSCM Confidential & Proprietary p69/102 notifNewDevice . In case of a notification dedicated to Delegated Management.7. Description NOTIFICATION notifCallEndUserToMno SP  MNO.List of elements named “actionStatus” of type actionStatus Output data name acknowledge Mandatory A list of actionStatus elements. It only notifies of the user’s call. the MNO may audit the UICC. This list can contain elements of types actionStatus: used for basic notifications dmActionStatus: used for notifications dedicated to Delegated Management mmiActionStatus: used for notifications regarding the MMI installation status Description Presence MNO acknowledgment of the notification Mandatory Resulting actions The Mobile Network Operator updates the information for this end user in his information system. 3.2 notifCallEndUserToMno Use This notification is used by the Service Provider to inform the MNO that the end user has called because of a loss of a theft of his mobile equipment. Conditions of use This notification can only be used in Process 12 – Lost or stolen mobile equipment. synchronous Input data name Description Presence syncHeader Synchronous Message Header Mandatory reason Operation justification. 3. The only acceptable values Optional for this parameter are: type: reason 11: mobile loss 13: mobile theft dateTimeCall type: dateTime Output data name acknowledge Date / time of the declaration call Description MNO acknowledgment of the notification Mandatory Presence Mandatory Resulting actions The Mobile Network Operator keeps record of this information related to the end user in his information system. not the loss or theft in itself.3 Use AFSCM Interface Specification V2.

Conditions of use This notification is used in the following processes: . or both new UICC and mobile. synchronous Presence Mandatory Mandatory Presence Mandatory Resulting actions Upon reception of this notification.Installation of the MMI if new mobile – Process 6. Conditions of use This notification can be sent anytime.Process 8 – Change UICC  deviceType set to 01 . Description NOTIFICATION notifChangeMsId Input data name Description syncHeader Synchronous Message Header newMsId type: msId Output data name New Identifier of the user or his subscription Description MNO  SP. This notification is used for instance when the user changes his MSISDN.Installation of application if new UICC – Process 5.Process 10 – Change Mobile handset  deviceType set to 02 .Entire new installation if new UICC + Mobile – Process 5 and Process 6. the Service Provider launches the appropriate action: .Process 14 – Get a new mobile equipment after a lost of theft  deviceType set to 03 Description NOTIFICATION notifNewDevice Input data name Description syncHeader Synchronous Message Header deviceType The type of the device(s) that have been changed. [Note] The reception of this notification for a new UICC implicitely means that the previous UICC is deactivated. type: deviceType Output data name acknowledge Description SP acknowledgment of the notification MNO  SP.1 – February 2012 – AFSCM Confidential & Proprietary . 3. mobile.The Mobile Network Operator sends this notification to inform the Service Provider in case the end user gets new devices: UICC.4 notifChangeMsId Use The Mobile Network Operator uses notifChangeMsId to notify the Service Provider that an identifier has changed for the end user and to provide the new identifier. . synchronous Presence Mandatory Mandatory Presence p70/102 AFSCM Interface Specification V2. The msId field of the syncHeader will be an idTech and its value will be that of the former idTech of the end user. .7.

7.1 – February 2012 – AFSCM Confidential & Proprietary p71/102 . Conditions of use This notification is used in several contexts: . synchronous Input data name Description Presence syncHeader Message Header for synchronous request Mandatory reason Operation justification.acknowledge SP acknowledgment of the notification Mandatory Resulting actions The Service Provider updates his information system with the new identifier for this end user. The only acceptable values for this Optional parameter are: type: reason 11: mobile loss 13: mobile theft dateTimeCall type: dateTime Date / time of the declaration call Mandatory Mandatory Presence Mandatory lineState Defines the MNO’s line state.After a loss or theft.5 notifCallEndUserToSp Use This notification is used by the Mobile Network Operator to inform the Service Provider that the end user has called because of a loss of a theft of his mobile equipment. possible values for the status are Line RESTRICTED. Conditions of use This notification can only be used in Process 11 – Lost or stolen mobile equipment.6 notifStateChangeToSp Use The Mobile Network Operators uses this notification to inform the Service Providers about status changes on the line or the NFC option. type: lineState Output data name Description acknowledge SP acknowledgment of the notification Resulting actions The Service Provider keeps record of this information related to the end user in his information system. 3. Line SUSPENDED or Application LOCKED. possible values for the associated reason are mobile loss or mobile theft. It only notifies of the user’s call. No other action is necessary.7. 3. AFSCM Interface Specification V2. not the loss or theft in itself. end user contacts Mobile Network Operator. Description NOTIFICATION notifCallEndUserToSp MNO  SP. when the MNO tries to lock the UICC applications OTA and restricts or suspends the line (Process 11).

Line SUSPENDED. When the end user gets a new mobile equipment after a loss or theft. the associated reason is mobile recovery. the MNO restores the end user’s mobile connection (Process 14). the value for the status will be Line SUSPENDED or Line ACTIVATED. When the Mobile Network Operator terminates the mobile service (Process 19). possible values for the status are Line TERMINATED and NFC option TERMINATED.8. When the end user wants to temporary suspend the mobile service (Process 15). the associated reason is line termination. status value is Line ACTIVATED. possible values for the status are Line RESTRICTED. possible values for the associated reason are same end user or changed end user. the Service Provider can use the sendScriptsReq request: data preparation is done by the Service Provider AFSCM Interface Specification V2. Description NOTIFICATION notifStateChangeToSp MNO  SP. In case the line is suspended or terminated. the associated reason is end user request. the associated reason is line reactivation. but the MNO did not manage to lock the application. the value for the status will be Contract owner CHANGED. possible values for the status are Line ACTIVATED and Application UNLOCKED. synchronous Input data name Description Presence syncHeader Synchronous Message Header Mandatory List of elements Mandatory A list of status elements representing the new statuses named “status” of of the mobile service after an action type status dateTimeChange Allows to retrieve the effective date of the application and Mandatory / or line status changing type: dateTime reason type: reason Output data name acknowledge Operation justification.8 Script sending 3. In these cases. for personalization of the service or application data update for instance. When the MNO informs the SP that the owner of the contract has changed (Process 16). No value for the reason will mean the MNO was not able to provide this information.1 – February 2012 – AFSCM Confidential & Proprietary p72/102 . Description SP acknowledgment of the notification Optional Presence Mandatory Resulting actions The Service Provider updates the information related to this end user in his information system. the Service Provider applies an IS lock on the service. 3. the associated reason is end user request. Line ACTIVATED or Line TERMINATED. When the end user wants to terminate mobile subscription or NFC option (Process 18). the Mobile Network Operator restores the end user’s mobile connection (Process 13).- - - - - - Once the end user recovers his mobile phone. the Service Provider may need to communicate with its UICC application or SSD.1 sendScriptsReq and sendScriptsResp Use During the life cycle of a mobile NFC service.

The size of all the concatenated APDUs of a script element should not exceed the maximum buffer size of the UICC (this buffer size is provided by the MNO as part of the UICC profile information). Output data name Description Presence AFSCM Interface Specification V2. the MNO will throw an exception and no APDU will be sent. Each responseScript element contains a compact response to the executed script: The index of the last APDU executed. then the Failed APDU Index provides the index of the failed APDU in the Command APDU list.3 Response codes to Mandatory asynchronous requests for a list of possible type: responseCode error returned by this request and for error management List of elements named Mandatory A list of responseScript elements. Should it exceed the maximum buffer size. Description REQUEST sendScriptsReq SP  MNO. asynchronous Input data name Description Presence requested Mandatory Transaction identifier (unique) type: requestId responseCode Refer to section 3.9.actual sending of the data to the targeted application in the UICC is done by the MNO Conditions of use Use of this request is not presented in the processes. There will be a responseScript element for each script element of the sendScriptsReq request. Mandatory of type script Each script element represents a list of APDUs to be sent and executed by a targeted application. and is subject to agreement with the MNO as to the authorization and conditions of use.1 – February 2012 – AFSCM Confidential & Proprietary p73/102 . asynchronous Input data name Description Presence asyncHeader Message Header for Asynchronous Request Mandatory List of elements named “script” A list of script elements. if its execution has failed The response to the last executed APDU (executed correctly or not) If the execution of one Command APDU has failed. “responseScript” of type Each responseScript element represents responseScript the response of the UICC application to the corresponding executed script. Output data name Description Presence acknowledgeWithValidityPeriod MNO acknowledgment of the request Mandatory RESPONSE sendScriptsResp MNO  SP.

The following values are used in mandatory enumeration dmActionStatus types: 01 UICC package loading 02 UICC application installation 03 UICC application extradition 04 UICC application activation 05 UICC application deletion 06 UICC registry update AFSCM Interface Specification V2.1 – February 2012 – AFSCM Confidential & Proprietary p74/102 Data type name Sample value actionStatus . up to X characters A string of alphanumeric characters of unspecified length A boolean value A string of characters of unspecfied length An ordered list of data. Detail of the data depends on the context An hexadecimal string of unspecified length A string specifiying a date and a time Use of time zone is not mandatory 1234567890ABCDEF 2010-07-28T09:18:00. 3.Acknowledge SP acknowledgment of the response Mandatory Resulting actions The MNO will choose the appropriate bearer to communicate the APDUs to the UICC.9 Data dictionary 3.9. up to X digits Data type name N(X) Sample value 1 234 56789 Hello Hello1234 True False Hello world! AN(X) AN(var) boolean char(var) List HEX(var) dateTime A string of alphanumeric characters.331+02:00 The following custom data types are defined in this interface specification: Custom data types Format actionStatus is a basic type that can be extended to include more details: The actionStatus type is the basic type The dmActionStatus type extends the actionStatus type for Delegated Management related details The mmiActionStatus type extends the actionStatus type for MMI installation related details An actionStatus element contains the following parameters Parameter Type Description step N(2).1 Data types The following basic data types are used in the interface specification: Basic data types Description An integer.

Possible values are 0: OK 5: Already performed 10: Failed Note: the GP LOCKED APPLICATION and GP UNLOCKED APPLICATION can also be used to notify a SSD lock. application installation and activation The following values are used in mmiActionStatus types: 20 MMI installation 21 MMI update The remaining values are used in basic actionStatus types: 30 UICC application personalisation 40 UICC application GP lock 41 UICC application GP unlock 42 Service lock on IT 43 Service unlock on IT 44 UICC application applicative lock 45 UICC application applicative unlock reason mandatory status mandatory type: reason N. SD Unique Data. all APDUs are install [for install] commands. AID of the mandatory package that has been loaded or deleted. Token Data digest) p75/102 dmActionStatus AFSCM Interface Specification V2. Possible values are: 1: UICC 2: Mobile handset 3: UICC + mobile handset The dmActionStatus type adds the following parameters to the actionStatus structure: Parameter Type Description aid aid Depending on the step. personnalized.1 Table 11. deviceType N(1) representing different types of devices. aid alias apdu ccmCommand HEX(5 to 16) AN(max 16) HEX(up to 256) A ccmCommand is a list of composed of one or several elements of type apdu or extendedApdu (if supported by the MNO). Token identifier. APDUs composing the ccmCommand SHALL be of the same type: for instance.2. although this is part of no described process.1 – February 2012 – AFSCM Confidential & Proprietary .14 (composed of Confirmation counter. activated or deleted confirmationData HEX(var) Confirmation Data is a LV structure conditional defined in GP 2. or of the UICC application that has been installed. enumeration Operation justification.10 UICC application installation and activation 11 UICC package loading. Several apdu or extendedApdu elements can be used if the commands need to be split.

if needed. It is formatted the same way it is stored in the UICC AN(16 max) Represents the International Mobile Equipment Identity of a mobile handset. and only if. the installation parameters and DAP signature for each application or package AID installStep installTable N(1) enumeration. will be right-padded (hence the last alpha-numeric character. restricted to the following values: 1: LOAD 2: INSTALL 3: ACTIVATE 4: REGISTRY_UPDATE An installTable is a structure containing the following records: Parameter Type Description aid aid Depending on the installStep mandatory value. the receipt(s) was (were) lost by the SP. depending on the choice of the MNO). shall not be swapped and. This case shall be exceptional extendedApdu iccId idTech imei HEX(up to 32768) N(19) [0-9A-F] An iccId is composed of 19 numeric characters.1 – February 2012 – AFSCM Confidential & Proprietary . It extends the mobileHandsetId type. the receipt(s) was (were) lost by the SP.receipt conditional HEX(var) This value is not present if. refers to : LOAD: the AID of the package Other steps: the AID of the UICC application instance installParameterIndex N(1) Refers to a set of GP mandatory installation parameters that are provisioned on the MNO p76/102 AFSCM Interface Specification V2. for this step. by adding the following elements: Parameter snr mandatory c mandatory Type N(6) N(max 2) Description Serial NumbeR Check digit (1 digit) or Software Version Number (2 digits) installInfo installInfo is a sequence composed of an installStep and an optional list of installTable: Parameter installStep type: installStep mandatory List of elements named “installTable”of type installTable optional Description defines an installation step the MNO must execute A list of installTable elements allowing to specify. and only if. This case shall be exceptional Token receipt This value is not present if.

212 mandatory Norm. It contains the following elements. brand and model It is extended by types tac and imei AFSCM Interface Specification V2. Type N(3) N (var 2 or 3) mobileHandsetId An identifier for a mobile handset. mandatory in case there are several MMI for the service Version of the Service Provider MMI application mnoId A mnoId is a sequence of the following elements : Code Description cc Country Code of the Owner and mandatory Manager of the UICC in accordance with the ISO 3166 norm mnc MNO Code true to the ITU E. as a sequence of the following elements: Parameter Type Description type unsignedByte Key type mandatory index byte Key index mandatory version byte Key version mandatory keyValue HEX(VAR) Value of key mandatory keyKcv HEX(3 to 8) Check sum of the key mandatory N(1) that defines the MNO’s line state.platform Note that: 1. installParameterIndex: Used if several sets of parameters are available on the MNO platform key A structure representing a 3DES key.1 – February 2012 – AFSCM Confidential & Proprietary p77/102 . It is composed of the initial eight-digit portion of the 15-digit IMEI code used to uniquely identify wireless devices. and is an abstract type that can be extended: Parameter Type Description tac N(8) The TAC (Type Allocation Code) of a mobile mandatory handset model. Possible values are: 1: line activated 2: line restricted 3: line suspended 4: line terminated actionStatus structure: Parameter Type mmiId N conditional mmiVersion mandatory version lineState mmiActionStatus The mmiActionStatus type adds the following parameters to the Description Identifier of the MMI. The format of the TAC is AABBBBBB where: The first two digits are the Reporting Body Identifier The next 6 digits identify the manufacturer.

g.1 – February 2012 – AFSCM Confidential & Proprietary . N(3-15). the end user.3 Response codes to asynchronous requests A responseScript is a sequence of the following elements: Parameter Type Description aid aid AID of the targeted application mandatory failedApduIndex N The index of the last APDU executed. formatted as the concatenation of the following attributes. if conditional its execution has failed apdu lastApduResponse The response to the last executed mandatory APDU (executed correctly or not) A script is a sequence of the following elements: Parameter Type aid aid mandatory Several apdu elements A list of elements mandatory of type apdu or extendedApdu A ssdInfo is a sequence of the following elements: Parameter Type 33123456789 msisdn reason requestId 10:223372036854:21 responseCode responseScript script Description AID of the targeted application APDU commands of the script ssdInfo Description p78/102 AFSCM Interface Specification V2.9. which can have the values defined in section 3. separated by colons: Parameter Type serviceId N(5) Timestamp in milliseconds N(19) Additional diversifier N(2) N(3).msId A msId is a sequence of the following elements: Parameter Type Description mnoId mnoId Identifier of the MNO optional msId Identifier of the mobile msisdn or alias or mandatory idTech subscription. including the country code (no ‘+’ sign) N(2). Possible values are: 1: line reactivation 2: line restriction 3: line suspension 4: line termination 11: mobile loss 12: mobile recovery 13: mobile theft 21: end user request 22: same end user 23: changed end user 31: SP request 40: MMI update 50: Token used 51: Token not used AN (26 max). e.

It heritates the tac element from the mobileHandsetId type. status N(1) representing a status. mandatory minor N(3) The minor version of the service. p79/102 Description and retry policy AFSCM Interface Specification V2. The errors contained in a same category should be handled in the same way.aid mandatory parentAid optional Several key elements optional aid aid A list of elements of type key AID of the SSD AID of the parent SSD. A version is a sequence of the following elements: Parameter Type Description major N(3) The major version of the service. if not the ISD One element per key transmitted. mandatory 35713603 for the Samsung Player One Cityzi tac uiccProfile version 3. Possible values are: 1: Line ACTIVATED 2: Line RESTRICTED 3: Line SUSPENDED 4: Line TERMINATED 10: Application UNLOCKED 11: Application LOCKED 12: Application DELETED 20: NFC option ACTIVATED 21: NFC option TERMINATED 22: Contract owner CHANGED The TAC (Type Allocation Code) of a mobile handset model. particularly regarding his retry policy Code type K W S D Category OK. char(16). Reference to a smart card manufacturer and operating system. mandatory revision N(3) The revision version of the service.2 Response and exception types Response codes and exceptions are grouped in categories.9.1 – February 2012 – AFSCM Confidential & Proprietary . not an error Warning Sequence Error Data error N/A A warning response informs the Service Provider that his request was in fact not necessary for this End User: the SP can proceed to the next step of his sequence The correct sequence for this request was not followed: the SP should review what step of the sequence may have been forgotten The parameters of the request do not match with the rules checked by the MNO. The following table lists these categories and indicates: what are the types of errors found in these categories how the Service Provider must handle these errors when confronted to them.

The Service Provider should then contact the MNO through After Sales services procedures. the SP can proceed to the next step Application already installed: no action was necessary.The Service Provider must fix the parameters and the request can be retried. I Ineligibility This is a definitive error.9. Thus the Service Provider should preferably contact the end user and ensure that his mobile equipment is connected before sending the request again. 3. the SP can proceed to the next step Application already activated: no action was necessary. the SP can proceed to the next step X X X X X X X X X X 042 090 200 202 204 210 220 221 222 C F F F F W W W W X X X X X X X X X X X X X X X X AFSCM Interface Specification V2. The Service Provider should not retry and should inform the end user. The Service Provider should not retry and should inform the end user he cannot benefit from NFC offer.3 Response codes to asynchronous requests The response codes are used in the asynchronous responses. createOrAllocateSsdResp responseCode bindMmiResp 000 020 K C OK: the asynchronous request is a success UICC not accessible: several tries may have been made but the operation has not been carried on because the UICC could not be reached Connection between MMI service and mobile handset failed DEPRECATED Card fatal error: a definitive error has occurred while communicating with the UICC Memory space not sufficient: there is not enough memory space on the UICC to carry the operation Error during application package loading DEPRECATED Error during MMI and UICC application binding DEPRECATED SSD already created and allocated for this SP: no action was necessary. the SP can proceed to the next step Application Package already loaded: no action was necessary. The table below presents the relationship between each response code and the applicable response. C Connection error The MNO made several retries before returning this type of response code.1 – February 2012 – AFSCM Confidential & Proprietary p80/102 suppressResp X X Description CODE_TYPE sendScriptsResp installMmiResp installResp . F Fatal error This is a definitive error.

occurs if the SP asks for application installation before asking for package loading Application not installed: for instance. the server throws a synchronous exception (faultMsg) with an appropriate errorType. the SP can proceed to the next step Package absent on the UICC: for instance. getMobileHandsetProfile createOrAllocateSsdReq isEligible & fullEligibilityCheck getUICCProfile installMmiReq bindMmiReq Description CODE_TYPE errorType sendScriptsReq X X X 001 D Value error: a value provided is not in the range of expected data (for instance this exception is thrown if an installStep value of 5 is passed as a parameter) X X X X X X X X X 002 D Format error: a value provided in the request was X incorrectly formatted (in most cases this should be prevented by only sending XSD-validated requests) D Service not provisioned: no service associated with the serviceId and serviceVersion X X X X X X X X X 003 X X X X X X X X AFSCM Interface Specification V2. occurs if the SP asks for application activation before asking for application installation Application is not activated: the SP must activate the cardlet application before binding X X X X X Note: As of version 2.1. the following codes have been deprecated: 042 (C): Connection between MMI service and mobile handset failed: code 090 should be used instead 202 (W): Error during application package loading: code 090 should be used instead 204 (W): Error during MMI and UICC application binding: code 090 should be used instead 3.9.4 Exceptions When an error is detected on the reception server. The table below lists all the possible values for errorType and the request for which they are applicable.createOrAllocateSsdResp responseCode bindMmiResp 223 224 225 226 W S S S Application or package not found on the UICC: no action was necessary.1 – February 2012 – AFSCM Confidential & Proprietary p81/102 suppressReq X X X getTokens getIdTech installReq suppressResp X Description CODE_TYPE sendScriptsResp installMmiResp installResp .

getMobileHandsetProfile

createOrAllocateSsdReq

isEligible & fullEligibilityCheck

getUICCProfile

installMmiReq

bindMmiReq

Description CODE_TYPE errorType

sendScriptsReq X X X X X X

004

D Mandatory data missing: this exception is thrown X if a mandatory data is missing (in most cases this should be prevented by only sending XSDvalidated requests) D Presence of unexpected data DEPRECATED D Unknown identifier DEPRECATED X X

X

X

X

X

X

X

X

X

005 006 007 008

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

D Identifier incompatible with the requested action X DEPRECATED D Unsupported identifier: the MNO does not support the identifier type (MSISDN, alias or idTech) provided in the request D Not coherent with SSD privilege (1) (for instance on a getToken call where the SSD does not have the DM privilege) D Unknown mnoId: the mnoId provided is well formatted but is unknown D Unknown msId: the msId provided is well formatted but is unknown D Unknown aid: the aid provided is well formatted but is unknown D Unknown installParameterIndex: the installParameterIndex provided is well formatted but is unknown D Unknown mmiId: the mmiId provided is well formatted but is unknown F Memory space not sufficient W SSD already created and allocated for this SP: no action was necessary, the SP can proceed to the next step S No SSD attributed to this SP on UICC W Application package already loaded W Application already installed W Application already activated W Application or package not found on the UICC: no action was necessary, the SP can proceed to the next step S Package missing on the UICC X X X

012

X

X

013 014 015 016

X X

X X

X X

X X X

X X

X X X X

X X

X X

017 200 210

X X X X X X X

211 220 221 222 223

X

X

?

?

X(1) X X(1) X X(1) X X

224

X

X

X

AFSCM Interface Specification V2.1 – February 2012 – AFSCM Confidential & Proprietary

p82/102

suppressReq X X X X X X X X X

getTokens

getIdTech

installReq

getMobileHandsetProfile

createOrAllocateSsdReq

isEligible & fullEligibilityCheck

getUICCProfile

installMmiReq

bindMmiReq

Description CODE_TYPE errorType

sendScriptsReq X X X X X X

225 226 230 240 241 250 400

S Application not installed S Application is not activated W MMI is already installed W Installation in progress W Service already installed W Unsupported operation (the requested action is not implemented) I NFC service not activated for this msId: for instance, the user has not subscribed to a mandatory NFC option with its MNO Other ineligibility reason (other than 400 and 402 to 404) UICC not compliant with NFC services Mobile handset not compliant with NFC services Offer not compliant with NFC services: for instance, the user does not have data use in his subscription and data use is required for this service X X X X X X X X X X

X

X

X X X

X X

X

X

X

X

X

X

401 402 403 404

I I I I

X X X X

900 901

F Unknown error F Quota overcome

X

X X

X

X X

X X

X X

1. Optional, such controls depend on the Mobile Network Operator Note: As of version 2.1, the following codes have been deprecated: 005 (D):Presence of unexpected data: since XSD verification is enforced, this exception should not happen; code 900 should be used instead 006 (D): Unknown identifier: codes 013 to 017 should be used instead 007 (D): Identifier incompatible with the requested action; code 900 should be used instead

AFSCM Interface Specification V2.1 – February 2012 – AFSCM Confidential & Proprietary

p83/102

suppressReq X X X X

getTokens

getIdTech

installReq

4

PROCESS IMPLEMENTATION REFERENCE
This chapter presents the reference implementation, between the IT systems of the SP and the MNO of the customer journey described in chapter 2, using the interface specified in chapter 3. It focuses on the interface between the SP and the MNO, but also presents the interactions with the UICC or the handset to describe the customer journey from end to end.

4.1

Representation of the exchanges
In order to simplify the representation of the exchanges in the sequence diagrams of this section, acknowledgments and exceptions will not be explicitly represented in the diagrams. Thus, the detailed diagram of Figure 38 – Sample sequence diagram of synchronous and asynchronous exchanges will be represented as followed:
Service Provider Mobile Operator

createOrAllocateSsdReq createOrAllocateSsdResp

getIdTech notifCallEndUserToMno

Figure 40 – Simplified representation used in sequence diagrams The legend used in the diagrams is presented below:
Service Provider Mobile Operator UICC

Asynchonous REQUEST Asynchonous RESPONSE

Synchronous FUNCTION or NOTIFICATION

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 41 – Legend of sequence diagrams Some parameters may be presented to bring precision to the use of a function, request or notification in a process.

4.2

Eligibility and scoring sub-processes
4.2.1 Sub-process A – MNO eligibility

Sequence diagram
Service Provider
IsEligible

Mobile Operator

Checks eligibility

AFSCM Interface Specification V2.1 – February 2012 – AFSCM Confidential & Proprietary

p84/102

AFSCM Interface Specification V2. 4.4 Subscription processes 4. 4. 4.3 Process 3 – Inquiry to the Mobile Network Operator This process does not require any exchange between the Mobile Network Operator and the Service Provider.5.1 Process 1 – Online service discovery This process does not require any exchange between the Mobile Network Operator and the Service Provider.2 Process 2 – Inquiry to the Service Provider This process does not require any exchange between the Mobile Network Operator and the Service Provider.3.3 Sub-process C – SP scoring This process does not require any exchange between the Mobile Network Operator and the Service Provider. 4.3.3. 4. the Service Provider can also use the fullEligibilityCheck function instead of isEligible.2.3 Service discovery and inquiry processes 4. the Service Provider does not need to call the getUICCProfile and getMobileHandsetProfile functions.1 Process 4 – Subscription to a mobile NFC Service This process does not require any more exchange between the Mobile Network Operator and the Service Provider than those described in Sub-process A – MNO eligibility.1 Process 5 – Mobile NFC UICC application installation The installation process is a succession of several requests on the Service Provider / Mobile Network Operator interface. 4.1 – February 2012 – AFSCM Confidential & Proprietary p85/102 .2.Figure 42 – Sequence diagram of Sub-process A – MNO eligibility Description Depending on whether he needs to perform a compatibility check next. Sub-process B – SP compatibility and Sub-process C – SP scoring. 4.2 Sub-process B – SP compatibility Sequence diagram Service Provider getUICCProfile getMobileHandsetProfile Checks compatiblity Mobile Operator Figure 43 – Sequence diagram of Sub-process B – SP compatibility Description If he used the fullEligibilityCheck function during a previous step. since it is particularly appropriate to a first subscription.5 Installation processes 4.4.

SSD creation/assignation If the Service Provider has no SSD assigned on the UICC of the end user. registry update installReq (among LOAD. but the first step. installation. The SP must use the createOrAllocateSsdReq request to have a SSD assigned. the first step of the UICC application installation process is the SSD creation/assignation. simple SD mode or delegated management mode. or the MNO sends a key set in the createOrAllocateSsdResp response Once the SSD is assigned.Sequence diagram of Process 5 – Installation of UICC application in Simple SD mode (personalization then activation) AFSCM Interface Specification V2. INSTALL. Service Provider Mobile Operator UICC Option: can be done in factory and attributed in advance SSD Creation / assignation createOrAllocateSsdReq SSD Creation createOrAllocateSsdResp Option: If SSD not already available on UICC SSD Key Replacement Option: can be done in factory Option: upon SP decision Application package loading. REGISTRY_UPDATE) Package Loading Option: package can be preloaded on UICC Application Instance Creation and Extradition Option: instance can be pre loaded on UICC installResp Registry update Application Personalization Option: personalisation can be done in factory notifStateChangeToMno (UICC application personalisation) Application activation installReq (ACTIVATE) installResp Application Activation Figure 44 . regardless of the mode that is used. Sequence diagram in simple SD mode The following sequence diagrams illustrate the implementation of Process 5 – Mobile NFC UICC application installation when personalization is performed before activation.1 – February 2012 – AFSCM Confidential & Proprietary p86/102 . There are two options for the key set securing the access to the assigned SSD: either it was exchanged between authorised parties during the provisioning phase. is the same. and after.The installation in itself can be performed in the two modes. SSD creation or assignation. the Service Provider may send GP commands OTA to replace the SSD key set with his own key set.

6. The Service Provider is fully responsible for the personalization step of the UICC application and must notify the MNO using the notifStateChangeToMno notification. creation and extradition. REGISTRY_UPDATE. as described in section 2.1 – February 2012 – AFSCM Confidential & Proprietary p87/102 . the Service Provider uses the installReq request to ask the MNO to perform the various installation steps. Sequence diagram in delegated management mode AFSCM Interface Specification V2.3 UICC and UICC application architecture. registry update and activation. Depending on the number of steps to perform and the sequencing of the activation and personalization steps. application installation and activation installReq (steps among LOAD. the SP thus asks the MNO to perform the loading. ACTIVATE) Package Loading Option: package can be preloaded on UICC Application Instance Creation and Extradition Option: instance can be pre loaded on UICC Registry update Application Activation installResp Application Personalization notifStateChangeToMno (UICC application personalisation) Figure 45 – Sample sequence diagram of Process 5 – Installation of UICC application in Simple SD mode using grouped requests (activation then personalization) Using the Simple SD mode For the actual UICC application installation.Service Provider Mobile Operator UICC Option: can be done in factory and attributed in advance createOrAllocateSsdReq SSD Creation / assignation SSD Creation createOrAllocateSsdResp Option: If SSD not already available on UICC SSD Key Replacement Option: upon SP decision Package loading. the SP can decide to use the single or grouped commands of the installReq request. INSTALL. Depending on the state of the UICC.

the SP uses the getTokens request to request authorization tokens for each step to perform among (depending on the state of the UICC.1 – February 2012 – AFSCM Confidential & Proprietary p88/102 . for each command: 2/ send command 3/ notify with receipt Not illustrated ORFor each command: 1/ request a token. Once he has the necessary tokens. the Service Provider sends OTA the GlobalPlatform commands to perform these steps. or when the installation is complete. 2/ send command.Service Provider Mobile Operator UICC Option: can be done in factory and attributed in advance SSD Creation / assignation createOrAllocateSsdReq SSD Creation createOrAllocateSsdResp Option: If SSD not already available on UICC SSD Key Replacement Option: upon SP decision DM card content management 1/ request all tokens.Sequence diagram of Process 5 Installation of UICC application in Delegated Management mode Using the Delegated Management mode In the Delegated Management mode. application installation and application activation. 3/ notify with all receipts getTokens Tokens calculation Application Loading Application Installation and Extradition Registry update Application Personalization and Activation notifStateChangeToMno (Token receipts. AFSCM Interface Specification V2. UICC application personalisation) OR 1/ request all tokens . To be authorized.3 UICC and UICC application architecture) package loading. Each action performed by the SP must be notified to the MNO using the notifStateChangeToMno notification. 3/notify with receipt getTokens Token calculation Application Loading notifStateChangeToMno (Token receipt) getTokens Token calculation Application Installation and Extradition notifStateChangeToMno (Token receipt) getTokens Token calculation Registry udpate notifStateChangeToMno (Token receipt) getTokens Token calculation Application Personalization and Activation notifStateChangeToMno (Token receipt. Then.6. 2/ send all commands. as described in section 2. the SP is “authorised” by the MNO to perform all the UICC application installation steps. either right after the action. UICC application personalisation) OR For each command: 1/ request a token. 2/ send command and finally notify all with receipts Not illustrated Figure 46 .

5. AFSCM Interface Specification V2. ACTIVATE. REGISTRY_UPDATE. INSTALL. UICC application personalisation) Only one option of token. personnalization and activation getTokens (new serviceVersion) Tokens calculation Application Loading Application Installation and Extradition Registry update Application Personalization and Activation Personnalization can come before or after activation notifStateChangeToMno (Token receipts. see sequence diagram of process 5 for more options Figure 48 .4.Sequence diagram of Process 5 – UICC application update in Simple SD mode Service Provider Mobile Operator UICC Sub-process B – SP compatibility getTokens (instance & package deletion. registry update. old serviceVersion) Delete application instance and package if possible suppressResp Sub-process A – MNO eligiblity Example: installation using grouped commands installReq (among LOAD. old serviceVersion) Delete application instance and package notifStateChangeToMno (Token receipt) Sub-process A – MNO eligiblity Suppress previous UICC application DM card content management Package loading.1 – February 2012 – AFSCM Confidential & Proprietary p89/102 . application installation. new serviceVersion) Package loading.2 Process 5 Update – Mobile NFC UICC application update The steps of this process differ if the Service Provider uses the Simple SD mode or the Delegated Management mode.Sequence diagram of Process 5 UICC application update in Delegated Management mode Using the Simple SD mode The SP starts this process with the Sub-process B – SP compatibility and the update must be stopped if the end user’s mobile equipment is not compatible with the new version of the UICC application. application installation and activation Package Loading Application Instance Creation and Extradition Registry update installResp Application Activation Application Personalization notifStateChangeToMno (UICC application personalisation) Personnalization can come before or after activation. command and notification sequence is presented. Sequence diagram Service Provider Mobile Operator UICC Sub-process B – SP compatibility Suppress previous UICC application suppressReq (instance & package. and step by step requests can be used instead of grouped commands Figure 47 .

they are under the application store provider’s responsibility. the SP can ensure that there is enough memory space for the new UICC application. the MNO manages the entire installation and informs the SP once the MMI is actually loaded in the mobile handset using installMmiResp. In case 3.5.3 Process 6 – Service Provider MMI installation / Update This process is divided in 4 cases: .Case 2: the SP launches the MMI installation or update. Using the Sub-process A – MNO eligibility after the former service deletion. Case 1 option ii Figure 50 .Sequence diagram of Process 6 – MMI installation managed by MNO The SP uses the installMmiReq request to ask the MNO to launch the MMI installation. 4. Using the Delegated Management mode The SP starts this process with the Sub-process B – SP compatibility as in simple SD mode. .Case 3: the MMI installation is done through an application store In cases 1 and 2. the SP can ensure that there is enough memory space for the new UICC application. the SP uses the getTokens request to be authorized. the SP uses the notifStateChangeToMno notification to inform the MNO with the token receipt.1 – February 2012 – AFSCM Confidential & Proprietary p90/102 . SP uses the suppressReq request to ask the MNO for the deletion of the service on the UICC and the installReq request for the installation of the new version of the UICC (as seen in section 4. In delegated management mode.In simple SD mode. Using the Sub-process A – MNO eligibility after the former service deletion.1 Process 5 – Mobile NFC UICC application installation). the servers hosting the MMI are under the Service Provider’s responsibility.Sequence diagram of Process 6 MMI installation launched by MNO AFSCM Interface Specification V2. Then. and sends OTA the GlobalPlatform commands in order to delete the former UICC application instance and package and install the new ones. In case of connection interruption during the MMI loading. In this case. the MNO manages the retries.Case 1: Upon the SP’s request.5. o option i: there is a local mechanism to manage the MMI download on the phone o option ii: the MNO uses a SMS to redirect the end user to the MMI download . Case 1 option i: Figure 49 . the MNO launches the MMI installation or update.

the SP or the MNO may retrieve 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. using the statuses MMI installed or MMI updated. In case of connection interruption during the MMI loading. Case 3 Figure 52 .Sequence diagram of Process 6 – MMI Installation launched by Service Provider In case 2.The SP uses the installMmiReq request to ask the MNO to launch the MMI installation. the SP takes care of the MMI installation and informs the MNO of the result of the installation using the notifStateChangeToMno notification. Therefore the Service Provider must manage a database with all the MMIs for each available NFC mobile handset. Critical Update Service Provider Mobile Operator UICC Mobile handset Lock UICC application notifStateChangeToMno (locked status. reason=MMI update) MMI Installation. reason=MMI update) AFSCM Interface Specification V2.1 – February 2012 – AFSCM Confidential & Proprietary p91/102 . MMI update These processes apply for the MMI installation and the MMI update as well. Once the SP is notified that the MMI is installed on the mobile handset. Requirement on the Service Provider Information System The MMI is specific for each mobile handset. and the MNO sends the installMmiResp response once the WAP push SMS is sent to the mobile handset of the end user. Case 1 or Case 2 Unlock UICC application notifStateChangeToMno (unlocked status. he informs the MNO using the notifStateChangeToMno notification.Sequence diagram of Process 6 – End user installs the MMI from an application store In case 3. During the MMI installation process in cases 1 and 2. the SP manages the retries. Case 2 Figure 51 . the SP must use the notifStateChangeToMno notification to inform the MNO of the MMI installation or update.

always after Process 5 Update – Mobile NFC UICC application update .5.4 Process 7 – MMI and UICC application binding Sequence diagram Service Provider bindMmiReq ACF loading in UICC (if MNO uses it) or equivalent bindMmiResp Mobile Operator Mobile handset Figure 54 – Sequence diagram of Process 7 – MMI and UICC application binding Description If the MNO uses MMI and UICC application binding.during the MMI update process. AFSCM Interface Specification V2.6 Life cycle processes 4.1 – February 2012 – AFSCM Confidential & Proprietary p92/102 .6. the Service Provider may lock the service until the MMI update is operative.during the installation process.Figure 53 . 4.Sequence diagram of Process 8 – Change UICC Description The MNO informs the Service Provider that the end user has a new UICC using the notifNewDevice notification. for instance if the new MMI is signed with a new certificate that requires an update of the bindings. 4. and optionally of the MMI application if needed. The Service Provider must then keep the MNO informed using the notifStateChangeToMno notification. It should then be used: .Sequence diagram of Process 6 – Critical MMI update In case he deems it critical to have an up-to-date MMI in order to use the mobile NFC service. The Service Provider will then have to go through the installation steps of the UICC application.1 Process 8 – Change UICC Sequence diagram Service Provider Mobile Operator UICC Old UICC deactivation New UICC activation notifNewDevice (UICC) Sub-process A – MNO eligiblity Sub-process B – SP compatibility Process 5 – Installation of UICC application Process 7 – MMI and UICC application binding Process 6 – Service Provider MMI installation/update Dependent on the compatibility of the MMI with the new UICC / UICC application Figure 55 . always after Process 5 – Mobile NFC UICC application installation .during the update process. the SP must use the bindMmiReq request.

3 Process 10 – Change mobile handset Sequence diagram Service Provider notifNewDevice (Mobile handset) Sub-process A – MNO eligiblity Sub-process B – SP compatibility Process 6 – Service Provider MMI installation/Update Mobile Operator UICC Figure 57 . The new mobile phone number may or may not be provided by the MNO. The Service Provider has to change the idTech for this end user in his information system. depending on the country.6. In France. The Service Provider will then have to go through the steps of the MMI application installation process. the MNOs are not allowed to provide the new MSISDN.4 Process 11 – Lost or stolen mobile equipment. No information is passed in the notification about the new mobile handset: eligibility and compatibility check are thus required before launching the MMI application installation.1 – February 2012 – AFSCM Confidential & Proprietary p93/102 .Sequence diagram of Process 10 – Change mobile handset Description When he detects that the end user has changed his mobile handset. end user contacts MNO Sequence diagram Service Provider Mobile Operator UICC notifCallEndUserToSp (Loss or Theft) notifStateChangeToSp (App locked and Line suspended or restricted) MNO tries to lock application via OTA AND suspends (or restricts) phone line Applies IS lock if OTA lock failed Figure 58 . the MNO simultaneously: AFSCM Interface Specification V2. 4.4.6.2 Process 9 – Change mobile phone number Sequence diagram Service Provider notifChangeMsId (old & new identifier) Mobile Operator NEW ID_TECH generation UICC Saves the new identifier in IT system Figure 56 . end user contacts MNO Description When an end user reports a lost or stolen mobile handset.6. 4. he generates a new idTech and notifies the SP using notifChangeMsId.Sequence diagram of Process 9 – Change mobile phone number Description When the Mobile Network Operator changes the end user’s mobile phone number. the MNO sends a notifNewDevice notification to the SP.Sequence diagram of Process 11 – Lost or stolen mobile equipment.

the SP informs the MNO of the call. end user contacts SP Description When he receives a call for lost or stolen mobile equipment.6 Process 13 – Recover mobile equipment after a loss Sequence diagram Figure 60 . depending on whether the mobile NFC service was permanently locked or simply locked: . If the UICC application is still unlocked after the MNO actions.If the service was simply locked OTA by the SP. using the notifCallEndUserToMno notification. end user contacts Service Provider Sequence diagram Service Provider Mobile Operator UICC notifCallEndUserToMno (Loss or Theft) Service Provider attemps to lock application via OTA Applies IS lock if OTA lock failed notifStateChangeToMno (UICC application GP lock or Service lock on IT) Figure 59 . all locks are communicated to the MNO using the notifStateChangeToMno notification.If the service was permanently locked. AFSCM Interface Specification V2. after which he informs the SP about the new status of the application and the line using the notifStateChangeToSp notification. but not the MMI. 4. Then.6.1 – February 2012 – AFSCM Confidential & Proprietary p94/102 . attempts to lock the service before line suspension. in case of failure. 4. applies an IS lock on the service. . The Service Provider then attempts to lock OTA the service and. he unlocks it and informs MNO using the notifStateChangeToMno notification.5 Process 12 – Lost or stolen mobile equipment.Sequence diagram of Process 12 – Lost or stolen mobile equipment.6.informs the SP of the loss or theft using the notifCallEndUserToSp notification.Sequence diagram of Process 13 – Recover mobile equipment after a loss Description The MNO informs the SP using notifStateChangeToSp when the line of the end user is restored after the recovery (following a loss or theft) of his mobile phone. the Service Provider deletes and reinstall the UICC application. the SP applies an IS lock on the mobile NFC service.

9 Process 16 .6.Change in contract ownership Sequence diagram AFSCM Interface Specification V2. suspends end user’s line Transfers entitlements and applies IS lock notifStateChangeToSp (Line suspended) notifStateChangeToMno (Service lock on IT) Unlocks the service on Information System notifStateChangeToSp (Line activated) notifStateChangeToMno (Service unlock on IT) At the date agreed with end user.6. later on. 4.8 Process 15 – End User requests temporary mobile service suspension Sequence diagram Service Provider Mobile Operator At suspension date agreed with end user. The SP uses the notifStateChangeToMno notification to inform the MNO of the lock applied and.7 Process 14 – Get new mobile equipment after a loss or theft Sequence diagram Service Provider notifNewDevice (UICC+Mobile phone) notifStateChangeToSp (Line Activated) Sub-process A – MNO eligiblity Sub-process B – SP compatibility Proceed to mobile NFC service installation processes Mobile Operator Provide new UICC and new mobile phone to end user Reactivation of the end user’s line UICC Figure 61 . 4. the MNO uses the notifNewDevice and notifStateChangeToSp notifications to inform the SP. These notifications are sent independently and the SP must use the notifStateChangeToSp notification as a starting point to trigger the eligibility and compatibility checks and the service installation.6.Sequence diagram of process 15 – Suspension of mobile service upon end user’s request Description The MNO uses the notifStateChangeToSp notification to inform the SP of the line suspension and thenn.4.1 – February 2012 – AFSCM Confidential & Proprietary p95/102 . of its re-activation. later on.Sequence diagram of Process 14 – Get new mobile equipment after a loss or theft Description When the end user gets a new mobile handset and UICC after a loss or theft. released. the MNO reactivates the end user’s line. restores end user’s line Figure 62 . Thus.

4.6. This process can be implemented as a termination. the Service Provider applies an IS lock on the service and informs the MNO using the notifStateChangeToMno notification.1 Process 18 – Termination of Mobile subscription or NFC option by end user Sequence diagram Service Provider Mobile Operator UICC Transfers entitlements and applies IS lock notifStateChangeToSp (Line or NFC option terminated) notifStateChangeToMno (Service lock on IT) Terminate line or NFC option Figure 64 .Sequence diagram of process 16 – Change in contract ownership Description The MNO uses the notifStateChangeToSp notification to inform the SP of the change in contract ownership.2 Process 19 – Mobile service termination by Mobile Network Operator Sequence diagram AFSCM Interface Specification V2.7. 4. the main impacts are in his Information System.7 Termination processes 4. If the SP wishes to implement this process.Service Provider Mobile Operator UICC notifStateChangeToSp (Contract owner CHANGED) Optional. only in case the end user remains the same and accepts service contract transfer Updates Information System OR Process 20 – Termination of mobile NFC service Figure 63 .7. 4.Sequence diagram of Process 18 – Termination of mobile subscription or NFC option by end user Description The MNO informs the SP of the line of NFC option termination using the notifStateChangeToSp notification.1 – February 2012 – AFSCM Confidential & Proprietary p96/102 . When the transfer of entitlements is done.10 Process 17 – End user swaps Mobile Network Operator Restrictions specific to version 2 Automated inter-MNO portability of mobile NFC services is out of scope of version 2 of this specification.

the Service Provider applies an IS lock on the service and informs the MNO using the notifStateChangeToMno notification. When the transfer of entitlements is done. of its restoration or termination.7. AFSCM Interface Specification V2.Sequence diagram of Process 20 – Mobile NFC service termination in DM mode In delegated management mode.Sequence diagram of Process 20 – Mobile NFC service termination in Simple SD mode In simple SD mode. of the suspension or restriction of the line and then. the SP uses the suppressReq request to ask the deletion of the service to the MNO who deletes the UICC application instance.1 – February 2012 – AFSCM Confidential & Proprietary p97/102 . In Delegated Management mode Service Provider getTokens Mobile Operator UICC Token calculation Delete application instance and package (if possible) notifStateChangeToMno (Token receipt) Delete bindings (if relevant) suppressReq (ID_SERV) Delete SSD suppressResp Figure 67 . suspends or restricts end user’s line Restore end user’s line If end user settles the situation OR Transfers entitlements and applies IS lock notifStateChangeToSp (Line Terminated) notifStateChangeToMno (Service lock on IT) At termination date. the SP uses the getTokens request to be authorized. depending on the status of the dispute process.Sequence diagram of Process 19 – Mobile service termination by MNO Description The MNO uses the notifStateChangeToSp notification to inform the SP first. 4. bindings (if relevant) and package (if possible) suppressResp Mobile Operator UICC Figure 66 .Service Provider Mobile Operator UICC notifStateChangeToSp (Line suspended or line restricted) notifStateChangeToSp (Line activated) At suspension date. the package (if there are no remaining instance linked to it) and the SSD if required. permanently stops end user’s line If end user does not settle the situation Figure 65 .3 Process 20 – Mobile NFC service termination In Simple SD mode Service Provider suppressReq (ID_SERV) Delete application instance. The MNO will also remove the bindings if present. SSD (if required). and sends OTA the GlobalPlatform commands in order to delete the UICC application instance and package.

AFSCM Interface Specification V2.Then. the Service Provider uses the suppressReq request to ask the MNO to delete the SSD. Finally. the SP uses the notifStateChangeToMno notification to inform the MNO with the token receipt.1 – February 2012 – AFSCM Confidential & Proprietary p98/102 .

A limitation to N retry cycles. the sending party may release the requests that were kept on hold 5. 5. the receiving party is declared unavailable: .4 Protocol retry management .The sending party must then use the HEART_BEAT query to check on the receiving party’s server status . In case of a connection disruption betweens platforms or in case a party does not send an acknowledgment. When the sending party of a call receives anything but a HTTP 200 code (including a connection timeout). upon request. responses and notifications described in section 3 Interface Specification of this document. The implementation of the retry mechanism must take into account: . After that limit.3 HEART_BEAT. .3 HEART_BEAT The HEART_BEAT service is used to query the status of the SP or MNO server: it is a HTTP request between the servers of the two parties and not a webservice. the other party uses the HEART_BEAT query as described in section 5.1 – February 2012 – AFSCM Confidential & Proprietary p99/102 . 5. This process is detailed in document [R5] Guidelines for interconnection of Service Providers' and MNOs' Information Systems. The AFSCM provides.The HEART_BEAT should be sent several times.4 Protocol retry management Each party must be able to reissue all the requests for which it did not receive an acknowledgment. responses and notifications are exchanged using web services with XML on HTTP. 5. It is therefore not included in the WSDL description files. A VPN is established between each MNO and Service Provider or his TSM. The following chart illustrates such a retry management between the sending party (the sender) and the receiving party (the receiver): AFSCM Interface Specification V2.2 Interface The Service Provider and the Mobile Network Operator need to establish a point to point VPN connection.5 WEB SERVICE IMPLEMENTATION The implementation of this section by Service Providers is mandatory.A progressive increment of time between two cycles.All requests must be put on hold by the sending party until the receiving party is deemed available again .Once the HEART_BEAT answer of the receiving party is HTTP 200 OK again.1 Protocol The requests. WSDL description files containing all requests. the absence of an answer can be considered as an incident and the technical team of the receiving party must be alerted. using the retry management mechanisms detailed in section 5.

In case of overload. When implementing load control. 5. in case of an overload exception. the heart_beat_ko_counter is used to track the number of retry cycles and the heart_beat_ok_counter prevents a loop which could happen if the HEART_BEAT service was dysfunctional (for instance if the HEART_BEAT answer OK but the web service still answers KO).1 – February 2012 – AFSCM Confidential & Proprietary p100/102 . 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. Instantaneous load control will be performed by the MNO. AFSCM Interface Specification V2. Two load limitation criteria are here defined. Instantaneous load: Limitation of number of simultaneous requests to the MNO platform (number of requests per second is limited).The sender calls a function of the receiver ‘s web service Can be a synchronous response. Global load control may be performed by the MNO. and the Service Provider will have to re-issue the command. HTTP error responses will be received as an answer to the SP requests. an acknowledge or an exception The sender processes the answer The receiver’s web service answers Connection error (HTTP error or connection timeout) The sender puts all other web services calls on hold HTTP 200 OK answer The sender resets his heart_beat_ok_counter & heart_beat_ko_counter to 0 Connection OK The sender calls the HEART_BEAT service of the receiver The sender releases all web services calls that are on hold Connection KO The sender increments his heart_beat_ok_counter The sender increments his heart_beat_ko_counter heart_beat_ok_counter <N? no heart_beat_ko_counter <N? yes The sender alerts the receiver’s technical maintenance service yes The sender waits for heart_beat_ok_counter * wait_period The sender waits for heart_beat_ko_counter * wait_period Figure 68 – Retry management illustration In this example. stop sending new requests until the situation is resolved.5 Load control The Service Provider should apply flow control mechanisms in order to avoid overload situations. the Service Provider must control the number of simultaneous and ongoing requests and must. 2. This is a server based control and in case of overload. The MNO will apply flow control mechanisms on outgoing notifications in order to avoid overload situations on the Service Provider server. a ‘quota overcome’ exception will be thrown. related to: 1. Global load: limitation of number of ongoing requests for each Service Provider (number of asynchronous requests that have been acknowledged but have had no asynchronous response yet). N is the number of retry cycles.

1 – February 2012 – AFSCM Confidential & Proprietary p101/102 .6 Request sender authentication In order to ensure the authentication of the sending party of an XML message. it is recommended (particularly in the case of a shared TSM VPN) that the receiving party relies on the WS-Security standard.509 certificates or Kerberos with X.5.509 certificates. AFSCM Interface Specification V2. using PKI through X.

1 – February 2012 – AFSCM Confidential & Proprietary p102/102 .wsdl: notifications definitions .afscmTypes.wsdl: notifications and responses definitions END OF DOCUMENT AFSCM Interface Specification V2. responses and notifications exchanged on the SP/MNO interface.spInterface.wsdl: requests definitions Web services exposed by the Service Providers: .xsd: schema for all messages definitions Web services exposed by the Mobile Operators: .requestMno. The files are provided in electronic version upon request to the AFSCM and are listed below: Types definitions: .lifecycleNotifications.Appendix 1 XSD AND WSDL FILES The AFSCM provides the WSDL for the requests.afscmMsg.xsd: schema for all basic and complex types .

Sign up to vote on this title
UsefulNot useful