EU Roaming regulation III
Interface & Protocol
Detailed Technical specifications
Version 1.0
Last Update 24/07/2013
Document History
History
V 0.0
29/01/2013: Initial version with “empty” chapters
V 0.1
10/03/2013: 1st draft version with CR already discussed (but not final)
V 0.2
19/04/2013: 2nd draft including all CR to date
V 0.2.1
19/04/2013: Adding ‘Telefonica CR for Diameter (IF1)’ and Annex for homerouting
V 0.3
21/05/2013: integration of adjusted sections (IF1, IF2, IF3,IF4 and IF5). The section will be
subject to additional adjustement as agreed to F2F Meeting on May 13-14
V 0.4
18/06/2013: integration of working assumptions, revised IF1 and IF3.
V 0.5
11/07/2013: integration of comments received from Christian (E+), Normunds (TSG), Ignacio
(TEF), Fredrik (Tele2) and David (RW).
17/07/2013: includes complete document review adaptation (David)
Includes editorial (font, alignment, etc) adaptations.
22/07/2013: includes adjustments for short codes, CAMEL operation, LBO scope
V 1.0
27/07/2013: Agreement on all latest changes
Minor change on SMS ECUR flow: added Used Service Unit AVP in Termination Request
page 1/96
Summary
REFERENCES .................................................................................................................. 6
DEFINITIONS.................................................................................................................... 7
ABBREVIATIONS ...............................................................................................................10
1
SCOPE ............................................................................................................................................ 11
1.1 DOCUMENT STRUCTURE ............................................................................................. 11
1.2 WORKING ASSUMPTIONS ............................................................................................13
1.2.1
GENERIC REQUIREMENTS ........................................................................................13
1.2.2
SINGLE IMSI IMPLEMENTATION..................................................................................14
1.2.3
LBO IMPLEMENTATION ...........................................................................................17
2
INTERFACE DEFINITION FOR SINGLE IMSI ............................................................................... 18
2.1 ARP – DSP CONNECTIVITY........................................................................................18
2.1.1
SIGTRAN .........................................................................................................18
2.2 INTERFACE OVERVIEW .............................................................................................. 24
2.2.1
GENERIC RULES FOR INTERFACE DEFINITION ................................................................ 25
2.2.2 PRELIMINARY NOTE.............................................................................................. 25
2.3 SI-IF1 : VOICE CONTROL ......................................................................................... 26
2.3.1
DESCRIPTION ..................................................................................................... 26
2.3.2 DETAILED PROCEDURES FOR MO CALLS .................................................................... 26
2.3.3 DETAILED PROCEDURES FOR MT CALLS ..................................................................... 30
2.3.4 INTERFACE PRIMITIVES .......................................................................................... 33
2.3.5 PARAMETERS, DEFINITIONS AND USE......................................................................... 33
2.3.6 ERROR HANDLING................................................................................................ 33
2.4 SI-IF2 : SMS CONTROL ......................................................................................... 35
2.4.1
CONTEXT.......................................................................................................... 35
2.4.2 DESCRIPTION ..................................................................................................... 36
2.4.3 CAMEL FOR SMS CONTROL.................................................................................. 37
2.4.4 DIAMETER ...................................................................................................... 40
2.4.5 DETAILED PROCEDURES AT DSP ............................................................................. 42
2.4.6 DETAILED PROCEDURES AT ARP ............................................................................. 43
2.4.7 INTERFACE PRIMITIVES .......................................................................................... 43
2.4.8 PARAMETERS DEFINITIONS AND USE.......................................................................... 45
2.4.9 ERROR HANDLING ............................................................................................... 47
2.4.10
LIMITATIONS ................................................................................................... 47
2.4.11 SPECIAL USE CASE: SHORT CODE ........................................................................... 47
2.4.12
SUMMARY TABLE ............................................................................................. 48
2.5 SI-IF3 : DATA CONTROL ......................................................................................... 49
2.5.1
ARCHITECTURE, DESCRIPTION AND DEFINITIONS ............................................................ 49
2.5.2 DEFINITIONS .......................................................................................................51
2.5.3 DETAILED PROCEDURES AT DSP ..............................................................................51
2.5.4 INTERFACE PRIMITIVES .......................................................................................... 52
2.5.5 PARAMETERS DEFINITIONS AND USE.......................................................................... 66
2.5.6 ERROR HANDLING ............................................................................................... 66
2.5.7 SUMMARY TABLE ................................................................................................. 67
page 2/96
2.6 SI-IF4 : MOBILITY CONTROL ..................................................................................... 68
2.6.1
DESCRIPTION ..................................................................................................... 68
2.6.2 DETAILED PROCEDURES AT DSP ............................................................................. 68
2.6.3 DETAILED PROCEDURES AT ARP ............................................................................. 68
2.6.4 INTERFACE PRIMITIVES .......................................................................................... 68
2.6.5 PARAMETERS DEFINITIONS AND USE.......................................................................... 69
2.7 SI-IF5 : USSD CONTROL ........................................................................................ 75
2.7.1
DESCRIPTION ..................................................................................................... 75
2.7.2 DETAILED PROCEDURES AT DSP ............................................................................. 76
2.7.3 DETAILED PROCEDURES AT ARP ............................................................................. 77
2.7.4 INTERFACE PRIMITIVES .......................................................................................... 77
2.7.5 PARAMETERS DEFINITIONS AND USE.......................................................................... 78
2.7.6 ERROR HANDLING ............................................................................................... 79
2.8 SI-IF9 : SMS WHOLESALE INTERFACE (MO+MT) ......................................................... 80
2.8.1
DESCRIPTION ..................................................................................................... 80
2.8.2 DETAILED PROCEDURES AT ARP ............................................................................. 80
2.8.3 DETAILED PROCEDURES AT DSP ..............................................................................81
2.8.4 INTERFACE PRIMITIVES ...........................................................................................81
2.8.5 PARAMETERS DEFINITIONS AND USE.......................................................................... 83
2.8.6 ERROR HANDLING ............................................................................................... 83
3
INTERFACE DEFINITION FOR LBO ............................................................................................. 84
3.1 ASSUMPTIONS ........................................................................................................ 84
3.2 INTERFACE OVERVIEW .............................................................................................. 84
3.3 LBO-IF1 : MOBILITY / PROFILE CONTROL ................................................................... 85
3.3.1
DESCRIPTION ..................................................................................................... 85
3.3.2 DETAILED PROCEDURES AT HPMN ........................................................................... 85
3.3.3 DETAILED PROCEDURES AT LBO.............................................................................. 86
3.3.4 INTERFACE PRIMITIVES .......................................................................................... 87
3.3.5 PARAMETERS DEFINITIONS AND USE.......................................................................... 88
3.3.6 ERROR HANDLING ............................................................................................... 89
3.4 LBO-IF2 : LBO NOTIFICATION INTERFACE ..................................................................... 90
3.4.1
DESCRIPTION ..................................................................................................... 90
3.4.2 DETAILED PROCEDURES AT DSP ............................................................................. 90
3.4.3 DETAILED PROCEDURES AT LBO.............................................................................. 90
3.4.4 INTERFACE PRIMITIVES .......................................................................................... 90
3.4.5 PARAMETERS DEFINITIONS AND USE.......................................................................... 90
3.4.6 ERROR HANDLING ............................................................................................... 90
3.5 ANNEX - STUDY ON HOME ROUTING AND LEGAL INTERCEPTION CASES ..................................91
3.5.1
DSP HOME ROUTING – CAP V1 ..............................................................................91
3.5.2 DSP HOME ROUTING – CAP V2 ............................................................................ 92
3.5.3 ARP HOME ROUTING – CAP V1 ............................................................................. 93
3.5.4 ARP HOME ROUTING – CAP V2 ............................................................................ 94
3.5.5 LEGAL INTERCEPTION ........................................................................................... 95
3.5.6 SUMMARY OF THE SOLUTIONS ................................................................................. 95
page 3/96
Figures
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
1 – REQUIREMENT HIERARCHY & CLASSIFICATION ............................................................ 11
2 – OVERVIEW: IP TRANSPORT FOR DIFFERENT PROTOCOLS ...............................................18
3– M3UA STACK OVERVIEW .....................................................................................19
4 – THE COMMUNICATION BETWEEN TWO SIGTRAN M3UA NODES IN THE OSI LAYER MODEL ......19
5 – M2PA STACK OVERVIEW................................................................................... 20
6 – THE COMMUNICATION BETWEEN TWO SIGTRAN / M2PA NODES IN THE OSI LAYER MODEL . 20
7 – SCTP MULTIHOMING (IP) – OPTION 1 .................................................................21
8 – SCTP MULTIHOMING (SPC) – OPTION 1 ..............................................................21
9 – SCTP MULTIHOMING (IP) – OPTION 2 ................................................................ 22
10 – SCTP MULTIHOMING (SPC) – OPTION 2 ........................................................... 22
11 – SCTP MULTIHOMING (IP) – OPTION 3 ............................................................... 22
12 – SCTP MULTIHOMING (SPC) – OPTION 3 ........................................................... 23
13 – SINGLE IMSI INTERFACE DEFINITION .................................................................... 24
14 – GENERIC RULES FOR FUNCTION MAPPING .............................................................. 25
15 – VOICE / CAMEL ARCHITECTURE AND ASSOCIATED FUNCTIONS .................................... 26
16 – SEQUENCE DIAGRAM FOR SCCP LEVEL RELAY OF CAMEL OPERATIONS (OPTION 1) ........ 28
17 – SEQUENCE DIAGRAM FOR MO CALL HANDLING WITH SEPARATE CAMEL DIALOGUES ........... 29
18 – SEQUENCE DIAGRAM FOR MT CALL HANDLING WITH SEPARATE CAMEL DIALOGUES .............31
19 – SEQUENCE DIAGRAM FOR ANTI TROMBONE SOLUTION ................................................ 32
20 – SMS ARCHITECTURE AND ASSOCIATED FUNCTIONS ................................................... 36
21 – GENERIC SMS INTERCEPTION MECHANISM FOR ONLINE CHARGING ................................. 36
22 – SMS CONTROL OVER CAMEL (EXISTING ROAMING AGREEMENT) ................................ 38
23 – SMS CONTROL OVER CAMEL (MAP INTERCEPT) ................................................. 39
24 – SMS CONTROL OVER DIAMETER (MAP INTERCEPT AND IEC MODE) ............................41
25 – SMS CONTROL OVER DIAMETER (MAP INTERCEPT AND ECUR MODE) ........................ 42
26 – DATA ARCHITECTURE AND ASSOCIATED FUNCTIONS................................................... 49
27 – MMS ARCHITECTURE AND ASSOCIATED FUNCTIONS .................................................. 50
28 – START OF DATA SESSION CALL FLOW: CONTROL AT PDP CONTEXT CREATION ................. 53
29 – START OF DATA SESSION CALL FLOW: CONTROL AT FIRST PACKET RECEIVED .................. 54
30 – START OF DATA SESSION CALL FLOW: SPLIT AUTHENTICATION AND QUOTA MANAGEMENT ..... 55
31 – MIDDLE OF DATA SESSION CALL FLOW ................................................................ 56
32 – TERMINATION OF DATA SESSION CALL FLOW (USER-TERMINATION) ............................. 57
33 – TERMINATION OF DATA SESSION CALL FLOW (ARP-TERMINATION)- CASE 1 .................. 58
34 – TERMINATION OF DATA SESSION CALL FLOW (ARP-TERMINATION) - CASE 2 ................ 59
35 – MMS MO USING IEC WITHOUT QUOTA MANAGEMENT FOR DATA VOLUME ....................... 60
36 – MMS MO USING IEC WITH QUOTA MANAGEMENT FOR DATA VOLUME .............................61
37 – MMS MT USING IEC .................................................................................... 63
38 – MMS MT USING ECUR ................................................................................. 65
39 – MOBILITY MANAGEMENT ARCHITECTURE AND ASSOCIATED FUNCTIONS.............................. 68
40 - ROAMING STATUS CHANGE NOTIFICATION .............................................................. 69
41 – ARCHITECTURE OF USSD SERVICES ................................................................... 75
42 – IF5 USSD INTERFACE ................................................................................... 76
43 – MO/MT SMS ARCHITECTURE AND ASSOCIATED FUNCTIONS........................................ 80
44 – TYPICAL SMPP REQUEST/RESPONSE SEQUENCE FOR AN SMS FROM ARP TO DSP ......... 82
45 – TYPICAL SMPP REQUEST/RESPONSE SEQUENCE FOR AN SMS FROM DSP TO ARP ......... 82
46 – LBO INTERFACE DEFINITION ............................................................................. 84
page 4/96
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
FIGURE
47
48
49
50
51
52
–
–
–
–
–
–
GLR – HLR INTERFACE ................................................................................. 87
UPDATE GPRS LOCATION CALL FLOW ................................................................. 89
DSP HOME ROUTING WITH CAP V1 INTERFACE TO ARP ...........................................91
DSP HOME ROUTING WITH CAP V2 INTERFACE TO ARP ......................................... 92
ARP HOME ROUTING WITH CAP V1 INTERFACE TO ARP .......................................... 93
ARP HOME ROUTING WITH CAP V2 INTERFACE TO ARP ......................................... 94
page 5/96
References
[1] Regulation (EU) No 531/2012 of the European Parliament and the Council of 13 June 2012 on
roaming on public mobile communications networks within the Union
[2] Regulations, Commission Implementing Regulation (EU) No 1203/2012 of 14 December 2012 on
the separate sale of regulated roaming services within the Union
Following documents are for information only (given for supporting the consultation).
No binding requirements should be derived from there.
[3] BoR (12) 68: ROAMING REGULATION - CHOICE OF DECOUPLING METHOD: A consultation to
assist BEREC in preparing advice to the Commission on its forthcoming Implementing Act, June
2012, 72 pages.
[4] BoR (12) 109: ROAMING REGULATION - CHOICE OF DECOUPLING METHOD, BEREC opinion
on article 5 implementing act, 27 Sept 2012, 7 pages
[5] BoR (13) 82: BEREC GUIDELINES ON ROAMING REGULATION (EC) NO 531/2012 (THIRD
ROAMING REGULATION) (Articles 4 and 5 on Separate Sale of Roaming Services)
[6] 3GPP TS 32.240, Telecommunication management; Charging management; Charging architecture
and principles
[7] 3GPP TS 22.011: Service accessibility
[8] 3GPP TS 23.122: Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode
[9] EU Roaming regulation III, Structural Solutions, High Level Technical specifications v1.0
page 6/96
Definitions
Below mentioned definitions are adopted by 3GPP TS 32.240 [5] “Charging architecture and
principles” and “Implementation Act”
alternative roaming provider: a roaming provider different from the domestic provider; It can be
single IMSI alternative roaming provider – named ARP or LBO roaming provider - called LBO provider.
billing: function whereby CDRs generated by the charging function(s) are transformed into bills
requiring payment;
call control function (CCF): CCF is the Call Control Function in the network that provides call/service
processing and control (see ITU-T Recommendation Q.1224)
CAMEL: network feature that provides the mechanisms to support operator specific services even
when roaming outside HPLMN;
charging data record (CDR): formatted collection of information about a chargeable event (e.g. time
of call set-up, duration of the call, amount of data transferred, etc) for use in billing and accounting. For
each party to be charged for parts of or all charges of a chargeable event a separate CDR shall be
generated, i.e. more than one CDR may be generated for a single chargeable event, e.g. because of
its long duration, or because more than one charged party is to be charged;
charging: function within the telecommunications network and the associated OCS/BD components
whereby information related to a chargeable event is collected, formatted, transferred and evaluated in
order to make it possible to determine usage for which the charged party may be billed (offline
charging) or the subscriber’s account balance may be debited (online charging);
circuit switched domain: domain within GSM / UMTS in which information is transferred in circuit
switched mode;
domestic provider: an undertaking that provides a roaming customer with domestic mobile
communications services;
domestic provider or Domestic Service Provider (DSP): an undertaking that provides a roaming
customer with domestic mobile communications services - Mobile Network Operator or a Mobile
Virtual Network Operator.
page 7/96
donor roaming provider: the roaming provider, that is currently providing roaming services to a
customer;
EUInternet access point name (APN): a common identifier set, manually or automatically, in the
roaming customer's mobile device and recognized by the home network and visited network to
indicate the roaming customer's choice to use local data roaming services (LBO Provider);
home network / HP(L)MN: a public communications network located within a Member State and
used by the roaming provider for the provision of regulated retail roaming services to a roaming
customer. The MCC+MNC of the customer's IMSI corresponds to a MCC+MNC of this network's
identity.
local data roaming service: a regulated data roaming service provided, temporarily or permanently,
to roaming customers directly on a visited network, by an alternative roaming provider without the
need for roaming customers to change their SIM card or mobile device;
mobile number portability: The ability for a mobile subscriber to change subscription network within
the same country whilst retaining their original MSISDN(s).
network barring: a control function used by the home network operator aimed at avoiding the
selection of certain visited networks for its roaming customers;
offline charging: charging mechanism where charging information does not affect, in real-time, the
service rendered.
online charging system: the entity that performs real-time credit control. Its functionality includes
transaction handling, rating, online correlation and management of subscriber accounts/balances.
online charging: charging mechanism where charging information can affect, in real-time, the service
rendered and therefore a direct interaction of the charging mechanism with bearer/session/service
control is required.
packet switched domain: domain in which data is transferred between core network elements.
premium service: call from VPLMN to premium rate service or value added service number of the
VPLMN country; call to destination in EU, where the interconnection cost is not regulated on national
termination market, including in the VPLMN country
real-time: real-time charging and billing information is to be generated, processed, and transported to
a desired conclusion in less than 1 second.
recipient roaming provider: a roaming provider, that will provide roaming services instead of
roaming services currently provided by the donor roaming provider after the change of roaming
provider;
resale of retail roaming services: a provision of regulated roaming services, provided as a bundle,
and associated services, such as voice mailbox services, that are usually available to roaming
customers, without the need for roaming customers to change their SIM card or mobile device, in
accordance with a wholesale agreement concluded between an alternative roaming provider and a
domestic provider;
retail charging: see charging
roaming customer: a customer of a roaming provider of regulated roaming services, by means of a
terrestrial public mobile communications network situated in the Union, whose contract or arrangement
with that roaming provider permits Union-wide roaming
roaming provider: an undertaking that provides a roaming customer with regulated retail roaming
services;
roaming: The ability for a user to function in a serving network different from the home network. The
serving network could be a shared network operated by two or more network operator.
page 8/96
traffic steering: a control function used by the home network operator aimed at the selection of
visited networks for its roaming customers based on a priority list of preferred visited networks;
union-wide roaming: the use of a mobile device by a roaming customer to make or receive intraUnion calls, to send or receive intra-Union SMS messages, or to use packet switched data
communications, while in a Member State other than that in which the network of the domestic
provider is located, by means of arrangements between the home network operator and the visited
network operator;
visited network /VP(L)MN: a public mobile communications network located within a Member State
other than that of the roaming customer’s HPLMN that permits a roaming customer to make or receive
calls, to send or receive SMS messages or to use packet switched data communications, by means of
arrangements with the home network operator. The MCC+MNC of the customer's IMSI does not
correspond to a MCC+MNC of this network's identity.
page 9/96
Abbreviations
3GPP
APN
ARP
BEREC
CAP
CC
CDR
CF
CS
DSP
ESME
EU
FQDN
GGSN
GSM
GSMA
GT
HLR
HPMN
IANA
IF
IMSI
IP
ITU
LBO
LTE
MAP
ME
MMS
MFC
MOC
MSISDN
MTC
MNO
MVNO
MVNE
NDC
NNI
NRA
OCS
ORLCF
OTA
PDP
QoS
RG
SGSN
SIM
SMS
SMSC
TAP
TBC
TBD
USSD
VLR
VPMN
Third Generation Partnership Project
Access Point Name
Alternative Roaming Provider
Body of European Regulators for Electronic Communications
CAMEL Application Part
Country Code
Charging Data Record
Call Forwarding
Circuit Switched
Domestic Service Provider
External Short Message Entity
Member States of the European Union, the outermost regions of the European
Union and countries adopting Regulation
Fully Qualified Domain Name
Gateway GPRS Service Node
Global System for Mobile communication
GSM Association
Global Title
Home Location Register
Home Public Mobile Network
Internet Assigned Numbers Authority
Interface
International Mobile Subscriber Identity
Internet Protocol
International Telecommunication Union
Local (Data) Break Out
Long Term Evolution
Mobile Application Part
Mobile Equipment
Multimedia Messaging Service
Mobile Forwarded Call
Mobile Originating Call
Mobile Subscriber ISDN Number
Mobile Terminating Call
Mobile Network Operator
Mobile Virtual Network Operator
MVNO Enabler
National Destination Code
Network to Network Interface
National Regulatory Authority
On-line Charging System
Optimal Routing Late Call Forwarding
Over The Air
Packet Data Protocol
Quality of Service
Rating Group
Serving GPRS Support Node
Subscriber Identity Module
Short Messaging Service
Short Message Service Center
Transferred Account Procedure
To Be Confirmed
To Be Defined
Unstructured Supplementary Services Data
Visited Location Register
Visited Public Mobile Network
page 10/96
1
SCOPE
The objective of this document is to describe the detailed technical specifications defining the interface
and protocols supporting the implementation of the roaming unbundling for EU roaming regulation III.
The document relies on interface requirement defined in the high level architecture document.
The HL document identifies basic requirements for securing the implementation of the regulation and
the service decoupling between the DSP and the ARP.
The reader is invited to refer to this document for getting a complete understanding of the set of
requirements, obligations, etc related to the Regulation III.
Customer
End User Services
(Associated use cases)
Architecture Definition & Specifications
(Functional architecture, interface definition, function mapping)
Operator Obligations
(Interface, function)
Detailed Design
(Interfaces & protocols)
Detailed Design
(Billing & Provisioning)
Detailed Design
(Processes)
Figure 1 – Requirement hierarchy & classification
1.1
Document structure
The core of this document contains detailed definition of the following interfaces (with associated use
cases)
o Single IMSI interfaces: IF1, IF2, IF3, IF4, IF5 and IF9
o LBO interfaces : IF1 and IF2
Additionally a test book will be provided as a separate document to list out procedures and scenarios
in order to validate those interfaces.
Each section of this document covers usually the following outline:

Context
o

This section explains the roaming environment for the interface being defined.
Description
o
This section explains the role of the interface, call flows and implementation
challenges to be addressed.
page 11/96
o



Detailed Procedures at DSP
o
This section explains how the DSP triggers the interface and the actions to be taken
upon receiving the answer from the ARP.
o
It includes procedures related to error handling.
Detailed Procedures at ARP
o
This section explains the actions to be taken upon receiving the initial trigger from the
DSP.
o
It includes procedures related to error handling.
Interface primitives
o

This section highlights the primitives relevant when using the interface between the
ARP and the DSP. The associated details can be found in the relevant 3GPP or OMA
standards.
Parameters Definitions and Use
o

The call flows usually show only the relevant fields applicable for enabling the
separation of retail sales.
This section highlights the field / parameters that are used in the protocol(s) for
enabling the decoupling of roaming.
Summary table
o
This section captures the information which is expected to be exchanged between the
DSP and ARP for setting up and maintaining the interface.
Important: This document will contain obligation and option.


“Shall” will describe an obligation
“May” will describe an option
page 12/96
1.2
Working Assumptions
The purpose of this section is to explain the working assumptions for ensuring the decoupling of retail
roaming services in the context of Single IMSI or Local Data Break-Out implementations.
It will clarify the expected information and identifiers to be shared by the involved parties: end-user,
Domestic Service Provider (DSP), Alternative Roaming Provider (ARP) or Local Data Break-Out
Provider (LBO).
1.2.1 Generic Requirements
1.2.1.1
Decoupling Solution Failure
It is expected the roaming services will be interrupted in case of the unavailability of the solution
enabling the decoupling of the retail roaming services when the customer uses the roaming services
offered by an ARP or an LBO provider.
This ensures the retail and wholesale charges are always aligned.
The DSP and ARP may agree to continue serving customers in case of failure of the decoupling
solution and will have appropriate dispute resolution procedure in place.
1.2.1.2
Activity termination at ARP/DSP Registration
The DSP may have the ability to terminate the on-going activity of a subscriber when the change of
roaming provider happens when the subscriber roams.
There are multiple ways to realize such termination mechanism as described in standard
specifications and fraud-handling document. This is out of scope of this document.
1.2.1.3
No discrimination principle
The DSP shall not alter the profile characteristics determining the quality of service of the roaming
subscribers when swapping to ARP or to LBO provider.
In the case of LBO, the DSP shall provide the EUinternet APN with the same QoS settings as the
internet service for his roaming subscribers using the usual HPMN APN for accessing the internet.
The DSP may restrict access to supplementary services that provides capability beyond the roaming
scope (e.g. multi-party call, call hold/call wait, etc).
page 13/96
1.2.2 Single IMSI implementation
The online interfaces that are defined further in this document enable a real-time charging and
management of the customer (mobility) at the ARP.
1.2.2.1
Architecture
Inside the Single IMSI architecture, the following parameters shall be unique and controlled by the
DSP
 HLR to VLR SS profile,
 SMSC address,
 APN for data services,
 PCRF parameters
1.2.2.2
Conditions for triggering the Proxies for enabling separation of sale
The following table summarizes the conditions to be fulfilled for triggering the corresponding interface.
IF
IF1
Event
MOC
IF1
MFC
IF1
MTC
IF2
SMS-MO
IF3
DATA
IF3
MMS-MO
IF3
MMS-MT
IF4
Mobility
IF5
ARP
USSD
Subscriber
Calling
subscriber
belongs to ARP
Redirecting subscriber
belongs to ARP
Called
subscriber
belongs to ARP
Calling
subscriber
belongs to ARP
Data Session initiator
belongs to ARP
Data Session initiator
belongs to ARP
Recipient of the MMS
belongs to ARP
Moving
subscriber
belongs to ARP
Dialing
subscriber
belongs to ARP
IF5
DSP
USSD
Dialing
subscriber
belongs to ARP
Location
In ARP coverage
Destination
In ARP destination set
Type
In ARP call type
In ARP coverage
In ARP destination set
In ARP call type
In ARP coverage
n.a.
In ARP call type
In ARP coverage
In ARP destination set
n.a.
In ARP coverage
n.a.
n.a.
In ARP coverage
In ARP destination set
n.a.
In ARP coverage
n.a.
n.a.
In ARP coverage
n.a.
n.a.
Any or depending
on
the
USSD
service – only in
ARP
coverage
(*)
Any or depending
on
the
USSD
service – only in
DSP
coverage
(*)
Using
USSD
code
designated for ARP
n.a.
Using USSD designated
for DSP
n.a.
(*): in case of USSD interface is used for triggering USSD Call back service (offered by DSP or ARP),
the DSP may apply a location control validating whether the roamer is in the ARP/DSP coverage.
The invocation at DSP and the control at the ARP requires at least:



Subscriber identification
Location information
Event type and destination
page 14/96
The definition and relevant parameters are defined in the following sections.
1.2.2.3
The subscriber identification
The subscriber shall be identified by its MSISDN wherever possible.
The subscriber MSISDN shall be used as the primary identifier of a subscription on interfaces between
DSP and ARP. Where a MSISDN is not associated with the subscription, IMSI shall be used. It shall
be possible for MSISDN and IMSI to both be included in protocol messages, but it is not mandatory to
include both under any circumstance.
Note: it is expected that Dual-IMSI implementation providing roaming enablement via a sponsor IMSI
should not affect the decoupling implementation because:
- The primary MSISDN of the customer remains usually available;
- The HPMN is still involved in the subscriber authentication and registration procedures as
well as the online charging activity. The IMSI-HPMN and IMSI-Sponsor mapping is usually
applied at the Sponsor operator.
1.2.2.4
The location information
The DSP and the ARP shall agree on the ARP roaming coverage i.e. the set of roaming locations
where the customer is controlled by the ARP.
The minimum set of locations consists of the mobile networks located in countries where the EU
Regulation applies. The DSP and ARP may extend the scope of the ARP coverage.
The observable location information of the roaming customer depends on the call event and the
roaming implementation at the DSP, and between the HPMN and the VPMN.
For example, the roaming arrangement using Roaming Hubs may affect the information passed to the
ARP.
In the context of CS-domain, the relevant information is the MSC/VLR Global Title of the core network
node serving the customer.
The Global Title (or its range) used by the VPMN is defined in the roaming agreement between the
HPMN and the VPMN and is not publicly available. However, the CC/NDC usually follows the regular
numbering plans and enables determining the location of the subscriber using ITU, NRA information,
or private companies.
In some cases, the roaming relationship between the home and the visited network is based on a
technical implementation that prevents the ARP from using publicly-available information for
determining the location of its customer. In such circumstances, the DSP shall provide the relevant
information for determining the location of a customer to the ARP.
This shall typically cover the cases where the GT CC/NDC does not reflect the actual location of the
customer e.g.
- Alias GT of a EU network caching a non-EU actual location
- Alias GT of a non-EU network caching a EU location
- GT of a EU network used specifically for non-terrestrial service (i.e. air, satellite or
maritime services)
- etc
In the context of PS-domain, the relevant information is usually the IP address or FQDN of the core
network node serving the customer. Additionally, depending on the technology and the VPMNimplementation, the MCC/MNC of the VPMN may also be visible on the online interface, for example,
GTP may convey optionally the MCC/MNC between the VPMN and HPMN in the RAI (Routing Area
Identity).
The IP address (or its range) or FQDN used by the VPMN is defined in the roaming agreement
between the HPMN and the VPMN and is not publicly available. However, the IP address or FQDN
page 15/96
may usually be resolved for determining the owner and location of the subscriber using IANA, whois
command, etc.
In some cases, the roaming relationship between the home and the visited network is based on a
technical implementation that prevents the ARP from using publicly-available information for
determining the location of its customer. In such circumstances, the DSP shall provide all relevant
information for determining the location of a customer to the ARP.
This shall typically cover the cases where the IP address or the FQDN does not reflect the actual
location of the customer e.g. an alias IP address.
Since the MCC/MNC identifies univocally the location of the subscriber, it is recommended the HPMN
and VPMN supports the use of these fields on their roaming interface.
The DSP is free to put in place a location information translation mechanism providing transparent
location information to the ARP within the interface instead of sharing GT/IP/FQDN information.
The location of the subscriber will be checked by the DSP and the ARP when processing the online
event. Dedicated errors are defined for each interface to identify unambiguously and directly, if
standard permits, the rejection due to location mismatch (ARP vs. DSP coverage).
It should be noted that out-of-ARP-coverage error includes the case where events are sent to the ARP
while the end-user is not in a roaming condition.
1.2.2.5
Event type and destination
The minimum set of destination consists of destination for which the EU Regulation applies. The DSP
and ARP may extend the scope of the ARP coverage. In such case, the DSP and the ARP shall
determine the ARP destination set and type i.e. the set of destinations under the control of the ARP
including the call type (voice, video-telephony, etc).
The event type is passed transparently to the ARP – e.g. Voice, video-telephony, SMS, Data, MMS.
Hence there is not specific action to be taken by the parties.
The called destination for Voice, SMS and MMS services is based on the publicly available numbering
plan. Hence the ARP is responsible of determining the destination of the call and hence, the
associated call rate.
The call destination will be checked by the DSP and the ARP when processing the online event.
Dedicated errors are defined for each interface to identify unambiguously and directly, if standard
permits, the rejection due to a destination set mismatch (Call Destination not being part of the EU
regulated destinations and of the DSP-ARP agreement).
1.2.2.6
Special use case: short codes
The call handling of short codes usually requires number translation for reaching the final call
destination. The associate charging has to be configured for charging correctly these calls, too.
The use short code calls is not part of the regulation and therefore its implementation is subject to
agreement between the DSP and the ARP.
1.2.2.7
Special use case: regulated free-of-charge numbers
The regulation requires the roaming provider to setup a free-of-charge number for obtaining more
detailed personalised pricing information on the roaming charges that apply in the visited network to
voice calls and SMS, and information on the transparency measures applicable by virtue of this
Regulation, by means of a mobile voice call or by SMS.
The free-of-charge requirement applies only in visited networks located inside the Union.
ARP will deliver Free-of-charge number for obtaining more detailed information on the roaming
charges. ARP free-of-charge number belongs to the EU numbering plan.
page 16/96
If the ARP coverage is limited to EU to EU, DSP has also to provide a DSP free-of-charge number for
the where the customer can get the non-EU destinations tariff.
2 implementation options are possible to handle the calls towards the DSP free-of-charge number:
1) Either DSP is able to filter the DSP free-of-charge number. The ARP will not receive the
corresponding triggers - ARP online charging is not impacted by the call.
2) DSP is not able to filter the DSP free-of-charge number. The DSP will inform the ARP about how
to recognize the destination. The ARP will not charge at retail level the ARP customer for dialling
the DSP free-of-charge number.
1.2.2.8
Special use case: Premium Rate and VAS services
The call handling of Premium Rate and VAS services requires specific management. These numbers
are not part of the regulation and therefore the corresponding implementation is subject to the
agreement in place between the DSP and the ARP.
1.2.3 LBO implementation
1.2.4
Subscriber identification
The subscriber shall be identified by its MSISDN wherever possible.
The subscriber MSISDN shall be used as the primary identifier of a subscription. Where a MSISDN is
not associated with the subscription, IMSI shall be used. It shall be possible for MSISDN and IMSI to
both be included in protocol messages, but it is not mandatory to include both under any
circumstance.
1.2.5
Service Usage
It is expected the LBO user will register the visited network providing the LBO service using a manual
mode selection. The manual selection registration may happen after an initial automatic registration.
This ensures the subscriber will not select alternative networks because of loss of coverage, SIM
parameters, etc.
The LBO design uses a new standardised APN value (standardised at European level) of "euinternet"
(not case sensitive), which is known hereafter as the EUInternet APN. The EUInternet APN is specific
to the LBO service and based on which the VPLMN will route Internet traffic directly to the VPLMN
instead of routing via the HPLMN.
It is expected the LBO user will access the LBO service using the EU-wide dedicated APN.
page 17/96
2
2.1
INTERFACE DEFINITION FOR SINGLE IMSI
ARP – DSP Connectivity
The preferred transport layer for the Signalling is IP. With Signalling Transport over IP (SIGTRAN) the
existing protocols on the higher layers can be used without changes (CAP, MAP). Also other protocols
like SMPP, http/json and Diameter can be used via the same IP connection.
A separation of the protocols in VPNs or IPSec can be mutually agreed between the DSP and the
ARP.
CAP
MAP
SMPP
(SMS)
http,
ftp
Diameter
SIGTRAN
IP
(VPN, IPSec)
Figure 2 – Overview: IP transport for different protocols
.
2.1.1 SIGTRAN
The TCAP and the SCCP provide a signaling connection between different signaling nodes and
provide a transport mechanism for the upper protocol layers, e.g. Camel or MAP. The SCCP, Camel
and MAP protocol layers do not require any modifications if SIGTRAN or TDM is used for the
transport.
If SIGTRAN is not available, TDM based
If SIGTRAN is used, M2PA or M3UA shall be used.
MTP
page 18/96
and
SCCP
can
also
be
used.
2.1.1.1
SIGTRAN Option M3UA
SIGTRAN (M3UA)
based Signalling
TDM based Signalling
CAMEL / MAP
CAMEL / MAP
TCAP
TCAP
SCCP
SCCP
M3UA
MTP
Layer 1-3
SCTP
IP Link
TDM Link
Figure 3– M3UA stack overview
The
Protocol
layers
in
classical
SCCP, CAMEL, MAP layers are unchanged.
SS7
MAP/CAMEL
and
in
Adressing:
Originating Local Reference
Destination Local Reference
TCAP
SCCP
Adressing:
Calling Party Number
Called party Number
SCCP
M3UA
Adressing:
Originating Point Code
Destination Point Code
M3UA
IP
M3UA.
MAP/CAMEL
TCAP
SCTP
SIGTRAN
Adressing:
used SCTP Association Set
Adressing:
Originating IP Adress
Destination IP Adress
SCTP
IP
IP based connection
Figure 4 – the communication between two SIGTRAN M3UA nodes in the OSI layer model
The Network Appearance Parameter (NA) in M3UA shall be agreed between the DSP and the ARP.
The value of the NA can be different from the value of the NA in the private network of the DSP. This
separation can improve the security.
page 19/96
2.1.1.2
SIGTRAN Option M2PA
SIGTRAN (M2PA)
based Signalling
TDM based Signalling
CAMEL / MAP
CAMEL / MAP
TCAP
TCAP
SCCP
SCCP
MTP3
MTP3
M2PA
MTP
Layer 1-2
SCTP
IP Link
TDM Link
Figure 5 – M2PA stack overview
The
Protocol
layers
in
classical
SCCP, CAMEL, MAP layers are unchanged.
SS7
and
MAP/CAMEL
in
SIGTRAN
Adressing:
Originating Local Reference
Destination Local Reference
TCAP
SCCP
Adressing:
Calling Party Number
Called party Number
SCCP
MTP3
Adressing:
Originating Point Code
Destination Point Code
MTP3
M2PA
IP
variant).
MAP/CAMEL
TCAP
SCTP
(M2PA
M2PA
Adressing:
used SCTP Association Set
Adressing:
Originating IP Adress
Destination IP Adress
SCTP
IP
IP based connection
Figure 6 – The Communication between two SIGTRAN / M2PA nodes in the OSI layer model
In this SIGTRAN option the M2PA layer emulates an MTP2 connection between the nodes.
page 20/96
2.1.1.3
MTP / M3UA Routing
For the following protocol layers an address planning between the DSP and the ARP is necessary:
-
IP connection (IP addresses, Gateway, Netmask, etc.)
SCTP Associations (number of associations, multihoming)
M3UA: The Network Appearance Parameter (NA) . The NA shall be agreed between the DSP
and the ARP. The value of the NA for the ARP connection can be different from the value of
the NA in the private network of the DSP.
-
Signaling Point Codes and MTP Routing Tables
SCCP Addresses (E.164 Global Titles)
As an option, for increasing redundancy, multiple SCTP associations are recommended (Multihoming).
Option 1:
IP .1
IP .3
IP .2
IP .4
1 SCTP Association
2 SCTP Pathes (primary,
secondary)
Figure 7 – SCTP Multihoming (IP) – option 1
SPC B
SPC A
MTP/M3UA Routing in A:
Destination B = Linkset A_B, Prio 1
Figure 8 – SCTP Multihoming (SPC) – option 1
page 21/96
Option 2 (more Reliability)
IP .1
IP .3
IP .2
IP .4
1 SCTP Association
with 4 SCTP Pathes
(2 prim, 2 sec)
Figure 9 – SCTP Multihoming (IP) – option 2
SPC B
SPC A
MTP/M3UA Routing in A:
Destination B = Linkset A_B, Prio 1
Figure 10 – SCTP Multihoming (SPC) – option 2
Option 3 (Paranoia Mode)
IP .1
IP .10
IP .2
IP .11
IP .3
IP .12
IP .4
IP .13
4 SCTP Associations
with 8 SCTP Pathes
4 M3UA Linksets
Figure 11 – SCTP Multihoming (IP) – option 3
page 22/96
SPC A
SPC B
SPC C
SPC D
Figure 12 – SCTP Multihoming (SPC) – option 3
MTP/M3UA Routing in A:
Destination B = Linkset A_B, Prio 1
Destination B = Linkset A_D, Prio 2
Destination D = Linkset A_D, Prio 1
Destination D = Linkset A_B, Prio 2
MTP/M3UA Routing in C:
Destination B = Linkset C_B, Prio 1
Destination B = Linkset C_D, Prio 2
Destination D = Linkset C_D, Prio 1
Destination D = Linkset C_B, Prio 2
The Signaling Point codes can be unique either in the country (national unique SPC) or can be unique
worldwide (international unique SPC).
If the DSP and the ARP agree on the usage of private SPCs (not unique in different networks), the
ARP shall use this private SPC only for the specific connection between the relevant ARP and the
DSP. The private SPC cannot be used for other SS7 connections between different networks.
2.1.1.4
SCCP Routing
The nodes on the DSP side and on the ARP (Carrier) side shall act as SCCP Relay Gateways.
The SCCP Addresses (Calling Party and Called Party, E.164 Global Titles) are involved in an end-2end Signaling Connection. They are used between the Serving PLMN and the DSP based on the
existing Roaming connections. In the signaling relationship between the VPLMN and the DSP the
E.164 GTs of the VPLMN and the DSP are used.
The ARP may have its own GT, or GT is provided from the DSP. However, the VPLMN does not have
necessarily an SCCP Routing for this GT as the roaming relationship only exists between the HPMN
and the VPMN. Hence this could result into problems in SCCP connections with multiple messages in
each direction, e.g. prepaid service.
To ensure the end-2-end routing from VPLMN to the ARP, the ARP has to use a GT from the DSP
range or the DSP shall use a proxy with SCCP address manipulation.
As described in the IF1 section, the SCCP Relay function or the Proxy function in place shall enable
the exchange of message end-to-end between the ARP and the DSP.
The selection of the method (Route on PC, TT modification, Global Title modification, etc) depends on
the DSP routing capabilities.
page 23/96
2.2
Interface overview
To enable the sale of regulated roaming services the following interfaces are proposed to directly
provide the basic regulated service.






IF1: An online interface for voice retail billing (Camel or Diameter).
IF2: An online interface for SMS retail billing (Camel or Diameter).
IF3: An online interface for Data/MMS retail billing (Diameter).
IF4: An interface for providing mobility information to the ARP, to inform the ARP that one of
its customers has started to roam or has changed networks.
IF5: real-time USSD interface to enable the ARP to provide pre-paid account queries
(conditional).
IF9: SMS delivery interface (optional).
The purpose of this document is to detail the specifications of each of these interfaces.
For sake of completeness, in order to manage the customer and perform proper billing and invoicing
the following additional interfaces are also required. They will be defined by the Billing and
Provisioning (B&P) workgroup.



IF6: Invoicing interface, providing for example re-written TAP CDRs.
IF7: Provisioning interface enabling the management of ARP subscriptions.
IF8: Interface for high usage and fraud control (optional).
Alternative Roaming Provider
Prepaid
SMS
Delivery
USSD
Tariff
notification
IF9
IF5
IF4
SMS
Delivery
USSD
Proxy
Mobility
Proxy
Postpaid
On line Charging System
WS
Billing
(SCP)
IF1
Voice
Proxy
IF2
SMS
Proxy
IF3
Data
Proxy
IF6
MMS
Proxy
Billing
CRM
IF7
CRM
Fraud
IF8
Fraud
ARP awareness
HLR
Voice
Mail
GMSC
SMSC
GGSN
MMSC
Domestic Service Provider
Visited Network
Figure 13 – Single IMSI interface definition
Note
ARP Awareness (terminology to be refined) logical function aims at enabling the DSP functions to
determine whether customers have an ARP subscription and if yes with which ARP, whether a service
used by an ARP customer has to be decoupled or not, etc.
page 24/96
2.2.1 Generic rules for interface definition
Some functions have to be assigned to DSP or ARP, based on the interfaces defined above.
The major criteria for interface definition and function mapping are modularity, information hiding,
coupling minimization and cohesion maximisation.
When defining the specifications details, the I&P group has considered:


Interfaces (IFx) availability,
Mapping of the functions associated to those interfaces (IFx),
following the scheme below.
ARP
Function
IFx
DSP
Function
Figure 14 – Generic rules for function mapping
2.2.2 Preliminary Note
By exclusively using Diameter-based Billing interfaces between the ARP and DSP Online Charging
Systems (OCS), voice could be rated and charged in Real Time at retail level by the ARP. CAMEL
roaming agreement between DSP and VPMN could remain in place for Real Time Charging, but the
possibility of interoperability issues between DSP and ARP CAMEL implementations could be avoided
(CAMEL services have only been tested when opening CAMEL roaming relationship between VPMN
and DSP implementations).
Another advantage of Diameter usage is that DSP IN service implementations are isolated from ARP
connections. This would remove the need for repeated backward compatibility testing with each
connected ARP following any change in service developments, version upgrades, protocols, etc. that
the DSP deploys internally in its IN systems. The support of a Diameter interface is not avoidable
(required for Anti bill shock measures, Real Time Data Charging), but support for a Camel interface is.
page 25/96
2.3
SI-IF1 : Voice Control
2.3.1 Description
This interface is designated to enable charging of ARP subscribers for voice calls. This interface shall
be established between the DSP and the ARP. Figure 4 shows conceptual network architecture for SIIF1. SI-IF1 interface between DSP and ARP shall be established over CAMEL protocol. Due to the
fact that the Diameter protocol for CS voice call is currently not standardized, the use of Diameter for
IF1 will be subject to future expansion and is out of the scope of this section. The use of Diameter will
be described in a next version of the present document.
The transport layer implementation of IF#1 shall be as described in DSP-ARP connectivity section.
Figure 15 – Voice / CAMEL architecture and associated functions
2.3.2 Detailed Procedures for MO Calls
2.3.2.1
Handling of MO-call at DSP
DSP may provide real-time charging interface and, optionally, real-time call control interface towards
ARP. The providing of real-time charging interface and real-time call control interface is subject to the
existence of CAMEL agreement between DSP and VPMN in countries that are covered by ARP. The
providing of real-time charging interface and call control interface further requires that the DSP
subscribers are provisioned with an O-CSI for usage in these VPMNs.
The CAMEL-IDP forwarding from DSP to ARP may be handled in the following methods (options):
1) Implementation Option 1 : Relaying the IDP message, and further CAMEL messages within
the CAMEL dialogue, between DSP and ARP by means of SCCP routing;
2) Implementation Option 2 - Managing two CAMEL dialogs: One between the VPMN’s
MSC/gsmSSF and the DSP’s SCP and another one between the DSP’s SCP and the ARP’s
SCP.
DSP shall forward the CAP-MO-IDP (for Mobile Originated (MO) call or Mobile Forwarded (MF) call)
received from VPMN to ARP’s SCP when all of the following conditions are fulfilled:
1) The Calling Party Number (for MO call) or Redirecting Party Id (for MF call) contained in the
IDP operation is related to an ARP subscriber – or based on OCSI definition if specific per
ARP;
page 26/96
2) The ARP subscriber is, as derived from the Location Information contained in the IDP
operation, located in ARP coverage, as specified in the working assumption section.
It is observed that the present condition can’t be fulfilled when Implementation Option 1 is
used, unless the OCSI associated with a customer varies per location. It results, when
Implementation Option 1 is used, all MO calls from the ARP subscriber might be forwarded
from DSP to ARP.
3) The Called Party BCD Number (for MO call) or Called Party Number (for MF call) contained in
the IDP operation is related to a ARP destination as specified working assumption section.
It is observed that the present condition can’t be fulfilled when Option 1 is used. When Option
1 is used, all MO calls from the ARP subscriber may be forwarded from DSP to ARP.
The DSP is not obliged to convert the CAMEL phase, as used between VPMN and DSP, for the ARP.
The CAMEL phase offered to the ARP may be the same one as is used between the VPMN and the
DSP.
The CAMEL signalling between DSP and ARP shall comply with GSM TS 03.78 and GSM TS 09.78
(for CAMEL Phase 1 or CAMEL Phase 2) or 3GPP TS 23.078 and 3GPP TS 29.078 (for CAMEL
Phase 3 or CAMEL Phase 4), depending on which CAMEL phase is used.
Implementation Option 1: Relaying CAMEL to ARP by SCCP routing – A CAMEL dialogue will be
established between VPMN and ARP, whereby the CAMEL dialogue is routed through the voice proxy
of the DSP. The voice proxy shall apply manipulation in the SCCP layer in order to facilitate that the
messages replied from the ARP will be routed to the DSP network. For the remainder of the CAMEL
dialogue, the CAMEL operations are sent between VPMN and ARP via the voice proxy.
The voice proxy for option 1 entails a functional entity in the DSP’s network that handles CAP
signalling related to voice call establishment to/from ARP subscriber. The voice proxy determines
whether the criteria are fulfilled for relaying the CAP signalling towards ARP. In the affirmative case,
the voice proxy relays the CAP signalling, for this call to/from the ARP subscriber, between VPMN and
DSP. This implies that the TCAP relationship is established between VPMN and ARP.
Examples of SCCP relaying methods are (i) replacing the SCCP Destination Address and SCCP
Origination address and (ii) replacing the SCCP Destination Address and adapting the Translation
Type (TT) of the SCCP Origination Address.
In this option the DSP only inspects upper layer (TCAP/CAP) and no modification or manipulation is
done.
This has the following implications:
1) DSP will not have full control of the call session.
2) DSP will not be able to produce CDRs. This fact may complicate failure investigation,
dispute resolution and wholesale management between DSP and ARP.
(e.g. ARP subscriber complains that a call failed. Without CDR in DSP, the investigation
will be more difficult).
3) DSP will not be able to apply restrictions on CAMEL operations that are generated from
ARP.
(e.g. ARP can connect the call to destinations that are not agreed by DSP or ARP SCP
may arm the Answer DP or the Disconnect DP in interrupt mode when that is not agreed
by DSP).
4) DSP may mandate the ARP to perform CAMEL integration to VPMNs.
The following figure depicts the basic MO-call signaling flow for option 1.
page 27/96
Figure 16 – Sequence diagram for SCCP level relay of CAMEL operations (option 1)
Option 2: Managing two CAMEL dialogs:
The voice proxy for option 2 entails a functional entity in the DSP’s network that comprises a gsmSCF
and a gsmSSF. The gsmSCF in the voice proxy terminates the CAP dialogue that is initiated from the
MSC/gsmSSF in the VPMN’s network or that is initiated from the GMSC/gsmSSF in the DSP’s
network. The gsmSSF in the voice proxy initiates the CAP dialogue towards ARP. The voice proxy
further contains service logic that handles the CAMEL dialogue towards the VPMN and the CAMEL
dialogue towards the ARP and that maps information between these two dialogues.
This option has the following aspects:
1) DSP will have full control of the call session.
2) DSP will be able to produce CDRs, which facilitates investigation and dispute resolution in
reasonable timeline. DSP will also be able to perform full wholesale management.
3) DSP will be able to apply restrictions on CAMEL operations that are generated from ARP.
4) DSP will perform separate CAMEL integration with VPMNs and CAMEL integration with
ARPs. CAMEL integration to VPMNs, in so far as such integration had already been applied,
will not have to be re-performed for each ARP.
5) DSP and ARP may agree on a unique CAMEL phase for the IF1 interface, independent of the
CAMEL phase between VPMN and DSP.
The following figure depicts the basic MO-call signaling flow for option 2.
page 28/96
Figure 17 – Sequence diagram for MO call handling with separate CAMEL dialogues
The DSP shall provide, in the CAP IDP operation, all mandatory parameters to ARP. In addition, the
DSP may perform the following manipulations on the CAP IDP operation:
1) Replace the SK value.
2) Adapt the Location Information. The CAMEL standard specificies the following mandatory subparameters for the Location Information:
a. VLR number;
b. Age of location information; and
c.
Cell ID or LAI.
Due to the fact that the tariff information is based on VPMN network, DSP shall provide the
VLR number in the Location Information. The DSP may, however, hide the CellIdOrLAI and/or
the Age-of-location parameters from the Location Information.
Call diversion
By selecting option 2, the DSP will have the capability to perform screening on DRA (Destination
Routing Address) number present in CAP Connect operation replied from ARP. DSP may, resulting
from analysing the DRA, reject the Connect operation.
Call event arming
By selecting option 2, the DSP will have the capability to perform screening on BCSM event arming
mode (Notify and Continue or Interrupt), present in the CAP-RRB (Request-Report-BCSM) messages
replied from the ARP. Arming BCSM events by ARP shall be done in conformance to agreement
between DSP and ARP. The following options are identified:
-
ARP may arm events in interrupt mode; this mode of event arming results in the establishment
of a control relationship between DSP and ARP. A control relationship allows ARP to provide
on-line charging and provides ARP with call control capability.
-
ARP may arm events in Notify and Continue mode; this mode of event arming results in the
establishment of a monitor relationship between DSP and ARP. A monitor mode enables ARP
to monitor the call, but does not provide on-line charging and call control capability, apart form
modifying the destination of the call or disallowing the call establishment.
Announcement playing
The playing of announcement is supported in CAMEL Phase 2 and higher. For option 2, the ability for
playing announcements by ARP is subject to agreement between DSP and ARP. In addition, the
ability for playing announcements by ARP is subject to the existence of CAMEL Phase 2, or higher,
page 29/96
agreement between DSP and the VPMN where ARP subscriber roams. The ability for playing
announcements by ARP is further subject to the support, by DSP, of this capability.
2.3.2.2
Handling of MO-call at ARP
Based on agreement between DSP and ARP, ARP may perform call diversion for certain call cases.
Based on agreement between DSP and ARP, ARP may arm BCSM DPs in “notify and continue mode”
or in “interrupt” mode.
For CAMEL Phase 1, the ARP may apply charging based on Request Report BCSM (RRB) and Event
Report BCSM (ERB). The use of Activity Test may also be possible for checking the transaction
status.
For CAMEL phase 2 and higher, the ARP may use the following charging related operations:
- Apply charging (ACH) and Apply charging report (ACR);
- Call information request (CIRq) and Call information report (CIRp); and
- Furnish charging information (FCI).
The use of call control operations (including the use of the Connect operation and the arming of DPs
in interrupt mode) must be agreed between DSP and ARP.
Note The arming of at least one DP in interrupt mode is required for the use of the Apply Charging
operation.
2.3.3 Detailed Procedures for MT Calls
2.3.3.1
Handling of MT-call at DSP
CAMEL control of MT calls may be done through interaction with the GMSC or through interaction with
the VMSC. Interaction with GMSC for MT calls is done through T-CSI. Interaction with VMSC for MT
calls is done through VT-CSI. When VT-CSI is used for MT call control, this is generally restricted to
Home network. MT calls in home network do not qualify for control by ARP. Therefore, VT-CSI based
control of MT call is considered to be out of scope of the present document.
When CAMEL is used for Mobile Terminating (MT) call in the DSP, DSP shall use the same CAMEL
phase for the interface between the DSP SCP and the ARP as between the GMSC and the DSP SCP.
Note
Conversion of CAMEL phase for this call case is not prohibited but is deemed to fall
outside the scope of the present document.
There is no dependency between the CAMEL phase used for MO and MT scenario.
When the DSP uses non-CAMEL IN, such as INAP, for MT control, conversion to CAMEL phase 2
shall be applied by the DSP network.
Note
Conversion to other CAMEL phase than CAMEL phase 2 is not prohibited but is deemed
to fall outside the scope of the present document.
For charging of MT call, an IDP shall be sent from DSP to ARP SCP. DSP shall populate all
parameters in the IDP operation, in accordance with the CAMEL standard.
DSP shall send IDP (MT call) to ARP’s SCP when all of the following conditions are fulfilled:
1) The recipient number (Called Party Number) contained in the IDP operation is related to an
ARP subscriber;
2) The recipient subscriber (ARP subscriber) is, as derived from the Location Information
contained in the IDP operation, located in ARP coverage, as specified in working assumptions
section;
It is observed that the present condition can’t be fulfilled when Implementation Option 1 is
used. When Option 1 is used, all MT calls to the ARP subscriber may be forwarded from DSP
to ARP.
page 30/96
The following figure depicts the basic MT-call signaling flow for option 2.
Figure 18 – Sequence diagram for MT call handling with separate CAMEL dialogues
A terminating call for a roaming ARP subscriber may lead to call forwarding in the VPMN. When
CAMEL agreement between DSP and VPMN operator is present, the call forwarding in the VPMN may
result in the invocation of a CAMEL service for the forwarded call. The DSP shall forward the IDP
operation related to this forwarded call, to ARP. ARP may in this case apply its own ‘anti trombone
solution’.
Note
‘Anti trombone solution’ is a term commonly used to refer to the method of converting call
forwarding in the VPMN into call forwarding in the Home PLMN. Such method prevents
additional roaming cost for the operator and/or the end-user.
The following figure shows the signaling associated with a particular implementation of Anti trombone
solution.
page 31/96
Figure 19 – Sequence diagram for Anti trombone solution
In hybrid scenario, comprising a mix of non-CAMEL based service invocation (in Home PLMN) and
CAMEL based service invocation (in VPMN), anti-trombone solution may be implemented by DSP as
defined in the High level specifications document.
2.3.3.2
Handling of MT-call at ARP
The CAMEL interface between DSP and ARP comprises both call control capability and charging
control capability. The use of call control operations (e.g. CONNECT and the arming of DPs in
interrupt mode) must be agreed between DSP and ARP. The use of CONTINUE or RELEASE is by
default allowed.
When CAMEL agreement between VPMN operator and ARP is present, ARP may apply its own antitrombone solution.
In hybrid scenario when non-CAMEL and CAMEL are present, ARP shall not be allowed to implement
anti-trombone solution of its own as defined in the High level specifications document.
page 32/96
2.3.4 Interface Primitives
The CAMEL operations that may be used for enabling the decoupling of roaming retail service for
voice control are:
DSP to ARP
 Initial DP (IDP)
 Event Report BCSM (ERB)
 Apply Charging Report (ACR)

Call Information Report (CIRp)
ARP to DSP
 Activity Test (AT)
 Apply Charging (ACH)
 Call Information Request (CIRq)
 Continue (CUE)
 Furnish Charging Information (FCI)



Release Call (RC)
Request Report BCSM (RRB)
Reset Timer (RT)
The actual availability and support of these operations depends on the HPMN CAMEL roaming
agreements (e.g. CAMEL phase) and DSP capability (e.g. capability of brokering the message,
interworking limitations with actual protocol being used (INAP for MT Call), etc).
The support of other CAMEL operations (e.g. Connect (CON)) providing call control or operations for
user interactions (e.g. Play Announcement) goes beyond the decoupling requirement and hence, shall
be defined as part of the DSP-ARP agreement.
2.3.5 Parameters, Definitions and Use
The parameters of the primitives are as specified in GSM TS 03.78 and GSM TS 09.78 (for CAMEL
Phase 1 and CAMEL Phase 2) and 3GPP TS 23.078 and 3GPP TS 29.078 (for CAMEL Phase 3 and
CAMEL Phase 4).
2.3.6 Error handling
2.3.6.1
System related errors
The following errors can occur when forwarding (option 1) or sending (option 2) call control and/or
charging control to ARP:
-
The ARP’s SCP does not respond to IDP sent by DSP.
-
The signalling connection between DSP and ARP is not operational.
-
Proxy device deployed between ARP and DSP is not operational.
In all of the above scenarios, the DSP shall reject the call establishment by returning an IDP Error to
MSC of the VPMN, for MO calls or MF calls, or to the GMSC of DSP, for MT calls or MF calls.
As a corollary of the above requirements, the DCH (Default-Call-Handling) in the O-CSI that is sent to
the VLR in VPMN or to the GMSC of DSP, as well as the DCH in the T-CSI that is sent to the GMSC
of DSP, shall be set to “RELEASE”.
page 33/96
2.3.6.2
Error handling in MO calls
When the calling subscriber does not belong to this ARP, ARP shall reject the CAMEL service
invocation by returning an IDP Error with error code MissingCustomerRecord.
When the ARP subscriber is currently not within ARP coverage, ARP shall reject the CAMEL service
invocation by returning an IDP Error with error code UnexpectedDataValue.
When ARP determines from the Called Party BCD Number in the CAP IDP operation that the
destination of the call does not represent a destination within ARP destination set, then ARP shall
reject the CAMEL service invocation by returning an IDP Error with error code ParameterOutOfRange.
Note
The above cases constitute ‘error cases’, in which DSP should not have invoked the
CAMEL service at ARP.
When the ARP subscriber doesn’t have sufficient credit for the call at hand, ARP shall the reject the
call establishment through the use of ReleaseCall. The cause value used in this call case shall be
agreed between ARP and DSP.
2.3.6.3
Error handling in MT calls
When the called subscriber does not belong to this ARP, ARP shall reject the CAMEL service
invocation by returning an IDP Error with error code MissingCustomerRecord.
When the ARP subscriber is currently not within ARP coverage, ARP shall reject the CAMEL service
invocation by returning an IDP Error with error code UnexpectedDataValue.
Note
The above cases constitute ‘error cases’, in which DSP should not have invoked the
CAMEL service at ARP.
When subscriber doesn’t have sufficient credit for the call at hand, ARP shall the reject the call
establishment through the use of ReleaseCall. The cause value used in this call case shall be agreed
between ARP and DSP.
page 34/96
2.4
SI-IF2 : SMS Control
2.4.1 Context
The observation of the current implementation of online charging methods for SMS roaming has
shown a lack of a single common approach in the industry.
While it is fully available in the standards, the adoption of CAMEL phase 3 in the roaming context
remains anecdotic. However, if a roaming agreement using CAMEL phase 3 (SMS control) exists
between the visited network and the home PLMN, it is likely that the DSP will leverage its existence for
decoupling the roaming service with the ARP.
The “home-routed” nature of the SMS has rather led operators to develop alternative techniques to
avoid the operational burden of roaming tests. This is based on intercepting the MAP SMS-MO
operations and subsequently allowing its process after interacting with the OCS.
There are typically multiple available approaches for interacting with the OCS and charge the
customer:



using a SS7 signalling (CAMEL phase 1,2 or 3, MAP, etc)
using Diameter
using near-realtime CDR for a “hot” billing approach
The recommended approach shall focus on using CAMEL phase 3 directly, a “MAP to CAMEL”
interworking function or “MAP to Diameter” interworking function.
The hot billing method is not recommended and shall only be used under mutual agreement. Indeed,
in the context of ARP roaming, there might dispute due to conflicting decision (SMS-C accepts the
SMS-MO leading to wholesale charges while the customer might be actually out of credit).
A private dispute resolution process should be put in place in case of such near-realtime scenario is
applied.
Since the purpose of these guidelines is to define a common online interface for any DSP to any
ARP, it is assumed the DSP will enhance its current implementation in order to comply with the
proposed interface based on CAMEL for SMS control or Diameter.
It is expected that most of DSPs may have to implement additional conversion/interworking function in
their network; hence, the applied recommendation is expected to follow the most “natural” or futureproof evolution from the existing DSP implementation.
page 35/96
2.4.2 Description
SMS real-time charging shall be based on standard protocol for online charging of SMS i.e. CAMEL
for SMS control (CAMEL phase3 onwards) or Diameter.
SCP
OCS
ARP
IF2a
CAMEL
For SMS control
DSP
Retail charging
IF2b
OR
Diameter
SMS Proxy
VMSC/SGSN
Visited Network
Figure 20 – SMS architecture and associated functions
The “home-routed” nature of the SMS has led operators to develop alternative techniques to avoid the
operational burden of roaming tests. This is based on intercepting the MAP SMS-MO operations and
to trigger the OCS before acknowledging the message.
This is depicted in the figure below.
In the context of decoupling roaming service, the MAP intercept function and SMS-C reside in the
DSP network while the OCS resides at the ARP.
When there isn’t any CAMEL agreement for SMS control in place between the HPMN and the VPMN,
the DSP shall ensure a real-time interface based on a MAP intercept function to be in place.
The call flow below illustrates the sought mechanism – however it is an implementation choice to
define where to implement the MAP intercept and the relevant protocol to reach the SMS-proxy on the
DSP side.
HPMN – MAP interception function
VPMN – MSC/VLR (*)
DSP – SMS Proxy
HPMN - SMSC
ARP - OCS
MO-FWD-SM or FWD-SM
Cg SCCP – MSC/V GT
Cd SCCP – SMSC/H GT
MAP Payload
IMSI – IMSI
SM-RP-DA – SMSC/H GT
SM-RP-OA – MSISDN (ARP)
TP-Destination Address (TP-DA)
Credit Check
Credit Reservation + Event Arming
MO-FWD-SM or FWD-SM
MO-FWD-SM or FWD-SM ACK
Submit Event Notification
MO-FWD-SM or FWD-SM ACK
(*) The same flow is applicable for SGSN-originated SMS
Figure 21 – Generic SMS interception mechanism for online charging
page 36/96
The MAP intercept function and the SMS-C function are shown as different entities for clarity reasons;
they could be located with the same network element i.e. within the SMSC platform.
The SMS/MAP intercept will be responsible for verifying that the user has credit on the account by
initiating a CAMEL dialogue or Diameter credit control session.
Additionally, it may run a format check verifying that the destination number is part of the ARP
coverage, identifying the sending party is an ARP customer, etc.
Depending on the actual DSP implementation, the interface used for credit checks is recommended to
contain different level of functionality to ensure correct retail as well as wholesale charging. This shall
ensures that the decoupling method does not introduce any caveat: the SMSC may, for example, not
process the SMS-MO although the ARP OCS allowed it.


When the interface is based on Diameter and the credit check is done
o
Prior to MO process then additional functionality is recommended in the interface in
order to ensure the retail process is in line with the actual SMS processing at the
SMSC. This can be done by a credit reservation and arming processing events or an
immediate charging with refund capability.
o
After MO process of the SMS is done then Immediate Event Charging (IEC) without
refunding capability is enough to ensure correct charging.
Similarly, for a Camel based interface,
o
In case credit check is done prior to the SMS process the mentioned procedure with
credit reservation and arming event is recommended to be implemented.
o
if the credit check is done after the actual MO SMS processing, then there is no need
to use the Request Report SMS and Event Report SMS procedure ; the direct process
of the credit control based on the IDP is sufficient.
When a subscriber sends an SMS that exceeds the permissible length for SMS, then the UE may offer
the subscriber to send the SMS as “concatenated SMS”.
The concatenated SMS is sent as two or more individual SM’s through the network.
In general, each SMS of a concatenated SMS will trigger its own online charging service.
2.4.3 CAMEL for SMS Control
Sample call flows are mentioned below.
Their purpose is to illustrate the principles and only relevant parameters are shown.
The actual implementation remains operator-specific.
The sending of SMS from SGSN is similar and can be deducted easily.
The initial purpose of the IF2 interface is to deliver online charging control.
Because CAMEL provides both call and charging control facilities jointly, the use of call control
operations (e.g. CONNECT-SMS and event report with interrupt mode) must be mutually agreed.
Beyond the ability of using the CONNECT-SMS operations, the set of modified destination subscriber
number and the arming of specific event shall be mutually agreed by the DSP and ARP.
This would prevent from abusing the DSP with the call control facilities provided (e.g. rerouting
number to fraudulent destinations).
page 37/96
The use of CONTINUE-SMS or RELEASE-SMS shall always be supported.
Existing roaming agreement allowing SMS control over CAMEL
Roaming agreement using CAP3 may exist, DSP shall detect that IDP-SMS shall be passed to the
ARP instead of its own OCS, when relevant.
Similarly to the implementation options presented in the IF1, the DSP may provide the CAMEL
messages:
- Relaying at SCCP level;
- Relaying at CAP Application level.
The reader should refer to IF1 section for getting an overview of the implications of choosing one or
the other method.
HPMN – SMS Proxy
VPMN – MSC/VLR (*)
HPMN - SMSC
IDP-SMS
IDP-SMS
Cg SCCP – MSC/V GT
Cd SCCP – gsmSCF GT
CAP Payload
Service Key
Destination Subscriber Number
Calling Party Number
IMSI
MSC number
SMSC number
[…]
Cg SCCP – SMS Proxy GT
Cd SCCP – ARP OCS GT
CAP Payload
Service Key
Destination Subscriber Number
Calling Party Number
IMSI
MSC number
SMSC number
REQUEST REPORT SMS Event
REQUEST REPORT SMS Event
Cg SCCP – ARP OCS GT
Cd SCCP – SMS Proxy GT
CAP Payload
Eventype : o-smsSubmission
Notify and continue
Eventtype: o-smsFailure
Notify and continue
CONTINUE-SMS
CONTINUE-SMS
MO-FWD-SM
MO-FWD-SM ACK
EVENT REPORT SMS
EVENT REPORT SMS
Cg SCCP – MSC/V OCS GT
Cd SCCP – gsmSCF GT
CAP Payload
Event: o-smsSubmission
Notification
Figure 22 – SMS control over CAMEL (existing roaming agreement)
CAP IDP-SMS does not contain any indication that the SMS is part of a concatenated SMS.
The DSP shall preferably use a Default Call Handling – RELEASE in the SMS-CSI.
It is recommended to use the SMS Event Report in this scenario.
page 38/96
ARP - OCS
Non-Existing roaming agreement allowing SMS control over CAMEL
When there isn’t any CAMEL agreement for SMS control in place between the HPMN and the VPMN,
the DSP shall ensure a real-time interface based on a MAP intercept function is in place.
The call flow below illustrates the sought mechanism – however it is an operator decision to define
where to implement the MAP intercept and the relevant protocol to reach the SMS-proxy on the DSP
side.
However, the protocol between the SMS-Proxy and the ARP-OCS shall be CAP3 for SMS-control.
VPMN – MSC/VLR (*)
HPMN – MAP intercept
MO-FWD-SM or FWD-SM
Cg SCCP – MSC/V GT
Cd SCCP – SMSC/H GT
MAP Payload
IMSI – IMSI
SM-RP-DA – SMSC/H GT
SM-RP-OA – MSISDN (ARP)
TP-Destination-Address (TP-DA)
HPMN – SMS Proxy
HPMN - SMSC
ARP - OCS
IDP-SMS
Cg SCCP – MAP intercept GT
Cd SCCP – SMS Proxy GT
CAP Payload
Service Key
Destination Subscriber Number
Calling Party Number
IMSI
MSC number
SMSC number
[…]
IDP-SMS
Cg SCCP – SMS Proxy GT
Cd SCCP – ARP OCS GT
CAP Payload
Service Key
Destination Subscriber Number
Calling Party Number
IMSI
MSC number
SMSC number
[…]
REQUEST REPORT SMS Event
REQUEST REPORT SMS Event
CONTINUE-SMS or CONNECTSMS
Cg SCCP – ARP OCS GT
Cd SCCP – Proxy SMS GT
CAP Payload
Eventype : o-smsSubmission
Notify and continue
Eventtype: o-smsFailure
Notify and continue
CONTINUE-SMS or CONNECT-SMS
MO-FWD-SM or FWD-SM
Cg SCCP – MAP intercept GT
Cd SCCP – SMSC/H GT
MAP Payload
IMSI – IMSI
SM-RP-DA – SMSC/H GT
SM-RP-OA – MSISDN (ARP)
(modified) TP-Destination-Address
(TP-DA)
MO-FWD-SM or FWD-SM ACK
EVENT REPORT SMS
Cg SCCP – MSC/V OCS GT
Cd SCCP – gsmSCF GT
CAP Payload
Event: o-smsSubmission
Notification
MO-FWD-SM or FWD-SM ACK
Figure 23 – SMS control over CAMEL (MAP intercept)
As indicated previously, the use of event reports depends on the actual implementation as stated
above.
page 39/96
2.4.3.1
CAMEL Control Limitations
The use SMS Submission and Failure event report is optional, but recommended when the interaction
with the OCS happens before the actual SMS processing.
This enables the alignment between the retail control and the wholesale activity: if the SMSC cannot
process the MO-SMS request, the actual retail charging shall not happen as a failure report will be
received at the ARP side.
In case the ARP does not support the use of these events, the DSP shall not be liable for any
inconsistencies between the SMS retail mechanism and the SMS wholesale mechanism (e.g. SMSC
processing).
In case the DSP does not support the use of these events, the DSP shall ensure a mutually agreed
dispute resolution procedure is in place for solving the cases where the ARP customer is charged
while the SMS is not processed by SMSC.
2.4.3.2
CAMEL Control Restrictions
The ARP shall not be allowed to modify the SMS-C being used by the subscriber as the roaming
relationship (VPMN-HPMN) should remain under the full control of the DSP.
2.4.4 DIAMETER
In case of using Diameter the DSP will perform unit determination and the ARP will be responsible for
charging determination, referred to as Decentralized Unit Determination and Centralized Rating in
3GPP TS 32.299.
Two cases for control of user credit for online charging are possible when charging SMS:
• Immediate Event Charging (IEC) and
• Event Charging with Unit Reservation (ECUR).
In the case of Immediate Event Charging (IEC), the credit control process for events is controlled by
the corresponding CC-Requested-Type EVENT_REQUEST that is sent with Credit-Control-Request
(CCR) for a given credit control event.
A refund using Direct debiting operation should be performed, when the service charged previously
through Direct Debiting Operation is finally proved to be unsuccessfully delivered.
page 40/96
VPMN – MSC/VLR (*)
HPMN – SMS Proxy
HPMN – MAP intercept
MO-FWD-SM or FWD-SM
Cg SCCP – MSC/V GT
Cd SCCP – SMSC/H GT
MAP Payload
IMSI – IMSI
SM-RP-DA – SMSC/H GT
SM-RP-OA – MSISDN (ARP)
TP-Destination-Address (TP-DA)
HPMN - SMSC
ARP - OCS
DIAMETER CCR
DIAMETER CCR
Destination-host AVP – SMS proxy
hostname
Subscription-Id AVP – ARP client MSISDN
Originator-SCCP-Adress – MSC/V GT
Recipient-Received-Address= destination
MSISDN
Requested-Action AVP DIRECT_DEBITING
Destination-host AVP – ARP OCS
hostname
Subscription-Id AVP – ARP client MSISDN
Originator-SCCP-Adress – MSC/V GT
Recipient-Received-Address= destination
MSISDN
Requested-Action AVP DIRECT_DEBITING
DIAMETER CCA
DIAMETER CCA
CC-Request-Type AVP EVENT_REQUEST
Refund-Information AVP
CC-Request-Type AVP EVENT_REQUEST
Refund-Information AVP
MO-FWD-SM or FWD-SM
Cg SCCP – MAP intercept GT
Cd SCCP – SMSC/H GT
MAP Payload
IMSI – IMSI
SM-RP-DA – SMSC/H GT
SM-RP-OA – MSISDN (ARP)
TP-Destination-Address (TP-DA)
MO-FWD-SM or FWD-SM ACK
MO-FWD-SM or FWD-SM ACK
Figure 24 – SMS control over Diameter (MAP intercept and IEC mode)
In the case of Event Charging with Unit Reservation (ECUR) the CC-Request-Type INITIAL /
TERMINATION_REQUEST are used for charging for a given credit control event, however, where a
reservation is made prior to service delivery and committed on execution of a successful delivery.
page 41/96
VPMN – MSC/VLR (*)
HPMN – MAP intercept
MO-FWD-SM or FWD-SM
Cg SCCP – MSC/V GT
Cd SCCP – SMSC/H GT
MAP Payload
IMSI – IMSI
SM-RP-DA – SMSC/H GT
SM-RP-OA – MSISDN (ARP)
TP-Destination-Address (TP-DA)
HPMN – SMS Proxy
HPMN - SMSC
ARP - OCS
DIAMETER CCR
Destination-host AVP – SMS proxy
hostname
Subscription-Id AVP – ARP client MSISDN
Originator-SCCP-Adress – MSC/V GT
Recipient-Received-Address= destination
MSISDN
CC- Request-Type AVP -INITIAL
REQUEST
Request Service Unit AVP – 1 unit
DIAMETER CCR
Destination-host AVP – ARP OCS hostname
Subscription-Id AVP – ARP client MSISDN
Originator-SCCP-Adress – MSC/V GT RecipientReceived-Address= destination MSISDN
CC- Request-Type AVP -INITIAL REQUEST
Request Service Unit AVP – 1 unit
DIAMETER CCA
DIAMETER CCA
CC-Request-Type AVP - INITIAL_REQUEST
Granted Service Unit AVP – 1 unit
CC-Request-Type AVP INITIAL_REQUEST
Granted Service Unit AVP – 1 unit
MO-FWD-SM or FWD-SM
Cg SCCP – MAP intercept GT
Cd SCCP – SMSC/H GT
MAP Payload
IMSI – IMSI
SM-RP-DA – SMSC/H GT
SM-RP-OA – MSISDN (ARP)
TP-Destination-Address (TP-DA)
MO-FWD-SM or FWD-SM ACK
MO-FWD-SM or FWD-SM ACK
DIAMETER CCR
CC-Request-Type AVP – TERMINATION
REQUEST
Used Unit Service AVP – 1 unit
DIAMETER CCR
CC-Request-Type AVP – TERMINATION REQUEST
Used Unit Service AVP – 1 unit
DIAMETER CCA
DIAMETER CCA
CC-Request-Type AVP - TERMINATION REQUEST
CC-Request-Type AVP TERMINATION REQUEST
Figure 25 – SMS control over Diameter (MAP intercept and ECUR mode)
The decision whether to apply IEC or ECUR is based on DSP capabilities.
2.4.5 Detailed Procedures at DSP
In the absence of CAP3 roaming agreement the SMSC or other network element involved in the MOSMS data path will have to initiate a credit / charging control session to the OCS of the ARP.
Hence a MAP to CAP or DIAMETER translation has to be performed.
The corresponding mapping table can be found in section 1.1.5.
Before initiating the credit control procedure, the DSP will check:
- The subscriber type: ARP or DSP
- The subscriber status: Realtime or offline charging
- The ARP subscriber is under the ARP coverage :
o the recipient number is a ARP-served number (e.g. a regulated destination or any
other destination mutually agreed)
page 42/96
o
the sender is located within the ARP footprint (e.g. in the Union or any location
mutually agreed).
The DSP will await ARP answer and process:
-
The positive / negative answer, as provided by the ARP
-
The DSP will time-out the transaction in case of no answer from the ARP
o Time Out is based on CAMEL timers i.e. 1 to 20sec.
o The value of the timer is a DSP implementation should be based on an internal
standard implementation policy.
-
Error handling
o See the detailed ARP procedures for possible returned errors.
2.4.6 Detailed Procedures at ARP
Upon IDP trigger or CCR request, the ARP will validate the sender of the SMS is an ARP customer
and eligible for service (w.r.t its current location and the recipient number).
The ARP will respond with the errors for the
CAMEL
DIAMETER
Subscriber does not
belong to ARP
missingCustomerRecord
DIAMETER_USER_UNKNOWN 5030
Subscriber is not
within ARP served
footprint
unexpectedDataValue
DIAMETER_END_USER_SERVICE_DENIED
4010
Recipient number of
the SMS is not within
ARP destination set
parameterOutOfRange
DIAMETER_END_USER_SERVICE_DENIED
4010
In case the ARP subscriber is not a prepaid customer and the online charging interface was used by
the HPMN, the ARP may respond with:
-
CAMEL CONTINUE-SMS
-
DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 4011
o The OCF determines that the service can be granted to the end user but no
further credit control needed for the service (e.g. service is free of charge or is
treated for offline charging).
2.4.7 Interface primitives
The CAMEL operations that may be used for enabling the decoupling of roaming retail service for
SMS control are:
From DSP to ARP:
Initial DP SMS,
Event Report SMS,
From ARP to DSP:
Continue SMS,
page 43/96
Release SMS,
Request Report SMS Event,
Furnish Charging Information SMS,
Reset Timer SMS.
The actual availability and support of these operations depends on the HPMN CAMEL roaming
agreements (e.g. CAMEL phase) and DSP capability (e.g. capability of brokering the message,
interworking limitations with actual protocol being used, etc).
The support of other operations (e.g. connect SMS) providing SMS control or other function shall be
defined as part of the DSP-ARP agreement.
The details of the primitives can be found in the relevant 3GPP standards for CAMEL – 22.078,
23.078 and 29.078.
DIAMETER primitives for Credit Control are:
Credit-Control-Request [CCR]
Credit-Control-Answer [CCA]
The details of the primitives can be found in the relevant 3GPP standards for DIAMETER – 32.299
(General) and 32.274 (SMS case).
page 44/96
2.4.8 Parameters Definitions and Use
The 3GPP standards define the mandatory and optional parameters of the primitives.
For CAMEL, the MAP -> CAMEL ph3 mapping table can be found as follows.
The table is based on 3GPP 29.078, 23.040 and 29.002 and shows the relevant parameters to be
matched between the MAP operation and the CAP operation.
SCCP parameters
Cg-SCCP Address
CAMEL parameters
Comments
MSC number
Per standard, only present if SMS
reference number present
Cg-SCCP Address
Location
number
MAP parameters
CAMEL parameters
IMSI
IMSI
n.a.
Service Key
SM-RP-DA
SMS-C
SM-RP-OA
Calling Party Number
TP-Destination-Address (TP-DA)
Destination Subscriber Number
n.a.
Event Type
SMS_Collected_Info
n.a.
Time Zone and Timestamp
Timestamp and Time Zone at the DSP – at
the time of intercepting the MAP message
1st octet of the SMS-SUBMIT
TPDU
TP Short Message Submission
TP Protocol Identifier
TP Protocol Identifier
TP Data Coding Scheme
TP Data Coding Scheme
TP Validity Period
TP Validity Period
n.a.
SMS Reference Number
Information/VLR
Best effort – copy of MSC field into
VLR
Comments
Determined by mutual agreement
between the DSP and ARP
MSISDN of the ARP customer
Specific Information
page 45/96
Determined by the MAP intercept function
In case Diameter is the chosen interface, the following MAP -> Diameter translation shall be done.
Detailed information can be found in 3GPP TS 32.274: "Telecommunication management; Charging
management; Short Message Service (SMS) charging".
The following table is based on 3GPP 32.299, 32.274, 23.040 and 29.002.
SCCP/MAP parameter
Diameter
AVP
SMS-Information
Comments
n.a.
SMS-Node
The SMS-Node AVP (AVP code
2016) is of type Enumerated and
identifies the role which the SMS
node performs in relation to the
charging event.
Cg-SCCP Address
Originator-SCCP-Address
This is usually the address of the
MSC or SGSN/Serving Node
that was serving the UE when it
submitted the SM. It contains the
Global Title, where Global Title
represents an E.164 number.
SM-RP-DA
SMSC-Address
The SMSC-Address AVP (AVP
code 2017) is of type Address
and carries the address of the
SMSC, as contained in the
SM.
TP Data Coding Scheme
Data-Coding-Scheme
n.a.
SM-Message-Type
The SM-Message-Type AVP
(AVP code 2007) indicates the
type of the message which
caused the charging interaction.
In the SMS-MO case, the value
is “0” (SUBMISSION)
TP Protocol Identifier
SM-Protocol-ID
TP-User-Data-Header-Indicator
SM-User-Data-Header
TP-Destination-Address (TP-DA)
Recipient-Info
Address
Or
/
Recipient-
A modified address (in case of optional
service rendered by the DSP)
TP-Destination-Address (TP-DA)
Recipient Received Address
SM-RP-OA
Subscription-Id
page 46/96
This field holds the address of
the recipient of the SM. This will
typically be an E.164 number or
a shortcode.
This field holds the original,
unmodified address of the
recipient of the SM, as received
by the SMS node, in case
address manipulation (such as
number plan corrections) have
been applied in the SMS node.
This will typically be an E.164
number or a shortcode
2.4.9 Error Handling
The error scenarios can be split into 2 major scenario sets:
Service Implementation Related:
1. ARP decision to reject the SMS because the subscriber doesn’t have any credit on the
account;
2. ARP decision to reject the SMS because the subscriber is not an ARP subscriber;
3. ARP decision to reject the SMS because the subscriber is not located within the ARP
coverage.
4. ARP decision to reject the SMS because the recipient number is not part of the ARP
destination set.
Breakdown / Failure Related:
1. Communication problem between DSP and ARP i.e. the ARP doesn’t respond to credit control
requests but the application layer is up ;
2. Connection (peer or signaling point) is down, it’s not possible to perform a credit control;
3. DSP failure in delivering the SMS from the ‘intercept’ function to the SMSC ;
4. Normal error handling by the DSP according to 3GPP 29.002 ;
There are no mechanisms / procedures available to deliver the SMS and do the retail charging a
posteriori. Hence, in all the above scenarios, the DSP shall reject the SMS-MO and return error to
MSC/SGSN of the Visited MNO. The actual reject can be sent by the SMSC or the MAP-interception
function.
2.4.10 Limitations
This usual architecture, leveraging the “home-routed” principle of the SMS-MO, can be subject to
Fraud cases, when the end-user or a 3rd party manipulates the destination SMSC address, making it
different from the DSP SMSC address. This is inherent to the architecture and can be minimized:


using CAMEL ph3 between Visited and Home networks,
applying SMS call barring.
The ARP should benefit from the protection mechanisms put in place by the DSP or the VPMN in
order to minimize these risks.
2.4.11 Special Use Case: Short Code
In case the DSP uses short codes for controlling its own pricing transparency solution (i.e. the
STOP/START mechanism), the DSP shall provide:
- the ARP with long number value of the short code for applying the appropriate retail charges or,
- filter the online triggers to the ARP for avoiding charging the customer for this message.
The use of short codes by ARP is out of scope of the regulation.
Therefore its implementation is subject to agreement between the DSP and the ARP.
The activation/deactivation of the transparency mechanism may happen when located in domestic
network or roaming in the ARP or DSP coverage.
page 47/96
2.4.12 Summary table
The following table summarizes the information shared between the ARP and DSP for the purpose of
setting up the interface. The actual connectivity items are out of scope.
Information
Protocol
CAP3/DIAMETER
Operational Model
Information Provider
Purpose
DSP
Identify the interfacing model
DSP
Identify the interface implementation
model
Mutually agreed
Identify the operations (call and event
control)
Mutually agreed
Identify the rerouting possibilties
ARP and DSP
Enable the continuation of the pricing
information
mechanisms
of
each
roaming provider under ARP/DSP
coverage.
Immediate Event Charging
Or
Reservation
In case of CAMEL, the list of
allowed operations (beyond the
roaming decoupling requirements)
In case of allowed CAMEL
Connect operations, the list of
agreed destination subscriber
number
Short Codes
page 48/96
2.5
SI-IF3 : Data Control
2.5.1 Architecture, Description and Definitions
Data charging is based on Diameter signalling. The same interface is designed to provide retail
charging and could also deliver Anti Bill Shock function.
Anti Bill shock
OCS
Retail charging
ARP
SI-IF3
DSP
Data Proxy
GGSN
Visited Network
SGSN
Figure 26 – Data architecture and associated functions
MMS charging can be based on event or volumes: two different architectures are proposed.
1. MMS charging on Volume is based on the same principle and interface as data charging (SIIF3a using Diameter signalling)
2. MMS charging on Event (per message) is based on an interface between the MMS proxy and
the ARP OCS (SI-IF3b using Diameter signalling).
page 49/96
OCS
Retail charging
ARP
SI-IF3a
or SI-IF3b
DSP
Visited Network
Data Proxy
MMS Proxy
GGSN
MMSC
SGSN
Figure 27 – MMS architecture and associated functions
Interfaces 3a and 3b between DSP and ARP for credit control, which includes bill shock function, shall
be based on standard 3GPP interfaces.
The Diameter Credit Control Application (DCCA) is a Diameter based application that can be used to
implement real-time credit control for a variety of end user services such as network access and
messaging services.
The following standard specifications shall apply:
 RfC 3588: Diameter Base Protocol
 RfC 6733 is replacing RFC 3588. The DSP will decide which RfC that is implemented.
 RfC 4006: Diameter Credit-Control Application
 3GPP TS 32.251: Telecommunication management; Charging management; Packet Switched (PS)
domain charging
 3GPP TS 32.270: Telecommunication management; Charging management; Multimedia
Messaging Service (MMS) charging
 3GPP TS 32.299 Telecommunication management; Charging management; Diameter charging
applications (Gy)
 3GPP TS 32.240: Telecommunication management; Charging management; Charging architecture
and principles
Further description below shall give a subset of the standard necessary to implement the minimum set
of functions enabling ARP with the charging management facilities for data services including MMS.
Additional functionality may be implemented on commercial terms. The used version of a particular
interface protocol specification is subject to mutual agreement between the DSP and ARP.
The quota management is unit based, units are measured in either volume or events. The DSP needs
to categorize the traffic using different Rating Groups, e.g. normal charging, zero-priced charging
(MMS event, ARP landing page). Each RG will create its own credit instance within a Gy session, the
different credit instance are handled separately from each other.
The DSP traffic categorization can be done using RG as the granularity i.e. several service data flows
with the same charging principle are belongs to the same RG and quota management is performed on
page 50/96
the RG. The other option of categorization introduces more granularity where quota management is
made on the combination of RG and the service data flow (service-identifier avp.
The DSP will state the level of granularity used to the ARP.
For data services session based charging with central unit determination and centralized rating shall
apply. The units are measured in volume.
For MMS charging scenario, if event based MMS charging applies; immediate event charging with
local unit determination and centralized rating shall apply.
2.5.2 Definitions
Depending on existing DSP implementations, the ARP has to support two possible methods,
according to 3GPP standard, to distinguish traffic for different purpose in DSP GGSN.
1. Multi APN strategy: If a DSP uses the multi APN strategy, the differentiation on different
services is generally determined by the APN. The DSP may make the APN usage visible to
the ARP. Charging of MMS can at the DSP based on dedicated APN or RG. Depending on
the implementation, the use of specific RG for the Quota management of MMS traffic volume
may be required in the Gy interface towards the ARP. Alternately, Quota management may
not be used for a dedicated APN, if e.g. MMS is not charged by volume.
2. Single APN strategy: A DSP using a single APN strategy (no dedicated APN for different
services) has to differentiate services by using rating groups: for example, in the case of MMS,
the DSP shall provide a second rating group to the ARP allowing charging MMS based on
events. In such case, the volume is accounted using a second rating group, which potentially
could be zero-rated in retail charging. The DSP may have additional RG configured,
depending on its implementation. They have to be supported by the ARP.
The Rating-Group AVP is of type Unsigned32 (AVP Code 432) and contains the identifier of a rating
group. The specific rating group the request relates to, is uniquely identified by the combination of
Service-Context-Id and Rating-Group AVPs. The definition of a rating group is DSP implementationdependant and will be given by the DSP to the ARP.
To allow sufficient operation, giving a good balance between charged volume and number of Gy
transactions, the DSP will define the size of
a. Default quota size per RG, used by the OCS when subscriber’s account has credit
enough the quota
b. Minimum quota size per RG, the minimum quota the OCS is allowed to provide when
the subscriber’s account doesn’t cover the default quota,
c. Quota threshold, when reporting shall be done.
d. Validity time, the time from when the quota is granted until GGSN will update the OCS
with the usage
e. Quota Holding Time, the time a credit instance are allowed to be idle i.e. no packets
are sent before the credit instance is terminated and GGSN will report the usage
As the standard roaming service will be offered, the charging control dialog will not include possibilities
to the ARP of setting or changing triggers in the GGSN of the DSP.
2.5.3 Detailed Procedures at DSP
The DSP will deliver all services to the customer, using GGSN and MMSC functionality.
The DSP will provide an online interface to the ARP OCS, acting as a client for direct charging control
using an event based charging interface, if event based MMS charging applies.
The DSP will provide an online interface to the ARP OCS, acting as a client for session charging
control using a session based charging interface.
page 51/96
The DSP sets parameters for data transmission to standard values, avoiding any discrimination in
terms of QoS offered to roamers.
The DSP will deliver only service to customers after successful authorization by the ARP. The DSP will
not allow transfer of payload packets to go through GGSN in case of quota hasn’t been granted by
ARP.
The DSP will deliver service differentiation (Data / MMS) either by APN or by Rating Group method
dependant on existing implemented methods.
Detailed Procedures at ARP
The ARP acts as OCS server for all data services.
The ARP has to grant volume quota for all chargeable services prior to usage i.e. responding to the
CCR.
2.5.4 Interface primitives
The charging control is based on Diameter Credit Control (DCC) using pairs of request and answer
messages (CREDIT-CONTROL-REQUEST (CCR) – CREDIT-CONTROL-ANSWER (CCA)). The use
cases are start, mid-session and termination control (it corresponds to the request type: Initial, Update
and Terminate).
For immediate event charging also event type ‘event’ is also used.
Details on content for the messages can be found in the Parameters Definitions and Use sections.
For termination of data session, either the customer or the OCS of ARP terminates the session. The
ARP can terminate the session using temporary or permanent error codes on command level. Error
codes on the MSCC level is only valid for the credit instance and will not lead to a disconnect of the
data session
Optionally the DSP may give ARP the possibility, depending on markets and commercial agreements,
to redirect traffic to Top-up Server of ARP.
MMS event charging is controlled by DCC messages between MMS proxy and ARP OCS.
2.5.4.1
Start of Data session
The DSP will state whether the CCR (I) will be sent prior to establishing the PDP session or if it will be
sent upon receiving the first payload packet.
Authentication and quota management can be combined within the CCR initial. If the DSP is splitting
the OCS authorization and quota management then a two-steps handling takes place.
The implementation of the Diameter dialog depends on needs for getting minimum quota together with
the PDP context establishment.
The three following scenarios are depicted hereafter and work without changes in ARP
implementations.
The following figure illustrates the scenario when the CCR (I) is sent during establishing the PDP
session and authentication and quota management is combined within the CCR (I). A default quota is
requested during the authentication.
page 52/96
VPLMN SGSN
GGSN
Create PDP Context
Request
(REQUESTED APN)
Create PDP Context
Response
OCS Data Proxy
DIAMETER CCR
CREDIT-CONTROL-REQUEST
(INITIAL_REQUEST, MULTIPLE-SERVICESCREDIT CONTROL (REQUESTED-SERVICEUNIT, SERVICE IDENTIFIER, VALIDITY-TIME,
UNIT-QUOTA-TRESHOLD, RATING GROUP))
DIAMETER CCA
CREDIT-CONTROL-ANSWER
(INITIAL_REQUEST, MULTIPLE-SERVICESCREDIT CONTROL (GRANTED-SERVICEUNIT, SERVICE IDENTIFIER, VALIDITY-TIME,
UNIT-QUOTA-TRESHOLD, RATING GROUP))
ARP - OCS
DIAMETER CCR
CREDIT-CONTROL-REQUEST (INITIAL_REQUEST, MULTIPLESERVICES-CREDIT CONTROL (REQUESTED-SERVICE-UNIT,
SERVICE IDENTIFIER, VALIDITY-TIME, UNIT-QUOTA-TRESHOLD,
RATING GROUP))
DIAMETER CCA
CREDIT-CONTROL-ANSWER (INITIAL_REQUEST, MULTIPLESERVICES-CREDIT CONTROL (GRANTED-SERVICE-UNIT,
SERVICE IDENTIFIER, VALIDITY-TIME, UNIT-QUOTA-TRESHOLD,
RATING GROUP))
Service delivery
Figure 28 – Start of Data Session call flow: control at PDP context creation
1.
2.
3.
4.
5.
6.
7.
End User initiates a PDP context request
The DSP prepare a data session e.g.
a.
authenticates the user request
b.
turn on Gy interfaces for this user and ARP
c.
assigned an IP address is to the user
d.
bitrate is set to standard, no dynamic bitrate is supported
DSP sends a quota request via Data Proxy using in the CREDIT-CONTROLREQUEST ( INITIAL_REQUEST) message to the ARP OCS.
ARP OCS receive a quota request via Data Proxy using in the CREDIT-CONTROLREQUEST ( INITIAL_REQUEST ) message from DSP.
ARP checks customer account
The ARP OCS responds with the Credit-Control-Answer (INITIAL_REQUEST )
message to Data Proxy granting the requested quota.
The DSP receive the Credit-Control-Answer (INITIAL_REQUEST) message via DATA
Proxy granting the requested quota. The DSP will if applicable setup the PDP context
and will allow service usage.
The following figure illustrates the scenario when the CCR (I) is sent after establishing the PDP
session and authentication and quota management is combined within the CCR (I) and triggered by
the start of the data transmission.
page 53/96
VPLMN SGSN
GGSN
OCS Data Proxy
ARP - OCS
Create PDP Context
Request
(REQUESTED APN)
Create PDP Context
Response
Service delivery
DIAMETER CCR
CREDIT-CONTROL-REQUEST
(INITIAL_REQUEST, MULTIPLE-SERVICESCREDIT CONTROL (REQUESTED-SERVICEUNIT, SERVICE IDENTIFIER, VALIDITY-TIME,
UNIT-QUOTA-TRESHOLD, RATING GROUP))
DIAMETER CCA
CREDIT-CONTROL-ANSWER
(INITIAL_REQUEST, MULTIPLE-SERVICESCREDIT CONTROL (GRANTED-SERVICEUNIT, SERVICE IDENTIFIER, VALIDITY-TIME,
UNIT-QUOTA-TRESHOLD, RATING GROUP))
DIAMETER CCR
CREDIT-CONTROL-REQUEST (INITIAL_REQUEST, MULTIPLESERVICES-CREDIT CONTROL (REQUESTED-SERVICE-UNIT,
SERVICE IDENTIFIER, VALIDITY-TIME, UNIT-QUOTA-TRESHOLD,
RATING GROUP))
DIAMETER CCA
CREDIT-CONTROL-ANSWER (INITIAL_REQUEST, MULTIPLESERVICES-CREDIT CONTROL (GRANTED-SERVICE-UNIT,
SERVICE IDENTIFIER, VALIDITY-TIME, UNIT-QUOTA-TRESHOLD,
RATING GROUP))
Figure 29 – Start of Data Session call flow: control at first packet received
1.
2.
End User initiates a PDP context request
The DSP prepares a data session e.g.
a.
authenticates the user request
b.
turns on Gy interfaces for this user and ARP
c.
assigns an IP address to the user
d.
bitrate is set to standard, no dynamic bitrate is supported
3.
The DSP may decide to accept PDP context request at this stage and trigger charging
control at first usage or can authenticate already the PDP context request against the
OCS of ARP.
DSP sends a quota request via Data Proxy using in the CREDIT-CONTROL-REQUEST
(INITIAL_REQUEST) message to the ARP OCS.
ARP OCS receives a quota request via Data Proxy using in the CREDIT-CONTROLREQUEST (INITIAL_REQUEST) message from DSP.
ARP checks customer account.
The ARP OCS responds with the Credit-Control-Answer (INITIAL_REQUEST) message to
Data Proxy granting the requested quota.
The DSP receives the Credit-Control-Answer (INITIAL_REQUEST) message via DATA
Proxy granting the requested quota. The DSP will, if applicable, setup the PDP context
and will allow service usage.
4.
5.
6.
7.
8.
The following figure illustrates the scenario when the CCR (I) for authentication is sent during
establishing the PDP session and the quota management is done afterwards by CCR (U) triggered by
the start of the data transmission.
page 54/96
VPLMN SGSN
GGSN
Create PDP Context
Request
(REQUESTED APN)
Create PDP Context
Response
OCS Data Proxy
DIAMETER CCR
CREDIT-CONTROL-REQUEST
(INITIAL_REQUEST)
DIAMETER CCA
CREDIT-CONTROL-ANSWER
(INITIAL_REQUEST)
ARP - OCS
DIAMETER CCR
CREDIT-CONTROL-REQUEST (INITIAL_REQUEST)
DIAMETER CCA
CREDIT-CONTROL-ANSWER (INITIAL_REQUEST)
Service delivery
DIAMETER CCR
CREDIT-CONTROL-REQUEST
(UPDATE_REQUEST, MULTIPLE-SERVICESCREDIT CONTROL (REQUESTED-SERVICEUNIT, SERVICE IDENTIFIER, VALIDITY-TIME,
UNIT-QUOTA-TRESHOLD, RATING GROUP))
DIAMETER CCA
CREDIT-CONTROL-ANSWER
(UPDATE_REQUEST, MULTIPLE-SERVICESCREDIT CONTROL (GRANTED-SERVICEUNIT, SERVICE IDENTIFIER, VALIDITY-TIME,
UNIT-QUOTA-TRESHOLD, RATING GROUP))
DIAMETER CCR
CREDIT-CONTROL-REQUEST (UPDATE_REQUEST, MULTIPLESERVICES-CREDIT CONTROL (REQUESTED-SERVICE-UNIT,
SERVICE IDENTIFIER, VALIDITY-TIME, UNIT-QUOTA-TRESHOLD,
RATING GROUP))
DIAMETER CCA
CREDIT-CONTROL-ANSWER (UPDATE_REQUEST, MULTIPLESERVICES-CREDIT CONTROL (GRANTED-SERVICE-UNIT,
SERVICE IDENTIFIER, VALIDITY-TIME, UNIT-QUOTA-TRESHOLD,
RATING GROUP))
Service delivery
Figure 30 – Start of Data Session call flow: split authentication and quota management
1.
2.
End User initiates a PDP context request
The DSP prepares a data session e.g.
a. authenticates the user request;
b. turns on Gy interfaces for this user and ARP;
c. assigns an IP address to the user;
d. bitrate is set to standard, no dynamic bitrate is supported.
3.
The DSP may decide to accept PDP context request at this stage and trigger charging
control at first usage or can authenticate already the PDP context request against the
OCS of ARP.
DSP sends a CREDIT-CONTROL-REQUEST (INITIAL_REQUEST) message to the ARP
OCS.
ARP OCS receives CREDIT-CONTROL-REQUEST (INITIAL_REQUEST) message from
DSP.
ARP checks customer account.
The ARP OCS responds with the Credit-Control-Answer (INITIAL_REQUEST) message to
the Data Proxy to allow further proceeding.
The DSP receive the Credit-Control-Answer (INITIAL_REQUEST) message via DATA
Proxy.
The DSP will if applicable setup the PDP context and will allow service usage.
If the DSP detects the beginning of Data transmission, DSP sends the CREDITCONTROL-REQUEST (UPDATE_REQUEST, “Rating Group”) message via Data Proxy to
ARP OCS.
4.
5.
6.
7.
8.
9.
10.
page 55/96
11.
12.
13.
2.5.4.2
ARP OCS receives CREDIT-CONTROL-REQUEST (UPDATE_REQUEST ) messages and
grant volume
ARP OCS responds with CREDIT-Control-Answer ( UPDATE_REQUEST ) message to
grant quota.
The DSP receives the CREDIT-Control-Answer ( UPDATE_REQUEST, “Rating Group” )
message via Data Proxy granting quota.
Data Mid-session update and control
VPLMN SGSN
GGSN
OCS Data Proxy
ARP - OCS
Service delivery
DIAMETER CCR
CREDIT-CONTROL-REQUEST
(UPDATE_REQUEST, MULTIPLE-SERVICESCREDIT CONTROL (REQUESTED-SERVICEUNIT, SERVICE IDENTIFIER, VALIDITY-TIME,
UNIT-QUOTA-TRESHOLD, RATING GROUP))
DIAMETER CCA
CREDIT-CONTROL-ANSWER
(UPDATE_REQUEST, MULTIPLE-SERVICESCREDIT CONTROL (GRANTED-SERVICEUNIT, SERVICE IDENTIFIER, VALIDITY-TIME,
UNIT-QUOTA-TRESHOLD, RATING GROUP))
DIAMETER CCR
CREDIT-CONTROL-REQUEST (UPDATE_REQUEST, MULTIPLESERVICES-CREDIT CONTROL (REQUESTED-SERVICE-UNIT,
SERVICE IDENTIFIER, VALIDITY-TIME, UNIT-QUOTA-TRESHOLD,
RATING GROUP))
DIAMETER CCA
CREDIT-CONTROL-ANSWER (UPDATE_REQUEST, MULTIPLESERVICES-CREDIT CONTROL (GRANTED-SERVICE-UNIT,
SERVICE IDENTIFIER, VALIDITY-TIME, UNIT-QUOTA-TRESHOLD,
RATING GROUP))
Service delivery
Figure 31 – Middle of Data Session call flow
Note The procedure is used for CCR update (e.g. Quota or time period expires) procedures.
In case of quota or time period expires no Update PDP Context Update Procedure between the SGSN
and GGSN applies.
1.
2.
3.
4.
5.
DSP operates data session on given quota, quota threshold and optional set guard time
period.
If either quota or the optional time period expires, DSP sends the CREDIT-CONTROLREQUEST (UPDATE_REQUEST, “Rating Group”) message via Data Proxy with used
volume to ARP OCS.
ARP OCS receives CREDIT-CONTROL-REQUEST (UPDATE_REQUEST) messages as
report of used volume and request to grant additional volume.
ARP OCS responds with CREDIT-Control-Answer ( UPDATE_REQUEST) message to
grant additional quota.
The DSP receives the CREDIT-Control-Answer ( UPDATE_REQUEST, “Rating Group” )
message via Data Proxy granting additional quota.
page 56/96
2.5.4.3
Data session termination by user
VPLMN SGSN
GGSN
OCS Data Proxy
ARP - OCS
Service delivery
Delete PDP Context
Request
DIAMETER CCR
DIAMETER CCR
CREDIT-CONTROL-REQUEST
(TERMINATION_REQUEST, USED_UNITS)
Delete PDP Context
Response
CREDIT-CONTROL-REQUEST (TERMINATION_REQUEST,
USED_UNITS)
DIAMETER CCA
DIAMETER CCA
CREDIT-CONTROL-ANSWER
(TERMINATION_REQUEST)
CREDIT-CONTROL-ANSWER (TERMINATION_REQUEST)
Figure 32 – Termination of Data Session call flow (user-termination)
1. The user terminates a PDP context.
2. The DSP sends a CREDIT-CONTROL-REQUEST (TERMINATION_REQUEST) via Data
Proxy to ARP OCS to report session termination including final volume used.
3. ARP OCS receives CREDIT-CONTROL-REQUEST (TERMINATION_REQUEST) message
on PDP context termination.
4. ARP OCS sends CREDIT-CONTROL-ANSWER (TERMINATION REQUEST) message to
DSP.
5. ARP updates customer account.
6. DSP receives the CREDIT-CONTROL-ANSWER (TERMINATION REQUEST) message via
DATA Proxy
page 57/96
2.5.4.4
Credit session terminated by ARP OCS with FINAL-UNIT-ACTION=TERMINATE
VPLMN SGSN
ARP - OCS
OCS Data Proxy
GGSN
Service delivery
DIAMETER CCR
CREDIT-CONTROL-REQUEST
(UPDATE_REQUEST)
DIAMETER CCA
CREDIT-CONTROL-ANSWER
(UPDATE_REQUEST (FINAL-UNITINDICATION(FINAL-UNIT-INDICATION (FINALUNIT-ACTION= TERMINATE))
DIAMETER CCR
CREDIT-CONTROL-REQUEST
(UPDATE_REQUEST, USED_UNITS)
DIAMETER CCA
CREDIT-CONTROL-ANSWER
(UPDATE_REQUEST)
DIAMETER CCR
CREDIT-CONTROL-REQUEST (UPDATE_REQUEST)
DIAMETER CCA
CREDIT-CONTROL-ANSWER (UPDATE_REQUEST (FINAL-UNITINDICATION(FINAL-UNIT-INDICATION (FINAL-UNIT-ACTION=
TERMINATE))
DIAMETER CCR
CREDIT-CONTROL-REQUEST (UPDATE_REQUEST, USED_UNITS)
DIAMETER CCA
CREDIT-CONTROL-ANSWER (UPDATE_REQUEST)
Figure 33 – Termination of Data Session call flow (ARP-termination)- case 1
1. The DSP may receive as answer, either on INITIAL-REQUEST or UPDATE, the CreditControl-Answer (Update_Request (Final-Unit-Indication (Final-Unit-Indication (Final-UnitAction= Terminate)) message.
2. DSP sends Credit-Control-Request (Update_Request, Used_Units) to ARP OCS.
3. ARP OCS responds with Credit-Control-Answer (Update_Request) message
Note Other possibilities to terminate the session including deleting the PDP Context on Diameter
Command level are not excluded.
page 58/96
2.5.4.5
Data session terminated by ARP OCS with CC-Session Failover (result code 4012,
DIAMETER_CREDIT_LIMIT_REACHED)
VPLMN SGSN
GGSN
OCS Data Proxy
ARP - OCS
Service delivery
DIAMETER CCR
CREDIT-CONTROL-REQUEST
(UPDATE_REQUEST)
DIAMETER CCA
Delete PDP Context
Request
CREDIT-CONTROL-ANSWER
(UPDATE_REQUEST (CC-SESSION FAILOVER
(DIAMETER_CREDIT_LIMIT_REACHED
(RESULT CODE 4012))
DIAMETER CCR
CREDIT-CONTROL-REQUEST (UPDATE_REQUEST)
DIAMETER CCA
CREDIT-CONTROL-ANSWER (UPDATE_REQUEST (CC-SESSION
FAILOVER (DIAMETER_CREDIT_LIMIT_REACHED (RESULT CODE
4012))
Delete PDP Context
Response
Figure 34 – Termination of Data Session call flow (ARP-termination) - case 2
1. The DSP may receive as answer, either on INITIAL-REQUEST or UPDATE, the CreditControl-Answer (Update_Request (CC-Session Failover DIAMETER-CREDIT-LIMITREACHED (Result Code 4012)) message.
2. The DSP terminates the data session by sending Delete PDP Context Request towards
the customer,
2.5.4.6
Credit control MMS
The event based credit control dialog will be between MMS Proxy and OCS of ARP. Data quota
handling for the plain data transmission part of a MMS within the GGSN depends on DSP
implementations.
If destination rules should apply for MMS, quota management of plain data transmission has to be
excluded: the ARP cannot be charged for MMS data volume while the message is not under his own
control due to a destination rule.
Multiple destination MMS will, DSP implementation dependant, either create a single CC session for
each recipient or request for multi-event Quota CC session.
The handling of Multiple Destination MMS where the destinations are shared between ARP and DSP
depends on the technical DSP capabilities and DSP/ARP agreement. It is not discussed further in this
document.
DSP standard retransmission policy for MMS will apply. No additional delivery reporting will be setup
to ARP.
page 59/96
2.5.4.7
MMS MO using IEC (Immediate Event Charging) without quota management for data
volume at GGSN
In the following case, the charging of the plain data transmission of the MMS is excluded, i.e. there is
no quota management applied. This is depicted in the figure hereafter.
VPLMN SGSN
GGSN
Create PDP Context
Request
MMS Relay
OCS MMS Proxy
ARP - OCS
Note 1
(Requested APN, may be
independent from MMS)
Create PDP Context
Response
(independent from MMS)
Note 2
Create PDP Context
Request
(Requested APN for MMS)
Create PDP Context
Response
MMS
MM1 Submit
Req
Message type,
Transaction ID,
MMS version,
Content type,
Recipient address,
Content
DIAMETER CCR
DIAMETER CCR
CREDIT-CONTROL-REQUEST
(EVENT_REQUEST with RequestedAction DIRECT_DEBITING, MMS
SPECIFIC AVP)
CREDIT-CONTROL-REQUEST
(EVENT_REQUEST with RequestedAction DIRECT_DEBITING, MMS
SPECIFIC AVP)
DIAMETER CCA
MM1 Submit
Res
Message type,
Transaction ID,
MMS version
Request status
CREDIT-CONTROL-ANSWER (EVENT
REQUEST)
DIAMETER CCA
CREDIT-CONTROL-ANSWER (EVENT
REQUEST)
MMS out
Figure 35 – MMS MO using IEC without quota management for data volume
page 60/96
2.5.4.8
MMS MO using IEC (Immediate Event Charging) with separate quota management for data
volume at GGSN
In this case the charging of the plain data transmission of the MMS is done by using a separate
Diameter dialog between the OCS Data Proxy and the ARP OCS before the MMS is sent. This case is
only applicable when there is no destination rules applied for MMS.
VPLMN SGSN
GGSN
MMS Relay
OCS Data Proxy
OCS MMS Proxy
ARP - OCS
Note 1
Create PDP Context
Request
DIAMETER CCR
(Requested APN, may be
independent from MMS)
CREDIT-CONTROL-REQUEST (Initial, CreditControl AVPs )
Create PDP Context
Response
DIAMETER CCA
(independent from MMS)
CREDIT-CONTROL-ANSWER (GRANTED
UNITS)
DIAMETER CCR
CREDIT-CONTROL-REQUEST (Initial,
Credit-Control AVPs)
DIAMETER CCA
CREDIT-CONTROL-ANSWER
(GRANTED UNITS)
Note 2
Create PDP Context
Request
DIAMETER CCR
DIAMETER CCR
(Requested APN for MMS)
CREDIT-CONTROL-REQUEST (Initial, CreditControl AVPs )
Create PDP Context
Response
DIAMETER CCA
MMS
CREDIT-CONTROL-ANSWER (GRANTED
UNITS)
CREDIT-CONTROL-REQUEST (Initial,
Credit-Control AVPs)
DIAMETER CCA
CREDIT-CONTROL-ANSWER
(GRANTED UNITS)
MM1 Submit
Req
Message type,
Transaction ID,
MMS version,
Content type,
Recipient address,
Content
Note 3
DIAMETER CCR
DIAMETER CCR
CREDIT-CONTROL-REQUEST (Initial, CreditControl AVPs )
CREDIT-CONTROL-REQUEST (Initial,
Credit-Control AVPs)
DIAMETER CCA
DIAMETER CCA
CREDIT-CONTROL-ANSWER (GRANTED
UNITS)
CREDIT-CONTROL-ANSWER
(GRANTED UNITS)
DIAMETER CCR
DIAMETER CCR
CREDIT-CONTROL-REQUEST
(EVENT_REQUEST with RequestedAction DIRECT_DEBITING, MMS
SPECIFIC AVP)
CREDIT-CONTROL-REQUEST
(EVENT_REQUEST with RequestedAction DIRECT_DEBITING, MMS
SPECIFIC AVP)
DIAMETER CCA
MM1 Submit
Res
Message type,
Transaction ID,
MMS version
Request status
CREDIT-CONTROL-ANSWER (EVENT
REQUEST)
DIAMETER CCA
CREDIT-CONTROL-ANSWER (EVENT
REQUEST)
MMS out
Figure 36 – MMS MO using IEC with quota management for data volume
page 61/96
Note 1: In case the requested APN is generic (MMS or Data is not differentiated on APN basis), the
GGSN gets quota for the global volume, including potential MMS Traffic - even if the customer will
never send a MMS.
Note 2: In case a dedicated APN is used for MMS, the GGSN gets quota for MMS. If the GGSN des
not support quota management for MMS, it is expected no CCR will be sent by the GGSN.
Note 3: Conditionally, in the case where no quota was assigned before, the GGSN detects the MMS
Relay access and initiate a CREDIT-CONTROL-REQUEST towards the ARP, the GGSN gets only
quota for MMS.
1. End user requests to send a Multimedia Message (MMS).
2. The DSP send Credit-Control-Request (EVENT_REQUEST with Requested-Action
DIRECT_DEBITING) via MMS Proxy to ARP OCS
3. ARP OCS receive Credit- Control-Request (EVENT_REQUEST with Requested-Action
DIRECT_DEBITING) via MMS Proxy to ARP OCS
4. ARP checks the end user’s account balance, rates the service, and debits the service from
the end user’s account
5. ARP OCS sends Credit-Control-Answer (Event Request) via MMS Proxy.
6. DSP receive Credit-Control-Answer (Event Request) via MMS Proxy.
page 62/96
2.5.4.9
MMS MT using IEC (Immediate Event Charging)
If a destination rules applies in MMS MO case then the quota management of plain data transmission
has to be excluded. It is not possible to have different quota rules for MMS MO and MMS MT.
VPLMN SGSN
GGSN
MMS Relay
OCS Data Proxy
OCS MMS Proxy
ARP - OCS
Note 4
Create PDP Context
Request
DIAMETER CCR
(Requested APN, may be
independent from MMS)
CREDIT-CONTROL-REQUEST (Initial, CreditControl AVPs )
Create PDP Context
Response
DIAMETER CCA
(independent from MMS)
CREDIT-CONTROL-ANSWER (GRANTED
UNITS)
DIAMETER CCR
CREDIT-CONTROL-REQUEST (Initial,
Credit-Control AVPs)
DIAMETER CCA
CREDIT-CONTROL-ANSWER
(GRANTED UNITS)
Note 5
Create PDP Context
Request
DIAMETER CCR
DIAMETER CCR
(Requested APN for MMS)
CREDIT-CONTROL-REQUEST (Initial, CreditControl AVPs )
Create PDP Context
Response
DIAMETER CCA
MMS
CREDIT-CONTROL-ANSWER (GRANTED
UNITS)
CREDIT-CONTROL-REQUEST (Initial,
Credit-Control AVPs)
DIAMETER CCA
CREDIT-CONTROL-ANSWER
(GRANTED UNITS)
MM1 notification Req
maybe silent SMS
MMS in
MM1 notification
Res
Note 6
Create PDP Context
Request
DIAMETER CCR
DIAMETER CCR
(Requested APN for MMS)
CREDIT-CONTROL-REQUEST (Initial, CreditControl AVPs )
Create PDP Context
Response
DIAMETER CCA
MMS
CREDIT-CONTROL-ANSWER (GRANTED
UNITS)
MM1 retrieve
Req
CREDIT-CONTROL-REQUEST (Initial,
Credit-Control AVPs)
DIAMETER CCA
CREDIT-CONTROL-ANSWER
(GRANTED UNITS)
DIAMETER CCR
Message type,
Transaction ID,
MMS version,
Content type,
Recipient address,
Content
CREDIT-CONTROL-REQUEST
(EVENT_REQUEST with RequestedAction DIRECT_DEBITING, MMS
SPECIFIC AVP)
DIAMETER CCR
CREDIT-CONTROL-REQUEST
(EVENT_REQUEST with RequestedAction DIRECT_DEBITING, MMS
SPECIFIC AVP)
DIAMETER CCA
MM1 retrieve
Res
Message type,
Transaction ID,
MMS version
Request status
DIAMETER CCA
CREDIT-CONTROL-ANSWER (EVENT
REQUEST, GRANTED UNITS)
MM1 retrieve
Ack
Figure 37 – MMS MT using IEC
page 63/96
CREDIT-CONTROL-ANSWER (EVENT
REQUEST, GRANTED UNITS)
Note 4: In case the requested APN is generic (MMS or Data is not differentiated on APN basis), the
GGSN gets quota for the global volume, including potential MMS Traffic.
Note 5: In case a dedicated APN is used for MMS, the GGSN gets quota for MMS. If the GGSN des
not support quota management for MMS, it is expected no CCR will be sent by the GGSN.
Note 6: Conditionally, in case of no quota assigned before; the behaviour is expected to be inline with
Note 3. The charging control remains initiated by the UE in order to receive the announced MMS
(SMS-push).
page 64/96
2.5.4.10 MMS MT using ECUR (Event Charging with Unit Reservation)
If a destination rules applies in MMS MO case then the quota management of plain data transmission
has to be excluded.
VPLMN SGSN
GGSN
MMS Relay
Data Proxy
Note 7
Create PDP Context
Request
DIAMETER CCR
(Requested APN, may be
independent from MMS)
CREDIT-CONTROL-REQUEST (Initial, CreditControl AVPs )
Create PDP Context
Response
DIAMETER CCA
(independent from MMS)
CREDIT-CONTROL-ANSWER (GRANTED
UNITS)
MMS Proxy
ARP - OCS
DIAMETER CCR
CREDIT-CONTROL-REQUEST (Initial,
Credit-Control AVPs)
DIAMETER CCA
CREDIT-CONTROL-ANSWER
(GRANTED UNITS)
Note 8
Create PDP Context
Request
DIAMETER CCR
DIAMETER CCR
(Requested APN for MMS)
CREDIT-CONTROL-REQUEST (Initial, CreditControl AVPs )
Create PDP Context
Response
DIAMETER CCA
MMS
CREDIT-CONTROL-ANSWER (GRANTED
UNITS)
CREDIT-CONTROL-REQUEST (Initial,
Credit-Control AVPs)
DIAMETER CCA
CREDIT-CONTROL-ANSWER
(GRANTED UNITS)
MM1 notification Req
maybe silent SMS
MMS in
MM1 notification
Res
Note 9
Create PDP Context
Request
DIAMETER CCR
DIAMETER CCR
(Requested APN for MMS)
CREDIT-CONTROL-REQUEST (Initial, CreditControl AVPs )
Create PDP Context
Response
DIAMETER CCA
MMS
CREDIT-CONTROL-ANSWER (GRANTED
UNITS)
MM1 retrieve
Req
Message type,
Transaction ID,
MMS version,
Content type,
Recipient address,
Content
CREDIT-CONTROL-REQUEST (Initial,
Credit-Control AVPs)
DIAMETER CCA
CREDIT-CONTROL-ANSWER
(GRANTED UNITS)
DIAMETER CCR
CREDIT-CONTROL-REQUEST
(INITIAL_REQUEST, MMS SPECIFIC
AVP)
DIAMETER CCR
CREDIT-CONTROL-REQUEST
(INITIAL_REQUEST, MMS SPECIFIC
AVP)
DIAMETER CCA
MM1 retrieve
Res
Message type,
Transaction ID,
MMS version
Request status
MM1 retrieve
Ack
DIAMETER CCA
CREDIT-CONTROL-ANSWER
(INITIAL_REQUEST, GRANTED
UNITS)
CREDIT-CONTROL-ANSWER
(INITIAL_REQUEST, GRANTED
UNITS)
DIAMETER CCR
CREDIT-CONTROL-REQUEST
(TERMINATION_REQUEST, USED
UNITS, MMS SPECIFIC AVP)
DIAMETER CCA
CREDIT-CONTROL-ANSWER
(TERMINATION_REQUEST)
Figure 38 – MMS MT using ECUR
page 65/96
DIAMETER CCR
CREDIT-CONTROL-REQUEST
(TERMINATION_REQUEST, USED
UNITS, MMS SPECIFIC AVP)
DIAMETER CCA
CREDIT-CONTROL-ANSWER
(TERMINATION_REQUEST)
Note 7: In case the requested APN is generic (MMS or Data is not differentiated on APN basis), the
GGSN gets quota for the global volume, including potential MMS Traffic.
Note 8: In case a dedicated APN is used for MMS, the GGSN gets quota for MMS. If the GGSN des
not support quota management for MMS, it is expected no CCR will be sent by the GGSN.
Note 9: Conditionally, in case of no quota assigned before; the behaviour is expected to be inline with
Note 3. The charging control remains initiated by the UE in order to receive the announced MMS
(SMS-push).
2.5.4.11 Generation and Handling of Call Data Records
The interfaces 3a and 3b will deliver all necessary information to the ARP to allow detailed retail billing
for data and event based MMS services. A volume based MMS billing will be included in the normal
Data volume. As regulation defines that prices for MMS volume is treated like for data traffic. Even if
all necessary information is already provided the DSP may have a mutual agreement with an ARP to
provide additional CDR’s on an offline interface (may be together with wholesale information).
2.5.4.12 Handling of non ARP traffic
MMS to and from a non EU regulated country/network are handled locally within the DSP. In this case
no quota management (neither for Data nor for the MMS event as such) applies between DSP and
ARP.
2.5.5 Parameters Definitions and Use
2.5.5.1
CCR/CCA fields
The AVP’s in the CCR / CCA are specified in 3GPP TS 32.299. In addition to this the Packet Switched
(PS) Domain charging is specified in 3GPP TS 32.251 and 3GG TS 32.270 describes the charging
management for the Multimedia Messaging Service (MMS).
2.5.6 Error Handling
The principle error handling has to follow the rules described in the Diameter Base Protocol (IETF
RFC 4006 and RFC 6733) and the related 3GPP specifications.
Especially the following procedures and actions are defined:
3GPP TS 32.299: Telecommunication management; Charging management; Diameter charging
applications (Gy)
3GPP TS 32.251: Telecommunication management; Charging management; Packet Switched (PS)
domain charging (Annex B: Tx expiration; Failure Handling procedure and session failover mechanism
description)
Generally the error scenarios can be split into 2 major scenario sets:
Service Implementation Related:
1. ARP decision to reject the Data traffic or the MMS because the subscriber doesn’t have any
credit on the account. (DIAMETER_CREDIT_LIMIT_REACHED 4012)
2. ARP decision to reject the Data traffic or the MMS because the subscriber is not an ARP
subscriber. ( DIAMETER_AUTHORIZATION_REJECTED 5003)
page 66/96
3. ARP decision to reject the Data traffic or the MMS because the subscriber is not located within
the ARP coverage. ( DIAMETER_AUTHORIZATION_REJECTED 5003)
4. ARP decision to reject Data traffic or the MMS because the subscriber not subscribed to a
detectable service, currently only “any Data” or MMS. (DIAMETER UNABLE TO COMPLY
5012)
5. ARP decision to reject Data traffic or the MMS because wrong AVP’s, Service parameters
(like APN) or messages received. (DIAMETER UNABLE TO COMPLY 5012)
6. DSP decision to reject service if the assigned Quota by the ARP is outside agreed limits.
(Undersized/ Oversized quota) .
Breakdown / Failure Related:
For all the following cases the DSP will not provide service to customers anymore.
1. Communication problem between DSP and ARP i.e. the ARP doesn’t respond to credit
controls but the application layer is up ;
2. Connection (peer or signalling point) is down, it’s not possible for the DSP to do a credit
control ;
3. Normal error handling by the DSP according to IETF and 3GPP Specifications as mentioned
above.
2.5.7 Summary table
The following table summarizes the information shared between the ARP and DSP for the purpose of
setting up the interface. The actual connectivity items are out of scope.
Information
Protocol
DIAMETER
Information
Provider
DSP
DCCA
Rating Groups
DSP
DSP
Operational mode at DSP
single / multi APN Operation
Quota management
Operational mode at DSP for MMS
DSP
Quota (minimum, default, etc.)
DSP
DSP
page 67/96
Purpose
Identify the interfacing model
Information elements out of 3GPP
standard are used.
Application according 3GPP
The DSP defines the structure and
values ranges the ARP has to commit
The DSP has to deliver the implemented
interface coding structure for ARP to
follow the implementation
Information if event based charging is
available or not
ARP to follow
2.6
SI-IF4 : Mobility Control
2.6.1 Description
Through this interface the DSP will inform the ARP on the subscriber’s roaming status while travelling
within the EU.
The roaming status information must be provided in near-real-time based on the mobility observation
between the VLR/SGSN and the HLR.
Subscriber location
ARP
Tariff Info
IF4
DSP
Mobility Proxy
Visited Network
VLR/SGSN
Figure 39 – Mobility management architecture and associated functions
This interface is based on OMA RESTful Network API for Terminal Status (Candidate Version 1.0 – 17
Jan 2012), which can be downloaded from:http://www.openmobilealliance.org/API/APIsInventory.aspx
Important The final description of the proposed interface will be defined by the OMA.
2.6.2 Detailed Procedures at DSP
The DSP will act as a notification server for this interface provided to the ARP.
The DSP must keep a trace of all the notifications sent to the ARP.
The DSP will send notifications one every successful update location on networks inside ARP
coverage.
The DSP will not retry sending notifications which previously failed to send, or for which it has not
received a response.
2.6.3 Detailed Procedures at ARP
The ARP will act as the notification client for this interface provided by the DSP.
The ARP must respond upon reception of the notification from the DSP.
The ARP will not receive notifications when subscribers attach to networks outside ARP coverage.
The ARP will not receive notifications when subscribers attach to DSP network or other home
country’s network in case of national roaming.
Note Only the actual registration events in a network are passed to the ARP. It results a possible
limitation on distinguishing when subscriber comes back to last ARP coverage network from outside
ARP coverage. Example: a customer coming back and forth EU and non EU location may be seen as
doing registration procedures in a network.
2.6.4 Interface primitives
The Subscriber’s Roaming Status may be provided via a RESTful web API. Usually RESTful web API
utilizes HTTP commands POST, GET, PUT, and DELETE in order to perform an operation on a
resource at the server. This resource is addressed by a URI; and what is returned by the server is a
representation of that resource depending on its current state.
page 68/96
The HTTP method POST is used to provide the Subscriber’s Roaming Status. The other HTTP
methods (i.e. GET, PUT and DELETE) are not used in this interface.
Resource URI
HTTP Method
http://{arp_host}/terminalstatus/{version}/notifications/RoamingChangeNotification
POST
Operation
Provide notification about the roaming status of the subscribers.
Where:
{arp_host} is replaced by the fully qualified domain name (FQDN) of the ARP server being accessed.
{version} optionally indicates the version of the interface being accessed, the current version is ‘v1’.
This figure below shows a scenario to send notifications about subscriber roaming status change:
VPLMN
VLR
DSP
ARP
1.- MAP: Location Updating Request
2.- MAP: Location Updating Accept
3. - Roaming
status change
4.- HTTP POST Notify new roaming status information
5.- HTTP Response
Figure 40 - Roaming status change notification
Outline of flow:
1. - A subscriber registers into a VPLMN and VLR/SGSN starts the Location Update procedure.
2. - The DSP ends the procedure by sending current subscriber information to the requesting VLR.
3. - The DSP detects the subscriber roaming status changes of an ARP subscriber.
4. - The DSP server notifies the ARP using HTTP POST about the roaming status changes.
5. - The ARP will respond to the HTTP request acknowledging the roaming status received.
This sequence will continue executing as far as the subscriber register into any VPLMN while roaming
within EU.
2.6.5 Parameters Definitions and Use
The content type for the interface is ‘application/json’.
The subsections of this section define the data structures used in this interface. Some of the structures
can be instantiated as so-called root elements.
For structures that contain elements which describe a user identifier, the statements in OMA RESTful
Network API for Terminal Status (Candidate Version 1.0 – 17 Jan 2012) section 6 regarding 'tel', 'sip'
and 'acr' URI schemes apply.
page 69/96
If a network element identifier (e.g. Visitor Location Register, Serving GPRS Support Node, etc.) of
type anyURI is in the form of a Global Title (GT), it MUST be defined as a global number according to
[RFC3966] (e.g. tel:+32476000011). The use of characters other than digits and the leading “+” sign
SHOULD be avoided in order to ensure uniqueness of the resource URL. This applies regardless of
whether the identifier appears in a URL variable or in a parameter in the body of an HTTP message.
If a network element identifier (e.g. Mobility Management Entity, etc.) of type anyURI is in the form of
an Fully Qualified Domain Names (FQDN), it MUST be defined according to [3GPP TS 23.003], and it
MUST include the protocol prefix 'tel:' followed by the FQDN (e.g.
tel:mmegi32799.mme.epc.mnc001.mcc206.3gppnetwork.org).
If a subscriber identifier (e.g. subscriberId, etc.) of type string is in the form of an International Mobile
Subscriber Identity (IMSI), it MUST be defined according to [ITU-T E.212].
If a terminal identifier (e.g. deviceId, etc.) of type string is in the form of an International Mobile
Equipment Identity (IMEI), it MUST be defined according to [3GPP TS 23.003] and it SHOULD consist
of 14 digits (e.g. 49015420323751), including the 8-digit Type Allocation Code (TAC) and the 6-digit
Serial Number (SNR).
2.6.5.1
Type: RoamingChangeNotification
A type containing terminal roaming status for change notification:
Element
callbackData
Type
xsd:string
Optional
Yes
Description
roaming.
TerminalRoamingStatus
No
Collection of the terminal roaming status
isFinalNotification
[1..unbounded]
xsd:boolean
Yes
Will be set to true if it is a final
notification about roaming status change.
link
common:Link
Yes
Link to other resources that are in
relationship with the resource.
CallbackData if passed by the
application during the associated
startNotification operation.
See [REST_NetAPI_Common].
[0..unbounded]
A root element named roamingChangeNotification of type RoamingChangeNotification is allowed in
request and/or response bodies.
page 70/96
2.6.5.2
Type: TerminalRoamingStatus
A type containing current terminal roaming status:
Element
address
Type
Optional
Description
xsd:anyURI
No
Address of the terminal device (e.g.
'sip' URI, 'tel' URI, 'acr' URI) to which
the roaming status information applies.
subcriberId
xsd:string
Yes
The International Mobile Subscriber
Identity (IMSI) to which the roaming
status information applies. Must be
included when the address of the
terminal device is unknown i.e.
‘tel:+000000000000’.
deviceId
xsd:string
Yes
The unique International Mobile
Equipment Identity (IMEI) of this
terminal device.
retrievalStatus
common:RetrievalStatus
No
Status of retrieval for this terminal
device address.
retrievalTime
xsd:dateTime
No
Indicates the time when the status was
retrieved
currentRoaming
RoamingStatus
Yes
Roaming status of terminal. Must be
included when
retrievalStatus=Retrieved.
servingNode
MobileServingNetworkNode No
Address of the mobile network node
serving the terminal device.
errorInformation
common:ServiceError
Must be included when
retrievalStatus=Error. This is the
reason for the error
2.6.5.3
Yes
Type: MobileServingNetworkNode
A type containing the type and the address of the network node serving the terminal device
Element
Type
Optional
Description
type
ServingNetworkNodeType
No
Type of the network node serving the
terminal device.
node
xsd:string
No
Address of the network node serving
the terminal device (e.g. 'sip' URI, 'tel'
URI, FQDN).
page 71/96
2.6.5.4
Enumeration: RoamingStatus
An enumeration, defining the roaming status of a terminal:
Element
InternationalRoaming
Description
DomesticRoaming
Terminal is roaming domestically, i.e., in the same country in which it
is registered for service with its home MNO/MVNO.
NotRoaming
Terminal is not roaming, i.e., is connected to its home MNO/MVNO.
2.6.5.5
Terminal is roaming internationally, i.e., in a country different from
that in which it is registered for service with its home MNO/MVNO
Enumeration: ServingNetworkNodeType
An enumeration, defining the serving network node types:
Element
VLR
Description
SGSN
Terminal is attached to a Serving GPRS Service Node.
MME
Terminal is attached to a Mobility Management Entity.
2.6.5.6
Terminal is attached to a Visitor Location Register.
Enumeration: RetrievalStatus
Enumeration
Retrieved
Description
NotRetrieved
Data not retrieved, current data is not provided (does not indicate an
error, no attempt may have been made). Note that this field is useful in
case a list of addresses are requested, some items could be marked as
"NotRetrieved" in case retrieval could not be attempted for some reason,
e.g. to avoid time outs
Error
Error retrieving data
Data retrieved. Current data is provided
page 72/96
Roaming status change notification for single network-connected subscriber
This shows an example roaming status notification for two mobile devices:
Notification:
POST
The JSON response contains a
http://www.arp.com/terminalstatus/v1/notifications/RoamingChangeNotification
roamingChangeNotification object.
HTTP/1.1
Content-Type: application/json
As the notification was for more than one mobile
Content-Length: nnnn
device the notification contain a roaming array.
Date: Thu, 01 Jul 2014 13:51:59 GMT
retrievalStatus value is one of “Retrieved” or
“Error”
{"roamingChangeNotification ": {
"roaming": [
{
"address": "tel:+000000000000",
"subscriberId": "206011234567890",
"deviceId": "49015420323751"
"currentRoaming": "InternationalRoaming",
"retrievalStatus": "Retrieved",
"retrievalTime": "2014-10-26T21:32:52",
"servingNode": {
"type": "VLR",
"node": "+336033445566"
}
},
],
}}
Response:
HTTP/1.1 204 No Content
Date: Thu, 01 Jul 2014 13:51:59 GMT
Indicates request processed successfully but no
data is returned
Error Handling
Response Codes
HTTP response codes are used to indicate:
204 – No Content; the server has fulfilled the request but does not need to return an entity-body
400 – Bad request; check the error message and correct the request syntax.
401 – Authentication failure, check your provider’s authentication requirements.
403 – Forbidden; please provide authentication credentials.
404 – Not found: mistake in the host or path of the service URI.
405 – Method not supported: in the interface, only POST is supported.
503 – Server busy and service unavailable. Please retry the request.
More details on these at http://www.ietf.org/rfc/rfc2616.txt
page 73/96
2.6.5.7
Exceptions
SVC0004: No valid address
400 indicates an error
HTTP/1.1 400 Bad Request
Content-Type: application/json
Content-Length: 1234
Date: Thu, 01 Jul 2014 13:51:59 GMT
A serviceException describes the reason why the service
cannot accept the request; for example if the request URI was
incorrect.
{"requestError": {
"serviceException": {
"messageId": "SVC0004",
"text": "No valid addresses provided in message
part %1",
"variables": "%1 - request URI"
}
}}
2.6.5.8
A policyException object means that the request syntax is
valid, however an operator policy has been broken: in this
example because the operator cannot support the batch size
requested.
serviceException and policyException share the same
body: an identifier pair for the exception (messageId), a text
pair to describe it consistently (text), and a variables pair to
indicate any specific cause of the error (variables). The
variables relate to the %1 placeholder(s) in the text.
SVC2000: Service Error
The following exception will be received in case the subscriber is not registered in the ARP systems,
and such will not be served by the ARP:
400 indicates an error
HTTP/1.1 400 Bad Request
Content-Type: application/json
Content-Length: 1234
Date: Thu, 01 Jul 2014 13:51:59 GMT
{"requestError": {
"serviceException": {
"messageId": "SVC2000",
"text": "The following service error occurred: %1. Error
code is %2.",
"variables": [
"%1 – Not a subscriber",
"%2 – ARP001",
]
}
}}
A serviceException describes the reason why the service
cannot accept the request; for example if the subscriber was
incorrect (not an APR subscriber).
The following exception will be received in case the subscriber is not roaming under the ARP
coverage, and such will not be served by the ARP:
400 indicates an error
HTTP/1.1 400 Bad Request
Content-Type: application/json
Content-Length: 1234
Date: Thu, 01 Jul 2014 13:51:59 GMT
{"requestError": {
"serviceException": {
"messageId": "SVC2000",
"text": "The following service error occurred: %1. Error
code is %2.",
"variables": [
"%1 – Not under coverage",
"%2 – ARP002",
]
}
}}
A serviceException describes the reason why the service
cannot accept the request; for example if the location was
incorrect (not under APR coverage).
page 74/96
2.7
SI-IF5 : USSD Control
2.7.1 Description
The major goal of this interface is to relay USSD signalling between subscriber and ARP services
USSD (Unstructured Supplementary Services Data) allows bi-directional and half-duplex connections
between a handset and a USSD application server, exchanging plain text messages with each other.
Each USSD message can contain up to 182 user characters and is completely transparent for the
handset and the mobile network.
There are two types of USSD, corresponding with its two phases of development in standard:
•
•
USSD phase 1: the USSD service platform sends a response and the session is closed.
So, only one request and its response are exchanged per session in USSD Phase 1.
USSD phase 2: a session in USSD Phase 2 may be composed of many USSD messages
(request and response messages). USSD Phase 2 can provide interactive services with a
user-friendly ergonomic interface.
The USSD service code has to follow a given format: A [A] [A]1X(Y)[*<STRING>]#
Where:
•
A = * or #
•
X = 0 – 9 where X = 0 – 4 for services of the HPLMN & X = 5 – 9 for services of the
VPLMN
•
Y=0–9
•
[ ] indicates an optional element.
In a roaming decoupling situation, only HPLMN range could be used:
100…149 for International use i.e. used in the VPMN: the Visited PMN sends the USSD back to the
Home PMN.
USSD services rely mainly on a USSD Center (USSD-C) which routes USSD messages from
handsets to USSD application servers and vice-versa. A synthetic architecture is defined below:
handset
VMSC
MAP
HLR
MAP
USSD-C
Applications
Figure 41 – Architecture of USSD Services
Sessions are opened by using service codes (like a short number combining * and #). After dialling on
the handset a USSD service code (#121# for instance), a USSD request is sent to the USSD-C which
identifies, thanks to the service code, the adequate application server which will process the request
and send the response: a text message displaying a menu for instance. The user may continue the
session by choosing an item of the menu or may decide to close it.
To support ARP related USSD services, minimizing the impact to existing infrastructure the following
principal solution shall be implemented:

USSD proxy with ARP awareness functionality,

Allocation of USSD service code for ARP services,

Routing of all ARP service code requests from HLR to USSD proxy and back.

Routing of all ARP related USSD signalling from USSD proxy to ARP and back.
page 75/96
handset
VMSC
MAP
HLR
MAP
USSD
proxy
IF5
ARP
SCP
Figure 42 – IF5 USSD interface
The DSP shall allocate at least one USSD service code for ARP services in the 100-149 range, which
does not overlap with existing DSP USSD service codes, but can be shared between different ARP.
IF5 USSD proxy / ARP interface shall be based on the SS7/MAP protocol.
There are 3 types of usage scenarios:

Mobile initiated USSD – when the network relays information from mobile user to application
entity in order to allow USSD operation.

Network initiated USSD request - when the invoking application entity requires information
from the mobile user, in connection with USSD handling;
Network initiated USSD notification - when the invoking application entity requires a
notification to be sent to the mobile user, in connection with USSD handling;

When interface 5 (IF5) is made available by the DSP then the mobile originated USSD is supported,
the network initiated requests are depending on HLR capability.
2.7.2 Detailed Procedures at DSP
2.7.2.1
General
Support of USSD signalling depends on the agreement between DSP and VPMN. DSP shall offer the
relay of USSD signalling on all the networks where it is used by DSP’s own subscribers.
2.7.2.2
Mobile-initiated USSD
DSP shall forward USSD requests initiated by subscriber and received from DSP network or VPMN to
ARP’s SCP when the three conditions below are met:
1) The number of USSD initiator corresponds to an ARP subscriber;
2) The USSD code belongs to ARP services;
3) The service requested is according to the agreement between DSP and ARP at the current
location of subscriber – the location is not limited to the EU, but particular services may be
limited to EU.
DSP shall ensure that subscriber identification (MSISDN) as well as the address of the VLR is
included in the signalling to ARP.
MSISDN-less subscriptions are out of scope and for further study.
No protocol conversion will be done between different MAP operations, the USSD proxy will
transparently pass the message relayed from the HLR.
2.7.2.3
Network-initiated USSD
DSP shall relay USSD notifications initiated by ARP SCP to VPMN in the following conditions:
1) The destination number of USSD corresponds to an ARP subscriber;
2) The service requested is according to the agreement between DSP and ARP at the current
location of subscriber;
page 76/96
2.7.3 Detailed Procedures at ARP
2.7.3.1
General
ARP is responsible for the provisioning of USSD based services and usage of USSD signalling
transferred between subscriber and ARP shall be in accordance to the standards.
The capacity of the MAP is limited. Heavy traffic between the SCP and the HLR will delay other MAP
transactions, for example, location updates. ARP shall ensure the reasonable usage of USSD
signalling and shall take into account capacity considerations.
2.7.3.2
Mobile-initiated USSD
ARP shall reply to all USSD requests initiated by subscriber and received via DSP:
1) The reply shall be performed related to the same Origination Transaction ID
2) The reply shall be forwarded to the Calling Party Address in the SCCP level of the USSD
request.
2.7.3.3
Network-initiated USSD
ARP may initiate USSD requests or notifications in the following conditions:
1) The destination number of USSD corresponds to an ARP subscriber;
2) The service used is according to the agreement between DSP and ARP at the current location
of subscriber;
2.7.4 Interface primitives
The interface is the standard MAP protocol according to 3GPP TS 29.002.
USSD signalling shall comply with the following standards:

3GPP TS 23.090, Unstructured Supplementary Service Data (USSD)-Stage 2 version 4.1.0,

3GPP TS 24.090, Unstructured Supplementary Service Data (USSD)-Stage 3.
The MMI for USSD shall be according to TS 22.030 and TS 22.090. The alphabet indicator and the
data coding scheme shall be according TS 23.038.
Common MAP-OPEN service primitives
MAP-OPEN confirmed service is used for establishing MAP dialogues between two MAP service
entities.
The following parameters are relevant for USSD:
Destination address:
A valid SCCP address identifying the destination peer entity.
Destination reference:
This parameter is a reference that refines the identification of the called process. It shall be either IMSI
or MSISDN.
Originating reference:
This parameter is a reference that refines the identification of the calling process. It shall be the ISDNAddress-String on MAP-PROCESS-UNSTRUCTURED-SS-REQUEST, but can be omitted on other
application contexts.
page 77/96
Application context name:
This parameter identifies the type of application context being established. If the dialogue is accepted
the received application context name shall be echoed.
The following MAP services (application contexts) are relevant for USSD:
 MAP-PROCESS-UNSTRUCTURED-SS-REQUEST (processUnstructuredSS-Request);
 MAP-UNSTRUCTURED-SS-REQUEST (unstructuredSS-Request);
 MAP-UNSTRUCTURED-SS-NOTIFY (unstructuredSS-Notify).
USSD MAP service primitives
The MAP_PROCESS_UNSTRUCTURED_SS_REQUEST confirmed service is used for Mobile
initiated USSD with the following relevant primitives:

Invoke id

USSD Data Coding Scheme

USSD String

MSISDN - included as an operator option, e.g. to allow addressing the subscriber’s data in the
gsmSCF with the MSISDN
The MAP_UNSTRUCTURED_SS_REQUEST confirmed service is used for Network initiated USSD
request with the following relevant primitives:

Invoke id

USSD Data Coding Scheme

USSD String
The MAP_UNSTRUCTURED_SS_NOTIFY confirmed service used for Network initiated USSD
notification with the following relevant primitives:

Invoke id

USSD Data Coding Scheme

USSD String
2.7.5 Parameters Definitions and Use
The following parameters shall be used for provisioning of USSD services for subscribers:

Destination reference - subscriber number used for subscriber identification:
o MSISDN number
o IMSI number, especially if MSISDN is not available.

Originating Reference - Location information (VMSC) – used for Mobile-initiated USSD
requests to distinguish location for services where location information is relevant.

USSD string – used for identification of ARP service.
MTP routing parameters shall be exchanged between ARP and DSP:

Signalling Point Codes
Specific SCCP routing parameters, which shall be exchanged and harmonised between ARP and
DSP:

The SSN used in this interface will be based on the existing DSP implementation and will be
provided by the DSP to the ARP
page 78/96
2.7.6 Error Handling
The following failure related errors can occur during USSD usage between VPMN, DSP and ARP:
-
The ARP’s SCP does not respond to USSD message sent by DSP.
-
The signalling connection between DSP and ARP is not operational.
-
Proxy device deployed between ARP and DSP is not operational.
In all of the above scenarios, the DSP shall reject the USSD by returning an MAP Error to MSC of the
VPMN.
All such error cases shall be handled in according to the MAP specification TS 29.002. For definition
of errors see 3GPP TS 24.080, for example, usually TC-U-ABORT message is sent back to the
VPMN.
USSD service related errors are handled in the following way.
Mobile-originated USSD:


When the subscriber does not belong to this ARP, error cause "Invalid Destination Reference"
is returned by ARP to the HLR in the MAP-Refuse-PDU.
When the service requested by the subscriber is not according to the agreement between
DSP and ARP at the current location of subscriber, error cause "Invalid Destination
Reference" is returned by ARP to the HLR in the MAP-Refuse-PDU. Additionally DSP may
reject such a request, sending similar error to VPMN.
Network initiated USSD notification or USSD request:




When the subscriber does not belong to this ARP, error cause "Invalid Destination Reference"
is returned by ARP to the HLR in the MAP-Refuse-PDU.
When the subscriber use the USSD service which does not belong to ARP coverage, error
cause "Invalid Destination Reference" is returned by ARP to the HLR in the MAP-RefusePDU, Additionally DSP may reject such a request, sending simlar error to VPMN.
If the VLR Address is not known in the HLR for the subsriber of ARP, the error cause "Absent
Subscriber" is returned to the USSD application.
If the VPMN does not support MAP version 2, the transaction is released.
page 79/96
2.8
SI-IF9 : SMS Wholesale Interface (MO+MT)
The following interface implementation shall be considered as an example. The IF9 is an optional
interface which requires mutual agreements between a DSP and an ARP.
2.8.1 Description
The interface IF9 is an optional interface between the ARP and DSP. It can provide an ARP the
possibility to instruct the DSP to generate a short message (SMS) for an ARP subscriber. The content
of such a SMS might be for example tariff data, bill shock prevention, emergency or hotline numbers.
Additional the ARP can receive SMS for own services.
SMS
ESME
ARP
IF9
DSP
Proxy
SMSC
HLR
MAP
Visited Network
VLR/SGSN
Figure 43 – MO/MT SMS architecture and associated functions
2.8.2 Detailed Procedures at ARP
The ARP is connected to the DSP via an IP interface. This IP connection shall protect against misuse
(fraud, address spoofing). It is requested to establish a secure connection between both entities (e.g.
VPN connection or IPSec tunnel).
The interface IF 9 shall be usually based on the protocol SMPP. The DSP can also propose other
methods available and commonly acknowledged as part of the state of the art in the DSP country.
Although valid, these techniques are not discussed in this document.
The ARP shall act as a SMPP Client (External Short Message Entity - ESME) and the SMSC of the
DSP as a SMPP server (SMSC).
page 80/96
The ARP has the responsibility to setup the connection to the SMSC with a “bind_transmitter” request.
This request considers authentication data. Detail information about this data is described in the
SMPP standard and must be mutually agreed between the ARP and DSP.
The bind connection can be established for a single SMS transmission or can be active all the time
(mutable agreed between the ARP and DSP).
2.8.3 Detailed Procedures at DSP
Dependent on the authentication data the SMSC, the DSP acknowledges the bind request of the ARP.
The Receiver of a SMS confirms with a (SMPP) ACK the received SMS from the Sender.
An optional SMS proxy could check an external database. The primary parameter for this check is the
MSISDN of the receiving party. The SMSC-proxy can check if the receiving subscriber belongs to the
sending ARP.
Further verification can be performed if the subscriber is served by the VPLMN (outbound roaming).
MT SMS:
The SMSC uses the MAP procedures to terminate the SMS in the VLR (VPLMN) after a HLR inquiry.
If the SMS cannot be delivered (e.g. absent subscriber), the SMSC keeps the SMS in a database.
According the configured retry schema the SMSC tries to deliver the SMS to the recipient.
The SMSC shall store CDRs for each successful MT_SMS for the Wholesale-Billing between the ARP
and the DSP.
MO SMS:
The Visiting MSC uses the MAP procedures to send the SMS to the SMSC.
The SMSC shall store CDRs for each MO_SMS for the Wholesale-Billing between the ARP and the
DSP.
2.8.4 Interface primitives
The exchange of SMS between the ARP and the DSP is defined in the Short Message Peer to Peer
Protocol Specification (SMPP).
The connection between the ARP and the DSP is made after a binding process. Each SMS shall be
acknowledged.
The figure below illustrates the bind, unbind and the SMS delivery more in detail.
page 81/96
Figure 44 – Typical SMPP request/response sequence for an SMS from ARP to DSP
Source: SMPP protocol specification V 3.4, SMPP Developers Forum
Figure 45 – Typical SMPP request/response sequence for an SMS from DSP to ARP
Source: SMPP protocol specification V 3.4 , SMPP Developers Forum
page 82/96
2.8.5 Parameters Definitions and Use
The address of the sender and the receiver shall be formatted according to the E.164 standard. The
used Type of number (TON) and Numbering Plan Indicator (NPI) shall be agreed between the ARP
and the DSP.
The coding schema for special characters in the SMPP payload (e.g. umlauts like ä,ö,ü,ß) shall be
agreed between the ARP and the DSP.
The SMSC shall store CDRs for each SMS for the Wholesale-Billing between the ARP and the DSP.
The maximum length of the SMPP messages shall be agreed between the ARP and the DSP. For a
single SMS the SMPP standard supports up to 254 octets but on SMSC (MAP/MTP) only 160 octets
per SMS are supported.
2.8.6 Error Handling
If the SMSC of the DSP cannot properly store the received SMS of the ARP in the own database, the
SMSC shall send an error on the SMPP interface according to the SMPP specification.
The SMSC does not send a delivery receipt to the ESME after an unsuccessful delivery of a SMS.
page 83/96
3
INTERFACE DEFINITION FOR LBO
3.1
Assumptions
No new interfaces are needed between LBO and HPMN to launch LBO offer, except a conditional
notification interface.
3.2
Interface overview
The following interfaces will be included in the LBO architecture:

IF1: existing MAP mobility interface, which will be impacted for customer profile and traffic
steering.

IF2: an NEW on-line notification interface provided by the LBO provider to inform Home
operators of the start/end of an LBO subscription (conditional).

IF3: existing TAP file interface. No TAP files are to be sent from LBO providers for LBO APN
usage.
HLR
Traffic
Steering
IF1(*)
SGSN
Notification
IF2
Notification
HPMN
WS
Billing
IF3(*)
(*) IF1 & IF3 are EXISTING interfaces,
while IF2 is really a NEW interface.
WS
Billing
LBO provider
Visited Network
Figure 46 – LBO interface definition
The purpose of this document is to detail the specifications of each of the IF1 and IF2 interfaces.
For sake of completeness, in order to manage the customer and perform proper billing and invoicing
the IF3 interface is also required. It will be defined by the Billing and Provisioning (B&P) workgroup.
page 84/96
3.3
LBO-IF1 : Mobility / Profile Control
3.3.1 Description
IF1 interface (MAP) is an existing interface which will be impacted for
•
Customer profile management: a standard EU Internet APN for regulated LBO service has to
be configured by default from the DSP, at least for the LBO networks and preferably (recommended)
for all the European countries. The sending of this APN to the rest of the world is an implementation
choice of the DSP.
The new standardised APN value (standardised at European level) is "euinternet" (not case sensitive),
which is known hereafter as the EUInternet APN. The EUInternet APN is specific to the LBO service
and based on which the VPLMN will route Internet traffic directly to the VPLMN instead of routing via
the HPLMN.
It is expected the LBO user will access the LBO service using the EU-wide dedicated APN
•
Traffic steering (using SS7) has to be defined clearly to be compliant with the regulation
“Obligation of DSPs not to bar or steer away outbound roaming customers having manually selected a
LBO/VPMN network”, according to the following conditions:


In order to assure customer experience, manual mode network selection shall be used
by LBO customers to choose the LBO network.
DSP SoR mechanism shall not interfere with manual selection
It is noted that some devices automatically switch back to “automatic network selection” without user
interaction and some handsets do not allow access to change the APN, which may impair the user
experience of the LBO customer
The version of MAP protocol in use within IF-1 interface is MAPv3.
The Network Identifier part of the APN used for EU Regulated services is: “euinternet”.
The full EU APN name is built accordingly by network elements as follows:
euinternet.mncxxx.mccxxx.gprs, where mncxxx.mccxxx.gprs is the Operator Identifier part of the APN
belonging to the LBO.
Mobility procedures at LTE/EPC Network elements are out of scope of this version of the document.
However it is expected the basic principles governing them remain similar.
3.3.2 Detailed Procedures at HPMN
The DSP must ensure an LBO-eligible roamer profile contains the EU Internet APN profile with VPAA
flag set to ON when roaming in a LBO network. VPAA stands for Visited PLMN Access Allowed and
gives right to a visited SGSN to deliver the whole S-G chain for packet data services.
Limitation of the usage of EU Internet APN within EU Countries may result in a definition, for example,
of specific service areas into the HLR, containing the list of PLMN allowed to receive this profile. The
detail to be listed will be the E.164 Global Title of the SGSN elements in a VPLMN. This information
can be retrieved from GSMA PRD IR.21 from each operator, assisted by RAEX Application, where
available.
Provisioning and de-provisioning to ARP LBO customers of this APN is an action in charge of the
Provisioning group.
To be noted that up today there may be HPMN that are applying Steering mechanisms only to Mobility
Procedures coming from visited MSC/VLR, considering the Circuit Switched preference for Location
page 85/96
Updating against GPRS Location Updating. The HPMN shall ensure its steering methods are inline
with the regulatory requirements.
In addition to the insertion and modification of general subscription data for a PS subscriber, the HLR
may request the insertion or modification of one or several new or existing PDP subscription contexts
in the SGSN. In particular, the following PDP context parameters may be modified by the HLR:
- QoS Profile Subscribed
- VPLMN Address Allowed
In the case of LBO, the HPMN shall provide the EUinternet APN with the same QoS settings as the
internet service for his roaming subscribers using the usual HPMN APN for accessing the internet.
3.3.2.1
Impacts on usage of Single IMSI+LBO
The HPMN, when acting as DSP, may decide to offer only real-time decoupling facilities (also called
convergent mode) to the connected ARP. This approach imposes the ARP service is only available in
the CAMEL roaming footprint of the DSP.
Impacts on LBO:
1. Since barring LBO networks is not allowed the following points should be noted:
2. In order for the LBO VPLMN to be able to provide full services (voice, SMS per traditional roaming
in addition to LBO Data) to a real-time controlled customer (whether ARP or DSP) the LBO may
request a CAMEL agreement with the DSP.
3. The LBO may choose not to ask for CAMEL agreement and therefore the prepaid/ real-time
subscriber will have only DATA services (and any other services allowed by the DSP for CAMEL
subscribers on non-CAMEL networks) in that network.
4. In such a case the LBO shall inform the LBO subscriber that there may be a loss of service (i.e.
MO call), this is to avoid an overload of customer care requests on the DSP.
Note Article 3 could enable CAMEL opening obligation for the VPMN (LBO provider) if requested by
HPMN.
3.3.3 Detailed Procedures at LBO
The LBO provider shall be able to receive the proper Internet EU APN with VPAA flag set to Allowed
into the MAP Primitive “Insert Subscriber Data”.
Configuration of EU Internet APN into SGSN, DNS, GGSN and Radius are out of scope of this
interface and will be detailed in the Whitepaper.
APN Restriction
The support for APN Restriction and Maximum APN Restriction at the SGSN is optional and an APN
Restriction value may be configured for each APN in the GGSN or P-GW. The support for reception,
storage, and transfer of APN Restriction is required for an S4-SGSN. It is used to determine, on a per
MS basis, whether it is allowed to establish PDP Contexts or EPS bearers to other APNs.
APN selection and DNS usage
Preconditions: the customer has EU Internet APN configured in the handset, customer SGSN Profile
contains a EU Internet APN and VPAA flag set to TRUE, LBO DNS contains record resolution for APN
to one or more LBO GGSN.
APN selection at LBO SGSN steps:
- EUInternet APN (APN (r)) is sent from customer MS to the SGSN [APN(r) is the requested APN]
- SGSN has stored the EuInternet APN (APN (s)) from the ISD subscription procedure [APN(s) is the
subscribed APN]
page 86/96
- match verification from SGSN between APN(r) and APN(s)
- VPAA flag verification
- DNS query composition as per above
- PDP Context Activation
GPRS Subscription Data Withdraw with MAP-DELETE-SUBSCRIBER-DATA service from DSP:
This parameter is used to indicate whether all GPRS Subscription Data for the subscriber shall be
deleted or if only a subset of the stored GPRS Subscription Data for the subscriber shall be deleted. In
the latter case only those PDP contexts whose identifiers are included in the subsequent identifier list
will be deleted.
Considerations on GLR implementation in a LBO provider
In case a visited PLMN has implemented a GLR (Global Location Register), the signalling interface
between DSP and LBO becomes GLa-interface and it is the same as that between the SGSN and the
HLR (see TS 29.002 [26]). The HLR regards the GLR as the SGSN via this interface.
SGSN
GLc
GLe
GLR
GGSN
GLa
HLR
Other PLMN
Signalling interface
Figure 47 – GLR – HLR interface
3.3.4 Interface primitives
The IF1 interface is a standard MAP interface that refers to SGSN Gr interface of a Visited PLMN (or
GLa interface in case of GLR at the visited PLMN).
The Gr interface is defined between the SGSN and HLR. It allows retrieving or updating GPRS
subscription and GPRS location information in the HLR during location-management or authentication
procedures.
This interface is used to exchange the data related to the location of the mobile station and to the
management of the subscriber. The main service provided to the mobile subscriber is the capability to
transfer packet data within a Packet Data Network.
MAP-Update-GPRS-Location service
The SGSN informs the HLR of the location of a mobile station managed by the latter. The HLR sends
to the SGSN all the data needed to support the service to the mobile subscriber. Exchanges of data
may occur when the mobile subscriber requires a particular service, when he wants to change some
data attached to his subscription or when some parameters of the subscription are modified by
administrative means.
Signalling on this interface uses the Mobile Application Part (MAP), which in turn uses the services of
Transaction Capabilities (TCAP). See TS 29.002.
page 87/96
The mobility management of the roaming customer in a Visited PLMN is handled by the application
context gprsLocationUpdateContext, with the following two MAP operations: updateGprsLocation and
insertSubscriberData.
MAP-INSERT-SUBSCRIBER-DATA service
This service is used by an HLR to update an SGSN with certain subscriber data in the following
occasions:
- if the GPRS subscription has changed;
- if the network access mode is changed;
- the operator has applied, changed or removed Operator Determined Barring;
- the subscriber has changed data concerning one or more supplementary services by using a
subscriber procedure;
- the HLR provides the SGSN with subscriber parameters at GPRS location updating of a subscriber
MAP-DELETE-SUBSCRIBER-DATA service
This service is used by an HLR to remove certain subscriber data from an SGSN if the subscription of
one or more services is withdrawn.
3.3.5 Parameters Definitions and Use
Relevant parameters to be considered regarding the Profile Management, transmitted within Location
Updating Procedures or Standalone ISD Procedures:
Subscriber Status
It is included either at location updating or when it is changed.
Operator Determined Barring information may be present according to DSP restriction applied to the
customer.
GPRS Subscription Data
This parameter contains a list of PDP-contexts a user has subscribed to and it shall contain the EU
Internet APN with proper VPAA flag, according to the LBO service selected by the customer.
At GPRS location updating, the HLR shall include the complete GPRS Subscription Data.
When there is a change in GPRS subscriber data the HLR shall include only the new and/or modified
PDP contexts and this will be applied during subscription and un-subscription of LBO services. When
the SGSN receives GPRS Subscription Data within a dialogue it shall check if the received data has to
be considered as the entire GPRS subscription data. If so, it shall replace the stored GPRS
Subscription Data with the received data set, otherwise it shall replace the data only for the modified
PDP contexts (if any) and add the new PDP contexts (if any) to the stored GPRS Subscription Data.
If the SGSN detects that there is overlapping in the information received within a dialogue, it shall
send the error Unexpected Data Value.
Access Restriction Data
This parameter indicates the allowed RAT according to subscription data. It is supposed no Access
Restriction is sent by the HLR within this procedure.
page 88/96
Figure 48 – Update GPRS Location call flow
3.3.6 Error Handling
Error Handling is implemented according to 3GPP TS 29.002
Implementation errors to be handled as per the roaming agreement.
page 89/96
3.4
LBO-IF2 : LBO notification interface
3.4.1 Description
IF2 interface is a NEW interface to provide notification to the HPMN of the LBO subscription.
Notification may be used by the HPMN to improve traffic steering policy, based on a dynamic
subscriber profile management


Conditional to LBO provider: it should send notifications to HPMN if requested to do so.
Optional to HPMN: it is up to the HPMN to decide whether it wants or not the notifications. The
HPMN shall demonstrate the use of the notification (the notification request cannot be used
solely for entry barrier reason). A demonstration for example could be the technical
acknowledgement of the message.
Due to late BEREC input, this interface will be defined at a later stage (expected date: September
2013)
3.4.2 Detailed Procedures at DSP
tbd
3.4.3 Detailed Procedures at LBO
tbd
3.4.4 Interface primitives
tbd
3.4.5 Parameters Definitions and Use
tbd
3.4.6 Error Handling
tbd
page 90/96
3.5
ANNEX - Study on Home Routing and Legal interception cases
3.5.1 DSP Home Routing – CAP v1
The figure below illustrates the scenarios when the DSP administrates the re-routing number ranges in
a separate network entity/proxy. The re-routing number range does not affect the signaling and the
service of the ARP. The DSP has the exclusive responsibility about this number range.
Next to the re-routing numbers the proxy has the responsibility to setup a CAP IDP operation (5) to the
dedicated ARP network element (NE). This IDP operation (5) must contain at least the original calling
and called party numbers and the location information (VLR address of the EU Visited MSC) from the
first IDP operation (1).
EU VPLMN
DSP HPLMN
Visited
MSC
Gateway
MSC
ARP PLMN
Proxy
1. CAP IDP
ARP NE
CLI, CLD,
Skey, VLR,
Rerouting No.
2. CAP CON
3. ISUP IAM
4. CAP/INAP IDP
5. CAP IDP
CLI, CLD,
Skey, VLR
6. CAP RRBCSM
7. CAP/INAP RRBCSM
8. CAP CON/CUE
9. CAP/INAP CON/CUE
Figure 49 – DSP Home Routing with CAP v1 interface to ARP
Pros:


Cons:



DSP has the responsibility about the administration of the re-routing numbers. This number
range need to be not considered in the IR.21 document.
DSP is aware about signaling and the Proxy or the Gateway MSC generates IN CDRs for
Wholesale Billing.
The proxy requires a service logic for identification of the two correlated trigger (1 and 4). A
new CAP IDP operation (5) for the ARP NE must be setup by the proxy.
Because of the limited CAP v1 operations no announcements are supported
(ConnectToResource, EstablishTemporaryConnection).
The ARP has to inform a customer about e.g. low credit with a SMS or USSD string (both
interfaces are optional).
page 91/96
3.5.2 DSP Home Routing – CAP v2
This scenario is comparable with the scenario in previous chapter. The difference is a CAP v2
interface between the DSP and ARP. The advantage of CAP v2 is the support of announcement
operations except the mid call announcement. The EDP (8) is available since Camel v4.
EU VPLMN
DSP HPLMN
Visited
MSC
Gateway
MSC
ARP PLMN
Proxy
1. CAP (v1) IDP
ARP NE
CLI, CLD,
Skey, VLR,
Rerouting No.
2. CAP (v1) CON
3. ISUP IAM
4. CAP (v2)/INAP IDP
5. CAP (v2) IDP
6. CAP (v2) RRBCSM
CLI, CLD,
Skey, VLR
7. CAP (v2)/INAP RRBCSM
8. CAP (v2) CON/CUE
9. CAP (v2)/INAP CON/CUE
Figure 50 – DSP Home Routing with CAP v2 interface to ARP
Pros:



Cons:

DSP has the responsibility about the administration of the re-routing numbers. This number
range need to be not considered in the IR.21 document.
DSP is aware about signaling and the Proxy or the Gateway MSC generates IN CDRs for
Wholesale Billing.
ARP can initiate announcements (ConnectToResource, EstablishTemporaryConnection) for
his subscribers, e.g. low credit.
The proxy requires a service logic for identification of the two correlated trigger (1 and 4). A
new CAP IDP operation (5) for the ARP NE must be setup by the proxy.
page 92/96
3.5.3 ARP Home Routing – CAP v1
In this scenario the ARP disposes of an own re-routing number range. The owner of this range is the
DSP but the usage is restricted for the ARP.
EU VPLMN
DSP HPLMN
Visited
MSC
Gateway
MSC
ARP PLMN
Proxy
ARP NE
1. CAP IDP
2. CAP IDP
3. CAP CON
4. CAP CON
5. ISUP IAM
6. CAP IDP
7. CAP RRBCSM
8. CAP CON/CUE
Figure 51 – ARP Home Routing with CAP v1 interface to ARP
Pros:


Cons:




Dependent of the calling party number the proxy has to forward the trigger to the dedicated
ARP. The administration of correlated IDP operations is not in the proxy but in the ARP NE
required.
DSP is aware about signaling and the Gateway MSC is able to generate CDRs for Wholesale
Billing.
The DSP has to reserve for every ARP a unique re-routing number range.
For an ARP additional development effort is required for identification of the correlated IDP
operations.
Because of the limited CAP v1 operations no announcements are supported
(ConnectToResource, EstablishTemporaryConnection).
The ARP has to inform a customer about e.g. low credit with a SMS or USSD string (both
interfaces are optional).
page 93/96
3.5.4 ARP Home Routing – CAP v2
This scenario is comparable with the previous CAP V1 – ARP Home routing scenario. The difference
is only the CAP v2 interface between the Proxy and the ARP.
EU VPLMN
DSP HPLMN
Visited
MSC
Gateway
MSC
ARP PLMN
Proxy
ARP NE
1. CAP (v1) IDP
2. CAP (v2) IDP
3. CAP (v2) CON
4. CAP (v1) CON
5. ISUP IAM
6. CAP (v2) IDP
7. CAP (v2) RRBCSM
8. CAP (v2) CON/CUE
Figure 52 – ARP Home Routing with CAP v2 interface to ARP
Pros:



Cons:


Dependent of the calling party number the proxy has to forward the trigger to the dedicated
ARP. The administration of correlated IDP operations is not in the proxy but in the ARP NE
required.
DSP is aware about signaling and charging of ARP subscribers. The Gateway MSC is able to
generate CDRs for Wholesale Billing.
ARP can initiate announcements (ConnectToResource, EstablishTemporaryConnection) for
his subscribers, e.g. low credit except the mid call announcement. The EDP (8) is available
since Camel v4.
The DSP has to reserve for every ARP a unique re-routing number range.
For an ARP additional development effort is required for identification of the correlated IDP
operations.
page 94/96
3.5.5 Legal Interception
Dependent on the national legal requirement it has to be investigated if an interception of the ARP
subscribers is required in the HPLMN of the DSP.
3.5.6 Summary of the solutions
DSP
DSP
ARP
ARP
Homerouting - Homerouting - Homerouting - Homerouting CAP v1
CAP v2
CAP v1
CAP v2
Service responsibility
of Re-Routing No.
DSP
DSP
Owner of the ReRouting No.
DSP
DSP
DSP Wholesale
Charging for an ARP
subscriber per call
+
+
Assistance of ARP
announcements
+
(*) Since CAP v2 announcement operations are supported
page 95/96
ARP
ARP
DSP
DSP
+
+
-
+
End of Document
page 96/96