Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1996-06-12
2003-02-04
Courtenay, III, St. John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S241000, C379S269000
Reexamination Certificate
active
06516355
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention relates to high capacity digital telecommunications switches which are controlled by a host. More particularly, the invention relates to compatible methods for controlling otherwise incompatible digital telecommunications switches as well as apparatus incorporating the methods.
2. State of the Art
Modern telecommunications systems utilize high capacity digital switching systems to process calls and effect different types of telecommunications. These switches are typically built in a modular form utilizing a bus and a plurality of modular cards which are mounted in racks and slots. A typical switch is the LNX-2000 from Excel, Inc., Sagamore Beach, Mass. Prior art
FIG. 1
shows the general physical configuration of the LNX-2000 and prior art
FIG. 2
shows a general block circuit diagram illustrating a bus and a plurality of modular cards.
Referring now to
FIGS. 1 and 2
, the digital switch
10
includes a rack
12
having slots
14
a
-
14
t
which are associated with a bus
16
. Typically, a redundant bus
16
a
is also provided as a back-up should the bus
16
fail for any reason. The first two slots
14
a,
14
b
are usually reserved for a power supply
18
and a redundant power supply
18
a.
The last two slots
14
s,
14
t
are usually reserved for a switch matrix CPU
20
and a redundant switch matrix CPU
20
a.
Each matrix CPU is provided with a respective control link
22
,
22
a
for connection to a host
40
. The control links are usually RS-232 serial links Each matrix CPU may also be provided with a reference clock port (not shown). The other slots are provided for modular cards
24
,
26
,
28
,
30
, and
32
a-k,
for example. The cards may provide access telecommunications channels, provide telecommunications signalling, or provide other telecommunications services. For example, card
24
shown in
FIG. 2
provides a 192-channel T1 interface Card
26
provides a 256-channel E1 interface. Card
28
provides a 24-channel ISDN Primary Rate interface. Card
30
provides digital signal processing such as tone generation, tone reception, digital voice recording and playback, etc. It will be appreciated that some of the interface cards will rely on functions of other cards in order to execute certain telecommunications functions. In general, each of the cards will rely on the matrix CPU for intelligent control of their basic functions. In addition, the T1 interfaces and the E1 interfaces may cooperate to provide conversions. The ISDN interfaces will rely on the T1 or E1 interfaces for B channel access. The DSP cards may be called upon by all of the interface cards to generate appropriate signalling tones.
Each of the cards in switch
10
is typically configured to operate in a user definable manner. Configuration of the cards is effected by the host
40
which sends configuration data to the matrix CPU
20
(
20
a
) which in turn remembers the configuration data for each card in the switch. In addition, the matrix CPU contains system software which is downloaded to it by the host. The system software governs the basic switch operation. Call processing activities are controlled by the host which remains in communication with the matrix CPU so long as the switch is in service.
Typical switch configuration commands issued by the host to the switch (the matrix CPU) include: resetting line cards, changing the service state of a card (placing it in and out of service), resetting the matrix CPU, downloading system software to the matrix CPU, setting the system time, system network synchronization, assigning logical span IDs, changing a channel service state, changing a channel configuration, changing a trunk type configuration (defining the signalling protocol for a particular channel or group of channels), changing a start dialing signalling protocol, configuring timers and filters (for signalling), busying out trunks, setting answer supervision mode(for each channel), setting release modes for a channel, setting call setup inpulsing parameters. Once configured, the switch remains configured until a card or the matrix CPU is reset, or until a change in service dictates changing one or more of the configuration parameters. For example, if new trunks are added or new cards are added, additional configuration will be required. Usually, the configuration data is saved as a file by the host and downloaded to the matrix CPU together with system software if the switch is reset.
Typical ongoing communication between the switch (the matrix CPU) and the host includes call processing, control of tone generation and reception, and call progress analysis. Call processing relates to how the switch handles incoming and outgoing calls and includes the functions of call setup, cross connections, inseize/outseize call control, incoming call setup, inseize control instructions, outgoing call setup, outseize control instructions and connection management. Tone generation control includes defining tone specifications, tone detection, digit collection, tone generation, outpulsing setup, and generating tones for prompting and call status information (e.g. dial tones and busy signals). Call progress analysis is generally used when originating a call to the PSTN and includes the functions of invoking the analysis, designing the analysis, configuring global parameters and cadence pattern parameters, setting pattern defaults and pattern ID
5
and setting class and tone group defaults.
The LNX 2000 Switch provides a host messaging protocol and specific message formats for communication between a host and the switch. Other switches provide their own host messaging protocols which deal with similar activities but which have different message formats. Thus, a host must be programmed in one way to control one brand of switch and in a different way to control another brand of switch. That is, different switches use different hardware components and therefore respond to different message sets. For example, the Summa 4 SDS Series of switches includes a Network Bus Controller Card, a Bus Repeater Card, a Direct Inward Dial Card, an E&N Trunk Card, a Subscriber Line Interface Card, a Universal Trunk Card, a Digital Conference Card, among others. These cards require different messages for configuration and operation than the coards mentioned above with regard to the LNX 2000 Switch. Moreover, the SDS Series utilizes its own Unix-based command language which is different from the command language used by the LNK 2000 Switch.
Parent application Ser. No. 08/555,040 discloses an object oriented development system for the configuration of telecommunications equipment including one or more digital telecommunications switches.
FIG. 3
illustrates a graphical representation of the structure of the development system. The development system includes an object server
50
having at least one man/machine interface (MMI) agent
52
, an object server
54
with predefined managed objects
56
and a database management library
58
, a server applications programmer interface (API)
60
coupled to the MMI and the object server for hiding the internal architecture of the object services from the MMI agent with respect to the managed objects
56
, and means for permitting the developer to create and define user-defined managed objects
57
which utilize the database management library and the database which stores managed object related data, and which does not require the server API to be rewritten. The server applications programmer interface (API) is organized and designed in a manner such that the user defined objects are automatically supported by the API. Predefined managed objects are initialized at start-up before the initialization of the user-defined objects. The development environment allows for the rapid development and deployment of new telecommunications services using combinations of predefined managed objects and user defined managed objects. The managed objects can include hardware such as shelf, rack, board, switch, signalling, etc., service
Duman Osman Ali
Hartmann Curtis
ADC Newnet, Inc.
Courtenay III St. John
LandOfFree
Methods and apparatus for controlling digital communications... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Methods and apparatus for controlling digital communications..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Methods and apparatus for controlling digital communications... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3144198