Intelligent Network

1. Introduction to IN

1.1 Introduction The purpose of this module is to provide the student with an introduction to the basic concepts behind Intelligent Networks. All the areas covered in this module are covered at an overview level. More detail is provided in the later modules.

Module Objectives After completing this module the participant will be able to: • Describe the purpose of the IN concept • Identify the different IN nodes • Describe the standardisation of IN and Ericsson’s IN release

Figure 1.1

Module Objectives.

1.2 What is IN? The term “Intelligent Network” means a network capable of meeting market demands for new services in a flexible and cost effective way. Ericsson’s products for advanced IN enable service providers to structure and program a wide range of advanced network services. The products, based on the AXE system and upon general-purpose computers, are capable of meeting the requirements for service availability to all subscribers in the network.

1.3 Driving Forces for IN There are many different driving forces for IN today. The telecom market has changed for the operators due to the deregulation. The monopolies of the old telecom administrators have ended and they now have to compete with other operators on the same market. That implies new demands to the operators to find ways to attract the customers. The IN concept makes it possible to meet the increasing market demands for more advanced services, in a faster, more flexible and thus more costeffective way. The introduction of IN services in the network contributes to higher revenues for an operator. Due to the availability of a wide range of new attrac-

1

IN 2.3 Service Testing Course

tive IN services the traffic as well as the number of successful calls will increase. The great advantage of IN, which has also been one of the driving forces behind its introduction, is that it drastically has reduced the time of introducing a new service in the network, from 2-4 years down to six month and even less. Other advantages are that a certain service in the network is controlled from one or a few central points (SCPs) instead of a great number of distributed points which is the case for conventional supplementary services. This greatly facilitates all administrative procedures like introduction, change or withdrawal of a service. Centralised control and administration also gives a better overview to the operator of the services in the network.

1.4 Background to IN The term "Intelligent Network" was phrased within BELLCORE in 1984. It started as a concept to help the newly born Regional Bell Operating Companies (RBOC) in the United States to become more competitive in the new deregulated environment. IN was, and still is, inspired by the advances in modern operation system and data base technologies. One of the scopes has been to bring computer vendors and products into the telecommunications market. In international standardisation the task is gradually being reached in defining IN as: "A telecommunications network with service independent capabilities that allows the network service providers or operating companies to independently define and competitively provide new network services".

1.5 Introduction to the IN Concept IN services are stored centralised in the network in an SCP (Service Control Point). The SCP acts as a data base where the IN services are stored and executed. The IN services are normally created with the help of SMAS which is a user friendly tool for creation and handling of IN services. The Ericsson way of creating IN services is called "The Service Script Concept". When a service has been created in SMAS it is installed in the SCP where it is executed. SMAS is an application within TMOS which is Ericsson’s concept for centralised operation and maintenance. No calls (speech circuits) are switched in the SCP. Switching of IN calls are done in the SSP (Service Switching Point). The SSPs are usually transit exchanges with some additional software. The SSP and the SCP are the two most important nodes in an IN network. When an IN call is received by an SSP, the SSP needs to send a request to an SCP and ask how the IN call shall be switched. This type of information exchange between the SSP and the SCP is carried out with the help of IN 2

Introduction to IN

signalling (i.e. the INAP protocol). INAP is part of the signalling system #7 and lies on top of the protocols: TCAP, SCCP and MTP.

SDP SMAS IN Service Control

SCP

SDF

SCE SCF SMS IN Service Management

INAP SSP SSF CCF

IP SRF

IP

IN Call Control

Speech, data Signalling

Figure 1.2

Components of the IN Network

It is important to distinguish between the IN functions and the IN nodes. In Figure 1.2 we have the following: SSF - Service Switching Function in a Service Switching Point (SSP) SCF - Service Control Function in a Service Control Point (SCP) SRF - Specialised Resource Function in a Intelligent Peripheral (IP) SDF - Service Data Function in a Service Data Point (SDP) CCF - Call Control Function (TCS in AXE) in a SSP INAP - Intelligent Network Application Part, the IN protocol SCE - Service Creation Environment in the Service Management Application System (SMAS) SMS - Service Management System (in SMAS) The SCF has the service control for an IN service while the SSF has the call control (on behalf of the SCF) for the IN calls.

3

IN 2.3 Service Testing Course

1.6 Differences between IN 2.1 & CS1 The functions of IN 2.1 and CS1 are not the same. CS1 has operations for Networked IPs which is not a part of IN 2.1, while IN 2.1 has more capabilities to use announcements during the call phase and to different call parties. IN 2.1 contains the SDF interface. This is kept in the CS1 environment, but with new SIBs. This interface is still an Ericsson proprietary interface, and in the IN 2.2 release it will therefore be denoted as CS1(+).

4

Introduction to IN

1.7 IN Network Nodes 1.7.1

SSP - Service Switching Point The SSP is responsible for all functions concerning switching of IN services. The switching is carried out as a result of service execution in the SCP. There is a continuous flow of information between the SSP and the SCP. The SCP decides about the switching and gives order to the SSP. The SSP informs the SCP about the subscriber activity and the call status in the switch. There are a number of important areas handled by the SSP. All these areas are described in the coming modules. SSF is divided into five subfunctions in IN 2.1: 1.

General

2.

Triggering and Invocation

3.

Congestion Control

4.

Special Resources

5.

Charging

A new CS1 SSF has been developed and added in IN 2.2. The subfunctions are now called: 1.

Triggering (changed from IN 2.1)

2.

IN Call Control (new)

3.

Dialogue Control (new)

4.

Mass Call Service (new)

5.

Special Resources

6.

Charging.

Triggering occurs when a Trigger Detection Point (TDP) is armed and the criteria for this Detection Point (DP) is met during the call process. In the SSP a new parameter called In Service Triggering (IST) is introduced. IN Call Control is the interface in SSF towards the Call Control Function (TCS) in order to allow SCF to control the call processing and the connectivity of the call. Dialogue Control makes all established dialogues behave according to determined rules. These rules are supervised by so called Finite State Machines (FSMs) in the SSF. These FSMs reflects the state of the dialogues and controls the reception and sending of operations between the SSF and the SCF. Mass Call Services contains two functions (Call Gap and Service Filtering) for protecting the SCF against overload as well as filtering of calls for televoting.

5

IN 2.3 Service Testing Course

1.7.2

SCP- Service Control Point The purpose of the Service Control Function (SCF) is to process the logic and data which makes a service and to interact with the SSF when appropriate in order to perform the service in the network. The SCF can be implemented in two ways:

1.7.3

1.

As a stand-alone node in the network called the Service Control Point (SCP)

2.

As part of a node which has both SSF and SCF functions, called the Service Switching and Control Point (SSCP)

3.

The SCF can exist on two platforms:

4.

As a software-only application on a telecommunications platform such as AXE. In this case the SCP is referred to as an SCP-T.

5.

As a set of software programs on a general purpose computer such as UNIX. In this case the SCP is referred to as an SCP-G (General purpose computer).

SSCP - Service Switching Control Point So far we have mentioned two different types of IN nodes, the SSP (Service Switching Point) and the SCP (Service Control Point). The software functions required to realise these IN nodes are mainly found in the AXE subsystem SES (Service provisioning subsystem). SES is divided into two functions, the SSF (Service Switching Function) to realise the SSP and the SCF (Service Control Function) to realise the SCP. Both the SCP and the SSP are today AXE nodes. The reason for the SSP to be an AXE node is easy to understand as the SSP is always a telephony exchange. The SCP, being a data base, is today built on the TPC (Telecom Purpose Computer), i.e. the AXE platform using the APZ processor. In IN phase 2.2 an SCP built on a GPC (General Purpose Computer), i.e. a UNIX platform will also be available. The SSF is usually implemented in a transit exchange but it can also be implemented in a local exchange. One type of services requiring implementation in a local exchange are services that can be subscribed on (e.g. Call forwarding). When a subscriber is subscribing on "Call forwarding" and it is activated, all calls to his phone are forwarded to a pre-programmed phone number. It is only the local exchange that can be informed about how a specific subscribers phone is programmed. These services are today mainly implemented as supplementary services. Mass call services, e.g. Televoting, can be another reason for having the SSF in the local exchange. During mass calling the transit exchanges will many times get to congested to be able to handle all calls. In these cases the calls can be better taken care of by the SSF in the local exchange. The SSP and the SCP distributes the IN functionality in the network. Except this distributed way there is also the possibility of implementing all functionality in one node, the SSCP (Service Switching Control Point). This is a combined node including both the SSF and the SCF. The SSCP

6

Introduction to IN

has its main advantages if there is mainly analogue transmission and no #7 signalling available in the network. The SSCP was the first IN node developed, that was in IN phase 1. There exist also another IN node, the SDP (Service Data Point) which among other tasks can be used to store customer data. An IP (Intelligent Peripheral) can also be an IN node. An IP handles equipment for announcements and reception of digits from the subscribers.

SCP SCF

SSCP LE

SSF+SCF

SSP LE

SSF

Figure 1.3

IN Nodes

1.7.4

SCP-G - Service Control Point-General Purpose Computer The SCP-G provides Service Control Point functionality on a General Purpose Computer platform. Since it is built on a general purpose computer platform, the SCP-G has advantages like scalable configurations from low-end to high-end systems and openness in terms of adding third party products. It is compliant with the ITU-T Capability Set 1 (CS1) protocol, plus a subset of the Ericsson INAP protocol (EINAP). The SCP-G has built-in high availability that allows it to continue operation after the failure of any single component. The SCP-G is managed by Ericsson’s Service Management Application System (SMAS), which offers service creation, provisioning, and network management capabilities. SMAS can also be used to manage and provision Ericsson’s AXE SCP (SCP-T).

7

IN 2.3 Service Testing Course

SMAS

TCP/IP

SDP TCAP over

SS7 SCP-G

SCP-G TCP/IP

TCAP/SS7

SSP

SSP

IP

Figure 1.4

IN Network with SCP-G

The SCP-G is comprised of the following functions:

8

1.

The Service Management Function (SMF) provides support for the SMAS interface.

2.

The Database Function (DBF) provides management support for the Sybase data server.

3.

The Local Data Function (LDF) manages the SCF disk-based objects and provides support for the mated pair interface.

4.

The Service Control Function (SCF) provides the service logic execution and the management of the RAM-based database of service and subscription data.

5.

The TC-User Function (TCF) provides support for interfacing with a Service Switching Point (SSP) and an Service Data Point (SDP). It also provides support for traffic simulation.

6.

The Traffic Simulation Function (TSF) provides support for service testing.

Introduction to IN

7.

The Service Node Application Platform (SNAP) provides the process management, configuration management, alarm handling, data logging and OA&M functions.

8.

The SS7 stack has responsibility for handling the SS7 protocol stack and for supporting traffic related statistics.

The SCP-G is designed to be a highly available system. It consists of one or more Functional Processors (FPs). An FP represents a single UNIX server in the SCP-G and may have multiple Central Processing Units (CPUs). In most cases, the above functions can be distributed across multiple FPs or can reside on the same FP. The exceptions being SCF and TCF, which must reside on the same FP. There are generally two instances for each type of function, one in a primary mode and one in a stand-by mode. When an FP fails that contains a primary function the corresponding stand-by function becomes primary. Until the failed FP is returned to a normal state, no stand-by function is available. It is also possible that for a given function there is no active stand-by function. Although there is no active stand-by function, there is a designated FP on which the function assumes primary responsibilities if the FP that is currently running as the primary function fails. Network transactions (i.e., traffic) involve the primary SS7 Stack, the primary TCF and the primary SCF. The stand-by SS7 Stack, DBF and SCF do not participate in the handling of network transactions, but are active in a “warm stand-by” mode. The stand-by functions will become primary and take over traffic handling in case of a failure of a primary function. Updates from SMAS are handled by the primary SMF then propagated to the primary and stand-by DBF. After successful completion by the DBF, the update is relayed to the primary and stand-by SCF. In this way both disk databases, and both RAM databases stay synchronized.

1.7.5

SDP - Service Data Point The Ericsson Service Data Point (SDP) is a database storage and retrieval system that has been developed as an integral part of the Intelligent Network (IN) product offerings from Ericsson. The SDP is used to store and handle large quantities of subscriber data, which can significantly increase the number of subscribers supported by the Service Control Point (SCP). The SDP consists of the following:

9

IN 2.3 Service Testing Course

• • • • • • •

Service Data Point (SDP) application software Service Node Application Platform (SNAP) software EINAP TC-User network communication from the UTS subsystem SYBASE® database management system Hewlett-Packard™ (HP) 9000 series hardware Hewlett Packard™ - UNIX (HP-UX) operating system environment HP Signalling System No. 7 (SS7) hardware and software

This HP equipment is a highly available system, it is not fault tolerant. The customer data held by the SDP can be managed by a Service Management System (SMS). When SDPs are configured as mated pairs there is a problem with customer data as it is often changed, e.g. the PIN code in the UPT service. If data is changed in one SCP the other SCP in the pair needs to be updated. The updating procedure between SCPs is quite time consuming as it has to be carried out via SMAS. Many of the problems with customer data can be solved with an SDP (Service Data Point), introduced in IN phase 2.1. One purpose of the SDP is to store subscriptions, i.e. customer data (CDMs), centralized in the network. Large volumes of data can be stored and no update between SCPs will any longer be needed. The SCPs will still store the service logic as well as local- and global data. During service execution the SCP will retrieve the customer data from the SDP. The installation of a subscription from SMAS to the SCP takes much longer time than the same procedure from SMAS to the SDP. That is due to (among other things) the simplified database structure of the SDP.

SDP - Service Data Point HD - Hard Disk #7 = Signalling System #7

SDP HD

HD

Primary Server #7-link

Figure 1.5

SDP - Service Data Point

10

HD

Ethernet

HD

Secondary Server #7-link

Introduction to IN

The SDP can be configured in different ways, one configuration is shown in Figure 2.2. In this case the SDP consists of two separate servers each of them connected to a hard disk pair. In this SDP the same customer data is stored on four different hard disks. Each of the servers have a separate #7 signalling connection and they are interconnected over Ethernet.

1.7.6

IP - Intelligent Peripheral When a service involves interaction with a user, IN will use an Intelligent Peripheral (IP). An Intelligent Peripheral can be defined as a physical entity that implements the IN Special Resource Function. The functions of this special resource can include one or more of the following:

• to make an announcement to a connected leg of a IN call (an announcement machine)

• to record a message which a service user wants to leave (a listening machine)

• to receive digits from a Dual Tone Multi-Frequency (DTMF) phone (a digit reception device)

• to perform speech recognition • to provide voice and fax mail facilities At present, the most common Intelligent Peripherals are those which perform the first three of the above functions. There are four types of Intelligent Peripheral: 1.

Integrated IP: this is located within an MSC/SSP node. All communication with the IP takes place through the use of internal protocols. It can make announcements and monitor for digits and is under the control of the SCF.

2.

Networked IP: this is connected to both an SSF and an SCF directly. Communication with the IP takes place using a standardised signalling protocol for IN equipment. It can make announcements and monitor for digits and is under the control of the SCF.

3.

Stand-Alone IP: this is external to an MSC/SSP node and is not connected directly to the SCF. Communication with the IP takes place using ordinary telephony network signalling protocols. The stand-alone IP can make announcements and monitor for digits. However, results (such as digits) cannot be returned to the SSF and can only be used within the IP itself. Stand-alone IPs are not under the control of the SCF.

4.

Advanced IP: this is external to an MSC/SSP node but is associated with an MSC/SSP. It exists on TCP/IP connected workstations and is connected to the MSC/SSP. Thus, the advanced IP enables the connection of multi-vendor audio and information systems to the network for the purpose of user interaction. This provides robustness and scalability in the network, because the SSF distributes all processing of user interaction features to the advanced IP.

11

IN 2.3 Service Testing Course

SCP

SSCP

IP Network IP

IP

IP

IP

Advanced IP

CCF

SSF

IP

IP Integrated IP

Stand Alone IP

Figure 1.6

All types of IP.

12

Introduction to IN

1.8 IN Standards Ericsson has undertaken pioneering work in IN and has worked at a more advanced stage than the international standards. Accordingly, Ericsson developed a proprietary specification called Ericsson INAP. Subsequently, INAP standards have been promoted with the ITU-T CS-1 specification and the ETSI Core INAP specification. Although Ericsson INAP and the ITU-T CS-1 specification are very similar in functional terms, the models and operations are different. Ericsson is actively engaged in developing and promoting international standards for IN. The twin pressures of a significant existing customer base using Ericsson INAP and market demands for CS-1 INAP has necessitated the development of Ericsson INAP CS-1+. CS-1+ provides backward compatibility for Ericsson INAP and also full compatibility with CS-1. Ericsson INAP CS-1+ extends INAP CS-1 with additional operations and parameters. The function specifies the INAP operations, parameter descriptions and detailed operational procedures. The operational procedures specify the expected behaviour of the functional entities for each operation.

1.8.1

ITU-T Capability Sets The International Telecommunication Union (ITU) is working to harmonise the IN standards worldwide. The ITU-T have defined a set of capabilities for the Intelligent Network. The list defines the functionality against which IN vendor equipment is assessed rather than services that are intended to be launched to customers. The list of recommendations below define the ITU-T Capability Sets: Q.120

General Series IN Recommendations Structure

Q.1201/1.312

Principles of IN Architecture

Q.1202/1.328

IN Service Plane Architecture

Q.120/1.329

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.1290

Glossary of Terms used in the Definition of IN

The goal of the ITU-T is to harmonise IN standards worldwide. The Q.121x series of recommendations is referred to as the international IN Capability Set (CS-1). CS-1 defines the overall architecture and vocabulary. The 14 recommendations contained within CS-1 were ratified in March 1993 and were printed in December of that year. Q.1211

Introduction to IN CS-1 13

IN 2.3 Service Testing Course

Q.1213

Global Functional Plane for IN CS-1

Q.121

Distributed Functional Plane for IN CS-1

Q.1215

Physical Plane for IN CS-1

Q.1218

IN Interface Recommendations for CS-1.

CS-2 is currently being developed. There are new specifications for personal mobility and international services being added in this standards version. CS-2 is due to be published in 1997.

1.8.2

ETSI ‘core’ standards In 1994, the European Telecommunications Standards Institute (ETSI) defined a ‘core version’ of the ITU-T recommendation that focuses on basic issues. The purpose of the ‘core standard’ is to provide a basic subset that should be implemented. ETSI ‘core’ INAP handles the inter-working functionality required by the CS-1 specification. It is used for inter-working between nodes in a multi-vendor environment. in the future, ETSI will contribute to the development of the ITU-T recommendations. The ETSI standards map closely against the ITU standards.

1.8.3

Q.1211

Guidelines for CS-1 Standards?

Q.1213

Global Functional Plane for IN CS-1

Q.1214

Distributed Functional Plane for IN CS-1

Q.1215

IN CS-1 Physical Plane

Q.1218

Core INAP.

Bellcore standards The term Intelligent Networks was first coined in the mid 1980s (1984) within Bellcore, a research facility of the regional telephone companies in the US. In 1984, the Regional Bell Operating Companies (RBOCs) choose to implement the Freephone 800 service using a central database to handle queries on how to handle the call, modelled on the AT&T system. In the early 1980’s, Bellcore started work on developing AIN standards in the United States. This work coincided with the telecom deregulation in the US. The first set of specifications, IN/1, were published in 1986. These specifications were used to implement early versions of the Freephone service. There have been several revisions since and the current set of recommendations is AIN 0.1 (following AIN 0.0). The development of AIN 0.2 and AIN 1.0 is ongoing. In time, it is likely that the ITU-T recommendations will incorporate the Bellcore specifications.

14

Introduction to IN

1.8.4

Ericsson standards IN development work in the Netherlands in 1988 (Phase 1- within the AXE 10 APT 210 08 R4 source system project) resulted in the Ericsson Service Script Interpreter (SSI) concept and a new application for the IN service creation and management called SMAS. Phase 1.0 introduced the first release of SSI (SSI/1) for the Ericsson SSCP. SSI/1 is contained in the AXE 10 TCS (Traffic Control Subsystem) and contains 34 SIBS called Control Types (CTs). An Ericsson proprietary protocol is used for communication between the SSF and SCF. In the US (1991), the Ericsson SSI/1 product was used to provide SCF functionality in trials of IN according to United States Bellcore AIN 0.0 standard. This necessitated the development of a non-proprietary SSF-SCF communication protocol according to RBOC Ameritech specifications which were based on the ANSI TCAP standard. The evolution of SSI/1 began in 1991. It resulted in a functionally richer SSI called SSI/2. IN 2.0 is a platform for local and international transit nodes, based on the AXE 10 APT 210 08 R5 IN 2.0 introduced the following additions into the Ericsson IN portfolio:

• The encapsulation of SSF and SCF software into a dedicated AXE 10 subsystem called the Service Provision Subsystem (SES)

• Stand alone SSP and SCP available through the development of support for communication between standalone SSF and SCF over SS7 TCAP protocol (ITU-T Blue Book version).

• An increase to 79 in the pool of supplied SIBs in the SCF to permit new validation services, as well as the SSI/1 translations services.

• The introduction of a new IN product called Service Data Point (SDP) and support for the Intelligent Peripheral (IP) function through the Ericsson AST-DR.

• A General Service Adapter (GSA) tool on top of the SMAS/TMOS application for service management and creation In the US (1992), the Ericsson product SSI/2 was used in trials based on the AIN 0.1 standard from Bellcore. The Bellcore AIN 0.1 standard approximately corresponded to the European standard Capability Set No. 1 (CS 1). IN 2.1 which was release in 1994, provided the capabilities to create IN services for PSTN and ISDN subscribers. The IN2.1 SCP is based on the Ericsson Source Systems APT 210 11/3 and APT 210-12/3. Together these support basic telephony (POTS), SS7 signalling Transfer Points (STPs) and ISDN in addition to IN applications at local and transit level in the network. IN 2.1 introduced the following additions into the Ericsson IN portfolio:

• New services for both end users and operators • Support for basic ISDN and Signalling Transfer Point STP (SS7) for IN 15

IN 2.3 Service Testing Course

functionality

• Support for connection and inter working with Siemens and Alcatel SSPs through the addition of a product called the Inter Working Unit to the SCP

• SSF- SCF communication using SS7 INAP protocol and the handling of the transport of INAP protocol messages in the form of TCAP messages over SS7.

16

Introduction to IN

1.9 Module Summary • IN is a way of implementing services in the network. These services are called IN services.

• The node for storing IN services is called the SCP and the node for switching IN calls is called the SSP. These nodes can as well be combined into an SSCP.

• IN 2.1 has a different SSF Call Model than the CS1 based SSF • "Special Resources" includes equipment for sending of announcements to the subscriber and receiving of digits from the subscriber. This type of equipment is implemented as IPs.

• The SDP is a UNIX based node for massive data storage. It has a simplified data base structure which speeds up the handling of the data.

• IN (Intelligent Network) started as a concept within BELLCORE in the US in 1984 to help them to become more competitive. This is still the main driving force.

17

IN 2.3 Service Testing Course

18

SMAS, Red Line Trace

2. SMAS, Red Line Trace

2.1 Introduction The purpose of this module is to provide the student with an overview of SMAS with an focus on the Audit function and to familiarise the student with the user interface of Red Line Trace, and its functionality with regards to function testing and verification.

Module Objectives After completing this module the participant will be able to: • Explain the main purpose of SMAS • Understand the functions of SMAS • Perform an Audit of a service. • Explain the main purpose of Red Line Trace • Understand the function of the RLT menu options • Perform Red Line Tracing of a service. Figure 2.1

Module Objectives.

2.2 SMAS Overview Ericsson’s products for Intelligent Networks (IN) allow network service providers to structure and program a wide range of advanced network services. The products can supply services to all subscribers in the telecom network. It is the Service Script Interpreter (SSI) in the AXE 10 or SCP-G (SCP-General purpose computer) system that gives these opportunities. One of Ericsson’s products for IN is SMAS. SMAS provides a userfriendly interface based on graphic presentations, thereby offering a service provider a way to quickly introduce new, competitive services that meet any customer’s needs.

2.3 What is a “Service”? The modern use of a telephone network implies much more than simply connecting two telephones. In a world where personal and professional relations are increasingly dependent on maintaining communication over considerable distances, it becomes more and more important to have a well-functioning and effective telephone network. The use of telephone services expands the application range of telephone traffic. It becomes 19

IN 2.3 Service Testing Course

easier to get in touch with people, leave messages, use the phone for marketing purposes, and so on. A few examples will give an idea of the possibilities provided by telephone services. One very useful telephone service is the personal number. Every subscriber is given a personal number at which he or she can be reached regardless of his or her whereabouts. The subscriber can specify different numbers where the he/she could be reached. The subscriber can call a central number and update this information at any time. When the personal number is dialled, the network will attempt to reach the user at each number in turn until all possible values have been tried or until the phone is actually answered. This service also includes the possibility of calling from any telephone and charging the call to the personal number. Universal number is another service. Imagine that a company, for instance a travel agency, wishes to be reached from a universal number. Depending on the caller’s geographical location, day of the week and time of day, the caller can be connected with different numbers, so that an office which is open is always reached. This is now possible, thanks to advanced service facilities. Other examples of services are freephone, pre-paid calls, credit-card calling, hot line, queuing, tele-voting, information-delivery services, and information-retrieval services.

2.4 What is SCE / SMS? Service Creation Environment (SCE) / Service Management System (SMS) is used for the creation and management of IN services. It is used only for design and support of IN services and does not take an active part in the actual telephone traffic. SCE / SMS makes it possible to define services, install services in a network, handle subscribers and subscriptions, and receive and present service monitoring information from the network such as statistics and call reports. To protect the network from overload, SMS also provides facilities to administer call gaping. SCE / SMS is divided into a number of sales objects: Service Management Platform, Service Creation, Service Deployment, Service Provisioning, Service Monitoring, Service Troubleshooting, Network Traffic Management, different Control Type Collections, Database Customer Programming Interface and C++ Customer Programming Interface. SCE / SMS allows the operating companies to define and implement IN services. These services, such as freephone, credit card call, personal number and virtual private network, can then be introduced throughout the network.

20

SMAS, Red Line Trace

2.5 Why SCE / SMS? SCE / SMS provides the operator with tools to define, install, administer, and maintain services and subscriptions in the network. It also provides tools to generate and present statistical information. SCE / SMS has been developed to provide easy-to-use interfaces based on graphic symbols, windows and forms. A service can be directly designed in the SSI, however, this is a very complicated procedure. SCE / SMS also includes functions for communication with all SCPs, SDPs, STPs and HLRs in the network, which means that SCE / SMS makes it possible to centralize service design and administration.

2.6 SCE / SMS Sales Objects The different sales objects that make up SCE / SMS are:

• Service Management Platform – This sales object is the platform for all functions of SCE / SMS. It contains the SCE / SMS databases which handle data during the service design and administration processes. It also communicates with the TMOS Platform so that information can be transferred between the SCE / SMS databases and the NEs in the network.

• Service Creation – This sales object is used to design SSLs which then are connected to form SLs. It is also used to define and connect service data with the logics. There is also an application for transferring service logics and service data between different SCE / SMS systems.

• Service Deployment – This sales object is used to install the services in the SCPs and to define a mate to an already defined SCP. It is also used to test a service; either a new service in order to test its function or for troubleshooting an already existing service or subscription.There is also an application for transferring service logics and service data between different SCE / SMS systems.

• Service Provisioning – This sales object is used to define subscribers and to connect the subscribers services. Customer-specific data is defined, and the subscriptions are installed in the SCPs. New administration groups can be defined and assigned different levels of permissions. There is also a tool for SDP data administration.

• Service Monitoring – This sales object is used to generate and present statistical data for the services, and to generate and present traffic measurement reports.

• Service Troubleshooting – This sales object offers applications for troubleshooting, and auditing the services and the subscriptions.

• Network Traffic Management – This sales object is used to protect the SCP against overload by administrating data belonging to the parts of the logics which are defined as Network Traffic Management related.

• Control Type Collections (CTC) – These sales objects provide the Con-

21

IN 2.3 Service Testing Course

trol Types which are used to create SSLs.

• Database Customer Programming Interface – This sales object has no graphical interface but provides Application Programming Interfaces (APIs) to the Service Provisioning sales object, that is, it allows a user to write own applications and APT-based user interfaces for the Service Provisioning sales object.

• C++ Customer Programming Interface – This sales object has no graphical interface but provides Application Programming Interfaces (APIs) to the Service Provisioning sales object, that is, it allows a user to write own applications and OpenWindows-based user interfaces for the Service Provisioning sales object. The Service Management Platform and one or more of the CTCs must always be available. Service Creation, Service Deployment, and Service Provisioning are used for the actual creation and administration of a service, see figure below. Service Monitoring, Service Troubleshooting, and Network Traffic Management provide the tools for monitoring, maintaining, and troubleshooting the network. 1. Elaborate Service Idea

1. Market demands provide an idea for a service. Logic and data are outlined.

2. Define Service Logic and Service Data

2. The service is realised by the creation of Service Logic and adding of Service Data in Service Creation. 3. The service is installed in the SCP via Service Deployment.

3. Install the service

4. Administer Subscriptions Subscriber Name..................... Tel.No.................... Address.................. Service name.........

4. When the service has been created and installed, subscribers can be connected with the service. This, and the addition of subscriber-specific data, is done in Service Provisioning.

Figure 2.2

How to create a new service and connect subscribers to the service.

22

SMAS, Red Line Trace

2.7 Service Elements The Service Script Interpreter (SSI) is a service-independent platform on which a number of control types are stored. Each control type performs a pre-defined function. An implementation of a control type is called a Logic Module (LM). An LM is the smallest logical building block in the SSI. An LM has one input and zero, one, or more outputs. An LM can be activated during traffic and when activated, the LM behaves according to its control type. To be able to work, most LMs must be connected to a Data Module (DM). The DM contains the data specific for that LM, for example when to use the different outlets. The LMs are combined to form service script logics (SSLs), which provide more complex functions than the LMs. The outlets of one LM are linked to the inputs of other LMs to form the desired SSL Logic Module Logic Module Logic Module

Logic Module Logic Module Logic Module

Logic Module

Figure 2.3

A service script logic.

Different parameters (for instance time of day, day of the week, A-number origin etc.) control the selection of outlets, and thus define the way in which the service will be accomplished. It is convenient, however, to split a service into different levels, using one or several SSLs for each level and then linking the different SSLs together to form a complete service. Script Levels The first level is called the system level. The first script on the system level is called the ACCESS script. When the invocation is sent from the Service Switching Function (SSF) to the Service Control Function (SCF), this script is activated first, independent of which service is requested. Usually this script performs some kind of number analysis to identify which service/subscription is requested. The ACCESS script is common to all services in the SCP. The other scripts at the system level are the ERROR, UPDATE, SAFILTER, and SCFPROCES script. These scripts are also common for all serv-

23

IN 2.3 Service Testing Course

ices in the SCP. The ERROR script is automatically activated when a fault occurs during the interpretation of a service. The UPDATE script is activated when an update event, due to for example congestion control, is received from the SSP. The SAFILTER script is used for receiving SSF response in the FILTER control type, and the SCFPROCES script is used when creating a new process in the SCF. Scripts intended for a specific group or category of services/subscriptions are called group scripts. A group script is common for all subscribers to a specific service. However, it is possible to connect data modules (customer data) to this script, which allows modification according to each subscriber request. This level is called the service level. On the service level there is also a script called Customer Control (CC) script. This script may be used as a support script when customer data changes via DTMF against data residing in an SCP shall be performed. To be able to change customer data residing in an SDP via DTMF, no CC script is required. The third level, called the subscriber-specific level, contains scripts intended for a specific service subscriber. A unique subscriber-specific script is created for each subscriber if the service includes subscriber-specific scripts. It is possible to modify the data modules in the subscriberspecific script according to each subscriber request. SYSTEM LEVEL

SERVICE LEVEL

ACCESS SCRIPT

GROUP SCRIPT

ERROR SCRIPT

CC SCRIPT

SUBSCRIBERSPECIFIC LEVEL SUBSCRIBERSPECIFIC SCRIPT

UPDATE SCRIPT

SDP Data

Figure 2.4

Service Script Levels.

24

SMAS, Red Line Trace

In addition to the different levels described above, the service can be designed to use an external database (SDP) for storage and/or retrieval of information. To be able to access an SDP, the scripts must contain specific Control Types. Those make it possible to read from and/or write to the SDP. A service can contain only group scripts, only subscriber-specific scripts or combinations of both. The order between the different kinds of scripts is not relevant. The functions of the different SCE / SMS interfaces and the usual design and administration procedures are described in more detail in the following modules. Each SCE / SMS sales object also has its own SCE / SMS User Guide description, where each interface is described in great detail.

25

IN 2.3 Service Testing Course

2.8 Service Management Platform SCE / SMS is designed as a number of application units, built on the Service Management Platform.

C++ Customer Programming Interface

Database Customer Programming Interface

Control Type Collections

Network Traffic Management

Service Troubleshooting

Service Monitoring

Service Provisioning

Service Deployment

Service Creation

Service Management Platform

TMOS Platform (TPF4)

Table 2.1

The SCE / SMS application units, built on the Service Management Platform.

The SCE / SMS Platform is the platform for all functions of SCE / SMS. It contains the databases which handle data during the service design and administration processes. It also communicates with the TMOS Platform so that information can be transferred between the databases and the SCPs in the network. The SCE / SMS Platform also contains the user functions which are common for all SCE / SMS applications. These functions are handled by the following applications:

• SCE / SMS Administration • SCE / SMS Locators

2.9 SCE / SMS Administration SCE / SMS Administration provides the tools for administration of the SCE / SMS system. The graphic user interface for SCE / SMS Administration consists of seven base windows, one for each application, and associated pop-up windows and forms. The different base windows are all opened from the workspace area. The applications are described in the following:

2.9.1

SSL Designer To be able to design Service Script Logics (SSLs), Service Logics (SLs), and Service Data a user must be defined in SCE / SMS as a Service Script Logic Designer. The SSL Designer function is provided for that purpose.

26

SMAS, Red Line Trace

2.9.2

Network Element Administration The graphic user interface for Network Element Administration allows the user to list, define, delete, and modify Network Elements (NEs). Two NEs of the same type can be defined as being mated. It is also possible to view details about an NE.

2.9.3

Event Log Manager The purpose of the event log is to maintain a history of system activities that directly or indirectly affect subscriber services. The events logged may be used for monitoring, troubleshooting, and auditing an SCE / SMS system.

2.9.4

Data Translation Editor The Data Translation function allows the user to add, delete and update site specific meanings of certain text parameters, for example routing information and error values.

2.9.5

NE Request Queue The NE Request Queue is a function used for communicating with a Network Element (NE). A request, for example an installation or a removal (of a service, subscription or global data module), an audit, or a data module update, is always executed as a background process. A request may be specified for immediate execution or scheduled for later execution. Two forms are provided to be able to see the NE Request Queue and the status for different requests:

• The NE Request Queue Manager, in which the user can view entries in the queue. Request parameters can be displayed for each entry.

• The NE Request Queue Notifier which spontaneously displays any change in the queue that the user has ordered.

2.10 SCE / SMS Locators These SCE / SMS functions provide the tools for locating different objects defined in SCE / SMS. The Locators can be activated from the base window of different applications to locate applicable objects. Note though that the Locators can not be activated from any of the applications in the SCE application unit Service Creation. SCE / SMS Locators are divided into three functions: 5.

Service/Subscription Locator

The Service/Subscription Locator provides a graphic interface for locating service/subscription elements defined in SCE / SMS. The following elements can be located with the Service/Subscription Locator:

27

IN 2.3 Service Testing Course

• • • • • 6.

SCPs Services Subscribers Subscriptions, that is, Telephone Numbers SSLs

Global Data Module Locator

The Global Data Module Locator provides a graphic interface for locating Global Data Module (GDM) elements defined in SCE / SMS. The following elements can be located with the Global Data Module Locator:

• SCPs • Control Types • Global Data Modules 7.

SDP Locator

The SDP Locator provides a graphic interface for locating SDP elements defined in SCE / SMS. The following elements can be located with the SDP Locator:

• SDPs • SDP Applications

28

SMAS, Red Line Trace

2.11 Service Creation Service Creation is the activity of creating the logic of a service and then to add service data to the logic. The logic is network dependent, that is, the logic is designed to work with specific network element types and the desired network element type is chosen by selecting a Control Type Collection (CTC) when the logic is designed. The logic of a new service is formed by one or more Service Script Logics (SSLs). An SSL is constructed by linking Logic Modules (LMs) together and specifying attributes etc. The combination of SSLs then makes up the Service Logic (SL).

Figure 2.5

LMs combined to form an SSL.

When the design process has been completed, SCE automatically checks the SL for logical inconsistencies. Completed SSLs and SLs are stored in the service logic library and can easily be recalled, and modified to meet new requirements from other customers. Service data can be entered to the Service Logic by the service operator or the subscriber (Customer Control). Service data consists of local data, customer data, global data, or a combination of these. Local data and customer data are connected directly with the Service Logic. Global data must be defined before it can be connected with the logic. That is why it has its own SCE / SMS application. Service Creation also includes a possibility to transfer SSLs, SLs, services, and global data modules between different SCE / SMS systems. Service Creation is divided into five applications: 1.

Service Script Logic Definition

The Service Script Logic Definition application is used to design the SSLs. To be able to create SSLs, the operator must be registered as a Service Logic Designer. When an SSL is to be created, the user must start with selecting a Control Type Collection (CTC) or just use the default one. A CTC is a collection 29

IN 2.3 Service Testing Course

of Control Types specific to a type of network element, a particular network protocol, or any other grouping. The design of an SSL is accomplished by creating a logic module graph, that is, choosing control types, defining their parameters, such as mode, input register and number of outlets and then connecting them with one another. An LM is defined by selecting a control type from a palette positioning it in the working area and setting a number of parameters.

Figure 2.6

The control types palette.

The SSLs are stored in the service logic library as private to the designer. Once the design is complete, the designer can change the status of the SSL to public, which means that the SSL is available to other designers for further use in Service Logic design. Service Script Logic Definition also includes functions for editing and viewing existing SSLs.

2.

Service Logic Administration

The Service Logic Administration application is used to design SLs. An SL is created by selecting a set of public SSLs from the service logic library. The designer must mark the SSLs as being group SSLs or subscriber-specific SSLs. A group SSL must also be marked as an ordinary SSL or a Customer Control (CC) SSL. One SSL must also be marked as the first one on each level. During the creation of an SL, the SL is private to the designer. The designer can then change the SL to public, which means that it is available for use in a service.

30

SMAS, Red Line Trace

Service Logic Administration also includes functions for editing and viewing existing SLs. Service Logic Administration

Service Logic Library

Freephonescript 1 Sep 26 1992 1:23:18PM First Group Validationscript_2 Sep 30 1992 2:23:12PM Group

Figure 2.7

Create an SL by choosing public SSLs from the service logic library.

3.

Global Data Administration

Global Data Administration is an application used to define Global Data Modules (GDMs). GDMs are data modules which are associated with a particular control type, and which all service designers can connect with LMs derived from that control type. A GDM is specified by defining a GDM name, selecting a control type, a CTC, and specifying number of outlets. If specifying a CCPROC GDM, the control type to be customer controlled must also be entered. Then the data values are added, and the GDM is stored in the service library in SCE. Global Data Administration also offers the possibilities to modify a GDM, copy a GDM, rename a GDM, or delete a GDM. To be able to install/remove GDMs in/from an SCP, or to work with “Only Installed” GDMs the Global Data Administration application within the Service Deployment application unit must be used.

4.

Service Definition

A service is defined in SCE by selecting a public SL from the service logic library and adding data to all the SSLs in that SL. The data can be either local to the service, local to the subscriber (customer data), or global. When developing a group of services, it is possible to share customer data between them (that is, shared SC). It is also possible to connect a DM in an SSL to Customer Control (CC), which means a subscriber is permitted to change part of his own data via a DTMF telephone. When data has been added, the service is stored in the service library. Service Definition also offers the possibilities to copy a service, to validate a service, to share data between two services, or to delete a service. The copy function is important when creating new service versions to already existing subscriptions. 31

IN 2.3 Service Testing Course

5.

Service Transfer

The Service Transfer application is the tool for transferring services (service logic and service data) to and from an SCE / SMS system by means of the UNIX file system. It is also possible to copy the UNIX file to tape. UNIX SCE / SMS Platform Tape Service Logic Library

Disk Files

Figure 2.8

Service Logic Transfer.

This application is used for transferring services designed at one service management centre to another service management centre. The application makes it possible for the service provider to centralize all service creation.

32

SMAS, Red Line Trace

2.12 Service Deployment Service Deployment provides the tools for administering services and global data in the SCPs, including to create and install new versions of services. There is an application for defining a new SCP as a mate to an already existing SCP within an SMS system. Service Deployment also includes a possibility to transfer services and global data modules between different SCE / SMS systems, and a tool for sending test queries, that is, to simulate the SSF-SCF interface. Service Deployment is divided into six applications: 1.

Global Data Administration

Global Data Administration is an application used to define Global Data Modules (GDMs). GDMs are data modules which are associated with a particular control type, and which all service designers can connect with LMs derived from that control type. A GDM is specified by defining a GDM name, selecting a control type, a CTC, and specifying number of outlets. If specifying a CCPROC GDM, the control type to be customer controlled must also be entered. Then the data values are added, and the GDM is stored in the service library in SCE. A GDM is installed by selecting a GDM from the service library and an SCP. The GDM can be installed in the SCP immediately or scheduled for future installation by specifying a time. The NE Request Queue facility is used in both cases, which means that the installation will take place as a background process. Global Data Administration also offers the possibilities to remove a GDM from an SCP, modify a GDM, copy a GDM, rename a GDM, or delete a GDM.

2.

Service Deployment

Service Deployment is used to install services. When installing a service into an SCP, a service must be selected from the service library and an SCP must be specified. The service can be installed immediately or scheduled for a future installation by specifying a time. The NE Request Queue facility is used in both cases, which means that the installation will take place as a background process. Service Deployment contains facilities to activate a service, deactivate a service or remove a service from an SCP. Service Deployment offers the possibility to set up new service versions to already existing subscriptions, to switch service versions for subscriptions or to remove service versions not longer wanted. This is done without losing any subscriber-specific data already created and installed.

33

IN 2.3 Service Testing Course

Service Deployment also includes a function to migrate services built on the Control Type Collections IN2.0 and IN2.1 to services using the Control Type Collections in an IN2.2 SCP, either IN2.1+, CS1, or CS1+.

3.

Installed Service Modification

This application enables the user to change data for a service directly in the SCP. The application makes visible data structures in the SCP which are hidden by other applications, such as Service Administrator (SA), Service Customer (SC), and OP/NOP areas. With this application it is possible to, for example, modify data in an installed service/subscription, activate and de-activate a service, or reinstall a service. This application also makes it possible to install or remove an SSL, independent of a service or a subscription. The installation of the access, error, and update scripts is done in this way.

4.

Query Simulation

Query Simulation is a tool for sending test queries, that is, to simulate the SSF-SCF interface. It allows a user to simulate the query, conversation response, and termination notification sent by an SSF. The query simulation is used either when a new service has been created, in order to test its function or for troubleshooting an already existing service or subscription. For the Control Type Collections CS1, CS1+, CS1G, and CS1-CH, Query Simulation offers a possibility to trace the call. The trace function indicates which logic modules are accessed as the call passes through the service logic.

5.

Service Transfer

The Service Transfer application is the tool for transfer services (service logic and service data) to and from an SCE / SMS system by means of the UNIX file system. It is also possible to copy the UNIX file to tape.

UNIX SCE / SMS Platform Tape Service Logic Library

Figure 2.9

34

Disk Files

SMAS, Red Line Trace

Service Logic Transfer.

This application is used for transferring services designed at one service management centre to another service management centre. The application makes it possible for the service provider to centralize all service creation.

6.

Mated Pair Introduction

Mated Pair Introduction (SMAAM) is a function for defining a new SCP as a mate to an already existing SCP within an SCE / SMS system. The function copies all installed data from the existing SCP to the mate and then installs the data into the mated SCP. It is implemented as a combination of manual actions and a computer application and has no graphical user interface.

35

IN 2.3 Service Testing Course

2.13 Service Provisioning SUBSCRIBER

SERVICE

SUBSCRIPTION

SCP

Figure 2.10

Defining a subscription

Service Provisioning is the activity of defining subscribers and administering subscriptions. The Service Provisioning is divided into four applications: 1.

Subscriber Administration

Subscriber Administration is an application whereby the user can define new subscribers, delete old subscribers, and modify data for existing subscribers. Some services allow the subscriber to modify the subscriber specific data. This could be done either by Subscriber Control via SCP (Customer Control) or by Subscriber Control via SMS. Subscriber Control via SMS means that the subscriber has access directly to SMS, via a workstation or a terminal, where the subscriber is able to change the subscriber specific data. Subscriber Control via SCP means that the subscriber is able to change the subscriber specific data, belonging to the subscriber, via a DTMF telephone.

2.

Subscription Administration

Subscription Administration is an application for defining subscriptions, that is, a subscriber and an installed service are selected and subscriberspecific data is defined. Each subscription is identified with a unique telephone number/SCP. For those subscribers who are allowed to modify part of their own data via a telephone (Subscriber Control via SCP), a CC telephone number must also be defined.

36

SMAS, Red Line Trace

The Subscription Administration application also contains the possibility to install Subscriptions or Customer Control, or both into an SCP; or remove Subscriptions or Customer Control, or both from an SCP; immediately or at a future time. Before installing a Subscriptions or Customer Control, or both, subscriber-specific data should be defined.

3.

AdmGroup Administration

The Application is used to define security permissions for any application that uses AdmGroups. Each application has its own forms for administering the permissions depending on the data being managed. The SMS admgroups are assigned according to a hierarchy of permissions. The ‘smasadm’ user has root access to the system and can view and manipulate all subscriptions, subscribers, admgroups, and other objects.

4.

SDP Data Administration

The Service Data Point is a database storage and retrieval system which increases the overall capacity of an Intelligent Network, by allowing data to be shared among different SCPs and SSPs. It provides high speed access to subscriber profile data to other nodes in the Intelligent Network and can also act as a gateway to other systems. The SDP Data Administration application provides a graphical interface for viewing and manipulating SDP data. There is a possibility to insert new data rows or to modify, view, or delete already inserted data rows in a transaction which is then submitted to an SDP. 5.

HLR Administration

The functions in HLR Administration provide interfaces for the following

• Defining and deleting subscribers of HLR subscriptions • Defining and deleting HLR subscriptions, and connecting them to an HLR

• Manipulating data field permissions and control flags.

37

IN 2.3 Service Testing Course

2.14 Service Monitoring Service Monitoring provides applications for managing and monitoring installed services and subscriptions. It also includes applications for collecting information from the SCPs, such as statistics and call report information. Service Monitoring is divided into four applications: 1.

Statistics

The measurement of statistics is performed by the SSI-function in the SCP and the Statistics application in SMS provides a user interface where it is possible to specify what to measure, when to start and stop the collection, and present the result. Statistics are collected on time interval or number of attempts. To be able to collect statistics and present statistics reports the service must include certain DMs or logic. 2.

Running Counters

The Running Counters application allows the user to view or reset a running counter in an SCP. A running counter is a counter specific to some of the control types that are updated in real-time in the SCP as the SCP processes its queries. The values of these counters are not continuously sent to the SMS system, and so the database is not always fully updated with this information. Therefore, this application provides the possibility to directly access the SCP to request the current value of these counters or reset them to zero. 3.

Call Reports

A call report is a focused study on the signalling between the SCF and the SSF during an IN call. The SSI-function in the SCP monitors the calls and the Call Reports application in SMS provides a user interface where it is possible to specify what information to monitor, when, and present the result. Call data items to be monitored are call query, call response and call termination information.To be able to collect call data items and send call reports, the service must contain certain DMs or logic. 4.

Exception Reports

An Exception Report is a call report which includes a binary error code. The error codes are set by the services or by the SSI itself under certain conditions. An exception report is sent to SMS in the same way as call reports, but may be routed to a specific output device, for example a printer or the system administrator’s mailbox. The error code can, with help of the Data Translation Editor, be translated into a text string before being sent to the output device.

38

SMAS, Red Line Trace

2.15 Service Troubleshooting Service Troubleshooting provides applications for auditing and troubleshooting installed services and subscriptions. Service Troubleshooting is divided into four applications: 1.

Audit

The function of audit is to compare data in a Network Element with the corresponding data in the SCE / SMS database or between mated NEs. Audit should be used any time that data in the SCE / SMS database is suspected to differ from that in the NE, or when data in mated NEs differ. Audit should also be used as a part of normal NE maintenance. An audit process is executed as a background process. If an audit has been specified with restricted execution time, it may be started and stopped several times. This is used to execute large, time-consuming audits, to avoid using overwhelming computing resources. Each execution of an audit will produce a discrepancy report. A discrepancy report showing missing data in the NE can be handled by means of the re-install function in the Installed Service Modification application. 2.

Blocking/Deblocking

Blocking/Deblocking is a tool to manually block/deblock a service or subscription. Blocking a service or a subscription means to temporarily taking it out of traffic. When a service is blocked, all subscriptions to that service are automatically blocked. 3.

Manual Setting

Manual Setting is a tool to manually determine the LM outlet that should be chosen, regardless of the dictates of any attached data module. It is used in combination with Query Simulation to test new services during service creation. The Manual Setting application is not intended for use in traffic. 4.

Query Simulation

This application is also included in the Service Deployment sales object.

39

IN 2.3 Service Testing Course

2.16 Network Traffic Management The Network Traffic Management (NTM) application is used to protect the SCP against service traffic overload through congestion control. Congestion control can be used to limit call intensity for a specific number or range of numbers, for example all 800 numbers. Congestion control is mainly defined by: Duration of Control The length of time during which calls are monitored Allowed Number of Calls The maximum number of calls allowed per gap interval Gap Interval The time period during which calls are counted The first call arriving during the duration of control starts the gap interval. Once the maximum number of calls (Allowed number of Calls) has occurred within the specific time frame, or gap interval, all subsequent calls are rejected for the remainder of that gap interval. The first call arriving after the previous gap interval expires begins a new gap interval. This process of counting calls per gap interval continues until the duration of control expires (see the figure below).

calls Allowed no of calls

Rejected calls Gap Interval Duration of Control

Figure 2.11

Congestion Control

40

time

SMAS, Red Line Trace

2.17 Control Type Collection A Control Type is a function in the Service Script Interpreter (SSI). The SSI contains a number of different Control Types which can be used to define Logic Modules (LMs). The LMs can then be combined to realize the logic function of a service. A combination of LMs form a Service Script Logic (SSL) and one or more SSLs form a Service Logic (SL). Most of the Control Type functions involve processing of data, for example, number analysis. For these Control Types, Data Modules (DM) with service data are connected to the LMs in the SSL when a service is defined. The Control Types are gathered into Collections. There are eight different Control Type Collection depending on what kind of AXE or Unix SCP software the Control Types will support and what kind of services are demanded:

• • • • • • • •

Control Type Collection IN 2.0 Control Type Collection IN 2.1 Control Type Collection US Market Control Type Collection IN 2.1+ Control Type Collection CS1 Control Type Collection CS1+ Control Type Collection CS1-CH Control Type Collection CS1G

Control Type Collection IN 2.0 The Control Type Collection IN 2.0 contains Control Types that makes it possible to work with the SSI.2.0. in AXE.

Control Type Collection IN 2.1 The Control Type Collection IN 2.1 contains Control Types that makes it possible to work with the SSI.2.1. in AXE. The following new functionality have been introduced in the Control Type Collection IN2.1 compared with Control Type Collection IN2.0.

• Enhancement to congestion control • Support for ISDN services • Support for Virtual Private Network Control Type Collection US Market The Control Type Collection US Market functions have been developed to meet customer demands in the North American market for the Advanced Intelligent Network (AIN) products. The following new functionality have been introduced in the Control Type Collection US Market compared with Control Type Collection IN 2.0. 41

IN 2.3 Service Testing Course

• Support for multiple protocols • Support for communication with other network entities • Support for virtual directory numbers The CTC US Market also contains Query Simulation enhancements to support multiple protocols and service script logic tracing.

Control Type Collection IN 2.1+ The Control Type Collection IN 2.1+ contains Control Types that makes it possible to work with the SSI.2.2. in AXE. The purpose of this Control Type Collection is to support IN2.1 functionality in the SSI.2.2. The following new functionality have been introduced in the Control Type Collection IN2.1+ compared with Control Type Collection IN2.1:

• New CC • New queue functionality Control Type Collection CS1 The Control Type Collection CS1 contains Control Types that makes it possible to work with the SSI.2.2. in AXE. The Control Type Collection CS1 supports development of ETSI CS-1 services.

Control Type Collection CS1+ The Control Type Collection CS1+ contains Control Types that makes it possible to work with the SSI.2.2. in AXE. The following new functionality have been introduced in the Control Type Collection CS1+ compared with Control Type Collection CS1:

• Leg manipulation Control Type Collection CS1-CH The Control Type Collection CS1-CH contains Control Types that makes it possible to work with the SSI.2.2. in AXE.

Control Type Collection CS1G The Control Type Collection CS1G contains Control Types to support IN2.2 CS1 functionality in Unix SCP-G.

42

SMAS, Red Line Trace

2.18 Database Customer Programming Interface The Database Customer Programming Interface sales object provides an API for accessing the SMS database. It can be used by a service provider to develop new customized user interfaces for the Service Provisioning functions in SMS. The sales object is intended for programmers with experience and knowledge of how to develop application programs and APT-based user interfaces. The sales object consists of:

• an SQL interface • user documentation describing the programming interfaces and how to use the mouse.

43

IN 2.3 Service Testing Course

2.19 C++ Customer Programming Interface The C++ Customer Programming Interface sales object provides an API for accessing the SCE / SMS database via C++. It can be used by a service provider to develop new customized user interfaces for the Service Provisioning functions in SMS. The sales object is intended for programmers with experience and knowledge of how to develop application programs and OpenWindows-based user interfaces. The sales object consists of:

• two C++ class libraries • user documentation describing the programming interfaces and how to use the mouse. Note: The TMOS Development Platform (TDP) and a number of third party software are required for using this interface.

2.19.1

Generic Service Adapter (GSA) Worth mention here is also the Generic Service Adapter (GSA) which is a product closely associated to SCE / SMS but not included in the standard SCE / SMS product. The GSA supports a Service Provider with tools to design user interfaces for service provisioning. The tool can be used for developing both command line oriented applications, form based applications and remotely based applications accessing the SCE / SMS system through a communication interface (RPC). Note though that the GSA only supports IN services created by SCE. The GSA is intended for service designers with appropriate experience and knowledge about the GSA and its associated 4GL tool. The TMOS Development Platform (TDP) is NOT required for using this interface. By means of the 4GL tool, and SYBASE APT Workbench, the user interface can be designed. The GSA includes three main parts:

• A user interface template used as a development base when designing new user interfaces

• A setup template which is an ordinary textfile which can be changed by any editor, for example, textedit

• An executable which is used in runtime and provides all functionality for Service Provisioning

44

SMAS, Red Line Trace

2.20 Design Rules Some rules to think of when designing services in SCE:

• During Service Creation it is possible for the service designer to choose to use only group scripts, only subscriber-specific scripts, or combinations of both group and subscriber-specific scripts in the SL. However, it is recommended that only group scripts are used. Subscriber-specific data should be defined by connecting Customer Data Modules (CDM) to the LMs. Subscriber-specific scripts should be used only if there is a need for subscriber-specific data on LMs that cannot take customer data, or when subscriber-specific global data is needed.

• When Customer Control is used in SCE / SMS, the service is implemented as two scripts, one changeable (the “real” script) and one associated script that performs the change in the changeable script. The best way to enable/disable Customer Control for each subscription in the Subscription Administration application is to create a group SSL marked CC in Service Creation. This SSL should contain CCTRAF LMs for defining how the service change should be performed.

• If a subscription is created without customer data and customer data is later added via the Installed Service Modification application the SC will not automatically be updated in the NRANAX global data module. This must be done manually for all subscriptions.

• The Blocking/Deblocking application requires the use of a NRANAX logic module with global data for the number analysis.

• Use only global data modules for number analysis control types such as NRANA and NRANAX when SMS will enter the number in the DM. Subscriptions cannot be installed in a local NRANAX from SCE. If the service contains customer data, a global NRANAX logic module must be chosen.

• Outlet 2 (the third outlet) on number analysis data modules such as NRANAX is used by SCE as an outlet for blocked subscriptions. It should not be used as the first match outlet.

• Do not use customer data in the access script. • To be able to create exception reports, the error script must contain a REPORT or SREPORT data module.

• When developing groups of services with shared SC, it is recommended that the data model, that is, what data modules that are required, is considered first, and thereafter the service logic is defined,

45

IN 2.3 Service Testing Course

in order to obtain a sound data storage structure. When using the INM protocol, it is recommended to use output 9 for customer control, and output 10 for traffic measurements.

46

SMAS, Red Line Trace

2.21 Red-line Trace 2.21.1

Red-line Trace Overview The Red-line Trace (RLT) application is a debugging tool for services designed in SMAS. It allows the user to test services locally, before the service is installed in an SCP. This is accomplished by simulating the SCP, the SSP, the SDP, and the INAP or the CS1 protocol. RLT can be used as a demonstration and training tool as well. The simulation is contained entirely within the SMAS system.

2.22 Execution of Red-line Trace RLT allows the user to specify an uninstalled service or an SCP, provide it with start values and simulate the interaction between the SSP, the SCP, and the SDP. The SSL is visible at all times of the simulation with a red line showing the execution path step by step. RLT provides a ‘resource’ window for voice prompting and digit collection. It is possible to play audio recordings for the announcements. The simulation can be provided step by step or in a continuous mode and at variable speeds. The layout of the simulation output windows can be set before and during simulation.

47

IN 2.3 Service Testing Course

2.22.1

Workflow There are two different types of workflows in RLT. The one displayed on the left describes the flow using 2.1, 2.1+, CS1, and CS1+ mode. The one displayed on the right describes the flow using CS1 /w Call Model mode. Start the Red-line Trace Application

Start the Red-line Trace Application

Select Installed/ Uninstalled mode

Select Detection Point

If Installed: Select an SCP

If Uninstalled: Select a Service

Select a Run command

Select Installed/ Uninstalled mode

If Installed: Select an SCP

If Uninstalled: Select a Service

If necessary, specify parameters

If necessary, specify parameters

Use Step, Next or Continue to move through the logic

Select a Run operation

Respond to announcement and digit collection

Use Step, Next or Continue to move through the logic

Send required leg events

Respond to announcement and digit collection

Repeat until the logic is tested

Send required leg events

Exit the User Interface

Repeat until the logic is tested

Exit the User Interface Figure 2.12

2.1, 2.1+, CS1, CS1+ and CS1/w Call Model mode.

48

SMAS, Red Line Trace

2.23 Tools for Debugging Red-line Trace provides several tools to help debug and report problems on a service. Breakpoints RLT provides three kinds of breakpoints: logic module, tag and operation. A logic module breakpoint will cause the service to stop executing when the breakpoint is reached. A tag breakpoint will cause the service to stop executing when the tag changes. An operation breakpoint will cause the service to stop executing when a particular operation is ready to be processed. Logic Module Trace As each logic module is executed, it is highlighted and the outlet taken is shown with a red line. In addition to this graphical display, a log of each module and outlet can be output to the dialogue window. Anything in the dialogue window can be saved to a file or included in a trouble report. Information like error messages and changed tags can also be placed in the dialogue window. INAP Dialogue The INAP messages passed between the SCP, SSP, and SDP are output to the dialogue window. Forced Outlets Service logic execution does not have to follow the logic of the service. If you wish to test a certain path in a service, or if a bug in the service needs a temporary work around, any outlet can be forced by clicking the left mouse button on the chosen path corresponding to that outlet. The connection turns blue to indicate that RLT always will take this path. Goto Here If you wish to skip over parts of an SSL, you may select ‘Goto Here’ on the logic module where execution should continue. Goto Here can even be used after an error has occurred, preventing the ERROR script from being invoked. Time Adjustment Services that use the date and/or time can be thoroughly tested by changing the simulation clock to any value. If your service does something special on New Years Day, there is no need to wait until January 1 to test the service. Simply change the system clock. SCP Monitor List At any one moment, the SCP can be waiting for several things to happen. It is sometimes difficult to know exactly what the SCP expects. For this 49

IN 2.3 Service Testing Course

reason, RLT allows you to view the SCP’s monitor list, revealing which events are expected, on what leg and with what InvokeID. Call Instance Data Manipulation The call instance data, also known as tags, can be viewed and changed at any point during service execution. This can be useful for certain test cases or in situations where a temporary work around is needed in a service. Multiple Connection Views Services that have features like network protection, uniform load distribution, or call queuing cannot be tested with only one call at a time. As many as 10 simultaneous calls may be simulated using RLT by opening additional connection views. Temporary IR/OR Register Changes The IR or OR values can be changed during a simulation. This allows the user to try new IR/OR settings before going through the steps required by SMAS for permanent solutions.

50

SMAS, Red Line Trace

2.24 Red-line Trace ETSI CS1 and CS1+ This section describes the RLT base window, the menus and the pop-up windows for handling and executing RLT using the ETSI CS1 and ETSI CS1+ domain.

2.25 Red-line Trace Base Window A major feature of the base window is the service script logic display where active logic modules are highlighted, and the logic flow is indicated by a red line. The base window with an example service is shown below:

Figure 2.13

Red-line Trace Base Window

The control area includes the following buttons: File

This displays a menu with choices of loading and locating services. It also provides an option to start a new connection view and selecting the protocol used for the simulation.

View

This displays a menu with choices for viewing information about the active RLT process.

51

IN 2.3 Service Testing Course

Edit

This displays options to edit the simulation clock. It also contains the Properties window options for simulation settings.

Run

This displays options available for starting the simulation.

Step

This steps the simulation to the next logic module.

Next

This executes the simulation until the next SSL.

Continue

This steps the simulation ahead until input is required.

Stop

This stops a continuous simulation.

Send

This sends operations to the SCF.

Error

This sends error case operations to the SCF.

Assist

This sends one operation or error case to the SCF over an assisting dialogue.

Reset

This resets the call instance.

The Mode setting area shows if the chosen service is installed or uninstalled. The text field depends on the Installed/Uninstalled setting: Service

This is the name of the active service and it is only visible in Uninstalled mode. To change service, use the Service Loader in the File menu.

SCP

This shows the name of the active SCP and it is only visible in Installed mode. To change active SCP, type the SCP name, or use the Service/ Subscription Locator in the File menu.

The RLT base window includes the following info areas display in ETSI CS1+ mode only: Assisting

Displays the legs in the call which are involved in assisting dialogues. The active options under Assist menu button reflect the state of the selected leg.

The RLT base window includes the following permanent text fields:

52

Date/Time

This shows the current SCF date and time. This is the value used by any date or time sensitive logic in the SCF. The Clock option from the Edit menu allows you to change the current date and time.

SA

This is the name of the active SA.

SSL

This is the name of the active SSL.

SC

This is the active Service Customer name.

SMAS, Red Line Trace

2.25.1

Next SA

This is the name of the next Service Administrator.

SCF state

This shows the states of the Service Control Function. The possible states are Idle, Waiting, Active, Event, Error, and Suspended.

SSL Display Area The SSL Display Area menu is brought forward by clicking the right mouse-button on the logic modules in the Display Area. The SSL Display Area menu is shown below:

Figure 2.14

SSL Display Area menu

The menu includes the following choices: View/Modify DM

This displays the SMAS Data Management form where the data module may be viewed or modified. Modification is only available when the user has update permission. This option can also be invoked by doubleclicking on the logic module.

Set Breakpoint

This sets a breakpoint at the selected logic module. A breakpoint will cause continuous service execution to stop when the breakpoint is reached.

Clear Breakpoint

This clears a breakpoint at the selected logic module.

Deblock DM

This deblocks a blocked logic module. This option is available when a module becomes blocked. Currently only NRANAX, LOOP and SCREEN can become blocked.

Goto Here

This moves the RLT simulation to a selected logic module.

Attributes

This opens the LM Attributes window displaying the logic modules attributes.

Dynamic Data

This opens a submenu which displays the dynamic data values of the indicated data module and an option to reset them. Statistic counters are examples of dynamic data.

53

IN 2.3 Service Testing Course

To force the RLT simulation to proceed on a chosen path, select the logic module connection with the left mouse button. The connection line will change colour to blue. Use the left mouse button to unselect or select another connection.

2.25.2

LM Attributes Window The LM Attributes window is shown below:

Figure 2.15

LM Attributes window

The LM Attributes window includes the following text-fields and checkbox:

54

Control Type

The name of the indicated control type.

Logic Module

The name of the indicated logic module.

Mode

The mode of the indicated logic module. An LM can be in either Branch or Register Mode.

Number of outlets

The number of outlets of the indicated logic module. This is generally a value from 0 to 255. This value does not apply to control types that jump to another SA or end the service logic execution.

Register Number

The register number used by the indicated logic module. This value only has meaning when the LM mode is ’Register’.

Locked

A check mark in this box indicates that the IR and OR values are locked and are not being changed. The IR and OR values of the LM may be changed by clicking the check mark (unlock), making the changes, and then applying the changes by clicking the check box again. Changes made this way are not saved to SMAS, but will exist only for the duration of this RLT process. The changed LM will be highlighted to indicate that temporary changes have been made.

SMAS, Red Line Trace

Revert

This button appears when the LM attribute panel has been unlocked. It may be used to restore an LM to its original IR and OR values.

55

IN 2.3 Service Testing Course

IR and OR

When the LM window is "unlocked" the IR and OR register values can be modified. Any value from 0 to 65535 may be entered.

Highlighted LM The highlighting syntaxes are setup as follows:

56

blue

Indicates that the LM is selected.

yellow

Indicates that the OR or IR values of the LM have been changed.

green

Indicates that the OR or IR values of the LM have been changed and that the LM is selected.

SMAS, Red Line Trace

2.26 File Menu The File menu includes choices for loading and locating new services. It contains the following items: Services

Opens the Service Loader window where you can select from services in the SMAS system. This is used in the Uninstalled mode. Locate Opens the Service/Subscription Locator. The Locator helps you to find SCPs, Services, Subscribers, and Subscriptions. This is used in the Installed mode.

New Call View

Opens a new base window connection view containing the same service.

E-INAP 2.1+

Changes the current domain to E-INAP 2.1+.

E-INAP 2.1

Changes the current domain to E-INAP 2.1.

ETSI CS1

Changes the current domain to ETSI CS1.

ETSI CS1 w/ Call Model Changes the current domain to ETSI CS1 w/ Call Model. ETSI CS1+

2.26.1

Changes the current domain to ETSI CS1+.

Service Loader Window The Service Loader window contains a list of existing services. The window is shown below:

Figure 2.16

Service Loader Window

Select the desired service from the service list, then choose the starting SSL from the SSL list. Select Accept when finished.

57

IN 2.3 Service Testing Course

2.26.2

Service/Subscription Locator The Service/Subscription Locator is a tool to locate SCPs and services. The Service/Subscription Locator window is shown below:

Figure 2.17

Service/Subscriber Locator Window

The locator may be used to select an on-line SCP. It may also be used to select a starting SA by choosing a service and an SSL name. An SC may be selected by specifying the associated telephone number. If an SA is not selected the processing will begin with the ACCESS SA of the specified SCP.

58

SMAS, Red Line Trace

2.27 View Menu The View menu contains the following items:

2.27.1

Tags

Provides a window with current call instance data. The data may be manipulated from this window.

Dialogue

Shows the complete INAP dialogue between the SSF and the SCF and between the SCF and the SDF.

Monitor List

Shows the SCF’s monitor list.

Labels

This displays a menu with choices for labelling the logic modules in the service logic display.

NPROCES List

Shows a window where you may start a new SCF process from a queued list of processes provided by the NPROCES control type.

Tag Values Window The Tag Values window shows the call instance data. It is possible to see if the tags have changed from one step to the next. An asterisk appears next to the most recently changed tags. The Tag Values window is shown below:

Figure 2.18

Tag Values Window

The Tag Values window includes the following: Find

Includes options to search for a string forward and backwards.

59

IN 2.3 Service Testing Course

Save

This menu enables you to save the current tag values in one of five slots. The tag values can be reloaded later using the Load menu or the Autoload feature. An asterisk (*) next to the slot name on the menu indicates the slot is used. Saving into a used slot will overwrite its contents. A slot can be cleared by selecting save when there are no tags in the tag buffer.

Load

This menu enables you to load previously saved tags into the tag buffer from one of five slots. The slot name on the menu is enabled when it contains at least one tag.

Auto-load

Tags can be automatically loaded from a particular slot each time service execution begins. It is possible to select None (which disables Auto-load), or one of the slots created from the Save menu. When Auto-clear is activated, the tag buffer will be emptied before auto loading the tags. This ensures a known starting point each time service execution begins.

Tag

Displays the name of the selected Tag. This sets a tag breakpoint. A tag breakpoint will cause continuous service execution to stop when the tag with a breakpoint is changed. This clears a tag breakpoint.

Auto-clear

When Auto-clear is checked (default), all tag values are cleared each time the simulation is run. If this option is not checked, the tag values will remain when the simulation is restarted. This is useful when it is desired to edit tag values before running the service.

Value

Displays the value of the Tag.

Set

This sets the value of a selected tag.

Delete

This deletes a tag, which has been selected.

Delete All

This deletes all tags.

The Tag Values window pane contains a list of current tags. The list includes four columns:

60

KoX

This displays the Kind-of-Number, Kind-of -Variable, Kind-of-LongInteger, Kindof-String of the Tag.

Tag Name

This displays the mnemonic name of the Tag.

Buf

This displays which kind of Buffer is used. There are four different Buffers: R-Response, Q-Query, T-Temporary and E-Event.

SMAS, Red Line Trace

Value

2.27.2

This displays the current value of the Tag.

SSF/SCF Dialogue Window The SSF/SCF Dialogue window is shown below:

Figure 2.19

SSF/SCF Dialogue Window

By default, the SSF/SCF Dialogue window shows the INAP messages passed to and from the SCF and SSF. An option on the properties window allows you to select other information which can also be shown in the dialogue window. Any combination of the following may be selected: Dialogue

INAP messages between SCF and SSF.

Changed Tags

A list of tags that have changed after the execution of a logic module.

Logic Module

The SA name, the SA side (OP or NOP), the SSL name and version, the outlet used, and the logic module name are listed as each logic module is executed.

Error Text

Messages from the SCF which are normally only displayed in the window footer are also placed in the dialogue window.

In the left column in the SSF/SCF Dialogue window a character displays the type of the dialogue: I-Initial, A-Assisting, N-Non call, S-SDP/SCF dialogue. The contents of the dialogue window may be saved to a file or printed for future reference.

61

IN 2.3 Service Testing Course

2.27.3

SCF Monitor List Window The SCF Monitor List window is shown below:

Figure 2.20

SCF Monitor List window

The SCF Monitor List includes the following columns:

62

Prio

This displays the priority of the monitor request. When several requests for the same event have been made, the priority will decide in which the order that the event is distributed to each requester. Requests with a priority of 0 will get the event first, requests with a priority of 15 will get the event last.

LM Name

This displays the name of the Logic Module that requested the event.

SA Name

This displays the name of the Service Administrator that contains the requesting Logic Module.

SC Name

This displays the name of the Service Customer that was in use when the monitor request was posted.

INVK

The invoke id that the monitor request is associated with.

LEG

The Leg shows which leg is being monitored.

EVNT

This displays the type of event. Possible events are: BCSM Error EventNotificationCharging ApplyChargingReport CallInformationReport ReturnResultPromptCollect SpecializedResourceReport Internal ErrorLevel2

SMAS, Red Line Trace

BCSM

When the event is BCSM, this column shows the mask for the monitored BCSM events. Use the right mousebutton to display the mask values. The events possible are: Alerting (CS1+) Answer No Answer Disconnect Re-answer (CS1+) Midcall Abandon Suspended (CS1+) Route Select Failure Called Party Busy Called Party Not Reachable (CS1+) Collect Information Analyzed Information

Mode

This displays the mode of the event. There are three different modes: Notify & Continue, Interrupted, and Transparent.

63

IN 2.3 Service Testing Course

2.27.4

Labels Menu The Labels menu is shown below:

Figure 2.21

Label Menu

With the Label menu it is possible to decide how to label logic modules in the SSL display area.

64

LM names

This option will present all logic modules with their Logic Module name.

DM ids

This option will present the Data Module ID of the logic modules that have data.

None

This option removes all logic module labels.

SMAS, Red Line Trace

2.28 Edit Menu The Edit menu contains the following items:

2.28.1

Clock

This displays the Set Clock window which makes it possible to change the simulation time.

Properties

This displays a window where properties of the simulation may be set. Properties such as simulation speed, announcement settings and output design may be specified.

Set Clock Window The Set Clock window is shown below:

Figure 2.22

Set Clock window

It allows the user to manipulate the clock in order to test different dates and times in the logic. Apply is used to accept the new time. Reset will cause the simulation to revert to the current date and time.

2.28.2

Properties Window The Properties window is shown below:

65

IN 2.3 Service Testing Course Figure 2.23

Properties Window

The window includes the following permanent textfields: Execution Speed

This slider sets the speed of the simulation when running in continuous mode.

NRANAx Search Method Indexed or Scanned, CCTRAF Directive

The CCTRAF control type is used to update data modules in a service. There are two options, Pretend to Change DB and Really change DB.

Dialogue Window

There are five different settings for the Dialogue Window. Dialogue, Changed Tags, Logic Modules, Error Text and Announcement Text.

Maximum Jumps

This makes it possible for the user to change the value RLT uses for maximum number of jumps to reflect the actual limit set by the SCF.

Maximum Gosub Depth This changes the value used for maximum gosub depth. Play Announcement This is not used in ETSI CS1/CS1+ mode. Announcement Path This is not used in ETSI CS1/CS1+ mode. Parts Path

This is not used in ETSI CS1/CS1+ mode.

Effects Path

This is not used in ETSI CS1/CS1+ mode.

Announcement Text File This is not used in ETSI CS1 mode. SSRDWR Configuration File This is not used in ETSI CS1 mode. Show SDF Window

Always - Shows the SDF window every time an Update or Retrieve operation is sent. As Needed - Shows the SDF window when an Update or Retrieve operation is sent and an operation break point has been set, or when an SDP has not been identified.

Number Analysis Search Method The control type NRANAX may search the SMAS database by either scanning the table, or by using the table’s index. Each method has different characteristics. Indexed Search Method The indexed search method is faster than the scanned method when searching large number analysis tables. The best performance, using this

66

SMAS, Red Line Trace

method, will be found when a number analysis table has about 5000 rows or more. This method has one major disadvantage: Table entries with either * or # in the key will not be found using this method. The only way around this is to use the Scanned search method, or to always store ‘B’ for * and ‘C’ for #. Scanned Search Method This method works well with small number analysis tables (under 5000 rows). This method will also find * and # if they are in the table. CCTRAF Directive The CCTRAF control type is used to update data modules in a service. This provides the service functionality called customer control. This property allows the user to decide if CCTRAF should really change the data (as it would in the SCP), or if it should only pretend to change the data. Pretend to Change DB When this option is selected, the CCTRAF logic module will go through the entire procedure of locating the DM to change, locating the change procedure (CCPROC), sending announcements (if any), etc. It will not actually cause any data to be changed. This is the default mode for the CCTRAF Directive. Really Change DB In this mode, CCTRAF will go through all the normal steps, including a change to the database. If an uninstalled service is being tested, then only the SMAS database will be changed. If the service and service data is installed, then a request for a change will be placed on the SCP request queue. This option cannot be selected if the RLT user does not have ‘update’ privileges.

Dialogue Window By default, the Dialogue window shows the INAP messages passed to and from the SCF and SSF. This option on the properties window will allow you to select other information which can also be shown in the dialogue window. Any combination of the following may be selected: Dialogue INAP messages between SSF and SCF are shown. Changed Tags A list of tags that have changed after the execution of a logic module is shown. Both the tag name and its new value are included.

67

IN 2.3 Service Testing Course

Logic Module The SA name, the SA side (OP or NOP), the SSL name and version, the outlet used, and the logic module name are listed as each logic module is executed. Error Text Messages from the SCF which are normally only displayed in the call view window footer are also placed in the dialogue window. Annc Text The text shown on the Resource window is also added to the dialogue window. These five items allow you to log detailed information surrounding the execution of a service. The contents of the dialogue window may be saved to a file or printed for future reference. Maximum Jumps The maximum number of jumps from one SA to another is limited by the SCF. This limit is configurable at the time the SCF dump is built. Therefore, RLT allows you to change the value it uses for maximum number of jumps to reflect the actual limit set by your SCF. The default value for the jump limit is 8. This is the value typically used in most SCF builds. You should not adjust this value unless you are certain your target SCF has a different limit. Using an inaccurate value will mean that RLT will fail to simulate how your service will execute on the target SCF.

Maximum Gosub Depth The maximum gosub depth is the depth that a subroutine may be nested. Like the jump limit, this limit is configurable at the time the SCF dump is built. RLT allows you to change the value it uses for the maximum gosub depth. The default for the gosub depth limit is 3. This is the value typically used in most SCF builds. You should not adjust this values unless you are certain your target SCF has a different limit. Using an inaccurate value will mean that RLT will fail to simulate how your service will execute on the target SCF. Update Permission It can be said that RLT will never change the database, because it only reads data and never writes. This assures that a novice cannot accidentally damage a working service.

68

SMAS, Red Line Trace

However, with the implementation of CCTRAF, it is possible that RLT will write changes to data in SMAS. To assure only knowledgeable users attempt these operations, a permission file must exist which gives users update permission. Only users with update permission may modify data using RLT. The permission file is called .rltupdates. The permission file must exist in the subdirectory pointed to by the environment variable TMOSHOME. This is usually /opt/tmos. The file is a list of users who have ‘update permission’. The SMAS or TMOS administrator can create the file in the following way: cd $TMOSHOME vi .rltupdates List user ids of people with update permission, one per line: etxtidw etxgroh etc... If the file contains the word ‘all’ on a line by itself, then all users will have update permission. This file should have read permission by all SMAS users. Write permission for this file should be disabled except for the system administrator. This can be done with the following command: chmod 644 .rltupdates

69

IN 2.3 Service Testing Course

2.29 Run Menu The Run menu includes the following items: InitialDp

Start the service by sending the SCF an InitialDP operation. A subwindow opens where all parameters may be specified.

ServiceFilteringResponse Start the service by sending the SCF a ServiceFilteringResponse operation.A subwindow opens where all parameters may be specified. NPROCES List

Shows a window where you may start a new SCF process from a queued list of processes provided by the NPROCES control type.

Run

Start the service without sending any initial operation to the SCF.

InitialDp Window The InitialDp window is shown below:

Figure 2.24

InitialDP window

Shows a window where you may invoke an InitialDp operation toward the SCF. This operation initiates dialogue between the SSF and SCF. The InitalDp window displays the parameters that are possible with the activate operation. Mandatory parameters are indicated with an (m) to the right of the name.

70

SMAS, Red Line Trace

Parameters which represent a choice are indicated with the word CHOICE beside their name. Choice parameters may have only one of their subparameters sent. If you supply a value for more than one choice subparameter, only the last one is used. Integer values are assumed to be decimal unless preceded by H’ or 0x. Numbers with frames may be indicated by specifying the frame first, followed by the telephone number. The character & can be used to as a separator. The InitialDp subpanel and operation panel displays the following icons: Selecting this button will display all subparameters so that their values can be modified. Selecting this button will remove all subparameters from view after they have been displayed. Selecting this button will display the subparameters of the associated parameter so that their values may be modified. After the subparameters have been displayed and/or modified, they can be removed from view by selecting this button again. Selecting this button will expand the parameter so that you may view or set the subparameters. Select this button again to collapse the parameter. The InitialDp window contains the following input fields: serviceKey

Number information that can be used to address the correct application or SSL within the SCF.

calledPartyNumber

Information used as routing address at invocation of an IN-service. It is usually a number (IN-service access number) dialled by a calling party to request an IN-service.

callingPartyNumber Information used to identify the calling party. It is a number that can be applied as routing address, for example for call back services. callingPartyCategory Information sent in forward direction in a call indicating the category of the calling party, for example ordinary subscriber, data call, payphone. cgEncountered

This parameter indicates that the related call has passed call gaping, indicating one or more gapCriteria was passed.

ipsspCapabilities

This parameter is sent by the assisting or handoff SSP to indicate which SRF resources are supported within the SSP. This parameter is applicable to this operation only in the physical scenarios corresponding to assist with relay or

71

IN 2.3 Service Testing Course

hand-off. The use of this parameter is network operator dependant. locationNumber

Specifies the location number of a base station in the mobile network.

originalCalledPartyIdThis parameter carries the dialled digits if the call has met callforwarding on route to the SSP or is forwarded by the SCP. extensions

This parameter allows for network operator specific extensions.

highLayerCompatibility This parameter indicates the type of the high layer compatibility, which will be used to determine the ISDN-teleservice of a connected ISDN terminal. serviceInteractionIndicators This parameter contains indicators used for control of the network based services at the originating exchange and the destination exchange and for providing call control information to the SSP. additionalCallingPartyNum This is an additional calling party number, for example a private number. forwardCallIndicators This parameter indicates if the call shall be treated as a national or an international call. It also indicates the signalling capabilities of the succeeding network connection. The network access capabilities do not indicate the terminal type. For example, an ISPBX will have an ISDN type of access, but the end user terminal behind the ISPBX may be ISDN or non-ISDN. bearerCapability This parameter indicates the type of the bearer capability connection to the user. eventTypeBCSM

This parameter indicates the armed BCSM detection Point event, resulting in the InitialDP operation.

redirectingPartyId

This parameter indicates the directory number the call was redirected from.

redirectionInformation This parameter contains forwarding related information, such as redirecting counter. Additional CS1+ Parameters

triggerType

72

This parameter indicates how the IN service was triggered.

SMAS, Red Line Trace

legIDs

This parameter indicates the legIDs available at the time of the hand over.

routeOrigin

This parameter indicates the incoming route from which the call was received.

testIndication

This parameter indicates that this request is to be processed by the non-operating area of the SLP.

cUGCallIndicator

This parameter defines the outgoing access capabilities of a member of a Closed User Group or identifies a non-CUG call.

cUGInterLockCode This parameter indicates a code that uniquely identifies a Closed User Group within the network. genericDigitsSet

This parameter contains one or more genericDigits elements.

genericNumberSet

This parameter contains one or more genericNumber elements.

cause

This parameter indicates the cause indicator that was received at the TDP. Only applicable to TDPs routeSelectFailure, o-CalledPartyBusy, oCalledPartyNotReachable, o-Disconnect, tCalledPartyBusy, t-CalledPartyNotReachable, t-Disconnect, t-routeSelectFailure

handOverInfo

This parameter indicates information needed to move the control relationship to another SCF.

forwardGVNSIndicator This parameter identifies the originating service provider and information about the calling VPN subscriber in terms of a customerID or a GVNS UserGroup. The parameter will also carry routing information for the terminating GVNS network. Selecting Send will send the operation with it’s completed parameter information to the SCF. Clear resets the window.

73

IN 2.3 Service Testing Course

ServiceFilteringResponse Window The ServiceFilteringResponse window is shown below:

Figure 2.25

ServiceFilteringResponse Window

Shows a window where you may invoke a ServiceFilteringResponse operation toward the SCF. Mandatory parameters are indicated with an (m) to the right of the name. Parameters which represent a choice are indicated with the word CHOICE beside their name. Choice parameters may have only one of their subparameters sent. If you supply a value for more than one choice subparameter, only the last one is used. Integer values are assumed to be decimal unless preceded by H’ or 0x. Numbers with frames may be indicated by specifying the frame first, followed by the telephone number. The character & can be used to as a separator. The ServiceFilteringResponse subpanel and operation panel displays the following icons: Selecting this button will display all subparameters so that their values can be modified. Selecting this button will remove all subparameters from view after they have been displayed.

74

SMAS, Red Line Trace

Selecting this button will display the subparameters of the associated parameter so that their values may be modified. After the subparameters have been displayed and/or modified, they can be removed from view by selecting this button again. Selecting this button will expand the parameter so that you may view or set the subparameters. Select this button again to collapse the parameter. The ServiceFilteringresponse window includes the following input fields: countersValue

This parameter indicates the number of calls counted.

filteringCriteria

This parameter specifies which calls are filtered based on ’serviceKey’, ’callingAddressValue’, ’calledAddressValue’or ’locationNumber’. It is a choice of ’serviceKey’ or ’addressAndService’.

Additional CS1+ Parameters

responseCondition

This parameter indicates whether this ServiceFilteringResponse marks the end of service filtering or is an intermediate response.

sCFCorrelationInfo This parameter allows a more efficient correlation mechanism between ActivateServiceFiltering and ServiceFilteringResponse. Selecting Send will send the operation with it’s completed parameter information to the SCF. Clear resets the window. NPROCES Window The NPROCES List window is shown below:

Figure 2.26

NPROCESS window

Shows a window where you may start a new SCF process from a queued list of processes provided by the NPROCES control type. Select a process from the list, then select the Run button to start the selected process in the SCF. 75

IN 2.3 Service Testing Course

When an entry from the NPROCES list is RUN, the system simulation date/time will be set to the time indicated by the list entry. Use Set Clock in the Edit menu to change the time back to the current date/time, if desired.

76

SMAS, Red Line Trace

2.30 Send Menu The Send operations will open subwindows with input fields and various selections. To apply the input and close the subwindow select Send. The Send menu includes the following options: CallInformationReportThis operation sends specific call information to the SCF as requested by the SCF in a previous CallInformationRequest operation. EventNotificationCharging This operation sends a report to the SCF of the occurrence of a specific charging event type requested by the SCF in a previous RequestNotificationChargingEvent operation. EventReportBCSM

This operation notifies the SCF of a call related event previously requested by the SCF in a RequestReportBCSMEvent operation.

ApplyChargingReportThis operation reports charging related information to the SCF as requested by the SCF in a previous ApplyCharging operation. SpecializedResourceReport This operation is used as a response to a PlayAnnouncement operation. PromptAndCollectUserInformation Result The PromptAndCollectUserInformation operation interacts with a call party in order to collect information. Sent as a response to PACUI operation. ActivateServiceFiltering Result The ActivateServiceFiltering operation causes the SSF to handle calls to destinations in a specified manner without requests for instructions from the SCF. Sent as a response to ASF operation. CS1+ Operations

ReleaseCallPartyConnection Result This operation displays a window where you may send the result of a ReleaseCallPartyConnection operation to the SCF. Reconnect Result

This operation displays a window where you may send the result of a Reconnect operation to the SCF.

HoldPartyConnection Result This operation displays a window where you may send the result of a HoldCallPartyConnection operation to the SCF.

77

IN 2.3 Service Testing Course

2.31 Error Menu The Error operations will open subwindows with input fields and various selections. To apply the input and close the subwindow select Send. The Error menu includes the following options: ActivateServiceFiltering Shows a window where you may return an errorcase of an ActivateServiceFiltering operation to the SCF. ApplyCharging

Shows a window where you may return an error case of an ApplyCharging operation to the SCF.

Callgap

Shows a window where you may return an errorcase of a CallGap operation to the SCF.

CallInformationRequest Shows a window where you may return an errorcase of a CallInformationRequest operation to the SCF. Cancel

Shows a window where you may return an errorcase of a Cancel operation to the SCF.

CollectInformation

Shows a window where you may return an errorcase of a CollectInformation operation to the SCF.

Connect

Shows a window where you may return an errorcase of a Connect operation to the SCF.

ConnectToResource Shows a window where you may return an errorcase of a ConnectToResource operation to the SCF. Continue

Shows a window where you may return an errorcase of a Continue operation to the SCF.

DisconnectForwardConnection Shows a window where you may return an errorcase of a DisconnectForwardConnection operation to the SCF. EstablishTemporaryConnection Shows a window where you may return an errorcase of an EstablishTemporaryConnection operation to the SCF. FurnishChargingInformation Shows a window where you may return an errorcase of a FurnishChargingInformation operation to the SCF.

78

InitiateCallAttempt

Shows a window where you may return an errorcase of an InitiateCallAttempt operation to the SCF.

PlayAnnouncement

Shows a window where you may return an errorcase of a PlayAnnouncement operation to the SCF.

SMAS, Red Line Trace

PromptAndCollectUserInformation Shows a window where you may return an errorcase of a PromptAndCollectUserInformation operation to the SCF. ReleaseCall

Shows a window where you may return an errorcase of a ReleaseCall operation to the SCF.

RequestNotificationChargingEvent Shows a window where you may return an errorcase of a RequestNotificationChargingEvent operation to the SCF. RequestReportBCSMEvent Shows a window where you may return an errorcase of a RequestReportBCSMEvent operation to the SCF. SendChargingInformation Shows a window where you may return an errorcase of a SendChargingInformation operation to the SCF. CS1+ Operations

ReleaseCallPartyConnection Shows a window where you may return an error case of a ReleaseCallPartyConnection operation to the SCF. HoldPartyConnectionShows a window where you may return an error case of a HoldCallPartyConnection operation to the SCF. Reconnect

Shows a window where you may return an error case of a Reconnect operation to the SCF.

SignallingInformationShows a window where you may return an error case of a SignallingInformation operation to the SCF. Handover

Shows a window where you may return an error case of a Handover operation to the SCF.

79

IN 2.3 Service Testing Course

2.32 Assist Menu The Assist operations will open subwindows with input fields and various selections. To apply the input and close the subwindow select Send. The Assist menu includes the following options: AssistRequestInstructions Shows a window where you may invoke an AssistRequestInstructions operation toward the SCF over an assisting dialogue. SpecializedResourceReport Shows a window where you may invoke a SpecializedResourceReport operation toward the SCF over an assisting dialogue. ApplyChargingReport Shows a window where you may invoke an ApplyChargingReport operation toward the SCF over an assisting dialogue. PromptAndCollectUserInformation Result Shows a window where you may send the result of a PromptAndCollectUserInformation operation to the SCF over an assisting dialogue. End Assisting Dialogue Ends an assisting dialogue connection. Cancel, Return Error Shows a window where you may return an errorcase of a Cancel operation to the SCF over an assisting dialogue. PlayAnnouncement, Return Error Shows a window where you may return an errorcase of a PlayAnnouncement operation to the SCF over an assisting dialogue. Prompt&CollectUserInfo, Return Error Shows a window where you may return an errorcase of a PromptAndCollectUserInformation operation to the SCF over an assisting dialogue. ApplyCharging, Return Error Shows a window where you may return an errorcase of an ApplyCharging operation to the SCF over an assisting dialogue. DisconnectForwardConnection, Return Error Shows a window where you may return an errorcase of a DisconnectForwardConnection operation to the SCF over an assisting dialogue. FurnishChargingInformation, Return Error Shows a window where you may return an errorcase of a FurnishChargingInformation operation to the SCF over an assisting dialogue.

80

SMAS, Red Line Trace

ReleaseCall, Return Error Shows a window where you may return an errorcase of a ReleaseCall operation to the SCF over an assisting dialogue. SendChargingInformation, Return Error Shows a window where you may return an errorcase of a SendChargingInformation operation to the SCF over an assisting dialogue.

81

IN 2.3 Service Testing Course

2.33 Pane Menu The RLT Pane Menu is a text menu, as shown here:

Figure 2.27

Pane Menu window

The Pane menu window includes choices to zoom and print the SSL.

82

SMAS, Red Line Trace

2.34 Module Summary • SMAS is part of TMOS which is Ericsson’s concept for centralised operation and maintence.

• If SMAS is not available, service handling can be done with the help of MML commands directly to the SCP.

• Service handling in SMAS covers a number of different areas: Service Creation, Service Deployment, Service Provisioning etc..

• Audit is used to compare data in a Network Element with the corresponding data in the SMAS database or between mated NEs.

• Red Line Trace is a debugging tool for services designed in SMAS. • RLT allows the user to specify and uninstalled service or an SCP, provide it with start values and simulate the interaction between the SSP, the SCP, and the SDP.

83

IN 2.3 Service Testing Course

84

Service Provisioning Subsystem (SES)

3. Service Provisioning Subsystem (SES)

3.1 Introduction Service Provision Subsystem (SES) implements the intelligent network functions in AXE and consists of central software only. Traditionally, all logic associated with subscriber services was held in the switching nodes to which subscribers were attached. Intelligent Networks make provision for services to be provided independent of a switching node. IN in an architectural concept for creation and provisioning of new services. The implementation of this concept will faciliate the rapid introduction of new services. The telecommunication Standardisation Sector of the International Telecommunication Union (ITU-T) has published a set of recommendations regarding IN. The first set of recommendations is called Capability Set 1 (CS1). Based on these recommendations, the European Telecommunication Standards Institute (ETSI) has published a standard for an IN Application Protocol (CS1 Core INAP).

Module Objectives After completing this module the participant will be able to: • Be able to describe the main functions of the SES • Be able to describe the main functions of the SSP and SCP • Be familiar with the function blocks within SSP and SCP • Understand how the IST table is built up • Monitor the dialogue between the SSF and SCF • Locate and correct fault in SSP and SCP. Figure 3.1

Module Objectives

3.2 SES Structure SES is divided into two functional elements:

• Service Control Function (SCF) which implements the SCP functionality

• Service Switching Function (SSF) which implements the SSP functionality SCF and SSF implemented in the same node provide the functionality of an SSCP 85

IN 2.3 Service Testing Course

SES interworks with two elements:

• Service Management System (SMAS) • Call and Connection Control

SMAS SCF Service Program Service Processing SSF - SCF Communication

SSF SSF - SCF Communication Operation Processing

Triggering

Traffic Processing

Resource Handling

Call and Connection Control

Figure 3.2

SES Structure

The Service Control Function (SCF) is made up of the following:

• Service Programs - these programs enable the IN services to be implemented in a fast and efficient way. Services are defined using Control Types. These Control Types are combined into Service Scripts to describe an IN service.

• Service Processing - provides for the execution of service programs, that is, on a service request from the SSF, service processing invokes the functions of a Service Program.

• SSF-SCF Communication - establishes dialogue between SSF and SCF in an IN call. When SSF and SCF are within the same exchange (in a Service Switching and Control Point - SSCP), they have commu86

Service Provisioning Subsystem (SES)

nication directly using AXE internal signals. When they are located in different exchanges, they use the signalling system CCS7 to communicate. Service Switching Function (SSF) is made up of the following:

• SCF-SSF Communication - will be explained in relation to SCF. • Operation Processing - executes the operations requested from SCF (for example, a response to a service request from the Traffic Control Subsystem - TCS).

• Triggering - contains the triggering function, that is, a function to detect when an IN service is to be activated.

• Resource Handling- controls announcements when they are used in an IN call. This function also handles reception of the subscriber’s dialled digits. Both SSF and SCF contain SCF communication functions. These functions are used to establish dialogue between SSF and SCF in an IN call. When in same AXE SSF-SCF communicate using AXE internal signals. When in separate they use C7 signalling. IN services are introduced to SCF using SMAS via IOG11 input/output interface. SES interworks with the following subsystems:

• • • • • • •

Trunk and Signalling Subsystem (TSS) Group Switching Subsystem (GSS) CHarging Subsystem (CHS) Traffic Control Subsystem (TCS) Common Channel Signalling subsystem (CCS) Operation and Maintenance Subsystem (OMS) Statistics and Traffic measurement Subsystem (STS)

3.3 SES Groups SES can be broken up into two different group products. With the products of each group, IN nodes can be configured. Products in a certain group will only function together with other products in the same group, not with products from the other group. One group, consists of INAP, SSF, SCF, TC_USER, IWU-S12, IWUEWSD, SSSIM and SSMM. This group is referred to as Group 1 below. The second group, consists of INAPCS1, INAPCS1+, SSFSTD, SCFSTD, PHF, INTSIM and SSMM. This group is referred to as Group 2 below. Both groups offer backwards compatibility. Group 2 offers compliance to ETSI CS1.

87

IN 2.3 Service Testing Course

3.3.1

Description of the Group 1 Products Intelligent Network Application Protocol (INAP) The INAP specifies the operations in the interface between SSF and SCF as well as the parameters within the operations. INAP also specifies the procedures that must be followed on the interface, and the underlying models of the switching state in the SSF. Service Switching Function (SSF) The SSF is the functional entity, embedded in a switching node of the network, which provides the network with access to the IN services in the SCF. It is responsible for forwarding a service request to the SCF whenever a call has met the trigger conditions of an IN call. It provides the interface to the SCF to allow services to interact with the calls and connections in the network. Its interface to the call and connection control function gives the SSF access to the network resources and call instances in the network. By means of a specified set of operations and events, the SSF offers a limited view and influence of the network to the SCF. It is responsible for executing the requested operations from SCF and generating network related events of interest towards the SCF. Service Control Function (SCF) The SCF controls the processing of IN services. It contains the service programs, which constitutes the IN services, and provides for the execution of these. On a service invocation request from the SSF, the SCF will select the requested service program and execute it. The SSF interface enables services to operate on connections and resources in the network. This limited interface to the network and the functional separation of network and service processing allows for network implementation independent service development and processing, i.e. the services are no longer dependent on the network implementation or network developments. Services are introduced in the SCF via the Service Management interface. The same interface provides for the operation and maintenance of the service after its deployment. S12 Interworking Function (IWU-S12) This interworking function is required in addition to (product) SCF when interworking towards S12 SSF is needed. The function provides translation of Alcatel INAP into Ericsson INAP and vice versa. A TC-User part is also included in this function. EWSD Interworking Function (IWU-EWSD) This interworking function is required in addition to (product) SCF when interworking towards EWSD SSF is needed. The function provides translation of Siemens

88

Service Provisioning Subsystem (SES)

INAP into Ericsson INAP and vice versa. A TC-User part is also included in this function. Transaction Capability User (TC-USER) The Transaction Capability User controls the usage of TCAP as a carrier for INAP. The TC-User builds TCAP messages from the INAP operation and is responsible for the establishment and maintenance of the dialogue between a SSP and SCP. This involves an activity test mechanism and the handling of reset indications. Traffic Simulation (SSSIM) For testing purposes this function can simulate the SSF-SCF communication towards either the SSF or the SCF. Furthermore it is possible to monitor the SSF-SCF communication. Memory Management (SSMM) This function can control the size of all size alterable files in SES, from a central point in the subsystem. It also takes care that the sizes of files in blocks SSI and SCFM are coordinated.

3.3.2

Description of the Group 2 Products Intelligent Network Application Protocol CS-1 (INAPCS1) The functionality of this product is similar to that of the Intelligent Network Application Protocol in Group 1. The main difference is, that it is compliant to the ETSI Core INAP standard. Intelligent Network Application Protocol CS-1+ (INAPCS1+) This product specifies the operations in the interface between SCF and SDF as well as the parameters within the operations. It also specifies the procedures that must be followed on the interface and the underlying models. All this is according to an Ericsson protocol. Service Switching Function CS-1 Standard (SSFSTD) The functionality of this product is similar to that of the Service Switching Function in Group 1. The main difference is, that it is compliant to the ETSI Core INAP standard. Service Control Function CS-1 Standard (SCFSTD) The functionality of this product is similar to that of the Service Control Function in Group 1. The main difference is, that it is compliant to the ETSI Core INAP standard. Protocol Handling Function The functionality of this product is similar to that of the Transaction Capabilities User function in group 1. Traffic Simulation (INTSIM) The functionality of this product is similar to that of the traffic simulation function in Group 1. This will be described in more detail later in this module.

89

IN 2.3 Service Testing Course

Memory Management (SSMM) The functionality of this product is similar to that of the traffic simulation function in Group 1. But there is no coordination of file sizes between blocks.

3.4 Service Switching Function (SSF) SSF (Service Switching Function) is part of the subsystem SES (SErvice provision Subsystem). It consists of central software only. The SSF is a Functional Entity in the Intelligent Network Distributed Functional Plane Architecture. This product forms the Ericsson implementation of SSF according to ETSI IN CS1 Core INAP with references to ITU CS1 recommendations. The SSF provides the set of capabilities required for interaction between the Call Control Function (CCF) and the Service Control Function (SCF) in order to access and process services for subscribers in an Intelligent Network.

3.5 SSF-SCF Communication For each IN call one or several dialogues may be established between SSF and SCF. Only one controlling dialogue is allowed. The information flow between SSF and SCF consists of a set of remote operations. When the SSF and SCF are embedded in the same network element they communicate directly via AXE-10 signals. When the SSF and SCF are located in different network elements they use the Transaction Capabilities Application Part (TCAP) to communicate via the Signalling System Number 7 network. The set of operations is defined in an IN Application Protocol according to ETSI Core INAP CS1.

SSCP Service Control Function

Figure 3.3

Embedded Configuration

90

Protocol Handling Function

Service Switching Function

Service Provisioning Subsystem (SES)

SCP1

SSP

Service Control Function

Service Switching Function

Protocol Handling Function

Protocol Handling Function

TCAP

SCP2 Service Control Function Protocol Handling Function Figure 3.4

Remote Configuration

91

IN 2.3 Service Testing Course

3.6 SSF Function Specification 3.6.1

Function Specification Description

Service Control Function

Protocol Handling Function

SSF Dialogue Control

Triggering

TCS

Charging

CHS

IN Call Control

OMS

ESS

Special Resource Handling

GSS

Mass Call Services

STS

Figure 3.5

Functional structure of SSF and interface to other APT subsystems

For a description of the interfacing APT subsystems see Appendix “Description of SSF interfacing APT Subsystems”. Dialogue Control Dialogue Control controls how dialogues are initiated, maintained, closed and coordinated by SSF. Several dialogues may exists for a single IN call segment, but only one at a time is allowed to influence the call processing i.e. single point of control. Other existing dialogues must be in a monitor relationship. The dialogues are supervised by Finite State Machines (FSMs) and must behave according to determined rules for the FSMs. The FSMs reflects the state of the dialogues and controls the reception and sending of operations between SSF and SCF. Some FSMs realizes the possibility for SCF to 92

Service Provisioning Subsystem (SES)

have a view of the status for the call process and the connection process in SSF/CCF. Other FSMs are used by the SSF itself to have the total picture of the call status. Following FSMs are handled by this function:

• - Session FSM This FSM coordinates several dialogues active on the same call and on the same SSF instance. The FSM is used by the SSF to decide if it is allowed to open a new dialogue (a control relationship) on a specific call segment.

• - Call FSM The Call FSM handles the operation reception and sending on a per dialogue level in a certain call segment in an initiating SSF. Several Call FSMs can be connected to the same Session FSM. The Call FSM reflects the view of the status for the call, for the SCF connected to the dialogue.

• - Non-call FSM This FSM is used for controlling reception and sending of operations on a non call associated dialogue either opened by SSF or SCF.

• - Assist FSM This FSM is used when SSF acts as an assisting SSF and controls the reception and sending of operations on a per dialogue level in a certain call segment. Only one Assist FSM can be connected to a Session FSM. The Assist FSM reflects the view of the status for the call, for the SCF connected to the dialogue.

Triggering At selection of IN an IN route and an IN Service Trigger (IST) is pointed out. The IST is available from the B-number analysis performed by the Traffic Control Subsystem (TCS). The initial conditions for the call handling must be prepared so that they may be applied for the rest of the IN call. An important part of this is the arming of the applicable Trigger Detection Points. Trigger Detection Points are points in the basic call process where an IN service could be invoked, starting by sending the operation InitialDP. Triggering occurs when a Trigger Detection Point (TDP) is armed and the criteria for this Detection Point is met during the call processing. Possible Call Gap or/and Service Filtering analysis is performed before allowing SSF to initiate a dialogue towards SCF. SSF will include data in the query to SCF according to settings in the trigger tables. The data is fetched by SSF from CCF. The IN Service Trigger (IST) points out the necessary data (defined by commands) which are needed for further processing by the Service Logic in SCF as well as data needed by SSF for finding the correct SCP. Dependent on type, data can be defined on IST level or per Trigger Detection Point within an IST.

93

IN 2.3 Service Testing Course

The Trigger function is also used when an assist dialogue is to be established towards SCF. This is triggered by defining specific IST values to reflect the ’assist case’.

Basic Charging SSF, Basic Charging specifies the ways in which it is possible to influence the charging of calls handled by SSF. Charging in the SSP of IN services is performed as a result of the ordinary charging analysis in the SSP and/or operations received from SCF. Charging can be performed by Toll Ticketing and/or Pulse Metering. For some service types, such as Credit Card calls, only Toll Ticketing is applicable. The following functionality is covered: a)

Guarantee that a TT-output is performed for the call.

b)

Influence the charging of the call - Tariff Indicator to incoming leg - Input to charging analysis to outgoing leg - Charge indication in ISUP messages - Tariff change during the call - Pulse burst during the call

c)

Start and stop charging

d)

Additional of Billing Information. Including charge for the use of a specific service.

In connection to charging it is possible to decide per IN service trigger, or per call, whether meter pulses and charging messages should pass from outgoing to incoming leg. It is possible to report the events: Received Charging Messages and specific charging information to the Service Control Function. Charging is covered in a later module.

94

Service Provisioning Subsystem (SES)

IN Call Control The IN Call Control is responsible for the interface to the call processing functions of the exchange. This interface allows SCF to control the call processing and the connectivity of the information channels for each leg in a call.

Call Processing Function (TCS1)

IN Call Control Function (SSF)

Call Processing Function (TCS2)

SCF

Figure 3.6

Connections between IN Call Control and TCS

To control and monitor the call status, the IN Call Control Function has Call Leg State Machines (CLSMs). CLSM is the Ericsson projection of the Basic call State Model(BCSM). The CLSMs is based on a call-leg concept, where each access represented by a leg is explicitly reflected in a Finite State Model. The CLSMs determines the Point in Call and when a Detection Point is reached. Possibilities exists for arming detection points at certain points in the CLSM. The detection points can be armed staticly by the Trigger function and are then called Trigger Detection Points (TDPs) or dynamically by SCF during a dialogue and are then called Event Detection Points (EDPs). This way it is possible for the SCF to have a view of the basic call processing activities. Trigger Detection Point handling is described in the Module ’Triggering’. EDPs are used by SCF to monitor on certain call events during service execution. Call events are reported up to SCF when armed EDPs are encountered. Detection points can be armed by the SCF as Event Detection Points in two different modes - ’Notify and Continue’ or ’Request’ mode. When a TDP or EDP armed in request mode is reported to SCF the basic call processing is suspended by SSF until an order is received from SCF to resume the call processing.

95

IN 2.3 Service Testing Course

When an EDP armed in notify-and-continue mode is reported to the SCF, the basic call process is NOT suspended by the SSF. The call processing continues immediately after the report is send to the SCF. Any kind of interaction from SCF on the call control and call set-up process are handled by the IN Call Control. Any other function in SSF can dynamically arm detection points in the CLSM, to be able to execute actions at a certain time in the call. When the detection point is reached, the functions will be informed about it and the specific action can be performed. Only one function is informed at a time to avoid interactions.

Call Processing Function (TCS1)

IN Call Control Function (SSF)

Call Processing Function (TCS2)

Mass Call Service Function

SSF Charging Function

Special Resource Function

Figure 3.7

Distribution of call events to different functions

To avoid interaction between actions caused by traffic events and actions caused by INAP events (operations received from the SCF or operations to be send to the SCF), the IN Call Control administrates a token. Any function in the SSF must ask for the token before an operation is executed or before a traffic event are handled - except transmitting of traffic event that do not affect the SSF.

Specialized Resource Function Specialized Resource Function describes how special resources can be controlled by IN when required for execution of IN provided services. The special resources can be used and controlled by IN for: - Simple announcements - Announcement with variable parts 96

Service Provisioning Subsystem (SES)

- Monitoring for DTMF digits - Voice prompting - Generating of tones - Generating of text Note: It is only possible to send announcements/text or to monitor for DTMF digits to the initial leg (SSF initial or SCF initial leg). A simple announcement can be played to the end-user one or a number of times. An announcement with variable parts gives the possibility to include up to five variable parts in an announcement. Monitoring for DTMF digits can be done towards the end-user. When DTMF digits are received they can be reported up to SCF. Voice prompting is used to play an announcement to the end-user and collect DTMF digits as response to the announcement and inform SCF about received information. Tones (busy, congestion etc.) can be sent to the end-user and it is possible to give a duration for the tone sending. It is possible for SCF to provide a text string to SSF for distribution to an end-user.

Counters in the measurement database for SSF This specification describes the measurements provided in the Service Switching Function (SSF). The functionality is based on the system for Statistics and Traffic Measurements. The following statistical functions are supported:

• • • • •

Average number if records in use for size alterable files. Average congestion for size alterable files. Average number of failed accessed due to erroneous IN Trigger Data. Average number of failed outgoing calls due to erroneous route data. The quality of the dialogues by means of - number of operations - number of errors/rejects - number of aborts - number of timeouts (Tssf, Tsrf)

• Number of SCF invocations per - Destination Point Code - Global Title Logic - Local destination 97

IN 2.3 Service Testing Course

- Global Title Service Number - SCF id as Global Title

• Number of service requests for the Call Gap function • Number of service requests for the Service Filtering function Mass Call Services Mass Call Services can be divided into two sub-functions namely Call Gap and Service Filtering.

• The Call Gap function is used to protect the SCF against overload. This is accomplished by reducing the rate of which specific service requests are sent to SCF. Call Gap is initiated from SCF via a specific operation or via a command interface. It is possible by SCF to decide the release procedure in SSF when a call is rejected i.e. send announcement, tone, text before releasing the call and/or include specific cause value at release.

• The Service Filtering function provides various mechanisms to filter calls according to specific algorithms. This can be used for televoting type of services, counting the rejected calls. A set of counters exists for this function and these can be reported up to SCF at occasions determined by SCF. It is possible by SCF to decide the release procedure in SSF when a call is rejected i.e. send announcement, tone, text before releasing the call or include specific cause value at release.

Interaction between INAP and ISUP Interaction between INAP and ISUP e.g. how call processing INAP operations affects ISUP signalling procedures and vice versa.

Ericsson support of Core INAP CS1, PICS SSP Ericsson SSP is compliance towards ETSI Core INAP CS1 in forms of tables. These tables includes information such as ETSI Core INAP operations, arguments, application contexts, interfaces etc.

98

Service Provisioning Subsystem (SES)

3.7 List of Function Specifications 1.

SSF, Dialogue Control

2.

SSF, Triggering

3.

SSF, Basic Charging

4.

SSF, IN Call Control

5.

Specialized Resource Function

6.

Counters in the measurement database for SSF

7.

SSF, Mass Call Services

8.

SSF, Interaction between INAP and ISUP

9.

Ericsson support of Core INAP CS1, PICS SSP

3.8 SSF Implementation 3.8.1

General Description The SSF is located in subsystem SES and inter-works with subsystems within APZ and with following APT subsystems: - TCS Traffic Control Subsystem - CHS Charging Subsystem - OMS Operation and Maintenance Subsystem - ESS Extended Switching Subsystem - GSS Group Switching Subsystem - STS Statistics and Traffic Measurement Subsystem SSF also has an interface towards the Protocol Handling Function (PHF) within subsystem SES. PHF has an interface towards CCS when the SSF is able to communicate with an externally located SCF (SCP) and an interface towards SCF, when the SCF is located in the same node as the SSF i.e. SSCP configuration.

99

IN 2.3 Service Testing Course

3.8.2

SSF Functions The figure below shows a rough grouping of the SSF functionality and the internal interfaces.

Mass Call Services

Dialogue Control

Specialized Resource Function

Triggering & IN Call Control

Charging

IN Clearing and Fault Handling

100

Service Provisioning Subsystem (SES)

3.8.3

Mapping SSF function to function blocks The different functions owned by SSF are implemented in a number of function blocks. Below is shown a functional grouping of the SSF blocks. Triggering SSFTDA1, SSFTDA2, SSFDCF IN Call Control SSFDCF, SSFCCF, SSFEC, SSFCROH, SSFXCM Mass Call Services SSFCG, SSFCGA, SSFSF, SSFSFA, SSFMCS Charging SSFCHM Dialogue Control SSFDM, SSFEC Specialized Resource Function SSFSRF IN Clearing and Fault Handling SSFICFH

Dialogue Control

Mass Calling Service

SSFDM SSFEC

Specialized Resource Function

Triggering & IN Call Control

SSFSRF

SSFCG SSFCGA SSFSF SSFSFA SSFMCS

SSFTDA1 SSFTDA2 SSFDCF SSFCROH SSFCCF SSFXCM SSFFEC

SSFCHM

Charging

Figure 3.8

Functional grouping of the SSF blocks

101

IN 2.3 Service Testing Course

3.8.4

Common Data Structure Functions blocks in SSF has some common files maintained by function block SSFDCF and SSFDM. SSFDCF is master for the Call-record file and the Leg-record file. For each IN call a Call-record and at least one Leg-record are seized. The pointers are distributed to all blocks have connected Call- and Leg-record files when SSF are accessed. When a second leg is initiated, then a new leg record will be seized. For follow-on calls the second leg record will be reused for the outgoing leg. SSFDM is master for the Dialogue-record file. All interested function blocks are advised when a Dialogue-record is seized or released.

Call - rec.

Leg - rec.

Dialogue - rec.

Leg - rec.

Figure 3.9

Common data structure for SSF

Only one Call-record is used per IN access. Up to two Leg-records can be used per IN access. Up to 16 dialogue records can be used per IN access, one per open dialogue. Some function blocks have additional links between Dialoguerecords, Leg-records and other records specific for the block. Each operation receiving and operation sending block has a Componentrecord file. Component-records can be connected to the Call-record or a Dialogue-record.

102

Service Provisioning Subsystem (SES)

3.9 SSF Function Blocks 3.9.1

SSFDCF SSFDCF is the main data manager of the IN Call Control function. SSFDCF is the master of the size alteration events for call records and leg records and it informs the blocks holding call records when a record must be initialized and when it is dismissed. SSFDCF contains a file for route data defined by command EXRBC. This data will be used as default route data when route-index is defined in operations Connect and/or InitiateCallAttempt. SSFDCF contains a file for IN service trigger (IST) data defined by commands SWIPI, SWITI and SWRDI. IST data is used to arm trigger detection points (TDP) and indicates which operation InitialDP or AssistRequestInstruction is to be send when the TDP is encountered in the call. Furthermore holds each TDP information about which contents the InitialDP should have if a call encounters the TDP and to which SCF the operation should be send to. SSFDCF contains a file for destination route data defined by command SWSDI. These destination is used to route the InitialDP or AssistRequestInstruction operations to the right SCF according to the destination indicated on a given trigger detection point on the IST. When SSF is seized from TCS, SSFDCF is linked to RE where it reads the necessary data. After the reading SSFDCF is replaced in the traffic chain by SSFCCF. SSFDCF stores the data received in operations from the Service Control Function and ’IAM’ data read from TCS (or through TCS). When a trigger detection point is encountered, the SSFDCF will send either InitialDP or AssistRequestInstruction to the SCF with requested information according to the trigger data. SSFDCF supplies data for operation sending as well as ’IAM’ data for routing.

3.9.2

SSFCCF SSFCCF have two interfaces towards TCS, an IT- and an OT-interface. When SSFDCF has send either InitialDP or AssistRequest operation to SCF (or it realized that no originating TDP exists) SSFCCF is linked into the traffic chain instead of SSFDCF. SSFCCF receives, queues and handles signalling events. SSFCCF contains a filter towards signalling events. SSFCCF reports events such as detection points to SSFEC. The call processing is halted for the actual call during the event handling in the SSFEC. Until SSFEC or SSFCROH continues the call processing, all 103

IN 2.3 Service Testing Course

received signals - except disconnection signals - to and from the actual leg are buffered. On order from SSFCROH, SSFCCF creates new outgoing legs. SSFEC takes care of the initialization of the leg records and informs the blocks holding the leg records, when a leg record must be initialized. SSFEC administrates the token for the SSF. To prevent interactions when handling a received operation or an encountered detection point, a token is introduced. The token can be requested by any function at any time during the call. If the token is in use, the request will be added to a queue. SSFEC maintains a CLSM on each leg. Every time an event is reported from SSFCCF/SSFDCF, SSFEC will update the CLSM on the leg on which the events has happened and if necessary also on the opposite leg. Events are reported to SSFEC by all other blocks in the SSF that normally handles the events. The events can be that a detection point is meet or that a local event has happened. SSFEC handles the arming, disarming and reporting of different kind of events. When an armed event has occurred, SSFEC will inform all blocks that has asked for (armed) the event. If the event is a detection point, then SSFEC will occupy token before reporting the event. If the event is a local event the user must itself ask for the token if necessary. When a the handling of a detection point is finished, SSFEC will check the remaining armings to update the Call FSMs, the Session FSM and check if the dialogues should still be kept open. SSFEC handles the operations RequestReportBCSMEvent and CallInformationRequest. EventReportBCSM: SSFEC is requested for certain information when certain call events happens. The information is send to the SCF in operation EventReportBCSM. CallInformationRequest: SSFEC is requested for certain information when the call or a call leg disconnects. The information is send to the SCF in operation CallInformationReport.

3.9.3

SSFCROH SSFCROH handles the operations from SCF that affects the call process. The operations are CollectInformation, Connect, ConnectToResource, Continue, EstablishTemporaryConnection, DisconnectForwardConnection InitiateCallAttempt and ReleaseCall. CollectInformation operation: SSFCROH checks in SSFEC that DP2 (CollectedInfo) has been armed and that a number of required digits are specified. SSFCROH orders SSFEC to change the CLSM state to PointInCall CollectInformation. Connect operation: SSFCROH orders SSFCCF to set up an outgoing leg to a new destination and connect it to an already existing initial leg (incoming or outgoing).

104

Service Provisioning Subsystem (SES)

ConnectToResource operation: SSFCROH informs SSFSRF to prepare for announcement sending, text sending or digit reception. Continue operation: SSFCROH informs SSFCCF to continue the call processing after an InitialDP or an EventReportBCSM has been send to the SCF. If no outgoing leg exist, SSFCCF will continue by making an outgoing leg (implicit Connect). If outgoing leg exist SSFCCF will propagate the reported event and release buffered events. SSFCROH will also inform SSFEC that the call processing continues. SSFEC will act as if handling of an event is finished.

• DisconnectForwardConnection operation: SSFCROH disconnects the connection towards the Assisting SSF.

• EstablishTemporaryConnection operation: SSFCROH uses an IT-interface towards TCS to set up a connection to an Assisting SSF.

• InitiateCallAttempt operation: SSFCROH orders SSFCCF to create an outgoing leg with no connection to another leg. This is only possible as the first leg in a call.

• ReleaseCall operation: SSFCROH orders SSFCCF to disconnect both incoming and outgoing leg. If a temporary connection exists, it will be disconnected as well.

3.9.4

SSFCHM SSFCHM provides SSF with an interface towards CHS, so that SSF is able to hold and resume charging, provide charge limit check and to store charging information in the TT records and determine charging. SSFCHM handles the operations SendChargingInformation, FurnishChargingInformation, ApplyCharging and RequestNotificationChargingEvent.

• SendChargingInformation: SSFCHM will order to send charging information in the traffic link (tariff, charge indicator etc.).

• FurnishChargingInformation: SSFCHM will send charging information directly to the charging instance for the call/service (tariff, additional billing information etc.).

• ApplyCharging: SSFCHM is ordered to request charging related information from CHS at a certain event. The information is send to the SCF in operation ApplyChargingReport.

• RequestNotificationChargingEvent: SSFCHM is ordered to monitor for certain charging messages in the traffic link. The content of the charging messages are returned to the SCF in the operation EventNotificationCharging.

3.9.5

SSFICFH SSFICFH is a help function for clearing of calls in error situations. A Clearing program is invoked that defines the actions to be taken e.g. displaying information, clearing the call, continuing the call etc.

105

IN 2.3 Service Testing Course

The actions or sequence of actions can for each fault/clearing case be specified by exchange data settings in the SSF. Depending on the clearing program parameters and the state of the call, SSFICFH decides whether the call is to be released or, if possible, continued.

3.9.6

SSFTDA1 SSFTDA1 handles a part of the command reception and printout of trigger table and traffic related data as well as service data, e.g. for setting of IN trigger analysis data. The rest is handled by SSFTDA2. Commands SWIPE Service Switching IST Procedure End Terminates the specification of an IN service trigger. SWIPI Service Switching IST Procedure Initiate Initiates the specification procedure of an IN service trigger (IST). SWIDI Service Switching IST Data Initiate Defines the IN service trigger default settings. SWISE Service Switching IST Settings End Removes IN service trigger data settings from the not operating area. SWISP Service Switching IST Settings Print Print all data for one or all IN service triggers (IST). SWITI Service Switching Invoke Table Initiate The command defines a Invoke Table. The purpose of the Invoke Table is to define which parameters should be send to the SCF when a dialogue is opened. SWRDI Service Switching Routing Data Initiate Defines the Routing Table and connects the Routing Table to a specific Trigger Detection Point. The purpose of the data in the Routing Table is to secure that the correct SCF and Service Logic Program is invoked.

106

Service Provisioning Subsystem (SES)

SWTDE Service Switching Trigger Detection End Removes a specified Trigger Detection Point and all connected data like Invoke Table and Routing Data. Printout - SSF IN SERVICE TRIGGER DATA

3.9.7

SSFTDA2 The block SSFTDA2 implements a part of the command initiated functions to administer IN service trigger data. The block handles command reception and printout for IN Destination data and Exchange data. The rest is handled by SSFTDA1 Further it handles commands used to copy, clear or switch the operating area (OP) and the not operating area (NOP) in block SSFDCF. Commands SWTZI Service Switching Trigger Zeroing, Initiate Initiates zeroing of the entire not operating area for IN service trigger analysis. SWTCI Service Switching Trigger Copy, Initiate Initiates copying of the operating area for IN service trigger analysis to the not operating area. SWTAI Service Switching Trigger Activate, Initiate The command activates IN service trigger data which previously has been setup by several initiating commands. SWTAR Service Switching Trigger Activate, Reset Initiates a switch to previously used IN service trigger data, if the protection period has not elapsed. SWPTI Service Switching IN Service Trigger Procedure, Initiate Clears the protection time on the not operating area. SWSDI Service Switching Service Control Function Destination, Initiate Defines destination data to be used when routing against SCP. SWSDE Service Switching Service Control Function Destination, End

107

IN 2.3 Service Testing Course

Removes a SCP destination of the type DPC or GT logical. SWSDP Prints data for one or all of the defined SCP destinations SWSEC Service Switching Exchange Data, Change The command is used to set IP SSP Capabilities and location of cause originator (LOC) parameters or default values for operation types Initiate Call Attempt, Establish Temporary Connection and Connect. SWSEP Service Switching Exchange Data, Print Initiates a printout of exchange data. Printouts - SCF DESTINATION DATA - SSF EXCHANGE DATA - IST USED IN B-NUMBER ANALYSIS, LINE BASED SERVICES OR CALL IN PROGRESS.

3.9.8

SSFSFA SSFSFA handles the commands and printouts in conjunction with service filtering. Commands SWFPI Service Switching, Service Filtering Procedure, Initiate Initiates the specification procedure for Service Filtering data. SWFPE Service Switching, Service Filtering Procedure, End Terminates the Service Filtering specification procedure SWFSI Service Switching, Service Filtering Specification, Initiate Specifies Service Filtering data for a given Service Filtering Criteria. SWFSE Service Switching, Service Filtering Specification, End Removes data for a specific Service Filtering Criteria. SWFSP Service Switching, Service Filtering Specification, Print Initiates printout of Service Filtering Criteria, data and counters. Printouts - SERVICE SWITCHING SERVICE FILTERING RESULT

108

Service Provisioning Subsystem (SES)

3.9.9

SSFCGA SSFCGA handles the commands and printouts in conjunction with call gap. Commands SWGPE Service Switching Call Gap Procedure, End Terminates the specification procedure for Call Gap data. SWGPI Service Switching Call Gap Procedure, Initiate Initiates the specification procedure in order to specify Call Gap data. SWGSE Service Switching Call Gap Specification, End Removes data for a specific Call Gap criteria. SWGSI Service Switching Call Gap Specification, Initiate Specifies Call Gap data for a specific type of Call Gap criteria. SWGSP Service Switching Call Gap Specification, Print Initiates printout of Call Gap Criteria and data. Printouts - SERVICE SWITCHING CALL GAP DATA

3.9.10

SSFCG SSFCG protects the SCF against overload by rejecting calls in the SSF according to Call Gap mechanism. SSFCG handles the operation CallGap.

3.9.11

SSFSF SSFSF provides a mechanism to reject calls either on basis of an interval specification or on basis of number of calls. SSFSF handles the operation ActivateServiceFiltering

3.9.12

SSFSRF The block handles and controls the interface towards announcement equipment and gives directives towards the IN Call Control. SSFSRF handles the operations PlayAnnouncement and PromptAndCollect. For both operations it is possible to play an announcement, send a tone or a text. When e.g. an announcement is to be played or a tone is to be send on a leg, SSFSRF will select the announcement device and control it. Then

109

IN 2.3 Service Testing Course

it will request the IN Call Control to set the proper state in the Leg Level FSM and establish the connection in GS. When a text is to be send, SSFSRF will order SSFCCF to send the text in a xxx message in the traffic link.

3.9.13

SSFDM This block is responsible for handling (opening, closing and supervision) of dialogues. SSFDM is the connection between the Protocol Handler and the operations handlers in the SSF. SSFDM administrates all operation reception and operation sending to and from the SSF. SSFDM maintains a table for distribution of operations and distribute the operations to the right operation handlers. SSFDM collects operations from the SSF to the SCF so that they are send in the most efficient way (as many operation in one message as possible). SSFDM handles the operation Cancel. When InvokeID is specified, SSFDM will order SSFSRF to cancel a specific operation. When ’ALL’ is specified SSFDM will order SSFEC and SSFCHM to cancel all outstanding reports to the SCF. The dialogue will not be closed even though no reports are outstanding. The SSF will wait for new orders from the SCF.

3.9.14

SSFXCM SSFXCM has the interface from SSF to the group switch. SSFXCM connects and releases passes in the group switch in the appropriate way for the situation. SSFXCM is ordered to connect or release passes from SSFCCF. To change the passes in the group switch, SSFCHM also have the connection to the call control functions (CLCOF). SSFXCM makes sure that both CLCOFs are updated with the correct MUPs and connections. SSFXCM is not operation receiving.

3.9.15

SSFMCS SSFMCS handles the traffic part of the Call Gap and the Service Filtering functions and the connection to the special resource functions (SRF).

110

Service Provisioning Subsystem (SES)

3.9.16

Link Pictures

inc. trunk

CHS

TCS

SSFDCF

SSFXCM

SSFCHM

SSFCCF

SSFEC

Figure 3.10

Call accessing SSF - before full number is received.

SSFDCF

inc. trunk

CHS

TCS

SSFCCF

SSFXCM

SSFCHM

SSFEC

Figure 3.11

Call accessing SSF - full number is received. An InitialDP is send to the SCF.

111

IN 2.3 Service Testing Course

SSFDCF

inc. trunk

CHS

TCS

SSFCCF

SSFSRF

ESS

SSFXCM SSFCROH SSFCHM

SSFEC

SSFDM

Figure 3.12

Call accessing SSF - full number is received. An announcement is connected to the incoming leg.

112

Service Provisioning Subsystem (SES)

3.10 Service Control Function (SCF) The figure below shows how SCF fits into the functional architecture of Intelligent Networks (IN), and the functional structure inside SCF.

Service Creation & Management

Service Program

Service Processing

SCF - SSF Communication

Service Switching Function Figure 3.13

Functional Architecture of IN

The Service Control function controls the processing of IN services. It contains the service programs, which constitutes the IN services, and provides for the execution of these.

3.10.1

SSF-SCF Communication For each IN call a dialogue will be established between SSF and SCF. In this dialogue the SSF and SCF can communicate via a specified set of operations. When the SSF and SCF are embedded in the same network element they communicate directly via AXE-10 signals. When the SSF and SCF are located in different network elements they use the Transaction Capabilities Application Part (TCAP) to communicate via the Signalling System Number 7 network. The set of operations is defined in an IN Application Protocol (INAP).

113

IN 2.3 Service Testing Course

3.10.2

Service Programs A Service Program contains logical constructs which provides the instructions for realization of the service in the network. Service programs are constructed from instances of SIB’s (Service Independent building Block, in Ericsson terminology called Controltypes), which upon their execution invoke functional routines in the SCF. These functional routines may invoke actions in the SSF to access or control network resources or invoke functional actions on data or resources in the SCF. The logical construct is build by interconnecting instances of SIB’s to each other, and upon execution, constitutes the flow of service processing.

3.10.3

Service Processing The Service Processing function provides for the execution of the service programs. On a service request from the SSF, it will interpret the relevant service program by invoking the functional routines required from the service program. Service processing contains and manages the service programs and service data (i.e. all persistent data in the SCF). On invocation of a service program, it creates a service process to maintain all process data for the service program.

3.11 SCF Function Specification 3.11.1

Service Script Interpreter, General The service script interpreter stores and maintains all service scripts (and related data) in the service database and interprets these service scripts on request. The service database is capable of changing, introducing and testing new service programs without any traffic disturbance on existing or old services. The interpreter provides the service with a synchronous environment for service execution. Whenever the interpreter is invoked it creates a service process (i.e. processing context) to execute service scripts, store process data (i.e. data received in the invocation and subsequent operation results/ events) and buffer incoming events until they can be processed. The interpreter executes the logical flow of SIB instances in the service program and invokes the controltype logic for each encountered SIB instance. The capabilities of each controltype are described in separate functional specifications. A SIB instance can request monitoring of events in the SSF (call events or operation related events). When an event is received the interpreter will associate it with a service process and execute the SIB instances which monitored the event.

114

Service Provisioning Subsystem (SES)

3.11.2

Ericsson’s Protocol for IN, Version 2 Here the relationships between controltypes, as independent building blocks of a service, and the external protocol are described. These external relationships are supported by operations and parameters, which defines the functional behaviour of the service. The external relationship and also the internal relationship of controltypes with the internal data items are described. Data items can support the controltype directly, by providing necessary data (Service Support Data) needed to perform its function, and indirectly by supplementary data (Call Instance Data) provided by the Basic Call Process (BCP).

3.11.3

Service Script Interpreter, Basic Controltypes Basic controltypes are the controltypes which provide the interpreter with the basic capabilities, i.e. elementary functions required for service program design. The controltypes can be divided in the following categories:

• Interwork functions These control the execution flow of Service Scripts (SS)

• Information functions Used to load data to the communication channel towards the SSF

• Selection functions Branching functions on various types of data

• Network protection and distribution functions For keeping track of and influencing network utilization.

• Table branching functions Functions to branch on indexed tables

• Number manipulation functions Functions to edit and compare variables of type Number

• Response functions Initiates sending of loaded data on the communication channel and terminates Service Script execution.

115

IN 2.3 Service Testing Course

3.11.4

Service Script Interpreter, Basic Controltypes 2 Basic controltypes set 2 have similar functions as the ones previous, some of them are extensions/enhancements of the controltypes. The simpler versions are maintained however to provide compatibility for Service Programs with former products. The controltypes can be divided in the following categories:

• Interwork functions These control the execution flow of Service Scripts (SS)

• Selection functions Branching functions on various types of data

• Network protection and distribution functions For keeping track of and influencing network utilization

• Number and variable manipulation functions Functions to manipulate variables and numbers

• System functions Operations directed to the interpreter to control SS execution

• Timer function A relative timer mechanism.

3.11.5

Service Script Interpreter, Basic Controltypes 3 The basic controltypes set 3 are the controltypes related to the connection model. Generally these cover the operations for manipulating connections in the SSF and monitoring of events in the SSF.

3.11.6

Service Script Interpreter, Number Analysis The number analysis controltype is used for obtaining an SS identity on basis of an input number. The controltype in the next section is an extension of this controltype. The Number Analysis controltype is maintained to provide compatibility for service programs with former products.

3.11.7

Service Script Interpreter, Extended Number Analysis This controltype is used for analysis of numbers, the obtained results can be used in the SS for further processing. As result of the number analysis, the controltype may activate the congestion control function in the SSF.

3.11.8

Service Script Interpreter, Queuing The controltype queuing enables services to put calls in a queue when they can not be handled immediately. Subscribers in the queue can either be connected to an announcement machine or be called back when they can be handled. The controltype has different modes of operation to enable full queue control for the Service, e.g. call pick up from the queue, insert/remove from queue, access to queue parameters.

116

Service Provisioning Subsystem (SES)

3.11.9

Service Script Interpreter, Customer Control The Customer Control (CC) controltype allows customers to change data in their service scripts. The scope of a change (i.e. which data in what controltypes may be changed) and the procedure to fetch the new data (i.e. by subscriber procedures, as call data or constants) are defined by a CC procedure. These procedures are defined by the operator and globally available to all Service Scripts. Per service script a CC case identifies the SIB instance which is to be changed and the procedure to change it.

3.11.10

Service Script Interpreter, Voice Prompting The voice prompting controltype enables the service to interact with subscribers, i.e. playing of announcements and reception of a response in the form of digits. Voice prompting can initiate announcement sending to any party involved in the service process in SSF, where each announcement can include one or more variable parts (i.e. telephone number, time, price information, etc.). Simultaneous or after announcement, digit reception can be started to receive a subscriber response. Digit reception can be controlled by time supervision, number length or a number mask (i.e. prefix or suffix code or a predefined number). The digit reception procedure can include a limited number of retries and allows use of correction digits.

3.11.11

Service Script Interpreter, External SDF Interface The external SDF interface consists of two controltypes. One controltype for reading from and one for writing to an external database. The function is able to receive spontaneous updates from an external database. On reception of an update, a service process will be created and a service script is started which takes care of the received update information.

3.11.12

Service Script Interpreter, Statistics Counters The statistics counter function consists of 5 controltypes and some subfunctions to issue and handle statistics record output. The controltypes can maintain the following counters:

• counters for execution statistics of a certain SIB instance. This SIB instance can be of any controltype, or a specific statistics controltype may be used for this.

• :counters for various call events, e.g. B-answer, B-busy, No-reply, congestion, A-termination, error.

• general purpose counters (i.e. not tied to specific events) with or without threshold values. Statistics record output can be initiated on time interval basis or on basis of the number of invocations of a SIB instance (of a specific statistics controltype). Furthermore the function will format and transfer statistic records for binary or alphanumeric output.

117

IN 2.3 Service Testing Course

3.11.13

Service Script Interpreter, Reports The report function consists of a controltype to issue reports of process data on various conditions:

• Date and time window, in which reports can be generated. • Maximum number of issued reports from this SIB instance • Sampling on number of passes through this SIB instance. The controltype determines if a report should be generated and which process data shall be included. The report function subsequently formats and transfers the report record for binary or alphanumeric output. Apart from the report controltype, the report function can be connected to a SIB instance of any controltype, allowing to issue reports during invocation of this SIB instance.

3.11.14

Service Script Interpreter, Traffic Simulation Function For testing purposes this function can simulate the SSF-SCF communication towards either the SSF or SCF. Furthermore it is possible to monitor on SSF-SCF communication for specific dialogues. In simulation mode the operator will play the role of the other entity towards either the SSF and/or SCF. In monitor mode all communication between SSF and SCF is reproduced on an output device, without any effect on the dialogue.

118

Service Provisioning Subsystem (SES)

3.12 SCF Internal Concepts 3.12.1

Service Program Structure Service Program. is build from one or several service scripts. A service script is more or less a modularity concept to divide programs in reusable and functional modules. Whenever a service is invoked and has to be executed on the interpreter, the identity of the service needs to be determined. This in order to select the service script to execute. This function is referred to in reference 2. This selection can be very depended on different parameters and is therefore also implemented on the interpreter as a script, called the ACCESS service script. A Service Program is normally structured as follows:

Service Script Access Service Script

Service Scripts Service Scripts

Figure 3.14

Service Program Structure

The ACCESS service script. determines the actual Service to execute. So whenever the interpreter is invoked, the same service script will be invoked which will determine the requested service. There is no real limitation on the number of scripts used to determine the service. In the example above only one script is used to determine the service but the ACCESS service script can consist of several scripts. How many scripts that is used to specify the service itself is arbitrary. In the figure the ACCESS service script points out 4 different services of which two uses only one script, one service uses three scripts and the last one uses two scripts.

3.12.2

SIB’s and Controltypes Service scripts are build from SIB’s instances (Service Independent Building blocks), or in Ericsson terminology controltype instances. The figure below shows the functional model of the SIB.

119

IN 2.3 Service Testing Course

Service Logic Parameters: Logical Inlet Service Data Parameters: Input Process data System data

. . .

Logical Outlets

Result Process data

Figure 3.15

Functional Model of the SIB

A SIB has the following characteristics:

• A SIB defines one complete activity/function • A SIB definition is service independent as well as network implementation independent

• SIB’s are reusable among different services • The implementation of a SIB in the SCF and network is of no importance to the service designer A SIB has one logical inlet. via which it is activated. Depending on the specific controltype of the SIB and the different parameters/data, one out of a number of logical outlets. is selected after the SIB has completed its function. By connecting logical inlets of other SIB’s to the logical outlets, a flow of SIB’s can be executed. In this way a service script is build up, i.e. by connecting SIB’s to each other. The controltype determines the function of the SIB. When building a service scripts, instances of SIB’s are created and tailored to the specific service by defining the parameters. I.e. the controltype is a service independent function, the parameters are used to describe the function for a specific service. The parameters/data the SIB instance uses at execution can be divided in different categories:

• Process data., dynamic data which is received from the network for a specific process or set by other SIB instances in the same process.

• Service data parameters., static data specific for a service script or a service customer (i.e. the customer subscribing to the service). This data can be constants or identifiers of process data.

• Service logic parameters., static data specific for the service logic part of the service script. This data can either be constants or identifiers of 120

Service Provisioning Subsystem (SES)

process data.

3.12.3

Service Script Structure When the model is applied to real implementation, the division in service logic and service data parameters becomes obvious. Once a service script is build, it must be possible to reuse it for different services and different customers without building the script again. This is achieved by dividing the SIB instance in a service logic module. (SLM) and a service data module. (SDM), as shown in the figure below. Service Logic controltype id connections to other SLM’s service logic parameters ............

logical outlets

Controltype Logic ............

. . .

Service Data scope, structure service data parameters ............

Figure 3.16

Service Script Structure

A script is build by defining SLM’s and connecting them to each other, each SLM is of a certain controltype. This part of the service script is called the Service Logic. and constitutes the logical connections in the service scripts (i.e. the program flow), and some fixed parameters. The service logic can be reused for different services. For each SLM a service data module must be defined (if necessary for the controltype). All those SDM’s form the service data part of the service script, and tailor the service script for a specific service and/or customer. The logic and data are kept together on script level by a service administrator. It contains a reference table with an entry for each service logic module and a reference to the corresponding service data module. As shown below, different service administrators can refer to the same service logic, but each one has its own service data.

121

IN 2.3 Service Testing Course

Service Script service logic

service admin.

service data

Figure 3.17

Service Script

Note that the above picture shows actually three different service scripts (one per service administrator) which all use the same service logic. This structure allows for the reuse of complete service logic with different data. But the reuse of complete services for different customers requires another class of data, i.e. the part of the service that is tailored for the customer is normally very small compared to all service data of the service script. For instance call transfer will only need a C-number per customer while all other service data in the service logic program is typically the same for all customers. Service data modules can be of different classes:

• data modules per service administrator • global data modules, which can be used from any script by a SIB instance of the corresponding controltype.

• data modules per service customer. The class of the data per SDM is also kept in the reference table of the service administrator and for the first two the reference to the actual service data module as well. The reference to a Service Customer. can be determined anywhere in a service program, before the first service customer data module is encountered (e.g. the access script). The Service Customer reference is established at run-time dynamically (for instance by analysing the A-number) and valid through the complete service process (not just per script).

122

Service Provisioning Subsystem (SES)

Service Logic Global Service Data

Service Administrator

Local Service Data Ref.

Service Customer

Service Customer Data

Figure 3.18

Data Reference

Therefore a service customer has its own service data reference table independent of the service script (data of a certain Service Customer can be used in several scripts).

3.13 SCF Interface For service programs, the SCF interface represents the communication channel to the outside world, i.e. beyond the interpreter. The interpreter and the services are invoked through this interface, and during service execution it is the communication link to the SSF for the service.

Interpreter Kernel

SCF Interface

Simulator

Figure 3.19

SCF Interface

The interpreter supports the following interface:

• Seizure, a service process is created in the interpreter and an access

123

IN 2.3 Service Testing Course

service script is executed.

• • • • 3.13.1

Change process state, inform interface about changed processing state Event, incoming event for this service process. Send data, send the following data on the communication channel Release, release the communication link and service process.

Internal SCF-SSF Protocol At seizure of the interpreter a service process is created to execute the requested service upon. The process will provide the service with a synchronous execution environment which means that no external events or operations, directed to a service process, can interrupt script execution. Only when the service program itself suspends the execution, new external events are handled. The SCF interface will adapt the asynchronous internal protocol, used between the SCF and SSF, to the synchronous interface of the interpreter. All incoming events will be buffered as long as the process state doesn’t allow new events to come in. The interpreter will report to the interface whenever it is ready to receive the next event for a process (by reporting changes of process state). SIB’s acting on SSF objects, or services with explicit operations towards the communication channel, will send their operations to the SCF interface function. The interface will translate these sending requests to the internal SCF-SSF protocol and forward them to either the SSF or an adaptation function for an external protocol (e.g. a TC-user function). The internal protocol supports the following operations:

• Seizure, bidirectional. Seizure of SCF from SSF or seizure of SSF from a SCF service.

• Operation request/indication. Sending or reception of an operation on the communication channel. NOTE: events are regarded as operations in this protocol.

• Release, bidirectional. All operations and their parameters are segmented on AXE 10 signals, i.e. the operations can normally carry more data than one AXE 10 signal. The parameters and operation identifiers are coded according to the Tag/ Length/Value principle.

3.13.2

SCF/SSF Simulator The SCF interface is provided with a test and monitor function. A simulator function is able to simulate either part (SSF or SCF) of the internal protocol. By connecting the simulator as monitor on the communication channel, all operations can be sent to an output device and as well passed on to the receiver (SCF, SSF or the external protocol adapter).

124

Service Provisioning Subsystem (SES)

At seizure, i.e. setup of the communication channel between SSF and SCF, it is determined if a simulator is needed on basis of trigger data in the SSF or parameters received in the external protocol (in case of a remote initiated test). The simulator is seized on service process basis, i.e. simulation and monitoring takes place per communication channel. The simulator can also be invoked by SCF depending on the specified function.

3.14 SCF Interpreter Kernel The interpreter kernel is the core of the SCF, including the interpreter, the service database (where all service logic and data is stored), database maintenance and the IO interface to the database.

3.14.1

Controltype Subscription Initially the interpreter has no controltypes for interpretation of service scripts. All controltypes present in SCF have to identify themselves to the interpreter at restart, i.e. they subscribe to the interpreter. During subscription the controltype owning block sends all attributes and properties of the controltype to the kernel. Basically this information tells the interpreter how it should treat SIB instances of this controltype during service processing and how these SIB instances are defined on the I/O interface of the database. More specific:

• Identity of the controltype and location of the controltype logic + service data modules, i.e. external, mixed or in the kernel (interpreter and database).

• Type and format of service logic parameters for I/O and storage of service logic modules.

• Type and format of service data parameters for I/O and storage of service data modules.

• Control information for service processing. For instance job length, controltype logic in form of loadable code (e.g. internal controltypes). Above the distinction has been made between internal and external (from the kernel’s viewpoint) controltypes on basis of the location of the controltype logic and the service data modules. However some controltypes are a mix of both, i.e. have service data stored both in the kernel and external. The SIB interpreter contains an LLA (Low Level Action) interpreter which is capable of executing loadable (to the kernel) LLA programs. These are a list of very simple procedure calls, which are dispatched by the LLA interpreter to the corresponding code sequences. By use of LLA, the controltypes can load their controltype logic into the interpreter during subscription phase.

125

IN 2.3 Service Testing Course

The internal controltypes have no external controltype logic, only LLA programs. The mixed and external controltypes also load LLA programs in the kernel at subscription, but mainly for activation of the external controltype logic when a SIB of that controltype is executed in the interpreter.

3.14.2

Service Processing Each service process has its own data area in the interpreter. Besides from storing control info for the interpreter (like process state, service administrator/customer references, etc.), all dynamic variables are allocated in this area during service processing. This is data received from the communication channel (e.g. at seizure or events) or variables created by SIB’s during script interpretation, all coded according to Tag/Length/Value format. The coding format accomplishes a service independent process record, i.e. no dependency between the interpreter and dynamic service data. All monitor requests for events are registered as well on process basis, so the interpreter can find the issuer of the request (the SIB instance) as an event comes in. The interpreter engine. For each SIB the interpreter has to execute, it returns to the same execution loop. In the description below it is assumed that the reference to the SIB instance, i.e. the logical inlet, is already established (from a previous SIB instance or as first SIB instance in a script). The interpreter reads the controltype of the SIB instance from the service logic module and looks up the LLA program of the controltype. The service data module is addressed (via the reference table in the service administrator/customer) and the interpreter calls the controltype logic. If it is located externally, the required process data is sent along. The controltype logic takes over and will do whatever it is designed to do (i.e. it has access to all its service logic and data parameters, the process data and the communication channel). The results are returned to the interpreter which will look up the connection to the next SIB instance (if any logical outlet was returned) in the service logic module according to this result. Incoming events are looked up in the registered monitor requests and directed to the SIB’s which had requested the event (if any). The controltype logic of the SIB can then decide if interpretation should resume with another SIB or remain suspended. All internal controltype logic is implemented as LLA programs in the kernel, the engine is part of the LLA interpreter.

3.14.3

Service Database The service database in the kernel stores all service logic and data modules, service administrator records and service customer records. It is also responsible for consistent relations between all this data, even for service data located outside the kernel. With use of the subscription info, i.e. format and datatypes of all parameters, the database provides a common I/O interface for all controltypes.

126

Service Provisioning Subsystem (SES)

Physically the data might be distributed (external controltypes) but the database takes care of all direct operator communication. Service Logic administration. Commands are provided for definition, printing, interconnecting and removal of service logic modules. The function includes the administration of service logics (i.e. the SL part of a service script) and printing of service logic modules. Service Data administration. Commands are provided for definition, change, removal and printing of Service Data Modules. The function includes the administration of service data modules, i.e. the relation between service logic modules and service data modules. Service data modules can be connected and disconnected to/ from service logic modules by means of commands. These connections can be printed on request. Some operational characteristics of service data modules can be set by command. Service Administrator handling. Commands are provided for definition, printing and removal of Service Administrators. An SA can have Operational Service Logic and Not-Operational service logic, the connection and disconnection between SA and SL is set by command. Some operational characteristics of a SA can also be set by command. Service Customer handling. Commands are provided for definition and removal of service customers. These definitions are used at administration of service data modules. The number of service data modules which can be defined for a service customer can be changed after the service customer is defined. All service data modules defined for a service customer can be printed on request.

3.14.4

Testing of Service Scripts On service script level testing and changing of services is supported without disturbing the service processing on the original service script. Each service script can have two versions, one operating and one not-operating. The operating version is accessible for service processing, the not-operating access is only accessible from testcalls and any modification can be made to it by the operator. By switching the two a modified service is taken into operation and an operating service is taken out of operation. Service scripts can be tested in a not-operating version before they are made available for service processing (i.e. the network).

3.14.5

Error Handling Program errors in service scripts are trapped by a global error service script. Whenever the interpreter detects a program error in a service script (like address errors, looping, etc.) a global error service script is invoked. The error service script itself can be customized but it should always be available in the service database as standard exception handler.

127

IN 2.3 Service Testing Course

3.15 Controltypes The kernel is highly application independent, i.e. the specific coding of data, operations and events is all done by the controltypes and the SCF interface/external protocol adapter. The functionality of the controltypes and the external protocol/SSF determines more or less the type of services which can be implemented on the interpreter. For a complete description of all controltypes is referred to the Controltype Overview in the applicable supplementary description, only a short overview is given here. In the overview is referred to numbers and variables, both are process variables only of different datatypes, i.e. variables are integers and numbers are BCD-coded strings.

3.15.1

Basic Controltypes

• • • • •

Jump to service script specified by constant Jump to service script specified by variable Load service data module parameters to communication channel Load call data to communication channel Load characteristics of current service administrator to communication channel

• Load characteristics of new service administrator to communication channel

• • • • • • • • • • • • • •

128

Load user dialled digits to communication channel Branch on time of the day Branch on date Branch on day of the week Branch on register, i.e. general purpose process variable Branch on digit (part of number) Branch on subscriber class SCF based call gaping Call distribution Ongoing call limiter Uniform load distribution, type 1 Screen number against a list Number modification Generate response operation and release service process

Service Provisioning Subsystem (SES)

3.15.2

Basic Controltypes Set 2

• • • • • •

Jump to subroutine in another service script

• • • • • • • • • • • • • • • • • • • • • •

Compare two numbers, branch on result

Return from subroutine to original service script Looping control Return to start of loop Send a handover on the communication channel to other SCF Load return information for handover to communication channel, and return here after backward handover Check the charge limit Branch on variable direct Branch on variable, value used as index in branching list Branch on variable, according to list of predefined values Check if variable is available Compare two variables, branch on result Compare actual time to check time, branch on result Copy part of variable into another variable Copy variable into part of another variable Read number from indexed list Read integer from indexed list Read long integer from indexed list Modification of variables Merge two numbers to a new one Convert variable to number Convert two variables to a number Convert a number to a variable Ongoing call counter Relative timer Uniform load distribution, type 2 Change process state

129

IN 2.3 Service Testing Course

3.15.3

Basic Controltypes Set 3 This set of controltypes operates mainly on the connection model, which is a model of the calls and connections present in the SSF. The connection model is described in reference 4. They all generate operations except "Explicit event handling" which are sent to the SCF interface for passing on to the SSF. The results (if any) are monitored in the interpreter as events. The "Explicit event handling" controltype generates via SCFM an operation if the handled event is an event monitored in intercept mode.

• • • • • • • • 3.15.4

Explicit monitoring Explicit monitoring type 2 Create a leg Join two legs Disconnect leg(s) Split two connected legs, break speech path Explicit event handling Release resource

Number Analysis The number analysis controltype is used to obtain a new service script identity (a Service administrator reference) by analysing a number. The actual analysis table, where the numbers are defined, is the service data module of the SIB. The service data module is global data.

3.15.5

Extended Number Analysis This controltype is an extension of the previous one. The service data module can be global, service administrator or service customer specific. The analysis result can be a service administrator, a service customer reference or any integer process variable. Congestion control information (e.g. call gaping) can be included as information for the SSF, i.e. this information is not delivered to the service process but sent directly to the SSF when encountered in the analysis. The function can supervise the utilization of the analysis tables and take protective actions when the tables are misused (i.e. to many Number Analysis number mismatches).

3.15.6

Queuing The queuing controltype inserts calls in a queue when a call can not be handled (on basis of number of ongoing calls or available free lines). A call in a queue can either be a connected call, i.e. connected to a announcement device, or a network address to call back to. The queue parameters, the queue itself and queuing statistics are all service data. The same service data module can be connected to different service logic modules, i.e. the same queue can be operated from different places in a service script. The operation which is performed on the queue (i.e. the mode) is indicated in the service logic parameters of the SIB. For instance,

130

Service Provisioning Subsystem (SES)

insert call in queue if it can not be handled, pick up a call from the queue, read statistics, change available lines, etc.

3.15.7

Customer Control The customer control controltype allows the customer to change the service data of his service script from for instance a telephone set. The controltype has service data to describe the customer control procedures, i.e. which service data can be changed for a certain controltype and the procedure to fetch the new data. The procedure can be a subscriber procedure, i.e. voice prompts and digit reception, or process variables or constants can be used to set the new data. This is global service data and not connected in the conventional way to SIB’s of the CC controltype. The service logic data of a CC SIB points out a certain customer control case. This case identifies a SIB in a service script which has to be changed and for this SIB the CC procedure to change it.

3.15.8

Voice Prompting The voice prompting facility includes 5 different controltypes with different capabilities (some of them overlapping each other). Basically they cover sending of announcements and reception of digits. The parameters for announcement sending and control of digit reception are part of the service data. At execution of a SIB, the external controltype (block SSVP) sends the operations for voice prompting directly to the SCF interface (for transfer to the SSF) and registers the required monitors for events in the kernel.

3.15.9

External SDF Interface Two controltypes enable reading and writing to an external database, currently only TCAP is used to provide communication to external entities. All address information needed to address the information elements in the external database are stored in the service data module of the SIB. Upon execution of the SIB a new communication channel in the SCF interface is opened to get access to an external entity. The function is also involved at reception of unsolicited information (not requested by an explicit reading operation) from an external database. Upon reception of such a message in the SCF interface, the external database function is seized which in its turn will start the script interpreter with the appropriate script.

3.15.10

Statistic Counters There are several controltypes to maintain statistic counters, some event specific, some more general, which can be used as SIB’s in a service script. Apart from these conventional structured SIB’s the kernel supports the collection of SIB execution statistics. A statistics counter can be connected to any Service Data Module (SDM) of a service administrator/customer, which is stepped each time the SDM is accessed for execution. This function has no Service Logic Module (SLM), only an SDM which contains the counters. 131

IN 2.3 Service Testing Course

Output of statistics is done per service administrator or customer. This is triggered by either a SIB instance which samples the output by issuing a statistic report every nth time it is executed, or by a timequeue function. A service administrator/customer can be put in a timequeue for periodical statistic output. The blocks SSOUT and SSPRINT take care of queuing and sending the statistic records to the appropriate output device.

3.15.11

Reports The report controltype issues an output report of a specified set of process variables when this SIB is encountered in a service script and certain sampling conditions are fulfilled. The conditions and process variables are specified in the SDM of the SIB. Similar to the statistic function, a report SDM can be tied to a service administrator/customer and any SDM of this service administrator/customer can be marked as trigger for the report function. The kernel will inform the report function each time a SDM is accessed which is marked with a report trigger. The report function evaluates then the sampling criteria for output. The blocks SSOUT and SSPRINT take care of queuing and sending the report records to the appropriate output device.

3.15.12

Tables There are a number of controltypes using conversion tables to obtain a result which points out a logical outlet of the SLM. The type of input data in the table depends on the function of the controltype:

• Origin analysis on two digits, which uses two consecutive digits out of a number to determine the table entry.

• Origin analysis on three digits, which uses three consecutive digits out of a number to determine the table entry.

• Area number analysis, which uses the area number to determine the table entry.

• Branch on incoming route number, which uses the route origin of the incoming call to determine the table entry.

• Branch on daytype, which uses the current date to determine the table entry.

• Branch on timetype, which uses the current time to determine the table entry.

• Branch on integer, which uses an integer process variable to determine the table entry. All tables are global data modules, of which there can be several per controltype. For each table entry a result value is defined, which is not necessarily unique within the table.

132

Service Provisioning Subsystem (SES)

3.16 SCF Function Blocks 3.16.1

SSI SSI is part of the kernel and responsible for service script processing. It contains the database memory to allow fast access to service logic and service data modules, but is not responsible for the database and maintenance functions.

3.16.2

SST SST contains the external controltypes listed under tables.

3.16.3

SSINT SSINT contains the basic controltypes, which are mostly internal controltypes (except for JUMP). SSINT subscribes these controltypes to the kernel at restart.

3.16.4

SSINT2 SSINT2 contains basic controltypes set 2, which are all internal controltypes except the relative timer. SSINT2 subscribes these controltypes to the kernel at restart.

3.16.5

SSINT3 SSINT3 holds basic controltypes set 3, which are external controltypes (except for Explicit monitoring, Explicit monitoring type 2, Explicit event handling and Release resource).

3.16.6

SSINT4 SSINT4 contains the basic controltypes set 4, which are internal controltypes, except MANDM. SSINT4 will also support the INM interface, since it has a full command interface for the controltypes.

3.16.7

SSINT5 This block contains the basic controltypes set 5, containing MODSTR, NUM2STR and NR2NR. SSINT5 will also support the INM interface, since it has a full command interface for the controltypes.

3.16.8

SSIA SSIA is responsible for the administrative part of the kernel, that is, the database maintenance and allocation functions. It contains the service data reference tables and is responsible for the consistency of the database.

3.16.9

SSIEXT SSIEXT contains the subscription interface for controltypes to the kernel. It distributes part of the subscription data, the data which is needed during service processing, to SSI. Together with SSIA it forms the administrative part of the external controltype interface (that is administration of service data). 133

IN 2.3 Service Testing Course

3.16.10

SSINMIO The block SSINMIO handles the TCP/IP connections between SCF and SMAS. The block is responsible for establishing and closing connections and transferring messages. These actions are initiated by commands.

3.16.11

SSINMOX The block SSINMOX translates the incoming INM operations to actions on the SCF database.

3.16.12

SSIC1 SSIC1 contains the command interface for definition of service logic and service logic modules.

3.16.13

SSIC2 SSIC2 takes care of the printing commands for service logic and the removal of service logic. It is responsible for service logic registration and access.

3.16.14

SSIC3 SSIC3 contains the commands to define, connect, remove and print service administrators. It also holds some of the minor administrative commands for service administrators. Administration for service administrators is implemented here as well, for instance, registration of references to service administrators from other parts of the database.

3.16.15

SSIC4 SSIC4 contains the commands for definition and printing of service data. It is responsible for the administration of global service data modules.

3.16.16

SSIC5 SSIC5 contains the commands to define, remove and print service customers. Administration for service customers is implemented here as well, for instance, registration of references to service customers from other parts of the database and registration of the service customers.

3.16.17

SSIC6 SSIC6 contains the commands for definition, removal and printing of service data connections as well as the commands for manual setting of service data modules.

3.16.18

SSSTR SSSTR contains the report controltypes. Also the timequeue function for periodic reports and the interface to SSOUT are located in SSSTR.

134

Service Provisioning Subsystem (SES)

3.16.19

SSNAX SSNAX contains the extended number analysis controltype and the analysis tables.

3.16.20

SSOUT SSOUT handles the requests for output to file or printer from SSSTR, SSSTC and SSCC. It will generate an alarm if a fault occurs during output handling or if buffer congestion occurs in one of its users.

3.16.21

SSPRINT Requests for output to a printer are handed over to SSPRINT. SSPRINT takes care of the printout formatting and printing.

3.16.22

SSSTC SSSTC contains the actual controltypes which are subscribed by SSSTCA. Also the timequeue function for periodic statistic reports and the interface to SSOUT are located in SSSTC.

3.16.23

SSSTCA SSSTCA contains the subscription interface for the statistic controltypes.

3.16.24

SSCC1 SSCC1 contains the traffic part of the Service Script Customer Control function. Customer Control covers the facilities to offer a subscriber the possibility to enable or disable a service and to manipulate some part of its Service Data.

3.16.25

SSCC2 SSCC2 contains the administration of Change Code data modules and subscription of controltypes for customer control.

3.16.26

SCFSM SCFSM is the Session Manager, which handles the processes in the SCF. This means that it manages the relation between (multiple) dialogues and the service instance.

3.16.27

SCFDH SCFDH is the Data Handler, which handles the conversion of data between the different formats used for protocol operations and internal SCF data.

3.16.28

SSIQ SSIQ contains the queuing controltype and the data structures for storage of the queues.

135

IN 2.3 Service Testing Course

3.16.29

SSINAP SSINAP contains some controltypes used for sending INAP operations.

3.16.30

SSINAP2 SSINAP2 contains some internal controltypes used for sending INAP operations. The controltypes are: CHARLIM, RELCPC, RECON, HOLDCPC, RELEASE, COLLECT, CANCEL, CALLINF, EXMON3, CONTINU, and DIFCON.

3.16.31

SSCREAP SSCREAP contains the controltype NPROCES and the related Call Instance Data. SSCREAP handles the external traffic functions of the controltype, mainly the administration of the order queue where the requested new processes are stored. The new process will be triggered by SSCREAP at the desired start time.

3.16.32

SSUPRT SSUPRT handles the controltypes RETRIEV, UPDAT and DEFAPPL. These controltypes are used to read data from and write data to an external database or SDF, comprising a more flexible way of defining read/write applications. The controltype DEFAPPL can be used for defining and maintaining applications and the format belonging to them.

136

Service Provisioning Subsystem (SES)

3.17 Blocks Owning to Control Types. ___________________________________________________________ CTRTYPE BLOCK ----------------------------------------------------------------------------------------BRDIR

SSINT2

BRONIND

SSINT2

BRONINX

SSINT2

CALLDIS

SSINT

CALLGAP

SSINT

CALLINF

SSINAP2

CALLQUE

SSIQ

CANCEL

SSINAP2

CCPROC

SSCC2

CCTRAF

SSCC1

CHARDAT

SSINAP

CHARLIM

SSINAP2

CHARREP

SSINAP

CHSTATE

SSINT2

COLLECT

SSINAP2

COMPNUM

SSINT2

COMPVAR

SSINT2

CONNECT

SSINAP

CONTINU

SSINAP2

CREANUM

SSINT2

DATE

SSINT

DAYINW

SSINT

DAYTYPE

SST

DEFAPPL DELCID DIGIT DISFCON

SSUPRT SSINT4 SSINT SSINAP2

___________________________________________________________

137

IN 2.3 Service Testing Course

CTRTYPE BLOCK ----------------------------------------------------------------------------------------ENDLOOP ESTAT

SSINT2 SSSTC

EVENTH

SSINT3

EXMON3

SSINAP2

FILTER

SSINAP

GAPPING

SSINAP

GOSUB2

SSINT2

HANDOFF

SSINAP

HANDOV2

SSINAP2

HOLDCPC

SSINAP2

INFO INITCAL JUMP JUMPR LOADQD LOOP

SSINT SSINAP SSINT SSINT SSINT2 SSINT2

MANDM

SSINT4

MANREF

SSINT4

MODLONG

SSINT4

MODSTR

SSINT5

MODVAR

SSINT2

MSTAT NPROCES NPROT NRANAX NR2NR

SSSTC SSCREAP SSINT SSNAX SSINT5

NUMVAR

SSINT2

NUM2STR

SSINT5

ONGOING

SSINT2

___________________________________________________________

138

Service Provisioning Subsystem (SES)

CTRTYPE BLOCK ----------------------------------------------------------------------------------------ORG2

SST

ORG3

SST

PARSE

SSINT4

PARTIN

SSINT2

PARTOUT

SSINT2

PRESENT

SSINT2

RECON

SSINAP2

RELCPC

SSINAP2

RELEASE

SSINAP2

REPORT

SSSTR

REPTYPE

SSSTR

RESINT RESLINT RESNUM

SSINT2 SSINT2 SSINT2

RESTAB

SST

RETRIEV

SSUPRT

RETSUB

SSINT2

ROUTE

SST

RTIMER

SSINT2

SCREEN

SSINT

SIGINFO

SSINAP

SREPORT

SSSTR

SRFCONN

SSINAP

SSTAT

SSSTC

STARATT

SSSTC

STARTIM

SSSTC

TIME

SSINT

TIMECHK

SSINT2

TIMETYP

SST

___________________________________________________________

139

IN 2.3 Service Testing Course

CTRTYPE BLOCK ----------------------------------------------------------------------------------------ULD

SSINT

ULD2

SSINT2

UPDAT

140

SSUPRT

USERINT

SSINAP

VARNUM

SSINT2

VAR2NUM

SSINT2

XMODVAR

SSINT4

Service Provisioning Subsystem (SES)

3.18 Triggering The IN Service Trigger (IST) is a result of B-number analysis in TCS which, if present, indicates that the call is to be routed to the service switching function (SSF). The IST can take any value in the range 165535. It is forwarded to the SSF where it is used as index to the IN triggering tables in order to determine the correct data for further processing of the call, e.g. SCP address or Service Key.

3.18.1

Triggering Data Administration This section describes how the command handling blocks SSFTDA1 and SSFTDA2 (Service Switching Functions, Trigger Data Administration) are used for defining data for traffic routes and trigger tables used to access IN services located in the Service Control Function (SCF). Due to the number of commands, the SSFTDA block has been split into two blocks SSFTDA1 and SSFTDA2. Because of the logical connections between the commands in the two blocks, this section describes the operations performed using commands from both blocks. When a call needs IN access, the call is triggered in the network, which leads to selection of a traffic route in the SSFDCF block. SSFDCF receives its operational parameters from the command administration blocks SSFTDA1 and SSFTDA2.

SSFTDA1

SSFTDA2

SSFDCF

Figure 3.20

Command handing blocks.

Depending on the services defined in the SCF, various information must be obtained from the SSFDCF block. The routes must be defined regardless of whether the SCF controlling the IN service is located in the own or a remote exchange. Information about the data to be transferred between the SSF and the SCF must be defined, and the different routing possibilities must be set. All this is done with the commands given in blocks SSFTDA1 and SSFTDA2. Command SWTZI zeroes the entire non-operating area for IN service trigger analysis. This zeroing is done before specification of the IN service trigger data. Commands SWIPI and SWIPE open and end an IN Service Trigger (IST) procedure which other commands referring to a single IST in SSFDCF are given.

141

IN 2.3 Service Testing Course

Command SWIDI defines traffical default IST settings and must be specified for each IST. Command SWITI defines the invoke tables for each IST. The purpose of the invoke table is to define the parameters that should be sent to the SCF when a dialogue is opened (initiating or assisting SSF). Command SWRDI defines the routing tables for each IST. The routing tables are connected to Trigger Detection Points (TDP). The purpose of the data in the routing table is to ensure that the correct SCF and Service Logic Program is reached when a SCF is invoked. Command SWTDE deletes a specified TDP as well as all connected data, like the invoke table and route table specified with the SWITI and SWRDI commands. Command SWISE deletes IST data settings. The command can only be used to delete one IST at a time. The command SWTAI activates IST data. Command SWSDI defines the five types of destinations used when routing towards SCF. The destinations have to be defined before any references are made to them from the routing tables. Command SWSDE deletes a SCF destination of the type Destination Point Code (DPC) or Global Title (GT). The command will only be executed if no routing data (specified using command SWRDI) refers to the specific SCF destinations. Command SWSEC defines exchange data, or sets up default values for the three operation types, Initiate Call Attempt (ICA), Establish Temporary Connection (ETC), and Connect (CON). Operational Instruction IN Service Trigger Data, Initiate describes how the default values for the traffic route are established, and how the invoke parameters and routing data are defined and connected. Operational Instruction Exchange Data, Change describes how to change exchange data. Operational Instruction Destination Data, Change describes how to change destination data. Operational Instruction IN Service Trigger Data, Change describes how to change IN Service Trigger (IST) data. Operational Instruction Invoke Data, Change describes how to change Invoke data. Operational Instruction Routing Data, Change describes how to change Routing data. Operational Instruction Destination Data, End describes how to delete destination data. Operational Instruction Trigger Detection Point, End describes how to delete Trigger Detection Points (TDP). Operational Instruction IN Service Trigger, End describes how to delete an IN Service Trigger (IST).

3.18.2

Trigger Detection Points (TDP) The TDPs are armed using the information about what Triggers are active in the call and service. Once the TDPs applicable to the Service have been armed, the call progresses. Subsequently, the SSF will be informed by Basic Call Handling when a DP is encountered in the call. If the DP is armed as a TDP then the Triggering function is informed that a TDP has been encountered. The Triggering function then reads a row from another data Table (the TDP Table), the index to which it obtains from the requisite TDP entry in the IST To TDP Table. This TDP data holds an indication as to whether the SSF is to trigger the service as an Initiating SSF

142

Service Provisioning Subsystem (SES)

(send InitialDP INAP operation to the SCF) or as an Assisting SSF (send AssistRequestInstructions INAP operation to the SCF). See Appendix for a description of the Basic Call State Model (TDP values):

• • • • 3.18.3

Originating Incoming Call Leg State Model Originating Outgoing Call Leg State Model Terminating Incoming Call Leg State Model Terminating Outgoing Call Leg State Model.

IST Invoke Table The purpose of the Invoke Table is to define which parameters should be send to the SCF when a dialogue is opened (Initiating or Assisting SSF). Each parameter may be marked as: 0 = Not included, 1 = Included, 2 = Included if available. Due to the number of parameters it is not possible to set all parameters in one command line. If all parameters are required then several SWITI commands have to be used. The command must be given inside of the IN Service Trigger (IST) procedure. The Invoke Table is connected to a Detection Point identified by the TDP parameter.

3.18.4

IST Routing Table The purpose of the data in the Routing Table is to secure that the correct SCF and Service Logic Program are reached when a SCF is invoked. Data are initialized to the default values and can be changed using one of the three described command syntaxes. Only parameters given in the commands are changed. The command must be given inside an IST procedure. The command can be used to change data for an existing Routing Table. Please note that the parameter Service Key (SKEY) is a mandatory parameter when the SCF is invoked by an initiating SSF.

3.18.5

Creation of an (IST) table. This section describes the procedure to create an (IST) table. 1. Zero the Non Operating Area (NO): Use command SWTZI. Printout: COMMAND EXECUTED, 2. Copy the Operating Area (OP) to the NOP: Use command SWTCI. 3. Activate the IN Service Trigger (IST) procedure: Use command SWIPI. 4. Change the common area of the IST: Use command SWIDI. 5. Change the route table for the TDP within the IST: Use command SWRDI.

143

IN 2.3 Service Testing Course

6. Change the invoke table for the TDP within the IST: Use command SWITI. 7. End the procedure: Use the command SWIPE. 8. Switch Operating(OP) to the NOP: Use the command SWTAI 9. Verify the creation of the IST: Use the command SWISP. See Appendix. “IN Service Trigger Table” printout for a description of the parameter values.

144

Service Provisioning Subsystem (SES)

3.19 Appendix. IN Service Trigger Table SSF IN SERVICE TRIGGER DATA DATA PRINTED FROM THE [NON] OPERATING AREA IST ist / |ACAT BSI TOI TOTR |acat bsi toi totr | |BOTR CC TOP SHREQ |botr cc top shreq | |COTR RI TOS OBCAT |cotr ri tos obcat | |ROTR SEC TSC CHZTR |rotr sec tsc chztr | | PCIDU PSCFU | pcidu pscfu \ / | / |TDP |ROUTING |tdp |DATA | | | |GTMOD | |gtmod | | | |FDESTID1 FDESTID2 | |fdestid1 fdestid2 | | | |DESTREF1 DESTREF2 | |destref1 destref2 | | | |ODESTID GTNAPI | |odestid gtnapi | | | |PI DL | |pi dl | | | |SNS CUNS | |sns cuns | | | |SKEY | |skey | \ | | / | |INVOKE | |TABLE | | | |AGN CGCAT CPN | |agn cgcat cpn

\ | | | TAFINFO FWINDIC PSCF | tafinfo fwindic pscf | | CPAI SSFTYPE PCID | cpai ssftype pcid | | IMPAIND MPINDIC TSUS | impaind mpindic tsus | | ARIINF CCBSIND OTC | ariinf ccbsind otc | / \ \| || || || || || || GTNT GTTRAN || gtnt gttran || || CGC CESS || cgc cess || || CTMP NUMDIG || ctmp numdig || || SFC SCFR || sfc scfr || || ADP SSFS || adp ssfs || || || || /| | \| || || || EXT3 EXT4 EXT5 || ext3 ext4 ext5 || TACTR tactr

CHINDIC chindic

SSC ssc

145

IN 2.3 Service Testing Course | | | | | | | | | | | | | | | | | | | | | | | | | | |TDP |tdp | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

146

| |BCAP EVTYPE CGE |bcap evtype cge | |CDN EXT1 EXT2 |cdn ext1 ext2 | |EXT12 EXT13 EXT14 |ext12 ext13 ext14 | |EXT15 EXT16 FWCI |ext15 ext16 fwci | |SII CUGCI CUGIC |sii cugci cugic | |GNACON GNACPN GNARDN |gnacon gnacpn gnardn | |LANSEL IPAV RO |lansel ipav ro \ . . . . . . / |ROUTING |DATA | |GTMOD |gtmod | |FDESTID1 FDESTID2 |fdestid1 fdestid2 | |DESTREF1 DESTREF2 |destref1 destref2 | |ODESTID GTNAPI |odestid gtnapi | |PI DL |pi dl | |SNS CUNS |sns cuns | |SKEY |skey \ / |INVOKE |TABLE | |AGN CGCAT CPN |agn cgcat cpn | |BCAP EVTYPE CGE

EXT6 ext6 EXT9 ext9 HLC hlc OCN ocn GDPNTC gdpntc GNCDFN gncdfn

. . .

GTNT gtnt CGC cgc CTMP ctmp SFC sfc ADP adp

EXT3 ext3 EXT6

|| || || || EXT10 EXT11 || ext10 ext11 || || IPCAP LN || ipcap ln || || RDI RDN || rdi rdn || || GNACDN GDBCGID || gnacdn gdbcgid || || EXID GNAORCDN|| exid gnaorcdn|| || || || /| . . | . . | . . | \| || || || || || || GTTRAN || gttran || || CESS || cess || || NUMDIG || numdig || || SCFR || scfr || || SSFS || ssfs || || || || /| \| || || || EXT4 EXT5 || ext4 ext5 || || EXT7 EXT8 || EXT7 ext7

EXT8 ext8

Service Provisioning Subsystem (SES) | | | | | | | | | | | | | | | | | | | | \

|bcap | |CDN |cdn | |EXT12 |ext12 | |EXT15 |ext15 | |SII |sii | |GNACON |gnacon | |LANSEL |lansel \

evtype cge

ext6

ext7

ext8

|| || EXT1 EXT2 EXT9 EXT10 EXT11 || ext1 ext2 ext9 ext10 ext11 || || EXT13 EXT14 HLC IPCAP LN || ext13 ext14 hlc ipcap ln || || EXT16 FWCI OCN RDI RDN || ext16 fwci ocn rdi rdn || || CUGCI CUGIC GDPNTC GNACDN GDBCGID || cugci cugic gdpntc gnacdn gdbcgid || || GNACPN GNARDN GNCDFN EXID GNAORCDN|| gnacpn gnardn gncdfn exid gnaorcdn|| || IPAV RO || ipav ro || /| . / . .

IST ist / |ACAT BSI TOI TOTR |acat bsi toi totr | |BOTR CC TOP SHREQ |botr cc top shreq | |COTR RI TOS OBCAT |cotr ri tos obcat | |ROTR SEC TSC CHZTR |rotr sec tsc chztr | | PCIDU PSCFU | pcidu pscfu \ / | / |TDP |ROUTING |tdp |DATA | | | |GTMOD | |gtmod | | | |FDESTID1 FDESTID2 | |fdestid1 fdestid2 | | | |DESTREF1 DESTREF2 | |destref1 destref2 | | | |ODESTID GTNAPI | |odestid gtnapi

TACTR tactr

CHINDIC chindic

TAFINFO tafinfo

FWINDIC fwindic

CPAI cpai

SSFTYPE ssftype

IMPAIND impaind

MPINDIC mpindic

ARIINF ariinf

CCBSIND ccbsind

GTNT gtnt

GTTRAN gttran

CGC cgc

CESS cess

CTMP ctmp

NUMDIG numdig

\ | | | PSCF | pscf | | PCID | pcid | | TSUS | tsus | | OTC | otc | / \ \| || || || || || || || || || || || || || || SSC ssc

147

IN 2.3 Service Testing Course | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |TDP |tdp | | | | | | | | | | | | | |

148

| |PI DL |pi dl | |SNS CUNS |sns cuns | |SKEY |skey \ / |INVOKE |TABLE | |AGN CGCAT CPN |agn cgcat cpn | |BCAP EVTYPE CGE |bcap evtype cge | |CDN EXT1 EXT2 |cdn ext1 ext2 | |EXT12 EXT13 EXT14 |ext12 ext13 ext14 | |EXT15 EXT16 FWCI |ext15 ext16 fwci | |SII CUGCI CUGIC |sii cugci cugic | |GNACON GNACPN GNARDN |gnacon gnacpn gnardn | |LANSEL IPAV RO |lansel ipav ro \ . . . . . . / |ROUTING |DATA | |GTMOD |gtmod | |FDESTID1 FDESTID2 |fdestid1 fdestid2 | |DESTREF1 DESTREF2 |destref1 destref2 | |ODESTID GTNAPI |odestid gtnapi | |PI DL

SFC sfc ADP adp

EXT3 ext3 EXT6 ext6 EXT9 ext9 HLC hlc OCN ocn GDPNTC gdpntc GNCDFN gncdfn

. . .

GTNT gtnt CGC cgc CTMP ctmp SFC

|| || || || SSFS || ssfs || || || || /| \| || || || EXT4 EXT5 || ext4 ext5 || || EXT7 EXT8 || ext7 ext8 || || EXT10 EXT11 || ext10 ext11 || || IPCAP LN || ipcap ln || || RDI RDN || rdi rdn || || GNACDN GDBCGID || gnacdn gdbcgid || || EXID GNAORCDN|| exid gnaorcdn|| || || || /| . . | . . | . . | \| || || || || || || GTTRAN || gttran || || CESS || cess || || NUMDIG || numdig || || SCFR || SCFR scfr

Service Provisioning Subsystem (SES) | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | \

|pi | |SNS |sns | |SKEY |skey \ / |INVOKE |TABLE | |AGN |agn | |BCAP |bcap | |CDN |cdn | |EXT12 |ext12 | |EXT15 |ext15 | |SII |sii | |GNACON |gnacon | |LANSEL |lansel \

dl

sfc

CUNS cuns

ADP adp

CGCAT cgcat

CPN cpn

EXT3 ext3

EVTYPE CGE evtype cge

EXT6 ext6

EXT1 ext1

EXT2 ext2

EXT9 ext9

EXT13 ext13

EXT14 ext14

HLC hlc

EXT16 ext16

FWCI fwci

OCN ocn

CUGCI cugci

CUGIC cugic

GDPNTC gdpntc

GNACPN GNARDN GNCDFN gnacpn gnardn gncdfn IPAV ipav

RO ro

scfr

|| || SSFS || ssfs || || || || /| \| || || || EXT4 EXT5 || ext4 ext5 || || EXT7 EXT8 || ext7 ext8 || || EXT10 EXT11 || ext10 ext11 || || IPCAP LN || ipcap ln || || RDI RDN || rdi rdn || || GNACDN GDBCGID || gnacdn gdbcgid || || EXID GNAORCDN|| exid gnaorcdn|| || || || /| /

[NONE] [EOT DURING PRINTOUT] END acat

A-subscriber category

adp

Armed DP indicator When DP9 or DP17 is armed, this indicator specifies how DP9 or DP17 should be armed. 0

Not used

1

DP9 or DP17 armed on incoming leg

2

DP9 or DP17 armed on outgoing leg

149

IN 2.3 Service Testing Course

3

agn

ariinf

bcap

150

DP9 or DP17 armed on incoming and outgoing leg

Additional calling party number This parameter determines whether the additional calling party number should be included when the Service Control Function (SCF) is invoked. 0

Not included

1

Included

2

Included if available

AssistRequestInstruction INFormation Indicates how to fetch the CorrelationID and SCFID from the call setup message, if the SSF is an Assisting SSF. 0

Assisting SSF The CorrelationID and the SCFID can be received as separate parameters, or can be embedded in the called party number. The CorrelationID and the SCFID are both received in the generic number format.

1

Assisting SSF, user-to-user The CorrelationID and the SCFID are received embedded in the user-to-user information 1 parameter in the call setup message. The CorrelationID and the SCFID are both received in the generic digit format in the user-to-user information 1 parameter.

2

Assisting SSF The CorrelationID and the SCFID are received as separate parameters. CorrelationID is received in generic digit format. The SCFID is received in generic number format.

Bearer capability This parameter determines whether the bearer capability should be included when the SCF is invoked. 0

Not included

1

Included

Service Provisioning Subsystem (SES)

2 botr

bsi

cc

ccbsind

cdn

cess

Included if available

B-Number origin transferring This indicator determines whether the B-number origin should be transferred from the incoming side to the outgoing side. 0

No transferring allowed

1

Transferring allowed

Backward setup indicator During setup of an IN service, the BSI informs the incoming side about setup conditions. 0

No backward setup indicators used

1

Malicious call tracing if no calling party number is available

Charging case This is the charging case default value which can be transferred to the outgoing side. 0 - 4095

Charging case

NO

Charging case not used

Call completion on busy subscriber indicator This parameter indicates how to handle the CCBS service when the CCBS interacts with an IN service in the call too. 0

Unconditional suppression of CCBS

1

Conditional acceptance of CCBS CCBS is accepted if the incoming call to the SSF originates in the same exchange as the SSF

Called party number This parameter determines whether the called party number should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

SCF control essential This parameter specifies whether

151

IN 2.3 Service Testing Course calls in a stable phase are allowed to survive abnormal loss of the dialogue to the SCF.

cgc

cgcat

cge

chindic

152

0

Calls are not allowed to survive

1

Calls are allowed to survive

Call gap criteria 0

No call gap criteria

1

Called address value

2

Gap on service

3

Called address and service

4

Calling address and service

Calling party category This parameter determines whether the calling party category should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Call gap encountered This parameter determines whether the call gap encountered should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Charging indicator Default setting of charge no charge indicator in the ISUP message ANM This indicator must be applied in case the call is handled by basic routing. 0

No indication

1

No charge

2

Charge

Service Provisioning Subsystem (SES) chztr

cotr

cpai

cpn

ctmp

Charging zone transferring This indicator determines whether the business group charging zone and the private telecommunication network charging zone should be transferred from the incoming side to the outgoing side. 0

No transferring allowed

1

Transferring allowed

Charging origin transferring This indicator determines whether the charging origin should be transferred from the incoming side to the outgoing side. 0

No transferring allowed

1

Transferring allowed

Calling party address indicator This parameter is used to indicate whether the SCF provided calling party number is allowed to overwrite the calling party number received from the incoming side or to be transmitted as an additional calling party number 0

SCF provided calling party number overwrites calling party number received from incoming side.

1

Transmit SCF provided calling party number as additional calling party number

Calling party number This parameter determines whether the calling party number should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Call treatment missing required parameter This parameter is only valid in situations where it is not possible to invoke the SCF. 0

Release call

153

IN 2.3 Service Testing Course

1

cugci

cugic

cuns

Continue without SCF invocation

ClosedUserGroup call indicator This parameter determines whether the ClosedUserGroup call indicator should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

ClosedUserGroup interlock code This parameter determines whether the ClosedUserGroup interlock code should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Unsuccessful service invocation This parameter specifies whether calls are allowed to survive if it was not possible to perform service invocation. 0

Calls are not allowed to survive.

1

Calls are allowed to survive.

destref1

SCF destination reference Reference to SCF destination in case the SI parameter from the routing case specification is set to 0 or no SI parameter is given Used in case FDESTID1 is 1, 2, or 3

destref2

SCF destination reference Reference to SCF destination in case the SI parameter from the routing case specification is different from 0 Used in case FDESTID2 is 1, 2, or 3

dl

TCAP and SCCP dialogue level

154

0

Network default

1

Blue TCAP, Blue SCCP

Service Provisioning Subsystem (SES)

evtype

exid

ext1

ext2

ext3

2

White TCAP, Blue SCCP

3

White TCAP, White SCCP

Event type BCSM This parameter determines whether event type BCSM should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Exchange identity This parameter determines whether exchange identity should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Extension 1 This parameter determines whether extension 1 should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Extension 2 This parameter determines whether extension 2 should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Extension 3 This parameter determines whether extension 3 should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

155

IN 2.3 Service Testing Course

ext4

ext5

ext6

ext7

ext8

ext9

156

Extension 4 This parameter determines whether extension 4 should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Extension 5 This parameter determines whether extension 5 should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Extension 6 This parameter determines whether extension 6 should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Extension 7 This parameter determines whether extension 7 should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Extension 8 This parameter determines whether extension 8 should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Extension 9 This parameter determines whether

Service Provisioning Subsystem (SES) extension 9 should be included when the SCF is invoked.

ext10

ext11

ext12

ext13

ext14

0

Not included

1

Included

2

Included if available

Extension 10 This parameter determines whether extension 10 should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Extension 11 This parameter determines whether extension 11 should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Extension 12 This parameter determines whether extension 12 should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Extension 13 This parameter determines whether extension 13 should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Extension 14 This parameter determines whether extension 14 should be included when the SCF is invoked.

157

IN 2.3 Service Testing Course

ext15

ext16

fdestid1

fdestid2

158

0

Not included

1

Included

2

Included if available

Extension 15 This parameter determines whether extension 15 should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Extension 16 This parameter determines whether extension 16 should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Format of SCF address This format parameter is used in case the SI (sending information) parameter from the routing case specification is set to 0, or no SI parameter is given. 0

Local

1

Destination point code and subsystem number

2

Global title

3

Global title and subsystem number

4

Global title service number

5

Global title service number and subsystem number

6

SCFid as global title

7

SCFid as global title and subsystem number

Format of SCF address This format parameter is used in case the SI parameter from the routing case specification is different from 0.

Service Provisioning Subsystem (SES)

fwci

fwindic

gdbcgid

gdpntc

0

Local

1

Destination point code and subsystem number

2

Global title

3

Global title and subsystem number

4

Global title service number

5

Global title service number and subsystem number

6

SCFid as global title

7

SCFid as global title and subsystem number

Forward call indicators This parameter determines whether the forward call indicators should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Forwarding indicator This is an indicator used to specify whether the call on the outgoing leg should look like a forwarded call or not. 0

No forwarding

1

Forwarding

Business communication group ID This parameter determines whether the business communication group ID should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Private network travelling class mark This parameter determines whether the private network travelling class mark should be included when the SCF is invoked.

159

IN 2.3 Service Testing Course

gnacdn

gnacon

gnacpn

gnaorcdn

gnardn

160

0

Not included

1

Included

2

Included if available

Additional called number This parameter determines whether the additional called number should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Additional connected number This parameter determines whether the additional connected number should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Additional calling party number This parameter determines whether the additional calling party number should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Additional original called number This parameter determines whether the additional original called number should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Additional redirecting number This parameter determines whether the additional redirecting number should be included when the SCF is invoked.

Service Provisioning Subsystem (SES)

gncdfn

0

Not included

1

Included

2

Included if available

Called freephone number This parameter determines whether the called freephone number should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

gtmod

Global title service number modification Digits can be deleted, and a prefix can be added to the service number used as global title.

gtnapi

Global title number plan

gtnt

0

Reserved

1

ISDN/Telephony (E.164)

2

Data (X.121)

3-15

Spare

NO

Parameter is no longer valid

Global title nature of address Used in case format of SCF address is global title logical, SCFid, or global title service number. 0

Reserved

1

International Number

2

Unknown

3

Subscriber number

4

National Significant Number

5-10

Spare, standard use

11-15

Spare, standard use

NO

Parameter is no longer valid

161

IN 2.3 Service Testing Course gttran

hlc

impaind

ipav

ipcap

Translation type for global title This parameter is used in case format of SCF address is global title, SCFid, or global title service number. 0-254

Translation types

255

Reserved

High layer compatibility This parameter determines whether the high layer compatibility should be included when the SCF is invoked. 0

Included

1

Not included

2

Included if available

Implied A-number indicator This is an indicator used to specify whether the implied A-number shall be used in basic routing when no SCF or SSF provided A-number exists. 0

Do not use implied A-number

1

Use implied A-number

IPAvailable This parameter determines whether the IPAvailable should be included when the SCF is invoked. 0

Included

1

Not included

2

Included if available

IP SSP capabilities This parameter determines whether the IP SSP capabilities should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

ist

IN service trigger Current maximum value is defined by SAE 701.

lansel

Language selection This parameter determines whether the

162

Service Provisioning Subsystem (SES) language selection should be included when the SCF is invoked.

ln

mpindic

numdig

0

Not included

1

Included

2

Included if available

Location number This parameter determines whether the location number should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Meter pulse indicator This parameter indicates whether meter pulses should be transferred from the outgoing side to the incoming side. 0

Pass

1

Drop

Number of digits 0

Not relevant for TDP

1-28

Number of called party digits to collect for TDP2 match

obcat

Origin of B-category The parameter is used as the origin for B-category analysis, where it is decided whether certain B-subscriber services should be suppressed. OBCAT is used in the block SUA.

ocn

Original called party ID This parameter determines whether the original called party ID should be included when the SCF is invoked.

odestid

0

Not included

1

Included

2

Included if available

Format of own address 0

Local (SSCP)

163

IN 2.3 Service Testing Course 1

SPC + SSN

2

Global title

3

Global title + SSN

otc

Offline tariff class This parameter is only valid for the Spanish market. Used as default tariff class. Is inserted in the TT-record by the IN charging system.

pcid

Pointer to first digit of correlationID Pointer to the first digit of the correlationID in the called party number received in the call setup message in an assisting SSF.

pcidu

3-28

Pointer to first digit of correlationID. PCID must be greater than PSCF.

NO

PCID is not used. PSCF must also be NO if PCID = NO.

Pointer to first octet of correlationID Pointer to the first octet of the correlationID in the the user-to-user 1 information received in the call setup message in an assisting SSF. The correlationID is expected to be received in generic digit format. 3-28

Pointer to first octet of correlationID. PCIDU must be greater than PSCFU + 1.

NO

PCIDU is not used. PSCFU must also be NO if PCIDU = NO.

pi

Protocol identifier The protocol identifier is used to select the INAP protocol. For each IN service trigger only one charging executor may be pointed out by the PI’s. A charging executor must have subscribed to the protocol identifier. For a description of the values, see Application Information Service Switching Function Changeable Exchange Adaptation.

pscf

Pointer to first digit of SCFID Pointer to the first digit of the SCFID in the called party number received in the call setup message in an assisting SSF.

164

Service Provisioning Subsystem (SES)

pscfu

rdi

rdn

2-27

Pointer to first digit of SCFID. PSCF must be less than PCID.

NO

PSCF is not used. PCID must also be NO if PSCF = NO.

Pointer to first octet of SCFID Pointer to the first octet of the SCFID in the user-to-user 1 information received in the call setup message in an assisting SSF. The SCFID is expected to be received in generic digit format. 1-26

Pointer to first digit of SCFID. PSCFU must be less than PCIDU - 1.

NO

PSCFU is not used. PCIDU must also be NO if PSCFU = NO.

Redirection information This parameter determines whether the redirection information should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

Redirection party ID This parameter determines whether the redirection party ID should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

ri

Route index This parameter is used to select the route used for routing the call.

ro

Route origin This parameter determines whether the route origin should be included when the SCF is invoked. 0

Not included

1

Included

165

IN 2.3 Service Testing Course 2 rotr

scfr

sec

sfc

shreq

166

Included if available

Route origin transferring This indicator determines whether the route origin should be transferred from the incoming side to the outgoing side. 0

No transferring allowed

1

Transferring allowed

SCF simulation handling 1

Normal (No simulation)

2

Simulation

3

Message logging

4

Simulation with pretty print

5

Message logging with pretty print

6

Service logic tracing

7

Service logic tracing and message logging

8

Service logic tracing and message logging with pretty print

Selection case This parameter indicates which type of CLSM is supported for this call to an IN identifier. 0

Originating CLSM

1

Terminating CLSM

Service filtering criteria 0

No Service filtering analysis

1

Service filtering analysis

Soft or hard request Indicates whether a soft or hard request is to be used to fetch the calling party number and calling party category. If number or category are not available, in own exchange, a hard request will initiate a request backward in the network. A soft request will NOT initiate a request backward.

Service Provisioning Subsystem (SES)

sii

0

Hard request

1

Soft request

Service interaction indicators This parameter determines whether the service interaction indicators should be included when the SCF is invoked. 0

Not included

1

Included

2

Included if available

skey

Service key

sns

Service number selection

ssc

0

No service number (SN) specified

1

Called party number used as SN

2

Calling party number used as SN

3

Redirecting number used as SN

Signalling system capability This parameter indicates whether the signalling system is capable of transferring correlationID and SCFID in the call setup message between an initiating SSF and an assisting SSF. 0

SCFID and correlationID transferred in separate parameters in generic number format

1

SCFID and correlationID transferred embedded in the B-number in generic number format and as separate parameters in generic number format

2

SCFID and correlationID are transferred as part of the ISUP user-to-user information 1 parameter in generic digit format

3

SCFID and correlationID are sent as separate parameters.

167

IN 2.3 Service Testing Course CorrelationID is sent in generic digit format. SCFID is sent in generic number format ssfs

ssftype

tactr

tafinfo

SSF simulation handling 1

Normal (No simulation)

3

Message logging

5

Message logging with pretty print

SSF type This parameter indicates which SSF type will be used when the SCF is invoked. 0

Initiating SSF

1

Assisting SSF

Traffic activity code transferring This indicator determines whether the traffic activity code should be transferred from the incoming side to the outgoing side. 0

No transferring allowed

1

Transferring allowed

Tariff information This parameter indicates whether tariff and tariff indicator should be transferred from the outgoing side to the incoming side. 0

Pass in any case

1

Drop in any case

tdp

Trigger detection point identifier This parameter identifies to which detection point (DP) the invoke table is connected.

toi

Type of indicator The type of indicator contains detailed information for the type of seizure parameter. For a description of the values, see Application Information Traffic Activity Code (4/155 18-ATP 210 11 Uen.).

top

Type of procedure The type of procedure contains detailed information for the type of seizure parameter. For a description of the values, see

168

Service Provisioning Subsystem (SES) Application Information Traffic Activity Code (4/155 18-ATP 210 11 Uen.). tos

Type of seizure The type of seizure indicates a function family group. For a description of the values, see Application Information Traffic Activity Code (4/155 18-ATP 210 11 Uen.).

totr

Timesupervision origin transferring This indicator determines whether the timesupervision origin should be transferred from the incoming side to the outgoing side. 0

No transferring allowed

1

Transferring allowed

tsc

Type of telecommunication service This parameter is used to identify the telecommunication service code. For a description of the values, see Application Information Traffic Activity Code (4/155 18-ATP 210 11 Uen.).

tsus

This parameter contains basic call= related information in order to control the timer for network initiated suspend in the SSP node.

EOT DURING PRINTOUT The operator has cancelled the printout NONE No data is to be printed Function This printout is received as an answer printout to command SWISP, and lists the above mentioned parameters for IN service trigger identifiers specified in the command. The second line in the printout specifies if the values printed are from the operating or non operating area, as specified by the SWISP command. Printout Type Answer printout Printout Block SSFTDA1

169

IN 2.3 Service Testing Course

3.20 Appendix. Description of SSF interfacing APT Subsystems Group Switching Subsystem (GSS) The Group Switching Subsystem (GSS) performs switching between time multiplexed buses and sets up paths between telecommunications devices. It also provides timing signals for its own synchronisation and for network synchronisation. The GSS consists of both hardware and software, and it works with other subsystems to switch calls of different types between subscribers - for example local, trunk and transit calls. The GSS functions are to:

• Select, connect and disconnect speech or signal paths through the Group Switch.

• • • •

Supervise disturbance in the hardware. Supervise the traffic. Supervise the PCM links to the Group Switch Maintain a stable clock frequency. This clock frequency is used for synchronisation in the Group Switch, and can also be used to synchronise the network.

Charging Subsystem (CHS) Charging is a key function since it is the means of translating network traffic into revenue and cost. It is essential that accurate and detailed charging data is available for billing and statistical purposes. Within AXE, charging and accounting are controlled by the Charging Subsystem (CHS) which is responsible for:

• Basic Charging Function - CHS provides the data to charge subscribers for their calls.

• Accounting - CHS provides the data to settle accounts between cooperating network operators (national or international)

• Additional Services - these services are in addition to ‘normal’ call charging. For example, the charging for user-to-user data transfer in signalling messages sent over the D-channel. Traffic Control Subsystem (TCS) The Traffic Control Subsystem (TCS) is the central traffic control subsystem in AXE. TCS consists of software only. The main TCS functions are divided into:

• Basic Core Functions, including basic call set-up, call supervision and release, and storing of subscriber categories.

170

Service Provisioning Subsystem (SES)

• Analysis Functions, including B-number, A-number and analysis to determine which ISDN service is requested.

• Administrative Functions, performs administration tasks associated with the Analysis functions. For example, they include the commands for changing, handling and printing data in the B-number analysis tables in the DA block.

• Service Functions, including semi-permanent connections and Trunk offering which allows the operator to get into speech position with a busy subscriber to offer an incoming call. Common Channel Signalling Subsystem (CCS) The Common Channel Signalling Subsystem (CCS) contains both hardware and software. Its main function is to handle CCS7 signalling. CCS7 speeds up call set-up time and improves trunk efficiency by sending the signalling information for numerous speech circuits on a few highspeed signalling links. CCS7provides the signalling backbone for IN.

Operation and Maintenance Subsystem (OMS) An AXE exchange is provided with operation and maintenance functions that guarantee a high quality of service OMS is implemented in central and regional software, as well as some hardware. The main OMS functions are:

• Supervision, which continually supervises the trunk and subscriber lines. if a fault or a disturbance is detected, an alarm is generated.

• Test and Fault Localisation, this contains diagnostic and test functions, which are used in conjunction with alarms and reports to localise faults, both internal and external to the exchange.

• Administration, enables exchange personal to change exchange data, connect and disconnect subscribers and services.

• Statistics, is used for measurement and printout of data such as the volume and type of traffic flowing through the exchange. This information is important for the planning and configuration of exchanges. Statistics and Traffic Measurement Subsystem (STS) The Statistics and Traffic Measurement Subsystem (STS) collects, stores, process and presents measurement data (statistics) on, for example, traffic flow and network performance. STS is implemented in the Support Processor (SP) but belongs to the APT system. STS consists of software only The following operations are performed by STS:

• Counters in the traffic system are read and data collected at specific intervals.

• The values of these counters are stored in a measurement database. 171

IN 2.3 Service Testing Course

• At defined intervals report programs read data form the measurement database and produce easy-to-read reports for network management/ exchange personnel.

172

Service Provisioning Subsystem (SES)

3.21 Module Summary • SES is divided into two functional elements, 1. Service Switching Function (SSF) 2. Service Control Function (SCF).

• The SSF provides the set of capabilities required for interaction between the Call Control Function (CCF) and the Service Control Function (SCF) in order to access and process services for subscribers in an Intelligent Network.

• The Service Control function controls the processing of IN services. It contains the service programs, which constitutes the IN services, and provides for the execution of these.

• The IN Service Trigger (IST) is a result of B-number analysis in TCS which, if present, indicates that the call is to be routed to the service switching function (SSF).

• Trigger Detection Points are points in the basic call process where an IN service could be invoked, starting by sending the operation InitialDP.

• Dialogue Control controls how dialogues are initiated, maintained, closed and coordinated by SSF to the SCF.

• IN Call Control is responsible for the interface to the call processing functions of the exchange.

173

IN 2.3 Service Testing Course

3.22 Abbreviations AD BCD BCSM CID CS1 CS1+ CTRTYPE DM ETSI FE HD ID IN INAP INM INPM IOG IP ISDN LLA MCS NCRD OCS PHF SA SC SCF SCEF SDF SDFD SES SIB SDM SL SLM SLP SLPI SMAS SMF SDF SRF SSCP SSF SSP SSI TCAP

174

Assisting Dialogue Binary Coded Decimal Basic Call State Model Call Instance Data Capability Set Ericsson superset of CS1 Control type Data Module European Telecommunications Standards Institute Functional Entity Handoff Dialogue Initiating Dialogue Intelligent Network IN Application Protocol IN Management interface IN Protocol Manager Input Output Group Intelligent Peripheral Integrated Services Digital Network Low Level Action Man-machine Communication Subsystem Non Call Related Dialogue Open Communications Subsystem Protocol Handler Function Service Administrator Service Customer Service Control Function Service Creation Environment Function Service Data Function SDF Dialogue SErvice provision Subsystem Service Independent Building Block Service Data Module Service Logic Service Logic Module Service Logic Program Service Logic Program Instance Service Management Application System Service Management Function Service Data Function Specialized Resources Function Service Switching and Control Point Service Switching Function Service Switching Point Service Script Interpreter Transaction Capabilities Application Part

BAT, SAT and NIT

4. BAT, SAT and NIT

4.1 Introduction IN services are currently tested in several phases. According to MIND (Method for IN service Development), three test phases can be distinguished: 1

Basic Test

2

Service Application Test (= Function test in MEDAX and TSE)

3

Network Integration Test (= System Test in MEDAX and TSE)

This module is a description of the test phases, the scope of each phase, the activities to perform in each phase, the documents to use and write per activity and the entry and exit criteria for each activity. The descriptions from the MEDAX and TSE process can be used to extend the descriptions in this module.

Module Objectives After completing this module the participants will be able to: • Explain the aims of BAT, SAT and NIT • Understand the work procedure for SAT and NIT • Describe the role, activities and tools associated with IN Service Testing • Apply acquired skills and knowledge in IN Service testing

Figure 4.1

Module objectives

4.2 Test Phases 4.2.1

Product Structure An IN service roughly consists of 3 parts:

• Service Functionality (SF) • Service Management System (SMS, also referred to as SAM) • User Inwindowation (UI) The complete Service Functionality can be divided into a number of features. Each feature is implemented by one or more Service Script Logics.

175

IN 2.3 Service Testing Course

Up till now a number of different Service Management Systems have been developed: SAMTool and a management system based on APT windows. A third way is to enter data through SMAS. At this moment two new management systems are being developed: one based on Powerbuilder (SMABase) and a WWW interface based on Java. All types of management systems can be divided into a number of ‘components’: a (Graphical) User Interface, a database, a transaction handler, and so on. The Service Functionality and the Service Management System are delivered to the customer with, at least, the following mandatory User Inwindowation objects:

• A Service Overview, describing the service from a functional point of view.

• A User’s Guide, describing the use of the SMS. • A System Administrator’s Guide, containing instructions for installing the SF and the SMS. It seems obvious that all delivered products are thoroughly tested before they are delivered to the customer.

4.2.2

Test Levels and Phases As mentioned in section 1.1 on page 1, MIND distinguishes 3 separate test phases. The first phase, called Basic Test, falls within the responsibility of the designer, while the other two test phases fall within the responsibility of the testers. When a designer has implemented the code, he must perform a quality check on the implemented code. The check is referred to as a Basic Test. Although you can argue whether this check should be called a Basic Test, a review or a quality check, throughout this module it will be called a Basic Test. Reason is that Basic Test is a common term that is also used in the standard MEDAX and TSE process. The Basic Test can be divided in two phases:

• A test of the separate blocks of implemented code. • A test of the interaction between blocks of code making up one product. The first phase means for SF that all SSLs are deskchecked. For the SMS the separate ‘components’ are tested. For example, the windows are tested separately; no interaction with other windows are tested. The separate User Information objects are reviewed. During the second phase of the Basic Test, the interaction between features (SF), ‘components’ of the SMS, and produced customer documentation (UI) is tested. At the end of this phase the complete service functionality, the complete service management system, and the documentation is tested as three, more or less, independent parts. After the Basic Test is completed the separate parts (SF, SMS and UI) are combined to be tested. The SF and the SMS are tested together, either on a real or a simulated STP. The SMS and the UI is also tested in combination. 176

BAT, SAT and NIT

For this test SMAS can run in simulated mode. Finally the SF and the UI is tested in combination. This complete test phase is called the Service Application Test (SAT), also known as Function Test (FT) in MEDAX and TSE. The last step is the Network Integration Test, where SF, the SMS and UI are tested as a complete product in the network. In this phase the focus is on performance of the service in the network, but also on the interaction of the service with other services in the network.

Basic Test Basic Test

¨

SF

SMS

UI

¦

SF SF SF

SAM SAM SMS

SAM SAM UI

SF

SMS

Service Application Test (Function Test)

Network Integration Test (System Test)

SF

UI

SMS

UI

Network SF SMS

UI

Figure 4.2

Test Phases

MIND, Method for IN service Development The purpose of MIND is to serve as the common Ericsson method for Service Application (SA) product development projects. The scope has been to focus on the technical view of SA product development, creating a common base by defining activities and documents created in a SA development project. It is important to note that MIND is for internal Ericsson use only. The MIND flow chart and documents can be found on http://mind.ni.ericsson.se 177

IN 2.3 Service Testing Course

http://mind.ni.ericsson.se

Figure 4.3

MIND 2.0

4.3 Basic Test The primary purpose of the Basic Test is to improve software quality and humanware quality. The Basic Test should detect and eliminate defects as early as possible in the software and humanware life-cycle. Code is checked for conformance to requirements, completeness, consistency and overall correctness. The focus is error detection, rather than correction.

178

BAT, SAT and NIT

The Basic Test is mainly performed by manual source code checking. There are three main methods for performing manual code checking. In each case, the used method depends on the complexity of the code. 1

Desk Check/Code Reading - One or more software engineers (other than the author) independently reviews the code. A checklist is used to ensure consistency. The results are documented in an inspection survey and record. If a Desk Test Checklist exists, it can be substituted for the inspection record. Feedback is given directly to the author or at a meeting.

2

Code Walk-through - A review meeting is hosted and moderated by the author. The emphasis is on error detection and the format is flexible. The participants prepare by reading the code and looking for errors. The results are documented in an inspection survey and record.

3

Code Inspection - A formal and rigorous inspection process in which defect detection, defect elimination, and correction verification is carried out by a small group during the development life cycle. Code inspections use checklists, preparation, well-defined roles, and continual process improvement to maximize error-detection efficiency. The results are documented in an inspection survey and record.

Basic Test execution consists of two phases. In phase 1 individual blocks of implemented code are tested. This phase is called ‘Unit Test’. The second phase focuses on the interface between different blocks of code. This phase is referred to as ‘Integration test’. It is important to implement the EST, Emulator Service Test on each Service Design Centre (SDC). The emulator will make the Basic Test much more efficient and a lot of faults would be detected much earlier in the Service Development procedure. That would mean that prototyping would be an important part of the design flow. A Basic Test must be performed on all new and modified code. Code that may be affected by modifications must also be basic tested. The elements to test should be described in a checklist. Preferably, this checklist must be generic, in order to re-use it in each project. Faults found during the Basic Test should be reported in the Basic Test Record. After the designer has corrected the fault(s), a new Basic Test must be performed on the modified code. The modified parts must be identified and re-tested. The designers are responsible for the complete Basic Test.

4.3.1

Entry Criteria BAT phase 1 The following input is required to start the Basic Test Phase 1: •

The Design Specifications (SSD, AAS, UIS) must be approved.

•

Checklists for executing a Basic Test must be available.

179

IN 2.3 Service Testing Course

•

4.3.2

Approved Service Requirement Specification (SRS).

Basic Test SF - Phase 1 During phase 1 of the Basic Test for SF, the designer/programmer should manually check the code (SSLs) by using one of the above described methods. The procedure to use will be decided by the project team during the feasibility study. The desk check and review focus on the implementation of one SSL. The integration between SSLs is not formally tested. This is within the scope of the second phase of the Basic Test. Aspects to consider when desk checking and reviewing a SSL, are: •

Are the correct register numbers used?

•

Are the correct data types used?

•

Is each variable assigned a value before it is used?

•

Are all outlets handled correctly?

•

Is the design efficient in terms of SIBs and CDMs?

The test is performed by deskchecking the Service Script Description (SSD) and the Service Function Specifications (SFS). What to check is specified in a checklist. A Basic Application Test Report, BATR, should be prepared including both test cases and the result of them. Each feature should be tested with the Red Line Trace tool. The BATR should be used as input when preparing the SAT test specifications.

4.3.3

Basic Test SMS - Phase 1 During phase 1 of the Basic Test for SMS, the designer/programmer tests the implemented code. This can be, for example, one window, a procedure, a function or a class. The test concentrates on an isolated block of code. The integration between blocks of code is not formally tested. This is within the scope of the second phase of the Basic Test. Aspects to consider when desk checking and reviewing a procedure, function, script or class, are:

180

•

How does this correspond to the customer needs and wishes?

•

Are the Design Rules and Guidelines followed?

•

Is the implementation according to the Design Specification?

•

Is the program divided in suitable parts for readability and maintenance?

•

Is the received input used?

BAT, SAT and NIT

•

Is the right output generated?

The test can be performed by desk checking and reviewing the implemented code or by compiling the code and then executing the compiled code. Testing the windows of a Graphical User Interface can be split in two parts: •

Coverage Test

•

Compliance Test

•

Usability Test,

During the coverage test, the designer/programmer starts of by systematically running through as many actions, i.e. menu selections, button push, tick box, etc., as possible. The compliance test consists of using a checklist to verify that the Graphical User Interface (GUI) complies to given guidelines. The usability test verifies if the GUI meets the Usability Goals which have been defined in the feasibility study. During phase 1 of the Basic Test SMS, the following areas should be covered when testing each separate window: •

Does the window conform to the SMS Design Rules?

•

Do fields on the window behave in the right way (minimum and maximum value, length)?

•

Do buttons and menu options react in the right way?

•

Is help text available for every field? Is the text complete and correct?

•

Configuration and set-up files should be deskchecked.

The test can be performed by deskchecking and/or executing the implemented code. A checklist specifies the elements to be checked. Such a checklist must be made for every component of the management system. The checklist must be generic, to enable re-use.

4.3.4

Basic Test UI - Phase 1 During phase 1 of the Basic Test for UI, the information designer and representatives of the SF and SMS groups review the different customer documents. The scope of this test phase is to check whether the information in the documentation is correct and complete and whether the documentation conforms to the Design Rules and Guidelines.

181

IN 2.3 Service Testing Course

Access to the management system will help when reviewing the documentation. However, access to the management system is not required. Aspects to consider when desk checking and reviewing the customer documentation, are: •

Are the UI Design Rules and Guidelines followed?

•

Is the implementation in accordance with the UIS?

•

Are descriptions correct (review by SF and SMS)?

•

Do the field characteristics comply with SMS specifications?

A checklist must be made stating the aspects to review. The checklist must be made as generic as possible, to enable re-use. Review remarks are indicated on the checklist or in an inspection record. The information designer is responsible for updating the documentation. After the update, the updated parts should be reviewed once more.

4.3.5

Exit Criteria The following exit criteria must be met to finalize the Basic Test Phase 1:

4.3.6

•

All new and modified code must have been basic tested.

•

All ‘testcases’, as listed in the checklist, must be passed.

Basic Test - Phase 2 To support a structured integration test, a test specification containing all test cases must be available. A detailed Test Instruction is not required for this test phase. UI

SF Feature_1

Feature_2

SSL

User Information Objects

SSL

SSL SSL

SSL

SMS

UG SAG

Component ‘GUI’ window

EUI

window window User’s Guide On-Line

Complete SF

Complete UI

Figure 4.4

Sub-phases for SF and SMS Integration test 182

Complete SMS

Component ‘Transaction Handler’ Procedure Function Class

BAT, SAT and NIT

4.3.7

Entry Criteria The following input is required to start the Basic Test Phase 2:

4.3.8

•

Basic Test environment and tools must be established and verified.

•

The Design Specifications (SSD, AAS, UIS) must be approved.

•

Approved Test Specifications for executing phase 2 of the Basic Test must be available.

Basic Test SF - Phase 2 The second phase of the Basic Test will verify that interfaces between components are correct and that the components interact according to the design. This test phase is typically carried out in steps, where increasingly larger components are integrated. First, all SSLs making up one feature are combined to be tested. Then all features making up one service are combined to be tested. This test focuses on whether the service is executing a call in the right way, meaning that the right flow is followed through the features. However, note that the scope of this test is limited to some major functional flows. Not all possible flows are expected to be tested. The Red Line Trace should be used for this test phase. By defining a number of different subscriptions and specifying input data, it can easily be tested whether the right sequence is followed. Blocking faults in the service and/or in one of the features can be discovered in this way. Testing of the feature should focus on all major functional flows. To ensure a structured performance of the Integration Test, a Test Specification must be available (included in the BATR), stating all test cases to be executed.

4.3.9

Basic Test SMS - Phase 2 Phase 2 of the Basic Test for SMS focuses on the interaction between different software blocks. All procedures, classes, functions, windows forming a complete Service Management System should be integrated tested. Testing components consisting of procedures, functions and/or classes should focus on: •

Usability goals fulfilled?

•

Are the Design Rules and Guidelines followed?

•

Is the implementation of the component according to the Design Specification?

•

Is the right input received from either a procedure/class/function or another component?

183

IN 2.3 Service Testing Course

•

Is the right output generated by the component?

The test can be performed by compiling the code and then executing the compiled code. The test of the (Graphical) User Interface should focus on: •

Consistent lay-out and behaviour of the windows

•

Data correctly inherited from other windows

•

User-friendly and easy-to-use management system

•

Help-text consistent and helpful

To test the GUI, a User Information designer should be involved to check the GUI on user-friendliness, consistency and ease-of-use. The way all components should behave is described in the design specification. This specification can be used as input for the test cases, specified in the Test Specification.

4.3.10

Basic Test UI - Phase 2 Phase 2 of the Basic Test for User Information consists of a review of consistency between the User Information Objects. The User Information Objects are also checked to ensure correctness, completeness and consistency. A generic checklist must be created for this purpose. Aspects to focus on when desk checking and reviewing the customer documentation are:

4.3.11

•

Usability goals fulfilled?

•

The customer’s needs and demands fulfilled?

•

Are the UI Design Rules and Guidelines followed?

•

Is the structure of the documentation clear?

•

Are the typography and lay-out consistent throughout all documents?

•

Are illustrations consistent throughout all documents?

Exit Criteria The following exit criteria must be met to finalize the Basic Test Phase 2:

184

•

All new and modified code must be basic tested.

•

All testcases, as mentioned in the Test Specification, must be passed.

•

Basic Test Report must have been prepared.

BAT, SAT and NIT

4.4 Service Application Test The Service Application Test (SAT) is the first test phase where all SF, SAM and UI components in the Service Application are integrated and tested as a full product. The focus for SAT is to verify the Service Application against the requirements according to what is stated in the Service Requirement Specification The service application test shall include:

• Functionality requirement tests • Verification of the complete service, using all the Service Application components.

• Performance requirement tests • Verification of service user loading time • Call execution time (when needed amount of HW is available, otherwise performed in NIT)

• Number of calls/sec (when needed amount of HW is available, otherwise performed in NIT) Service Application Test is where functionality is verified from the user’s point of view. That means that it tries out if the Test Object really does what it is intended to do and comprises good usability. Verification of robustness against user related mistakes and external faults is also included here. More concrete, the Service Application Test focuses on the interaction between SF and the SMS, the SMS and UI and, last but not least, SF and UI. During the SAT/FT all requirements as specified in the SRS and possible Change Requests, must be verified. Whenever possible, capacity tests are also within the scope of the Service Application Test. However, if capacity tests cannot be executed it this test phase, they will be moved to the Network Integration Test. In the Service Application Test every detected fault generates a Trouble Report. Formal Trouble Reports must always be written in order to get a correct statistical evaluation of the project and confirm that no detected faults are dropped. Trouble Reports are written in TRtool. The complete Service Application Test is the responsibility of the testers.

4.4.1

SF-SMS Test For the SF-SMS Test, the SMS is used to enter data that is needed to execute the service. When the data is defined, calls can be set up to test the service functionality. The User Information is used as a help for the testers; the documentation is not formally tested. The SF-SMS test is executed on a either a real STP or a simulated one (Simulated Function Test), where calls can be made. This test is mainly a requirement based test, meaning that all SF requirements must be tested. A Test Specification and a Test Instruction are used 185

IN 2.3 Service Testing Course

to ensure a structured and controlled way of testing. Testing of the SMS requirements is done in the SMS-UI test. For the SF-SMS test extensive knowledge of the service is required. It is recommended that the SF-SMS testers are involved in phase 2 of the Basic Test for SF. The testers can then get a good view of the structure of the service.

4.4.2

SMS-UI Test The SMS-UI test can be divided in two parts: testing the SMS requirements and testing the UI requirements. The SMS requirements are tested here and not in the SF-SMS test, because most test cases for the SMS can be executed without the use of an STP. All SMS requirements are tested on their correct implementation and whether data entered in the SMS is sent to the correct data modules in SMAS. Testing the usability of the SMS is also within the scope of the SMS-UI Test. Besides the SMS requirements, the UI requirements are tested on their correct implementation and the relation between the SMS and the documentation is tested: does the documentation exactly describe how the SMS works. Aspects of the documentation to be tested are: •

Are the step-by-step instructions in the documentation correct and complete?

•

Are all functions of the SMS described in the documentation?

•

Does the text, in combination with the illustrations, give all information needed to use the SMS?

•

Is the reader guided through the documentation in the right way?

The SMS-UI test is executed with SMAS in simulated mode. A Test Specification and a Test Instruction are used to ensure a structured and controlled way of testing. The SMS-UI test must be performed by the Service Application Testers. The testers must have knowledge strategies to test user interfaces.

4.4.3

SF-UI Test The SF-UI test mainly concerns the installation instructions of SF: do the installation instructions exactly describe how the SF can be installed. To test this, the step-by-step instructions must be strictly followed. A Test Specification and a Test Instruction are used to ensure a structured and controlled way of testing. The SF-UI test must be performed by the Service Application Testers. They do not need to have service specific knowledge. As the installation instruc-

186

BAT, SAT and NIT

tions are written for an audience with knowledge of Unix and SMAS, the testers are expected to have this knowledge too. Test environment The tests can be performed in different environments, and without access to the complete network environment. The AXE test environment must be equipped with:

• Proper software generation according to Service Requirement Specification (SRS). A software generation, dump, which is maintained either as a Product Line dump or as an AS containing the proper generation of the IN software. Which software generation that is required shall be stated in the SRS. It must be stated if the Service Application requires specific corrections or specific products.

• Limited hardware For the SAT, only limited hardware shall be required. The tests ought to be able to perform in a single node, unless the Service Application requires more than one node. The basic hardware setup implies service access using either LIC or BL. Entry Criteria The following input is required to start the Service Application Test: •

Approved Service Application Test Plan

•

Service Application Test environment must be established and verified.

•

Approved Service Application Test Specifications and Test Instructions must be available.

•

All Basic Test cases must be passed.

•

Deviation Descriptions and Product Revision Information must be available.

Exit Criteria The following exit criteria must be met to finalize the Service Application Test: •

All errors found are reported.

•

All testcases, as mentioned in the Test Specification, must be passed.

•

Input to Service Application Test Report has been provided.

187

IN 2.3 Service Testing Course

4.4.4

Service Application Test procedure

SRS

TER

Project Spec.

SAT Planning

SRS AFS UFS

SATP SAT Specification

SATS TOL

SAT Preparation

SAT Instruction

SATI

SAT Execution SA product Installation Instructions SF Installation Instruction SAM

Documents updated

Test Report

SATR

Figure 4.5

SAT test procedure

188

BAT, SAT and NIT

Test Planning Within this activity, the basis for Service Application Test (SAT) is defined. This implies descriptions of tools to be used (for example simulator/emulator), test reports to be written and personnel required for testing. An analysis is made of the requirements and other preconditions which will affect the scope of SAT. In addition to the Service Requirement Specification (SRS), check the general test aspects that have been considered in the TEchnical Report (TER) during the prestudy phase. To plan for SAT, a number of issues have to be considered:

• Test analysis giving the scope of test, estimation of man-hours for test design and execution, estimate time and resources for Test Configuration Management (TCM), specify if tests are excluded and subjects for special attention. Note: Should some performance tests not be possible to execute in SAT due to HW limitations, this must be communicated to the Network Integration Test (NIT) test as early as possible!

• Initial TCM activities including test plant booking where requirements on AXE SW, AXE HW, SMAS environment and other environments must be specified. This is a critical activity which must be initiated as early as possible in order to get access to a testsite with the proper setup.

• Test decision where the object is to: - Decide the scope of the tests that are to be performed. - Approve the cost estimate for the tests. Input Service Requirement Specification, SRS TEchnical Report, TER Project information Output Service Application Test Plan, SATP

SAT Specification The purpose of the Service Application Test Specification (SATS) activity is:

• To give an overview of the test environment, necessary equipment, test tools and their usage.

• Specify the test configuration and indicate if any deviations from a standard SAT configuration are required. The way to perform each test case defined in the SAT plan shall be described and compiled into a SAT Specification where each test case is numbered. A test case is one of the following categories: 189

IN 2.3 Service Testing Course

• Requirement based test to verify behaviour and performance as stated in the requirements.

• Design based test to verify changes made to the SF, SAM and UI parts not related to any requirement.

• Miscellaneous test to verify aspects not covered in requirement based or design based tests, e.g. user friendliness. In addition to the Service Application Test Specification (SATS), a Test Object List (TOL) used for checking the progress during test execution should be created. The TOL is a matrix with each test case against all relevant information for that test case. Input Service Application Test Plan, SATP Service Requirement Specification, SRS Service Function Specification, SFS Administration Function Specification, AFS User information Function Specification, UFS Output Service Application Test Specification, SATS Test Object List, TOL

SAT Instruction The purpose of a Service Application Test Instruction (SATI) is to give a detailed, step-by-step description of how each test case should be executed, and the expected result of each action. Depending on the complexity, several SAT instructions may be created. Each SAT instruction should also contain information about the test environment, part of the exchange configuration involved, and manual preparations or modifications needed. All modifications must be restored after the test. Input Service Application Test Specification, SATS Test Object List, TOL Output Service Application Test Instructions, SATI For an example of what the content list of a SATI would look like se figure 1.6, figure 1.7. shows an example of a test case layout according to MIND:

190

BAT, SAT and NIT

Freephone Contents 1 Preparations 1.1 Test Environment 1.2 Data for loading of Freephone 1.3 Data for removal of Freephone 2 Requirement-Based tests 2.1 Ordinary calls (Successful calls) 2.2 Ordinary calls (Unsuccessful calls) 2.3 Modification calls (Successful calls) 2.4 Modification calls (Unsuccessful calls) 2.5 Call for access to other services (Successful calls) 3 Design based tests 3.1 Normal user reactions 3.2 Abnormal user reactions 4 References

Figure 4.6

SATI content list example

191

IN 2.3 Service Testing Course

2.1.1 Successful call - connection to 800011 Make sure that 800011 will be chosen by the load distribution function. Calls from one of the A-numbers 1-4. ACTION: Dial the access number for the service 30 12345678. RESULT: The phone with the number 800011 rings. ACTION: Answer the phone and check that you are in speech position. RESULT: Speech path okey. ACTION: Onhook all phones and check that no devices are hanging: > TOBJI:ALL; RESULT: No devices are hanging. COMMENT: -

Figure 4.7

A Test case example

SAT Preparation The objective of Service Application Test (SAT) preparation is to setup the test plants in accordance with the SAT plan. This includes AXE, SAMservers, workstations, and other HW needed in addition to the standard setup. The setup should be conducted using correct versions of AXE software and SMAS. Exchange data should be loaded (and modified if necessary), parameter corrections and service related corrections should be loaded. All test tools specified shall be made available. Before the preparation is ready, the basics shall be verified, for example by making some test calls. Input Service Application Test Specification, SATS Service Application Test Plan, SATP Output Test site ready for execution

192

BAT, SAT and NIT

SAT Execution During test execution, the progress should be monitored by the Test Manager, who also reports to the main project. Operative decisions concerning the test execution are made by the Test leader. Please note that it is not only the functions and characteristics of the service that should be tested, but also instructions such as Installation Instructions. The exchange data files should be stored and a Service Application Test Report should be written. When the SA product has passed the service application test and all product documents have been updated, they are stored in GASK. It is important that experiences and opportunities for improvement are identified and described before the SAT execution activity is finished. Input SA product Installation Instructions, II (SF) Installation Instructions, II (SMS) Service Application Test Instructions, SATI Test Object List, TOL Service Application Test Plan, SATP Output Service Application Test Report, SATR

193

IN 2.3 Service Testing Course

4.5 Network Integration Test The Network Integration Test is the first test phase where all network components are integrated. The focus of the Network Integration Test is to verify the Service Application against the requirements regarding how the SA shall operate in the network. The test is parted up into five parts:

• Network Interaction Tests - Verifies the SA traffical interaction with concerned networks (PLMN, PSTN, ISDN etc.), nodes (PABX:s, VMS etc.) and IP:s.

• Service Interaction Tests - Verifies the SA interaction with Basic Services (Fax,SMS,Data etc.) in cooperating networks / nodes / IP:s. - Verifies the SA interaction with supplementary services (Call Forwarding etc.) in the concerned nodes/networks. - Verifies the SA interaction with other IN-services.

• Charging Tests - Verifies that charging is handled correctly from a network perspective, that the Toll Ticket is generated in the correct node in the network. - This test verifies that correct information is output to the ticket by investigating the interaction with Billing-IPs e.g. BGW, BIP, TIMS etc.

• Negative Tests - Verify the SA behaviour during network congestion, node restarts, overload situations etc.

• Stability Test - Verify the SA stability by applying a normal traffic load to the service for a number of days. The service execution should be stable and without faults during the complete time period. Note: The tests mentioned above shall be performed to verify the requirements from a network perspective on the SA, that is, the network requirements on the SA must be stated in the SRS. The NIT focuses on verifying the complete service product: SF, SAM and UI. For BN the NIT is usually performed by the Operations department of ETM. For BR the NIT is performed by EPK. Network Environment The NIT must be performed in a complete network environment. Two scenarios exist: 1.

194

The NIT is performed for an SA product, to verify that it will function in a number of general networks / network nodes. This can be PSTN (fixed) and/or PLMN (mobile). The SA shall also be verified towards “standard” voice-mail systems, billing interfaces and so on. The networks / network nodes included in the test setup is decided by analysing the potential customer networks. The purpose of this NIT is to ensure that the SA network interaction requirements are fulfilled when interacting with the included networks / network nodes. The result of these tests can be used when

BAT, SAT and NIT

selling the SA. 2.

The NIT is performed as a system test, to verify that the SA functions as required in a specific customer network. The test environment (trunk interfaces, parameter settings etc.) must be set-up as close as possible to the customer network. If a NIT of the first type has already been performed this NIT will only verify customer specific interaction requirements not included in the first NIT.

The NIT must be performed with the proper software generation in every network node included in the test configuration. The NIT is only applicable for one software generation network configuration. Entry Criteria The following input is required to start the Network Integration Test: •

Approved Network Integration Test Plan

•

Network Integration Test environment must be established and verified.

•

Approved Network Integration Test Specifications must be available.

•

All Service Application Test cases must be passed.

•

Deviation Descriptions and Product Revision Information must be available.

•

All Trouble Reports from previous test phases are corrected or have proven workarounds

•

All preliminary User Documentation

Exit Criteria The following exit criteria must be met to finalize the Network Integration Test: •

All errors found are reported.

•

All testcases, as mentioned in the Network Integration Test Specification, must be passed.

•

Input to Network Integration Test Report has been provided.

195

IN 2.3 Service Testing Course

4.5.1

Network Integration Test procedure The procedure used for NIT activities is shown in the flow chart below. SRS

Network Plan

Service Documentation

Proj. Info.

Test Analysis Service Products

Test Decision

Exchange Data Specification

Test Planning

SA Delivery Analysis & Application System Spec.

Test Analysis Report Minutes of Meeting

Exchange Data Specification

Test Plan

SA Delivery Analysis Report

Test Specification Test Specification TOL

STP Preparation

NIT Entry Decision

Minutes of meeting H-module Preparation

NIT Execution NIT Exit Decision

Document Update

Minutes of meeting H-module

Test Reporting

H-module test Test Report

Service AS Release

Evaluation of NIT Activities Service AS in PRA

Figure 4.8

NIT test procedure

196

Evaluation Summary

BAT, SAT and NIT

Test Analysis The Test Analysis is performed to analyse the technical scope of the planned NIT. The amount of work required to perform a test according to this scope is also analysed. A suggested test environment including all necessary network components to perform the test with the required quality should be defined on block level. Technical assistance from System Experts should be available to analyse certain complicated issues. The Test Leader should focus on the technical issues. The Project Manager should focus on project related issues like the estimation of man-hours and risks. Input documents:

• A Network Plan of the target network. This plan should indicate the nodes and networks cooperating with the IN service. The interface used towards these nodes and networks should also be stated. If a customer specific Network Plan is unavailable a general network configuration should be used.

• A Service Requirement Specification with a number of requirements affecting network interaction.

• Project information stating the requirements on the NIT test period like required quality, auxiliary networks included by strategic reasons etc.

• Previous Test Analysis Reports, NIT Evaluation summaries and Minutes of the Test Decision Meetings from other test projects should be used as a source of information. The Test Analysis Report, which is the output of the Test Analysis, must state the following:

• A list of all included test cases. This list should be made with headings according to the standard list of test categories for NIT (Network Interaction, Service Interaction, Charging, Negative and Stability tests). If possible, priorities shall be defined for the test cases, at least in two levels: high priority and low priority. If available a reference to the relevant network interaction requirement should be stated together with each test case.

• Estimate required man-hours for the activities during the following test period (The activities are; Test planning, Test Specification, Exchange Data Specification, STP preparation and NIT execution). The manhours shall be calculated using information accumulated from previous test projects (x man-hours per test case).

• Excluded tests should be explicitly stated together with the reason why they where excluded ("excluded tests" means tests that are included in the normal scope of NIT but are not included in this particular test project).

• Indicate risks and opportunities that have been found during the analysis.

197

IN 2.3 Service Testing Course

Test Planning The Test Planning can be divided into three sections: test, TCM and quality. It is performed to allocate the necessary STP resources for the NIT, plan the test execution, plan the TCM activities and also to outline quality considerations. The Test Plan for the NIT shall be prepared by the Project Manager and the TCM responsible in cooperation. As input to the Test planning the following should be used:

• The Test Analysis Report. This document should indicate the various network components needed in a suitable STP environment.

• Project Quality Plan. This document will outline the quality requirements for the project. The objective of the Test planning is:

• To describe all components included in the test plant. This is normally the first activity to perform. It is a critical activity since test plants are normally heavily booked. SW and HW may have to be purchased / rented and this has to be planned well in advance. When booking, a number of test requirements must be taken into account like: - AXE SW and HW requirements. - SMAS SW and HW requirements. - Other Network component requirements (PABX, BGW, VMS etc.) - The number of test phones (mobile, fixed). - The number of AT terminals. - A-law or u-law speech coding. - Test position and tools like UNIX applications, FIOL, PlexView, DocView etc. - Other test tools like TURBO-7 signalling generator.

• Book the required STP configuration. • To state the SW level for the included nodes in the test plant. • To plan the test execution phase. This should be in the form of a time plan and routines to follow for e.g. trouble shooting.

• To state the NIT test organisation and the procedures for test execution. The objective of the TCM planning is:

• To describe the generation handling procedures to follow. This allows the introduction of changes to the test environment in an organised and traceable way. Items described should be how to use the Log-Book, how to handle emergency corrections and how to handle product updates. Handling and labelling of the AXE-dumps, SMAS-dump etc. should also be described.

• To state how trouble reporting shall be handled e.g. by using MHS. If MHS is used, state TR-identities etc.

198

BAT, SAT and NIT

The objective of the Quality planing phase is:

• To outline the goals that must be achieved. • To outline the strategies deployed to achieve these goals. • To implement a procedure for the measurement of these goals. The Test Plan document, which is created during the Test planning phase, will be used as a guide for all activities during the test execution phase and as input data for the STP setup activity.

Test Specification The way to perform each test case defined in the Test Analysis shall be described and compiled into a Test Specification. Each Test Case shall be numbered. A Test Object List (TOL) used for checking the progress during test execution should also be created. The TOL is a matrix with each test case against all relevant information for that test case. The input to the Test Specification should be:

• The Test Analysis Report. The objective of the Test Specification activity is:

• As an overview specify necessary equipment, telephones, numbers to be used, service-profile etc.

• For each test case to describe how the test shall be executed step-bystep. The result for each action must be stated.

• Finally to create a Test Object List.

199

IN 2.3 Service Testing Course

Figure 4.9

NIT Specification 200

BAT, SAT and NIT

Exchange Data Specification The Exchange Data Specification activity is performed in order to create a document describing the service oriented exchange data. The document shall define the exchange data and parameters needed to get the SA operational in the network included in the NIT scope. This may cover data changes in i.e. the SSP, MSC, PABX and other nodes. The following items should be handled in the document:

• Exchange data to get the service in operation. This will include service triggering data, valid subscriber categories, B-no. analysis data, charging data etc.

• Parameter corrections needed to support charging etc. • Service related corrections needed in the SSP or in the other network nodes. STP Preparation The goal of this activity is to setup the System Test Plant (STP) according to the network configuration described in the Test Plan. The exchange data for the service should be setup using the Exchange Data Specification.

• The setup of each node should be done with the relevant AXE software release (according to the Test plan). The basic exchange data should be loaded and on top of this the service related exchange data. Parameter corrections and service related corrections necessary for the service should be loaded.

• When the STP preparations are finalised the TCM responsible should be informed about the configuration of each node. The software backup, a software record and the exchange data files should all be stored according to the routines stated in the Test Plan. Note that a SMAS backup without any service should also be stored. Note: This "starting point reference" including all nodes in the setup is very important to produce in order to have a stable "fall-back" during test execution. All experience shows that this is really needed in the complex testing environment that the NIT concept creates. SA Delivery Analysis and Application System Specification The Application System Specification will take place as part of the NIT, the procedure involves registering the service application system and related documentation in PRIM. The SA Delivery Analysis is performed in order to verify that a complete delivery has been received from the design department. As a result of the analysis a short summary should be written describing the state of the delivery. A number of items should be checked:

• Verify that all service products have been delivered and that these products are in a released state.

• Verify that all applicable SA documentation to install, test, deliver and

201

IN 2.3 Service Testing Course

maintain the service is delivered and in a released state. Network Integration Test Execution During this phase of the project the NIT testing will be executed. The NIT shall include Network Interaction tests, Service Interaction tests and Charging tests, Negative tests and Stability tests unless otherwise stated as excluded in the Test Analysis Report. The tests will be carried out according to procedures outlined in the test plan. The Test Object List (TOL) will be updated throughout the test execution phase. H-Module Preparation The H-Module is a binder containing all information related to the installation of a service product. The binder should contain:

• Installation Test Specification. • Demonstration Test Specification. • Acceptance Test Specification. All the above documentation will ensure that the service product can be installed and made operational in a customer site. The Demonstration and Acceptance Test Specification outlines the procedure to get the service product operational. The H-Module may be part of the customer documentation package.

Test Report This document should be completed by the testleader and approved by the project manager. It should describe the results of the NIT in detail and may contain information like:

• • • • •

Test Object Test Result List of failed Test Cases (with explanation). Completed Test Object list (TOL). List of Service related corrections.

H-Module Test The Installation, Demonstration and Acceptance Test Specifications should be fully tested to ensure the service can be made fully operational on delivery to the customer site as quickly as possible. In order to complete these tests correctly it is necessary to execute a complete maiden installation of the Service Application within the test configuration.

202

BAT, SAT and NIT

Service Application System Release The NIT execution phase is now complete. The Service AS is now fully tested with all relevant documentation updated and reviewed. The Service AS is now ready for delivery. The Service AS may now be released with all documentation complete and approved. The service product may be market specific and as such will be released as PRA. It will then become part of a First Office Application (FOA) or Delta delivery. In this situation the Industrialisation activity is not complete as the Service Delivery procedure is also the responsibility of the Industrialisation project, this procedure will be described in the next section. The service product may also be a general product for "off the shelf" sales. In which case the Industrialisation project activities are now complete. Some parts of the NIT may need to be repeated for this product under market conditions when they are known but this is not always the case. Evaluation of NIT Activities All personnel will be involved in this phase of the project. They will each be responsible for submitting their opinions on how the project could have been improved, new test tools or better procedures perhaps. This Evaluation summary should also contain statistical information about the project resources, man-hours, STP and test cases for example. This information will allow for better planning in future projects and will give statistical output on time periods involved for projects.

203

IN 2.3 Service Testing Course

4.6 Delivery Procedure The procedure used for Delivery activities is shown in the flow chart below. Each activity will be described separately in the following chapters Service AS in PRA/PRB

Customer Package

Installation

Installation Test

Acceptance

Yes

Service AS in PRB ? No

FOA Support

Handover to PLM

Figure 4.10

Delivery procedure

4.6.1

General For a Delta or FOA delivery the installation and initial market support are part of the Industrialisation procedure. A Delta delivery is the customisation of an existing product for re-release in a new market application. This is due to the fact that the NIT was performed as a system test to verify the SA functions for a specific customer network. Parts of the NIT may then need to be repeated in the future should the service product be sold in a different market environment.

4.6.2

Customer Package This process customises a service product for a specific customer market. Each customer will have different requirements and these must be taken into consideration when the service product is being delivered. Some cus-

204

BAT, SAT and NIT

tomers will require assistance with network configuration, they may require all the service product documentation whereas other customers may not.

4.6.3

Installation Using the Installation Instruction as prepared for the H-Module the service product is loaded into the customer network. Any modifications to the customer network will be completed to ensure the service product will function correctly. Details and decisions regarding the installation will take place between the project manager, testleader and customer representatives. Before the installation all relevant documentation as specified in the customer requirements will be given to the customer for inspection.

4.6.4

Installation Test This test is completed after the installation. The entry criteria are:

• • • • •

Correct HW and SW generations available H-Module Relevant Docview and Plexview Network information Service product information

The installation test activity is performed according to the test plan and the exit criteria are:

• All tests are completed and signed off • A summary of all trouble reports, their classifications and status must exist The project manager and the test leader are responsible to ensure the entry and exit criteria are met.

4.6.5

Acceptance This phase uses the Demonstration and Acceptance test specifications from the H-Module. The service product is verified in the customer network using a small cross section of test cases from the NIT. The network configuration and exchange data may need to be modified for these tests to be completed. Any service or market parameter corrections will also be loaded at this time.

4.6.6

First Office Application (FOA) support After the acceptance is complete the NIT team (or part thereof) will be responsible for the support of the product until the status changes to PRB. The product is then handed over to PLM and the NIT responsibilities are finally complete.

205

IN 2.3 Service Testing Course

4.7 Module Summary An IN service roughly consists of 3 parts:

• Service Functionality (SF) • Service Management System (SMS (SAM)) • User Inwindowation (UI) The table below shows the test phases, the type of document that describes the tests to be executed and the way to handle Trouble Reports.

206

Test Phase

Document

Trouble Reports

Remarks

Basic Test - Phase 1

Checklist

Checklist

Basic Test - Phase 2

Test Specification

SCN Tool

SF: Use Red Line Trace

Service Application Test

Test Specification and Test Instruction

TR Tool

SF-SMS: test on STP or use emulator

Network Integration Test

Test Specification

TR Tool

BAT, SAT and NIT

Glossary

AAS

Administrative Application Specification

BAT

Basic Test; the first test phase, performed by designers/programmers

BGW

Billing Gateway

FOA

First Office Application

IP

Information Provider

ISDN

Integrated Services Digital Network

GUI

Graphical User Interface

MEDAX

Method products for AXE 10 Development and Maintenance

MIND

Method for IN service Development

NIT

Network Integration Test; called System Test in MEDAX and TSE.

PABX

Private Automatic Branch Exchange

PSTN

Public Switched Telephone Network

PLMN

Public Land Mobile Network

SA

Service Application

SAT

Service Application Test; called Function Test in MEDAX and TSE.

SCNTool An Ericsson tool used to register fault found during phase 2 of the Basic Test. SDC

Service Design Centre

SF

Service Functionality; the implemented service logic in SMAS.

SFS

Service Function Specification

SMABase A new SMS, developed for the fixed market (BN), based on Powerbuilder. SMAS

Service Management Application System; the application used to implemented the service logic. 207

IN 2.3 Service Testing Course

208

SMS

Service Management System; the user interface implemented on top of SMAS for entering subscription data.

SRS

Service Requirement Specification

SSD

Service Script Description

SSL

Service Script Logic

STP

System Test Plant

TCM

Test Configuration Management

TER

Technical Report

TOL

Test Object List

TRTool

An Ericsson tool to register trouble reports.

TSE

TMOS development Support Environment

UI

User Inwindowation

UIS

User Information Specification

VMS

Virtual Memory System

IN Charging

5. IN Charging

5.1 Introduction 5.1.1

Objectives To Network Operators, Charging is the most important function of any network. There is little point in providing services to customers unless these services can be charged in order to generate revenue. For Intelligent Networks, charging is even more important, as the raison d’etre of IN services is to generate additional revenue. Furthermore, IN services require more flexible and innovative charging methods than that traditionally used for Plain Old Telephony Services (POTS).

ModuleObjectives After completing this module the participants will be able to: • Describe how charging takes place in AXE • Explain the typical information fields in a TT record • Describe the Control Types that influence charging • Explain the Procedures and Operation flows involved with charging. Figure 5.1

Module Objectives

In this module, we will review how charging takes place in an AXE exchange, and explain some of the more typical information fields contained in a TT (Toll-Ticket) record. We will then examine how charging takes place in an Intelligent Network, including the roles of the SCP and SSP in charging. We will examine the Control Types associated with charging, and the procedures and operation flows used by these to influence the charging function.

5.1.2

Charging Methods There are two different ways of recording charging information in an AXE exchange: Pulse Metering and Toll Ticketing. In any particular instance either or both of these methods may be employed. Pulse Metering

209

IN 2.3 Service Testing Course

Pulse metering is the oldest method of automatically recording charging information. It is based on the old electro-mechanical equipment where electrical pulses were generated which stepped an electro-mechanical meter. The rate at which the pulses were generated determined the tariff for the call: the more frequent the pulses, the more expensive the tariff. In AXE, the meter for local subscribers is simply a “counter” unique to that subscriber which is incremented for each “pulse”. The AXE can also send these pulses on to other network elements such as subordinate exchanges, pay-phones and customers equipment. Toll Ticketing For each call charged using the TT method, the exchange collects different types of information. This information includes the A-number, the Bnumber, call start time, call length and outgoing route. This data is collected in a function block, CDR (Charging Data Recording) in CHS. When the call is terminated, the function block TT organises output of the data onto the I/O system. Normally the TT data is stored on hard disk and then dumped manually to magnetic tape or transmitted automatically to a billing centre over data links.

Billing centre

Magnetic tape Information about calls

Computer

FMS CDR

TT

Hard Disk

Bills

Figure 5.2

Toll Ticketing

5.1.3

Charging Architecture There are two ways in which Charging analysis can be performed in AXE Local 4.1.

210

IN Charging

XSS

ISOMAM

IUSAM

Charging Administration

FOAM

Charging

CHS

APSI RMP Generic Charging Service

System Platform

APZ

Figure 5.3

Charging Architecture

For PSTN, old ISDN, BGS and BGC calls and services, the initial charging analysis (i.e. Charging Case and Charging Program) is performed in the CHS (Charging Subsystem) within XSS. This is basically the same as the charging analysis in non-AM architecture (e.g. AXE Local 3). Further charging analysis (i.e. Tariff Class, Switching Class and Tariff) is carried out by CHSS (Charging Services Subsystem) within the RMP (Resource Module Platform). In non-AM architecture, the same analysis is performed in CHS. For ISDN-E (Ericsson ETSI ISDN implementation) calls, charging analysis may be carried out within the ISUAM (ISDN User Services Application Module). Basic Call charging for ISDN-E can be carried out either in XSS or ISUAM (depending on an application specific parameter), but service charging analysis for ISDN-E is always carried out in ISUAM. This kind of analysis is not available in non_AM architecture.

211

IN 2.3 Service Testing Course

5.1.4

IN Call Models For IN calls, charging can be applied to each of the legs of the call. The incoming leg will be charged as appropriate depending on the whether the call is an ISDN-E call or not. The outgoing leg, however, will always be charged using CHS charging.

CHOOR

CHOOR

CHMON

TCS

SSF

CHMON

TCS

B

A

Figure 5.4

Non-AM Environment

In a non-AM environment, all charging is carried out in subsystem CHS. The charging data is defined in the same way as described for non-ISDN-E charging for both legs of the IN Call.

CHOOR A

CHMON

MAIN VIEW CHS1

CHOOR

TCS

SSF

SUBVIEW

SUBVIEW

IN1

IN2

CHMON

TCS

B

MAIN VIEW CHS2

Figure 5.5

AM Environment - XSS Originating

In the AM environment, the incoming leg is charged in the same way as if the call was a non-IN call. The outgoing leg will be charged using CHS. Figures 5.5 above shows the call model for a call with charging for the incoming leg being done in CHS (e.g. PSTN, old ISDN caller).

212

IN Charging

CHOOR

IUSAM

MAIN VIEW IUSAM

DJI

TCS

SSF

SUBVIEW

SUBVIEW

IN1

IN2

CHMON

TCS

B

MAIN VIEW CHS2

Figure 5.6

AM Environment - ISUAM Originating

Fig 5.6 shows the call model for calls with charging for the incoming leg being done in ISUAM (e.g. an ISDN-E caller). Note that charging for the outgoing leg is done in CHS.

213

IN 2.3 Service Testing Course

5.2 Charging Data Fig 5.7 below shows the various data tables associated with charging in an AM - Architecture. Only the tables associated with “call” charging are shown.

CHS (XSS) B-No Analysis

Traffic Activity Dependant Charging Case Data (CHISP)

Charging Case Data (CIBSP)

ISDN-E Charging Call Branching Condition Data (ICBSP)

IUSAM

ISDN-E Charging Call Charging Program Data (ICASP)

Figure 5.7

Call Charging Data - AM Architecture

214

Extended Chrg. Data (CHESP) Charging Prog Data (CIPSP)

Tariff Class Data (CHCSP)

Tariff Data (CHTSP)

Switching Class Data (CHSSP)

CHSS (RMP)

IN Charging

5.2.1

Call Charging (non-ISDN-E) The data tables for non-ISDN-E call charging is shown in fig 5.8 below:

B-No Analysis

CC

CO, Extended Chrg. TSC ACO, Data (CHESP) VPN, Traffic Activity CC EAE etc. CHP Dependant Charging Prog Charging Case Charging Case Data (CIPSP) Data (CHISP) Data (CIBSP)

TC

Tariff Class T Data (CHCSP)

Tariff Data (CHTSP)

SWC Switching Class Data (CHSSP)

Figure 5.8

Non-ISDN-E Call Charging

The main input into the charging analysis is a Charging Case (CC). Normally CC is specified in B-Number Analysis, but may also be specified from the IN functions. Essentially, the Charging Case depends on the destination of the call (e.g. Country and Area codes part of the B-Number).

215

IN 2.3 Service Testing Course

Traffic Activity Dependant Charging Case Data The Charging Case is first analysed in the table “Traffic Activity Dependant Charging Case Data”, which allows branching to a new charging case (NCC). Branching for “Calls” is based on the TSC (Telecommunications Service Code) and CI (Call Indicator) parameters*. The value of the TSC parameter is assigned by “Telecommunications Service Analysis Data” and depends on the bearer capabilities, teleservice, etc. requested by an ISDN call. The value of the TSC code is dependant on the administration. So, essentially this table allows charging to be dependant on what the call is being used for. Typically, administrations may charge low rates for 3.1 kHz Audio and Speech calls, and higher rates for 56 and 64 kbit/sec calls.