CA2357440C - Load shared architecture for an ss7 node - Google Patents

Abstract

A plurality of processors, each containing a statically replicated SS7 protocol stack, are interconnected with each other for inter-processor SS7 protocol layer message passing by a switch to form a scalable SS7 node. The interconnecting switch operates to allow the exchange of SS7 protocol stack related messages between an SS7 layer in one processor and a different SS7 layer in another processor. The node further includes an SS7 link interface associated with at least one of the plurality of processors, with the switch further operating to allow the exchange of SS7 protocol stack related messages between the link interface for one processor and the SS7 protocol stack in another of the processors. Still further, one or more processors include an application, with the switch further operating to allow the exchange of SS7 protocol stack related messages between a selected application resident on one processor and the SS7 protocol stack in another of the processors.

Description

"' Patent Application LOAD SHARED ARCHITECTURE

BACKGROUND OF THE INVENTION
Technical Field of the Invention The present invention relates to Common Channel Signaling System Number 7 (SS7) and, in particular, to a load shared architecture for an SS7 node.
Descr~tion of Related Art Common Channel Signaling System No. 7 (SS7 or C7) is an international protocol and a worldwide standard for telecommunications. SS7 defines the procedures and protocol by which network elements (nodes) in the telephone network exchange information. The signaling communications are performed over a digital network to execute functions like call setup, routing and control of wired and wireless calls. SS7 was initially developed in order to separate call management and signaling functions from the voice channel. By adding functions for querying databases with customer related information, SS7 has also become an important part of developing new services in the network. SS7 now supports distributed computer r . . .
Patent Application systems permitting access to intelligent database functions and other software driven services. SS7 today covers all aspects of control signaling for a complex digital network. This includes the reliable routing and delivery of control messages to establish and monitor a call. SS7 is also designed to meet today=s demands, as well as future demands, of the network like:
- management and maintenance;
- number portability;
- name/number display;
- freephone, toll, collect and credit calls;
- call forwarding;
- three-way calling;
- wireless roaming; and - mobile subscriber authentication.
SS7 uses a layered protocol modeled on the OSI seven layer communications model. The components of that protocol are generally described below and are illustrated in FIGURE 1.
Message Transfer Part - Level 1 The level 1 portion of the message transfer part (MTP Level 1) is equivalent to the OSI physical layer. MTP level 1 defines the physical, electrical and functional 11 . ~ r Patent Application characteristics of the digital signaling links of the SS7 network. The physical interfaces utilized for the signaling links include E-1, DSBO, DS-OA, DS-1 and v.35.
Message Transfer Part - Level 2 The level 2 portion of the message transfer part (MTP Level 2) is equivalent to the OSI data link layer. MTP level 2 provides link-layer functionality. It implements flow control, error checking and sequence validation to ensure that the two end points of a signaling link can reliably exchange signaling messages (i.e., end-to-end transmission).
Message Transfer Part - Level 3 The level 3 portion of the message transfer part (MTP Level 3) is equivalent to the OSI network layer. MTP level 3 extends the functionality provided by MTP
level 2 to ensure that messages can be delivered between signaling points across the SS7 network regardless of whether they are directly or indirectly connected.
It includes such capabilities as node addressing, routing, alternate routing, and congestion control.
Signaling Connection Control Part The signaling connection control part (SCCP) comprises the OSI transport layer for supporting transaction capabilities application part (TCAP) based services (described below). SCCP provides two major functions that are lacking in the MTP

~r Patent Application layers. The first of these functions is the capability to address applications (i.e., sub-systems) executing within a signaling point. The MTP layers can only receive and deliver messages with respect to a node as a whole, they cannot address specific software applications residing and executing within that node. SCCP, however, allows these sub-systems to be explicitly addressed. The second function provided by the SCCP is the ability to perform incremental routing using a capability called global title translation (GTT). GTT frees originating signaling points from the burden of having to know every potential destination to which they might have to route a message. In performing GTT, a signaling point does not need to know the exact final destination of a message. It can, instead, perform intermediate GTT, in which it uses its tables to find another signaling point further along the route towards the destination. That signaling point, in turn, can further pass on the message or perform final GTT and route the message to its actual destination.
ISDN User Part (ISUP) ISUP defines the messages and protocol used in establishing and tearing down voice and data calls over the public switched network (PSN), and manages the trunk network on which they rely. Despite its name, ISUP is used for both ISDN
and non-ISDN calls. In the North American version of SS7, ISUP messages rely exclusively on MTP to transport messages between concerned nodes.

f . ~ ~
Patent Application Transaction Capabilities Application Part (TCAP) TCAP defines the messages and protocol used to communicate between applications (deployed as sub-systems) in nodes. TCAP supports the exchange of non-circuit related data between applications across the SS7 network using the SCCP
connectionless service. Queries and responses sent between service switching points (SSPs) and service control points (SCPs) are carried in TCAP messages. In mobile networks (such as IS-41 and GSM networks), TCAP carries mobile application part (MAP) messages sent between mobile switches and databases to support, for example, user authentication, equipment identification, and roaming.
Telephone User Part (TUP) The Telephone User Part (TUP) is used for basic call setup and tear-down on analog circuits. In more complex networks, ISUP is used instead of TUP.
As telecommunications networks become more complex, and as more and more subscribers join these networks, increasingly larger and larger demands are being placed on the SS7 network to support operations. It is foreseen that SS7 stacks will soon need to be capable of delivering throughput in the order of thousands, if not tens of thousands, of transactions per second. Current SS7 processing capability, however, is limited, while fulfilling availability and redundancy requirements, to providing service in the order of a few hundred transactions per second. It is 1 . . , Patent Application unfortunately noted that current processing architectures have no potential for reaching the performance levels required in the future.
SUMMARY OF THE INVENTION
A Common Channel Signaling System Number 7 (SS7) node in accordance with the present invention utilizes a plurality of processors interconnected with each other by a switch for message passing. An SS7 protocol stack is statically replicated on each of the plurality of processors, with each stack including a plurality of SS7 layers. The interconnecting switch operates to allow the exchange of SS7 protocol stack related messages between an SS7 layer in one processor and a different layer in another processor. The node further includes an SS7 link interface associated with at least one of the plurality of processors, with the switch further operating to allow the exchange of SS7 protocol stack related messages between the link interface for one processor and the SS7 protocol stack in another of the processors. Still further, at least one of the processors includes an application, with the switch further operating to allow the exchange of SS7 protocol stack related messages between a selected application resident on one processor and the SS7 protocol stack in another of the processors.

s Patent Application BRIEF DESCRIPTION OF THE DRAWINGS
A more complete understanding of the method and apparatus of the present invention may be acquired by reference to the following Detailed Description when taken in conjunction with the accompanying Drawings wherein:
FIGURE 1 (previously described) is an illustration of the SS7 layered protocol;
FIGURE 2 is a block diagram of a load shared architecture for an SS7 node in accordance with the present invention;
FIGURE 3 is a block diagram illustrating the SS7 protocol stack interfaces for a processor within the architecture of FIGURE 2; and FIGURES 4A-4D are exemplary traffic cases illustrating operation of the SS7 node of the present invention.
DETAILED DESCRIPTION OF THE DRAWINGS
Reference is now made to FIGURE 2 wherein there is shown a block diagram of a load shared architecture for an SS7 node in accordance with the present invention. A Common Channel Signaling System Number 7 (SS7) node 10, comprising, for example, a signal transfer point (STP), a service control point (SCP), or a service switching point (SSP), is configured to include a plurality of processors Patent Application 12 interconnected for communication with each other over data links 14 by a switching mechanism 16 comprising in a preferred embodiment a digital switch matrix. The processing capabilities of the node 10 are scalable to meet SS7 processing throughput demands (for example, in terms of transactions per second) by adding or subtracting the included number of processors 12 connected to the switch.
To this end, the disclosed architecture is designed to achieve maximal combined throughput and linear scalability through the use of the switch interconnected plural processors. These two characteristics are partially conflicting with two other desirable characteristics of the SS7 node 10 architecture, namely minimal round-trip delay time and maximal throughput per processor, but it is noted that the latter two characteristics, while not emphasized, are still satisfactorily achieved with the present architecture.
The SS7 node 10 of the present invention utilizes the combined processor 12 capacity in a cluster configuration as efficiently as possible by smoothing out the execution of the SS7 protocol stack (see, FIGURE 1) over all the included processors 12. This architecture accordingly takes advantage of the potential of the SS7 stack for parallel execution of different tasks in both a vertical and horizontal dimension. All layers of the SS7 protocol stack (above the MTP level 2 layer), see generally at 18, are replicated in each of the processors 12, and further execute ~2- 1-03; 3:42PM; ;5143457929 # 4, 9 Patent Application Docket number: P13$67CA
SUBSTITUTE SHEET
within the context of a single TelORB process. A process configured in this manner is commonly referred to as being Astatically replicated.
Reference is now additionally made to FIGURE 3, wherein the stack interfaces for a processor 12 in the architecture of FIGURE 2 are shown. In the upward direction 20, SS7 messages may have to be routed between different processors 12 at the exit of certain ones of the layers of the stack.
Therefore, loose (i.e., message or event oriented) binding, as indicated by the open arrow 22, is used in the upward direction 20 by the application programming interface (API) 24 between certain stack layers. More specifically, each SS7 protocol layer within the stack, except for the IS-4.1/MAP layer, is allowed to execute independently in a --thread within the process. In this context, the Athread may be different from the two thread mechanisms available in the TelORB, and may instead comprise a stack internal, generic mechanism comprising a part of the SS7 stack_ Such functionality for SS7 stack operation is most often delivered as part of the 5S7 stack product itself, as is well known in the art. Most SS7 products are distributable in the vertical dimension and are highly portable by having isolated alI operating system dependent code in a special adaptation module (the system support interface - SSI) that is ported into TeIORB in the context of the present invention. In the downward direction 30, there is freedom to choose the entity of the next stack layer as long as it t2- t-03; 3:42PM; ;5t43457929 # 5/ 9 Patent Application Docket number: P13867CA
SUBSTITUTE SHEET
remains the same during a transaction. However, when taking into account efficiency considerations, the next stack layer within the same processor 12 is most often a better choice. Thus, in a preferred embodiment, static binding, as indicated by the solid arrow 32, is used in the downward direction 30 by the application programming interface (API) 24 between all stack 18 layers down to MTP level 3.
In this configuration, the SS7 protocol layers with the stack execute within the context of the uppermost IS-41/MAP layer thread of the process.
Given the foregoing, the architecture does not distinguish between traffic processors and signaling terminals. All processors 12 act as signaling terminals, sharing the same amount of load related to SS7 signaling. This extreme degree of --parallelization means that the SS7 contribution to the load on each processor is kept low. This facilitates configuration of the application as the node designer can simply assume that SS7 processing will add a uniform load to each processor within the node 10, and dimension the node accordingly.
At least one of the processors 12 within the clustered architecture of the node includes an interface board (IB) 40 providing Tl/El ports, H.110, and DSO
support that runs MTP level 2 on top of a real-time operating system (OS). As an example, this may comprise Trilliums MTP 2 product running on Vx-Works, with the hardware provided by a Performance Technologies interface board (like the PT-10 ~~

Patent Application CPC380 telecom engine board) or an Artesyn interface board (like the MPC860MH, MPC8260 or BajaSpan SS7 portable protocol engines). Another option is to attach PMC modules directly to TeIORB boards in order to potentially eliminate the need for any special sub-racks for SS7. Several interface boards 40 may be clustered together with one TeIORB processor 12 on the same CPCI backplane in order to provide the requisite number of SS7 links 42 per processor (and for the overall node 10). It is preferred, but not required, to spread the links 42 out over as many processors 12 of the node 10 as possible in order to minimize failure unit size and minimize the risk of creating communications bottlenecks. In the preferred embodiment, MTP level 2 communicates via direct memory access DMA with a driver in TeIORB, and that driver in turn uses TeIORB inter-process communication (IPC) to pass messages to and from MTP level 3. It should be noted here that the communications between MTP level 2 and MTP level 3 are not static within a given processor 12, and thus an interface board 40 associated with one processor may communicate with an MTP level 3 portion of the SS7 protocol stack in a different processor.
The MTP level 3 layer communicates downward 30 to MTP level 2 (in effect to its acting agent - the device driver) using IPC with static calls. It communicates upward 20 with loose binding to the SCCP layer (or other protocols like ISUP
or B-~2- 1-03; 3:42PM; ;543457929 a 6/ 9 Patent Application Docket number: P13867CA
SUBSTITUTE SHEET
i ISUP as appropriate) using either the inter-thread event passing mechanism or IPC depending on destination. The management code of MTP level 3 is preferably allocated along with the dataphase code of the layer, but in the preferred embodiment only two instances of it (one active and one Ahot stand-by) are running at a time. This is preferred because the management functionality can (and typically must) be centralized as it is a non-time critical and non-power consuming activity.
In the event of a permanent processor failure, one of the inactive instances takes over as stand-by entity to accordingly avoid any single point of failure.
The SCCP layer uses static calls for communication downward 30 towards MTP level 3. In the upward 20 direction, IPC or inter-thread events are used to -communicate with TCAP over loose binding. As with the MTP level 3 layer, the zxlanagement code of SCCP layer is preferably allocated along with the dataphase code of the layer, but in the preferred embodiment only two instances of it (one active and one Ahot stand-by) are running at a time. This is preferred because the management functionality can (and typically must) be centralized as it is a non-time critical and non-power consuming activity. In the event of a permanent processor failure, one of the inactive instances takes over as stand-by entity to accordingly avoid any single point of failure.

Patent Application The TCAP layer is a library code tightly bundled (i.e., executing within the same thread) with the application layer protocol. It uses static calls in both the upward 20 and downward 30 directions for communicating with IS-41/MAP and SCCP, respectively.
The IS-41/MAP layer uses static calls in the downward 30 direction for communicating with the TCAP layer. In the upward 20 direction, CORBA/IPC or TeIORB IPC dialogues (loose binding) are used to communicate with the application (App) processes.
It is recognized that the SS7 node 10 may need to support other protocols as well as those described above. Examples of these other protocols include ISUP
and B-ISUP. It is further recognized that some specific applications (like ISDN
applications) may need to be supported. These protocols may be executed as separate processes within the same system sharing the common infrastructure of the disclosed stack. The issue of addition involves a simple matter of configuration as neither the source code nor the load modules of the stack need to be modified.
Additional APIs 24 are needed to interface the SS7 protocol stack 18 to the ISUP
based protocol. This interface 24 utilizes loose (i.e., message or event oriented) binding, as indicated by the open arrow 22, in both the upward direction 20 and downward direction 30 with respect to communications with either MTP level 3 Patent Application layer or the SCCP layer of the SS7 protocol stack. Still further, an interface is needed between the ISUP based protocol and the ISDN applications. This interface 24 also uses loose binding, as indicated by the open arrow 22, in both the upward direction 20 and downward direction 30 with respect to communications between the ISUP based protocol and the ISDN applications. These interfaces 24 use either inter-thread event passing mechanism or IPC depending on destination for the loose binding connections. Given the foregoing, it should be noted that the communications between MTP level 3 layer (or the SCCP layer) and the ISUP base protocols) are not static within a given processor 12, and thus an MTP level 3 layer (or SCCP layer) associated with one processor may communicate with an ISUP
based protocol in a different processor. For similar reasons, an ISUP based protocol in one processor may communicate with an ISDN application resident in a different processor.
The application programming interfaces 24 may be either standardized (public) or proprietary components. As an example, the TCAP and SCCP APIs are already specified in )DL by the OMG (see, telecom/98-10-03). C++ and Java versions of these interfaces are generated in the context of the TeIORB
development environment. The APIs for IS-41 and MTP level 3 (a well as other application t2- t-03; 3-42PM; ;5143457929 s~ 7% 9 Patent Application Docket number: P13867CA

I
supporting interfaces) are also preferably specified in JDL, but as no standard definition is currently available, proprietary configurations are used.
Network and link operation and management functionalities, as well as management of the stack itself, is performed using a CORBAJIDL interface via a dedicated (and duplicated) stack manager 60 process. The management intefface is described in CORBA IDL, and added to the TelORB interface repository. In this ' way, the stack, like the rest of the system, can be managed by any browser 62 that understands Internet inter-ORB protocol (IIOP) and dynamic CORBA interfaces. A
database 64, preferably comprising TeIORB's database advantageously re-used for operation and maintenance functions, is connected to the stack rxxanager 60.
The --existing framework in TelORB (which is also based on CORBA/IIOP) is used for alarm handling, and used is made of the TelORB interface repository specifications for creating and issuing alarm.
A more complete understanding of the operation of the SS7 node 10 of the present invention may be obtained by reference to some exemplary traffic cases as illustrated in FIGURES 4A-4D.
In FIGURE 4A, the exemplary handling of an incoming begin SS7 message received from a remote node is illustrated. The message is addressed to the node, and is received on one of the links 42. For performance reasons, the transition 15 1-w t2- t-03; 3:42PM: ;5143457929 ~ 3i 9 Patent Application Docket number: PI3867CA
SUBSTTTUTE SHEET
100 from MTP level 2 to MTP level 3 is performed using connectionless Araw IPC
(i.e., without any dialog set-up sequence or Akey-to-DU algorithm being used).
The TelORB processors 12 adjacent to each included interface board 40 act as distributors with respect to messages to and from the board. It is important that these processors not become bottlenecks, and thus as little work as possible is performed by these processors on a per-message basis. Accordingly, it is preferred that MTP
level 3 not be terminated here (i.e., the TelORB processor 12 adjacent the interface board) for most messages. Instead, the messages are immediately forwarded (see, reference 100) to a deterministically selected MTP level 3 entity (layer) that is normally located on a different processor 12 than the processor associated with the -interface board 40 (where MTP level 2 handling occurred). Given a :node 10 containing N processors 12 (including the adjacent processor), each processor in the node will terminate a l IN fraction of the traffic handled by each of the included interface boards 40.
The deterministic selection process for MTP level 3 handling is needed to maintain sequentiality of messages coming from the same signaling point. In accordance with a preferred embodiment of the invention, origination point code (OPC) for a message, along with the value of signaling link selector (SLS), are used to select the MTP level 3 entity to receive the message. This key combination has a 16 ~..

Patent Application potential limitation in that the number of MTP level 3 entities available for selection by this method in the upward direction may be less than the total number of MTP
level 3 entities available in the node (i.e., that may be used in a downward direction).
In most practical cases, this key limitation is acceptable. As an addition, however, that solves this limitation concern, use of a destination point code (DPC) may also be made in the deterministic algorithm (along with OPS and SLS) to identify the destination MTP level 3 entity for the incoming message.
Generally speaking, there is no reason to split MTP level 3 and SCCP layer handling of a message between two different processors. It is recognized, however, in view of the loose binding provided in the upward direction by the API to support connection oriented SCCP, that such a split is supported by the architecture.
Notwithstanding the foregoing, a preference exists to maintain a one-to-one relationship between the MTP level 3 and SCCP layers on the same processor and the transition 102 of the message is made in that fashion. The loose binding provided by the API further supports inter-processor connectivity from MTP
level 3 and any included ISUP based protocols (as previously described).
The transition 104 from SCCP to TCAP may involve an inter-processor hop.
The receiving TCAP entity is selected by SCCP using a random or round-robin selection process from among all the TCAP entities available within the node.
There Patent Application are two reasons for this. First, the deterministic (OPC+SLS+DPS) procedure implemented at the MTP level 2 to MTP level 3 transition 100 does not guarantee a smooth distribution of traffic load in instances where different signaling points (i.e., OPCs) generate different traffic rates. A secondary and more non-deterministic algorithm is thus needed to govern this transfer 104. Second, the potential limitation described previously concerning the selection of MTP level 3 (and hence SCCP) entities for the transition 100 should preferably not be imposed on the transfer 104 selection. TCAP selection based on random or round-robin algorithms reduces the risk of an unwanted load bias in the node. The preferred binding mechanism at this transition 104 is connectionless Araw@ IPC.
Although an option to instead terminate TCAP/IS-41 in the application process itself exists, and thus save one IPC transition (hop), the task of identifying the application at this point would require looking into the MAP/IS-41 part of the message, and this would necessitate the use of a complex and power consuming parsing algorithm. There is a significant risk in such an implementation for not reaching an optimized message handling process, and thus, although this potential option for solution is available, it is not preferred.
The transition 106 from TCAP/IS-41 to the application itself is performed using either TeIORB asynchronous CORBA (based on IPC) or IPC dialogues. A

t2- t-03: 3:42PM; ;5143457929 # 9/ 9 Patent Application Docket number: P13867CA
SUBSTITUTE SHEET
Akey-to-DU algorithm, as well as an identification of the key to be used, is defined for each application in support of this transfer.
Reference is now made to FIGURE 4B wherein an illustration is provided for the exemplary handling of an outgoing continue/end on dialog SS7 message initiated by a remote node. The transition 110 from the application to the IS-41/TCAP
layer uses the CORBA connection {see, FIGURE 4A, transition 106) established during Abegin.@ Thus, the same IS-4I/TCAP entity used at begin is used for the outgoing message. The transition 112 from TCAP to SCCP to MTP level 3 is made within the same processor in accordance with the tightly bound APIs. Downcalls for these entities are preferably locally processed (i.e., handled within the same processor). --The transition 1 I4 from MTF level 3 to MTP level 2 relies on the internal routing algorithm of MTP level 3 to select the outgoing link.
Reference is now made to FIGURE 4C wherein an illustration is provided for the exemplary handling of an incoming continue/end on dialog SS7 message initiated by a remote node. The transition 120 from MTP level 2 to MTP level 3 is wade as described above in accordance with the deterministic selection algorithm.
The transition 122 from MTP level 3 to SCCP is made as described above with a preference for the local SCCP entity (i.e., on the same processor). The transition 124 from SCCP to TCAP utilized the local transaction identity {as originally assigned by 19 ,.:
~S 01/12/2003 015~04 5143457929 Direceived Patent Application the TCAP entity receiving invoke) as the selector. In this manner it is recognized that by assigning each TCAP entity a set of unique identity sequences, the identity can be later used to find the correct entity for subsequent calls. As an example, the administration of the identity sequences could be provided by dividing the thirty-two bit range of identities into a certain number (e.g., 2048) sub-sequences. If each TCAP entity uses its own processor number as a multiplier, it will automatically know its own sequence, and this can be published for use by IPC. For assigning identities, a round-robin algorithm within the given sequence may be used. The transition 126 from TCAP to IS-41 is the same before (see, FIGURE 4A). The transition 128 from IS-41 to the application uses the same CORBA connection that was established (see, FIGURE 4A) during invoke to ensure that the message automatically end up in the right application.
Reference is now made to FIGURE 4D wherein an illustration is provided for the exemplary handling of an outgoing begin SS7 message to the remote node.
The transition 130 from the application to IS-41/TCAP is made locally (i.e., within the same processor). The reason for this is that an assumption can be made that originated message traffic is fairly equally distributed over all of the generating processors of the node. The local stack is accordingly just as good a choice as any other stack. A CORBA dialog is established for this transition. The transition Patent Application Docket number: P13867CA
from TCAP to SCCP to MTP level 3 is made within the same processor in accordance with the tightly bound APIs. Downcalls for these entities are preferably locally processed (i.e., handled within the same processor). The transition 134 from MTP level 3 to MTP level 2 relies on the internal routing algorithm of MTP
level 3 to select the outgoing link.
Although preferred embodiments of the method and apparatus of the present invention have been illustrated in the accompanying Drawings and described in the foregoing Detailed Description, it will be understood that the invention is not limited to the embodiments disclosed, but is capable of numerous rearrangements, modifications and substitutions without departing from the spirit of the invention as set forth and defined by the following claims.

Claims (32)

1. A Common Channel Signaling System Number 7 (SS7) node, comprising:
a plurality of processors;
an SS7 protocol stack statically replicated on each of the plurality of processors, each stack comprising a plurality of SS7 layers;
a switch interconnecting the plurality of processors to allow the exchange of an SS7 protocol stack related message between an SS7 layer in one processor and a different SS7 layer in another processor; and an interface associated with at least one of the plurality of processors for establishing a physical external SS7 communications link connection.

2. The SS7 node of claim 1 wherein each SS7 protocol stack includes a signaling connection control part (SCCP) layer and a transaction capabilities application part (TCAP) layer, the switch allowing the SCCP layer of the SS7 protocol stack in a first one of the processors to communicate a message to the TCAP layer of the SS7 protocol stack in a second one of the processors.

3. The SS7 node of claim 1 wherein each SS7 protocol stack includes a message transfer part (MTP) level three layer and the interface includes an MTP
level two layer, the switch allowing communication of a message between the MTP
level two layer for the interface of a first one of the processors and the MTP
level three layer of a second one of the processors.

4. The SS7 node of claim 1 wherein each SS7 node further includes a plurality of resident applications, and wherein each SS7 protocol stack includes an upper-most SS7 layer, the switch allowing communication of a message between the upper-most SS7 layer of the SS7 protocol stack in a first one of the processors and a selected application resident in a second one of the processors.

5. The SS7 node of claim 4 wherein the upper-most SS7 layer comprises an IS-41 layer.

6. The SS7 node of claim 4 wherein the upper-most SS7 layer comprises a mobile application part (MAP) layer.

7. The SS7 node of claim 1 wherein each SS7 protocol stack includes a signaling connection control part (SCCP) layer and a message transfer part (MTP) level three layer, the switch allowing communication of a message between the MTP
level three layer in a first one of the processors and the SCCP layer in a second one of the processors.

8. The SS7 node of claim 1 wherein at least one processor further includes an application protocol in addition to the SS7 protocol stack, and wherein each SS7 protocol stack includes a message transfer part (MTP) level three layer, the switch allowing communication of a message between the MTP level three layer in a first one of the processors and the additional application protocol in a second one of the processors.

9. The SS7 node of claim 8 wherein the additional application protocol comprises an ISDN user part (ISUP) based protocol.

10. The SS7 node of claim 1 wherein at least one processor further includes an ISDN user part (ISUP) based protocol in addition to the SS7 protocol stack, and at least one processor further includes a resident ISDN
application, the switch allowing communication of a message between the ISUP based protocol in a first one of the processors and the ISDN application resident in a second one of the processors.

11. The SS7 node of claim 1 wherein the physical external SS7 communications link connection comprises a DS0/DS1 connection.

12. The SS7 node of claim 1 further including an operation and maintenance manager for the node implemented through one of the processors of the node, and further including a back-up operation and maintenance manager for the node implemented through another of the processors.

13. A Common Channel Signaling System Number 7 (SS7) node, comprising:
a plurality of processors;
an interface associated with at least one of the plurality of processors for establishing a physical SS7 communications link connection external to the node, the interface including an MTP level two layer;

an SS7 protocol stack statically replicated on each of the plurality of processors, each stack comprising a plurality of SS7 layers and including a message transfer part (MTP) level three layer; and a switch interconnecting the plurality of processors to allow an interface received SS7 protocol stack related message to be routed from the MTP level two layer of the interface for one of the processors to the MTP level three layer of another of the processors.

14. The SS7 node of claim 13 wherein each SS7 protocol stack further includes a signaling connection control part (SCCP) layer, the switch allowing the received SS7 protocol stack related message to be routed from the MTP level three layer of one of the processors to the SCCP layer of another of the processors.

15. The SS7 node of claim 14 wherein at least one processor further includes an application protocol in addition to the SS7 protocol stack, the switch allowing the received SS7 protocol stack related message to be routed from the SCCP layer in one of the processors to the additional application protocol in another of the processors.

16. The SS7 node of claim 15 wherein the additional application protocol comprises an ISDN user part (ISUP) based protocol.

17. The SS7 node of claim 14 wherein each SS7 protocol stack further includes a transaction capabilities application part (TCAP) layer, the switch allowing the received SS7 protocol stack related message to be routed from the SCCP
layer of one of the processors to the TCAP layer in another of the processors.

18. The SS7 node of claim 13 wherein each SS7 node further includes a plurality of resident applications, and wherein each SS7 protocol stack includes an upper-most SS7 layer, the switch allowing the received SS7 protocol stack related message to be routed from the upper-most SS7 layer of in one of the processors to a selected application resident in another of the processors.

19. The SS7 node of claim 18 wherein the upper-most SS7 layer comprises a layer selected from the group consisting of an IS-41 layer and a mobile application part (MAP) layer.

20. The SS7 node of claim 13 wherein at least one processor further includes an application protocol in addition to the SS7 protocol stack, the switch allowing the received SS7 protocol stack related message to be routed from the MTP
level three layer in one of the processors to the additional application protocol in another of the processors.

21. The SS7 node of claim 20 wherein the additional application protocol comprises an ISDN user part (ISUP) based protocol.

22. The SS7 node of claim 21 wherein at least one processor further includes a resident ISDN application, the switch allowing communication of a message from the ISUP based protocol in one of the processors to the ISDN
application resident in another of the processors.

23. The SS7 node of claim 13 wherein the physical external SS7 communications link connection comprises a DS0/DS1 connection.

24. A Common Channel Signaling System Number 7 (SS7) node, comprising:

a plurality of processors each including a plurality of resident applications;

an interface associated with at least one of the plurality of processors for establishing a physical SS7 communications link connection external to the node;

an SS7 protocol stack replicated on each of the plurality of processors, each stack comprising a plurality of SS7 layers and including an upper-most SS7 layer;

and a switch interconnecting the plurality of processors to allow an application originated SS7 protocol stack related message to be routed from a selected application resident in one of the processors to the upper-most SS7 layer of in another of the processors.

25. The SS7 node of claim 24 wherein each SS7 protocol stack further includes a message transfer part (MTP) level three layer, and wherein the interface includes an MTP level two layer, the switch allowing the application originated SS7 protocol stack related message to be routed from the MTP level three layer of one of the processors to the MTP level 2 layer of the interface for another of the processors.

26. The SS7 node of claim 25 wherein at least one processor further includes an application protocol in addition to the SS7 protocol stack, the switch allowing a message to be routed from the additional application protocol in one of the processors to the MTP level 3 layer in another of the processors.

27. The SS7 node of claim 26 wherein the additional application protocol comprises an ISDN user part (ISUP) based protocol.

28. The SS7 node of claim 27 wherein at least one processor further includes a resident ISDN application, the switch allowing communication of a message from the ISDN application resident in one of the processors to the ISUP
based protocol in another of the processors.

29. The SS7 node of claim 26 wherein each SS7 protocol stack further includes a transaction capabilities application part (TCAP) layer, the switch allowing the message to be routed from the additional application protocol in one of the processors to the TCAP layer in another of the processors.

30. The SS7 node of claim 24 wherein the upper-most SS7 layer comprises a layer selected from the group consisting of an IS-41 layer and a mobile application part (MAP) layer.

31. The SS7 node of claim 24 wherein the physical external SS7 communications link connection comprises a DSO/DS1 connection.

32. The SS7 node of claim 24 wherein the SS7 protocol stack is statically replicated on each of the processors.