NSN In@vantage

Nokia Siemens Networks IN@PLATOP Part 1
Course Documentation 2007
Copyright 2007 Nokia Siemens Networks All rights reserved
Page 1
IN@PLATOP (Part 1)
Training Center for Charging & Care Responsible: Helmut Lffler Nokia Siemens Networks Phone: +49 89 636 50292 email: helmut.loeffler@siemens.com 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.
Page 2
IN@PLATOP (Part 1)
Content
Content
1. 2. 2.1 2.2 2.3 2.3.1 2.3.2 2.3.3 2.4 2.5 2.5.1 2.5.2 2.5.3 2.6 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.6.6 2.6.7 2.6.8 2.7 2.8 3. 3.1 3.2 3.3 3.3.1 3.3.1.1 3.3.1.2 3.3.1.3 3.3.1.3.1 3.3.2 3.3.2.1 3.3.2.2 3.3.2.3 3.4 4. 4.1 4.2 4.2.1 4.2.2 4.2.3 4.2.3.1 4.2.3.2 4.2.3.3 4.2.4 4.3 Product Structure..........................................................................................1-6 IN@vantage ...................................................................................................2-8 IN@vantage Integration ..................................................................................2-8 Overview of IN Services................................................................................2-10 Number Translation Services........................................................................2-12 Freephone.....................................................................................................2-12 Premium Rate ...............................................................................................2-14 Universal Access Number.............................................................................2-16 Multi SIM .......................................................................................................2-18 VPN...............................................................................................................2-22 Private Numbering Plan ................................................................................2-24 Member Types ..............................................................................................2-24 Call Types .....................................................................................................2-26 Mobile Centrex ..............................................................................................2-28 Mobile Centrex Use Case .............................................................................2-28 Architecture Overview ...................................................................................2-30 Key Features of Mobile Centrex....................................................................2-32 Mobile Centrex like a Virtual PBX .................................................................2-34 Switchboard Functionality provided by SWAT ..............................................2-36 MCX Client: User Admin ...............................................................................2-38 Example 1: Small Company in the plumbing business .................................2-40 Example 2: Insurance Agency ......................................................................2-41 Railway@vantage .........................................................................................2-42 Functional Blocks of IN@vantage .................................................................2-50 Prepaid@vantage........................................................................................3-52 What is Prepaid@vantage ............................................................................3-52 Integration of Prepaid@vantage ...................................................................3-54 Prepaid Service.............................................................................................3-56 How to invoke the Prepaid Service ...............................................................3-56 Originating Calls............................................................................................3-56 Terminating Calls ..........................................................................................3-58 Recharging Overview....................................................................................3-60 Voucher Recharging by DTMF......................................................................3-62 Use Cases.....................................................................................................3-64 Online-charged Voice Calls from Fixed Network SINAP............................3-64 Online-charged Voice Calls from Abroad MOC CAP 2 ..............................3-66 SS7 Event Charging: SMS from Abroad .......................................................3-68 Functional Blocks Prepaid@vantage ............................................................3-70 Charging@vantage .....................................................................................4-73 Network Embedding of Charging@vantage..................................................4-74 Features of Charging@vantage ....................................................................4-76 CORBA Communication to Payment Plug-in on Application Server.............4-76 Advice of Charge...........................................................................................4-76 Balancing ......................................................................................................4-76 Real-time Account Supervision .....................................................................4-76 Support of Prepaid Accounts on Dedicated Systems ...................................4-78 Support of Online Credit Limit Supervision for Postpaid Subscribers ...........4-78 HotBilling Support .........................................................................................4-79 Charging@vantage Charging Scenarios ......................................................4-80
Page 3
Content
IN@PLATOP (Part 1)
4.3.1 4.3.1.1 4.3.1.2 4.3.1.3 4.3.2 4.3.2.1 4.3.2.2 4.4 4.5 5. 5.1 5.2 5.3 5.4 5.4.1 5.4.2 5.4.3 5.5 5.5.1 5.5.1.1 5.5.1.2 5.5.1.3 5.5.1.4 5.5.2 5.5.2.1 5.5.2.2 6. 6.1 6.2 6.3 6.4 7. 7.1 7.2 8. 8.1 8.2 8.3 8.4 9. 9.1 9.2 9.3 9.3.1 9.3.2 9.3.3 9.4 9.4.1 9.4.2
IP Event Charging .........................................................................................4-82 SMS-MO Event Charging with Reservation ..................................................4-82 HTTP Content Charging via Web/WAP Proxy ..............................................4-84 MMS Submission IP Event Charging ............................................................4-86 IP Session Charging .....................................................................................4-88 IP Session Charging based on RADIUS (Pre-RO) .......................................4-88 IP Session Charging via SSG .......................................................................4-90 IN and Mobile Data Services.........................................................................4-92 Functional Blocks of Charging@vantage ......................................................4-94 charge@once ..............................................................................................5-97 Functional Blocks of charge@once ..............................................................5-98 Integration of charge@once........................................................................5-100 Features of charge@once ..........................................................................5-102 Interfaces of charge@once .........................................................................5-103 CAP-based Interfaces .................................................................................5-103 IP-based Interfaces Payment PlugIn........................................................5-103 IP-based Interfaces Online Interfaces......................................................5-104 Use Cases...................................................................................................5-105 CAMEL-based Charging .............................................................................5-106 Charging of Circuit-switched (CS) Traffic....................................................5-106 SS7 Session Charging in PO Domain.........................................................5-108 SS7 Event Charging in CS Domain: SMS-MO............................................5-110 IP Session Charging in PO Domain via SSG..............................................5-112 IP Charging Scenarios ................................................................................5-112 HTTP Content Charging via Web/WAP Proxy ............................................5-114 Hotbilling for IP Applications (Content) .......................................................5-116 Flexible Rating...........................................................................................6-118 Tariff Examples ...........................................................................................6-119 General Principles of Rating .......................................................................6-125 Architecture and Dataflow ...........................................................................6-126 Enhancements in V7.6 ................................................................................6-139 Service Creation Environment.................................................................7-141 Introduction .................................................................................................7-141 Architecture .................................................................................................7-142 @vantage Platform ...................................................................................8-144 Software Architecture..................................................................................8-146 Hardware Architecture ................................................................................8-148 Cluster Architecture.....................................................................................8-150 Functionality of TSP7000 ............................................................................8-152 Operation and Maintenance .....................................................................9-154 Introduction .................................................................................................9-154 Interfaces ....................................................................................................9-156 Fault Management ......................................................................................9-158 Architecture .................................................................................................9-158 Fault Management GUI...............................................................................9-160 @vantage Commander Configuration Management GUI ...........................9-162 Performance Monitoring..............................................................................9-166 Architecture .................................................................................................9-166 Performance Monitoring GUI ......................................................................9-168
Page 4
IN@PLATOP (Part 1)
Content
9.5 10. 10.1 10.2 11. 11.1 11.2 11.3 11.3.1 11.3.2 12. 12.1 12.2 12.3 12.4
Security Management .................................................................................9-170 Disaster Recovery...................................................................................10-172 Architecture / Solution Summary...............................................................10-172 Detailed Description ..................................................................................10-174 SMAF ........................................................................................................11-177 Introduction ...............................................................................................11-177 Function Split ............................................................................................11-177 Service Management Application..............................................................11-180 Service Management Login Screen ..........................................................11-180 Service Data Administration......................................................................11-180 Ticketing ..................................................................................................12-183 Introduction ...............................................................................................12-184 Phases of Ticket Handling ........................................................................12-186 Ticket Formatting ......................................................................................12-188 Ticket Scenarios........................................................................................12-190
Page 5
Product Structure
IN@PLATOP (Part 1)
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
Page 1-6
IN@PLATOP (Part 1)
Product Structure
Product Structure
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 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
1-2
Nokia Siemens Networks
Introduction / Training Center / 2007
Notes
Page 1-7
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
Page 2-8
IN@PLATOP (Part 1)
IN@vantage
Integration of IN@vantage
HLR
IN@vantage
SSP MSC (SSP) MSC (SSP)
Basestation
BSC
BSC
Basestation
2-1
Notes
Page 2-9
IN@vantage
IN@PLATOP (Part 1)
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
Page 2-10
IN@PLATOP (Part 1)
IN@vantage
Services of IN@vantage
Number Translation Service Multi SIM Virtual Private Network Mobile Centrex Railway@vantage
2-2
Notes
Page 2-11
IN@vantage
IN@PLATOP (Part 1)
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
Page 2-12
IN@PLATOP (Part 1)
IN@vantage
Number Translation Service: Freephone Service

0800 4567
IN
022 84599 030 33445 040 77445 Typical Use Cases Service Hotline Reservation Hotline Information Hotline : Main Features Single number Reverse charging Call forwarding on busy/no answer Time-dependent routing Origin-dependent routing Call distribution Subscriber-specific announcement Authentication
x
A
Operator Benefits Call completion Segment-specific service variants
Subscriber Benefits Attracts calls: advertising/ business opportunities Call completion Billing control
User Benefits Call free of charge Low barrier to place call
2-3
Notes
Page 2-13
IN@vantage
IN@PLATOP (Part 1)
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
Page 2-14
IN@PLATOP (Part 1)
IN@vantage
Number Translation Service: Premium Rate Service

0900 -700700
Weather Forecast Hamburg IN Weather Forecast Munich
Typical Use Cases Location-specific Information Weather Forecast Sports Results Horoscope : Main Features Premium rate charging Time-dependent routing Origin-dependent routing Selection code-dep. routing Announcement User Benefits Ubiquitous / convenient access to information
Operator Benefits Participation in new business opportunities Additional traffic
Subscriber Benefits Revenue by premium charge Operator collects charges New sales channels
2-4
Notes
Page 2-15
IN@vantage
IN@PLATOP (Part 1)
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.
Page 2-16
IN@PLATOP (Part 1)
IN@vantage
Number Translation Service: Universal Access Number Service

Typical Use Cases
Booking, Ordering Service Mail Order Business Ticket Line :
Main Features Single number Split charging Call forwarding on busy/no answer Time-dependent routing Origin-dependent routing Selection code-dep. routing Call distribution Subscriber-specific announcement Operator Benefits Call completion Segment-specific service variants Subscriber Benefits Attractive tariff option Optimized call distribution 24/7 One number for multiple locations User Benefits Single number Easy to remember
2-5
Notes
Page 2-17
IN@vantage
IN@PLATOP (Part 1)
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
Page 2-18
IN@PLATOP (Part 1)
IN@vantage
MultiSIM@vantage - Motivation
Convenience Service for business customers with several mobiles Car phone Business mobile Private mobile PDA / 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. Lawyers Doctors on call Security Guards Constructors Physicians Farmers
2-6
MultiSIM@vantage - Solution Overview

MultiSIM@vantage provides support for
Several independent SIM cards, one phone number One primary MSISDN Several 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)
2-7
Page 2-19
IN@vantage
IN@PLATOP (Part 1)
Page 2-20
IN@PLATOP (Part 1)
IN@vantage
MultiSIM@vantage - One Phone Number, Parallel Ringing

Example: User has a business mobile, a private mobile and a mobile in his car
One Phone Number MSISDN1 MSISDN2
MSISDN3
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.
2-8 Nokia Siemens Networks Introduction / Training Center / 2007
Notes
Page 2-21
IN@vantage
IN@PLATOP (Part 1)
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
Page 2-22
IN@PLATOP (Part 1)
IN@vantage
VPN@vantage
Public network
Constructor
Typical Use Cases Customer-specific networks within and across PLMN May include corporate networks Main Features Private numbering plan Abbreviated dialing (short codes) On-net/off-net call type variations Flexible charging options Screening, Barring Closed User Group
VPN@vantage
Construction company
PABX
On Site PLMN
Operator Benefits Flexible tariff offerings Cost reduction due to usage of core networks resources
User Benefits Subscriber Benefits Outsourcing of private network No call charges, no prepaying for calls via the VPN resources to operator Comfort of dialing short Centralized administration numbers Flexible teaming of VPN Screening of calls members Individual tariff options
2-9
Notes
Page 2-23
IN@vantage
IN@PLATOP (Part 1)
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
Page 2-24
IN@PLATOP (Part 1)
IN@vantage
Private Numbering Plan Member Types
Member Type Description On-net This member type characterizes a full user of the VPN, generally a member of the company and the VPN. Off-net Admin/DTMF This member type is used by the service if the number of the corresponding user is not defined in the PNP. This member type is used to provide access to the DTMF menu.
Partner On-net As a user can be a full member of one VPN only, this member type is 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. Virtual On-net This member type is a user whose private number is registered in the 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 of sub companies).
Notes
Page 2-25
IN@vantage
IN@PLATOP (Part 1)
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 Page 2-26
IN@PLATOP (Part 1)
IN@vantage
Call Types - 1
On - off 2 2
PLMN
PLMN VPN
1 3 off - on
on - on
Call Types - 2
off - off 5 VPN PLMN
PLMN
on virtual on
Partner VPN Partner On-Net
2-12
Page 2-27
IN@vantage
IN@PLATOP (Part 1)
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 companys 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.
Page 2-28
IN@PLATOP (Part 1)
IN@vantage
MobileCentrex@vantage
A typical use-case ...
Welcome to mobile.inc. Press 1 for sales, Press 2 for service, Press 3 for Operator Please wait, Well be with you in no time
bl ab la bl a!
What can we do for you?
2-13
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
Page 2-29
IN@vantage
IN@PLATOP (Part 1)
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 Page 2-30
IN@PLATOP (Part 1)
IN@vantage
MobileCentrex@vantage Architecture Overview
(calls from inside or outside the company)
IN System
GSM/ UMTS
Assisting IP
(custom. announcements)
(MobileCentrex IN application)
Private Numbering Black-/Whitelist Screening Automatic Switchboard Call Queuing Hunting groups DTMF menu Roaming support :
S W AT
Web Portal IP Server
MCXpress Server
M CX Clien t
M CX Clien t
Admin traffic & status info Signaling traffic Calls
Enterprise
Mobile Network Operator / Service Provider
2-14
Notes
Page 2-31
IN@vantage
IN@PLATOP (Part 1)
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
Page 2-32
IN@PLATOP (Part 1)
IN@vantage
MobileCentrex@vantage Key Features

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
2-15
Notes
Page 2-33
IN@vantage
IN@PLATOP (Part 1)
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
Page 2-34
IN@PLATOP (Part 1)
IN@vantage
MobileCentrex@vantage
Virtual PBX- Solution
A virtual mobile telephone system Built on standard GSM and IN Extended with comfortable administration and switchboard functionality
Wireless Attendant
GSM and IN infrastructure
Calling/called party (e.g. Employees of

the Enterprise calling each other via the MobileCentrex)
MNO
Enterprise
Attract small to medium-sized enterprise customers to switch from PBX to mobile phones and thus increase mobile network traffic Introduce additional IN service on well-established and proven IN platform
2-16
Notes
Page 2-35
IN@vantage
IN@PLATOP (Part 1)
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 employees 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 employees voice box due to the employee being out of the office or the employees phone being busy or out of coverage.
GSM ........... Global System for Mobile Telecommunication SWAT ......... Siemens Wireless Attendant
Page 2-36
IN@PLATOP (Part 1)
IN@vantage
Switchboard Functionality provided by SWAT
2-17
Notes
Page 2-37
IN@vantage
IN@PLATOP (Part 1)
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 Customer Care Subscriber User Network operator for maintenance,.. Customer care personnel of the network operator Enterprise / company which subscribes the MobileCentrex@vantage service Employee of the company
Page 2-38
IN@PLATOP (Part 1)
IN@vantage
MCX Client: User admin
2-18
Notes
Page 2-39
IN@vantage
IN@PLATOP (Part 1)
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.
Page 2-40
IN@PLATOP (Part 1)
IN@vantage
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 companys 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 companys 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 Page 2-41
IN@vantage
IN@PLATOP (Part 1)
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 Page 2-42
IN@PLATOP (Part 1)
IN@vantage
Railway@vantage
Scope of Railway Communication
Railway Fixed Network
EIRENE (GSM-R) Network
Other EIRENE (GSM-R) Network International Train Communications
Shunting Communications
Train Communications
Wide Area Communications (trackside, depot, station, ...)
2-19
Notes
Page 2-43
IN@vantage
IN@PLATOP (Part 1)
Functional Addressing (1) + (2) (3) The train personnel register per USSD via the HLR at Railway@vantage. 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. Personnel enter the train. If the person forgets to deregister, the timer expires and the functional number is deregistered. The person is informed about deregistration by an USSD.
(3a) (4) (5) + (6)
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 Page 2-44
IN@PLATOP (Part 1)
IN@vantage
Functional Addressing
(6)
USSD Notification, forwarded
(3)
HLR
USSD Notification
Register Functional Number, set timer
(5) (2)
USSD (Forwarded)
Railway@vantage
(1)
USSD Registration Request
(4)
Deregister by timer
MSC
(3a)
E.g. move on to train
2-20
Notes
Page 2-45
IN@vantage
IN@PLATOP (Part 1)
(1) + (2) (3) (4) (5)
Somebody calls a person by functional number, not knowing the MSISDN. Railway@vantage determines the MSISDN of the destination and Sends it to the MSC. 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
Page 2-46
IN@PLATOP (Part 1)
IN@vantage
Functional Addressing
HLR
Railway@vantage
(3)
Check, Translate Number
CdPA: Call Type / Functional Number of train driver A train driver A
(2)
(4) (5)
CdPA: MSISDN
(1)
CdPA: Call Type / Functional Number
MSC
establish connection
Controller
E.g. move on to train
2-21
Notes
Page 2-47
IN@vantage
IN@PLATOP (Part 1)
Location-dependent Addressing (0) (1) (2) (3) (4) The location of a train is reported to Railway@vantage by a Train positioning system or by the cell-ID of GSM-R. The train driver calls the responsible controller via short code. Short code and cell-ID are sent to Railway@vantage. Railway@vantage determines the destination number. Connection is established.
MSC ........... Mobile Switching Center Page 2-48

IN@PLATOP (Part 1)
IN@vantage
Location-dependent Addressing
Train positioning system (optional)
(0)
Track-based location information
Railway@vantage
(2)
Short Code, Cell ID
Number, based on (3) Controller Location and short code
(4)
Controller Area A
establish connection
MSC
(1)
Short Code
Controller A
Controller Area B
Controller Area C
Controller C
2-22
Notes
Page 2-49
IN@vantage
IN@PLATOP (Part 1)
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
Page 2-50
IN@PLATOP (Part 1)
IN@vantage
Functional Blocks of IN@vantage

Billing Tickets
Common Common Database Database
Convergent Convergent Charging Charging Service Service Logic Logic
#7 #7 based based Service Service Logic Logic Interface Category / Type Network Elements
#7 : INAP/CAP (session, service)
IN@vantage
MSSP, MSSP, SSP SSP GSN GSN
2-23
Notes
Page 2-51
Prepaid@vantage
IN@PLATOP (Part 1)
3.
3.1
Prepaid@vantage
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
Page 3-52
IN@PLATOP (Part 1)
Prepaid@vantage
Prepaid@vantage
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 Flexible Rating Balancing Support 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.
3-1
Notes
Page 3-53
Prepaid@vantage
IN@PLATOP (Part 1)
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
Page 3-54
IN@PLATOP (Part 1)
Prepaid@vantage
Integration Prepaid@vantage
Prepaid@vantage
HLR
GPRS MAP CAP INAP GTP, DIAMETER
SGSN
GSM
GTP
GGSN
WWW
MSC (SSP) SSP

Basestation
BSC
PCU
MSC (SSP)
UMTS UE
UTRAN
BSC
Basestation
3-2
Notes
Page 3-55
Prepaid@vantage
IN@PLATOP (Part 1)
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
Page 3-56
IN@PLATOP (Part 1)
Prepaid@vantage
Mobile Originating Calls
Roaming: Calling party is PPS subscriber Calling party is PPS subscriber
VPLMN HPLMN
3-3
Notes
Page 3-57
Prepaid@vantage
IN@PLATOP (Part 1)
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
Page 3-58
IN@PLATOP (Part 1)
Prepaid@vantage
Mobile Terminating Calls
Roaming: Called party is PPS subscriber Called party is PPS subscriber
VPLMN HPLMN
3-4
Notes
Page 3-59
Prepaid@vantage
IN@PLATOP (Part 1)
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
Page 3-60
IN@PLATOP (Part 1)
Prepaid@vantage
Recharging Overview Mechanisms and Access Types

Prepaid@vantage
Online I/F
e.g. Corba, HTTP, FTAM
Corba I/F
Payment Payment Plug-in Plug-in Payment Plug-in
Voucher Management System (VoMS)
Customer Care (SMAF)
Payment Broker
Payment GW
Financial Institutions
Application Sever
...
Application Sever
...
Mechanism:
Recharge via VoMS/#7 DTMF, USSD Recharge via Customer Care Manual Recharge (voucher based or voucher-less, cash-in)
Untrusted domain Recharge via Application Sever / IP
Access Type: (voucher based)

3-5 Nokia Siemens Networks
Cash-in, IVR, Web, WAP, SMS, ATM, POS etc. (voucher-less)
Notes
Page 3-61
Prepaid@vantage
IN@PLATOP (Part 1)
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 subscribers 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
Page 3-62
IN@PLATOP (Part 1)
Prepaid@vantage
Voucher Recharge via DTMF

Own Terminal (Mobile Phone)
Send voucher recharge message
4 4
VoMS IF
Prepaid@vantage
5 5
Voucher Management System (VoMS)
Acknowledge
RRB CTR, PA; 3 P&C 3
6 6
IDP Initiate call (DTMF)
2 2
PA, ERB (Recharge result) IDP: Initial Detection Point
IP
1 1 3 3
RRB: Request Report BCSM CTR: Connect To Resource PA:: Play Announcement P&C: Prompt and Collect user information ERB: Event Report BCSM
PLMN
6 6
MSC/SSP
Subscriber & Terminal
3-6
Notes
Page 3-63
Prepaid@vantage
IN@PLATOP (Part 1)
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. 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.
2.
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 subscribers 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 subscribers account.
Page 3-64
IN@PLATOP (Part 1)
Prepaid@vantage
Online Charged Voice Call from Fixed Network (SINAP based charging of voice calls)
Example: Online charging of simple fixed voice call
Prepaid@vantage
2. IDP 3. SCI, FCI, CTR, PAC (prepaid card number) 5. PAC (PIN) 6. PAC result 8. PAC result 12. ACR 9. AC, CON (granted time) AC: Apply Charging ACR: Apply Charging Report CON: Connect CSI: CAMEL Subscr. Info CTR: Connect To Resource FCI: Furnish Charging Info IDP: Initial Detection Point PAC: Prompt And Collect PIN: Personal Identification Number 7. PAC (destination number) SSP: Service Switching Point IP: Intelligent Peripheral
SINAP
4. PAC result
10. Call connection 1. Initiate call 11. Release call Fixed network or
SSP incl. IP
3-7
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
Page 3-65
Prepaid@vantage
IN@PLATOP (Part 1)
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
Page 3-66
IN@PLATOP (Part 1)
Prepaid@vantage
SS7 Session Charging in CS Domain (CAP 2 based charging for voice calls)
Example: Online charging of simple GSM MOC voice call from VPLMN
Prepaid@vantage
CAP2
HLR
2. IDP Retrieve CSI 5. ACR 3. AC, Connect (granted time) AC: Apply Charging ACR: Apply Charging Report CSI: CAMEL Subscr. Info IDP: Initial DP
4. call connection 1. Initiate call (MOC)
MSC/VLR
VPLMN
3-8
Notes
Page 3-67
Prepaid@vantage
IN@PLATOP (Part 1)
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 SMSMO 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
Page 3-68
IN@PLATOP (Part 1)
Prepaid@vantage
SS7 Event Charging in CS Domain (CAP3 based SMS-MO charging)

Example: MS-MO with surveillance of successful delivery at SMS-C
Prepaid@vantage
CAP3
HLR
2. IDP Retrieve CSI 1. Send SMS 5b. ERB (submit, failure) 4. SMS delivery 5a. Report: submit, failure 3. RRB, CUE CSI: CAMEL Subscr. Info CUE: Continue ERB: Event Report BCSM IDP: Initial DP RRB: Request Report BCSM Event
SMS delivery
MSC/VLR
VPLMN
SMS-C
3-9
Notes
Page 3-69
Prepaid@vantage
IN@PLATOP (Part 1)
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
Page 3-70
IN@PLATOP (Part 1)
Prepaid@vantage
Prepaid@vantage
Billing Tickets
Common Common Database Database Balance Balance Management Management Rating Rating Logic Logic Convergent Convergent Charging Charging Service Service Logic Logic #7 #7 based based Service Service Logic Logic Interface Category/Type Network Elements
#7 : INAP/CAP (session, service) MSSP, MSSP, SSP SSP GSN GSN
Prepaid@vantage
3-10
Notes
Page 3-71
Charging@vantage
IN@PLATOP (Part 1)
Page 4-72
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 operators 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
Page 4-73
Charging@vantage
IN@PLATOP (Part 1)
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 subscribers 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
Page 4-74
IN@PLATOP (Part 1)
Charging@vantage
Network Embedding Charging@vantage

External Balance Management INXpress INXpress V6.2/V7b V6.2/V7b Prepaid@vantage Prepaid@vantage Online IF Address Resolution User User Repository Repository LDAP Billing Billing Center Center SAP SAP FTAM, FTP Billing / CRM
Charging @vantage
CORBA / FTAM
Operation
@Commander Server
AAA AAA Session Authorization Ro/RADIUS, GTP
RADIUS
Payment PlugIn CORBA SMSC SMSC
Payment PlugIn Ro/RADIUS, GTP Web/Wap Web/Wap Proxy Proxy (MSP, (MSP, CSG, CSG, IPS) IPS) IP Event
Ro/RADIUS (S)FTP FTAM Application Application Server Server Hot Billing
Policy Policy Router Router (SSG, (SSG, CSG, CSG, IPS) IPS) IP Session
MMSC MMSC
4-1
Notes
Page 4-75
Charging@vantage
IN@PLATOP (Part 1)
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.
Page 4-76
IN@PLATOP (Part 1)
Charging@vantage
Features of Charging@vantage
CORBA Communication to Payment PlugIn Advice of Charge Balancing

1. 2. 3. 4. 5.
Real-time Account Supervision Addresses Prepaid Accounts on Dedicated Systems Credit Limit Supervision for Postpaid Subscribers Long Term Reservation Handling GOB Certification
HotBilling Support
4-2
Notes
CORBA ...... Common Object Request Broker Architecture GOB ........... Grundstze ordnungsgemer Buchfhrung HTTP .......... Hypertext Transfer Protocol J2EE .......... Java 2 Enterprise Edition SMS ........... Short Message Service WAP ........... Wireless Application Protocol
Page 4-77
Charging@vantage
IN@PLATOP (Part 1)
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 operators 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
Page 4-78
IN@PLATOP (Part 1)
Charging@vantage
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............ Grundstze ordnungsgemer Buchfhrung
Page 4-79
Charging@vantage
IN@PLATOP (Part 1)
4.3
Charging@vantage Charging Scenarios
In addition, or as an alternative to handling charge requests via a dedicated Payment Plugin, 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 websurfing. 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 Page 4-80
IN@PLATOP (Part 1)
Charging@vantage
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 operators network infrastructure and should be clarified in the project.
Page 4-81
Charging@vantage
IN@PLATOP (Part 1)
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. The MSC of the VPLMN forwards the SMS to the SMS-C of the HPLMN. The SMS-C queries Charging@vantage to reserve a certain amount. In the following steps it has to be checked, whether the subscribers 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. Charging@vantage confirms the reservation after checking the account of the subscriber in the Prepaid system. The SMS-C delivers the SMS to B-party. After the SMS is delivered to B-party, the confirmation is sent to the SMS-C. 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 subscribers account provides sufficient balance). The PPS provides an indication back to Charging@vantage. Charging@vantage provides an acknowledgement about successful charging to the SMS-C.
1b) 2)
3) 4) 5) 6)
7)
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
Page 4-82
IN@PLATOP (Part 1)
Charging@vantage
SMS-MO Event Charging with Reservation
Charging@vantage
7. confirmCharge 6. charge
Prepaid IN V6.2 / V7b
3. confirmReserve
2. reserve
via Payment PlugIn

1. send SMS 1b. storage at SMSC 4. delivery to B-party 5. delivery confirmation
MSC/VLR
A-Party
SMSC
B-Party
4-3
Notes
Page 4-83
Charging@vantage
IN@PLATOP (Part 1)
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). 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 freeof-charge. In the following steps it has to be checked, whether the subscribers 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 subscribers 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 subscribers PPS account and is charged directly. Alternatively, the scenario may be implemented using reservation handling. In this case the amount is withdrawn from the subscribers 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 subscribers account automatically. 1)
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
Page 4-84
IN@PLATOP (Part 1)
Charging@vantage
HTTP Content Charging via Web/WAP Proxy (Trusted environment) Immediate Charging
3a. Charge
Charging@vantage
3b. Successful debit
2. charge
4. confirmCharge
RADIUS or via Payment PlugIn

1. HTTP_R 5. HTTP_R
Consumer
Web/WAP 6. Content Delivery (HTTP) Proxy
HTTP Content Server
4-4
Notes
Page 4-85
Charging@vantage
IN@PLATOP (Part 1)
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) 1b) The subscriber initiates an MMS submit request from his mobile phone 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 subscribers 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 subscribers 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
Page 4-86
IN@PLATOP (Part 1)
Charging@vantage
Immediate IP Event Charging of MMS MMS submission with bearer free of charge
Charging@vantage
RADIUS (Pre-R0)
1b. Service_Id 1c Free-of-Charge 1.MMS Subm. Req. 3.charge 4.ok
GSN
2. MMS Subm. Req. 5.MMS Subm. Ack.
RADIUS (Pre-R0) or via Payment PlugIn

MMSC
SSG
4-5
Notes
Page 4-87
Charging@vantage
IN@PLATOP (Part 1)
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
Page 4-88
IN@PLATOP (Part 1)
Charging@vantage
IP Session Charging-based on RADIUS (Pre-RO)

Supported Charging Scenarios Support of time-based budget control Support of volume-based budget control Delivery of connection-specific information Typical Use Cases via Service Selection Gateway
(SSG)
Web/WAP surfing Video Streaming
4-6
Notes
Page 4-89
Charging@vantage
IN@PLATOP (Part 1)
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 subscribers account. 3b) The successful debit of the subscribers 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 subscribers 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 Page 4-90
IN@PLATOP (Part 1)
Charging@vantage
IP Session Charging in PO Domain (RADIUS based GPRS/UMTS Charging via SSG)

Example: HTTP web session
3a. Charge
Charging@vantage
3b. Successful debit
RADIUS (Pre-R0)
2. reserve 7. charge 1. HTTP request 4. connect (granted time / volume) 8. ok 5. HTTP_Req.
HTTP Web Server Internet
GGSN
SSG
6. HTTP_Delivery
4-7
Notes
Page 4-91
Charging@vantage
IN@PLATOP (Part 1)
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
Page 4-92
IN@PLATOP (Part 1)
Charging@vantage
IN and Mobile Data Services (e.g. MMS)

Deriving charging info for transport at different levels: Browser
Application HTTP level TCP level IP level Request Response To other IP network domains To other targets
SGSN
GGSN
SSG
MMSC
Application
Charging@vantage
Mobile Network
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 (APNindependent) The MMSC sends and stores multimedia messages from and for mobile subscribers and generates charging information based on events
Request Response
4-8
Notes
Page 4-93
Charging@vantage
IN@PLATOP (Part 1)
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 operators legacy systems, e.g. integration of CRM, Online Bill Presentment, Statistics etc. For saving operators 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 postprocessing 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.
Page 4-94
IN@PLATOP (Part 1)
Charging@vantage
Functional Blocks of Charging@vantage

Existing Existing Balance Balance Management Management System System (SCP (SCP V7b) V7b)
Billing Tickets
Common Common Database Database
Convergent Convergent Charging Charging Service Service Logic Logic IP-based IP IP-based Service Service Logic Logic IP-based Hot IP IP-based Hot Billing Billing Service Service Logic Logic
Charging@vantage Interface Category / Type Network Elements
GTP, Ro, IP (session) SSG, MSP, CSG
GTP, Ro and CORBA (PlugIn) IP (event)
Ticket Hot Billing Non-standard Application Server
CSG, SMSC, Application Server (MMSC,)
4-9
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
Page 4-95
charge@once
IN@PLATOP (Part 1)
Page 5-96
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
Page 5-97
charge@once
IN@PLATOP (Part 1)
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)
Page 5-98
IN@PLATOP (Part 1)
charge@once
Functional Blocks of charge@once

Billing Tickets
charge@once Common Common Database Database Rating Logic Internal Rating Rating Logic
Convergent Convergent Charging Charging Service Service Logic Logic #7-based #7 #7-based Service Service Logic Logic Interface Category / Type Network Elements IP-based IP IP-based Service Service Logic Logic IP-based Hot IP IP-based Hot Billing Billing Service Service Logic Logic
GTP, Ro, DIAMETER #7 : INAP/CAP (session, service) MSC, SSP, GSN GTP, Ro,DIAMETER IP (session, service)
and CORBA (PlugIn)

IP (event)
Ticket Hot Billing
SSG, MSP, CSG
SMSC, Application Server, CSG (MMSC,)
Non-standard Application Server
5-1
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
Page 5-99
charge@once
IN@PLATOP (Part 1)
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
Page 5-100
IN@PLATOP (Part 1)
charge@once
Integration of charge@once
charge@once
TCP/IP (RADIUS, GTP, DIAMETER) CORBA MMSC MSP SSG CSG SMSC
INAP MSSP SSP
CAP MSSP
MAP HLRi
5-2
Notes
Page 5-101
charge@once
IN@PLATOP (Part 1)
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 subscribers 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 subscribers 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
Page 5-102
IN@PLATOP (Part 1)
charge@once
5.4
5.4.1
Interfaces of charge@once
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
Page 5-103
charge@once
IN@PLATOP (Part 1)
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 websurfing. 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
Page 5-104
IN@PLATOP (Part 1)
charge@once
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
Page 5-105
charge@once
IN@PLATOP (Part 1)
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) 2) The subscriber initiates a mobile originating call by dialing the desired destination number. 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. charge@once provides the response including granted time to the MSC. The MSC continues in processing the respective request, connects the call and monitors the call duration / respectively time consumption. The MSC reports the consumed time/amount back to charge@once.
3) 4) 5)
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 subscribers 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
Page 5-106
IN@PLATOP (Part 1)
charge@once
SS7 Session Charging: MOC CAMEL Phase 2 Charging of Circuit Switched (CS) Traffic
charge@once
CAP2
HLR
2. IDP
Retrieve CSI
3. AC, CON (granted time)
5. ACR
1. Initiate call (MOC)
4. call connection
MSC/VLR
VPLMN AC: Apply Charging ACR: Apply Charging Report CON: Connect CSI: CAMEL Subscr. Info IDP: Initial DP
Notes
Page 5-107
charge@once
IN@PLATOP (Part 1)
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 subscribers 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
Page 5-108
IN@PLATOP (Part 1)
charge@once
SS7 Session Charging in PO Domain

Example: Online charging of HTTP web session. (CAMEL Phase 3 based GPRS/UMTS Charging )
charge@once
CAP3
HLR
Retrieve CSI 2. IDP_GPRS 7. ACR_GPRS 3. Connect_GPRS, AC_GPRS (granted time / volume)
5. HTTP_Req. 1. GPRS_PDP_context_req 4. GPRS_context_ack
SGSN
GGSN
6. HTTP_Delivery
HTTP Web Server Internet
VPLMN
5-4
Notes
Page 5-109
charge@once
IN@PLATOP (Part 1)
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) 2) The subscriber sends an SMS from his mobile phone 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
Page 5-110
IN@PLATOP (Part 1)
charge@once
SS7 Event Charging in CS Domain: SMS-MO

Example: SMS-MO CAMEL Phase 3 based with surveillance of successful delivery at SMSC
charge@once
CAP3
HLR
2. IDP Retrieve CSI 1. Send SMS 5b. ERB (submit, failure) 4. SMS-delivery 5a. Report: submit, failure 3. RRB, CUE
MSC/VLR
VPLMN
SMS delivery
SMSC
CSI: CAMEL Subscr. Info CUE: Continue ERB: Event Report BCSM IDP: Initial DP RRB: Request Report BCSM Event
5-5
Notes
Page 5-111
charge@once
IN@PLATOP (Part 1)
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) 2) The subscriber initiates an HTTP request for a session to a web-server. 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 operators network infrastructure and should be clarified in the project.
Page 5-112
IN@PLATOP (Part 1)
charge@once
IP Session Charging in PO Domain via SSG

Example: HTTP web session (Radius-based GPRS/UMTS Charging)
charge@once
RADIUS (Pre-R0)
2. reserve 6. charge 3. connect (granted time / volume) 7. ok
1. HTTP request
4. HTTP_Req.
GGSN
SSG
HTTP Web Server

5. HTTP_Delivery
Internet
5-6
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
Page 5-113
charge@once
IN@PLATOP (Part 1)
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 subscribers 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 subscribers 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 subscribers account directly. Alternatively the scenario may be implemented using reservation handling: in this case the amount is withdrawn from the subscribers 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 subscribers account.
HTTP .......... Hypertext Transfer Protocol RADIUS ..... Remote Authentication Dial In User Service WAP ........... Wireless Application Protocol
Page 5-114
IN@PLATOP (Part 1)
charge@once
HTTP Content Charging via Web/WAP Proxy

Example: immediate charging in trusted environment charge@once
charge@once
2. charge
3. confirmCharge
RADIUS (Pre-R0) or via Payment PlugIn

1. HTTP_R 4. HTTP_R
Consumer
Web/WAP 5. Content Delivery (HTTP) Proxy
HTTP Content Server
5-7
Notes
Page 5-115
charge@once
IN@PLATOP (Part 1)
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
Page 5-116
IN@PLATOP (Part 1)
charge@once
Hotbilling for IP Applications (Content)
charge@once
3. ticket processing (account check, rating; update account; optional blocking)
MAP3
HLR
3a. barring of subscriber if necessary (AnyTimePOBarring)
FTAM/FTP
2. ticket file
4. Log / error ticket files; confirmation tickets for further evaluation / processing
1. Subscriber uses application
GSN
Application Server, e.g. Game Server
e.g. e.g. Data Data Warehouse Warehouse
5-8
Notes
Page 5-117
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.
Page 6-118
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
6-1
Notes
Page 6-119
Flexible Rating
IN@PLATOP (Part 1)
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)
6-2
Notes
An incomplete list of accounts. With V7.6 new accounts can be added dynamically.
Page 6-120
IN@PLATOP (Part 1)
Flexible Rating
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)
Page 6-121
Flexible Rating
IN@PLATOP (Part 1)
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
6-4
Notes
Discounts can be based on a number of items.
Page 6-122
IN@PLATOP (Part 1)
Flexible Rating
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. .
6-5
Notes
Page 6-123
Flexible Rating
IN@PLATOP (Part 1)
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.
6-6
Notes
Page 6-124
IN@PLATOP (Part 1)
Flexible Rating
6.2
General Principles of Rating
The following chapter describes how such tariffs can be designed
Data Domains
Domain Explanation
Data constituting the price and tariff framework

Examples
Tariffs and conditions Prices and conditions Bonus, Promotions, Discounts Surcharges
Dynamics
Product Data
Subscriber Data
Data from the subscriber database reflecting the subscriber attributes
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, .)

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
6-7
Notes
Page 6-125
Flexible Rating
IN@PLATOP (Part 1)
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
Page 6-126
IN@PLATOP (Part 1)
Flexible Rating
Interfaces
SS7 interfaces
SSP MSC/VLR SGSN
charge@once
IP Interfaces
Applic. PlugIn
SMS-C MMS-C HTTP Appl / Content Game Server Server
CSCF
eGGSN / IPS
Web / WAP
6-8
Notes
Page 6-127
Flexible Rating
IN@PLATOP (Part 1)
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.
Page 6-128
IN@PLATOP (Part 1)
Flexible Rating
Architecture of Charging and Rating
6-9
Notes
Page 6-129
Flexible Rating
IN@PLATOP (Part 1)
Components Involved
Charging
2 1
Rating
4
IP/SS7 Network
8
Service Logic
Service Data
Charging
Charging
6
Balancing
6-10
Notes
An overview on the sequence the components are used. See detailed description on the following pages.
Page 6-130
IN@PLATOP (Part 1)
Flexible Rating
Examples of Data received from Network

INAP 3 A-Party/B-Party Location information VLR-ID Charging Location Number Bearer Capability Quality of service . CORBA Product GTP Price MSISDN . Service ID .
Rating
2 1
IP/SS7 Network 8
Service Logic
Diameter SGSN IP RADIUS MSISDN MSISDN RuleBaseId APN MCC/MNC SGSN Address . .
Charging
Charging
6
Balancing
6-11
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
Page 6-131
Flexible Rating
IN@PLATOP (Part 1)
Call Handling by Service Logic

3
Charging
2 1 IP/SS7 Network 8 DataBase
Rating
4
Service Logic
Example: Service Logic Call Handling Emergency Call? 7 Call? First
Charging
Determine access variant (Mobile originating call, Mobile originating Charging Balancing call Roaming, Mobile Terminating Call, SMS, GPRS, USSD ) 6 Determine rating relevant data (look up ContractName/AccessVariant/TariffId, check if call is FnF call, Mobile local call, ) Call charging
6-12
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
Page 6-132
IN@PLATOP (Part 1)
Flexible Rating
Service to Rating
Prov1-Moc-1
Prov1-Moc-1
Charging
Rating
Rating looks up the data assigned 4 to triple Prov1-Moc-1 = Rating logic and data.
1 IP/SS7 Network 8
Service Logic
Charging
Charging
6
Balancing
6-13
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.
Page 6-133
Flexible Rating
IN@PLATOP (Part 1)
Rating Logics - Principle

Rating logics Determine input parameters to be used And map input parameters to output parameters TimeOfCall Parameter1 Account Balance Mapping Parameter2 Parameter3 Parameter4 isHz . Threshold Parametern
CalledParty
IsFnf
6-14
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.
Page 6-134
IN@PLATOP (Part 1)
Flexible Rating
Rating to Charging
IntervallBegin IntervallEnd 3 e1
Charging
2 1 IP/SS7 Network 8 7
Rating
Service Logic
e7 4 ChargingProfile Name ChargeFunction GSM
Charging
5
Charging
6
Balancing
6-15
Notes
The values determined by the rating logic are returned to charging to compute the price and charge accounts.
Page 6-135
Flexible Rating
IN@PLATOP (Part 1)
Simple Charging Profile Symbolic Description
Start
Compute price and charge account X using parameters received from rating
Do not connect the call/ do not send SMS
Connect the call/ send SMS
6-16
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.
Page 6-136
IN@PLATOP (Part 1)
Flexible Rating
Charging to Balancing
Charging
2 1 IP/SS7 Network 8 7
Rating
4
Service Logic
Subscriber account(s)
Charging
Charging
6
Balancing
6-17
Notes
Charging tries to deduct money or units from the accounts defined in the charging profile.
Page 6-137
Flexible Rating
IN@PLATOP (Part 1)
Balancing to Network
Charging
2 1 IP/SS7 Network 8
Rating
4
Service Logic
Charging
Charging
6
Balancing
6-18
Notes
The message successful or not successful is returned via charging to service and network.
Page 6-138
IN@PLATOP (Part 1)
Flexible Rating
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 to future calls, but also to calls made in the past. ( may apply also to SMS, Data downloads .) Group structures
6-19
Notes
With charge@once V7.6 new enhancements are introduced enabling shorter development cycles and easier introduction of new tariffs.
Page 6-139
Service Creation Environment
IN@PLATOP (Part 1)
Page 7-140
IN@PLATOP (Part 1)
7.
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@vantagespecific 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
Page 7-141
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
Page 7-142
IN@PLATOP (Part 1)
SCE Architecture
Service Creation Tools Service Creation Assistant JBuilder JDK optional: XMLSpy Service Delivery AXT Install SMAT make javac
Trace Analyzer (Visual Slick Edit)
OTE (CTF+Sims) GXI
TSM
IPS (IPSL Tool Package) TCP/IP NFS Client / Samba Version Management System Client
nfsd / samba rshd OGW
Versioning System
SCE Repository
SCE Client
SCE Server (Solaris)
7-1
IN@OV / Training Center / 2007
Notes
SAF Platform @vantage (single node)
Page 7-143
@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 doesnt 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
Page 8-144
IN@PLATOP (Part 1)
@vantage Platform
@vantage Platform Software Architecture
Hosted 3rd party applications
Online Charging
Presence Manager (OMIP)
Location Enabling Server GeoToolBox (OMIP)
Mobile Session Manager
VOT
VPN
PPS
NTS
3rd party applications
Mobile Smart Proxy
Charging
HSS, CSCF
HLRi
Service Application Framework
@vantage platform
Common Application Framework
RTP
Telco Service Platform (TSP7000) Hardware
OEM SW
8-1
Notes
Applications
Page 8-145
@vantage Platform
IN@PLATOP (Part 1)
8.1
Software Architecture
The @vantage platform is composed of: The Telco Service Platform 7000 (TSP7000) consisting of a highly scalable, reliable multivendor 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
Page 8-146
IN@PLATOP (Part 1)
@vantage Platform
@vantage Platform - Software Architecture

Applications
IN services or other applications based on the respective network elements (SEP, SMAP, PEP, HLRi, )
SAF API
Service Application Framework
Service Creation Environment Service Logic Execution Environment
CAF API
@vantage platform
Common Application Framework
User Management Logging Ticketing
TSP7000
integrated 3rd party software

SUN Solaris FSC Solaris FSC Rel.UNIX
Platform API
3rd Party Software (DB, RTP, Communication) Operating System Hardware
8-2
Notes
Page 8-147
@vantage Platform
IN@PLATOP (Part 1)
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
Page 8-148
IN@PLATOP (Part 1)
@vantage Platform
TSP7000 - Cluster Interconnections
2-Node Cluster (SUN/FSC)
DB
Node
LAN switch
Node Cluster interconnect Fiber channel
8-3
Notes
Page 8-149
@vantage Platform
IN@PLATOP (Part 1)
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 Fujitsu Siemens Corporation PRIMEPOWER SUN Microsystems SUN Fire
Operating System Solaris Solaris
Cluster Software PrimeCluster 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
Page 8-150
IN@PLATOP (Part 1)
@vantage Platform
TSP7000 - Cluster Architecture
node 1
node 2
Further Integrated & Enhanced 3rd Party Products Resiliant Telco Platform Cluster Package Operating System Operating System
Hardware
Hardware
Cluster File System
Database
8-4
Notes
Page 8-151
@vantage Platform
IN@PLATOP (Part 1)
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, ULTICOMs Signalware SS7 protocol stack product is certified for use with RTP. The TSP components originally purchased from FSC have been widely extended (TSP addons) 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 ........... Grundstze ordnungsgemer Buchfhrung 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
Page 8-152
IN@PLATOP (Part 1)
@vantage Platform
TSP7000 - Architecture and OEM Products

Platform API (Single System Image) Availability Functions Scalability Functions Tool Functions Database @vantage Specific Functions
File Transfer
Configuration and Installation
SS7 Connectivity IP Connectivity Volume Manager
RTP
Java
WEB
SNMP
Admin
Cluster Software Operating System Hardware
@vantage @Platform
Extended OEM Product
OEM Product
8-5
Notes
Page 8-153
Operation and Maintenance
IN@PLATOP (Part 1)
9.
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 Page 9-154
IN@PLATOP (Part 1)
@vantage V7.6 OAM
Interfaces Fault Management Configuration Management Performance Monitoring Security Management Further Features LEMAF
9-1
Notes
Page 9-155
IN@PLATOP (Part 1)
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
Page 9-156
IN@PLATOP (Part 1)
Interfaces
Northbound Interfaces
Northbound interfaces Fault Management Performance Management
SNMP
SMTP
FTP
Configuration Management
Backup& Restore Security Management
Oracle DB
Southbound Interfaces
Communication with NE agents
SNMP
CORBA
UDP
@vantage Commander Server

SUN Cluster 3.0 SUN Solaris 8 SUN Fire Prime Cluster 3.0 SUN Solaris 8 FSC Prime Power
9-2
Notes
Page 9-157
IN@PLATOP (Part 1)
9.3
9.3.1
Fault Management
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 operators 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
Page 9-158
IN@PLATOP (Part 1)
IN@vantage - Fault Management

@Commander Client @Commander Client @Commander Client
@Commander Server
SNMP, FTP
IN@vantage NE
IN@vantage NE
IN@vantage NE
9-3
Notes
Page 9-159
IN@PLATOP (Part 1)
9.3.2
Fault Management GUI
The @vantage Commanders 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
Page 9-160
IN@PLATOP (Part 1)
Fault Management
Event Browser
9-4
Notes
Page 9-161
IN@PLATOP (Part 1)
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.
Page 9-162
IN@PLATOP (Part 1)
@vantage Commander Configuration Management GUI
9-5
Notes
Page 9-163
IN@PLATOP (Part 1)
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.
Page 9-164
IN@PLATOP (Part 1)
Configuration Management
@Commander Client
export import @Commander Server Import/Export Pool
upload
download
IN@vantage NE
9-6
Notes
Page 9-165
IN@PLATOP (Part 1)
9.4
9.4.1
Performance Monitoring
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
Page 9-166
IN@PLATOP (Part 1)
IN@vantage - Performance Monitoring
@Commander Client
@Commander Client
@Commander Client
@Commander
UDP IN@vantage Network element IN@vantage Network element IN@vantage Network element
9-7
Notes
Page 9-167
IN@PLATOP (Part 1)
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 Page 9-168

IN@PLATOP (Part 1)
@vantage Commander Performance Monitoring GUI

PM Explorer Tree Navigator Previewer: values of selected Performance Objects
Description
Main Window
Performance Monitoring
Selected Objects
Graph Windows
9-9
Page 9-169
IN@PLATOP (Part 1)
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 Page 9-170
IN@PLATOP (Part 1)
Security Management (1)

Assignment of tasks and access rights to roles
Role Management
Access Rights None Read Write Execute
9-10
Security Management (2)

Assignment of roles and map to user
Configured Roles
Configured Maps
User Management
9-11
Page 9-171
Disaster Recovery
IN@PLATOP (Part 1)
10.
10.1
Disaster Recovery
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 doesnt 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
Page 10-172
IN@PLATOP (Part 1)
Disaster Recovery
Operational Improvements Disaster Recovery*

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
Primary Cluster 1
......
Primary Cluster 4
Secondary Cluster (Rescue Service)
Primary Cluster 5
......
*Feature not supported by configurations based on RM600
Primary Cluster 9
Data replication from primary to secondary cluster
10-1
Notes
Page 10-173
Disaster Recovery
IN@PLATOP (Part 1)
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 operators 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.
Page 10-174
IN@PLATOP (Part 1)
Disaster Recovery
Operational Improvements Disaster Recovery* - Summary

Disaster Recovery Concept: operational steps in case of disaster Switch-back Setup of Primary and Secondary Cluster
Installation Phase Crossover Phase
Set up of New System / Repair of Faulty One
Reconstruction Phase
Operational Steps for Disaster Recovery
Regular Operation
Data Replication from Primary Clusters to Secondary Cluster
Manual switch over to Full
Auto. switch over to Rescue
A Primary Cluster fails
Service Secondary acts like Primary - No Data Replication
Data Replication of other Primary Clusters continues Operator Decision
Service
*Feature not supported by configurations based on RM600

Notes
Page 10-175
Disaster Recovery
IN@PLATOP (Part 1)
The different operational steps and the tasks and behavior of primary and secondary cluster in each stage are as follows:
Operation Mode Installation Phase
Primary Cluster (in)active
Secondary Cluster inactive
Data Replication inactive
Remarks 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) continuous data replication to secondary cluster failure reported to operator console switch over to full service initiated by operator
Regular operation
active
rescue service as fall active (all primaries) back rescue service becoming active Recovery service processes tickets written by rescue service active, full service active (remaining primaries) stopped
Switch over to rescue service Switch over to full service
inactive inactive
Reconstruction Phase Fail-back Phase
inactive / repair or replacement resuming full service active Recovery service processes tickets written by rescue service
stopped
Repair / replacement of faulty primary cluster fail-back initiated by operator / service staff supported by @vantage Commander
rescue service as fallback
active
Page 10-176
IN@PLATOP (Part 1)
SMAF
11.
11.1
SMAF
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
Page 11-177
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
Page 11-178
IN@PLATOP (Part 1)
SMAF
Integrated SMAF
CORBA, HTTP, FTAM
*) same functionality as in configuration with SMAP
SMAF *)
Service Management Access Function
SEP
TkF
FTAM
Ticketing Function
SMF *)
Service Management Function SEP related
SCF
Service Control Function
SEP DB
INAP, CAP, MAP
Online IF, POP3, SMTP, HTTP, SNMP
11-1
Customer Access to SMAF
CORBA
Batch file Interface FTAM/FTP
GUI Interface HTML based
SMAF
Service Management Access Function

SMF
Service Management Function
CORBA
11-2
Page 11-179
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 Page 11-180
IN@PLATOP (Part 1)
SMAF
Service Management - Login Screen
11-3
Service Management Service Data Administration
11-4
Page 11-181
Ticketing
IN@PLATOP (Part 1)
Page 12-182
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

Page 12-183
Ticketing
IN@PLATOP (Part 1)
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
Page 12-184
IN@PLATOP (Part 1)
Ticketing
Tickets Creation
Application 1
Application 2
Application n IPC messages
Ticket Manager RtpTicWrite local ticket file RTP node
CEn pool CE2 pool CE1 pool
Ticket Pool (cluster file system or shared disk)
12-1
Notes
Page 12-185
Ticketing
IN@PLATOP (Part 1)
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
Page 12-186
IN@PLATOP (Part 1)
Ticketing
Phases of Ticket Handling

executed by the network element
Generation Formatting Storage
executed by the external system

Transfer Evaluation
Initiation
Binary or ASCII Project specific
Filename
FTAM
Ordering
Format Selection Data Collection
Directory
Fileswitch
12-2
Notes
Page 12-187
Ticketing
IN@PLATOP (Part 1)
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...
Page 12-188
IN@PLATOP (Part 1)
Ticketing
Ticket Formatting
Network Element
Application
Formatter (Product)
binary ASCII
Formatter (Project)
arbitrary format
Ticket Pool
12-3
Notes
Page 12-189
Ticketing
IN@PLATOP (Part 1)
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 isnt (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
Page 12-190
IN@PLATOP (Part 1)
Ticketing
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
12-4
Notes
Page 12-191

NSN In@vantage

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

NSN In@vantage

Transféré par

Droits d'auteur :

Formats disponibles

Nokia Siemens Networks IN@PLATOP Part 1

Course Documentation 2007

Copyright 2007 Nokia Siemens Networks All rights reserved

Copyright 2007 Nokia Siemens Networks All rights reserved

Copyright 2007 Nokia Siemens Networks All rights reserved

Copyright 2007 Nokia Siemens Networks All rights reserved

Copyright 2007 Nokia Siemens Networks All rights reserved

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

Copyright 2007 Nokia Siemens Networks All rights reserved

Nokia Siemens Networks

Introduction / Training Center / 2007

Copyright 2007 Nokia Siemens Networks All rights reserved

Copyright 2007 Nokia Siemens Networks All rights reserved

SSP MSC (SSP) MSC (SSP)

Nokia Siemens Networks

Introduction / Training Center / 2007

Copyright 2007 Nokia Siemens Networks All rights reserved

Copyright 2007 Nokia Siemens Networks All rights reserved

Nokia Siemens Networks

Introduction / Training Center / 2007

Copyright 2007 Nokia Siemens Networks All rights reserved

Number Translation Services

Copyright 2007 Nokia Siemens Networks All rights reserved

Number Translation Service: Freephone Service

Operator Benefits Call completion Segment-specific service variants

User Benefits Call free of charge Low barrier to place call

Nokia Siemens Networks

Introduction / Training Center / 2007

Copyright 2007 Nokia Siemens Networks All rights reserved

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

Copyright 2007 Nokia Siemens Networks All rights reserved

Number Translation Service: Premium Rate Service

Operator Benefits Participation in new business opportunities Additional traffic

Nokia Siemens Networks

Introduction / Training Center / 2007

Copyright 2007 Nokia Siemens Networks All rights reserved

Universal Access Number

Copyright 2007 Nokia Siemens Networks All rights reserved

Number Translation Service: Universal Access Number Service

Booking, Ordering Service Mail Order Business Ticket Line :

Nokia Siemens Networks

Introduction / Training Center / 2007

Copyright 2007 Nokia Siemens Networks All rights reserved

Copyright 2007 Nokia Siemens Networks All rights reserved

Nokia Siemens Networks

Introduction / Training Center / 2007

MultiSIM@vantage - Solution Overview

Nokia Siemens Networks

Introduction / Training Center / 2007

Copyright 2007 Nokia Siemens Networks All rights reserved

Copyright 2007 Nokia Siemens Networks All rights reserved

MultiSIM@vantage - One Phone Number, Parallel Ringing

Copyright 2007 Nokia Siemens Networks All rights reserved

Copyright 2007 Nokia Siemens Networks All rights reserved

Nokia Siemens Networks

Introduction / Training Center / 2007

Copyright 2007 Nokia Siemens Networks All rights reserved

Private Numbering Plan

The following member types are available:

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

Copyright 2007 Nokia Siemens Networks All rights reserved

Private Numbering Plan Member Types

Copyright 2007 Nokia Siemens Networks All rights reserved