Patent Application
20080013446
The subject matter described herein relates to routing signaling messages and utilizing exception routes in a communications network. More particularly, the subject matter described herein relates to methods, systems, and computer program products for selectively limiting access to signaling network nodes that share a point code.
In a signaling system 7 (SS7) network, signal transfer point (STP) nodes are employed to route SS7 signaling messages through the network. Conventional SS7 routing is based on a destination point code (DPC) value that is contained in a message transfer part (MTP) routing label in an SS7 message. Such routing is commonly referred to as MTP routing. An exemplary SS7 message signaling unit (MSU) 100 is shown in
Signaling links connected to an STP are organized into groups of up to 16. Each group is known as a linkset. Furthermore, all signaling links in a given linkset terminate at the same adjacent node. In the case of a combined linkset, all signaling links in a given linkset terminate at the same mated pair of adjacent nodes. STP nodes are typically provisioned to distribute messages across all of the links in a linkset for load sharing purposes.
In addition to signaling links and linksets, a routing entity, commonly referred to as a signaling route, is also defined at an STP. A signaling route may include one or more signaling linksets. An STP may maintain a cost value associated with each route, and route availability is affected by received network management information. When multiple routes exist to the same destination, the STP can select the lowest cost route to the destination. Thus, all messages received at an STP that are addressed to a particular DPC are typically routed to the destination via the first available, lowest cost route. The overall route selection is typically based on the DPC specified in the message being routed. Such a routing mechanism ensures that a message will be routed to the appropriate destination corresponding to the DPC.
To illustrate conventional MTP routing, a sample SS7 network 200 is presented in
In the second message routing scenario illustrated in
The routing process illustrated above has significant drawbacks in situations where network operators need the ability to control the routing of some or all signaling messages traversing a network. For example, on the occasion where a new signaling node (e.g., an SCP) is to be added to an existing network the originating signaling points (e.g., mobile switching centers (MSCs)) typically need to be reprovisioned with a corresponding destination point code so that the new signaling node can be contacted. To avoid the inconveniences and complications associated with reprovisioning the originating signaling points, the new signaling node can be assigned a point code that is currently used by an existing signaling point. Allowing two or more nodes to share a point code where each node processes a portion of the signaling message traffic in the network works well when both nodes and routes to both nodes are available. However, if either node failed, it would be desirable to limit the flow of traffic to the other node to prevent the available node from being overwhelmed. However, because both nodes share a point code, there is no current mechanism for preventing traffic from falling back to the available node and immediately overwhelming that node. Accordingly, in light of these difficulties, there exists a need for methods, systems, and computer program products for selectively limiting access to signaling network nodes that share a point code.
Methods, systems, and computer program products for selectively limiting access to signaling network nodes that share a point code are disclosed. According to one method, first and second destination nodes are provisioned to be identified by a common point code. Messages are routed to the first and second destination nodes respectively using first and second exception routes that are keyed by different combinations of parameters that include the common point code as a destination point code (DPC). At least one default route is provided to the first and second destination nodes. Failure of at least one of the first exception route and the first destination node is detected. In response to detecting the failure, fallback access to the second destination node via the at least one default route is restricted.
The subject matter described herein for selectively limiting access to network nodes that share a point code may be implemented using a computer program product comprising computer executable instructions embodied in a computer readable medium. Exemplary computer readable media suitable for implementing the subject matter described herein includes disk memory devices, programmable logic devices, application specific integrated circuits, and downloadable electrical signals. In addition, a computer readable medium that implements the subject matter described herein may be distributed across multiple physical devices and/or computing platforms.
Preferred embodiments of the subject matter described herein will now be explained with reference to the accompanying drawings of which:
The present subject matter relates to systems and methods for selectively limiting access to signaling network nodes that share a point code. In one embodiment, the present subject matter adds a no fallback option for origin-based message transfer part (MTP) exception routes. As used herein, an “exception route” may include any specifically designated route for transferring messages that is characterized by a predefined combination of one or more parameters and a destination point code (DPC). In one example, an exception route may be utilized to establish dedicated routes from a particular originating signaling node (e.g., a mobile switching center (MSC) or a service switching point (SSP)) to a specific destination (e.g., a service control point (SCP)). An exception route is particularly useful for allocating traffic loads when a newly introduced signaling node, which shares a point code with an existing signaling node, is placed in an established network. For example, one exception route may be provisioned to route messages from one originating node to the existing signaling point that uses the common point code and another exception route may be provisioned to route messages from another originating node to the new signaling point that uses the shared point code. Because the existing signaling node and the newly added signaling node process traffic from different originating signaling points, the total traffic load of the network is shared by the signaling points on a per-origination basis. However, if either of the signaling nodes or routes to the signaling nodes fails, it would be undesirable to allow traffic from both originations to be processed by the available signaling node because that node would likely be overwhelmed with traffic and would also fail. The subject matter described herein provides a no fallback option for exception routes that restricts traffic from falling back to a node that shares a point code with another node when either the node or a route to the node fails.
Although only two MSCs, two STPs, and two SCPs are shown in
In one embodiment, a customer may desire to expand network 400 by adding a new network component (e.g., SCP 409) in order to help alleviate increased traffic loads experienced by an existing network component (e.g., SCP 408). For example, SCP 408 may be responsible for receiving traffic from both MSC 402 and MSC 403. For the purpose of dividing the existing traffic load, SCP 409 may be added so that SCP 409 can process a portion of the signaling message traffic that would have been processed solely by SCP 408. The addition of a new signaling node may be burdensome to the network operator since signaling point originators (e.g., MSC 402 and MSC 403) present in network 400 typically need to be reprovisioned in order to communicate with the new signaling node. For example, if the new signaling node is assigned a new point code, MSCs that formerly communicated with SCP 408 must be provisioned to send messages to the new point code of SCP 409. Because network 400 may include multiple MSCs, reprovisioning each MSC or a subset of the MSCs to communicate with the new point code of SCP 409 can be labor intensive.
In order to avoid this difficulty, SCP 409 can be provisioned to use the existing point code of SCP 408. In
After SCP 409 is added, traffic originating from MSC 403 may be routed to SCP 409. Likewise, traffic originating from MSC 402 may be routed to SCP 408. Thus, SCP 409 is able to alleviate the amount of traffic that originally flowed to SCP 408. This architecture also enables the network to accommodate future expansion since SCP 408 and SCP 409 are essentially sharing the bandwidth that was being handled by SCP 408 only. In one embodiment, the segregation of traffic flowing from a specific MSC (e.g., MSC 402) to a specific SCP (e.g., SCP 408) is implemented by using origin based routing and exception routes.
Generally, network 400 continues to operate in this configuration until a network component failure occurs (or another network signaling node is added). In an exemplary scenario, SCP 408 fails and becomes unavailable. In response, STP 406 sends a transfer prohibited (TFP) message to MSC 402 and not to MSC 403. The TFP message may include the point code (e.g., 2-8-37) of SCP 408 as the concerned point. In response to the TFP message, MSC 402 may cease sending messages to DPC 2-8-37 until a transfer allowed (TFA) concerning 2-8-37 message is received. MSC 403 may continue sending messages to 2-8-37, and these messages will be routed to SCP 409 on LS2413.
Thus, in operation, when a message is received, a lookup is first performed in table 504 to determine whether the parameters in the message matches one of the exception routes. If the message does not match one of the exception routes, a lookup is performed in table 502 to see whether the message matches one of the default routes. Under normal STP operation, if SCP 408 or 409 becomes unavailable, the corresponding exception route will be marked as unavailable. The default route having the same linkset as the exception route would also be marked as unavailable. However, under normal STP operation, messages addressed to the DPC 2-8-37 would be able to access a default route corresponding to the available destination. If the available destination were incapable of handling the total volume of traffic formerly handled by the two destinations, the available destination would fail.
However, according to the subject matter described herein, exception routing table 504 is provided with a no fallback field that restricts access to default routes when an exception route is unavailable. In the example illustrated in
Although the examples illustrated in
In addition to the above-described restricted access, by setting the no fallback option to yes, the network operator can direct its STP to generate response method network management events for the DPC based on the status of the exception routes. For example, if LS1 becomes unavailable to carry traffic, STP 406 may be configured to send transferred prohibited messages (TFPs) to MSC 402 whenever it receives traffic to DPC 2-8-37 that contains the point code of MSC 402 in the OPC field.
One example of utilizing the NoFallback filed of table 504 is illustrated in
In block 604, a routing table is queried using the OPC and DPC of the received signaling message. Namely, a determination is made as to whether the OPC and DPC of the received message match one of the exception routes listed in table 504. If the OPC and DPC do not match one of the exception routes, then method 600 proceeds to block 608. Alternatively, if the OPC and DPC match one of the exception routes, then method 600 continues to block 605, where a determination is made as to whether or not the route is available. If the route is available, then method 600 proceeds to block 606 where the message is routed over the linkset that corresponds to the matched routing table entry. If the route is not available (e.g., the terminating signaling node has failed), then method 600 continues to block 607.
In block 607, a determination is made as to whether or not a NoFallback option is indicated. In one embodiment, STP 406 queries table 504 in order to determine if the NoFallback field indicates whether STP 406 should fallback to default table 502 (i.e., NoFallback option) due to the failure of the associated exception route. In one embodiment, a NoFallback parameter is implemented in a per origination basis (e.g., the OPC of the sending signaling node). For example, referring to
In block 608, the default route table is queried using only the DPC of the signaling message to determine whether a default route applies. If the DPC matches a default route entry, method 600 continues to block 610 where the signaling message is routed over lowest cost route. If the route is not available, then the linkset with the second lowest routing cost (if applicable) is used. Alternatively, if no matching entry exists in block 608, then method 600 proceeds to block 612 where the STP 406 simply sends a message indicating the unavailable destination. Method 600 then ends.
Accordingly, providing an exception route with an indicator for controlling whether or not to fall back to a default route affords more precise control over which signaling nodes may have access to a shared resource (e.g., SCP 408 and SCP 409). In one embodiment, multiple exception routes may be added to table 504 to allow or deny access to the default route on a per-origination basis.
In prior routing solutions, the OPC and DPC (and possibly other message parameters) values contained in a signaling message are used to select one of many routes to the signaling node associated with the specified DPC. One aspect in which the present subject matter differs from prior OPC routing solutions is that the present subject matter limits access to a resource in a shared pool of resources based on the point code of the originating node (or some other parameter). More importantly, the present subject matter enables resources in the pool to share a point code, thereby eliminating the need to reprovision originators that access the resources when a new resource is added to the pool.
Shown in
Each module 702, 704, and 706 may include an application processor and a communication processor. The communication processor may control communication with other modules via IMT bus 700. The application processor on each module may execute the applications or functions that reside on each module. For example, the application processor on DSM 706 may execute software that implements routing function 455. Similarly, the application processor on LIM 702 may execute software that implements a screening function for determining whether messages should be forwarded to DSM 706 for application to an IMS offload function.
LIM 702 may include an SS7 MTP level 1 function 710, an SS7 MTP level 2 function 712, an I/O buffer 714, a gateway screening (GWS) function 716, an SS7 MTP level 3 message handling and discrimination (HMDC) function 718, including an application screening function 720, routing function 440 and associated routing database 450, and a message handling and distribution (HMDT) function 724. MTP level 1 function 710 sends and receives digital data over a particular physical interface. MTP level 2 function 712 provides error detection, error correction, and sequenced delivery of SS7 message packets. I/O buffer 714 provides temporary buffering of incoming and outgoing signaling messages.
GWS function 716 examines received message packets and determines whether the message packets should be allowed in network routing element 108 for processing and/or routing. HMDC function 718 performs discrimination operations, which may include determining whether the received message packet requires processing by an internal processing subsystem or is simply to be through switched (i.e., routed on to another node in the network). Messages that are permitted to enter STP 406 may be routed to other communications modules in the system or distributed to an application engine or processing module via IMT bus 700. Routing function 440 may route received messages that are identified by discrimination function 718 as requiring routing to the appropriate LIM or DCM associated with the message destination. Exemplary routing criteria that may be used by routing function 440 to route messages include the routing data illustrated in Tables 5A and 5B. Message handling and distribution (HMDT) function 724 distributes messages identified by discrimination function 718 as requiring further processing to the appropriate processing module within STP 406 for providing the processing.
DCM 704 includes functionality for sending and receiving SS7 messages over IP signaling links. In the illustrated example, DCM 704 includes a physical layer function 724, a network layer function 726, a transport layer function 728, an adaptation layer function 730, and functions 716, 718, 720, 722, and 724 described above with regard to LIM 702. Physical layer function 724 performs open systems interconnect (OSI) physical layer operations, such as transmitting messages over an underlying electrical or optical interface. In one example, physical layer function 724 may be implemented using Ethernet. Network layer function 726 performs operations, such as routing messages to other network nodes. In one implementation, network layer function 726 may implement Internet protocol. Transport layer function 728 implements OSI transport layer operations, such as providing connection oriented transport between network nodes, providing connectionless transport between network nodes, or providing stream oriented transport between network nodes. Transport layer function 728 may be implemented using any suitable transport layer protocol, such as stream control transmission protocol (SCTP), transmission control protocol (TCP), or user datagram protocol (UDP). Adaptation layer function 730 performs operations for sending and receiving SS7 messages over IP transport. Adaptation layer function 730 may be implemented using any suitable IETF or other adaptation layer protocol. Examples of suitable protocols include Tekelec's transport adapter layer interface (TALI), MTP level 2 peer-to-peer user adaptation layer (M2PA), MTP level 3 user adaptation layer (M3UA), and/or signaling connection control part (SCCP) user adaptation layer (SUA). Functions 440, 450,716,718,720,722, and 724 perform the same operations as the corresponding components described above with regard to LIM 702. Because STP 406 includes SS7 over IP processing capabilities, STP 406 can also be considered an SS7/IP signaling gateway.
Database services module 706 performs database related services for received signaling messages identified by discrimination function 518 as requiring further processing. Examples of database services that may be provided include global title translation and number portability translation. Database services module includes a service selection function 740 that selects an appropriate database service to be applied to a received message in a database services function 750 for providing the appropriate database service. After the database service has been provided, routing function 440 may perform a lookup in routing database 450 to determine the appropriate LIM or DCM associated with the outbound signaling link.
Thus, in operation, when a message is received by STP 406, the message is passed up the appropriate protocol stack to routing function 440. Routing function 440 performs a lookup in routing database 450 to determine the module associated with the outbound signaling link. The message is then routed to the module associated with the outbound signaling link. Because the no fallback option is implemented in routing database 450, messages addressed to a shared point code will not fallback from an exception route to a default route. Accordingly, new nodes can be added to the network that share a point code of an existing node without risking failure of both nodes when of the nodes fails.
It will be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the subject matter described herein is defined by the claims as set forth hereinafter.
The present application claims the benefit of U.S. Provisional Patent Application Ser. No. 60/791,394, filed Apr. 12, 2006; the disclosure of which is incorporated herein by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 60791394 | Apr 2006 | US |
