Fault processing system and method of radio communication net with proxy exchanger

Fault processing system and method for wireless communication network with proxy switch

BACKGROUND OF THE INVENTION Field of the Invention The present invention relates to wireless communication and, more specifically, to the use of proxy switches in mobile communication networks to improve the capacity and cost performance of communication networks and provide a platform for new mobile services.

Related methods describe that all modern mobile communication systems have a hierarchical structure, in which geographic: coverage area is divided into many smaller geographic areas called "cells". Referring to Figure 1, each cell is preferably served by a base transceiver station (BTS) 102a. Several BTSs 102b-n are gathered together to form a base station controller (BSC) 106a through a fixed link 104a. BTS and BSC are sometimes collectively referred to as base station subsystem (BS) 107. Several BSCs 106b-n may be combined into a mobile switching center (MSN) 110 through fixed links 108a-n.

The MSC 110 acts as a local switching exchange (including additional features for handling mobility management requirements, described below) and communicates with the telephone network (PSTN) 120 through the trunk group. In the US mobile network, there are concepts of local MS and gateway MSC. The local MSC is the MSC that corresponds to the exchange association with the mobile station (MS); this association is based on the telephone number, for example, the area code of the MS. (The local MSC is related to the HLR discussed below). The gateway MSC, on the other hand, is an exchange used to connect MS to PSTN calls. Therefore, sometimes the local MSC and the gateway MSC are the same entity, but sometimes they are not (for example, when the MS is roaming). Generally, the visitor location register (VLR) 116 is co-located with the MSC 110 and the logically singular HLR is used in the mobile network. As will be explained below, HLR and VLR are used to store many types of user information and user conditions.

Briefly, many radio channels 112 are associated with the entire coverage area. Radio channels are divided into channel groups and assigned to each cell. The channel is used to transmit signaling information to establish a call connection or similar operations, and once the call connection is established, it carries voice or data information.

At a relatively high level of abstraction, mobile network signaling involves at least two main aspects. On the one hand, it involves the signaling between the MS and other parts of the network. 2G ("2G" is the industrial name of "second generation") and later technologies. This signaling involves multiple access methods used by MS (for example, time division multiple access, TDMA; code division multiple access, CDMA). ), the allocation of radio channels, authentication and so on. The second aspect involves the signaling of different entities in the mobile network, such as the signaling between the MSC, VLR, and HLR. The second part is sometimes called the mobile application part (MAP), especially when used in the signaling system number 7 (SS7) environment.

Different forms of signaling (as well as data and voice communication) are transmitted and received according to different standards. For example, the Electronics Industry Association (EIA) and the Telecommunications Industry Association (TIA) helped define many American standards, such as IS-41, a MAP standard. Similarly, CCITT and ITT helped define international standards, such as GSM-MAP, an international MAP standard. Information about these standards is widely known and can be found in relevant organizations and documents, see, for example, Bosse, SIG NALING IN TELECOMMUNICATIONS NETWORKS (Wiley 1998).

To call from MS 114, the user dials and presses the "Send" button on the mobile phone or other MS. MS 114 sends a dial to indicate that the requested delivery service is to MSC 110 through BS 107. The MSC 110 checks with the relevant VLR 116 (in more detail below) to determine whether the MS 114 allows the requested service. The gateway MSC routes the call to the local exchange of the dial-up user in the PSTN 120. The local exchange informs the called user terminal that the response signal is routed back to the MS 114 through the serving MSC 110 that completes the conversation path. Once this setting is complete, the call can be made.

To transfer the call to MS 114, (assuming the call is coming from PSTN 120) the PSTN user dials the MS-related phone number. According to at least US standards, the PSTN 120 routes the call to the MS's local MSC (which may or may not be the one serving the MS). The MSC then asks the HLR 118 to determine which MSC is serving the MS. This is also to notify the serving MSC that there is a call. The local MSC routes the call to the serving MSC. The serving MSC pages the MS through the appropriate BS. The MS answers and establishes a suitable signaling link.

During a call, BS 107 and MS 114 may jointly change the channel or BTS 102, if necessary, for example due to signal conditions. These changes are called "handovers", and this involves the known message and signaling itself.

One aspect of MAP involves "mobility management." Simply put, different BSs and MSCs may be required to serve the MS, such as MS 114 roaming to different locations. Mobility management ensures that the gateway MSC has the user status and other MSCs need to correctly service the call (billing) information. To achieve this, MSCs use a visitor location register (VLR) 116 and a home location register (HLR) 118. HLR is used to store and retrieve mobile identification number (MLN), electronic serial number (ESN), MS status and MS service status, and others. In addition to storing the MSC identification used to identify the gateway MSC, the VLR also stores similar information. In addition, under the appropriate MAP protocol, a location update process (registration notification) is performed to make the mobile user's local MSC know where the user is. These procedures are applied when the MS roams from one place to another or when the MS turns on and registers itself to access the network. For example, a location update process can be performed simultaneously with the MS 114 sending location update messages to the HLR 118 through the BS 107 and the MSC 110. The VLR 116 sends a location update message to the HLR 118 serving the MS 114, and the user situation is downloaded from the HLR 118 to the VLR 116. MS 114 sends back a confirmation of successful location update. The HLR 118 requests the VLR (if any) of the previous case-specific data to delete data related to the relocated MS 114.

Figure 2 shows the signaling in the CDMA mobile network and the user traffic interface between the BS 107 and the MSC 110 in more detail. BS 107 uses the A1 interface for signaling information communication. The A2 interface transmits user traffic (such as voice signals) between the switch component 204 of the MSC and the BS 107. The A5 interface is used to provide a user traffic path for a circuit switched data call (as opposed to a voice call) between the source BS and the MSC.

When the number of cell sites or the number of users increases, the load on the MSC 110 increases. The increased load forces service providers to increase system capacity. Generally, to increase capacity, the MSC of the service provider adds more switching modules or deploys additional MSCs in the network. Both of these programs are costly.

Moreover, users are demanding updated services, such as "data calls" to the Internet. These services are certain services, because MSCs are mainly designed for voice calls, and they are not cost-effective. Due to the ownership and closed design of many MSC software structures, it is complicated or infeasible to integrate new services in MSC. That is, it is not easy to add the software logic for providing services to the MSC 110. Often, an exchange accessory is used to provide these services. For example, the Workplace Function (IWF) is an attachment that routes data calls to the Internet. Each method-integrating functions into the MSC and adding a trunk-side accessory-including implementing the MSC in service. Since the new service is to stimulate demand, the integration of new services through MSC design changes or trunk-side accessories may increase network congestion at the MSC and require expensive MSC resources.

Abstract The present invention provides a system and method for mobile communication. In particular, switching operations are performed between at least one mobile switching center (MSC) and at least one base station subsystem (BS). The converted communication traffic according to an aspect of the present invention can be transferred to or input from the backup network. According to one aspect of the invention, the logic at the translation address decodes the message to infer when delivery occurs.

In one aspect of the invention, communication is redirected from a mobile communication network to a backup communication network, the mobile communication network including at least one BS, at least one MS, at least one MSC, and at least one switch. The switch sends a signaling message to or receives a signaling message from the MSC on the first signaling link, and sends a message to or receives a message from the BS on the second signaling link; where the second The link has consistency with the mapping of the first link. The switch detects whether the received message is a conversion sequence message (COO) from the MSC, indicating that the MSC will not receive signaling messages on the first signaling link, and the switch generates a conversion confirmation (COA) message and sends it to the MSC . After detecting the COO, the switch receives the signaling message on the second signaling link and provides the control information contained therein to the backup communication network. In addition, after detecting the COO, the switch receives information from the bearer circuit corresponding to the second signaling link and directs the information to the backup communication network.

In another aspect of the present invention, the proxy switch includes signaling message processing logic for sending signaling messages to or receiving signaling messages from the MSC on the first signaling link, and on the second signaling link. Let the link send messages to or receive messages from the BS; where the second link has the consistency of the mapping of the first link. The message interception logic detects whether the signaling message from the MSC is a COO, which means that the MSC will not receive the signaling message on the first signaling link. The message interception logic also prevents the COO from being delivered to the BS and generates a conversion confirmation (COA) message and sends it to the MSC. After the message interception logic detects the COO, the signaling message redirection logic receives the signaling message on the second signaling link and provides the control information contained in it to the alternate communication network; the bearer circuit redirection logic changes from corresponding to the second signaling link. 2. The bearer circuit of the signaling link receives the information and directs the information to the backup communication network.

Brief description of the drawings In the drawings, Figure 1 is a system diagram of a prior art mobile network; Figure 2 illustrates the interface between a BS and a mobile switching center in a prior art mobile network; Figure 3A-B illustrates the The proxy switch of the preferred embodiment and some layouts in the mobile network; Figure 4 illustrates the optimal data device of the proxy switch according to the preferred embodiment of the present invention; Figure 5 illustrates the proxy according to the preferred embodiment of the present invention The mobility management logic circuit of the switch; Figures 6A-B illustrate the additional feature logic of the proxy switch according to the preferred embodiment of the present invention; Figure 7A illustrates the fault management logic of the proxy switch according to the preferred embodiment of the present invention Figure 7B illustrates the FSN and BSN counters of the proxy switch according to the preferred embodiment of the present invention; Figure 8 illustrates the message siphon logic of the proxy switch according to the preferred embodiment of the present invention; Figure 9 illustrates the message siphoning logic of the proxy switch according to the preferred embodiment of the present invention; The software processing structure of the proxy switch according to the preferred embodiment of the present invention; Figure 10 illustrates the software processing structure of the proxy switch according to the preferred embodiment of the present invention; Figure 11 illustrates the software processing structure of the proxy switch according to the preferred embodiment of the present invention Some processing of the software module structure; and Figures 12-14 are simplified structural diagrams that show the message flow and the interactive actions of the software processing.

Detailed description The preferred embodiment of the present invention provides a proxy switch and a method for using it in a mobile communication network. The agent switch is preferably located between the MSC and the BS, and is "transparent" to other components, that is, no BS or MSC needs to know the agent switch or need to change their functional behavior due to the existence of the agent switch. On the contrary, the BS and MSC operate as usual, ignoring the existence of the proxy switch.

Among all the benefits, the proxy switch may alleviate congestion within the mobile network. For example, a proxy switch may be used to (a) siphon the communication traffic initiated by the MS from the network before it enters the MSC (b) send the siphoned traffic to the desired destination through the backup network, such as packet-based The internet. Similarly, a proxy switch may be used to pass communications from the backup network to the MS. As a result, it is possible to avoid expensive MSC and PSTN resources, and the proxy switch may be economically and effectively used to increase the capacity of the network.

In addition, the proxy switch defines a set of startup functions to allow new communication services to be provided to the network. For example, using proxy switches, new call waiting services may be integrated into the mobile network.

FIG. 3A shows the optimal layout of the agent switch 300, where the agent switch 300 is located between the BS 107 and the MSC 110. Only a subset of the trunk line 306 that carries user traffic requires the terminal to be at the proxy switch; other trunk lines 308 may directly connect the MSC 110 and the BS 107. All the control links 312 of the slave BS 107 are terminated in the proxy switch 300. The proxy switch includes a control panel 302 and a data plane 304 (referred to as a "bearer plane"). The control plane 302 handles all signal traffic, and the data plane 304 handles user traffic for all trunks connected to the proxy switch.

In the optimal layout, the proxy switch 300 communicates according to the same signaling protocol on both sides of the control plane 302. For example, in an embodiment suitable for CDMA technology, the signaling link 312 between the BS 107 and the proxy switch 300 transmits information according to the IS-634/IOS A1 interface. Similarly, the signaling link 314 between the MSC 110 and the proxy switch 300 transmits information according to the A1 interface. This situation is in contrast to other mobile switching complexes, such as MSC or BS, where different signaling standards are used for communication on both sides of the switch. For example, the MSC has an A1 interface on one side of the complex and communicates according to SS7/ISUP on the other side (that is, the PSTN side of the switch).

In other embodiments, in CDMA 2000, the proxy switch terminal has new ingress interfaces A8, A9 and egress interfaces A10, A11 for transmitting packet-based traffic, including signaling user traffic. Currently MSCs do not support the entry interface.

The proxy switch data plane 304 uses the same standard on both sides of the switch. The BS side trunk 306, in the CDMA embodiment, communicates according to the A2 and A5 interfaces, respectively, depending on whether voice or data is transmitted on the trunk. Similarly, the MSC side trunk line 307 uses the same interface. In contrast, the MSC has A2/A5 on one side but communicates according to the PSTN 64kb/s pulse code modulation standard on the other side.

In addition, since in some embodiments, all other entities of the mobile network use their own point codes in their signaling ("point codes" are used as unique identifiers in the network), the proxy switch 300 does not use The point code instead uses the point code in the message it receives. Using the point code of BS or MSC instead of the point code of the proxy switch will facilitate the transparency of the proxy switch.

In many embodiments, there is a one-to-one correspondence between the MSC and the proxy switch. Several BSs may work with a proxy switch.

Figure 3B shows another optimal layout. In the layout of FIG. 3B, the proxy switch 300 may communicate with more than one MSC 110j-110k. The control plane 302 of the proxy switch 300, as in the layout of Fig. 3a, may receive control signals from several BSs 107a-n. In addition, the data plane 304 may receive trunks 306a-n from several BSs. Different from the layout of FIG. 3a, the layout of FIG. 3b also receives and sends information to multiple MSCs 110j-k on the signaling link 314j-k.

The layout configuration of Figure 3b is used to better distribute the load on the system, improve reliability (provide another path to the MS), and provide services that are always consistent with the user's situation. In an embodiment using the layout of Figure 3B, the system can be configured so that calls from a given caller are routed to the MSC that handles most of the user's traffic (as opposed to only the geographic location where the user turns on his MS 114) . This decision may be based on statistical monitoring or may be configured in the user's situation. The system is configured in such a way that the amount of location update messages and the amount of similar messages may be reduced. In other embodiments, the proxy switch may be configured to forward calls to relatively underutilized MSCs. In this case, the system administrator may best manage the offloading of the entire communication system. In addition, calls may be routed to MSCs that provide consistent conditions for a given user.

The proxy switch 300 includes software that receives all signaling messages and, depending on the message and system status, performs at least one of the following: 1. Send the message unchanged to the MSC or BS specified in the message; 2. Intercept the MSC and Messages between BSs 3. For some intercepted messages, change the intercepted message to a different message and send the changed message instead of the original message, and send the intercepted message to the MSC or BS with the specified address in the message; 4 . Siphon messages from mobile and PSTN-based networks to backup networks.

The types of actions performed in each case along with the triggering event will be described below.

In many cases, especially when the message from the MS 114 is siphoned away and the traffic is directed to the backup network, the proxy switch 300 may work as the MSC 110. In this role, the proxy switch fulfills the duties and functions that a general MSC should have. Consider the case of a roaming MS; when it moves from one cell to another, it may roam into a cell served by a different MSC, so it needs to implement a "handover" between the source and target MSCs. If the proxy switch 300 has siphoned away the message and the call/session has been routed to the backup network, the handover must be managed by the proxy switch, similar to the handover method managed by a conventional MSC. The agent switch must ensure that the appropriate database is updated with the new location of the MS. Another function of the proxy switch is resource allocation. In particular, when the MS initiates a message requesting a call/session, an appropriate circuit (channel) must be allocated to this session. Depending on the system configuration and system status, the proxy switch performs the allocation, just like the conventional MSC method of allocating circuits.

Figure 4 shows an exemplary layout in which the proxy switch 300 is connected to several backup networks, such as an IP backbone 412 or a circuit-based backup network 414, for example, different carriers. These backup networks may be used to carry voice and/or data traffic to the desired destination while avoiding PSTN 120 and expensive MSC 110 resources in whole or in part. In other words, these arrangements can be used to make circuit traffic backhaul to a different network; for example, circuit traffic from Nashua NH can be backhauled to Waltham MA's MSC. Or they may be used to connect to other networks. For example, the IP backbone 412 may communicate with the IP voice network 418 or the Internet 416. As will be described below, when siphoning traffic to a backup network, the bearer circuit control information (for example, from a signaling message) and voice or data from the link 306 may be sent through the backup network.

To support the layout of these examples and maintain transparency, the preferred embodiment of the present invention provides some core functions. The core functions facilitate the siphoning of traffic from the trunk line 306 before they reach the MSC 110; facilitate the injection of traffic from the backup network to the trunk line 306; facilitate transparent operation; be used as a building block for higher-level applications; and/or support Error recovery process.

Mobility management process when there is a proxy switch When the MS 114 is roaming in the network, the standard process of mobility management requires the MS to issue location update or registration notifications when roaming from one cell to another. These updates are received by the MSC 110 (via the BSC), and finally, the VLR/HLR complex is updated with the new location of the MS. However, standard procedures may not be feasible in some embodiments and the system state of the present invention. For example, the MS may have a call without using the MSC (for example, a call handled by the backup network) but the MS may need to send a location update or handover message. To this end, the preferred embodiment of the present invention provides mobility management logic for the proxy switch, as described in conjunction with FIGS. 3 and 5.

If the location update or handover message is received by the proxy switch 300 from the BS 107, the proxy switch 300 determines whether the MS is being occupied by a call 505. If the MS is not occupied by the call, the proxy switch 300 allows the location update message to be transmitted to the MSC 110 via 510. MSC 110 then updates 515 VLR 116 as usual. The logic flow ends at 599.

If the agent switch 300 determines that the MS 114 is occupied by a call, the agent switch checks 520 whether the MSC 110 is occupied by the call. For example, this can be learned by analyzing call (also called "session") status information maintained by the agent switch. If the MSC is occupied by an MS call, except at this time, the handover message is directly sent to the MSC 110 to process the proxy switch as described above.

If the MS is occupied by a call and the MSC is not occupied by a call, the proxy switch 300 intercepts the handover message 525 from the BS 107 and, using the information in the handover message, converts the handover message into a location update message 530. The location update message is then sent to 535MSC 110 and the proxy switch updates its own database (not shown) to reflect this change. This local database serves as the VLR of the proxy switch and contains all the information contained in the VLR (because the proxy switch sometimes needs to work like an MSC). The proxy switch 300 then sends a confirmation message 540 to the BS 107. The logic flow ends at 599.

The process of managing auxiliary features when a proxy switch exists. In the preferred embodiment of the present invention, the MS may be busy when the MSC thinks the MS is idle; for example, when the MSC tries to send a call from PSTN 120 to the MS, the MS may Are busy with data or voice calls processed by the backup network. To support this situation, the agent switch 300 provides logic to notify the MS of this situation. Using this logic, auxiliary services, such as traditional call waiting, may be provided by proxy switches. Moreover, new forms of call waiting and other new services may be built on this core support function.

3 and 6A in combination, when a call enters the agent switch 300 from the MSC 110, the agent switch determines whether the MS is being occupied by the call when the message enters 602. If the MS is not busy, the proxy switch 300 allows the message originating from the MSC to be sent to the BS 603. The logic flow ends at 699.

If the MS is busy, the agent switch decides 604 if the MS call is being handled by the agent switch and not by the MSC; for example, the call may be handled by an alternate network connected to the agent switch (see Figure 4), where the agent switch needs to process Similar to the call behavior of an MSC; the proxy switch does not simply let the message through. If the call is handled by the proxy switch instead of the MSC, the proxy switch intercepts 605 the call from the MSC 110 and converts the intercepted message into a 606 feature notification message. The proxy switch 300 then sends 607 the characteristic message to the BS 107 for subsequent transmission to the MS 114, which will be used to inform the user about the incoming call. The proxy switch intercepts 608 any response to the feature notification message from the BS and reacts accordingly. How the proxy switch acts depends on the application used in this logic.

If the MS is occupied by a call handled by the agent switch and also occupied by a call handled by the MSC, the agent switch takes action 609 as a response to this state. This action depends on the specific application involved. Traditional call waiting is just such a service that may be built on top of core functions.

If sometimes, the MS is occupied by two calls of the backup network, and the call of the third MS comes from the backup network or MSC, the proxy switch will guide the third call according to the application logic. For example, in a call waiting application, the third call will be routed according to the instructions included in the user's situation; the general choice is to direct the call to the user's voice mailbox. When the MS is occupied by two calls involving the MSC, the third call of the MS comes from the backup network and uses similar logic; again, the user situation indicates how the third call is handled and how the proxy switch follows this logic. Finally, it should be noted that if the MS is occupied by two calls involving the MSC and the third call of the MS arrives, the MSC itself, in this case, will decide which logic it uses to handle the third call.

For example, Figures 3 and 6B combine to illustrate an exemplary call waiting application. The logical actions are as described above through the actions labeled 608 or 609 (note that Figure 6B starts with modules 608 or 609, as opposed to 600); that is, although Figure 6B helps describe the use of specific auxiliary characteristics such as traditional call waiting, auxiliary characteristics The initial behaviors are those described in Figure 6A.

If the logic starts at 608, it means that the agent switch has detected that the MS is occupied by the call, and the agent switch is processing the call, but the MSC is not there. At this point, the proxy switch has intercepted the call request from the MSC, converted it into a feature notification, and sent this feature notification to the BS. The agent then receives interception of the response to this message from the BS.

In the call waiting application logic of FIG. 6B, if the user indicates that they are willing to receive a call, the proxy switch converts 615 the response to a message indicating that the MS is receiving a new call from the MSC. The proxy switch 300 then sends 620 the converted message to the MSC. At this point in this example, the MSC "thinks" that the call is a normal call, that is, the MSC state reflects only a conversation with the MS. In fact, as new calls are received, the user is receiving two calls in call waiting mode: one call is being processed for the MSC and the other is being processed by the proxy switch. The agent switch status reflects these two calls. Proxy Exchange 300 helps 625 MSC 110 establish a new call. (This last step is only done when the user receives the call; if the user does not accept it, the agent logic timeout will never reach action 625.) For example, the agent switch 300 may put a call from the backup network on hold so that the call received from the MSC can be enabled. Pass to reach MS. The proxy switch 300 intercepts 630 any subsequent characteristic notification responses from the MS and redirects to the MSC or proxy switch as needed. For example, the user may wish to "switch" between mobile and alternate network service calls. The proxy switch may need to intercept this response to put a call on hold and connect another call to the user as part of the act of intercepting subsequent feature notifications. In other cases, if the MSC is connected to the MS by multiple calls (some on hold), the proxy switch may need to send such responses to the MSC. When the call ends, the proxy switch 300 sends 640 the correct charging information to the system. This is done so that the user can receive the correct bill when a service that does not involve the MSC is provided. The way the information is stored and sent to the billing system depends on the implementation of the use system and the service provider. Most service providers specify how billing information is collected, formatted, and sent.

If the MS 114 is occupied by a call and is also occupied by a call handled by the MSC, and if the MSC indicates a new call to the MS, the proxy switch 300 may be configured to intercept 650 the feature notification message from the MSC to the BS 107. The feature notification message is blocked 655 and cannot be transmitted to the BS, so no response is sent 660 from the BS to the MSC. The logic flow ends at 699. The MSC does not get an answer and it is assumed that the MS does not want to receive the call. The MSC then ends the call using standard procedures, such as the user's voice mailbox or playing the user's absence message.

The call waiting application logic of Figure 6B is limited to handling two simultaneous calls. The same general method can be extended to handle call waiting for more than two calls, handle multiple calls from a backup network, handle data calls and voice calls, and the like.

The fault management process when there is a proxy switch There is a standard process for fault management of the signaling link between the BS 107 and the MSC 110. In these processes, the BS and the MSC are considered to be the same level, the same level 1 and the same level 2. The two same levels maintain two sets of numbers, called Forward Sequence Number (FSN) and Reverse Sequence Number (BSN). FSN identifies the latest message sent to the same level and BSN identifies the latest message received from the same level. For example, suppose there are two signaling links SLC0 and SLC1 between the same level 1 and the same level 2. If the same level 1 has FSN=5, and the same level 2 has BSN=3, then the same level 1 knows that it has sent all messages including message 5 to the same level 2; the same level 2 knows that it has received all the messages. Including the message of message 3. If SLC0 is interrupted and the same level 1 detects this interruption, the same level 1 sends a switch command (COO) message to the same level 2, requiring the same level 2 to switch to the link SLC1. Same level 2 responds with COA (conversion confirmation). Included in these messages is the BSN number based on which missing message is to be resent. For example, in the above example, messages 4 and 5 need to be retransmitted to the same level 2.

In another example, consider an example in which the same level 1 has FSN=10 and BSN-6; the same level 2 has FSN=8 and BSN=3. It is also assumed that there are two signaling links between the same level 1 and the same level 2, represented by SLC0 and SLC1, and it is assumed that SLC0 is interrupted as detected by level 1. Then, the same level 1 uses the link SLC1 to send the COO message to the same level 2 and includes its BSN (=6) in the COO message. When the same level 2 receives this message, it compares the received BSN with the internal FSN (=8) and decides that the last two messages (8-6=2) should be resent. The same level 2 queues two messages to resend and sends the COA message including its BSN (=5). The same level 1 receives COA messages and compares the received BSN with its internal FSN (=10), and then decides that the last 5 messages (10-5=5) should be resent. The same level 1 queues two messages to resend to the same level 2.

In the preferred embodiment, the standard replay and recovery mechanism between the BS and MS is not expected to be feasible. In short, the BS 107 may send a message to the proxy switch without being received by the MSC, for example, a siphoned message, or vice versa, for example, a blocked MSC message. Therefore, the basic FSN/BSN status in the BS and MSC will not accurately reflect the status of the entire system.

Accordingly, in the preferred embodiment of the present invention, the proxy switch provides a new form of fault management. 3 and 7A-B in combination, the proxy switch establishes 705 a set of FSN and BSN counters for each link to the MSC 110 and a set of FSN and BSN counters for each link to the BS 107. With particular reference to FIG. 7B, which uses a single link arrangement to illustrate this concept, the FSN/BSN pair 787 with link 785 on the MSC and the FSN/BSN pair 789 with link 786 are conventional. Track the number of messages sent and acknowledged (or "acked") in the MSC link segment 785 for 787; track the same but BS situation for 789. The proxy switch 300 includes FSN/BSN pairs 788 and 790. Track the number of sent and confirmed (or "acked") messages on the link segment 786 from the proxy switch 300 to the BS 107 for 788; track the number of sent and confirmed (or "acked") messages for the link segment 785 from the proxy switch 300 to the MSC 110 for 790 acked) The number of messages.

As mentioned indirectly, the value of 787 is not expected to be equal to the value of 788. For example, as part of the normal proxy switch logic, the transmission of MSC messages to BS 107 may be interrupted, as described herein. After the message is interrupted, the FSN value of 787 should be one greater than the value of 788. In addition, the difference between the FSN and BSN of the 787 and the difference between the FSN and BSN of the 788 do not need to be the same. For example, assume the simple case where a message from the MSC 110 should be interrupted by a part of the normal proxy switch logic, as described here. The difference in 787 will be one until the confirmation is received at MSC 110, but there will be no difference in pair 788, as no message is sent to BS 107.

As the message is received at the proxy switch 300, the proxy switch intercepts the message and updates the FSN/BSN pair as described above.

If the proxy switch 300 detects 715 a COO message from the MSC 110, indicating that the link 785 is not smooth, the proxy switch 300 intercepts the message 720 and does not allow it to pass to the BS 107. The COO includes the BSN message to the 787 and identifies the new link (not shown) to which the signaling should be switched. The proxy switch forces the interruption of the link 786 between the proxy switch and the BS (link 786 corresponds to link 785). The interrupt simulation is as follows. Every few milliseconds, regular BSs and MSCs send a message called "fill signal", and the receiver knows that the link is running after receiving it. If the receiver does not receive the fill signal within the specified length of time, it assumes an interruption and sends a COO message. Therefore, in order to simulate an interrupt, an embodiment of the present invention modifies the state machine based on the software protocol so that the "fill signal" is not sent, thereby generating an interrupt, causing the generation of COO at the proxy switch (this modification is related to the conventional MSC).

The proxy switch uses the 788 pairs of BSNs to generate COO messages to the BS 107, which is contrary to the BSN information including the original COO messages for the 787 information. The new COO informs the BS of the number of messages it has received on the (interrupted simulation) link (that is, a BSN of 788). The generated COO uses the new link to be switched to (not shown in Figure 7B). This new link corresponds to the link between the proxy switch 300 and the MSC 110 to be switched to.

The revised BSN number is sent to 735 BS 107 via a new COO message. COO is sent on an uninterrupted link. The proxy switch 300 waits for and receives a COA (confirmation) message 740 from the BS 107, and generates 745 a new COA message. The new COA will include BSN information pair 790, as opposed to the information in pair 789. Send the new COA 750 to the MSC 110.

Subsequently, the proxy switch waits to receive the retransmitted information on the new link from the MSC and BS. Any received information is then retransmitted 755 to the corresponding destination or processed in the usual way (including potential interruptions, etc., as described above). The logic flow ends at 799.

In the above embodiment, the proxy switch relies on the BS or MSC to detect the interruption in the corresponding link. The interruption in the signaling link is forced as a result of the current BS structure; that is, the interruption needs to be used to establish the necessary events for COOs. In other embodiments, the proxy switch may detect the interruption, and in response to this, the proxy switch will imitate the MSC related to the BS or imitate the BS related to the MSC.

Automatic triggering process based on COO message siphoning In some embodiments of the present invention, the proxy switch may dynamically determine when the system can benefit from redirecting (siphoning) messages to an alternate network (see, for example, 400, Figure 4). For example, in an embodiment of the present invention, the proxy switch 300 directly or indirectly monitors the signaling bandwidth as a system bandwidth measurement (for example, reduced signaling bandwidth becomes reduced system bandwidth). In one embodiment, the COO from the MSC may be used as a congestion signal for the MSC, or at least the bandwidth to/from the MSC will be impaired until the affected link is repaired and the traffic returns to that chain road. Therefore, the proxy switch 300 interprets the COO as a trigger event "slowing down" the traffic to the MSC, and in response, starts to siphon the traffic to the backup network connected to the proxy switch.

One form of exemplary logic is shown in FIG. 8 in this regard. The proxy switch establishes a set of 805 FSN and BSN counters for each link to the MSC. Every message to or from the BS is intercepted and the sequence number is updated corresponding to 810. If the proxy switch 300 detects 815 the COO message from the MSC 110, then the proxy switch 300 intercepts the message 820 and does not allow it to pass to the BS 107. In this example, the COO only reflects the requested change and does not indicate that the message needs to be replayed. The proxy switch 300 then generates a COA message 825 with the modified BSN number of the MSC, and sends the COA message 830 to the MSC 110. The modified sequence number is established by the proxy switch during message processing, similar to the above. Therefore, MSC believes that its COO has already occurred. The communication bandwidth between the MSC and the BS will be reduced due to the conversion, due to the lack of a signaling link.

However, although the bandwidth between the proxy switch 300 and the MSC may be impaired due to the aforementioned COO, the bandwidth between the BS 107 and the proxy switch 300 is not impaired. The proxy switch may take advantage of this by siphoning traffic to the backup network. Correspondingly, the proxy switch starts to siphon 835 the traffic generated from the BS side of the proxy switch. There are many alternate network types that may be used to transmit voice and data traffic from the MS 114 (see Figure 4). If there are multiple types of alternate networks connected to the proxy switch, the proxy switch may select the alternate network type based on the type of communication, for example, data or voice. When siphoning begins, the proxy switch configures the data plane to route some of the circuit-bearing traffic to a suitable backup network (which will be explained below). For example, the VoIP assembly 404 may be configured according to the information proposed in the signaling message.

The traffic siphoning of a given conversation continues. The proxy switch 300 then maintains the FSN and BSN numbers as described above. Any COO message from BS 107 is intercepted and COA is generated and sent to BS while maintaining FSN and BSN counters. Any COO message from MSC 110 is intercepted 850 and it is checked whether they indicate that the MSC is ready to be on the link of the previous failure again Receive traffic, that is, check whether the COO is changed back to a message. If there is such a message, the proxy switch interprets it as the MSC can handle the higher-level traffic again, and will take action to "reconnect" the siphoned link and traffic. (If the COO is not a change-back message, it may be a conversion message, indicating that it can further benefit from siphoning traffic.) If there is a change-back message, the new COO is generated from the modified BSNs 855 and sent 860 to BS 107. The modified BSNs are the aforementioned ones maintained by the agent. The proxy switch 300 then waits and receives the COA message 865 from the BS107. The new COA message is generated 870 from the modified BSN number and sent 875 to the MSC 110. The proxy switch then stops the traffic siphoning process. The control plane corresponds to the command data plane.

In some embodiments, the decision to siphon traffic may include other considerations. For example, the backup network may provide QoS guarantees that are considered by the proxy switch logic. In one embodiment, the siphon is only at the boundary of the session. Correspondingly, if a call is siphoned, it is at the origin of the call.

The above description is based on the premise that COO is used as an indication of network congestion. In an embodiment of the present invention, the above-mentioned automatic siphon logic is supplemented by the fault management logic circuit shown in Figs. 7a-b. In this embodiment, each time the proxy switch 300 obtains a COO from the MSC, it executes the above-mentioned replay logic. The COO message from the BS, however, is always handled as an interruption of the signaling link, and the replay logic is executed without siphoning.

The process of saving point codes across BSC and MSC In the SS7 network, all network elements are addressed by unique numbers called "point codes". As a result, all BSCs and MSCs will have a unique point code. The message from the BSC to the MSC generally includes a destination point code, for example, the point code of the desired MSC, and an originating point code, for example, the point code of the BSC that sent the message.

The message from the BSC to the MSC, for the call originated from the MS, additionally requires the allocation of a bearer circuit to the call. The carrier circuit (carrying voice and data) is identified by the circuit identification code (CIC).

To support the transparent operation of the proxy switch, the point codes and CICs transmitted between the BSC and MSC are reserved for all messages. This requirement is too complicated, because when some of the circuits carrying the bearer traffic transparently cross the BSC to the MSC, other circuits sent from the BSC will be terminated at the proxy switch, and the MSC does not know such termination.

As mentioned above, some trunks 308 are pre-defined for direct connection between the BS and MSC, while other trunks 312 are connected to the proxy switch. Similarly, in the preferred embodiment, some of the bearer circuits are pre-defined for direct connection between the BS and the MSC ("via circuit"), and the remaining circuits are terminated at the proxy switch ("siphonable circuit").

In one embodiment, under normal operation, the MSC may not assign a siphonable circuit to any call. When siphoning traffic (as described above), the proxy switch may assign a siphonable circuit to the call from the BS (via communication from the appropriate CIC to the BS), and the BS will respond by sending voice data on that circuit . As will be explained below, the sound or data may be read from the circuit and then sent to the backup network through the DACS 402 accordingly.

In order to ensure the consistency of the MSC information when the proxy switch fails, in an embodiment of the present invention, the network management system accesses the CIC database at the MSC and marks that the siphonable circuit is available. As a result of this behavior, the MSC will consider these circuits to be available for distribution, and the network will behave like a conventional mobile network (that is, a network without an agent).

When the proxy switch is restored, the network management system revisits the CIC database at the MSC, but this time the siphonable circuit is marked as "unavailable". It also accesses the proxy switch database and marks the siphonable circuit as "available". These circuits are then assignable to the proxy switch as described above. In some embodiments, the siphonable circuit may gradually be marked as "unavailable" at the MSC and marked as "available" at the proxy switch so that the proxy switch gradually gains more control over the siphonable circuit.

In order to process the layout of FIG. 3B, the above-mentioned technology needs to be added. In particular, to process the layout of FIG. 3B, the proxy switch needs to intercept the message from the BS and change the point code to reflect the remapped MSC. In an embodiment, this is done at the granular session layer, meaning that the remapping to the new MSC may be decided at the session boundary. As an alternative, the remapping may be done at another granular call layer, for example, when the MS is turned on. Some embodiments implement the mapping to MSCs and their corresponding point codes through related device serial numbers (for example, including messages when the MS is turned on).

Hardware Structure Referring to FIGS. 3 and 4 in combination, the best embodiment of the proxy switch 300 includes a control plane 302 and a data plane 304. The control plane includes a combination of processing hardware and related software. The data plane is mostly composed of hardware that responds to control plane commands.

The control plane includes a programmable signaling card (for example, the available PMC8260 from the Force system) for receiving signaling information from the signaling links 312, 314 and performing initial processing on it. This initial processing includes sending and terminating information on the signaling link and extracting the message information included in the signaling message under program control. Once the message information is collected, the signaling card transmits the message information to the programmable processing card (for example, RPC 3305 and 3306 available from Radisys), which is then responsible for performing the proxy switch function in response to the response as described above.

The control plane consists of a passive fault tolerance mechanism. These mechanisms ensure that in the event of a catastrophic failure of the control plane, the signaling link received on one side of the control plane will be bypassed to the other side. Therefore, if there is a problem with the control plane, the link will be bypassed and cross the control plane, and the BSC and MSC can communicate as usual.

An exemplary embodiment data plane 304 is shown in FIG. 4. It includes a DACS 402, an IP voice component 404, a data terminal module 406 (for example, terminal A5 data in a CDMA network), a PPP relay component 408, and a PPP relay component 410. Different components may be packaged on one or more modules.

DACS 402 receives the carrier circuit of trunk 306 and terminates the information received on the trunk; it also sends voice and data on these trunks. The predefined DACS 402 port is connected to the VoIP 404 and the data terminal assembly 408. The data terminal component 408 is then connected to the PPP relay 408, and then communicates with the PPP terminal component 410. Moreover, the data plane may also be used to connect to a backup circuit-based network, for example, to backhaul traffic to the circuit MSC of another regional network.

All data plane entities receive control commands from the control plane through the control channel 401 used to carry information according to H.248 and Media Gateway Control Protocol (MGCP). The control channel is especially used to inform the DACS 402 how to equip the carrier circuit. For example, mapping from a given input circuit of BS 107 to an output port of one of the components. The control channel is also used to transmit control information to different components. For example, the signaling information includes control information such as the IP address used to establish the destination address required for the VoIP component. This information will then be used in the VoIP component to send the sound information received from the DACS by sub-packaging the information accordingly and sending it according to a suitable protocol, such as RTP/UDP/IP.

The data plane consists of a passive fault tolerance mechanism. These mechanisms ensure that when the control plane fails, the trunk line received on the DACS side will be bypassed to the output trunk line connected to the MSC. Therefore, if there is a problem with the data plane, the trunk line will be bypassed across the data plane, and the BSC and MSC can communicate as usual.

The software structure is combined with reference to Figures 9-10. In the preferred embodiment, the control plane software executes the session manager processing and the communication processing. The session manager processing includes a proxy session manager (PSM) 904 and a core session manager (CSM) 1002. The communication processing includes SS7 message processor (SS7MsgHdlr) 902a-n and IP message processing (IPMsgHdlr) 906a-n. As the name implies, the session manager includes logic for managing and processing call sessions, while the message processor includes logic for processing messages. The message processor encapsulates the logic of message processing so that other software does not need to know the details of message processing. Similarly, the session manager encapsulates the logic of call processing so that other software such as the message processor does not need to know the session state or the like.

SS7MsgHdlr and IPMsgHdlr are responsible for receiving incoming messages and sending out messages. The former receives and sends signaling messages to the MSC 110 and/or BS 107. The latter SS7MsgHdlr and IPMsgHdlr receive and send control messages to the data plane. The PSM process 904 handles all calls or conversations that "flow through", or calls that are not siphoned. The CSM process 1002 processes all calls or conversations siphoned by the proxy switch 300. In this way, the CSM process 1002 provides many functions similar to the circuit MSC and the BS, so that it responds to messages from the BS like an MSC, and responds to messages from an MS like a BS. Generally, there are multiple PSM and CSM processes running on different processor cards at the same time to provide the necessary scalability and performance. Additional software processing provides failover and reliability. It is called PSM'904' and CSM'1002' in the figure. The purpose of these basic processes is to provide failover for other PSMs and CSMs. In one embodiment, each PSM and CSM has "image" PSM/CSM provides "image" coverage. In the case of PSM or CSM processing failure, the corresponding image PSM/CSM processing is designed to take over the failed processing.

Referring to Figure 9, when signaling messages arrive from BSC and MSC, they are processed by SS7MsgHdlr902a-n and executed on the SS7 processing card. There is an SS7MsgHdlr associated with each signaling link from or to the proxy switch. The SS7 processing card (as described above) extracts enough information from the signaling message to identify the corresponding SS7MsgHdlr to which the signaling message is to be transmitted.

SS7MsgHdlr receives the message and assigns (preferably) a unique logical reference number for this message. This reference number is later used to identify subsequent messages belonging to the same ongoing call/session. The assigned logical reference number returns the communication to the software system running on the BS or MSC. (E.g. SCCP protocol stack), the software then uses the reference number on all subsequent messages belonging to this call/session.

After the above processing, SS7MsgHdlr 902 selects PSM 904 to process the message. In one embodiment, SS7MsgHdlr checks the point code of the originating source of the message and selects the PSM related to this code. For example, a table can be used to store such relationships.

PSM 904 then decides whether this message is for the call/conversation to be siphoned. In one embodiment, this decision is made by checking the service option field contained in the message that distinguishes the data session from the voice call. In another embodiment, this decision is made by checking the calling and called party numbers to confirm whether both are mobile phone numbers. In another embodiment, this decision is made by checking the caller's phone to determine whether the caller chooses a VoIP service provider. Once it has decided to siphon the call/session, PSM 904 sends a message to CSM 1002. If it is decided not to siphon the call/session, the PSM generates a message to be sent back to the MSC or BS through SS7MsgHdlr processing.

The PSM process 904 may also communicate with the CSM process 1002 through the Internet protocol, see, for example, FIG. 10. The internal protocol of the preferred embodiment is stateless and text-based. As mentioned above, PSM handles non-siphonable conversations/calls. Once it encounters a siphonable session/call, it passes that session/call environment to the CSM for processing. CSM processing is responsible for handling all siphoned conversations/calls. CSM communicates with the data plane through standard control protocols such as 248H and MGCP (Media Gateway Control Protocol).

The internal structure of PSM and CSM processing is similar. Referring to FIG. 11, the incoming message is received by the network interface module 1102. The network interface module then sends the message to the protocol engine 1104. For example, this engine 1104, in the CDMA embodiment, is responsible for encoding and decoding messages according to the IS-634 protocol. The state machine module 1106 is responsible for processing messages and recording states according to the protocol. For example, under a given protocol, a given message means a transition to the next known state in that protocol. The state machine module 1106 includes logic for recording states and realizing state transitions.

The active directory module 1108 interacts with the external mobility management function of the MSC, and is responsible for acquiring and updating subscriber status and other user/subscriber data. In a traditional MSC, the visitor location register (VLR) is generally located at the same place as the MSC; the VLR includes information (conditions) of users currently roaming within the coverage area of the MSC. Additionally, the MSC is connected to another database, called a home location register (HLR), which contains all users "home" in the current network. Generally, when a user roams and enters an area covered by the MSC, the MSC requires the HLR to send the user information and store it in the (local) VLR. When the user roams out of the area covered by the MSC (into the area covered by another MSC), the user situation is deleted. The Active Directory module in the proxy switch acts as a client of the HLR database. It requests from HLR to roam into the user situation in the area covered by the proxy switch, and updates the local database, that is, the action behavior of the active directory module and the device-related database. Like the traditional VLR for roaming users.

The media gateway controller (MGC) module 1110 interacts with the data plane 304 of the proxy switch through open control protocols such as H.248 and MGCP. Upon receiving an action request from the IS-634 state machine module 1106, the MGC 1110 sends a message to the data plane 304 in the H.248 or MGCP protocol to perform the required action. In one embodiment, in the so-called TDM-VoIP case, these action messages to the MSC 1110 of the data plane instruct the data plane to receive incoming circuit (TDM) traffic at the ingress port and convert it into RTP/UDP/IP packets And send out from one of the outgoing ports. Therefore, in this embodiment, the incoming circuit traffic is sub-packaged and sent out in the form of packets. This embodiment can be used to receive circuit calls and use them as voice call transmission over IP (VoIP). In another embodiment, in the so-called TDM-VoIP case, the MGC 1110 instructs the data plane 304 to receive incoming circuit (TDM) traffic at the ingress port and send it out from the egress port as a circuit (TDM) traffic exchange. In this case, the incoming circuit traffic is saved as a circuit and switched to the backup circuit network.

Figures 12-14 are used to illustrate the above concepts with simplified structural diagrams. This figure is used to illustrate the interactive actions of different software processes in response to signaling messages. The carrier circuit is not included in some figures due to simplification. Moreover, for reasons of simplification, only a single interaction example of PSM and CSM processing is shown.

FIG. 12 is used to illustrate the control flow of the initial new call message from the BS 107 to the MSC 110, and also illustrates "through call". Passing through calls is that the proxy switch 300 is not responsible for call management and the calls are passed through for calls processed by the MSC 110. The proxy switch 300 is transparent to the purpose of the call (it may change the point code, for example, to handle the remapping of MSCs explained in Figure 3B). The BS 107 sends 1205 a service request (such as CSR) to the desired MSC 110. The service request includes a service option field indicating whether this is a request for a voice call or a data call. The proxy switch receives this message (because it is on the signaling path between the BSC and MSC); in particular, SS7MsgHdlr processes 902 to receive the call and assigns the unique local reference number for this message (this is the initial message of the potential call request ), and route 1210 to PSM 904 for further processing. The PSM process 904 decodes the incoming message and uses the IS-634 state machine (for the CDMA embodiment) to determine whether the call is siphoned (for example, to the backup network) and allowed by the MSC 110 processing. Since the call is not siphoned in this example, the message is encoded and sent back to 1215 to SS7MsgHdlr for processing 902. In one embodiment, the communication protocol between the SS7MsgHdlr and the PSM process is a stateful text-based protocol, providing an abstraction layer (related to the session logic) of the basic signaling protocol. The SS7MsgHdlr process 902 then resends 1220 the IS-634 message to the MSC 110. The MSC processes the message and answers 1225. The response is received by the proxy switch 300 but since the response is related to an ongoing non-siphonic call (determined by the local reference number assigned to the initial CSR request message as explained above), the SS7MsgHdlr process 902 does not forward the message To PSM904. On the contrary, SS7MsgHdlr transparently continues to forward this message 1230 to BS 107. All further exchanges related to this call are allowed to pass transparently between the BS and the MSC, except for the call release message at the end of the call. In response to the call release, the proxy switch 300 guarantees to let the call end along with the handling of the local reference number. The call release message can also be sent to the BS 107 through the proxy switch so that the BS can perform the release processing work.

FIG. 13 is used to illustrate the call message originating from the BS 107 to the MSC 110 and is also used to illustrate the proxy trunk, that is, the trunk controlled and allocated by the MSC 110. The BS 107 sends a 1305 service request to the required MSC 110. The proxy switch receives this message and the SS7MsgHdlr process 902 receives the call, assigns a unique local reference number to this message, and routes it 1310 to PSM 904 for further processing. The PSM processing 904 decodes the incoming message and uses the IS-634 state machine (for the CDMA embodiment) to determine whether the call is siphoned (for example, to the backup network) or allowed to be processed by the MSC 110. Since the call is not siphoned in this example, the message is encoded and sent back to 1315 to SS7MsgHdlr for processing 902. The SS7MsgHdlr process 902 then resends the 1320 message to the MSC 110. The MSC 110 answers 132 the call setup request (as described above) by assigning a channel to the call. This channel allocation is received by the proxy switch 300 and transmits 1330 the allocation to the PSM 904. The proxy switch 300 then responds 1335 that it has recorded the allocation 1330. The proxy switch then continues to send a 1340 channel allocation request upwards to the BS 107. All further exchanges related to this call between BSC and MSC are allowed to pass through the proxy switch transparently until the call release message. Call release triggers the release process in the proxy switch.

Figure 14 is used to illustrate the "siphon call" situation. The siphoned call is initiated by the BS 107, intercepted and then redirected to the backup network by the proxy switch. In this example, all signaling is handled by the proxy switch and the trunk that carries user traffic is controlled by the proxy switch. The BS 107 sends a 1405 service request to the MSC 110. The proxy switch receives the message and assigns a unique local reference number to the message, and routes it 1410 to the PSM 904 for further processing. The PSM process 904 decodes the incoming message and uses the IS-634 state machine (for the CDMA embodiment) to determine whether the call is to be siphoned. Since the call is siphoned to the backup network in this example, the PSM sends 1415 this message to the CSM process 1002. The CSM process 1002 now starts to behave like a conventional MSC and issues 1420 a channel allocation for the call, which allocates trunk lines between the BS and the data plane of the proxy switch. The channel allocation then sends 1435 to SS7MsgHdlr. SS7MsgHdlr processes and sends 1430 this channel allocation information to the BS so that the BS can use it for user traffic. The CSM also sends messages to the data plane of the proxy switch (using the H.248 or MGCP protocol as described above) refers to the introduction of receiving incoming user traffic on the allocated channel and importing it to the backup network. As explained above, in one embodiment, the backup network may be an IP network. All further exchanges between BSC and CSM take place until the MSC issues a call release command to cause resource release (release process).

In another embodiment, the software structure may only use a single process instead of two different processes (PSM and CSM) to perform the proxy function. In this embodiment, the PSM process alone determines, as before, whether the call is siphoned away. If this is not a siphon call, then processing is allowed to proceed to the MSC. If it is a siphon call, PSM handles the call itself and sends and receives messages from BS 107 and MSC 110. In other words, the PSM acts like the MSC and BS 107 in this embodiment and handles all signaling related to this. In this way, the PSM process provides many of the same functions as the circuit MSC and the BS 107 in the sense that it responds to messages from the BS 107 like the MSC, and responds to messages from the MS like the BS 107. Generally, multiple PSM processes run on different processor cards at the same time to provide the required scalability and performance. Additional software processing provides failover and reliability. The purpose of these processes is to provide failover for other PSMs. In one embodiment, each PSM has "image" processing to provide "image" coverage. In the case of PSM processing failure, the corresponding image processing is designed to take over the failed processing. All the above embodiments are changed to facilitate the implementation of the transparent switch. However, the functional subset offers more advantages than the state of the art. For example, a switch that is partially visible to the network may still provide many of the advantages discussed above.

In addition, the embodiment is described in part related to the CDMA protocol, but the embodiment may be modified to work with GSM, IS-136, and/or other 2G and 3G protocols.

The trunk connection from the proxy switch to the MSC is optional.

After describing the exemplary embodiments, various modifications of these embodiments that do not deviate from the spirit and scope of the present invention will be apparent to those skilled in the art.