Comverse Real-Time Billing Solutions

Payment Server Interface

Proprietary and Confidential

 Notice
This document contains proprietary and confidential material of Comverse. Any unauthorized
reproduction, use, or disclosure of this material, or any part thereof, is strictly prohibited. This
document is solely for the use of Comverse employees and authorized Comverse customers.
The material furnished in this document is believed to be accurate and reliable. However, no
responsibility is assumed by Comverse, Inc. for the use of this material. Comverse, Inc.
reserves the right to make changes to the material at any time and without notice.
Copyright © 2007 Comverse, Inc. All rights reserved.
Several products and company names mentioned herein may be trademarks and/or registered
trademarks of their respective companies.
Comverse
Corporate Headquarters
100 Quannapowitt Parkway
Wakefield, MA 01880 USA
Tel: (781) 246-9000
Fax: (781) 224-8143
www.comverse.com

Revision History
Version Date Author Description

Page 2 of 62 Proprietary and Confidential ,

 Table of Contents
1. RTB Payment Server Interface Overview ................................................................... 6

2. RTB Payment Server Interface Specifications ........................................................... 6

2.1. Overview..............................................................................................................................................................6
2.1.1. Service Logic Unit Redundancy................................................................................................ 7
2.1.2. Load Sharing............................................................................................................................ 7
2.2. Heartbeats ...........................................................................................................................................................7
2.2.1. Heartbeat Request ................................................................................................................... 8
2.2.2. Heartbeat Response ................................................................................................................ 8
2.3. Validate Subscriber..............................................................................................................................................9
2.3.1. Validate Subscriber Request .................................................................................................... 9
2.3.2. Validate Subscriber Response ............................................................................................... 10
2.3.3. Validate Subscriber Response ............................................................................................... 11
2.4. Apply Charge.....................................................................................................................................................11
2.4.1. Apply Charge Request ........................................................................................................... 11
2.4.2. Apply Charge Response......................................................................................................... 12
2.4.3. Transaction ID Acknowledgement .......................................................................................... 13
2.4.4. Limitations ............................................................................................................................. 14
2.5. Apply Currency Charge .....................................................................................................................................15
2.5.1. Apply Currency Charge Request ............................................................................................ 15
2.5.2. Apply Currency Charge Response ......................................................................................... 16
2.5.3. Transaction ID Acknowledgement .......................................................................................... 17
2.5.4. Apply Currency Charge Message Sequences......................................................................... 18
2.6. Apply Tariff ........................................................................................................................................................19
2.6.1. Apply Tariff Request............................................................................................................... 20
2.6.2. Apply Tariff Response ............................................................................................................ 22
2.6.3. Transaction ID Acknowledgement .......................................................................................... 23
2.6.4. Calculating the Charge........................................................................................................... 24
2.6.5. Apply Tariff Message Sequences ........................................................................................... 24
2.7. Apply Tariff Volume ...........................................................................................................................................25
2.7.1. Apply Tariff Volume Request .................................................................................................. 25
2.7.2. Apply Tariff Volume Response ............................................................................................... 28
2.7.3. Transaction ID Acknowledgement .......................................................................................... 28
2.7.4. Calculating the Charge........................................................................................................... 29
2.7.5. Apply Tariff with Volume Message Sequences ....................................................................... 30
2.8. Reversing Charges ............................................................................................................................................31
2.8.1. Reverse Charge Message Sequences.................................................................................... 31
2.8.2. Reverse Charge Request ....................................................................................................... 31
2.8.3. Reverse Charge Response .................................................................................................... 32
2.9. Disconnect Connection......................................................................................................................................33
2.10. Invalid Message.................................................................................................................................................33
2.11. Flow Control / Throttling.....................................................................................................................................34

Proprietary and Confidential Page 3 of 62

 2.12. Configuration Parameters ..................................................................................................................................34

3. Provisioning the Payment Server in the SAW .......................................................... 35

4. Application Note: Charging For Fun Dial Services .................................................. 37

4.1. Subscriber Ringback Tone Purchasing Process................................................................................................37
4.2. The High-Level Approach for Charging .............................................................................................................38
4.3. Message Flows..................................................................................................................................................39
4.3.1. Successful purchase of first ringback tone (Includes HLR interaction).................................... 39
4.3.2. Successful purchase of additional ringback tone .................................................................... 39
4.3.3. Successful purchase of gift ringback tone .............................................................................. 40
4.3.4. Failed purchase of first ringback tone (HLR-related error) ...................................................... 40
4.3.5. Failed purchase of ringback tone (Subscriber not authorized) ................................................ 40
4.3.6. Failed purchase of ringback tone (Internal error).................................................................... 40
4.4. Provisioning .......................................................................................................................................................40
4.4.1. Fun Dial Provisioning ............................................................................................................. 40
4.4.2. RTB Provisioning ................................................................................................................... 41
4.4.3. Provisioning Example ............................................................................................................ 41
4.5. RTB Usage Records ..........................................................................................................................................47
4.5.1. History Records ..................................................................................................................... 47
4.5.2. CDRs..................................................................................................................................... 48
4.6. Other Charging Considerations .........................................................................................................................49
4.7. Converged Considerations ................................................................................................................................49
4.8. Payment Server Apply Tariff Usage...................................................................................................................50

5. Application Note: MMS Charging Overview ............................................................. 51

5.1. Charging for Sending MMSs..............................................................................................................................51
5.2. Charging for Retrieving MMSs...........................................................................................................................52
5.3. Scenario 1: Person-To-Person (Via Handset)....................................................................................................53
5.3.1. Business Scenario ................................................................................................................. 53
5.3.2. Usage Scenario ..................................................................................................................... 53
5.3.3. Charging Scenario ................................................................................................................. 53
5.4. Scenario 2: Person-to-VAS Application (Via Handset) ......................................................................................54
5.4.1. Business Scenario ................................................................................................................. 54
5.4.2. Usage Scenario ..................................................................................................................... 54
5.4.3. Charging Scenario ................................................................................................................. 54
5.5. Scenario 3: Person-to-Person (Via Application).................................................................................................55
5.5.1. Business Scenario ................................................................................................................. 55
5.5.2. Usage Scenario ..................................................................................................................... 55
5.5.3. Charging Scenario ................................................................................................................. 55
5.6. Scenario 4: Person-To-VAS Application (Via Application) – Future Support .....................................................56
5.6.1. Business Scenario ................................................................................................................. 56
5.6.2. Usage Scenario ..................................................................................................................... 56
5.6.3. Charging Scenario ................................................................................................................. 57
5.7. Scenario 5: Retrieval of MMS (From Person) ....................................................................................................57

Page 4 of 62 Proprietary and Confidential ,

 5.7.1. Business Scenario ................................................................................................................. 57
5.7.2. Usage Scenario...................................................................................................................... 58
5.7.3. Charging Scenario ................................................................................................................. 58
5.8. Scenario 6: Retrieval of MMS (From VAS Application)......................................................................................58
5.8.1. Business Scenario ................................................................................................................. 58
5.8.2. Usage Scenario...................................................................................................................... 58
5.8.3. Charging Scenario ................................................................................................................. 59
5.9. Scenario 7: Retrieval of MMS (From E-mail) .....................................................................................................59
5.9.1. Business Scenario ................................................................................................................. 59
5.9.2. Usage Scenario...................................................................................................................... 59
5.9.3. Charging Scenario ................................................................................................................. 59
5.10. Param1 & Param2 (in CDR only) MMS Message Types Overview ...................................................................60
5.11. MMS File/Attachment Types ..............................................................................................................................60
5.12. MMS Message Types ........................................................................................................................................61
5.13. Payment Server Bearer and Discount Fields.....................................................................................................61
5.13.1. Bearer Capability Values ........................................................................................................ 61
5.13.2. Discount Values ..................................................................................................................... 62

Proprietary and Confidential Page 5 of 62

1. RTB Payment Server Interface Overview
The RTB Payment Server is a TCP/IP-based interface enabling external services to support real-
time authorization, rating, and charging for transactional usage.
The Payment Server can be used for charging many kinds of value-added services including
sending and receiving SMS and MMS messages, Internet access and other data content, vending
machine purchases, and various other transactions.
Two types of charging are supported.
The first type of charging allows the external service to debit a specific amount. This direct
charge might be typical of a vending machine purchase.
The second uses tariff information stored within the RTB system’s Rating Engine. This tariff-
based charge might be typical of an SMSC, which does not normally have rating capabilities.
Any charge may be “backed-out” or reversed, if the external service decides it is appropriate
(i.e., an SMS message was not successfully delivered).

2. RTB Payment Server Interface Specifications

2.1. Overview
The Payment Server interface has been designed to allow simple, network-based
communications between the Payment Server and external applications. Up to 20 simultaneous
sessions from one or more External Services are supported by a single Payment Server Service
Logic Unit (SLU).

TCP/IP is used as the transport protocol. As with any network-based communication,

configuration files (/etc/hosts and /etc/services files on the Payment Server system) must be
matched by the equivalent configuration files on the External Service side. This includes IP
Addresses as well as port number.

Two TCP/IP ports are reserved; port numbers 6200 and 6300. Port 6300 should only be used for
4.205 data transaction billing applications.

Data Content Providers should always use port number 50013.

Each External Service has the option to maintain a permanent connection to the Payment Server
or to connect only when there is an action to be performed.

The interface uses the 17 messages shown in Table 2-1.

Table 2-1 Payment Server Interface Messages

External Service Originated Payment Server Originated

Heartbeat Request Heartbeat Response

Page 6 of 62 Proprietary and Confidential ,

 External Service Originated Payment Server Originated

Validate Subscriber Request Validate Subscriber Response

Apply Charge Request Apply Charge Response

Apply Currency Charge Request Apply Currency Charge Response

Apply Tariff Request Apply Tariff Response

Transaction ID Acknowledge

Reverse Charge Reverse Charge Response

Confirmation Request Confirmation Response

Apply Tariff with Volume Apply Tariff with Volume Response

Invalid Message Response

Disconnect Session

The External Service initiates most actions, including establishing the TCP/IP session. Upon
receipt of an action request from the External Service, the Payment Server attempts to perform
the requested action, and sends a response messages indicating the success or failure of the
action.

Note that message sequences may be intermixed. The External Server need not wait until one
transaction has been completed before starting another transaction.

As a general rule, all data is left aligned. Any place within a field that does not contain a data
character should be filled with the space character.

Note that length field contains the length of the message excluding the length field itself.

2.1.1. Service Logic Unit Redundancy

The Payment Server application resides on the Comverse RTB Service Logic Unit (SLU),
which operates in an N+1 redundancy mode. Minimally, two SLUs are designated to support
the Payment Server application.

In the event that a particular SLU is unavailable, the External Service application must contain
logic to establish TCP/IP sessions with another SLU.

2.1.2. Load Sharing

The Payment Server does not contain any load sharing capabilities. So, if the load is greater
than that which can be handled by a single Payment Server, it is up to the External Service(s) to
divide the load between multiple Payment Server units.

2.2. Heartbeats
Heartbeat messages are sent between the External Service and the Payment Server in order to
keep the session active when there is no other message activity from the External Service.
The heartbeat period is configurable at the Payment Server, with the default value being one
minute, and a maximum value of 30 minutes.

Proprietary and Confidential Page 7 of 62

 If the Payment Server does not detect any External Service messages for two heartbeat periods,
it disconnects the session.
Similar functionality should be programmed in to the External Service.

2.2.1. Heartbeat Request

The Heartbeat Request message is sent from the External Service to the Payment Server in
order to keep the session active when there is no other message activity from the External
Service. It is important to note that the Payment Server always responds to a Heartbeat Request
with a Heartbeat Response.

Table 2-2 Heartbeat Request Message

Field Size Type Value Hexidecimal Value
(bytes)
Length 2 16 bit binary 2 0002x
Message ID 1 8 bit binary 1 = Request 01x
Message Name 1 8 bit binary 1 = Heartbeat 01x

2.2.2. Heartbeat Response

The Heartbeat Response message is sent from the Payment Server to the External Service in
response to the Heartbeat Request message.

Table 2-3 Heartbeat Response Message

Field Size Type Value Hexidecimal Value
(bytes)
Length 2 16 bit binary 2 0002x
Message ID 1 8 bit binary 2 = Response 02x
Message Name 1 8 bit binary 1 = Heartbeat 01x

Page 8 of 62 Proprietary and Confidential ,

 Figure 2-1 Typical Heartbeat Message Sequence

2.3. Validate Subscriber

The Validate Subscriber sequence is a “pre-qualification” used by the External Service to
validate a Subscriber ID, or to determine if the subscriber has a certain amount of money
available.
Using the Subscriber ID from the request message, the Payment Server responds with a status
indicating the subscriber’s validity (valid Subscriber ID, valid subscriber state), or with an
indication that the subscriber currently has sufficient balance to cover the charge.
This sequence returns information only, and does not in any way affect the subscriber’s account.

2.3.1. Validate Subscriber Request

The Validate Subscriber Request message is sent from the External Service to the Payment
Server to validate an RTB subscriber’s status and balance.

Validate Subscriber Request message does not actually debit the subscriber’s
account.

Proprietary and Confidential Page 9 of 62

 Table 2-4 Validate Subscriber Request Message
Field Size Type Value Hexidecimal Value
(bytes)
Length 2 16 bit binary 53
Message ID 1 8 bit binary 1 = Request
Message Type 1 8 bit binary 2 = Validate Subscriber
Associated 4 ASCII/binary A value generated by the
Number External Service to uniquely
identify this request
Subscriber ID 30 ASCII ID of subscriber to be
validated
Charge 17 ASCII Amount of charge to be
Amount validated

2.3.2. Validate Subscriber Response

Table 2-5 Validate Subscriber Response Message

Field Size Type Value Hexidecimal Value
(bytes)
Length 2 16 bit binary 15
Message ID 1 8 bit binary 2 = Response
Message Type 1 8 bit binary 2 = Validate
Subscriber
Associated 4 ASCII/binary The Associated
Number Number that was
received in the
request
Status ID 1 8 bit binary 00x =Subscriber is prepaid, valid,
active, and has sufficient balance
01x = Invalid Subscriber ID
02x = Prepaid subscriber not active
03x = Service unavailable
04x = Prepaid subscriber has
insufficient balance
10x = Subscriber is postpaid, valid,
active, and has sufficient credit
12x = Postpaid subscriber not active
14x = Postpaid subscriber has
insufficient balance
Note- For purposes of this field, a
Toggle subscriber is considered
Prepaid when in Prepaid mode and
Postpaid when in Postpaid mode.
Filler 8 N/A Unused

Page 10 of 62 Proprietary and Confidential ,

2.3.3. Validate Subscriber Response
The Validate Subscriber Response message is sent from the Payment Server to the External
Service in response to the Validate Subscriber Request message.
The response indicates whether the Subscriber ID is valid, if the subscriber is in a valid state,
and if the subscriber has sufficient balance.

2.4. Apply Charge

The Apply Charge sequence is used by the External Service to debit a subscriber’s account by a
specific amount.
The Apply Charge sequence is initiated by the External Service sending the Apply Charge
Request message to the Payment Server to debit a subscriber’s account. After confirming that
the Subscriber ID is valid, the subscriber is in the Active state, and that the subscriber has
enough balance to afford the Charge Amount, the Payment Server deducts the charge amount
from the subscriber, creates appropriate transaction records on the RTB system, sends back a
positive response message to the External Service, and starts a timer (default value 5 minutes)
to wait for the Transaction ID Acknowledge message from the External Service.
If the Transaction ID Acknowledge is not received within the defined time period, the
subscriber charge is automatically reversed at the RTB system.
If the subscriber is unavailable or has an insufficient balance, the Payment Server sends a
negative response to the external client, indicating the status of the subscriber, and the charge
amount is not deducted from the subscriber's account.

2.4.1. Apply Charge Request

When the External Service wants to debit a subscriber’s account by a specific amount, it sends
an Apply Charge request message that enables it to communicate with the Payment Server. If
the subscriber is active with a sufficient balance, then the charge amount is deducted from the
subscriber's account.
If any of the validation steps fail, a negative response message is sent to the External Service,
no debit is applied to the subscriber’s account, and no call records are created on the RTB. No
Transaction ID Acknowledge message is required when a negative response is received.
The apply charge sequence includes an Associated Number field. This field, supplied by the
External Server, is used to link the request and response messages.

Table 2-6 Apply Charge Request Message

Field Size Type Mandatory / Value Hexidecimal Value
(bytes) Optional
Length 2 16 bit binary M 85 0055x
Message 1 8 bit binary M 1 = Request 01x
ID
Message 1 8 bit binary M 3 = Apply 03x
Type Charge

Proprietary and Confidential Page 11 of 62

 Field Size Type Mandatory / Value Hexidecimal Value
(bytes) Optional
Associated 4 ASCII/binary M A value 00000001x – This
Number generated by number is generated
the External by the external server
Service to to be used as a
uniquely reference number for
identify this all messages related
request to this transaction.
Subscriber 30 ASCII M ID of 393939313233343536
ID subscriber to 20….20x
be validated i.e., 999123456
Subscriber ID in the
format that is stored in
the RTB database.
Field is left-justified,
padded with spaces to
fill in the 30 bytes.
Charge 17 ASCII M Amount to be 31302E3030202020…
Amount charged to 20
subscriber’s i.e., 10.00 dollars
account. Valid
amounts are – Field is left-justified,
999999999999 padded with spaces to
.999 to 0.00 fill in the 17 bytes.

Type of 32 ASCII M A character Note that if the first

Charge string characters are MMS
indicating the 72696E67746F6E6523
transaction 312020…...20x
type (i.e., train
ticket) i.e., ringtone#1
Field is left-justified,
padded with spaces to
fill in the 32 bytes.

2.4.2. Apply Charge Response

The Apply Charge Response message is sent from the Payment Server to the External Service in
response to the Apply Charge Request message.
A Status of 0 indicates that the account has been debited. Any other Status value indicates that
the charge has not been applied.

Table 2-7 Apply Charge Response Message

Field Size Type Value Hexidecimal Value
(bytes)
Length 2 16 bit binary 15 000Fx
Message ID 1 8 bit binary 2 = Response 02x
Message Type 1 8 bit binary 3 = Apply Charge 03x

Page 12 of 62 Proprietary and Confidential ,

 Field Size Type Value Hexidecimal Value
(bytes)
Associated 4 ASCII/binary The Associated Number 00000001x – This is the
Number that was received in the number that was received in
request the Apply Charge request
message to which this is the
response.
Transaction ID 8 64 bit binary This number is 0123456789ABCDEFx
generated by the
Payment Server to
uniquely identify this
transaction. The
external server must
use this number in any
follow-on messages
such as Transaction
Acknowledge of
Reverse Charge.
Status ID 1 8 bit binary 00 = Prepaid Charge 00x or 10x
Applied This indicates that the charge
01 = Invalid Subscriber was applied to the subscriber.
ID If the charge could not be
02 = Prepaid subscriber applied, then a non-zero Status
not active ID would be returned, and the
value would indicate why the
03 = Service charge could not be applied.
unavailable
04 = Prepaid subscriber
has insufficient balance
10 = Postpaid Charge
Applied
12 = Postpaid
subscriber not active
13 = Service
unavailable
14 = Postpaid
subscriber has
insufficient balance

2.4.3. Transaction ID Acknowledgement

The Transaction ID Acknowledge message is sent from the External Service to the Payment
Server in response to either the Apply Charge Response or Apply Tariff messages.
This message is sent to either acknowledge that the charge or tariff should or should not be
reversed.

The Transaction ID Acknowledge message must be received within the defined

time period, or the Payment Server automatically reverses the charge.

A Status ID of 0 indicates that the charge should remain. A Status ID of 1 indicates that the
charge should be reversed.

Proprietary and Confidential Page 13 of 62

 The Transaction ID Acknowledge message also allows the External Service to
request that the charge be reversed.

Table 2-8 Transaction ID Acknowledge Message

Field Size Type Value Hexidecimal Value
(bytes)
Length 2 16 bit binary 15 000Fx
Message ID 1 8 bit binary 1 = Request 01x
Message Type 1 8 bit binary 6 = Transaction 06x
ID Acknowledge
Associated 4 ASCII/binary The Associated 00000001x – This is the number that
Number Number that was received in the original Apply
was received in Charge request message to which this
the charge or is the acknowledgement.
tariff request
Transaction ID 8 64 bit binary Transaction ID 0123456789ABCDEFx
as supplied by This is the number that the Payment
the Payment Server returned as part of the Apply
Server in the Charge response.
response
message
Status ID 1 8 bit binary 0 = Apply 00x
1 = Reverse In general, this message is used to
ACK the Apply Charge/Tariff
response.
The only time Reverse (01x) would be
used is in the unlikely event that the
external service immediately realized
that the original request was a
mistake.

2.4.4. Limitations
Because Apply Charge requests do not access RTB tariffs, these transactions are treated as
balance adjustments, and have the following limitations:
ƒ Only currency charges are allowed. Charging in other units is not supported.
ƒ The currency type of the charge must be the same as the currency used by the subscriber. If
the currency types differ, the Apply Currency Charge (refer to section 2.5) must be used.
ƒ Charges may only be taken from the Core Balance. Other balances are not considered.
ƒ Usage-based promotions are not supported. Usage reported in Apply Charge messages is not
counted by the usage-based promotion accumulators, and discounts cannot be applied to
charges from Apply Charge requests.
The Apply Tariff sequence is used by the External Service to charge for subscriber’s usage
based on tariff tables within the RTBS.
The sequence is initiated by the External Service sending the Apply Tariff Request message to
the Payment Server.

Page 14 of 62 Proprietary and Confidential ,

2.5. Apply Currency Charge
The Apply Currency Charge sequence is used by the External Service to debit a subscriber’s
account by a specific amount of a specific currency type.
The sequence is initiated by the External Service sending the Apply Currency Charge Request
message to the Payment Server.
Apply Currency Charge Request is identical to the Apply Charge Request except for the
addition of a Currency Type field, which contains the ISO Currency Code for the charge being
applied.
Apply Currency Charge operates identically to the Apply Charge Request and Apply Charge
Response scenarios except that in the case that the charging currency does not match the
subscriber’s COS currency:
ƒ If the currency mismatch flag is set to be true, the charge shall be converted to the
subscriber’s COS currency, using the then applicable conversion rate based on the
subscriber’s primary home time zone.
ƒ If currency mismatch is false, the call shall be rejected. The Apply Currency Charge
Response shall indicate a failure status of Currency Mismatch.

2.5.1. Apply Currency Charge Request

The Apply Currency Charge Request message is sent from the External Service to the Payment
Server to debit a subscriber’s account by a specific amount.

Table 2-9 Apply Currency Charge Request Message

Field Size Type Mandatory / Value Hexidecimal Value
(bytes) Optional
Length 2 16 bit M 88 0058x – hex equivalent of
binary 88
Message ID 1 8 bit M 1=Request 01x
binary
Message Type 1 8 bit M 10=Apply 0Ax
binary Currency Charge
Associated 4 ASCII/bin M A value 00000001x – This number
Number ary generated by the is generated by the
External Service external server to be used
to uniquely as a reference number for
identify this all messages related to
request this transaction.
Subscriber ID 30 ASCII M ID of subscriber 39393931323334353620
to be validated ….20x
i.e., 999123456
Subscriber ID in the
format that is stored in the
RTBS database.
Field is left-justified,
padded with spaces to fill
in the 30 bytes.

Proprietary and Confidential Page 15 of 62

 Field Size Type Mandatory / Value Hexidecimal Value
(bytes) Optional
Charge 17 ASCII M Amount to be 31302E3030202020…20
Amount charged to i.e., 10.00 dollars
subscriber’s
account. Valid Field is left-justified,
amounts are padded with spaces to fill
0.00 to in the 17 bytes.
999999999999.9
99
Type of Charge 32 ASCII M A character Note that if the first
string indicating characters are MMS
the transaction 72696E67746F6E652331
type (i.e., train 2020…...20x
ticket) i.e., ringtone#1
Field is left-justified,
padded with spaces to fill
in the 32 bytes.
Currency Type 3 ASCII M The ISO
Currency Code
for the charge
being applied.

2.5.2. Apply Currency Charge Response

The Apply Currency Charge Response message is sent from the Payment Server to the External
Service in response to the Apply Currency Charge Request message.
A Status of 0 indicates that the account has been debited. Any other Status value indicates that
the charge has not been applied

Table 2-10 Apply Currency Charge Response Message

Field Size Type Value Hexidecimal Value
(bytes)
Length 2 16 bit binary 1 000Fx
Message ID 1 8 bit binary 2=Response 02x
Message Type 1 8 bit binary 10=Apply Currency 0Ax
Charge
Associated 4 ASCII/binary The Associated 00000001x – This is the number
Number Number that was that was received in the Apply
received in the Currency Charge request message
request to which this is the response.

Page 16 of 62 Proprietary and Confidential ,

 Field Size Type Value Hexidecimal Value
(bytes)
Transaction ID 8 64 bit binary This number is 0123456789ABCDEFx
generated by the
Payment Server to
uniquely identify
this transaction.
The external server
must use this
number in any
follow-on
messages such as
Transaction
Acknowledge of
Reverse Charge.
Status ID 1 8 bit binary 00=Charge Applied (0Ax)
01=Invalid 00x
Subscriber ID This indicates that the charge was
02= Subscriber not applied to the subscriber. If the
active charge could not be applied, then a
03=Service non-zero Status ID would be
unavailable returned, and the value would
indicate why the charge could not
04= Subscriber has be applied.
insufficient balance
10= Currency
Mismatch

2.5.3. Transaction ID Acknowledgement

The Transaction ID Acknowledge message is sent from the External Service to the Payment
Server in response to the Apply Currency Charge Response message.
This message is sent to either acknowledge that the charge or tariff should be taken, or to notify
the Payment Server that the charge/tariff should be reversed.
In general, this message should be thought of as a protocol acknowledgement that the client has
received the successful Apply Currency Charge Response.
Note that this message must be received within the agreed upon time period, (which should be 5
minutes or less), or the Payment Server automatically reverses the charge.
A Status ID of 0 indicates that the charge should remain. A Status ID of 1 indicates that the
charge should be reversed.

Table 2-11 Transaction ID Acknowledge Message

Field Size Type Value Hexidecimal Value
(bytes)
Length 2 16 bit binary 15 000Fx
Message ID 1 8bit binary 1=Request 01x
Message Type 1 8 bit binary 6=Transaction ID 06x
Acknowledge

Proprietary and Confidential Page 17 of 62

 Field Size Type Value Hexidecimal Value
(bytes)
Associated 4 ASCII/binary The Associated 00000001x – This is the
Number Number that was number that was received in the
received in the charge original Apply Currency Charge
or tariff request request message to which this
is the acknowledgement.
Transaction ID 8 64 bit binary Transaction ID as 0123456789ABCDEFx
supplied by the This is the number that the
Payment Server in the Payment Server returned as
response message part of the Apply Currency
Charge response.
Status ID 1 8 bit binary 0=Apply 00x
1 = Reverse In general, this message is
used to ACK the Apply
Charge/Currency Charge/Tariff
response.
The only time Reverse (01x)
would be used is in the unlikely
event that the external service
immediately realized that the
original request was a mistake.

2.5.4. Apply Currency Charge Message Sequences

The following are typical Apply Currency Charge message sequences:

Figure 2-2 Typical Apply Currency Charge Message Sequence – Charge Not Reversed

Page 18 of 62 Proprietary and Confidential ,

 Figure 2-3 Typical Apply Currency Charge Message Sequence – Charge Reversed by External Server

Figure 2-4 Typical Apply Currency Charge Message Sequence – Charge Reversed Due To Timeout

2.6. Apply Tariff

The Apply Tariff request message is sent by an external client to the Payment Server when the
external client wants to charge a subscriber using the RTB tariff and rating engine. If the
transaction is authenticated then RTB determines the actual cost and enables the Payment
Server to deduct the derived charges tariff from the appropriate party.
There are three scenarios in which a tariff can be applied: Mobile Originating (MO) to
application, application to Mobile Terminating (MT), or MO to MT.
ƒ A Mobile Originating to Application type message deducts the tariff from the originating
subscriber's account.
ƒ An Application to Mobile Terminating type message deducts the tariff from the terminating
subscriber's account.

Proprietary and Confidential Page 19 of 62

 ƒ A Mobile Originating to Mobile Terminating type message deducts the tariff from the
originating subscriber's account.
Charges are calculated based on a variety of factors, which are described in section 2.6.4.
If the subscriber to be charged is capable of paying for the transaction (has enough funds, and is
in a state allowing the transaction), the subscriber’s account is debited, and the Payment Server
responds with an Apply Tariff response message, with a status indicating the transaction is
allowed and has been charged.
Additionally, the Payment Server starts a timer (default value 5 minutes) to wait for the
Transaction ID Acknowledge message from the External Service.
If the Transaction ID Acknowledge is not received within the defined time period, the
subscriber charges are automatically reversed at the RTB system!
Each time the Payment Server updates the RTB database of account balances, a record is added
to the Payment Server Transaction History table, and optionally a CDR is generated.
If, however, the subscriber is unavailable or has insufficient balance, the Payment Server
creates a negative response message to the external client, the charge amount is not deducted
from the subscriber's account, and no transaction is recorded in the RTB.

No Transaction ID Acknowledge message is required when a negative response

is received.

The Apply Tariff sequence also includes an Associated Number field. This field, supplied by the
External Server, is used to link the request and response messages.

2.6.1. Apply Tariff Request

The Apply Tariff Request message is sent from the External Service to the Payment Server to
charge a subscriber using the RTB tariff and rating engine.

Table 2-12 Apply Tariff Request Message

Field Size Type Mandatory Value Hexidecimal Value
(bytes) / Optional
Length 2 16 bit binary M 135 0087x
Message ID 1 8 bit binary M 1 = Request 01x
Message 1 8 bit binary M 4 = Apply 04x
Type Tariff
Associated 4 ASCII/binary M A value 00000002x – This is the
Number generated by number that was received in
the External the Apply Charge request
Service to message to which this is the
uniquely response.
identify this
request

Page 20 of 62 Proprietary and Confidential ,

Field Size Type Mandatory Value Hexidecimal Value
(bytes) / Optional
Originating 30 ASCII M Originating 39393939393132332020….20x
Caller ID Subscriber ID i.e., 99991234
or Application
ID This represents the Application
ID, which is some unique way
to identify the service.
Originating 30 ASCII O MSC Address 20202020….20x
Subscriber / Cell ID of
MSC originating
Address subscriber
Subscriber 1 8 bit binary M 1 = Mobile 01x or 02x or 03x or 04x
Type Originating to
Mobile
Terminating
(MO to MT)
2 = Mobile
Originating to
Application
3=
Application to
Mobile
Terminating
4 = Data
Terminating 30 ASCII M Terminating 39393931323334353620….20x
Caller ID Caller ID or i.e., 999123456
Application ID
Subscriber ID in the format that
If blank, and is stored in the RTB database.
the In this case, this is the
Terminating subscriber receiving the item
Subscriber (ringtone).
MSC Address
is also blank, Field is left-justified, padded
the with spaces to fill in the 30
terminating bytes.
party is
assumed to
be
“anywhere”
Terminating 30 ASCII O MSC Address 20202020….20x
Subscriber / Cell ID of Assuming we are not doing
MSC terminating location-based charges, this
Address subscriber field is not used, so it should
be filled with all spaces.
Bearer 4 ASCII M 2= 32202020x
Capability WAP/SMS i.e., 2
Transaction
3 = Web
Transaction
11 = Data-
Services

Proprietary and Confidential Page 21 of 62

 Field Size Type Mandatory Value Hexidecimal Value
(bytes) / Optional
Discount 4 ASCII M Allowable 31323520x
values: 0-255 i.e., 125
This field is A combination of the
used by the Application ID and Discount
tariff engine fields ultimately determines
to determine which tariff is applied to
the charge for calculate the charge.
the service.

For content providers, the Subscriber Type should be 4 (Data), and the Bearer
Capability should be 11 (Data-Services)

2.6.2. Apply Tariff Response

Table 2-13 Apply Tariff Response Message

Field Size Type Value Hexidecimal Value
(bytes)
Length 2 16 bit binary 15 000Fx
Message ID 1 8 bit binary 2 = Response 02x
Message Type 1 8 bit binary 4 = Apply Tariff 04x
Associated 4 ASCII/binary The Associated 00000002x – This is the number that
Number Number that was was received in the Apply Charge
received in the request message to which this is the
request response.
Transaction ID 8 64 bit binary This 8 byte 0123456789ABCDFFx
number is
generated by the
Payment Server
to uniquely
identify this
transaction. The
external server
must use this
number in any
follow-on
messages such
as Transaction
Acknowledge of
Reverse Charge.

Page 22 of 62 Proprietary and Confidential ,

 Field Size Type Value Hexidecimal Value
(bytes)
Status ID 1 8 bit binary 00x = Charge successfully applied to
prepaid subscriber
01x = Invalid Subscriber ID
(subscriber not found)
02x = Prepaid subscriber not active or
not data enabled, charge not applied
03x = Service unavailable
04x = Prepaid subscriber has
insufficient balance, partial charge
taken
05x = Tariff engine error
06x = No tariffs found
10x = Charge successfully applied to
postpaid subscriber
12x = Postpaid subscriber not active
or not data enabled, charge not
applied
14x = Postpaid subscriber has
insufficient balance, partial charge
taken
Note- For purposes of this field, a
Toggle subscriber is considered
Prepaid when in Prepaid mode and
Postpaid when in Postpaid mode.

2.6.3. Transaction ID Acknowledgement

Table 2-14 Transaction ID Acknowledge Message

Field Size Type Value Hexidecimal Value
(bytes)
Length 2 16 bit binary 15 000Fx
Message ID 1 8 bit binary 1 = Request 01x
Message Type 1 8 bit binary 6 = Transaction ID 06x
Acknowledge
Associated 4 ASCII/binary The Associated 00000002x – This is the number
Number Number that was that was received in the original
received in the Apply Tariff request message to
charge or tariff which this is the acknowledgement.
request
Transaction ID 8 64 bit binary Transaction ID as 0123456789ABCDFFx
supplied by the This is the number that the Payment
Payment Server in Server returned as part of the Apply
the response Tariff response.
message

Proprietary and Confidential Page 23 of 62

 Field Size Type Value Hexidecimal Value
(bytes)
Status ID 1 8 bit binary 0 = Apply 00x
1 = Reverse In general, this message is used to
ACK the Apply Charge/Tariff
response.
The only time Reverse (01x) would
be used is in the unlikely event that
the external service immediately
realized that the original request
was a mistake.

2.6.4. Calculating the Charge

The standard RTB billing model is used to calculate the charge for the service.
This involves first mapping the received Bearer and Discount values into an Initial Activity /
Subtype / and Unit Type via the Payment Server Translation table (shown in section 3 below).
The initial Subtype can then be mapped to a final Subtype based on Location Relationships,
using the location information provided in the Originating and Terminating MSC Address fields
in the Apply Tariff message, and / or special features (like Friends and Family).
The Final Activity / Subtype / Unit type is used to determine the Tariff Plan (and associated
Tariffs) based on the subscriber’s COS, as well as the Date/Time of the usage.
Ultimately charges are calculated based on the Tariffs within the Tariff Plan.

2.6.5. Apply Tariff Message Sequences

The following are typical Apply Tariff message sequences:

Figure 2-5 Typical Apply Tariff Message Sequence – Charge Not Reversed

Page 24 of 62 Proprietary and Confidential ,

 Figure 2-6 Typical Apply Tariff Message Sequence – Charge Reversed by External Server

Figure 2-7 Typical Apply Tariff Message Sequence – Charge Reversed Due To Timeout

2.7. Apply Tariff Volume

The Apply Tariff Volume method allows an external system to apply a tariff to a specified
volume of units for MO-MT, App-MT and MO-App transactions. This method is similar to the
Apply Tariff method with the addition of Volume, Unit Type, and Param1 and Param2 fields.

2.7.1. Apply Tariff Volume Request

The Apply Tariff Volume Request message is sent from the External Service to the Payment
Server to charge a subscriber using the RTB tariff and rating engine, based on usage volume.

Proprietary and Confidential Page 25 of 62

 Table 2-1 Apply Tariff with Volume Request Message
Field Size Type Mandatory / Value Comment
Format Optional
Length 2-char 16-bits M 178 This is the message size.
binary
Message ID 1-char 8-bits M 1 Request (01x)
binary
Message Type 1-char 8-bits M 11 APPLYTARIFF_VOLUME
binary (05x)
Associated 4-chars ASCII/bin M A value generated by the
Number ary External Service to uniquely
identify this request
Originating Caller 30- ASCII M 12345678 MSISDN of Originating
ID chars Subscriber (no porting prefix)
Originating 30- ASCII O A-number location.
Subscriber MSC chars
Address
Subscriber Type 1-char 8-bits M 1 1=MO-MT. 2=MO-App.
binary 3=App-MT.
Terminating 30- ASCII M 1234568 MSISDN of Terminating Party
Caller ID chars
Terminating 30- ASCII O B-number location.
Subscriber MSC chars
Address
Bearer Capability 4-chars ASCII M 101 Values 0000-9999. Used
along with Discount and Unit
Type to determine RTBS
Application and SubType.

Examples:

HS to HS: 101
HS to VAS: 102
HS to E-mail: 103
SoB to HS: 104
SoB to E-mail: 105
SoB to VAS (future): 106
VAS to HS: 107
E-mail to HS:108

Page 26 of 62 Proprietary and Confidential ,

Field Size Type Mandatory / Value Comment
Format Optional
Discount 4-chars ASCII M 102 Values 0000-9999. Used
along with Discount and Unit
Type to determine RTBS
Application and SubType.

Examples

Picture=101 ;
Audio=102 ;
Video=103 ;
Text=104 ;
Ringtone=105 ;
Multi=106 ;
Empty = 107;
Other = 108
Volume 10- ASCII M 3000000 Volume (typically bytes used).
chars Values 0-999999999 allowed.

This is a required field for this

method.
Unit Type 4-chars ASCII M 2 Unit of volume. Ultimately this
is mapped to an RTBS Unit
via the PS Unit Type Mapping
table defined below.

Allowable values are 0-9999.

This is a required field for this

method.
InfoParam1 32- ASCII O ABCD Information passed to the
chars CDR, but NOT used in rating
determination.
Should be left blank when not
used.
For Comverse MMSC, this
field is the 1st 32-characaters
of destination e-mail address
in this field.
InfoParam2 32- ASCII O EFGH Information passed to the
chars CDR, but NOT used in rating
determination.
Should be left blank when not
used.
For Comverse MMSC, this is
the VAS ID and VAS Name in
this field.

Proprietary and Confidential Page 27 of 62

2.7.2. Apply Tariff Volume Response
The Apply Tariff Volume Response message is sent from the Payment Server to the External
Service in response to the Apply Tariff Request message.
A Status of 0 indicates that the account has been debited. Any other Status value indicates that
no charge has been applied. [

Table 2-15 Apply Tariff with Volume Response Message

Field Size Type Value
Length 2-bytes 16-bits binary 15
Message ID 1-byte 8-bits binary 2=Response
Message Type 1-byte 8-bits binary 11=Apply Tariff Volume
Associated Number 4-bytes ASCII/binary The Associated Number that was
received in the request
Transaction ID 8-bytes 64-bits binary This 8-byte number is generated
by the Payment Server to uniquely
identify this transaction. The
external server must use this
number in any follow-on messages
such as Transaction Acknowledge
of Reverse Charge.
Status ID 1-byte 8-bits binary 00x=Charge successfully applied
to subscriber
01x=Invalid Subscriber ID
(subscriber not found)
02x=Subscriber not active or not
data enabled, charge not applied
03x=Service unavailable
04x=Subscriber has insufficient
balance, partial charge taken
05x=Tariff engine error
06x=No tariffs found

2.7.3. Transaction ID Acknowledgement

Table 2-16 Transaction ID Acknowledge Message

Field Size Type Value Hexidecimal Value
(bytes)
Length 2 16 bit binary 15 000Fx
Message ID 1 8 bit binary 1 = Request 01x
Message Type 1 8 bit binary 6 = Transaction ID 06x
Acknowledge
Associated 4 ASCII/binary The Associated 00000002x – This is the number
Number Number that was that was received in the original
received in the Apply Tariff Volume request
charge or tariff message to which this is the
request acknowledgement.

Page 28 of 62 Proprietary and Confidential ,

 Field Size Type Value Hexidecimal Value
(bytes)
Transaction ID 8 64 bit binary Transaction ID as 0123456789ABCDFFx
supplied by the This is the number that the Payment
Payment Server in Server returned as part of the Apply
the response Tariff response.
message
Status ID 1 8 bit binary 0 = Apply 00x
1 = Reverse In general, this message is used to
ACK the Apply Charge/Tariff
response.
The only time Reverse (01x) would
be used is in the unlikely event that
the external service immediately
realized that the original request
was a mistake.

2.7.4. Calculating the Charge

The standard RTB billing model is used to calculate the charge for the service.
This involves first mapping the received Bearer and Discount values into an Initial Activity /
Subtype / and Unit Type via the Payment Server Translation table (shown in section 3 below).
The initial Subtype can then be mapped to a final Subtype based on Location Relationships,
using the location information provided in the Originating and Terminating MSC Address fields
in the Apply Tariff message, and / or special features (like Friends and Family).
The Final Activity / Subtype / Unit type is used to determine the Tariff Plan (and associated
Tariffs) based on the subscriber’s COS, as well as the Date/Time of the usage.
Ultimately charges are calculated based on the Tariffs within the Tariff Plan.

Proprietary and Confidential Page 29 of 62

2.7.5. Apply Tariff with Volume Message Sequences
The following are typical Apply Tariff with volume message sequences:

Figure 2-8 Typical Apply Tariff with Volume Message Sequence – Charge Not Reversed

Figure 2-9 Typical Apply Tariff with Volume Message Sequence – Charge Reversed by External Server

Page 30 of 62 Proprietary and Confidential ,

 Figure 2-10 Typical Apply Tariff with Volume Message Sequence – Charge Reversed Due To Timeout

2.8. Reversing Charges

There may be times when the External Server requests that the previous transaction be reversed.
Examples would be the case where an SMS message was unable to be delivered, or a refund is
required for a purchase from a vending machine.
Apart from the Transaction ID Acknowledge, discussed in Section 2.4, which can only be used
to reverse the charge within a short time of the original charge (typically 5 minutes), the
Reverse Charge method can be used to reverse any previous transaction, based on the
Transaction ID.
Be aware that a reversal cannot be reversed. The Payment Server contains logic such that only
valid Transactions can be reversed, and each can only be reversed once.

Reverse Charge depends on the existence of transaction histories to operate

correctly. If transaction histories are purged after five days, a transaction that is
six days old cannot be reversed.

2.8.1. Reverse Charge Message Sequences

The following are some typical Reverse Charge messaging sequences:

2.8.2. Reverse Charge Request

The Reverse Charge Request message is sent from the External Service to the Payment Server
to reverse a previous transaction.

Table 2-17 Reverse Charge Request Message

Field Size Type Mandatory Value Hexidecimal Value
(bytes) / Optional
Length 2 16 bit binary M 14 000Ex
Message ID 1 8 bit binary M 1 = Request 01x

Proprietary and Confidential Page 31 of 62

 Field Size Type Mandatory Value Hexidecimal Value
(bytes) / Optional
Message 1 8 bit binary M 5 = Reverse 05x
Type Charge
Associated 4 ASCII/binary M A value 00000003x
Number generated by
the External
Service to
uniquely
identify this
request
Transaction 8 64 bit binary M Transaction ID 0123456789ABCDFFx
ID as supplied by This is the number that the
the Payment Payment Server returned as
Server in the part of the Apply Tariff
response to the response.
charge/tariff
request

2.8.3. Reverse Charge Response

The Reverse Charge Response message is sent from the Payment Server to the External Service
in response to the Reverse Charge Request.
The Payment server looks internally for a Payment Server Transaction History record with a
matching Transaction ID.
If a match is found, the transaction is reversed, meaning the charge amounts are refunded to the
subscriber, a Payment Server History record is created, optionally a CDR is created, and a
positive response is sent.
If a match is not found, for example, if a transaction’s history record has been purged, a
negative response is sent.

Table 2-18 Reverse Charge Response Message

Field Size Type Value Hexidecimal Value
(bytes)
Length 2 16 bit binary 7 0007x
Message 1 8 bit binary 2 = Response 02x
ID
Message 1 8 bit binary 5 = Reverse Charge 05x
Type
Associated 4 ASCII/binary The Associated Number 00000003x – This is the number
Number that was received in the that was used in the Reverse
reverse request Charge request message.
Status 1 8 bit binary 0 = Charge Reversed 00x
7 = Transaction Not Found 0 indicates that the transaction
was reversed. 7 indicates that the
Transaction ID was not found, so
the transaction could not be
reversed.

Page 32 of 62 Proprietary and Confidential ,

 If a subscriber’s currency is found to be different from the currency in use at the
time of a transaction, the RTB uses the currency conversion rate that was in
Apply Tariff.

Table 2-19 depicts a typical Reverse Charge messaging sequence:

Table 2-19 Typical Reverse Charge Message Sequence –Reverse Charge Request

2.9. Disconnect Connection

Either side may send a Disconnect Message to terminate the session.
ƒ The Payment Server sends the Disconnect message when a switchover from Active to
Standby occurs.
ƒ The External Service may send the Disconnect message at any time.
The only response to this message is to tear down the TCP/IP session.

Table 2-20 Disconnect Request Message

Field Size Type Value Hexidecimal Value
(bytes)
Length 2 16 bit binary 2 0002x
Message ID 1 8 bit binary 1 = Request From 01x or 02x depending on which
External Service side is sending the message
2 = Request From
Payment Server
Message 1 8 bit binary 8 = Disconnect 08x
Type

2.10. Invalid Message

If the Payment Server receives an invalid message type, it replies with an Invalid Response
message.

Proprietary and Confidential Page 33 of 62

 Table 2-21 Invalid Response Message
Field Size Type Value Hexidecimal Value
(bytes)
Length 2 16 bit binary 7 0007x
Message ID 1 8 bit binary 2=Response 02x
Message Type 1 8 bit binary The Message ??x - Whatever was in the fourth byte
Type that was of the “garbage” message received by
received the Payment Server.
Associated 4 ASCII/binary Associated ????????x – Whatever was in the
Number Number that Associated Number field of the
was received “garbage message received by the
Payment Server.
Status ID 1 8 bit binary 8 = Invalid 08x
message
Type

2.11. Flow Control / Throttling

There may be instances where requests through the Payment Server cannot be handled due to
the RTB system being too busy. When in this overload condition, the Payment Server takes the
following actions in an attempt to throttle interactions with the RTB application:
ƒ Apply Charge, Apply Tariff, Validate Subscriber, and Reverse Charge requests are ignored.
The External Service should react by resending these requests after the appropriate timeout
period.
It is expected that overload conditions are transient, and will occur very infrequently.

2.12. Configuration Parameters

The Service Parameters Table fields shown in Table 2-22 must be configured.

Table 2-22 Payment Server-Related Fields in the Service Parameters Table

Service Parameters Table Fields Default Description
PSVR_AC_SV_CD NULL Payment Server Apply Charge Service Code
PSVRCP_AC_SV_CD NULL Content Provider Apply Charge Service Code
PSVR_AC_CH_CD NULL, Payment Server Apply Charge Charge Code
PSVRCP_AC_CH_CD NULL Content Provider Apply Charge Charge Code
PSVR_AC_CG_TP 1 Payment Server Apply Charge Charge Type
PSVRCP_AC_CG_TP 1 Content Provider Apply Charge Charge Type
PSVRCP_AC_BR_TP 11 PMTSVRCP Apply Charge Bearer Type
PMT_CDR_UNSUCC 0 0=OFF,1=ON, Generate CDRs for unsuccessful
attempts

Page 34 of 62 Proprietary and Confidential ,

3. Provisioning the Payment Server in the SAW
How
1. Log in to the System Administration Workstation (SAW).
2. In the TreeView area of the SAW, click on Billing Model. The Billing Model TreeView
displays.
3. In the Billing Model TreeView, under External Interfaces, click Payment Server.
4. Click PS Unit Type Mapping. The Payment Server Unit Type Mapping window appears.

Figure 3-1 Payment Server Unit Type Mapping Window

5. To map a new external unit type to an RTB internal unit type, click New on the toolbar.
6. In the External Parameters detail pane, complete the following fields:
ƒ External Unit Type – numeric value, 0-9999
ƒ External Unit Type Description – numeric value, 0-9999.
7. In the Internal Parameters detail pane, complete the Unit Type field by making a selection
from the drop-down list.
8. Click Save. The new External Unit Type Mapping is added to the selection list in the
Payment Server Unit Type Mapping window.
9. In the Billing Model TreeView, click PS Unit Type Mapping.
10. The Payment Server Translation window (Figure 3-2) appears.

Proprietary and Confidential Page 35 of 62

 Figure 3-2 Payment Server Translation Window

11. To define a new mapping of Bearer, Discount, and External Type to Application / Subtype /
Unit Type, click New on the toolbar. Text fields in the Payment Server Translation window
become available in the Payment Server Detail pane.
12. In the Payment Server Detail pane, complete the following fields:
ƒ Bearer Capability – numeric value, 0-9999
ƒ Discount – numeric value, 0-9999.
13. Complete the following fields by making selections from the drop-down lists:
ƒ External Unit Type Description – description of the external unit type to which an
RTB unit type will be mapped.
ƒ Application – name of the application for which usage charges will be determined, e.g.,
voice call, SMS, etc.
ƒ Application Sub Type – sub type name associated with this Application activity.
Application Sub Types are defined in the Activity Definition table.
ƒ Unit Type − unit type to be used for tariff charging (Currency, Seconds, Octet, or SMS).
14. Click Save. The new Payment Server translation for billing is added to the selection list in
the Payment Server Translation window.

Page 36 of 62 Proprietary and Confidential ,

 Appendix
The following Application Notes represent agreements between the Comverse Real time Billing
Division (RTBD) and other Comverse divisions on how to use the Payment Server to charge for
specific Comverse value added services.

4. Application Note: Charging For Fun Dial Services

Fun Dial is a Comverse VAS that allows subscribers to select the ringback tone that will be
heard by callers attempting reach the subscriber. Fun Dial lets subscribers create ringback
tones-for incoming calls using favorite music tracks, sound effects, or self-created messages
mixed with almost any audio content. Different ringback tones may even be configured for
different callers.
Fun Dial is typically not charged by the use. Instead subscribers may be charged a recurring
subscription fee (which could be 0), and are charged every time they purchase a new ringback
tone.
The recurring charge would be handled by existing RTB Periodic Charge (or Recurring Charge
in converged systems), which is performed in a non-real time batch mode.
With regard to charging for ringback tone purchases, the basic requirements are:
ƒ Authorization and charging in real-time – The subscriber should be charged immediately for
provisioning a ringback tone, and should be prevented from provisioning a tone that he
cannot immediately pay for.
ƒ Differentiated charging based on the ringback tone(s) selected, as well as the subscriber’s
chosen subscription. There is no need to differentiate charging based on subscriber’s
location at the time of the ringback tone purchase.
ƒ Full integration into RTB rating and charging capabilities, including support for Usage-
Based Promotions, multiple Balances, flexible charge Units, etc.
ƒ Generation of usage records indicating the date/time, charge, and ringback tone selection.
When using the Comverse Fun Dial VAS, all of these charging capabilities can be supported in
RTB using the existing Payment Server Interface.
The remainder of this document will describe how to use the Payment Server Interface for real-
time charging of Fun Dial ringback tone purchases, including configuration requirements for
both Fun Dial and RTB.

4.1. Subscriber Ringback Tone Purchasing Process

Subscribers manage their Fun Dial Ringback tone provisioning, including the purchasing of new
tones as well as the configuration as to what tones are to be played under what conditions, using
an application supplied as part of Fun Dial.
As the purpose of this document is to describe the charging process, the configuring of what
songs are to be played under what conditions will not be discussed.
With regard to purchasing ringback tones, the basic process is as follows (note that we will
assume the use of a Web-Based Application in this document:

Proprietary and Confidential Page 37 of 62

 1. Subscriber accesses a Fun Dial User Interface Application, and selects a ringback tone to
purchase.

Fun Dial supports multiple user interfaces, including a Web Application, which
will be used in the examples in this document).

2. Before allowing the purchase, the Web Application connects to RTB (via PSI) to have RTB
authorize the purchase
3. RTB calculates the charge for the song.
□ Assuming the subscriber has enough funds and is allowed to purchase the song, RTB
charges the subscriber, and sends back an authorization to Web Application.
□ If the purchase cannot be authorized (due to low funds or subscriber not allowed), RTB
responds by rejecting the purchase attempt, and the Web Application displays a message
indicating a problem.
4. Assuming that the purchase attempt is approved, Fun Dial determines if this is the first purchase
by the subscriber.
5. If this is the first purchase, the Web App updates the HLR to enable Fun Dial services for this
subscriber
□ If there is a failure in the HLR update, the Web App notifies RTB (via Payment Server)
to back-out the charge, and displays a message to the subscriber indicating a problem
6. Assuming no HLR problems, the Web App attempts to complete the song purchase process.
□ If there is an internal failure, the Web App notifies RTB (via Payment Server) to back-
out the charge, and displays a message to the subscriber indicating a problem.
Otherwise, the transaction is successful and the ringback tone is now available for the
subscriber to assign for callers to hear, the subscriber has been charged for the purchase of the
song, and appropriate usage records have been generated for the subscriber’s purchase.
Note that Fun Dial supports the capability to purchase a ringback tone as a “gift” for another
subscriber. That is, subscriber A purchases a ringback tone that subscriber B may provision.
This scenario is similar to the normal purchase scenario with the following differences /
restrictions:
ƒ Both the gift purchaser and the gift recipient must belong to the same operator.
ƒ Both the gift purchaser and the gift recipient must be active Fun Dial users.
ƒ The purchased ringback tone becomes available for the gift recipient to use / provision.
ƒ An SMS is sent to gift recipient to notify him that he has received a ringback tone.

4.2. The High-Level Approach for Charging

The basic approach is to use the real-time charging capabilities of the Payment Server to
support the charging of Fun Dial ringback tones as follows:
ƒ Assign a Price Code to each ringback tone in Fun Dial.
ƒ Use the Payment Server Bearer and Discount fields to uniquely identify the charge to be
taken.

Page 38 of 62 Proprietary and Confidential ,

 □ Populate the Bearer field with unique value to represent a Fun Dial purchase (unique so
as not to interfere with any existing PSI-supported applications like SMS).

Different values may be used to differentiate self purchases from gift purchases.

□ Populate the Discount field with a Price Code that ultimately maps to a specific charge
for that song.
ƒ Populate Payment Server Subscriber Type field with App-MT (meaning that the B-Number
represents the charged party).
ƒ Use Payment Server A-Number field to represent the content selected (Track ID).
□ Prefix the actual Track ID with a unique character sequence to differentiate it from a
“normal” phone number or Application ID.
ƒ Use Payment Server B-Number field to represent subscriber to be charged (Subscriber ID).
ƒ Use other Payment Server fields as per protocol requirements.
Using this approach, the unique combination Bearer and Discount can be mapped to a Fun Dial
ringback tone purchase-specific Application / Subtype / Unit Type triplet, which can then be
mapped to an appropriate Tariff Plan, with appropriate charges.

The unique Application / Subtype / Unit Type triplet allows for a unique Charge
Code (and Service Code in converged systems), so that these charges may be
isolated from other usage in the invoice.

4.3. Message Flows

Message flows for five different scenarios, covering typical successful as well as failure
outcomes are shown below, including:
ƒ Successful purchase of first ringback tone (includes HLR interaction)
ƒ Successful purchase of additional ringback tone
ƒ Successful purchase of a gift ringback tone
ƒ Failed purchase of first ringback tone (HLR-related error)
ƒ Failed purchase of ringback tone (subscriber not authorized)
ƒ Failed purchase of ringback tone (internal error)
Additionally, the specific field use of the Payment Server Apply Tariff message can be found in
Section 4.8.

4.3.1. Successful purchase of first ringback tone (Includes HLR interaction)

This is the typical “first song purchase” scenario. Note that because it is the subscriber’s first
purchase, the subscriber’s profile must be updated on the HLR.

4.3.2. Successful purchase of additional ringback tone

This is the typical “additional song purchase” scenario (which do not require any HLR update).

Proprietary and Confidential Page 39 of 62

4.3.3. Successful purchase of gift ringback tone
This is the typical “gift song purchase” scenario, where subscriber A purchases a ringback tone
for subscriber B. Note that no HLR updates are involved.

4.3.4. Failed purchase of first ringback tone (HLR-related error)

This is a “first song purchase” scenario with a failure due to some sort of problem updating the
HLR. Note that ultimately the charge is backed out from the subscriber due to the inability to
successfully complete all parts of the operation.

4.3.5. Failed purchase of ringback tone (Subscriber not authorized)

This could be a first song or additional purchase attempt that is ultimately rejected because the
subscriber could not make that purchase due to low funds, being in suspended state, etc.

4.3.6. Failed purchase of ringback tone (Internal error)

This could be a first song or additional song purchase that failed due to some internal
processing error. Note that ultimately the charge is backed out from the subscriber due to the
inability to successfully complete all parts of the operation.

4.4. Provisioning

It is assumed that basic provisioning for Fun Dial and RTB has already been
performed, and that both systems are operational.

Provisioning for Fun Dial charging requires some level of synchronization (coordination)
between Fun Dial and the RTB configuration regarding Price Code (attached to each ringback
tone to represent the charge) and the Payment Server Bearer value to be used.
Each is discussed in both the Fun Dial and RTB provisioning sections that follow.

4.4.1. Fun Dial Provisioning

It is assumed that basic Fun Dial provisioning has already been performed, and
that Fun Dial is operational.

The additional Fun Dial provisioning required to support RTB charging involves:
ƒ Assigning Price Codes to each ringback tone available for purchase.
ƒ Provisioning values for the Payment Server Bearer field (one value for regular purchase,
and one for gift purchase).

4.4.1.1. Price Code

The Price Code is an integer value that will be used by RTB to map the transaction to a
particular Application /Subtype, and ultimately a unique charge. In the end the Price Code will
be mapped to the Payment Server Discount field. Values of 0-9999 are supported.

Page 40 of 62 Proprietary and Confidential ,

 For each ringback tone available for purchase, the operator must assign a Price Code.
In this case, a Price Code of 1 could represent Basic, while a value of 2 represents Premium.
The actual values used are not important; it is just a matter of provisioning these values, and
coordinating them with the RTB rating provisioning.

Price Codes are not operator provisionable. Please contact your local Comverse
Support team to arrange to have Price Codes provisioned at Fun Dial.

4.4.1.2. Bearer
Bearer is a Payment Server-specific field used to differentiate charging for different services
and usage. Values of 0 -9999 are supported.
The reason for using this field is to uniquely identify Fun Dial purchases from any other
activity using Payment Server.
So, all that matters is that the value chosen does NOT interfere with any other Bearers
provisioned for RTB Payment Sever use, and that the same value is provisioned in RTB.

Bearer is not operator provisionable. Please contact your local Comverse

Support team to arrange to have the Bearer value provisioned at Fun Dial.

4.4.2. RTB Provisioning

ƒ It is assumed that basic RTB provisioning has already been performed, and that RTB is
operational.
ƒ Screenshots included in this section are from RTB 4.6 UR10. The SAW screens any other
version of RTB may contain some slight difference.
ƒ All provisioning is performed on a future version which is later scheduled to go active.
The additional RTB provisioning required to support Fun Dial charging involves:
ƒ Provisioning of Application, Subtypes, Units, Tariff Plans, and Tariffs for the Fun Dial
charging.
ƒ Provisioning the Payment Server mapping of Bearer and Discount into the desired
Application / Subtype.

4.4.3. Provisioning Example

To illustrate the required provisioning let’s assume the following very simple business case:
ƒ Three available ringback tone tracks:
□ “Operator’s Theme Song” – Free for any subscriber’s use – Track ID = 00000041
□ “Happy Birthday Song” - Basic tone, charged €1.50 – Track ID = 00000062
□ “It’s a Beautiful Day Song” – Premium, charged €2.00 – Track ID = 00000091
ƒ There is no difference in charging for self-purchases vs. gift purchases.

Proprietary and Confidential Page 41 of 62

 ƒ Agreed-upon Bearer Value = 49 for regular purchase, and 48 for a gift purchase, as these do
not interfere with any already used Payment Server Bearer values.
ƒ Agreed upon Price Codes:
□ 1 = No Charge
□ 2 = Basic Charge
□ 3 = Premium Charge
ƒ In RTB, the Application for Fun Dial will be called “Fun Dial”, and the associated Units
will be “Track”.

4.4.3.1. Fun Dial Provisioning

All Fun Dial provisioning is performed by Comverse support personnel.

ƒ Assign Price Code value 1 to “Operator’s Theme Song”, Price Code value 2 to “Happy
Birthday Song”, and Price Code value 3 to “It’s a Beautiful Day Song.”
ƒ Provision Bearer value to 49 for regular purchases, and 48 for gift purchases.

4.4.3.2. RTB Provisioning

All RTB provisioning can be performed by the operator.

1. Define Application and Initial Subtypes for Fun Dial in the SAW Activity Definition
screen.
As shown in Figure 4-1, the following Application / Subtypes have been defined
specifically for Fun Dial charging, each supporting the Units of Track:
ƒ Fun Dial / Free – To be used for Free ringback tones
ƒ Fun Dial / Basic – To be used for Basic ringback tones
ƒ Fun Dial / Premium – To be used for Premium ringback tones

Since there will be no location-based charging for Fun Dial ringback tone
purchases, the Activity Modifier Location should remain unchecked.

Page 42 of 62 Proprietary and Confidential ,

 Figure 4-1 Application Subtypes for Fun Dial

Application / Subtypes for

FunDial ringback tone purchases

Disable Location-
Based Billing for
these Activities

2. Define Final Subtypes for Fun Dial in the SAW Subtype Translation screen.
As shown in Figure 4-2, the Final Subtypes have been defined for each of the Fun Dial
Initial Subtypes.
All Subtype modifiers (Location Relationship, Special Feature, and Access Method
should be configured as NONE).

Figure 4-2 Final Subtypes for Fun Dial

Subtype Translation mapping

of FunDial Initial Subtypes to
Final Subtypes

3. Configure Payment Server mapping of Bearer and Discount to Application and

Subtypes for Fun Dial in the SAW Payment Server Translation screen

Proprietary and Confidential Page 43 of 62

 As shown in Figure 4-3, the combinations of Bearer values for Fun Dial (49 & 48), and
the three different Price Codes (1, 2, and 3), which are passed as Discount values, are
each mapped to an Application of Fun Dial with a different Subtype for each of the
Price Codes (Discount). There is no differentiation between regular purchases and gift
purchases.

Each uses the Units of Track.

Figure 4-3 Bearer Capability and Discount Mapping

Payment Server mapping of Bearer Capability

and Discount to Application / Subtype.

4. Configure Tariffs to be used for Fun Dial charging.

Configure Charge Type as appropriate for downstream processing.
As shown in Figure 4-4, a separate Tariff has been provisioned to be used by each
Application / Final Subtype combination.

Page 44 of 62 Proprietary and Confidential ,

 Figure 4-4 Tariff Definition for Ringback Tones

Define Tariffs for Free, Basic, and

Premium ringback tones

5. Configure Tariff Plans for each of the Fun Dial ringback tone purchases Application /
Subtype combinations in the SAW Tariff Plan screen.
As shown in Figure 4-5, a Tariff has been provisioned for each of the Application /
Subtype combinations.

It is assumed that existing Calendars will be used.

Figure 4-5 Tariff Plan Definition for Ringback Tones

Define Tariffs Plans for Free, Basic,

and Premium ringback tones

Proprietary and Confidential Page 45 of 62

 6. Assign Tariff Plans created above to the Fun Dial Application / Final Subtypes in the
SAW Activity and Tariff Plan screen.
Assign Charge Code, and in converged systems Service Code (not shown here) as
appropriate to meet downstream processing requirements.
As shown in Figure 4-6, a Tariff Plan has been provisioned for each of the Activity /
Subtype combinations.

If the Default Activity box is checked, the Application / Final Subtype pair will
automatically default to being enabled for each COS.

Figure 4-6 Fun Dial Activities Assigned to Tariff Plans

Tariff Plans assigned to

FunDial Application / Final
Subtypes

7. Enable or Disable Fun Dial Application / Final Subtypes in each COS as desired using
the SAW Activity and Tariff Plan screen.

If it is desired to have different charging per COS, this COS Activities tab
Figure 4-7 can be used to assign different Tariff Plans, and /or assign a Discount
Plan to the Fun Dial charging.

Page 46 of 62 Proprietary and Confidential ,

 Figure 4-7 COS Activities Tab

Enable / Disable FunDial Application

Subtypes per COS as desired

8. The Payment Server supports number manipulation (NMS) on the A and B-numbers, as
well as the A and B-location fields.
Since the location fields are not used, we can ignore them.
Typically NMS is used for normalizing the A and B numbers to match the Subscriber ID
format in RTB. This may or may not be required, depending on the configuration of Fun
Dial and RTB.
However, there is another potential use for NMS when supporting Fun Dial charging,
and is related to the Content ID (Track ID) which is passed into RTB as the A-Number.
The potential issue is that the A-Number has a non-numeric prefix (“TR”) followed by
the numeric Track ID.
It is possible that some downstream processing systems may have a problem with an A-
Number containing non-numeric values.
If so, NMS can be used to resolve the issue.
That is, NMS can be configured to modify the A-Number, including removing the
prefix, or modifying the prefix to some numeric value (which can be handled
downstream).
For example, if a Track ID is received as “TR1223345”, NMS can be used to modify
this to “1223345” (remove prefix), or 99991223345 (replace alpha-characters with
numeric characters), or any other programmable manipulation.

4.5. RTB Usage Records

RTB generates two types of usage records for the Fun Dial ringback tone purchases; a PS
Transaction History Record, and a CDR.

4.5.1. History Records

PS Transaction History records are stored in the RTB database. They are available for retrieval
via CCWS, display via CCC, and extraction.

Proprietary and Confidential Page 47 of 62

 A Fun Dial ringback tone purchase history record will look like any other Payment Server
history record, with the following unique characteristics:
ƒ Charge Code – As configured in Activity and Tariff Plan screen
ƒ Message Type – Apply Tariff
ƒ Secondary Subscriber – Track ID
ƒ SubType – Activity Final Subtype as provisioned
ƒ Transaction Type – App-MT
ƒ Type of Charge – As per configuration
ƒ Unit Type – As per configuration (TRACK in the sample provisioning above)
ƒ Usage Amount – As per calculated charge
ƒ Balance Details – Details of Balance change amounts, and values after the charge

For scenarios where the charge is backed out due to some error (refer to the
failure scenarios in sections 4.3.3 and 4.3.6), a second PS Transaction History
record will be generated, showing the credit that was applied when the
transaction was reversed.

This “reversal” history record will look similar to the charge record shown above except:
ƒ The message type will be Reverse Charge
ƒ The Balance changes will be negative values, indicating a credit.

4.5.2. CDRs
Since the fields included in CDRs are configurable on a system-by-system basis, it is difficult
to give a detailed description of the CDRs related to Fun Dial ringback tone purchases.
However, we can make the following statements:
ƒ In general, the CDR will look like a Payment Server CDR for an APP-MT scenario, except
that the A_Number field will contain the Track ID of the tone purchased.
The format of the Track ID will be TRxxxxxxx unless modified with a Number
Manipulation Script, as described in section 4.4.3.2, step 8.
The operator should check to make sure that this will not cause problems with downstream
processing.
ƒ For reversal scenarios, RTB will generate two CDRs; one for the original charge and one
for the reversal (similar to History generation).

Should the operator desire reports on Fun Dial ringback tone purchases, like
number of purchases over a period, total revenue from Fun Dial purchases, etc.,
the CDRs can be used to supply the raw data for the report.

Page 48 of 62 Proprietary and Confidential ,

4.6. Other Charging Considerations
Since the charging for Fun Dial ringback tone purchases is fully integrated into the RTB, all of
the basic and enhanced rating and charging capabilities may be used.
This includes:
ƒ Non-Currency and multiple Balances – A Balance of unit TRACK, allowing for the
awarding of free ringback tones, pre-purchase of ringback tones, packages with allocations
of ringback tones, etc.
ƒ Differentiated charging based on subscriber’s COS.
ƒ Differentiated charging based on date/time of purchase - not typically used for this kind of
content, but nonetheless, available.
ƒ Differentiated charging for gift ringback tones.
Using the above capabilities, the operator may create flexible packages and offerings, as well as
include ringback tones as part of a promotion scheme.
Some possibilities are:
ƒ Package-based offerings – Allowing the subscriber to purchase a package of ringback tones.
For example, “For €5 each month, get five ringback tone downloads”.
ƒ Recharge Promotions - Giving ringback tones as a reward for recharging. For example,
“One free ringback tone download for every recharge over €50”.
ƒ Usage-Based Promotions – Awarding Bonuses or Discounts based on the purchases of Fun
Dial ringback tones, or recharge bonuses of ringback tones. For example, “For every €100
spent on monthly service, receive a free ringback tone download”.
ƒ Different ringback tone price based on service package. For example, “Join the Platinum
Class of Service and pay €1 per ringback tone instead of €1.50.”

4.7. Converged Considerations

In Comverse converged systems, there are some other considerations;
ƒ Provisioning of Service Code
In Comverse converged systems, the Activity and Tariff Plan screen (shown in Section
4.4.3.2 item 6) contains an additional column for Service Code that may be configured for
each row.
This is an essential part of the downstream G/L classification functionality, and must be
provisioned.
ƒ Invoicing considerations
Ultimately,the charges for the Fun Dial ringback tone purchases need to be included on the
customer’s invoice.
The operator must decide how to show these transactions, and if any customization to the
invoice format process is required.

Proprietary and Confidential Page 49 of 62

4.8. Payment Server Apply Tariff Usage
The following table shows how the various Apply Tariff Fields are used is support of Fun Dial
charging.

Table 4-1 Apply Tariff Request Message Usage for Fun Dial Charging
Field Size Type Value / Comments
Length 2 16 bit binary 135 (0087x)
Message ID 1 8 bit binary 1=Request (01x)
Message Type 1 8 bit binary 4=Apply Tariff (04x)
Associated 4 ASCII/binary A value generated by the External Service to
Number uniquely identify this request
Originating Caller 30 ASCII Content Identifier of specific ringback tone
ID purchased, in the form of a Track ID.
Format is TRxxxxxxxx
Where TR indicates that this is a Track ID, and
xxxxxxxx is the specific Track number
For gift purchases, the format is:
TRxxxxxxxxF <recipient MSISDN>
Where F is a configurable delimiter, and
<recipient MSISD> is the subscriber receiving the
gift ringback tone
Orig Subscriber 30 ASCII Not used for Fun Dial purchases…fill with Blanks
MSC Address
Subscriber Type 1 8 bit binary 1=MO to MT
2=Mobile Originating to Application
3=Application to Mobile Terminating
Use 03 for Fun Dial ringback tone purchase
charging
Terminating 30 ASCII Terminating Caller ID or Application ID
Caller ID Subscriber ID of purchaser (sub to be charged)
Terminating Sub 30 ASCII MSC Address / Cell ID of terminating subscriber
MSC Address Not used for Fun Dial purchases…fill with Blanks
Bearer Capability 4 ASCII Allowable values are 0-9999.
The requirements are:
1. This value does not interfere with any other
Payment Server Bearer Capability values already
used
2. Fun Dial and RTB are synchronized and
provisioned to use the same value
Note that different values may be used for regular
vs. gift purchases
Discount 4 ASCII Allowable values: 0-9999
Contains Price Code for the track being purchased.

Page 50 of 62 Proprietary and Confidential ,

5. Application Note: MMS Charging Overview
Together, the Comverse RTB and MMSC products support the real-time authorization and
charging for MMS usage.
In very simplified terms, the authorization and charging is performed as follows:
1. Before allowing a subscriber to send or retrieve an MMS, the MMSC passes
information to RTB regarding the subscriber and the composed MMS, and asks for
“permission” to allow the transaction.
2. RTB takes this information, calculates the potential charge, and then authorizes or
inhibits the transaction based on the subscriber’s current status (service plan, available
funds, status, etc.).
3. If the transaction is allowed, RTB debits the subscriber’s account and authorizes the
MMSC to continue the transaction.
If the transaction is not allowed, RTB responds to the MMSC with a rejection of the
transaction, and the subscriber receives an indication that this action is not permitted.
The actual charge calculation supports many different “dimensions” or types of information that
can be included in determining the actual charge for a particular MMS.
This, in addition to the inherent flexibility of the RTB rating and charging capabilities,
including multiple balances, configurable charge units, and Usage-Based Promotions, gives the
operator numerous ways to charge for, and differentiate charges, for MMS usage.

5.1. Charging for Sending MMSs

For originating (sending) MMS scenarios, the charged party is the originating subscriber.
The following criteria can be used to determine the charge for sending a particular MMS:
ƒ Who: Sending Subscriber’s Service Plan – The Service / Rate Plan assigned to the
subscriber. This enables the operator to charge subscribers in the “Gold” service plan €0.10
per kilobyte of Audio MMSs, while subscribers in the “Platinum” service plan are charged a
flat rate of €0.25 per Audio MMS.
ƒ When: Date/Time of the action. – The Date / Time of the sending of the MMS. This enables
the operator to differentiate the charges for peak vs. off-peak usage.

The Date/Time of the transaction is always based on when RTB receives the
transaction.

ƒ How: How was the message composed/sent? – Was it from the subscriber’s handset or an
application?

Even when the subscriber uses an Application to compose the MMS, it is still
the sending subscriber that is charged.

Proprietary and Confidential Page 51 of 62

 ƒ What: MMS Message Type – Type of MMS (i.e., Audio, Video, Text, etc.). This enables the
operator to charge differently for text MMSs as opposed to video MMSs. Refer to Section
5.12 for a description of how MMS Message Types are determined.
ƒ Where: Sending Subscriber Location – The location of the subscriber sending the MMS
(typically based on the SGSN the subscriber is attached to). This enables the operator to
charge differently based on where the subscriber is when using the service.
ƒ Amount: Volume – Number of bytes in the MMS. This enables the operator to charge more
for a 1-Megabyte attachment than for a 1-Kilobyte attachment. Note that via provisioning,
volume can be ignored so that MMSs are charged per message
ƒ Who / How Recipient: The Type and specific identifier of the intended recipient of the
MMS (i.e., e-mail address, VAS Server, phone number, etc.). These dimensions enable the
operator to charge differently for handset-to-handset MMSs, as opposed to handset to e-
mail MMSs, or differently for an MMS to a subscriber of the same operator as opposed to
an MMS to another operator’s subscriber.
Ultimately any / all of these criteria may be used in any combination to calculate and
differentiate the charge for sending an MMS.
Additionally, RTB Usage-Based Promotions and multiple Balances may be used.
Finally, for MMSs sent to handsets (via a phone number), Friends and Family as well as
Calling Circle discounts may be applied.

5.2. Charging for Retrieving MMSs

For retrieving MMS scenarios, the charged party is the retrieving subscriber.
The following criteria can be used to determine the charge for retrieving a particular MMS;
ƒ Who: Retrieving Subscriber’s Service Plan – The Service / Rate Plan assigned to the
subscriber. This enables the operator to charge subscribers in the “Gold” service plan €0.10
per Kilobyte for retrieving Audio MMSs, while subscriber in the “Platinum” service plan
are charged a flat rate of €0.25 per Audio MMS retrieved.
ƒ When: Date/Time of the action. – The Date / Time of the receiving of the MMS. This
enables the operator to differentiate the charges for peak vs. off-peak usage.

The Date/Time of the transaction is always based on when RTB receives the
transaction.

ƒ What: MMS Message Type – Type of MMS (i.e., Audio, Video, Text, etc.). This enables the
operator to charge differently for text MMSs as opposed to video MMSs. Refer to Section
5.12 for a description of how MMS Message Types are determined.
ƒ Where: Retrieving Subscriber Location – The location of the subscriber retrieving the
MMS (typically based on the SGSN the subscriber is attached to). This enables the operator
to charge differently based on where the subscriber is when using the service
ƒ Amount: Volume – Number of bytes in the MMS. This enables the operator to charge more
for a 1-Megabyte attachment than for a 1-Kilobyte attachment. Note that via provisioning,
volume can be ignored so that MMSs are charged per message.

Page 52 of 62 Proprietary and Confidential ,

 ƒ Who / How Sender: The Type and specific identifier of the sender of the MMS (i.e., VAS
Server, phone number, etc.). This enables the operator to charge differently for retrieving
person-initiated MMS vs. VAS application-initiated MMSs.
Ultimately any / all of these criteria may be used in any combination to calculate and
differentiate the charge for retrieving an MMS.
Additionally, RTB Usage-Based Promotions and multiple Balances may be used.
Finally, for retrieved MMSs sent by a subscriber (as opposed to a VAS), Friends and Family
as well as Calling Circle discounts may be applied.

5.3. Scenario 1: Person-To-Person (Via Handset)

A subscriber, using his handset to compose the message, sends an MMS to another person.

5.3.1. Business Scenario

This is the basic originating MMS scenario, where a subscriber composes and sends an MMS
from his handset to another person (as opposed to an application). Note that the “address” of
this person could be a phone number or an e-mail address.
In this scenario, only the sending subscriber will be charged.

5.3.2. Usage Scenario

The subscriber on the network composes and sends an MMS to another person.
The MMS may contain one or more attachments of various types (refer to Section 5.11 for list
of attachment types) or it may contain no attachments (although this is not very common).
Some examples of potential uses are:
ƒ Subscriber sends vacation pictures (taken from camera phone) to relatives.
ƒ Subscriber sends video highlights (received from his sports subscription) of local team to
friends
ƒ Subscriber sends quick message with no attachments to inform spouse that he will be late
(i.e., Send “Roads congested, will be home at 5” in subject field of empty MMS).

5.3.3. Charging Scenario

Originating subscriber is charged based on any combination of the following:
ƒ Subscription – What service plan and rates the subscriber has agreed to
ƒ Date/Time of sending attempt – When is the action occurring (i.e., peak, off-peak)
ƒ Sending Location – Where the subscriber is when sending the MMS.
ƒ Type of attachments – What type(s) of files have been attached
ƒ Volume (number of bytes in MMS) – Total size of message
ƒ Destination Address (phone number or e-mail) – Who is the recipient, and what type of
address is it (i.e., local phone number, international phone number, e-mail address)

Proprietary and Confidential Page 53 of 62

 Note that Friends and Family, Group, and/or Calling Circle differentiated tariffing may be
applied if destination address is a phone number.
Additionally, Usage-Based Discounts and Promotions may be used as well.

5.4. Scenario 2: Person-to-VAS Application (Via Handset)

A subscriber, using his handset to compose the message, sends an MMS to a VAS Application.

5.4.1. Business Scenario

Subscribers may subscribe to Value Added Services (VAS) for a variety of business and
personal needs.
VAS may include things like:
ƒ News / weather / sports alerts
ƒ Stock quotes
ƒ Movie reviews and snippets
ƒ Picture sharing
Typically VASs “push” content to the subscribers (although ultimately the subscriber must
perform an action to retrieve it).
So subscribers sending MMSs to VASs is typically used for registration and/or configuration
purposes, and sending content to be shared among a group.
In this scenario, only the sending subscriber may be charged, although often times this type of
MMS is not charged at all (unless the sending subscriber is roaming).

5.4.2. Usage Scenario

The subscriber composes and sends an MMS to a VAS (typically a short-code)..
The MMS may contain one or more attachments.
Some examples of potential uses are:
ƒ Subscriber registers for stock quotes, indicating the particular stocks to monitor
ƒ Subscriber registers for sport video clips, indicating his favorite teams
ƒ Subscriber uploads picture into a shared photo album

5.4.3. Charging Scenario

Originating subscriber is charged based on any combination of the following:
ƒ Subscription – What service plan and rates the subscriber has agreed to
ƒ Date/Time of sending attempt – When is the action occurring (i.e., peak, off-peak)
ƒ Sending Location – Where the subscriber is when sending the MMS.
ƒ Type of attachments – What type(s) of files have been attached
ƒ Volume (number of bytes in MMS) – Total size of message

Page 54 of 62 Proprietary and Confidential ,

 ƒ Destination Address (VAS short code) – Who is the recipient. In this case, the “who” is a
VAS)

Friends and Family, Group, and/or Calling Circle differentiated tariffing may be
applied if destination address is a phone number.

Additionally, Usage-Based Discounts and Promotions may be used as well.

While all of these charging variations are supported, typically the sending of an MMS to a VAS
service is solely charged based on the VAS to which the MMS is sent (and is typically free)
unless the sending subscriber is roaming (to cover roaming access charges).

5.5. Scenario 3: Person-to-Person (Via Application)

A subscriber, using an Application to compose the message, sends an MMS to another person.

5.5.1. Business Scenario

This is much like Scenario 1, except that the subscriber is using an application (typically a Web
application) to compose and send the MMS (instead of the handset).
Applications could be made available on the Internet, or from specific application terminals,
like a Kiosk in a shopping center.
Like Scenario 1, only the sending subscriber will be charged.
The major differences between this and handset-initiated MMSs are:
ƒ There is no location information for the sending subscriber, so charging cannot be
differentiated by subscriber location.
ƒ Any attachments included will come from a computer or an application, instead of a
handset.
ƒ Charging can be differentiated (if desired by the operator) based on the fact that the
subscriber is using an application.

5.5.2. Usage Scenario

The subscriber (1234567), using a Web application, composes and sends an MMS to another
person.
The MMS may contain one or more attachments of various types (refer to Section 5.11 for list
of attachment types) or it may contain no attachments (although this is not very common).
Some examples of potential uses are:
ƒ Subscriber sends vacation pictures (stored on local computer) to relatives.
ƒ Subscriber sends video highlights (received from his sports subscription) of local team to
friends.

5.5.3. Charging Scenario

Basically this is charged just like a subscriber sending the MMS from his handset except:

Proprietary and Confidential Page 55 of 62

 ƒ The charging can be differentiated based on the fact the subscriber is using an application.
ƒ The charging cannot be differentiated by sending subscriber location (as it is not known).
Originating subscriber is charged based on any combination of the following:
ƒ Subscription – What service plan and rates the subscriber has agreed to.
ƒ Date/Time of sending attempt – When is the action occurring (i.e., peak, off-peak)
ƒ Sending Location – Not supported. However the fact that an application is being used can
be used to differentiate rating.
ƒ Type of attachments – What type(s) of files have been attached?
ƒ Volume (number of bytes in MMS) – Total size of message
ƒ Destination Address (phone number or e-mail) – Who is the recipient, and what type of
address is it (i.e., local phone number, international phone number, e-mail address)?
Note that Friends and Family, Group, and/or Calling Circle differentiated tariffing may be
applied if destination address is a phone number.
Additionally, Usage-Based Discounts and Promotions may be used as well.

5.6. Scenario 4: Person-To-VAS Application (Via Application) – Future

Support
A subscriber, using an Application to compose the message, sends an MMS to a VAS
Application.

This scenario is not currently supported.

5.6.1. Business Scenario

This is much like Scenario 2, except that the subscriber is using an application (typically a Web
application) to compose and send the MMS (instead of the handset).
Applications could be made available on the Internet, or on specific application terminals, like
Kiosks in a shopping center.
Like Scenario 2, only the sending subscriber will be charged.
The major differences between this and handset-initiated MMSs are:
ƒ There is no location differentiating for the sending subscriber.
ƒ Any attachments included will come from a computer or an application, instead of a handset
ƒ Charging can be different (if desired by the operator) based on the fact that the subscriber is
using an application.

5.6.2. Usage Scenario

The subscriber (1234567), using an application, composes and sends an MMS to a VAS
(typically a short-code).
The MMS may contain one or more attachments.

Page 56 of 62 Proprietary and Confidential ,

 Some examples of potential uses are:
ƒ Subscriber registers for stock quotes, indicating the particular stocks to monitor.
ƒ Subscriber registers for sport video clips, indicating his favorite teams.

5.6.3. Charging Scenario

Originating subscriber is charged based on any combination of the following:
ƒ Subscription – What service plan and rates the subscriber has agreed to.
ƒ Date/Time of sending attempt – When is the action occurring (i.e., peak, off-peak)?
ƒ Sending Location – Not supported. However the fact that an application is being used can
be used to differentiate rating:
ƒ Type of attachments – What type(s) of files have been attached?
ƒ Volume (number of bytes in MMS) – Total size of message
ƒ Destination Address (VAS short code) – Who is the recipient? In this case, the “who” is a
VAS).

Friends and Family, Group, and/or Calling Circle differentiated tariffing may be
applied if destination address is a phone number.

Additionally, Usage-Based Discounts and Promotions may be used as well.

While all of these charging variations are supported, typically the sending of an MMS to a VAS
service is solely charged based on the VAS to which the MMS is sent. Typically there is no
charge for this unless the sending subscriber is roaming (to cover roaming access charges).
An example of a potential charging scenario is shown below. Note that this is just one of the
many possible variations of charging schemes.

Any combination of the examples below can be supported:

ƒ MMSs to the Stock Quote VAS cost 0.10. MMS to all other VASs are free.

5.7. Scenario 5: Retrieval of MMS (From Person)

A subscriber retrieves an MMS sent by another person, either directly from a handset or via an
Application.

5.7.1. Business Scenario

This is the basic originating MMS retrieval scenario, where a subscriber retrieves an MMS from
the MMS server.
The reason for differentiating MMSs from another person vs. an MMS from a VAS Application
is that operators typically do NOT charge for the retrieval of MMSs from another person unless
the retrieving subscriber is roaming (to cover roaming access charges).
In this scenario, only the retrieving subscriber will be charged.

Proprietary and Confidential Page 57 of 62

5.7.2. Usage Scenario
The subscriber retrieves an MMS (sent by another person) from the MMS server.
The MMS may contain one or more attachments of various types (refer to Section 5.11 for list
of attachment types) or it may contain no attachments (although this is not very common).
Some examples of potential uses are:
ƒ Receipt of vacation pictures (taken from camera phone) sent by traveling relative.
ƒ Receipt of video highlights of local team sent by friend.
ƒ Receipt of quick message with no attachments from spouse indicating that he/she will be
late (i.e., Receipt of MMS with “Roads congested, will be home at 5” in subject field of
empty MMS).

5.7.3. Charging Scenario

Receiving subscriber can be charged based on any combination of the following (typically
subscribers are only charged when roaming, but virtually any other charging scenario can be
supported):
ƒ Subscription – What service plan and rates the subscriber has agreed to.
ƒ Date/Time of receipt – When is the action occurring (i.e., peak, off-peak)?
ƒ Receiving Location – Where is the subscriber when retrieving the MMS.
ƒ Type of attachments – What type(s) of files have been attached?
ƒ Volume (number of bytes in MMS) – Total size of message.
ƒ Origination Address (phone number) – Who is the sender?
Note that Friends and Family, Group, and/or Calling Circle differentiated tariffing may be
applied if sending address is a phone number.
Additionally, Usage-Based Discounts and Promotions may be used as well.

5.8. Scenario 6: Retrieval of MMS (From VAS Application)

A subscriber retrieves an MMS sent by a VAS Application.

5.8.1. Business Scenario

This is the basic MMS retrieval scenario, where a subscriber retrieves an MMS sent by a VAS
Application.
The reason for differentiating MMSs from another person vs. an MMS from a VAS Application
is that operators typically do NOT charge for the retrieval of MMSs from another person unless
the retrieving subscriber is roaming (to cover roaming access charges).
In this scenario, only the retrieving subscriber will be charged.

5.8.2. Usage Scenario

The subscriber retrieves an MMS (sent by a VAS) from the MMS server.

Page 58 of 62 Proprietary and Confidential ,

 The MMS may contain one or more attachments of various types (refer to Section 5.11 for list
of attachment types) or it may contain no attachments (although this is not very common).
Some examples of potential uses are:
ƒ Receipt of stock quote
ƒ Receipt of video highlights of local team

5.8.3. Charging Scenario

Receiving subscriber can be charged based on any combination of the following:
ƒ Subscription – What service plan and rates the subscriber has agreed to.
ƒ Date/Time of receipt – When is the action occurring (i.e., peak, off-peak)?
ƒ Receiving Location – Where is the subscriber when retrieving the MMS?
ƒ Type of attachments – What type(s) of files have been attached?
ƒ Volume (number of bytes in MMS) – Total size of message.
ƒ Origination Address (VAS Application ID) – Sending VAS.

Friends and Family, Group, and/or Calling Circle differentiated tariffing may
NOT be applied.

Additionally, Usage-Based Discounts and Promotions may be used.

5.9. Scenario 7: Retrieval of MMS (From E-mail)

A subscriber retrieves an MMS sent by an e-mail Application.

5.9.1. Business Scenario

This is the basic MMS retrieval scenario, where a subscriber retrieves an MMS sent by an e-
mail Application.
The reason for differentiating MMSs from e-mail vs. an MMS from a VAS Application is that
the operators may want to charge differently for this.
In this scenario, only the retrieving subscriber will be charged.

5.9.2. Usage Scenario

The subscriber retrieves an MMS (sent from an e-mail application) from the MMS server.
The MMS may contain one or more attachments of various types (refer to Section 5.11 for list
of attachment types) or it may contain no attachments (although this is not very common).

5.9.3. Charging Scenario

Receiving subscriber can be charged based on any combination of the following:
ƒ Subscription – What service plan and rates the subscriber has agreed to.

Proprietary and Confidential Page 59 of 62

 ƒ Date/Time of receipt – When is the action occurring (i.e., peak, off-peak)?
ƒ Receiving Location – Where is the subscriber when retrieving the MMS?
ƒ Type of attachments – What type(s) of files have been attached?
ƒ Volume (number of bytes in MMS) – Total size of message.
ƒ Origination Address (VAS Application ID) – Sending VAS.

Friends and Family, Group, and/or Calling Circle differentiated tariffing may
NOT be applied.

Additionally, Usage-Based Discounts and Promotions may be used.

5.10. Param1 & Param2 (in CDR only) MMS Message Types Overview
One of the charging dimensions for MMS involves the type of attachments.
The way it influences the charging is as follows:
ƒ Each MMS attachment is classified by Attachment Type. Supported Attachment Types are
shown in section 5.11 below.
ƒ Based on the attachment types, the MMS is classified with a Message Type. Supported
Message Types, along with the rules for mapping Attachment Types to Message Types are
shown in section 5.12 below.
ƒ The MMS Message Type is passed through to RTB to be available as one of the components
for charging each MMS.

5.11. MMS File/Attachment Types

The following Attachment Types are defined:
ƒ Image – Any attachment with content type “image/*“ (the sub type is not important) or a
file with the following extensions: GIF, JPG, JPEG, BMP, WBMP, TIFF, MNG and PNG.
ƒ Audio – Any attachment with content type “audio/*“ (the sub type is not important) or a file
with the following extensions: WAV, MP3, MIDI, AMR, EVRC, AAC, QCELP and SBC.
ƒ Ringtone – Any attachment with content type “text/x-imelody” or “text/x-emelody” or a
file with the following extensions: IMY, EMY.
ƒ Video – Any attachment with content type “video/*“ (the sub type is not important) or a file
with the following extensions: MPEG, MPG, AVI, ASF, 3GP, MP4, QT, MOV, MP2V,
MPV2 and WMV.
ƒ Text – Any attachment with content type text/plain, text/html or application/smil, or a file
with one of the following extensions: TXT, TEXT, HTML, HTM, SMI, SML, SMIL.
ƒ DRM – Any attachment with content type application/vnd.oma.drm.message or
application/vnd.oma.drm.rights+xml.

Page 60 of 62 Proprietary and Confidential ,

5.12. MMS Message Types
The MMS will support the following Message Types. Attachment Types referred to here are
defined above.
ƒ Picture_message - A message with one or more image attachments and optionally one or
more text attachments.
ƒ Audio_message - A message with one or more audio attachments and optionally one or
more text attachments.
ƒ Video_message - A message with one or more video attachments and optionally one or
more text attachments.
ƒ Text_message - A message with one or more text attachments.
ƒ Ringtone_message - A message with one or more ringtone attachments and optionally one
or more text attachments.
ƒ Empty_message – Message with no content. No content means NULL content or empty
string (“”) content.
ƒ Multimedia_message – Any message that is not one of the above (i.e., message with either
unrecognized attachment or multiple attachments from different types).
ƒ DRM_message – Message that contains at least one DRM attachment (in addition to other
any other attachments).

5.13. Payment Server Bearer and Discount Fields

5.13.1. Bearer Capability Values

The following table contains the Bearer Values used in Payment Server support for MMS
charging:

Proprietary and Confidential Page 61 of 62

 Table 5-1 Payment Server MMS Bearer Capability Values
Value Description
101 Handset to Handset
102 Handset to VAS
103 Handset to E-mail
104 Subscriber App to Handset (Send on Behalf Of to Handset)
105 Subscriber App to E-mail (Send on Behalf Of to E-mail))
106 (Reserved for Future Use) Subscriber App to VAS (Send on Behalf Of to VAS)
107 VAS to Handset
108 E-mail to Handset

5.13.2. Discount Values

The following table contains the Discount values used in Payment Server support for MMS
charging.

There is a 1:1 mapping of MMS Message Types to Discount values

Table 5-2 Payment Server MMS Discount Values

Value Description (MMS Type)
101 Picture
102 Audio
103 Video
104 Text
105 Ringtone
106 Multimedia
107 Empty
108 DRM

Page 62 of 62 Proprietary and Confidential ,