NSN in@Vantage

Copyright 2007 Nokia Siemens Networks Page 1 All rights reserved

Nokia Siemens Networks IN@PLATOP – Part 1 Course Documentation 2007

IN@PLATOP (Part 1)

Page 2 Copyright 2007 Nokia Siemens Networks All rights reserved

Training Center for Charging & Care

Responsible: Helmut Löffler Nokia Siemens Networks Phone: +49 89 636 50292 email: [email protected]

Version: 14 May 2007

Technical modifications are possible. Technical specifications and features are binding only insofar as they are specifically and expressly agreed upon in a written contract. The software and hardware names used in this document are registered trademarks and are thus subject to the legal provisions thereof.

The reproduction, transmission or use of this document or its contents is not permitted without express written authority. Offenders will be liable for damages. All rights, including rights created by patent grant or registrations of a utility model or design, are reserved.

IN@PLATOP (Part 1) Content


Content 1. Product Structure..........................................................................................1-6

2. IN@vantage ...................................................................................................2-8 2.1 IN@vantage Integration ..................................................................................2-8 2.2 Overview of IN Services................................................................................2-10 2.3 Number Translation Services........................................................................2-12 2.3.1 Freephone.....................................................................................................2-12 2.3.2 Premium Rate ...............................................................................................2-14 2.3.3 Universal Access Number.............................................................................2-16 2.4 Multi SIM .......................................................................................................2-18 2.5 VPN...............................................................................................................2-22 2.5.1 Private Numbering Plan ................................................................................2-24 2.5.2 Member Types ..............................................................................................2-24 2.5.3 Call Types .....................................................................................................2-26 2.6 Mobile Centrex ..............................................................................................2-28 2.6.1 Mobile Centrex Use Case .............................................................................2-28 2.6.2 Architecture Overview...................................................................................2-30 2.6.3 Key Features of Mobile Centrex....................................................................2-32 2.6.4 Mobile Centrex like a Virtual PBX .................................................................2-34 2.6.5 Switchboard Functionality provided by SWAT ..............................................2-36 2.6.6 MCX Client: User Admin ...............................................................................2-38 2.6.7 Example 1: Small Company in the plumbing business .................................2-40 2.6.8 Example 2: Insurance Agency ......................................................................2-41 2.7 Railway@vantage .........................................................................................2-42 2.8 Functional Blocks of IN@vantage.................................................................2-50

3. Prepaid@vantage........................................................................................3-52 3.1 What is Prepaid@vantage ............................................................................3-52 3.2 Integration of Prepaid@vantage ...................................................................3-54 3.3 Prepaid Service.............................................................................................3-56 3.3.1 How to invoke the Prepaid Service ...............................................................3-56 3.3.1.1 Originating Calls............................................................................................3-56 3.3.1.2 Terminating Calls ..........................................................................................3-58 3.3.1.3 Recharging Overview....................................................................................3-60 3.3.1.3.1 Voucher Recharging by DTMF......................................................................3-62 3.3.2 Use Cases.....................................................................................................3-64 3.3.2.1 Online-charged Voice Calls from Fixed Network – SINAP............................3-64 3.3.2.2 Online-charged Voice Calls from Abroad – MOC CAP 2 ..............................3-66 3.3.2.3 SS7 Event Charging: SMS from Abroad .......................................................3-68 3.4 Functional Blocks Prepaid@vantage ............................................................3-70

4. Charging@vantage .....................................................................................4-73 4.1 Network Embedding of Charging@vantage..................................................4-74 4.2 Features of Charging@vantage....................................................................4-76 4.2.1 CORBA Communication to Payment Plug-in on Application Server.............4-76 4.2.2 Advice of Charge...........................................................................................4-76 4.2.3 Balancing ......................................................................................................4-76 4.2.3.1 Real-time Account Supervision .....................................................................4-76 4.2.3.2 Support of Prepaid Accounts on Dedicated Systems ...................................4-78 4.2.3.3 Support of Online Credit Limit Supervision for Postpaid Subscribers ...........4-78 4.2.4 HotBilling Support .........................................................................................4-79 4.3 Charging@vantage Charging Scenarios ......................................................4-80

Content IN@PLATOP (Part 1)

Page 4 Copyright 2007 Nokia Siemens Networks All rights reserved

4.3.1 IP Event Charging.........................................................................................4-82 4.3.1.1 SMS-MO Event Charging with Reservation ..................................................4-82 4.3.1.2 HTTP Content Charging via Web/WAP Proxy ..............................................4-84 4.3.1.3 MMS Submission IP Event Charging ............................................................4-86 4.3.2 IP Session Charging .....................................................................................4-88 4.3.2.1 IP Session Charging based on RADIUS (Pre-RO) .......................................4-88 4.3.2.2 IP Session Charging via SSG .......................................................................4-90 4.4 IN and Mobile Data Services.........................................................................4-92 4.5 Functional Blocks of Charging@vantage......................................................4-94

5. charge@once ..............................................................................................5-97 5.1 Functional Blocks of charge@once ..............................................................5-98 5.2 Integration of charge@once........................................................................5-100 5.3 Features of charge@once ..........................................................................5-102 5.4 Interfaces of charge@once.........................................................................5-103 5.4.1 CAP-based Interfaces.................................................................................5-103 5.4.2 IP-based Interfaces – Payment PlugIn........................................................5-103 5.4.3 IP-based Interfaces – Online Interfaces......................................................5-104 5.5 Use Cases...................................................................................................5-105 5.5.1 CAMEL-based Charging .............................................................................5-106 5.5.1.1 Charging of Circuit-switched (CS) Traffic....................................................5-106 5.5.1.2 SS7 Session Charging in PO Domain.........................................................5-108 5.5.1.3 SS7 Event Charging in CS Domain: SMS-MO............................................5-110 5.5.1.4 IP Session Charging in PO Domain via SSG..............................................5-112 5.5.2 IP Charging Scenarios ................................................................................5-112 5.5.2.1 HTTP Content Charging via Web/WAP Proxy ............................................5-114 5.5.2.2 Hotbilling for IP Applications (Content) .......................................................5-116

6. Flexible Rating...........................................................................................6-118 6.1 Tariff Examples ...........................................................................................6-119 6.2 General Principles of Rating .......................................................................6-125 6.3 Architecture and Dataflow...........................................................................6-126 6.4 Enhancements in V7.6 ................................................................................6-139

7. Service Creation Environment.................................................................7-141 7.1 Introduction .................................................................................................7-141 7.2 Architecture.................................................................................................7-142

8. @vantage Platform ...................................................................................8-144 8.1 Software Architecture..................................................................................8-146 8.2 Hardware Architecture ................................................................................8-148 8.3 Cluster Architecture.....................................................................................8-150 8.4 Functionality of TSP7000............................................................................8-152

9. Operation and Maintenance .....................................................................9-154 9.1 Introduction .................................................................................................9-154 9.2 Interfaces ....................................................................................................9-156 9.3 Fault Management ......................................................................................9-158 9.3.1 Architecture.................................................................................................9-158 9.3.2 Fault Management GUI...............................................................................9-160 9.3.3 @vantage Commander Configuration Management GUI ...........................9-162 9.4 Performance Monitoring..............................................................................9-166 9.4.1 Architecture.................................................................................................9-166 9.4.2 Performance Monitoring GUI ......................................................................9-168

IN@PLATOP (Part 1) Content


9.5 Security Management .................................................................................9-170

10. Disaster Recovery...................................................................................10-172 10.1 Architecture / Solution Summary...............................................................10-172 10.2 Detailed Description..................................................................................10-174

11. SMAF........................................................................................................11-177 11.1 Introduction ...............................................................................................11-177 11.2 Function Split ............................................................................................11-177 11.3 Service Management Application..............................................................11-180 11.3.1 Service Management Login Screen..........................................................11-180 11.3.2 Service Data Administration......................................................................11-180

12. Ticketing ..................................................................................................12-183 12.1 Introduction ...............................................................................................12-184 12.2 Phases of Ticket Handling ........................................................................12-186 12.3 Ticket Formatting ......................................................................................12-188 12.4 Ticket Scenarios........................................................................................12-190

Product Structure IN@PLATOP (Part 1)

Page 1-6 Copyright 2007 Nokia Siemens Networks All rights reserved

1. Product Structure Various products are offered on basis of the Siemens @vantage platform.

IN@vantage SS7 handling Mobile and Fixed Networks Example Intelligent Services: −− Number Translation Services NTS −− Virtual Private Network Services VPN −− Mobile Centrex

Prepaid@vantage SS7 handling Mobile and Fixed Networks Example Intelligent Service: −− Prepaid Service PPS

Charging@vantage IP charging Session and Event Charging

charge@once Combination of Charging@vantage and Prepaid@vantage SS7 charging and IP charging Mobile, Fixed Networks and IP networks Session and Event Charging

SS7 ............ Signaling System #7 IP................ Internet Protocol NTS ............ Number Translation Service PPS ............ Prepaid Service VPN............ Virtual Private Network

IN@PLATOP (Part 1) Product Structure

Copyright 2007 Nokia Siemens Networks Page 1-7 All rights reserved

1-2 © Nokia Siemens Networks Introduction / Training Center / 2007

Product Structure

IN@vantageSS7 handlingMobile and fixed networksExample Intelligent Services- Number Translation Services NTS- Virtual Private Network Services VPN- Mobile Centrex

Prepaid@vantageSS7 handlingMobile and fixed networksPrepaid Service PPS

Charging@vantageIP chargingSession and event charging

charge@onceCombination of Charging@vantage and Prepaid@vantageSS7 charging and IP chargingMobile, fixed networks and IP networksSession and event charging

Notes

IN@vantage IN@PLATOP (Part 1)


2. IN@vantage In this chapter, the following topics will be covered:

IN@vantage Integration IN@vantage Services IN Call Handling concept IN@vantage Features IN@vantage Components

2.1 IN@vantage Integration

IN@vantage is a computer-based system that interworks with the basic Telco network. It is integrated into an existing communication network to provide centralized services. These services (e.g. Virtual Private Network, Mobile Centrex, Multi SIM, Freephone) can be made available to a customer for specific applications.

The functionality provided by an IN system are described in the ITU recommendations Q12xx (e. g. Q1201, Q1221).

BSC............ Base Station Controller HLR............ Home Location Register INAP........... Intelligent Network Application Part ITU ............. International Telecommunication Union MAP ........... Mobile Application Part MSC ........... Mobile Switching Center MSSP ......... Mobile Service Switching Point SSP ............ Service Switching Point Telco.......... Telecommunication

IN@PLATOP (Part 1) IN@vantage



Integration of IN@vantage

MSC (SSP)

HLR

MSC (SSP)

BSC BSC Base-station

Base-station

IN@vantage

SSP

Notes



2.2 Overview of IN Services

In the following subchapters the services are described:

Number Translation Service Multi SIM Virtual Private Network Mobile Centrex Railway@vantage

ACD ........... Automatic Call Distribution IRI............... Interception Related Information LEA ............ Law Enforcement Agency LI ................ Lawful Interception NTS ............ Number Translation Service SIM............. Subscriber Identity Module VPN............ Virtual Private Network




Services of IN@vantage

Number Translation ServiceMulti SIMVirtual Private NetworkMobile CentrexRailway@vantage

Notes



2.3 Number Translation Services

NTS services determine new destination numbers for Called Party Addresses. They can handle screening as well as charging aspects of calls. Various variants of NTS services are possible:

Freephone Premium Rate / Info Service (Weather, Sports, Events, Consulting...) Split / Reversed Charging Ordering / Booking Services (Warehouse, Travel, Ticketing...) Call Center Service Universal Access Number Group Hunting

2.3.1 Freephone

The user of the Freephone service dials a number which is then translated to a certain destination number, depending on the time or the location the call was initiated or the load situation of the subscriber. Most of the time, it is not the user that is charged for the call, but rather the subscriber (such as a reservation hotline).

FPH ............ Freephone NTS ............ Number Translation Service UAN ........... Universal Access Number




Number Translation Service:Freephone Service

Main FeaturesSingle numberReverse chargingCall forwarding on busy/no answerTime-dependent routingOrigin-dependent routingCall distributionSubscriber-specific announcementAuthentication

Operator BenefitsCall completionSegment-specific service variants

User BenefitsCall free of chargeLow barrier to place call

Subscriber BenefitsAttracts calls: advertising/ business opportunitiesCall completionBilling control

A B

IN

0800 4567022 84599030 33445

040 77445x

Typical Use CasesService HotlineReservation HotlineInformation Hotline:

Notes



2.3.2 Premium Rate

The user of the Premium Rate service dials a number which is then routed to a certain information center (like weather forecast or sports results). It is the user that is typically charged for the call plus a specific fee for the benefit of the information. The routing of the call to a destination number could depend on the time the call was made or the location from which the call was initiated. It is also possible to route a call depending on a selection code entered by the user. Announcements can be played to ask questions or to inform the user.

PRM ........... Premium Rate




Number Translation Service:Premium Rate Service

Operator BenefitsParticipation in new business opportunitiesAdditional traffic

User BenefitsUbiquitous / convenient access to information

Subscriber BenefitsRevenue by premium chargeOperator collects chargesNew sales channels

Typical Use CasesLocation-specific InformationWeather ForecastSports ResultsHoroscope:

0900 -700700Weather Forecast

Hamburg

INWeather Forecast

Munich Main FeaturesPremium rate chargingTime-dependent routingOrigin-dependent routingSelection code-dep. routingAnnouncement

Notes



2.3.3 Universal Access Number

The user of the Universal Access Number service dials a single number which is then translated to a certain destination number, depending on the time the call was made or the location from which the call was initiated, or the load situation of the subscriber. The fee for the call could be split for both, the user and the subscriber. If the destination is busy or no answer, the call could be rerouted to another destination.




Number Translation Service:Universal Access Number Service

Operator BenefitsCall completionSegment-specific service variants

User BenefitsSingle numberEasy to remember

Subscriber BenefitsAttractive tariff optionOptimized call distribution 24/7One number for multiple locations

Main FeaturesSingle numberSplit chargingCall forwarding on busy/no answerTime-dependent routingOrigin-dependent routingSelection code-dep. routingCall distributionSubscriber-specific announcement

Typical Use CasesBooking, Ordering ServiceMail Order BusinessTicket Line:

Notes



2.4 Multi SIM

MultiSIM@vantage (also referred to as parallel ringing) is a solution for users who regularly use multiple mobile phones, as, e.g., business mobile, private mobile, car phone, PDA, notebook. By using MultiSIM@vantage, the user can answer incoming calls from either of his terminals as they all ring at the same time. The user can establish outgoing calls from either of his phones. Although there are several SIM cards in the different devices, only one unique phone number appears.

ACD ........... Automatic Call Distribution CLI ............. Calling Line Identity CPH............ Call Party Handling (Function of SINAP7m for Leg Management) MSISDN ..... Mobile Station ISDN PAC............ Prompt And Collect PDA............ Personal Digital Assistant SIM............. Subscriber Identity Module SINAP ........ Siemens Intelligent Network Application Part




MultiSIM@vantage - Motivation

Convenience Service for business customers with several mobilesCar phoneBusiness mobilePrivate mobilePDA / Notebook

Targeted at users who need to be reachable at all times, but do not want to carry all phones at once – typical target customers are e.g.

LawyersDoctors on callSecurity GuardsConstructorsPhysiciansFarmers


MultiSIM@vantage - Solution Overview

MultiSIM@vantage provides support for

Several independent SIM cards, one phone numberOne primary MSISDNSeveral secondary MSISDN (in general, max. 2 secondary MSISDNs)

IN-based call party handling and connection for terminating calls Can be supported from IN@vantage V7 onwards (CPH, SINAP7m)Switched based parallel ringing feature available with SR9

IN-based handling of originating calls (outgoing calls)Unique A-number presentation independent from which SIM the originating call is set up (for CLI presentation, statistics, tickets)






Incoming calls are directed to all registered phones at the same time (parallel ringing, no hunting).User can answer the call with any of the registered phones.Outgoing calls can be established from any of the phones.Although several SIM cards in different devices are used, they appear as one unique phone number to the outside world.

MultiSIM@vantage - One Phone Number, Parallel RingingExample: User has a business mobile, a private mobile and a mobile in his car

MSISDN1 MSISDN3

One Phone Number

MSISDN2

Notes



2.5 VPN

A VPN service provides the creation of a private or corporate network by using public network infrastructure. The service users may access the VPN service via mobile and fixed network (single lines or PBX), and via PBXs connected directly to the switching system. The service logic for the VPN and the VPN database are located within an IN system. SS7 connections are used between the IN and the SSPs. The service provider creates a VPN for a service subscriber (specified by a VPN-ID). The service subscriber may represent a large company or a group of people. The service subscriber manages users in this VPN with the advantage of a private network and a huge set of available features. VPN service ensures optimal network reliability. The ability to take advantage of network operator resources and redundant elements guarantees significant increases in network availability. A VPN establishes a company-wide communication network for telephone, fax and data by using the public infrastructure of the PLMN and IN@vantage. The users of a VPN are offered the ease of in-house networks between:

Different users of the VPN Different sites of the company Different companies with a VPN of their own Other companies operating in close cooperation

VPN............ Virtual Private Network PABX ......... Private Automatic Branch Exchange PBX............ Private Branch Exchange PLMN ......... Public Land Mobile Network SS7 ............ Signaling System #7 SSP ............ Service Switching Point VPN............ Virtual Private Network




VPN@vantage

Main FeaturesPrivate numbering planAbbreviated dialing (short codes)On-net/off-net call type variationsFlexible charging optionsScreening, BarringClosed User Group

Typical Use CasesCustomer-specific networks within and across PLMNMay include corporate networks

Constructioncompany

Constructor

On Site

VPN@vantagePABX

Public network

PLMN

Operator BenefitsFlexible tariff offeringsCost reduction due to usage of core networks resources

Subscriber BenefitsOutsourcing of private network resources to operatorCentralized administrationFlexible teaming of VPN members Individual tariff options

User BenefitsNo call charges, no pre-paying for calls via the VPNComfort of dialing short numbersScreening of calls

Notes



2.5.1 Private Numbering Plan

The Private Numbering Plan (PNP) is one of the basic features of the VPN service. The PNP can be designed separately from the public numbering plan.

Private and public numbers:

The Private Number (PN) is a virtual directory number specified in the PNP. A PN has between 1 and 10 digits. Ambiguity within the PNP is not allowed.

The Public Number is the phone number of a user within the Public Switched Telephone Network (PSTN) or the Public Land Mobile Network (PLMN).

More than one number can be administered for each user. For example:

A number for a fixed network A number for a mobile network A number for the mailbox

Every private number is assigned to a public number. Both numbers must be unique within a VPN of a subscriber. A user defined within the PNP can be reached via both the public number and the private number.

VPN members can be reached via short codes even in different locations.

2.5.2 Member Types

The following member types are available:

On-net Off-net Admin/DTMF Partner On-net Virtual On-net

DTMF ......... Dual Tone Multi Frequency PLMN ......... Public Land Mobile Network PN .............. Private Number PNP............ Private Numbering Plan PSTN.......... Public Switched Telephone Network VPN............ Virtual Private Network




Private Numbering Plan – Member Types

This member type is a user whose private number is registered inthe PNP but who can only receive VPN calls. He is a normal user within the PSTN or PLMN.This member type can be used to provide short codes in the PNP for public numbers that are frequently used (e.g. the numbers ofsub companies).

Virtual On-net

As a user can be a full member of one VPN only, this member typeis used to differentiate between Home VPNs and Partner VPNs.Thus, certain features of the VPN are made available to users of a foreign VPN, e.g. private numbers and special charging.

Partner On-netThis member type is used to provide access to the DTMF menu.Admin/DTMF

This member type is used by the service if the number of the corresponding user is not defined in the PNP.

Off-net

This member type characterizes a full user of the VPN, generally a member of the company and the VPN.

On-netDescriptionMember Type

Notes



2.5.3 Call Types

[1] on-net to on-net call On-net and forced on-net optimize network usage and helps to save costs. This call type allows the VPN user to set up a call from an on-net access to an on-net (or virtual on-net) destination within the VPN by dialing the (partner access code) Private Number (PN). The calling line is registered within the PNP as a direct service access, dialed service access or inband service access. It is not possible to set up a call as a virtual on-net member; virtual on-net members can only receive VPN calls. A virtual VPN user cannot use the resources of the VPN. If a VPN user dials another user using the public number instead of the private number or dialing the corporate number and PN, the SEP will handle the call as if (only) the Private Number had been dialed. This is known as a forced on-net call.

[2] on-net to off-net calls This VPN feature allows a VPN user to make a call from an on-net connection of the VPN to a B-party who is not a member of the VPN. An off-net connection can be any PSTN, ISDN or PLMN number and is not defined in the PNP. The service subscriber of the VPN or the user will be charged for the call, depending on the parameters of the charging component.

[3] off-net to on-net calls This call type allows the VPN user to set up a call from an off-net access to an on-net destination (virtual/partner) within the VPN, e.g. by dialing a remote access code, the VPN access code, the VPN Id and a private number. The B-party can be a virtual on-net connection or an on-net connection (partner). The service subscriber of the VPN or the user will be charged for the call depending on the parameters of the charging component of the FSL.

Example of an off-net to on-net call: An employee is working at the office of a customer. He wants to call a colleague via the VPN and uses the phone of the customer. The employee and his colleague are members of a VPN although the customer is not. The bill for this call is received by the company of the employee and not by the customer.

[4] on-net to virtual on-net calls This call type allows the VPN user to set up a call from an on-net access to a virtual on-net destination within the VPN by dialing the (partner access code) Private Number (PN). The calling line is registered within the PNP as a direct service access.

[5] off-net to off-net call This feature allows a VPN user to set up a call from an off-net access to an off-net destination (not registered within the PNP), e.g. by dialing a remote access code, the VPN access code and a public number.

Example of an off-net to off-net call:

An employee is working at the office of a customer. He wants to call back another customer via the VPN and uses the phone of the customer.

The employee is a member of a VPN although the customer is not. The bill for this call is received by the company of the employee and not by the customer.

FSL ............ Flexible Service Logic ISDN........... Integrated Services Digital Network PLMN ......... Public Land Mobile Network PN .............. Private Number PNP............ Private Numbering Plan PSTN.......... Public Switched Telephone Network SEP ............ Service Execution Point VPN............ Virtual Private Network




Call Types - 1

1

2

PLMN

PLMN

2

3 on - on

On - off

off - on

VPN


Call Types - 2

PLMN

PLMN

4

Partner VPNPartner On-Net

5

off - off

on – virtual on

VPN



2.6 Mobile Centrex

Mobile Centrex is a virtual mobile telephone system extended with comfortable administration and switchboard functionality. Mobile Network Operators (MNO) attract Small and Medium Enterprises (SME) customers to switch from PBX to mobile phones and, thus, increase mobile network traffic. It is a tailor-made VPN-like application with a comfortable Web-based administration.

2.6.1 Mobile Centrex Use Case

A typical use case could look as shown in the next slide:

The term automatic switchboard is used for the switchboard functionality realized through the MobileCentrex@vantage specific IN application. The automatic switchboard facilitates the work of the switchboard operator: Callers are automatically guided to the correct destination via a DTMF menu. Dependent on their selection, they are forwarded to an appropriate employee or department or even to a switchboard operator if desired. The caller can make a pre-selection by himself and is automatically guided to the correct person or hunting group sparing the company extra staff for attending and switching these calls. The DTMF menu is defined via MCX client. Via this client, the enterprise can define a main menu with up to 5 choices, each routing the call either to a phone number (i.e. employee, hunting group, queue), or to the next menu level with up to 3 more choices. The caller can enter his/her choice after the announcement is played.

The service provider manages the services running on the IN system commercially. He has a contractual relationship with the enterprises subscribing to MobileCentrex@vantage. The service provider takes care of the subscription process, i.e. initial set up of service to allow for an enterprise to administer their individual data and make use of MobileCentrex@vantage.

The SWAT represents the workspace of a switchboard operator in a mobile fashion. The SWAT is a standard PC with special SWAT software, headset, connected via GSM module, so that it can be operated anywhere. The SWAT supports the day-to-day activities of a switchboard operator via a graphical user interface, e.g. look up of employees and their numbers, transferring calls, etc.

The switchboard is usually the first contact a caller has when calling into a company via the company’s main number. The switchboard operator (in small companies this is usually the secretary) takes an incoming call and forwards it to an appropriate employee or department.

The term switchboard operator is used for the member of the enterprise operating the switchboard. The switchboard operator is supported by the SWAT for efficient call handling and call connection. The terms switchboard operator and switchboard attendant are used as synonyms.




MobileCentrex@vantage A typical use-case ...

blablabla!

Welcome to mobile.inc.Press 1 for sales,

Press 2 for service,Press 3 for Operator

Please wait,We’ll be with you in

no time

What can we do for you?

Notes

CAMEL ...... Customized Applications for Mobile Network Enhanced Logic DTMF ......... Dual Tone Multi Frequency GSM ........... Global System of Mobile telecommunication MCX ........... Mobile CentreX MNO........... Mobile Network Operators PBX............ Private Branch Exchange SME ........... Small and Medium Enterprises VPN............ Virtual Private Network SWAT......... Siemens Wireless Attendant



2.6.2 Architecture Overview

Web Client or Web Admin is used for the customer self-care capabilities, i.e. administration of the numbering plan, hunting groups, queues, automatic switchboard routing, etc. The Web Admin is enabled via an MCX client (PC) at the enterprise site that is connected via the web to the dedicated MCXpress server.

DTMF ......... Dual Tone Multi Frequency GSM ........... Global System for Mobile Telecommunication IVR ............. Interactive Voice Response MCX ........... Mobile CentreX MNO........... Mobile Network Operators PBX............ Private Branch EXchange SME ........... Small and Medium Enterprises SWAT......... Siemens Wireless Attendant UMTS ......... Universal Mobile Telecommunications System




MobileCentrex@vantage Architecture Overview

IP

Enterprise

IN System (MobileCentrex IN

application)Private NumberingBlack-/Whitelist ScreeningAutomatic SwitchboardCall QueuingHunting groupsDTMF menuRoaming support:

GSM/UMTS

MCXpress Server

Assisting IP(custom.

announcements)

(calls from inside or outside the company)

Admin traffic & status infoSignaling trafficCalls

Mobile Network Operator / Service Provider

SWAT

MCXClient

MCXClient

Web Portal Server

Notes



2.6.3 Key Features of Mobile Centrex

Mobile Centrex is a tailor-made VPN-like application with comfortable Web Admin.

The special features of Mobile Centrex are:

Private Numbering Plan - Short numbers Special tariffs for internal and external call types, e.g. internal calls free of charge White list and blacklist screening for outgoing calls Hunting groups, users can log on / off via USSD commands DTMF-controlled Automatic Switchboard Queue Service incl. priority screening Roaming support via CAMEL phase 2 Comfortable administration by the company themselves via dedicated Web application Integration with fixed lines and PBX networks possible SWAT “Siemens Wireless Attendant”: PC-based “mobile console” representing the

switchboard of the enterprise

CAMEL ...... Customized Applications for Mobile Network Enhanced Logic DTMF ......... Dual Tone Multi Frequency GSM ........... Global System of Mobile Telecommunication MCX ........... Mobile CentreX PBX............ Private Branch EXchange SWAT......... Siemens Wireless Attendant USSD ......... Unstructured Supplementary Service Data




Key Features:

Private Numbering Plan - Short numbers

Special tariffs for internal and external call types, e.g. internal calls free of charge

White list and blacklist screening for outgoing calls

Hunting groups, users can log on / off via USSD commands

DTMF-controlled Automatic Switchboard

Queue Service incl. priority screening

Roaming support via CAMEL phase 2

Comfortable administration by the company themselves via dedicated Web application

Integration with fixed lines and PBX networks possible

SWAT “Siemens Wireless Attendant”: PC-based “mobile console” representing the switchboard of the enterprise

MobileCentrex@vantageKey Features

Notes



2.6.4 Mobile Centrex like a Virtual PBX

The Mobile Network Operator (MNO) is responsible for maintaining and operating the mobile network including the IN system.

The service provider manages the services running on the IN system commercially. He has a contractual relationship with the enterprises subscribing to MobileCentrex@vantage. The service provider takes care of the subscription process, i.e. initial set up of service to allow for an enterprise to administrate their individual data and make use of MobileCentrex@vantage.

Enterprise comparies are those that subscribe to the MobileCentrex@vantage, i.e. customer of the network operator / service provider

GSM ........... Global System for Mobile telecommunication MNO........... Mobile Network Operator MSC ........... Mobile Switching Center PBX............ Private Branch EXchange




MobileCentrex@vantageVirtual PBX- Solution

MNO Enterprise

WirelessAttendant

GSM and IN infrastructure

A virtual mobile telephone systemBuilt on standard GSM and INExtended with comfortable administration and switchboard functionality

Calling/called party (e.g. Employees of

the Enterprise calling each other via the MobileCentrex)

Attract small to medium-sized enterprise customers to switch from PBX to mobile phones and thus increase mobile network trafficIntroduce additional IN service on well-established and proven IN platform

Notes



2.6.5 Switchboard Functionality provided by SWAT

The Siemens Wireless Attendant SWAT provides the company switchboard operator with an easy to use graphical user interface providing a familiar set of features for convenient call handling.

The SWAT is a special software application running on a standard PC connected via a standard GSM module or a mobile phone. Thus, the workplace becomes totally mobile and can be operated most cost-efficiently from anywhere – home, office, airport or elsewhere.

Using the phone list view at the SWAT, the switchboard operator can easily look up numbers, names and functions of the employees and transfer the incoming calls to the correct employee.

The immediate call transfer feature allows him to put the calls through to a colleague immediately without having to wait for the colleague to answer the phone. The operator can turn to the next caller in the queue at once which increases the throughput / number of calls to be handled by one switchboard operator.

The SWAT operator may check on the employee’s availability via the “Office Intelligence” feature or via “Status Query” before transferring the call. Thus, he can avoid that he directs an incoming call to the employee’s voice box due to the employee being out of the office or the employee’s phone being busy or out of coverage.

GSM ........... Global System for Mobile Telecommunication SWAT......... Siemens Wireless Attendant




Switchboard Functionality provided by SWAT

Notes



2.6.6 MCX Client: User Admin

The MobileCentrex@vantage service can be administered from an MCX client by the network operator/service provider or by the company itself. The web pages are written in Java and provided based in http form to the client. Access to the web administration pages is password-protected and follows the general functional and security aspects of IN@vantage. Role-based functional restrictions and access rights are supported.

The following user roles are pre-defined:

Administrator Network operator for maintenance,..

Customer Care Customer care personnel of the network operator

Subscriber Enterprise / company which subscribes the MobileCentrex@vantage service

User Employee of the company




MCX Client: User admin

Notes



2.6.7 Example 1: Small Company in the plumbing business

Imagine a 6-person company. Five workers and the boss’ wife who takes care of office work on a part-time basis. The workers are usually at customer sites all day and can only be reached via mobile phones. Whilst on the road, they need to schedule new jobs with customers, order material and consult other customers.

Instead of individual mobile and fixed-line subscriptions, the company subscribes to MobileCentrex@vantage. They enhance their customer service by introducing a voice menu (“… for trouble with the washing machine dial 1, for general repair dial 2, for all other service press 3”) with a hunting group for the washing machine experts (1) and the plumber emergency team (2). Everything else is routed to the boss’ wife, who will even attend the calls while on the road to take the kids to school.



2.6.8 Example 2: Insurance Agency

The insurance agency “Be Safe” is a company with 20 employees and subscribes to MobileCentrex@vantage.

All employees hold a mobile, however depending on their position they have restricted rights for making outgoing calls (blacklist / whitelist). Internally, they communicate with each other via the private numbering plan (dialing short numbers).

The company’s main number is connected to the automatic switchboard. From the voice menu, the customer can choose different departments - which are connected to appropriate hunting groups – or decide to be transferred to the switchboard operator. The switchboard operator is running the Siemens Wireless Attendant (SWAT) and connected to the switchboard queue. The caller is provided with announcements and music while waiting for the switchboard operator to be free. When making outgoing calls from the switchboard, the MSISDN of the switchboard operator is changed to the company’s main number, so that the called person (e.g. customer) sees the main number of the company in his display.

The company has set up two hunting groups, one for sales to business customers and one for sales to private persons. The agents log on and off their hunting groups depending on their availability. The groups are administrated with different members depending on day and time.

SWAT......... Siemens Wireless Attendant



2.7 Railway@vantage

Railway@vantage is the name of the intelligent network solution integrated into the GSM-R system. GSM-R provides railway operators with a fairly standardized communication network for implementing and coordinating their operating and maintenance activities.

Railway@vantage provides the following features within GSM-R:

Functional Addressing, e.g. the assignment of easy-to-remember numbers to different functions (driver, attendant ...) regardless of who is on duty and where the train is located.

Location-dependent Addressing, e.g. connection of the personnel aboard the train to the controller in charge for the respective location of the train.

GSM-R ....... Global System for Mobile telecommunication -Railway




Railway@vantageScope of Railway Communication

EIRENE (GSM-R) Network Other

EIRENE (GSM-R)Network

Railway Fixed Network

Shunting Communications

Train Communications

International Train Communications

Wide Area Communications(trackside, depot,

station, ...)

Notes



Functional Addressing (1) + (2) The train personnel register per USSD via the HLR at Railway@vantage.

(3) Railway@vantage assigns a functional number (conductor, train driver of a specific train) to an MSISDN and starts a timer for that case the person forgets to deregister.

(3a) Personnel enter the train.

(4) If the person forgets to deregister, the timer expires and the functional number is deregistered.

(5) + (6) The person is informed about deregistration by an USSD.

GSM-R ....... Global System for Mobile telecommunication –Railway HLR............ Home Location Register MSC ........... Mobile Switching Center MSISDN ..... Mobile Station ISDN USSD ......... Unstructured Supplementary Service Data




Functional Addressing

Railway@vantage

MSC

HLR

USSD (Forwarded)(2)(1)

(3)

Deregister by timerUSSD

RegistrationRequest

(3a)E.g. move on to train

(4)

Register Functional Number, set timer

(5)USSD Notifi-cation, for-warded

USSD Notification(6)

Notes



(1) + (2) Somebody calls a person by functional number, not knowing the MSISDN.

(3) Railway@vantage determines the MSISDN of the destination and

(4) Sends it to the MSC.

(5) MSC establishes the connection to the correct person, e.g. the MSISDN of the traindriver.

CdPA ......... Called Party Address GSM-R ....... Global System for Mobile telecommunication –Railway HLR............ Home Location Register MSC ........... Mobile Switching Center MSISDN ..... Mobile Station ISDN USSD ......... Unstructured Supplementary Service Data




Functional Addressing

Railway@vantage

MSC

HLR

establish connection

CdPA: Call Type /Functional Number

(2)

(3)

(5)(1)

CdPA: Call Type /Functional Numberof train driver A

Check, Translate Number

E.g. move on to train

(4)CdPA: MSISDN

Controller

train driver A

Notes



Location-dependent Addressing

(0) The location of a train is reported to Railway@vantage by a Train positioning system or by the cell-ID of GSM-R.

(1) The train driver calls the responsible controller via short code.

(2) Short code and cell-ID are sent to Railway@vantage.

(3) Railway@vantage determines the destination number.

(4) Connection is established.

MSC ........... Mobile Switching Center




Location-dependent Addressing

Controller Area B

ControllerArea A

Controller A

Controller CController Area C

Railway@vantage

MSC

Controller Number, based onLocation and short code

Train positioningsystem (optional)

Track-based locationinformation

establish connection

Short Code

Short Code,Cell ID

(0)

(2) (3)

(4)

(1)

Notes



2.8 Functional Blocks of IN@vantage

Service Logics The service logics are responsible for call and session control, screening, user interaction, etc.. Specialized service logics are dedicated to specific interface types. The appropriate service logics are responsible to provide the necessary online protocol and state handling as well as service-dependent features and subscriber dialog (where appropriate). Charging requests will be forwarded to the charging component.

#7 Service Logic: This service logic is responsible for service requests via the #7 network. In the case of a prepaid service, this service logic will perform up-front functions such as call screening with white and black lists, etc., and then call upon the functionality provided by the charging component.

Charging The charging component controls the entire charging and recharging transactions. The charging component takes care of rating invocation and coordinates access to accounts via Balancing. The charging component is used by all service logics alike. With the help of the Balance Management, the Charging component checks the remaining credit limit on the accounts and reserves chargeable amounts before service delivery. The final payment is executed after successful service delivery.

CAP............ CAMEL Application Part GSN ........... GPRS Support Node INAP........... Intelligent Network Application Part MSC ........... Mobile Switching Center MSSP ......... Mobile Service Switching Point SSP ............ Service Switching Point




Functional Blocks of IN@vantage

InterfaceCategory / Type

#7 : INAP/CAP(session, service)

Common DatabaseCommon DatabaseCommon Database

NetworkElements

MSSP, SSPGSN

MSSP, SSPGSN

Convergent Charging Service LogicConvergent Charging Service LogicConvergent Charging Service Logic

#7 based Service Logic

#7 based #7 based Service LogicService Logic

Billing Tickets

IN@vantage

Notes

Prepaid@vantage IN@PLATOP (Part 1)


3. Prepaid@vantage

3.1 What is Prepaid@vantage

Prepaid@vantage is the Siemens market leading prepaid solution for SS7 session and event charging. It offers online charging and many other attractive service features. Based on the @vantage platform, a prepaid service can be tailored exactly to the needs of every network operator. With 300 million installed or ordered prepaid subscribers, Siemens is the world market leader for prepaid in GSM and fixed networks.

Prepaid@vantage offers a modular and scalable system platform and allows the quick deployment of customized prepaid services. It provides real-time rating and charging of SS7 sessions and events for prepaid subscribers in fixed networks, 2G, 2.5G and 3G networks as well as real-time monitoring of accounts and thresholds. A Prepaid Service (PPS) offers a quick and easy solution to calling without a fixed contract and ensures the service provider and the network operator the guaranteed payment for phone calls and service usage.

A prepaid service subscriber pays a certain amount in advance to his prepaid account. He is subsequently able to place telephone calls amounting to his account balance without having to pay a (monthly) basic fee. All charges are debited from a single prepaid account. A prepaid service eliminates the need for contracts, basic charges and bills. The prepaid account is simply updated each time a call is made.

Prepaid@vantage provides flexible online rating and charging of as well as real-time monitoring of accounts and thresholds. Based on a modular and scalable system platform, it allows the quick deployment of customized prepaid services for SS7 voice and data calls both in fixed networks and in 2G, 2.5G and 3G mobile networks. Prepaid@vantage has the following features:

Real-time charging for prepaid subscribers in fixed, GSM, GPRS and UMTS networks Volume, time and location-based charging enables a variety of new data services Charging requests, events and session charging, forwarded from Charging@vantage and

Payment@vantage systems, originally initiated by application servers or shopping scenarios

Support of international roaming (CAP Phase 1-3, USSD Call Back) Prepaid@vantage is based on the highly scalable @vantage platform dedicated to the

increasing performance and reliability requirements of converging voice and data networks.

2G .............. 2nd Generation 2.5G ........... 2.5th Generation 3G .............. 3rd Generation CAMEL ...... Customized Applications for Mobile Network Enhanced Logic CAP............ CAMEL Application Part GPRS ......... General Packet Radio Service GSM ........... Global System for Mobile telecommunication PPS ............ Prepaid Service UMTS ......... Universal Mobile Telecommunications System USSD ......... Unstructured Supplementary Service Data

IN@PLATOP (Part 1) Prepaid@vantage



Prepaid@vantage

Real-time charging for prepaid subscribers in fixed, GSM, GPRS and UMTS networksVolume, time and location based charging enables a variety of new data servicesCharging requests, events and session charging, forwarded from Charging@vantage and Payment@vantage systemsFlexible RatingBalancingSupport of international roaming CAP Phase 1-3, USSD Call Back)Prepaid@vantage V7.6 is based on the highly scalable @vantage platform dedicated to the increasing performance and reliability requirements of converging voice and data networks.

Notes



3.2 Integration of Prepaid@vantage

Prepaid@vantage is a computer-based system working in addition to the basic Telco network. It is integrated into an existing communication network to provide a prepaid service.

Mobile Originating Calls (MOC) and Mobile Terminating Calls (MTC) are recognized inside the Mobile Service Switching Points (MSSP) as IN calls by checking the CSI in the HLR. Also for IP traffic, Prepaid@vantage controls the routing and charging of events and sessions.

A subscriber may set up an MOC from his home network (HPLMN) or from a visited (foreign) network (VPLMN). If he sets up a call from a visited network, the subscriber is roaming.

BSC............ Base Station Controller GGSN......... General GPRS Support Node GPRS ......... General Packet Radio Service GTP’........... GPRS Tunneling Protocol HLR............ Home Location Register HPLMN ...... Home Public Land Mobile Network MAP ........... Mobile Application Part MOC........... Mobile Originating Call MSC ........... Mobile Switching Center MSP ........... Multiple Subscriber Profile MSSP ......... Mobile Service Switching Point MTC ........... Mobile Terminating Call PCU............ Packet Controll Unit PPS ............ Prepaid Service SGSN ......... Supporting GPRS Service Node SSP ............ Service Switching Point UE .............. User Equipment UMTS ......... Universal Mobile Telecommunications System UTRAN....... UMTS Terrestrial Radio Access Network VPLMN....... Visited Public Land Mobile Network




Integration Prepaid@vantage

MSC (SSP)

HLR

MSC (SSP)BSC

PCU

BSC Base-station

Base-station

Prepaid@vantage

SSP

SGSN GGSNGPRS

GSM

WWW

GTP‘, DIAMETERCAPINAP

GTP

MAP

UTRANUMTS

UE

Notes



3.3 Prepaid Service

The Prepaid Service (PPS) is a telecommunications service for which subscribers pay in advance. It allows cashless calls from any kind of mobile telephone. Through payment in advance and online charging, there is no need to credit subscribers.

3.3.1 How to invoke the Prepaid Service

3.3.1.1 Originating Calls Originating calls represent the main call type of the PPS. The basic network detects an OC by the MSISDN of the PPS subscriber.

A subscriber may set up an OC from his home network (HPLMN) or from a visited (foreign) network (VPLMN). If he sets up a call from a visited network, the subscriber is roaming.

Possible handling of such a call:

While the originating call is processed, the service performs a number of checks, for example:

If the dialed number is charge-free. If the number is a menu access number. If the number is forbidden. If the account balance is sufficient.

Special rate plans are applied to charge originating calls.

A post-call notification function may inform the subscriber about his current credit after he released the call via, e.g., an USSD message.

HPLMN ...... Home PLMN MSISDN ..... Mobile Station ISDN OC.............. Originating Call PLMN ......... Public Land Mobile Network PPS ............ Prepaid Service USSD ......... Unstructured Supplementary Service Data VPLMN....... Visited PLMN




Mobile Originating Calls

HPLMN

VPLMN

Calling party is PPS subscriber

Roaming: Calling party is PPS subscriber

Notes



3.3.1.2 Terminating Calls A PPS subscriber is charged or is not charged for incoming calls - in the following called TC (or Mobile Terminating Call) - when he is within his home network (HPLMN) and the incoming call is not forwarded to another destination.

If the subscriber is roaming in a foreign network (VPLMN), he is typically charged at least for the roaming leg of the TC.

If the incoming call is forwarded to another destination or to a voice mailbox, the PPS subscriber is charged for the forwarding leg of the call.

If the service is not available, the provider or subscriber record is not accessible, or if the subscriber is locked, an announcement is played and the call is released.

A special rate plan is applied to charge terminating calls.

A post-call notification function may inform the subscriber about his current credit after he released the call via, e.g., an USSD message.

HPLMN ...... Home PLMN PPS ............ Prepaid Service TC .............. Terminating Calls USSD ......... Unstructured Supplementary Service Data VPLMN....... Visited PLMN




Mobile Terminating Calls

HPLMN

VPLMN

Called party is PPS subscriber

Roaming: Called party is PPS subscriber

Notes



3.3.1.3 Recharging Overview Prepaid@vantage accounts can be recharged using various methods. The most widely spread method is the use of vouchers, which the subscribers can buy at various points of sales such as gas stations, tobacco shops, kiosks, etc. To use a voucher for recharging, the Prepaid subscriber has to obtain access to a recharging procedure. Depending on the access variant, the user has to enter the identification of the voucher to transfer the value of the voucher to his account. The subscriber's account is identified by the information provided during access to the recharging procedure: e.g. calling party address (MSISDN) or login information. Before the recharging is executed, it is checked with the external voucher management system, whether the voucher is valid. Administration, production and use of the vouchers are controlled by an external voucher management system.

Online Prepaid Account Recharging via VoMS, accessed by

USSD DTMF menu Customer Care (via SMAF)

Online Recharging via dedicated Recharge Applications, Cash-in Bank recharge, e.g. via

−− Tele-banking system, IVR communication −− Web −− ATM

SMS WAP

ATM ........... Automated Teller Machine CC .............. Customer Care Corba ......... Common Object Request Broker Architecture DTMF ......... Dual Tone Multi Frequency HPLMN ...... Home Public Land Mobile Network IVR ............. Interactive Voice Response MSISDN ..... Mobile Station ISDN POS............ Point Of Sales SMAF ......... Service Management Access Function SMS ........... Short Message Service UCB ........... USSD Callback (Service) USSD ......... Unstructured Supplementary Service Data USSD ......... Unstructured Supplementary Service Data VoMS ......... Voucher Management System VoMS ......... Voucher Management System VPLMN....... Visited Public Land Mobile Network WAP ........... Wireless Application Protocol




Recharging OverviewMechanisms and Access Types

Customer Care(SMAF)

Customer Care(SMAF)

Voucher Management System (VoMS)

Voucher Management System (VoMS) Payment BrokerPayment Broker

Payment Plug-in

Payment Plug-in

e.g. Corba, HTTP, FTAM

Payment GWPayment GW

Payment Plug-in

Payment Plug-in

Financial Institutions

Application Sever

Online I/F Corba I/F

Application Sever ...

Access Type:DTMF, USSD (voucher based)

Manual Recharge (voucher based orvoucher-less, cash-in)

Cash-in, IVR, Web, WAP, SMS, ATM, POS etc.(voucher-less)

...

Recharge via VoMS/#7 Recharge via Application Sever / IPUntrusted domain

Recharge via Customer Care

Mechanism:

Prepaid@vantage

Notes



3.3.1.3.1 Voucher Recharging by DTMF In case of voucher recharging by DTMF, the subscriber connects to the DTMF menu and selects the appropriate item. He then is connected to the voucher management system and asked to key in the identification of the voucher. The identification of the voucher is used to find the voucher in the database of the voucher management system, where it is checked that the voucher is valid and its value is determined. The evaluation of the subscriber's MSISDN means that it is determined which account to recharge. Optionally, a check against the “max account threshold” may be executed. Usually, the account is recharged and a confirmation ticket is written. In the case that one of the checks leads to a negative result, the subscriber receives an announcement telling him why the recharge was not successful. In addition a confirmation ticket is written.

1. The subscriber initiates an online recharge request via DTMF menu after dialing a special service number (DTMF menu for recharge) by using his of own terminal.

2. A call is set-up between the subscriber and the SSP. The appropriate subscriber’s home SEP is triggered by the SSP via CAP 2 operations. The IP (in Switch) under the control of SEP is now playing announcements and guiding through user interactive dialogs (collecting subscriber input via DTMF).

3. By prompt of the DTMF menu the subscriber chooses voucher recharge and enters the voucher ID, which is then collected by the SEP.

4. The SEP sends the recharge request with the voucher ID to the VoMS.

5. The VoMS checks the validity of recharge data and sends respective acknowledge message back to the SEP.

6. In SEP the correct account is accessed and increased with the given recharge amount. A confirmation ticket for further evaluation is written. The SEP sends back the recharge result and informs the subscriber by playing announcements, including the updated account information: balance, expiry date etc.

CAP............ CAMEL Application Part DTMF ......... Dual Tone Multi Frequency HPLMN ...... Home Public Land Mobile Network MSISDN ..... Mobile Station ISDN PPS ............ Prepaid Service SEP ............ Service Execution Point SSP ............ Service Switching Point UCB ........... USSD Callback (Service) USSD ......... Unstructured Supplementary Service Data VPLMN....... Visited Public Land Mobile Network




22

44

55

MSC/SSP

Voucher Recharge via DTMFOwn Terminal (Mobile Phone)

11

33

PLMN

IP



66

6’6’

3’3’

VoMS IF

Initiate call (DTMF)

IDP

RRB CTR, PA;

P&C…

Subscriber & Terminal

Send voucher recharge message

Acknowledge

PA, ERB (Rechargeresult)

IDP: Initial Detection Point

RRB: Request Report BCSM

CTR: Connect To Resource

PA:: Play Announcement

P&C: Prompt and Collect user information

ERB: Event Report BCSM

Prepaid@vantage

Notes



3.3.2 Use Cases

3.3.2.1 Online-charged Voice Calls from Fixed Network – SINAP In the fixed network, there are two possibilities to access the prepaid service:

1. Dialed service access: PPS supports direct access dialing within the fixed network. To reach the service, the PPS subscriber has to dial a service access number.

2. Subscribed service access: PPS also supports access via line triggering. To reach the prepaid service, the line is triggered according to the subscribed party number.

Identification and Authentication

After a welcome announcement, the PPS subscriber is prompted for a prepaid card number and a PIN. In the case of successful authentication, the PPS subscriber is prompted to dial the desired destination number. The Identification and Authentication feature is optional.

A typical call in the fixed network is as follows:

1.) A fixed subscriber initiates a call which is recognized as an IN call.

2.) The Service Switching Point (SSP) sends the Initial Detection Point (IDP) SINAP message to Prepaid@vantage.

The steps 3 to 6 are optional for identification and authorization.

3.) Prepaid@vantage controls the charging of the basic network (AMA ticket is created inside the SSP) by Furnish Charging Information (FCI), addresses the Intelligent Peripheral (IP) by Connect To Resource (CTR) and asks for the prepaid card number by Prompt And Collect (PAC).

4.) The Intelligent Peripheral (IP) plays an announcement asking for the prepaid card number. The fixed subscriber enters the card number via DTMF and the Prompt And Collect result (PAC result) is sent to Prepaid@vantage.

5.) The Prepaid@vantage asks for the Personal Identification Number (PIN) by sending Prompt And Collect (PAC) to the IP.

6.) The Intelligent Peripheral (IP) plays an announcement asking for the Personal Identification Number (PIN). The fixed subscriber enters the card number via DTMF and the Prompt And Collect result (PAC result) is sent to Prepaid@vantage.

7.) Prepaid@vantage checks the subscriber’s authorization and if the check is positive, asks for the destination number by Prompt And Collect (PAC).

8.) The Intelligent Peripheral (IP) plays an announcement asking for the destination number. The fixed subscriber enters the destination number via DTMF and the Prompt And Collect result (PAC result) is sent to Prepaid@vantage.

9.) Prepaid@vantage sends Apply Charging (AC) with a certain amount of granted time and CONnect (CON) with the destination number.

10.) The call is established.

11.) In this example, the fixed subscriber releases the call before the granted time is exceeded.

12.) The Service Switching Point SSP informs Prepaid@vantage about that event by sending an Apply Charging Report (ACR). Prepaid@vantage calculates the amount of money and charges the subscriber’s account.




Online Charged Voice Call from Fixed Network (SINAP based charging of voice calls)

Example: Online charging of simple fixed voice call

10. Call connection

2. IDP

AC: Apply ChargingACR: Apply Charging ReportCON: ConnectCSI: CAMEL Subscr. InfoCTR: Connect To ResourceFCI: Furnish Charging InfoIDP: Initial Detection PointPAC: Prompt And CollectPIN: Personal Identification Number

SINAP

Prepaid@vantage

or

SSP: Service Switching PointIP: Intelligent Peripheral

1. Initiate call

SSP incl. IPFixed network

3. SCI, FCI, CTR, PAC (prepaid card number)

12. ACR

6. PAC result

8. PAC result9. AC, CON

(granted time)

7. PAC (destination number)

11. Release call

5. PAC (PIN) 4. PAC result

Notes

AC .............. Apply Charging ACR ........... Apply Charging Report AMA ........... Automatic Message Accounting CON ........... CONnect CSI ............. CAMEL Subscription Information CTR............ Connect To Resource DTMF ......... Dual Tone Multi Frequency FCI ............. Furnish Charging Information IDP ............. Initial Detection Point IP................ Intelligent Peripheral PAC............ Prompt And Collect PACresult .. Prompt And Collect result PIN ............. Personal Identification Number SINAP ........ Siemens Intelligent Network Application Part SSP ............ Service Switching Point



3.3.2.2 Online-charged Voice Calls from Abroad – MOC CAP 2 This service access enables service triggering from abroad. Prepaid@vantage provides a specific call handling for that, e.g. individual charging and rating.

The prerequisite is the availability of CAMEL Phase 2 or 3 within the VPLMN.

AC .............. Apply Charging ACR ........... Apply Charging Report CAMEL ...... Customized Applications for Mobile Network Enhanced Logic CAP............ CAMEL Application Part CSI ............. CAMEL Subscription Information GSM ........... Global System for Mobile telecommunication HLR............ Home Location Register IDP ............. Initial Detection Point MOC........... Mobile Originating Call MSC ........... Mobile Switching Center VLR ............ Visitor Location Register VPLMN....... Visited Public Land Mobile Network




SS7 Session Charging in CS Domain(CAP 2 based charging for voice calls)

Example: Online charging of simple GSM MOC voice call from VPLMN

4. call connection1. Initiate call (MOC)

2. IDP 3. AC, Connect (granted time)

MSC/VLR

5. ACR

AC: Apply ChargingACR: Apply Charging ReportCSI: CAMEL Subscr. InfoIDP: Initial DP

VPLMN

Retrieve CSI

HLRCAP2

Prepaid@vantage

Notes



3.3.2.3 SS7 Event Charging: SMS from Abroad To control an SMS service by Prepaid@vantage, the SEP must be triggered with an SMS-MO attempt when the subscriber is sending an SMS. The SMS-MO service access provides for that. A mobile subscriber is marked in his Home Location Register (HLR) with an SMS CAMEL Subscription Information (SMS-CSI) that is used to identify an SMS service at the SEP. This guarantees the immediate service triggering as soon as the subscriber sends a short message.

Whenever the subscriber sends a short message, the SSP recognizes the trigger event and signals it via a #7 message (Initial DP SMS operation) to the SEP. So the respective service will be identified and started.

CAMEL ...... Customized Applications for Mobile Network Enhanced Logic CAP............ CAMEL Application Part CS .............. Customer Support CSI ............. CAMEL Subscription Information ERB............ Event Report BCSM HLR............ Home Location Register IDP ............. Initial Detection Point MSC ........... Mobile Switching Center RRB ........... Request Report BCSM SEP ............ Service Execution Point SMS-C........ Short Message Service Center SMS-MO .... SMS Mobile Originating SS7 ............ Signaling System #7 VLR ............ Visitor Location Register VPLMN....... Visited Public Land Mobile Network




SS7 Event Charging in CS Domain(CAP3 based SMS-MO charging)

5a. Report:submit, failure

4. SMS delivery

SMS-C

1. Send SMS

2. IDP3. RRB, CUE

MSC/VLR

Example: MS-MO with surveillance of successful delivery at SMS-C

SMS delivery

5b. ERB (submit, failure)

RetrieveCSI

CSI: CAMEL Subscr. InfoCUE: ContinueERB: Event Report BCSMIDP: Initial DPRRB: Request Report BCSM Event

VPLMN

HLR

CAP3

Prepaid@vantage

Notes



3.4 Functional Blocks Prepaid@vantage

#7 Service Logic This service logic is responsible for service requests via the #7 network. In the case of a prepaid service, this service logic will perform up-front functions such as call screening with white and black lists, etc., and then call upon the functionality provided by the charging component.

Charging component The charging component controls the entire charging and recharging transactions. The charging component takes care of rating invocation and coordinates access to accounts via Balance Management. The charging component is used by all service logics alike. By the help of the Balance Management the Charging component checks the remaining credit limit on the accounts and reserves chargeable amounts before service delivery. The final payment is executed after successful service delivery.

Rating Rating for online and offline charging is supported, (able to support flexible charging/billing based on a variety of criteria). Hereby, operators are able, to implement and modify different rates.

APN............ Access Point Name CAP............ CAMEL Application Part GPRS ......... General Packet Radio Service GSN ........... GPRS Support Node INAP........... Intelligent Network Application Part MOC........... Mobile Originating Call MSSP ......... Mobile Service Switching Point MTC ........... Mobile Terminating Call QoS............ Quality of Service SMS ........... Short Message Service SSP ............ Service Switching Point




Prepaid@vantage

InterfaceCategory/Type



NetworkElements

MSSP, SSPGSN

MSSP, SSPGSN


#7 based Service Logic

#7 based #7 based Service LogicService Logic

Balance ManagementBalance ManagementBalance Management

Billing Tickets

Prepaid@vantage

Rating LogicRating LogicRating Logic

Notes

Charging@vantage IN@PLATOP (Part 1)


IN@PLATOP (Part 1) Charging@vantage


4. Charging@vantage Charging@vantage is a new product dedicated to IP content and event charging. Charging@vantage is based on the experience gained in providing carrier grade intelligent network solutions (and especially PPS). Charging@vantage interacts with PPS on physically separated machines, i.e. re-uses existing prepaid servers to avoid migration efforts and keep the existing infrastructure.

Charging@vantage is responsible for controlling and monitoring of entire IP-based charging requests and transactions. A charging transaction is defined as the process from the initiation of the charge request until its final confirmation. Although Charging@vantage is primarily dedicated to IP online charging, it is also able to handle charging based on tickets (hot billing).

For the balance management of prepaid subscribers, Charging@vantage re-uses existing Siemens prepaid servers in order to avoid migration efforts and to keep the existing infrastructure. For saving operator’s investments, Charging@vantage writes tickets which can be used further on by classical billing systems in the postprocessing process.

MMSC ........ Multimedia Messaging Service Center MSP ........... Mobile Smart Proxy OAM ........... Operation, Administration & Maintenance PPS ............ Prepaid Service SMSC ......... Short Message Service Center



4.1 Network Embedding of Charging@vantage

Depending on the use case, one or more network elements interwork with Charging@vantage. i.e.:

The application servers, e.g. HTTP content server, MMSC (providing services to the consumers).

Policy Router and/or IP Monitor like CSG or IPS enable the monitoring and control of IP sessions and HTTP streams.

Balance Management Systems that hold the prepaid consumer accounts. Optional: User Repository-used to retrieve the location of the accounts (only needed if

more than one Balance Management System is involved).

All systems are controlled and synchronized by Charging@vantage via defined interfaces.

Charging@vantage receives various parameters from the network: e.g. MSISDN, service ID, URL, time, bearer, intended volume to be downloaded, etc.

Charging@vantage determines the balance management system involved in the charging transaction based on the received MSISDN. The determination is achieved via an internal “address resolution table” or by inquiring a User Repository.

Charging@vantage initiates, synchronizes, and controls the booking of the appropriate amounts on the involved consumer accounts. From Charging@vantage the point-of-view first a reservation of the amount is carried out: The amount is withdrawn from the subscriber’s PPS account and is stored as reservation on Charging@vantage.

Charging@vantage communicates the successful / unsuccessful reservation back to the requesting server incl. further details for advice of charge and/or session monitoring.

Charging@vantage monitors the transaction until it receives a final confirmation from the partner network element. The response of the corresponding partner network element is confirmed in a ticket for subsequent billing or statistical evaluations. Additionally (e.g. in case of session charging) subsequent amount reservations or refund of “non-used” amounts are handled by Charging@vantage.

To support deferred delivery/charging in parts subscriber accounts containing reserved money are stored temporarily on the Charging@vantage system.

AAA ........... Authentication, Authorization and Accounting CORBA ...... Common Object Request Broker Architecture CRM ........... Customer Relationship Management CSG ........... Content Service Gateway FTAM ......... File Transfer, Access & Management FTP ............ File Transfer Protocol GTP............ GPRS Tunneling Protocol IPS ............. Intelligent Packet Solution LDAP ......... Lightweight Directory Access Protocol MMS........... Multimedia Messaging Service MMSC ........ Multimedia Messaging Service Center MSISDN ..... Mobile Station ISDN MSP ........... Mobile Smart Proxy PPS ............ Prepaid Service RADIUS ..... Remote Authentication Dial In User Service SAP ............ Service Access Point SMSC ......... Short Message Service Center SSG............ Service Selection Gateway WAP ........... Wireless Application Protocol




IP EventIP Session

Network Embedding Charging@vantage

Ro/RADIUS, GTP‘

Policy Router(SSG, CSG, IPS)Policy Router

(SSG, CSG, IPS)SMSCSMSC

Payment PlugInCORBA

Web/Wap Proxy(MSP, CSG, IPS)Web/Wap Proxy(MSP, CSG, IPS)

Ro/RADIUS

MMSCMMSC

LDAPCORBA /FTAM

FTAM, FTP

Billing / CRMINXpress V6.2/V7bPrepaid@vantage

INXpress V6.2/V7bPrepaid@vantage

Online IF

Billing CenterSAP

Billing CenterSAP

User Repository

User Repository

Operation

Address Resolution

External BalanceManagement

RADIUSAAAAAA

Session Authorization

Hot Billing

ApplicationServer

ApplicationServer

(S)FTP FTAMPayment PlugInRo/RADIUS, GTP’

Charging@vantage

@CommanderServer

Notes



4.2 Features of Charging@vantage

Charging@vantage is the central network element responsible for the control and monitoring of the entire charging transaction. A charging transaction is defined as the process from the initiation of the charge request until its final confirmation. Depending on the use case one or more network elements interwork with Charging@vantage.

4.2.1 CORBA Communication to Payment Plug-in on Application Server

The Payment Plug-in was introduced in previous versions to provide event and content charging for applications. The most widely used applications for Payment Plug-ins are originating and terminating SMS, Premium Rate SMS charging or the charging for WAP content.

The PlugIn is installed on the application server and provides HTTP and J2EE compliant Java interfaces for easy integration with the applications. It is connected to the Charging Server via CORBA interface.

The Payment Plug-In supports use cases such as immediate charging, charging in parts, charging with deferred delivery, recharge control, reservation handling, provisioning of basic rating information, refund and cancel.

4.2.2 Advice of Charge

All charge requests are transmitted to the charging server in real-time, i.e. before service delivery. Thus, the account verification and tariff determination can be achieved in advance and the subscriber can be informed about the respective price / unit to be paid for in advance (“advice of charge”). Thus, the “advice of charge” feature provides cost transparency and spending control for prepaid as well as for postpaid, subscribers, in turn increases the acceptance of new services.

4.2.3 Balancing

4.2.3.1 Real-time Account Supervision Charging@vantage is dedicated to the provisioning and execution of real-time charge requests. Charging@vantage supports real-time account identification, tariff determination, real-time account monitoring as well as real-time reservation handling in close co-operation with connected Prepaid Servers or by using specific postpaid account systems for online credit limit check.

The consumers pay in advance (prepaid) or have a predefined spending limit (postpaid). Their credit limit is exactly the same as the amount on their account. To avoid a subscriber overdrawing his account (and thus minimize the risk for the operator), rating and charging is achieved in real-time.

Since the tariff determination is performed in advance, cost transparency for the subscriber can be guaranteed (advice of charge). This feature increases acceptance of new services and may soon be required by law.




Features of Charging@vantage

CORBA Communication to Payment PlugIn Advice of ChargeBalancing

1. Real-time Account Supervision2. Addresses Prepaid Accounts on Dedicated Systems3. Credit Limit Supervision for Postpaid Subscribers4. Long Term Reservation Handling5. GOB Certification

HotBilling Support

Notes

CORBA ...... Common Object Request Broker Architecture GOB ........... “Grundsätze ordnungsgemäßer Buchführung” HTTP.......... Hypertext Transfer Protocol J2EE .......... Java 2 Enterprise Edition SMS ........... Short Message Service WAP ........... Wireless Application Protocol



4.2.3.2 Support of Prepaid Accounts on Dedicated Systems For prepaid subscribers who want to pay through their prepaid account, Charging@vantage accesses and reuses existing Siemens prepaid servers known from SS7 charging by default. This design concept has the following advantages:

Avoids duplication of subscriber data and all related consistency problems. Maintains the existing human or system interfaces to existing legacy systems like

Customer Care and Billing Centers. Avoids additional administration and operation efforts.

Charging@vantage interworks with Siemens Prepaid systems from version INXpress V6.2 upwards. The interface between the Payment server and the prepaid server is based on a proprietary online interface implemented in ASN.1.

This design concept has the following advantages:

Optimizes new hardware investment and operational efforts as all functions are physically located on the same server.

Reduces the amount of external interfaces and, thus, the dependency on other systems.

4.2.3.3 Support of Online Credit Limit Supervision for Postpaid Subscribers To reduce the operator’s risk of receiving unpaid bills, Charging@vantage supports online balance checks in advance for postpaid consumers. Therefore, dedicated online account systems for postpaid subscribers have to be introduced to be used for online credit limit supervision. Each charge request is verified against the online account before the service is granted. As long as the subscriber has not exceeded his balance limit the service is granted and a charging ticket (for billing purposes) is written.

The real-time postpaid account systems are not part of Charging@vantage but may be offered separately. As an alternative to separate postpaid account systems, the configuration option “charge@once” - including prepaid and postpaid accounts - can be offered.

ASN.1......... Abstract Notation Number 1 SS7 ............ Signaling System #7



4.2.4 HotBilling Support

Charging (based on tickets) is supported as a quick way to enable charging for any application server without a real-time charging interface. With a hot billing approach, credit limit supervision / account control can only be performed after service delivery has taken place. I.e. to minimize the credit risk for the operator, charging based on hot billing is only recommended for trial purposes, where the maximum credit risk can easily be calculated. For commercial usage, we recommend to use online charging. The ticket transfer is based on FTP or FTAM. Up to 256 different ticket types are supported.

FTAM ......... File Transfer, Access & Management FTP ............ File Transfer Protocol GoB............ “Grundsätze ordnungsgemäßer Buchführung”



4.3 Charging@vantage Charging Scenarios

In addition, or as an alternative to handling charge requests via a dedicated “Payment Plug-in”, Charging@vantage V2.0 provides a new real-time charging interface for the direct connection of application servers / IP network elements to the charging server. This new interface is suitable for simple event charging, e.g. multi media messages, purchase of soft goods as well as for complex IP session charging as needed for video streaming or web-surfing.

The first IP network elements that are connected to the Siemens Charging Server via the new online charging interface (RADIUS interface) are:

Siemens MSP Cisco Policy Router Ericsson MMS

Other network elements can also be connected easily. The new online charging interface is based on RADIUS and proves a pre-standard implementation of the standard RO interface as currently under standardization by 3GPP.

The main benefits of a standard charging interface vs. a proprietary solution, are the support of roaming scenarios and minimizing the necessity for mediation and gateway devices. Thus, the overall deployment efforts can be reduced when new network elements are introduced in the network.

Depending on the use cases and the type of application offered different scenarios are supported including immediate charging, charging in parts, charging with deferred delivery, recharge control, advice of charge, rating, and reservation handling.

IP Event Charging via IP Monitor (MSP) supports charge, rate & reserve, advice of charge, reservation.

IP Event Charging via MMSC supports charge, and rate & reserve.

IP Session Charging via Policy Router supports unit grant and debiting, reservation, and advice of charge.

In the following charging scenarios a Policy Router (SSG), a Web/WAP Proxy (such as Siemens MSP) and the Content Servers (e.g. MMSC, HTTP Content server) are distinguished.

3GPP.......... 3rd Generation Partnership Project HTTP.......... Hypertext Transfer Protocol MMS........... Multimedia Messaging Service MMSC ........ Multimedia Messaging Service-Center MSP ........... Mobile Smart Proxy OS .............. Operating System RADIUS ..... Remote Authentication Dial In User Service SSG............ Service Selection Gateway WAP ........... Wireless Application Protocol



The Policy Router (SSG) provides traffic control on the IP layer (layer 3 according to OSI reference model), i.e. it can be used for IP session charging using volume and/or time units.

The Web/WAP Proxy monitors the IP traffic on the application layer (layer 7) and can be used for URL-based event charging.

Alternatively, the content servers may be connected directly to the charging system to trigger the respective online charging capabilities.

The adequate solution depends on the planned charging scenarios as well as the operator’s network infrastructure and should be clarified in the project.



4.3.1 IP Event Charging

4.3.1.1 SMS-MO Event Charging with Reservation This example explains a simplified flow for a charging scenario for an SMS submission (i.e. a subscriber submits an SMS to be retrieved from one, or various recipients).

It is assumed that the subscriber is charged for the SMS submission if the delivery is successful and the bearer is assumed to be free of charge.

1a) The A-party subscriber sends an SMS from his mobile phone to the MSC. The VLR was updated by the location update from the HLR, so the SMS-CSI determines that the originator is a prepaid subscriber. The HOME SMS-C can be addressed by evaluating the MSISDN.

1b) The MSC of the VPLMN forwards the SMS to the SMS-C of the HPLMN. 2) The SMS-C queries Charging@vantage to reserve a certain amount.

In the following steps it has to be checked, whether the subscriber’s account balance is sufficient for SMS submission. It is assumed that the subscriber is only charged for the SMS in case of its successful submission.

3) Charging@vantage confirms the reservation after checking the account of the subscriber in the Prepaid system.

4) The SMS-C delivers the SMS to B-party. 5) After the SMS is delivered to B-party, the confirmation is sent to the SMS-C. 6) The SMS-C accesses Charging@vantage, provides information for charging purposes

and requests the charging of an appropriate amount of money which is determined by Charging@vantage or by the rating component of the effected PPS service. Charging@vantage accesses the PPS, determining the amount of money to be charged, checks the account balance of the subscriber and carries out a charge of the respective amount (in the example outlined above, the subscriber’s account provides sufficient balance). The PPS provides an indication back to Charging@vantage.

7) Charging@vantage provides an acknowledgement about successful charging to the SMS-C.

CSI ............. CAMEL Subscription Information HLR............ Home Location Register HPLMN ...... Home Public Land Mobile Network MSC ........... Mobile Switching Center MSISDN ..... Mobile Station ISDN OSI ............. Open Systems Interconnections PPS ............ Prepaid Service SMS ........... Short Message Service SMSC ......... Short Message Service Center SSG............ Service Selection Gateway VLR ............ Visitor Location Register VPLMN....... Visited Public Land Mobile Network




A-PartySMSC

1. send SMS 1b. storage at SMSC

3. confirmReserve

2. reserve

SMS-MO Event Charging with Reservation

MSC/VLR

6. charge

7. confirmCharge

B-Party

5. delivery confirmation

4. delivery to B-party

Charging@vantage

via Payment PlugIn

PrepaidIN V6.2 / V7b

Notes



4.3.1.2 HTTP Content Charging via Web/WAP Proxy The following example explains a simplified flow for HTTP content charging via a Web/WAP Proxy. It is assumed that the subscriber is charged for the content if the delivery is successful and the bearer is assumed to be free of charge. In this use case, the relevant charging information is provided by the Web/WAP Proxy via Pre-RO Radius interface or via the Payment PlugIn.

The Proxy may either provide a price (e.g. obtained from the URL or from an internal table) or other charging information such as e.g. service ID which will then be used by Charging@vantage to determine the correct pricing based on the given information. The bearer (transport) is assumed to be free of charge and the involved network elements for transport charging are not shown in the figure. The bearer charging can be controlled by communication between SGSN and the prepaid system (via CAMEL) or by communication between the SSG and the charging system (via RADIUS).

1) The subscriber initiates a request for content delivery from an HTTP content server. It is assumed that the service request is already authorized and transport is set “free-of-charge”. In the following steps it has to be checked, whether the subscriber’s account balance is sufficient for content retrieval. It is assumed, that the subscriber is only charged for the content in case of its successful delivery to the subscriber.

2) The Web/WAP Proxy accesses Charging@vantage, provides information for charging purposes (based on the monitoring of the URL) and requests the reservation of an appropriate amount of money. Different variants are possible here and need to be clarified in the project: The correct price can be either delivered by the Web/WAP proxy or will be determined by Charging@vantage.

3a) Charging@vantage accesses the PPS, providing the amount of money to be charged. The PPS checks the account balance of the subscriber and carries out a reservation of the respective amount (in the example outlined above, the subscriber’s account provides sufficient balance).

3b) The PPS service indicates the successful charge to Charging@vantage. 4) Charging@vantage acknowledges the successful amount reservation and provides

charging information to the Web/WAP Proxy. 5+6) Content delivery to the subscriber via the Web/WAP Proxy.

As outlined above, the amount is withdrawn from the subscriber’s PPS account and is charged directly. Alternatively, the scenario may be implemented using reservation handling. In this case the amount is withdrawn from the subscriber’s PPS account and is stored as reservation on Charging@vantage. In the case of unsuccessful delivery or after a certain timeout, Charging@vantage will refund the reservation to the subscriber’s account automatically.

CAMEL ...... Customized Applications for Mobile Network Enhanced Logic HTTP.......... Hypertext Transfer Protocol PPS ............ Prepaid Service RADIUS ..... Remote Authentication Dial In User Service SGSN ......... Supporting GPRS Service Node SSG............ Service Selection Gateway WAP ........... Wireless Application Protocol




Consumer

HTTP Content Charging via Web/WAP Proxy (Trusted environment) Immediate Charging

HTTPContentServerWeb/WAP

Proxy6. Content Delivery(HTTP)

1. HTTP_R

4. confirmCharge2. charge

5. HTTP_R

3b. Successful debit

3a. ChargeCharging@vantage

RADIUS or via Payment PlugIn


Notes



4.3.1.3 MMS Submission IP Event Charging The following example explains a simplified flow for a charging scenario for an MMS submission (i.e. a subscriber submits an MMS to be retrieved from one or various recipients).

It is assumed that the subscriber is charged for the MMS submission if the delivery is successful and the bearer is assumed to be free of charge.

1) The subscriber initiates an “MMS submit” request from his mobile phone 1b) The Policy Router authorizes the respective service request and provides a Service ID

to Charging@vantage via the Radius interface. The Service ID is evaluated by Charging@vantage subsequently.

1c) Charging@vantage evaluates the Service ID. As the result, Charging@vantage instructs the Policy Router to set the bearer “free-of-charge”.

2) The MMS Submit Request is forwarded to the Multimedia Messaging Service Center (MMSC).

In the following steps it has to be checked whether the subscriber’s account balance is sufficient for MMS submission. It is assumed that the subscriber is only charged for the MMS in case of its successful submission.

3) The MMSC accesses Charging@vantage, provides information for charging purposes and requests the charging of an appropriate amount of money which is determined by Charging@vantage or by the rating component of the effected PPS service. Charging@vantage accesses the PPS, determining the amount of money to be charged, checks the account balance of the subscriber and carries out a charge of the respective amount (in the example outlined above, the subscriber’s account provides sufficient balance). The PPS service provides an indication back to Charging@vantage.

4) Charging@vantage provides an acknowledgement about successful charging to the Policy Router.

5, 6) MMS provides submission acknowledge to subscriber.

GSN ........... GPRS Support Node PPS ............ Prepaid Service MMS........... Multimedia Messaging Service MMSC ........ Multimedia Messaging Service Center RADIUS ..... Remote Authentication Dial In User Service SSG............ Service Selection Gateway




Immediate IP Event Charging of MMSMMS submission with bearer free of charge

MMSC

GSN

5.MMS Subm. Ack.

2. MMS Subm. Req.1.MMS Subm. Req.

SSG

Charging@vantage

4.ok

3.charge

1b. Service_Id

1c Free-of-Charge

RADIUS (Pre-R0)

RADIUS (Pre-R0) orvia Payment PlugIn


Notes



4.3.2 IP Session Charging

4.3.2.1 IP Session Charging based on RADIUS (Pre-RO) The RADIUS protocol, also known as AAA protocol, is used for the following:

Accounting The act of collecting information on resource usage for the purpose of trend analysis, auditing, billing, or cost allocation.

Authentication

The act of verifying the identity of an entity (subject).

Authorization

The act of determining whether a requesting entity (subject) will be allowed to access to a resource (object).

Client/Server Model A Network Access Server (NAS) operates as a client of RADIUS. The client is responsible for passing user information to designated RADIUS servers, and then acting on the response which is returned.

RADIUS servers are responsible for receiving user connection requests, authenticating the user, and then returning all configuration information necessary for the client to deliver service to the user.

A RADIUS server can act as a proxy client to other RADIUS servers or other kinds of authentication servers.

Network Security Transactions between the client and RADIUS server are authenticated through the use of a shared secret, which is never sent over the network. In addition, any user passwords are sent encrypted between the client and RADIUS server, to eliminate the possibility that someone snooping on an unsecure network could determine a user's password.

Flexible Authentication Mechanisms The RADIUS server can support a variety of methods to authenticate a user. When it is provided with the user name and original password given by the user, it can support PPP PAP or CHAP, UNIX login, and other authentication mechanisms.

AAA ........... Authentication, Authorization and Accounting CHAP ......... Challenge Handshake Authentication Protocol NAS............ Network Access Server PAP ............ Password Authentication Protocol PPP ............ PrePaidPayment Radius ....... Remote Authentication Dial In User Service SSG............ Service Selection Gateway




IP Session Charging-based on RADIUS (Pre-RO)

Supported Charging Scenarios

Support of time-based budget controlSupport of volume-based budget controlDelivery of connection-specific information

Typical Use Cases via Service Selection Gateway(SSG)

Web/WAP surfingVideo Streaming

Notes



4.3.2.2 IP Session Charging via SSG Charging@vantage supports time-based and volume-based charging of data transport via IP network elements such as a Policy Router (Service Selection Gateway, SSG). Typically surfing in catalogues or info pages, video streaming or access to 3rd party servers or corporate network server is session charged.

The following example can be seen as an alternative to the transport charging via an SGSN via CAMEL. It shows a simplified flow for charging HTTP-based web sessions via the involved IP network element (Policy Router).

It is assumed that the subscriber is charged for the bearer (transport) itself and no event charging has to be performed.

1) The subscriber initiates an HTTP request for a session to a web-server (e.g. http://www.siemens.com).

2) The Policy Router authorizes the respective service request and provides a service ID to Charging@vantage via the RADIUS interface.

3a) Charging@vantage determines the respective unit price and initiates the deduction of an appropriate amount (referring to a certain time or volume) from the subscriber’s account.

3b) The successful debit of the subscriber’s account is indicated to Charging@vantage. 4) The Policy Router is instructed about granted time / volume to supervise the IP traffic. 5-7) While the subscriber surfs in the internet while the Policy Router continuously

supervises the consumed units (time and / or volume). If the reserved portion (time and / or volume) is used up, the Policy Router contacts Charging@vantage to confirm the charges and asks for an additional portion

Steps 2) to 7) will be repeated in principle until the session terminates or until the account balance becomes zero.

7+8) In case the session terminates a final confirmation to Charging@vantage is sent allowing the remaining amount to be refunded – for not completely used up portions - to the respective subscriber account.

The determination of the respective unit price may either be performed on the charging server itself, or on the prepaid server holding the subscriber’s specific account data and needs to be decided by project.

CAMEL ...... Customized Applications for Mobile Network Enhanced Logic GGSN......... General GPRS Support Node RADIUS ..... Remote Authentication Dial In User Service SGSN ......... Supporting GPRS Service Node SSG............ Service Selection Gateway




IP Session Charging in PO Domain(RADIUS based GPRS/UMTS Charging via SSG)

6. HTTP_Delivery

5. HTTP_Req. HTTPWebServer

Internet

2. reserve 4. connect (granted time / volume)

Example: HTTP web session

7. charge

1. HTTP request

8. ok

SSG

3b. Successful debit

3a. Charge

Charging@vantage

RADIUS (Pre-R0)


GGSN

Notes



4.4 IN and Mobile Data Services

The different components of the telecommunication network can provide different information for charging:

The SGSN can monitor transport of IP packets and generates charging information for transported volume (APN-based).

The GGSN establishes a PDP context for the mobile subscriber and acts as a gateway between GPRS- and IP network.

The SSG can derive charging information for IP transport based on selected service/ destination and port number (APN-independent).

The MMSC sends and stores multimedia messages from and for mobile subscribers and generates charging information based on events.

APN............ Access Point Name CAMEL ...... Customized Applications for Mobile Network Enhanced Logic GGSN......... General GPRS Support Node GPRS ......... General Packet Radio Service MMS........... Multimedia Messaging Service MMSC ........ Multimedia Messaging Service Center PDP............ Packet Data Protocol RADIUS ..... Remote Authentication Dial In User Service SGSN ......... Supporting GPRS Service Node SSG............ Service Selection Gateway TCP ............ Transmission Control Protocol




IN and Mobile Data Services (e.g. MMS)

Deriving charging info for transport at different levels:

SGSNBrowser SSG MMSC Application

IP level

TCP level

HTTP level

The SGSN can monitor transport of IP packets and generates charging information for transported volume(APN-based)

The MMSC sends and stores multimedia messages from and for mobile subscribers and generates charging information based on events

To othertargets

Application

Request

Response

Mobile Network

GGSN

To otherIP network domains

RequestResponse

The SSG can derive charging information for IP transport based on selected service/ destination and portnumber (APN-independent)

Charging@vantage

The GGSN establishes a PDP context for the mobile subscriber and acts as a gateway between GPRS- and IP- network

Notes



4.5 Functional Blocks of Charging@vantage

Charging@vantage is based on Siemens’ modular architecture for convergent online charging. Charging@vantage is primarily dedicated to IP online charging but may also handle charging based on tickets (IP Hot Billing). The system is based on 3GPP standardization for charging and billing. Open interfaces allow integration to operator’s legacy systems, e.g. integration of CRM, Online Bill Presentment, Statistics etc. For saving operator’s investments, also classical Billing Systems can be used further on. The main functional elements of Charging@vantage are:

Service Logic components (IP, Hot Billing) Charging Component Common Database

Charging@vantage accesses pre-/postpaid accounts on separate servers (e.g. existing prepaid servers). Thus, it functions as a gateway and mediator between the IP network elements and/or application servers that are requesting charging and the related account management systems.

The logical functions are implemented as separate components with defined function split and interfaces.

IP and IP Hot Billing Service Logics IP Service Logic: this service logic is responsible for service requests coming from IP-based session and event services (intended to cover new services in the mobile IP environment such as multimedia messaging, file downloads, video streaming etc.); it handles the dialog with the connected IP network elements and calls upon the functionality provided by the charging component;

Hot Billing (Ticket) Service Logic: this service logic is responsible for processing tickets written by network elements (intended to cover legacy hot billing scenarios). This is necessary because some network elements do not support online interfaces or only in later product releases. Introducing this functionality, workarounds via mediation functions will become obsolete.

Convergent Charging Service Logic The Convergent Carging Service Logic controls the entire charging session / transactions respectively recharging transactions. It takes care of a performance-optimized handling of rating invocation (project-specifically) and coordinates access to accounts located on external systems. The convergent charging logic is used by all service logics alike. By the help of the external accounting systems (e.g. Prepaid Server), the charging logic checks the remaining credit limit on the accounts and reserves chargeable amounts before service delivery. The final payment is executed after successful service delivery.

Tickets including all relevant information of the charging transaction for further post-processing are written.

Common Database The common database holds and accesses the product data and the configuration data as well as temporary data for controlling the transactions.




Functional Blocks of Charging@vantage

InterfaceCategory / Type GTP’, Ro,

IP (session)

GTP’, Ro andCORBA (PlugIn)IP (event)

TicketHot Billing


NetworkElements SSG, MSP, CSG Non-standard

Application ServerCSG, SMSC, Application Server(MMSC,…)


IP-based Service Logic

IPIP--based based Service LogicService Logic

IP-based HotBilling Service Logic

IPIP--based Hotbased HotBilling Service Logic Billing Service Logic

Billing Tickets

Charging@vantage

Existing Balance Management System (SCP V7b)Existing Balance Management System (SCP V7b)Existing Balance Management System (SCP V7b)

Notes

3GPP.......... 3rd Generation Partnership Project Corba ......... Common Object Request Broker Architecture CRM ........... Customer Relationship Management MMSC ........ Multimedia Messaging Service Center MSP ........... Mobile Smart Proxy SCP............ Service Control Point SMSC ......... Short Message Service Center SSG............ Service Selection Gateway

charge@once IN@PLATOP (Part 1)


IN@PLATOP (Part 1) charge@once


5. charge@once charge@once is the convergent online charging solution for the following:

Applications, Networks and Subscribers.

In combination of Charging@vantage and Prepaid@vantage on one physical cluster, charge@once can be enabled for:

Session and event charging Any application SS7 mobile and fixed networks IP networks

In SS7 networks, the core network elements are connected via CAP or SINAP; the IP network elements and application servers are connected via pre-standardized Online Charging Interface (RADIUS), DIAMETER, GTP’ or via the „Payment PlugIn“ (as provided in previous versions, i.e. Payment@vantage or Charging@vantage).

Thus session and content charging can be offered in any core network and supports all network types, e.g. fixed networks, GSM, GPRS, UMTS or IP – including WLAN access.

CAP............ CAMEL Application Part GPRS ......... General Packet Radio Service GSM ........... Global System for Mobile telecommunication RADIUS ..... Remote Authentication Dial In User Service SINAP ........ Siemens INAP SS7 ............ Signaling System #7 UMTS ......... Universal Mobile Telecommunications System WLAN ........ Wireless LAN



5.1 Functional Blocks of charge@once

Service Logics The service logics are responsible for call and session control, screening, user interaction, etc. Specialized service logics are dedicated to specific interface types. The appropriate service logics are responsible to provide the necessary online protocol and state handling as well as service-dependent features and subscriber dialog (where appropriate). Charging requests will be forwarded to the charging component.

#7 Service Logic This service logic is responsible for service requests via the #7 network. In the case of a prepaid service, this service logic will perform up-front functions such as call screening with white and black lists, etc., and then call upon the functionality provided by the charging component.

IP Service Logic This service logic is responsible for service requests coming from IP-based session and event services (intended to cover new services in the mobile IP environment such as multimedia messaging, file downloads, video streaming etc.); it handles the dialog with the connected IP network elements and calls upon the functionality provided by the charging component;

Hot Billing/Ticket Service Logic This service logic is responsible for processing tickets written by network elements (intended to cover legacy hot billing scenarios). This is necessary because some network elements do not support online interfaces or only in later product releases. Introducing this functionality, workarounds via mediation functions will become obsolete.

Charging component: The charging component controls the entire charging and recharging transactions. The charging component takes care of rating invocation and coordinates access to With the help of Balance Management, the Charging component checks the remaining credit limit on the accounts and reserves chargeable amounts before service delivery. The final payment is executed after successful service delivery.

Rating: Rating for online and offline charging, which is able to support flexible charging/billing based on a variety of criteria is supported. Hereby, operators are able, to implement and modify different rate plans (designed for a special subscriber category) as a marketing instrument.

Balance Management: The accounts of prepaid and postpaid subscribers are controlled and managed by charge@once. Checking the thresholds before service delivery, negative account balances will be avoided. The accounts can be held in real currency units as Euro or in any other unit as bonus points, volume units, and time units. It is possible to assign different accounts to one subscriber, or to have a common account for a group of subscribers (Family, Company)




Functional Blocks of charge@once

InterfaceCategory /Type


GTP’, Ro,DIAMETERIP (session, service)

GTP’, Ro, DIAMETERand CORBA (PlugIn)IP (event)

TicketHot Billing


NetworkElements MSC, SSP, GSN SSG, MSP, CSG Non-standard

Application ServerSMSC, Application Server, CSG(MMSC,…)


Internal RatingInternal Rating

#7-based Service Logic

#7#7--based based Service LogicService Logic

IP-based Service Logic

IPIP--based based Service LogicService Logic

IP-based HotBilling Service Logic

IPIP--based Hotbased HotBilling Service Logic Billing Service Logic

Rating LogicRating LogicRating Logic

Billing Tickets

charge@once

Notes

CAP............ CAMEL Application Part CORBA ...... Common Object Request Broker Architecture CSG ........... Content Service Gateway GSN ........... GPRS Support Node GTP............ GPRS Tunneling Protocol INAP........... Intelligent Network Application Part MMSC ........ Multimedia Messaging Service Center MSC ........... Mobile Switching Center MSP ........... Mobile Smart Proxy SMSC ......... Short Message Service Center SSG............ Service Selection Gateway SSP ............ Service Switching Point



5.2 Integration of charge@once

Charge@once is the combination of Charging@vantage and Prepaid@vantage, and it is possible to implement it in the following:

Charging scenarios emerging from the SS7 network: −− Charging of voice calls (based on CAP Phase 1, CAP Phase 2, CAP 3 and INAP). −− Charging of data sessions in GPRS and UMTS networks (based on CAP 3) for time

and/or volume.

Charging scenarios from any type of IP network element can be handled. These cover: −− Online IP charging scenarios (e.g. session and event charging for SMS, MMS and

other applications in the IP domain). −− Hotbilling IP charging scenarios, i.e. ticket-based charging as a quick and easy way to

connect with any application server that does not support the standard IP interfaces for online charging.

CAP............ CAMEL Application Part CORBA ...... Common Object Request Broker Architecture CSG ........... Content Service Gateway GPRS ......... General Packet Radio Service GTP............ GPRS Tunneling Protocol HLRi........... Home Location Register innovation INAP........... Intelligent Network Application Part MAP ........... Mobile Application Part MMS........... Multimedia Messaging Service MMSC ........ Multimedia Messaging Service Center MSP ........... Mobile Smart Proxy MSSP ......... Mobile Service Switching Point RADIUS ..... Remote Authentication Dial-In User Service SMS ........... Short Message Service SMSC ......... Short Message Service Center SSG............ Service Selection Gateway SSP ............ Service Switching Point TCP/IP........ Transmission Control Protocol/Internet Protocol UMTS ......... Universal Mobile Telecommunications System




MMSC MSP

Integration of charge@once

MSSPSSP

MSSP HLRiSSG

SMSC

CAPINAP MAPTCP/IP (RADIUS, GTP’, DIAMETER)CORBA

charge@once

CSG

Notes



5.3 Features of charge@once

charge@once - as a central network element - is responsible for the control and monitoring of all of the charging and rating transactions of sessions and events.

A transaction is defined as the process from the initiation of the session or event request until its final confirmation. Depending on the use case, one or more network elements cooperate with charge@once.

MSSP, SGSN handle GPRS / UMTS data and voice sessions for 2G, 2.5G and 3G subscribers.

The application servers, e.g. HTTP content server, MMSC, etc…, providing services to the consumers.

Policy Router and/or IP Monitor enabling monitoring and control of IP sessions and HTTP streams.

All systems are controlled and synchronized by charge@once via defined interfaces.

charge@once determines the tariff based on various parameters received from the network: e.g. MSISDN, APN, service ID, URL, time, bearer, intended volume to be downloaded, etc.. This concept allows for subscriber’s specific data such as usage counters to be used for the tariff determination as well.

charge@once determines the accounts involved in the charging transaction based on the received MSISDN and the charging profile. The accounts are stored directly on charge@once.

charge@once initiates, synchronizes, and controls the booking of the appropriate amounts on the involved consumer accounts. From point-of-view of charge@once, first a reservation of the amount is carried out: The reserved amount is withdrawn from the subscriber’s account and is stored as reservation.

charge@once communicates the successful / unsuccessful reservation back to the requesting server incl. further details for advice of charge and/or session monitoring.

charge@once further monitors the transaction until a final confirmation from the partner network element is received. Every successful charge is confirmed in a ticket for subsequent billing, bookkeeping and/or statistical evaluations. Additionally (e.g. in case of session charging) subsequent amount reservations or refund of “non-used” amounts are handled by charge@once.

APN............ Access Point Name GPRS ......... General Packet Radio Service MMSC ........ Multimedia Messaging Service Center MSISDN ..... Mobile Station ISDN MSSP ......... Mobile Service Switching Point SGSN ......... Supporting GPRS Service Node UMTS ......... Universal Mobile Telecommunications System



5.4 Interfaces of charge@once

5.4.1 CAP-based Interfaces

The CAP protocol has been standardized by 3GPP and is used to integrate Intelligent Network functions into mobile networks. Prepaid applications use CAMEL to handle online charge requests from SS7 network elements, control time and/or volume consumption, verify additional screening features and ensure roaming between networks. The following CAMEL use cases are typically used in the context of charging:

Online charging of airtime usage for Prepaid subscribers (MSSP connection to charge@once)

Online charging for PO data transfer (time-based or volume-based charging, connection of SGSN to charge@once)

Online charging for SMS in circuit-switched networks including successful delivery control (MSSP connection to charge@once)

Online charging for SMS in packet-oriented networks including successful delivery control (SGSN connection to charge@once)

Roaming support (MSC / SGSN in foreign networks connected to charge@once)

5.4.2 IP-based Interfaces – Payment PlugIn

The Payment PlugIn was introduced in previous versions to provide event and content charging for applications. The most widely used applications for the Pyment-PlugIn are the charging of originating and terminating SMS, Premium Rate SMS charging, and the charging of WAP content.

The PlugIn is installed on the application server and provides HTTP and J2EE compliant Java interfaces for easy integration with the applications. It is connected to the Charging Server via a CORBA interface.

The Payment PlugIn supports use cases such as immediate charging, charging in parts, charging with deferred delivery, recharge control, reservation handling, provisioning of basic rating information, and refund and cancellation.

3GPP.......... 3rd Generation Partnership Project CAMEL ...... Customized Applications for Mobile Network Enhanced Logic CAP............ CAMEL Application Part CORBA ...... Common Object Request Broker Architecture GPP............ General Purpose Processor GPRS ......... General Packet Radio Service J2EE .......... Java 2 Enterprise Edition MSC ........... Mobile Switching Center MSSP ......... Mobile Service Switching Point PO .............. Packet Oriented SGSN ......... Supporting GPRS Service Node SMS ........... Short Message Service SS7 ............ Signaling System #7 WAP ........... Wireless Application Protocol



5.4.3 IP-based Interfaces – Online Interfaces

In addition or as an alternative to the “Payment PlugIn”, charge@once provides a real-time charging interface for the direct connection of application servers / IP network elements. This new interface is suitable for simple event charging, e.g. multi media messages, purchase of soft goods as well as for complex IP session charging as needed for video streaming or web-surfing.

The first IP network elements that are connected to charge@once via the online charging interface are, e.g.

Siemens MSP (IP Monitor) Ericsson MMS Cisco SSG (Policy Router) Content Service Gateway CSG

Other network elements can also be connected easily. The online charging interface is based on RADIUS and proves a pre-standard implementation of the standard RO interface as currently under standardization by 3GPP.

Depending on the use cases and the type of application offered different scenarios are supported including immediate charging, charging in parts, charging with deferred delivery, recharge control, advice of charge, rating, reservation handling.

IP Event Charging via IP Monitor (MSP) supports charge, rate & reserve, advice of charge, reservation. The IP Monitor monitors the IP stream on the application layer and may therefore provide charging information on application layer (e.g. based on URL).

IP Session Charging via Policy Router (SSG) supports unit grant and debiting, reservation, advice of charge. The Policy Router monitors the IP traffic on the IP layer and is used for volume-based and/or time-based session charging.

IP Session and Event Charging via Content Service Gateway (CSG). The CSG examines the mobile wireless and wireline IP data stream beyond the IP and TCP/UDP (Transmission Control Protocol/User Datagram Protocol) headers, thus enabling billing based on content.

IP Event Charging via MMSC supports charge, rate & reserve.

3GPP.......... 3rd Generation Partnership Project MMS........... Multimedia Messaging Service MMSC ........ Multimedia Messaging Service Center MSP ........... Mobile Smart Proxy RADIUS ..... Remote Authentication Dial In User Service SSG............ Service Selection Gateway TCP ............ Transmission Control Protocol UDP............ User Datagram Protocol



5.5 Use Cases

charge@once supports SS7-based charging in GSM, GPRS and UMTS networks via CAMEL protocol as well as session-based and event-based charging of new IP services via IP interfaces.

In the following subchapters some example scenarios for CAMEL as well as IP event and session charging are described.

CAMEL ...... Customized Applications for Mobile Network Enhanced Logic GPRS ......... General Packet Radio Service GSM ........... Global System for Mobile telecommunication SS7 ............ Signaling System #7 UMTS ......... Universal Mobile Telecommunications System



5.5.1 CAMEL-based Charging

5.5.1.1 Charging of Circuit-switched (CS) Traffic charge@once supports time-based charging of GSM or UMTS circuit-switched connections. This use case is typically used for voice calls or – in the UMTS environment – for video calls.

The following example shows a simplified flow for a GSM mobile originating call based on CAMEL Phase 2.

1) The subscriber initiates a mobile originating call by dialing the desired destination number.

2) The MSC triggers charge@once via CAMEL Phase 2 interface (IDP) due to the CAMEL Subscription Information (CSI) retrieved from the HLR. Tariff determination is carried out on charge@once and an appropriate amount (referring to a certain time interval) is deducted from the subscriber account.

3) charge@once provides the response including granted time to the MSC. 4) The MSC continues in processing the respective request, connects the call and

monitors the call duration / respectively time consumption. 5) The MSC reports the consumed time/amount back to charge@once.

Steps 3) to 5) will in principle be repeated in case the provided time portion is used up, i.e. in this case the MSC may order an additional unit for time consumption. This requires sufficient debit on the subscriber’s account.

In case the session terminates and the time provided to the MSC was not completely used up, charge@once is refunds the amount to the respective subscriber account.

AC .............. Apply Charging ACR ........... Apply Charging Report CAMEL ...... Customized Applications for Mobile Network Enhanced Logic CAP............ CAMEL Application Part CON ........... Connect CS .............. Circuit Switched CSI ............. CAMEL Subscription Information HLR............ Home Location Register IDP ............. Initial Detection Point MOC........... Mobile Originating Call MSC ........... Mobile Switching Center SS7 ............ Signaling System #7 VLR ............ Visitor Location Register VPLMN....... Visited Public Land Mobile Network UMTS ......... Universal Mobile Telecommunications System




SS7 Session Charging: MOC – CAMEL Phase 2Charging of Circuit Switched (CS) Traffic

4. call connection1. Initiate call (MOC)

2. IDP 3. AC, CON (granted time)

MSC/VLR

5. ACR

AC: Apply ChargingACR: Apply Charging ReportCON: ConnectCSI: CAMEL Subscr. InfoIDP: Initial DP

VPLMN

Retrieve CSI

CAP2HLR

charge@once

Notes



5.5.1.2 SS7 Session Charging in PO Domain charge@once supports time-based and volume-based charging of data connections in GPRS / UMTS networks. Typically surfing the web or access to 3rd party servers or corporate network server is session charged.

The following example provides a simplified flow for charging HTTP-based web sessions based on CAMEL Phase 3.

1) The subscriber initiates an HTTP request for a session to a Web Server (e.g. http://www.siemens.com).

2) The SGSN accesses charge@once via CAMEL Phase 3 interface (IDP_GPRS). Tariff determination is carried out on charge@once and an appropriate amount (referring to a certain time and / or volume) is deducted from the subscriber account.

3) charge@once provides the response including granted time / granted volume to the SGSN.

4 + 5) The SGSN continues in processing the respective request and forwards the request to the respective Web Server, monitoring time / volume consumption.

6) HTTP delivery to subscriber. 7) The SGSN reports the consumed amount back to charge@once.

Steps 3) to 7) will be repeated should the provided volume or time portions be used up.This will unable the granting of additional units for time / volume consumption. This requires sufficient debit on the subscriber’s account.

In case the session terminates and the time or volume provided to the SGSN was not completely used up, charge@once refunds of the amount to the respective subscriber account.

AC .............. Apply Charging ACR ........... Apply Charging Report CAMEL ...... Customized Applications for Mobile Network Enhanced Logic CAP............ CAMEL Application Part CSI ............. CAMEL Subscription Information GGSN......... General GPRS Support Node GPRS ......... General Packet Radio Service HLR............ Home Location Register HTTP.......... Hypertext Transfer Protocol IDP ............. Initial Detection Point PDP............ Packet Data Protocol SGSN ......... Supporting GPRS Service Node UMTS ......... Universal Mobile Telecommunications System VPLMN....... Visited Public Land Mobile Network




SS7 Session Charging in PO Domain

6. HTTP_Delivery

5. HTTP_Req.HTTPWebServer

Internet

GGSN

1. GPRS_PDP_context_req

4. GPRS_context_ack

2. IDP_GPRS 3. Connect_GPRS, AC_GPRS (granted time / volume)

SGSN

Example: Online charging of HTTP web session. (CAMEL Phase 3 based GPRS/UMTS Charging )

7. ACR_GPRS

VPLMN

Retrieve CSI

HLR

charge@once

CAP3

Notes



5.5.1.3 SS7 Event Charging in CS Domain: SMS-MO In this scenario, the subscriber is charged for sending an SMS. The implementation follows the CAMEL Phase 3 standardization for SMS-MO charging. The scenario shows the call flow for sending an SMS in the CS Domain. The scenario includes the optional monitoring of successful storage of the SMS at the SMSC.

1) The subscriber sends an SMS from his mobile phone 2) The MSC initiates a CAP 3 dialogue towards charge@once. Charge@once evaluates

the request, determines the respective tariff and checks the account for sufficient balance.

3) charge@once instructs the MSC to deliver the SMS and to report the result about successful storage back.

4) The SMS is forwarded to the Short Message Service Center. 5a+b) The result about successful storage (submit / failure) is reported back to

charge@once and respective charging takes place.

CAMEL ...... Customized Applications for Mobile Network Enhanced Logic CAP............ CAMEL Application Part CSI ............. CAMEL Subscription Information CUE............ Continue ERB............ Event Report BCSM HLR............ Home Location Register HTTP.......... Hypertext Transfer Protocol IDP ............. Initial Detection Point MMSC ........ Multimedia Messaging Service Center MSC ........... Mobile Switching Center MSP ........... Mobile Smart Proxy OSI ............. Open Systems Interconnections RRB ........... Request Report BCSM SMSC ......... Short Message Service Center SMS-MO .... SMS Mobile Originating SS7 ............ Signaling System #7 SSG............ Service Selection Gateway VLR ............ Visitor Location Register VPLMN....... Visited Public Land Mobile Network WAP ........... Wireless Application Protocol




SS7 Event Charging in CS Domain: SMS-MO

5a. Report:submit, failure

4. SMS-delivery

SMSC

1. Send SMS

2. IDP3. RRB, CUE

MSC/VLR

Example: SMS-MO CAMEL Phase 3 based with surveillance of successful delivery at SMSC

SMS delivery

5b. ERB (submit, failure)

RetrieveCSI

CSI: CAMEL Subscr. InfoCUE: ContinueERB: Event Report BCSMIDP: Initial DPRRB: Request Report BCSM Event

VPLMN

HLR

charge@once

CAP3

Notes



5.5.1.4 IP Session Charging in PO Domain via SSG charge@once supports time and volume based charging of data transport via IP network elements such as a Policy Router (Service Selection Gateway, SSG). Typical applications for session charging are: surfing in catalogues or info pages, video streaming or access to 3rd party servers or corporate network server.

The following example can be viewed as an alternative to the transport charging via CAMEL. It shows a flow for charging HTTP based web sessions via the involved IP network element (Policy Router).

1) The subscriber initiates an HTTP request for a session to a web-server. 2) The Policy Router authorizes the respective service request and provides a service ID

to charge@once via the RADIUS interface. charge@once determines the respective unit price (depending on product selection and referring to a certain time or volume) and deducts an appropriate amount from the subscriber account.

3) The Policy Router is instructed about the granted time / volume in order to supervise the IP traffic.

4-6) While the subscriber surfs in the internet, while the Policy Router continuously supervises the consumed units (time and / or volume). If the reserved portion (time and / or volume) is used up, the Policy Router contracts charge@once to confirm the charges and request for an additional portion.

Steps 2) to 6) will be repeated in principle until the session terminates or until the account balance becomes zero.

6+7) In case the session terminates a final confirmation to charge@once is sent allowing the remain amount to be refunded – for not completely used up portions - to the respective subscriber account.

5.5.2 IP Charging Scenarios

In addition to connecting charge@once via standard SS7 interfaces to the network, charge@once can also be connected directly to the IP network elements. This configuration option provides charging for IP sessions similar to SS7 session charging and enables further charging options for the provided content and events based on additional information provided by the IP network elements and application servers.

Note: In the following charging scenarios a Policy Router (SSG), a Web/WAP Proxy (such as the Siemens MSP) and the Content Servers (e.g. MMSC, HTTP Content server) are distinguished.

The Policy Router (SSG) provides traffic control on the IP layer (layer 3 according to OSI reference model). I.e. it can be used for IP session charging using volume and/or time units. The Web/WAP Proxy (MSP) monitors the IP traffic on the application layer (layer 7) and is used for event charging e.g. based on the URL.

Alternatively, the content servers may directly be connected to the charging system to trigger the respective online charging capabilities.

The adequate solution depends on the planned charging scenarios as well as the operator’s network infrastructure and should be clarified in the project.




IP Session Charging in PO Domain via SSG

5. HTTP_Delivery

4. HTTP_Req.HTTPWebServer

Internet

2. reserve 3. connect (granted time / volume)

Example: HTTP web session (Radius-based GPRS/UMTS Charging)

6. charge

GGSN

1. HTTP request

7. ok

SSG

charge@once

RADIUS (Pre-R0)

Notes

GGSN......... General GPRS Support Node GPRS ......... General Packet Radio Service HTTP.......... Hypertext Transfer Protocol IP................ Internet Protocol MMSC ........ Multimedia Messaging Service Center MSP ........... Mobile Smart Proxy OSI ............. Open Systems Interconnections PO .............. Packet Oriented RADIUS ..... Remote Authentication Dial In User Service SS7 ............ Signaling System #7 SSG............ Service Selection Gateway UMTS ......... Universal Mobile Telecommunications System



5.5.2.1 HTTP Content Charging via Web/WAP Proxy The following example provides a flow for HTTP content charging. It is assumed that the subscriber is charged for the content if the delivery is successful. In this use case the relevant charging information is provided from the Web/WAP Proxy via Pre-RO RADIUS interface or via the Payment PlugIn.

The bearer (transport) is assumed to be free of charge and the network elements involved in transport charging are not shown in the picture.

1) The subscriber initiates a request for content delivery from an HTTP content server. It is assumed that the service request is already authorized and transport is set “free of charge”. In the following steps it has to be checked, whether the subscriber’s account balance is sufficient for content retrieval. It is assumed, that the subscriber is only charged for the content if it is delivered successfully.

2) The Web/WAP Proxy accesses charge@once, provides information for charging purposes (based on the monitoring of the URL), and requests the authorization of an appropriate amount of money. Different variants are possible and need to be clarified in the project. The correct price can be either delivered via the Web/WAP Proxy or will be determined by the rating component of charge@once. charge@once accesses the subscriber account, checks the account balance of the subscriber and authorizes the respective amount (in the example outlined above the subscriber’s account provides sufficient balance). The same would apply for credit limit checks for postpaid subscribers in case of credit limit supervision.

3) charge@once acknowledges the successful charging to the Web/WAP Proxy. 4+5) Content is delivered to the subscriber via the Web/WAP Proxy.

As outlined above, the amount is withdrawn from the subscriber’s account directly. Alternatively the scenario may be implemented using reservation handling: in this case the amount is withdrawn from the subscriber’s account and is stored as a reservation. In case of unsuccessful delivery or after a certain timeout, charge@once will refund the reservation to the subscriber’s account.

HTTP.......... Hypertext Transfer Protocol RADIUS ..... Remote Authentication Dial In User Service WAP ........... Wireless Application Protocol




HTTP Content Charging via Web/WAP Proxy

Example: “immediate charging” in trusted environment

Consumer

charge@once

HTTPContentServerWeb/WAP

Proxy5. Content Delivery(HTTP)

1. HTTP_R

3. confirmCharge2. charge

4. HTTP_R

charge@once

RADIUS (Pre-R0) orvia Payment PlugIn

Notes



5.5.2.2 Hotbilling for IP Applications (Content) In addition to online charging interfaces, charge@once also provides a means for processing charging information from tickets. In this case the service usage is charged as soon as charge@once receives the ticket, and the respective charging information stored inside. A Hot Billing approach always bears a credit risk of unpaid services, as the network operator can only charge/bill for the service after its usage. Therefore this method is only recommended for trial purposes or niche market applications, where the maximum Credit risk can easily be calculated.

1) The subscriber uses an application, e.g. downloads some software, surfs the internet or plays some games.

2) After the service was used the GSN writes an appropriate ticket containing information about service usage. This ticket is retrieved by the charging system using file transfer (FTAM/FTP).

2.1) If the account balance is down to zero or even below zero, charge@once may block the subscriber from using further services by blocking him in the HLR.

3) charge@once processes the information stored in the ticket and charges the account accordingly (e.g. check for duplicate tickets, evaluation of information given in the ticket, retrieval of account and service information, rating, charging)

4) charge@once confirms the successful or unsuccessful processing of the ticket information in appropriate logging/error or confirmation tickets. These can be retrieved for further evaluation.

FTAM ......... File Transfer, Access & Management FTP ............ File Transfer Protocol GSN ........... GPRS Service Node HLR............ Home Location Register MAP ........... Mobile Application Part




Application Server, e.g. Game Server

3. ticket processing (account check, rating; update account; optional blocking)

Hotbilling for IP Applications (Content)

2. ticket file 4. Log / error ticket files; confirmation tickets for further evaluation / processing

e.g. Data Warehousee.g. Data

Warehouse

1. Subscriberuses application

HLR

3a. barring of subscriber if necessary (AnyTimePOBarring)

GSN

charge@once

FTAM/FTPMAP3

Notes

Flexible Rating IN@PLATOP (Part 1)


6. Flexible Rating This chapter contains:

A few examples of tariffs realized A description of rating and charging architecture Explanation of rating logics V7.6 enhancements of rating and charging.

IN@PLATOP (Part 1) Flexible Rating


6.1 Tariff Examples


Tariff Examples - Standards

Many companies offer one or more of the following options for Mobile Originating Calls

• Friends and Family• Home zone• Favourite Area• Mobile Local Call

to the subscriber. Selection of one or more options at the same time is possible.Reduced prices apply if one or more options are selected.The options are also used for SMS pricing

Notes




Tariff Examples – Free Accounts

Additionally to the standard monetary account the following accounts were implemented

• Free minutes account, e.g. Each subscriber gets 10 free minutes each month

• Free SMS account, e.g subscriber gets 10 free SMS each month

• Free kbytes account• “BundledSMSAccount” (recharged via

special voucher)• …

Notes

An incomplete list of accounts. With V7.6 new accounts can be added dynamically.




Tariff Examples – Accumulators - 1

Accumulators implemented were• SMS usage counter• Call time• Revenue• ...

Such accumulators are updated during the call. Conditions may apply like

• Update minutes accumulator only in case monetary account is charged

• Do not update in case free account is charged

Notes

Accumulators can be used to count various items. Used to apply discounts if thresholds are reached.

With V7.6 discounts can be applied

not only to prices of events or sessions taking place after the threshold is reached, but also to events or sessions in a certain time interval before the threshold was reached.

Example: If the subscriber spends more than 20 Euros within a month, he receives a discount of 10% for future calls up to the end of the month as well as a discount of 10% on calls made from the beginning of the month to the moment, the threshold was reached (so called “tiered rating”)




Tariff Examples – Accumulators/Counters

Therefore there are balance/counter dependent tariffs.Lower prices are charged in case a threshold is reached

– Minutes called– Sent SMS– Volume Counters– Money spent on calls– …

Notes

Discounts can be based on a number of items.




Tariff Examples – Call Duration Dependent Prices and Bonuses

Additionally there are call duration dependent prices like

• Degressive tariffs• Tariffs with charge free intervalls• The longer the call the more bonus SMS

are accumulated on bonus accounts.• ….

Notes




Tariff Examples – Time related Discounts

Additionally there are special options like:• Discount on subscribers special day.• Discount during “Summertime”, e.g.

July/August.• Discount on calls during Happy Hour.• Loyality program: in case the subscriber is

customer for more than one year, a special price is charged.

Notes



6.2 General Principles of Rating

The following chapter describes how such tariffs can be designed


Data DomainsDynamics

• Tariffs and conditions• Prices and conditions• Bonus, Promotions, Discounts• Surcharges• …

ProductData

• Data constitutingthe price andtariff framework

• Reference to frame contract• Subscription type (e.g. prepaid, postpaid)• Subscriber loyalty status (e.g. gold)• Subscriber personal information (e.g. birthday)• Subscriber accounts and values

(e.g. monetary account, SMS bonus account)• Subscribed options (e. g. free-minute bundle, ….)• …

SubscriberData

• Data from the subscriber database reflecting the subscriber attributes

• Product IDs• Supplementary services, e.g. call forwarding• A-location, B-location• Access Point Name• Time, duration, volume, (QoS)• URL• …

Network Data

• Data delivered by network elements or application servers

Domain Explanation Examples

Notes



6.3 Architecture and Dataflow

Charge@once offers a multitude of interfaces to allow all kinds of network elements connections:

INAP, CAMEL RADIUS GTP, DIAMETER CORBA based plugins

CAMEL ...... Customized Applications for Mobile Network Enhanced Logic CORBA ...... Common Object Request Broker Architecture CSCF ......... Call State/Service Control Function GGSN......... Gateway GPRS Support Node GTP............ GPRS Tunneling Protocol HTTP.......... Hypertext Transfer Protocol INAP........... Intelligent Network Application Part IP................ Internet Protocol IPS ............. Independent Protocol Simulator MMSC ........ Multimedia Messaging Service Center MSC ........... Mobile Switching Center RADIUS ..... Remote Authentication Dial In User Service SGSN ......... Supporting GPRS Service Node SMSC ......... Short Message Service Center SS7 ............ Signaling System #7 SSP ............ Service Switching Point VLR ............ Visitor Location Register WAP ........... Wireless Application Protocol




Interfaces

IP Interfaces

Applic.PlugIn

SS7 interfaces

charge@once

MSC/VLR

SGSNeGGSN /

IPSWeb /WAP

SSP

CSCFAppl /GameServer

HTTPContentServer

MMS-CSMS-C

Notes



charge@once consists of following components:

The service logics are responsible for interfaces to network elements. Charging is responsible to compute the price based on parameters received from rating

and charge account(s) based on information found in a so called charging profile. The charging profile to be used is returned by rating.

Rating is responsible to deliver the input parameters for charging. Balance is responsible to access the accounts.




Architecture of Charging and Rating

Notes




Components Involved

1

IP/SS7 Network Service Logic

Charging Rating

Charging

BalancingCharging

4

5

6

78

3

2

ServiceData

Notes

An overview on the sequence the components are used.

See detailed description on the following pages.




Rating

CORBA• Product• Price• ….

Examples of Data received from Network

1


Charging

Charging

BalancingCharging

4

5

6

78

3

2

INAP• A-Party/B-Party• Location information• VLR-ID• Location Number• Bearer Capability• Quality of service• ….

GTP‘• MSISDN• Service ID• ….

Diameter• SGSN IP• MSISDN• RuleBaseId• MCC/MNC• ….

RADIUS• MSISDN• APN• SGSN Address• ….

Notes

The data delivered from the network can be used for rating.

APN............ Access Point Name CORBA ...... Common Object Request Broker Architecture GTP............ GPRS Tunneling Protocol INAP........... Intelligent Network Application Part IP................ Internet Protocol MSISDN ..... Mobile Station ISDN SGSN ......... Supporting GPRS Service Node SS7 ............ Signaling System #7 VLR ............ Visitor Location Register




Call Handling by Service Logic

1

IP/SS7 Network

Charging Rating

Charging

BalancingCharging

4

5

6

78

3

2

DataBase

Service LogicExample: Service Logic Call Handling• Emergency Call?• First Call?• …

• Determine access variant (Mobile originating call, Mobile originatingcall Roaming, Mobile Terminating Call, SMS, GPRS, USSD …)

• Determine rating relevant data(look up ContractName/AccessVariant/TariffId, check if call is FnFcall, Mobile local call, …)

• Call charging

Notes

This example shows the call handling by a prepaid service.

Service data found is used or can be used for rating:

Mandatory data like contract name, access type (moc, moc roaming, sms …) and tariff of the subscriber.

Optional data like threshold values, lists of FnF numbers, HZ identification ….

The values for contract name, access type and subscribers tariff are sent to charging.

GPRS ......... General Packet Radio Server IP................ Internet Protocol SMS ........... Short Message Service SS7 ............ Signaling System #7 USSD ......... Unstructured Supplementary Service Data




Service to Rating

1

IP/SS7 Network Charging

BalancingCharging

4

5

6

78

3

2

Service Logic

Rating looks up the data assigned to triple„Prov1-Moc-1“ = Rating logic and data.

Charging RatingProv1-Moc-1

Prov1-Moc-1

Notes

Service logic calls charging with “ContractName-AccessType-Tariff”. If this is the first call of charging within this session (or this call is made on behalf of an event), charging calls rating to get the charging relevant parameters.




Rating Logics - Principle

Rating logics

• Determine input parameters to be used

• And map input parameters to output parameters

CalledParty

TimeOfCall

IsFnf

isHz

Threshold

Mapping

Account Balance

Parameter1

Parameter2

Parameter3

Parameter4

….

Parametern

…

Notes

Rating looks up rating logic and assigned rating data.

Rating logics map input parameters to output parameters.

An own rating logic may be available for each accesstype.




IntervallBegin

IntervallEnd

e1

…

e7ChargingProfile

Name

…

ChargeFunction„GSM“

Rating to Charging

1


Charging Rating

Charging

BalancingCharging

4

5

6

78

3

2

Notes

The values determined by the rating logic are returned to charging to compute the price and charge accounts.




Simple Charging Profile – Symbolic Description

Start

Compute price and chargeaccount X using parameters

received from rating

Do not connect the call/do not send SMS

Connect the call/send SMS

Notes

Charging has a set of charging functions (formulas) available as well as a number of charging profiles.

A charging profile defines among other items:

The accounts to be charged. The sequence the accounts shall be used. What to do in case charging was successful or not.

Charging profiles are created using a graphical editor. Various charging profiles may be available:

One for each product or access type. Several for one product.

The ID of the charging profile to be used is returned from rating.




Charging to Balancing

1


Charging Rating

Charging

Charging

4

5

6

78

3

2

Balancing

Subscriberaccount(s)

Notes

Charging tries to deduct money or units from the accounts defined in the charging profile.




Balancing to Network

1


Charging Rating

Charging

Charging

4

5

6

78

3

2

Balancing

Notes

The message “successful” or “not successful” is returned via charging to service and network.



6.4 Enhancements in V7.6


V7.6 Enhancements

With 7.6 following enhancements are available:

• Dynamic accounts – accounts can be added “on the fly” if necessary

• Dynamic data – data can be added on the fly if necessary

• Discounts – basic rating can be enhanced by additional rating logics

• Subscriptions – Subscribers can subscribe to certain options, such as Fnf

• Tiered rating – if a threshold is reached, discounts may be applied not only tofuture calls, but also to calls made in the past. ( may apply also to SMS, Data downloads ….)

• Group structures

Notes

With charge@once V7.6 new enhancements are introduced enabling shorter development cycles and easier introduction of new tariffs.

Service Creation Environment IN@PLATOP (Part 1)


IN@PLATOP (Part 1) Service Creation Environment


7. Service Creation Environment

7.1 Introduction

The SCE is a development environment for the development of services running on the IN@vantage platform.

The SCE supports service designers in all aspects of the service creation process.

Service creation consists of many different tasks, including:

Designing a data model in xml format. Writing the actual program code for a service logic in Java. Creating an installable package ready for deployment.

The SCE provides tools for all these tasks, some of them developed in-house, some as OEM components.

A unified graphical user interface for these tools is provided by the Service Creation Assistant (SCA). It serves as a shell to integrate all required tools into the IN@vantage-specific service creation process. As it generates various code parts and automates common service creation tasks, a service designer can focus on creating the business logic.

An actual program code for the service is also written in SL (Service Language).

SL is better suited for IN services than Java because:

SL is an imperative and procedural language. The SL syntax was tuned to support action/subroutine calls as intuitively and safely as

possible (see below). A more comfortable means to write general purpose code was needed: We decided to

introduce a programming approach and developed a programming language suited for the task SL (Service Language).

SL is very simple with respect to its language constructs. This is because in the IN service domain, we do not need much here.

But SL is very sophisticated with respect to adaptability to changes The entire logistics process (delivery, installation, …) is better because we base flexible

logic logistics on data base changes. A new logic is just another entry in the data base, thus we get versioning, fall back, etc. for free.

Service logics are stored in a library, where subroutines are also stored. Subroutines that are need by more than one logic can be implemented once and used (called) more than once. We call these public subroutines. And if these subroutines use and share other subroutines, that is also possible. We call these private subroutines.

OEM ........... Original Equipment Manufacturer SCA............ Service Creation Assistant SCE............ Service Creation Environment SL............... Service Language

Service Creation Environment IN@PLATOP (Part 1)


7.2 Architecture

The SCE system consists of a tool client and a server connected via TCP/IP (e.g. LAN).

The SCE client is an off-the-shelf standard PC with Windows 2000 as OS Software. Also running on the SCE client are the following:

A validating XML editor for data model design (Borland JBuilder, or, alternatively, Altova XMLSpy)

A Java IDE (Integrated Development Environment) for service design (Borland JBuilder) Custom SCA wizards integrated into JBuilder which offer implementation support for

frequently recurring coding tasks Functionality for performing tests in an offline test environment during service logic

creation (Offline Test Environment (OTE)). Automation of regression tests is supported via a dedicated GUI application (Test Suite Manager (TSM)).

Software to write test scripts for offline testing (XML editor). Trace analysis functionality via the Trace Analyzer as a PlugIn of the Visual SlickEdit. Software to write test scripts for online testing of service logic components (Sim-Script test

case editor, Independent Protocol Simulator (IPS)). Converter to make scripts created for offline tests available for online testing, i.e. to

convert CallSim test scripts to IPS test scripts (Generic XML to IPSL converter (GXI)). A version management system (Rational ClearCase).

The SCE server is a SUN Fire server. It contains:

A compact version of the IN@vantage platform as a test platform, allowing online tests of newly created services on a real environment under authentic conditions.

Tools for the creation of installable service packages, including the Advanced XML tooling (AXT), for the creation of configuration and management files, makefile tooling and a Java compiler.

Service Management and Service Management and Data Access Toolkit (SMAT), which generates various functional component interfaces and their implementations.

AXT ............ Advantage XML Tooling GXI ............. Generic XML to IPSL converter IDE ............. Integrated Development Environment IPS ............. Independent Protocol Simulator IPSL ........... Independent Protocol Simulator Language JDK ............ Java Development Kit LAN ............ Local Area Network OTE............ Offline Test Environment SCA............ Service Creation Assistant SCE............ Service Creation Environment SMAT ......... Service Management and Data Access Toolkit TCP/IP........ Transmission Control Protocol/Internet Protocol TSM............ Test Suite Manager XML............ eXtended Markup Language

IN@PLATOP (Part 1) Service Creation Environment


7-1 © Nokia Siemens Networks IN@OV / Training Center / 2007

SCE Architecture

SCE Server (Solaris)

OGW

SAF

Plat

form

@va

ntag

e(s

ingl

e no

de)

SCE Repository

Versioning

SystemTCP/IP

Trace Analyzer(Visual Slick Edit)

OTE(CTF+Sims)

TSM GXI

Version Management System Client

NFS Client / Samba

IPS (IPSL Tool Package)

rshd

Service Creation Tools

Service Creation Assistant

JBuilder

JDK

optional:XMLSpy

Service Delivery

AXT

Install make

SMAT

javac

nfsd / samba

SCE Client

Notes

@vantage Platform IN@PLATOP (Part 1)


8. @vantage Platform IN@vantage, Prepaid@vantage, Charging@vantage and charge@once are based on the Siemens @vantage platform.

The Siemens @vantage platform offers:

A multi-purpose platform to support service convergence as e.g. fixed, mobile (2G, 2.5G and 3G) and IP networks.

A scalable platform enabling flexible configuration and distribution of hardware and applications.

High connectivity via standardized interfaces into telephone and IP networks. Homogenous operation, administration and management for all types of applications. Efficient development environment for short-term introduction of new applications.

The network elements realized so far based on the @vantage platform are:

Service execution point (SEP) of IN@vantage supporting the IN service applications (PPS, PPD, VPN, FPH, PRM, UAN, VOT, and many more)

Payment execution point (PEP) of Payment@vantage V1.2 Home location register innovation V1.1

Please note that not all features of the @vantage platform are used by all network elements. This means that the fact that a feature is available in the @vantage platform doesn’t imply that it is also available/used in a network element based on the @vantage platform. However it may support a respective feature or functionality in the application.

CSCF ......... Call State/Service Control Function FPH ............ Free Phone Service HLRi........... Home Location Register Innovation HSS............ Home Subscriber Service NTS ............ Number Translation Service OEM ........... Original Equipment Manufacturer OMIP .......... Open Mobile Internet Platform PEP ............ Payment Execution Point PPD............ PrePaid Data Service PPS ............ Prepaid Service PRM ........... Premium Rate Service RTP ............ Resilient Telco Platform SEP ............ Service Execution Point TSP ............ Telco Service Platform UAN ........... Universal Access Number Service VOT............ Tele Voting Service VPN............ Virtual Private Network

IN@PLATOP (Part 1) @vantage Platform



@vantage Platform – Software Architecture

Hardware

Telco Service Platform (TSP7000)

Service ApplicationFramework

Common Application Framework

RTP OEM SW

PPS

VPN

NTS

VOT

HLR

i

HSS

, CSC

F

Cha

rgin

gLo

catio

nEn

ablin

gSe

rver

Geo

Tool

Box

(OM

IP)

Pres

ence

Man

ager

(OM

IP)

3rd

part

y ap

plic

atio

ns

@va

ntag

e pl

atfo

rm

App

licat

ions

Hos

ted

3rd

part

y ap

plic

atio

ns

Onl

ine

Cha

rgin

g

Mob

ile S

essi

on M

anag

er

Mob

ile S

mar

t Pro

xy

Notes



8.1 Software Architecture

The @vantage platform is composed of:

The Telco Service Platform 7000 (TSP7000) consisting of a highly scalable, reliable multi-vendor hardware, the operating system and integrated third party software as e.g.: cluster software, communication stacks, database, Resilient Telco Platform (RTP).

The Common Application Framework (CAF) consisting of a development environment to support programming of highly available applications. CAF provides a component framework and a programming model, various platform components and OAM functions. This functionality is provided as a set of libraries and covers, e.g., user management, logging, ticketing, etc.

The Service Application Framework (SAF) providing a service logic execution environment for developing and executing service logics.

Every layer provides an application programming interface (API) to its users, i.e. to the layer above as can be derived from the following figure:

API ............. Application Programming Interface CAF ............ Common Application Framework FSC ............ Fujitsu Siemens Computer HLRi........... Home Location Register Innovation PEP ............ Payment Execution Point RTP ............ Resilient Telco Platform SAF ............ Service Application Framework SEP ............ Service Execution Point SMAP ......... Service Management Access Point TSP ............ Telco Service Platform




@vantage Platform - Software Architecture

Service Application Framework

SUN Solaris FSC Solaris FSC Rel.UNIX

Common Application Framework

Applications

Platform API¦ 3rd Party Software

(DB, RTP, Communication)¦ Operating System¦ Hardware

IN services or other applications based on the respective network elements (SEP, SMAP, PEP, HLRi, …)

CAF API¦ User Management¦ Logging¦ Ticketing¦ …

SAF API¦ Service Creation

Environment¦ Service Logic Execution

Environment

integrated 3rd party software

TSP

7000

@va

ntag

e pl

atfo

rm

Notes



8.2 Hardware Architecture

Hardware Redundancy within each Node

Power supply, dedicated disks, I/O controller, cabling, …

Cluster Interconnect

Fully meshed net between nodes and LAN switches Based on Gigabit Ethernet and cluster internal LAN switches

(maximum cable length 525 m)

Oracle Parallel Server Database

Fiber channel connection to all nodes (maximum cable length 525 m) Common database cache of all nodes Synchronization via high-sophisticated cache coherency mechanisms

FSC ............ Fujitsu Siemens Computer LAN ............ Local Area Network




TSP7000 - Cluster Interconnections

Cluster interconnect

2-Node Cluster (SUN/FSC)

LANswitchNode Node

DB

Fiber channel

Notes



8.3 Cluster Architecture

A state-of-the-art method to achieve the targets of availability and scalability is the combination of several hosts to one system.

The resulting system is named cluster, the single hosts are named nodes.

From the outside, a cluster is seen as one single system, independent of the fact that it may consist of multiple hosts. This leads to an efficient management of the system, by hiding the complexity of the configuration to the person administering it or developing applications on top of it.

The following hardware configurations of different vendors are supported by TSP7000:

Hardware Operating System Cluster Software

Fujitsu Siemens Corporation PRIMEPOWER Solaris PrimeCluster

SUN Microsystems SUN Fire Solaris SUN Cluster

The nodes of a cluster are glued together by various cluster components, i.e. they are connected to each other and share resources within the cluster. Their proper configuration is vital with respect to stability and high performance of the cluster. The main connection between the nodes is the Cluster Inter-Connect which is a private network for inter process communication within the cluster. Further, a cluster can be connected to several LANs.

A core LAN, the main LAN at the customers site An administration LAN connects the cluster to a cluster console A LAN to connect the cluster to Backup and Restore servers Project-specific networks

A central cluster resource is shared storage. In the TSP7000, the shared storage is used by the Cluster File System and the Cluster Database.

Cluster File System allows file systems to be mounted concurrently and coherently on every cluster node. They can be accessed as if they were mounted locally.

The database is a central software component to achieve persistent data storage within the cluster. It contains platform configuration data, as well as sensitive dynamical data, e.g, to store the state of certain processes.

LAN ............ Local Area Network TSP ............ Telco Service Platform




TSP7000 - Cluster Architecture

Database

node 1

OperatingSystem

Hardware

node 2

OperatingSystem

Hardware

Further Integrated & Enhanced 3rd Party Products

Cluster Package

Cluster File System

Resiliant Telco Platform

Notes



8.4 Functionality of TSP7000

The Telco Service Platform TSP7000 is the basic layer of @vantage.

Integration and encapsulation of 3rd party hard- and software products. Provision of the single system image of complex cluster configurations concerning

development and OAM of TSP7000 applications. Enabling of highest availability. Enabling of a high scalability concerning availability, performance and load.

TSP7000 may be seen as multi-vendor hardware and a high-availability operating system with integrated add-on functionality like database, communication stacks and development tools.

The TSP7000 has an open systems architecture based on SPARC or Risc machines with UNIX (SUN Solaris or Reliant UNIX) operating system (OS) and corresponding cluster software (SUN Cluster or Prime Cluster) which communicates via the Cluster Interconnect (CI). The functionality is provided by TSP7000 components integrated with state of the art third party products such as the Ulticom Signalware™ (SS7) stack, Oracle Database (OPS), Apache Webserver (Web), SUN Java Servlet Engine (JSE), and the EMANATE SNMP package. Currently, ULTICOM’s Signalware SS7 protocol stack product is certified for use with RTP.

The TSP components originally purchased from FSC have been widely extended (TSP add-ons) and modified to meet the requirements of @vantage. The next slide shows the amount of modifications, indicated by the color of the boxes (yellow = original OEM product, orange= SN product).

TSP add-ons comprise new components such as the Account Manager, the Online Counter, single-system image FT-processes, and new Context Manager processes to realize the GPRS-Always-On features Rare Context Replication and the Context-On-Disk.

Availability summarizes the Node/Communication/Process Management, Context Management, Timers, and the Event and Alarm handling. The Node Management provides Graceful Shutdown functionality.

Tools include the trace management and the ticket management. Both fulfill IN compatibility requirements (e.g. ticket naming, GOB).

The scalability aspects are covered by dispatcher processes, load balancing algorithms, and the Communication Management.

Admin stands for local and remote TSP platform administration interfaces (GUI, CLI).

The TSP7000 functions are accessed via a uniform interface, the TSP API which provides a single system image to the software application.

API ............. Application Programming Interface CI................ Cluster Interconnect CLI ............. Calling Line Identity GOB ........... “Grundsätze ordnungsgemäßer Buchführung” GPRS ......... General Packet Radio Server JSE ............ Java Servlet Engine OAM ........... Operating, Administration & Maintenance OEM ........... Original Equipment Manufacturer OS .............. Operating System RTP ............ Resilient Telco Platform SNMP ......... Simple Network Management Protocol SS7 ............ Signaling System #7 TSP ............ Telco Service Platform




TSP7000 - Architecture and OEM Products

Operating System

Cluster Software

RTP Java Admin

Platform API (Single System Image)

VolumeManager WEB SNMP

IP Connectivity Database File TransferSS7 Connectivity

ScalabilityFunctions

ToolFunctions

@vantage SpecificFunctions

AvailabilityFunctions

OEM ProductExtended OEM Product

Hardware

Configuration

and Installation

@vantage @Platform

Notes

Operation and Maintenance IN@PLATOP (Part 1)


9. Operation and Maintenance In this chapter, the topic Operation and Maintenance is covered.

The @commander Server is providedfot tasks such as Performance Monitoring, Process Management, User Management and so on.

The operator uses the features provided by the @vantage Commander Server via clients, which are standard PC's with client software installed.

9.1 Introduction

The main objective of an efficient Operation, Administration & Maintenance (OAM) concept is a convenient day-to-day system operation and supervision which allows for a stable running in general.

For OAM issues, the @vantage Commander is the central element manager for the entire IN@vantage product family. That means that all INXpress network elements can be controlled and monitored through one interface, thus reducing additional administration, operation and training costs.

However, if the @vantage Commander fails, a web-based interface, LEMAF, is available for basic administration tasks.

OAM features provided for IN@vantage/Charging@vantage/charge@once are:

Configuration Management Performance Monitoring

Observation of system behavior such as CPU load, incoming & outgoing payment requests etc.

Fault Management In case of abnormal system behavior – e.g. failing connections to external systems - alarms are raised and displayed at the Commander.

Backup and Restore

The data safeguarding of software and data is part of the Backup and Restore concept.

LEMAF ....... Local Element Management Access Function OAM ........... Operation, Administration & Maintenance

IN@PLATOP (Part 1) Operation and Maintenance



@vantage V7.6 OAM

Interfaces

Fault Management

Configuration Management

Performance Monitoring

Security Management

Further Features

LEMAF

Notes



9.2 Interfaces

The northbound interface offers connections to

A network management center via SNMP protocol to forward events An e-mail server to forward events via e-mail A remote host to transfer files via FTP

The southbound interface offers connections to the @vantage cluster to

Receive traps via SNMP Receive performance monitoring data via UDP Get administrative access via CORBA

CORBA ...... Common Object Request Broker Architecture FSC ............ Fujitsu Siemens Computer FTP ............ File Transfer Protocol SMTP ......... Simple Mail Transmission Protocol SNMP ......... Simple Network Management Protocol UDP............ User Datagram Protocol




NorthboundInterfaces

Southbound Interfaces

@vantage Commander Server

SNMP SMTP FTP

Oracle DB

Northboundinterfaces

FaultManagement

ConfigurationManagement

Backup&Restore

PerformanceManagement

SecurityManagement

SUN Cluster 3.0

SUN Solaris 8

SUN Fire

Prime Cluster 3.0

SUN Solaris 8

FSC Prime Power

SNMP CORBA UDPCommunication with NE agents

Interfaces

Notes



9.3 Fault Management

9.3.1 Architecture

All alarm events of the NEs are forwarded to the fault management application of the @vantage Commander. It provides the following functions from the operator’s point of view:

Event display Allows the operators the monitoring and processing of alarm events. Event filters can be defined and applied to reduce the amount of visible alarm events. Additional event information (e.g. long and repair texts) can be displayed. Single events can be printed to spool printer or forwarded manually to e-mail addresses.

Event preprocessing Comprises the alarm escalation (static event translation) as well as dynamic event suppression and alarm compression.

Alarm reset correlation Provides the automatic clearing of alarm events in case of ceased alarm conditions according to predefined correlation rules.

Alarm catalogs Loaded from NEs and can be browsed and printed at the @vantage Commander.

Alarm statistics/analysis (Event post-processing) Shows statistics over all or selected network elements in tabular or graphical form.

Alarm log file handling Provides audit mechanisms in order to limit the total number of stored alarm events. Confirmed alarm events will be deleted from the event DB when a certain threshold is reached. This threshold depends on the capacity of the event DB. The database typically holds the events of several months. Approaching this threshold is signaled by an event.

Event forwarding Provides the automatic forwarding of alarm events to the various destinations such as alarm printers, e-mail addresses and external operations systems (Northbound Interface, respectively OS) in parallel. The amount of forwarded events could be reduced by event forwarding discriminators. The forwarding interface to the OS supports alarm synchronization and clearing of alarms.

Reliable event transmission Assures the reliable transmission of alarm events from the NEs to the @vantage Commander as well as from the @vantage Commander to an OS.

DP .............. Data Base FTP ............ File Transfer Protocol NE .............. Network Element OS .............. Operating System SNMP ......... Simple Network Management Protocol




IN@vantage - Fault Management

IN@vantage NE

SNMP,FTP

@CommanderServer

IN@vantage NE

@CommanderClient

@CommanderClient

@CommanderClient

IN@vantage NE

Notes



9.3.2 Fault Management GUI

The @vantage Commander’s fault management GUI displays the current events.

If an alarm event occurs on an NE, a notification is sent to the FM application of the @vantage Commander.

Alarm events are displayed on a central Graphical User Interface (GUI) but can also be forwarded to various destinations like external Operating Systems, alarm printers or e-mail addresses.

Different severity levels ensure a customizable handling of alarm priorities.

FM .............. Fault Management NE .............. Network Element




Event Browser

Fault Management

Notes



9.3.3 @vantage Commander Configuration Management GUI

Via this dedicated interface you are able to perform the following:

View configuration data. Change configuration data on the fly. Download configuration data from IN@vantage network element to @vantage

Commander server. The configuration data will be stored in ASCII files using an xml format.

Export configuration data, i.e. copy the data to the @vantage Commander client. Import data from client. Upload data from @vantage Commander to IN@vantage network element and activate it. Compare configuration data.




@vantage Commander Configuration Management GUI

Notes



Configuration data can be downloaded from an @vantage cluster to the export pool on the @vantage Commander server.

From the export pool, it can be exported to the @vantage Commander client or any other remote host.

The data can be modified and imported into the import pool of the @vantage commander server.

From the import pool, it can be uploaded to the @vantage cluster, where it is automatically activated.

You will find all or some of these features also in other applications such as User management and security management.




Configuration Management

importexport

upload download

@Commander ServerImport/Export Pool

@Commander Client

IN@vantage NE

Notes



9.4 Performance Monitoring

9.4.1 Architecture

The PM capabilities allow the online monitoring of various aspects of one or more network elements. The performance data may be filtered, analyzed and displayed in a number of views. The performance data are collected at the NE by PM agents and periodically forwarded to the @vantage Commander via UDP datagrams.

Performance monitoring application provides the following functions: Online monitoring of performance data via a graphical user interface (monitoring view) Visualization of historical performance data via a graphical user interface (historical view) Online supervision of performance objects via a state display (state window) Graphical user interface to filter, display and analyze performance monitoring data in a

variety of visual presentations. Threshold definition and visualization

A network operator may administrate performance thresholds. The thresholds are visualized in PM GUI. If the threshold is reached, an alarm is raised. The alarm is automatically reset if the performance value falls back below the threshold.

Online user manual and context help for performance objects For each performance object, a help text describing the meaning of the performance object is provided.

Export of collected performance data to an external OS via FTP only.

FTP ............ File Transfer Protocol NE .............. Network Element OS .............. Operating System PM.............. Performance Monitoring UDP............ User Datagram Protocol




IN@vantage - Performance Monitoring

IN@vantage Network element

UDP

@Commander



@CommanderClient

@CommanderClient

@CommanderClient

Notes



9.4.2 Performance Monitoring GUI

Performance Monitoring has two main purposes:

The detection of system bottlenecks to take appropriate curative actions and prevent system crashes.

The detection of problems within the call activity.

Performance Monitoring is an IN @vantage application. It is used to monitor the performance of the @vantage environment and emit alarm events if threshold values are exceeded. The Performance Monitoring is provided with a functionality that allows the @vantage Commander user to receive performance data from all NE (Network Elements) within the @vantage environment. These data are collected for each host.

The Performance Monitoring is a graphical application which allows monitoring of various aspects of one or more clusters. The captured data may be filtered, analyzed and displayed in a number of views.

One of the design goals of Performance Monitoring was to keep the resource demands placed on the cluster nodes to an absolute minimum. To this end, the Performance Monitoring Agent process, which runs on a cluster, sends datagrams at regular intervals. This design avoids the need for the more connection-oriented client/server implementation and allows the PM application to dynamically detect clusters which may then be monitored.

@vantage Performance Monitoring is an application:

which does not require detailed knowledge of the cluster architecture in question that can be used for immediate and effective vertical detection of a broad spectrum of

problem zones on customers living and/or test systems which inflicts only a minor performance penalty on call processing which can manifest itself in a variety of visual representations (graphical, numerical) which seamlessly integrates any number of clusters onto the @vantage Commander GUI

desktop

Various modes to display the data are provided.

PM.............. Performance Monitoring




Main Window

Description

Previewer:values of selected Performance Objects

PM Explorer TreeNavigator

@vantage Commander Performance Monitoring GUI


Graph Windows

Selected Objects

Performance Monitoring



9.5 Security Management

The SM (Security Management) is used to enable the supervision of the security of the @vantage Commander. It provides the following:

User Management, Log Management, Key Administration and Password handling.

Via the User Management users and roles can be created, modified and deleted. The roles are assigned to the users and specify the rights of the users.

All security-relevant and configuration-relevant user actions and system processes are continuously logged. Via the Log Management, they can be displayed and exported to external destinations.

The Key Administration of the @vantage Commander contains the handling of @vantage Commander secrecy keys (for encryption/decryption) and integrity keys (for data integrity protection).

The password handling comprises dialog boxes with the login data and for changing the user password or the password of another user.

The User Management consists of two parts:

Defining roles. Roles are assigned permissions to access applications such as configuration management, security management, fault management and backup and restore.

Defining users. Users are assigned roles.

The User Management is used to create users. It allows to you to perform the following:

Define user names Define passwords Define expiration dates Display faulty login attempts Assign roles to a user Display the applications a user is currently using.

Users can also be created using text files in XML format.

Such text files may be created on the @vantage Commander client and imported to the @vantage Commander server.

SM.............. Security Management




Access RightsNoneReadWriteExecute

RoleManagement

Assignment of tasks and access rights to roles

Security Management (1)


Assignment of roles and map to user

Configured Roles

Configured Maps

UserManagement

Security Management (2)

Disaster Recovery IN@PLATOP (Part 1)


10. Disaster Recovery

10.1 Architecture / Solution Summary

The solution to enhance the availability of a service, even in case that an entire cluster crashes, is the provisioning of a standby cluster (referred to in the following section as “secondary cluster”).

The secondary cluster is situated far away of the primary cluster. The distance between primary and secondary cluster can be hundreds or even thoudsands of km. One secondary cluster usually accounts for a number of primary clusters (up to 9).

By default, the secondary cluster runs a “rescue service”. −− The rescue service provides basic service functionality that is sufficient to guarantee

service availability for the subscribers. −− The rescue service doesn’t have access to any accounts. It writes tickets for each call

for processing at a late date. The rescue service is activated automatically and can step in for a broken primary cluster within a couple of seconds.

The secondary cluster can also take over “full service functionality” for one primary cluster. −− Full service means that the same service with all features that was originally running on

the primary cluster is activated on the secondary cluster. −− This includes access to all service and subscriber data. −− As a prerequisite, all data changes on the primary clusters have to be continuously

replicated to the secondary cluster. −− When taking over full service on the secondary cluster the database-including all

service and subscriber data of the broken primary cluster-needs to be activated. −− This may take some time (up to approx. 2-3 hours in large configurations), so the

rescue service is typically used in the meantime to gap this time frame and provide continuous service availability to the subscribers.

FSC ............ Fujitsu Siemens Computer RM.............. Recovery Manager

IN@PLATOP (Part 1) Disaster Recovery



Operational Improvements Disaster Recovery*

Secondary Cluster (Rescue Service)

PrimaryCluster 1

PrimaryCluster 5

PrimaryCluster 9

PrimaryCluster 4. . . . . .

. . . . . .

Motivation– Ensure permanent service availability even in case of huge disaster (earthquake, flood...)

Description:– One secondary cluster provides the rescue service for up to 9 primary clusters– The secondary cluster may take over full service of one primary cluster

Data replication fromprimary to secondarycluster

*Feature not supported byconfigurations based on RM600

Notes



10.2 Detailed Description

In this chapter, the necessary system preparations for disaster recovery, as well as the operational steps in the event of a failure leading to disaster recovery measurements, are described.

However, since every network operator’s infrastructure is different, a dedicated emergency plan needs to be developed between the network operator and service staff. This emergency plan describes the decisions to be taken and tasks to be accomplished after the loss of a primary cluster.

IN@PLATOP (Part 1) Disaster Recovery



Operational ImprovementsDisaster Recovery* - Summary

Regular Operation

Auto. switch over to Rescue Service

Crossover Phase

Setup of Primary and Secondary Cluster

Manual switch over to Full

Service

Set up of New System / Repair of

Faulty One

Switch-back

InstallationPhase

Recon-struction

Phase

Data Replication fromPrimary Clusters to Secondary Cluster

Data Replication of other PrimaryClusters continues

Secondary acts likePrimary - No Data

Replication

Operational Steps forDisaster

Recovery

A Primary Cluster fails

Operator Decision

Disaster RecoveryConcept: operational steps in case of disaster

*Feature not supported by configurations based on RM600

Notes



The different operational steps and the tasks and behavior of primary and secondary cluster in each stage are as follows:

Operation Mode Primary Cluster Secondary Cluster Data Replication Remarks

Installation Phase (in)active inactive inactive set up of primary and secondary cluster. Setup of data replication can be done with the primary cluster online (preferably at times of low traffic)

Regular operation active rescue service as fall back

active (all primaries) continuous data replication to secondary cluster

Switch over to rescue service

inactive rescue service active (remaining primaries)

failure reported to operator console

Switch over to full service

inactive becoming active Recovery service processes tickets written by rescue service

stopped switch over to full service initiated by operator

Reconstruction Phase

inactive / repair or replacement

active, full service stopped Repair / replacement of faulty primary cluster

Fail-back Phase resuming full service – active Recovery service processes tickets written by rescue service

rescue service as fallback

active fail-back initiated by operator / service staff – supported by @vantage Commander

IN@PLATOP (Part 1) SMAF


11. SMAF

11.1 Introduction

The Service Management Access Function (SMAF) offers Network Operators and Service Providers access to the service and service subscriber management functionality.

The SMAF provides generic (service-independent) and dedicated (service-dependent) functions of service management access and service management, i.e. the provision of access to service data and service subscriber data. Network Operator/Service Provider (project) specific service management applications can be built on top of the generic functions.

The SMAF is a mandatory function, which is integrated into the Service Execution Point (SEP)

11.2 Function Split

The Service Management architectural concept is based on the following function split:

Service Management Access Function (SMAF) Providing the customer access to the SMF and SDF via different external interfaces of the IN@vantage, Prepaid@vantage, Charging@vantage, or charge@once system:

−− Web GUIs (based on HTML) −− CORBA interfaces (via IIOP) −− Batch file interfaces (based on FTAM)

The SMAF controls external system access via secure user authentication.

Service Management Function (SMF) Providing the core service management functions independently of the presentation/access via the external interfaces

SMAF IN@PLATOP (Part 1)


As such, the SMF includes the (service management) business logic. Access to service management features is controlled via user roles, tasks and function rights.

Service Data Function (SDF) Providing transaction based efficient access to service data instances (modeled as service Persistent Data Objects). Provides access to the SEP DB.

Ticketing Function (TkF) Providing confirmation tickets on specific service management events (creation, modification, deletion of objects).

Providing customer access to SMF is the basic SMAF functionality that is realized by following interfaces:

GUIs (via HTML/WML over HTTP) for user interactive administration CORBA interface (via IIOP). batch file interface (via FTAM/FTP) for automated processing, e.g. of mass data

CAP............ CAMEL Application Part CORBA ...... Common Object Request Broker Architecture DMAF ......... Distribution Management Access Function FTAM ......... File Transfer, Access & Management FTP ............ File Transfer Protocol HTML ......... Hypertext Markup Language HTTP.......... Hypertext Transfer Protocol IIOP ............ Internet Inter-ORB Protocol INAP........... Intelligent Network Application Part LMAF ......... Local Management Access Function MAP ........... Mobile Application Part POP3.......... Post Office Protocol Version 3 SCF ............ Service Control Function SDF ............ Service Data Function SEP ............ Service Execution Point SMAF ......... Service Management Access Function SMF............ Service Management Function SMTP ......... Simple Mail Transmission Protocol SNMP ......... Simple Network Management Protocol TkF............. TicketFunction




Integrated SMAF

SEP DBSCF

Service ControlFunction

SMF *)Service Management

Function

SMAF *)Service Management

Access Function

TkFTicketing Function

*) same functionality as inconfiguration with SMAP

SEP related

SEP

FTAM

CORBA, HTTP, FTAM

INAP, CAP, MAPOnline IF, POP3, SMTP,

HTTP, SNMP


Customer Access to SMAF

Batch fileInterface

FTAM/FTP

SMAFService Management

Access Function

SMFService Management

Function

CORBA

CORBA

GUI InterfaceHTMLbased

SMAF IN@PLATOP (Part 1)


11.3 Service Management Application

The Service Management Application provides the necessary parameters.

11.3.1 Service Management Login Screen

To authenticate a user, a username and a password has to be entered in the “Login Screen”.

11.3.2 Service Data Administration

The logged-in user is able to administrate chosen service data (dependent on the roles assigned to the user).

Apart from the Data Model for service design, in V 7.6 there also exists the so-called Generic Data Model (GDM). The GDM is a very sophisticated model for subscriber data. It is encapsulated in the Generic Access, accessible via FLER like other Generic Access Variables.

GDM........... Generic Data Model FLER.......... Flexible Logic Editor for Rating




Service Management - Login Screen


Service Management – Service Data Administration

Ticketing IN@PLATOP (Part 1)


IN@PLATOP (Part 1) Ticketing


12. Ticketing Tickets document all of the relevant occurrences happening during operation of charge@once, IN@vantage, Prepaid@vantage or Charging@vantage (pay@once). The tickets are mainly used for the following purposes:

Statistical evaluation e.g. to perform the following: −− Evaluate service acceptance −− Portfolio optimization by adapting the service offering −− Optimize resources −− Enhance customers’ loyalty

Fulfillment of legal regulations concerning orderly book keeping and documentation Billing of postpaid subscribers Clearing between the involved parties (e.g. network operator and merchants, network

operator and payment service provider) Provision of itemized information on charged services Crosscheck with other systems

In general, tickets supply network operators and service providers with information about service usage. Tickets can track management operations as well as quality and usage of services and network resources. By evaluating the ticket data the service providers are able to decisively improve the acceptance and quality of the offered services. The Service Control Function (SCF) as well as the Service Management Function (SMF) may cause a large amount of tickets to be written. The tickets are aimed at describing the current context of a call, a transaction or an SM action (e.g. creation or deletion of a subscriber record) at a particular time. They contain a marker of the action, the timestamp when the action was performed and action-specific data. These tickets are sampled and collected after reaching a size or a time threshold. The ticket file is written by using @vantage platform methods explained further on.

SCF ............ Service Control Function SMF............ Service Management Function



12.1 Introduction

The network elements write tickets according to the respective needs of the applications. These tickets are stored in the ticket pool of the network element. They stay there until they are retrieved by an external system, which deletes the files on the network element after having successfully received them.

The TkF is responsible for the contents of the fields and the point in time when the tickets are to be written. Depending on the use cases, service management-related services use SDF to write so-called “confirmation tickets”. Call processing-related services use the TkF directly to generate call-, confirmation-, and service logic counter tickets. The TKF maps the predefined ticket types onto the ticket pool of the TSP. Without using the TKF, an application has to configure the TSP ticket pool by its own. The TkF offers a predefined set of ticket types with a well-defined set of layout variants respectively formats:

Call tickets NOP Counter tickets Service Logic (SL) Counter tickets Confirmation tickets

The TkF allows the writing of tickets explicitly under the control of an application (see the slide). The Ticket Manager of the TSP Layer provides a C-API interface. Using this interface, the application may identify one of a configurable set of ticket pools by mapping its ticket types onto this pool (CE1, CE2, CEn pool). The content is transparently handled by the platform. The API prepares messages from the ticket records which are then sent to a ticket process responsible for storing the tickets into the ticket pools.

E.g. ticket files are located in: /global/TspTicketpool/cft

resp. /global/TspTicketpool/cat

Example of CE pools: cat.clust02.20050211153026.20050211153526 cft.clust01.20050211123500.20050211124000

The policies for each ticket pool are specified by TSP configuration parameters.

An external customer system may retrieve the ticket information via FTAM/FTP.

C-API ......... Common Application Programming Interface FTAM ......... File Transfer Access & Management FTP ............ File Transfer Protocol IPC ............. Inter-Process Communication NOP ........... Network Operator RTP ............ Realtime Transport Protocol SL............... Service Logic TkF............. Ticketing Function TSP ............ Telco Service Platform




Tickets Creation

local ticket file RTP node

CEn pool

CE2 pool

CE1 pool

Ticket Pool (cluster file system or

shared disk)

RtpTicWrite

IPC messages

Application 1

Ticket Manager

Application 2 Application n

Notes



12.2 Phases of Ticket Handling

These files are automatically closed at the NE after either a configurable time, a number of contained tickets, or a configurable file size. In case of low disk space, an alarm is initiated. Empty ticket files can be suppressed if required (default: no suppression, see parameter (Rtp/Tic/WriteEmptyFiles in /RTP Add-on/). These “ticket manager” function moves ticket files to the central ticket pool. Ticket files are generated locally on the nodes of a cluster. Closed files are moved into the ticket pool and renamed.

During the installation, the names of the system path (Sun cluster) or shared disk (FSC cluster) are defined for the ticket pool.In this directory, ticket type-specific files are stored in ticket type specific subdirectories.

Storage of ticket files means that the local file is transferred to another directory. There is no postprocessing (merge etc.) in between. Therefore, files in the subdirectory of the central pool are all tickets of a certain type, but each ticket file contains only tickets from one node. Ticket files can be accessed by external applications via a FTAM-Client connected to the FTAM-Server on the Charging Server. In the standard product configuration of the charging system such as ABC, a ticket file on the ABC server is deleted implicitly by the FTAM-Server after a succesfully completed transfer. As an alternative, FTP can be used as the transfer protocol. Furthermore, ticket files are not included in the standard backup and restore concept of the ABC server.

The evaluation of ticket files is not part of Siemens applications. Nevertheless, ticket files must be retrieved regularly from the Charging Server because all ticket files have a limited lifetime. If the available limit of the ticket file pool size is reached, the oldest ticket file will be overwritten by the RTP Ticket Manager (to guarantee a permanent system availability). An alarm is generated at a level of 75% of the maximum ticket pool size (default value). The generated alarm cannot be disabled.

Note: it is recommended that all ticket files be retrieved within 1 day. For emergency reasons, ticket files are stored for a maximum of 5 days.

ABC ........... Administration and Billing Center FSC ............ Fujitsu Siemens Computer FTAM ......... File Transfer, Access & Management FTP ............ File Transfer Protocol RTP ............ Resilient Telco Platform




Phases of Ticket Handling

executed by the network element executed by the external system

Initiation

Format Selection

DataCollection

Binary orASCII

Project specific

Filename

Directory

Fileswitch

FTAM Ordering

Generation Formatting Storage Transfer Evaluation

Notes



12.3 Ticket Formatting

1. The application collects the content of the ticket in an internal buffer.

2. The product formatter writes the ticket in a product specific format (binary or ASCII).

3. A project-specific formatter may write the tickets in an arbitrary format, e.g. ASN.1.

4. The tickets are stored in a ticket pool for collection by an external system.

Example 1: Usually, the statistic tickets are translated from binary format into readable text format ASCII, using the TCONV tool and the files are copied into the configured ASCII Output Directory. Example 2: Here the confirmation ticket is translated via TCONV into the ASCII readable format: cft.clust02.20050127152208.20050127153747 --- ticket header Version 33 TicketType 6 (Confirmation Ticket) RecordLength 252 TimeStamp 2005.01.27 15:22:08 TimeZone 1 AssignmentTreeInformation 3-1-1-11 AssignmentTreeNode 1061143662012002 LogicalNEAddress CE1Name CorrelationType 0 CorrelationID 0x7FE78EA700000000000000013C315E700400 TicketSequenceID 0 DisconnectBFlag 0 --- ticket body ConfSwitch 0x400001FF ConfType 7 CallingParty 43662012002 LoginType 0 EventCause 2...




Ticket Formatting

Application

Formatter(Product)

Ticket Pool

Network Element

binary ASCII arbitrary format

Formatter(Project)

Notes



12.4 Ticket Scenarios

Event & session charging via #7 All scenarios are covered where the events or sessions to be documented are provided to the IN and/or charging system via the #7 service logic. This applies e.g. for voice calls, GPRS sessions (via CAP3), sending of SMS (via CAP1 or CAP3).

Administration Administrable actions are documented. This actions may be initiated either via one of the SMAF interfaces (GUI, batch, Corba), by a call (e.g. dialed access for DTMF menu; in this case additionally a #7 ticket is provided) or by other means. Examples are: creating, modifying, deleting subscriber data, recharging a prepaid account, switching a flag via DTMF menu.

Service logic counters Service specific occurrences are documented by counting them. This applies e.g. for the use of a specific service feature.

Network operator counters This scenario is similar to scenario 3. However, service independent occurrences are counted either system wide, service specifically or even for a more specific entity. A typical example is the number of successful calls.

Event charging via payment PlugIn The charging of events is documented, which are communicated to the charging system by using the payment PlugIn.

Event charging via RADIUS (Web/WAP Proxy) The charging of an event is documented, which is communicated to the charging system by a Web/WAP Proxy (e.g. Mobile Smart Proxy, MSP) via the Radius interface.

Event charging via Radius (MMSC) Herewith the charging of an event is documented, which is communicated to the charging system by a Multimedia Messaging Service Center (e.g. Ericsson MMSC) via the RADIUS interface.

Session charging via RADIUS (Policy Router) The charging of a session is documented, which is communicated to the IN and/or charging system by a Policy Router (e.g. the Cisco Service Selection Gateway, SSG) via the Radius interface

Hot Billing If an application which wants to initiate charging requests isn’t (yet) able to initiate online requests by using the payment plug in or the Radius interface, it may deliver data records containing the necessary information to charge the appropriate accounts. The handling of these data records also may be documented in tickets. For this scenario tickets are defined project specifically.

CAP............ CAMEL Application Part CORBA ...... Common Object Request Broker Architecture DTMF ......... Dual Tone Multi Frequency GPRS ......... General Packet Radio Service MMSC ........ Multimedia Messaging Service Center MSP ........... Mobile Smart Proxy RADIUS ..... Remote Authentication Dial In User Service SMAF ......... Service Management Access Function SMS ........... Short Message Service WAP ........... Wireless Application Protocol




Ticket Scenarios

Event & Session Charging via #7

Administration

Service Logic Counters

Network Operator Counters

Event Charging via Payment PlugIn

Event Charging via RADIUS (Web/WAP Proxy)

Event Charging via RADIUS (MMSC)

Session Charging via RADIUS (Policy Router)

Hot Billing

Notes

Documents

NSN in@Vantage