ISUP loop back technique question

Shan, You are describing a Service Node (SN) configuration possibly for a prepaid implementation. If I understand your description you are essentially hairpinning a call through a SN to exercise mid-call control (a pre-IN solution).
ISUP loop-around is a mechanism where ISUP signalling is still performed to a Virtual Signaling Switch Point (VSSP) and the bearer circuits are looped back in the MSC (T1a to T1b).
Note- My examples are with T1's looped, I'm not sure that a E1 can be looped as easily, needs some investigation.
Call Scenario: For example purposes, T1a and T1b are looped. T1a is assigned CIC's 1-24 and T1b is assigned CIC's 25-48. The VSSP (or SN) must have the knowledge that CIC 1 is physically connected to CIC 25, CIC 2 to CIC 26 and so on.
Via MSC processing a call is identified as needing special processing and routed to the trunk group with CIC's assigned to T1a (CIC 1). The IAM is sent to the VSSP (MSC has no idea this is anything other than another SSP). If the call is authorizated (usually communication to the SN/SCP) the VSSP initiates a new call into the MSC on the mated (looped trunk circuit, T1b-CIC 25). At this point in time the MSC thinks there is a call to the VSSP (outgoing on CIC 1) and another call from the VSSP to some destination (incoming on CIC 25). In reality, there is a call from the originator through the loop-around and connected to the destination of the second call.
The initial call leg from MSC to VSSP (via CIC 1) is up for the duration of the call, the second call leg can be established/terminated at will to one destination (say an IVR for announcement) and then another call established/terminated (say for desired subscriber or PSTN connection) without affecting the initial call leg.
In summary, ISUP loop-around will allow savings of facilities (T1/E1) from MSC to SN (what you called SCP in your note) but, the ports required at the MSC will not change. Any IVR trunk groups will also not be saved (if there are any). You also need a network element containing Virutal Signaling Point logic for call control.
I am aware of a couple of companies providing VSSP's, one the most popular is Telesoft, in UK. (Just an example I'm not a salesman, there are others).
So in a rather wordy fashion, yes- ISUP loop-around can provide facility savings but it is not a trivial undertaking (not like in-band loop-arounds of years past).
I am not aware of any coherent write-ups on this kind of implementation anywhere in the public domain, hope this helps its difficult to fully explain ISUP loop-around in 100 words or less !
Good Luck,
Larry Gassman

Larry, Thank you very much for your explanation. I searched the web for some information regarding the ISUP loop back. Except for some sketchy details, i didnt get any useful information. I came across a document in my company detailing about the concept but it didnt explain about what is involoved in implemeting ISUP loop back. Since bearer channels are costly, i was thinking in these lines. Agreed that i should have mentioned SN instead of SCP.
Thanks Again. Shan

No. SCPs are signaling endpoints only, and even then only for TCAP messaging. Did you mean SSP?

I meant ServiceNode (a prepaid billing system) which has some SCP features also. Shan

Hi All, I have another question. In Larry's response he described the ISUP bearer channels hairpinning into the SN as pre-IN solution. If it is pre IN solution, what is the modern method for controlling ISUP calls? Thanks in advance. Regards Shan

Shan, Calls between switches are controlled via ISUP irrespective of pre/post IN. By implementing an IN solution what changes is the ability to remotely (via the SCP) exercise call control. As Thor noted traditionally SCP's communicate via TCAP messaging. I am "ASSUMING" we are talking a wireless prepaid implementation (if not most of the following is not on point).
Your current implementation requires the MSC to route the call to the SN whereby the call can be controlled (authorization, pre/post call announcments, mid-call tones, etc). This places the SN in the call path for the entire duration of the call (announcement times + conversation time).
An IN implementation suspends the call (via triggering) at the MSC and exchanges messages with the SCP, allowing "remote call control" without actually routing the call to the SCP (SN). Wireless Intelligent Networking (WIN) is used IS-41 nets and Customized Applications for Mobile Enhanced Logic (CAMEL) is used for GSM nets.
If I remember your original point it was regarding savings on T1/E1 bearer facilities. In an IN solution calls are only connected to an Intelligent Peripheral (IP) for the duration of announcements. If a subscriber does not wish to have any pre/post call announcements then there is no traffic to the IP consequently less bearer facility required. Additionally, pre/post call announcements average 5-15 seconds (at least thats my experience) while total call duration average 2-4 minutes. Having to engineer trunk groups with hold times of 15 seconds vs 240 seconds again results in far fewer bearer facilities.
If you require detailed information on prepaid call processing refer to IS-826 (for ANSI). This spec gives call flows for both SN and SCP/IP configurations. I am not aware of a like spec defining CAMEL procedures for prepaid charging.
I don't know where you are in the food chain (carrier, service provider, MVNE/O) but there are multiple ways to support prepaid including ISUP loop-around, SIM toolkit, IN, Hot-Billing, USSD (call-back). All approaches have their pro's/con's depending on your needs.
One note of caution, if you go down the IN road you must ensure the MSC you are using supports the necessary version (ANSI-41D or CAMEL V2) and you understand how your particular vendor prices those features. It is not unusual for vendors to price triggers per sub per year, this recurring expense can destroy a marginal business case !

snipped-for-privacy@rek.tjls.com Thanks LCG, I am working for a prepaid solution vendor, and we are looking at reducing the cost of out current offering. We analysed and found that the switch which houses the signalling, IVR and voice bearer circuits is costly and wanted to do way with or reduce the bearer channels so that the price of our offering comes down. Thanks again for your help. Cheers Shan

snipped-for-privacy@rek.tjls.com You might look into use of Release Line Trunk (RLT), I believe originally developed by Nortel and now supported by quite a few MSC vendors. Briefly, allows the SCP to bridge in and tear-down voice paths. It is used as a mechanism to reduce T1/E1 bearer needs for Call Centers/IVR's.
If you thought ISUP loop-around info was hard to find....RLT is an even bigger "secret" ! Might try googling or searching the Nortel web site for RLT spec (I haven't seen one in years don't know the current version).
I do have a client using RLT for a RingBack Tone platform implementation and have to call/beg/borrow/steal information on RLT as I can find it, so if you happen to get your mitts on a spec......its not to early to give me a Chritmas present ! For that matter if anyone out there has access to a current (or for that matter older) version of the RLT spec, I'm a big believer in single-malt and cigars (if you're anywhere in Northern Va.) !!!
good luck,

snipped-for-privacy@rek.tjls.com I sure will, if find the spec :)