The present invention relates to mobile communication networks. In particular, and not by way of limitation, the present invention is directed to a system and method for achieving interoperability between telecommunication servers in a mobile communication network by automatically distributing capability and configuration information between the servers.
In existing mobile communication networks, interoperability between telecommunication servers such as Mobile Switching Centers (MSCs) is achieved through several procedures. First, each MSC stores/administers the capabilities of neighboring/reachable MSCs in the network. Second, each MSC transmits to receiving MSCs, all of the information needed for the features supported by the transmitting MSC. This includes information for features that are not supported by the receiving MSC. Third, newly introduced features are designed in such a way that backwards compatibility is not hampered.
There are several disadvantages of the existing procedures. Regarding network administration, the existing procedure of administering the capabilities of neighboring/reachable MSCs within each MSC utilizes a large amount of system resources. This is undesirable to network operators who must provide these resources even though the resources are not producing revenue. In addition, the procedure has a good chance of causing system failures due to human errors such as typing mistakes. For example, if an operator owns 50 MSCs in his network, and every MSC must contain capabilities information for all the other MSCs, then changing the configuration of a single MSC requires updating the 49 other MSCs with this new information.
The existing procedures also cause problems relating to bandwidth and processing capacity. Transmitting nodes currently transmit all of the information needed for the features supported by the transmitting MSC, even for features that are not supported by the receiving MSC. This is a waste of network bandwidth and processing capacity at both the transmitting and the receiving MSCs. For example, at inter-MSC handover, the anchor MSC sends BSSMAP/Radio Access Network Application Part (RANAP) Service Handover information to the target (i.e., non-anchor) MSC even though the non-anchor MSC may not support this feature. By way of further example, the anchor MSC always includes Shared Network Information (SNA), if available. In cases where the SNA is too large to fit in the BSSMAP Handover Request message, the SNA is sent in an extra BSSMAP Common ID message. These messages are sent even if the non-anchor MSC does not support this feature, or where there is no need for the information (e.g., the non-anchor MSC is not serving a shared area).
The design of newly introduced features in such a way that backwards compatibility is not hampered causes the introduction of inefficient functionality in the network. The Mobile Application Part (MAP) protocol ensures backward compatibility by initiating the MAP dialog between MSCs with the highest version supported by the initiating MSC. If the other MSC does not support this version, a fallback mechanism is utilized to downgrade to an older version of the protocol. In some cases, however, particularly in third generation systems, the proposed solutions for backward compatibility are overly complicated. In the 3rd Generation Partnership Project (3GPP), for example, for the introduction of codec negotiation over the E-interface, a complex solution has been proposed with the introduction of a new information element in order to ensure backward compatibility. The proposed solution also requires changing one of the major design principles in handover.
Another example of inefficient functionality for the sake of backward compatibility, is found in the optional function of Inter-MSC SRNS Relocation for multiple bearers. The anchor MSC first tries the function with all bearers available. If the non-anchor MSC does not support multiple bearers, the non-anchor MSC rejects the first attempt. The anchor MSC then tries again, but with only one bearer selected.
Thus, there is much inefficiency in the existing procedures for achieving interoperability between MSCs in a mobile communication network. It would be advantageous to have a system and method for achieving interoperability by automatically distributing capability and configuration information between MSCs.
The present invention enables interoperability between MSCs by causing each MSC to send operational information such as capability and configuration information to neighboring MSCs following a reconfiguration, reset, or any other procedure that may have changed the capabilities or configuration of the affected MSC. Each neighboring MSC that supports the invention responds by sending its own capability and configuration information to the affected MSC. Thereafter, each MSC uses its knowledge of the capabilities and configuration of neighboring MSCs to send only the information that is needed to implement requested services or features.
Thus, in one aspect, the present invention is directed to a method of automatically distributing operational information between MSCs in a mobile communication network. The method includes the steps of defining for each MSC in the network, at least one neighboring MSC; performing a procedure that changes the first MSC's operational information; and upon completion of the procedure, automatically sending the first MSC's operational information from the first MSC to the first MSC's neighboring MSCs. This is followed by receiving and storing the first MSC's operational information in each of the first MSC's neighboring MSCs; and upon receiving the first MSC's operational information, sending operational information for each of the first MSC's neighboring MSCs from the neighboring MSCs to the first MSC. The operational information may include capability and configuration information.
In another aspect, the present invention is directed to a method of reducing signaling and processing requirements in a mobile communication network having a plurality of neighboring MSCs. The method includes the steps of automatically distributing operational information between the MSC's whenever an operational capability of one of the MSCs is changed; initiating a service in a first MSC; and upon initiating the service in the first MSC, sending to MSCs neighboring the first MSC, only information that the operational information stored in the first MSC indicates is supported by the neighboring MSCs.
In yet another aspect, the present invention is directed to an MSC that automatically distributes operational information for the MSC to neighboring MSCs in a mobile communication network. The MSC includes a communication signaling mechanism that automatically sends the MSC's operational information to at least one neighboring MSC upon start-up of the MSC, and receives in return, operational information for the at least one neighboring MSC. The MSC also includes means for storing the operational information for the at least one neighboring MSC. The operational information may include capability and configuration information. The MSC may also include means for initiating a service; means for determining from the stored capability and configuration information for the at least one neighboring MSC, which information related to the initiated service is supported by the at least one neighboring MSC; and means for sending to the at least one neighboring MSC, only the service-related information that is supported by the at least one neighboring MSC.
In an exemplary scenario, MSC-1 is reconfigured and/or reset. Just before MSC-1 starts operation, MSC-1 sends its capability and configuration information to all of its defined neighboring MSCs. This is illustrated by the outgoing arrows from MSC-1 to MSC-2, MSC-3, MSC-4, and MSC-5. Since MSC-3 and MSC-5 do not support the present invention, they discard the information and continue to operate as before. Since MSC-2 and MSC-4 support the present invention, they store the received information and consider the information during operation. In addition, as shown by the incoming arrows to MSC-1, they send their own capability and configuration information to MSC-1.
Once MSC-1 is reconfigured or switched on at step 21, MSC-1 sends a message such as a Configuration Capabilities Data Request message 22 to neighboring MSC-2. In the exemplary message shown, MSC-1 indicates that it is compliant with the Third Generation Partnership Project (3GPP) release version 5 specification, it supports Shared Network Information (SNA), and it includes codec negotiation functionality. In addition, the message contains an indication of the SNA-information mapping utilized by MSC-1. This mapping enables MSC-1 to use a single value in communication with MSC-2 instead of a large amount of data (for example, the value 1 instead of r1, r2, b2, and b3; or the value 2 instead of r2, r3, b1, and b2).
Once MSC-2 receives the Configuration Capabilities Data Request message 22, MSC-2 stores the included information, and uses the information to make future operations more efficient. For example, MSC-2 will never send Service Handover information to MSC-1 because MSC-2 knows that MSC-1 does not support this information. In this manner, the invention saves both processing and signaling resources. In addition, MSC-2 prepares a response in the form of a Configuration Capabilities Data Response message 23. This message includes capability and configuration information for MSC-2. In the exemplary message shown, MSC-2 indicates that it is compliant with the 3GPP R6 specification, it supports SNA and Service Handover, and it can handle a maximum of four bearers. Upon receipt of the Configuration Capabilities Data Response message, MSC-1 stores the included information, and uses the information to make future operations more efficient.
Other capability and configuration data may also be included in the Configuration Capabilities Data Request message 22 and the Configuration Capabilities Data Response message 23. For example, proprietary information such as vendor identifications and vendor-specific features may also be indicated. Additionally, the messages may indicate exceptions to levels of functionality that are indicated. For example, if MSC-2 is compliant with 3GPP release version 6 except for one feature or capability, MSC-2 may indicate in its message that MSC-2 is compliant with 3GPP release version 6, but not the non-supported feature or capability.
At step 36, MSC-2 starts a service within the mobile communication network that requires the participation of other MSCs. At step 37, MSC-2 determines, from the capability and configuration information that it has stored for other MSCs, whether or not MSC-1 supports the service. At step 38, upon determining that MSC-1 does not support the service, the method moves to step 39 where MSC-2 does not send service-related information to MSC-1. This saves network bandwidth and relieves MSC-1 of the tasks of receiving the service-related information, analyzing the information to determine whether the information is useful, and discarding the information after determining that the information is for a service that MSC-1 does not support. However, upon determining at step 38 that MSC-1 does support the service, the method moves to step 40 where MSC-2 sends the service-related information to MSC-1. Thus, information is only sent from one MSC to another when the receiving MSC supports the service or functionality with which the information is associated.
Although the present invention has been described in detail with reference to only a few exemplary embodiments, those skilled in the art will appreciate that various modifications can be made without departing from the invention. Accordingly, the invention is defined only by the following claims, which are intended to embrace all equivalents thereof.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/IB03/04526 | 10/14/2003 | WO | 4/13/2006 |