Traffic Cases

Charging Compound 1

CUSTOMER PRODUCT INFORMATION

2/1551-FAV 101 72/4 Uen L

Copyright

© Ericsson AB 2010–2016. All rights reserved. No part of this document may be

reproduced in any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due to
continued progress in methodology, design and manufacturing. Ericsson shall
have no liability for any error or damage of any kind resulting from the use
of this document.

Trademark List

All trademarks mentioned herein are the property of their respective owners.
These are shown in the document Trademark Information.

2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Contents

Contents

1 Introduction 1
1.1 Purpose and Scope 1
1.2 Typographical Conventions 1
1.3 Deprecation 2

2 General 3

3 Common for All Traffic Cases 5

3.1 Mobile Number Portability 5
3.2 Community Charging 5
3.3 Location Based Charging 6
3.4 Yield Optimization 7
3.5 Notifications 8
3.6 SDP Selection 10
3.7 Subscription ID Independence 11

4 Traffic Cases 13
4.1 Real-Time Charging Services 13
4.2 Offline Charging Services 54
4.3 Voucher Refill and Enquiry 57
4.4 B-number Modification 64

Glossary 71

Reference List 75

2/1551-FAV 101 72/4 Uen L | 2016-11-30

Traffic Cases

2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Introduction

1 Introduction

This section describes the purpose and scope of this document, as well as
typographical conventions used.

1.1 Purpose and Scope

The purpose of this document is to describe exemplifying signalling sequences
for different traffic scenarios in the Charging System.

The signalling sequence examples provided in this document are not meant to
cover all possible scenarios. The purpose is to give a general overview.

The main target groups for this document are as follows:

• Network administrators

• System administrators

• Application administrators

• Operation and Maintenance (O&M) personnel

For information regarding the target groups, see the Customer Product
Information Overview, Reference [1].

1.2 Typographical Conventions

This document follows a set of typographic rules that make the document
consistent and easy to read. The typographic conventions are found in the
Customer Product Information Overview, Reference [1].

In addition to the writing conventions mentioned above, the following applies:

• The term Multi Mediation Solution is used whenever a reference to the

associated products File and Event Mediation, Online Mediation, or
Ericsson Multi Mediation is needed.

Note: Event Mediation, Online Mediation, and Ericsson Multi Mediation

can appear either together or independently in other Charging
System Customer Product Information (CPI), when used as
example of the Multi Mediation solution needed.

• The term Service Data Point (SDP) is used whenever a reference to the
network element SDP Prepaid is needed.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 1

 Traffic Cases

1.3 Deprecation
Elements can be deprecated but are still described in the documentation.

For a general description of deprecation and details of what is deprecated, see

the System Description, Reference [5] and for respective network element the
Network Element Description.

For information on what is deprecated since previous release, see the Network
Impact Report, Reference [3].

No further details about what is deprecated is given in this document.

2 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 General

2 General

The Charging System can charge different types of calls and events. This is
done either online (in real time) or offline.

For all traffic cases, described in this document the following applies:

• The call-flows describe logical signalling paths, not physical connections.

• The call-flows describe non-fault situations. Error handling is not covered.

• The call-flows are dependent on service class settings and the service state.

The different protocols and services are used as follows:

• CS1+ is used for voice and SMS-related services.

• CAMEL Application Part version 1 (CAPv1) is used for voice-related

services.

• CAPv2 is used for voice-related services.

• CAPv3 is used for SMS and GPRS services.

• Diameter, Draft 8, is used for content based services in real time.

• Diameter Credit Control Application (DCCA) is used for online credit control
of content based services.

• Ericsson RealTime Charging protocol (ERTC) is used for voice and

SMS-related services.

• Mobile Application Part version 2 (MAPv2), or higher, is used for

Unstructured Supplementary Service Data (USSD) notifications.

• ETSI MAP can be used for USSD End of Call Notification, USSD Callback,
and Any Time Interrogation (ATI).

• Multimedia Telephony Application Server Ro (MTAS) is used for real-time

cost and credit control of MultiMedia Telephony (MMTel) voice and video
traffic.

The Service Control Point (SCP) is the generic name for the function(s) that
CCN realizes in the Charging System. Throughout the flowcharts in this
document CCN are used as the SCP, except for MMTel voice and video traffic
where OCC is used.

For more information regarding Charging System, see the System Description,
Reference [5].

2/1551-FAV 101 72/4 Uen L | 2016-11-30 3

 Traffic Cases

4 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Common for All Traffic Cases

3 Common for All Traffic Cases

This chapter describes different features valid for all traffic cases.

3.1 Mobile Number Portability

Mobile Number Portability (MNP) in a network offers a mobile subscriber
possibility to keep its number independently of a network operator choice. MNP
makes it possible to differentiate charging of a Charging System subscriber for
calls and SMS that the subscriber makes or receives. This is based on the
portability information retrieved from an MNP database.

For CAPv2 mobile originating calls, the called party number and calling party
number is compared. If the numbers are equal, meaning the subscriber dialed
their own number, then CCN sets the network identifier parameter to an
operator configured value without going to the Local Number Portability (LNP)
or MNP database to perform Mobile to Mobile (M2M) check.

Figure 1 illustrates MNP.

CCN MNP

1
2

Figure 1 Mobile Number Portability

1. The call is initiated by the Charging System subscriber.

2. If it is an originating or forwarded call: the called party number is sent to

the MNP database.

If it is a terminating call: the calling party number is sent to the MNP

database.

3. The MNP database returns MNP information to CCN, for delivery to SDP.

3.2 Community Charging

Community Charging makes it possible to offer different tariffs when subscribers
are calling within or between communities. Community Charging is not included
in any of the flowcharts. If not stated, in this document, but when active it is
performed immediately before the first interrogation is sent to SDP. Community
Charging is available for all services and for both prepaid and post-paid
subscribers.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 5

 Traffic Cases

Figure 2 illustrates community charging.

SDP or Ext
SDP AF
DB

1
2
3
4
5

Figure 2 Community Charging

1. CCN performs a first interrogation towards an SDP.

Note: Retrieval of the non-served subscribers community data is not

performed. That is, step 2–5 are omitted if the non-served
subscribers number is part of a number list indicating that the
number is never part of a community or if there is no non-served
subscriber present for pre-rated services.

If the non-served subscribers number is part of a number list

indicating that the number is known to be stored in external
database AF is not interrogated. Step 2 and 3 are then skipped

2. SDP retrieves the SDP-ID for the non-served subscriber.

3. AF returns the SDP-ID.

4. SDP requests community data for the non-served subscriber from the entity
holding the non-served subscribers data.

5. The entity holding the non-served subscribers community data returns

community data for the non-served subscriber. This data is used for rating
in SDP.

3.3 Location Based Charging

Location Based Charging (LBC), see Figure 3, can be performed for originating,
terminating, and forwarded voice calls. It can also be performed for data
(SCAPv2 and Gy). Location information can be fetched for ported or non-ported
non-served subscribers.

LBC is performed for Service Charging Application Protocol (SCAP) MO SMS.

6 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Common for All Traffic Cases

CCN HLR VLR

1
2
3
4
5

Figure 3 LBC

1. A charging request is received from the MSC, the request contains location
information for the served subscriber.

Note: CCN compares received call party number (originating and

forwarded calls), or calling party number (terminating calls), with
internal number lists. If the received number exists in the number
list, a query can be sent to the HLR in step 2. If no match is found
in the internal number list, a default location number is allocated
to the non-served subscriber.

2. CCN requests location information for the non-served subscriber.

3. The HLR requests the location information from the VLR.

4. The VLR returns the location information to the HLR.

5. The HLR returns the location information. The received information both
from the MSC and from the HLR is forwarded to SDP (not shown in
previous figure).

3.4 Yield Optimization

At start of a charging session the discount is determined based on the
location of the subscriber. The Yield Optimization (YO) function is valid for
originating voice and circuit switched SMS sent over CS1+, CAPv2, CAPv3,
and ERTC/RTCfA. Data is supported using Gy and SCAPv2.

Core network CCN SDP HLR

1
2
3
4
5
6
.
.
.

Figure 4 Yield Optimization, Tariff Update Approach

2/1551-FAV 101 72/4 Uen L | 2016-11-30 7

 Traffic Cases

1. The subscriber initiates a charging session.

2. The core network sends call party number to CCN.

3. CCN makes an interrogation lookup towards HLR requesting location

information based on the call party number from the core network.

4. The HLR returns the location information to CCN.

5. CCN performs an SDP selection and sends the location information data
collected in Step 4, along with other data, in a first interrogation/intermediate
interrogation to SDP.

6. SDP uses the information to determine the appropriate discount in the tariff
database and reserves money from the account. The calculated session
time is sent to CCN, together with other call data such as announcements
to be played. A charging session starts and can have several intermediate
interrogations.

7. At every intermediate interrogation from CCN to SDP, CCN monitors the

age of the answer in Step 4 against a predetermined time period. If a
certain amount of time has elapsed since the last HLR interrogation, a
new interrogation towards the HLR is made and the new data received
is processed. The default time period between HLR interrogations is 60
minutes but is configurable to 15, 30, or 60 minutes. It is not recommended
to make the interval smaller than five minutes.

Note: Step 3–7 can be repeated several times.

For more examples, see the User Guide Yield Optimization, Reference [6].

3.5 Notifications
In the Charging System, there are different ways to communicate with the
subscriber. USSD notifications are used for both sending and receiving
messages while SMS notifications only is used for sending messages to the
subscriber.

This section describes the different End-User Notifications the Charging System
can send to the subscriber.

3.5.1 USSD Notifications

In Figure 5, an example of USSD end-of-call notification is shown. If end-of-call
notification is enabled, these steps always follow at the end of a call.

8 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Common for All Traffic Cases

MSC/SSF CCN SDP HLR

1
2

5
6

Figure 5 USSD Notifications

1. The call is released.

2. The MSC sends information to the SSF about the call, and the SSF sends
an Intelligent Network Application Protocol (INAP) message to CCN about
the disconnection.

3. CCN analyses the disconnection from the mobile phone and sends
information about the call to SDP for rating.

4. SDP calculates the cost for the service. Then a text string is composed in
the correct language and currency and if necessary the country code is
added to the MSISDN. SDP sends the composed USSD message to the
HLR.

5. The HLR transfers the USSD message to the correct MSC.

6. The MSC sends the USSD message to the subscribers mobile phone and
the result is shown on the display.

3.5.2 SMS Notification

In Figure 6, an example of SMS end-of-call notification is shown. If end-of-call
notification is enabled, it is always performed at the very end of a call.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 9

 Traffic Cases

MSC/SSF CCN SDP SMS-C

1
2

Figure 6 SMS Notification

1. The service is disconnected.

2. The MSC sends information to the SSF, and the SSF sends a message to
CCN about the disconnection.

3. CCN analyses the disconnection from the mobile phone and sends
information about the call to SDP for rating.

4. SDP calculates the cost for the service. Then a text string is composed in
the correct language and currency and if necessary the country code is
added to the MSISDN. SDP sends the composed SMS message to the
SMS-C.

5. The SMS-C sends the SMS message to the subscribers mobile phone and
the result is shown on the display.

3.6 SDP Selection

Charging System supports scalability of accounts by adding SDP network
elements. This means that accounts in Charging System can be distributed
over several SDPs. To locate which SDP a specific account resides on, the
Domain Name Service (DNS) database in the Account Finder (AF) is used.
CCN uses AF to identify which SDP a call or session is routed to. CCN can use
either AF lookup, service key routing, or number series routing towards SDPs.
Which of the methods that are used are configured in CCN. It is also possible to
configure CCN to cache the AF lookups to limit the number of requests to AF.

3.6.1 Static SDP Selection

In static SDP Selection, there is only one SDP.

10 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Common for All Traffic Cases

3.6.2 Service Key Selection

The service keys can be used for routing to the correct SDP when multiple
SDPs are used. The Service keys are passed from the SSF to CCN.

3.6.3 MSISDN Selection

CCN gets the MSISDN from the Initial Detection Point (IDP), then SDP is
selected according to the callers MSISDN.

3.6.4 Account Finder Selection

Account finder selection can in some cases replace service key routing.

Account finder selection is not included in any of the flowcharts in this document,
but when active, it is performed immediately before the first interrogation is
sent to SDP. In Figure 7, an example of Account Finder Selection is shown.
In this example CCN is used in the figure, but the example is the same with
OCC as an alternative to CCN.

CCN AF

1
2

Figure 7 Account Finder Selection

1. CCN or OCC sends the MSISDN to AF requesting which SDP the call
is routed to.

2. AF uses the MSISDN to identify the SDP and sends the result back to
CCN or OCC.

3.7 Subscription ID Independence

Charging System supports other subscription identifiers than MSISDN when
accessing CCN. This requires that account finder selection is used for SDP
selection. CCN then sends the received subscription identifier to AF and
receives which SDP to route to and the MSISDN of the subscription. The
MSISDN is then used when communicating with SDP.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 11

 Traffic Cases

12 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

4 Traffic Cases

This section describes the different call and service types that are supported
by Charging System.

In the traffic cases following, Mobile Number Portability (MNP) and Location
Based Charging is not used, if it is not stated. For information about MNP, see
Section 3.1 on page 5 and Section 3.3 on page 6 for Location Based Charging.

4.1 Real-Time Charging Services

The Charging System can supervise charged sessions in real time.

The Charging System subscribers have the possibility to make and receive
real-time calls when roaming outside the Home Public Land Mobile Network
(HPLMN). A Charging System subscriber can be prevented from making calls
when roaming outside the HPLMN. This is decided by business configurations
and roaming agreements.

To allow for efficient call handling in the HPLMN, the network operator can offer
the capabilities of the Ericsson proprietary feature Extended CAMEL. With
this feature, the subscriber triggers Charging System using INAP CS1+ in the
HPLMN and CAMEL in the VPLMN.

With the CAPv3 SMS MO over CIP/IP function, a new CIP/IP based charging
context is available between SPD and CCN. If CIP/IP is not enabled in the
configuration, CIP/SS7 is used instead.

This chapter describes different types of real-time Charged calls.

4.1.1 Charged Calls (CS1+)

This chapter describes the traffic cases for charged calls CS1+. For an
overview of the traffic cases, see Table 1.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 13

 Traffic Cases

Table 1 Overview of Traffic Case, Charged Calls CS1+

Description Involved Charging CDR Gener Applies To
System Network ation in the
Elements Charging
System
The Charging System supervises each charged call in real CCN and SDP. CCN or the Originating,
time. A Charging System account can never be overdrawn. If MSC/SSF. Terminating, and
a subscriber tries to call when the Service Scenario or account Forwarded Calls
value limit (service class prepaid empty limit or account in the HPLMN and
prepaid empty limit) has been reached, then the call is never Terminating Calls in
established. the VPLMN.
If a subscriber runs out of money on the account, the call is
disconnected by the Call Cut-off procedure.

In Figure 8, an originating charged call, with CS1+, is shown. This is followed

by an explanation of all steps in the figure. Terminating and Forwarded calls
work in a similar fashion in a Charging System point of view and is not shown
in detail here.

14 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

MSC/SSF CCN SDP

1 2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

Figure 8 Originating Charged Call, CS1+

1. A call is initiated from a charging system subscriber. The Originating IN

Category Key (OICK) of the subscriber in the VLR, routes the call to the
SSF.

2. The SSF collects data about the call and triggers CCN.

3. CCN performs an SDP selection and sends the data, collected in step 2, in
a first interrogation to SDP. Optionally, CCN performs an MNP lookup or an
LBC lookup, or both, at this stage.

4. SDP reserves money from the account and sends the calculated call time
to CCN, together with other call data such as announcements to be played.

5. CCN tells the SSF to play announcements if this has been requested by
SDP. Further on, CCN tells the SSF to set up the call and to supervise it
based on the call time calculated by SDP.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 15

 Traffic Cases

6. The call lasts longer than the call time sent to the SSF, so a notification
is sent to CCN.

7. CCN requests SDP to make another reservation from the account with an
intermediate interrogation.

8. SDP makes a new charging analysis and deducts the amount previously
reserved from the account. In this example, it is assumed that there are still
sufficient funds left on the subscribers account. SDP then reserves money
for the next period and forwards a new call time to CCN.

9. CCN passes the new call time on to the SSF.

Note: Step 6–9 can be repeated several times.

In this example, steps 10–17 describes what happens when the

subscribers account balance reaches the account empty limit
(service class prepaid empty limit or account prepaid empty limit).

10. The call lasts longer than the call time sent to the SSF and a notification
is sent to CCN.

11. CCN requests SDP to make another reservation from the account with an
intermediate interrogation.

12. SDP makes a new charging analysis and updates the account. The
charging analysis shows that there is not enough money on the account
to cover the requested period. SDP sends the calculated call time to CCN
together with an indication that there is no money left on the account and
that a call cutoff warning announcement is to be played. The time between
the warning announcement and call cutoff can be configured. For this
example 30 seconds is used.

13. CCN uses the 30 seconds indication from SDP and the time between call
cutoff warning and call cutoff is excluded from the new call time. CCN then
passes the new call time on to the SSF.

14. The SSF notifies CCN that the time sent down in step 13 has expired.

15. CCN sends the remaining 30 seconds and tells the SSF to play the call
cutoff warning announcement.

16. The SSF notifies CCN that the final 30 seconds has expired.

17. CCN tells the SSF to play the call cutoff announcement and to disconnect
the call.

18. The SSF notifies CCN of the call disconnection.

19. A final report is sent from CCN to SDP. SDP performs final charging of
the call.

20. SDP rates the total call and sends a final report result to CCN.

16 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

21. CCN sends a call release to the SSF.

Note: If end-of-call notification is enabled a notification is sent to the

subscriber, see Section 3.5.1 on page 8.

4.1.2 Charged Calls (ERTC)

This chapter describes the traffic cases for Charged Call ERTC. For an
overview of the traffic cases, see Table 2.

Table 2 Overview of Traffic Cases, Charged Calls ERTC

Description Involved Charging CDR Generation Applies To
System Network in the Charging
Elements System
Charged Calls ERTC enables Real Time Charging through CCN and SDP. CCN Originating,
the MSC in the HPLMN without the invocation of IN or Terminating, and
CAMEL. When roaming, outside the HPLMN the subscriber Forwarded Calls
can have a CAMEL trigger to provide for CAMEL roaming. in the HPLMN and
Terminating Calls in
the VPLMN

In Figure 9, a mobile originating charged call with Real Time Charging for All
(RTCfA) is shown. Terminating calls work in a similar fashion in a charging
system point of view. If a forwarded call triggers the Charging System, two
sessions, one terminating and one originating, are executed through the
Charging System to charge for the forwarded call.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 17

 Traffic Cases

MSC CCN SDP

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Figure 9 Originating Charged Call, ERTC

1. A call is initiated from the subscriber.

2. The MSC collects data about the call and triggers CCN.

3. The data collected from the MSC is mapped to a first interrogation in CCN.
CCN makes an SDP selection and sends the data, collected in step 2, to
SDP. The service scenario of the account is checked and a preliminary
charging analysis takes place.

4. SDP reserves money from the account and sends the calculated call time
to CCN, together with other call data such as announcements to be played.

5. CCN stores the call data received from SDP. CCN sends a reply to allow
the call to continue.

6. The call lasts longer than the call time calculated. The MSC requests CCN
for a new reservation.

7. CCN forwards the request to SDP to make another reservation from the
account with an intermediate interrogation.

18 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

8. SDP makes a new charging analysis and deducts the amount previously
reserved from the account. There are still sufficient funds on the subscribers
account, so SDP sends back a new reservation period to CCN.

9. CCN passes on the interrogation result to the MSC.

Note: Step 6–9 can be repeated several times.

In this example, the following steps describe what happens when

the balance on the subscribers account reaches the account empty
limit (service class prepaid empty limit or account prepaid empty
limit).

10. The MSC call leg monitoring detects that the call reservation is because of
be extended. The MSC requests CCN for a new reservation.

11. CCN forwards the request to SDP to make another reservation from the
account with an intermediate interrogation.

12. SDP makes a new charging analysis and deducts the amount previously
reserved from the account. The charging analysis shows that there is not
enough money on the account to cover another full requested period. SDP
sends the calculated maximum call time to CCN, together with a call cutoff
warning announcement.

13. CCN forwards this information to the MSC. The MSC call leg monitoring
detects that it is time for the call cutoff warning announcement. The MSC
plays the announcement to the subscriber and then orders the call to be
released.

14. The MSC releases the call, collects data about the call, and sends it to CCN.

15. CCN acknowledges the call release to the MSC.

16. A final report is sent from CCN to SDP.

17. SDP calculates the total cost of the call and sends a final report result
to CCN.

Note: If end-of-call notification is enabled a notification is sent to the

subscriber, see Section 3.5.2 on page 9.

4.1.3 Toll-Free Calls (ERTC)

This chapter describes the traffic case for Toll-Free Call ERTC. For an overview
of the traffic case, see Table 3.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 19

 Traffic Cases

Table 3 Overview of Traffic Case, Toll-Free Calls ERTC

Description Involved Charging CDR Gener Applies To
System Network ation in the
Elements Charging
System
The Charging System Operators can offer Toll-Free Numbers CCN and SDP. CCN Originating and
to their Charging System subscribers. They are stored in the Forwarded calls
Service Class of the subscriber or on a service level. Toll-Free in the HPLMN.
Numbers on a service level are available to subscribers of all
Service Classes.

The following, see Figure 10, applies for an originating toll-free call with RTCfA.

MSC CCN SDP

1
2
3
4
5

Figure 10 Toll-Free Call, ERTC

1. A call is initiated from a subscriber.

2. The MSC collects data about the call and triggers CCN.

3. A first interrogation is sent to SDP where the service scenario of the

account is checked and an analysis takes place. The output from the
analysis indicates that this is a toll-free call. SDP is configured so no CDRs
are generated for Toll-free calls.

Note: It can be configured whether a CDR is to be generated or not

in CCN for toll-free calls. The generated CDR can be used for
statistical purposes. If a CDR is to be generated, or call setup
result is to be sent to SDP, then a final report is sent to SDP.

4. SDP returns the charging analysis result to CCN.

5. CCN forwards the result to the MSC. The Charging System has no further
involvement in the call.

4.1.4 Charged Calls (MTAS Ro)

This chapter describes the traffic cases for charged calls with MTAS Ro. For an
overview of the traffic cases, see Table 4.

20 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

Table 4 Overview of Traffic Case, Charged Calls with MTAS Ro

Description Involved Charging CDR Gener Applies To
System Network ation in the
Elements Charging
System
The MTAS Ro service context is a proprietary interface OCC and SDP. OCC or MTAS. Originating,
towards the Ericsson implementation of the MMTel Application Terminating, and
Server. It is used for real-time cost and credit control of MMTel Forwarded Calls
voice and video traffic. in the HPLMN and
VPLMN.

In Figure 11, an originating charged call, with MTAS Ro, is shown. This is
followed by an explanation of all steps in the figure. Terminating and Forwarded
calls work in a similar fashion in a Charging System point of view and is not
shown in detail here.

MTAS OCC SDP

1 2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Figure 11 Originating Charged Call, MTAS Ro

2/1551-FAV 101 72/4 Uen L | 2016-11-30 21

 Traffic Cases

1. A call is initiated from a charging system subscriber.

2. MTAS collects data about the call and triggers OCC.

3. OCC performs an SDP selection and sends the data, collected in step 2, in
a first interrogation to SDP.

4. SDP reserves money from the account and sends the calculated call
time to OCC. If there is insufficient fund on the account for the call, a
low-balance-indication is sent to OCC.

5. OCC tells MTAS to set up the call and to supervise it. MTAS can decide if
an announcement is to be played if low-balance-indication is received.

6. B-party answers the call.

7. A notification that B-party has answered the call is sent.

8. OCC requests SDP to reserve new units from the account. SDP makes a
new charging analysis based on the updated data available at the B-party
answer. No units are deducted since none has been consumed yet.

9. SDP then reserves money for the next period and forwards a new call
time to OCC.

10. OCC passes the new call time to MTAS.

11. The threshold for consumed units is reached, and a notification is sent
to OCC.

12. OCC requests SDP to make another reservation from the account.

13. SDP makes a new charging analysis and deducts the consumed units from
the account. In this example, it is assumed that there are still sufficient
funds left on the subscribers account. SDP then reserves money for the
next period and forwards a new call time to OCC.

14. OCC passes the new call time on to the MTAS.

Note: Step 11-14 can be repeated several times.

15. A media change is initiated or a supplementary service is started.

16. MTAS informs OCC that a media change is initiated or that a supplementary
service has been started.

17. OCC requests SDP to make another reservation from the account with an
intermediate interrogation.

18. SDP makes a new charging analysis and updates the account and deducts
consumed units from the account.

19. OCC passes the new call time to MTAS.

22 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

20. The threshold for consumed units is reached, and a notification is sent
to OCC.

21. OCC requests SDP to make another reservation from the account.

22. SDP makes a new charging analysis and deducts the consumed units from
the account. The charging analysis shows that there is not enough money
on the account to cover the requested period. SDP then reserves the final
units for the next period and forwards a new call time to OCC.

23. OCC passes the new call time and final-unit-indication to MTAS. MTAS can
use the final-unit-indication to trigger off call cut warning announcements in
the IMS system.

24. The call is disconnected.

25. MTAS notifies OCC of the call disconnection.

26. A final report is sent from OCC to SDP. SDP performs final charging of
the call.

27. SDP rates the total call and sends a final report result to OCC.

28. OCC sends a call release to MTAS.

4.1.5 SMS IN Triggered Charging (CS1+)

This chapter describes the traffic case SMS IN Triggered Charging. For an
overview of the traffic case, see Table 5.

Table 5 Overview of Traffic Case, SMS IN Triggered Charging (CS1+).

Description Involved Charging CDR Generati Applies To
System Network on in Charging
Elements System
IN triggered SMS charging allows the network operator CCN and SDP. CCN or the Originating and
to charge for short message transactions in real time MSC/SSF Terminating short
without using CAMEL. The Charging System intercepts the messages in
short message in the MSC/VLR and simulates a regular the HPLMN and
Charging System call. Terminating in the
VPLMN.

This example, see Figure 12, describes SMS IN triggered originating charging
with two interrogations. One for checking the account balance and one for
deducting the cost of the SMS. Terminating calls work in a similar fashion in a
charging system point of view and is not shown i detail here.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 23

 Traffic Cases

SMS-C MSC/SSF CCN SDP

1
2
3
4
5
6
7
8
9
10
11
12

13

Figure 12 IN Triggered SMS, CS1+

1. An SMS is sent based on OICK and the destination address routes it

to the SSF.

2. The SSF collects data about the call and triggers CCN to check the account.

3. The data, collected in step 2, is sent in a first interrogation to SDP, where

the service scenario of the account is checked and a preliminary charging
analysis takes place. No reservation of money is performed in this step.

4. SDP sends the result of the interrogation to CCN.

5. CCN sends a successful result to the SSF.

6. The MSC delivers the SMS to the SMS-C.

7. The delivery of the SMS is confirmed by the SMS-C.

8. The MSC/SSF triggers CCN to deduct the fee of the SMS.

9. CCN sends a first interrogation to SDP where the service scenario of the
account is checked and a preliminary charging analysis takes place.

10. SDP reserves money from the account and sends a successful result,
together with other call data, to CCN.

11. CCN sends a final report to SDP.

24 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

12. SDP rates the total cost, deducts money from the account and sends a
final report result to CCN.

13. CCN sends a release operation with a successful deduct code to the
MSC/SSF.

Note: If end-of-call notification is enabled a notification is sent to the

subscriber, see Section 3.5.1 on page 8.

4.1.6 SMS Charging Based on CAMEL Phase 3

This chapter describes the traffic case SMS Charging based on CAMEL Phase
3. For an overview of the traffic case, see Table 6.

Table 6 Overview of Traffic Case, SMS Charging Based on CAMEL phase 3

Description Involved Charging CDR Generation Applies To
System Network in the Charging
Elements System
CAMEL phase 3 SMS charging allows the operator to charge CCN and SDP. CCN Originating SMS
for mobile originating SMS in real time. This traffic case in both the
always interacts twice with the Charging System, once to HPLMN and the
check the account balance and once at delivery to the SMS-C VPLMN.
to deduct the cost from the account.
Both Circuit Switched (CS) and Packet Switched (PS) Mobile
Originating SMS is supported.

The preconditions for the traffic case, SMS charging based on CAMEL phase 3,
are described in the following bullet list.

• The SMS is Circuit Switched (CS).

• All network elements are located in the HPLMN.

• The SMS is charged, not toll free.

• The MNP is active.

• The community charging is active.

• The subscribers account is a preactivated account (life cycle notification).

• There are sufficient funds left on the subscribers account for the SMS
(money available).

2/1551-FAV 101 72/4 Uen L | 2016-11-30 25

 Traffic Cases

SMS-C MSC/SSF CCN SDP

1
2
3

4
5
6

7
8
9

Figure 13 SMS Charging Based on CAMEL Phase 3

1. An originating SMS is received by the MSC/SSF.

2. The MSC/SSF analyses the data and interrogates the serving CCN.

3. CCN interrogates SDP. Optionally, an MNP lookup can be performed here,

see Section 3.1 on page 5.

4. SDP verifies the account status, reserves money and sends the result to
CCN. If Community Charging is enabled it is performed at this stage, see
Section 3.2 on page 5.

5. CCN replies to the interrogation from the SSF based on the result from SDP.

6. The MSC/SSF delivers the SMS to the SMS-C.

7. The SMS-C confirms the delivery of the SMS.

8. The MSC/SSF forwards the result to CCN.

9. CCN forwards the result to SDP. SDP charges the corresponding account.

Note: If end-of-call notification is enabled a notification is sent to the

subscriber, see Section 3.5.1 on page 8.

4.1.7 CAPv3 MO SMS Calls (CIP/IP)

This chapter describes the traffic case CAPv3 MO SMS calls. For an overview
of the traffic case, see Table 7.

26 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

Table 7 Overview of Traffic Case, CAPv3 SMS MO over CIP/IP

Description Involved Charging CDR Gener Applies To
System Network ation in the
Elements Charging
System
The CAPv3 SMS MO over CIP/IP function introduces a CIP/IP based CCN and SDP CCN Originating
charging context in CCN and SDP. SMS in both
the HPLMN and
The context is applicable to SMS MO traffic. the VPLMN.

The preconditions for the traffic case, CAPv3 MO SMS Calls, are described in
the following bullet list.

• The SMS is Circuit Switched (CS).

• All network elements are located in the HPLMN.

• The SMS is charged, or toll free.

• The MNP is active.

• The community charging is active.

• The subscribers account is a preactivated account (life cycle notification).

• There are sufficient funds left on the subscribers account for the SMS
(money available), if charging is applicable.

MSC CCN SDP

1. InitialDPSMS

2. CIR
(First Interrogation (FI))

3. CIA (FI Answer)

4. RequestReportSMS
Event

5. Continue SMS

6. EventReportSMS

7. CIR
(Final Report (FR))

8. CIA (FR Answer)

9. ReleaseSMS

Figure 14 CAPv3 MO SMS Calls

1. An originating SMS is received by the MSC. The MSC analyses the data
and sends an InitialDPSMS request to the serving CCN.

2. CCN interrogates SDP by a CIR. Optionally, an MNP lookup can be

performed here, see Section 3.1 on page 5.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 27

 Traffic Cases

3. SDP verifies the account status, and reserves funds.

4. CCN sends the result by a CIA to CCN. If Community Charging is enabled

it is performed at this stage, see Section 3.2 on page 5.

5. CCN replies to MSC based on the result from SDP.

6. CCN sends an EventReportSMS to MSC, stating that the SMS is allowed

to be delivered.

7. CCN forwards the result to SDP by a CIR from CCN to SDP. SDP charges
the corresponding account.

Note: If end-of-call notification is enabled a notification is sent to the

subscriber, see Section 3.5.1 on page 8.

8. SDP replies with a final report answer by a CIA to CCN including charging
data.

9. CCN sends a confirmation to MSC that the SMS is allowed to be sent.

4.1.8 SMS Charging (ERTC)

This chapter describes the traffic case SMS Charging based on ERTC. For an
overview of the traffic case, see Table 8.

Table 8 Overview of Traffic Case, SMS Charging Based on ERTC

Description Involved Charging CDR Gener Applies To
System Network ation in the
Elements Charging
System
SMS Charging based on ERTC allows the network operator to CCN and SDP. CCN. Originating and
charge for short message transactions in real time without using Terminating
CAMEL or IN. The Charging system will intercept the short message SMS in the
in the MSC. This traffic case, always interact twice with the Charging HPLMN
System. Once to check the account balance, and once at delivery to
the SMS-C to deduct the cost from the account.

The following, see Figure 15, applies for an originating SMS with RTCfA. A
Terminating SMS work in a similar fashion in a Charging System point of view
and is not shown here.

28 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

MSC CCN SDP SMS-C

1
2
3
4
5
6
7
8
9
10
11

Figure 15 Originating SMS Charging, ERTC

1. A subscriber sends an SMS and it is received by an MSC.

2. The MSC sends an SMS indication to CCN to initiate an SMS charging

session.

3. In CCN, the data collected from the MSC is mapped to a first interrogation.

4. The first interrogation is sent to SDP, where the service scenario of the
account is checked and a preliminary charging analysis takes place. SDP
reserves money from the account and sends the result to CCN.

5. CCN replies to the MSC with the result.

6. The MSC delivers the SMS to the SMS-C.

7. The SMS-C confirms the reception of the SMS to the MSC.

8. After successful delivery to SMS-C, the MSC sends a message to CCN, to

charge for the SMS.

9. A final report is sent from CCN to SDP. SDP performs a final charging
of the SMS.

10. SDP reports the total cost of the SMS and sends a final report result to CCN.

11. CCN replies with the result of the charging session to the MSC.

Note: If end-of-call notification is enabled a notification is sent to the

subscriber, see Section 3.5.2 on page 9.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 29

 Traffic Cases

4.1.9 GPRS Charging based on CAMEL Phase 3

This chapter describes the traffic case GPRS Charging Based on CAMEL
Phase 3. For an overview of the traffic case, see Table 9.

Table 9 Overview of Traffic Case, GPRS Charging Based on CAMEL Phase 3

Description Involved Charging CDR Generation Applies To
System Network in the Charging
Elements System
GPRS Charging based on CAMEL phase 3, CCN and SDP. CCN. Originating traffic in
enables charging of packet switched traffic in real the HPLMN and the
time. VPLMN.

4.1.9.1 TDP at PDP Context Establishment Acknowledgement

Figure 16 Illustrates Trigger Detection Point (TDP) at Packet Data Protocol

(PDP) context establishment acknowledgement.

SGSN/
gprsSSF CCN SDP HLR

1
2
3

4
5
6
7
8
9
10
11

12
13
14
15

Figure 16 TDP at PDP Context Establishment Acknowledgement

30 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

1. The subscriber initiates a data transfer. This initiates a PDP context in

the SGSN.

2. An interrogation is made to the HLR.

3. Data is sent from the HLR, containing subscriber information such as

CAMEL Subscription Information (CSI). The call is routed to the gprsSSF.

4. The SGSN triggers CCN to check if the PDP context is allowed to continue.

5. The first interrogation is sent to SDP where the service scenario of the
account is checked and a preliminary charging analysis takes place.

6. SDP reserves money from the account and sends the result to CCN.

7. CCN passes the information on to the SGSN. CCN also tells the SGSN to
set up the session and to supervise it.

8. The SGSN notifies CCN about reached limit.

9. CCN requests SDP to make another reservation from the account with an
intermediate interrogation.

10. SDP rates the event and sends the result to CCN.

11. CCN passes the new limit to the SGSN.

Note: Step 8–11 can be repeated several timed.

12. The SGSN notifies CCN that the user has ended the session.

13. CCN sends a final report to SDP.

14. SDP calculates the total cost of the session and sends a final report result
to CCN.

15. CCN tells the SGSN to disconnect the charging session.

Note: If end-of-call notification is enabled, a notification is sent to the

subscriber, see Section 3.5.1 on page 8.

4.1.10 Service Charging Based on Diameter, Draft-8

This chapter describes the traffic cases Service Charging based on Diameter,
Draft-8. For an overview of the traffic cases, see Table 10.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 31

 Traffic Cases

Table 10 Overview of Traffic Cases, Service Charging based on Diameter, Draft-8.

Description Involved Charging CDR Generation Applies To
System Network in the Charging
Elements System
Service charging using SCAP over Diameter, Draft-8, CCN and SDP SDP Originating sessions.
enables charging of content based services in real time
using either:

• Session based charging with price determined by the

service network.
• Session based charging with price determined by the
Charging System.
• Direct debit of pre-rated events.
• Refund

4.1.10.1 Service Charging, Diameter, Draft-8, Event Based (Direct Debit)

This chapter describes the traffic case Service Charging, Diameter, Draft-8,
Event Based. Figure 17 illustrates Diameter, Draft-8, event-based service
charging (direct debit).

Service
node CCN SDP

1
2

3
4
5
6
7

Figure 17 Service Charging, Diameter, Draft-8, Event based (Direct Debit)

1. The subscriber accesses a charged service.

2. The service application checks the subscriber and connects to CCN.

3. A first interrogation is sent to SDP where the service scenario of the

account is checked and a charging analysis is performed.

4. SDP reserves money and sends the result back to CCN.

32 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

5. CCN immediately sends a final report to SDP.

6. SDP deducts the reserved funds from the account and return a final report
result to CCN.

7. CCN sends back a confirmation to the service application that the direct
debit has been successfully executed.

Note: If end-of-call notification is enabled, a notification is sent to the

subscriber, see Section 3.5.1 on page 8.

4.1.10.2 Service Charging, Diameter, Draft-8, Session Based

This chapter describes the traffic cases Service Charging, Diameter, Draft-8,
Session Based.

Figure 18 illustrates Diameter, Draft-8, session-based service charging.

Service
node CCN/OCC SDP

1
2

3
4
5

6
7
8
9
10
11
12
13

Figure 18 Service Charging, Diameter, Draft-8, Session

1. A subscriber accesses a charged service.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 33

 Traffic Cases

2. The service application checks the subscriber and connects to CCN.

3. CCN interrogates SDP.

4. SDP checks the account status. If necessary, SDP rates and reserves
money. The result is returned.

5. CCN tells the serving network element to continue and monitor the session.

6. The service application notifies CCN that a limit has been reached

7. CCN requests SDP to make another reservation from the account with an
intermediate interrogation.

8. SDP rates the event and sends the result to CCN.

9. CCN passes the new limit to the service application.

Note: Step 6–9 can be repeated a number of times.

10. The service application notifies CCN that the user has ended the session.

11. CCN sends a final report to SDP.

12. SDP calculates the total cost of the session and sends a final report result
back to CCN.

13. CCN tells the service application to disconnect the charging session.

Note: If end-of-call notification is enabled, a notification is sent to the

subscriber, see Section 3.5.1 on page 8.

4.1.11 Service Charging Based on DCCA

This chapter describes the traffic cases Service Charging based on Diameter
Credit Control Application (DCCA). For an overview of the traffic cases, see
Table 11.

34 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

Table 11 Overview of Traffic Cases, Service Charging based on DCCA.

Description Involved Charging CDR Gener Applies
System Network ation in the To
Elements Charging
System
Service charging using SCAPv2 over DCCA enables online credit control CCN or OCC and SDP Origin
of content based services using either: SDP ating
Sessions.
• Immediate Event Charging (IEC). Event charging, without reservation.
• Event Charging with Unit Reservation (ECUR). Session-based event
charging.
• Session Charging with Unit Reservation (SCUR).
Service charging using Gy over DCCA enables online credit control of
content based services using:
Session Charging with Unit Reservation (SCUR).
The charging previous scenarios are available with both of the following
combinations:

• Decentralized unit determination and centralized rating

• Centralized unit determination and centralized rating

4.1.11.1 Service Charging, DCCA Direct Debit

Figure 19 illustrates DCCA direct debit service charging.

Service
node CCN/OCC SDP

1
2

3
4
5

Figure 19 Service Charging, DCCA Direct Debit

1. A subscriber accesses a charged service.

2. The service application checks the subscriber and connects to CCN or

OCC.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 35

 Traffic Cases

3. A first interrogation is sent to SDP where the service scenario of the

account is checked and a charging analysis is performed.

4. SDP deducts funds from the account and return a final report result to
CCN or OCC.

5. CCN or OCC sends back a confirmation to the service application that the
direct debit has been successfully executed.

Note: If end-of-call notification is enabled, a notification is sent to the

subscriber, see Section 3.5.1 on page 8.

4.1.11.2 Service Charging, DCCA Session

Figure 20 illustrates DCCA session service charging.

Service
node CCN/OCC SDP

1
2

3
4
5

6
7
8
9
10
11
12
13

Figure 20 Service Charging, DCCA Session

1. A subscriber accesses a charged service.

2. The service application checks the subscriber and connects to CCN or

OCC.

36 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

3. CCN or OCC interrogates SDP.

4. SDP checks the account status. If necessary, SDP rates and reserves
money. The result is returned.

5. CCN or OCC tells the serving network element to continue and monitor
the session.

6. The service application notifies CCN or OCC that a limit has been reached

7. CCN or OCC requests SDP to make another reservation from the account
with an intermediate interrogation.

8. SDP rates the event and sends the result back to CCN or OCC.

9. CCN or OCC passes the new limit to the service application.

Note: Step 6–9 can be repeated a number of times.

10. The service application notifies CCN or OCC that the user has ended the
session.

11. CCN or OCC sends a final report to SDP.

12. SDP calculates the total cost of the session and sends a final report result
back to CCN or OCC.

13. CCN tells the service application to disconnect the charging session.

Note: If end-of-call notification is enabled, a notification is sent to the

subscriber, see Section 3.5.1 on page 8.

4.1.12 Optimized Signalling for Bonus on Incoming Call (CS1+)

This chapter describes the traffic cases Optimized Signalling for Bonus on
Incoming Call. For an overview of the traffic case, see Table 12.

Table 12 Optimized Signalling for Bonus on Incoming Call CS1+

Description Involved Charging CDR Generation Applies To
System Network in the Charging
Elements System
Optimized Signalling for Bonus on Incoming Calls (BIC) solves a CCN and SDP CCN or MSC/SSF Terminat
specific operators requirement on bonus generated on terminating ing calls
traffic. The purpose of this feature is to reduce the number of in the
interactions between CCN and SDP for terminating calls and HPLMN.
thus reduce the traffic load in these network elements and in the
signalling network.

An example of optimized signalling for bonus on incoming call, is illustrated

in Figure 21.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 37

 Traffic Cases

MSC/VLR GMSC/SSF CCN SDP HLR

1
2
3
4
5
Called party
answers
6
7
Call disconnect

8
9
10
11
12

Figure 21 Optimized Signalling for Bonus on Incoming Call, CS1+

1. A call is initiated to a Charging System subscriber.

2. An interrogation is made to the HLR.

3. Data is sent from the HLR containing information such as TICK. The call
is routed to the SSF.

4. The SSF collects data about the call and triggers CCN.

5. CCN tells the SSF to monitor called party answer.

6. At called party answer, the SSF sends a response to CCN.

7. CCN tells the SSF to monitor called and calling party disconnection.

8. At called or calling party disconnection, the SSF sends an indication to

CCN. CCN calculates the duration of the call.

9. The calling party number belongs to a Public Switched Telephone Network

(PSTN). A first interrogation (without rating) is sent to SDP, that establishes
if Family and Friends (FaF) have to be applied for the call.

10. The result of the first interrogation is sent to CCN.

11. A final report is sent from CCN to SDP. It contains the FaF parameters
received in the first interrogation.

12. SDP rates the total call and adds bonus, based on the call duration, to the
called party account. SDP then returns the result to CCN. Depending on
the configuration a CDR is generated.

38 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

Note: If end-of-call notification is enabled, a notification is sent to the

subscriber, see Section 3.5.1 on page 8.

4.1.13 Roaming Calls Based on CAMEL Phase 1

This chapter describes the traffic case Roaming Calls based on CAMEL Phase
1. For an overview of the traffic case, see Table 13.

Table 13 Overview of Traffic Cases, Roaming Originating Calls based on CAMEL Phase 1
Description Involved Charging CDR Generation Applies To
System Network in the Charging
Elements System
Roaming Calls based on CAMEL Phase 1 enables roaming by CCN and SDP CCN or the SSF in Originating and
routing the speech path from the VPLMN to the HPLMN. This the HPLMN Forwarded
means that all calls are routed through the HPLMN. Calls in the
VPLMN.
Example:
The Charging System subscriber is calling from a VPLMN to a
subscriber in the same PLMN. The speech connection is set up
through the HPLMN. CAMEL features are used to redirect the call
to the HPLMN where the INAP CS1+ based Charging System
service controls and monitors the call.

Figure 22 illustrates a roaming originating call with CAMEL phase 1. A roaming

forwarded call work in a similar fashion in the charging system and is not
shown in detail here.

MSC/SSF SSF CCN

1
2
3
4
5

VPLMN HPLMN
Figure 22 Roaming Originating CAMEL Phase 1

1. The call is initiated from a subscriber roaming in a VPLMN. The Originating

CSI (O-CSI) in the VLR routes the call to the SSF.

2. The SSF triggers and initiates CCN in the HPLMN.

3. CCN checks if all mandatory data is received and stores this data. CCN
tells the SSF to reroute the call to the SSF in the HPLMN.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 39

 Traffic Cases

4. The SSF routes the call to the HPLMN using the SCP-id, in international
format, as called party.

5. The SSF in the HPLMN initiates CCN. Data for the call, stored in step 3,
is retrieved.

Note: From now on the call works the same way as for an Originating
CS1+ call, see Section 4.1.1 on page 13.

4.1.14 Charged Calls Based on CAMEL Phase 2

This chapter describes the traffic case charged calls based on CAMEL Phase
2. For an overview of the traffic case, see Table 14.

Table 14 Overview of Traffic Cases, Roaming Originating Calls based on CAMEL Phase 2
Description Involved Charging CDR Generation Applies To
System Network in the Charging
Elements System
Charging System supports roaming outside the HPLMN with help CCN and SDP CCN in the Originating
of the protocol CAPv2. Extended CAMEL allows CS1+ functions HPLMN and Terminati
in the home network together with CAPv2 functions in the visited ng Calls in the
network. VPLMN and
the HPLMN.
Example:
The Charging System subscriber call from a VPLMN to a
subscriber in the same PLMN. All call handling such as call
monitoring of call duration is performed by the gsmSSF in the
VPLMN.

Figure 23 illustrates a roaming originating call with CAMEL phase 2. A

terminating call work in a similar fashion in a Charging System point of view
and is not shown in detail here.

40 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

MSC/SSF SSF SRF CCN SDP

1
2
3
4
5
6
7
8
9
10

VPLMN HPLMN

Figure 23 Roaming Originating CAMEL Phase 2

1. A call is initiated from a Charging System subscriber roaming in a VPLMN.

The Originating CAMEL Subscription Information (O-CSI) in the VLR routes
the call to the SSF.

2. The SSF in the VPLMN initiates CCN in the HPLMN. CCN processes the
data.

3. The data, received in step 2, is sent to SDP where the service scenario of
the account is checked and a preliminary charging analysis and reservation
of funds are performed.

4. SDP sends the result of the calculated call time together with call data such
as announcements to be played back to CCN.

Note: Step 5–9 are only executed if an announcement is played. Playing

announcements from the HPLMN is optional.

5. CCN tells the SSF in the VPLMN to connect to an assisting SSF in the
HPLMN.

6. A call setup announcement is to be played, so the SSF in the VPLMN

connects to the assisting SSF in the HPLMN. If the connection attempt
to assisting SSF fails, CCN initiates retry attempts to the same or other
defined assisting SSF.

7. The assisting SSF requests instructions from CCN.

8. CCN tells the assisting SSF to play announcements.

9. The assisting SSF tells the SRF to play an announcement.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 41

 Traffic Cases

10. CCN tells the SSF in the VPLMN to set up the call and to supervise it based
on the call time calculated by SDP.

Note: From now on the call is processed in the same way as for an
originated CS1+ call, see Section 4.1.1 on page 13.

4.1.15 Charged Call Based on CAMEL Phase 2, Pre-Call Replenishment

This chapter describes the traffic case charged calls based on CAMEL phase 2
inside HPLMN when the Pre-Call Replenishment (PCR) function is active.

For an overview of the traffic case, see Table 15.

Table 15 Overview of Traffic Cases, Pre-Call Replenishment

Description Involved Charging CDR Gener Applie
System Network ation in the s To
Elements Charging
System
The Charging System subscriber call from HPLMN. The subscriber does SDP and CCN. CCN in the Origin
not have enough money on the account and the PCR function is active. HPLMN ating
The subscriber gets routed to the IVR. Calls
in the
HPLM
N.

Figure 24 illustrates a charged calls based on CAMEL phase 2 inside HPLMN

when the PCR function is active.
MSC/gsmSSF Assisting SSF CCN SDP

1
2
3
4
5
6
7

8
9
10
11
12
13
14

15

16

Figure 24 Pre-Call Replenishment

1. An originating CAPv2 call is initiated from a Charging System subscriber

inside HPLMN.

42 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

2. The SSF collects data about the call and triggers CCN.

3. A first interrogation is sent to SDP where the service scenario of the

account is checked and a charging analysis is performed.

4. SDP sends the result indicating either low balance, insufficient balance,
or account expiry. If low balance, the SDP sends calculated call time.
Announcements could also be sent.

Note: Steps 8-10 are only executed if call setup announcements are to
be played.

5. CCN instructs the MSC/gsmSSF to connect the call to an assisting SSF.

6. MSC/gsmSSF connects to the assisting SSF. If the connection attempt

to assisting SSF fails, CCN initiates retry attempts to the same or other
defined assisting SSF.

7. The assisting SSF requests instructions from CCN.

8. CCN instructs the assisting SSF to play announcements.

9. The assisting SSF instructs the gsmSRF to play announcement.

10. Assisting SSF informs CCN that the announcements are finished.

11. CCN instructs assisting SSF to play menu options to the subscriber to refill
the account or to continue the call.

12. Assisting SSF reports selected menu option to CCN.

13. CCN instructs the assisting SSF to play announcement to indicate that the
call is being transferred to perform replenishment (if refill) or that the call is
being connected (if selected menu option is to continue the call)

14. Assisting SSF informs CCN that announcement is finished. Continue with
step 15 when selected menu option is refill. Otherwise, if selected menu
option is to continue the call continue with step 16.

15. CCN instructs the MSC/gsmSSF to connect to IVR.

Note: From now on the call is processed in the same way as described
in Section 4.3.1.2 on page 59. CCN is not involved in the call any
more. The subscriber has to dial the destination number again
to get connected.

16. CCN instructs the MSC/gsmSSF to set up the call and supervise it based
on the call time calculated by SDP.

Note: From now on the call is processed in the same way as for an
originated CS1+ call, see Section 4.1.1 on page 13.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 43

 Traffic Cases

4.1.16 Charged Call Based on CAMEL Phase 2, Personal Greeting Service

This chapter describes the traffic case charged calls based on CAMEL phase 2
inside and outside HPLMN when the Personal Greeting Service (PGS) function
is active.

For an overview of the traffic case, see Table 16.

Table 16 Overview of Traffic Cases, Personal Greeting Service

Description Involved Charging CDR Generation Applies To
System Network in the Charging
Elements System
The Charging System subscriber call from HPLMN. The PGS CCN CCN in the Terminating
function is active. HPLMN and the calls inside and
SSF in the VPLMN outside HPLMN

Figure 24 illustrates a charged calls based on CAMEL phase 2 inside and

outside HPLMN when the PGS function is active.
MSC/gsmSSF IP Player CCN SDP

1
2
3
4
5
6
7

8
9
10
11
12
13

Figure 25 Personal Greeting Service

1. A terminating CAPv2 call is initiated from a Charging System subscriber

inside or outside HPLMN.

2. The SSF collects data about the call and triggers CCN.

3. A first interrogation is sent to SDP where the service scenario of the

account is checked and a charging analysis is performed.

4. SDP sends the result indicating sufficient balance. The SDP sends
calculated call time.

5. If caller is subscribed to PGS, CCN requests the MSC/gsmSSF to set up

the call and triggers PGS announcement establishment towards assisting
SSF. PCR or call setup announcements, if ordered by SDP, are played
before the PGS announcements

44 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

6. MSC/gsmSSF connects to the IP player. If the connection attempt to IP

fails, CCN initiates retry attempts to the same or other defined IP.

7. The IP player requests instructions from CCN.

8. CCN instructs the IP player to play PGS announcements.

9. Continue operation is sent from CCN to SSF.

10. At called party answer, the SSF sends a response to CCN.

11. CCN informs the MSC/gsmSSF to disconnect the IP player.

12. Disconnects SRF if not already disconnected. This step is optional

depending on MSC vendor type.

13. The call is now connected and CCN supervises the call based on the
call time calculated by SDP. From here, the call continues as a normal
charged call

4.1.17 Charged Call Based on CAMEL Phase 2, Charging of Voice Calls

before B-Answer
This chapter describes the traffic case charged calls based on CAMEL phase 2
inside and outside HPLMN when the charging of voice calls before B-answer
function is active.

For an overview of the traffic case, see Table 17.

Table 17 Overview of Traffic Cases, Charging of Voice Calls Before B-Answer

Description Involved Charging CDR Generation Applies To
System Network in the Charging
Elements System
The Charging System subscriber call from HPLMN. The CCN, SDP CCN in the Originating
charging of voice calls before B-answer function is active. HPLMN and the calls inside and
SSF in the VPLMN outside HPLMN

The call flow for charging of voice calls before B-answer is the same as for a
charged call based on CAPv2, see Section 4.1.14 on page 40, except that
charging of the call starts at reception of First Interrogation Result (FIR) from
SDP instead of when the call is answered.

The function is only applicable for MO CAPV2 calls when CIP/IP is used and
the following conditions are met:

• Subscribers service class is a service class with charging of voice calls

before B-answer functionality active.

• The subscriber makes an originating call.

• The originating call is allowed, that is, the subscriber has enough money on
the account, and the call is to be charged.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 45

 Traffic Cases

The subscriber is charged if the call duration before answer is longer than or
equal to the configuration for free of charge period for unsuccessful call set up
in the following cases:

• The call is not answered before the granted time expiry.

• The call is not successfully connected.

If the subscriber has low balance and the PCR function is active, no charging is
made for the time prior and during the PCR.

4.1.18 Forwarded CAMEL Phase 2

This chapter describes the traffic case Forwarded Calls based on CAMEL
Phase 2.

For this traffic case there are two possible scenarios:

• Call forwarding in GMSC (early call forwarding).

• Call forwarding in MSC/VLR (late call forwarding).

4.1.18.1 Early Call Forwarding

The first possible scenario for forwarded CAMEL Phase 2, call forwarding in
GMSC (early call forwarding), is shown in Figure 26.

An overview of the traffic case is shown in Table 18.

Table 18 Overview of Traffic Cases, Early Call Forwarding

Description Involved Charging CDR Generation Applies To
System Network in the Charging
Elements System
If the subscriber has call forwarding, there is a parameter CCN and SDP CCN Works in a
available to decide how the charging is performed for early similar way both
call forwarding. The parameter decides if both the roaming ine HPLMN and
terminating leg and the roaming forwarded leg is to be charged the VPLMN.
or only the roaming forwarded leg.

46 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

MSC/VLR GMSC/SSF CCN HLR

1
2
3
4
5
6
7
8
9

VPLMN HPLMN
Figure 26 Early Call Forwarding

1. A call is initiated to a subscriber roaming in a VPLMN.

2. An interrogation is made to the HLR.

3. The HLR fetches current subscriber location data from the VLR in the
VPLMN.

4. The VLR sends subscriber location data to the HLR.

5. Data is sent from the HLR, containing information like Call Forwarding
Unconditional (CFU) and T-CSI indication, and the call is routed to the SSF.

6. The SSF in the HPLMN triggers CCN where data about the call is collected.

7. CCN tells the SSF in the HPLMN to set up the call.

8. The HLR is again interrogated, now with Terminating CAMEL Subscription

Information (T-CSI) suppression and the call forwarding setting and O-CSI
is found.

9. The HLR returns call forwarding settings and O-CSI to GMSC.

Note: From now on the call is processed as an originating call, see

Section 4.1.1 on page 13.

4.1.18.2 Late Call Forwarding

The second possible scenario for roaming forwarded CAMEL phase 2, call
forwarding in MSC/VLR (late call forwarding), is shown in Figure 27.

An overview of the traffic case is shown in Table 19.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 47

 Traffic Cases

Table 19 Overview of Traffic Cases, Late Call Forwarding

Description Involved Charging CDR Generation Applies
System Network in the Charging To
Elements System
At Late Call Forwarding, the service manages the calls in a similar CCN and SDP CCN -
fashion as for forwarded calls in the HPLMN. Both originating and
terminating leg is charged unless Optimal Routing at Late Call
Forwarding is used. For more information about Optimal Routing at
Late Call Forwarding, see Section 4.1.18.3 on page 49.

MSC/VLR GMSC/SSF CCN SDP HLR

1
2
3
4
5
6
7
8
9
10
11
12
13
14

VPLMN HPLMN

Figure 27 Late Call Forwarding

1. A call is initiated to a subscriber roaming in a VPLMN.

2. An interrogation is made to the HLR.

3. The HLR fetches current subscriber location data from the VLR in the
VPLMN.

4. The VLR sends subscriber location data to the HLR.

5. Data is sent from the HLR containing such information as T-CSI and the
call is routed to the SSF.

6. The SSF in the HPLMN triggers CCN where data about the call is collected.

7. The data, collected in step 6, is sent to SDP where the service scenario of
the account is checked and a preliminary charging analysis and reservation
of funds are performed.

48 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

8. SDP sends the result of the calculated call time as well as call data to CCN.

9. CCN tells the SSF in the HPLMN to set up the call.

10. The HLR is interrogated again, now with T-CSI suppression.

11. The HLR fetches the roaming number from the VLR.

12. The VLR returns the roaming number to the HLR.

13. Data is sent back to the GMSC in the HPLMN.

14. The call is routed to the MSC/VLR in the VPLMN and if the subscriber is
not reachable or does not answer the SSF initiates an originating session
from the VPLMN.

Note: From now on the call created is an originating call, see Section
4.1.1 on page 13.

4.1.18.3 Optimal Routing at Late Call Forwarding

A traffic case for optimal routing at late call forwarding is shown in Figure 28.
For an overview of the traffic case, see Table 20.

Table 20 Overview of Traffic Cases, Optimal Routing at Late Call Forwarding

Description Involved Charging CDR Generation Applies
System Network in the Charging To
Elements System
Suppression of terminating charging at late call forwarding is only CCN and SDP CCN -
possible when Optimal Routing at Late Call Forwarding (ORLCF)
is available. With ORLCF, the Charging System handles late call
forwarding the same way as early call forwarding.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 49

 Traffic Cases

MSC/VLR GMSC/SSF CCN SDP HLR

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

VPLMN HPLMN

Figure 28 Optimal Routing at Late Call Forwarding

1. A call is initiated to a subscriber roaming in a VPLMN.

2. An interrogation is made to the HLR.

3. The HLR fetches current subscriber location data from the VLR in the
VPLMN.

4. The VLR sends subscriber location data to the HLR.

5. Data is sent from the HLR, containing such information as T-CSI, and the
call is routed to the SSF.

6. The SSF in the HPLMN triggers CCN, where data about the call is collected.

7. The data, collected in step 6, is sent to SDP where the service scenario of
the account is checked and a preliminary charging analysis and reservation
of funds are performed.

8. SDP sends the result of the calculated call time as well as call data to CCN.

9. CCN tells the SSF in the HPLMN to set up the call.

10. The HLR is interrogated again, now with T-CSI suppression.

11. The HLR fetches the roaming number from the VLR.

50 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

12. The VLR returns the roaming number to the HLR.

13. Data is sent back to the GMSC in the HPLMN.

14. The call is routed to the MSC/VLR in the VPLMN.

15. The MSC/VLR returns MAP_RESUME_CALL_HANDLING and initiates the

optimal routing at late call forwarding.

Note: From now on the call is processed in the same way as an early call
forwarded call, see Section 4.1.18.1 on page 46.

4.1.19 Roaming, USSD Callback

This section describes the traffic case Roaming, USSD Callback. For an
overview of the traffic case, see Table 21.

Table 21 Overview of Traffic Cases, Roaming, USSD Callback CS1+

Description Involved Charging CDR Generation Applies
System Network in the Charging To
Elements System
Roaming USSD callback calls are calls initiated in a VPLMN by using CCN, AF, and SDP CCN or -
a USSD service code together with the number to be called. The MSC/SSF
service manages the calls by first connecting the calling subscriber
and later the called subscriber, using the number plan of the home
network.

Figure 29 illustrates roaming USSD callback with CS1+.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 51

 Traffic Cases

MSC/VLR GMSC/SSF CCN AF SDP HLR

gsmSSF
1
2

3
4
5
6
7

8
9
10

11
12
13
14
15
16
17
18

19
20
21
22
23
24
25
26
27
28
29
30

VPLMN HPLMN
Figure 29 Roaming USSD Callback, CS1+

1. A USSD request is sent from a charging system subscriber roaming in a

VPLMN.

2. Based on the service code, the MSC in the VPLMN routes the USSD
message to the HLR in the HPLMN through the GMSC in the HPLMN.

3. The HLR performs an analysis of the USSD service code and as a result
transfers it to SDP.

4. SDP checks if the USSD originates from an allowed roaming area.

52 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

Note: When ETSI MAP is used, the roaming area check is not possible,
as location information is not received.

SDP can, based on the configuration, perform an optional AF lookup for

retrieval of correct SDP ID. The AF lookup is only done if the indicated
subscriber is not located under the current SDP.

5. AF returns the subscribers SDP ID.

6. SDP sends an order to the SCF to set up the call.

7. The SCF sends available information to the correct SDP where the service
scenario of the account is checked and a preliminary charging analysis
takes place.

8. SDP sends the result of the calculated call time together with call data
back to SCF. No reservation is made.

9. The SCF tells the SSF in the HPLMN to connect the Charging System
subscriber.

10. A roaming interrogation is made to the HLR to retrieve the roaming number.

11. HLR fetches the roaming number from the VLR.

12. The VLR returns the roaming number to the HLR.

13. The roaming number is sent back from the HLR to the GMSC.

14. The speech connection, between the calling Charging System subscriber
and the SSF in the HPLMN, is established.

15. The SSF signals to the SCF when the Charging System subscriber
answers.

16. The SCF order a reconnection-loop through the SSF.

17. The SSF simulates a normal call from the calling subscriber. This is needed
to allow call supervision and charging. This work around is because of
charging limitations in the SSF.

18. The SCF performs a new Interrogation to SDP. Optionally, an MNP lookup
can be performed here, see Section 3.1 on page 5.

19. SDP rates and sends the result to the SCF and reserves money. If
Community Charging is enabled it is performed at this stage, see Section
3.2 on page 5.

20. The SCF tells the SSF to establish a connection to the called subscriber.

21. The call lasts longer than the call time sent to the SSF, so the SSF notifies
the SCF.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 53

 Traffic Cases

22. The SCF requests SDP to make another reservation from the account
with an intermediate interrogation.

23. SDP makes a new charging analysis and deducts the amount previously
reserved from the account. There is still money left on the subscribers
account, so SDP sends a new call time to the SCF.

24. The SCF sends the new allowed call time to the SSF.

Note: Step 21–24 can be repeated.

25. The calling subscriber releases the call.

26. The SSF in the VPLMN notifies the SSF in the HPLMN of the call
disconnection.

27. The SSF notifies the SCF of the call disconnection.

28. A final report is sent from the SCF to SDP.

29. SDP rates the total call and sends a final report result back to the SCF.

30. The SCF sends a call release to the SSF.

Note: If end-of-call notification is enabled a notification in sent to the

subscriber, see Section 3.5.1 on page 8.

4.2 Offline Charging Services

If an event for some reason cannot be charged using online charging, the
Charging System has the possibility to charge the subscribers accounts offline
by collecting and post processing CDRs.

4.2.1 Offline Cost and Credit Control

This section describes the traffic case Offline Cost and Credit Control. An
overview of the traffic case is shown in Table 22.

Note: This traffic case is not possible without the Multi Mediation Solution.
Multi Mediation is used to store, reformat, and make CDRs available
for post-processing by SDP. If the system is configured to manage
without Multi Mediation, this functionality is not replaced by another
network element.

54 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

Table 22 Overview of Traffic Cases, Offline Cost and Credit Control

Description Involved Charging CDR Gener Applie
System Network ation in the s To
Elements Charging
System
Charging Data Record (CDR) processing provides the possibility to adjust SDP and AF SDP -
the Charging System subscribers account by collecting and post-processing
CDRs. The Multi Mediation Solution receives the original CDRs from the
charging-, core-, and service network and reformats them to an SDP-specific
format.
In a smaller Charging System, it is possible to have a solution without Multi
Mediation. For more information, see the Network Impact Report, Reference
[3].

A traffic case, showing the Offline Cost and Credit Control, can be seen in
Figure 30.

Network SDP HLR EMM AF

1
2
3
4

5
6
7
8

Figure 30 Offline Cost and Credit Control

1. The Multi Mediation Solution receives CDRs from the network.

Note: The Multi Mediation Solution module used in this traffic case is the
File and Event mediation module.

2. The Multi Mediation Solution filters and reformats the CDRs and
interrogates AF to get the SDP IP address.

3. AF translates MSISDN into SDP IP address and returns it to the Multi

Mediation Solution.

4. The Multi Mediation Solution sends the CDR to SDP, which performs a
check of account status, rates the CDR and updates the account.

5. The subscriber is barred in the HLR for the offline service if the account
status indicates no money or no services. See Community Charging,
Section 3.2 on page 5.

6. USSD notification is enabled, so SDP sends the USSD information to the

HLR, for delivery to the subscriber.

7. For further delivery, the HLR passes the USSD information to the MSC/VLR.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 55

 Traffic Cases

8. SDP notifies the Multi Mediation Solution that the CDR has been processed.
The notification with the result from the rating is sent in a CDR.

4.2.2 Offline Cost and Credit Control through Input Offline Record
This section describes a traffic case for offline cost and credit control using
the SDP File Interface for Offline Rating function. An overview of the traffic
case is shown in Offline Cost and Credit Control Using the SDP File Interface
for Offline Rating Function.

Note: This traffic case is not possible without a mediation device. The
mediation device is used to consolidate and reformat input data, and
to route it to the correct SDP. If the system is configured to manage
without a mediation device, this functionality is not replaced by another
network element.

Table 23 Offline Cost and Credit Control using the SDP File Interface for Offline Rating
Function
Description Involved Charging CDR Gener Applie
System Network ation in the s To
Elements Charging
System
SDP File Interface for Offline Rating function can be used for offline rating. If Multi Mediation, AF, SDP -
so, it replaces the functionality included in the CDR Processing function. SDP, and CRS
In a smaller Charging System, it is possible to have a solution without Multi
Mediation. For more information, see the Network Impact Report, Reference
[3].

A traffic case for Offline Cost and Credit Control through the Input Offline Record
Interface is shown in Offline Rating through the Input Offline Record Interface.

Figure 31 Offline Rating through the Input Offline Record Interface

56 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

1 Input data on an offline event is sent to the mediation device, for example,
MSC voice MO CDRs.

2 The mediation device consolidates and reformats the data to the Detail
Record Parameter List Input Offline Record, Reference [2] .

3 The mediation device performs a lookup towards AF to fetch information

on which SDP the subscriber information is on.

4 The mediation device receives the SDP address for the subscriber from AF.

5 The mediation device routes the record to the identified SDP.

6 SDP executes rating of the offline event and generates an Offline Credit
Control Record (OCCR) CDR.

7 SDP sends a CDR to CRS.

8 The CDR is stored in CRS.

4.3 Voucher Refill and Enquiry

A voucher is considered as cash and the value lies with the hidden information.
A refill does not only add money to the account, but can also adjust the account
expiry dates. This can be done in a number of different ways.

It is possible for a subscriber to get account information presented on the mobile

phone. Whit the use of different service codes it is possible to request account
information and get it presented either through a text or voice announcement.

This section describes the two different kinds of voucher refill and enquiry.

4.3.1 IVR Voucher Refill and Enquiry

This section describes Voucher Refill and Enquiry using voice notifications.

4.3.1.1 Voucher Refill Through IVR

This chapter describes the traffic case Voucher Refill through the Interactive
Voice Response (IVR). For an overview of the traffic case, see Table 24. In
Figure 32 the traffic case of voucher refill through IVR is illustrated.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 57

 Traffic Cases

Table 24 Overview of Traffic Cases, Voucher Refill through IVR

Description Involved Charging CDR Generation Applies To
System Network in the Charging
Elements System
The subscriber calls a service number and gets routed to the IVR. SDP, the VS, AIR, and AIR -
Through announcements, and voice prompts the IVR helps the caller AF.
to interact with the Charging System for refill procedures.

MSC/VLR SDP EMM VS AIR IVR HLR AF

1
2
3
4
5

6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

Figure 32 Refill Through IVR

1. A refill call is initiated by the Charging System subscriber.

2. The call is routed to the IVR. The IVR checks if the calling party number
is complete.

3. The IVR requests account information from AIR.

4. AIR interrogates AF to get the SDP IP address.

5. AF returns the SDP IP address.

6. AIR uses the returned SDP IP address to request account and subscriber
data information from SDP.

58 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

7. SDP checks if any account updates are necessary and sends the result
of the account information requests back to AIR.

8. AIR sends the requested information to the IVR, for example preferred
language. The IVR plays a standard welcome announcement and a menu
announcement. The subscriber selects the menu option Voucher Refill and
enters the voucher activation number.

9. The entered activation code and the mobile number of the subscriber is
sent to AIR for verification.

10. AIR requests account information from SDP.

11. SDP sends the result of the account information request back to AIR. AIR
verifies that the subscriber exists and is not barred from refill.

12. AIR sends the entered voucher activation code to the Voucher Server (VS)
for verification.

13. When the VS has verified the voucher activation code and reserved the
voucher, it returns a response to AIR.

14. AIR receives a response from the VS indicating if the verification was
successful or not. It was successful, so AIR sends a refill request to SDP.

15. The account balance is increased in SDP database for the account.

Offline Cost and Credit Control is used and has caused an SMS/GPRS
barring. Unbarring of SMS and GPRS in the HLR is supported when a
certain account threshold has been reached. In this case through a refill.

16. SDP sends the result of the refill back to AIR.

17. The refill was successful, so AIR requests the VS to set the voucher in
used state.

18. The VS responds with the result back to AIR.

19. AIR sends a response to the IVR including the account balance and an
indication if the refill was successful or not. A CDR including the refill data
is generated.

20. The IVR uses the voice prompt to notify the subscriber of the result.

21. The subscriber releases the call.

22. A CDR is sent to the Multi Mediation Solution as a receipt (optional). In a

system without Multi Mediation, CDRs are sent directly to CRS.

Note: The Multi Mediation Solution module used in this traffic case is the
File and Event mediation module.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 59

 Traffic Cases

4.3.1.2 Enquiry Through IVR

The traffic case of enquiry through IVR is illustrated in Figure 33. For an
overview of the traffic case, see Table 25.

Table 25 Overview of Traffic Cases, Enquiry through IVR

Description Involved Charging CDR Gener Applie
System Network ation in the s To
Elements Charging
System
The subscriber calls a service number and gets routed to the IVR. Through SDP, AIR, the IVR, - -
announcements, and voice prompts the IVR helps the caller to interact with and AF.
the Charging System for account balance enquiries, accumulator enquiries,
and expiry date enquiries.

MSC/VLR SDP AIR IVR AF

1
2
3

5
6
7
8

9
10
11
12
13
14
15

Figure 33 Enquiry through IVR

1. An enquiry call is initiated by the Charging System subscriber.

2. The call is routed to the IVR. The IVR checks if the calling party number
is complete.

3. The IVR requests account information from AIR.

4. AIR interrogates AF to get the SDP IP address.

5. AF returns the SDP IP address.

6. AIR uses the returned SDP IP address to requests account and subscriber
data information from SDP.

60 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

7. SDP checks if any account updates are necessary and sends the result
of the account information requests back to AIR.

8. AIR sends the requested information to the IVR, for example preferred
language. The IVR plays a standard welcome announcement and a menu
announcement. The subscriber selects the menu option Balance Enquiry.

9. A balance enquiry request with the mobile number of the subscriber is

sent to AIR.

10. AIR enquires SDP for account information.

11. SDP sends the requested account information to AIR.

12. AIR forwards the account information to the IVR.

13. The IVR plays a response message.

14. The subscriber releases the call.

15. The MSC informs the IVR about the completion of the call.

4.3.2 USSD Voucher Refill and Enquiry

This section describes Voucher Refill and Enquiry using notifications through
the mobile handset.

4.3.2.1 USSD Voucher Refill

This section describes the traffic case of USSD Voucher Refill. The traffic case
is illustrated in Figure 34. For an overview if the traffic case, see Table 26.

Table 26 Overview of Traffic Cases, USSD Voucher Refill

Description Involved Charging CDR Generation Appli
System Network in the Charging es To
Elements System
The subscriber enters a USSD service code and a voucher activation SDP, the VS, AIR, and AIR -
code using the mobile handset. AIR interacts with SDP for refill of the AF.
subscribers account. The subscriber receives a USSD text message
with a notification if the voucher refill was successful or not.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 61

 Traffic Cases

MSC/VLR SDP EMM VS AIR HLR AF

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

17

Figure 34 USSD Voucher Refill

1. A Charging System subscriber originates a USSD message with the USSD

service code corresponding to voucher refill and the voucher activation
code.

2. The MSC forwards the message to the HLR.

3. The HLR analyses the USSD service code and forwards the message
to AIR.

4. AIR interrogates AF to get the SDP IP address.

5. AF returns the SDP IP address.

6. AIR uses the returned SDP IP address to requests account and subscriber
data information from SDP.

7. SDP checks if any account updates are necessary and sends the result
of the account information request back to AIR. AIR verifies that the
subscriber exists and is not barred from refill.

8. AIR sends the activation code to the VS for verification.

9. When the VS has verified the activation code and reserved the voucher, it
returns a response to AIR.

10. AIR receives a response from the VS indicating if the verification was
successful or not. It was successful, so AIR sends a refill request to SDP.

11. The account balance is increased in the SDP database.

62 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

Offline Cost and Credit Control is used and has caused an SMS/GPRS
barring. Unbarring of SMS and GPRS in the HLR is supported when a
certain account threshold has been reached. In this case through a refill.

12. SDP sends the result of the refill back to AIR.

13. The refill was successful, so AIR requests the VS to set the voucher in
used state.

14. The VS responds with the result back to AIR.

15. AIR reformats the response into a USSD text string and sends it to the
HLR. The response is successful, so the appropriate successful message
is sent, otherwise a failure response with the reason for failure would have
been sent. A CDR including the refill data is generated.

16. The HLR forwards the response to the MSC and the response is displayed
on the subscribers handset.

17. A CDR is sent to the Multi Mediation Solution as a receipt (optional). In a

system without Multi Mediation, CDRs are sent directly to CRS.

Note: The Multi Mediation Solution module used in this traffic case is the
File and Event mediation module.

4.3.2.2 USSD Balance Enquiry

This section describes the traffic case of USSD Balance Enquiry. The traffic
case is illustrated in Figure 34. For an overview of the traffic case, see Table 27.

Table 27 Overview of Traffic Cases, USSD Balance Enquiry

Description Involved Charging CDR Generation Applies
System Network in the Charging To
Elements System
The subscriber enters a USSD service code using the mobile SDP, AIR, and AF. - -
handset. AIR interacts with SDP for balance enquiries, accumulator
enquiries, and expiration date enquiries. The subscriber then
receives a USSD text message with the account information.

MSC/VLR SDP AIR HLR AF

1
2

3
4
5
6
7
8
9

Figure 35 USSD Balance Enquiry

2/1551-FAV 101 72/4 Uen L | 2016-11-30 63

 Traffic Cases

1. A Charging System subscriber originates a USSD message with the USSD

service code corresponding to enquiry.

2. The MSC forwards the message to the HLR.

3. The HLR analyses the USSD service code and forwards the message
to AIR.

4. AIR interrogates AF to get the SDP IP address.

5. AF returns the SDP IP address.

6. AIR uses the returned SDP IP address to request account and subscriber
data information from SDP.

7. SDP sends the requested account information to AIR.

8. AIR reformats the response into a USSD text string and send to the HLR.
The response is successful, so the appropriate successful message is
sent, otherwise a failure response with the reason for failure would have
been sent.

9. The HLR forwards the response to the MSC and the response is displayed
on the subscribers handset.

4.4 B-number Modification

With the B-number Modification function, it is possible to change the original
B-number and to reroute calls based on subscription data. This is applicable for
both voice and SMS.

Rerouting information is sent to MSC via CCN. In CCN a CDR is generated

including reroute address information.

It is possible to either change the B-number fully, or to add a prefix before the
dialed B-number to switch specific traffic based on the modified B-number.
Either change is made in SDP.

The Pre-analysis structure in SDP is used to modify the B-number data, type,
and nature of address, and to add prefix.

The original B-number is available for functions like Family and Friends
(FaF), Community Charging, and so on. A prefix used with the
Other-Party-ID-Prefix parameter is used for rating.

The parameters introduced with this function are propagated by CRS on

UAH-API, for ECMS to display the value in the GUIs.

4.4.1 Rerouting Address

The operator wants to have the possibility to reroute a call to a B-number only
in a CIR First Interrogation, or at Direct Debit rating. A possible reroute is

64 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

based on subscriber data conditions. This way, the call can be rerouted in a
CONNECT operation towards MSC.

The number sent in the CDR is the original B-number, sent from CCN to
SDP. The reroute address, and Other-Party-ID-Prefix if used, are also
included in the CDR.

This use case applies to Voice services using CS1+ or CAPv2, and SMS
services using CAPv3.

Figure 36 shows the traffic flow for reroute of a dialed B-number.

Figure 36 Reroute of Dialed B-number

1 A subscriber starts a call to an original B-number. The call is received by

MSC and forwarded to CCN.

2 MSC checks the B-number and detects that this call is to be rerouted. MSC
adds a prefix, for example *121*. The B-number and the prefix are sent to
CCN in an InitialDP.

3 CCN detects that a prefix exists and sends the original B-number together
with the additional prefix, separated from the B-number, to SDP in a
CIR-FI. The prefix is sent in the Other-Party-ID-Prefix parameter.
An evaluation of the Pre-analysis structure in SDP is made to decide if the
call is to be rerouted or not.

In SDP, both the original B-number and the prefix can be used for rating
decisions.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 65

 Traffic Cases

4 If the call is allowed and rerouted, the reroute address is sent back to
CCN in a CIR-FIA over CIP/IP.

5 The reroute address is forwarded to from CCN to MSC.

6 If a reroute of the call is performed, CCN sends a CONNECT response to

MSC. If the call is not rerouted, CCN sends a CONTINUE response.

7 If using SMS services over CS1+, CCN also sends a RELEASE CALL
response to MSC.

8 A CDR is generated in CCN, including both the original B-number

and the reroute address. In SDP, a Credit Control CDR is generated
including the same data is in the CCN CDR, but also includes the
Other-Party-ID-Prefix parameter.

9 CDRs are sent from CCN to CRS.

10 CDRs are sent from SDP to CRS.

11 The parameter values to be displayed in the ECMS GUIs are sent from
CRS to ECMS.

For more information, see the SDP Use Cases, Reference [4].

4.4.2 Short Number Dialing

A subscriber is using a short number *11*123 when calling. The short number
is mapped to number lists in MSC, and a match is found. MSC adds a prefix
before the B-number which is forwarded to CCN, see Section 4.4.2 on page 66.
The step numbers in the figure corresponds to the steps in the flow in Figure 37.

This use case applies to Voice services using CS1+ or CAPv2, and SMS
services using CAPv3.

Figure 37 shows the traffic flow for reroute of dialed B-number when using
short number.

66 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

Figure 37 Reroute of Dialed B-number, Short Number Dialing

1 A subscriber is using a short number *11*123 when calling.

2 The short number is mapped to number lists in MSC, and detects that the
short number maps to a B-number.

3 MSC adds the prefix *999*, known by configuration, before the B-number.
They are forwarded as one number to CCN in an Initial DP.

4 CCN detects the prefix and checks it against the 'Known prefix' list. If the
prefix is identified, the prefix is separated from the B-number and added to
the AVP parameter Other-Party-Id-Prefix.

5 The B-number and the AVP parameter Other-Party-Id-Prefix

including the prefix are sent to SDP in a CIR-FI.

6 The Pre-analysis structure is evaluated in SDP to see if the call is allowed

or not, and if it is to be rerouted. Rating decisions are taken, and the prefix
can also be used for rating.

7 A CIR-FIA response is sent back from SDP to CCN including the rerouting
address.

8 CCN sends a CONNECT response to MSC together with the reroute address.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 67

 Traffic Cases

9 CDRs are generated in CCN and SDP. The CCN CDR contains the
reroute address and the Credit Control CDR in SDP contains the
Other-Party-Id-Prefix parameter including the prefix.

10 CDRs are sent from CCN to CRS.

11 CDRs are sent from SDP to CRS.

12 The parameter values to be displayed in the ECMS GUIs are sent from
CRS to ECMS.

For more information, see the SDP Use Cases, Reference [4].

4.4.3 Reduced FNR Accesses

By using the B-number Modification function, the Flexible Number Register

(FNR) lookups are reduced. In SDP, the reroute address can be set to indicate
a ported number.

Figure 38 Reduced FNR Accesses

1 A subscriber calls a number that is ported.

2 MSC sends an InitialDP to CCN, including the B-number. If a prefix is

used that is also included.

3 CCN performs an FNR lookup.

68 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Traffic Cases

4 A Routing Number is sent from CCN to SDP in a CIR-FI.

5 SDP detects that the number is ported.

6 A reroute address, for example based on the Routing Number, is sent back
to CCN in a CIR-FIA over CIP/IP.

7 CCN forwards the information to MSC in a CONNECT response.

MSC recognizes the reroute data as ported number and uses the
information as it is. No additional access to FNR is required.

8 A CDR is generated in CCN, including both the original B-number sent to

SDP and the reroute address. In SDP, a Credit Control CDR is generated
including the same data is in the CCN CDR, but also includes the
Other-Party-ID-Prefix parameter if prefix is used.

9 CDRs are sent from CCN to CRS.

10 CDRs are sent from SDP to CRS.

11 The parameter values to be displayed in the ECMS GUIs are sent from
CRS to ECMS.

2/1551-FAV 101 72/4 Uen L | 2016-11-30 69

 Traffic Cases

70 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Glossary

Glossary

Active Service CS1+

Service scenario of a Charging System Ericsson’s IN protocol supporting all
account capabilities of Ericsson INAP 2.1 and ETSI
Core INAP CS1.
AF
Account Finder CSI
CAMEL Subscription Information
AIR
Account Information and Refill DCCA
Diameter Credit Control Application
A-Number
The calling party DNS
Domain Name Service
ATI
Any Time Interrogation ECUR
Event Charging with Unit Reservation
B-Number
The called party Ericsson MM
Ericsson Multi Mediation
CAMEL
Customized Application for Mobile Enhanced ERTC
Logic Ericsson Real Time Charging
CAP FaF
CAMEL Application Part Family and Friends
CCA FNR
Credit Control Answer Flexible Numbering Register
CCN Full Service
Charging Control Node Service scenario of a Charging System
account
CDR
Charging Data Record GMSC
Gateway MSC
CFU
Call Forwarding Unconditional GPRS
General Packet Radio Service
Charging System Subscriber
Either a master- or an associated- subscriber GSM
to a Charging System account. Global System for Mobile Communication
CIA gsmSCF
Charging Interrogation Answer Executes the IN service in case of service
execution initiated by the gsmSSF through
C-Number CAMEL
Forwarded to number

2/1551-FAV 101 72/4 Uen L | 2016-11-30 71

 Traffic Cases

gsmSRF MSISDN
Service Resource Function Mobile Station ISDN number

gsmSSF MTAS
Functional entity that interfaces the GMSC to Multimedia Telephony Application Server
the gsmSCF
No Service
HLR Service scenario of a Charging System
Home Location Register account

HPLMN non-served subscriber

Home Public Land Mobile Network Subscriber other than the served subscriber

ID OCCR
Identity Offline Credit Control Record

IDD O-CSI
International Direct Dialing Originating CAMEL Subscription Information

IDP OICK
Initial Detection Point Originating IN Category Key
IEC Passive Service
Immediate Event Charging Service scenario of a Charging System
account.
INAP
Intelligent Network Application Protocol PCR
Pre-Call Replenishment
In-call Announcements
Warning announcement that the money on PDP
the Charging System account is running out Packet Data Protocol
ISDN PS
Integrated Services Digital Network Packet Switched
IVR PSTN
Interactive Voice Response Public Switched Telephone Network
LNP QoS
Local Number Portability Quality of Service
M2M RAR
Mobile to Mobile Re-Authorization Request
MMTel Refill
MultiMedia Telephony Procedure for adding value to a Charging
System account.
MNP
Mobile Number Portability RTCfA
Real Time Charging for All
MO
Managed Object

72 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Glossary

SCAP USSD
Service Charging Application Protocol Unstructured Supplementary Service Data

SCF VLR
Service Control Function Visiting Location Register

SCP Voucher
Service Control Point Used to refill a Charging System account

SCUR VPLMN
Session Charging with Unit Reservation Visited Public Land Mobile Network

SDP VS
Service Data Point Voucher Server

served subscriber YO
The subscriber to whom the charging service Yield Optimization
is provided

Service Class
Pre-customized Charging System services
used to differentiate Charging System.

Service Scenario
Defines the state of a Charging System
account.

SM
Short Message

SMS
Short Message Service

SMS-C
SMS Center

SRF
Service Resource Function

SSF
Service Switching Function

T-CSI
Terminating CAMEL Subscription Information

TDP
Trigger Detection Point

TICK
Terminating IN Category Key

2/1551-FAV 101 72/4 Uen L | 2016-11-30 73

 Traffic Cases

74 2/1551-FAV 101 72/4 Uen L | 2016-11-30

 Reference List

Reference List

Ericsson Documents

[1] Customer Product Information Overview, 1551-FAV 101 72/4

[2] Detail Record Parameter List Input Offline Record, 1/190 59-FAY 302
114/1

[3] Network Impact Report, 1/109 48-FAV 101 72/4

[4] SDP Use Cases, 1/155 56-FAM 901 107/5

[5] System Description, 1/1551-FAV 101 72/4

[6] User Guide Yield Optimization, 12/1553-FAV 101 72/4

2/1551-FAV 101 72/4 Uen L | 2016-11-30 75