intelligent network in @ vantage in introduction...

Intelligent Network

IN@vantage

IN Introduction V7a

IN Training Center

Intelligent Network Training Center Vienna IN Introduction V7a Edition 9/02

Technical modifcations possible. Technical specifications and features are binding only insofar as they are specifically and ex-pressly 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.

Intelligent Network IN Introduction V7a

IN Training Center IN @ INTRO for COMCEL Colombia Page 1-1

Contents

1 What is an Intelligent Network? ................................................................................... 1-3

1.1 Example: Prepaid Service (PPS) ........................................................................................1-4

1.1.1 Life Cycle ..........................................................................................................................1-4

1.1.2 Additional Features............................................................................................................1-6

1.1.3 PPS – Service Logic for Online Charging..........................................................................1-10

1.2 IN Goals ..........................................................................................................................1-12

1.3 IN and Basic Network......................................................................................................1-14

1.4 IN@vantage Architecture .................................................................................................1-16

1.5 Execution of an IN Call ....................................................................................................1-26

2 Standards and Triggering............................................................................................ 2-29

2.1 Structure and Contents of Standards...............................................................................2-30

2.1.1 ITU/INAP .........................................................................................................................2-30

2.1.2 CAMEL ...........................................................................................................................2-34

2.2 The Basic Call State Model (BCSM).................................................................................2-36

2.3 O_BCSM and T_BCSM ...................................................................................................2-38

2.4 Triggering Possibilities .....................................................................................................2-40

2.5 Dialing Sequences – Examples ........................................................................................2-44

3 @vantage Platform....................................................................................................... 3-47

3.1 @vantage System Architecture........................................................................................3-48

3.2 @vantage Platform Layers ...............................................................................................3-50

3.3 Multi Vendor Hardware / Operating System ....................................................................3-52

3.3.1 SUN Hardware ................................................................................................................3-54

3.3.2 Hardware of Fujitsu Siemens Corporation .......................................................................3-58

3.4 System Software ............................................................................................................3-60

3.5 Cluster (2 or 4 Node) .......................................................................................................3-62

3.6 Telco Service Platform.....................................................................................................3-64

3.7 Common Application Framework ....................................................................................3-66

3.8 Platform Components and Interfaces ..............................................................................3-70

4 Service Execution Point............................................................................................... 4-73

4.1 IN Main Functions ...........................................................................................................4-74

4.2 Functional Points .............................................................................................................4-76

4.3 Functional Architecture....................................................................................................4-78

4.3.1 Service Control Function (SCF) ........................................................................................4-78

4.3.2 Service Data Function (SDF)............................................................................................4-82

4.3.3 Service Management Function (SMF)..............................................................................4-82

IN Introduction V7a Intelligent Network

Page 1-2 IN @ INTRO for COMCEL Colombia IN Training Center

4.3.4 Service Management Access Function (SMAF) ...............................................................4-84

4.3.5 Ticket Function (TkF) .......................................................................................................4-84

4.3.6 Support of OA&M Functions ...........................................................................................4-86

5 Service Management Access Point (SMAP)............................................................... 5-89

5.1 Functional Architecture....................................................................................................5-90

5.1.1 Service Management Function (SMF) / Service Management Access Function (SMAF) ..5-90

5.1.2 Distribution Management Access Function (DMAF) ........................................................5-90

5.1.3 Location Management Access Function (LMAF)..............................................................5-90

5.1.4 Ticketing Function (LMAF)...............................................................................................5-92

5.1.5 Support of OA&M Functions ...........................................................................................5-92

5.2 Data Distribution..............................................................................................................5-94

6 Service Creation Environment .................................................................................... 6-97

6.1 Applying the Data Model .................................................................................................6-98

6.2 Data Model ...................................................................................................................6-100

6.3 SMAT............................................................................................................................6-104

6.4 Features........................................................................................................................6-106

6.4.1 Reasons for the Feature Concept ..................................................................................6-108

6.4.2 Example 1: Threshold Check .........................................................................................6-110

6.4.3 Example 2: DTMF Number administration .....................................................................6-112



1 What is an Intelligent Network?

Along an example in this chapter you will learn what an Intelligent Network is, what it is used for, and what its goals are. Items covered include:

• the Prepaid Service as an example for the usage of IN

• introduction of the main implementation concepts and the main subsystems

The IN product of Siemens is named IN@vantage which also is named IN Version 7a. Prede-cessor Versions have existed up to V6.2 and V7b (b because of its Bellcore based architectu-re). With V7a the IN system has become completely redesigned based on the so called @vantage architecture.

This course document is based on the actual Version V7a.



1.1 Example: Prepaid Service (PPS)

Prepaid Service is based on the principle of on-line charging. The subscriber has to book (and load, if this is not automatically following from the booking) an account and only then can per-form calls. During the calls the balance is continuously debited. If the balance is below a certain limit no calls can be set up. When the account balance reaches zero the actual call will be inter-rupted. The subscriber can recharge his account. The service can be seen as a kind of virtual telephone credit card.

The benefit of the Service Provider is the guaranteed payment. No post-processing of billing is required.

This service is available for mobile and fixed networks.

Core Features

Prepaid credit account: the subscriber pays before he can make calls, he loads certain a-mounts of money to his account at the system.

Online charging during call: the system decreases the account balance during or after the call.

Recharging: to load the account with money the subscriber buys a voucher which has a sec-ret voucher number. The subscriber then dials the (toll-free) hotline number, where he is con-nected to an automatic dialogue. He is asked to enter the voucher number. If the voucher number is valid (a valid voucher can be found by this number) the respective amount of money which is assigned to this voucher will be added to the account. The voucher then will be mark-ed as invalid so it cannot be reused. Vouchers can be offered for different prices. An other method of recharging is to charge the subscriber via his credit card for the respective amount of money which she or he wishes to load to the prepaid service account. This task can be carried out automatically at regular intervals, or manually. Finally the operator can set the charge manually, e.g. to provide restitution after a subscriber's complaint.

1.1.1 Life Cycle

The lifecycle starts when somebody subscribes to the Prepaid Service by buying a correspon-ding SIM-Card with a related MSISDN. The Prepaid Service already might be equipped with a positive account balance. If not, the account has to be recharged before the service can be u-sed. Which of the two options is available depends on a marketing based decision of the Ser-vice Provider.

Performing calls now decreases the account balance by the means of online charging.

With the first call respectively with the recharging, the recharging period starts. There must be another recharging task performed before this period ends, otherwise the card gets locked. During a warning period before the end of the recharging period an announcement is played, to inform the Subscriber, that he has to recharge. After the subscriber got locked due to the end of the recharging period he still may perform recharging calls for a certain grace period before his subscription finally is deleted.

If the account balance runs below the call credit threshold no calls can be performed. At a ba-lance below the recharge reminder threshold an announcement warns the Subscriber about the low balance. To solve the problem the Subscriber simply has to recharge.



1Intelligent Services – IN@TR - What is an Intelligent Network

Intelligent Networks

Training Center

Information and

Communications

Example: Prepaid Service - Lifecycle

�

0 0 4 9 , 0 0

0 0 4 9 , 0 0

SubscribePPS

BuyVoucher

RechargePerform Calls

Start of Recharging

Period

Grace Period

End ofGrace Period

� BelowCall Credit

Thresh-old

Below RechargeReminder Threshold

0 4 5 0 , 0 0

0 5 0 0 , 0 0

0 0 0 7 , 0 0

0 0 0 1 , 0 0

End of Recharging

Period

Warning Period

Notes



1.1.2 Additional Features

Special tariffs: some calls can be charged at special rates.

• Friends & family: the subscriber can establish a list of up to ten numbers

• Favorite area: calls to a specific geographical region

• Local call: calls within the present geographical region of the subscriber

• Charge free numbers: e.g. to the operator or to the recharging unit

• Emergency calls: These are not treated by the service logic but are just connected with-out further checks. They are not charged

Advice of charge: the charge for the current call is shown on the mobile station’s display.

Account query: the subscriber has three ways to get information on his actual account balan-ce: via recharging hot-line (announcement), via USSD (USSD = Unstructured Supplementary Service Data => shown on the mobile’s display) or by calling the customer care hot-line (opera-tor). Two currencies are supported, e.g. DM and €.

Low account threshold: if the account value is below the call credit threshold, the call is de-nied. The subscriber is informed that the call cannot be set up because of insufficient credit. The subscriber is also informed if the account value runs down below the recharge reminder threshold during a call. At an account balance of zero the actual call will be terminated.

Validity duration monitoring: if the service subscriber attempts a call after the expiration date of the prepaid card the call answered with an announcement and then released.

Administration menu: an administration dialog is available for users to change the language for prompts; to modify their PIN or redirection destinations; or to check their account value and the expiration date of the card.

Call forwarding, call redirection: incoming calls will be redirected to a pre-established for-warding destination.

First call handling: no incoming calls can be received before the first outgoing call is perfor-med. At the first call the service is activated for the subscriber and an activation announcement is performed. The subscriber is asked to select his preferred language.

Screening: a black- and a white-list (forbidden number ranges respectively permitted excepti-ons) prevents the possibility of calling destinations which would get into conflict with online charging (e.g. certain NTS).

Fax and data calls, SMS, GPRS: these calls must be treated differently, especially the char-ging mechanism works in a different way. Additionally e.g. announcements shall be suppres-sed.

DM “Deutsche Mark” = German Marks NTS Number Translation Services PPC PrePaid Card USSD Unstructured Supplementary Service Data





Training Center

Information and

Communications

� Special tariffs (friends & family, favorite area, local call,

charge free numbers, emergency calls)

� Advice of charge

� Account query (dialogue , USSD: 2 currencies)

� Low account threshold

� Validity duration monitoring

� Administration menu (language, PIN,

redirection destinations, account value, expiration date)

� Call forwarding, call redirection

� First call handling

� Screening (black- / white-list of forbidden numbers)

� Fax and data calls, SMS, GPRS

� Dialed access

0 4 5 0 , 0 0

Prepaid Service - Additional Features

Notes



Dialed access: normally you assume that your mobile phone (your SIM card) is automatically assigned to the PPS service. But the service is ready to accept dialed access as well. The subscriber may have to identify himself with PUI and PIN. This feature is of interest for fixed networks especially, but available in mobile networks as well.

ISDN Integrated Services Digital Network MSISDN Mobile Station International ISDN number PIN Personal Identification Number PPS PrePaid Service PUI Personal User Identification





Training Center

Information and

Communications

� Special tariffs (friends & family, favorite area, local call,

charge free numbers, emergency calls)

� Advice of charge

� Account query (dialogue , USSD: 2 currencies)

� Low account threshold

� Validity duration monitoring

� Administration menu (language, PIN,

redirection destinations, account value, expiration date)

� Call forwarding, call redirection

� First call handling

� Screening (black- / white-list of forbidden numbers)

� Fax and data calls, SMS, GPRS

� Dialed access

0 4 5 0 , 0 0

Prepaid Service - Additional Features

Notes



1.1.3 PPS – Service Logic for Online Charging

In order to provide a service - in our example “Freephone“ - a kind of program, a “Service Lo-gic”, has to be set up, which is executed in the case of a call. The customizable part of a servi-ce logic can be modified easily by the Service Provider, or even by the Service Subscriber.

The online charging process may be divided into following parts:

• Determine if the connection can be started:

• check whether the minimum costs can be billed – the feature (a) inquires the current tariff (Feature “Tariff Determination”), (b) evaluates the subscribers remaining credit /debit, (c) optionally reminds the user on recharging, (d) determines if the subscribers remaining credit / debit covers the minimum connection time / volume and reserves the necessary amount on the account.

• Start the connection and enable hard and soft cost control (soft cost control enables the subscriber to exceed his credit limit)

• Supervise the running costs (time based/volume based)

• Perform cost control

• React if the accumulated costs would exceed the subscribers current deposit/credit

• Bill the costs to the appropriate account(s) and provide billing tickets

• Inform the subscriber about irregularities (the feature “User Interaction” can be used)





Training Center

Information and

Communications

PPS – Service Logic for Online Charging

Your account is

1 cent!

Start

Superviseconnection Cost control

Bill the costs

Yes

Call End

Account Updated

Inform the userabout irregularities

Running Connection

Irregularities

opt. Info

Irregularities

No

Determine if the

connection can bestarted

Start connection

End

0 4 5 0 , 0 0

Notes



1.2 IN Goals

Intelligent Networks are used to make public switched telecommunication networks more fle-xible. IN can serve fixed networks (PSTN/ISDN) as well as mobile networks (GSM/GPRS).

Additional flexibility is achieved through the following:

Flexible routing selects the destination of a telephone call according to criteria such as time, origin, user input and so on. It also includes features such as percentage distribution, "the nth call" and "every nth call". Flexible routing answers the question: "Where to put the call?"

Flexible screening checks, whether a call is allowed to be connected according to criteria such as time, origin, destination, user input and so on. Black or white lists can be used as che-cking patterns.

Flexible billing allows the determination of how much has to be paid for a call, who shall be charged and in what way will the charging be performed. Again, criteria such as time or di-stance can be evaluated.

Flexible User Interactive Dialogue (UID) enables the service to request the caller to provide additional input such as PUI and PIN, or to select a choice from a menu (e.g. "If you want to check your tariff model dial 1, if you want to change your tariff model dial 2").

Communication with external systems enables the service to request additional input from external databases (e.g. voucher management system) as input to answer the questions about how to deal with the call (e.g. the value of the voucher, which is also the recharge amount).

Statistical data can be produced based on a variety of parameters e.g. according to counters, call information, etc.

GPRS General Packet Radio Service GSM Global Standard for Mobile communication ISDN Integrated Services Digital Network PIN Personal Identification Number PSTN Public Switched Telephone Network PUI Personal User Identification UID User Interactive Dialogue





Training Center

Information and

Communications

Intelligent Networks - Goals

Flexible screening

� Additional intelligence for public switched

telecommunication networks (fixed and mobile):

?

?

?

Flexible routing

Flexible

User Interactive Dialog

or

Flexible billing

Flexible statistics

“…?” - “…!”

Communication with

external systems

Notes



1.3 IN and Basic Network

In IN architecture a centralized data management receives signaling information to be able to execute the service. There are two ways of embedding the IN into the basic network: integra-ted IN and overlay technology.

With some pre-IN solutions the entire call (i.e. both voice and signaling channel) had to be routed from the local switching center via transit switches to a dedicated switching center (with dedicated software), from where the call was connected to the local B-party switch.

Distinct disadvantages of this were the enormous channel capacity wasted on the long-distance trunk lines and the lack of flexibility.

With the IN solution the voice channel is connected only to the nearest switch which provides

the Service Switching Function (SSF). The SSF (together with the CCF, the Call Control Function) manages the detection of an IN call, separates the signaling from the traffic channel and forwards it to the central component with the SCF.

Two different architectural concepts can be distinguished:

In an Integrated IN each single switch provides the SSF. This solution enables the use of the shortest routes for the voice channel and thus the best performance.

In an Overlay Network selected switches only are extended with the SSF. This solution is cheaper and enables multi-vendor networks (the use of switches from different vendors), but might cause restrictions e.g. at Advice of Charge or USSD (Unstructured Supplementary Servi-ce Data, used to send data to the mobile station e.g. the available account).

The Service Switching Function sends a message to the Service Control Function (SCF), by which the service is executed. Within the SCF the service logic is performed and that way the SCF decides whether it is allowed to connect the call, and, if so, where to connect it and how to charge it. The relevant information is sent back to the SSF, so that the call can be connec-ted, or not.

The advantages are obvious:

Signaling can be handled very efficiently (short duration, small amount of data) and only lines of shorter distance are used for both voice and signaling.

Only small enhancements at the switches are necessary within the basic network (switches have to be equipped with SSF) and no dedicated switching centers are needed.

A high degree of flexibility is guaranteed by the very concept of Service Control Function and Flexible Service Logic.

CCF Call Control Function SCF Service Control Function SSF Service Switching Function USSD Unstructured Supplementary Service Data





Training Center

Information and

Communications

IN and Basic Network

SSF

SCF

X

X

Overlay Structure

Overlay Structure

SSF

Integrated Structure

Integrated Structure

SSF

… Traffic-Channel andSignaling

… Signaling

SCF … Service Control Function

SSF … Service Switching Function

X … Local Exchange or MSC

MSC … Mobile Switching Center

Notes



1.4 IN@vantage Architecture

To gain the benefits of IN the architecture foresees the subsystems SSP, SEP, SMAP (optio-nal) and SCE (optional).

The Service Switching Point (SSP) is the door into the IN system for the calls originating in the basic network.

Tasks of the SSP:

IN trigger, "door into IN" (detecting a call as an IN call)

Separation of signaling and traffic information

Connection of the call to the destination

Charge ticketing (IN AMA tickets)

Collecting information for statistics

Precounting for service Televoting

Call Gapping (in case of overload)

There is at least one SSP in the network, e.g. if it is the Gateway via which an alternative pro-vider interconnects with a basic network of an established telecom. Normally there are several SSPs, dependent on the network structure (integrated or overlay). The maximum number of SSPs is not fixed generally but is configured in each SEP. There can be up to several hundred SSPs.

AMA Automatic Metering Account B&R Backup and Restore system CAMEL Customized Applications for Mobil network Enhanced Logic CAP CAMEL Application Part DTMF Dual Tone Multi Frequency GPRS General Packet Radio System. GSN GPRS Support Node HLR Home Location Register ICP Interception Control Point INAP IN Application Part IP Intelligent Periphery LAN Local Area Network MAP Mobile Application Part MGW Messaging GateWay SCE Service Creation Environment SEP Service Execution Point SGSN Serving GSN SMAP Service Management AccessPoint SS7 Signaling System Number 7 SSP Service Switching Point StWH Statistics WareHouse TCP/IP Transmission Control Protocol/Internet Protocol VoMS Voucher Management System





Training Center

Information and

Communications

IN@vantage Architecture

Service Access

Service Control

Service Para-meterization

System andServiceAdminis-tration Remote

Systems

SS7 (INAP / CAP / MAP)

IP

LAN (TCP/IP)

SSP

LAN (TCP/IP)

Basic NetworkHLR

StWH

SCE

MGW

B&R

VoMS

SSP

ICP

@vantageCommander

SEP SEP

SMAP

SGSN

Notes



The Serving GPRS Support Node (SGSN) is the switch in the GPRS package transmission network which triggers the IN service and controls the IN supported package transmission.

The Home Location Register (HLR) as the central register of subscriber records in the basic network supplies subscriber data to the SEP.

The Intelligent Periphery (IP) is used to perform announcements and User Interactive Dialog (UID), this means playing announcements and receiving responses as speech or DTMF tones. So the IP is the translator between traffic channel (speech) and signaling.

We distinguish between integrated IP (part of the EWSD) and external IP (separate HW e-quipment supplied by partners of Siemens, e.g. Tecnomen, or Comverse).

The IP can be a local one at each single SSP or a centralized, so-called assisting IP (AIP), con-nected to one dedicated SSP.

An assisting IP also might perform small services, so-called micro services, as additional func-tionality by itself, e.g. it can supply voice mailbox or Unified Messaging Service (UMS).

The Service Execution Point (SEP) is the “center of intelligence” in the IN system. It per-forms the service execution, that means it runs the service logic. It decides whether it is allo-wed to connect the call, and, if so, where to connect it and how to charge it.

Tasks of the SEP:

Service execution

Collection of statistics data

The database stored on the SCP is filled via the Service Management Access Point (SMAP) “offline” (i.e. not during the call). It is task of the SMAP to collect data (e.g. subscriber data) via GUI and to distribute them to the SEPs. The SMAP functionality (SMAF) may also be integra-ted in the SEP.

AIP Assisting IP DTMF Dual-Tone Multi Frequency EWSD Elekronisches WählSystem Digital GUI Graphic User Interface IP Intelligent Periphery SCE Service Creation Environment SEP Service Execution Point SMAF Service Management Access Function SMAP Service Management Access Point UID User Interactive Dialog UMS Unified Messaging Service





Training Center

Information and

Communications


Service Access

Service Control



Systems


IP

LAN (TCP/IP)

SSP

LAN (TCP/IP)

Basic NetworkHLR

StWH

SCE

MGW

B&R

VoMS

SSP

ICP

@vantageCommander

SEP SEP

SMAP

SGSN

Notes



The @vantage Commander provides:

Fault, message and alarm management (for SMAP, SEP, @vantage Commander, StWH, MGW etc.)

Performance monitoring, e.g. real time analysis of number of calls, CPU load or call se-tup times including visualization of online measurements

Configuration management, esp. of the SEP and the SMAP (e.g. process management) as well as of the monitored network elements

User management of the logins of all users of the different components

The backup and restore system (B&R) performs centralized regular backup and, if required, restauration of all network elements of the IN system which are usually under the control of the network operator (SEP, SMAP, @vantage Commander Server, StWH, Messaging Gateway and Interception Control Point server).

The Statistics Warehouse (StWH) is a means for archiving and processing call- and user-related statistics data. The different types of tickets written at the SEP are collected at the StWH in order to make the information enclosed therein available for network operator, service provider or service subscriber.

The Services are developed at a Service Creation Environment (SCE).

The Messaging Gateway (MGW) enables the SEP to communicate with a wide range of ex-ternal data points (EDPs) such as e-mail servers, or the Short Message Service Centers (SMSC).

The Voucher Management System (VoMS) only is needed if the Prepaid Service is executed on the IN system with voucher recharging. It is used to produce and maintain voucher data pa-ckages.

The Interception Control Point (ICP) enables law enforcement authorities to monitor the acti-vities of IN users. The ICP is an optional component. Lawful Interception is required by the law in many countries, enabling an Interception Authority – usually part of the executive authority or of the jurisdiction –to supervise specific subscribers’ calls, to monitor data base modifications

performed by these subscribers and to collect corresponding interception records and to deli-ver them to the Intercepting Authority.

In the figure Remote Systems summarize all external partners of the IN system like Billing Center, Short Message Service Center, VoMS of foreign vendors etc.

ASD Advanced Service Design B&R Backup and Restore system CPU Central Processing Unit EDP External Data Point FSL Flexible Service Logic ICP Interception Control Point IP Intelligent Periphery MGW Messaging GateWay OAM Operation, Administration and Maintenance SCE Service Creation Environment SMSC Short Message Service Center StWH Statistics WareHouse VoMS Voucher Management System





Training Center

Information and

Communications


Service Access

Service Control



Systems


IP

LAN (TCP/IP)

SSP

LAN (TCP/IP)

Basic NetworkHLR

StWH

SCE

MGW

B&R

VoMS

SSP

ICP

@vantageCommander

SEP SEP

SMAP

SGSN

Notes



Interfaces:

SSP – SEP: Intelligent Network Application Part (INAP) operations or CAMEL Application Part (CAP) operations based on the Signaling System No. 7 (SS7) protocol family for signaling messages

SEP – SMAP: proprietary messaging based on TCP/IP for transfer of service subscriber related data

SEP – SCE: file transfer based on FTP and on TCP/IP for moving Service Logic from SCE to SEP

SSP – internal IP: proprietary protocol for signaling messages (announcements, UID)

SSP – external IP: DSS1 or EDSS1 (like a connection with a PBX) for signaling messages (announcements, UID)

SEP – HLR: Mobile Application Part (MAP) operations based on SS7 to fetch data about calling or called party

SEP – AIP: INAP operations for signaling messages (micro services)

SEP – SGSN: CAMEL Application Part (CAP) Phase 3 operations based on SS7 for signa-ling messages

@vantage Commander – SEP, SMAP, @vantage Commander, StWH, MGW etc.: simple Network Management Protocol (SNMP) based on TCP/IP used for the message (fault) management. Trivial File Transfer Protocol (TFTP) based on TCP/IP used for performance monito-ring

@vantage Commander – SEP: proprietary messaging based on TCP/IP for SEP configura-tion management

B&R – SEP, SMAP, @vantage Commander Server, StWH, MGW and Interception Control Point server: client - server communication based on Embedded Remote Procedure Call (ERPC) and TCP/IP for transmission of backup relevant data

AIP Assisting IP API Application Programming Interface CAMEL Customized Applications for Mobil network Enhanced Logic CAP CAMEL Application Part CORBA Common Object Request Broker Architecture DSS1 Digital Subscriber Signaling System No. 1 EDSS1 European Digital Subscriber Signaling System No. 1 ERPC Embedded Remote Procedure Call FTAM File Transfer, Access and Management FTP File Transfer Protocol HLR Home Location Register IIOP Inter-Inter-ORB-Protocol INAP IN Application Part IP Intelligent Periphery MAP Mobile Application Part MGW Messaging GateWay ORB Object Request Broker PBX Private Branch eXchange SGSN Serving GSN SNMP Simple Network Management Protocol SS7 Signaling System Number 7 TCP/IP Transmission Control Protocol/Internet Protocol TFTP Trivial File Transfer Protocol UID User Interactive Dialog VoMS Voucher Management System





Training Center

Information and

Communications


Service Access

Service Control



Systems


IP

LAN (TCP/IP)

SSP

LAN (TCP/IP)

Basic NetworkHLR

StWH

SCE

MGW

B&R

VoMS

SSP

ICP

@vantageCommander

SEP SEP

SMAP

SGSN

Notes



StWH – SEP and SMAP: file transfer based on FTAM and on TCP/IP for statistics raw data

ICP – SEP: proprietary messaging based on TCP/IP for interception relevant data

SSP – remote system (billing center): file transfer based on FTAM and on X.25 packet switched transmission for IN AMA ticket files (IN charging records)

SEP – remote systems, VoMS: proprietary messaging interface based on TCP/IP to ar-bitrary external data points, either

directly connected (such as SEP with VoMS) or

connected via the messaging gateway (e.g. SMSC)

SMAP – remote systems (e.g. billing center), External File Interface (EFI): file transfer based on FTAM and on TCP/IP

for fetching report files (billing data to charge administrative tasks) from the SMAP

for fetching statistical data from the SMAP

as Mass Data Interface (MDI) alias Bulk Data Interface (BDI) for transmission of fi-les with service related and service subscriber and service user related data an alternative to the GUI interfaces of the SMAP with much higher perfor-mance

StWH – remote systems (e.g. data ware house): file transfer based on FTAM and on TCP/IP for statistics data

AMA Automatic Metering Account BDI Bulk Data Interface EFI External File Interface FTAM File Transfer, Access and Management MDI Mass Data Interface SMSC Short Message Service Center TCP/IP Transmission Control Protocol/Internet Protocol





Training Center

Information and

Communications


Service Access

Service Control



Systems


IP

LAN (TCP/IP)

SSP

LAN (TCP/IP)

Basic NetworkHLR

StWH

SCE

MGW

B&R

VoMS

SSP

ICP

@vantageCommander

SEP SEP

SMAP

SGSN

Notes



1.5 Execution of an IN Call

The following steps are performed during the call:

1 Call from the Service User: the call appears in the basic network

2 Recognition of IN request (IN trigger function): the SSP detects the call as an IN call and prepares to involve the SEP

3 Query: the SSP sends a query to the SEP to ask, how to proceed further with the call

4 Service Execution: the SEP derives the destination number for the call from the respec-tive service logic and sends the answer to the SSP

5 Response: the destination number is transmitted to the SSP

6 Call set up to destination number: the SSP checks whether the traffic channel can be set up, in especially the B-party must be reachable and must not be busy

7 Normal call set up: now the traffic channel (voice channel) is established. A-party and B-party can talk to each other

8 Call release: call ended by A-party or B-party

9 End-of-call treatment: the end time of the call is recognized

10 Event message end-of-call: statistical data are transmitted to the SEP

11 Reception and processing of the event message, processing of statistical data: the SEP writes a call ticket containing all information which is relevant for statistics

ISDN Integrated Services Digital Network PLMN Public Land Mobile Network PSTN Public Switched Telephone Network





Training Center

Information and

Communications

Execution of an IN Call

SEP

SSP

Local Switch

PSTN / ISDN/PLMN

Calling Party Called Party

1

2

3

4

5

6

7 8

9

10

11

Local Switch

Notes



2 Standards and Triggering

The chapter provides an overview about the IN relevant standards. It explains main concepts of the triggering procedure, that is the mechanism, how the SSP detects that a certain call is an IN call. The terms Basic Call State Model (BCSM) and Detection Point (DP) are introduced.

BCSM Basic Call State Model DP Detection Point



2.1 Structure and Contents of Standards

Especially three sets of recommendations are relevant as IN standards:

• ITU-T Q.1200-Series

• ETSI Core INAP

• ETSI GSM CAMEL

2.1.1 ITU/INAP

ITU-T Q.1200-Series

The most relevant aspects standardized by that series are:

• the Functional Blocks, that are sets of functions to be fulfilled by different subsystems to enable IN,

• the Basic Call State Model (BCSM) which describes the embedding of IN within the basic network (for more details see below in this chapter),

• the INAP protocol for communication between the SCF and the SSF/SRF and other inter-face protocols,

• the Service Independent Building Blocks (SIBs), which the service logic is made of,

• IN services

Some of these standards must be seen as what they are: recommendations. E.g. it does not make sense to provide the standardized set of services if there are no operators or providers ready to market them on the one hand and if there is a Service Creation Environment to de-velop new flexible services considering the market demands on the other hand.

The ITU-T IN standard is structured into various Capability Sets. They can be seen as steps of completion. Siemens fully covers CS-1 and some features of CS-2.

BCSM Basic Call State Model CAMEL Customized Applications for Mobil network Enhanced Logic CS Capability Set ETSI European Telecommunications Standards Institute GSM Global System for Mobile telecommunication ITU International Telecommunication Union ITU-T ITU Telecommunication Standardization Sector INAP Intelligent Network Application Part / Protocol SCF Service Control Function SIB Service Independent Building Block SRF Specialized Resource Function SSF Service Switching Function



0Intelligent Services – IN@TR - IN Services and their Features


Training Center

Information and

Communications

Structure and Contents of IN Standards (ITU/INAP)

� ITU-T Q.1200-Series

� Q.120x … General

� Q.121x … Capability Set 1


…

� Q.129x … Glossary

Q.12x1 Principles Introduction

…

Q.12x8 Interface Recommendation (INAP)

Q.12x9 IN User’s Guide

Contains e.g.:

ServicesServices

SIBsSIBs

INAPINAP

BCSMBCSM

Functional BlocksFunctional Blocks

ETSI Core INAP:

� ETS 300 374-x

Notes



The series is structured as follows:

• Q.1200 Q-Series IN Recommendation Structure

• Q.1201 Principles of IN Architecture

• Q.1202 IN Service Plane Architecture

• Q.1203 IN Global Functional Plane Architecture

• Q.1204 IN Distributed Functional Plane Architecture

• Q.1205 IN Physical Plane Architecture

• Q.1208 General Aspects of the IN Application Protocol

• Q.1211 Introduction to IN Capability Set 1 (CS-1)

• Q.1213 Global Functional Plane for IN CS-1

• Q.1214 Distributed Functional Plane for IN CS-1

• Q.1215 Physical Plane for IN CS-1

• Q.1218 Interface Recommendations for IN CS-1

• Q.1219 IN Users Guide for CS-1

• Q.122x Series IN Capability Set 2 (CS-2)

• Q.123x Series IN Capability Set 3 (CS-3)

• Q.1290 Glossary of Terms Used in the Definition of INs

ETSI Core INAP

ETS 300 374-x defines Core INAP as a slight modification of ITU CS-1 INAP. Siemens INAP (SINAP7) fully covers ETSI Core INAP and additionally supports certain CS-2 operations.

INAP Dialects

SINAP is the Siemens INAP which has developed from SINAP3 via SINAP5 and SINAP6 up to SINAP7.

SINAP exists as SINAPvn, where v determines the version number and n can be “s” for fixed networks (Small band), “m” for Mobile and “i” for IN, which combines “s” and “m”.

There are various country specific (better: Network Operator specific) INAP dialects such as CHINAP for Switzerland or INAP-R for Russia.

CHINAP Swiss INAP CS Capability Set ETSI European Telecommunications Standards Institute INAP Intelligent Network Application Part / Protocol INAP-R INAP for Russia ITU International Telecommunication Union ITU-T ITU Telecommunication Standardization Sector SINAP Siemens INAP

General Information about the ITU-T IN

Recommendations for the various Capability Sets (CS), containing principles (Q.12x1), in-terface recommenda-tions esp. INAP (Q.12x8) and a user’s





Training Center

Information and

Communications

Structure and Contents of IN Standards (ITU/INAP)

� ITU-T Q.1200-Series

� Q.120x … General



…

� Q.129x … Glossary

Q.12x1 Principles Introduction

…

Q.12x8 Interface Recommendation (INAP)

Q.12x9 IN User’s Guide

Contains e.g.:

ServicesServices

SIBsSIBs

INAPINAP

BCSMBCSM

Functional BlocksFunctional Blocks

ETSI Core INAP:

� ETS 300 374-x

Notes



2.1.2 CAMEL

ETSI GSM CAMEL

CAMEL is defined to support the usability of IN services even in visited GSM networks.

CAMEL is realized in phases, where IN@vantage V7a covers most of CAMEL phase 3.

Among other aspects the CAMEL recommendations GSM 02.78, GSM 03.78 and finally GSM 09.78 (which contains the CAP protocol) describe the following:

• the Basic Call State Model (BCSM) which describes the embedding of IN within the GSM network (for more details see below),

• the CAMEL Application Part (CAP) for communication between the SCF and the Mobile SSF/SRF,

• modifications of the Mobile Application Part (MAP), the interface between the GSM swit-ches and the HLR.

3GPP

By the standards of the 3rd Generation Partnership Project the CAMEL standards are extended to meet the needs of 3rd generation mobile networks. This affects especially the field of packet oriented data transmission.

3GPP 3rd Generation Partnership Project BCSM Basic Call State Model CAMEL Customized Applications for Mobil network Enhanced Logic CAP CAMEL Application Part ETSI European Telecommunications Standards Institute GSM Global System for Mobile telecommunication HLR Home Location Register MAP Mobile Application Part SCF Service Control Function SRF Specialized Resource Function SSF Service Switching Function





Training Center

Information and

Communications

Structure and Contents of IN Standards (CAMEL)

� ETSI GSM CAMEL

� GSM 02.78

� GSM 03.78

� GSM 09.78 … CAP

� 3GPP

� TS 22.078

� TS 23.078

� TS 29.078

Contains e.g.:

CAP/

MAPCAP/

MAPBCSMBCSM

Notes



2.2 The Basic Call State Model (BCSM)

To guarantee multi vendor inter-working, for the CCF, the Call Control Function, the Functional Block which is responsible for controlling the call and for triggering, a so called Basic Call State Model (BCSM) is standardized, being executed in the basic call process. The BCSM is a kind of state transition diagram, which shows the different states a telephone call can reach while it is processed on the switch. It also defines the events causing the transition from one state to the other. Those states are described as Points In Call (PIC).

To be precise a Point in Call is a state of the BCSM with the following characteristics:

• entry event (and parameters)

• exit event (and parameters)

• processing during the point in call.

For example, a PIC can be a state where the dialed digits are analyzed (compared to the en-tries in the routing tables of the switch).

Between these PICs so called Detection Points (DP) are defined. This are points where the ba-sic call process can be interrupted to carry out the service execution and thus a service logic. More theoretically we should say at the DPs the CCF switches over to the SCF (via SSF). Thus new instructions or data can be requested and received from the SCF before the basic call processing is continued.

That way the service execution is started to evaluate the service logic. The starting point of the service logic is called Point Of Initiation (POI), the ending point is named Point Of Return (POR). There can also be communication between the service execution and the basic call process after POI and before POR at so called Points Of Synchronization (POS, not shown in the diagram).

Different standards define different BCSMs. Siemens realized the one of ITU-T Q.1214 rec-ommendation which also is valid for CAMEL phase 3.

BCSM Basic Call State Model CAMEL Customized Applications for Mobil network Enhanced Logic CCF Call Control Function DP Detection Point PIC Point In Call POI Point Of Initiation POR Point Of Return POS Point Of Synchronization SCF Service Control Function SSF Service Switching Function





Training Center

Information and

Communications

Basic Call Process

IN Service Logic

POI POR

Basic Telephone Network

PIC DP PIC. . .

. . .

Service Execution

Basic Call State Model

Basic Call State Model (BCSM)

Notes



2.3 O_BCSM and T_BCSM

To be precise, there are two BCSMs defined in each capability set or CAMEL phase:

• Originating BCSM (O_BCSM): BCSM for call processing from the calling party to the switch. During processing this BCSM an IN service is detected, if the service is related to the calling party or is direct dialed.

• Terminating BCSM (T_BCSM): BCSM for call processing from the switch to the called party. During processing this BCSM an IN service is detected, if the service is related to the called party.

This means that in case of a two party call (at least) one O_BCSM and (at least) one T_BCSM is involved. (There can be several SSPs on the route of a call. If so the network has to prevent that the same service is triggered twice, e.g. the trigger must be contained in the database of one SSP only).The two BSCMs run parallel to each other and interact with each other. In case of multiparty calls one O_BSCM and several T_BCSM are involved. The O_BCSM and the T_BCSM usually become effective at different Service Switching Points.

BCSM Basic Call State Model CAMEL Customized Applications for Mobil network Enhanced Logic CCF Call Control Function INAP Intelligent Network Application Part / Protocol ISDN Integrated Services Digital Network ISUP ISDN User Part O_BCSM Originating BCSM SCF Service Control Function SSF Service Switching Function T_BCSM Terminating BCSM





Training Center

Information and

Communications

The BCSM in Connection to the IN

O_BCSM

SCF

INAP

Originating Line Terminating Line

Service Control

Service Switching

T_BCSM

SSF / CCF

ISUP

Notes



2.4 Triggering Possibilities

There are four different types of triggering: dialed trigger, automatically triggered originating calls, automatically triggered terminating calls and event triggered services.

Dialed

The calling party dials a public number which is known as an IN number or Access Code at the SSP. From that the SSP derives a so called service key.

The service key is the only mandatory value sent by the SSP to the SCF to identify a service. The service key uniquely identifies the service within the network. Service keys form the high-est level of service identification numbers.

The SSP sends the service key plus the IN number or Access Code, that is the originally dialed number or B-party respectively, (plus additional information) to the SCF and thus invokes the service logic.

Normal Structure of an IN number: IN Number = Service Code + Subscriber Code

The Service Code is an optional level. It can be used to distinguish between different services of the same kind (e.g. different Number Translation Services).

The Subscriber Code is also an optional level. It can be used to distinguish between different instances of services (e.g. Freephone Service as order line of the different subscribing compa-nies “Chinese Food” and “Pizza Line”).

Automatically Triggered Originating Call

On the other hand, IN services can be automatically triggered. If the caller has subscribed an IN service (an IN service is related to the CgPA somewhere in the HLR or the SSP’s database), the corresponding service key is transferred to the SCF together with additional information (e.g. calling party identification) and the service is activated before setting up the call.

Automatically Triggered Terminating Call

Also for terminating calls, a trigger table entry corresponding to possibly subscribed IN services decides, if a service has to be activated before call establishment.

Event Triggered Services

It also is possible, that the service is started by the SCF, triggered on a certain event (e.g. a point in time). This might be used for wake up calls for instance.

CgPA CallinG Party Address HLR Home Location Register





Training Center

Information and

Communications

Triggering Possibilities

� Dialed

� Automatically Triggered Originating Call

� Automatically Triggered Terminating Call

� Event Triggered Services (from SEP)

� USSD Trigger

� Mobility Trigger (from HLR, MAP)

� SMS Trigger (CAMEL)

� GPRS Trigger (from SGSN, CAMEL)

Notes



USSD Trigger

USSD may trigger IN services via this mechanism.

Mobility Trigger

This trigger occurs in the VLR and the HLR, when an update of the subscriber record - espe-cially a location update - is performed. The trigger is indicated to the SCF via MAP.

SMS Trigger

The SMS trigger indicates the occurrence of an outgoing short message. It either is detected in the SSP or in the SGSN.

GPRS Trigger

The GPRS trigger, which is observed in the SGSN, introduces IN services to GPRS data trans-mission.

CgPA CallinG Party Address GPRS General Packet Radio Service HLR Home Location Register SMS Short Message Service





Training Center

Information and

Communications

Triggering Possibilities

� Dialed

� Automatically Triggered Originating Call

� Automatically Triggered Terminating Call

� Event Triggered Services (from SEP)

� USSD Trigger

� Mobility Trigger (from HLR, MAP)

� SMS Trigger (CAMEL)

� GPRS Trigger (from SGSN, CAMEL)

Notes



2.5 Dialing Sequences – Examples

The slide shows several possible dialing sequences.

In all the cases the calling party may dial a destination e.g. a fully qualified public directory num-ber of a B party (national or international format).

1) Direct Access

In this case the directory number or MSISDN of the calling party is registered in the HLR or the SSP database as a subscriber of the service. No Number has to be dialed to ask for the execu-tion of the IN service.

2) Dialed Access based on IN number

In this case the SSP derives the need for executing the service from the dialed IN number which consists of a Service Code (indicating the requested service) and the Subscriber Code (identifying the acting subscriber).

3) Dialed Access based on Access Code (AC)

Same as 2) but instead of an IN number only an Access Code is dialed. Based on the AC the SSP can identify the requested service. The SCF identifies the subscriber based on the Calling Party Address.

4) Remote Access

This gives the VPN user the possibility to use the IN service from any telephone, also from a device which is not registered as a subcriber’s terminal (e.g. public coin phone, hotel). The A party device is unknown to the IN service and so prior to the call an identification and authenti-cation procedure has to be performed. For identification the Private User Identification (PUI) of the calling party may be used, for authentication a PIN is needed.

5) Inband Access

This access has to be used to integrate numbers from foreign networks into the service (e.g. numbers from the fixed network into the mobile network or the other way round). The calling party in the foreign network dials a Freephone number (IN number), which the Service Provider has subscribed to in the foreign network and by which the call is redirected to the IN service in the Service Providers network.

Because the Freephone service in the foreign network cannot deal with additionally dialed dig-its, the IN service has to prompt for the destination number.

AC Access Code HLR Home Location Register PIN Personal Identification Number PUI Personal User Identification SC Service Code SubsC Subscriber Code





Training Center

Information and

Communications

Dialing Sequences - Examples

destination

1) Direct access:

e.g. 0815-4711

5) Inband access:

IN number

e.g. 0800 2222 Prompt 0815-4711

2) Dialed access based on IN number:

e.g. 0801 1111 0815-4711

SC

No access dialed, trigger based on CgPA

SubsC

3) Dialed access based on AC:

e.g. 0501 0815-4711

AC Subscriber known by CgPA

destination

destination

destination

4) Remote access:

e.g. 0502 Prompt 1234 9876 Prompt 0815-4711

PUI PIN destinationAC

Subscriber known by CgPA

Notes



3 @vantage Platform

IN@vantage V7a is based on the common @vantage platform, which is used as a basis for dif-ferent systems within the wide field of telecommunication computing. In this chapter the meaning of the platform and its basic structure are introduced.



3.1 @vantage System Architecture

Within @vantage V7 the following solution packages are available:

• IN@vantage V7 IN@vantage is the basis for the well-known intelligent services like Prepaid, Virtual Private Networks, Freephone, Premium Rate, Split Charging, Televoting and others.

• Parlay@vantage V1 Parlay@vantage is the solution, which allows network operators to open up their networks by a secure Open Service Access for service creation. Service creation may be executed by the network operator, by Siemens or by 3rd parties

• Payment@vantage V1 Payment@vantage is the real-time solution for provision of new and advanced payment mechanisms, made available centrally in public, private and enterprise networks. Pay-ment@vantage is a carrier grade solution in the context of electronic and mobile commerce.

The three solution packages are all based on the @vantage platform, which will be described in this chapter.



1Intelligent Services – IN@TR - Service Access Mechanisms


Training Center

Information and

Communications

PaymentIN

@vantage System Architecture

@vantage Platform PlatformLayer

Interface

ApplicationLayer

Interface

Parlay

IPSSPBasic Network

HLR

SSP

IP-world

SGSN

Notes



3.2 @vantage Platform Layers

The advantage platform is based on multi vendor hardware. This hardware, along with its oper-ating system hosts the so called Telco Service Platform (TSP). This is a software package run-ning on the various hardware entities.

Atop the software Common Application Framework (CAF) is located. Via the Platform API this framework is connected to the TSP, via the CAF API the different applications are then con-nected.





Training Center

Information and

Communications

@vantage Platform

Telco Service Platform (TSP)

Common Application Framework (CAF)

Multi Vendor Hardware / Operating System

CAF API

Platform

API

Notes



3.3 Multi Vendor Hardware / Operating System

The hardware from different vendors can be used to deliver computing power to the platform. Its CPUs and memory along with the operating system build the basis for the @vantage plat-form.

The hardware is available as low end, mid range or high end system.





Training Center

Information and

Communications


low end

system

mid range

system

high end

system


- basic operating system

- CPUs

- memory

Notes



3.3.1 SUN Hardware

The system is realized as a 2 node or a 4 node cluster. Thus, a minimum of 2 machines in a cluster configuration is required.

Small: 2 Sun Fire V880 (Daktari) with up to 8 CPUs. 2 T3WG (2 bricks in single-brick configuration) for shared storage.

Medium: 2 Sun Fire 4800 (Serengeti 12) with 4, 8, or 12 CPUs each. Each Sun Fire is configured as a single segment holding a single domain. 2 T3WG (2 bricks in single-brick configuration) for shared storage.

Large: 2 Sun Fire 6800 (Serengeti 24) with 8, 12, 16, 20, or 24 CPUs each. 2 T3WG (2 bricks in single-brick configuration) for shared storage.

XLarge: 2 E15K (Serengeti 72) with up to 72 CPUs each. Not documented here – only project specific provision.

All these require external shared storage (HW RAID system T3 of Sun) and Gigabit cluster in-terconnects. SunCluster 3, Veritas Cluster Volume Manager, and Oracle Real Application Clus-ter are used as software.

For each of this variants the table below shows

• the maximal performance of the SEP in kilo Performance Units (kPU), where one prepaid call means 1 PU, 1 GPRS based date transmission is estimated with 3 PUs and one short message is weighted with 0.5 PUs. The performance figures are holding for four node clus-ters.

• the maximal performance of the SMAP in number of thousand handled subscribers. The performance figures are holding for four node clusters.

• number of CPUs, RAM, dimensions, needed power

• the number of domains. A domain can be seen as reserved capacity, which enables the kind of virtual machine within the machine.

• the number of PCI slots

CPU Central Processing Unit GPRS General Packet Radio System PCI Peripheral Component Interconnect PU Performance Unit RAM Random Access Memory





Training Center

Information and

Communications

SUN Hardware

SUN FIRE 4800

SUN FIRE 6800

SUN FIRE 15k

SUN FIRE V880

Model Max. SEP

Performance (kPU)

Max. SMAP

Performance (kSub)

Number of

CPUs

RAM

Sun Fire V880 530 6600 4-8 8 GB

SUN FIRE 4800 1500 20000 4-12 96 GB

SUN FIRE 6800 3000 40000 4-24 192 GB

15k 8100 108000 4-106 576 GB

Notes



Model Max.

SEP

Perfor-

mance

(kPU)

Max.

SMAP

Perfor-

mance

(kSub)

Num-

ber of

CPUs

RAM Di-

mensio

ns

(mm)

Weight

(kg)

Power

Con-

sump-

tion

(VA)

Number

of Do-

mains

Number

of PCI

Slots

Sun Fire V880

530 6600 4-8 8 GB 714 x 480 x 836

131 4500 1 1 UltraSCSI, 4 PCI

SUN FIRE 4800

1500 20000 4-12 96 GB 760 x 470 x 720

125 4100 2 16 PCI

SUN FIRE 6800

3000 40000 8-24 192 GB

1905 x 610 x 1346

455 8200 4 32 PCI

15k 8100 108000 4-72 576 GB

1910 x 850 x 1660

1122 18 72 PCI (Hot Plug)

For further information regarding Sun Fire see e.g.: http://www.sun.com/midframe http://partner.sun.com/midframe/ http://sun.com/servers/midrange/interactivetour/

White Paper: http://www.sun.com/servers/wp.html - midrange

Further material regarding Sun Fire may be found at http://trinidad.mchp.siemens.de/e8/restricted/oem/harddoc/index.shtml

CPU Central Processing Unit kPU kilo PU kSub kilo Subscribers PCI Peripheral Component Interconnect PU Performance Unit RAM Random Access Memory SCSI Small Computer Systems Interface VA Volt Ampere





Training Center

Information and

Communications

SUN Hardware

SUN FIRE 4800

SUN FIRE 6800

SUN FIRE 15k

SUN FIRE V880

Model Max. SEP

Performance (kPU)

Max. SMAP

Performance (kSub)

Number of

CPUs

RAM

Sun Fire V880 530 6600 4-8 8 GB

SUN FIRE 4800 1500 20000 4-12 96 GB

SUN FIRE 6800 3000 40000 4-24 192 GB

15k 8100 108000 4-106 576 GB

Notes



3.3.2 Hardware of Fujitsu Siemens Corporation

If our customers prefer original Siemens quality based on the SOLARIS operating system they may use FSC Primepower machines instead of SUN. For the purpose of reusing existing IN V7b hardware IN@vantag can also be delivered on the familiar RM600 E80 or even E60 ma-chines.

Model Max.

SEP

Perfor-

mance

(kPU)

Max.

SMAP

Perfor-

mance

(kSub)

Num-

ber of

CPUs

RAM Di-

mensio

ns

(mm)

Weight

(kg)

Power

Con-

sump-

tion

(VA)

Number

of Do-

mains

Number

of PCI

Slots

RM 600 E60

310 Not available

2-24 4 GB 1380 x 600 x 800

330 2780 1 7 (HIOS)

RM 600 E80

1040 Not available

2-24 24 GB 1380 x 600 x 800

330 2780 1 12 PCI

Prime-power 800

200 26600 4-16 64 GB 1800 x 766 x 1161

570 5700 4 24 PCI

Prime-power 2000

3600 53300 8-128 512 GB

1800 x 2172 x 3338

3180 36000 15 192 PCI

CPU Central Processing Unit FSC Fujitso Siemens Corporation HIOS High Performance Input Output System kPU kilo PU kSub kilo Subscribers PCI Peripheral Component Interconnect PU Performance Unit RAM Random Access Memory VA Volt Ampere





Training Center

Information and

Communications

Hardware of Fujitsu Siemens Corporation

Primepower 2000

RM600-E60/E80

Primepower 800

Model Max. SEP

Performance (kPU)

Max. SMAP

Performance (kSub)

Number

of CPUs

RAM

RM 600 E60 310 Not available 2-24 4 GB

RM 600 E80 1040 Not available 2-24 24 GB

Primepower 800 200 26600 4-16 64 GB

Primepower 2000 3600 53300 8-128 512 GB

Notes



3.4 System Software

Software Purpose Product used on SUN

and FSC Primepower

Software used on

RMs

Operating system HW access Solaris 8 Reliant Unix 5.45B10

C++ Compiled program-ming language

Forte 6 update 1 (CC5.2)

CDS 2.0B

CORBA Interface for access to SW objects

VBJ 4.1.1

VBCC 4.1.1

VBJ 4.1.1

VBCC 4.1.1

FTAM File transfer 7 7

Java VM Programming language interpreter

JRE 1.2.2 JRE 1.2 without hot spot

JRE Java Runtime Envi-ronment

1.2.2 PL6 1.2.B

JCCHART.JAR V6.3.3 V6.3.3

Oracle tuning pack Database tuning 2.1 2.0.4

Oracle DB C-API Embedded SQL C Interface JDBC-Driver

Data base manager 8.1.7 -

Sun Cluster Cluster management on Solaris machines

3.0 -

RMS Cluster Cluster management on Berkeley Unix machines

- SPS V4.0

Signal Ware SS7 connection 8.02 6.04

Emanate SNMP master agent

Error and event mes-saging

SMAWadapt: 1.0A0

SMAWsnmmpm: 1.3A2001

SMAWadapt: 1.0A0

SMAWsnmmpm: 1.3A2001

Netscape Internet browser 4.7 4.7

Apache Server Web server 1.3.11 1.3.11





Training Center

Information and

Communications

System Software

Software Purpose

Operating system HW access

C++ Compiled programming language

CORBA Interface for access to SW objects

FTAM File transfer

Java VM Programming language interpreter

JRE Java Runtime Environment

Oracle DB Data base manager

Sun Cluster / RMS Cluster Cluster management

Signal Ware SS7 connection

Emanate SNMP master agent Error and event messaging

Netscape Internet browser

Apache Server Web server

Notes



3.5 Cluster (2 or 4 Node)

There are several possibilities to set up the architecture of the hardware. Two characteristic ones are the 2-Node and the 4-Node Configuration:

The number of nodes shows, how many computing elements are used. The more computing elements, the more power the system has; even though the number of computing elements can be increased, obviously they all have to access the same database. Thus, both configura-tions only have one central database.

Main characteristics of the Multi-Node Cluster

• up to 4 nodes, up to 2km distance

• Oracle parallel server

• real time database access from each node

• communication with the Disk cabinet via fiber channel

• single system image view

• high availability

• uninterrupted installation, upgrade, repair





Training Center

Information and

Communications

Clusters (2 or 4 nodes)

2 Node Cluster 4 Node Cluster

Data Base Data Base

Computing

Element

Computing

Element

Computing

Element

Computing

Element

Computing

Element

Computing

Element

Notes



3.6 Telco Service Platform

The software TSP is specifically designed for the use in the telecommunication environment.

The TSP performs the following software functions:

• Communication Manager (for access to the processes)

• Transaction Processing Monitor

• Counter Manager

• Object Manager (gives access to persistent object oriented data)

• Overload Manager

• Data Base

• Alarm manager (event handling)

• Context Manager (current data of a job, e.g. a call)

• Timer Manager

• External Communication

• SS7 up to TCAP / ISUP

• TCP/IP, UDP

• ISDN, X.25

• FTP, SNMP, HTTP

• FTAM

• (TCAp over IP, tunneling e.g. TCP/IP over X.25)

• Application Manager

The Platform Management covers

• Configuration Management

• Fault Management

• Performance Management

• Security Management

• System Management (e.g. installation, backup, time synchronization)

The Platform API provides a functionally unique API. It is used to hide the real hardware struc-ture of the clusters to the higher layers. This means that for all higher layers (common applica-tion framework, applications) a so-called single image view is provided.





Training Center

Information and

Communications

Telco Service Platform

Platform

API

- functionally unique API

- single image view

Telco Service Platform (TSP)

Operating System

Communication

Manager

Timer

Manager

Transaction Processing

Monitor

Context

Manager

Alarm

Manager

Database

Object

Manager

Platform Management

Counter

Manager

Application

Manager

Local Management

File Manager (Logs,

Statistics, Tickets, Traces)

External

Communication

Overload

Manager

Notes



3.7 Common Application Framework

The Common Application Framework abstracts from the different underlying TSPs with the

help of the Platform Adaptation Layer (PAL) and adds a component model, a programming model for continuous availability, an interface to the Common Call Control and a couple of addi-tional functions. The interface of the CAF to the application layer is called CAF API and has a C++ and a Java part.

Internally the Common Application Framework (CAF) consists of the parts:

• Component Framework including Platform Adaptation Layer (PAL)

• Platform Components

• OAM

On top of the TSP, visible to the CAF via Platform API as single image, the Platform Adaptation Layer (PAL) – as part of the CAF – is located. On top the Component Framework (CFRAME) is placed. It is connected to the platform components (and the OAM) via the framework API.

Thus “services” used by more than one application are provided by the CAF. Using the CAF’s components the applications can access – mediated via CFRAME and PAL – the TSP without deeper knowledge of the TSP’s functions and components.

The Component Framework (CFRAME)

The component framework (CFRAME) is covering the different TSP interfaces with the Plat-form Adaptation Layer (PAL). Only in the PAL the different interfaces of the TSPs are visible.

Operation and Maintenance

The OAM parts of the @vantage platform contain all functions for:

• Fault Management

• Configuration Management

• Performance Monitoring

• Installation

• Backup and Restore

• User Management Administration Function (UMAF)

• Local Element Management Administration Function (LEMAF)

including the necessary GUIs.

API Application Programming Interface CAF Common Application Framework CFRAME Component Framework OAM Operation Administration Maintenance PAL Platform Adaptation Layer TSP Telco Service Platform





Training Center

Information and

Communications

Common Application Framework

Component Framework (CFRAME)

CAF API

Common Application Framework (CAF)

Platform Adaptation Layer (PAL)Platform

API

Framework API

• Provides access to platform services and network resources

• Provides additional services used by more than one application

• Consists of Components

Platform

Components

Platform

ComponentsOAM

Notes



Platform Components

The platform components are built by using the component model and basic functions pro-vided by CFRAME. They provide functions like:

• Common Call Control and protocol handling for various external protocols like SS7 and IP based protocols. The Common Call Control component as the most comprehensive platform component provides the access to communication and data networks to enable the control and man-agement of call processing. The servers of this component are set on top of the TCAP and TCP/IP communication stack of the TSP 7000 platform.

• Directory Access

• E-Mail

• Online Interface

• Web access

• Account management (for subscriber accounts)

• Batch Processing

• GUI Server

• Language Map

• Logging

• Ticket Handling

• Traffic Limitation

• User Management Function

• XML Parser

The Common Application Framework is structured in layers as shown in the figure.

API Application Programming Interface CAF Common Application Framework CFRAME Component Framework EMF Element Management Function (Fault, Configuration, Security and Performance Mgt.) GUI Graphic User Interface HTTP Hyper Text Transport Protocol IP Internet Protocol PAL Platform Adaptation Layer SS7 Signaling System No. 7 TCAP Transaction Capability Application Part TCP Transmission Control Protocol TSP Telco Service Platform UMAF User Management Access Function UMF User Management Function XML eXtensible Markup Language





Training Center

Information and

Communications

CAF Platform Components

Installation andUpdate

Component Framework - CFRAME

Logging, Tickets, Traffic Lim., UMF, XML-Parser,Accounts

CAF API

ONLINE, WEB/HTTP, e-Mail

Common Call Control, Batch, GUI-Server

EMF-Agents, UMAF, Logging Accessvia GUI

Notes



3.8 Platform Components and Interfaces

The platform components communicate with external partners according the table below.

Platform Component External Partner Protocol

MSC/SSP/IP INAP / SINAP

HLR MAP

Common Call Control

MSC/SSP/IP/SGSN CAP

Online Interface to other IN hosts, e.g. to other

SEPs, VoMS

ONLINE interface (= messag-ing interface), ASN.1

e-mail Mail server, SMSC SMTP / POP3

e-mail, Web access Web Clients, WAP Gateway http / WAP

OAM @commander SNMP / Corba / FTP

There is a programming interface via Corba

File Transfer is possible via FTAM, FTP

ABC Administration and Billing Center (or else: Accounting Billing Charging system) API Application Programming Interface ASN.1 Abstract Syntax Notation One CAMEL Customized Applications for Mobile network Enhanced Logic CAP CAMEL Application Part FTAM File Transfer, Access and Management, ISO 8571 FTP File Transfer Protocol GPRS General Packet Radio Service LDAP Lightweight Directory Access Protocol HLR Home Location Register http Hyper Text Transport Protocol IN Intelligent Networks INAP IN Application Part IP Intelligent Periphery IP Internet Protocol MAP Mobile Application Part MSC Mobile Switching Center OAM Operation, Administration, Maintenance OSA Open Software Architecture POP3 Post Office Protocol 3 SEP Service Execution Point SGSP Serving GPRS Support Node SINAP Siemens INAP SIP Session Invocation Protocol SMSC Short Message Service Center SMTP Simple Mail Transfer Protocol SNMP Simple Network Management Protocol SSP Service Switching Point WAP Wireless Application Protocol





Training Center

Information and

Communications

Platform Components and Interfaces

Customer Self Care

Ticket HandlingSMTP,

POP3SMTP, POP3

httphttp

Corba, FTAM / FTP

Corba, FTAM / FTP

Voucher Mgmt ASN.1ASN.1

online

GUI ServerWeb Batch

Processing

Account Handling

CommanderSNMP, Corba, FTAM

SNMP, Corba, FTAM

ABCWAP, Web

E-Mail

Common Call Control OAMLogging

Load Limitation

User Mgmt

Language Mapping

Customer Care

Backup &

Restore

Mail Server

Web Client/Server httphttp

StatisticsFTAM /

FTPFTAM /

FTP

Corba, http, FTAM / FTP

Corba, http, FTAM / FTP

OSA API Rel. 99 / Parlay API 2.1

OSA API Rel. 99 / Parlay API 2.1

OSA/Parlay Client

Eg.

LDAPUser Repository LDAPLDAP

MAPMAP CAPCAP INAP INAP

SGSNMSC SSPHLR

@vantage Platform

Notes



4 Service Execution Point

In this chapter the Service Execution Point will be introduced in more detail.



4.1 IN Main Functions

Within the IN application two main functionalities have to be observed.

Service Management Access Function (SMAF)

SMAF provides access to the Service data via different interfaces:

Via internet (http)

With API functions (CORBA)

As bulk data interface (service access function)

Service Execution Function (SEF)

Service Execution is the main functionality of an IN system. It is working together with other related functions, so let us mention:

Executes IN services (e.g. Prepaid, VPN, …)

Handles data management (via Service Data Function SDF)

Invokes creation of tickets (in the platform consists of componentsAPI Application Pro-gramming Interface http Hyper Text Transport Protocol SDF Service Data Function SEF Service Execution Function SMAF Service Management Access Function VPN Virtual Private Network



1Intelligent Services – IN@TR - Overview about Standards


Training Center

Information and

Communications

IN Main Functions

IN

Service Management Access Function (SMAF)

CAF API

• via internet (http)

• with API functions (CORBA)

• as bulk data interface (service access function)

Service Execution Function (SEF)

• executes IN services (e.g. Prepaid, VPN,...)

• handles data management (via Service Data Function SDF)

• invokes creation of tickets (in the platform)

Notes



4.2 Functional Points

The application SEF hosted at an @vantage platform builds the functional point SEP (Service Execution Point).

The functional point SMAP (Service Management Access Point) is formed by the @vantage platform hosting the SMAF (and additional functions – see detailed description of SMAP in the next chapter)





Training Center

Information and

Communications

Functional Points

@vantage Platform

SEF

SEP

@vantage Platform

SMAF

SMAP

IPSSPBasic Network

HLR

SSP SGSN

Notes



4.3 Functional Architecture

The Service Execution Point (SEP) is the kernel component of IN@vantage. The SEP provides all functions necessary to execute intelligent services.

The SEP software is structured according to the following functions:

Service Control Function (SCF),

Service Data Function (SDF),

Service Management Function (SMF),

Ticket Function (TkF), and

Also Operation, Administration and Maintenance (OA&M) functions are provided at the SEP.

If there are more than one SEPs in the network, the SEPs will be connected to an SMAP, where the Service Management Access Function (SMAF) will be located (Multi Cluster Envi-ronment). If there is only one SEP and no SMAP, the SEP will provide the SMAF as well (Sin-gle Cluster Environment).

4.3.1 Service Control Function (SCF)

The Service Control Function (SCF) provides the core functions for the execution of intelligent services since it enables access to the SS7 stack and the related INAP, CAP, and MAP proto-cols. Basically, the SCF

Provides the triggering and execution of intelligent services,

Supports service management, tracing, load control, performance monitoring, ticketing, and

Uses platform functions and persistent data access via the Service Data Function.

Protocols/Interfaces

CAMEL Phase 3 Enhancements for GSM, GPRS and UMTS

Enhanced support of PPS for UMTS (enhanced evaluation of bearer services for UMTS data calls; support of UMTS specific location information Service Area ID, SAI),

Enhanced support of VPN and NTS for GPRS and UMTS (new operation ActivityTest for keep alive mechanism; feature support of FurnishChargingInformationGPRS)

Enhanced support of SMS-MO (support of SMS for VPN: new operations FurnishCharg-ingInformationSMS and ConnectSMS; monitoring of SMS transfer to SMSC: new Detection Points SMS_Submit and SMS_Failure)

Support of new Trigger Detection Points for unsuccessful calls (T_Busy, T_No_Answer)

Mobility management event notification towards services (Location Update, IMSI Attach/ Detach)

Control of subscriber data in HLR (with MAP operations ATM, ATSI),

Retrieval of current location information (with enhanced MAP operation ATI)

Further support of CAMEL Phase 1 and CAMEL Phase 2





Training Center

Information and

Communications

Functional Architecture

SEP SEP

SMAP

TkF

Ticketing

FunctionSMF

Service

Management Function

Single Cluster Environment

(1 SEP, no SMAP)

SMAF

Service

Management

Access Function

SCF

Service Control

Function

TkF

Ticketing

Function

SEP

Data Base

SEP

Data Base

SCF

Service Control

Function

SMF

Service

Management Function

Multi Cluster Environment

(n > 1 SEP, 1 SMAP)

Notes



SINAP Enhancements (SINAP7m+)

Call Party Handling (support of parallel ringing; enhancements for leg specific charging and statistics)

IN Interworking (support of user-to-user-signalling 1 (UUS1) in INAP operations IDP, RC, ERB, CON for the transfer of transparent data)

Indication of a preceding IN dialogue in operation IDP

IN CS2 Service Interaction Indicator (SII) completion

CAMEL Phase 3 like Call Gapping for load limitation

Further support of SINAP5m, SINAP5m+, SINAP5m++, SINAP6i, SINAP7m

Support of Online Interface (only used by service logic)

For communication with external systems (released for VoMS -outbound-), for communication with the Messaging Gateway for hotbilling scenarios, or for communication with other IN@vantage servers

Support of SMTP/POP3

For connections to mail servers

WAP Push via HTTP

For information services

CAMEL Interworking

Support of roaming of subscribers within a PLMN between 2G and 3G areas

Circuit Switched (CS) connections (UMTS � UMTS, UMTS � GSM) *) voice only

Packet Oriented (PO) connections (UMTS � UMTS, UMTS � GPRS, GPRS � UMTS)

Standardization compliance

The IN@vantage V7a implementation is required to be compatible with the following CAMEL standards (released after Palm Springs plenary 03/2001):

3 G TS 23.078 (Stage 2) v3.8.0

3 G TS 29.078 (Stage 3, CAP) v3.7.0

3 G TS 29.002

In addition, selected change requests (approved at the Stockholm, Puerto Rico and Dresden meetings) are included.





Training Center

Information and

Communications


SEP SEP

SMAP

TkF

Ticketing

FunctionSMF

Service

Management Function


(1 SEP, no SMAP)

SMAF

Service

Management

Access Function

SCF

Service Control

Function

TkF

Ticketing

Function

SEP

Data Base

SEP

Data Base

SCF

Service Control

Function

SMF

Service

Management Function


(n > 1 SEP, 1 SMAP)

Notes



4.3.2 Service Data Function (SDF)

The Service Data Function (SDF) provides (refer also to SEP Data Base):

Storage and representation of persistent data, i.e. data accessed and possibly modified during voice calls and/or data sessions,

Data handling of persistent data (create, search, read, modify, delete),

Consistent manipulation of persistent data including basic constraint checks,

Access to persistent data, e.g. by the SCF and SMF/SMAF.

In particular, the SEP DB contains

Common Service Data (replicated data),

Service Subscriber data (master data),

Configuration data.

4.3.3 Service Management Function (SMF)

The Service Management Function (SMF) supports the provisioning and operation of intelligent network services. The SMF covers:

Service deployment, i.e. installation/de-installation of services, features, management applications including the corresponding data models and data handling,

Service provisioning, i.e. the assignment/de-assignment of installed call services to service providers (service commissioning) and service subscribers (service subscription),

Service operation control, i.e. service activation/de-activation, service data administration (service data browser/editor functionality), and customer management (creation/deletion of customers and the related personal data).





Training Center

Information and

Communications


SEP SEP

SMAP

TkF

Ticketing

FunctionSMF

Service

Management Function


(1 SEP, no SMAP)

SMAF

Service

Management

Access Function

SCF

Service Control

Function

TkF

Ticketing

Function

SEP

Data Base

SEP

Data Base

SCF

Service Control

Function

SMF

Service

Management Function


(n > 1 SEP, 1 SMAP)

Notes



4.3.4 Service Management Access Function (SMAF)

In IN@vantage V7a configurations, the SMAF is a mandatory function. The SMAF may either be integrated into the SEP or be available via CORBA on a dedicated SMAP cluster.

The SMAF enables the administration of intelligent services for both, the service subscriber and the customer care center. The SMAF integrated into the SEP offers the same functions as provided by the SMAP:

Service activation/deactivation

Service subscriber data administration

Common service data management

Personal data management

Authentication and authorization control

Call Service timer management

Protocols/Interfaces for service management functions

CORBA (via IIOP): For connections to the SMAP or to external service management systems

FTAM: For batch file access for user management, service activation/deactivation

HTTP (HTML): For GUI access (authentication use cases, provider management, service man-agement, subscriber self-administration; Support of HTTP 1.0, HTTP 1.1, HTML 4)

Note:

In multi-cluster configurations (multiple SEP clusters) additional service management functions for the distribution and localization of service data objects need to be provided. These func-tions (Distribution Management Access Function (DMAF), Location Management Access Func-tion (LMAF) can be considered as extensions of the SMAF. DMAF and LMAF are part of the SMAP functionality (refer to 4.1.3). Consequently, service management in multi-cluster con-figurations should be performed via a dedicated SMAP cluster (preferred configuration). If the SMAF is integrated into the SEP (in case of a multi-cluster configuration), it has to be considered that the DMAF and LMAF are not covered. If equivalent functions are available on a customer specific external system, it is possible to use the external system instead of SMAP.

4.3.5 Ticket Function (TkF)

The Ticket Function (TkF) supports the provision of information concerning the administration of data hosted by the SEP.

The ticket layout as well as the ticket field semantics is compatible to INXpress V6.2 and V7b.

Provision of tickets of different ticket types

Call tickets: 0x22, V8

Confirmation tickets, network operator tickets and counter tickets: 0x21, V8

External systems (StWH, ABC) may collect tickets from the SEP (written by the TkF into direc-tories of the SEP) via FTAM.





Training Center

Information and

Communications


SEP SEP

SMAP

TkF

Ticketing

FunctionSMF

Service

Management Function


(1 SEP, no SMAP)

SMAF

Service

Management

Access Function

SCF

Service Control

Function

TkF

Ticketing

Function

SEP

Data Base

SEP

Data Base

SCF

Service Control

Function

SMF

Service

Management Function


(n > 1 SEP, 1 SMAP)

Notes



4.3.6 Support of OA&M Functions

Operation, Administration and Maintenance (OA&M) functions supported at the SEP cover Fault Management, Configuration Management, Performance Monitoring, Load Management, and Backup/Restore.

In particular, Performance Monitoring includes new groups of counters supported at the SEP such as operating system counters, platform counters, service control counters, and service management counters. Load Management supports specific load limitation objects at external interfaces of the SEP: the email interface (SMTP/POP3), the Web interface (HTTP), the SS7 in-terface (CAP/MAP/INAP), and the Online Interface.

The Local Element Management Access Function (LEMAF) is supported in case of emergency without invocation of the Commander. The following tasks are offered (dependent of the user role):

Configuration Management,

Display of performance monitoring counters,

Display of alarms,

Administration of trace,

Start/stop of processes,

SS7 administration.

Interfaces for OA&M functions

The SEP provides the following interfaces for OA&M functions:

CORBA (IIOP) interface for the connection to the @vantage Commander,

SNMP interface to the @vantage Commander for fault management,

FTAM/FTP interface to the @vantage Commander for ticket transfer for fault management,

TCP/IP interface for the support of Backup and Restore.





Training Center

Information and

Communications


SEP SEP

SMAP

TkF

Ticketing

FunctionSMF

Service

Management Function


(1 SEP, no SMAP)

SMAF

Service

Management

Access Function

SCF

Service Control

Function

TkF

Ticketing

Function

SEP

Data Base

SEP

Data Base

SCF

Service Control

Function

SMF

Service

Management Function


(n > 1 SEP, 1 SMAP)

Notes



5 Service Management Access Point (SMAP)

The Service Management Access Point (SMAP) covers the generic functions of the Service Management and the Service Management Access, i.e.:

Provision of access to services and user data,

Distribution of service data to various SEP clusters (by utilizing the SMAP Data Base).

In particular, the SMAP DB contains

Common Service Data (master data),

Personal data (master data),

Customer location data (master data),

Configuration data.

User-role specific service management access applications can be built on top of the generic SMAP functions. These functions may also be integrated into the SEP.

The SMAP functionality includes:

Flexible service and service subscriber management,

Secure user authentication and fine-granular authorization,

Single sign-on,

Role based access control,

Customized and easy to use graphical user interfaces (Web),

Support of single-cluster configurations as well as in large multi-cluster configurations.

The SMAP supports role-based access control as well as the ‘single-sign-on’ principle for net-work operator/service provider staff. The SMAP offers state-of-the-art technology in order to provide interfaces via Web GUIs (based on HTML), Java and CORBA (via IIOP) based open dia-log interfaces for implementing customer specific administration applications, and batch file in-terfaces (FTAM based bulk data interfaces) for the import/export of mass data.

Service management access activities can be logged, management requests are recorded in confirmation tickets which maybe processed by the Statistics Warehouse for statistical evalua-tion.



5.1 Functional Architecture

5.1.1 Service Management Function (SMF) / Service Management Access

Function (SMAF)

The SMF comprises functions for the management of intelligent services (service deployment, service provisioning, service operation control, i.e., service activation/deactivation, service data administration, customer/user management, etc.). The SMAF provides customer access to the service management functions:

Generic interfaces for service management

Support of customized and role-oriented Web GUIs for network operator, service provider, and service subscriber (GUIs based on HTML over HTTP, CORBA interfaces via IIOP, batch file interfaces using FTAM and FTP)

Single sign-on for network operator and service provider

5.1.2 Distribution Management Access Function (DMAF)

In multi-cluster configurations there is an additional need for distribution mechanisms for ser-vice data objects (in order to assign functions to the individual SEP and SMAP clusters). The DMAF extends the SMAF and covers all interfaces and functional extensions for customer ac-cess to distribution functionality:

GUI for the administration of the distribution function

GUI and CORBA interface for the administration of subscriber location information

DMAF provides location transparency for the SMAF client, i.e. the service management use cases as seen by the SAMF are the same as seen in a single and a multi cluster environment. It is used to

Retrieve status information on the broadcasted objects (e.g. if the distribution is currently run-ning, if the distribution failed, etc.)

Retry faulty transactions

Add/remove an SEP

5.1.3 Location Management Access Function (LMAF)

In multi-cluster configurations, it may be necessary to determine the location (i.e. SEP) where the persistent part of a service data object resides. The LMAF allows the customer to access location information for routed service data objects via external interfaces (GUI, CORBA, Batch). It provides functions to get / create / delete a location.



1Intelligent Services – IN@TR - Functional Roles


Training Center

Information and

Communications


SMAP

SMAF

Service

Management

Access Function

TkF

Ticketing

Function

SMAP

Data Base

SMF

Service

Management Function

DMAF

Distribution

Management

Access Function

LMAF

Location

Management

Access Function

(Subscribers)

SEP 1 SEP 2 SEP 3 SEP n. . . .

Service Creation Environment (SCE)

Notes



5.1.4 Ticketing Function (LMAF)

Management applications write tickets in the SMF using the Management Ticket Control Com-ponent (MTCC) of TkF; only confirmation tickets will be written. The ticket layout as well as the ticket field semantics is compatible to INXpress V6.2/V7b.

For the following “Confirmation Types” confirmation tickets must be written according to the persistant data handling:

Creation of object (only SMF-Customer)

Deletion of object (only SMF-Customer)

Modify of object (only SMF-Customer)

Confirmation tickets for

Outpayment

Recharge

Voucher-recharge

are written by SMF but not by SMAF, i.e. they are written on SEP.

The tickets mentioned above are used for monitoring and logging the administration actions of the operators staff to service or service subscriber objects. A ticket consists of:

Logging information

Time information

Specific information about the kind of action

5.1.5 Support of OA&M Functions

Operation, Administration and Maintenance (OA&M) functions supported at the SMP cover Fault Management, Configuration Management, Performance Monitoring, Load Management, and Backup / Restore.





Training Center

Information and

Communications


SMAP

SMAF

Service

Management

Access Function

TkF

Ticketing

Function

SMAP

Data Base

SMF

Service

Management Function

DMAF

Distribution

Management

Access Function

LMAF

Location

Management

Access Function

(Subscribers)

SEP 1 SEP 2 SEP 3 SEP n. . . .

Service Creation Environment (SCE)

Notes



5.2 Data Distribution

In particular, the SMAP DB contains:

Common Service Data (master data): Persistent data being encapsulated by features; common service data are shared be-tween services via usage of features, i.e. service independent (global) data that any ser-vice may access. The life cycle of common service data models are coupled to the IN product and call feature deployment. Examples: holiday calendar, international code number table. Common Service Data are distributed to the SEPs.

User Access Data (master data): User Management Function on SMAP stores user data of network operator, service pro-vider and service subscriber (e.g. external user id, function rights, roles) and correspond-ing password in SMAP database. User Access Data are not sent to the SEPs.

Service Specific Data: Service Specific Data compromise all persistent data on which a specific call service logic directly operates. Service data are coupled to the call service life cycle. While common service data are shared between call services via feature usage, service data are assigned to a specific call service logic. Service data may be classified according to the type of their owner (service customer type). For PPS-like services we may have network operator data, provider data, service specific subscriber data. Data, being available on SMAP and distributed to all SEPs (broadcast by distribution function, redundant data):

For network operator data: service specific global tariff table.

For provider data: service specific screening lists for each provider.

Data located on a dedicated SEP (routing by distribution function, non-redundant data):

dial tones, causes, tele/bearer data, node tables, Service Subscriber data (for example account of the subscriber or service specific DTMF PIN for each subscriber).

Announcements may be of the following categories:

"Global" announcements, which are configuration data of the platform, administered by @commander and stored at the SEP.

Announcements, which represent service, respectively feature data and which can be played in special states of a service, may be owned by the network or service pro-vider. They are available on SMAP and distributed to all SEPs.

Service Subscriber location data (SEP ID): A service subscriber is an object in the service customer hierarchy which

owns some service data

usually has a parent customer

may have zero or more child customers

has a service customer type.

Typical examples of service subscriber types are: Network Operator, Provider and Sub-scriber. As mentioned before, data of PPS-like service subscribers are stored in the SEP data-base. On SMAP database, only the location of the corresponding SEP is stored (DMAF).

SMAP Configuration data: Each component defines its configuration data model. The model defines a tree of con-figuration data objects. Basic elements of this tree are nodes (containing no data but used for structuring), sim-ple data (integer, strings, Boolean), tables of simple data





Training Center

Information and

Communications

Data Distribution

SEP 1 SEP 2 SEP n. . . .

SMAP DB contains:■ Common Service Data■ User Access Data■ Service specific Data

(master data) ■ Service Subscriber

Location Data (SEP ID)■ SMAP Configuration

Data

SEP DB contains:■ Common Service Data■ Service specific Data

(replicated data + master data)Service Subscriber Data

■ SEP Configuration Data

SMAP

Notes



6 Service Creation Environment

In this chapter the main principles of service creation are introduced

With IN@vantage version 7.2, the approach to Service Development respectively Service Crea-tion is based on two main steps:

The data model is defined in XML.

Java Code is generated.



6.1 Applying the Data Model

1. The Data Model has to be described in XML.

2. The Data Model has to be converted by the SMAT.

SMAT Service Management and Data Access Toolkit



1Intelligent Services – IN@TR - Operating Interfaces


Training Center

Information and

Communications

Applying the Data Model

***

**

***

Data Model Syntax (DTD)


Service Data Model (XML)


Data

modelling

�

�

Service Management Access Functions

Service Management Access Functions

Service Management Functions

Service Management Functions

Service Data FunctionsService Data Functions

SMAT

Notes



6.2 Data Model

The SCE supports the concept of an explicit service data/management model, which can be used to describe relevant aspects of call and management services. The data model will be de-fined during the service creation process by the service designer. It describes all service-specific persistent data needed by the service as well as relevant information for the represen-

tation and management of this data (via SDF and SMF) and its access via the external inter-

faces (SMAF).

The service data model

describes all persistent data of a service

describes also the service customer type hierarchy of this service

describes also the physical mapping of the data

describes also access methods for this data

The service model language is defined using the Extensible-Markup-Language (XML)

technology, such that the syntax is specified by a special Document Type Definition (DTD). When designing the V7 service/feature (data) model language, the following issues have been considered:

The XML technology reduces the effort to develop tools and applications by using existing XML-based tools, like XML editors, XML parsers, XML-based translators (code genera-tors, …), XML tree comparison tools, XML viewers, etc.

A goal of the service model is to generate Java code for SDF, SMF and SMAF. Therefore, the language concepts basically follow the object-oriented modeling approach, simplifying the usage and semantic understanding as well as the generation of Java classes / inter-faces.

The basic data model types can easily be mapped to the standard database base types, sup-porting the object-relational mapping of data representations.

Strict separation of “logical” and “physical” data model aspects; object oriented service data modeling should be possible without having fixed the physical object/relational data map-ping.

Support of declarative specification style, which focuses on the ‘what’ and not on the ‘how’. Separation of data modeling and attribution from management and access functions.

Additionally to the syntax, which is defined by the DTD, also semantics must be considered.

Also features may define their own data model. Feature data models do not contain all the in-formation a service data model may contain.





Training Center

Information and

Communications

Data Model

describes also the service customer type hierarchy of this service

describes physical mapping of the data

describes all persistent data of a service

describes access methods for this data

Notes



Data Model Structure

The Data Model is split up into the parts described above.

The figure also shows sub-aspects of the data model: Together with each data item properties like default value or value range have to be specified.





Training Center

Information and

Communications

Data Model Structure

(Call) Service Data Model

Service Data Model Definition

Data Type Definitions (Types, Ranges, Classes)

Data Object Definitions

Service Data Model Representation (Object-Relational Mapping Attributes)

Service Data Management Definitions

Flexible Data Range Definitions

Data Default Value Definitions

Data Constraints Definitions

Data Access Right Definitions (Object Rights)

Data Object Assignment to Business Hierarchy Levels

Service Management Access Definitions

Service Management (Access) Function Signatures

Notes



6.3 SMAT

The “Service Management and Data Access Toolkit” (SMAT) consists of a framework that al-lows to build translators which compile data models to (more or less arbitrary) target code.

The generator derives target code from the XML specification of a Service Data/Management Model.

YAGG

The generator for SMAT is called YAGG, that is "Yet Another Generator in our Galaxy".

The service data function is distributed over several platform components. All generated parts of the service data function will be part of the component, which uses it. The generic part of the service data function will be part of the service data component.

Output of YAGG is:

SMAF functions for data access via GUI, batch or programming interface (CORBA)

SMF functions to store and distribute data

SDF functions for access to the data by the SCF

After the Data Model has been translated by SMAT the service program logic has to be com-pleted in the form of Java sources.





Training Center

Information and

Communications

Service Conversion

SMAT

***

**

***





SMAF GUI (pages, JSP)SMAF GUI (pages, JSP)

SMAF GUI (implementation, Java)SMAF GUI (implementation, Java)

SMAF CORBA (interfaces, IDL)SMAF CORBA (interfaces, IDL)

SMAF CORBA (implementation, Java)SMAF CORBA (implementation, Java)

documentation, compatibility checker etc.documentation, compatibility checker etc.

SMAF Batch (implementation, Java)SMAF Batch (implementation, Java)

SMF (interfaces, Java)SMF (interfaces, Java)

SMF (implementation, Java)SMF (implementation, Java)

SDF (interfaces, Java) for Service Management and Call ServiceSDF (interfaces, Java) for Service Management and Call Service

SDF (implementation, Java) for Service Management and Call ServiceSDF (implementation, Java) for Service Management and Call Service

Data

modelling

�

�

Imple-

mentation

�

Notes



6.4 Features

A service designer can make use of predefined features.

Feature

Basic Fee & GTO

Location Information Evaluation

Offline Charging

Basic Tariff Model

Screening

Threshold Check

First Call Handling

DTMF Menu Item

Subscriber Lock Check

Pin Check

Recharge

Charge Free Detection

Online Charging

Authorization with User Identification

Tariff Determination

Multi Currency Support

DTMF Number Administration

Online Event Charging

Service Access

User Interaction

Authorization Profile

Ticketing





Training Center

Information and

Communications

Features (Examples)

Service AccessService Access

LocationInformationLocationInformation

ThresholdCheckThresholdCheck

Online ChargingOnline Charging TicketingTicketing

ScreeningScreening

User interactionUser interaction

Pin CheckPin Check

SubscriberLock CheckSubscriberLock Check

DTMF NumberAdministrationDTMF NumberAdministrationA service designer

can make use of a feature API

Notes



6.4.1 Reasons for the Feature Concept

The service feature concept will be introduced to:

�� reduce service development costs

�� reduce time to market and speed up the service creation process over all phases

�� enable more and more efficient service projects

�� enhance service quality and ease adaptation and maintenance

�� support migration friendly service design

The concept is based on the definition and consequent embedding of service features

in the service creation process. Well-defined, developed, tested and released service

features are used to define, simulate, specify, create and test IN services.





Training Center

Information and

Communications

Reasons for Feature Concept

� reduce service development costs

� reduce time to market and speed up the service creation

process over all phases

� enable more and more efficient service projects

� enhance service quality and ease adaptation and

maintenance

� support migration friendly service design

Notes



6.4.2 Example 1: Threshold Check

This service feature checks a given parameter against two thresholds. The feature differenti-ates following cases:

• parameter < threshold 1

• parameter = threshold 1

• threshold 1 < parameter < threshold 2

• parameter < threshold 2

• parameter = threshold 2

For each of the five possible cases the user can be informed based on the chosen exit path.

First the parameter will be checked against threshold 1. If the parameter is equal threshold 1 the feature ends in match A. If the parameter is larger than threshold 1 it will subsequently be checked against threshold 2, otherwise the condition was not TRUE and the check will be ended. The same process will be used for threshold 2. If the allowed range of values is not ex-ceeded the result is TRUE. In case that the parameter is outside the range of thresholds the result is FALSE.

The value range for parameter p must be defined.

Service Feature Usage

Depending on the thresholds and the parameter to be checked, the feature can be used as:

• Expiration date check

• Card validity check

• Minimum account balance check

• Minimum granted time check

• Turnover limits

• Credit limits

• Upper debit limit (assigned to customer)

• Upper item (price/goods) limit (assigned to merchant)

• Upper / lower account limit

For all time declarations the GMT format shall be applied.

Service Data

• Threshold 1

• Threshold 2

• Parameter ‘p’

• Exit A: fell short

• Exit B: in

• Exit C: exceeded

• Match A: equal threshold 1

• Match B: equal threshold 2





Training Center

Information and

Communications

Features Example 1: Threshold Check

Threshold 1

Threshold 2

Exit A: fell short

Exit B: in

Exit C: exceed Match B:

equal Threshold 2

Match A: equal Threshold 1

Task: compare a parameter ‘p‘ with two thresholds

Examples:Expiration date checkCard validity checkMinimum account balance checkMinimum granted time checkTurnover limits Credit limits Upper debit limit (ass. to customer)Upper item (price/goods) limit (ass. to merchant) Upper / lower account limit

Examples:Expiration date checkCard validity checkMinimum account balance checkMinimum granted time checkTurnover limits Credit limits Upper debit limit (ass. to customer)Upper item (price/goods) limit (ass. to merchant) Upper / lower account limit

Notes



6.4.3 Example 2: DTMF Number administration

This service feature enables the administration of a number or number list via DTMF phones.

The feature requests the caller to enter the position of the number in the number list he wants to administer. In case of single number administration this announcement will be suppressed.

The caller is informed about the current number. If the number is empty, an announcement in-forms about this fact. After that the caller is prompted to enter the new value. The new num-ber is announced and the feature may request the caller to confirm it. After successful confir-mation he may administer an other number in the list or finish the administration.

The DTMF Number Administration feature have to have the possibility charge the number ad-ministration operation online.

After invocation of the DTMF Number Administration feature a welcome announcement is played. If more than one element in the list of numbers exists, the caller is prompted to select one of the following options: (1) the number of the list element to be administered or (2) the selection code for an help announcement or (3) the selection code for exit.

When the input of the caller is collected, the valid range of input will be checked. It depends on the maximum number of list elements and the possible selection codes. If the input is valid and the current list element isn't empty the number of the list element and the stored number are announced. The caller is prompted to select one of the following options: (1) insert/modify the number or (2) return to the to the first prompt (cancel).

If the administration process is to be charged, the available credit will be checked. In case of sufficient credit the fee to be needed is reserved and the caller is informed using the right cur-rency. If the administration process isn't to be charged, the number of free administrations that have not been consumed yet is announced.

The caller is prompted to enter the new number. The new number is checked to fulfil the fol-lowing constraints:

• the number must have contain a certain minimum and maximum length,

• the number may not be an predefined emergency number,

• the number may not be equal to the own number of the caller (provided by Screening fea-ture),

• the number leads the a right screening result,

• the number may not be already administered in the list.

If a check fails, the feature returns to the first prompt. Otherwise the entered number is an-nounced.

The caller is prompted to select one of the following options: confirm/ not confirm (return to the first prompt).

After successful confirmation

• the new number is stored in the list,

• the administration process will be charged (if the administration isn't free of charge),

• the free of charge counter is incremented,

• an announcement is played and

• the DTMF Number Administration feature returns to the first prompt.





Training Center

Information and

Communications

******

Features Example 1: DTMF Number

Administration

List of numbersto be administrated

Threshold for free of charge attempts

Minimum length

Counter for free of charge attempts

number of list elements

Used e.g. for administration of:

• user speed list / short codes• FnF connections• favorite area(s)

• black/white list numbers

• follow-me numbers

Used e.g. for administration of:

• user speed list / short codes• FnF connections

• favorite area(s)

• black/white list numbers

• follow-me numbers

Maximum length

******

Notes

intelligent network in @ vantage in introduction...

Documents