Note: Descriptions are shown in the official language in which they were submitted.
CA 02214725 1997-09-05
WO 96/2783~ PCTIUS96102273
SERVIOE M~NAGEMENT OPERATION AND SU2PORT ~Y'i 1~ AND ME~OD
C~?.OSS }~F~FF~7FNC~ TO }?F'T.~TFn APPTICATIONS
This application is related to U.S. Patent Application Serial
~o. 07/972,817, the content~ of which are hereby incorporated by
reference.
BACKGROUND OF 1~ INVENTION
The present invention relates generally to the Ad~anced
Intelligent Telephone Networ~ ("AINn), and more specifically ~o a
Ser~ice Management System ("sMS") for proce~ing and implemen~_
new telephone services or modifyin~ old services.
Implementing new telephone services or modifying o'd se~rices
efficle~tly and economically has long been a problem for telephbr.e
companie3. Recent advances in the AIN have reduced the cost of
creating new services by simplifying creation proces~, but have
left ~ome problems unsolved, particularly problems concerning
gathering and manipulating data required to implement new
services.
The AIN ~J de~cribed in the related applications referenced
above, pro~ide~ telerh~n~ service ~y~am~ custo~ to the
desires of indi~id~al cu~tomers. As used in thi~ application,
"customer~ refer~ lo the entity for which a service is pro~ided,
and "user~ or ~operator~ refers to the person using the system to
create, te~, or modify the service. The usQr and customer may be
the same, but they need not be.
The AIN includeJ a cu~t~m~ erYice~ (~CS~) application to
create and, in certain ci~ anc~ e~ch cu~tomer'~
gervice ~0~4 1..~ ~ or ~vy~ . The CS can include one or both of
SUBSTITUTE SHEET (RUEE 26)
CA 022l472~ l997-09-0~
W096/27835 PCT~S96/02273
the Service Processing And Creation Environment ("SPACE~"j
software application and the Multi-Services Application ~latform
~"~SAP~") software appl cation. Both SPACE and MSAP are
proprie~ary software applications owned by Bellcore, the assignee
of ~his appllcation. Each customer~s service program is s~o-ed _n
a database as a record or a series of records of customized call
proaessing information called a call processing record ("CPR").
Individual CPRs are created for each customer indicating the
telephone services to which they subscribe and the call processing
steps necessary to provide those services. These CPRs dictate how
the network will respond to calls to or from the customer's
telephone number.
In the AIN, the CPRs corresponding to a service are created
in a creation environment of the CS application and are executed
during call processing in a call processing environment of the CS
application. As used herein, a switch, or service switching point
("SSP"), is a piece of telephone equipment which receives and
routes telephone calls t
Fig. 1 illustrates an exemplary AIN 100 comprising an SMS
llO, Service Control Points ("SCPs") 120 and 130, Signal Transfer
Points ("STPs") 140 and 150, and SSPs 160 and 170. Each SSP
recognizes a variety of "triggers" within customer telephone call
signals and generates queries to SCPs based on the triggers. The
SSPs then process customer calls in response to commands received
f-om the SCPs.
The SCPs are configured as a mutually mated pair in different
locations. If an SCP, such as SCP 120, is disabled, its mate, SCP
-- 2
CA 0221472~ 1997-09-0~
W096l27835 PCT~S96102273
130, can ensure that telephone service continues without
interruption.
Associated with the SCP pair 120 and 130 is an SMS ' 0. The
SMS 110 provides a support interface through which customer data
and service logic can be added or managed.
~ ach of the SMS ilO and the SCPs 120 and 130 can execu~e the
CS application. The CS application generally provides for both
the creation of a CPR (service creation) through an operator
interface, and for the execution of CPRs during call processing.
However, the CS application may, in certain circumstances, provide
for only the creation or the execution o~ CPRs.
Fig. 2A is a functional block diagram of SMS llo. SMS 110
comprises CPU 240, database 242, operator interface 244, and CS
application 246. Operator interface 44 comprises display 48,
keyboard 50 and mouse 52, each connected to CPU 240. CS
application 246 includes service creation portion 254 and call
processing portion 256. A CPR can be created at SMS 110 via
operator interface 244 and can also be used by SMS 110 to process
calls input to CPU 240 via any number of sources such as a network
switch simulator or a dedicated testing switch (not shown).
Fig. 2B is a functional block diagram of SCPs 120 and 130.
SCPs 120 and 130 each comprise CPU 258, database 260, and CS
application 246. In Fig. 2B, CS application 246 comprises only
call processing portion 256. This is because SCPs 120 and 130
provide no operator interface 244 (Fig. 2A), therefore, in this
embodiment, CPRs cannot be created at SCPs 120 and 130.
CA 022l472~ l997-09-0~
W096/27835 PCT~S96/02273
The service creation portion 254 of SMS 110 comprises the
SPACE software application. The call processlng portion 256 in
SMS llO and SCPs 120 and 130 comprises Ihe MSAP software
application. ~he service creation portion 254 of SPACE is
dedlcated to the creation of CPRs, and a service management
portion of SPACE (not shown) is dedicated to managing services,
testing and validating procedures, and transferring CPRs, tables,
and messages to the SCPs 120 and 130.
CPRs corresponding to new telecommunication services are
created using SPACE by generating a high level, display
representation (graph) of the desired service on a display of a
user workstation (not shown). The graph is comprised of "nodes,"
"decision boxes," and "branches." Each node represents a high
level instruction for the execution of the service. The displayed
graph of a CPR is extremely useful in that it permits an operator
to create and understand the telephone service being created. For
use in an execution environment, however, the CPR graph is first
translated into a lower level representation comprising data
structures and pointers representing the CPR, and is then
translated into a binary representation. The SCPs 120 and 130 use
this binary representation to process calls in the execution
environment. Using SPACE, new services are easily created and
easily implemented.
Many customers may request the same telecommunication service
for mass markets, however. For example, many customers may wish
to designate a long distance carrier during certain times of the
day (i.e., business hours). The graph corresponding to each
CA 0221472~ 1997-os-o~
W096/27835 PCT~S9610~273
custome~'s CPR would therefore be identical except or graph entry
points, nodes defining the carriers, and nodes defining the t me
of day that speci led carriers will service the call. All s~her
nodes n of the graph and the structure of the graph would be
"gener -" to the service.
It is impractical and inefficient to require a user ~s build
the same graph for every customer requesting the same service.
Accordingly, SPAC~ and MSAP provide for service templates. Once
created and enabled, a template serves as a "form" for creatirg a
customer specific version of a service. Customer specific
versions of a service are established by making "customizable" one
or more nodes within a template. In this manner, the template
allows the same service to be provided to more than one customer
without having to rebuild the entire graph or redefine generic
call variables in the CPR establishing the service.
Using the CS application, and particularly templates, to
create and process CPRs has dramatically reduced the costs of
creating and instantiating new telephone services, but problems
remain. For example, the AIN l00 cannot quickly and economically
receive and implement service requests from customers since a
skilled operator must coordinate the instantiation of each new
service in the AIN l00. "Service request," as used ir. this
application, refers to a request by a customer to receive a new
telecommunications service or alter an existing service.
To implement a new service in the AIN l00, the operator must
typically collect data from the customer. For a call screening
service, for example, the operator must collect at least the
CA 022l472~ l997-09-0~
W096/2783S PCT~S96/02273
customer's telephone number and a list of numbers not to be
screened. It is desirable, of course, to collect this data and
-.stantiate this information into the network as quickly and as
e~ficiently as possible to reduce costs and provide speedy
service. With the current AIN 100, however, i_ s necessary for a
person skilled in the operation of the SPACE software to collec-
the data and manually enter that data into a template at the
SMS 120. This has the disadvantage of taking up the valuable time
of trained employees and possibly requlring training of additional
employees in the operation of the SPACE software of the SMS 110.
The current AIN 100 has the additional disadvantage of
requiring that AIN workstations be used for the implementation of
service requests. This disadvantage reduces the accessibility of
these AIN terminals for operation and maintenance activities.
It is desirable, therefore, to have telephone service sales
representatives or data entry personnel enter in the collected
data to the AIN 100 without a large amount of training. It is
also desirable to allow the sales representatives or data entry
personnel to enter the required data into the AIN 100 from a
remote location via a cheaper or more accessible interface than is
presently available for instantiating new CPRs or modifying
existing CPRs.
DESCRIPTION OF THE INVENTION
Accordingly, the present invention is directed to an SMS
operation and support system that substantially obviates one or
=
CA 0221472~ 1997-09-0~
WO 96/2783~ PCTIUS961022'73
more of the problems due to limitations and disadvantages cf the
related art.
This invention allows relativeiy unskilled operators ~5
coordinate requests for services at a Service Negotiation System
( "SNS" ) by collecting data and sending it to the SMS quickly ana
ef r ciently. The SMS accepts collected data from the SNS,
translates the collected data into provisioning data," and
supplies the provisioning data to a Network Element Manager
( "NEM" ) . AS used in this application, a network element refers to
a component that requires data updates to provide service, e.g.,
an intelligent peripheral, an SCP, a network database, or the
like. As used in this application, "provisioning data" refers to
the data required by the NEM to create a CPR for a requested
service. After creating the CPR, the NEM transfers the CPR to a
database in an SCP. By translating collected data into
provisioning data and supplying the provisioning data to the NEM,
the SMS eliminates the need for skilled operators to create the
provisioning data.
In accordance with one feature of the invention, those
skilled in the operation of SPACE need only create a single
Service Management Program ("SMP") (similar to a CPR) for each
service. The SMP instructs the SMS to accept the collected data
in a particular manner for a given customer service, reconfigure
the data into the provisioning data format required by the NEM,
and send the provisioning data to the NEM. Once this SMP is
created, an unskilled operator can collect the data required for
each customer service request, and the SMS will insure that the
CA 0221472~ 1997-09-0~
W O 96/27835 PCTrUS96/02273
collected data gets to the network element manager in the proper
form.
In accordance with another feature of the invention, the SMS
can have multiple SMPs to receive data in multiple forma~s and
convert the data into a single provisioning data format. This
flexibllity allows the AIN of this invention to communicate wi~h a
large variety of input devices and data input schemes. The SMS,
-f configured properly, can accept its data from multiple remote
terminals operated at work sites of multiple sales
representatives, allowing quicker, more efflcient entry of
customer service requests.
Additional features and advantages of the invention will be
set forth in the description which follows, and in part will be
apparent from the description, or may be learned by practice of
the invention. The objectives and other advantages of the
invention will be realized and attained by means of the
instrumentalities and combinations particularly pointed out in the
written description and appended claims hereof as well as the
appended drawings.
To achieve these and other advantages and in accordance with
the purpose of the invention, as embodied and broadly described,
the invention recites in a telecommunications network, a method
for processing a request for services from a customer, the method
comprising the steps, executed by a data processor, of: receiving
a service request from the customer, the service request including
a function name, corresponding to a network service, and
corresponding data; generating provisioning data corresponding to
CA 0221472~ 1997-09-0~
W096/27835 ~CT~S96S0~273
information necessary for a network element to process the network
service based on the data received from the customer; and sending
the provisioning data to the network element.
It is to be unders~ood that both the roregoing genera_
description and the following detailed description are exemDlary
and explanatory and are intended to provide further explanation o-
the invention as claimed.
BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings, which are incorporated in and
constitute a part o~ the speci~ication, illustrate presently
preferred implementations of the invention and, together with the
general description given above and the detailed description of
the preferred implementations given below, serve to explain the
principles of the invention.
Fig. 1 is a block diagram of an existing AIN;
Fig. 2A is a block diagram of the SMS in Fig. 1;
Fig. 2B is a block diagram of the SCP in Fig. 1;;
Fig. 3 is a block diagram of an AIN using an SMS in
accordance with one embodiment of the present invention;
Fig. 4 is a block diagram of the software of the AIN in Fig.
3 in accordance with one embodiment of the present invention;
Fig. 5A is a block diagram of the SCE in Fig. 3 in accordance
with one embodiment of the present invention;
Fig. 5B is a block diagram of the NEM in Fig. 3 in accordance
with one embodiment of the present invention;
CA 0221472~ 1997-09-o~
W096/278~5 PCT~S96/02273
Fig. 5C ls a block diagram of the SMS in Fig. 3 in accordance
with one embodiment of the present invention.
Fig. 6 is a block diagram of a service local area ne~work -n
accordance with one embodiment of the present invention;
Fig. 7A is a flow diagram showing generally the opera~ion c
the SNS of Fig. 3 in accordance with one embodiment of the presen-
invention;
Fig. 7B is a flow diagram showing generally the operation of
the SMS of Fig. 3 in accordance with one embodiment of the present
invention;
Fig. 7C is a flow diagram showing generally the operation of
the NFM of Fig. 3 in accordance with one embodiment of the presenr
invention;
Fig. 7D is a flow diagram showing generally the operation of
the switch interface system of Fig. 3 in accordance with one
embodiment of the present invention;
Fig. 8 is a flow diagram showing the creation of SMP~s and
CPRs in accordance with one embodiment of the present invention;
Fig. 9 is a flow chart illustrating of the operation of the
advanced intelligent network of Fig. 3 in processing a request for
service in accordance with one embodiment of the present
invention;
Fig. 10 is a flow diagram of the operation of an SMS showing
the manipulation of saved files in accordance with one embodiment
of the present invention;
- 10
CA 022l472~ lss7-os-o~
W096/27835 PCT~S96102273
Fig. 11 is a flow chart of the operation of the SMS in
processlng requests from an SNS in accordance with one embodiment
of the present invention;
Fig. 12 is a graphical process diagram of a service
management program for a originating call screening service
management program in accordance with one embodimen~ of the
present invention;
3EST MODE FOR CARRYING OUT THE INVENTION
Reference will now be made in detail to the construction and
operatlon of preferred implementations of the present invention
which are illustrated in the accompanying drawings. In those
drawings, like elements and operations are designated with the
same reference numbers.
The following description of the preferred implementations of
the present inventlon is only exemplary of the invention. The
present invention is not limited to these implementations, but may
be reallzed by other implementations.
Fig. 3 illustrates a preferred embodiment of an AIN 300 in
accordance with this invention. The AIN 300 includes a Service
Negotiation System ("SNS") 305, an SMS 310, a subscriber database
315, a Service Creation Element ("SCE") 325, a service local area
network ("LAN") 335, an NEM 345, a switch interface system 355,
SCPs 120 and 130, STPs 140 and 150, and SSPs 160 and 170.
The SCPs 120 and 130 preferably include the MSAP software for
executing CPRs necessary to process calls received by the SSPs 160
and 170 from telephones 180. In a preferred embodiment, the NEM
CA 022l472~ l997-09-0~
W096/27835 PCT~S96/02273
345 is connected to two SCPs 120 and 130, although il is
understood that the number of SCPs connected to the NEM 345 may
vary.
mhe SNS 305 preferably comprises one or more computers (not
shown) connec~ed to the SMS 310 via modem communication lines, bu;
can incluae any means for providing data to the SMS 310.
Fig. 4 illustrates the software used in a preferred
embodimen~ of the AIN 300. The software includes a modif ed
version of the SPACE software 410, a modified version of the MSAP
software 430, a plurality of SMPs 420, the SPACE software 440, the
MSAP software 460, a plurality of CPRs 450, and a plurality of
triggers 470. The SMPs 420 control the operation of the SMS 310
in translating data collected by the SNS 305 into the provisioning
data required by the NEM 345 for instantiating new services. The
SMPs 420 are created by the modified SPACE software 410,
preferably contained in the SCE 325, and are executed by the
modified MSAP software 430, preferably contained in the SMS 310.
The CPRs 450 control the operation of the SCPs 120 and 130 in
processing calls received at the SSPs 160 and 170. The CPRs 450
are created by the SPACE software 440, preferably contained in the
NEM 345, based on the provisioning data and are executed by the
MSAP software 460, preferably contained in the SCPs 120 and 130.
The triggers 470 respond to calls to or from the SSPs 160 and 170
and request that the MSAP execute particular CPRs based on theses
calls.
The modified SPACE software 410 includes additional nodes
tailored for the SMP's data conversion functions as described
- 12 -
CA 0221472~ 1997-os-o~
W096127835 PCT~S96102273
below. The modified MSAP software 430 is designed to process the
additional nodes provided in the modified SPACE software 410.
Both the modified SPACE software 410 and the modified MSAP
software 430 are proprietary software applications owned by
Bellcore, the assignee of this application.
In accordance with the present invention, the SMPs 420 are
created using the modified SPACE software 410 in a manner similar
to the creation of the CPRs 450. Individual SMPs can be tailored
by operating personnel to sequence and control the execution of
service management functions for each particular service and for
each particular format of data collected by the SNS 305. The SMPs
420 correspond to high level, displayed representations (graphs)
of the desired service management functions. As with CPRs, these
graphs are comprised of "nodes," "decision boxes,1' and "branches,"
with each node representing a high level instruction for the
execution of the service management function.
Fig. 5A is a functional block diagram of a preferred
embodiment of an SCE 325. SCE 325 comprises CPU 558, database
552, operator interface 44, and customized processing ("CP")
application 560. Operator interface 44 comprises display 48,
keyboard 50 and mouse 52, each connected to CPU 558.
The CP application 560 includes creation portion 564 and
execution portion 566. The creation portion 564 of SCE 325
preferably comprises the modified SPACE software. The execution
portion 566 of SCE 325 preferably comprises the modified MSAP
software. Through the CP application, an operator creates and, in
certain circumstances, executes the SMP associated with a given
CA 022l472~ lss7-os-o~
W096/27835 PCT~S96/02273
service. The operator also uses the CP application to create any
tables, databases, or definitions required for the executi_n of
the SMPs. The SMPs and additlonal data are stored in a database
552. _ndividual SMPs are created for each service and i..c_cate
~he data chat will be collected by the SNS 305 and sent to ~he SMS
310, and the provisioning data required by the NEM for
instantiating the service. These SMPs dictate how the SMS 310
will receive data collected by the SNS 305 and translate the
collected data into the provisioning data required by the NEM 335
to instantiate a new service. SMPs may be executed in the SCE 325
through inputs received from a simulated SNS or testing SNS (no~
shown).
Fig. 5B is a functional block diagram of a preferred
embodiment of the NEM 345. NEM 345 comprises CPU 568, database
562, and CS applicatlon 246. CS application preferably includes
service creation portion 254. The service creation portion 254
preferably comprises the SPACE software.
The NEM 345 preferably implements template programs to take
provisioning data recei~ed from the SMS 310 and create the CPRs
necessary for the SCPs 120 and 130 to process telephone calls.
Fig. 5C is a functional block diagram of a preferred
embodiment of an SMS 310. SMS 310 preferably comprises CPU 540,
database 542, and CP application 560. CP application 560 includes
execution portion 566. The execution portion 566 of SMS 310
preferably comprises the modified MSAP software.
Referring again to Fig. 3, the subscriber database 315
preferably comprises an Oracle~ database stored on a hard disk
CA 022l472~ l997-09-0~
W096/278~5 ~CT~S96tO2273
drive, although it may be on any kind of s~orage medium that will
allow for easy access by the SMS 310. The subscriber database 3 -
preferably includes an entry for each customer containing at leas.
the customer's name, telephone number, and 'ist of subscribed
services and related information and data concerning the
subscribed services. The subscriber database may also nclude
additional data such as the mailing address of the customer,
billing information, or the like.
The SSPs 160 and 170 preferably comprise any commercially
available telephone switch used for processing telephone calls,
e.g., the AT&T 5ESS switch, the AT&T lAESS switch, or the Norther-
Telecom DMS 100 switch.
The switch interface system 355 preferably comprises a
standard MARCH interface device, as disclosed in the Bellcore
document SOAC/MAS Interface S~ecification, document reference
BD-SOAC-SPEC-002, but can be any interface device that will
receive in~ormation from the SNS 305 required for processing
telephone calls and send it to SSPs 160 and 170. This information
includes, e.g., the trigger data indicating when and how the SSPs
160 and 170 must query the SCPs 120 and 130 during call
processing. In an alternate embodiment, the switch interface
system 355 can be connected via an interface to the SMS in
addition to or instead of to the SNS 305.
Fig. 6 shows a preferred embodiment of the service LAN 335.
As shown, LAN 335 preferably includes an operations support cente-
("OSC") 602, a service assurance group 604, one or more remote
users 606, one or more remote operation support systems ("OSS")
CA 022l472~ l997-09-0~
W096/27835 PCT~S96/02273
608, a user administration group ("UAG") 610, and a maintenance
and operations console ("MOC") 612. The OSC 602, UAG 610, and MOC
5-2 are connected directly to the SMS 310 via LAN 335. ~he remore
users 606 and the remote OSSs 608 can connect to the L~N from a
remote location preferably via the internet using a transmissior.
control pro~ocol/internet protocol ("TCP/IP"). TCP/IP is
àescribed in a series of technical reports called Intern_t
~ecuests For Ccmments, which are available from the Network
Tnformation Center. The operation of the service LAN 335 will be
described in more detail below.
Referring again to Fig. 3, in accordance with the present
invention, during operation of AIN 300, the SMS 310 receives data
from the SNS 305 relating to the activation or alteration of the
services subscribed to by a customer, for example, data concerning
a new connection, a change of service, or a disconnection. The
data may include various types of service order passes for
communicating with other parts of the AIN 300, e.g., notification
of completion, correction, or cancellation. The connection
between the SNS 305 and the SMS 310 helps coordinate the AIN
provisioning flow and ensure that the subscriber database 315, the
SCPs 120 and 130, and the SSPs 160 and 170 are all updated in the
proper order. In implementing the flow of collected data from the
SNS 305, the SMS 310 correlates data received from the SNS 305
with associated subscription data, if any, contained in the
subscriber database 315. As used in this invention, "subscription
data" refers to information relating to past, active, and pending
data received by the SMS 310 from the SNS 305. The SNS 305 can
CA 022l472~ lss7-os-o~
W096/27835 PCT~S96102273
also, as necessary, retrieve and update subscription data stored
in the subscriber database 315. The connection between the SNS
305 and the SMS 310 can, thereIore, be used by the SNS 305 to
retrieve information relating to the current status of customer
subscriptions, and then send updated subscription data .o ~he SM5
310 based on that data. Alternatively, the interface could be
used by the SNS 305 to retrieve current views of subscript~ons
when customers request such information or -eport troubles.
Access to the SMS 310 by ~ultiple different inquiries from
the SNS 305 is also within the scope of the invention.
The SMS 310 administers the subscriber database 315 by, for
example, creating, deleting, updating, and retrieving subscription
data in the subscriber database 315. The SMS 310, in addition to
operating based on information from the SNS 305, also accesses and
administers the subscriber database 315 in response to inquiries
made ~rom the ser~ice LAN 335. The subscriber database 315 is
preferably connected directly to the SMS 310, but can also be a
remote database accessed by a remote interface, such as the
SQL*Net interface. The SQL~Net interface is described in the
SOL~Net TCP/IP User's Guide (version 1.2) available from Oracle,
Inc.
Access to the SMS 310 by multiple inquiries from the SNS 305
is also within the scope of the invention. The SMS 310 and the
SNS 305 are preferably connected using a TCP/IP interface, but can
be implemented using any interface that will allow the data to be
passed between the SNS 305 and the SMS 310. The messages passed
between the SNS and the SMS preferably have the data coded
- 17 -
CA 022l472~ l997-09-0~
W096/27835 PCT~S96/02273
according to Abstract Syntax Notation One ("ASN.1~). ASN.1 is a
language-independent, operating system-independent notation for
defining abstract data types and is described in CCITT
Recommendations X.208 and X.409, both documents produced by
;3ellcore.
The SMS 310 receives instructions from the SCE 325 regard ng
the processing of data received from the SNS 305 for transmit_al
to the NEM 345 for activating subscriptions in the SCPs '20 and
130. These instructions preferably comprise SMPs created with the
modified SPACE system. These SMPs created by the SCE 32S instruc~
the SMS 310 on how to take information in one form and convert i~
into a form acceptable for entry into a CPR template, i.e.,
provisioning data.
The interface between the SMS 310 and the SCE 325 may be a
physical connection, such as an RS-232 interface, internet
connection, modem connection, or the like, or the SCE 325 may be
physically separate from the SMS 310 and the programs can be
loaded onto floppy disks at the SCE 325 and hand carried from the
SCE 325 to the SMS 310.
The interface between the SMS 310 and the NEM 345 is
preferably a TCP/IP interface with the data encoded according to
ASN.1. The SMS 310 controls message traffic to the NEM 345 and
queues messages for later transmittal to the NEM 345 when the SMS
310 is temporarily out of contact with the NEM 345.
SMS 310 can interface with multiple NEMs 345 and can
provision each with the appropriate provisioning data for a given
customer based on the geographic address of the customer the
CA 022l472~ lss7-os-o~
W096/2783S PCT~S96102273
geograpAic area servicéd by each NEM 345 and SCP pair 120 and 130.
This way the SMS 310 insures that it provisions a customer~s
service for the SCPs 120 and 130 that service the seographical
area in which the customer lives.
In a preferred embodiment, the SNS 305 is connected -_ ~he
switch interface system 355 to provide trigger informatior. to the
SSPs 160 and 170. ~ust as the SCPs 120 and 130 receive CPRs
including the proper information to process calls and implement
services in accordance with the invention, the SSPs receive
trigger data to instruct them as to what CPRs to request
activation of by the SCPs 120 and 130, and when to request the
activation.
In an alternate embodiment, SMS 310 may be directly connected
to the switch interface system 355 to send trigger data to SSPs
160 and 170, and the connection between the SNS 305 and the switch
interface system 355 may be deleted. In this alternate embodiment
the SMS 310 sends the necessary trigger data in the proper format
to the switch interface device based on information received from
the SNS 305.
In addition to the interface between the SMS 310 and the SCE
325, there also e~ists an interface between the SMS 310 and the
service LAN 335. Via this interface, operators can view and
update subscription data in the subscriber database 315. Updates
to subscription data based on data entered by this method are
treated just like updates based on data collected by the SNS 305.
In both cases, the SMS 310 will proceed to convert collected data
CA 022l472~ l997-o9-o~
W096/2783~ PCT~S96/02273
to provisioning data and send the provisioning data to the NEM
345.
Figs. 7A-7D show generally the operation of the AIN 300 in
accordance with a preferred embodiment of the present invention.
Fig. 7A shows generally the operation of the SNS 305. Fig. 7B
shows generally the operation of the SMS 310. Fig. 7C shows
generally the operation of the NEM 335. Fig. 7D shows generaily
the operation of the switch interface system 355.
As seen in Fig. 7A, the SNS 305 initially receives a requesc
for new service from a customer (step 710). The SNS 305 then
collects data from the customer (step 712) and sends the collected
data to the SMS 310 (step 714). Finally, based on the collected
data, the SNS 305 creates the trigger data necessary for the SSPs
160 and 170 to correctly process calls in accordance with the new
service (step 716) and sends the trigger data to the switch
interface system 355 (step 718).
As seen in Fig. 7B, the SMS 310 receives the collected data
from the SNS 305 (step 720), converts the collected data into the
provisioning data required by the NEM 335 to instantiate the new
service (step 722), and sends the provisioning data to the NEM 335
(step 724).
As seen in Fig. 7C, the NEM receives the provisioning data
from the SMS 310 (step 730), fills the necessary templates with
the provisioning data (step 732), and instantiates the requested
service via the filled template (step 734).
- 20 -
CA 022l472~ l997-09-0~
W096/27835 PCT~S96/02273
As seen in Fig. 7D, the switch interface system receives the
trigger data from the SNS 305 (step 740) and places the trigger
data to the SSPs (step 742) .
Fig. 8 is a flow diagram showing the creation of SMPs and
CPRs and illustrates this commonality of service creation in the
present invention. The creation portion 564 of CP application 560
(Fig. 5A) includes all of the functions available in the S2ACE
software as well as those avallable only in the modi~ied SPACE
software. As a result, an operator 802 may use the SCE 325 to
create CPRs 806 for execution by SCPs 120 and 130 and may also use
the same SCE 325 to create SMPs 804 for execution by SMS 310.
A preferred method of operation o~ the AIN 300 including the
SMS 310 in accordance with this invention will now be described
with reference to Figs. 9A and 9B which show processing steps of
the AIN 300 to process a request from a customer for the
activation or alteration of a service.
The processing begins when a customer requests to add,
change, or delete a service provided by the AIN 300, i . e., submits
a "change service" order, and gives the request, to the SNS 305
(step 908). The SNS 305 then collects data from the customer
required to add, change, or delete the service (step 910). Based
on the information collected from the customer, the SNS 305 sends
the data in an agreed upon format to the SMS 310 (step 912).
Using the data from the SNS 305, the SMS 310 determines the
appropriate SMP to execute and based on that SMP, verifies that
necessary data has been collected and received, and validates the
data, i.e., determines if sufficient data has been submitted in a
- 21 -
CA 0221472~ 1997-09-05
W 096/27835 PCTrUS96/02273
proper format with acceptable data values (step 914). If the data
is verified and valid, the SMS 310 then translates the collected
da~a from its initial data format to a provisioning data format
!s~ep 9~6) and saves the provisioning data as subscription data
~nder .he status of a pending view (step 917). If ~n step 314,
~he data is either not verified or not valid, the SMS enters an
error s~ate and ceases processing the request (step 915).
After the collected data is converted to provisioning data,
the SMS checks the due date of the request (step 918). If SMS
determines that the due date requested by the SNS 305 ls
immediate, the SMS 310 sends the provisioning data to the NEM 345
(step 922). If the due date is some time in the future, the SMS
310 exits the process (step 920) and continues with other
operations until it determines that the requested due date has
arrived, at which time it returns (step 921) and executes step
922.
Upon receiving the provisioning data, the NEM 345 populates
the template associated with the service requested by the customer
with the supplied provisioning data to complete the required CPR
for processing the customer's change service order (step 924).
Then the NEM 345 updates the databases associated with the SCPs
120 and 130 with the resulting CPR (step 926). Next, the NEM
determines if any errors have occurred during the creation or
modification of the required CPR (step 928). If the NEM 345
detects no errors in step 928, the NEM 345 responds to the SMS 310
with a message acknowledging the successful update (step 930). I~
the NEM 345 does detect an error in step 928, the NEM 345 enters
CA 022l472~ lss7-os-o~
W096/27835 PCT~S96102273
an error state and ceases processing the request (step 923). Cnce
the SMS 310 receives the acknowledge from the NEM 345, the SMS 31
responds to the SNS 305 with an acknowledge signal (step 932).
The SMS 310 then stores ~he provisioning data in its subsc~iber
database 315 under the status ~active~ (step 934).
The SNS 305, upon receiving the acknowledge signal, sends to
the switch interface sys~em 355 a packet of information containing
the trigger data (step 936). As used in this application,
~trigger data" is the data necessary for the switch interface
system 355 to place the required triggers in the SSPs 160 and 170
for properly accesslng the SCPs 120 and 130 to process the new
service. The switch interface system then checks the due date of
the service request (step 938). If the switch interface system
355 determines that the due date for starting the service is
immediate, the switch interface system 355 sends the AIN triggers
to the SSPs 160 and 170 (step 942) . If the due date is some time
in the future, the switch interface system 355 exits the process
(step 940) and continues with other operations until it determines
that the requested due date has arrived, at which time the switch
interface system 355 returns (step 941) and executes step 942.
As the switch interface system sends the triggers to the SSPs
160 and 17Q, it determines if any errors occurred during
transmission (step 946). If the switch interface system 355
detects any errors, it enters an error state and ceases processins
the request (step 944). If the switch interface system 355
detects no errors in the sending of the triggers to the SSPs 160
and 170, the switch interface system 355 sends an acknowledgment
- 23 -
CA 022l472~ l997-09-0~
W096t27835 PCT~S96/02273
from the SSPs 160 and 170 to the SNS 305 (step 948). SNS 305
later sends a signal to SMS 310 acknowledging that the AI~ 300 has
completed processing the service request (step 950).
Tn al'ernate embodiments, step 936 could be carried out
àirectly by the SMS 310, avoiding the need for step 950. _n ~h s
alternate embodiment, the switch interface system 355 sends an
acknowledgment directly to the SMS 310 as step 948.
The subscriber database 315 records the history of a
customer's subscriptions from the time collected data is first
sent to the SMS 310. SMS 310 maintains a set of subscription data
re ating to a particular customers service subscription, including
multiple "views" of that subscription from its initial request
through any additional requests for modification or cancellation.
These different views reflect the history of that service for the
customer. SMS 310 tracks the different views by assigning a
"status" to each piece of data indicating what stage of
implementation the request has reached. The views supported by
the SMS 310 and subscrlption status indications are summarized as
follows, with reference to Figs. 10 and 11.
As shown in Fig. 10, the SMS 310 saves the collected data as
subscription data in a saved view 1002, exception views 1004 and
1010, a pended view 1006, a sending view 1008, a master view 1012,
and a historical view 1014. The saved view 1002 contains a status
of "saved" which indicates that the collected data has been
received by the SMS 310, but has not been validated or translated.
The pended view 1006 contains a status of "pending" which
indicates that the collected data has successfully been translated
CA 022l472~ l997-09-0~
w096l27835 PCT~S96102273
to provisioning data, has passed all validations, and is awaitir.g
posting to the NEM 345. The sending view 1008 contains a status
of llsending" which indicates that provisioning data correspondi.,g
to the data collected by the SNS 305 is currently being posted to
the NEM 345. ~his view preferably exists only frcm the t-me the
SMS 310 begins the posting process until the posting is czmpleted,
or unt-l an error ~s encountered. The exception views 1004 and
1010 contain a status of "failed" which indicates that the
collected data or provisioning data has either failed the
validation (exception view 1004) or an error was encoun~ered
during the posting process (exception view lO10). The master view
1012 contains a status of "active" which indicates that this is
the data corresponding to the CPR currently contained in the
database associated with the SCPs 120 and 130. The hlstorical
view 1014 contains a copy of the most recent master view 1012 that
was successfully posted to the NEM 345 prior to the present master
view 1012.
Fig. 11 is a flow chart of the operation of the SMS 310 and
the subscriber database 315 as they relate to Fig. 10. The SMS
310 initially receives collected data from the SNS 305, which
reflects the customer's request for new or altered service and
saves the data as subscription data in a saved view (step 1102).
The SMS 310 then determines whether this data requires any
corrections or has resulted in any errors, i.e., validates the
data (step 1104). If there are errors or required corrections,
the SMS 310 saves the collected data as subscription data in an
"exception" view (step 1106) and exits the processlng of the
CA 022l472~ l997-09-0~
W096/27835 PCT~S96/02273
request (step 1107). If the SMS 310 later receives data providing
correction of the error, the SMS 310 returns (step 1114), makes
the correction (step 1113), and proceeds to step 1108.
If no errors are detected in the initial request in
s~ep llG4, the SMS 310 saves the current data as su~script on data
-n a pended view tstep 1108). Next, the SMS determines when the
request is due to be instantiated (step 1110). If the SMS 310
determines that the request is due to be instantiated immediately,
the SMS 310 sends the request, in the form of provisioning data,
to the SCPs 120 and 130 via the NEM 345 (step 1116). If the SMS
310 determines that the due date is some time in the future, the
SMS 310 exits the process (step 1112) and continues with other
operations until it determines that the requested due date has
arrived, at which time it returns (step 1114) and executes step
1116~ Upon sending the provisioning data, the SMS 310 then
determines whether the sending of provisioning data has resulted
in any errors (step 1118).
As in step 1104, if there are any detected errors, the SMS
310 saves the current provisioning data as subscription data in an
exception view (step 1120) and exists the process (step 1121). If
the SMS 310 later receives data providing correction of the error,
the SMS 310 returns to the process (step 1124), makes the
correction (step 1125), resends the corrected provisioning data
(step 1116), and rechecks whether its transmittal was successful
(step 1118).
If the sending of provisioning data from the SMS 310 to the
NEM 345 proceeds with no errors in step 1118, the SMS 310 saves
- 26 -
CA 022l472~ lss7-os-o~
W096l27835 PCT~S96102273
the subscription data in the present master view as a subscription
data in the historic view ( st2p 1122) and then saves the current
data as subscription data in the master view (step il23).
SMS 310 provides flexibility to manage a wide variety cf
services througn the mechanism of SMPs. The SMPs are crea~ed v~a
the same or a similar graphical user interface used to create C~Rs
for the SCP 120 and 130. Individual SMPs can be tailored by
operating personnel to sequence and control the execution c~
service management functions for each particular service.
For a given service, an SMP and any associated data tables
allow operators to specify the particular data items expected by
the SMS 310, the source of each data item, and the processing
steps necessary to convert the collected data into the
provisioning data required by the NEM 345. The operators
preferably specify this conversion by specifying which of a
plurality of NEMs 345 to provision, which NEM template should be
populated with the data, and the error handling for a variety of
conditions, e.g., faulty or missing data, incorrect area of
service, no response from the NEM system 345, or the like.
The creation of a new AIN service as it relates to the SMS
310 will be described below with reference to Fig. 12. As
discussed, AIN service creation typically starts with an operator
graphically creating and testing the logic for the new service.
Once this logic is tested in the call processing environment, the
developer creates a CPR "template" for the service. This template
represents the provisioning data needed for creation of a CPR for
the new service. Service templates are described more fully in
- 27 -
CA 022l472~ l997-09-0~
W096;~ 35 PCT~S96/02273
the U.S. patent applications which have been incorporated by
reference above.
With data collected from ~he customer via the SNS 305, and
the provisioning data required by the NEM 345 for the creaticn ~~
a CPR for ~he new service, the developer can create the SMP neede~
to coordinate the creation of the new service. The creation or an
SMP will be illustrated by describing the processing of a requesc
for a originating call screening ("OCS") service will be
explained.
OCS is a mass market service that allows customers to
"screen" incoming calls. Typical collected data includes the
customer's telephone number, their list of numbers not to be
screened, an override PIN used to bypass the screening, a
screening list PIN (used by the customer to update the screening
list telephone numbers), and a forwarding number (to which callers
who have been screened are directed, e.g., the customer's voice
mailbox).
Fig. 12 illustrates an OCS SMP in accordance with one
embodiment of this invention. The OCS SMP controls the SMS 310
behavior during conversion of collected data received from the SNS
305 into provisioning data for filing a template in the NEM 345 to
create the CPR for the OCS service.
When an OCS transaction request is recelved by SMS 310, the
SMS 310 executes the OCS SMP. As used in this application, a
"transaction request" for a given service refers to any piece of
data received by the SMS 310 pertaining to the creation, deletion,
or alteration of a CPR for that service. Upon entry into the OCS
- 28 -
CA 022l472~ lss7-os-o~
w096l2783~ PCT~S96102273
SMP (step 1202), the OCS SMP determines where the transac~ion
request came from (step 1204). If the transaction request came
rom the SNS 305, the processing of the SMP branches to an SNS
path (step 1206). In the SNS path, the SMS 310 determines the
specific type c- request that is being made, i.e., reques. 'or new
service, update of old service, cancel service, etc., based on
information in the coliected data (step 1212). Then, depending cn
the type of request made, the processing branches to the section
of the SMP designed to handle that request type (steps 1218-1224).
While handling a particular request, the SMP may temporarily hand
over processing control to a second SMP to perform one part of th.e
request. The SMS 310 will execute this other SMP and then return
processing control to the original SMP. These handover processes
include processes for adding new OCS service (step 1230),
cancelling a service (step 1232), etc.
If step 1204 determines that the request comes internally
from the SMS 310, the processing of the SMP branches to an
internal path (step 1208), immediately during processing or on the
subscription due date and time, and the posting process begins
(step 1216). The SM5 310 then hands over process control to an
SMP for sending data (step 1234) which retrieves the provisioning
data from the subscriber database 315 and then sends provisioning
data to the NEM 345. In this embodiment, since there is only one
function in the internal branch, step 1214 must choose the posting
branch (step 1226).
If step 1204 determines that the request comes from the NEM
335, the processing of the SMP branches to an NEM path (step
- 29 -
CA 022l472~ l997-09-0~
W096/27835 PCT~S96/02273
1210). As with the internal branch, in this embodiment .here s
only one function in the NEM branch, so step 1216 must choose the
response branch (step 1228). The response branch handles a
-esponse to the provisioning request Crom the NEM 345 by :-andi~.g
over control to an SMP for accepting the response. ~hat SMP
analyzes the response, updates the subscription data in _he
subscriber database 315 in SMS 310, and sends an appropr ate
response back to SNS 305.
It is understood that all of these secondary SMPs used in the
handover processes could be part of the OCS SMP. They are
preferably saved as separate SMPs to reduce the complexity and
creation cost of the individual SMPs. In this way a "basic" SMP
may be accessed essentially as a node by multiple other SMPs.
In accordance with the present lnvention, the creation
portion 464 of the CP application 460 in the SCE 325 has been
enhanced and extended to include new programming elements to
support functions of the SMS 310 which are not performed by the
SCPs 120 and 130. These new elements are in the form of
additional nodes to use in the creation of the graphs used to make
the SMPs. In addition, SMS-specific functions have been added to
the execution portion of the CP application in the SMS 310 and the
SCE 325.
The basic programmability features available wlth the MSAP
and SPACE software are outlined below, followed by the preferred
enhancements and extensions of this invention. The functions
listed below include basic nodes existing in the SPACE software as
well as additional node types.
- 30 -
CA 022l472~ lss7-os-o~
W096/27835 PCT~S96/02273
Each of the following types of nodes are available _or
creating SMPs through a graphical user interface: program
nitiation, decision making, management of table data, gathering
administrative data, interfacing with external systems, _es~ing
applications, managing applications, adding new services, _~voki~_
an SMP, and accessing a database.
A "program initiation" function starts the SMP f owing. n
the case of call processing, using CPRs, this function determines
when a switch encounters a trigger while processing a call, e.g.,
the caller dials a specific number, receives a call, or goes off-
hook. A program inltiation for an SMS 310 starts in response to
an invoke SMP function. The SMS 310 invokes SMP function whenever
the SMS 310 receives any data that it identifies as relating to a
particular service associated with an SMP.
"Decision making" functions enable an SMP to make logical
decisions which effect the processing flow of data through the SMS
310. For example, an SMP for processing collected data for an AIN
service may have an area-of-service decision to see if the
customer's geographical area is served by particular switches.
Based upon the decision, the service request may continue or be
handled by exception processing routines.
"Management of table data" functions allow the application t~
manipulate data tables. SPACE software includes the ability to
create, populate, access, and update data in tables. Preferably
these tables are stored internally by the SMS 310 or SCPs 120 and
130 as regular Oracle~ tables. Table data may contain
provisioning data relating to area-of-service, service parameter
CA 0221472~ 1997-09-0~
W O 96/2783S PCTrUS96/02273
choices, or other information which is required by the NEM 345 fo-
creatlng a CPR for a given service. During provisioning
t~ansactions, between the SMS 310 and the NEM 345, these ~ables
are accessed as part of a process to validate an crder. Tables
may also be used to store results of processing, such as e-ror
orders or pended orders.
"Gathering administrat ve data" functions allow the SMP
designer to include data collection and reporting in an SMP. Data
collection may be specified in the SMP for any network event or
situation, such as creation of a new service subscription,
cancellation of a service subscription etc. When this network
event occurs, the collected data is then sent to a data and
reports system ("DRS") for retention and reporting.
"Interfacing with external systems" functions allow SMP
designers to access data in external systems, such as other OSS
systems. In the SPACE system, GetData and SendData nodes or
processing routines retrieve and update data in external systems.
The GetData and SendData nodes currently support systems on TCP/I~
networks, 3270 SNA networks, and SS7 network databases.
"Testing applications" functions allow the application to
perform testing operations. SPACE software includes built-in
testing tools which are used for initial testing and can also be
invoked by the SMS 310 for diagnosis and trouble shooting.
"Managing application" functions make it possible for an
operator to modify applications and activate them in the SMS 310.
Managing application functions include specific functions to
CA 022l472~ l997-o9-o~
W~96/27835 PCT~S96102273
coordinate multlple SMPs, te~plates, and convert collected data
into provisioning data.
Adding new service" functions allows an operator to add a
~ew service within an SMP. SMPs for new services will generally
be able tO use the exist ng programming tools to add new data
bases, change or add editing rules, support new AIN service
_eatures or provide service management reports. In SPACE, Ihe
GetData, SendData and Play Application generic contract nodes can
be used to get data from different external OSSs or to invoke
specially written new software for highly unusual processing or to
access OSS data.
The ~'invoke SMP" function allows the application such as an
SMP, to invoke another SMP. The current AIN allows for service
initiation of CPRs through the AIN-defined triggers which are
implemented in SSPs 160 and 170. These static AIN triggers are
not adequate for SMP initiation and are replaced in the SMS 310
with the invoke SMP function. All SMPs are initiated by the
invoke SMP function. An invoke SMP transaction occurs when data
is received from a cooperating system indica~ing the SMP should be
involced, e.g., the transmission of data. An example of this can
be seen in the operation of the OCS SMP, with reference to Fig.
12. In Fig 12, the SMP can be initiated from the SNS 305 causing
the SMP to branch to step 1206, the SMS 310, i.e., internally,
causing the SMP to branch to step 1208, or the NEM 345 causing the
~ SMP to branch to step 1210.
A preferred embodiment of the invention includes a number of
facilities in the AIN 300 which send invoke SMP transactions to
- 33 -
CA 022l472~ lss7-os-o~
W096/27835 PCT~S96/02273
the execution environment in the SMS 310. The most often used are
the connection between the SMS 310 and the SNS 305, which will
package data as invoke SMP transactions, and the interface between
the LAN 335 and the SMS 310 which will allow administrative and
operator personnel to initiate SMPs.
The database access functions allow the SMP to access data
from an external or an lnternal database. In the SPACE system,
database access functions include generic Data Layer Building
Block ("DLBB") primitives, Table Access Primitives, GetData
Primitives, and SendData Primitives, which are extensively used
for the SMS 310, especially for accessing the subscriber database
315.
In addition, a preferred embodiment of the CP application of
the present invention enhances several functions of the standard
SPACE software. For example, the SPACE software currently allows
for the definition of tables which are used for AIN services.
According to a preferred embodiment of the present invention,
these facilities are extended to allow SMP developers to define
more complex databases which are required for the subscriber
databases. These databases are directly available on the SMS 310
execution environment through existing primitives (Table Access,
GetData and SendData). Preferably these databases are created as
Oracle~ databases.
The SMS 310 also includes a number of additional functions
which are not available in the current version of the SPACE
software. These functions relate to provisioning interfaces,
- 34 -
CA 022l472~ l997-09-0~
W096/27835 PCT~S96102273
multiple views, improved transaction processing, area-of-service
network functioning, open access, and protocol support.
~ Provisioning interface transactions for the ir.terface be~ween
the SMS 3iO and the NEM 345 are generated by SMPs which provids
for mult_ple views cc a given request for service. Preser.tly, ~M
functions do not keep multiple views of a given request fcr
execution of a CPR. The SMS 310 provides for improved transaction
processing by supporting database rollback facilities. The SMS
310 allows for subscriptions to be sent to a network system for
any geographic area and does not limit transmission to a mated
pair of SCPs. The SMS 310 will also accept requests for services
obtained by GetData/SendData functions from other OSS systems,
which provides for the open access envisioned by emerging service
needs. The requests obtained by GetData/SendData functions
preferably operate over a variety of network protocols and can be
extended to lnclude protocol handlers for customer-specific
situations.
A preferred embodiment of the SMS in the present invention
also includes a generic process layer building block ("PLBB")
called the play application primitive. The play application
primitive is used for AIN services to initiate processes which
operate on intelligent peripherals ("IPs") for specialized
applications, such as accessing paging networks.
The play application primitive also provides the ability to
- initiate external processes in a cooperating system. This allows
the SMS to reuse certain processes, some of which can be provided
for immediate use, and some of which may be developed by the
CA 022l472~ l997-09-0~
W096l27835 PCT~S96/02273
operator to meet a customer's individual needs. For example, an
AIN service that must provlsion a digitized recording for a
customer may use a piay application, "Download Speech,~ to send
instruc ions to an IP provisloning system to activate the
customized announcement.
Another example of the use of the play application primitive
is for cus~omer self-provisioning of services. A customer may for
example, call a "service desk" application to modify
characteristics of their service themselves. The AIN service desk
application issues a play application to the SMS 310 to manage the
change in the effected systems. This may be done, e.g., with the
use of a touch tone telephone. In this example, the play
application comes into the SMS 310 as an invoke SMP, and the
invoked SMP handles validation and distributlon of the customers
changes.
In a preferred embodiment of this invention, third party
providers have the option of using their own system to communicate
with SMS 310, using a standard OSS gateway. Alternatively, the
providers have access to SMS 310 via supported application
terminals. Since SMS 310 provides an open contract interface for
transaction requests, third party providers can take advantage of
these same communications protocols.
Third party providers using their own system to maintain
their customers will use the OSS gateway for access into the AIN
system including the SMS of the present invention. With this
approach, the interface is system-to-system and does not require
any SMS 310 display "screens" for maintenance of data, although
- 36 -
CA 022l472~ l997-09-0~
W096/27835 PCT~S96/02273
third party providers may access the SMS 310 using screens for
provisioning and maintaining their customers AIN service data.
These screens provide the necessary data element "templates"
required for gathering the necessary data rrom their serv_ce
customers.
The operators o~ the SMS 310 have the ability to prohibit
third party viewing of screens used for the main~enance ana
operations of the SMS 310 system however. These screens are
preferably available only to operating personnel responsible for
such tasks.
In addition, the SMS 310 may provide security veri~ication O r
messages through physical communication addresses, message type,
request type, and a security field. All transaction requests from
a third party provider are screened through security to help
ensure that the service provider is authorized to access the SMS
310 and execute the requested transaction. There is always a
security ~ield associated with any transactions with SMS 310
requesting a change in service. This security field contains data
values which are stored along with subscription data when the data
is added or changed. Third party providers are limited to viewing
and maintaining only their own customer's subscriptions.
SMS 310 executes specific SMPs to process the transactions
requested by third party service providers. It is within the
scope of this invention to include processing logic in these SMPs
to gather appropriate statistics as desired by the operator or the
third party service providers.
- 37 _
CA 022l472~ l997-09-0~
W096/27835 PCT~S96/02273
Third party providers may have access to standard reports
which would list their customers and the services ~o which they
subscr be. Ad hoc reporting may be available under the suidance
~f the operator to help ensure proper processing and perfsrmance
:evels c the SMS 310 are being maintalned for all users. Repor-
-outing strategies depend upon the needs of the operator and the
~hird parties.
Errors in third party transaction requests are reported to an
error file which can be viewed by the third party.
The preferred embodiment of the SMS 310 software developmen~
includes a tool kit based on the existing SPACE service creation
environment. The SPACE system report and listing capabilities are
available to list service creation components that have been
created by the third party. For third party use of the SMS 310
process server, the operator can include SMP logic which will
capture certain statistical information concerning subscriptions
cf customers owned by the third party.
A preferred embodiment of the SMS 310 provides certain
service management features and access flexibility to support the
user interface and AIN user group requirements. For use with the
preferred embodiment of SMS 310 and user workstations provides
TCP/IP, Token-Ring, or Ethernet communications which allow various
groups access to the SMS 310.
Fig. 6 illustrates how the support center users, mediated
access users, service assurance users, and user administrators can
either locally or remotely access the SMS 310. The terminal
devices used in the configuration shown in Fig. 6 are preferably
- 38 -
CA 022l472~ lss7-os-o~
W~96/27835 PCT~S96J02273
intelligent workstations equipped wi~h a TCP/IP, Token-Ring LAN
interface capability which will allow users of SMS 310 to access
other systems used by the operator.
Authorized users who have workstations equipped with T~
Token-Ring hAN connections can access the SMS 310 system. ~hese
users may be iocal to ~he LAN connected to the SMS 310 or may be
remotely located where connectivity to SMS 310 is accompiisned v a
network routers 514.
The maximum number of workstations that can be supported is
largely driven by response time requirements. A preferred
embodiment of the SMS system will allow for 30 workstatlon users
simultaneously connected to the SMS 310.
The SMS 310 workstation provides a graphical user interface
where system capabilitles and functions are presented using menu
bars and pull downs. The user can navigate through the menu
selections with point and click technology or may access functions
via function key combinations.
The preferred embodiment of the graphical user interface is
based on the X Window System with Motif Style guides. A color
monitor attached to the workstation provides a high level of
resolution, permi~ting an extensive amount of information to be
displayed without loss of detail.
SMS 310 provides operators with on-line help for all
functions and tasks they must perform. A complete set of on-line
documentation can be accessed, with support for user specific
notations and bookmarks for later retrieval.
- 39 -
CA 022l472~ l997-09-0~
W096/27835 PCT~S96/02273
SMS 310 provides a dialog box which exists across the bc~cm
cr the screen to provide textual feedback on actions, such as
syntactical error notifications or the s~atus of remote
cperat ons. The user has on-line documentation readily ava ab 5
which will provide more information to help resolve any errors and
provide more details on how to use the system.
The SMS 310 supports a "saved" view of a subscription which
acts as a hold facility for an incomplete request ror service.
This capability enables the user to suspend the current entering
of the request for service until a later time. The request wil'
remain saved until the user completes the request information and
submits it for validation processing.
A preferred embodiment of SMS 310 stores the subscription
data elements in Oracle~ database tables. Standard Oracle~
reporting tools are preferably available for the user to create ad
hoc reports. In addition, sampling and measurement nodes are
available to the developer of the SMPs if the operator chooses to
have SMS 310 communicate with a data and reports system. By
leveraging the DRS system to support reporting capabilities on the
SMS 310, the operator can collect data reflecting actual SMP
request proces~ing statistics. Operating statistics assoclated
with system functions are provided to the user via the SMS 310
maintenance and operations console 612.
While there has been illustrated and described what are at
present considered to be preferred embodiments and methods o~ the
present invention, it will be understood by those skilled in the
art that various changes and modifications may be made, and
- 40 -
CA 0221472~ 1997-09-0~
w096/27835 PCT~S96/02273
equivaients may be substituted for elements thereof without
departing from the true scope of the invention For example, the
preferred embodiments of the invention have been described in the
context of the AIN and telephone networks ~he preser.t _nven~cr,
howeve~, can be used for system managemen~ in other
telecommunications networks such as cable television netwcrks,
computer networks, wireless networks, broadband networks, or the
like
In addition, many modi~ications may be made to adapt a
particular element, technique or implementation to the teachings
of the present invention without departing from the central scope
of the invention. Therefore, it is intended that this invention
not be limited to the particular embodiments and methods disclosed
herein, but that ~he invention include all embodiments falling
with the scope of the appended claims.
