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.
Figure 1.1
Module Objectives.
1.2 What is IN?
The term “Intelligent Network” means a network capable of meeting mar-ket demands for new services in a flexible and cost effective way. Erics-son’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 cost-effective way.
The introduction of IN services in the network contributes to higher reve-nues for an operator. Due to the availability of a wide range of new
attrac-Module Objectives
After completing this module the participant will be able to: • Describe the purpose of the IN concept
• Identify the different IN nodes
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 intro-ducing 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 dis-tributed 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 independ-ently 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 Con-trol 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 con-cept 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 tran-sit 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
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.
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 Applica-tion 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.
SDF SCF SCP SDP SCE SMS SMAS IN Service Control INAP SSF CCF SSP SRF IP IP Signalling Speech, data IN Call Control IN Service Management
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 capa-bilities 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(+).
1.7 IN Network Nodes
1.7.1 SSP - Service Switching Point
The SSP is responsible for all functions concerning switching of IN serv-ices. 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 subfunc-tions 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 connec-tivity 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 dia-logues and controls the reception and sending of operations between the SSF and the SCF.
Mass Call Services contains two functions (Call Gap and Service Filter-ing) for protecting the SCF against overload as well as filtering of calls for televoting.
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 appro-priate in order to perform the service in the network. The SCF can be implemented in two ways:
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).
1.7.3 SSCP - Service Switching Control Point
So far we have mentioned two different types of IN nodes, the SSP (Serv-ice Switching Point) and the SCP (Serv(Serv-ice 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 imple-mentation 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-pro-grammed 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
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 devel-oped, 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.
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 Pur-pose 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 opera-tion 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). SCF SSF SSP SCP LE SSF+SCF SSCP LE
Figure 1.4
IN Network with SCP-G
The SCP-G is comprised of the following functions:
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 exe-cution 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. SMAS SSP IP SS7 TCAP/SS7 TCAP SDP SSP SCP-G SCP-G over TCP/IP TCP/IP
7. The Service Node Application Platform (SNAP) provides the proc-ess 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 func-tion. 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 pri-mary TCF and the pripri-mary 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 Net-work (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:
•
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 softwareThis 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 Manage-ment System (SMS).
When SDPs are configured as mated pairs there is a problem with cus-tomer 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 net-work. 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.
Figure 1.5
SDP - Service Data Point
HD Primary Server Secondary Server HD HD HD Ethernet #7-link #7-link
SDP
SDP - Service Data PointHD - Hard Disk
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 announce-ment 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 facilitiesAt present, the most common Intelligent Peripherals are those which per-form 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 commu-nication 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 standard-ised signalling protocol for IN equipment. It can make announce-ments 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.
Figure 1.6
All types of IP. SCP SSCP IP IP IP IP IP CCF SSF IP Network IP Advanced IP Stand Alone IP Integrated IP
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 neces-sitated the development of Ericsson INAP CS-1+. CS-1+ provides back-ward 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 proce-dures 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 harmo-nise the IN standards worldwide. The ITU-T have defined a set of capabil-ities 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 vocab-ulary. The 14 recommendations contained within CS-1 were ratified in March 1993 and were printed in December of that year.
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 per-sonal mobility and international services being added in this standards ver-sion. 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-work-ing 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. 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.
1.8.3 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 recommen-dations 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.
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 10subsystem 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 Eric-sson AST-DR.•
A General Service Adapter (GSA) tool on top of the SMAS/TMOS application for service management and creationIn 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 operatorsfunctionality
•
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 mes-sages over SS7.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 com-bined 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 sim-plified data base structure which speeds up the handling of the data.•
IN (Intelligent Network) started as a concept within BELLCORE in theUS in 1984 to help them to become more competitive. This is still the main driving force.
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.
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 user-friendly interface based on graphic presentations, thereby offering a serv-ice provider a way to quickly introduce new, competitive servserv-ices 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
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.
easier to get in touch with people, leave messages, use the phone for mar-keting purposes, and so on.
A few examples will give an idea of the possibilities provided by tele-phone services.
One very useful telephone service is the personal number. Every sub-scriber 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 cen-tral 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 call-ing, hot line, queucall-ing, tele-votcall-ing, 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 serv-ices, 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 Manage-ment, different Control Type Collections, Database Customer Program-ming Interface and C++ Customer ProgramProgram-ming 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.
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 net-work.•
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 adminis-tration groups can be defined and assigned different levels of permis-sions. 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 meas-urement reports.•
Service Troubleshooting – This sales object offers applications for trou-bleshooting, 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 theCon-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 Man-agement provide the tools for monitoring, maintaining, and troubleshoot-ing the network.
Figure 2.2
How to create a new service and connect subscribers to the service.
Subscriber Name... Tel.No... Address... Service name... Service Idea 3. Install the service 4. Administer Subscriptions 2. Define Service Logic 1. Elaborate
1. Market demands provide an idea
for a service. Logic and data are outlined.
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 Deploy-ment.
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.
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 acti-vated during traffic and when actiacti-vated, 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 exam-ple 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
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,
SAFIL-Logic Module Logic Module Logic Module Logic Module Logic Module Logic Module Logic Module
ices in the SCP. The ERROR script is automatically activated when a fault occurs during the interpretation of a service. The UPDATE script is acti-vated 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 (cus-tomer 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 spe-cific scripts. It is possible to modify the data modules in the subscriber-specific script according to each subscriber request.
Figure 2.4
Service Script Levels.
GROUP SCRIPT SUBSCRIBER-
SYSTEM LEVEL ACCESS SCRIPT ERROR SCRIPT SPECIFIC SCRIPT SERVICE LEVEL SUBSCRIBER-SPECIFIC LEVEL UPDATE SCRIPT CC SCRIPT SDP Data
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 follow-ing modules.
Each SCE / SMS sales object also has its own SCE / SMS User Guide description, where each interface is described in great detail.
2.8 Service Management Platform
SCE / SMS is designed as a number of application units, built on the Serv-ice Management Platform.
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 com-mon for all SCE / SMS applications. These functions are handled by the following applications:
•
SCE / SMS Administration•
SCE / SMS Locators2.9 SCE / SMS Administration
SCE / SMS Administration provides the tools for administration of the SCE / SMS system. The graphic user interface for SCE / SMS Administra-tion consists of seven base windows, one for each applicaAdministra-tion, and associ-ated pop-up windows and forms. The different base windows are all opened from the workspace area. The applications are described in the fol-lowing:
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.
Serv ic e Creation Serv ic e Deploym ent Serv ic e P rovisioning Serv ic e M onit o ring Serv ic e T roubl e s hoot ing Net w or k T raf fic M anagem ent Cont rol T y pe Collec tions D a tabas e Cust om er Prog ramm ing In te rfa c e C++ Cust omer Prog ramm ing In te rfa c e
Service Management Platform
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 Net-work Element (NE). A request, for example an installation or a removal (of a service, subscription or global data module), an audit, or a data mod-ule 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 win-dow 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 ele-ments can be located with the Service/Subscription Locator:
•
SCPs•
Services•
Subscribers•
Subscriptions, that is, Telephone Numbers•
SSLs6. 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 follow-ing elements can be located with the Global Data Module Locator:
•
SCPs•
Control Types•
Global Data Modules7. 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:
•
SDPs2.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 Col-lection (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, tomer data, global data, or a combination of these. Local data and cus-tomer 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.
of Control Types specific to a type of network element, a particular net-work protocol, or any other grouping. The design of an SSL is accom-plished by creating a logic module graph, that is, choosing control types, defining their parameters, such as mode, input register and number of out-lets 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 fur-ther 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 sub-scriber-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.
Service Logic Administration also includes functions for editing and view-ing existview-ing SLs.
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
Service Logic Administration Service Logic Library
Freephonescript 1 Sep 26 1992
Validationscript_2 Sep 30 1992 2:23:12PM Group
5. Service Transfer
The Service Transfer application is the tool for transferring services (serv-ice logic and serv(serv-ice 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.
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.
Tape Disk Files Service Library UNIX SCE / SMS Platform Logic
2.12 Service Deployment
Service Deployment provides the tools for administering services and glo-bal data in the SCPs, including to create and install new versions of serv-ices. 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 sched-uled 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 los-ing any subscriber-specific data already created and installed.
Service Deployment also includes a function to migrate services built on the Control Type Collections IN2.0 and IN2.1 to services using the Con-trol 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 re-install a service.
This application also makes it possible to install or remove an SSL, inde-pendent 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 simula-tion 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 indi-cates which logic modules are accessed as the call passes through the serv-ice 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.
Tape Disk Files Service Library UNIX SCE / SMS Platform Logic
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 combina-tion of manual accombina-tions and a computer applicacombina-tion and has no graphical user interface.
2.13 Service Provisioning
Figure 2.10
Defining a subscription
Service Provisioning is the activity of defining subscribers and administer-ing subscriptions. The Service Provisionadminister-ing is divided into four applica-tions:
1. Subscriber Administration
Subscriber Administration is an application whereby the user can define new subscribers, delete old subscribers, and modify data for existing sub-scribers. Some services allow the subscriber to modify the subscriber spe-cific 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 tele-phone.
2. Subscription Administration
Subscription Administration is an application for defining subscriptions, that is, a subscriber and an installed service are selected and subscriber-specific data is defined. Each subscription is identified with a unique tele-phone number/SCP. For those subscribers who are allowed to modify part of their own data via a telephone (Subscriber Control via SCP), a CC tele-phone number must also be defined.
SERVICE SUBSCRIBER
SUBSCRIPTION
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; immedi-ately 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 administer-ing the permissions dependadminister-ing on the data beadminister-ing 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 HLR2.14 Service Monitoring
Service Monitoring provides applications for managing and monitoring installed services and subscriptions. It also includes applications for col-lecting information from the SCPs, such as statistics and call report infor-mation. 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 run-ning counter in an SCP. A runrun-ning counter is a counter specific to some of the control types that are updated in real-time in the SCP as the SCP proc-esses 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 termi-nation 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.
2.15 Service Troubleshooting
Service Troubleshooting provides applications for auditing and trouble-shooting installed services and subscriptions. Service Troubletrouble-shooting 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 sus-pected 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 sev-eral 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 discrep-ancy 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 sub-scription. 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
2.16 Network Traffic Management
The Network Traffic Management (NTM) application is used to protect the SCP against service traffic overload through congestion control. Con-gestion 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 arriv-ing 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).
Figure 2.11
Congestion Control Allowed no of calls
Gap Interval
Rejected calls time calls
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 exam-ple, 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 CS1GControl 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 functional-ity 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 NetworkControl 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
•
Support for multiple protocols•
Support for communication with other network entities•
Support for virtual directory numbersThe 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 fol-lowing new functionality have been introduced in the Control Type Col-lection IN2.1+ compared with Control Type ColCol-lection IN2.1:
•
New CC•
New queue functionalityControl 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 functional-ity have been introduced in the Control Type Collection CS1+ compared with Control Type Collection CS1:
•
Leg manipulationControl 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.
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 knowl-edge of how to develop application programs and APT-based user inter-faces.
The sales object consists of:
