|
Service Creation for Advanced Intelligent Networks Utilizing Intelligent Peripherals
Steve Silberstang
Abstract
Technological advances coupled with an increasingly open business environment have spurred
telecommunication service providers to compete based not only on price and quality of service
but also on new service offerings and time-to-market. New services are being introduced to the
market at an ever-increasing pace, many requiring sophisticated voice-processing support. The
challenge to the service provider is, at a minimum, to keep pace with the competition in
offering these services and, better still, to invent and develop new, distinctive service
offerings. The advanced intelligent network (AIN) provides the framework for deploying these
new services, and the intelligent peripheral (IP) provides the required voice-processing
support. This essay discusses the service creation environment (SCE) required to bring such
products to market expeditiously.
Introduction
Until recently, the voice-processing requirements for a telephone switch were quite modest and
could be satisfied by the limited announcement capabilities offered by the switch, usually as
sequenced announcement of greetings, instructions, and terminating messages. No specialized
service creation environment was required to develop and deploy these services. More complex
voice-processing capabilities such as central office-based voice mail were provided' but not
as an integrated service of the switch.
Complex voice-processing capabilities grew outside of the switching network in the form
of interactive voice response systems, voice mail systems, call directors, automated
operators, and other customer service and support systems. Over time, these systems embraced
new technologies including facsimile, speaker-dependent and speaker-independent voice
recognition, text-to-speech, and voice identification.
With the introduction of the intelligent network (IN), these two technologies were brought
together out of necessity. Services rich in voice-processing content and requiring an
abundance of digitized voice storage could no longer be created solely with the innate
capabilities of the switch. The variety of service offerings, their complexity, and, in many
cases, the requirement for multilanguage support, quickly outpaced the voice-processing
capabilities and capacities of the switch. Voice-processing systems were integrated with
switching systems to support these new services. The exact manner in which voice processing
systems would be integrated with other components of the network was not addressed at this time.
Service creation became dichotomized. Call-processing services were being developed for
the service control point (SCP), using one set of service creation tools. Voice-processing
services were being developed for the interactive voice response (IVR) systems, using a
completely different set of service creation tools.
The advanced intelligent network gave definition to the integration of call switching,
call handling, and voice processing. Within the service node AIN architecture, the service
switching point (SSP) provided the call-switching capability, the service control point
provided the call-handling capability, and the intelligent peripheral provided the voice
processing capability. SS7 signaling provided the messaging protocol, allowing the AIN
components to communicate. TCAP messages allow the SSP and the SCP to cooperate in the
handling of calls so that the SCP can use its data storage and data processing capabilities
to make complex call-handling decisions on behalf of the SSP. The Bellcore 1129+ message
protocol allows the SCP and the IP to communicate so that the SCP, a network component which
has no capability of its own to support voice-processing, can call upon the IP to assist in
the support of service logic requiring voice-processing and/or voice storage capabilities.
This essay will discuss the details of the Bellcore 1129+ interface, particularly in the
context of service creation. It will discuss the residual dichotomy of service creation and
how this will be affected by the more widespread acceptance of the 1129+ interface. Finally,
it will suggest an evolutionary path for the 1129+ interface that, in part, will be dictated
by the requirement of service providers for integrated service creation and centrally managed
service deployment and service management.
The AIN Environment
AIN is a collection of components which act in concert to deliver complex call-switching and
handling services. The SSP provides robust call-switching capabilities and, usually, limited
call-processing and voice-processing capabilities. When switching decisions require complex
call-processing logic and large data stores, the SSP relies on the capabilities of a service
control point to query subscriber databases and execute service logic. The SSP uses SS7
signaling, specifically TCAP messages, to ask the SCP to ascertain how to treat the call.
This mechanism supports several advanced telephone services, including 800 and 900 dialing,
credit calling, debit card calling, call forwarding, private virtual networks, and the like.
A diagram showing AIN components is given in Figure 1.
When switching decisions require complex voice-processing services, the SCP alone cannot
assist the SSP. The SCP provides no facilities for termination of voice circuits and,
accordingly, cannot speak, collect touch-tone input, or per-form other voice-processing
service. Instead, the call must be diverted to an intelligent peripheral. The IP provides
the voice-processing services the SCP lacks. Instructions passed from the SCP instruct the
IP how to handle the call. Within the AIN environment, this is the function of the Bellcore
1129+ protocol - a modified SS7 message set carried over a TCP/IP communications path
(see Table 1).
Bellcore 1129+
The intelligent peripheral must provide voice circuit support and some mechanism for
obtaining information about an incoming call. Several mechanisms are available for capturing
call information including ISUP signaling, ISDN signaling, in-band DTMF signaling, or DTMF
input to voice queries. In any case, the 1129+ transaction is triggered by the receipt of an
inbound call and initiated with the delivery of a Provide Instructions message from the IP
to the SCP (see Figure 2). Thereafter, the transaction continues with queries issued by the
SCP and synchronous responses to these queries returned by the IP, reporting results of the
requested action. In AIN 0.1 and AIN 0.2, these queries are carried by TCP/IP communications.
Later releases of AIN carry these messages over SS7 communications and support communications
passing through intermediate network elements.
The 1129+ transaction set can be divided into three categories, as listed in Table2.
The first category includes transactions that are completely defined by the specification and
can be processed by a generic 1129+ IP implementation.
Some examples include requests to
play a sequence of announcements (CallInfoToResource, Play Announcement), to play a sequence
of announcements and then collect touch-tone input (CallInfoToResource, Play Announcements &
Collect Digits), and to verify a string of collected digits against a string provided as part
of a request (CallInfoToResource, VerifyDigits, ActualDigits). Several other transactions fit
into this category.
The second category of transactions are those which have well-defined message content but
need site- or installation-specific customization to support transaction pro-cessing since
some aspect of the transaction is not well defined by the specification. For example, the
SCP can request that the IP solicit and collect a string of touch-tone digits for
verification against a User Password; however, it is the User Identifier that is supplied
along with the transaction and not the User Password itself CallInfoToResource, VerifyDigit,
UserId). The interface expects the IP to extract the password from a User File for this
comparison but does not define the structure or format of this file.
The third category of transaction has neither a well-defined message content nor a
supporting infrastructure to permit processing. This transaction type requires negotiation
be-tween the SCP and IP to determine message content. The ExtendedInfo-ToResource,
PlayApplication request and its associated ExtendedInfo-FromResource, PlayApplication
response that can best be described as the SCP asking the IP to "do something for me" and
the IP responding with "here are the results." Nothing in the specification limits the scope
of these requests. The meaning and content is purely a negotiation. A Play Application can
be almost anything from a request to record a restricted number in a restricted number
database to a request to play an interactive voice response script to the caller who is
already on the line (see Figure 3).
The Service Creation Dichotomy
The 1129+ interface permits service logic to be created for and executed on an SCP. The
SCP can field Providelnstructions messages initiated by the IP and can thereafter provide
explicit instructions to the IP to perform voice- processing functions such as speech,
digit collection, digit verification, message recording, message playback, and call
transfer. Service creation environments in use by service providers that are currently used
to define call-processing strategies can be extended to support the voice-processing
capabilities of the IP. In their most basic form, these service creation environment
extensions will be defined as service independent building blocks (SIBBs) and will map
one-to-one to the 1129+ message set. These elementary functions, each of which triggers a
single 1129+ query/response, can be amalgamated into macros or higher level SIBBs to improve
the effectiveness of the SCE.
The 1129+ interface, specifically the PlayApplication transaction, permits service logic
to be created for and executed on the IP (see Figure 4). The SCP can pass the IP an
arbitrary set of parameters as part of a PlayApplication request for execution of IP Service
Logic. In many cases, the Interactive Voice Response system from which the IP has evolved
provides a robust service creation environment specifically designed for the creating of
voice-processing applications. The same sorts of functions that can be evoked via 1129+
transactions, speech, digit collection, message recording and playback, call transfer and the
like, can also be coded using the IP's service creation environment and evoked using the IP's
service logic execution environment.
Here is the dichotomy. Should the service provider create service logic intended to
execute on the SCP or on the IP? We examine some of the factors influencing this decision.
SGP Versus IP Service Creation and Execution
There are several compelling reasons to develop service logic for the SCP. This is where
traditional call-handling service logic resides in the IN/AIN environment and significant
investment has already been made in infrastructure. Service logic is built using a service
creation environment, loaded to a service management subsystem, and distributed to multiple
service control points using existing network connections and delivery mechanisms. Facilities
are normally in place for alarm handling, statistic gathering, and billing functions.
Technicians are familiar with the service creation environment, and craftspersons are familiar
with the service logic execution environment (SLEE). Documentation has been published,
training material produced, and procedures well established. These factors influence the
service provider to treat the IP as a "black box" driven by extensions to the existing service
creation and service logic execution environment.
On the other hand, the service creation environment in place for an IP will often provide a
much more effective tool for creating voice-processing service logic. There are two major
reason why this is true. For one, these tools have been designed specifically for creating
voice-processing applications and have been refined over many years and many product versions.
Very sophisticated graphical user interfaces (GUIs) have been developed to assist in the
creation of voice-processing applications. Second, the 1129+ interface is still immature and,
in many cases, does not provide a sufficiently robust or complete command set to effectively
control the IP facilities. For example, there are no 1129+ messages currently defined to handle
voice recognition, facsimile, or text-to-speech features. Furthermore, there is no 1129+
message that can efficiently handle one of the most basic voice-processing constructs - a
limited selection menu. Complex error-processing logic and a multitude of messages must be set
in place on the SCP to properly handle a simple menu. Instead, a PlayApplication request used
in conjunction with the menu-handling facilities in place on the IP can reduce the complexity
of this transaction (see Figures 5 and 6).
On a simplistic level, the service provider must choose between developing service logic
quickly on the IP and sacrificing the infrastructure available with the SCP or taking the
additional time to develop on the SCP and bearing the associated market risk. In reality,
the better choice is often governed by the complexity of the application and may in fact be
a hybrid solution with service logic on both the SCP and the IP.
Toward An Improved Service Creation Environment
A common, integrated service creation environment for AIN which executes within the SCP
infrastructure and treats the IP as a "black box" is, in the opinion of the author, the
preferred direction. However, the IP must remain open and provide a robust service creation
environment of its own to handle situations which are, by design, outside the context of the
1129+ transaction set or, by analysis, best handled independently of the SCP.
As mentioned above, the SCP's SCE can be extended through the use of SIBBs to incorporate
the capabilities of the 1129+ interface and, in fact, through higher level functions, made
more and more powerful. However, certain capabilities will remain cumbersome to implement,
and other capabilities will be impossible to implement without significant improvements to
the 1129+ interface itself. The author is confident that such improvements are forthcoming,
driven by market demand accompanying the deployment of AIN and IP facilities.
A few suggestions, by no means a complete list, for improving the Bellcore 1129+ protocol follow:
Provide Additional Options for Resource Digits
Resource digits permit an SCP to instruct an IP to speak dates, times, monetary amounts,
telephone numbers, and digit strings. A few useful constructs are missing, including the
ability to speak cardinal and ordinal numbers, percentages, days of the week, and optional
formats for dates, times, telephone numbers, and amounts.
Provide Ability to Record a Specific User Announcement
Currently, when adding a user (subscriber) announcement, the system assigns the next available
user announcement number which is not always convenient. Provision should be made to specify
the announcement number to be used to record a user announcement.
Provide a Simple Menu Function
The VerifyDigits function allows the SCP to specify retry and reprompt logic. A specialized
variation of this function should be provided to simplify processing of limited selection
menus. One should be able to specify the valid input values, time-out limits, time-out values,
input error limits, initial prompts, retry prompts for various circum-stances, and success and
failure termination prompts. Response to this function should indicate success or failure,
returned value, and types of errors committed.
Provide a Function to Set Language
The IP should optionally be given the opportunity to manage multiple languages. Currently,
the SCP is required to map message numbers for multilanguage applications. Some IVR system,
have the capability to manage multiple message sets (i.e., an English message #1 from one set;
a French message #1 from another set, and so forth). Additionally, many ResourceDigit-processing
routines vary, based on language.
Provide Functions for New Technologies
The message set should be extended to include facsimile, text-to-speech, voice recognition,
voice identification, voice training, and so forth.
Intelligent Peripheral Capabilities and Architecture
A diagram of the model 1129+ IP service execution environment is shown in Figure 7.
The intelligent peripheral must provide a framework to support a number of capabilities,
namely:
Solid Support of the Bellcore 112gi Message Protocol
This support must include a reliable TCP/IP comrnunications server, a message encoder and
decoder, and processing support for the full 1129+ message set. It must properly handle the
tricky details of type-ahead, caller abandonment, message synchronization, and communication
reestablishment. The support must be solid and reliable, which implies that defect-free
software be deployed. This implies a standard Bellcore 1129+ base product that does not change
with installation and/or application.
Accommodation to Change
The IP must be able to accommodate the inevitable extension and improvement of the protocol.
This implies that new releases be quickly assembled and tested. An 1129+ implementation created
using the service creation envi-ronment of the IVR reduces time to support a new release.
Ability to Support Those 1129+ Functions That Fall
Outside the Definition of the Specification
The IP must provide support for those functions that are not completely defined by the 1129+
specification and those that require site- and/or application-dependent modification. A
client/server model is suggested in which the communications, encoding, decoding, and
base-message processing are handled by generic, base product software elements, and only those
aspects of transaction processing that fall outside the specification are handled by separate
installation-specific server modules. For example, a VerifyUser transaction can be processed
by soliciting the user password, using generic 1129+ software and then sending the user
identifier and solicited password to a user directory server module. The user directory server
should be able to manage a site-specific directory housed in a relational database or file
system. It must be able to read the user record, extract the user password, compare the user
password to the solicited password, and return a match/no match determination to the generic
software for encoding into a proper response and delivery back to the SCP. This isolates the
site/installation-specific code to the directory server module, mitigating the possibility
of introducing defects into the generic IP software.
A VerifyDialingPlan transaction can be processed in the same manner as the VerifyUser
transaction; that is, with site-specific processing implemented within an independent service
module.
Ability to Support the PlayApplication Function
The PlayApplication function is unique in that both the message content and message processing
are application- and site-specific, while strict encoding and decoding rules are enforced by
the protocol. A PlayApplication can require almost any type of processing. We suggest that
common software be employed for communication and encoding/decoding the 1129+ messages and that
standard facilities be employed to classify the PlayApplication requests by type of resources
and services required. PlayApplication transactions can be classified into three categories:
(1) those needing local data processing only, (2) those needing remote data processing only,
and (3) those needing voice processing and optionally local and/or remote data processing.
For example, suppose the SCP wants the IP to maintain a restricted-number database and wants an
entry to be added to this database for a specified subscriber. The SCP, using a PlayApplication
transaction, could provide the subscriber identifier and the restricted number and (1) ask that
the number be added to a local database, (2) ask that the number be added to a database on a
remote host or network, or (3) provide only the subscriber identifier and ask that the IP
solicit the restricted number from the caller and then add this number to a local or remote
restricted-number database.
Facilities must be provided to:
1) create local servers to manage local databases,
2) create remote servers to manage remote databases, and
3) create service scripts that interact with the caller and, optionally, manage local or
remote databases.
This IP service creation environment should support development of these service scripts.
The service script should be able to utilize all the umbrella services offered by the IP,
including local and remote server support, statistics gathering and reporting, activity and
error logging, alarm processing, line trace, debugging facilities, monitoring, and control
functions. This separation of function permits maximum security of generic 1129+ processing
facilities and at the same time full access to the robust service creation and service logic
execution environment available on the IP.
The Intelligent Peripheral Service Creation Environment
The IP's service creation environment should include a graphical user interface (GUI) to
permit the rapid definition of applications. The icons, or programming elements, should
represent major processing functions, such as presentation of a voice menu and determination
processing flow based upon menu selection or solicitation of touch-tone input with
verification and retry. Default processing parameters should be automatically set and easily
modified. Provision for extending the programming elements should be provided via macros,
subroutine constructs, and/or program language exits.
The SCE should produce documentation including flow charts, specifications, and recording
lists. It should also produce executable code in the form of scripts, state tables, and/or
generated program code. The developer should be able to define, verify, generate, compile,
and test scripts and program code on a platform that is independent of the IP's service logic
execution environment. New scripts should be easy to install without disrupting services.
The service creation environment should be capable of maintaining and extending the base
Bellcore 1129+ implementation as well as creating new Play Applications, including full-fledged
IVR applications that include access to local and host services and data.
Conclusion
Bellcore 1129+ provides a standard interface between the service control point (which houses
the traditional advanced intelligent network), the service logic execution environment (SLEE),
and the intelligent peripheral, which provides the voice-processing and voice storage
capabilities that support AIN applications. This is a step in the right direction, since it
provides a standards-based mechanism for the service provider to extend the traditional service
creation, deployment, and execution environments to include the control of voice-processing
facilities. This centralizes service management and places it in an environment that is both
familiar and well supported by support services such as billing, alarm handling, and the like.
However, currently and in the foreseeable future, there will still be a place for an
IP-based service creation and execution environment. Bellcore 1129+ acknowledges this by
inclusion of the PlayApplication function. Many services can be more efficiently created,
deployed, and executed with IP resident service logic or hybrid systems in which the service
logic is distributed between the SCP and the IP. It is therefore important that the IP provide
a robust service support environment of its own in addition to support of Bellcore 1129+.
Also, Bellcore 1129+ requires site- and/or application-specific processing in support of a
number of commands. This demands that the IP provide an open and flexible environment to
access databases, communicate with external systems, interface with switching fabric, and
support various signaling protocols.
Finally, Bellcore 1129+ currently lags behind the capabilities offered by a robust IVR system,
such as voice recognition, facsimile, text-to-speech, and the like. Though very powerful, the
facility still has some serious weaknesses that must be corrected. Acceptance in the field and
wider usage will flush out these problems and will stimulate the definition of a more robust
message set. Accordingly, greater service control will be possible from the vantage of the SCP
which is in line with traditional AIN SCE architecture.
Steven D. Silberstang is Chairman and Chief Technical Officer of Amarex Technology, Inc. His
area of focus includes interactive voice response for call centers, computer telephony
integration, advanced intelligent networks, and intelligent peripherals.
|
|
