In ISUP calls the bearer circuit has to be routed through the switch
(SCP) for call setup and tear down. In other words for each ISUP call
two E1 circuits/legs are needed for the voice to travel from MSC to the
SCP and back to MSC and there to the end subscriber. So instead of
getting routed in the MSC itself, the voice travel to the SCP from MSC
and goes back to MSC.
I heard that there is a concept called ISUP loop back where virtual
circuits are setup between MSC and the SCP and thus number of bearer
channels needed to setup and tear down ISUP calls is significantly
reduced. In other words vioce need not travel through a bearer circuit
from MSC to SCP and back to MSc and then on to the end subscriber. So
the there is a saving of trunk circuits between MSC and SCP.Anybody
know anything more about this technique?
Thanks in advance.
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.
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
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
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 !
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.
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.
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 +
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
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
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 !
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.
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
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
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.) !!!