
[Mike] The answer to Carl's question of why does the SS7 GW send the signaling to the MG first instead of directly to the MC is that putting a component of call control in the MG will enhance the scalability of the decomposition. In the current thinking on the decomposition, all of the call control for a (potentially) large number of gateways would be located in the MC running on a general-purpose computing platform. As one adds lines/trunks to the MG or adds MGs to be served by a single MC, the compute power of the MC needs to grow accordingly. There are scalable, general-purpose computing platforms to which one can add processors and memory. But such platforms have limits and can be exceedingly expensive as they scale - particularly where redundancy is required. A better solution is to have some of the processing burden, the purely local component that has little need to communicate with other system elements, reside on the processing engines in the MG. This is a proven architecture for the kind of massive scalability that is required in carrier networks. I think that the call control function can be effectively divided between the MG and MC, so that call control processing (CCP) resides in the MG and call control information (CCI) resides in the MC. In this way, CCP is distributed throughout the MGs (e.g., on each trunk/line card), but the real intelligence on what to do with each call is derived from the CCI that resides in the centralized MC. One possible method that could be used by the CCI to tell the CCP what to do would be to use some type of scripting capability such as that proposed by Ike in draft-elliott-ipdc-media-00.txt. Using an approach like this, the call control script is run on the MG by CCP, but the actual script to be executed is determined by the MC through the CCI (which in turn is based on the services to which the customer has subscribed). Separating call control into CCP and CCI has the important benefit of distributing the call processing burden to achieve scalability. Still, the knowledge of subscribers, services and what to do with each call remains in the MC for ease of administration and control. The call processing flow then proceeds along these lines: ------- | CCI | MC ---|--- | | -----------------------|--------------------- | | | MG | CCP | | / \ | | / \ | --|->Ingress Signaling Egress Signaling--|--> | | ---------------------------------------------| 1) The ingress call signaling function (residing in MG for CAS and ISDN trunks/lines or on an external SS7 GW for SS7-based trunks) provides call indication and call parameters to the CCP in the MG. The call parameters, such as calling number, called number, trunk group of incoming call, carrier selection, etc., are obtained from the configured ingress signaling function. 2) CCP in the MG sends a request to the MC containing the call parameters for this call. 3) The MC determines the CCI for the call, including the script that the CCP should execute and, for simple (e.g., tandem) calls, the route (next GW or trunk group) that the call should follow. This is returned by the MC to the MG in its response to the request. 4) The CCP in the MG executes the script provided by CCI and, if the call is exiting the MG, invokes the egress signaling function associated with the selected outgoing path. In this way the signaling and CCP functions have a tight and well- defined relationship. The MC and MG have a simple request-response relationship. The MG contains no configured customer, services or call routing information, only the configuration of its links and other internal resources. All knowledge of what to do with a call is contained in the CCI residing in the MC and returned to the MG CCP in the form of scripts. New services are introduced by creating new scripts. There is no need to proportionally increase the size of the MC as the network grows. The MG takes on the burden of call processing. The MC is largely a database function that is easily replicated for redundancy and load sharing. A close parallel to this can be found in the evolution of carrier class circuit switching where the advent of microprocessor technology allowed more of the required call processing to be cost-effectively distributed first to remote switch modules and then to the individual line and trunk cards. Mike Hluchyj Sonus Networks
participants (1)
-
Hluchyj, Mike