BugFix

EWSD
IN Services in EWSD

General IN applications in EWSD network nodes Hardware for EWSD-based SSP Hardware of the Integrated Service Logic (ISL) Software Administration Interfaces Call charge registration

The term intelligent network (IN) is recognized worldwide as referring to a network architecture that can be used for all telecommunication services. The architecture of the intelligent network (IN) gives operators of telecommunication networks a rapid means of developing and provisioning new, attractive and sophisticated services. In the conventional IN solution, independent components are installed to act as service switching point (SSP), service control point (SCP) and service creation environment point (SCEP). IN offers a wide range of services, many of which are already available and in use. Despite these benefits, other fundamental objectives of the IN architecture, such as unrestricted inter-operation between different network operators via the IN, have not yet been achieved. Although the interface between service switching point (SSP) and service control point (SCP) has been standardized, most IN platforms still operate autonomously. What is more, the costs of implementing an IN, especially the startup costs, are high and often represent a barrier for new and relatively small network operators.

The Integrated Service Logic (ISL) in EWSD represents an economical way of expanding the range of services on offer by implementing services that would otherwise only be available in a conventional IN. This solution provides a quick and cost-effective means of provisioning a variety of IN services without the need for an enhanced IN infrastructure. Because it uses the standardized interfaces, one and the same EWSD exchange can also be used as an SSP in a conventional IN without any further software upgrades and form a basis for longer-term evolution into a conventional IN offering the full range of sophisticated services. Moreover, the ISL provides the basis for future interconnections between Siemens SSPs and other vendors SCPs in a conventional IN environment.

Conventional IN SCEP SMP SCP ISL EWSD network node

SSP

SSP

SSP

SSP

IN applications in EWSD network nodes

EWSD currently offers the following network nodebased IN solutions: EWSD-SSP direct access services EWSD-SSP services with direct and dial-up access EWSD-based IN services EWSD-SSP direct access services The EWSD-SSP direct access services are divided in three features: Global Series Completion Service The Global Series Completion Service allows a called subscriber to be reached under different directory numbers (e.g. in the xed network and in the mobile radio network) (see Feature Description: Global Series Completion Service). Selective Reverse Charging With the Selective Reverse Charging service subscribers can dene the calling subscribers from whom they wish to accept the reversed charges, and this is applied automatically on arrival of the incoming calls (see Feature Description: Selective Reverse Charging). Time Dependent Call Forwarding The Time Dependent Call Forwarding service allows subscribers to automatically forward incoming call requests arriving at specic times to directory numbers that they have specied (see Feature Description: Time Dependent Call Forwarding). EWSD-SSP services with direct and dial-up access The EWSD-SSP services with direct and dial-up access are divided in four features: Dial-up Access With Dial-up Access an alternative network provider can offer subscribers of another network provider access to their network via a dial-up number (see Feature Description: EWSD based IN Services in Transit Network Nodes (TXS Services)). Travel Service Using the travel service, subscribers of an alternative network provider can use a specic service number and authorization code to make a call from any telephone or PBX from any network via the carriers network (see Feature Description: EWSD based IN Services in Transit Network Nodes (TXS Services)). Commercial Free Call Service The Commercial Free Call service allows companies and advertising agencies to offer free calls in the local network to callers after they have been connected to a promotional announcement (see Feature Description: Commercial Free Call Service).

Automatic Service Selection The Automatic Service Selection service offers subscribers a choice of services (e.g. IN, operator, directory enquiries or voice information services) when they dial a particular service number; subscribers select the service they require from a menu with voice control (see Feature Description: Automatic Service Selection).

EWSD-based IN services The EWSD-based IN services are divided in three features: Freephone With the Freephone service, it is the called subscriber instead of the calling subscriber that accepts the charges for the connection (see Feature Description: Freephone). Reverse Charging With the Reverse Charging service, a called subscriber can accept any charges incurred by a calling subscriber without the intervention of an operator (see Feature Description: Reverse Charging). Televoting The Televoting service is used for votes taken via the telephone network. The users of this service are usually radio or TV stations or market research institutes. Those telephone subscribers wishing to participate in the vote dial a specied directory number to register their vote or opinion (see Feature Description: Televoting).

Hardware for EWSD-based SSP

The service switching point (SSP) contains all of the call-processing functions and provides support for signaling system no. 7 (SS7) connections to the service control point (SCP). In addition, the SSP contains IN functions such as trigger functions, query and response functions. The new call-processing functions for IN (e.g. repeat call setup after the occurrence of certain events) are concentrated in the incoming parts of the signaling programs.

The EWSD-SSP is composed of the following physical units: switching network (SN); coordination processor (CP); signaling system network control (SSNC)/ common channel signaling network control (CCNC); various LTG types: for connections between trunks and lines; for connections to the service control point (SCP); for the presentation of interactive user dialog sequences and; for connections to the external intelligent peripherals (IP). The SSP is an enhanced EWSD network node, with the additional functional units Service Switching Function (SSF), Call Control Function (CCF) and Specialized Resource Function (SRF). Most of these new functions are implemented in software, only the SRF requires additional hardware modules.

Switching network (SN) The switching network (SN) is a central component of the EWSD system. It connects the voice and signaling channels between the LTGs in the local network node. Coordination processor (CP) The coordination processor (CP) is a multiprocessor system that allows load sharing between processors and is capable of handling the load, for instance, in the event of hardware faults. The CP performs the following tasks: control of the SN; routing; call charge registration; communication with the operator through MML; supervision of the database for subscriber data and IN trigger data. Signaling system network control (SSNC)/ Common channel signaling network control (CCNC) The signaling system network control (SSNC)/ common channel signaling network control (CCNC) is a modular multiprocessor system which controls signaling between the network nodes. Line/trunk group (LTG) The line/trunk groups (LTG) communicate with subscriber lines, remote network nodes, intelligent peripherals (IP) and the service control point (SCP). The LTGs contain code receivers for a number of different signaling systems and temporary counters for charge registration. Different types of LTG are used to connect subscriber lines to remote network nodes or to international network nodes. The range also includes special types of LTG for connecting IPs and for interactive dialog with users (UI-LTG). LTG for interactive dialog with users (UI-LTG) The LTG for interactive dialog with users (UI-LTG) is based on the operationally controlled equipment for announcement (OCANEQ) and the voice processing unit (VPU). The announcements played by the OCANEQ are composed by joining together text fragments stored in the memory of the OCANEQ. The text fragments can be linked together as required. The VPU recognizes DTMF signals as well as voice input. It is these hardware components that are used by the UI-LTG to compose UI dialog sequences that consist of a series of short individual announcements containing variable elements.

SSP A-LTG A-LTG SSNC/CCNC SN

CP SSF SSP features IN database IN administration

CCF

Standard LTGB UI-LTG SRF OCANEQ Code receiver

Voice recognition

IP-LTG

IP SRF

Operationally controlled announcement equipment (OCANEQ) OCANEQ is implemented on a single module. This module consists of a voice memory unit and a control unit: The voice memory unit is used to store the text fragments needed to compose the necessary announcements. It has an addressing capacity for 65,535 different text fragments. To ensure an acceptable quality of announcements, the text fragments are never shorter than one complete voice unit (approximately equivalent to half a second). There are two versions of the voice memory, offering capacity for either 1 hour 10 minutes, 3 hours 30 minutes, 10 hours 30 minutes or 37 hours 26 minutes. A cache memory allows text fragments to be downloaded over Ethernet interface or over an ISDN dial-up connection. The control unit composes the complete announcements from the text fragments stored in the memory unit. It is capable of supporting up to 63 announcement channels. Announcements that use the same text fragments can be played simultaneously and independently on different channels. The tools ALINA (Administration of Language Data for Individual Announcements) and PC-CAPE (PC for Cutting and Programming Equipment) can be used to generate new announcements and to modify existing announcements. ALINA provides support for MML generation and PC-CAPE is used to provide the text fragments. In addition, the OCANEQ Service Software tool is needed to load the text fragments to the OCANEQ memory. Voice processing unit (VPU) The VPU module supports simultaneous recognition of speech input and DTMF tones. Speech recognition is implemented by a loadable supplementary software product. 32 receiver ports per module are available. Each port has an echo canceller for DTMF and speech. The "Store and Forward" function allows temporary storage of subscriber speech input. Approximately three minutes of compressed speech information per speech channel can be stored and played back during the call.

External intelligent peripheral (IP) The external IP is not considered as a part of the EWSD system. It is linked to the network node over ISDN primary-rate multiplex lines. The IP provides the same functionality as a UI-LTG. Unlike the UI-LTG, the IP has a very large-capacity voice memory. It also allows announcements to be recorded online and updated over data interfaces. The main applications of the IP are: long announcements that are changed frequently (e.g. weather forecasts) announcements recorded by service subscribers UI dialog sequences storage of incoming information during the absence of a service user and replaying this information as soon as the service user returns (voice mailbox, fax mailbox etc.). A related capability of the IP is that it is able to report receipt of messages to the SCP. processing of special call types (three-way calling, large conference etc.) Hardware maintenance The VPUs and OCANEQ undergo regular routine testing by the LTG. An explicit diagnostic function can be called up via MML.

Hardware of the Integrated Service Logic (ISL)

No special hardware is needed to use the Integrated Service Logic (ISL) over and above the SSP functionality. Some of the services offered to users by the ISL call for the input of information by means of DTMF, for instance authorization codes or menu selection for administration of the service subscribers data. A UI-LTGs are needed for dialog with the service subscriber. All of the phrases needed to compose the announcements for ISL-based services are recorded in an announcement catalog. Furthermore a special mid-call trigger (MCT) hardware and firmware is required in case of the usage of the TXS feature A-side initiated follow-on. The MCT hardware enables a calling subscriber to release an existing call and initiate a new call without the need of anew identification.

Software
In accordance with ITU Q.1214 and Q.1224, a number of functional units have been defined which are used to build up separate structured software blocks. These functional units can be looked at regardless of their physical location in a specific exchange, as solutions in the Integrated Service Logic (ISL). The Integrated Service Logic (ISL) can be implemented simply if an internal Service Control Function (SCF) and a Service Data Function (SDF) are present in the EWSD system. The figure shows the functional units of this model. They are explained in the subsequent sections of this description.
SSP solution

SCP SCF SDF

control of the call-processing functions (in the CCF) needed for IN services, under the control of the SCF; provision of the call-processing actions of SSF and SCF; provision of access to SSF and CCF; selection and activation of SSF features. SCF access: The purpose of the SCF access functions is to establish a clear dividing line between the IN application part (INAP) and the underlying transport services. IN feature access: Further parts of the SSF are the IN-specic functions overload protection for SCP and SS7 network (Congestion Control), load reduction between SSP and SCP (Service Filtering), charge registration and statistics.

EWSD-SSP CCF SSF SRF

For an SSP configuration with Integrated Service Logic (ISL), the SSF remains the same, no changes need to be made. Call Control Function (CCF) The Call Control Function (CCF) provides control for call setup and release by the users and by the Service Control Function (SCF). The main task of the CCF is to provide trigger mechanisms which allow the SCF to be accessed via the Service Switching Function (SSF) and hence allow the IN service logic to influence the processing of IN calls. For an SSP configuration with Integrated Service Logic (ISL), the CCF remains the same, no changes need to be made. Service Control Function (SCF) The Service Control Function (SCF) works with the CCF to process IN service requests via the Service Switching Function (SSF). It controls and monitors the CCF.

ISL solution EWSD GP CCF SSF SCF SDAF CP Subscriber database SDF

TCAP

Service Switching Function (SSF) The Service Switching Function (SSF) provides the functions needed for the interaction between the Call Control Function (CCF) and the Service Control Function (SCF). Using an interface between these two units, the SSF administers the signaling between CCF and SCF and enables the SCF to control the CCF. The SSF comprises the functions SSF control, SCF access and IN feature access. SSF control: SSF control provides the functions needed for the interaction between the Call Control Function (CCF) and the Service Control Function (SCF): administration of the interfaces between CCF SSF and SSF SCF;

In a conventional IN architecture, the SCF is located in an SCP, whereas in an SSP configured as an ISL solution the SCF is integrated in the EWSD network node. The SCF is an independent functional unit installed in the GP and provides all of the functions needed to control the ISL-based services. Service Data Access Function (SDAF) The Service Data Access Function (SDAF) component is not standardized. In an SSP configured as an ISL solution, the SDAF is integrated in the EWSD network node, where it acts as a transfer and distribution point between the service logic and the various databases in the CP.

The SDAF implements access to the appropriate database, depending on the service or feature data received. Service Data Function (SDF) The Service Data Function (SDF) contains subscriber and network data for access by the SCF while an IN service is active. In a conventional IN environment, the SDF is located in the SCP and usually in the same hardware component as the SCF. In an SSP configuration with Integrated Service Logic (ISL), the SDF is integrated in the EWSD network node. The SDF is located in the CP and forms a separate database for service subscribers together with the associated administration functions for this database. It stores data on the service subscribers and their service and feature data. MML is used for the administration of the subscriber database by the operator, for all ISL services, and menu-driven interactive dialog sequences with the subscribers. Specialized Resource Function (SRF) The Specialized Resource Function (SRF) provides access to the system resources needed for the execution of IN services (e.g.: code receivers, announcements, voice mail facilities and voice recognition modules). The SRF provides menu-driven interactive dialog sequences to support the following functions: playing xed announcements; playing multi-fragment composite announcements; application of audible tones; requests for subscriber control input by means of tones or announcements; collection of subscriber information by means of DTMF or voice recognition. For an SSP configuration with Integrated Service Logic (ISL), the SRF remains unchanged, no changes are necessary.

Information on administration can be found in the Operating Manuals (OMN). Subscriber-controlled administration using menu-driven interactive dialog Service subscribers can modify their data for the services "Time Dependent Call Forwarding", "Global Series Completion Service" and "Selective Reverse Charging" using a special service number. The dialog with the service subscriber is menu-driven and uses announcements and DTMF signals. The UI-LTG is employed for the dialog with the service subscriber. A series of announcements allows the service subscriber to choose among various menu options. The service subscriber dials one of the numbers offered to call up the next announcement. Further information can be found in the Feature Descriptions Time Dependent Call Forwarding, Global Series Completion Service and Selective Reverse Charging.

Interfaces
IN application part (INAP) The INAP, which is based on the transaction capabilities application part (TCAP), is used as the communications protocol between the SCF and the service switching function (SSF), for both the external and the internal Service Control Function (SCF). One of the fundamental design principles of the Integrated Service Logic (ISL) was to retain the existing interfaces and functionality of the service switching point (SSP), in particular those of the SSF. For this reason, the SSF uses the same addressing mechanisms as an internal or external SCP to access its own SS7 node.

SSP with ISL CCF SSF INAP/ TCAP SDF SCF INAP/ TCAP SCF

SCP SDF

Administration
Administration using MML All service subscriber data relating to the Integrated Service Logic (ISL) are administered in a separate database for ISL service subscribers. This database contains data on the service subscribers and the ISL services and features assigned to these service subscribers. In case of TXS services all subscribers are administered in the IN authorization database. So-called IN triggers are used to access the intelligent network (IN). These IN triggers are defined in the CCF and in the SSF. If the defined conditions are met, the IN trigger activates an IN service with a query to the SCF.
6

Internal interfaces in the Integrated Service Logic (ISL) Within the Integrated Service Logic, the following interfaces are provided: Interface between SCF and SDAF In accordance with the standardized IN architecture, there is an interface between the Service Control Function (SCF) and the Service Data Access Function (SDAF). The ISL architecture denes the functionality of the Service Control Function (SCF) and the Service Data Function (SDF) within the EWSD system and provides a more simple implementation of these interfaces. An SDAF is integrated in the ISL in addition to the SCF and SDF. The SDAF operates as a transfer point between the service logic located in the GP and the service data located in various databases in the CP. Interface between SDAF and subscriber database This interface is implemented by means of a normal CP procedure. Interface between SDAF and ISL subscriber database This interface is implemented by means of a normal CP procedure. Interface between subscriber database and operator Administration of the various database features for a subscriber in the transit exchange is implemented by means of MML. Interface between ISL service subscriber and operator Administration of the ISL service subscriber database by the operator is implemented by means of MML.

EWSD offers three ways of implementing charge registration for IN services: Charges registered exclusively by functions in the public switched telephone network (PSTN) In this method, charges are recorded for the calling party by means of counters and AMA records. The charges are billed to the calling party only. Charges registered exclusively by IN components The charges are billed to the service subscriber. No charges are billed to the calling party. The charges are registered in the service switching point (SSP) or in the service control point (SCP). It is possible to generate IN-AMA records, or to register the charges on subscriber meters in the SSP and, if required, generate IN-AMA records subsequently. Charges registered partly in the PSTN and partly in the IN This method involves both PSTN and IN components. The charge information or meter pulses are supplied by the SCP or SSP. In the PSTN, AMA records are created or the incoming meter pulses or meter pulses generated on the basis of the charging information are accumulated on counters in the PSTN. Because the Integrated Service Logic (ISL) is based on the IN architecture, the same principles of charge registration are applied as in the conventional IN. As a rule, IN-AMA records are generated for charge registration. They record the duration of various parts of the call and information relating to the service. This information is used to calculate the actual call charges in the billing center.

Call charge registration

The introduction of services in the intelligent network (IN) has placed entirely new demands on charge registration. The basic idea is that each of the two parties pays a part of the accumulated charges. The question of who is responsible for paying for what is treated separately for each IN service. The following options exist: Neither of the parties pays. The calling party pays. The service subscriber pays. The calling party and the service subscriber each pay part. Two different service subscribers each pay part.

Copyright (C) Siemens AG 2002 Issued by Information and Communications Group Hofmannstrae 51 D-81359 Mnchen Technical modifications possible. Technical specifications and features are binding only insofar as they are specifically and expressly agreed upon in a written contract. Order Number: A30828-X1160-D-1-7618 Visit our Website at: http://www.siemens.com