WO2005054996A2

WO2005054996A2 - Method and system for partitioning and allocating codes in a network entity with a distributed processing architecture background

Info

Publication number: WO2005054996A2
Application number: PCT/US2004/039424
Authority: WO
Inventors: Brahmananda Vempati; Jianming Xu
Original assignee: Acatel Wireless, Inc.
Priority date: 2003-11-25
Filing date: 2004-11-24
Publication date: 2005-06-16
Also published as: WO2005054996A3

Abstract

A method and system are provided for allocating, partitioning, and managing identifiers, such as circuit identification codes (CICs) (Fig. 2, item 206), across multiple call processing entities (Fig. 3, items 112, 114) in a network node (Fig. 2, item 204) having a distributed architecture.

Description

METHOD AND SYSTEM FOR PARTITIONING AND ALLOCATING CODES IN A NETWORK ENTITY WITH A DISTRIBUTED PROCESSING ARCHITECTURE BACKGROUND In many telecommunication systems, the performance of a network node, such as a switch, is judged by its capacity and speed in handling simultaneous calls. That is, the benchmark is the maximum number of calls that the network node can handle at any given time. Therefore, the processing speed of the network node plays a major feature of, and often determines, the market acceptability of such a product. Taking a telecommunication switch as an example, depending on a geographical area in the switch is deployed, the capacity of the switch may be required to handle from a few hundred thousand to a few million calls. For each call, a Circuit Identification Code (CIC) should be assigned and reserved for the duration of the call. Multiple CICs can be assigned at the same time for multiple calls occurring simultaneously in the switch. However, current methods for allocating and managing CICs are inefficient and may require human intervention.

BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 illustrates a schematic of one embodiment of a distributed architecture system for call processing in a telecommunication network entity. Fig. 2 is a flow chart of one embodiment of a method for assigning and partitioning CICs to Call

Control Modules (CCMs) when adding a CCM pair to a CCM pool in the distributed architecture system of Fig. 1. Fig. 3 illustrates the application of the method of Fig. 2 within the system of Fig. 1. Fig. 4 illustrates one embodiment of a method for steady state monitoring that may be performed by a Facility Manager (FM) process on a System Administration Module (SAM) card within the distributed architecture system of Fig. 1. Fig. 5 illustrates one embodiment of a method for assigning and partitioning CICs to CCMs when a CCM fails within the distributed architecture system of Fig. 1. Fig. 6 is a flow chart of one embodiment of a method that may be used for assigning and partitioning CICs to CCMs when multiple CCMs fail within the distributed architecture system of Fig. 1. Fig. 7 illustrates an exemplary telecommunications system within which the distributed architecture system of Fig. 1 maybe implemented. WRITTEN DESCRIPTION The present disclosure is directed to a method and system for dynamically partitioning a number of CICs over a set of operational CCMs without manual intervention. It is understood that the following disclosure provides many different embodiments, or examples, for implementing different features of the invention. Specific examples of components and arrangements are described below to simplify the present disclosure. These are, of course, merely examples and are not intended to be limiting. In addition, the present disclosure may repeat reference numerals and/or letters in the various examples. This repetition is for the purpose of simplicity and clarity and does not in itself dictate a relationship between the various embodiments and/or configurations discussed. For the purposes of illustrating the present disclosure, various acronyms are used, the definitions of which are listed below: BICC Bearer Independent Call Control BICCSG BICC Signaling Gateway CCM Call Control Module CIC Circuit Identification Code DDF DCard Distribution Function DDM Data Distribution Module DPC Destination Point Code FM Facility Manager GSM Global System for Mobile communications IAM Initial Address Message ISDN Integrated Services Digital Network ISUP ISDN User Part (of SS7) ^• ISUPSG ISUP Signaling Gateway OPC Originating Point Code REL Release SAM System Administration Module SIM Signaling Interface Module SS7 Signaling System No. 7 It is understood that various embodiments utilizing, for example, a telecommunication switch and voice applications processed thereon are used as representative applications. However, the present disclosure may apply to any type of switch or any network node that needs partitioning of circuit identification numbers or similar identifiers over multiple processing entities coexisting within the same node. Although a certain type of architecture is used herein to describe the disclosure, the present disclosure applies to any type of architecture that includes distributed call processing entities. For each call handled by a telecommunications switch, a CIC should be assigned and reserved for the duration of the call. Multiple CICs can be assigned at the same time for multiple calls occurring simultaneously in the switch. In an SS7 network, a switch supporting voice calls is allocated a fixed number of CICs depending on the switch's engineered maximum capacity. CICs may serve various purposes for a given protocol. For example, with respect to the ISUP protocol, a CIC serves the following purposes: (1) identification of the physical circuits and (2) identification of the signaling relationship between the peer ISUP entities and association of all signaling messages to that relationship. However, in the BICC protocol, the role of a CIC is only to identify the signaling relationship between peer BICC entities. For a switch with a distributed architecture, multiple call processing entities known as Call Control Modules (CCMs) can coexist in the switch as part of its architecture. The CCMs may be located in independent pieces of hardware or may coexist on the same hardware, but each is an independent software module. Each CCM can handle up to a maximum number of calls at a given time. It may be important in such a design that the incoming calls are relatively evenly distributed among all active CCMs in the distributed architecture. This balances the load inside the switch, resulting in greater reliability and efficiency in handling calls. It may also be important for the switch to have an efficient scalability property so that it can meet any deployment capacity requirements. In addition, the switch needs to be designed to efficiently scale (i.e., with minimal cost in terms of adding new elements) in order to support future changes in capacity requirements. Referring to Fig. 1, in one embodiment, a switch 100 with a distributed architecture is illustrated. The switch 100 is coupled to an SS7 network 118 and contains multiple CCMs for handling incoming traffic from the SS7 network. For purposes of example, each CCM resides on an independent physical card where the intelligence of handling calls is implemented in software. However, it is understood that the present disclosure applies to embodiments where the modules are located on the same hardware, as well as embodiments where such functionality is provided at least partially using hardware . For purposes of convenience, the present disclosure refers to each module as a card. The switch 100 includes Signaling Interface Module (SIM) cards 102 and 104, as well as Data

Distribution Module (DDM) cards 106 and 108, CCM cards 110 and 112, and System Administration Module (SAM) cards 114 and 116. As a general description of the traffic flow within the switch 100, the following example provides a high level description of the process that occurs when a call is received at the switch. The SIM cards 102 and 104 act as an interface with the SS7 network 118. The SIM cards 102, 104 receive SS7 messages and convert the messages into internal messages that are sent to the DDM cards 106, 108. The DDM cards are responsible for selecting one of the CCM cards 110, 112 for each message and forwarding the message to the selected card. A DCard Distribution Function (DDF) (not shown) in each of the DDMs 106, 108 may be used to distribute incoming ISUP/BICC messages to one of the CCM cards 110, 112. Each CCM card 110, 112 may include one or more ISUP Signaling Gateways (ISUPSG) (not shown) and/or BICC Signaling Gateways (BICCSG) (not shown), as will be described later in greater detail. Once the call reaches the appropriate CCM card 110 or 112, the CCM communicates with one of the SAM cards 114, 116 to get approval to accept the call. The SAM makes the decision to approve a call after it identifies that the switch 100 has enough capacity to handle the additional call. The SAM then informs the CCM of such acceptance, and reserves a CIC for that call from the CIC pool that has been assigned to the switch. Each SAM 114, 116 may include a Facility Manager (FM) process (not shown) for assigning the appropriate ISUPSG or BICCSG for local allocation of CICs. In a switch with a distributed architecture as described above, all allocated CICs should be partitioned across all configured CCMs. Some existing solutions use Round Robin or random assignment of CICs to different CCMs. However, these solutions may need manual intervention to repartition the CICs when CCMs are added or removed. This is considered an inconvenience for the network operator and may lead to inaccurate CIC assignment due to human error. In addition, existing solutions do not take into consideration network entities that originate more calls than others towards the switch. In these scenarios, given that the CICs are not partitioned properly, a large amount of incoming traffic may be sent to only some of the CCMs. As the total load is not evenly distributed among all CCMs, the switch is not balanced. In addition, these scenarios may create problems when some CCMs become overloaded while others have a relatively large unused capacity. The overloaded CCMs may become stressed and start rejecting calls because they have reached their maximum capacity, and one or more CCMs may shut-down and block all traffic. These problems may reduce the overall switch capacity and increase maintenance difficulties, which in turn increases"the cost of operating the switch in the network. Another problem with current solutions is the use of static partitioning methods. This obviates the need for data synchronization among DDMs and does away with the attendant race condition issues. The drawback of static provisioning solutions is their inability to cope with seamless capacity upgrades, which invalidates one of the primary advantages of a distributed MSC architecture. Conversely, when a CCM failure occurs, all the CICs that were the responsibility of that CCM pair will have to be taken out of service, thereby impacting traffic handling capacity. Additionally, the task of network engineering to derive the static tables that ensure a balanced partition among CCMs becomes tedious. Accordingly, in one embodiment, a method is provided to partition all the CICs allocated to the switch 100 across all CCMs so that traffic is evenly distributed across all available CCMs. The method may be implemented to as to be internal to the system and not visible to the other network nodes in the SS7 network. As will be described later in greater detail, the method may also provide a solution for automatically re-partitioning the CICs without manual intervention when new CCMs are added in the switch, as well as when a CCM is removed or breaks down. In some embodiments, the method may provide improved or optimal use without requiring manual intervention, and without violating the SS7 protocols. The method may also handle incoming calls with minimum processing delay and have good scalability without losing efficiency when handling a relatively large number of calls. Referring now to Fig. 2, in one embodiment, a method 200 may be used to implement some or all of the characteristics described above. The method 200 may, when given a CIC number, assign the number to one of the CCM cards in a distributed architecture system (e.g., the switch 100 of Fig. 1). In the present example, the method applies a modulo scheme using the CIC and a value N as follows, where N is the number of configured CCM pairs in the switch. A CCM pair is composed of one CCM card that is active and handling calls, and another CCM card that acts as a standby to take over the first CCM card's activities if the first card fails. One embodiment of the method 200 uses recursion and assigns the CIC as follows. In step 202, a determination is made using a value pair A(CIC, N) as to whether CIC modulo N equals zero. If so, the method assigns the CIC to node N in step 204 and ends. If CIC modulo N is not equal to zero, a variable k is set equal to the value of CIC divided by N in step 206. The value pair is updated to A(CIC - k, N - 1) in step 208, and the method returns to step 202. The steps 202, 206, and 208 may be repeated until a zero result is reached. This embodiment of the method 200 may be represented as follows:

Proc A ( CIC, N)

{ if CIC % N = 0 assign node N; else k := [ CIC AN] ; %% integer divide A (CIC -k, N-l);

}

This process will continue until CIC % N equals zero, at which time the CIC will be assigned to node N. Accordingly, if the CIC is 1500 and there are six pairs of configured CCM cards (N = 6), then: if 1500 % 6 = 0 assign node 6; else k := [1500/6]; %% integer divide A (1500 -k, 6-1); } Another embodiment of the method 200 assigns the CIC without using recursion as follows:

Proc A ( CIC, N)

{ while (CIC %N != 0) { k := [ CIC / N] ; %% integer divide CIC = CIC - k; N = N - 1; } assign node N;

} The method 200 may be implemented in a DDF process (e.g., in the DDMs 106, 108) to distribute incoming ISUP/BICC messages to one of the CCM cards 110, 112. A Facility Manager process in the SAMs 114, 116 may use the method 200 for assigning the ISUPSGs and BICCSGs for local allocation of CICs. In addition, the ISUPSG and BICCSG in the CCMs may also use the method 200 during transient conditions when message forwarding to the appropriate CCM pair is needed. The method 200 may be used to distribute the CICs equitably if they are contiguously numbered. Since in practice, CICs are generally assigned contiguously, the allocation will generally result in a fairly uniform distribution. However, where CICs are assigned with gaps in ranges, this equity may not be maintained. The method 200 assumes that CCM node numbers are in a sequential range from 1 to N. However, since this assumption is not practical, an internal mapping table may be used to map between an index number assigned by the method 200 and the corresponding node number. For example, 5 CCM pairs may be mapped as shown below in Table 1.

Node Number 16 33 44 46 50 Index 1 2 3 4 5 Table 1

This mapping table may be dynamically created and maintained to reflect the current status of the CCM pairs. In the event of failure of a CCM pair (e.g., node number 44), the mapping table may be updated to reflect only the in-service CCMs as shown below in Table 2.

Table 2 hen the failed CCM pair (e.g., node number 44) returns to service or another CCM pair is added, the mapping table is updated to reflect this by adding the node number as shown below in Table 3.

Table 3

The method 200 may be used for the provisioning of new CICs without any associated configuration changes. The new CIC ranges that are provisioned may be accommodated by the method and distributed equitably among the CCM nodes. Referring now to Fig. 3, in another embodiment, a switch (e.g., the switch 100 of Fig. 1) may need to handle the addition of a new CCM pair 300 to the switch 100. The additional functionality may be embedded within the switch 100 (e.g., within the FM and ISUPSG) in order to transition the traffic to the new CCM pair without needing to issue ISUP blocks. In the present example, the additional ISUPSG functionality enables the ISUPSG to verify and, if necessary, locate another CCM pair that should handle the ISUP message. This functionality makes it possible to handle calls that originated prior to the addition of new CCM(s) and that are still in progress in those CCM nodes. For example, a distribution method may be implemented within the DDF 106 that takes into account the (N+l)⁴ CCM pair. However, there may be calls currently associated with the CIC on a CCM (e.g., the CCM 112) based on the old distribution method (before the node pair was added). To resolve this, the DDF 106 begins to route all ISUP messages taking into account newly added CCM pair 300, oblivious of whether the call is now on the CCM pair per the new configuration or on the CCM pair per the old configuration. However, the ISUPSG on the CCM preprocesses the ISUP message and checks to see if mere is a call instance associated with the CIC. If there is one, then it continues processing normally. It is noted that this check may only be done for non-IAM messages. IAMs themselves may be handled normally. If the ISUPSG finds that there is no call associated with this ISUP message, then it uses the "old" distribution method (e.g., the configuration before the new CCM pair was added) and forwards the ISUP message to that CCM pair. This forwarding by the ISUPSG on the CCM pair may continue until all the CICs have been retired from the old distribution method, which may be signaled to the ISUPSG by the FM as will be described later in greater detail with respect to Fig. 4. This process may be used in adding one or more CCM pairs to the switch 100. The forwarding activity will be called into play only for a brief period of time and then subside to handle the rare cases of long duration calls. With additional reference to Fig. 4, one embodiment of the additional functionality embedded within the switch 100 may be implemented within the FM in order to transition the traffic to the new CCM pair without issuing ISUP blocks. The FM functionality is used to disable the forwarding mechanism in ISUPSGs. The forwarding mechanism is disabled when it is recognized by the FM that a "steady state" has been reached that signifies that all CICs have homed to the appropriate CCMs. The FM then instructs the ISUPSGs on each CCM to disable the forwarding mechanism. In the present example, a method for recognizing the "steady state" may be implemented as follows. The FM may maintain a counter of the number of busy circuits (CurrBUSYCount) at any given time by incrementing on allocation of a circuit and decrementing on release of a circuit. When the FM recognizes a configuration change (e.g., the addition or removal of a CCM pair), the counter and a timestamp (T) are saved to reflect the number of busy circuits at the time of the configuration change. Meanwhile, the original counter continues to be updated. When a release occurs for a call that was started earlier than the saved timestamp (T), men the saved counter is decremented. When the saved counter reaches zero, the FM instructs the ISUPSGs to stop forwarding. If another configuration change occurs during this process, the FM saves the timestamp (T) and the counter to reflect the current values. Referring now to Fig. 5, in another embodiment, a process may be implemented to handle CCM pair failure using one of two approaches. The first approach is to recognize the CCM pair failure and block all circuits that would be handled by that CCM. The second approach is to reassign the CICs to other CCM pairs that are still active. The CIC allocation method can handle the reduction in the number of CCMs in a manner similar to that used to add CCM pairs, as will be described in greater detail below. Referring now to Fig. 6, a method 600 illustrates one embodiment of a forwarding process that may be implemented using the present disclosure. As will be described using specific examples with respect to Fig. 7, the method 600 enables a CCM node to receive a message and determine whether the message should be forwarded and, if so, to what CCM. hi step 602, a CCM receives a message (e.g., from a DDM) and, in step 604, determines whether there is a corresponding call on the CCM that is associated with the message. If so, the method continues to step 606, where the message is handled. If not, a determination is made in step 608 as to whether the message may be forwarded. This may be indicated by using an indicator such as a field or other value either received with the message or received separately. If forwarding is not allowed, the method drops the call in step 610 and ends. If forwarding is allowed, the method determines which system configuration to use for forwarding in step 612 and updates the forwarding indicator accordingly in step 614. In step 616, the method forwards the message to the CCM indicated by the configuration, and the process begins again at the CCM to which the message is forwarded. Referring now to Fig. 7, a specific example of the method 600 of Fig. 6 is illustrated. Fig. 7 shows how successive CCM failures may be handled by extending the previously described mechanism of forwarding non-IAM messages to handle multiple forwardings. As configuration changes occur, each ISUPSG keeps a stack of methods (e.g., configurations indicating the number of nodes (e.g., CCMs), node numbers, and corresponding indices). Each ISUPSG uses these methods to forward messages when a corresponding call is not found on the CCM to which the ISUPSG belongs. In addition, each ISUPSG knows which method(s) have previously been used to forward a message based on an indicator (e.g., a TTL IE) associated with the message to ensure that forwarding will not continue indefinitely. The TTL may also be used to indicate which method an ISUPSG should use to forward the message. For purposes of example, Fig. 7 includes up to six nodes identified (from left to right) as nodes

14, 16, 17, 19, 22, and 25. As described previously with respect to Table 1, each CCM is identified by an index because the CCMs may not be numbered sequentially. Accordingly, each node is assigned a sequential number as follows: node 14 = 1, node 16 = 2, node 17 = 3, node 19 = 4, node 22 = 5, and node 25 = 6. It is noted that in the original configuration (A0), designated as Event 0, no forwarding will be done (e.g., the system is in a steady state). All messages find their "home" CCM since everything is consistent with the method being used. i Event 1, node 17 fails. Upon detecting the configuration change, each ISUPSG adjusts to use method AO (corresponding to the original configuration) to forward non-IAM messages that do not correspond to a call on the receiving ISUPSG. In addition, because a configuration change has occurred, an updated method (identified as Al) is stored for each of the remaining nodes (e.g., the nodes are now operating in configuration Al). It is understood that, because of the failure of node 17, the various CICs may be repartitioned among the nodes using one of the previously described methods (e.g., the method 200 of Fig. 2). Accordingly, a CIC handled by one node during one configuration may be handled by another node during a later configuration. Different exemplary messages after Event 1 are handled as follows. In Event 1, message A is received by CCM node 22, which finds that it has no corresponding call. Because CCM node 22 has no corresponding call, it forwards the call based on the assumption that the call may have started prior to the latest configuration change. Accordingly, it uses the A0 configuration (which is the configuration prior to current configuration Al) to identify the node that was associated with the call in the previous configuration and forwards the call to the relevant node. In the present example, CCM node 16 is identified by A0 as the node handling the call associated with message A, and so CCM node 22 forwards the message to CCM node 16. It is understood that CCM node 22 is aware that CCM node 16 was associated with the message A during the A0 configuration, and simply uses A0 to identify the time period for which it must identify the relevant node for the message A. CCM node 22 also sets the TTL to 0 to indicate that the node receiving the forwarded message is not allowed to forward the message again. The ISUPSG on CCM Node 16 delivers the message to the corresponding call that exists on CCM node 16. If the call is not present on CCM node 16, then CCM Node 16 drops the message because TTL is set to zero (e.g., CCM node 16 is not allowed to forward the message). Message B is received by the ISUPSG on CCM node 14, which finds that there is no corresponding call on CCM node 14. Accordingly, CCM node 14 determines that CCM node 16 is the recipient based on the previous configuration A0, and forwards the message to CCM Node 16 after setting TTL = 0. The ISUPSG on CCM node 16 delivers the message to the corresponding call on CCM node 16. If the call is not present, CCM node 16 drops the message since TTL is 0. Messages C and D are received by CCM nodes 19 and 14, respectively, each of which determines that it has the corresponding call. Accordingly, no forwarding is required for either message. Message E is received by CCM node 22, which finds that there is no corresponding call on CCM node 22. CCM node 22 forwards the call on the assumption that this call may have started prior to the latest configuration change. Accordingly, CCM node 22 refers to A0 and finds that the recipient is CCM node 17, which is not in service. This signifies a message for a call that does not exist because of the failure of CCM node 17, and CCM node 22 drops the message. It is noted that, because there are no recorded configurations prior to AO (because the system was in the steady state), further forwarding is not possible. hi Event 2, CCM node 22 fails (after the failure of CCM node 17). Upon detecting the configuration change (placing the system in current configuration A2), each remaining ISUPSG adjusts so as to use method Al for forwarding and AO for subsequent forwarding. Both methods may be needed for forwarding because a call may have originated during the time when either the first or second configurations were active (and prior to the current configuration A2). Message A is received by CCM node 14, which finds that there is no corresponding call on CCM node 14. CCM node 14 forwards the message based on the assumption that the call may have started during the system's previous configuration. Accordingly, CCM node 14 uses Al and forwards the message to CCM node 16, which CCM node 14 knows was handling the call associated with message A during configuration Al. CCM node 14 also sets TTL = 1 to indicate that one more forwarding hop is allowed (because the message may have been sent during the configuration represented by A0). The ISUPSG on CCM node 16 receives the message and determines that there is no corresponding call on CCM node 16. CCM node 16 forwards the message using A0. CCM node 16 uses A0 because there have been two configuration changes and the value T = 1 in the received message indicates that the message can be forwarded one more time. Accordingly, CCM node 16 is able to determine that it should forward the message using A0. CCM node 16 forwards the message to CCM node 19, which CCM node 16 knows was handling the call associated with message A during configuration A0. CCM node 16 also sets TTL = 0 to indicate that no more forwarding hops are allowed. The ISUPSG on CCM node 19 delivers the message to the corresponding call on CCM node 19. If the call is not present, CCM node 19 drops the message since TTL is 0. Message B is received by CCM node 14, which finds that there is no corresponding call on CCM node 14. CCM node 14 forwards the message based on the assumption that the call may have started during the system's previous configuration. Accordingly, CCM node 14 uses Al and forwards the message to CCM node 16, which CCM node 14 knows was handling the call associated with message B during configuration Al. CCM node 14 also sets TTL = 1 to indicate that one more forwarding hop is allowed (because the message may have been sent during the configuration represented by A0). The ISUPSG on CCM node 16 delivers the message to the corresponding call on CCM node 16. If the call is not present, CCM node 16 would forward the message based on configuration A0. Messages C and D are received by CCM nodes 19 and 25, respectively, each of which determines that it has the corresponding call. Accordingly, no forwarding is required for either message. In Event 3, CCM Node 17 is returned to service. Upon detecting the configuration change, each remaining ISUPSG adjusts so as to use method A2 for forwarding, and Al and A0 for subsequent forwarding. All three methods may be needed for forwarding because a call may have originated during the time when one of the first, second, or third configurations was active (and prior to the current configuration A3). Message A is received by CCM node 14, which finds that there is no corresponding call on CCM node 14. CCM node 14 forwards the message based on the assumption that the call may have started during the system's previous configuration. Accordingly, CCM node 14 uses A2 and forwards the message to CCM node 16, which CCM node 14 knows was handling the call associated with message A during configuration A2. CCM node 14 also sets TTL = 2 to indicate that two more forwarding hops are allowed (because the message may have been sent during the configuration represented by Al or AO). The ISUPSG on CCM node 16 receives the message and determines that there is no corresponding call on CCM node 16. CCM node 16 forwards the message using the previous configuration Al (because T = 2 indicates that there are two hops left so the message has been forwarded once already). Accordingly, CCM node 16 forwards the message to CCM node 19, which CCM node 16 knows was handling the call associated with message A during configuration Al. CCM node 16 also sets TTL = 1 to indicate that one more forwarding hop is allowed. The ISUPSG on CCM node 19 receives the message and determines that there is no ^• corresponding call on CCM node 19. CCM node 19 forwards the message using the previous configuration AO (because T = 1 indicates that there is only one hop left so the message has been forwarded twice already). Accordingly, CCM node 19 forwards the message to CCM node 25, which CCM node 19 knows was handling the call associated with message A during configuration AO. CCM node 19 also sets TTL = 0 to indicate that no more forwarding hops are allowed. The ISUPSG on CCM node 25 delivers the message to the corresponding call on CCM node 25. If the call is not present, CCM node 25 drops the message since TTL is 0. Message B is received by CCM node 14, which finds that there is no corresponding call on CCM node 14. CCM node 14 forwards the message based on the assumption that the call may have started during the system's previous configuration. Accordingly, CCM node 14 uses A2 and forwards the message to CCM node 16, which CCM node 14 knows was handling the call associated with message B during configuration A2. CCM node 14 also sets TTL = 2 to indicate that two more forwarding hop are allowed (because the message may have been sent during the configuration represented by Al or A0). The ISUPSG on CCM node 16 delivers the message to the corresponding call on CCM node 16. If the call is not present, CCM node 16 would forward the message based on configuration Al after setting TTL = 1. Messages C and D are received by CCM nodes 17 and 19, respectively, each of which determines that it has the corresponding call. Accordingly, no forwarding is required for either message. Message E is received by CCM node 25, which finds that there is no corresponding call on CCM node 25. CCM node 25 forwards the message based on the assumption that the call may have started during the system's previous configuration. Accordingly, CCM node 25 uses A2 and forwards the message to CCM node 19, which CCM node 25 knows was handling the call associated with message E during configuration A2. CCM node 25 also sets TTL = 2 to indicate that two more forwarding hops are allowed (because the message may have been sent during the configuration represented by Al or AO). The ISUPSG on CCM node 19 receives the message and determines that there is no corresponding call on CCM node 19. CCM node 19 forwards the message using the previous configuration Al (because T = 2 indicates that there are two hops left so the message has been forwarded once already). Accordingly, CCM node 19 forwards the message to CCM node 16, which CCM node 19 knows was handling the call associated with message E during configuration Al . CCM node 19 also sets TTL = 1 to indicate that one more forwarding hop is allowed. The ISUPSG on CCM node 16 delivers the message to the corresponding call on CCM node 16. If the call is not present, CCM node 16 would forward the message based on configuration AO. Message F is received by CCM node 14, which finds that there is no corresponding call on CCM node 14. CCM node 14 forwards the message based on the assumption that the call may have started during the system's previous configuration. Accordingly, CCM node 14 uses A2 and forwards the message to CCM node 16, which CCM node 14 knows was handling the call associated with message F during configuration A2. CCM node 14 also sets TTL = 2 to indicate that two more forwarding hops are allowed (because the message may have been sent during the configuration represented by Al or AO). The ISUPSG on CCM node 16 receives the message and determines that there is no corresponding call on CCM node 16. CCM node 16 forwards the message using the previous configuration Al (because T = 2 indicates that there are two hops left so the message has been forwarded once already). Accordingly, CCM node 16 forwards the message to CCM node 19, which CCM node 16 knows was handling the call associated with message F during configuration Al. CCM node 16 also sets TTL = 1 to indicate that one more forwarding hop is allowed. The ISUPSG on CCM node 19 receives the message and determines that there is no corresponding call on CCM node 19. CCM node 19 forwards the message using the previous configuration AO (because T = 1 indicates that there is only one hop left so the message has been forwarded twice already). Accordingly, CCM node 19 forwards the message to CCM node 17, which CCM node 19 knows was handling the call associated with message A during configuration A0. CCM node 19 also sets TTL = 0 to indicate that no more forwarding hops are allowed. The ISUPSG on CCM node 17 (now back in service) delivers the message to the corresponding call on CCM node 17. If the call is not present, CCM node 17 drops the message since TTL is 0. If CCM node 17 had not returned to service, the message would be dropped by CCM node 19. Accordingly, the various configurations may be used for message forwarding using an indicator (e.g., the TTL) to identify which configuration should be used next and how many times the message may be forwarded. The above disclosure provides many different embodiments, or examples, for implementing the disclosure. However, specific examples, and processes are described to help clarify the disclosure. These are, of course, merely examples and are not intended to limit the disclosure from that described in the claims. For instance, even though the SS7 ISUP protocol was used to describe the disclosure, the present disclosure applies to any protocol that needs reservation of a code number associated with every call made by a given user. Also, even though voice was used to describe the disclosure, the present disclosure applies to any service user application call that needs a reservation of a code associated with the call and a limited number of these codes are made available. Additionally, even though a specific telecommunication node internal architecture was used to describe the disclosure, the present disclosure applies to any telecommunication node with any internal architecture type that has multiple call processing entities. Furthermore, even though a telecommunication node architecture with call processing entities residing on different hardware cards is used to describe the disclosure, the present disclosure applies for call processing entities that reside on the same piece of hardware. In addition, even though a certain number of call processing entities or CCM cards are used to describe the disclosure, the present disclosure applies to any number of call processing entities that exist in the telecommunication switch. Furthermore, even though the addition of one CCM card was used to describe the disclosure for CIC partitioning during capacity increase, the present disclosure applies to any number of CCM cards that can be added to the architecture of the telecommunication node. In some embodiments, the present disclosure presents a method and system for partitioning Circuit Identification Codes allocated to a switch across all call processing entities in the switch with a distributed architecture. The present disclosure provides a solution that evenly distributes traffic among all active and available Call Control Modules (CCMs). The solution is internal to the system and is not visible to the other network nodes in the SS7 network. The partitioning method also provides a solution for automatically re-partitioning the CICs with no manual intervention needed when new CCMs are added to the switch. The solution also works when removing a CCM or if one or many CCMs break down in the switch, hi addition, the solution presented in the present disclosure may be optimal without requiring any manual intervention, without violating any of the SS7 protocols, and while providing ease of scalability for the entire telecommunication switch. The concepts presented in the present disclosure are implemented using software solutions. The present disclosure provides a solution that works in the architecture to support the capability to route messages pertinent to a CIC to the CCM that has been assigned the responsibility to handle that CIC. Specifically, the process in a Data Distribution Module (DDM) may use the CIC information to route incoming ISUP/BICC messages to the correct CCM. For CIC selection in the outgoing direction, the Facility Manager (FM) process in the System Administration Module (SAM) may be responsible for determining the CCM. The present disclosure provides a dynamic CIC allocation/partitioning mechanism to overcome issues presented by static partitioning. The solution presented in the present disclosure includes a method that unambiguously maps CICs to CCMs. The present disclosure also presents a solution for repartitioning a fixed number of CICs over a set of CCMs automatically and dynamically when one or many CCMs become unavailable, or when one or many CCMs are added to an existing set of CCMs or when one or many CCMs are brought back into service after break-down. The present disclosure provides a method that can be executed automatically and dynamically without manual intervention to partition the CICs over an available number of CCMs by taking in consideration a combination of destination and origination addresses of other entity nodes in the network.

The present disclosure also presents a solution that does not introduce changes into or violate standard

SS7 protocols used in the network to support SS7 services. In addition, the present disclosure provides a solution to partition CICs over multiple CCMs in a manner transparent to other network entities. In other words, the solution does not impact or change other network entities. The present disclosure also presents a solution to route an incoming call at the switch to the correct CCM. Furthermore, the present disclosure presents a solution that allows traffic handling in the switch to be evenly distributed within a configurable variance among all operational

CCMs. The present disclosure also provides a solution for group messages consistent with the partitioning scheme, hi addition, the present disclosure provides a solution for dynamically repartitioning CICs over a set of CCMs without any service interruption. While the disclosure has been particularly shown and described with reference to the preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the disclosure, as set forth in the following claims.

Claims

WHAT IS CLAIMED IS:

1. An executable method for assigning a circuit identification code (CIC) to one of a plurality of call control module (CCM) cards in a distributed architecture telecommunication node, wherein each card is represented by a sequential number between 1 and N, wherein N is equal to the number of active CCM cards in the node, the method comprising: determining whether CIC modulo N equals zero; assigning the CIC to card N if CIC modulo N equals zero; calculating a value k if CIC modulo N is not zero; calculating a new value of CIC (CIC_new) based on the value k; calculating a new value of N (N_new); and determining whether CIC_new modulo N_new equals zero.

2. The method of claim 1 wherein the value k is calculated by dividing CIC by N.

3. The method of claim 2 wherein CIC_new is calculated by subtracting k from CIC and N_new is calculated by decrementing N.

4. The method of claim 1 further comprising assigning the CIC to N_new if CICnew modulo N_new equals zero.

5. The method of claim 1 further comprising identifying that a CCM card in the distributed architecture telecommunication node has failed, wherein the CIC is assigned as part of a repartitioning process automatically executed by the distributed architecture telecommunication node.

6. The method of claim 5 further comprising dynamically updating an index table after the node has failed, wherein the index table associates a sequential number to each of the plurality of CCM cards that are active.

7. The method of claim 1 further comprising maintaining a counter and a timestamp for each of a plurality of configuration changes, wherein a configuration occurs when a CCM card is rendered inactive or when a CCM card is added.

8. A method for forwarding a message within a distributed architecture telecommunication node having a plurality of call control module (CCM) cards after at least one of the cards is rendered inactive, the method comprising: storing a configuration of the plurality of cards each time a card is rendered inactive; receiving a message at a first card of the plurality of CCM cards; determining whether the message is associated with a call being handled by the first card; forwarding the message to a second card if the message is not associated with a call being handled by the first card, wherein the second card is identified as being associated with the call by the configuration stored prior to the most recently stored configuration.

9. The method of claim 8 further comprising: determining whether the message is associated with a call being handled by the second card; and forwarding the message to a third card if the message is not associated with a call being handled by the second card, wherein the third card is identified as being associated with the call by the configuration stored prior to the configuration used to forward the message to the second card.

10. The method of claim 8 wherein multiple configurations are stored until a steady state is reached indicating that each CIC is associated with its corresponding CCM.

11. The method of claim 10 further comprising: determining whether forwarding is allowed, wherein forwarding is disabled when the steady state is reached; and using a number of stored configurations since the last steady state to determine the number of times the message can be forwarded.

12. The method of claim 11 wherein the message is dropped by the first card if the message is not associated with a call being handled by the first card and forwarding is not allowed.

13. The method of claim 11 wherein the message is dropped by the first card if forwarding is allowed but the second card is not active.

14. The method of claim 8 further comprising updating a forwarding indicator prior to forwarding the message by the first card, wherein the forwarding indicator identifies whether the message can be forwarded by the second card and a configuration to be used if the message can be forwarded.

15. A method for forwarding a message within a distributed architecture telecommunication node having a plurality of call control module (CCM) cards after a first card is rendered inactive, the method comprising: storing a first configuration of the plurality of cards prior to the first card being rendered inactive; storing a second configuration after the first card is rendered inactive; receiving a first message at a second card of the plurality of CCM cards; determining whether the first message is associated with a call being handled by the second card; and forwarding the first message to a third card if the first message is not associated with a call being handled by the second card, wherein the third card is identified as being associated with the call by the first configuration.

16. The method of claim 15 further comprising notifying the third card that the message is not to be forwarded again, wherein the third card will drop the message if the message is not associated with a call being handled by the third card.

17. The method of claim 16 wherein the notifying occurs when the first message is forwarded to the third card.