...

...

...

[Mike] Now what about SS7? I think that early thinking on how SS7

...

for providing PSTN interconnection for ISP remote access servers via IMTs led to the current trend of piling lots of signaling and call processing into the MCs. As many others have convincingly argued, it makes much sense to terminate SS7 A and F links on an external signaling gateway (to preserve scare SS7 point codes, to allow one to separate a significant and complex development with many country variations and certification requirements into a separate component, etc.) But an ISUP IAM message signifying an incoming call for a particular CIC (DS0 on a trunk group) can just as easily be

...

by a processor on the trunk card that supports that DS0 (as though

can be used processed the

...

signaling arrived via CAS or ISDN). This then makes it consistent with how CAS and ISDN trunks are served per the above discussion.

[Carl] Yup, makes sence to have SS7 GWs. However I don't think that the signalling should be sent to the MG first before passing it on to the MC (which is what I believe is being suggested here and thus my comment). Why transit the signalling through the MG when the SS7 GW could send the signalling directly to the MC? If "routine processing" is needed then we could have the SS7 GW perform this function prior to communicating with the MC. As for scaleable decomposition, the MC can still make use of the MGs to run scripts associated with individual calls. As of course, the industry can always demand bigger and more powerfull SS7 GWs.

[Nancy] I think the architecture needs to be flexible. Either the SS7 messages can be passed from the SG to the MG so that they become like end-point associated signalling and be treated just as the ISDN signalling is, OR the SS7 messages can go through the MC to the MG. The device control protocol should be able to handle both. If the signalling is associated with the endpoint in the MG, then the MC learns about it as an event notification to the MC from the MG. If the signalling comes directly to the MC from the SG, then it is the MC's job to tell the MG.

[Ike] Actually, the architecture is flexible if we are careful to correctly name the components. In the case where a primary rate interface ISDN line terminates at a MG, and signaling is backhauled to an MC, then by my definition the the device which contains an MG also contains an SG.

Looking at it that way, the example you give above can be restated as "Either the device containing the MG function can also contain an SG function for receipt of SS7 messages which can then be backhauled to an MC, OR the SS7 messages can arrive at an independent device which contains only an SG function, and the SS7 signals can be backhauled directly to an MC."

When you state "The device control protocol should be able to handle both", I'd rather state "the signaling transport protocol should be able to handle both." That is...whether SS7 signals are backhauled from an independent SG, or from a device which combines the functions of the SG and the MG, then the same signaling transport protocol should be employed.

I don't see the reason to use the MGCP event notification mechanism to deliver the equivalent of ISUP messages from an MG to an MC.

Rules of thumb: - If you have signaling in message form already, then backhaul it from the SG function to the MC function (if you have one) using the signaling transport protocol - If you have inband signaling, it is really media events which need to be left to the MC function to interpret. Use MGCP event notifications to deliver it to the MC, and let the MC figure out the meaning in a service context. - Alternatively, if you have inband signaling and know you are unlikely to want to apply alternative meanings to inband signaling, then you have the option of translating the signaling to a message oriented signaling (such as Q.931). When you do that, you've created an SG function on the device, and you should use the signaling transport protocol to backhaul the resulting message oriented signaling protocol to your MC.

Regards, Ike Elliott Level 3 Communications

[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