You are on page 1of 102

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-Franois Roueche Evelyne Babel Gal Grard, Mayss Chahid, Julian Alvero, Susana Oliver-Pastor Rolla Lamaa

Bouygues Telecom NRJ mobile Orange SFR AFSCM AFSCM Orange

Editor Document manager Approval

Sbastien Gauthier Sbastien 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

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

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

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

TABLE OF FIGURES ______________________________________________________________


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

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

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

p8/102

1 1.1

INTRODUCTION
Context
The Mobile Network Operators Bouygues Telecom, Orange and SFR have founded the AFSCM (Association Franaise du Sans Contact Mobile) to foster the development of mobile contactless services. The Service Providers Credit Mutuel, Socit Gnrale and Volia have already joined the AFSCM as associate members. The AFSCM objective is to support the inception of new contactless services for mobile phone users. In particular, AFSCM 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; To specify technical guidelines for the development of mobile contactless services to ensure seamless installation and consistent user experience;

To promote the benefits of the mobile phone platform for contactless service providers, for technology providers and for end users. To define a mutually beneficial mobile contactless eco-system, AFSCM will propose a shared mobile contactless target mark and a shared brand that will distinguish those contactless services that are available to mobile phone users. AFSCM constituency will include all companies involved in the development of a sustainable market for mobile contactless services such as Service Providers, handset makers, smart card manufacturers, Mobile Network Operators, MVNOs. Together, AFSCM members will contribute to the definition of innovative industry standards and best practices. The stated objective of the AFSCM is to facilitate the development of mobile contactless services. To this end, the founding members recognize the significance of the following success factors: Virtuous eco-system in which all parties involved can develop a sustainable market position, Efficient customer support, Smooth customer experience, State-of-the art application life cycle management, Service portability in the event of a mobile equipment swap, Service portability in the event of a Mobile Network Operator swap.

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

p9/102

1.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. To this end, AFSCM members have recognized the definition of a standardized interface and processes. That ensures interoperability between the actors simplifies the deployment and avoids redundancy in a multi-actors environment. From the point of view of a Service Provider, this interface specification ensures that the same mechanisms and the same server will be applicable regardless of the mobile network selected by the end user. From the point of view of a Mobile Network Operator, this interface specification provides a unified way of exchanging data with any Service Providers of mobile NFC services. Furthermore, this specification covers the entire life cycle of a mobile NFC service from the perspective of the end user.

1.3

Content of the interface specification


This document describes in chapter 2 Functional Requirements: process description and flowcharts the processes for every step of the customer journey: inquiry of information, subscription and installation of the mobile NFC service, use and termination of the mobile NFC service. Then, the document presents the detailed specification of the interface between Mobile Network Operators and Service providers in section 3 Interface Specification. Section 4 Process implementation reference presents the exchanges on the SP/MNO interface for all processes of the customer journey, Web service implementation, exchange protocol and the connection between the information systems of both actors are described in section 5 Web service implementation.

1.4

Assumptions
The work of the Process and Technical committees of the ASFCM, resulting in the current document, has been based on two sources of information: - On one hand, the existing specifications of Mobile NFC services. These specifications target implementation for dedicated service domains: o Ulysse specifications for mobile NFC transport ticketing services, o and Payez Mobile specifications for mobile NFC payment services. - And on the other hand, the technical capabilities of the different components of the NFC ecosystem including the NFC mobile handset, the UICC and the MNO information systems. A key driver is to propose a simple and efficient solution, which covers all identified NFC use cases for a UICC centric model. It is a more mature solution than version 1 and targets large commercial deployments. The AFSCM also specifies high level requirements for both UICC and mobile handsets in separate documents. These documents are only provided to the relevant suppliers on request. UICC technology The NFC application is hosted on the UICC of the mobile equipment. The UICC uses JavaCard 2.2.2 technology and implements GlobalPlatform 2.2. Supported GlobalPlatform features Within the features defined by GlobalPlatform for remote application management, both Simple SD management (with DAP as an option) and Delegated Management are supported. Confidential Loading for packages is not supported in this version of the specification.

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

p10/102

Mandated DAP is supported but has no impact on this interface specification. Mandated DAP is a feature that automatically ensures that the applications loaded on the UICC were previously validated. UICC memory size In version 2 of the specification, it is not possible to manage memory space booking on a UICC as described in Payez Mobile. OTA capabilities The SSD are created in the UICC. SSD can be created in two different ways: - SSD creation in factory in this case, the SSD root keys may not be managed by the MNO. - Or SSD creation OTA in this case, the SSD temporary keys are managed by the MNO. The application package is loaded in the UICC. It can be loaded either in factory or OTA. Once the application is available in the UICC, the application activation (or deactivation) is performed upon request of the Service Provider. Process and Information Systems The following assumptions are made based on the current Information System limitations: - The Mobile Network Operators will not send notifications to the Service Providers prior to line suspension, termination or UICC change for instance. The Service Providers are informed once the suspension or termination is effective. - A technical identifier is used to identify the end user in the communication between Mobile Network Operator and Service Providers. The Mobile Network Operator is identified in the header of each request, response and notification with the mnoId data. - Another restriction is related to the synchronisation of actions in case of urgent situations such as loss or theft. 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. Yet, it relies on the capacity of the Mobile Network Operators information system to perform the locking actions before line suspension or termination, which is not guaranteed in version 2 of this specification. 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. 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.

1.5

How to use this specification?


Mandatory, conditional and optional features In the specifications below, some features are optional or conditional. They are represented in dotted line in the flowcharts and the conditions are mentioned in the description. These features are optional or conditional for the Service Provider, except for the MMI and UICC application binding, the implementation of which is a decision of the MNO. 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. From this perspective, 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.

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

p11/102

All features that are not explicitly optional or conditional are mandatory features. They must be implemented by each Service Provider in order to be AFSCM compatible. The MNO platform is ready to manage all the possible Service Provider configurations provided that they are compliant with the current interface specification. Versions Version 1 of this specification was designed to meet the requirements for short term deployments in 2010. Version 2 is designed for commercial deployment and improves on version 1 by - bringing new features such as Delegated Management support, - adding more functions, which are more modular, while retaining the simplicity of version 1, - including various feedbacks from Service Provider and industry partners following the 2010 short term deployments. - Improving reliability mechanisms (validity period, retries)

1.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: - The NFC applications validation process. The purpose of this document is to provide the Service Providers with a unique process and rules for elaborating NFC applications taking into account the MNO requirements. - The NFC applications (Cardlet and MMI) development guidelines. The rules for elaborating NFC applications are fully detailed in a guidelines book that gather all the functional, technical and security requirements regarding the process for validation, loading and hosting of NFC applications. - The definition of Secure Service Management roles, - The guidelines for interconnection of Service Providers' and MNOs' Information Systems. This document is the continuation of the interface specification, providing information on the process to be applied and the data that must be exchanged prior to establishing any connection between information systems. This document specifies the provisioning mechanisms for compatibility. - The customer support guidelines

1.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 - General Description v1.1 Book 1 - Mobile Handset UICC Applications v1.1
p12/102

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

[R9]

Book 2 - Payment Service Delivery & Management v1.1

[R10] Book 3 - Payment Processing v1.1 Ulysse [R11] Contactless transport ticketing using mobile phones - General Specifications V1.1 [R12] Contactless transport ticketing using mobile phones - Technical Specifications V1.1 GlobalPlatform [R13] Global Platform Card Specification 2.2.1 [R14] UICC configuration 1.0.1

1.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 Europenne Payez Mobile Association Franaise 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.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.6.1 Invitation presented to the end user for getting his approval or rejection for instance for downloading the MMI. 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.1 February 2012 AFSCM Confidential & Proprietary

p13/102

FUNCTIONAL REQUIREMENTS: PROCESS DESCRIPTION AND FLOWCHARTS


This section presents all the user experiences as they can be implemented in version 2. The restrictions compared to the mid term and long term target as defined for instance in Payez Mobile or Ulysse are highlighted.
Action Choice Covers a process already described

Optional action or process

Process

Notifications

Figure 1 Process flowcharts legend

2.1

Process overall mapping


The following chart presents the processes that are described in this document, grouped in categories. Optional or conditional processes are represented with a dotted outline.
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, only if SP wants to update OTA

Install / Update MMI Process 6

Conditional, mandatory only if MMI is necessary

Conditional, mandatory when MNO supports it

MMI and UICC application binding - Process 7

Change UICC Process 8

Change Mobile Phone Number - Process 9

Change Mobile Handset Process 10

Use

Lost/stolen Mobile equipment, user contacts MNO - Process 11

Lost/stolen Mobile equipment, user contacts SP - Process 12

End user requests Temporary mobile service supsension - Process 15

Recover mobile equipment Process 13

Get new mobile equipment Process 14 Optional process Not supported yet

Change in contract ownership - Process 16

End user swaps MNO Process 17

Termination

Termination of Mobile subscription or NFC option by end user - Process 18

Mobile service termination by MNO - Process 19

Mobile NFC service termination - Process 20

Figure 2 Process overall mapping

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

p14/102

2.2

Service discovery, subscription and installation sequences


There are several ways to sequence the inquiry, subscription and installation steps. 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, Process 1 can be accessed from the MNO wallet for instance.
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, 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.1 February 2012 AFSCM Confidential & Proprietary p15/102

Use case example #3: subscription in the service providers offices


The end user goes at the service providers 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 Providers office

2.3

Eligibility and scoring sub-processes


This section presents sub-processes regarding eligibility and scoring, that will be used further in several processes. 2.3.1 Eligibility and compatibility: definitions This version of the specification introduces the notion of compatibility, in order to be able to manage a growing number of UICC and handset models. Eligibility is still the responsibility of the MNO, and ensures an end users equipment is eligible to mobile NFC services (see Sub-process A). Compatibility is the responsibility of the Service Provider, 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, or that his MMI is available for this reference, etc). A given mobile NFC service may for instance be available for a handset model and not for another. 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, 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, Inform the end user about new services now available for his mobile handset, Present to the end user only the services that are compatible with his device during service discovery.

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

p16/102

This will be achieved at provisioning stage. The SP will provide the MNO with a list of compatible devices/operating systems with its services. This provisioning solution is described in [R5] Guidelines for interconnection of Service Providers' and MNOs' Information Systems. In addition to helping the end user find the services compatible with his handset, this will help the Service Provider avoid compatibility issues or end user complaints. 2.3.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: - mobile handset eligibility - UICC eligibility - 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 users equipment is eligible to the mobile NFC service. In this sub-process, the MNO is responsible for ensuring the said eligibility, based on the information at his disposal and the following criteria: - Commercial contract: the end-user has a contract with the Mobile Network Operator, and has access to NFC services - Technical: UICC and mobile handset are NFC capable - Available memory space on UICC [Note] Should the end user gets his mobile equipment outside of the Mobile Network Operators' point of sales network, the MNO cannot guarantee its eligibility, even if it is NFC capable.

Restrictions specific to Version 2 In Version 2 of this specification, the way the eligibility check works might differ from one MNO to another especially regarding the available memory space on UICC; moreover, the accuracy of the information regarding the available memory space is not guaranteed.

2.3.3

Sub-process B SP compatibility

Flowchart

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

p17/102

Sub-process B SP compatibility Service Provider


Request detailed information about the end users mobile equipment (UICC and/or mobile handset)

Mobile Network Operator

Provide detailed information about the end users 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 users equipment is technically compatible with his mobile NFC service. The Service Provider is responsible for maintaining a list of mobile handsets and UICC models that are compatible with his mobile NFC service. In this sub-process, the MNO provides the necessary technical information to the SP, and the SP checks the said technical compatibility. 2.3.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. The MNO takes no part in this process.

2.4

Service discovery and inquiry processes


In these processes, the end user discovers the NFC services. In the Process 1, he discovers a mobile NFC service on an online application store. This process is optional.

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

p18/102

In the other processes, the end user inquires about a mobile NFC service and contacts either the Service Provider (Process 2) or the Mobile Network Operator (Process 3). Both processes are mandatory. 2.4.1 Process 1 Online service discovery

Flowchart
Process 1 - Online service discovery End user Mobile Network Operator
Check services to which the end users 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 users 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, or the mobile handset OS provider; MNO application stores contains applications that are showcased by the MNO ; in this case, 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, the SP needs to provide the MNO its service compatibility information. The provisioning of this information is described in [R5].

2.4.2

Process 2 Inquiry to the Service Provider

Flowchart

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

p19/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: - mobile NFC services - 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. The Service Provider verifies the end users equipment eligibility and invites him to subscribe. Shoud the end user not be eligible, 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. 2.4.3 Process 3 Inquiry to the Mobile Network Operator

Flowchart

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

p20/102

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; the MNO will thus check the end users eligibility and, should the end user not be eligible, propose the appropriate mobile equipment and offer. The MNO can invite the end user to contact the Service Provider for additional information about the service (Process 2) or subscription (Process 4).

2.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 - From the mobile handset in a WAP session (in a WAP browser or through the MMI, if it has already been installed) The Service Provider must use at least one of these channels. 2.5.1 Process 4 Subscription to a mobile NFC Service

Flowchart

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

p21/102

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 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 users 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. 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 users first subscription to a mobile NFC service or a subscription to an additional mobile NFC service. During the course of this process, the Service Provider must identify the end user in order to be able to communicate with the MNO; several possibilities exist:

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

p22/102

The Service Provider can ask the end users 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, provided upon agreement by the MNO)

2.6

Installation processes
2.6.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, which are optional). In this specification, a mobile NFC service is identified by a serviceId. The following precisions are made concerning this identifier: - All application instances of a mobile NFC service identified by the same serviceId are in the same SSD - If the SP updates one of his UICC application packages, the serviceVersion must be incremented - A service can only be installed once, and in only one serviceVersion, on a given UICC - A single UICC application package can be used to instantiate several cardlet applications, but with a different serviceId for each instance : the package is then shared between services - 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: - The MMI can be available in different formats and versions in order to address different handset models; more information about MMI formats for compatibility can be found in [R5] Guidelines for interconnection of Service Providers' and MNOs' Information Systems - 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, it does not increment the serviceVersion of the service) - A single MMI instance can use several UICC application instances with different serviceId identifiers - A UICC application can be used by several MMI that have the same serviceId - This document takes MMI installation into account, but direct implementation of this installation is not detailed. 2.6.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, can be done using the Simple SD mode or the Delegated Management mode. Service Provider MMI installation / update (Process 6): this process is conditional. It is possible that some mobile NFC services do not require a MMI. In this case the Process 6 is not applicable. MMI and UICC application binding (Process 7): this process is conditional: if the MNO implements bindings, the SP has to implement this process.

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

p23/102

These steps may be performed in the order of preference of the Service Provider, the only condition being that Process 7 must always come after Process 5 or Process 5 Update. The installation sequences are detailed in section 2.2 Service discovery, subscription and installation sequences . A mobile NFC service is considered completely installed, and is indeed fully operational for the End user, once the UICC application(s) AND the MMI are installed: it is thus imperative, particularly for the customer services, that the Service Provider notifies the MNO of the MMI installation progress. These installation processes also include the update of applications, described by the following processes: - Process 5 Update for the UICC application update. Implementation of this process is optional, depending on the Service Providers decision to be able to update OTA its UICC application. As for the installation of the UICC application, this process can be implemented using the Simple SD mode or the Delegated Management mode - Process 6 for the MMI update. Implementation of this process is mandatory when there is a MMI. [Note] In the mobile NFC service lifespan, the MMI might be deleted from the end users mobile handset. The Service Provider is responsible for the tolerance or not that his mobile NFC service is used without the MMI on the mobile handset. In case the SP tolerates such use, it is recommended to inform the end user that he cannot benefit from full capacity of his mobile NFC service. If not, the SP should either launch the MMI installation or lock or delete the UICC application. 2.6.3 UICC and UICC application architecture The UICC application, also named application, is composed of one or several packages, one or several instances and personalisation data hosted in the UICC as represented below. The drawing below is an example of representation of all that is necessary on the UICC before the mobile NFC service can be used.
ISD SP SSD

Package

Instance Perso Data

Figure 14 Representation example of the UICC application In Simple SD management mode, the MNO sends the CCM commands to the UICC upon request of the Service Provider. 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, the SP requests a token from the MNO for each action to be done on the UICC (package loading, application installation). Once it has the tokens, 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.

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

p24/102

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

Package

Instance

Or
ISD SP SSD

Package Instance

FULLY PRELOADED The SSD is created in factory. The application is loaded, instantiated and extradited in factory. The personalisation can be done by the Service Provider in factory. The following operations are to be done OTA: If UICC application personalisation was not done in factory, it is done by the SP After the UICC application personalisation, only the activation of the application remains to be done OTA on the end users UICC, either by the MNO (upon SP request, Simple SD mode) or the SP (upon MNO authorization, Delegated Management mode). [Note] For this Fully preloaded scenario, the Service Provider only needs to send an activation request to the MNO.

ISD

SP SSD

Package

or
ISD SP SSD

PARTIALLY OTA In this scenario, the application is loaded in factory.The SSD may be created in factory (as represented) or OTA (by the MNO). 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, only the SSD may be created in factory; all operations are performed OTA: If necessary, the SSD may be created OTA by the MNO Package loading, 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.1 February 2012 AFSCM Confidential & Proprietary

p25/102

2.6.4

Process 5 Mobile NFC UICC application installation

Flowchart The following flowcharts present the UICC application installation process: - First in Simple SD mode o With the personalisation step before the activation step o With the personalisation step after complete installation and activation - Then, 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

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, if authorized, 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, 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, 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 MNOs platform before submitting requests for loading the package. The installation parameters are pre validated by the MNO. In both modes, the personalisation step may also occur after the activation.
AFSCM Interface Specification V2.1 February 2012 AFSCM Confidential & Proprietary p27/102

2.6.5

Process 5 Update Mobile NFC UICC application update

Flowchart The following flowcharts present the UICC application update process: - First in Simple SD mode - Then, 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, 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, specifying the reason why he is not eligible

Process 5 Installation of UICC application Simple SD mode

Process 3 - 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.1 February 2012 AFSCM Confidential & Proprietary

p28/102

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, request application deletion authorization

Deliver, if authorized, 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, specifying the reason why he is not eligible

Process 5 Installation of UICC application Delegated Management Mode

Process 3 - 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. It applies in following circumstances: - The end user replaces or updates his mobile NFC service requiring the installation of a new NFC application, - The Service Provider wants to update his NFC service or deploy a new service for one or all of his end users It should be noted that: - Since it is necessary to delete the existing application, the SP must first check the compatibility of the end users mobile equipment with the new version of the service. - 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. - Optionally the end user might have to sign a new contract or contract amendment. The installation process is otherwise similar to the one described in Process 5. 2.6.6 Process 6 Service Provider MMI installation / update This process is conditional. It is mandatory when a MMI is necessary for the mobile NFC service.
AFSCM Interface Specification V2.1 February 2012 AFSCM Confidential & Proprietary p29/102

There are three ways to initiate this process: Case 1: Upon Service Provider request, the MNO launches the MMI installation or update, Case 2: the Service Provider launches the MMI installation or update. Case 3: the end user installs the MMI from an application store

In all cases, it is assumed that the MMI hosting is not under the responsibility of the MNO. 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. There might be several MMIs in a service, using the same UICC applications: in this case, should several MMIs be installed, this process may be repeated as many times as necessary. Case 1: flowchart
Process 6 Service Provider MMI installation/update
Case 1: Upon Service Providers request, 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, case 1 Case 1: description In this case, it is not the Service Provider, but the MNO who initiates the OTA connection with the mobile handset, in order to load the MMI application on the end users mobile handset. Depending on the agreement between the Service Provider and the MNO, there are two possibilities: i. The MNO manages the entire installation including retries if necessary. The MNO informs the Service Provider once the MMI is actually loaded in the mobile handset. In case of connection interruption during the MMI loading, the MNO manages the retry policy. In this situation, there is a local synchronisation mechanism in the mobile handset to ensure the MMI download. This mechanism is an option that can be proposed by the MNO. It can only be available on NFC mobile handsets sold by the MNOs implementing it.
AFSCM Interface Specification V2.1 February 2012 AFSCM Confidential & Proprietary p30/102

ii. Or the MNO sends a WAP push SMS to the handset to establish a connection with the Service Providers MMI server. In case of connection interruption during the MMI loading, the SP manages the retry policy, by sending a new request to the MNO. 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, case 2 Case 2: description In this case, the Service Provider is fully in charge of the MMI download and installation. Several reasons might cause failure of the MMI download (network coverage loss, mobile handset switched off, end user rejects or does not approve opt-in ). It is recommended to attempt several consecutive times to download the MMI before considering that it has failed. In case the MMI is never installed, the SP notifies the MNO and may: suppress the UICC application, inform the end user in case of installation failure.

Case 3: flowchart

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

p31/102

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, 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, case 3 Case 3: description In case 3, the end user directly installs his MMI from an application store. MMI installation notification In all cases, 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. Thus, during the MMI installation process, the Service Provider must notify the MNO of the following events: MMI installation completion Failure during MMI installation No MMI has been installed, because the MMI is already installed (no installation is needed) MMI update completion Failure MMI update

[Note] In some cases, 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 SP must build a notification inside the MMI to be triggered at first launch. MMI update When the Service Provider needs to update the MMI on the end users mobile handset, the two processes described above (case 1 and case 2) also apply. For case 3, the standard update mechanisms used by the application store apply.

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

p32/102

In case the Service Provider estimates that it is urgent and mandatory, ie critical, to update the MMI for using the mobile NFC service, the Service Provider might decide to lock the service until the MMI update is effective. The Service Provider is responsible for such a decision and must notify the MNO. 2.6.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. The Service Provider should use this process when the UICC applications are installed and active. This process is conditional since MMI and UICC application binding support is optional for the MNO. 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. In case of MMI update, 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, or when the MMI bears a new certificate). The MNO always loads the most recent bindings available for this service version.

2.7

Life cycle processes


The following processes can be encountered during the use of a mobile NFC service. Their support is mandatory to implement a mobile NFC service and ensure a consistent end users experience. Change UICC (Process 8) Change mobile phone number (Process 9) Change mobile handset (Process 10) Lost or stolen mobile equipment, 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.1 February 2012 AFSCM Confidential & Proprietary

Change in contract ownership (Process 16) End user swaps Mobile Network Operator (Process 17)

2.7.1 Locking a mobile NFC service The processes in this specification use several ways to lock a mobile NFC service. This could happen following a theft, loss or in any other process that requires it. The locks performed by the Mobile Network Operator are OTA locks. They can be of two kinds: - Set the GlobalPlatform status of SD or the UICC application(s) to LOCKED - Use a OTA command which blocks the contactless interface of the UICC The locks performed by the Service Provider could be: - 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, the SP locks it by sending it the appropriate OTA command (referred to as OTA applicative lock, for instance with an EMV script processing command APPLICATION BLOCK) - IS locks o The SP blocks the use of the end users service in its Information Systems (IS). The SP is then responsible for the corresponding lock policy: temporary or definitive lock, blacklist, 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. [Note] It is recommended that only the party which locked an application is in charge of unlocking it when necessary. Each party must thus clearly register in its Information System the responsibility of each lock. 2.7.2 Suspended line and restricted line In some situations, the MNO suspends the end users line. But it can also be useful to only restrict the line in some cases: - When a users line is suspended, he cannot access at all the MNOs network and thus has no access to any telecom service. - When a users line is restricted, incoming calls or messages are enabled but no outgoing communication is allowed, like voice, data and SMS (particularly, PoR messages are blocked) 2.7.3 Process 8 Change UICC

Flowchart

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

p34/102

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, to get larger memory space or to get additional features. Changing the UICC requires to reinstall the UICC application. In addition, in order to ensure service continuity after a UICC change, 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. The responsibility of the end user must thus be mentioned in MNO and Service Provider contracts, regarding the destruction of the old UICC. 2.7.4 Process 9 Change mobile phone number

Flowchart

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

p35/102

Process 9 Change mobile phone number (without changing UICC, 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. 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. The Mobile Network Operator notifies the Service Provider about the change of idTech. If needed, the Service Provider must contact the end user to get his new mobile phone number. 2.7.5 Process 10 Change mobile handset

Flowchart

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

p36/102

Figure 26 Flowchart of process 10 Change mobile handset Description When the end user changes his mobile handset, it is convenient to provide him with assistance for launching the installation of the MMI for each mobile NFC service hosted in his UICC. Yet, as the mobile change may be temporary, an Opt-in is presented to the end user so that he can decide whether downloading of MMI is necessary or not on this mobile handset. Once the end user inserts the UICC in a new mobile handset: - Either a local detection is done on the mobile handset to identify that MMI are missing compared to the content of the UICC. (An application detecting missing MMIs on the mobile handset is an option that can be implemented by the MNO. It can only be available on mobile handsets sold by the MNOs supporting it.) If there is a local application for detection of missing MMI, an opt-in is presented to the end user: if the end-user opts in, the local detection application operates connects to the Service Providers servers to download the MMI. - Or the Mobile Network Operator remotely detects that the mobile handset has changed. In case the detection is done remotely on his information system, the MNO notifies all relevant Service Providers about the end users 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.

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

p37/102

2.7.6

Process 11 Lost or stolen mobile equipment, end user contacts MNO

Flowchart
Process 11 End users mobile equipment was lost or stolen. End user contacts his MNO. 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, definitive IS lock, OTA lock, ...) If not already done, 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, definitive IS lock, OTA lock, ...)

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 users mobile equipment was lost or stolen. End user contacts his Service Provider.

Figure 27 Flowchart of process 11 Change UICC Lost or stolen mobile equipment, end user contacts MNO Description Since the lost / stolen UICC is left in an uncontrolled environment, 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. The MNO will thus attempt to lock OTA all mobile NFC services hosted on the end users mobile equipment or its UICC NFC interface before line suspension. Regardless of the success or not of the OTA lock performed by the MNO, the Service Provider must apply a IS lock on the end users service and apply his own loss or theft policy. [Note] In some cases, some MNO may restrict the line instead of suspending it. The SP will then be notified of a line restriction instead of a line suspension. 2.7.7 Process 12 Lost or stolen mobile equipment, end user contacts Service Provider

Flowchart

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

p38/102

Process 12 End users mobile equipment was lost or stolen. End user contacts his Service Provider. End user Service Provider

End user contacts his Service Provider

Use

Identify and authenticate End user for mobile NFC service. Invite end user to contact his MNO

Notify MNO about End users call

If not already done, contacts his MNO

Launch appropriate process (IS lock or black/grey-list, definitive IS lock, OTA lock, ...)

Attempt to lock OTA the mobile NFC application

Notify MNO about lock status

Process 11 End users mobile equipment was lost or stolen. End user contacts his MNO.

Figure 28 Flowchart of process 12 Change UICC Lost or stolen mobile equipment, 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. The SP must thus authenticate the end-user before notifying the MNO. 2.7.8 Process 13 Recover mobile equipment after a loss (or theft)

Flowchart

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

p39/102

Process 13 After a loss or theft, 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, there are two possibilities on line restoration: - If the service was permanently locked, the SP must entirely reinstall the mobile NFC Service. It is thus necessary to suppress the old version of the service. - If the service was reversibly locked, the SP unlocks it on its IS. 2.7.9 Process 14 Get a new mobile equipment after a loss or theft

Flowchart

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

p40/102

Process 14 After a loss or theft, the End user has a new NFC mobile handset and UICC and wants to restore his mobile NFC service End user
End user contacts his MNO Provide end users new equipement Restore end users 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, 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 users new equipment and of its line re-activation; the SP should proceed to the eligibility and installation steps after the reactivation notification. It must be noted that eligibility and compatibility check are required since the notification does not imply that the new equipment is NFC compatible. In order to ensure service continuity, the Service Provider should transfer the entitlements that were stored in the former UICC in the new one. 2.7.10 Process 15 End User requests temporary mobile service suspension

Flowchart

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

p41/102

Process 15 End User requests temporary mobile service suspension End user Service Provider Mobile Network Operator
Acknowledge end users request and agree on suspension date and restore date

End User requests temporary mobile service suspension

Transfer entitlements and lock of service on information system

At suspension date, 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, 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, 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.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, or dont 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.1 February 2012 AFSCM Confidential & Proprietary

p42/102

Figure 32 Flowchart of process 16 Change in contract ownership Description The owner of the contract with the MNO changes. Two cases occur: The new owner of the contract was the end user of the phone line, 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, 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. 2.7.12 Process 17 End user swaps Mobile Network Operator

Description The end user changes Mobile Network Operator, while keeping the same phone number and wants to keep the mobile NFC services. He has to go through two consecutive steps: - Mobile subscription termination (Process 18) with the first 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.

2.8

Termination processes
There are three mobile NFC service termination processes: - Mobile subscription or NFC option termination by end user (Process 18) - Mobile service termination by Mobile Network Operator (Process 19) - Mobile NFC service termination (Process 20) Unlike a suspension or a restriction, a line termination is permanent. It should be noted that in all termination processes, the end user is responsible for destroying the UICC 2.8.1 Process 18 Termination of Mobile subscription or NFC option by end user

Flowchart

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

p43/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 Providers for transferring his rights to another support

At termination date

Termination

At termination date, try to lock the mobile NFC services OTA

At termination date, permanently stop mobile service or NFC option

Transfer end users 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, agreed between the end user and the MNO. Upon reception of the termination notification, the Service Provider can organize the transfer of entitlements available in the current UICC. 2.8.2 Process 19 Mobile service termination by Mobile Network Operator

Flowchart

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

p44/102

Process 19 Mobile service termination by MNO End user


End user doesnt respect the MNOs 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 users 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 users mobile service termination

Yes

Restore the line and Notify Service providers

Termination

At termination date, try to lock the mobile NFC services OTA

Definitly stop End users 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,

Notify MNO about locking

Figure 34 Flowchart of process 19 Mobile service termination by Mobile Network Operator Description Upon reception of the termination notification, the Service Provider can organize the transfer of entitlements that were available in the current UICC. The Service Provider might do this action earlier, upon reception of the notification for line suspension. 2.8.3 Process 20 Mobile NFC service termination

Flowchart The following figures present the mobile NFC service termination process, in Simple SD mode and Delegated Management mode, respectively.

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

p45/102

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 users 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, 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 users 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, 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, 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: - The end users wants to suppress the application from his mobile handset or to terminate the mobile NFC service, - Or the Service Provider wants to terminate the mobile NFC service for this end user. Once the Service Provider launches the termination process: - in Simple SD mode, the MNO performs the deletion of the service on the UICC and notifies the deletion status to the SP.
AFSCM Interface Specification V2.1 February 2012 AFSCM Confidential & Proprietary p46/102

in Delegated Management mode, the SP performs the deletion using the tokens provided by the MNO and notifies the MNO about the status of the deletion. The Service Provider is responsible for asking the deletion of the SSD. -

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

p47/102

3 3.1

INTERFACE SPECIFICATION
Introduction
The current specification focuses on one core interface between the Service Provider (and possibly his subcontracting company acting as Secure Service Manager) and the Mobile Network Operator. All the requests related to the management of the mobile NFC services are handled on this interface. This interface defines the following types of requests: - Control functions used to query the eligibility of the end user for mobile NFC service, - Requests and responses related to the installation, activation and deletion of the Mobile NFC service application, - Notifications between Service Provider and Mobile Network Operator related to the life cycle of the UICC, mobile handset, mobile NFC service application, mobile subscription Functions and requests are always issued by the Service Provider and their responses are generated by the MNO. Notifications can be sent both ways.

Figure 37 Architecture overview 3.1.1 Implementation The entire content of this section is implemented by MNO, except when explicitly written otherwise, and must be implemented by Service Providers. 3.1.2 Elementary requests / batch Each request, response or notification concerns one single end user (msId). No request is provided to handle batch processing. 3.1.3 Naming conventions Synchronous function Asynchronous request Asynchronous response Notification

functionName requestNameReq responseNameResp notifNotifName

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

p48/102

3.1.4 Data types This specification uses standard data types such as integer, string, etc and defines custom data types. These data types are defined in section 3.9.1 Data types. 3.1.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, as well as the notifications, are synchronous and require synchronous answers. Functions require a direct and synchronous answer, or an exception. Notifications require a synchronous acknowledgment. Asynchronous requests and responses The requests in the interface that do require remote access to the UICC or mobile handset are asynchronous. Those requests use a unique transaction identifier (requestId), generated by the party sending the request. The same transaction identifier is sent in the asynchronous response to match responses to requests. The transaction identifier (requestId) is composed of three data blocks separated by colons: o serviceId numeric up to 5 digits o Timestamp in milliseconds- 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, which can be an exception in case a format error or a data error is identified in the parameters of the request. In case an exception is thrown, no asynchronous response will be sent. Representation The following sequence diagram illustrates the various synchronous and asynchronous exchanges.
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, 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, 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 February 2012 AFSCM Confidential & Proprietary p49/102

3.1.6 Retries and validity period management for asynchronous requests When using asynchronous requests, which entail OTA commands execution, it is important to define how to manage the retries. Request identifier Each asynchronous request is marked with a unique identifier, generated by the Service Provider, which is passed in the asyncHeader header. When sending a retry of a request, the identifier must be the same as the one that has been sent first. When receiving this retry attempt, the Mobile Network Operator is able to track retries, and if a call to a request is performed with an identifier of a request already in progress in its system, then the MNO shall refuse the new call. Validity period Each asynchronous request has an optional validity period that can be set by the Service Provider, in the asyncHeader header. This field defines the length of the period (provided as a number of seconds) during which the request is valid. The period starts at the time the function call was received by the MNO and ends a number of seconds later. During this period, the MNO has the responsibility to execute all the individual execution steps that are required to complete the request. The following flowchart details how the validity period is to be implemented.
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, 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, 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.2

Headers
3.2.1 syncHeader Header for Synchronous Requests This header is applicable to synchronous requests and notifications.

TYPE syncHeader

Header for Synchronous Requests


p50/102

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

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. This item is reserved for future use. Providing data in this field will have no impact 3.2.2 asyncHeader Header for Asynchronous Requests This header is applicable to asynchronous requests. It requires a transaction identifier. 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; for more details, 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, duration in seconds. For more information, see section Retries and validity period management

Mandatory Optional (RFU) (1) Optional

1. This item is reserved for future use. Providing data in this field will have no impact

3.3

Acknowledgments and exceptions


The acknowledgments and exceptions are synchronous responses to requests or notifications. - The acknowledgments are used to acknowledge the successful reception of a request. There are two different types of acknowledgments: o A simple HTTP acknowledgment o An acknowledgment with a validity period - The exception is used in case an error is detected 3.3.1 acknowledge The MNO sends a standard acknowledgement as a synchronous answer to each notification received from the Service Provider. The SP sends a standard acknowledgement as a synchronous answer to each notification received from the MNO. No particular structure is defined for this simple HTTP acknowledgment.

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

p51/102

3.3.2 acknowledgeWithValidityPeriod The MNO sends an acknowledgement acknowledgeWithValidityPeriod as a synchronous answer to each asynchronous request received from the Service Provider. ACKNOWLEDGEMENT acknowledgeWithValidityPeriod MNO SP, synchronous Data name Description Presence Accepted validity period of the request, duration in acceptedValidityPeriod seconds. For more information, see section Retries and Mandatory type : N validity period management

3.3.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. When an exception (faultMsg) is thrown in response to an asynchronous request, it cancels the process and no asynchronous response corresponding to this request will be sent. The exception (faultMsg) contains information about the type of error detected and optionally which data failed. An exception (faultMsg) can be thrown by the MNO and by the Service Provider. EXCEPTION faultMsg Data name errorType type: N(3) errorDetails type: char(var) SP MNO or MNO SP, synchronous Description Presence Indication of the type of error encoutered. Mandatory Possible values are listed in section 3.9.4 Exceptions Indication of the data that failed the control. Data identifier (ex : Optional mnoId, idTech, )

3.4

Identifiers
3.4.1 Technical Identifier idTech

Mobile Subscription identifier Most headers in the interface specification identify the mobile subscription using a mobile subscription identifier call msId, which can take be one of the following: - MSISDN: the phone number of the user - Alias: identifier usually linked to the WAP or mobile internet - idTech: a technical identifier, dedicated to mobile NFC services IdTech introduction For regulatory and confidentiality reasons, in some countries, the MSISDN may be transmitted by the Mobile Network Operators. Thus, it is recommended that, in the earlier steps of a mobile NFC service installation, the MNO will convert the MSISDN into a technical identifier named idTech to communicate with the Service Providers. The idTech shall be generated by the Mobile Network Operator respecting the following rules:

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

p52/102

It shall be a unique intra MNO identifier of variable length depending on the Mobile Network Operator, with a maximum length of 16 alphanumeric characters. - The idTech shall enable the Mobile Network Operator and the Service Provider to address the end users mobile handset or UICC via a mobile network access platform, for instance to send SMS PUSH BIP and SMS PUSH WAP. In France, the idTech identifier can be identical to the WAP ALIAS identifier. [Note] In France, due to legal restrictions, the MNO will enforce the use of idTech and diversify the idTech identifier using the end users MSISDN and either the Service Provider ID or the services serviceId idTech use When the idTech is used as the identifier between MNO and SP, only the getIdTech and the fullEligibilityCheck methods can be used with another identifier such as the MSISDN or the alias. In this case, when another identifier than the idTech is used in the other methods, the Unsupported identifier exception must be thrown by the MNO. 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, responses and notifications. The idTech is generated upon reception by the Mobile Network Operator of an eligibility request or the getIdTech request described in the next paragraphs. idTech life cycle The table below summarizes impacts of end user cases on idTech life cycle. End User Cases
Service activation Termination, deactivation mobile services UICC change Resuming the end user contract after it has been suspended Change of mobile handset Mobile handset lost or stolen Mobile services temporary suspension Terminate current mobile services contract in the event of the end user opening a new mobile services contract with the same MNO or another MNO (the end user may keep their MSISDN) MSISDN modification Former MNO suppresses old idTech. New MNO generates new idTech Suppresses old idTech Generates new idTech Suppresses old idTech. Receives new idTech No change No change

idTech Status (MNO)


Generates Suppresses

idTech Status (SP)


Receives Suppresses

Suppresses old idTech. Receives new idTech

Table 1: idTech life cycle 3.4.2 Service Identifiers: serviceId and serviceVersion Each mobile NFC service, as described in section 2.6.1, is identified by a service identifier serviceId. It is a unique value for a combination of a Service (of a given Service Provider) and a set of UICC applications (packages + instances), known that a given package can be shared between several serviceId. By default, the service identifier is attributed by the AFSCM.
AFSCM Interface Specification V2.1 February 2012 AFSCM Confidential & Proprietary p53/102

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. 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, avoiding the use of AID or other technical details. The serviceVersion in particular must be use cautiously: When requiring the MNO to install its mobile NFC service, the SP must provide the serviceVersion of the service to be installed. When requiring operations on an installed service, the SP must provide the correct serviceVersion of the service that is installed.

3.5

Control functions
There are several control functions, all synchronous, each one serving a different purpose: getUICCProfile: the MNO provides the SP details about the end users UICC getMobileHandsetProfile: the MNO provides the SP details about the end users handset isEligible : the MNO checks the end users eligibility to the service getIdTech: the MNO provides the SP with the end users idTech fullEligibilityCheck requires the MNO to perform all of the above controls in one single step, and to return the end users idTech 3.5.1 getUICCProfile

Use This function is to be used by the SP needing information on the end users UICC, for compatibility checking or key set diversification for instance. Conditions of use It may be called anytime and only depends on the SP knowing an end users subscription identifier. Description FUNCTION getUICCProfile SP MNO, synchronous Input data name Description Presence syncHeader Synchronous Message Header Mandatory Output data name Description Presence iccId UICC identifier; Unique value per UICC that can be used Mandatory in the SSD keys diversification process. 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.
AFSCM Interface Specification V2.1 February 2012 AFSCM Confidential & Proprietary p54/102

If the UICC is not NFC compliant, the MNO may throw an exception with the 402 code. 3.5.2 getMobileHandsetProfile

Use This function is to be used by the SP needing information on the end users handset, for compatibility checking for instance. Conditions of use It may be called anytime and only depends on the SP already knowing an end users subscription identifier. Description FUNCTION getMobileHandsetProfile SP MNO, 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 users handset Mandatory type: mobileHandsetId Resulting actions The Mobile Network Operator does not perform any eligibility check and only returns the required information. If the mobile handset is not NFC compliant, the MNO may throw an exception with the 403 code.

3.5.3

isEligible

Use This function is to be used by the SP needing information on the end users eligibility. Depending on the context, the Service Provider can use this function using the following end-user identifiers: - end users MSISDN: Subscription at Service Provider's local office or on web site (Process 4) for instance - end users mobile ALIAS: Subscription via a WAP session (Process 4) for instance - end users 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. It may be called anytime except in the following cases: - If an installation is already in progress for this service, an exception of type Installation in progress will be thrown; the Service Provider should then resume the installation. - If the service is already installed in this version, an exception of type Service already installed will be thrown. It only depends on the SP already knowing an end users subscription identifier. Description
AFSCM Interface Specification V2.1 February 2012 AFSCM Confidential & Proprietary p55/102

FUNCTION isEligible Input data name syncHeader Output data name eligible type: boolean

Description Synchronous Message Header Description True if the end user is eligible. If the end user is not eligible, an exception is thrown

SP MNO, 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: - Commercial (access to NFC services), - Technical (mobile handset and UICC NFC capable), - And, if supported by the MNO, available memory space on UICC. If the end user is eligible the Mobile Network Operator generates the idTech. If not, the MNO will throw an exception of type Incompatibility (see section 3.9.3 Response codes to asynchronous requests). Restrictions specific to version 2 In version 2 of this specification, the way the eligibility check is performed might differ from one MNO to another, particularly regarding the available memory space on the UICC. 3.5.4 getIdTech

Use This function is to be used by the SP needing to get an end users IdTech corresponding to another known identifier. Conditions of use It may be called anytime and only depends on the SP already knowing either the end users MSISDN or alias identifier. 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, synchronous Presence Mandatory Presence Mandatory

Resulting actions The Mobile Network Operator does not perform any eligibility check and only returns the required information. 3.5.5 fullEligibilityCheck

Use fullEligibilityCheck is a request cumulating the features of the more modular functions:
AFSCM Interface Specification V2.1 February 2012 AFSCM Confidential & Proprietary p56/102

getUICCProfile getMobileHandsetProfile isEligible getIdTech Depending on the context, the Service Provider can use this function using the following end-user identifiers: - end users MSISDN: Subscription at Service Provider's local office or on web site (Process 4) for instance - end users mobile ALIAS: Subscription via a WAP session (Process 4) for instance - end users 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. It may be called anytime except in the following cases: - If an installation is already in progress for this service, an exception of type Installation in progress will be thrown; the Service Provider should then resume the installation. - If the service is already installed in this version, an exception of type Service already installed will be thrown. It only depends on the SP already knowing an end users subscription identifier. Description FUNCTION fullEligibilityCheck SP MNO, 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, 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: - Commercial (access to NFC services), - Technical (mobile handset and UICC NFC capable), - And, if supported by the MNO, available memory space on UICC. If the end user is eligible the Mobile Network Operator generates the idTech. If not, the MNO will throw an exception of type Incompatibility (see section 3.9.3 Response codes to asynchronous requests). Restrictions specific to version 2
AFSCM Interface Specification V2.1 February 2012 AFSCM Confidential & Proprietary p57/102

In version 2 of this specification, the way the eligibility check is performed might differ from one MNO to another, particularly regarding the available memory space on the UICC.

3.6

Installation requests
3.6.1 createOrAllocateSsdReq and createOrAllocateSsdResp

Use This request is used by the Service Provider to request a SSD creation or a SSD assignation. This request is conditional; it is mandatory only: - if the Service Provider has not been allocated a SSD yet (whether the SSD needs to be created OTA or not) - or if the Service Provider needs to receive the SSD key set. Conditions of use The request for SSD creation is the first step of the installation process. When the idTech is used as the mobile subscription identifier, the Service Provider must have the idTech of the end user in order to send this request. When the MNO does not manage the SSD keyset, the createOrAllocateSsdResp does not contain any keys. A process is set up during the provisioning phase between the authorised parties for the SSD keys exchange (described in [R5] Guidelines for interconnection of Service Providers' and MNOs' Information Systems). Once the Service Provider has a SSD assigned, use of this request is not necessary anymore. In case the Service Provider already has a SSD assigned and calls again the createOrAllocateSsdReq request, the MNO returns 210 as a response code and may or may not send the SSD keys, depending on a separate agreement between the SP and the MNO. 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, asynchronous Presence Mandatory Optional (1) Presence Mandatory MNO SP, asynchronous Presence Mandatory

List of elements named ssdInfoof type ssdInfo

Mandatory Refer to section 3.9.3 Response codes to asynchronous requests for a list of possible error returned by this request and for error management. Conditional (3) A list (2) of elements of type ssdInfo SSD keys may be encrypted (on agreement between SP and MNO), key value length depends
p58/102

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

Output data name acknowledge

on the encryption. It is recommended that the keys be encrypted with AES, with a key length of 256 bits Description SP acknowledgment of the response

Presence Mandatory

1. Presence indicates that the SSD is to be created in a hierarchy as a sibling of the parentAid SSD. 2. The MNO may create more than one SSD: presence of additional SSD AID depends on agreement between SP and MNO 3. Mandatory if key set managed or loaded OTA by MNO and required by SP. KeyTable presence depends on an agreement between SP and MNO [Note] The TAR is composed of bytes 13, 14 and 15 of the AID. [Note] The algorithm to be used for KCV (key check value) depends on the card profile. The information will be exchanged between MNO and SP during the provisioning phase Resulting actions Upon reception of the createOrAllocateSsdReq request, 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, and assigns it to the service of the SP In its response, the MNO sends the AID of the SSD and, if necessary, the keyset of the SSD. The privilegies given to the SSD associated with the Service Provider are defined by the MNO at provisioning time. SSD keyset renewal In order to secure communications between SP Platforms and their NFC applications on the UICC, the sender (SP Platform) uses SSD SCP 80 and SCP 02 keysets to encrypt OTA commands. Thus, these keysets are considered to be sensitive data that only SPs should have access to. Initially (before SSD allocation), keysets could be managed by the MNO (for pre-created SSDs for instance). Therefore some SPs (i.e banking SPs) need to change those keys after NFC service installation. 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, Global Platform defines several mechanisms described in [R14] UICC configuration 1.0.1 and based on the support of GP 2.2 Amendment A. 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. All data exchanges are done on the interface between the SP platform and the UICC. For more details, please refer to [R14] UICC configuration 1.0.1. 3.6.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. The Service Provider prepares the Global Platform Card Content Management commands that are necessary and sends token requests for these CCM commands. 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.
AFSCM Interface Specification V2.1 February 2012 AFSCM Confidential & Proprietary p59/102

Conditions of use getTokens can only be used in Delegated Management mode. getTokens is used in the following context: UICC application installation (Process 5), 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, when the token key is not diversified for each card, 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. Should such need arise, the Service Provider must contact the MNO. Description FUNCTION getTokens Input data name syncHeader List of elements named ccmCommand of type ccmCommand SP MNO, 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. 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, updated by the MNO to comply with security rules (for instance, add "Card Image Number" or "Token identifier" in order to insure Token diversification).

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

p60/102

The APDU are also updated with a token. (3) 1. Several occurrence of this field enables the specification of several CCM commands for which a token is to be generated. If so, the CCM commands must be given in the order they are intended to be delivered/executed in the Secure Element. 2. Present if the APDU command is modified by the MNO. 3. The number of APDUs of the updated CCM commands is potentially higher than the number of APDU of the original ones, due to the inclusion of the token itself. Resulting actions If the given parameters of the tokens request are compatible with its internal policies, the Mobile Network Operator generates the tokens and returns them to the Service Provider. Otherwise, an exception is thrown with an error code. Upon reception of the token the Service Provider can establish an OTA connection to the UICC in order to send the GP command.

3.6.3

installReq and installResp

Use This request and associated response are restricted to the Simple SD management. installReq is used in the installation process (Process 5) to perform the different steps of the installation process, which are: - Application loading with installStep=LOAD, - Application installation with installStep=INSTALL, - Application activation with installStep=ACTIVATE (this step is mandatory in the installation process) - 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. The steps sequence shall be compliant with GP lifecycle state transition. Depending on the SP application and whether it is pre-loaded or pre-instantiated, the installation step sequence could be, for instance: - LOAD, INSTALL, ACTIVATE - INSTALL, ACTIVATE - LOAD, INSTALL, REGISTRY_UPDATE, ACTIVATE - REGISTRY_UPDATE, 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. The SP must already have a SSD assigned on this UICC (see createOrAllocateSsdReq and createOrAllocateSsdResp). The package will be loaded by the MNO in the SSD assigned for this service on this UICC.

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

p61/102

Since the package needs to be loaded OTA, it is mandatory to have the application certified package available on Mobile Network Operators platform before submitting requests for loading the package. The use of DAP is optional. In case DAP signature is used, i. The DAP signature can be the same for all the UICC (key for DAP not diversified in the UICC). In this case, it is possible to provision the DAP signature on the MNO platform together with all the other technical details, or the DAP signature can be sent in the installReq request. ii. In case the key for DAP is diversified for each UICC, the DAP signature must be calculated for each UICC. In this case the DAP signature can only be sent in the installReq request. 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. 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. The application will be installed by the MNO in the SSD assigned for this service on this UICC. 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 installation parameters must be provisioned in advance on the MNO platform together with the application package, and verified and validated by the MNO. Conditions of use: installReq with ACTIVATE STEP This step is mandatory. The SP must already have a SSD assigned on this UICC (see createOrAllocateSsdReq and createOrAllocateSsdResp), the package(s) of the application(s) must already be loaded on the UICC and the application must already be installed. The application instantiated in the SSD assigned for this service on this UICC will be activated by the MNO. With this response, the Mobile Network Operator confirms whether activation is performed or not. Conditions of use: installReq with REGISTRY_UPDATE STEP This step is optional. Once the application is installed on the UICC, the Service Provider may change the parameters of its application. Especially it may change the user interaction parameters (display message, application image, Url) or the contactless parameters. These parameters are detailed in [R13] Global Platform Card Specification 2.2, Amendment C. 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. This command can be used anytime, as part of the installation process or not (if the application is installed or activated) Description REQUEST installReq Input data name Description SP MNO, asynchronous Presence
p62/102

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

asyncHeader Message Header for Asynchronous Request List of elements named An ordered list of installInfo, to be executed sequentially. 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, responseCode) Description Transaction identifier (unique) An ordered list of (installStep, responseCode) tuples reporting the execution status related to an installation request.
Parameter installStep Type installStep Description defines an installation step the MNO has executed Refer to section 3.9.3 Response codes to asynchronous requests for a list of possible error returned by this request and for error management.

Mandatory Mandatory

Presence Mandatory MNO SP, asynchronous Presence Mandatory Mandatory

responseCode

responseCode

Output data name acknowledge

In case all steps requested could not be executed, the response shall contain the results of all executed steps up to the one that failed. Description SP acknowledgment of the response

Presence Mandatory

Resulting actions with LOAD STEP Upon reception of this request, the Mobile Network Operator: - Checks that a SSD is attributed to this Service Provider on this UICC. - Checks if the package is already loaded in the UICC in which case the MNO does not need to perform any OTA actions. When all the controls are OK, the Mobile Network Operator loads OTA the package (or packages if there are several packages in the service) in the UICC. Once the package is available on the end users UICC, the SP can proceed to the next step of the installation process: the application installation. Resulting actions with INSTALL STEP After the necessary verifications (package loaded, application not already installed ), 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).

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

p63/102

Once the application is installed on the end users UICC, the SP can proceed to the next step of the installation process: the personalisation or the activation of the application. Resulting actions with ACTIVATE STEP After the necessary verifications (SSD assigned, package loaded, application installed and not activated, ), the Mobile Network Operator sends the GlobalPlatform command for application (or applications if there are several applications in the service) activation. Once the application(s) is (are) activated: - Either personalisation has already been done by the SP, in case the application is fully operational - Else it has not, and the next step is to personalise the application Resulting actions with REGISTRY_UPDATE STEP After the necessary verifications, the Mobile Network Operator sends the GlobalPlatform command to the targeted application. 3.6.4 installMmiReq and installMmiResp

Use installMmiReq is used by the SP to ask the MNO to initiate the MMI installation. Conditions of use installMmiReq is used in Process 6, when the MNO is involved in the MMI installation: - In case 1, the Service Provider requests the MNO to initiate the MMI download. The Service Provider sends the request with mmiAction set to: Option i MMI with retries and the version of the MMI to be loaded. Option ii MMI only and the version of the MMI to be loaded The response is used to inform the Service Provider about the result of MMI download initiation. In case the service has several MMIs (not including the several versions of the same MMI), the MNO will provide an identifier for each MMI, and this mmiId shall be provided in the installMmiReq input. A call to the installMmiReq request only handles the installation of one MMI. Description REQUEST installMmiReq Input data name asyncHeader mmiId type: N mmiAction type: N(1) Description Message Header for Asynchronous Request Identifier of the MMI, mandatory in case there are several MMI for the service Action to be done by the MNO. Possible values are:
1 2 MMI only MMI with retries

SP MNO, asynchronous Presence Mandatory Conditional Mandatory

Output data name Description acknowledgeWithValidityPeriod MNO acknowledgment of the request RESPONSE installMmiResp

Presence Mandatory MNO SP, asynchronous


p64/102

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

Input data name requestId type: requestId responseCode type: responseCode

Description Transaction identifier (unique) Refer to section 3.9.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. The URI indicated in the SMS must have been provided by the SP to the MNO and may depend on the mobile handset model. If several URI have been provided by the SP, the MNO will use the TAC of the mobile handset of the end user to identify the corresponding URI. For more information on the compatibility information provisioning, see [R5]Guidelines for interconnection of Service Providers' and MNOs' Information Systems. Once he is aware of the result of the installation process, the Service Provider must notify the MNO using notifStateChangeToMno. 3.6.5 bindMmiReq and bindMmiResp

Use Using bindMmiReq, the SP asks the MNO to bind the MMI of the mobile NFC service to the UICC application. Conditions of use bindMmiReq can only be used once the UICC application are installed and active. It should be used, when possible, before MMI installation. Description REQUEST bindMmiReq SP MNO, 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, asynchronous Input data name Description Presence Mandatory requestId Transaction identifier (unique) type: requestId responseCode type: responseCode Refer to section 3.9.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.1 February 2012 AFSCM Confidential & Proprietary

Resulting actions The MNO performs the binding. In the case of ACF files, the MNO loads or updates the ACF and always loads the more recent certificate. 3.6.6 suppressReq and suppressResp

Use This request is used by the SP to ask the MNO to - Delete all UICC content related to the target service (serviceId and serviceVersion) including the application instance, the application package and the associated bindings - Delete the Service Providers 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, it is recommended not to delete the SSD, and therefore not to use the DELETE_SSD action. In case of Mobile NFC service termination (Process 20) In Simple SD mode, the Mobile Network Operator is responsible for deleting the application instance, package and the SSD In Delegated Management mode, the Service Provider is responsible for the deletion of the application(s) and package(s) on the UICC, but will use suppressReq with the DELETE_SSD action to ask the MNO to delete the SSD; 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, asynchronous Presence Mandatory

Mandatory

deleteReason type: N(1)

Indicates the reason of the removal. 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.9.3 Response codes to asynchronous requests for a list of possible error returned by this request and for error

Optional

Presence Mandatory MNO SP, asynchronous Presence Mandatory

Mandatory
p66/102

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

management Output data name acknowledge Description SP acknowledgment of the response Presence Mandatory

Resulting actions Upon reception of this request, the Mobile Network Operator makes several controls in order to analyse what can and must be suppressed or not according to the following rules: - Do not delete a package if there is still another instance linked to this package, - Do not deleted a SSD if it is not empty - Do not delete a package that cannot be OTA loaded - Delete MMI and UICC application bindings related to the suppressed mobile NFC service (if such bindings are used). Once the service has been deleted, the Service Provider can delete the information related to the service of this end user from his information system.

3.7

Notifications
3.7.1 notifStateChangeToMno

Use The Service Provider uses this notification to inform the MNO either about the MMI installation status, about command execution in Delegated Management mode, or about the lock/unlock of the UICC application. Conditions of use The notifStateChangeToMno notification is used in the following contexts: - In Delegated Management mode, to send the token receipts of OTA commands to the MNO (Process 5, Process 5 Update and Process 20). 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, application installation and activation o reason is Token used (when the token has been used, and confirmationData and receipt must be filled) or Token not used (when, for any reason, 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, confirmationData and receipt must be present - In Delegated Management mode, to notify the MNO that a token has not been / could not be used o Depending on the context, step can be either of the values already listed above o reason is Token not used (when, for any reason, the SP has / could not use the token: confirmationData and receipt should not be present)
AFSCM Interface Specification V2.1 February 2012 AFSCM Confidential & Proprietary p67/102

status is Already performed when the token has been used but the action has not been performed because it was already done, Or Failed in other cases. To notify the MNO about the installation status of the MMI (Process 6): in the installation process, the MNO must be notified of the MMI installation status after, whether the installation/update was successful or not, and even when no installation was necessary because the MMI was already installed. or SP request o Depending on the context, 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, the status is either OK, Failed or Already performed o aid, confirmationData and receipt must be present In Process 5, to notify to the MNO the status of the personalisation applied to the UICC application. In this case, 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, depending on the type of lock, and whether it is applied or removed, 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, 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 users 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, the status is either OK, 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, and status is OK

Description NOTIFICATION notifStateChangeToMno Input data name Description syncHeader Synchronous Message Header
AFSCM Interface Specification V2.1 February 2012 AFSCM Confidential & Proprietary

SP MNO, synchronous Presence Mandatory


p68/102

List of elements named actionStatus of type actionStatus

Output data name acknowledge

Mandatory A list of actionStatus elements, enabling the SP to notifiy several messages to the MNO. 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. In case of a notification dedicated to Delegated Management, if the SP does not send the receipt associated with the execution of the command(s), the MNO may audit the UICC. 3.7.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. It only notifies of the users call, not the loss or theft in itself. Conditions of use This notification can only be used in Process 12 Lost or stolen mobile equipment, end user contacts Service Provider. Description NOTIFICATION notifCallEndUserToMno SP MNO, synchronous Input data name Description Presence syncHeader Synchronous Message Header Mandatory reason Operation justification. 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. 3.7.3 Use
AFSCM Interface Specification V2.1 February 2012 AFSCM Confidential & Proprietary p69/102

notifNewDevice

The Mobile Network Operator sends this notification to inform the Service Provider in case the end user gets new devices: UICC, mobile, or both new UICC and mobile. [Note] The reception of this notification for a new UICC implicitely means that the previous UICC is deactivated. Conditions of use This notification is used in the following processes: - Process 8 Change UICC deviceType set to 01 - Process 10 Change Mobile handset deviceType set to 02 - 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. type: deviceType Output data name acknowledge Description SP acknowledgment of the notification MNO SP, synchronous Presence Mandatory Mandatory Presence Mandatory

Resulting actions Upon reception of this notification, the Service Provider launches the appropriate action: - Installation of application if new UICC Process 5, - Installation of the MMI if new mobile Process 6, - Entire new installation if new UICC + Mobile Process 5 and Process 6. 3.7.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. This notification is used for instance when the user changes his MSISDN. Conditions of use This notification can be sent anytime. The msId field of the syncHeader will be an idTech and its value will be that of the former idTech of the end user. 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, synchronous Presence Mandatory Mandatory Presence
p70/102

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

acknowledge

SP acknowledgment of the notification

Mandatory

Resulting actions The Service Provider updates his information system with the new identifier for this end user. No other action is necessary. 3.7.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. It only notifies of the users call, not the loss or theft in itself. Conditions of use This notification can only be used in Process 11 Lost or stolen mobile equipment, end user contacts Mobile Network Operator. Description NOTIFICATION notifCallEndUserToSp MNO SP, synchronous Input data name Description Presence syncHeader Message Header for synchronous request Mandatory reason Operation justification. 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 MNOs line state. 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.7.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. Conditions of use This notification is used in several contexts: - After a loss or theft, when the MNO tries to lock the UICC applications OTA and restricts or suspends the line (Process 11); possible values for the status are Line RESTRICTED, Line SUSPENDED or Application LOCKED; possible values for the associated reason are mobile loss or mobile theft.
AFSCM Interface Specification V2.1 February 2012 AFSCM Confidential & Proprietary p71/102

Once the end user recovers his mobile phone, the Mobile Network Operator restores the end users mobile connection (Process 13); possible values for the status are Line ACTIVATED and Application UNLOCKED; the associated reason is mobile recovery. When the end user gets a new mobile equipment after a loss or theft, the MNO restores the end users mobile connection (Process 14); status value is Line ACTIVATED; the associated reason is line reactivation. When the end user wants to temporary suspend the mobile service (Process 15); the value for the status will be Line SUSPENDED or Line ACTIVATED; the associated reason is end user request. When the MNO informs the SP that the owner of the contract has changed (Process 16); the value for the status will be Contract owner CHANGED; possible values for the associated reason are same end user or changed end user. No value for the reason will mean the MNO was not able to provide this information. When the end user wants to terminate mobile subscription or NFC option (Process 18); possible values for the status are Line TERMINATED and NFC option TERMINATED; the associated reason is end user request. When the Mobile Network Operator terminates the mobile service (Process 19); possible values for the status are Line RESTRICTED, Line SUSPENDED, Line ACTIVATED or Line TERMINATED; the associated reason is line termination.

Description NOTIFICATION notifStateChangeToSp MNO SP, 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. 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. In case the line is suspended or terminated, but the MNO did not manage to lock the application, the Service Provider applies an IS lock on the service.

3.8

Script sending
3.8.1 sendScriptsReq and sendScriptsResp

Use During the life cycle of a mobile NFC service, the Service Provider may need to communicate with its UICC application or SSD, for personalization of the service or application data update for instance. In these cases, the Service Provider can use the sendScriptsReq request: data preparation is done by the Service Provider
AFSCM Interface Specification V2.1 February 2012 AFSCM Confidential & Proprietary p72/102

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, and is subject to agreement with the MNO as to the authorization and conditions of use. Description REQUEST sendScriptsReq SP MNO, asynchronous Input data name Description Presence asyncHeader Message Header for Asynchronous Request Mandatory List of elements named script A list of script elements. Mandatory of type script Each script element represents a list of APDUs to be sent and executed by a targeted application. 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). Should it exceed the maximum buffer size, the MNO will throw an exception and no APDU will be sent. Output data name Description Presence acknowledgeWithValidityPeriod MNO acknowledgment of the request Mandatory RESPONSE sendScriptsResp MNO SP, asynchronous Input data name Description Presence requested Mandatory Transaction identifier (unique) type: requestId responseCode Refer to section 3.9.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. responseScript of type Each responseScript element represents responseScript the response of the UICC application to the corresponding executed script. There will be a responseScript element for each script element of the sendScriptsReq request. Each responseScript element contains a compact response to the executed script: The index of the last APDU executed, 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, then the Failed APDU Index provides the index of the failed APDU in the Command APDU list. Output data name Description Presence
AFSCM Interface Specification V2.1 February 2012 AFSCM Confidential & Proprietary p73/102

Acknowledge

SP acknowledgment of the response

Mandatory

Resulting actions The MNO will choose the appropriate bearer to communicate the APDUs to the UICC.

3.9

Data dictionary
3.9.1 Data types

The following basic data types are used in the interface specification:
Basic data types Description An integer, 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, 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.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), 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

10 UICC application installation and activation 11 UICC package loading, 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, enumeration Operation justification. 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, although this is part of no described process.

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). Several apdu or extendedApdu elements can be used if the commands need to be split. APDUs composing the ccmCommand SHALL be of the same type: for instance, all APDUs are install [for install] commands.

deviceType

N(1) representing different types of devices. 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, AID of the mandatory package that has been loaded or deleted, or of the UICC application that has been installed, personnalized, activated or deleted confirmationData HEX(var) Confirmation Data is a LV structure conditional defined in GP 2.2.1 Table 11.14 (composed of Confirmation counter, SD Unique Data, Token identifier, Token Data digest)
p75/102

dmActionStatus

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

receipt conditional

HEX(var)

This value is not present if, and only if, the receipt(s) was (were) lost by the SP. This case shall be exceptional Token receipt This value is not present if, and only if, the receipt(s) was (were) lost by the SP. 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, shall not be swapped and, if needed, will be right-padded (hence the last alpha-numeric character, depending on the choice of the MNO). 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. It extends the mobileHandsetId type, 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 installTableof type installTable optional Description defines an installation step the MNO must execute A list of installTable elements allowing to specify, for this step, the installation parameters and DAP signature for each application or package AID

installStep

installTable

N(1) enumeration, 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, 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.1 February 2012 AFSCM Confidential & Proprietary

platform Note that: 1. installParameterIndex: Used if several sets of parameters are available on the MNO platform

key

A structure representing a 3DES key, 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 MNOs line state. 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, 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.212 mandatory Norm.

Type N(3)

N (var 2 or 3)

mobileHandsetId An identifier for a mobile handset. It contains the following elements, 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. It is composed of the initial eight-digit portion of the 15-digit IMEI code used to uniquely identify wireless devices. The format of the TAC is AABBBBBB where: The first two digits are the Reporting Body Identifier The next 6 digits identify the manufacturer, brand and model It is extended by types tac and imei
AFSCM Interface Specification V2.1 February 2012 AFSCM Confidential & Proprietary p77/102

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, e.g. the end user. N(3-15), 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), formatted as the concatenation of the following attributes, separated by colons: Parameter Type serviceId N(5) Timestamp in milliseconds N(19) Additional diversifier N(2) N(3), which can have the values defined in section 3.9.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, 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.1 February 2012 AFSCM Confidential & Proprietary

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, if not the ISD One element per key transmitted.

status

N(1) representing a status. 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. It heritates the tac element from the mobileHandsetId type. char(16); Reference to a smart card manufacturer and operating system. A version is a sequence of the following elements: Parameter Type Description major N(3) The major version of the service. mandatory minor N(3) The minor version of the service. mandatory revision N(3) The revision version of the service. mandatory 35713603 for the Samsung Player One Cityzi

tac

uiccProfile

version

3.9.2 Response and exception types Response codes and exceptions are grouped in categories. The errors contained in a same category should be handled in the same way. 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, particularly regarding his retry policy
Code type K W S D Category OK, 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.
p79/102

Description and retry policy

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

The Service Provider must fix the parameters and the request can be retried. C Connection error The MNO made several retries before returning this type of response code. Thus the Service Provider should preferably contact the end user and ensure that his mobile equipment is connected before sending the request again. F Fatal error This is a definitive error. The Service Provider should not retry and should inform the end user. The Service Provider should then contact the MNO through After Sales services procedures. I Ineligibility This is a definitive error. The Service Provider should not retry and should inform the end user he cannot benefit from NFC offer.

3.9.3 Response codes to asynchronous requests The response codes are used in the asynchronous responses. The table below presents the relationship between each response code and the applicable response.
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 SP can proceed to the next step Application already installed: no action was necessary, 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.1 February 2012 AFSCM Confidential & Proprietary

p80/102

suppressResp X X

Description CODE_TYPE

sendScriptsResp

installMmiResp

installResp

createOrAllocateSsdResp

responseCode

bindMmiResp

223 224 225 226

W S S S

Application or package not found on the UICC: no action was necessary, the SP can proceed to the next step Package absent on the UICC: for instance, occurs if the SP asks for application installation before asking for package loading Application not installed: for instance, 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 server throws a synchronous exception (faultMsg) with an appropriate errorType. The table below lists all the possible values for errorType and the request for which they are applicable.

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)

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

003

AFSCM Interface Specification V2.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

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

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(1) X X(1) X X(1) X X

224

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

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

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

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

Figure 42 Sequence diagram of Sub-process A MNO eligibility Description Depending on whether he needs to perform a compatibility check next, the Service Provider can also use the fullEligibilityCheck function instead of isEligible, since it is particularly appropriate to a first subscription. 4.2.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, the Service Provider does not need to call the getUICCProfile and getMobileHandsetProfile functions. 4.2.3 Sub-process C SP scoring This process does not require any exchange between the Mobile Network Operator and the Service Provider.

4.3

Service discovery and inquiry processes


4.3.1 Process 1 Online service discovery This process does not require any exchange between the Mobile Network Operator and the Service Provider. 4.3.2 Process 2 Inquiry to the Service Provider This process does not require any exchange between the Mobile Network Operator and the Service Provider. 4.3.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.

4.4

Subscription processes
4.4.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, Sub-process B SP compatibility and Sub-process C SP scoring.

4.5

Installation processes
4.5.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.

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

p85/102

The installation in itself can be performed in the two modes, simple SD mode or delegated management mode; but the first step, SSD creation or assignation, is the same, regardless of the mode that is used. SSD creation/assignation If the Service Provider has no SSD assigned on the UICC of the end user, the first step of the UICC application installation process is the SSD creation/assignation. The SP must use the createOrAllocateSsdReq request to have a SSD assigned. 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, or the MNO sends a key set in the createOrAllocateSsdResp response Once the SSD is assigned, the Service Provider may send GP commands OTA to replace the SSD key set with his own key set. 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, and after.
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, installation, registry update

installReq (among LOAD, INSTALL, 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 - Sequence diagram of Process 5 Installation of UICC application in Simple SD mode (personalization then activation)

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

p86/102

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, application installation and activation

installReq (steps among LOAD, INSTALL, REGISTRY_UPDATE, 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, the Service Provider uses the installReq request to ask the MNO to perform the various installation steps. Depending on the state of the UICC, as described in section 2.6.3 UICC and UICC application architecture, the SP thus asks the MNO to perform the loading, creation and extradition, registry update and activation. The Service Provider is fully responsible for the personalization step of the UICC application and must notify the MNO using the notifStateChangeToMno notification. Depending on the number of steps to perform and the sequencing of the activation and personalization steps, the SP can decide to use the single or grouped commands of the installReq request. Sequence diagram in delegated management mode

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

p87/102

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, 2/ send all commands, 3/ notify with all receipts getTokens Tokens calculation Application Loading Application Installation and Extradition Registry update Application Personalization and Activation notifStateChangeToMno (Token receipts, UICC application personalisation)

OR
For each command: 1/ request a token, 2/ send command, 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, UICC application personalisation)

OR
1/ request all tokens ; Then, for each command: 2/ send command 3/ notify with receipt Not illustrated

ORFor each command:


1/ request a token, 2/ send command and finally notify all with receipts
Not illustrated

Figure 46 - Sequence diagram of Process 5 Installation of UICC application in Delegated Management mode Using the Delegated Management mode In the Delegated Management mode, the SP is authorised by the MNO to perform all the UICC application installation steps. To be authorized, the SP uses the getTokens request to request authorization tokens for each step to perform among (depending on the state of the UICC, as described in section 2.6.3 UICC and UICC application architecture) package loading, application installation and application activation. Once he has the necessary tokens, the Service Provider sends OTA the GlobalPlatform commands to perform these steps. Each action performed by the SP must be notified to the MNO using the notifStateChangeToMno notification, either right after the action, or when the installation is complete.

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

p88/102

4.5.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
Service Provider Mobile Operator UICC

Sub-process B SP compatibility

Suppress previous UICC application

suppressReq (instance & package, old serviceVersion) Delete application instance and package if possible suppressResp Sub-process A MNO eligiblity

Example: installation using grouped commands


installReq (among LOAD, INSTALL, REGISTRY_UPDATE, ACTIVATE, new serviceVersion)

Package loading, 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, and step by step requests can be used instead of grouped commands

Figure 47 - 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, 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, application installation, registry update, 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, UICC application personalisation)


Only one option of token, command and notification sequence is presented; see sequence diagram of process 5 for more options

Figure 48 - 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 users mobile equipment is not compatible with the new version of the UICC application.
AFSCM Interface Specification V2.1 February 2012 AFSCM Confidential & Proprietary p89/102

In simple SD mode, 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.5.1 Process 5 Mobile NFC UICC application installation). Using the Sub-process A MNO eligibility after the former service deletion, the SP can ensure that there is enough memory space for the new UICC application. Using the Delegated Management mode The SP starts this process with the Sub-process B SP compatibility as in simple SD mode. In delegated management mode, the SP uses the getTokens request to be authorized, and sends OTA the GlobalPlatform commands in order to delete the former UICC application instance and package and install the new ones. Then, the SP uses the notifStateChangeToMno notification to inform the MNO with the token receipt. Using the Sub-process A MNO eligibility after the former service deletion, the SP can ensure that there is enough memory space for the new UICC application. 4.5.3 Process 6 Service Provider MMI installation / Update This process is divided in 4 cases: - Case 1: Upon the SPs request, the MNO launches the MMI installation or update. 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 2: the SP launches the MMI installation or update. - Case 3: the MMI installation is done through an application store In cases 1 and 2, the servers hosting the MMI are under the Service Providers responsibility. In case 3, they are under the application store providers responsibility. Case 1 option i:

Figure 49 - 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. In this case, the MNO manages the entire installation and informs the SP once the MMI is actually loaded in the mobile handset using installMmiResp. In case of connection interruption during the MMI loading, the MNO manages the retries. Case 1 option ii

Figure 50 - Sequence diagram of Process 6 MMI installation launched by MNO


AFSCM Interface Specification V2.1 February 2012 AFSCM Confidential & Proprietary p90/102

The SP uses the installMmiReq request to ask the MNO to launch the MMI installation, and the MNO sends the installMmiResp response once the WAP push SMS is sent to the mobile handset of the end user. In case of connection interruption during the MMI loading, the SP manages the retries. Once the SP is notified that the MMI is installed on the mobile handset, he informs the MNO using the notifStateChangeToMno notification. Case 2

Figure 51 - Sequence diagram of Process 6 MMI Installation launched by Service Provider In case 2, the SP takes care of the MMI installation and informs the MNO of the result of the installation using the notifStateChangeToMno notification. Case 3

Figure 52 - Sequence diagram of Process 6 End user installs the MMI from an application store In case 3, the SP must use the notifStateChangeToMno notification to inform the MNO of the MMI installation or update, using the statuses MMI installed or MMI updated. Requirement on the Service Provider Information System The MMI is specific for each mobile handset. Therefore the Service Provider must manage a database with all the MMIs for each available NFC mobile handset. During the MMI installation process in cases 1 and 2, 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. MMI update These processes apply for the MMI installation and the MMI update as well. Critical Update
Service Provider Mobile Operator UICC Mobile handset

Lock UICC application notifStateChangeToMno (locked status, reason=MMI update) MMI Installation, Case 1 or Case 2 Unlock UICC application notifStateChangeToMno (unlocked status, reason=MMI update)

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

p91/102

Figure 53 - 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 may lock the service until the MMI update is operative. The Service Provider must then keep the MNO informed using the notifStateChangeToMno notification. 4.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, the SP must use the bindMmiReq request. It should then be used: - during the installation process, always after Process 5 Mobile NFC UICC application installation - during the update process, always after Process 5 Update Mobile NFC UICC application update - during the MMI update process, for instance if the new MMI is signed with a new certificate that requires an update of the bindings.

4.6

Life cycle processes


4.6.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 - 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. The Service Provider will then have to go through the installation steps of the UICC application, and optionally of the MMI application if needed.

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

p92/102

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 - Sequence diagram of Process 9 Change mobile phone number Description When the Mobile Network Operator changes the end users mobile phone number, he generates a new idTech and notifies the SP using notifChangeMsId. The Service Provider has to change the idTech for this end user in his information system. The new mobile phone number may or may not be provided by the MNO, depending on the country. In France, the MNOs are not allowed to provide the new MSISDN. 4.6.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 - Sequence diagram of Process 10 Change mobile handset Description When he detects that the end user has changed his mobile handset, the MNO sends a notifNewDevice notification to the SP. The Service Provider will then have to go through the steps of the MMI application installation process. 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. 4.6.4 Process 11 Lost or stolen mobile equipment, 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 - Sequence diagram of Process 11 Lost or stolen mobile equipment, end user contacts MNO Description When an end user reports a lost or stolen mobile handset, the MNO simultaneously:
AFSCM Interface Specification V2.1 February 2012 AFSCM Confidential & Proprietary p93/102

informs the SP of the loss or theft using the notifCallEndUserToSp notification, attempts to lock the service before line suspension, after which he informs the SP about the new status of the application and the line using the notifStateChangeToSp notification, If the UICC application is still unlocked after the MNO actions, the SP applies an IS lock on the mobile NFC service. 4.6.5 Process 12 Lost or stolen mobile equipment, 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 - Sequence diagram of Process 12 Lost or stolen mobile equipment, end user contacts SP Description When he receives a call for lost or stolen mobile equipment, the SP informs the MNO of the call, using the notifCallEndUserToMno notification. The Service Provider then attempts to lock OTA the service and, in case of failure, applies an IS lock on the service; all locks are communicated to the MNO using the notifStateChangeToMno notification. 4.6.6 Process 13 Recover mobile equipment after a loss

Sequence diagram

Figure 60 - 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. Then, depending on whether the mobile NFC service was permanently locked or simply locked: - If the service was permanently locked, the Service Provider deletes and reinstall the UICC application, but not the MMI, - If the service was simply locked OTA by the SP, he unlocks it and informs MNO using the notifStateChangeToMno notification.

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

p94/102

4.6.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 users line

UICC

Figure 61 - 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, the MNO reactivates the end users line. Thus, 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. 4.6.8 Process 15 End User requests temporary mobile service suspension

Sequence diagram
Service Provider Mobile Operator
At suspension date agreed with end user, suspends end users 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, restores end users line

Figure 62 - Sequence diagram of process 15 Suspension of mobile service upon end users request Description The MNO uses the notifStateChangeToSp notification to inform the SP of the line suspension and thenn, later on, of its re-activation. The SP uses the notifStateChangeToMno notification to inform the MNO of the lock applied and, later on, released. 4.6.9 Process 16 - Change in contract ownership

Sequence diagram

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

p95/102

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 - 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. This process can be implemented as a termination. If the SP wishes to implement this process, the main impacts are in his Information System. 4.6.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.

4.7

Termination processes
4.7.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 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. When the transfer of entitlements is done, the Service Provider applies an IS lock on the service and informs the MNO using the notifStateChangeToMno notification. 4.7.2 Process 19 Mobile service termination by Mobile Network Operator

Sequence diagram

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

p96/102

Service Provider

Mobile Operator

UICC

notifStateChangeToSp (Line suspended or line restricted) notifStateChangeToSp (Line activated)

At suspension date, suspends or restricts end users line

Restore end users 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, permanently stops end users line If end user does not settle the situation

Figure 65 - Sequence diagram of Process 19 Mobile service termination by MNO Description The MNO uses the notifStateChangeToSp notification to inform the SP first, of the suspension or restriction of the line and then, of its restoration or termination, depending on the status of the dispute process. When the transfer of entitlements is done, the Service Provider applies an IS lock on the service and informs the MNO using the notifStateChangeToMno notification. 4.7.3 Process 20 Mobile NFC service termination

In Simple SD mode
Service Provider
suppressReq (ID_SERV) Delete application instance, SSD (if required), bindings (if relevant) and package (if possible) suppressResp

Mobile Operator

UICC

Figure 66 - Sequence diagram of Process 20 Mobile NFC service termination in Simple SD mode In simple SD mode, the SP uses the suppressReq request to ask the deletion of the service to the MNO who deletes the UICC application instance, the package (if there are no remaining instance linked to it) and the SSD if required. The MNO will also remove the bindings if present. 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 - Sequence diagram of Process 20 Mobile NFC service termination in DM mode In delegated management mode, the SP uses the getTokens request to be authorized, and sends OTA the GlobalPlatform commands in order to delete the UICC application instance and package.

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

p97/102

Then, the SP uses the notifStateChangeToMno notification to inform the MNO with the token receipt. Finally, the Service Provider uses the suppressReq request to ask the MNO to delete the SSD.

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

p98/102

WEB SERVICE IMPLEMENTATION


The implementation of this section by Service Providers is mandatory.

5.1

Protocol
The requests, responses and notifications are exchanged using web services with XML on HTTP. The AFSCM provides, upon request, WSDL description files containing all requests, responses and notifications described in section 3 Interface Specification of this document.

5.2

Interface
The Service Provider and the Mobile Network Operator need to establish a point to point VPN connection. A VPN is established between each MNO and Service Provider or his TSM. This process is detailed in document [R5] Guidelines for interconnection of Service Providers' and MNOs' Information Systems.

5.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. It is therefore not included in the WSDL description files. When the sending party of a call receives anything but a HTTP 200 code (including a connection timeout), the receiving party is declared unavailable: - The sending party must then use the HEART_BEAT query to check on the receiving partys server status - The HEART_BEAT should be sent several times, using the retry management mechanisms detailed in section 5.4 Protocol retry management - 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, the sending party may release the requests that were kept on hold

5.4

Protocol retry management


Each party must be able to reissue all the requests for which it did not receive an acknowledgment. The implementation of the retry mechanism must take into account: - A limitation to N retry cycles. After that limit, the absence of an answer can be considered as an incident and the technical team of the receiving party must be alerted. - A progressive increment of time between two cycles. In case of a connection disruption betweens platforms or in case a party does not send an acknowledgment, the other party uses the HEART_BEAT query as described in section 5.3 HEART_BEAT. The following chart illustrates such a retry management between the sending party (the sender) and the receiving party (the receiver):

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

p99/102

The sender calls a function of the receiver s web service

Can be a synchronous response, an acknowledge or an exception

The sender processes the answer

The receivers 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 receivers 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, N is the number of retry cycles, 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).

5.5

Load control
The Service Provider should apply flow control mechanisms in order to avoid overload situations. Two load limitation criteria are here defined, related to: 1. Instantaneous load: Limitation of number of simultaneous requests to the MNO platform (number of requests per second is limited). This is a server based control and in case of overload, HTTP error responses will be received as an answer to the SP requests. Instantaneous load control will be performed by the MNO. 2. 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). Global load control may be performed by the MNO. In case of overload, a quota overcome exception will be thrown, and the Service Provider will have to re-issue the command. When implementing load control, the Service Provider must control the number of simultaneous and ongoing requests and must, in case of an overload exception, stop sending new requests until the situation is resolved. The MNO will apply flow control mechanisms on outgoing notifications in order to avoid overload situations on the Service Provider server. The values for the maximum acceptable instantaneous load and global load are to be exchanged during the provisioning phase between each MNO and Service Provider.

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

p100/102

5.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, using PKI through X.509 certificates or Kerberos with X.509 certificates.

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

p101/102

Appendix 1

XSD AND WSDL FILES

The AFSCM provides the WSDL for the requests, responses and notifications exchanged on the SP/MNO interface. The files are provided in electronic version upon request to the AFSCM and are listed below: Types definitions: - afscmTypes.xsd: schema for all basic and complex types - afscmMsg.xsd: schema for all messages definitions Web services exposed by the Mobile Operators: - lifecycleNotifications.wsdl: notifications definitions - requestMno.wsdl: requests definitions Web services exposed by the Service Providers: - spInterface.wsdl: notifications and responses definitions

END OF DOCUMENT

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

p102/102