 |
Claims  |
|
|
We claim:
1. A computer-implemented method for controlling a telecommunications
system by using inter-object message communication, said telecommunication
system comprising an operating system, a linker, and a plurality of object
means for controlling functionality of said telecommunication system, each
of said object means controlling a subset of said functionality and a
subset of data, said method comprising:
generating a message in an origination object means, said origination
object comprising one of said plurality of object means, said message
being divided into parts comprising a symbolic name of a destination
object means, said destination object means comprising one of said
plurality of object means different from said origination object means, a
designation of one or more predefined system operations to be performed on
said message by said operating system, and an argument list;
said origination object means causing said operating system to transmit
said message from said origination object to said linker, said linker
having a linker table comprising a plurality of symbolic names and a
corresponding plurality of address pointers for each one of said plurality
of object means, said linker comparing said symbolic name in said message
to said plurality of symbolic names in said linker table in order to
determine one or more address pointers corresponding to said symbolic
name; and
said linker object controlling said operating system to perform said
designated one or more predefined system operations on said message and
providing said determined one or more address pointers of a destination
object means to said one or more predefined operations, whereby, said
telecommunications system is responsive to said system to operations to
perform its operations.
2. A method in accordance with claim 1 wherein, after said message is
transmitted, said linker comparing said symbolic name in said message to
said symbolic names in said linker table; and
said linker causing said one or more predefined operations to be performed
on said message and providing said address pointer to said one or more
predefined operations only if said symbolic name in said message is found
in said linker table.
3. A method in accordance with claim 2 wherein said telecommunications
system includes a plurality of processors, said method further comprising
if said symbolic name in said message is not found in said linker table,
transmitting said message to another of said plurality of processors.
4. A method in accordance with claim 3 wherein said linker further
comprises a network address table, said network address table including a
list of symbolic names and a corresponding processor identified for each
symbolic name and wherein the step of transmitting said message to another
of said plurality of processors comprises:
comparing said symbolic name in said message to entries of said network
address table;
if said symbolic name is found in said network address table, transmitting
said message to said corresponding identified processor; and
if said symbolic name is not found in said network address table,
broadcasting said symbolic name to said plurality of processors.
5. A method in accordance with claim 3 wherein said linker further
comprises a table of local alias names, said table comprising a list of
local alias names and one or more corresponding local object means, said
method further including the step of:
determining if said symbolic name in said message is found in said local
alias name table, and
if said symbolic name in said message is found in said local alias name
table, providing said message to all local object means corresponding to
said alias name.
6. A method in accordance with claim 5 further comprising:
if said symbolic name in said message is not found in said local alias name
table, broadcasting said symbolic name to said plurality of processors.
7. A telecommunication switching system, said telecommunication switching
system comprising a plurality of telecommunication line devices for
connecting telecommunication lines and at least one interconnection device
for establishing connections between said telecommunication line devices,
said system including an object-oriented program-controlled system
comprising:
an operating system;
a plurality of object means for controlling functionality of said
telecommunications system, each of said object means having at least one
symbolic name, each of said plurality of object means being created by
said operating system, wherein each of said plurality of objects controls
a portion of the functionality of said telecommunications system;
a linker for receiving messages, said linker including a linker table of a
plurality of symbolic names and a corresponding plurality of address
pointers of destination object means, wherein each newly created object
means includes means to add its at least one symbolic name and its address
pointer to said linker table, and each object means includes means to
remove its at least one symbolic name and its address pointer from said
linker table before deleting itself from said plurality of object means,
so that interobject communication is not disturbed by said adding and said
removing, said linker causing a designated at least one predefined system
operation to be performed on said messages by said program-controlled
system and providing said address pointer of a termination object means to
said one or more predefined system operation;
origination object means comprising ones of said plurality of object means,
said origination object means controlling each of said plurality of
telecommunication line devices for sending origination messages to said
linker, each of said origination messages comprising a symbolic name of a
termination object means controlling one of said plurality of
telecommunication line devices and a designation of at least one of said
predefined system operations;
said termination object means comprising ones of said plurality of object
means different from said origination object means, said termination
object means controlling each of said plurality of telecommunication line
devices responsive to said linker for sending identification messages,
said identification messages each comprising a symbolic name of a fabric
control object means; and
said fabric control object means comprising at least one of said plurality
of object means different from said origination object means and said
termination object means, for controlling each of said interconnection
devices, to establish connections between telecommunication line devices
controlled by said origination object means and telecommunication line
devices associated with said termination object means.
8. A system in accordance with claim 7 wherein said linker is further
responsive to said identification message for causing said termination
object means to apply an alerting signal to said telecommunication line
device associated with said termination object means;
said termination object means is responsive to detection of an answer
response for transmitting an answer message to said linker; and
said linker is responsive to receipt of said answer message for
transmitting said connection message to said at least one interconnection
device.
9. A computer-implemented system for delivering messages in an
object-oriented program-controlled system, said system comprising:
a plurality of object means which communicate by messages, said messages
each comprising a symbolic name of one of said plurality of object means
as a destination object and an argument list, each of said plurality of
object means controlling a portion of said system;
a linker responsive to said messages for determining one or more
destination addresses for said message by consulting a linker table, said
linker table having a plurality of symbolic names and a corresponding
plurality of destination addresses, wherein there is at least one
destination address for each symbolic name and wherein each of said
plurality of objects further includes means for adding itself to said
linker table by adding its one or more symbolic name and its address
pointer to said linker table, and each of said plurality of objects
includes means for removing itself from said linker table by removing its
one or more symbolic name and its address pointer from said linker table,
so that inter-object communication is not disturbed by such adding and
removing, wherein said linker is capable of completing said communication
by causing said one or more predefined system operations to be performed
on said argument list of said message and providing said determined one or
more address pointers of a destination object to said one or more
predefined system operations. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
BACKGROUND OF THE INVENTION
It is well-known that large software systems, for example, software for
controlling a large telecommunication system is complex and costly to
build. In an effort to alleviate this problem, large software systems are
commonly divided into segments or components. However, the various
components of todays large software systems are tied inextricably to one
another by dependencies which cause a great deal of coordination and
negotiation among the developers of the software system and often force
them to synchronize their work efforts, slowing down the development of a
project. Typically, the developer must investigate syntactic issues such
as how a particular global data structure is laid out or what order of
arguments another developer's function demands. Such interdependencies add
to the cost and the development time of the large and complex systems.
Before a program can be loaded into a machine it must be compiled, that
is, converted from the source code format in which the programmer
typically writes the program to the object code format which will be
recognized by the machine. Compiling includes computing proper addresses
of other programs and data areas with which the compiled program
communicates. Thus, compiling cannot be done until all associated programs
are fully defined. Similarly, a single developer's compiled program cannot
be tested on the machine until all the other programs with which this
program communicates have been written and are functioning on the same
machine. Similar restrictions are in effect when a change is made in a
program. For example, when a change is made to a program component which
is used by other program components, the other programs which are
dependent on the revised component must be recompiled as well. To properly
integrate a change in conventional systems, the entire system program
should be recompiled, although certain limited changes can sometimes be
made. In large systems compiling can usually be done only on off-line
computers. Thus, it is difficult and time consuming to introduce changes
in a large program controlled system such as a telecommunications
switching system after it has been installed in the field. The
interdependencies of program components which are found in present day
systems were recognized many years ago as adding to the complexities, time
and costs of developing or modifying a complex software system. Some but
not all of the problems of interdependency are solved by the known LISP
language. However, LISP is generally not considered to be slow for real
time systems. Today it is recognized that software absorbs more than 80
percent of development time and cost of a major computer based system.
Accordingly, improvements in software technology are greatly sought after.
SUMMARY OF THE INVENTION
In accordance with this invention an improved software structure is
provided by means of a linking mechanism which allows software components
to communicate using symbolic names instead of addresses related to the
physical characteristics of the system. An interprogram communication
protocol in accordance with this invention employs executable expressions
using only symbolic names. Advantageously, this protocol makes possible
the independent development of communicating software components. In
accordance with this invention, one program entity does not need to know
the address of another entity. Neither do the sending and receiving
programs have to be on the same processor, nor do they need to know
whether or not they are on the same processor. Furthermore, interprogram
communication by means of the executable expression provides for
asynchronous communication, allowing a sender to proceed without a need to
wait for reply, which is of utmost importance in a real time system such
as a stimulus driven communication switching system. Advantageously, to
the receiving program executable expression is received in the same manner
as a method invocation. This allows the receiver program to be written as
if it were invoked by the usual method invocation mechanism, while the
compile time independence of software components is maintained.
In one embodiment of the invention a linking mechanism, called a runtime
linker provides communication between independent program entities
referred to herein as objects. The runtime linker includes tables for the
conversion of symbolic object names to system address designations. In the
system of this invention, the objects do not communicate directly With
each other, but all communicate via the runtime linker by transmitting to
the runtime linker the symbolic name of a called object and information to
be transferred. The runtime linker responds by invoking the called objects
at the called objects system address. The interobject message structure in
accordance with one embodiment of this invention, includes the symbolic
name of the destination object, the symbolic name of the method of the
destination object to be executed and the symbolic name of the sending
object. The message provides the name of the sending object to the
executing object, to be used by the receiving as a destination for a
response message. Advantageously, the use of only symbolic names to effect
intercomponent communication allows one to replace an existing object with
a new one possibly having additional functionality, without disturbing the
rest of the software. Further in accordance with this invention, call
processing software for a telecommunications switching system is
partitioned into independent objects each for performing specified call
handling functions pertaining to selected facilities such as lines, trunks
etc. The objects of the call processing software communicate via
executable expressions (messages) by means of a runtime system which
passes messages between objects on the same processor or on different
processors of a multiprocessor system.
BRIEF DESCRIPTION OF THE DRAWING
The invention may be more fully understood from the following detailed
description when read with reference to the drawing in which:
FIG. 1 is a block diagram representation of an illustrative
telecommunication switching system embodying the invention;
FIGS. 2 and 6 are pictorial representations of portions of the application
software for controlling the switching system of FIG. 1;
FIGS. 3 through 5, 7 and 8 are a flow chart representation of the functions
of the application software in completion of an illustrative call;
FIG. 9 is a pictorial representation of runtime system software for use in
the system of FIG. 1;
FIGS. 10 through 12 are flow chart representations of sequences of actions
of the runtime system of FIG. 9;
FIGS. 13 through 18 are representations of tables and queues in the
illustrative system; and
FIG. 19 is a representation of a backup arrangement for the system of FIG.
1.
DETAILED DESCRIPTION
FIG. 1 is a block diagram representation of an illustrative distributed
telecommunications switching system which is used to illustrate the
principles of the invention. The system comprises a plurality of
processors 101, each of which is equipped with a runtime system and object
oriented application software for carrying out telecommunications
functions. The processors 101 are interconnected by a bus 103 having
broadcast capability such as for example the well-known ETHERNET local
area network. The application software may be resident in a single
processor or distributed over the various processors 101. Certain
application software, such as the objects communicating with peripheral
devices, are preferably located in processors which have physical
connections to the peripheral devices, for example, via interconnecting
buses 105. The processors 101 may, for example be the IVORY computer of
Symbolics Company or the MICROEXPLORER processor of Texas Instruments
Company, adapted to run Common LISP.
In the illustrative embodiment of FIG. 1, three switch modules 120, 130 and
140, comprises processors 121, 131 and 141, respectively, and comprising
switching networks 122, 132, 142, respectively. The switching networks
132, 142 may be connected to subscriber lines 110 or interoffice trunks
112. The switching network 122 may be dedicated to special services, such
as interconnecting broadband lines designed for handling video. The
processors 121, 131 and 141 may, for example be Motorola 68000 processors
and preferably programmed in a lower level language such as the well-known
C language and using for example a real time version of the AT&T UNIX.RTM.
operating system. The switching networks 122, 132 and 142 include the
necessary and well-known line and trunk interface circuitry as well as
switching fabric for performing interconnections. A further switching
network, bridging network 115, is provided to interconnect the network
switches 132 and 142 to provide paths between lines and trunks of the two
different switching modules. Known switching systems may have a variety of
switching modules, many of them interconnectable by a switching network
such as network 115. The switching modules 120, 130 and 140 of FIG. 1 may,
for example, be the switching modules of the AT&T 5ESS.RTM. Switch as
described in the AT&T Technical Journal, July-August 1985, Vol 64, No. 6,
part 2 or switching modules as described in U.S. Pat. No. 4,592,048. The
interconnecting switch 115 may be a time multiplexed switch as described
in that patent and controlled by a known control processor 116. The lines
110 and trunks 112 connected to switch modules 130 and 140 may be standard
analog or digital lines and trunks.
In a system in accordance with this invention, software functions may be
partitioned into lower level functions, more closely tied to the
peripheral hardware, and higher level functions which are more hardware
independent and may be more readily executed in a higher level software
environment such as LISP. The processors 116, 121, 131 and 141 are
preferably used to perform low level functions such as controlling the
networks and other functions such as detecting call origination, flashes,
call termination as well as performing the functions of collecting digits
and providing alerting and dial tone signals on the associated lines and
trunks, as required. These functions are customarily performed in stored
program controlled switching systems and are well-known in the art. In the
present arrangement, the processors 101 communicate with the switching
module processors and perform higher level, hardware independent
communication functions required to provide communication services.
FIG. 2 is a pictorial representation of a portion of the application
software for carrying out higher level communication functions, resident
in the LISP processors 101. A basic unit in the call processing software
structure is a group of related software components called objects. Each
of the objects in the system has a unique name, a set of operations called
methods and a state called instance data. Communications between objects
is by messages wherein information elements are represented as keywords
and value pairs; keywords are represented by symbols and values are
represented by a set of self-describing data types, i.e. symbols, numbers,
strings or a list of these values, as is commonly done in LISP. All
messages identify the symbolic name of the receiver, the symbolic name of
the sender, the symbolic name of the method of the receiver to be given
control upon this path of the message, and a list of arguments which are
expected by the receiving method. Each of the processors 101 has a runtime
software system by which the messages are passed between objects, as
discussed in greater detail with respect to FIGS. 10 through 12. When a
message is passed between components which are in the same processor, the
runtime system converts the symbolic names to system addresses and passes
the message to the intended receiver. If the intended receiver is not
found in the processor of the originating object, the runtime system of
the originating processor transmits the message to the receiving processor
and the runtime system of the receiving processor translates the symbolic
names into system addresses. The sender and receiver objects communicate
directly only with the resident runtime system and are not affected by the
fact that interprocessor communication takes place.
Objects may be characterized as static or dynamic. Static objects comprise
the telecommunication switching office configuration and are in existence
independent of any call activity within the office. Dynamic objects are
created on a temporary basis, such as, for the duration of a call. Objects
may be linked to each other by static links or dynamic links. A static
link exists only between static components and may be considered part of
the office configuration. Dynamic links may exist between two static
components, two dynamic components or a static and a dynamic component.
Dynamic links are established only for a specific purpose such as passing
messages for the duration of a specific call. Objects are created by the
runtime system from a component class defined by a programmer in the
software development environment, as a template for how the component
instance will be constituted in the target system. The class includes a
definition of the instance of data elements which are managed by the
component and the set of methods (program text) which have exclusive
access to the instance data. Static objects are created in the system when
the office configuration is initiated or modified. Dynamic objects are
created for a specific purpose, such as a specific telephone call and are
destroyed when the call is terminated.
For each active subscriber of the system having at least one active
telephone line connected to at least one telecommunications terminal,
there exist at least three related objects. These are known as the
subscriber object, the line object, and the port object. A subscriber may
have more than one line and a separate line object is provided for each
line assigned to the subscriber. Furthermore, a line may have more than
one associated port object. For example, an ISDN digital subscriber line
may have more than one terminal, and a separate port object is provided
for each such terminal. A port object is created on the processor 101 for
each available line or trunk termination of the system. Line and
subscriber objects are created when subscribers are assigned to the ports.
Line objects are linked to their related subscriber and port objects by
bidirectional static links which remain as long as the relationship
exists. This static linking is shown in FIG. 2 with solid lines, while
dynamic linking, e.g. for the duration of a call, is shown by dotted
lines. A port object represents the physical appearance of a subscriber's
terminal equipment and communicates with the processor of the switch
module to which the terminal equipment is physically connected. Where the
subscriber is connected to the switch via an ISDN digital subscriber line,
the port object is responsible for the D channel signaling interface. A
line object represents the logical network address and is responsible for
network routing and line specific features. A subscriber object is
responsible for billing, call screening and other features common to all
lines owned by the subscriber. The various objects shown in FIG. 2 may be
distributed over several of the host processors 101 independent of their
linking. For the sake of efficiency, the port objects are preferably
resident in the ones of processors 101 which are connected via bus 105 to
the switch module to which the associated terminal equipment is connected.
The following will illustrate the interactions of the various objects in
the establishment of an illustrative call between two subscribers. By way
of example, it will be assumed that a call is originated from a port
associated with directory number 555-2000 and is directed to directory
number 555-3000. The sequence of this illustrative call will be described
with respect to FIGS. 2 through 5. As indicated in block 501 of FIG. 3,
the processing of a call in the high-level object-oriented application
software is initiated by the detection by one of the port objects of an
origination request. The originating subscriber may, for example, be
connected to one of the subscriber lines 110 of switch module 130. Call
origination by, for example, an off-hook signal on an analog line is
detected by means of well-known scanners or the like and associated low
level software incorporated in the switch module 130, in a standard and
well-known way. An origination request message is transmitted from module
130 via the runtime system of the the associated one of the processors 101
to the port object. In this example, the associated port object is labeled
port A, shown at 215 in FIG. 2. Port object 215 sends a message reflecting
the detected origination request to the associated line object shown at
212, which is the originating line object referred to in block 502 of FIG.
3. An exemplary message is shown in Table A. The line object 212 creates a
call manager object 250 as shown in block 504. Creation of the call
manager is done by means of a message from the line object to the local
runtime system by providing the class name of the desired object and an
optional object name designation. In this illustrative system the call
manager is a dynamic object which will remain in existence only for the
duration of one call and will destruct when the call is terminated. After
the call manager 250 has been created, the line object 212 sends the name,
S100, of the associated subscriber object 210 and the name, A123, of the
associated port object 215 to call manger 250, as reflected in block 506
of FIG. 3. An exemplary message is shown in Table A, message 2. The call
manager knows the name of the line object, which created the manager by
virtue of the communications originating from the line object, which
includes the name of the caller.
The call manager 250 transmits a message via the runtime system to port
object 215 with the name A123, which the call manager received earlier
from the associated line object 212. The message instructs the port object
to collect digits, as reflected in block 508 of FIG. 3. The digits may be
collected in a well-known manner in the associated switching module, which
is module 130 in this example, and transmitted to the port object. In this
example, the collected digits represent the number 555-3000 of a
subscriber connected to one of the subscriber lines 110 of switching
module 140. The port object 215 transmits the collected digits to the call
manager 250 together with the name of its associated fabric controller
object, as reflected in block 509. An exemplary message is shown in Table
A, message 3.
Associated with the switching networks 122, 132, 142 are the fabric
controller object 230, 231, and 235, respectively. The fabric controller
derives network connection information from the calling and called port
and channel information provided to it and transmits the derived
information to the appropriate processor for controlling the associated
network to establish the desired interconnection. In the event that the
two ports involved in a call are in the same switching module, only one
fabric controller object is involved in the call. However, if the
originating subscriber port is connected to one switch module and the
terminating subscriber port is connected to another switch module,
originating and terminating fabric controller objects are involved.
Furthermore, when two switch modules are involved in a call, a connection
must be established between them through the interconnecting switching
network 115. The switching network 115 is controlled by processor 116
connected to one of the call handling processors 101 via one of the busses
105. The switching network and processor represent a separate physical
resource to the system and a software object designated by the number 250
in FIG. 2 and referred to as a bridge controller, communicates connection
information to the processor 116. The bridge controller receives messages
from fabric controllers involved in a call to generate connection
information for the bridging network 115. Since the switching networks
122, 132 and 142 and the bridging network 115 are physical resources, the
fabric controllers and bridge controller corresponding to the networks are
created at the time that the physical resource is added to the system.
Likewise, port objects are generated at the time that the network
terminations are added to the system and the name of the fabric controller
which is associated with the port is recorded in the port object.
Similarly, the name of the bridge controller 250 is provided to the fabric
controllers which may need to call the bridge controller object to obtain
connections through the bridging network.
The name of the originating fabric controller passed to the call manager
250, indicated in block 509, is in this illustrative example FC1000, the
name of fabric controller 231. As indicated in block 510 of FIG. 3 the
call manager broadcasts an incoming call message, using the name of the
terminating line object, 555-3000. An exemplary message is shown in Table
A, message 4. If 555-3000 is in fact an active number in the switching
system, there will exist a line object which has that name. All messages,
including the broadcast message from the call manager 250 are transmitted
through the runtime system. Broadcast messages are distributed via bus 103
to each of the processors and the runtime system of each processor
receives and analyzes the alias name. When a runtime system recognizes the
broadcast name as belonging to an object on its processor, the message is
transmitted by that runtime system to the addressed object and is
received, as reflected in block 512 of FIG. 3. In this example, line
object 222 is the terminating line object with the broadcast alias name
555-3000, and receives the message.
The terminating line object 222, having received the broadcast message with
the alias name 555-3000, tests to determine whether one of the two ports,
port A or port B associated with this line is available, as reflected in
block 514 in FIG. 3. If a port is available, the terminating line object
222 transmits a "Route Complete" message to the call manager 250, as
reflected in box 516 in FIG. 4. The message includes the name of the
terminating port object, for example A456, and the name of the terminating
subscriber object, for example $400. These names are known to the line
object because of linking that was included in the object at the time that
the subscriber and line objects were created. An exemplary message is
shown in Table A, message 5. As indicated in block 518 of FIG. 4, the call
manager 250 sends an alerting message (Table A, message 6) to terminating
port object 225 with the name A456 to cause that port to provide an
alerting signal to its associated subscriber terminal and also sends a
message (Table A, message 7) to the originating port object 215 with the
name A123 to cause its associated subscriber terminal to receive an
audible ringing signal. The terminating port object 225 sends a message
(Table A, message 8) with the name of the associated fabric controller
235, FC2000, to the call manager 250, as indicated in block 520, and waits
for an off-hook signal. In the meantime, as indicated in block 521, the
call manager 250 sends messages (Table A, messages 9 and 10) to the fabric
controllers 231 and 235 to cause them to reserve a path for the completion
of a call. In this example, the calling subscriber is connected to a
module 130 and the called subscriber is connected to module 140 (FIG. 1).
Accordingly, this exemplary call involves switching networks 132 and 142,
and bridging network 115. Fabric controller object 231 controls switching
network 132 by messages via bus 105 to processor 131, fabric controller
235 controls switching network 142 by messages via bus 105 to processor
141, and bridge controller 250 controls bridging network 115 by messages
via bus 105 to processor 116. Each fabric controller comprises the
programs and data for selecting an available path through its associated
network is response to a message defining the name of a port object
associated with the network and the name of the bridging controller. Table
A message 9 is an exemplary message sent from call manager 250 (CMA123) to
controller 231 (FC1000) naming port object 215 (A123) and fabric
controller 260 (BC5000). Table A message 10 shows an analogous message
sent to fabric controller 235. Such messages are transmitted as indicated
in block 521. Each fabric controller selects a path through its associated
network from the network terminal associated with the identified port
object to an interconnecting link to the bridging network and send a
message to the bridging controller 260 identifying the selected link and
the identity of the call. The identity of the call may be chosen to be the
same as the name of the call manager (CMA123) since it is a unique name
and the call manager exists only for the duration of the call. Messages 11
and 12 of Table A represent messages transmitted from fabric controller
231 (FC1000) and 235 (FC2000), respectively, to bridge controller 260
(BC5000), reserving a path with the bridge controller a indicated in block
522. The message identifies the call (CMA123) and the network links (X,Y)
selected by the fabric controllers.
After having received an alert message from the call manager to apply an
alerting signal to the associated terminal, as indicated in block 518, the
port object 225 waits for an off-hook indication from the terminal
associated circuitry and corresponding software in switching module 140.
Upon receipt of the off-hook indication, the terminating port object 225
(A456) sends an off-hook message (Table A, message 13) to the call manager
250 (CMA123) when the off-hook is detected as indicated in block 524, of
FIG. 4. Thereafter, the call manager 250 (CMA123) sends a message (Table
A, message 14) to the originating port object 215 (A123) to stop sending
audible signals to the originating subscriber, sends messages (Table A,
message 15, 16) to the fabric controllers (FC1000, FC2000) to make a
connection via the reserved path and sends a message (Table A, messages 17
and 18) to the subscriber objects 210 and 220 that a call has been
established for billing purposes. The actions are indicated generally in
block 526 shown in FIG. 4. The fabric controllers (FC1000, FC2000) send
connect messages (Table A, message 19, 20) to the bridge controller
(BC5000) as indicated in block 527 of FIG. 4.
At this point, a call has been established and stable call audits may be
performed by the port objects and the fabric controller objects by sending
periodic inquiry messages to the call manager to verify the continued
existence of the call manager. If for any reason the call is interrupted
and the call manager is terminated, the port objects and the fabric
controller objects will take action to terminate the call connections. The
stable call audits are indicated in block 528 of FIG. 4. When the call is
terminated by either the calling or called party going on-hook, the
corresponding port object will receive an on-hook indication from the
associated switching module and send a disconnect message (Table A,
message 21, 22) to the call manager 250 indicating termination of the
call, as depicted in block 530 of FIG. 4. The call manager will react to
the first such message whether from the terminating or originating port
object and initiate the call tear-down process. A second on-hook message
from the other port object is simply ignored if the tear-down process has
already been started. The call manager 250 sends disconnect messages
(Table A, messages 23-30) to fabric controller objects 231 (FC1000) and
235 (FC2000), to port objects 215 (A123) and 225 (A456), to line objects
212 (123) and 222 (456) and to subscriber objects 210 (S100) and 220
($400). This is indicated in block 532 of FIG. 4.
The fabric controller objects 231 and 233 each respond to the disconnect
message from the call manager by sending a disconnect message (Table A,
message 31, 32) to the bridge controller 260 (BC5000), as indicated in
block 533, and by stopping any further stable call audits and releasing
the established path through the associated networks in a well-known
fashion. The bridge controller likewise causes the path for this call in
bridge network 115 to be released. The port objects also stop the audits
and adjust their internal data to reflect termination of a call. The line
objects respond to the disconnect message by changing internal data to
reflect termination of a call as do the subscriber objects, which
additionally respond to the disconnect message by terminating the billing
period. After transmitting the disconnect messages, the call manager
object 250 will self-destruct by causing the runtime system to remove its
name from the system and to release the memory reserved for the call.
In the decision block 514 of FIG. 3, a test is made by the terminating port
object to determine whether a port is available for connection. In the
event that it is not, an unavailability message is sent from the
terminating port object 225 to the call manager 250, as indicated in block
540 of FIG. 5. Thereafter, a request message is sent from the call manager
to the terminating subscriber object 220 as indicated in block 542. Since
the subscriber object contains details of the subscriber service options,
the request message from the call manager to the subscriber object is
equivalent to a request for further instructions. In this example, a test
is made by the subscriber object, as indicated in block 546, to determine
whether call forwarding has been defined. If so, the call forwarding
number, is sent to the call managers as indicated in block 547 and the
call manager will broadcast an incoming call message with the call
forwarding number, as indicated in block 510 of FIG. 3. Thereafter, the
call will be treated in the same manner as a completed call described
above. In the event that the test in block 546 indicates that there is to
be no call forwarding, a reject message is sent to the call manager as
indicated in block 548. The call manager will provide a message to the
originating port 215 to apply busy tone to the subscriber terminal.
Thereafter, the system waits for an on-hook as indicated in block 552 and
when an on-hook is detected an on-hook message is sent from the
originating port object 215 to the call manager 250 as indicated in block
553. Thereafter, the call manager will send termination messages to the
originating port object, the originating line object and the originating
subscriber object as indicated in block 544. Finally, the call manager
object 250 will self-destruct by causing the runtime system to remove its
name from the system and to release the memory reserved for the call. The
messages used in block 540 through 556 are not shown in detail since these
messages are analogous to the exemplary messages of Table A.
What has been described in the previous paragraphs with respect to FIGS. 3
through 5 is a local call, that is, a call to another subscriber number
within the same system, but on a different switching module. In the case
of a call to another switching system within what is known as a Local
Access Transport Area (LATA), an object known as a tandem agent (not shown
in the drawings) analyzes the called directory number broadcast by the
call manager and transmits the number to the identified system within the
same LATA via one of the trunks 112. In such a cas | | |
