CAS backhaul - Why backhaul?

[Hluchyj, Mike]

>>> >
>>> > [Mike] Now what about SS7?  I think that early thinking on how SS7
can be used
>>> > 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
processed
>>> > by a processor on the trunk card that supports that DS0 (as though
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