WO1999033278A2

WO1999033278A2 - Interface components for a telecommunications switching platform

Info

Publication number: WO1999033278A2
Application number: PCT/US1998/020189
Authority: WO
Inventors: L.P. Alcatel Usa Sourcing; James M. Davis; Scott A. Kooy; Henry J. Lohn, Iii; R. Timothy Wallace; Mark D. Browning; Cecil W. Johnson, Jr.; Shawn W. Vines
Original assignee: Alcatel Usa Sourcing Lp
Priority date: 1997-09-26
Filing date: 1998-09-25
Publication date: 1999-07-01
Also published as: WO1999033278A3; AU9584298A

Abstract

Disclosed are resource modules for telecommunications switching platforms which are capable of responding to heartbeat messages and identifying themselves as operational over one bus or both buses of a redundant-pair control bus. The modules also have reprogrammable, nonvolatile memories associated with them from which they can run their operating systems. The modules can also transfer their operating system into another memory, allowing each module to make updates to the operating system stored in its nonvolatile memory without interrupting its execution of its run-time operating code. The modules may be used as a part of a system and method for forming circuit connections within a telecommunications switching platform that uses tables of logical identifiers for resources and information channels being handled by the platform to allow dynamic addressing of components and provide significant flexibility in reconfiguration of the switching platform.

Description

INTERFACE COMPONENTS FOR A TELECOMMUNICAΗONS SWITCHING PLATFORM

Telecommunications switching platforms operate to connect incoming communication channels to selected outgoing communication channels. This switching is generally done in response to phone numbers dialed by the users or subscribers of the company operating the telecommunications system, or by others who are calling these subscribers. For example, the

SUBSTTΠΠΈ SHEET(RULE 26) caller enters a phone number and signaling is sent along with or over the communication channel and the telecommunication system attempts to establish an end-to-end communications link to the destination number that the caller has dialed. An end-to-end communications channel is established through a switch within the telecommunications switching platform. This switch is typically a non-blocking matrix switch, which is operable to connect the incoming channel to one of many outgoing channels. The switch operates under control of a processor within the telecommunications switching platform. The processor supplies information that the switch uses to connect one information channel to another through the switch. Typically, the switch receives a number of time- multiplexed input signals and provides a number of time- multiplexed output signals. There are also typically a number of resources within the switching platform. These resources may be connected to each other or to an information channel through the switch. For example, if the caller seeks to initiate a call to a busy number, the caller must receive a busy signal; this busy signal is provided by a resource within the telecommunications switching platform, and the familiar busy tone is passed through the switch and received by the caller.

In the event that a resource within the telecommunication switching platform fails or is added or removed from the system while the system is operating, prior-art systems have failed to detect such failure or insertion or extraction. Thus, such systems are unable to be easily configured or reconfigured.

In prior-art telecommunications switching platforms, a number of processors or controllers may be implemented to perform the numerous functions of the platforms. In such cases, each of the processors typically has an operating system associated with it. Prior-art systems have typically required that the operating system be downloaded into volatile memory from a high-level operating system, which might have its own associated nonvolatile semiconductor memory or hard disk drive.

Certain support functions are generally provided by a telecommunications switching platform. Specifically, the telecommunications switching platform decodes signaling generated in response to keys input by the caller/subscriber so that the caller's voice channel may be connected to an appropriate destination information channel. In the process of connecting, other tones may be provided to the caller/subscriber. Specifically, if the switching platform is unable to connect the caller to the requested destination because the connecting trunk is busy, the switching platform provides the trunk busy tone. For incoming calls, the switching platform sends normal busy signals back to the far side connection if the local loop for the called party is busy. If the local loop or subscriber loop is not busy, the switching platform will send a ring signal until the subscriber answers. Thus, the switching platform will provide a number of different tones during the intermediate process of making end-to-end switching connections.

Telecommunications switching platforms commonly interface to telecommunications spans and switch control and information channels on those spans, forming cross connections between different input and output information channels. The telecommunications switching platforms typically interface to the telecommunications spans using El or Tl protocol interfaces .

In the event that an interface to a telecommunication span fails, or an interface is added or removed from the system while the system is operating, prior-art systems have failed to detect such failure or insertion or extraction. Thus, such systems are unable to be easily configured or reconfigured.

Telecommunications switching platforms operate to connect incoming communication channels to selected outgoing communication channels. Incoming information channels may be 16 kbps PC-encoded voice channels or 64 kbps PC -encoded voice channels. Outgoing information channels may likewise be 16 kbps LPC-encoded voice channels or 64 kbps PCM-encoded voice channels. Even when information channels are being switched from one 16 kbps LPC-encoded voice channel to another 16 kbps LPC-encoded voice channel, the telecommunications switching platform may require the internal switching of the voice channels to be performed using 64 kbps switches and channels; thus even in this circumstance rate conversion and transcoding may be required.

In conventional telecommunications systems, the applications processor (e.g., the call processor) keeps track of the addresses assigned to the various incoming and outgoing communications channels, as well as the various resources that are addressed within the telecommunications switching platform. This is done through hard wiring or a large table of fixed addresses corresponding to these communication channels and resources. Thus, for example, traffic channels are processed through an assigned digital signal processor (DSP) and if the DSP fails, the associated traffic channels are not available until the DSP is repaired or replaced due to the inability of the telecommunications to dynamically reallocate DSPs to traffic channels.

SUMMARY OF THE INVENTION The present invention overcomes the problems associated with prior-art systems by providing a system and method for determining when a system resource has failed or been removed or inserted into an operating telecommunications switching platform. The present invention also provides for a system and method in which each of the switching modules has a reprogrammable, nonvolatile memory associated with it that has the module's operating system stored in it.

A system in current operation is sometimes referred to as "hot," and thus the removal or reinsertion of a resource or module in such a system may be referred to herein as a "hot removal" or a "hot insertion.§

The switching modules communicate with other elements of the telecommunication switching platform through a control bus, which preferably comprises a pair of redundant control buses. Communications over the control bus is through a Local COMmunication (LCOM) protocol. To monitor for, among other things, resource module failures, "hot insertions, " and "hot removals, " the LCOM protocol provides for a heartbeat messaging scheme. In one embodiment, this messaging scheme provides that one group of resource modules will use one of the redundant control buses as a primary bus, and that the other group of resource modules will use the other of the redundant control buses as a primary bus. Whichever group of resource modules uses one of these redundant buses as a primary bus will use the other of the redundant buses as a secondary bus .

The switching module's LCOM controller, within a first time period, sends a primary heartbeat message over both of the redundant control buses. The buses are individually addressed by use of an LCOM header. Supposing that one of the buses is referred to as Bus A and the other as Bus B, then there will be a "broadcast A" value placed in the LCOM header of the LCOM heartbeat message intended to be broadcast over Bus A and a "broadcast B" value placed in the LCOM header of the LCOM heartbeat message intended to be broadcast over Bus B. This process is preferably referred to herein as "primary heartbeat messaging." The LCOM controller also preferably performs a type of heartbeat messaging known as "secondary heartbeat messaging.§ With the secondary heartbeat messaging, the LCOM controller preferably cycles through all known resource modules in the switching platform, by placing certain "slot IDs" in the LCOM header of each secondary heartbeat message . The LCOM controller then cycles through the known slots of the platform, making sure that each interface module is also capable of communicating over its secondary bus.

To allow for more efficient system power-up, the modules of the present invention preferably have their operating systems stored in a nonvolatile memory that can be reprogrammed without removing it from the system. For instance, the nonvolatile memory might be a Flash memory, an Electrically Erasable Programmable Read-Only Memory (EEPROM) or it might be a battery-backed Static Random Access Memory (SRAM) , or it might another type of nonvolatile, reprogrammable memory. By keeping the operating system in a nonvolatile memory associated with the module, the preferred embodiment platform eliminates the need for a time-consuming download of operating system code into a large number of volatile memories associated with many modules in the telecommunications switching platform. Instead, each module powers-up ready-to-operate with its own operating code. Then, if necessary, perhaps while the platform is already up and operating, new operating system code can be downloaded and programmed into the nonvolatile memory of the module without interruption to the system or delay in the system power-up.

In a preferred embodiment of the present invention, a telephony-support module is provided. The telephony-support module preferably provides audio functions including trunk signaling such as MFRl and MFR2 , tone generation, digitized announcement record and playback, and tone decoding. Within a telephony-support module, a microprocessor preferably directs the delivery of these tones and announcements. The microprocessor is preferably connected to volatile and nonvolatile memory and to digital signal processors (DSPs) to provide the tone delivery and announcement functions. The telephony-support module is operable to communicate with other resources and with high- level applications within the telecommunications switching platform through local communications protocols that in one embodiment are provided within the microprocessor.

In one embodiment, the tones and announcements are placed upon high-speed, time-multiplexed buses by the DSPs. The high-speed buses preferably have 128 information channels carrying tones or voice signals at 64 kbps. According to an embodiment of the invention, these tones and/or signals will be placed upon certain timeslots or channels on the high-speed buses. A switch, which is preferably a time-space-time switch, is preferably operable to switch any information channel of one of a plurality of input high-speed buses to any information channel of any one of a plurality of output highspeed buses .

In a preferred embodiment of the present invention, a telephony-support module is provided. The telephony-support module preferably provides audio functions including trunk signaling such as MFRl and MFR2 , tone generation, digitized announcement record and playback, and tone decoding.

Within a telephony-support module, a microprocessor preferably directs the delivery of these tones and announcements . The microprocessor is preferably connected to volatile and nonvolatile memory and to digital signal processors (DSPs) to provide the tone delivery and announcement functions. The telephony-support module is operable to communicate with other resources and with high- level applications within the telecommunications switching platform through local communications protocols that in one embodiment are provided within the microprocessor.

In one embodiment, the tones and announcements are placed upon high-speed, time-multiplexed buses by the DSPs. The high-speed buses preferably have 128 information channels carrying tones or voice signals at 64 kbps. According to an embodiment of the invention, these tones and/or signals will be placed upon certain timeslots or channels on the high-speed buses. A switch, which is preferably a time-space-time switch, is preferably operable to switch any information channel of one of a plurality of input high-speed buses to any information channel of any one of a plurality of output highspeed buses.

An embodiment of the present invention uses tables of logical identifiers for resources and information channels being handled by the platform to allow dynamic addressing of components and provide significant flexibility over prior-art systems. Specifically, the applications processor of the telecommunications switching platform no longer has to maintain large tables of information concerning physical details within the switching platform. The applications processor maintains smaller tables of the logical identifiers of the telecommunications channel inputs and outputs to the switching platform itself. The applications processor can request that end-to-end connections be formed by specifying the logical identifiers of two sets of telecommunications channel inputs and outputs.

Thus, in the preferred embodiment of the present invention, switching modules operating beneath the applications processor make connections between information channels by translating logical identifiers into specific

SUBSTTTUTE SHEET (RULE 26) switching information. The switching module receives end-to- end switching instructions from the applications processor, and proceeds to form these end-to-end connections in a manner transparent to the applications processor. By storing in a configuration table certain additional information associated with the various communications channels and resources within the system, the switching module can independently call upon resources and make intermediate connections within the switching module without further direction from the applications processor.

In one embodiment of the present invention, the telecommunications switching platform has an applications processor that manages the switching platform and controls the connection of telecommunications channel inputs to selected telecommunications channel outputs through end-to-end switching requests. The platform has a switching module that performs switching functions to carry out these end-to-end switching requests. The switching module in turn has a switch to connect telecommunications channels to each other and to resources within the platform. The switching module instructs the switch to make these connections in accordance with its translation of the logical identifiers.

Preferably, the switching module receives a number of digital signals or spans. Each span carries a number of separate telecommunications channel inputs to (and outputs from) the platform. Each span is divided into multi-bit, periodically-repeating frames. Each frame, in turn, is further subdivided into a plurality of timeslots, with each timeslot being one or more bits that are consistently transmitted at a certain time within each frame. Each of these timeslots represents an information channel on said digital signal. These information channels can include LAP-D signaling channels, voice or data traffic channels, and PSTN- trunk DSO channels. The switch within the switching module is preferably capable of connecting any telecommunications input

SUBSTTTUTE SHEET (RULE 26) channel on any timeslot of any digital signal to any telecommunications output channel.

In one embodiment of the present invention, the telecommunications switching platform maintains a configuration table by which semi-permanent connections can be "nailed-up" between the telecommunications input and output channels and resources within the telecommunications switching platform.

In another embodiment of the present invention, a method for configuring a telecommunications-switching platform is described. The platform in this embodiment includes a controller, a switching module, system resources, and at least one shared communication path. The platform receives channel inputs and outputs from external telecommunications systems. The method described includes building a configuration table with logical identifiers for the platform's system resources and information channel inputs and outputs. A system resource's logical identifier determines over which timeslot of the shared communications path the resource will communicate. The method also includes the step of polling at least one system resource to receive a registration from such system resource and determining a logical identifier for such system resource. The method also includes the step of building a connection table in which a logical identifier is assigned to the telecommunications channel inputs and outputs. For a particular communications channel, the logical identifier determines over which portion of the shared communication path the information channel will be carried. The configuration table and the connection table may be the same table or different tables.

In another embodiment of the invention, logical identifiers are maintained for conferences being handled by the telecommunications switching platform. The conference logical identifier contains information concerning which

SUBSTTTUTE SHEET(RULE 26) resources have been allocated in the switching module to provide the conference connections. When a higher-level application, such as the call processor, wants to provide a conference connection, it will request a set of conference logical identifiers. If conference resources are available, then the application will be able to make 1-way or 2 -way connections to the logical identifiers assigned to the conference. Normally 2 -way connections will be assigned to these conference logical identifiers, although in certain circumstances, one-way connections may be assigned.

A database of configuration data for resources in the switching platform is built at initialization of the telecommunications system, including the construction of logical components identifiers for the resources in the switching platform that can be used as indices to the database, allowing for the dynamic remapping of resources by dynamically updating the configuration database.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGURE 1 is a block diagram of an embodiment of the claimed telecommunications switching platform;

FIGURE 2 is a block diagram of lower-level functional elements within the telecommunications switching platform of FIGURE 1;

FIGURE 3 is a timing diagram illustrating the multiplexing of telecommunications channels upon the high- speed buses of FIGURE 2;

FIGURE 4 is a system-level block diagram illustrating how connections may be formed through the telecommunications switching platform of FIGURE 1;

SUBSTTTUTE SHEET(RULE 26) FIGURE 5 is timing diagram for several high-speed buses, illustrating the switching task performed by the switching module of the telecommunications switching platform;

FIGURE 5A is a block diagram of the telephony-support module of FIGURES 1-2;

FIGURE 6 is a task flow diagram illustrating the interfaces to a configuration task;

FIGURE 6A is a software block diagram of the control framework, communications buffering, and software resources operating on the telephony-support module of FIGURE 5A;

FIGURE 7 is a flow diagram of the steps taken by the switching module upon startup of the telecommunications switching platform;

FIGURE 7A is a block diagram of an embodiment of the hardware supporting the communications buffering function of FIGURE 6A;

FIGURE 8 is a block diagram of the switching module of FIGURES 1-2;

FIGURE 9 is block diagram of the interface module of FIGURES 1-2;

FIGURE 9A is a flow diagram of a Primary Heartbeat Messaging function;

FIGURE 10 is a block diagram of another embodiment of the telephony-support module;

SUBSTTTUTE SHEET (RULE 26) FIGURE 10A is a flow diagram of a Secondary Heartbeat Messaging function

FIGURE 11, is a block diagram of the signal -processing module of FIGURES 1-2;

FIGURE 12A-B is a block diagram illustrating a configuration table used to store Logical Component Identifiers (LCIs) and other information concerning system resources and information channels; and

FIGURES 13A - 13D illustrate an exemplary flow diagram of the steps taken in translating and interpreting logical identifiers according to an embodiment of the present invention.

All of these drawings are drawings of certain embodiments of the invention. The scope of the invention is not limited to the specific embodiments illustrated in the drawing and described below. Instead, the scope of the invention is set forth in the claims.

SUBSTTTUTE SHEET(RULE 26) DETAILED DESCRIPTION OF EMBODIMENTS FIGURE 1 is a block diagram of an embodiment of the present invention. This block shows the overall telecommunications-switching platform 10. This switching platform 10 includes redundant call processors 12 and Network Management System ("NMS" ) servers 14 as well as switching modules 16 and resource processors 18,20,22 that carry out a number of the lower-level tasks to be accomplished by the switching platform 10. Resource processors include, for example, a telephony-support module 18, an interface module 20, and a signal -processing module 22.

The switching modules 16 and resource processors 18,20,22 communicate with each other through, for example, a control bus 24. Data is passed between these same elements over highspeed data buses 25, which are preferably time-multiplexed serial data buses. The operation of these high-speed data buses 25 will be described in greater deal in FIGURES 2-3 and the text accompanying these figures.

Still referring to FIGURE 1, the switching modules 16 preferably communicate with higher-level functional elements (the call processors 12, for example) within the platform 10 through communication hubs 26. In an embodiment of the present invention, logical communication paths are made between the resource processors 18,20,22 and the higher-level functional elements via the switching module 16 through, for example, TCP/IP sockets through the communication hubs 26.

The communication hubs 26 connect the call processors 12 to the switching modules 16 and the NMS servers 14. Preferably, there are two distinct LANs 28,30 within the call processor 12. The first LAN 28 connects the redundant call processors 12 to the redundant NMS servers 14 and redundant switching modules 16 through redundant communication hubs 26. The second LAN 30 can connect the redundant NMS servers 14 to local NMS clients 32 and/or remote NMS clients 34.

SUBSTTTUTE SHEET(RULE 26) Connection to remote NMS clients 34 is preferably performed through a router 36 and a modem 38. Since there is no direct NMS client access to the first LAN 28 on which the call processors 12, the switching modules 16, or the resource processors 18,20,22 operate, the NMS servers 14 may serve as "firewalls" against hacker intrusion into the switching platform 10.

With further reference to FIGURE 1, the interface modules 20 connect externally to telecommunication spans 40 (see

FIGURE 2) , which are, for example, industry-standard Tl or El spans each carrying a number of information channels as specified by the particular standard. These information channels may be telecommunications traffic channels or telecommunications control channels, as will be discussed below. Connection to the spans are made through span signal paths 41 from the interface modules to a span connector panel 42, which is the point at which the telecommunication spans 40 (see FIGURE 2) physically connect to the switching platform 10.

Collectively, the switching modules 16, resource processors 18,20,22, control buses 24, high-speed buses 25, span signal paths 41, and span connector panel 42 are referred to as the Input/Output Sub-System ("IOSS") platform 27. In one embodiment of the present invention, the IOSS platform 27 resides on a single shelf within a telecommunications equipment rack and performs the lower-level functions within the telecommunications switching platform 10

Control bus 24 preferably comprises a pair of redundant control buses 24, over which the various resource processors 18,20,22 communicate using, for example, a Local COMmunication (LCOM) protocol. Although the high-speed data buses 25 are sometimes referred to as PCM buses, where PCM stands for Pulse Code Modulation, which is a digital voice encoding standard, the data carried on them may include control information,

SUBSTTTUTE SHEET (RULE 26) signaling information, data information, and voice information encoded using other standards. For example, voice information that has been encoded by a Global Standard for Mobile Communication (GSM) system are encoded using a certain type of Linear Predictive Coding (LPC) .

Communication hubs 26 are preferably Ethernet Local Area Network (LAN) communication hubs, although the hubs 26 may be hubs for other local networking protocols such as, for example, Token Ring or StarLAN. The communication hubs 26 and protocols may operate using either wired or wireless connection schemes. Although the resource processors 18,20,22 preferably communicate with higher-level functional elements in the system through the switching module 16 via Transmission Control Protocol/Internet Protocol ("TCP/IP") sockets through the communication hubs 26, other networking protocols are possible. It is also possible, for example, to have such resource processors 18,20,22 directly connected to the higher- level elements in the system such that they will be directly addressed by these high-level elements using data and address buses .

"Lower-level" functions, which are described above as being performed by the IOSS platform 27 might be defined, for instance, as all functions within the Open System

Interconnection ("OSI") framework as being below the Session Layer (Layer 4) . Under such a division, the IOSS platform 27 would be responsible for communications routing and end-to-end delivery of information, including error recovery and flow control.

FIGURE 2 is a block diagram of lower-level functional elements within a telecommunications switching platform 10. At the center of this block diagram are the redundant switching modules 16, which connect to the higher-level functional elements in the platform 10 through the communication hubs 26. In this embodiment, all communications

SUBSTTTUTE SHEET (RULE 26) between the higher-level functionality and the resource processors 18,20,22 are routed through, for example, the active, or ONLINE, switching module 16 instead of the inactive or OFFLINE one of the redundant switching modules 16.

The switching module 16 performs a number of functions. For example, one function of the switching module 16 is switching the telecommunication information channels arriving into the platform 10 through the telecommunications spans 40. As shown in FIGURE 2, telecommunication spans 40 are connected to the interface modules 20. Information channels are transmitted within the spans 40 through, for example, time division multiplexing. The switching module 16 contains switches 43, which are responsible for making the connections between information channel inputs and information channel outputs according to commands from the higher-level functionality within the platform such as the call processor 12. The software function within the call processor 12 that controls switching of the information channels at the applications layer may be called the Resource Manager.

The switching platform 10 is also operable to, for example, receive from and transmit to GSM-standard mobile phones. Under the GSM standard, wireless voice channels are transmitted at 16 kbps ("kbps"), using LPC coding, whereas under many land-based telephony standards voice channels are transmitted at 64 kbps using PCM coding. Thus, in order to connect a mobile caller to a land-based called party, it is necessary to adapt the rate of the 16 kbps GSM voice channel to the land-based 64 kbps standard. This rate conversion is accomplished by, for example, a signal processing module 22.

With continued reference to FIGURE 2, a GSM Base Transceiver Station (BTS) 44 (see FIGURE 4) transmits four GSM voice channels on a 64 kbps DS0 information channel. The telecommunications switching platform 10 connects the 64 kbps DS0 channel from the BTS 44 to a signal-processing module 22

SUBSTTTUTE SHEET (RULE 26) so that the signal-processing module 22 can convert this DSO information channel into four discrete 64 kbps PCM-encoded channels. These four 64 kbps information channels are then switched to four different information channels. The final switching of four channels to four different channels will accomplish the end-to-end switching, or will connect one or more of the GSM voice channels to one of the telephony support functions (such as dial tones or tone generation or tone decoding) .

Since voice connections are bi-directional or full- duplex, the connection process described above is carried out in the reverse order to receive signals from the land-based information channels. Thus, the switching module 16 connects one 64 kbps DSO channel to the signal-processing module 22, then connects the four 64 kbps channels outputs from the signal-processing module 22 to four different 64 kbps information channels, and these connections are duplicated in the reverse direction, for a total of 10 switch connections.

Still referring to FIGURE 2, connection is made between the information channels and the resource processors 18,20,22 and the switching modules 16 through a series of high-speed buses 25. As shown in FIGURE 2, there are a total of 12 such buses used in this embodiment. For future capacity expansion, spare high-speed buses 25 may be included within the telecommunications rack and switch 43 may be configured to switch information channels on these additional buses. This embodiment includes four such spares, for a total of 16 high- speed buses. Each of these buses 25 operate at an exemplary data rate of 8.192 megabits per second ( "Mbps" ), which gives each bus 25 a capacity for 4 El spans, each El span having a bit rate of 2.044 Mbps. Each of these buses 25 is logically subdivided into 128 timeslots 46 (see FIGURE 3) . Each of these 128 timeslots 46 may be, for example, a 64 kbps channel. To share each of these buses between the various resources within the telecommunications switching platform 10, each

SUBSTTTUTE SHEET(RULE 26) resource or incoming information channel is assigned a certain position or timeslot within the buses 25 to which they are attached. The present invention, as set forth in certain of the claims hereinbelow, includes a novel method for assigning, maintaining, and utilizing the assignment of these timeslots 46 (see FIGURE 3) to the various resources and information channels within the platform 10.

The switching module 16 uses a switch 43 to make connections between a timeslot 46 on one bus 25 to a different timeslot 46 on that same bus 25 or another bus 25. In an embodiment of the present invention, the switching module 16 is capable of connecting any of 2048 inputs to 2048 outputs. All of these connections can preferably be maintained simultaneously. The resources used within the switching platform 10 may be dynamically assigned based on system needs. As mentioned, the interface modules 20 form the entry and exit points for telecommunications spans 40 that are connected to the switching platform 10. Each of these interface modules 20 is capable of handling, for example, four El spans 40. Each El span may be comprised of 32 channels including 30 voice channels transmitted at 64 kbps, one 64 kbps framing channel, and one 64 kbps signaling channel. There are a total of six interface modules 20 shown in FIGURE 2, each of which is preferably capable of handling four spans 40.

The switch 43 is preferably a Time-Space-Time switch, which is a space switch (i.e., a matrix switch) interposed between two time switches.

FIGURE 3 shows how telecommunications channels may be multiplexed onto a single high-speed bus 25. In this embodiment, 128 traffic and/or information channels are multiplexed together to form a single frame that repeats every 125 μs . Each of the timeslots 46, which are numbered 1 through 128 in FIGURE 3 and begin repeating again after 128 timeslots, preferably comprises a group of eight contiguous

SUBSTTTUTE SHEET (RULE 26) bits occurring every 125 μs . These repeating groups of bits are designated in the exemplary timeslot 1 (as shown by the break-out Figure for that timeslot) as BO through B7.

FIGURE 4 illustrates how connections may be formed through a telecommunications switching platform 10. In this embodiment, four GSM mobile phones are shown in wireless communication with a BTS 44. By the time the GSM-encoded voice signals are transmitted from the BTS 44 to the switch platform 10, they form a 64 kbps DSO information channel 49, which would preferably be transmitted within a telecommunications span 40 as discussed above. The span 40 is then received by the interface module 20 and is passed from there to the switching module 16. Because there is no reason to change the assignment of this GSM-encoded information channel 49 into the switching module 16, and because the GSM- encoded information channels 49 will preferably always have to be rate-adapted by the signal-processing module 22, it is advantageous to semi-permanently connect and assign the information channel to the signal-processing module 22. This semi-permanent connection is referred to as an "nailed-up" connection 47. In accordance with this designation, the addressing information required to maintain this connection through the switch 43 is stored in a configuration table within the switching module 16. The addressing information is maintained there until the system is reconfigured or until an error occurs such as a component failure or a board is removed^which would require the connections to be reconfigured.

Still referring to FIGURE 4, within the signal -processing module 22, a DSO channel comprising four 16 kbps GSM voice channels is expanded into four PCM-encoded information channels 48. This expansion is shown within the Transcoder Rate Adaptation Unit ("TRAU") functional block of the signal- processing module 22. These four PCM-encoded voice channels are then passed again back through the switching module 16.

SUBSTTTUTE SHEET(RULE 26) Since these various voice channels are switched in real time so that the GSM telephone users can make and receive phone calls to different individuals, the switching module 16 makes real-time switching assignments or connections 19 for these PCM-encoded voice channels 48. Thus, the switching module 16 dynamically updates the connection information describing how the circuits will be switched through the switch 43. In this example, the four PCM-encoded voice channels 48 are all passed through the same or different interface modules 20 and are then transmitted to the Public Switched Telephone Network (PSTN) .

Instead of connecting GSM callers to other parties through the PSTN, a GSM caller may call another GSM mobile telephone also connected to the same telecommunications switching platform 10. In that circumstance, one of the PCM- encoded voice channels 48 would be re-routed through the switch 43 to another channel of a signal-processing module 22 to be rate-adapted back to a 16 kbps GSM-encoded information channel 49 and then passed again through the switching module 16 and through the original or another interface module 20 to the same or another BTS 44. Again, the routing involved in such an end-to-end connection through the switching platform 10 can be very complex.

FIGURE 5 is a diagram showing the switching task that is accomplished by the switch 43 within the switching module 16. On the left-hand side of the figure, three exemplary bus inputs and outputs (high-speed buses 25) are shown. In the embodiments described above, there are twelve such high-speed buses 25 that pass through the switch 43. The switch is capable of receiving all of these buses and switching a timeslot from any position on any input bus 25 to any position on any output bus 25. For example, in this figure the data from timeslot 1 of input bus 1 (Bl_l) is placed in timeslot 2 of output bus 1 , as indicated by the arrow drawn between these positions. Similarly, the data from timeslot 2 of bus 1

SUBSTTTUTE SHEET(RULE 26) (Bl_2) is placed in timeslot 0 of output bus 2 (B2_0) , and so on. For illustration purposes, a number of other channel connections are illustrated in this figure. In the preferred embodiment, the switch 43 is capable of connecting in this manner any of 128 timeslots on any of the twelve input buses 25 to any of 128 timeslots on any of twelve output buses 25.

FIGURE 8 provides an exemplary block diagram of the switching module 16. In this embodiment, the switching module 16 provides functions such as, for example, switching (SWTH task 70, see FIGURE 6) ; conferencing; data communication; local communications (LCOM task 74, see FIGURE 6); remote LAP-

D communications (RLPD task 66, see FIGURE 6); and an Ethernet interface .

FIGURE 8 shows the switching module 16 from a hardware perspective. The switch 43 in this embodiment is, for example, a 2048-by-2048 memory timeslot, non-blocking switch implementation. The switch 43 may be, for instance, a Time- Slot Interchange Random Access Memory (TSIRAM) . The switch 43 operates to receive and transmit over a number of high-speed buses 25, making timeslot cross connections from one timeslot of one high-speed bus 25 to a different timeslot within the same high-speed bus 25 or another high-speed bus 25, as was discussed with respect to FIGURE 3. It is possible to accomplish this function using, for example, four SIEMENS Memory Time Switch Large (MTSL-16) components, although other components may provide the same function. All timeslot cross connections preferably take place within this switch 43. This will provide capacity for sixteen high-speed buses 25 (e.g., 8.192 Mbps buses) to interconnect modules on the backplane along internal components of the switching module 16. Each 8.192 Mbps bus 25 provides one hundred and twenty-eight 64 kbps timeslots.

The Remote LAPD (RLPD) data function preferably comprises 32 communications channels and is implemented with network

SUBSTTTUTE SHEET (RULE 26) interface controllers 152 and a bus multiplexer 154. Like other information channels and resources, these RLPD channels have logical identifiers or LCIs associated with them. The Resource Manager uses this logical identifier information to route the RLPD channels. This function is implemented in this embodiment using a Siemens Multichannel Network Interface Controller (MUNICH32) for the network interface controllers 152 and a MUSAC-A in switch mode as a bus multiplexer 154. Any or all of the 32 channels are connected to the proper paths through the switch 43. Each channel can support 64 Kbps or sub-rate (i.e., less than 64 Kbps) data rates. These channels are preferably used for any type of HDLC-based communications required of the system.

Still referring to FIGURE 8, the Local Communications

Function 74 preferably comprises a point-to-multipoint control bus link 24 between the switching module 16 and the resource processors 18,20,22. This function is preferably provided by a LCOM controller 155, which may, for example, be a SIEMENS Enhanced Serial Communications Controller (ESCC2) , although other components are commercially available to serve this local communication function. A second link 24 is provided for redundancy. This bus 24 provides part of the communication path between the applications processor 12 and modules local to the backplane 16,18,20,22. The switching module 16 completes the path to the applications processor through local communication network 28. The switching module uses this same network 28 for its communication path to the application processor 12. The local communication (LCOM) software task 74 is represented on FIGURE 6, and is executed on the switching module 16.

The network 28 is preferably an Ethernet LAN, connected through a lOBaseT connector on the front of the switching module 16 which is implemented, for example, using a MOTOROLA Enhanced Ethernet Transceiver (EET) and an Ethernet controller that is integrated into the switching module controller 156.

SUBSTTTUTE SHEET (RULE 26) The controller 156 additionally provides supervisory control of all the tasks that execute on the switching module 16. Additionally provided, either integrated within the controller 156 or as components connected thereto (as shown in FIGURE 8) , are a memory 158 and a nonvolatile memory 160. The memory 158 preferably stores run-time code and data, and is preferably a Dynamic Random Access Memory (DRAM) having a capacity of at least 4 Megabytes. The nonvolatile memory 160 preferably stores a non-volatile backup copy of the run-time memory and is preferably a FLASH memory having at least 2 Megabytes storage. The nonvolatile memory 160 may contain hardware write-protected blocks of code for boot up. The runtime code can be downloaded and upgraded remotely, whereas preferably the boot code can be upgraded only after on-site removal of the hardware boot_block_protection feature. This protection is implemented in this way to protect the reliability of operation of the switching 16 module in the event of power failure during runtime code updates. A temperature monitor 162 may be provided to alarm upon ambient temperature thresholds being exceeded.

With further reference to FIGURE 8, the switching module 16 contains previously-described external connections, which are the redundant control buses 24, the high-speed buses 25, and the network connection 17. The switching module 16 also contains an internal address and data bus 163, through which the switching module controller 156 can access the memories 158,160 that are internal to the switching module 16. The switching module 16 also contains two internal high-speed buses 164, which may, for instance, be used to implement conferencing and LAPD functionality through communications with the conferencing unit 150 and the bus multiplexer 154. The bus multiplexer 154 may in turn be connected to the network interface controllers 152 through high-speed buses 166. These high-speed buses 166 are preferably high-speed serial LAP-D buses, although these buses may also be implemented with a lower data rate than is used in the other high speed data bases 25,164.

SUBSTTTUTE SHEET (RULE 26) A block diagram of exemplary interface module 20 is provided in FIGURE 9. The interface module 20 is the point at which the telecommunications spans 40 enter the switching platform 10. These connections are shown where the four spans 40 enter the interface module 20 and are connected to four line interface circuits 180. Depending on the ability to integrate the functions of the line interface circuit 180, these functions could be implemented in a single integrated component or in a greater number of components. Also, although interface module 20 is shown having four span connections, more or less spans 40 could be handled by a single module 20, depending on the state of the technology used and the complexity of the functions provided in a particular module.

With further reference to FIGURE 9, a span interface controller 182 provides control of the interface module 20. The span interface controller 182 communicates with other components within the interface module 20 through span interface address and data bus 184. The interface module 20 communicates with other components in the IOSS platform 27, particularly with the switching module 16, through the redundant control buses 24. The LCOM controller 186 is provided to implement the communications protocol by which this communication is carried out. Associated with the LCOM controller 186 is a nonvolatile memory 188 in which this interface module 20 can maintain its operating code in a nonvolatile fashion. Preferably, this nonvolatile memory 188 is a FLASH memory, whereby although the code is stored a nonvolatile fashion, it can still be changed with minimal effort. Another memory 189, a DRAM for example, is also provided for storage of the controller's 182 real-time executable code and data. A bus multiplexer 190 is provided so that in this embodiment the four telecommunications spans 40 can be multiplexed into a single high-speed bus 25 and transmitted to the switching module 16.

SUBSTTTUTE SHEET(RULE 26) Referring now to all the modules which are illustrated in FIGURES 5A, 8, 9, 10, and 11 to allow for more efficient system power-up, the interface modules of the present invention preferably have their operating codes stored in their nonvolatile memories, which can be reprogrammed without removing them from the system. For instance, the nonvolatile memory might be a Flash memory, or an Electrically Erasable Programmable Read-Only Memory (EEPROM) or it might be a battery-backed Static Random Access Memory (SRAM) , or it might another type of nonvolatile, reprogrammable memory. By keeping the operating code in a nonvolatile memory associated with the particular module, the preferred embodiment platform 10 eliminates the need for a time-consuming download of operating code into a large number of volatile memories associated with the modules 16, 18, 20, 22 in the platform 10. Instead, each main module controller powers-up ready-to- operate with its own operating code. Then, if necessary, perhaps while the platform is already up and operating, new operating system code can be downloaded and programmed into the nonvolatile memories of the modules 18 without interruption to the system or delay in the system power-up.

The download of the operating code from the high-level elements in the system preferably comprises the access of a hard disk drive connected to the call processors 12. Within the hard drive is stored a number of files containing the operating code for various processors on the switching modules 16 and resource processors 18,20,22 in the telecommunication switching platform 10. For example, a number of files might be assigned as follows according to the particular module in the switching platform and the resources operating on the modules :

SUBSTTTUTE SHEET (RULE 26)

Thus, for each cell in the above table that is marked with an "X", the call processor 12 and its associated hard drive (or other storage device) preferably will maintain a file containing operating code for the indicated process. If a resource processor wakes up already having valid operating code stored in it, the resource processor will begin operating from that code. If, on the other hand, a resource processor does not contain valid operating code on start-up, it will have to wait until at least some of these files are downloaded to it before it can begin operating. Also, when file updates are made to these operating code files, the Resource Manager level of the call processor can request that these file updates be made to the various resource processors 18,20,22 and switching modules 16.

The download of each of the files will preferably have a particular format that will identify the type of file that is being downloaded. Particularly, the file will have a file signature that identifies the generation of switching platform on which the file is to reside, the particular module, and the type of code within the particular module. The format of the file will preferably be as follows:

SUBSTTTUTE SHEET (RULE 26)

In the above file format, the first two bytes are preferably a JUMP code, which are preferably used only for the controller in the resource processor. Files not intended for the controller might include a false jump code such as, for example, "00." The "EOF" code is optional and preferably not needed in the file format, since there is a "LENGTH" field.

The flexible use of the volatile/nonvolatile memory arrangement described above allows, for example, the telecommunication switching platform 10 to download country- specific tone tables into the nonvolatile memory to be used as a part of the telephony-support module's 18 operating code. This gives the system significant flexibility in configuration for the often-unique signaling tones used in countries throughout the world. In the same way, the characteristic function of the tone-encoding and -decoding algorithms used by the DSPs A58 can be flexibly changed and updated. The tone- encoding and -decoding algorithms used by the DSPs A58, for example, can be adapted or programmed to handle multiple (See FIGURE 5A) standards.

Referring to an embodiment of the telephony-support module shown FIGURE 5A, another purpose served by the nonvolatile memory A54 could be the storage of voice messages when voice messaging is a function supported by the telephony switching platform 10. Again, like the interface module 20, the telephony-support module 18 includes an LCOM controller A56 that is operable to communicate with the other resource processors 18,20,22, and particularly with the switching module 16 through the redundant control buses 24.

SUBSTTTUTE SHEET(RULE 26) Still referring to FIGURE 5A, functions that may be performed by the telephony-support module 18 include voice messaging and tone decoding and generation for tones such as DTMF and MFR1/MFR2. Other functions include the generation of dial tones, busy signals, ring signals, trunk busy signals, and other functions. For example, when a telephone subscriber wishes to place a call, the phone number is entered by pressing numbers on the keypad of his phone. The phone or, in the case of mobile telephony, the BTS 44, generates signaling tones that identify each number that is pressed. These tones are passed over an information channel associated with the calling subscriber. The switching platform 10 processes these tones by switching them to one of the resource processors, e.g., the telephony-support module 18, which decodes the tones. These tones may be in the form of MFRl, MFR2 , or DTMF tones, or may be tones of another format. Once these tones have been decoded, the call processor 12 seeks to make a connection in accordance with the entered phone number. The call processor 12 then determines which information channel should be connected through to the subscriber. As the switching platform 10 seeks to make a connection to the number sought by the subscriber, tones are provided by the telephony- support module 18 to the subscriber's assigned information channel. These tones would include busy signals and ring signals. Throughout the establishment of a connection, the switching module 16 is continually making and breaking new connections between the subscriber's assigned information channel and various resources within the switching platform 10.

With further reference to FIGURE 5A, the function of generating and interpreting tones that are carried over the information channels is called upon when the switching platform 10 is attempting to establish connections between a subscriber and the party that the subscriber has dialed. The telephony-support module 18 interprets tones generated in response to keys pressed by the calling party subscriber, and

SUBSTTTUTE SHEET (RULE 26) provides either a busy signal, a ring signal, or some other signal, as the switching platform 10 attempts to make a connection to the called party. The DSPs A58 are responsible for this tone interpretation and generation.

A bus multiplexer A60 is provided to make the appropriate connections between information channels that have been routed to the interface module 20 and the appropriate to resources within the telephony-support module 18. Specifically, under the direction of the controller A50, the bus multiplexer A60 places incoming tones signals on the appropriate timeslot to be interpreted by one of the DSPs A58, and will read signals from the DSPs A58 and placed them on that high-speed bus 25 in the appropriate timeslot.

Continuing reference to FIGURE 5A, under direction of the controller A50, voice messages will be played back from the voice-message memory A57 or stored therein. Again, the bus multiplexer A60, under the controller's 50 direction, <will extract the incoming voice channels from the appropriate timeslots of the high-speed bus 25 and direct them to the appropriate address within the voice-message memory A57. In the reverse direction, the bus multiplexer A60 will read the stored messages from the voice-message memory A57 and place these messages in the appropriate timeslot on the high-speed bus 25.

Still referring to FIGURE 5A, the high-speed bus 25 comprises 128 transmit timeslots and 128 receive timeslots; as each of these timeslots is preferably a 64 kbps information channel, the high-speed bus 25 is preferably an 8.192 Mbps Time-Division-Multiplexed (TDM) bus. Preferably, the highspeed bus 25 shown in FIGURE 5A is dedicated exclusively to the telephony-support module 18 and, where applicable, the redundant telephony-support module 25.

SUBSTTTUTE SHEET(RULE 26) The bus multiplexer A60, which is preferably a Siemens MUSAC integrated circuit although other commercially-available multiplexers may be used, preferably switches these transmit and receive timeslots to the 6 DSPs A58. The DSPs preferably process data carried over four sub-high-speed buses 59, which each preferably carry 32 information channels or timeslots.

With further reference to FIGURE 5A, each DSP A58 preferably either receives a dedicated sub-high-speed bus A59 (preferably 2.048 Mbps) from the bus multiplexer A60 or shares a sub-high-speed bus A59 with another DSP A58. Each sub-highspeed bus A59 consists of 32 transmit and 32 receive timeslots. The controller A50 preferably programs the bus multiplexer A60 and determines how the high-speed bus 25 will be switched to the DSPs A58.

In one embodiment, the first sub-high-speed bus A59 is used to carry 31 timeslots for playing of digitized voice messages. This sub-high-speed bus A59 will be connected to a zeroeth DSP ("DSPO") 58. This DSPO preferably will use the other transmit timeslot and a receive timeslot for the Transmit and Receive FIFO function. In this embodiment, there are thirty-one other, unused, timeslots. In another embodiment, these unused timeslots could be used for either DTMF or MFRl decoders as processing bandwidth allows for the DSPO.

With continued reference to FIGURE 5A, the second sub- high-speed bus A59 is preferably used for a 32 channel tone generator. This sub-high-speed bus A59 is preferably connected to a first DSP ("DSP1") 58. This DSP1 preferably will use all its transmit timeslots to generate fixed tones using a table downloaded by the controller A50. In this embodiment, there are thirty-two unused receive timeslots. These timeslots could be used in other embodiments as, for example, MFRl or DTMF decoders, depending on the processing bandwidth for the DSP A58.

SUBSTTTUTE SHEET (RULE 26) The third sub-high-speed bus A59 is preferably used for a 16-channel tone generator and decoder. This sub-high-speed bus A59 is preferably shared by second DSP ("DSP2") and third DSP ("DSP3") . DSP2 will be used for MFRl or MFR2 decoders and will be split between the second DSP ("DSP2") and the third ("DSP3") . If each DSP uses each of its sixteen channels as MFR2 decoders, all transmit and receive timeslots allocated for this DSP will be used.

Still referring to FIGURE 5A, the fourth sub-high-speed bus A59 will be used for MFRl or MFR2 decoders and will be split between the fourth DSP ("DSP4") and the fifth ("DSP5") . If each DSP uses each of its sixteen channels as MFR2 decoders, all transmit and receive timeslots allocated for this DSP will be used.

The transmit timeslot utilization is the most allocated resource. This preferably allows for a maximum of 64 MFR2 decoders. While allowing many more MFRl or DTMF decoders due to the availability of receive timeslots and some free DSP utilization on DSPO and DSP1.

The interface between the controller A50 and each DSP A58 is preferably a two-register DMA controller, which is preferably integrated within the DSP A58. Each DSP preferably contains its own internal memory, and the integrated DMA controller allows controller A50 to read from or write to memory contained within each DSP A58. To communicate with the DSP A58, the controller A50 preferably writes an address to the DSP's 58 address port, then reads or writes data to that DSP's data port. Sections of the DSP's integrated memory are preferably partitioned within the DSP to allow the controller A50 to write commands, read the status of programs running within the DSP A58, and send/receive data to/from buffers that are controlled by individual programs running within each DSP A58.

SUBSTTTUTE SHEET (RULE 26) In continued reference to FIGURE 5A, each DSP A58 preferably comprises a built-in, flexible, serial TDM interface that allows connectivity to either a Tl-standard or El-standard high-speed bus 25. The DSP A58 preferably allows selective monitoring and tri-stating of individual timeslots. To "tri-state" an individual timeslot means to place the DSP in a high-impedance state during a certain timeslot so as to effectively make the DSP A58 electrically invisible during that timeslot. This "tri-stating" feature allows multiple

DSPs to share a single high-speed bus by only transmitting on certain timeslots.

Each DSP A58 preferably comprises integrated memory of at least 16Kx24 bit for its program code and 16Kxl6 for its data memory. Making the integrated memory at least this large allows the DSP software to be optimized for speed and also allows special functions to be implemented, including a sophisticated communications interface, large FIFO structures, audio buffers to reduce interrupt processing, and statically- allocated memory stacks for multiprocessing.

With continued reference to FIGURE 5A, the FIFO structures for instance, allow for efficient recording, playing, and saving of voice messages. These voice messages are preferably provided to notify callers of specific conditions of the telephony switching platform and can be programmed by a system administrator who calls a special number on a mobile or land line to make such a recording in the telephony-support module 18.

For recording of such voice messages, the DSP A58 sets aside some portion of its internal memory for the storage of audio. For example, the DSP might set aside 8192 words (8k) of memory. Once the voice message recording begins, the speech signal is carried to the DSP over a channel of its associated sub-high-speed bus A59. Preferably, when the DSP has recorded

SUBSTTTUTE SHEET (RULE 26) enough of the voice message to occupy half of the memory set aside for buffering within the DSP (4k words in this instance) , the DSP will set a flag in its memory indicating that fact to the controller A50. Depending on which half of the DSP buffer memory has been filled, the controller A50 can then proceed to read the correct portion of DSP memory and store or write it to the memory A52 , clearing the flag set by the DSP in the process . Once the person making the recording is satisfied with it, the controller A50 (according to instruction from that person) will transfer the speech data from memory A52 into nonvolatile memory A54.

A similar process occurs in playing voice messages from the memory A52 or nonvolatile memory A54. As data is loaded into the DSP A58 for it to play (by placing the data into the appropriate timeslot of the sub-high-speed bus A59, the DSP will set a flag once its internal speech data storage memory is half full (preferably) . The controller A50 at that time will cause the data to be placed on the sub-high-speed bus A59 depending upon which half of internal DSP memory had been filled.

Still referring to FIGURE 5A, each DSP A58 also comprises a two-register Internal Direct Memory Access ("IDMA") port, which allows the controller A50 to read data from and write data to each DSP A58 with minimal supervision by either the DSP A58 or the controller A50.

The DSP A58 further comprises a hardware scheme that supports autobuffering of data from the sub-high-speed bus

A59, which data from the bus A59 to be stored in buffers without occurring any interrupt overhead in transferring the data to memory.

The DSP application software comprises resource modules operating under a control framework. Each resource module is designed to be reentrant, meaning that multiple copies of each

SUBSTTTUTE SHEET(RULE 26) resource module may be run simultaneously. ^' further, each resource module preferably performs a single function. For example, within the DSP application software the DTMF decoder, MFRl transcoder, MFR2 transcoder, tone generator, receive FIFO, digitized announcement recording and playback, and Interprocessor Communications are all examples of resource modules. The control framework acts as an operating system, deciding which resource modules to run, allocating memory for those resources, collecting information to pass to the resources, and after the resource modules have completed execution, determining whether any action or state change is necessary.

The reentrant design of the DSP application resources allows the controller A50 to call upon the DSPs A58 for multiple instances of the various resources provided by the DSPs A58. Thus, if the controller A50 needs, for example, another MFR2 transcoder, the controller A50 commands the DSP A58 to activate that resource and another instance of that module is created.

Some functions such as dial tone generation and busy signal generation only involve generation of audio signals. Other functions such as MFR2 transcoding involve both generation and reception of audio signals. To make the resources as modular as possible, functions that involve both generation and reception of audio signals are preferably divided into separate modules, on for generation and one for reception/decoding. Therefore, all audio processing modules either process transmit audio or receive audio. Preferably, all audio resource modules are reentrant except for the digitized announcement functions.

In one embodiment of the invention, a unique logical identifier is assigned to each of the above-defined resources. Each of the resources is thereby assigned a timeslot 46 (see FIGURE 3) on the high-speed bus 25. No two resources process

SUBSTITUTE SHEET (RULE 26 the same audio. A single timeslot 46 will be used, for instance, to transmit the busy signal to the switch 43. Within the telephony-support module 18, and since the maximum number of audio sources that could be processed were 32 transmits and 32 receives, 64 memory segments can be statically allocated by determining the worst case stack usage by a transmit resource and multiplying that number by 32. The same allocation can be made for the receive resources.

Still referring to FIGURE 5A, since most communications are between a controller A50 and a DSP A58, instead of using a central communications routine to process each message and route it to a particular DSP, the logical identifier provides a way for the DSP A58 to create individual communications buffers for each particular resource. Thus, for the example of digit decoders, instead of the DSP A58 sending a message to the controller A50 when a digit was decoded, the control framework simply monitors the decoding resource module. When a digit is decoded, the control framework simply writes that digit to the receive buffer associated with the particular resource. This allows the controller A50 to read the digit some time later.

Preferably, there is also provided a set of status registers for each channel or logical identifier. These status registers enable the controller A50 to determine the current state of any resource on the DSP A58 at any time. Using the logical identifiers also eases control of the internal resources of the DSP. Instead of each resource module keeping track of which channel it is to process, a few simple structures allow the control framework to loop through all the active channels, determine which resources should be run, and send the proper audio buffer pointers, stack pointers, and state values to each resource since all information can be accessed using this channel key.

SUBSTTTUTE SHEET(RULE 26) Therefore the interface between the control framework and any resource preferably consists of a pointer to the audio buffer, a pointer to the stack holding the current state of the resource, and various controller-configurable values. Once the resource is complete, a state is returned along with any processed information, such as decoded digits.

Further, what may appear to be one resource to the controller can be multiple internal resource modules (see FIGURE 6A) coordinated by the control framework, like the MFR2 forward/backward transcoder. Actually, this resource is preferably an MFR2 decoder A74 coordinated with the tone generator resource A62. If a modem were used in the telephony-support module DSP software, it would actually be many internal resources: a modem transmitter, a modem receiver, a tone generator, and a transmit and receive rate converter.

The tone generator A62 shown in FIGURE 6A is a reentrant module that actually contains an internal dual tone generator that can be controlled in five different ways. These ways (or tone classes as they are referred to in the communications section) are determined by what kind of tone is to be generated. Class one generates continuous tones, class two generates cadenced tones, class three generates a series of

DTMF digits, class four generates a series of MFRl digits, and class five generates a series of preprogrammed tones. The resource is passed a pointer to the stack, a pointer to the transmit audio buffer to be filled, the number of active transmit channels, and the duration of audio to be processed.

The resource A62 returns a state flag indicating whether the tone generation has been completed. Classes one and two are continuous and do not complete. In the other classes, the state flag is returned from the resource indicating when the resource has completed generating the sequence.

SUBSTTTUTE SHEET(RULE 26) Still referring to FIGURE 6A, the DTMF/MFR1/MFR2 forward/MFR2 backward decoder are reentrant resource modules . MFR2 forward and MFR2 backward are designated in the drawing and discussed herein as a single module; preferably these will be implemented as separate modules but they could be accomplished in either fashion. Although these resource modules are physically different modules, the interfaces to these modules A66, A70, A74 are preferably identical. All these resource modules preferably decode dual tones, but each has different specifications for the frequency, duration, audio quality, and filtering. These resources are passed a pointer to the stack, a pointer to the receive audio buffer to be filled, the number of active receive channels, and the duration of audio to be processed. The resource returns a digit if one has been decoded and validated, otherwise it returns a zero value is returned for MFR2 and a negative 1 for MFRl and DTMF.

The audio storage resource A78 preferably monitors audio and stores audio in a small circular buffer. When audio is detected, the contents of the buffer is stored at the beginning of one FIFO and the additional audio is stored afterwards. When one FIFO is filled, the resource A78 begins storing audio in another FIFO. The resource is passed a pointer to the receive audio buffer to be processed and the number of active receive channels. The resource module returns a value indicating if FIFO 1 or FIFO 2 has been filled. This function is preferably not a reentrant module, meaning that preferably no more than one instance of this module can be run at the same time.

With further reference to FIGURE 6A, the audio playback resource A82 plays audio from one FIFO until it is empty, then begins playing audio from another. The resource A82 is passed a pointer to the receive audio buffer to be processed and the number of active receive channels. The resource module returns a value indicating if FIFO 1 or FIFO 2 has been

SUBSTTTUTE SHEET (RULE 26) emptied. Like the audio storage resource A78, audio playback resource A82 is preferably not a reentrant module.

The control framework handles some of the functions of an operating system including allocating memory, scheduling and prioritizing tasks, and interfacing to low level driver software. The control framework consists of a startup routine and one main loop that cycles through active transmit and receive channels. Inside the loop, the framework tests whether any transmit or receive resources are active for the current channel. If a resource is active, the state of that resource is determined, information for that resource/channel combination is calculated and passed and the resource is executed. Once the resource has completed processing, the return values are used to determine any state changes or necessary actions to be taken. For example, if a tone generator returns that it has completed the assigned generation, several events occur: the status buffer is set to indicate that the transmit is complete, the resource is stopped from running (it is not deactivated) , and the transmit stack and transmit communication buffer for that channel is cleared.

Once all active channels have been processed, the applications software has completed processing. The control framework then returns control to the driver software, which determines whether audio is ready to be processed. If audio is not ready, the driver software activates a communications routine which processes commands from the controller A50.

The startup routine in the control framework takes care of the following tasks : all transmit audio buffers are cleared, the command string is validated and processed if a command has been written by the controller A50, and the timer subroutine is run. The timer subroutine takes care of any control functions that need a time-out such as the DTMF and MFRl decoders A66, A70. After a certain duration has passed

SUBSTTTUTE SHEET(RULE 26) and no digits have been detected, the timer routines expire and a bit is set in the status register for that channel indicating that the reception is complete and that the buffer can be read.

Referring now to FIGURE 7A, with continued referenced to FIGURE 5A, the DSP communications interface A92 is based on a buffer system, since the controller A50 can directly access DSP memory. The controller A50 sends commands to the DSP command buffer and any transmit data is written to the communications transmit buffers. When an action occurs within the DSP it is reflected in the status buffer and any receive information detected by the DSP A58 is reported. Using buffers allows the controller A50 to treat the resource modules as intelligent distributed hardware devices rather than having all communications pass through a control process within the DSP A58.

There are five type of buffers utilized in the communications interface: command, communications, FIFO, pointer, and status. The command buffer is used to send command from the controller A50 to the DSP A58. The communications buffers are accessed to send data to and receive data from resources running on particular channels or timeslots. The FIFO buffers are used to buffer audio between the sub-high-speed bus A59 and the controller memory A52 or voice message memory A57 for the digitized announcement functions. The pointer buffer is absolutely located at a certain, IDMA address (0x4000) and contains the location of all other buffers. The status buffer contains the run-time status of the various resources.

The controller A50 uses the IDMA port of each DSP for communications. The IDMA (Internal Direct Memory Access) port 88 consists of two registers: an address register and a data register. In order to read information from the DSP A58, the controller A50 writes an address to the address register, then

SUBSTTTUTE SHEET(RULE 26) reads from the data register. In order to write information to the DSP A58, the controller A50 writes an address to the address register, then writes to the data register. If the read or write operation is working on consecutive data access, like reading or writing a buffer, only the first address needs to be written. After the first data access, the address can be automatically incremented. Preferably, all DSPs on the telephony-interface module 18 will have a separate IDMA port mapped to the I/O of the controller A50.

Still referring to FIGURES 5A AND 7A, to communicate with the DSP, the controller A50 reads and writes to several buffers. A difficulty arises when with new revision of DSP software, the location of these buffers can change dramatically. The solution to this problem was to create a statically-located buffer containing the location of the other buffers and a static map to tell where each pointer is located in the static buffer. This static buffer is called the pointer buffer A94. In one embodiment, the pointer buffer is statically located at a certain IDMA address at the beginning of data memory. A map can then be defined with addresses relative to the pointer buffer A94 , and these addresses for the various transmit and receive buffers can be converted to their IDMA addresses by adding the certain IDMA address to each of the relative addresses.

For example, the addresses given below are data memory addresses. Assuming the certain IDMA address for the static pointer buffer is at 0x4000, addresses may be converted to IDMA addresses by adding 0x4000 to each address.

Address Buffer Pointer Addres Buffer Pointer s

0x0000 Status Buffer 0x0001 Command Buffer

Pointer Pointer

0x0002 Channel 1 Transmit 0x0003 Channel 1 Receive Buffer Buffer

0x0004 Channel 2 Transmit 0x0005 Channel 2 Receive Buffer Buffer

SUBSTTTUTE SHEET (RULE 26) 0x0006 Channel 3 Transmit 0x0007 Channel 3 Receive Buffer Buffer

0x0008 Channel 4 Transmit 0x0009 Channel 4 Receive Buffer Buffer

0x000A Channel 5 Transmit OxOOOB Channel 5 Receive Buffer Buffer

OxOOOC Channel 6 Transmit OxOOOD Channel 6 Receive Buffer Buffer

• • • •

In addition to communicating with the DSPs A58, the controller A50 also effects communication with the switching module 16 through the LCOM controller A56. A unique protocol has been adapted for communications among the switching module 16 and the resource processors 18,20,22 over the control bus 24. The LCOM protocol has driver software that is compiled to run on the controller for the switching module 16, as well as the controllers for the resource processors 18,20,22. The LCOM protocol also has an applications layer or applications software, which operates at the higher level above the driver software .

Preferably, the LCOM driver code is cross compiled to the controllers for the resource processors 18,20,22 and the switching module 16. The LCOM driver is capable of managing the redundant control buses 24, which are preferably two ESCC2 synchronous serial buses operating at up to 256 Mbps each. The LCOM driver comprises an interrupt service routine and receive and transmit queues .

Referring to FIGURE 6, the LCOM driver in the switching module 16 utilizes two tasks, LCOM 74 and LCMR, to provide routing to and from the driver software.

The driver transmits and receives one message per frame. In one embodiment, the message has the following format:

SUBSTTTUTE SHEET(RULE 26)

The first four bytes of the message is the LCOM_HEADER, which is available only to the LCOM software.

Referring to FIGURE 6, on the switching modules 16 and resource processors 18,20,22, there are preferably two transmit queues, one for each transmit bus 24. A message is placed in a transmit queue with a LcomSendMessage call 72. LcomSendMessage 72 has the following format:

UINT1 LcomSendMessage (UINT1 processor_id, UINT1 process id,

UINT2 length, void FAR *msg)

The "processor_id" field is the slot id of the desired destination board. The slot id is simply the slot in which the desired destination board is located. There are two exceptions to using the slot id: BID_SDM is used in place of the slot id to send to the switching module 16; BID_PSM is used in place of the slot id to send to the on-line telephony- support module 18.

The "process_id" field preferably identifies either a task on the switching module 16, such as the tasks 62, 66, 70, 74, 78, 82, 86, 90 or a pseudo-task on the resource processors 18,20,22.

The "length" field is the length of the raw message. This length does not include the length of the LCOM_HEADER, which is preferably four bytes.

SUBSTTTUTE SHEET (RULE 26) The "msg" field is any data of any data type, although the message's length is preferably limited by a constant known to the software.

Still referring to FIGURE 6, on the switching module 16, there is preferably no prerequisite to calling LcomSendMessage 72, but on the resource processors another function, NewMessage, is called before LcomSendMessage. NewMessage allocates a queue link. This queue link is then added to the transmit queue when LcomSendMessage is called.

In the OFFLINE switching module 16 (in embodiments having redundant switching modules 16) , the message is discarded and is not added to the transmit queue.

The type of message preferably determines which queue the message is placed in. On the resource processors 18,20,22, if the message is a normal traffic message, it is placed in the queue that serves the primary bus 24. If it is an LCOM application message, the message is placed on either a primary or a secondary bus 24. On the switching module 16, if the message is a normal traffic message, the Heartbeat Table determines in which queue the message is placed. If it is an LCOM application message, the message may be placed on either of the buses.

On the resource processor boards 18,20,22, the queues are repeatedly checked for messages to be transmitted. If a message is ready, and the corresponding driver transmit buffer is ready, the message is taken off the queue and placed in the driver transmit buffer.

On the switching module 16, when a new message is added to a transmit queue, an event wakes up the LCOM task 74. Messages are taken from the transmit queues until the queues are empty. Each message waits for the appropriate transmit

SUBSTTTUTE SHEET (RULE 26) buffer to become available before it is placed in the driver transmit buffer.

For either the switching module 16 or any of the resource processors 18,20,22, once a message is placed into the driver transmit buffer, a first group of bytes, preferably thirty- two, are moved to the LCOM Controller's 56 transmit FIFO. This controller is shown on the telephony-support module block diagram, FIGURE 5A, but analogous controllers preferably exist on each of the switching modules 16 and resource processors 18, 20, 22 for interfacing with the redundant control buses 24.

When another group of bytes are transmitted by the LCOM controller A56, an interrupt is generated, and another group of bytes are moved to the LCOM Controller's 56 transmit FIFO. This continues until the entire message is sent. The message is preferably sent in constant-size groups of thirty-two in this embodiment. Even the last group is preferably the same size as the other groups. For this reason, the transmit buffer size of the LCOM driver is preferably divisible by the size of each group of bytes. If there is a transmission error and the error is recoverable, the buffer index is reset, the message is moved to the LCOM Controller's 56 transmit FIFO, and the transmission process is repeated.

As with transmission, messages are received by the LCOM Controller A56 in constant-size groups of bytes, so the receive buffer size of the driver is preferably divisible by thirty-two. As each block is received, an interrupt is generated, and the group of bytes are moved from the LCOM Controller A56 receive FIFO to the LCOM driver receive buffer.

This continues until the entire message is received. Then the message is added to the receive queue. If there is a reception error, and the error is recoverable, the buffer index is reset, and reception occurs at the beginning of the message. If an error occurs which is not recoverable, this

SUBSTTTUTE SHEET (RULE 26) means that a message has been lost, and an error flag is set which eventually will cause an alarm.

On the resource processors 18,20,22, the receive queue is repeatedly checked for received messages. If one is available, it is taken from the queue and sent to a message distributor. The distributor routes the message based on only the process_id, which is the second byte of the LCOM_HEADER in this embodiment. The distributor uses the process_id to reference a table of function pointers. The referenced function is then called with the same parameters of LcomSendMessage 72. The following defines the interface of all resource processor message functions:

function ( UINT1 processor, UINT1 process_id, UINT2 length, void FAR *msg) ;

On the switching module 16, when a new message is added to the receive queue, an event wakes up the LCMR task. Messages are taken from the receive queue until the queue is empty. Each message is copied to the appropriate operating system queue based on the process_id of the message.

The LCOM software also exists at the applications layer. The software at this level comprises the following functions: "hot" resource processor 18,20,22 board insertion detection; individual resource processor 18,20,22 bus failure detection and recovery; individual resource processor 18,20,22 failure detection (including "hot" resource processor 18,20,22 board removal detection) ; and OFFLINE switching module 16 bus failure detection. These functions are implemented with the following mechanisms: Primary Heartbeat Messaging; Secondary Heartbeat Messaging; and OFFLINE Heartbeat Response Reception.

Primary Heartbeat Messaging occurs on the primary bus 24 of each resource processor 18,20,22. In this embodiment, the

SUBSTTTUTE SHEET (RULE 26) primary bus 24 is the bus 24 on which the resource processor is currently transmitting application messages. All bus traffic except for Secondary Heartbeat Messaging occurs on the primary bus 24. The primary bus 24 of a resource processor 18,20,22 is determined only by its broadcast address. If its broadcast address is LCOM_BROADCAST_ADDRESS_A, then its primary bus is Bus A. If its broadcast address is LCOM_BROADCAST_ADDRESS_B, then its primary bus is Bus B.

The switching module 16 uses these broadcast addresses to broadcast heartbeat messages to either all boards with primary bus A or all boards with primary bus B. The primary bus 24 only has meaning for the resource processors 18,20,22; therefore, the switching module 16 does not have a primary bus. It transmits application messages on both buses 24. Primary heartbeat messaging is used to detect hot board insertion, primary bus failure, and board failure.

Secondary heartbeat messaging occurs on the secondary bus 24 of each resource processor 18,20,22. In this embodiment, the secondary bus 24 is the bus other than the primary bus 24. Secondary heartbeat messaging is used to detect secondary bus 24 failure.

OFFLINE heartbeat response reception is not active. The

OFFLINE switching module 16 does not transmit on either the primary or secondary buses 24. The switching module 16 simply receives the same resource processor 18,20,22 responses that the ONLINE switching module 16 does. The OFFLINE heartbeat response reception is used to detect OFFLINE switching module

16 bus failure.

These functions and mechanisms are implemented with software on the resource processors 18,20,22 and the switching module 16. The switching module 16 application software consists of the LCOM heartbeat task (LCMH) and the Heartbeat_Table . The Heartbeat Table retains the state of

SUBSTTTUTE SHEET (RULE 26) each slot of the IOSS platform 27. Specifically, the Heartbeat_Table maintains status as to: whether each slot responds to a heartbeat poll; which bus 24 is used by each slot in its heartbeat response; and which bus 24 is the current transmission bus 24 for each slot.

Other functions that may be provided by the switching platform 10 include conferencing, voice messaging, and telephony support functions such as busy signals, ring signals, trunk busy signals and other functions. For example, when a telephone subscriber wishes to place a call, he will enter the phone number by pressing numbers on the keypad of his phone. The phone generates tones that identify each number that is pressed. These tones are passed over an information channel associated with the calling subscriber. The switching platform 10 processes these tones by switching them to one of the resource processors, i.e. the telephony- support module 18, which decodes the tones. Once these tones have been decoded, the call processor 12 seeks to make a connection in accordance with the entered phone number. The call processor 12 determines which information channel should be connected through to the subscriber. As the switching platform 10 seeks to make a connection to the number sought by the subscriber, tones are provided by the telephony-support module 18 to the subscriber's assigned information channel. These tones would include busy signals and ring signals. Throughout the establishment of a connection, the switching module 16 is continually making and breaking new connections between the subscriber's assigned information channel and various resources within the switching platform 10.

With reference now to FIGURE 11, a block diagram of an embodiment of the signal-processing module 22 is shown. The signal-processing module 22 is designed for rate-adapting the 16 Kbps GSM-encoded information channels 49 to and from the 64

Kbps PCM-encoded information channels 48 (see FIGURE 4) . This function is carried out, for example, by digital signal

SUBSTTTUTE SHEET (RULE 26) processors ("DSPs") 240. To allow flexible provisioning in this embodiment, the DSPs 240 are housed on daughter-boards 242. Up to four daughter-boards may be installed on the main module, although fewer daughter boards can be used if a full complement of daughter boards 242 is not required. In this embodiment, the daughter-boards 242 are configured to hold at least two DSPs each. Assuming, for example, that each DSP can process four GSM-encoded voice channels 49, the signal- processing module 22 thus provides up to 32 GSM ports in eight-port increments.

The bus multiplexer 254 in the signal-processing module 22 is responsible for connecting, under control of the controller 252, information channels from the PCM high-speed bus 25 to the DSP 240 signal processing resources. In addition to performing a rate adaptation, the DSPs 240 can be called upon to perform echo canceling when that function is required, particularly when the switching platform 10 is handling GSM-encoded voice channels 49. For maximum timeslot flexibility, in a preferred embodiment, two 32 -timeslot highways are available to each daughter-board 240. Thus, a fully populated signal-processing module 22 would occupy slightly less than one third of a 128 channel, 8.192 Mbps high-speed data bus 25. Accordingly, as shown in FIGURE 2, each signal-processing module 22 can share its high-speed data bus 25 with two other signal-processing modules 22.

FIGURE 6 is a task flow diagram illustrating interfaces to a configuration task ("CNFG") 50, which preferably executes in the switching module 16 and is responsible for all physical-configuration-related aspects within the platform (e.g., monitoring the number and type of boards, the backplane configuration, which connections have been "nailed-up," etc.). To maintain the platform database 52, which preferably includes a configuration table, messages containing configuration information are routed through CNFG 50. Upon receiving a message, CNFG 50 updates the database 52 as

SUBSTTTUTE SHEET(RULE 26) needed. If the message was destined for the switching module 16, CNFG 50 provides a response if needed. If the message was destined for one of the resource processors 18,20,22, CNFG 50 forwards the message to the appropriate resource processor 18,20,22.

According to an embodiment of the present invention, logical component identifiers (LCIs) are used as an addressing scheme to, for example, facilitate connections being made by the switching module 16. According to an embodiment of the present invention, an LCI is, for example, a 32 -bit number that identifies the shelf, slot and board type by the upper 16 bits, the lower 16 bits of the LCI being context dependent as a function of the board type. LCIs can be made by any component needing to generate an LCI using, for example, a macro or function call that can take the underlying data, such as the shelf, slot, board type, etc. and put the data into the LCI 32 bit format. For example, LCIs can be generated by the call processor 12 for each of the spans 40 to identify to the switching module 16 the traffic channels and LAP_D channels that are to be added, as well as to make and break connections. Similarly, the switching module 16 can generate

LCIs to establish nailed-up connections, the various LCIs generated representing, for example, the DSPs allocated to each nailed-up connection as well as the physical or logical circuits allocated to a traffic channel. In addition, the LCIs generated according to an embodiment of the present invention can be used as indices to the CNFG database 52 illustrated in detail in FIGURES 12A and 12B and discussed below.

The CNFG task 50 provides an interface to translate LCIs into high-speed bus 25 and timeslot 46 data for a SWTH task 70. The SWTH task establishes connections in the switch 43. These logical identifiers serve as indices to configuration database 52 that provides physical connection information to the CNFG task 50. CNFG task 50 passes the connection

SUBSTTTUTE SHEET (RULE 26) information to the switch 43 to make the appropriate connections between information channels on the high-speed buses 25. The CNFG task 50 will determine certain LCIs at system start-up.

An example of the building of a LCI is during system startup, at which time the switching module 16 receives description data from each installed resource processor 18,20,22, for example in the form of a registration message. When the registration information is received by the switching module 16, the CNFG task 50 utilizes the registration information (e.g., shelf, slot, board type) and builds a board LCI for each resource processor 18,20,22. The call processor 12 can also build LCIs. For example, the call processor 12 includes initial information on the components of the system (e.g., based on information manually provided by an operator during installation of the system) , such as span configuration and the configuration of individual timeslots. Thus, the information known by the call processor 12 as well as registration information provided from the switching module 16 to the call processor 12 at startup of the switching module 16 can be used by the call processor 12 to build LCIs for spans 40 on each interface module 20. The CNFG task 50 in the switching module 16 or the call processor 12 can use, for example, macros to build and manipulate each LCI. For example, MAKE macros can be used to put the data into the proper fields of the LCI while the macros can be used to allow retrieval of the particular fields of interest in the LCI.

According to an embodiment of the present invention, LCIs are 32 bits although all of the bits may not be used for each LCI. For example, when addressing IOSS Platform boards 27, the LCI is constructed using the shelf, slot, and interface fields. Any remaining fields will be set to NONE. All boards within the IOSS Platform 27 (e.g., resource processors

18,20,22) are addressable in this manner. The below table demonstrates Board LCI 0x0054FFFF, residing at slot 5 on shelf

SUBSTTTUTE SHEET(RULE 26) 0 and is a board type 4, which is an arbitrarily selected designation for an interface module 20 according to an embodiment of the present invention.

5

Shel Slot Board Span Type Span Logical f Type circuit

4 8 4 bits 4 bits 4 bits 8 bits bits bits

0 0x0 0x5 0x4

OxF OxF OxFF

Preferably, the upper or most significant 16 bits of the above exemplary 32-bit logical identifiers or LCIs consistently provide the same types of information, i.e., shelf, slot, and board type. The lower 16 bits are preferably context-sensitive, depending upon the type of resource or communication channel that is being identified.

To make the LCI, the shelf, slot, and board_type data is preferably provided to a MAKE_BOARD_LCI macro, which would then generate the properly-formatted LCI. For example, to create a LCI for a span 40 on an interface module 20, a trunk LCI would be used to address individual circuits (e.g., DSOs) on an interface module 20. When the specified span being addressed is configured as a land span (e.g., a PSTN span), the physical circuits are used to construct the LCI, as each timeslot (DSO) on the span carries a PSTN traffic channel. However, if the specified span is configured as an air span (e.g., a GSM span), then logical circuits are used to do the mapping to the air traffic channel, as each physical timeslot

(e.g., a 64kbps DSO) carries four air traffic channels (e.g., 4 16 kbps GSM traffic channels) . Thus, a single span carries 32 physical timeslots addressed by a physical circuit, each physical timeslot supporting four air traffic channels resulting in 128 air traffic channels that can be addressed via a logical circuit. When nailing up a connection for an air span, however, logical circuits cannot be used because a single DSP supports one physical circuit and four logical

SUBSTTTUTE SHEET (RULE 26) circuits. Thus, the nailed-up connection for four air channels uses the same DSP and thus the nailed-up connection for the four air traffic channels must use the physical timeslot of the DSP. Thus, according to an embodiment of the present invention, an air span LCI can contain a force physical bit that when set causes the appropriate physical circuit to be used for the nailed-up connection, the force physical bit then being not set so that the logical circuits are used for call processing. Therefore, when specifying a trunk connection to the platform 27, LCIs for trunks may, for example, be constructed as follows:

Shel Slot Board Span Type Span Logical

15 f Type circuit

4 8 4 bits 4 bits 4 8 bits bits bits bits

0x0 0x5 0x4 0x0 0x0 0x07

The above example is for a land circuit (also known as a

PSTN trunk) having an LCI of 0x00540007. The first five fields are preferably fixed for all the field in a particular span. The last field, "logical circuit," maps differently based on the interface and circuit type. In this example, the interface is an El standard land span, indicated by "0x0" in the span type field, and is assigned to timeslot 7 on the span (because of the "0x7" in the logical circuit field) . An air span would have been a different span type and the logical circuit field would contain a number between 0 and 127 (decimal) . For any DSO that has been allocated for a LAP-D channel, a group of four logical circuit numbers will be allocated, but only the first will be used to access the LAP-D signaling channel.

When addressing spans 40, the LCI is constructed using all of the fields, except for the logical circuit field. The logical circuit field is preferably set in this circumstance to OxFF. Spans 40 are preferably addressable via the interface modules 20. Both the Span LCIs and the Channel LCIs

SUBSTTTUTE SHEET (RULE 26) (e.g., the last field of an LCI) refer to an interface module 20. Accordingly, the range of permissible values for "Slot" would be the same for either a Span LCI or a Channel LCI^specifically, the permissible range would be those slots where an interface module 20 could be placed on the shelf. Further the Board Type would be the same for either, specifically "4" in this exemplary embodiment, referring to an interface module 20. The Span Type and Span for Channel LCIs and Span LCIs would also have the same range of values, as when identifying a particular Channel LCI, one must first identify the span 40 on which that channel is being carried. The Channel LCI contains the additional, final field that identifies the time slot 46 of the information channel within a particular span 40. For land-based spans having 64 kbps PCM information channels, there will be 32 timeslots (or Channel LCIs) per Span LCI. Since GSM-based voice channels are encoded at 16 kbps, when the span 40 carries nothing but GSM- encoded voice channels there will be 128 timeslots or Channel LCIs per Span LCI (4 channels within each 64 kbps timeslot) .

DSP LCIs are used when accessing signal processing module 22 or telephone support module 18 resources. DSP LCIs can be used to identify individual DSPs. The LCI below illustrates a DSP LCI.

Shel Slot Board unused DSP Channel f Type

4 8 4 bits 4 bits 4 bits 8 bits bits bits

30 0x0 0x0 0x2 or OxF 0x0 OxFF

0x3

(PSM or

SPM)

For a DSP LCI on a signal -processing module 22, the DSP field ranges from 0-8 (i.e., there are up to eight DSPs on a preferred embodiment signal-processing module 22) and individual DSPs are addressed 1-8 with 0 indicating a broadcast message. For a DSP LCI on a telephony-support

SUBSTTTUTE SHEET (RULE 26) module 18, the DSP field ranges from 0-6 (i.e., there are six DSPs on a preferred-embodiment telephony-support module 18) , and individual DSPs are addressed 1-6 with 0 indicating a broadcast message. While a DSP LCI for a signal -processing module 22 identifies an individual DSP, the Channel field identifies one of the decoded DSP connections 49 or one of the four decoded DSP connections 49. For a telephony-support module 18, the channel field represents the resource provided by the module 18, for example a tone generated by the module 18.

According to an exemplary embodiment of the present invention, when forming connections, the application layer, which is comprised of the call processor 12, for example via a resource manager within the call processor 12, provides the LCIs for the two endpoint information channels that the call processor 12 wishes to connect. The IOSS platform 27 forms all intermediate connections through the switch 43, including any connections that may be required through the signal processing modules 22 in a manner that is transparent to the call processor 12 and the resource manager.

This method and system for providing logical identifiers for components and communications channels provides a way to identify, preferably throughout the entire platform, all elements and channels to be connected and to make connections between those elements. A standard format is provided that builds up a LCI in a building block manner that can also be used as indices to a database of configuration information to allow dynamic updating of the database and remapping of connections without involving the call processor. In addition, the LCIs according to an embodiment of the present invention can be built as needed by various components thereby reducing the burden on the call processor to track an entire set of connections and allowing alternate connection paths to be established without invoking call processor logic. This provides significant flexibility over prior-art systems in

SUBSTTTUTE SHEET (RULE 26) which incoming lines, outgoing lines, and platform resources are identified in a single list or database that is generally accessed by a single process that is responsible for managing the formation of these connections.

The CNFG task 50 provides a function to translate LCIs into the high-speed bus 25 and timeslot 46 information. This function preferably translates one or two LCI values with one operation. In an embodiment of the present invention, there are, for example, three parameters to this function: count; lci_xlate_ptr; and phys_xlate_ptr . The count parameter will specify the number of LCI values to translate. The preferred range is 1 or 2. The lci_xlate_ptr points to a 32 -bit array maintained by the function requesting the translation containing the LCI values to translate. The phys_xlate_ptr points to an array of structures that will contain the translated line and slot data for each of the input LCI values, which is also established by the function requesting the translation. This function returns a zero value, unless an error is encountered. LCIs that identify individual communications paths (timeslots on spans) will be translated to physical circuits within the IOSS Platform 27. Additionally, the CNFG task 50 (see FIGURE 6) maintains the look-up tables needed to translate LCIs (see FIGURES 12A-12B) .

Also, CNFG task 50 provides interfaces to report alarms and software errors. Alarms caused by the switching module 16 are considered local alarms, while alarms generated by resource processors 18,20,22 are considered remote alarms. In any case, both types of alarms are passed to the CNFG task 50 for processing. Operationally, this task 50 maintains and controls physical platform configuration information, hardware fail-overs, and process "hot-removal" and "hot-insertion" of resource processor or other boards. The CNFG task 50 also manages the state of the switching module 16 and monitors the status of the resource processors 18,20,22 within the switching platform 10. CNFG 50 maintains a table of state

SUBSTTTUTE SHEET (RULE 26) information for each resource processor 18,20,22 and for the redundant switching modules 16.

As shown in FIGURE 6, the CNFG task 50 interfaces with the resource manager software modules running on the call processors 12 and many of the other tasks executing within the IOSS platform 27. These interfaces may be implemented, for example, by the use of message queues. CNFG 50 interfaces with each task's command mailbox. The CNFG 50 task accepts commands through its message queue, Cnfg_Qid 54. In an embodiment of the present invention, the messages arriving in the queue 54 via MSGI task 56 originated in the Resource Manager.

After processing startup initialization functions, this CNFG task 50 is driven by, for example, an event flag. The event flag indicates that a message has been placed in CNFG ' s message queue, Cnfg_Qid 54. Preferably, all configuration- related messages pass through CNFG 50. The CNFG task 50 may be commanded by the Resource Manager to issue state-change commands (e.g., ONLINE, OFFLINE) to boards residing within the IOSS platform 27. Also, board additions and removals are preferably detected and reported to this task. Finally, in addition to maintaining platform configuration, this task effects redundant fail-overs when necessary.

All objects required by the CNFG task 50 are preferably available at startup. The CNFG task 50 starts by initializing itself and resetting all configuration tables. During startup, the task reads a system information and status register on the switching module 16. The results of this read are then made available to the other tasks within the IOSS platform 27. This information is also preferably made available in a global data structure. Information that may be included in this global data structure include, for example, the following fields:

SUBSTTTUTE SHEET(RULE 26) write_protect : Indicates whether the bootstrap portion of the IOSS platform 27 is write protected shelf address: Indicates on which shelf of a telecommunications rack the IOSS platform resides slot_id: Indicates in which slot of a telecommunications rack shelf a module has been placed hardware info: may be used to provide model and revision information for the rack backplane and/or module PCB

On startup, code within the switching module verifies the above fields, and generates an error if information contained in these fields is incorrect or not within the range of possible values. To enable the switching module 16 to initialize itself, it preferably contains a boot-only version of its operation code which is stored in, for example, a write-protected portion of the switching-module's nonvolatile memory 160 (not shown, see FIGURE 8) . This boot-only code would contain, for example, a minimal system to allow loading of run-time code into the switching module 16. It would be burned into the boot-block of the nonvolatile memory 160, preferably during the manufacturing process. The boot-only code comprises the following IOSS tasks:

20 ROOT Root task

MSGI 56 Message router in

MSGO 62 Message router out

LDER 86 Code loader

CNFG 50 Configuration

The tasks mentioned are preferably logically identical to their operational counterparts; the only difference being their data tables. The boot-only executable version contains minimal functionality, while the operational version contains full system functionality. The Boot-only version of Root starts MSGI 56, MSGO 62, CNFG 50, and LDER 86 and then also allows at least some communications to the Resource Manager.

The operational version of the code contains the functionality included in the boot-only version plus, for

SUBSTTTUTE SHEET (RULE 26) example, switching functionality and built -in test and fault isolation test (BIT/FIT) capability. Additional IOSS software includes the following tasks:

5 BIT 82 Built In Test

CNFG 50 Configuration

LCOM 74 Local Communications

RLPD 66 Remote LAP-D

SWTH 70 Switch

10 TSIG 78 Trunk Signaling/PCM Message support

SYNC 90 Redundancy control

The run-time version of the root task first creates the objects required by the run-time tasks using table driven functions. Root provides global object ID'S that each task may use to access the objects. Then, Root will create and start all of the tasks described below. Upon completion, Root will suspend itself.

The Message Router In 56/Message Router Out 62 (MSGI/MSGO) tasks is one point of communication between the IOSS platform 27 and the Resource Manager, and is preferably implemented through a pNA socket interface. MSGI 56 reads from a socket and routes the messages to the proper destination within the IOSS platform 27. Messages may be delivered locally to other tasks executing on the switching module 16, over a remote LAP-D link to the BTS 44, or over the LCOM link 24 to various resource processors 18,20,22. MSGI 56 blocks on socket reads if data is not available. MSGO 62 preferably uses one input message queue, blocks on a read from the queue, and delivers the messages to the proper destination.

The Loader (LDER) task 86 performs downloads to nonvolatile memory 160 and is the file handler for downloads to the resource processors 18,20,22. Download messages are received from Resource Manager (RM) via the MSGI task 56. The download messages may indicate boot block loads, executable loads, or loads to Field Programmable Gate Arrays (FPGAs) in

SUBSTTTUTE SHEET(RULE 26) the resource processors 18,20,22 or switching module 16. For each of the three downloadable entities managed by LDER 56, there is a known file name that LDER 56 will use. These files preferably reside on a disk that is capable of being NFS- mounted and accessed directly by LDER 56. The results of the download will be sent up to the Resource Manager through MSGO 62.

The Configuration task (CNFG) 50 is preferably responsible for all board-configuration-related aspects within the IOSS platform 27. In one embodiment, this task 50 generates a configuration table, specifically including at least logical identifier or LCI translation tables for use by SWTH 70. CNFG 50 "nails-up" connections 47 (see FIGURE 4) within the IOSS platform 27 on command from the Resource Manager. Once this has been performed, CNFG 50 monitors resource processor 18,20,22 statuses and informs the Resource Manager when the IOSS platform 27 is ready to begin operation. Operationally, this task maintains platform configuration information, manages hardware failovers, and processes "hot- removal" and "hot-insertion" of boards. Also, CNFG 50 is preferably responsible for requesting table downloads within the switching module 16.

To maintain the platform configuration information, CNFG task 50 handles resource processor 18,20,22 board insertions and extractions. The removal of any resource processor 18,20,22 is preferably detected at run-time by LCOM 74 and reported to CNFG 50. The Resource Manager detects the removal of a switching module 16 at run-time. CNFG 50 reports the board removal (except for switching module 16 removal) to the Resource Manager and adjusts the database 52 to reflect the new hardware status. Additionally, CNFG 50 generates disconnect commands for SWTH 70 if the board removed was currently in use.

SUBSTTTUTE SHEET (RULE 26) If a switching module 16 is hot-inserted into the IOSS platform, it will automatically become the off-line switching module 16. The SYNC task 90 ensures that the newly-inserted switching module 16 is synchronized as quickly as possible with the existing switching module 16 in case a failover is necessary. If a switching module 16 or telephony-support module 18 is hot-inserted into a system, it automatically becomes an off-line slave.

Any signal processing modules 22 added to the IOSS platform 27 at run-time are also detected by LCOM 74 and reported to CNFG 50. CNFG 50 reports the board addition to the Resource Manager and adjusts the configuration database 52 to reflect the new hardware status. SWTH 70 does not need to be told about signal -processing module 22 additions. Adding a signal-processing module 22 will increase the pool of DSPs 240 (see FIGURE 11) available to the IOSS platform 27.

With continued reference to FIGURE 6, any interface modules 20 added to the IOSS platform 27 at run-time are detected by LCOM 74 and reported to CNFG 50. In this embodiment, CNFG 50 reports the board addition to the Resource Manager and then adjusts the database 52 to reflect the addition. CNFG 50 preferably will not by itself place the new spans 40 into service. If spans 40 are connected, TSIG 78 receives a message indicating that the span 40 is active. The Resource Manager then requests that the specified span 40 be brought into service.

The Local Communications (LCOM) task 74 establishes and maintains a point-to-multipoint connection and connectivity to the resource processors 18,20,22 within the IOSS platform. In one embodiment, each resource processor 18,20,22 within the IOSS platform uses its slot id as its identifier. LCOM 74 identifies resource processors 18,20,22 that are currently active in the IOSS platform 27 and periodically polls unused slots to determine if a board has entered the system. LCOM 74

SUBSTTTUTE SHEET (RULE 26) recognizes and reports when resource processors 18,20,22 are no longer communicating or when one of the links has failed.

Still referring to FIGURE 6, the Remote LAP-D (RLPD) task 66 provides communications to the BTS 44. RLPD is accessed via special messages from Resource Manager to establish connections, pass messages to the BTS 44 and release connections .

The Switch (SWTH) 70 task services the Resource Manager. SWTH 70 receives messages from the Resource Manager, via MSGI 56. Based on the received message, SWTH 70 makes the necessary connections through the switch 43. The results of commanded actions will be sent to the Resource Manager through MSGO 62. Another function of SWTH 70 is to service BIT 82 requests to establish connections to perform testing. SWTH 70 maintains a table indicating current timeslot connections and status (operational, BIT, unused, etc.) .

Preferably, all of the connections in the interface modules 20, signal-processing modules 22, and telephony- support modules 18 will be "nailed-up" connections 47, so that real-time switching occurs primarily in the switching module 16. The resource processors 18,20,22 can be initialized to their "nailed-up" connections 47, but will also respond to run-time commands requesting connections or disconnections.

FIGURE 7 is a flow diagram of the steps taken by the CNFG task 50 upon startup of the IOSS platform 27. In this embodiment, there are redundant switching modules 16. At step

100, the states of these switching modules 16 are unknown. Since the switch modules 16 have nonvolatile memory, which is used to store the switch module executable code, upon start-up it is not known whether the switching modules 16 have executable code stored in their memory or not. The CNFG task 50 running on each of the redundant a switch modules 16

SUBSTTTUTE SHEET (RULE 26) perform an initialization which includes executing a power-up self-test suite. Upon successful completion of self-test, the switching module 16 firmware determines if run-time executable code is present in nonvolatile memory 160 (see FIGURE 8) . If a run-time version is present, it is preferably copied from nonvolatile memory 160 to memory (preferably DRAM or SRAM) 158 and control is passed to the memory 158 (preferably RAM) version. The loaded run-time software preferably starts the operating system and the IOSS tasks. Each switching module 16 will assert its bus_ready line and try to become the master. Once the executable is running from memory 158, the nonvolatile memory 160 can be reprogrammed.

After initialization of the switching module 16, the CNFG task 50 builds up empty configuration tables in step 112 based on its read of the system information and status register (e.g., stored in a hardware register of the switching 16) , and described further with regard to FIGURES 12A and 12B. If the CNFG task 50 executes successfully, it sends a "Ready" message to the Resource Manager indicating that the switching module 16 has had a successful power-up 102. At that point, the switching module 16 is in a state called a "Reset" 104. Next, the CNFG task 50 determines whether there is valid executable code in the nonvolatile memory 160 of the switching module 16 (step 106) . If the CNFG task 50 determines that there is no valid executable code in the nonvolatile memory, it calls to the LDER 86 (see FIGURE 6) . At step 108, then, LDER 86 loads executable code into memory 158 from an external data base, for example, or from a transmission from a higher- level application within the telecommunications switching platform 10.

If the power-up self-test suite fails for any reason, the failure may be reported by at least two methods. First, a message can be written to an RS-232 maintenance port on the switching module (which may or may not have a terminal connected) , then an error code may be flashed on the switching

SUBSTTTUTE SHEET(RULE 26) module 16 front panel. Dependent upon what point in the power-up test sequence a failure is detected, the operating system may or may not be started. If the operating system is active, then an error message will also be sent to Resource Manager. Also, at this point, the switching module 16 will not have asserted the bus_ready line and will therefore not attempt to become a master. If a run-time executable is not present in nonvolatile memory 160, the boot version will be copied from nonvolatile memory 160 to memory 158 and restarted. Now that the operating system is running, the Root task will be started and will eventually request a download from Resource Manager. A switching module 16 that does not contain a run-time executable will not assert the bus_ready signal, and will not attempt to become a master. It will instead preferably flash a fatal error code.

Still referring to FIGURE 7, once the executable code has successfully been loaded into each of the redundant switching modules 16, the platform determines which of the switching modules 16 will be ONLINE and which of the switching modules

16 will be OFFLINE. This is resolved in step 110, where each of the switching modules 16 attempts to seize control as master of the control bus 24. Once bus ownership has been resolved at step 110, the CNFG task 50 builds the configuration table 52 at step 112. The configuration table 52 is initially constructed in step 112 as an empty table whose size and fields are determined by what the CNFG task 50 has read from the information and status register of the switching module 16. Once the empty configuration table 52 has been constructed in step 112, at step 114 each switching module 16 sends a "Ready" message to the Resource Manager. Each switching module 16 at this time also reports its state, i.e., one of the switching modules 16 is ONLINE while the other switching module 16 is OFFLINE. The switching module 16 that is ONLINE then begins at step 116 to receive configuration information from each resource processor 18,20,22 that is in communication with the switching module 16. Also at step 116, the switching module 16 continues after

SUBSTTTUTE SHEET (RULE 26) updating the configuration table 52 and provides the Resource Manager with this configuration information so that the Resource Manager can keep its system configuration database current. FIGURES 12A and 12B further illustrate the building of database 52.

The CNFG task 50 continues at step 118 in which the switching modules 16 receive a SET_CLOCK message from the Resource Manager. Both the ONLINE and the OFFLINE switching module 16 receive the SET_CLOCK message, so both of the switching modules 16 can be synchronized with the Resource Manager. For those resource processors 18,20,22 that are in the reset state, executable code is preferably loaded therein. In step 120, the Resource Manager issues LOAD messages for each resource processor 18,20,22 that is in the RESET state.

The LDER task 86 (see FIGURE 6) within the switching module 16 is responsible for processing these downloads to the resource processors 18,20,22.

With further reference to FIGURE 7, the call processors 12 along with the switching modules 16 begin the task of assigning resources to traffic channels 48, 49, and control and signaling (e.g., LAPD protocol in this embodiment) channels 48. This occurs at step 122, where the Resource Manager generates and sends ADD_TCH and ADD_LAPD messages to the CNFG task 50. At step 122, for each "add" message, the CNFG task 50 will establish "nailed-up" connections 47 through the necessary interface modules 20 and signal-processing modules 22 and will send appropriate connection commands to the SWTH task 70. Still at step 122, for all ADD_TCH messages, CNFG 50 will attempt to locate and assign (by issuing the nailed-up connection request to the SWTH task 70, see FIGURE 6) signal-processing module 22 resources. For all ADD_LAPD messages, CNFG 50 will locate and assign (by issuing a nailed-up connection request to the SWTH task 70, see FIGURE 6) LAPD controller resources within the switching module 16.

SUBSTTTUTE SHEET (RULE 26) Once these steps have been completed, the CNFG task is at step 124, and the IOSS platform 27 is ready to place calls.

Referring now to FIGURE 9A, the LCOM application software for the resource processors 18,20,22 consists of two message functions, which handle all LCOM heartbeat messages: Primary Heartbeat Messaging and Secondary Heartbeat Messaging.

Primary Heartbeat Messaging. Primary heartbeat messaging is the ONLINE switching module's 16 mechanism for detecting and responding to hot insertions, hot removals, and primary LCOM bus 24 failures. "Hot" insertions and removals refer to insertions and removals that are performed when the switching platform 10 is powered-on and operating. A Heartbeat Table is provided on the switching module to monitor the status of the various resources in the telecommunications switching platform. The Heartbeat Table is kept at a lower applications level in the system than is the Configuration Table, and these tables are preferably separate. Other embodiments are, however, possible in the present invention; specifically, the status information could be maintained in real-time in the configuration table, and the below-mentioned updates to the Heartbeat Table could be made instead to the Configuration Table.

Periodically, at step A172, the switching module 16 broadcasts a heartbeat message on both control buses 24. Each resource processor 18,20,22 responds at step A174 to the broadcast message received on its primary bus 24. For each resource processor 18,20,22 that responds, the Heartbeat Table is checked at step A176 to determine if the resource processor 18,20,22 was previously registered therein. This is done for each responding RP, as can be seen by decision block A180. If a newly inserted resource processor 18,20,22 responds to the broadcast message, the switching module 16 registers this slot as a hot insertion at step A178. If an existing resource processor 18,20,22 fails to respond, at step A182, in the next

SUBSTTTUTE SHEET (RULE 26) heartbeat cycle the switching module 16 board tries transmitting a Heartbeat Message over the secondary bus 24. If the resource processor still fails to respond over the secondary bus 24, according to the test at step A186, then the switching module 16 registers either a hot removal or a board failure for that resource processor 18,20,22 at step A188. The switching module 16 makes this registration by removing the resource processor 18,20,22 from the Heartbeat Table and updating the Cnfg-Platform Cnfg table 52 (see FIGURE 6) .

Still referring to FIGURE 9A, more detailed embodiments will be discussed below. In one embodiment, at step AA172, the LCMH task clears the response number and response bus fields of the Heartbeat Table and broadcasts the heartbeat message on both buses 24 in an alternating fashion. In other words, the LCMH will transmit a heartbeat message first over one of the buses (Bus A) and then will transmit a heartbeat message on the other bus (Bus B) . Bus A may be a primary bus for some resource processors 18,20,22 and may be a secondary bus for the others . Bus B may be a primary bus for those buses for which Bus A was the secondary bus and may be a secondary bus for the others . The LCMH task sends the broadcast heartbeat message, which is preferably of the following format:

BROADCAST_ADDR_A is used for broadcasting to those resource processors 18,20,22 that have Bus A as their primary bus 24. BROADCAST_ADDR_B is used for broadcasting to those resource processors 18,20,22 that have bus B as their primary bus 24. The Bus__Id corresponds to the primary bus 24 of the resource processor 18,20,22.

SUBSTTTUTE SHEET(RULE 26) Each resource processor 18,20,22 is preferably configured to receive a broadcast heartbeat message on its primary bus 24, so each resource processor 18,20,22 receives and responds at step A174 to only one of the broadcasted heartbeats. Upon reception, a message distributor within the resource processor 18,20,22 sends it to the PidCmnLcomHeartbeat message function. This message function performs actions depending on the resource processor 18,20,22 state and then responds at step A174 to the switching module 16 by sending a heartbeat response message on its primary bus 24. An exemplary format for the heartbeat response message is defined below:

The LCMH_ID is the process_id of the LCMH_ID task. The Bus_Id represents the primary bus 24 of the resource processor 18,20,22.

When the switching module 16 receives a heartbeat response message from a resource processor 18,20,22, it is distributed to the LCMH task, which at step A178 updates the Heartbeat Table for that particular resource processor

18,20,22. The Heartbeat Table is updated to indicate the new valid response count and the new bus 24 on which the response was received.

After one second has elapsed since the broadcast, the LCMH task updates the Heartbeat Table state fields based on the responses collected in the response number and response bus fields of the Heartbeat Table. The LCMH task then

SUBSTTTUTE SHEET (RULE 26) performs actions based on the state of each resource processor 18,20,22 in the Heartbeat Table.

The following sections describe how the heartbeat mechanism detects hot insertions, hot removals, and primary LCOM bus 24 failures.

Hot Insertions. The following method for detecting hot insertions accounts for the switching module 16 or the resource processor 18,20,22 powering up first, and allows for new resource processors 18,20,22 to attempt connection on both buses 24 in case the board has only one good bus 24. Also, this method eliminates the need for CNFG task to ping all slots at startup.

When a resource processor 18,20,22 has finished booting and initializing, it goes into registration mode. In an attempt to balance the message load, the board initially sets its broadcast address and primary bus 24 based on its slot number. In one embodiment, if a resource processor 18,20,22 is located on a telecommunications rack slot having an odd slot number, its initial primary bus 24 will be Bus B. If it is in a slot having an even slot number, its initial primary bus 24 will be Bus A. This helps in load sharing and reducing the number of collisions on the control buses 24.

Although the buses 24 are preferably wired-OR buses, upon which collisions are possible, the buses 24 may be other types of buses or the resource processors 18,20,22 might be connected to each other using local area network connections. In any case, even if collisions cannot happen on the buses 24, the load-sharing by division of resource processors 18,20,22 between two communications media is still advantageous in balancing the traffic load therebetween.

SUBSTTTUTE SHEET (RULE 26) The switching module 16 receives the heartbeat response, and after one second has elapsed since sending the heartbeat message, updates the Heartbeat Table to indicate that the new board is ON-LINE. And then sends a PID_CHANGE_BROADCAST_ADDR message to the resource processor 18,20,22 (note this message is mainly used to swap broadcast addresses) . The PID_CHANGE_BROADCAST_ADDR message has the following format:

When the resource processor 18,20,22 receives the PID_CHANGE_BROADCAST_ADDR message, it leaves registration mode, and goes into normal operation mode. The resource processor 18,20,22 is then able to transmit all messages.

If the resource processor 18,20,22 does not receive a heartbeat message from the switching module 16, the transmission bus 24 and broadcast address are changed to the other bus 24. If there is no heartbeat message within a second time period, the transmission bus 24 and broadcast address are changed back to the original bus 24, and so on. This bus switching allows the resource processor 18,20,22 to attempt connection on both buses 24 in case one is bad.

Bus and Board Failure Detection. The following bus failure detection method detects individual resource processor 18,20,22 primary bus 24 failure within one time period and individual resource processor 18,20,22 failure within two time periods. A time period is preferably one second, but of course, these time periods can be shortened to any desired time period by increasing the rate of the heartbeat messages from the switching module 16. In one embodiment, the LCOM protocol only assumes board failure, but cannot determine

SUBSTTTUTE SHEET (RULE 26) between resource processor board 18,20,22 failure and hot removal .

Thus, when a resource processor 18,20,22 stops responding on both buses according to the test at step A186, LCOM sends CNFG a BOARD_NOT_RESP message at step A188. CNFG must determine if a board has failed or has been removed based on the ONLINE or OFFLINE state of the resource processor 18,20,22.

If the switching module 16 receives responses from all existing resource processors 18,20,22 within a first period, it proceeds assuming that all is well at step A190. But if the switching module 16 does not receive a response from an already-existing resource processor 18,20,22, the switching module 16 assumes that, at the least, that the unresponsive resource processor 18,20,22 has a bad transmit or receive bus driver of its primary bus 24. The Heartbeat Table is updated accordingly at step A184. If the secondary bus 24 is also known bad, a BOARD_NOT_RESP is sent to CNFG at step A188 since no communication with the resource processor 18,20,22 is possible. If the secondary bus 24 is known to be good, the process proceeds to step A189. At step A189, a minor alarm message is sent to the CNFG task on the switching module 16. Also at step A189, a set broadcast address message is sent from the switching module 16 to the unresponsive resource processor 18,20,22 on the secondary bus 24 so that resource processor is communicated with over its secondary bus 24.

If the resource processor 18,20,22 receives the set broadcast address command, the Change Broadcast Address message function will set the broadcast address according to the Bus_Id field of the message. This also swaps the primary and secondary bus 24 (and queue) so that the new primary bus 24 is the old secondary bus 24, and the new secondary bus 24 is the old primary bus 24. This will allow the resource

SUBSTTTUTE SHEET (RULE 26) processor 18,20,22 to receive and respond to heartbeats on the known good bus 24.

In cases when the resource processor 18,20,22 is not able to respond to heartbeat messages within the prescribed heartbeat period, preferably one second, the

LcomStopResponding function is called. This puts the resource processor 18,20,22 back in registration mode, and sends an LCOM stop responding message to the switching module 16. This tells the switching module 16 to ignore any unresponsiveness of a board. In other words, if the switching module 16 does not get a heartbeat response from the resource processor 18,20,22, no alarms are sent to the CNFG task. The LCOM stop responding message has the following format :

Once the unresponsive state has been reached, the switching module 16 behaves as if the resource processor 18,20,22 is not present. Then, when the resource processor 18,20,22 receives and processes an LCOM heartbeat, the resource processor and the switching module 16 behave as if the resource processor 18,20,22 was a hot insertion.

Secondary Heartbeat Messaging. Referring now to FIGURE

10A, secondary heartbeat messaging is the ONLINE switching module 16 mechanism for detecting a bad secondary bus 24 on a resource processor 18,20,22. This mechanism is important so CNFG can be warned that the secondary bus 24 is bad, so no attempt is made to use this as a primary bus 24. Instead, an operator can then force the suspect board into OFFLINE mode and replace it with another without losing any messages. The

SUBSTTTUTE SHEET (RULE 26) secondary bus 24 failure method detects bus failure of secondary buses 24, preferably within twenty heartbeat periods in an embodiment where twenty resource processors 18,20,22 exist on the IOSS platform 27.

During each heartbeat period, the switching module 16 sends a secondary heartbeat message at step A202. This heartbeat message is in addition to the primary heartbeat message, but it is only addressed for one registered resource processor 18,20,22. In one embodiment, the secondary heartbeat message is always sent on the secondary bus 24. Preferably, the secondary heartbeat message has the same format as the primary heartbeat message, which was described above.

At step A204, the resource processor 18,20,22 responds to the secondary heartbeat message the same way it responds to a primary heartbeat message, but it responds on the secondary bus 24. In this embodiment, this is the only message that is sent on the secondary bus 24 from a resource processor 18,20,22. The format of the secondary heartbeat response message is preferably the same as the format of the primary heartbeat response described above.

The switching module 16 preferably responds to the secondary heartbeat response message the same way it responds to a primary heartbeat response message . When the switching module 16 receives a valid heartbeat response message from a resource processor 18,20,22 according to the test step A206, it is distributed to the LCMH task, which updates the Heartbeat Table. The Heartbeat Table is updated at step A208 to indicate the new valid response count and the new bus 24 on which the response was received.

If, after the heartbeat period elapses, the switching module 16 does not receive a response from the resource processor 18,20,22, it is assumed that the unresponsive resource processor 18,20,22 has, at the least, either bad

SUBSTTTUTE SHEET (RULE 26) transmit or receive bus 24 driver on its secondary bus 24. Then, at step A210, the Heartbeat Table is updated accordingly and a minor alarm message is sent to CNFG, since communication with the resource processor 18,20,22 is still possible on the primary bus 24.

According to step A212, each period, a different registered resource processor 18,20,22 is addressed until they all have been addressed. When a secondary heartbeat message has been sent to all registered boards, the cycle starts over.

OFFLINE Heartbeat Response Reception. OFFLINE heartbeat response reception is the OFFLINE switching module 16 mechanism for detecting a bad bus 24 on the OFFLINE switching module 16. This mechanism is important so the CNFG task can be warned that a OFFLINE switching module 16 bus is bad, so it will never attempt to use it. The switching module 16 board can then be replaced by an operator without losing any messages. OFFLINE heartbeat response reception allows detection of OFFLINE switching module 16 bus error, preferably within twenty seconds . The OFFLINE Heartbeat Response Reception is also a passive mechanism. No messages are sent to resource processors 18,20,22 from the OFFLINE switching module 16. Instead, the OFFLINE switching module 16 utilizes the resource processors 18,20,22 responses to the ONLINE switching module 16 to determine bus status.

Preferably, within twenty heartbeat periods, the OFFLINE switching module 16 should receive twenty complete sets of primary heartbeat response messages and one or more sets of secondary heartbeat response messages. When the OFFLINE switching module 16 receives a heartbeat response, it is distributed to the LCMH task, which updates the Heartbeat Table.

After the preferred twenty heartbeat periods, the Heartbeat Table is checked. If the table indicates at least

SUBSTTTUTE SHEET(RULE 26) one reception of a heartbeat response on bus A and bus B, all is well. The OFFLINE heartbeat response reception begins another cycle, but if the table indicates no receptions on a particular bus 24, then that bus is assumed bad. A warning alarm is sent to the CNFG task to inform it of the bad bus 24.

Heartbeat Table Operation; ONLINE Switching Module 16

Operation. When the switching module 16 becomes ONLINE, if either bus 24 is known bad, the switching module 16 will send a set broadcast address message to all boards using the good bus 24. The set broadcast address message is defined above. This ensures that each resource processor 18,20,22 uses the only good bus as its primary bus 24.

Next all response number fields of the Heartbeat Table are initialized to LCOM_NO_CARD . As responses start coming in, the state will change to indicate the primary bus 24 of each board.

After initialization, the LCMH task periodically resets the Heartbeat Table response number fields to zero and the Heartbeat Table response bus fields to NO_BUS for each resource processor 18,20,22. When a valid heartbeat response message is received from a resource processor 18,20,22, the Heartbeat Table response number field for that board is incremented, indicating a valid reception. The Heartbeat Table bus response field is also updated according to the bus 24 on which the heartbeat response message is received.

The Heartbeat Table state field is updated according to the values of the Heartbeat Table response number and response bus fields.

The Heartbeat State Table holds the heart beat state value for each slot of the system. There are dynamic states

SUBSTTTUTE SHEET (RULE 26) which are transient states having a duration of one period and there are static states changing only upon certain events. The following lists possible static and dynamic heartbeat states and descriptions:

SUBSTTTUTE SHEET (RULE 26)

Each slot of the Heartbeat Table state field is preferably updated every heartbeat period. The following events within the heartbeat period induce a change: reception of a Primary Heartbeat Response Message; reception of a Secondary Heartbeat Response Message; no reception of Primary Heartbeat Response Message; and no reception of a Secondary Heartbeat Response Message.

The following state table shows the next state that results from an event occurring during the current state.

The following states cause the following responses, and preferably immediately advance to another state:

SUBSTTTUTE SHEET (RULE 26)

Heartbeat Table Operation; OFFLINE Switching Module 16

Operation. After a period, preferably every twenty seconds, the LCMH task resets the OFFLINE switching module 16 fields of the Heartbeat Table. The Heartbeat Table response number field is set to 0, and the Heartbeat Table response bus field is set to NO_BUS . Then, within preferably twenty periods, when a valid primary or secondary heartbeat response message has not been received from a resource processor 18,20,22 and the Bus_Id of the response does not match the previous Bus_Id, the Heartbeat Table is updated to indicate the new valid response count and the new bus 24 on which the response was received.

SUBSTTTUTE SHEET (RULE 26) Again, after a period, the OFFLINE switching module 16 slot of the Heartbeat Table is updated based on the Heartbeat Table response number and response bus fields. If a bus 24 fails, an alarm is sent to the CNFG task. If both buses 24 fail, a BOARD_NOT_RESP message is sent to the CNFG task. The following shows the state of this entry based on the responses indicated by the latter tables:

10

15

Also, for each bus 24 with no response, an alarm message is sent to the CNFG task, warning it of existing bad OFFLINE switching module buses.

CNFG interfaces. The LCOM application interfaces with the CNFG task through alarm and board_not_responding messages . When a resource processor 18,20,22 is not responding on bus A or bus B, LCOM send CNFG a BOARD_NOT_RESP message of the following format:

typedef struct

30 MSG_HEADER hdr; BOARD_NOT_RESP_BODY_T body } BOARD_NOT_RESP_T;

typedef struct

{ UINT2 slot ;

} BOARD_NOT_RES P_BODY_T ; When a bus failure occurs, CNFG is notified through an alarm message. For switching module 16 OFFLINE bus failures, LCOM uses the Report_Alarm function to send the message:

Report_Alarm(UINT2 base_alarm, UINTl report_status) ;

The following table describes each OFFLINE switching module 16 LCOM base alarm:

For resource processor 18,20,22 bus failures, LCOM uses the Report_Remote_Alarm function to send the message (lei is always INVALID_LCI) :

Report_Remote_Alarm(UINT2 base_alarm, UINTl report_status, UINTl slot, UINT4 lei) ;

The following table describes a number of exemplary LCOM base alarms:

SUBSTTTUTE SHEET(RULE 26) ALM CMN LCOM The switching module 16 failed to SECONDARY BUS _A_FA receive a secondary heartbeat response IL from an resource processor 18,20,22 on bus A.

ALM CMN LCOM The switching module 16 failed to SECONDARY BUS _B_FA receive a secondary heartbeat response IL from an resource processor 18,20,22 on bus B.

There are also some common alarms that can occur on the switching module 16 and the resource processors 18,20,22:

FIGURES 12A AND 12B illustrate an exemplary configuration table 52 used to store individual board configuration information and information used to translate Logical Identifiers or LCIs into switch 43 high-speed bus 25 and timeslot 46 information. The CNFG task 50 creates and maintains a global configuration table 260. The table 260 contains the necessary platform configuration data and will be modified by the CNFG task 50, but will be read by one or more tasks within the switching platform 10. The table 260 is preferably statically configured, assuming all slots used, with recommended board layouts but is by dynamically updated as needed. The fields, field types, and comments for table 260 are shown below. When the switching module 16 starts up, each resource processor 18,20,22 connected to the switching module 16 checks in as described previously via a registration message. CNFG task 50 then updates the database

SUBSTTTUTE SHEET (RULE 26) 52. For example, the fields in table 260 can be updated as each board checks in. In particular, field 278 is an array field that is updated for each board (e.g., there are up to twenty entries of board data, one for each board) . The contents of field 278 are shown at table 300 in Figure 12A and described below.

Field Name Field Type Comments

Pcm_bus_state UINTl Indicates which of the (262) redundant switching modules is ONLINE and owning the high-speed buses 25.

Lock ind (264) UINTl Indicates lock state of switching module 16: CNFG_CMD_LOCK or ~CNFG CMD LOCK

Shelf (266) UINTl Identifies whether the current shelf is shelf 0 or shelf 1

Slot (268) UINTl Identifies the slot in which the switching module 16 is: SDM SLOT A or SDM SLOT B

Clock_source UINT4 Identifies the current clock (270) source , e.g., INTERNAL_ CLOCK, CLOCK_l, CLOCK_2, CLOCK 3, or CLOCK 4

Clock_source_rate UINT4 Indicates the current clock (272) source rate : SPAN_TYPE_E1 or SPAN TYPE Tl

Online_psm_slot UINTl Identifies the slot of the (274) ONLINE telephony-support module 18.

Stats (276) CNFG_PLATFORM Is a structure 276 STAT TYPE containing counts of installed hardware components .

Board [ ] (278) CNFG_BOARD Is an array 278 of specific TYPE board-related data. This array is preferably sized to be one greater than the largest number of boards that may reside in the switching platform 10. The extra slot is used for cross-connects

As the resource processors 18,20,22 check in with the switching module 16, the registration information is used by CNFG task 50 to update the stats field 276, which contains, for

SUBSTTTUTE SHEET (RULE 26) example, information concerning the number and type of boards installed in the switching platform 10, along with the total number and allocated number of various system resources.

The stats field 276 contains, for example, the field names and types set forth below.

Field Name Comments Inst sdm (282) UINT4 The bit position indicates the card-rack slot and the number of bits set indicate the number of installed boards .

Inst_psm (284) UINT4 Same as above 0 Inst_qsm (286) UINT4 Same as above

Inst_spm (288) UTIN4 Same as above

Total_spans (290) UINT2 Total number of span interfaces known to the platform

Land_spans (292) UINT2 Number of spans 40 allocated to land circuits

Air spans (294) UINT2 Number of spans 40 allocated to air circuits 5 Bp_type (296) UINTl Current backplane type

Cur_bp_slots UINTl Current number of backplane

(298) slots

The land-spans field 292 and air-spans field 294 define the number of spans 40 allocated to land and air circuits. For example, there will be a defined number of radios associated with a particular switching platform 10 and thus there exists a defined number of air traffic channels to be assigned by the call processor 12. As the equipment associated with the switching platform 10 is known to the application processor 12, the application processor, at the time of system initialization, can determine the allocation of spans 40 between land and air.

The board field 278 of the configuration database 260 is, for example, an array field and contains board-related information and is dimensioned to have an array size of one more than the largest number of boards ("n") that may reside in the switching platform 10. Backplane slots are numbered 1 to n. The resource processors 18,20,22 report their slot numbers to CNFG

SUBSTTTUTE SHEET(RULE 26) 50 when the resource processors check in with the switching module 16. Array 278 thus contains information concerning each resource processor 18,20,22 currently registered with the switching module 16. The registration information provided to switching module 16 in combination with the configuration information known by the call processor 12 and provided to the switching module 16 allows the CNFG task 50 to update tables 260,280,300, including building board LCIs to be stored in field 302 (e.g., the upper 16 bits of the LCI - shelf, slot, board type) .

Array 278 will also be used to translate LCI values to switch 43 high-speed bus 25 and timeslot 46 information, also described with respect to FIGURES 13A AND 13B. Board types for every slot will start in table 300 as NO_BOARD in field 304, and are updated as boards register. Board states will start as

UNKNOWN and are updated as boards register. The config_ptr field

324 is then cast to an appropriate board type, based on the type field. For example, a signal processing module 22 board would cause field 324 to be set to the signal processing board type and would provide a pointer to, for example, table 346 shown in Figure 12B. As long as the type field is NO_BOARD, no attempt is made to access this pointer. During CNFG's 50 initialization, the config__ptr field 324 of each array element will be set to the address of a statically-allocated structure of the recommended board type for each slot, based on backplane type. Once set, this field 324 will preferably not change unless a system reset is performed.

Field Name Field Type Comments LCI (302) UINT4 Board LCI value ,

Type (304) UINTl Board type: NO_BOARD, BOARD_SDM, BOARD_SPM, BOARD_PSM, BOARD QPM El, BOARD QPM Tl

State (306) UINTl Board state: UNKNOWN_ST, RESET_ST, OFFLINE_ST, ONLINE_ST, ERROR_ST, IN TEST ST, LOADING ST

Prev_state UINTl see state field above (308)

SUBSTTTUTE SHEET (RULE 26) Code_version[ ] CHAR1 An array of CODE_VERSION _LENGTH (310) bytes used to contain the code version for a specific board.

Boot_version[ ] CHAR1 An array of CODE_VERSION_ LENGTH (312) bytes used to contain the boot version for a specific board.

Fpga_version [ ] CHAR1 An array of VERSION_LENGTH bytes (314) used to contain the FPGA version of a specific board.

Dsp_version[ 3 CHAR1 An array of CODE_VERSION_ LENGTH (316) bytes used to contain the FPGA version for a specific signal - processing module 22 or telephony- support module 18.

Vm_time[ ] CHAR1 An array of CODE_VERSION_ LENGTH (318) bytes used to contain the voice message version for a specific telephony-support module 18.

Tone_version[ ] CHAR1 An array of CODE_VERSION_ LENGTH (320) bytes used to contain the tone version for a specific telephony- support module 18.

Rev_number UINT2 Hardware revision of board. (322)

*config_ptr VOID Cast to appropriate type, based on (324) specified type field. No attempt to cast is made if type = NO_BOARD . Valid casts:

SDM_BD - CNFG_SDM_BOARD_TYPE SPM_BD - CNFG_SPM_BOARD_TYPE PSM_BD - CNFG_PSM_BOARD_TYPE QSM_E1_BD - CNFG_QSM_E1_B0ARD_TYPE QSM Tl BD -CNFG QSME Tl BOARD TYPE

At this point, the registered hardware in the switching platform is ready to begin operation and the resource manager can send messages to the switching module 16 is to add traffic channels or LAP-D channels. For each message to add a LAP_D channel, the CNFG task 50 will process the add message by locating and assigning a LAP-D control resource via issuing a nailed-up connection request to the SWTH task of the CNFG task 50. Table 330 is accessed as shown below and in Figure 12B, and table 330 contains field 332, which is an array of telecommunications control channels used to communicate with a BTS 44. Field 332 is accessed via the config_ptr 324 field of the configuration database 260.

SUBSTTTUTE SHEET (RULE 26) Field Name Field Type Comments BTS_Control [ CNFG_BTS_CO An array of (NUM_BTS_CONTROL_ (332) NTROL TYPE CHAN) elements containing

BTS__control channel assignment data .

BTS_Control channels (sometimes specifically referred to as MUNICH channels because of the SIEMENS-proprietary Munich integrated circuits used in an embodiment of the present invention) are used to communicate with the BTS 44. This communication path is provided, for example, through an Abis interface and implemented with a LAP-D protocol . Each BTS_CONTROL channel may be associated with one timeslot 46 of a high-speed bus 25. The contents of field array 332 is shown below and as table 380 in Figure 12B.

Field Name Field Type Comments

LCI UINT4 LCI of the interface module 20

(382) trunk connected to this BTS CONTROL channel.

Sapi UINT2 Initial SAPI used by the LAP-D

(384) task to establish the control link.

Tei UINT2 Initial TEI used by the LAP-D

(386) task to establish the control link.

Timeslot UINT2 Physical timeslot 46 associated

(388) with the LCI

Con PHYS_CKT_T MTSL line & slot information for

(390) the PCM timeslots associated with this BTS CONTROL channel .

If a signal processing module 22 checks in with the switching module 16 and, for example, a traffic channel is added, then the CNFG task 50 updates table 340 shown below and in Figure 12B. Each signal-processing module 22 preferably contains 1 to 4 daughter boards 242, with each daughter board 242 containing two DSPs 240. The DSPs 240 are used to provide GSM encoding and are mapped into, for example, GSM_ABIS traffic channel circuits. Each DSP 240 is individually controllable. CNFG task 50 will statically allocate space for the maximum number of these structures needed. The table 340 is accessed through the config_ptr field 324 of the configuration database

260.

Field Name Field Type Comments Dsp_mask UINTl Mask indicating which DSPs 240

(342) are installed.

Tot_instailed UINTl Total number of DSPs 240 _dsps (344) installed on this signal- processing module 22 board.

Free_dsps UINTl Number of DSPs 240 remaining to

(346) be used. Faulted_dsps UINTl Number of faulted DSPs 240.

(348) Dsp[ ] (350) CNFG_DSP_RESO A two dimensional array 350 used URCE TYPE to access the DSPs 240 [MAX_SPM_DAUGHTER_BDS] [MAX DSP PER DAUGHTER BD]

Each DSP 242 is indexed in the table 340 via dsp[] field 350. Thus, field 350 would have eight array entries, one for each DSP 242 on the signal processing module 22, the organization and content of the array for each DSP 242 shown below as table 400 and in Figure 12B. As shown in table 400, for each DSP 242, a LCI is generated by the CNFG task 50 and stored in field 402. As each DSP utilizes five timeslots, five physical address locations on a pcm bus are stored in fields 408 and 410. For example, field 408 contains the physical circuit assigned to the DSP connection handling GSM encoded channels 49 and field 410 provides an array of the physical circuits assigned to the DSP connection handling the four resultant PCM encoded lines channels 48. Also shown in table 400 is field 406, which contains the span 40 that has been nailed-up to the DSP 242 when a traffic channel was added. Field 406 contains the LCI of the appropriate span 40.

0 Field Name Field Type

DSP_lci (402) UINT4 Provides the LCI of the particular DSP 242. State (404) UINTl DSP_ALLOCATED, DSP_INSTALLED, DSP_TEST, DSP_FAILED, DSP NOT PRESENT

QSM_trunk_lci UINT4 QSM trunk that has been ¹ NAILED- (406) UP' to this DSP 242.

GSM_ckt PHYS_CKT_TYPE High-speed bus 25 and timeslot 0 (408) information for the GSM-encoded timeslot associated with the particular DSP 242.

PCM_ckt [ ] PHYS CHT TYPE An array 410 of (410) MAX_TCH_ENCODED_PER_DSP (4 ) elements 440 containing highspeed bus 25 and timeslot information for the PCM timeslots associated with the DSP.

When a telephony support module 18 registers with the switching module 16, the CNFG task 50 maintains the pcrrALine that is associated with the module 18 as shown below in table 360 and in Figure 12B. CNFG 50 will statically allocate space for the maximum number of these structures needed. Table 360 is accessed through the config_ptr 324 field of the configuration database 260.

Field Name Field Type Comments 5

PCM_line UINTl High speed bus 25 used by this (362) board.

The resources provided by the telephony support modules 18 are further identified by LCIs according to an embodiment of the present invention. For instance, a LCI would be provided for a dial tone, which would be a resource provided by the one of the DSPs 226 (see Figure 10) . As before, this LCI identifies a timeslot 46 that exists on the high-speed bus 25 to which the telephony support module 18 is connected. In the embodiment of Figure 2, the high-speed bus 25 that is dedicated to the telephony-support modules 18 is bus 1. More than one of the traffic channels being switched by the switching platform 10 may need to be connected to a particular resource. For example, more

SUBSTTTUTE SHEET (RULE 26) than one of the traffic channels may need to hear a busy signal or ring signal at a particular time. Accordingly, the switch 43 is operable to connect the time slot carrying such signals to multiple traffic channels as instructed by the switching module controller 156.

Other resources provided by the telephony support module 18 include resources for decoding and transmitting signaling information that is used to form connections between information channels. The DSPs 226 of the telephony support module 18 will preferably provide a pool of such resources on various timeslots 46 of the high-speed bus 25 between the switch 43 and the telephony support module 18. These resources will be dynamically assigned, based on availability, to the traffic channels needing such resources . When an interface module 10 registers with the switching module 16, the field 324 will be cast to field 372, as shown in

Figure 12B, and CNFG task 50 will update field 372, which is an array of spans (e.g., Els) contained in an interface module 20

(e.g., there are four spans on each module 20) . Also, there will be a table 370 for each interface module 20. The span interface modules 20 preferably interface to El-standard spans 40. An interface module 20 preferably contains 1 to 4 spans 40, with each span 40 being individually controllable.

5

Field Name Field Type Comments span. ] (372) CNFG_SPAN_TYP This field is an array 372 of E CNFG_SPAN_TYPE, containing MAX_QSM_SPANS_BD (4) elements 420.

The CNFG task 50 can support, for example, land spans 40 and GSM air spans 40. The content of each array field 372 is shown in table 420 below and in Figure 12B. As shown in the table 420, each span 40 has a unique logical identifier or "LCI" field 422, type field 424, state field 426, physical circuit array 428, and logical circuit array (air circuits only) 428. Defined types 424 comprise, for example: SPAN_NONE, SPAN_GSM_ABIS, or SPAN_PSTN. SPAN_NONE, indicates no physical connection to a interface module 20 for a particular span input. A span's state 426 may be

SUBSTTTUTE SHEET (RULE 26) ENABLED, DISABLED, or FAULTED. The state of a single span 40 does not affect other spans on the same board 40.

Air spans 40 (e.g., GSM_ABS) use both the logical and physical circuit arrays. Air span circuits map 4 to 1 within one of the timeslots of an exemplary high-speed bus 25. Thus, the logical circuit array 428 is preferably an array containing 128 entries 440. These logical LCI entries 440 are referenced by the Resource Manager. The physical circuit array 430 preferably contains 32 entries and is used for interface module 20 to DSP 242 mapping. This array 430 is used to translate LCI values from the Resource Manager to high-speed bus 25 and timeslot 46 information. Land spans (e.g., PSTN spans) preferably map directly to physical circuits, in which case only the physical circuit array 430 is needed. These LCI entries are referenced by the Resource Manager. This array 430 is used to translate LCI values from the Resource Manager to high-speed bus 25 and timeslot 46 information.

0 Field Name Field Type Comments LCI (422) UINT4 LCI that identifies the particular span 40.

Type (424) UINTl Span types : SPAN_NONE SPAN_PSTN SPAN GSM ABIS 5

State (426) UINTl ENABLED - span 40 is present at the interface module 20 and is ready for use .

DISABLED- span 40 is present, but disabled

FAULTED - span 40 is present, but faulted

Logical_ckt [ CNFG_PHYS_CKT An array 426 of ] TYPE MAX_GSM_ENCODED_TIMESLOTS 0 (426) elements 440 representing the logical 4 to 1 mapping of air circuits. Not used for land circuits . phys_ckt [ ] CNFG_PHYS_CKT An array 428 of MAX_2M_TIMESL0T (428) TYPE elements 440 representing the physical timeslots for this span 40.

SUBSTTTUTE SHEET (RULE 26) Dsp_lci [ ] UINT4 An array 430 c>f MAX 2M TIMESLOT (430) elements 440, indicating the LCI of the DSP 442 "nailed' ' to this timeslot Preferably, this field is only used for GSM spans .

Still referring to Figure 12B, tables 440 are used as the lowest level in which the configuration database 52 and provide the PCM bus values. For example, each table 440 provides the high-speed bus 25 and timeslot a specified circuit is mapped to.

0

Field Name Field Type Comments

Line (442) UINTl High-speed bus 25 number, preferred range is 0 - 15. 5 Slot (444) UINTl Timeslot number within a particular high-speed bus 25, preferred range is 0 - 127.

Type (446) UINTl circuit type

Figure 13 is an exemplary flow chart describing how LCIs according to an embodiment of the present invention are used to configure communications within the telecommunications switching platform 10. The process begins at step 460, where, for example, the resource manager provides a LCI to the SWTH task, which in turn calls the Cnfg__Lci_Xlation process of the CNFG task 50. At step 462, the switching module 16 uses the LCI to extract the slot, span, and board_type that is associated with the LCI, for example, using the GET macro described previously.

At decision step 464, if the slot provided within the LCI exceeds the maximum number of slots in the backplane of the telecommunications switching platform, then the switching module

16 would note that this is an invalid slot and would return that result at step 466 (INVALID SLOT) . If, however, the slot number was in the permissible range for of a particular telecommunications switching platform, the switching module 16 at step 468 compares the provided board_type from the LCI to the table of board_types that are in use in that particular telecommunications switching platform. If the board_type provided in the LCI is not a board_type used in the particular

SUBSTTTUTE SHEET(RULE 26) telecommunications switching platform 10, the process at step 470 returns that result from the process (INVALID BOARD) .

Now, if the board_type was one of the permissible types of boards for that particular telecommunications switching platform, the process proceeds to follow different paths depending on which type of board was identified by the particular LCI. At step 472, if the board_type corresponds with that for a telephony support module 18 (sometimes referred to as a PCM-Support Module or "PSM"), then the process will continue at step 474. If, on the other hand, the board_type corresponds to an interface module 20, the process at step 480 will proceed to step 500, which is identified by the "A" branch (see Figure 13B) . If the board_type is neither the telephony-support module 18 or an interface module 20, the process proceeds to step 482, where the board_type is checked to see whether it corresponds with a switching module 16. If the board_type indicates a switching module 16, the process continues to step 550, which is designated by "B, " which is shown again at the top of Figure 13C. If the board_type is neither a telephony support module 18, nor an interface module 20, nor a switching module 16, then the process continues to step 484, where it is determined whether the board_type corresponds to that associated with signal processing module 22. If the board_type does corresponds to a signal processing module 22, the process continues to step 600, which is identified by "C" and is shown again at the top of Figure 13D. Since the board_type was tested for validity at step 468, the board_type should always be able to be identified by one of the decision blocks 472, 480, 482, 484, or a new decision block for a new type of board not specifically described herein. Step 486 is nonetheless provided as a default to return an INVALID BOARD message if for whatever reason the process proceeds from all the known board_type decision blocks without branching to the handler for that particular type of board type.

Returning to the manner in which LCIs are handled for each of the particular board_types, if the board_type was that of a telephony support module 18, the process continues at step 474.

At step 474, the switching module 16, using the LCI, extracts the circuit identifier, for example using a GET macro. At step 476,

SUBSTTTUTE SHEET (RULE 26) the switching module 16 looks to the configuration table 52 to find the telephony support module's assigned high speed bus 25 (sometimes referred to as a PCM-line) . At step 478, the process returns a high speed bus 25 identifier and the particular slots used by the telephony support module 18. For example, the circuit identifier extracted from the LCI would be used as an index into database 260 illustrated in Figure 12A to navigate through to the database table 360, which identifies the PCM line used by the module 18. If the board_type was that of an interface module 20, the process continues at step 500 (Figure 13B) . At step 502, the span identifier within the LCI is extracted and tested to see if it is within the range of 0-3. This is because in the embodiment of the present invention, the interface module 20 handles no more than four spans by itself. If the span identifier is outside this permissible range, the process returns an INVALID SPAN message at step 504. If, on the other hand, the span identifier is within the permissible range, the process creates a pointer to a data set that associated with the particular span, and extracts the span_type that is associated with this particular span 40 from the data structure at step 506. At decision blocks 508 and 510 it is determined from the span-type information within the configuration table 52 whether the particular span 40 is a land-based span or an air span. For example, table 420 for each interface module 20 includes span type information in field 424. Land-based spans are sometimes specifically referred to as PSTN spans and air spans are sometimes specifically referred to as GSM or PCS spans. If at step 508 it is determined that the span is a land-based span, the process sets the circuit__pointer to point to the physical circuit array in the configuration table at step 514 (see field 430 of table 420 in Figure 12B) .

If at step 508 it was determined that the span was not a land- based span, the process would continue to step 510, where the span_type would be tested to see whether the span is a GSM_ ABIS air span. In the present configuration, if the span was neither of these types, the process returns an INVALID SPAN message at step 512. If, on the other hand, it was determined at step 510 that the circuit was an air span, then at step 511 it would be

SUBSTTTUTE SHEET (RULE 26) determined if a force physical bit in the span LCI was set. If the force physical bit was set, the ckt_ptr would be set to the physical circuit in step 513 because this would indicate that the nailed-up connection for the span was not yet established and the physical circuit associated with the span should be used to establish the nailed-up connection between the span and its allocated DSP.

If the force physical bit is not set, then at step 518 the process sets a pointer to the logical circuit in the configuration table 52 for the desired traffic channel. Once the pointer has been properly set at step 513, 514 or step 518, the process continues at step 516 to extract the circuit identification from the LCI. If the circuit is within a permissible range for circuits within that particular telecommunications switching platform (step 518) , the process returns that circuit's line and slot information at step 522. If the circuit is outside the range of permissible circuits, the process returns an INVALID CIRCUIT message at step 520.

If the board_type corresponds with that for the switching module 16, the process continues at step 550 (Figure 13C) . Here, switching module 16 extracts the circuit identification from the LCIs at step 552. If the circuit identification is within the range of valid control channels, which are sometimes referred to as MUNICH32 channels, the process will access at step 556 the configuration table 52 to get to the line and slot information associated with that particular circuit. For example, the switching module 16 LCI would be used to index through database 260 to table 330 down to the line and slot fields for the circuit contained in table 440, as shown in Figure 12B. If, on the other hand, the circuit is outside the range of valid MUNICH32 channels, then at step 560 the circuit is checked to see whether it is within the range of valid conference circuits. If it is, at step 562, the slot is set to "circuit" and the line is set to 0. This line and slot information will be returned from the process at step 558. If the circuit was outside the range of valid MUNICH32 channels and valid conference circuits, in this embodiment the process returns an INVALID CIRCUIT message at step 564.

SUBSTTTUTE SHEET (RULE 26) If the board_type corresponds with that for a signal processing module 22, which is sometimes referred to as an SPM, the process continues at step 600 (see Figure 13D) . At step 602, the DSP information is extracted from the LCI. If at step 604 it is determined that the DSP is within the range of permissible DSPs for the switching platform, (e.g., numbered between 1 and 8) the process at step 608 creates a pointer to this SPM board using the DSP look-up line and slot data from the configuration table 52. This line and slot information is return from the process at step 610. If at step 604 the DSP had been outside the range of permissible DSP use, the process will return an INVALID CIRCUIT message at step 606.

According to an embodiment of the present invention, the interaction of LCIs, the CNFG task 50 and the CNFG database 52 is now described. When an air traffic channel is added (e.g., in response to an ADD_TCH message to make a nailed-up connection) , the call processor 12 provides a span LCI and a physical timeslot to be used for the connection. From this information, a logical timeslot can be determined. For example, if the call processor 12 sends a command, for example via a resource messenger to the switching module 16, to add a traffic channel to timeslot 1, a span LCI is provided (which provides the shelf, slot, board type, span (air or land) and a span number) and a physical timeslot, e.g., 1. With this information, CNFG task 50 locates a free DSP for the nailed-up connection by going into the CNFG table, illustrated in Figures 12A and 12B, and reading field 346 to find a free DSP. For example, CNFG task 50 searches the configuration database 52 for all signal-processing modules 22. For each signal-processing module 22 identified, the CNFG task 50 reads field 346 to determine if a free DSP exists, and would then search array field 350 for each free DSP on the module 22.

The DSP array 350 for the free DSP also includes fields 402- 410 as shown in Figure 12B. Field 408 identifies the encoded GSM connection of the DSP, e.g., the pcm bus line and slot contained in fields 442-446 as shown in Figure 12B, for the nailed-up connection. Field 410 includes an array of the decoded GSM connections of the DSP namely the pcm line and slot for each connection of the free DSP that provides a DSP for a single voice connection. Thus, the line and slot for the encoded GSM connection for the free DSP provides one connection point on the switching module 16, the other connection point being the LCI of the span provided by the call processor 12. Accordingly, a nailed-up connection is made between these points.

As shown in Figure 12B, the LCI of the span for the nailed-up connection to the free DSP is inserted into field 406 (which is in table 400 for the free DSP now assigned to the nailed-up connection) and represents the span and physical timeslot the DSP is connected to. Similarly, the span array 372 contains fields

422-432 for each span. Field 432 contains the LCI of the free DSP now being used for the nailed-up connection to the span. Field 430 in the span array 372 represents the physical timeslot used for the nailed-up connection that is connected via the switching module 16 into the physical circuit identified in field 408 of the DSP table 400, thus providing the nailed-up connection. If the nailed-up connection is for a land span, then field 430 provides the physical timeslot used to process a call through the switching platform 10. However, if the nailed-up connection is for an air span, indicated in field 424, then for call processing on the span, the physical timeslot field 430 is used only for establishing the nailed-up connection and actual call processing (e.g., the voice connection for a call) uses the logical timeslot field 428.

The tables 440 including fields 442-446 contain the pcm bus values and are based, for example, on the hardware layout information stored in a table in the switching module 16 that associates the pcm line and slot data with the component assigned to the timeslot. Fields 442-446 are initially set to a null value for the logical timeslots until air traffic channels are added, which are added four at a time. When the air channels are added, the line and slot for each logical circuit stored in array field 428 correspond to the four decoded GSM connection for the associated DSP stored in array field 410 of DSP table 400 for the particular DSP.

Once a nailed-up connection is established, the nailed-up DSP LCI from dsp_lci field 402 goes in the dsp_lci array field 432

SUBSTTTUTE SHEET (RULE 26) for the span of the nailed-up connection (e.g., each timeslot on a span could be a traffic channel assigned a unique DSP) . Similarly, the LCI of the span of the nailed-up connection is put in field 406 of the DSP table 400, as shown in Figure 12B. If a DSP is to be reallocated because, for example, the DSP has failed (e.g., the board detects that a DSP is not responding to a polling signal) , the board containing the DSP has been removed from the system or a test such as built in test (BIT) determines that the DSP is bad, then the DSP can be replaced by an operational DSP via a remapping operation according to an embodiment of the present invention. The remapping can be done as long as there is an available DSP to assume the functions of the failed or missing DSP. For example, to remap a DSP (or any other component that may have spare components available) according to an embodiment of the present invention, the resource manager, and thus the call processors, are told by, for example, the switching module 16 that a particular DSP is out of service. As explained earlier, the LCI of the span connected to the bad DSP to can be provided to the resource manager by the CNFG task 50. This LCI would include the span and the physical timeslot used for the nailed-up connection, which identifies the GSM- encoded connection to the DSP (e.g., the physical circuit identified in field 408 of table 400 for the DSP) from within the four traffic channels (e.g., the decoded GSM connections of the DSP identified in array field 410 in table 400 for the DSP) can be identified. With this information, the resource manager informs the call processor 12 that the four traffic channels allocated to the failed DSP are out of service . Once the traffic channels are out of service, the switching module 16 will attempt to locate a free DSP. For example, the CNFG task 50 will read field 346 of the DSP table 340 to determine if there is a free DSP and then determine the LCI of the free DSP as explained previously. If a free DSP cannot be located, no further action is taken to remap the connections to the failed DSP and the affected traffic channels remain out of service.

However, if a free DSP is located, a MOVE TCH message is sent to the SWTH task, which takes the LCI of the span connected to the bad DSP, the LCI of the bad DSP and the LCI of the new DSP

SUBSTTTUTE SHEET(RULE 26) and moves the connection in the switching module 16 of the affected span to the new DSP and will then break the connection between the affected span and the bad DSP. Once the new connection is established, the resource manager is then told that the affected traffic channels are now available, the resource manager informing the call processor 12 that the traffic channels are back in service. The MOVE TCH message involves, for example, the following changes to the CNFG database 52 illustrated in Figures 12A and 12B. The qsm_trunk_lci field 406 in the DSP table 400 for the new DSP will be updated to contain the LCI of the span (e.g., the span does not change and the LCI of the span is put in the database for the remapped DSP) . Correspondingly, the dsp_lci [] field 432 in the span table 420 for the span will be updated with the LCI of the new DSP. In addition, as a new DSP has been mapped to the span, the new LCIs for the physical circuit connection to the new DSP and the logical circuits (e.g., four for every physical circuit) must be provided to the configuration database 52 for the span. Accordingly, the decoded DSP pcm line and slot data for the new DSP of field 410, contained in fields 442-446 of field 440 of the new DSP, will be copied into the logical_ckt array 428 of the affected span, e.g., the four traffic channels associated with the four logical circuits in the affected span will be replaced with the circuits of the new DSP that will handle the traffic channels. Therefore, the failed DSP has been dynamically remapped to allow a new DSP to assume the functions of the failed DSP and further, all of the changed connections remained transparent to the call processor 12. For example, the LCIs of the spans were not changed nor were the traffic channels assigned to each span and thus no additional processing was required by the call processor 12 due to the remapping process.

Described above are a system and method for providing telecommunications span interface, switching modules, and switching functions in a telecommunications switching platform. The switching module or interface module is capable of sending heartbeat messages and identifying as operational over one bus or both buses of a redundant-pair control bus. The module also has a reprogrammable, nonvolatile memory

SUBSTTTUTE SHEET (RULE 26) associated with it from which it can run its operating code. The module can also transfer the operating code into another memory, allowing it to make updates to the operating code stored in the nonvolatile memory without interrupting its execution of its run-time operating code.

A few preferred embodiments have been described in detail hereinabove. It is to be understood that the scope of the invention also comprehends embodiments different from those described, yet within the scope of the claims.

For example, the terms "controller, " "processing circuitry, " and "control circuitry" comprehend ASICs (application specific integrated circuits) , PAL (programmable array logic) , PLAs (programmable logic arrays) , decoders, memories, non-software based processors, or other circuitry, or digital computers including microprocessors and microcomputers of any architecture, or combinations thereof. Memory devices include SRAM (static random access memory) , DRAM (dynamic random access memory) , pseudo-static RAM, latches, EEPROM (electrically-erasable programmable read-only memory) , EPROM (erasable programmable read-only memory) , FLASH memory, registers, or other memory devices known in the art. Words of inclusion are to be interpreted as nonexhaustive in considering the scope of the invention.

Aspects of the claimed invention may be applied to switching systems for GSM mobile switches, PCS mobile switches, or in switches primarily used for switching land- based circuits. The telecommunications circuits described in the preferred embodiment were generally El or Tl spans, but aspects of the invention could be applied to platforms that switch lower- or higher-bandwidth circuits such as T-2, T-3, or SONET. Also, aspects of the invention could be applied to switch circuits of bandwidths generally equivalent to El or Tl but having different framing formats.

SUBSTTTUTE SHEET (RULE 26) Implementation is contemplated in discrete components or fully integrated circuits in silicon, gallium arsenide, or other electronic materials families, as well as in optical- based or other technology-based forms and embodiments. It should be understood that various embodiments of the invention can employ or be embodied in hardware, software or microcoded firmware.

While this invention has been described with reference to illustrative embodiments, this description is not intended to be construed in a limiting sense. Various modifications and combinations of the illustrative embodiments, as well as other embodiments of the invention, will be apparent to persons skilled in the art upon reference to the description. It is therefore intended that the appended claims encompass any such modifications or embodiments.

SUBSTTTUTE SHEET(RULE 26)

Claims

What is claimed is:

51. A resource module for use in a telecommunications switching platform for switching information channels borne on telecommunications signals connected to said telecommunications switching platform, said resource module comprising : 0 a control bus interface connected to a control bus within said telecommunications switching platform; a controller connected to said control bus interface, said controller operable to communicate with other elements in 5 said telecommunications switching platform through said control bus interface, said controller further operable to receive a primary heartbeat message as a part of said communication with other elements within said telecommunications switching platform and to transmit a 0 primary heartbeat response upon receipt of said primary heartbeat message.

The resource module of claim 1 wherein said control bus is a pair of redundant control buses comprising a primary control bus and a secondary control bus . 5

A resource module for use in a telecommunications switching platform for switching information channels borne on telecommunications signals connected to said resource module, said resource module comprising: 0 a nonvolatile memory; another memory; a local communications controller operable to communicate with other elements in said telecommunications switching 5 platform through a control bus; and a module controller connected to said nonvolatile memory, said another memory, and said local communications controller, said module controller operable to control the operation of said resource module, said module controller

SUBSTTTUTE SHEET(RULE 26) further operable: to perform operations according to instructions stored in said nonvolatile memory; to effect the transfer of instructions from said nonvolatile memory to said another memory; to perform other operations according to instructions stored in said another memory; and to effect the loading of new operating instructions from the telecommunication switching platform's higher-level applications into said nonvolatile memory through said local communications controller. A telecommunications switching platform comprising:

a plurality of telecommunications channel inputs;

a plurality of telecommunications channel outputs;

an applications processor operable to manage the switching platform and to control the connection of selected ones of said channel inputs to selected ones of said channel outputs through end-to-end switching requests; and a switching module in electrical communication with said applications processor and operable to perform switching functions to effect said end-to-end switching requests from said applications processor, said switching module comprising a switch and a configuration table in which a first address is translated into a second address to determine the connection of said pluralities of channel inputs and channel outputs to said switch.

The telecommunications switching platform of claim 4 wherein said switching module receives at least one digital signal that is divided into multi-bit, periodically-repeating frames, and wherein said frames are further subdivided into a plurality of timeslots, each timeslot being one or more bits that are consistently transmitted at a certain time within each frame whereby each of said timeslots represents an information channel on said digital signal.

SUBSTTTUTE SHEET(RULE 26) The telecommunications switching platform of claim 5 wherein at least one of said information channels is a telecommunications control channel.

The telecommunications switching platform of claim 5 wherein at least one of said information channels is one of said plurality of telecommunications channel inputs and outputs .

The telecommunications switching platform of claim 5 wherein each timeslot of said digital signal is represented by a first and second address in said configuration table.

The telecommunications switching platform of claim 4 wherein said switching module receives a plurality of digital signals divided into multi-bit, periodically-repeating frames having a plurality of timeslots wherein timeslots of each digital signal are represented by first and second addresses and wherein said switch is operable to switch signals between at least one timeslot of one of said plurality of digital signals to another timeslot of one of said plurality of digital signals.

The telecommunications switching platform of claim 4 and further comprising a switching module responsible for creating said configuration table and for translating said first addresses into said second addresses via said configuration table.

The telecommunications switching platform of claim 10 and further comprising a plurality of resource processors wherein at least one of said first addresses uniquely identifies at least one of said plurality of resource processors such that said identifying address is a logical identifier of said resource processor.

SUBSTTTUTE SHEET (RULE 26) The telecommunications switching platform of claim 11 wherein at least one of said plurality of resource processors is a signal-processing module having a plurality of a digital signal processors operable to perform signal processing on telecommunications channels being switched by said switching platform.

The telecommunications switching platform of claim 12 wherein each of said plurality of digital signal processors is uniquely identified by one of said first addresses.

The telecommunications switching platform of claim 11 wherein at least one of said resource processors is a telephony-support module responsible for providing call- related functions.

The telecommunications switching platform of claim 11 and further comprising an interface module responsible for terminating spans between the telecommunications switching platform and external telecommunications systems.

The telecommunications switching platform of claim 4 wherein said configuration table permits the formation of semi-permanent connections between said plurality of telecommunications input and output channels and resources within the telecommunications switching platform.

A method for configuring a telecommunications switching platform, said platform comprising a controller, a switching module, system resources, and at least one shared communication path, and a plurality of telecommunications channel inputs and outputs for receiving and transmitting information channels to and from external telecommunications systems, the method comprising:

SUBSTTTUTE SHEET (RULE 26) building a configuration table comprising logical identifiers for said system resources, wherein said logical identifier determines over which portion of said at least one shared communications path said system resource will communicate; building a connection table in which a logical identifier is assigned to at least one of said telecommunications channel inputs and outputs, whereby said logical identifier determining over which portion of said at least one shared communication path the information channel associated with said assigned telecommunications channel input and output will be carried.

The method of claim 17 wherein said configuration table and said connection table are the same table.

The method of claim 17 and further comprising the step of polling at least one system resource to receive a registration from such system resource and determining a logical identifier for such system resource.

The method of claim 17 whereby said telecommunications switching platform further comprises a control bus, and wherein said telecommunication platform further comprises a controller connected to said control bus, said controller operable to communicate with other elements in said telecommunications switching platform through said control bus, and further comprising the steps of: transmitting primary heartbeat messages to a first group of a plurality of other elements within the telecommunications switching platform over a first bus of said redundant control buses; and

receiving primary heartbeat responses from said first group over said first bus.

A resource shelf for a telecommunications switching platform, said resource shelf comprising:

SUBSTTTUTE SHEET (RULE 26) a switching module for switching information channels borne on telecommunications signals connected to said telecommunications switching platform, said switching module connected to an applications processor in said telecommunications switching platform;

a plurality of resource modules connected to said switching module for providing resources to the telecommunications switching platform, said resource modules operable to communicate with said applications processor through said switching module.

A method for setting up conference calls in a telecommunications switching platform, the method comprising the steps of: assigning a logical identifier to be used for conferences being handled by the telecommunications switching platform, the conference logical identifier containing information concerning which resources have been allocated in the switching module to provide the conference connections; assigning traffic channels to connect to the conference by requesting connection to the logical identifier assigned to the conference.A switching module for use in a telecommunications switching platform having an applications processor another switching module and at least one resource processor, said switching module comprising: an arbitration bus connected to said another switching module whereby said switching module and said another switching module are operable to negotiate over which of said modules will be an active module and which of said modules will be an inactive module;a network connection to said applications processor; and a local communications connection to said at least one resource processor whereby said switching module is operable to pass communications between said applications processor and said at least one resource processor .The switching module of claim 23 and further comprising conferencing circuits operable to connect multiple two-way traffic channels into a single conference .

SUBSTTTUTE SHEET(RULE 26)