Tampere University of Technology
Telecommunications Laboratory
83390 Advanced Topics in Broadband Networks
Interworking SS7 with IP and H.323
Bilhanan Silverajan
Abbreviations
ACM Address Complete Message
ANM Answer Message
ASE Application Service Element
ASP Access Signaling Protocol
COT Continuity Test
DNS Domain Name System
HDLC High level Data Link Control
IAM Initial Address Message
IN Intelligent Network
ISDN Integrated Services Digital Network
ISUP ISDN User Part
MC Media gateway Controller
MG Media Gateway
MGCP Media Gateway Control Protocol
MTP Message Transfer Port
NAS Network Access Server
OAM Operations, Administration and Maintenance
RSGP Reliable Signaling Gateway Protocol
RT Routing Tables
SA Signaling Agent
SCAL Signaling TCP Connection/IP Adaptation Layer
SCCP Signaling Connection Control Part
SCP Service Control Point
SG Signaling Gateway
SS7 Signaling System Number 7
SSP Service Switching Point
STP Signaling Transfer Point
SUAL Signaling UDP/IP Adaptation Layer
TCAP Transaction Capabilities Application Part
VoIP Voice Over IP
1. Introduction
This paper discusses the interworking of SS7 with IP and H.323 to support telephony
traffic in IP networks. A number of SS7 vendors such as Lucent and Nortel also
appear to be developing products that are aimed at such a level of interworking.
Several task forces have been involved in this area, and consequently a number of
draft specifications have been published for consideration and standardisation. Some
of the more notable efforts include the creation of a new protocol for SS7-IP signaling
called Reliable Signaling Gateway Protocol (RSGP) whose rules and messages are
derived from the ITU-T Q.931 developed for call control in ISDN. Bay Networks also
has a proposal for a similar protocol called Access Signaling Protocol (ASP), but as
RSGP includes ASP, this paper will only attempt to discuss RSGP.
Another draft specification discusses the relationships of H.323 and SS7 and
consequently recommends an SS7 gateway residing between the H.323 Gatekeeper
and the SS7 exchange, whose function will be to translate the messages coming from
one side into a format the other can understand.
An adaptation layer which supports the transfer of SS7 messages atop IP while taking
advantage of MTP is also discussed briefly.
An SS7-Internet Interworking Architectural Framework is also described which aims
to unify the various proposals and drafts into an overall model framework that would
provide a frame of reference for future standardisation.
2. Motivation
The biggest motivation for combining the closed environment, circuit switched
networks of SS7 with the more open, packet switched IP world appears to be an
increased market competition and revenue possibility.
Today s telephone networks are largely based on SS7 technology, which apart from
supporting basic customer calls, also provide advanced Intelligent Network services.
Examples of such services include call forwarding, call screening, caller ID and toll-
free numbers. Currently IP telephony with VoIP has no provision for such services. It
would be both expensive and redundant for the Internet task forces to specify and
reimplement such services separately for VoIP, as the IP protocol suite was not
designed to offer these services. By resolving such issues using an interworking
approach, two major advantages can be immediately perceived.
Firstly, apart from the obvious benefit of saving cost and effort, the IP network will
have an increased value to companies carrying voice traffic that can offer advanced
services. This will certainly help in a more rapid adoption of IP as a core public
network and aid in reducing overall costs of investing in legacy telecommunications
infrastructure.
Secondly, companies offering traditional SS7 services will now be able to reach far
wider groups of subscriber bases via interworking and interconnecting with public
internet-based networks. This also creates a higher level of flexibility for SS7 users
who might not have the SS7 protocol stack, but instead rely on IP for transporting
SS7 traffic as well. Other SS7 network nodes will already be on the standard SS7
network and have a full SS7 protocol stack. These can then act as gateways having
dual SS7/IP stacks to open up access to the SS7 nodes on the large installed base of
SS7 networks which have no knowledge of the IP network interconnection.
3. Possible End-to-end SS7 Configurations using IP
At the moment, many parts of the IP-SS7 interworking is yet to be standardised. It is
foreseen that the many existing specification drafts will be unified in the final set of
standards. One of these drafts is the interworking configuration which will allow end
users to speak SS7 via public packet-switched networks like the Internet. This type of
full topology configuration is shown in Figure 1.
SCP SCP
STP STP
IP/SS7 GW
SSP
STP STP
internets
SCP SCP
STP STP
IP/SS7 GW
SSP
STP STP
Figure 1. Full SS7 topology configuration
As the figure shows, the end users are communicating via SS7, so the traffic being
transferred between them is ISUP, SCCP, TCAP and so on. The Signaling Transfer
Points (STPs) offer the full features of MTP-3 such as point code routing and some
level of fault tolerance with failed nodes and links.
A more scaled down approach from Figure 1 is also possible, in which the STPs will
not exist as separate nodes but will instead function with the Service Switching Points
(SSPs) to provide only a simple point-to-point operations, using only addressing
which is provided with IP. This type of configuration is shown in Figure 2.
SCP SCP
SSP SSP
IP/SS7 GW IP/SS7 GW
internets
STP STP
Figure 2. Scaled-down point-to-point configuration
4. The SS7-IP Architectural Framework
With the wide variety of SS7-IP interworking proposals that were put forward, it was
necessary for a unifying framework to be put forth that could provide a reference for
all the ongoing work, components and entities that were being described. As such, the
SS7-IP Architectural Framework was developed to reflect the overall situation. This
framework is shown in Figure 3.
SS7-IP
Gateway/
Telco
SCP
Controller
Telco
Exchanges
networks
RT &
SG
DNS
SS7 links
SSP
STP
MC
internets
POTS
Phones MG
IP Phones
Figure 3. The SS7-IP Architectural Framework
U
s
er
l
i
nk
s
This framework is considerably more complex than the specifications of H.323 as
well as MGCP from the numerous entities it introduces, especially around the SS7-IP
Gateway/Controller. It also introduces several other entities not depicted in Figure 3
that also remain pertinent to the interworking aspect of SS7 with IP and H.323. These
are placed in the Framework because several Internet Drafts propose different
methods of implementing SS7-IP interworking, and the Framework is thus able to
explain each of these alternatives to some level of consistency. Some of the entities
that the Framework introduces are:
" Signaling Gateway (SG):
These receive and send public switched telephone system (PSTS) signals and SS7
messages.
" Media gateway Controller (MC):
This acts as a registration and resource management entity and is therefore similar
to the H.323 Gatekeeper and MGCP Call Agent, but is able to manage resource
usage based on policies as well.
" Media Gateway (MG):
This is the physical interface for PSTN lines and trunks, as well as VoIP links.
" Routing Tables (RT):
The IP routing tables that are accessed with destination IP addresses to route IP
traffic through an internet.
" Domain Name System (DNS):
This is the database storing domain names and associated IP addresses and SS7
point codes.
" Signaling Agent (SA), not shown in Figure 3:
The entity responsible for signaling mediation between MG-MG, MG-SG, SG-
SG.
" Network Access Server (NAS), not shown in Figure 3:
The entity responsible for allocating and deallocating resources, largely on the
packet swtiched network. The NAS therefore has some of the capabilities of the
H.323 gatekeeper and the MGCP Call Agent, and it encompasses both an SG and
MC.
5. Reliable Gateway Signaling Protocol (RSGP)
One of the Internet Drafts which describe the operations of SS7 and IP interworking
involves the introduction a new protocol called the Reliable Gateway Signaling
Protocol (RSGP), which is used for signaling at the SS7-IP gateway. This proposal
uses the Framework as a model, but separates the SG from the NAS as shown in
Figure 7, with RSGP being the protocol used between the SG and the NAS.
Telco
SCP
Exchanges
SS7 links
SSP
SG
STP
internets
NAS
Figure 7. Reliable Signaling Gateway Protocol (RSGP) configuration
The messages exchanged between the SG and the NAS are used to support call
processing, and Operations, Administration and Maintenance (OAM) operations. In
total, 21 messages are used. 13 messages are derived from ITU-T Q.931, used for
ISDN call control, and use this protocol s rules pertaining to the message contents.
The remaining 7 are new RSGP messages.
Figure 8 illustrates the sequence of messages the NAS exchanges with the SG to
register itself with the SG and to provide the interface and port information to the SG.
Initially the NAS sends an NAS STATUS message to the SG to initialize the RSGP
operation. This message contains one of the following types of information:
1. NAS is doing a cold reboot
2. NAS is reestablishing connectivity to the SG with a warm start
3. NAS is in hot shutdown
4. NAS is in soft shutdown, with existing calls completed
The SG then acknowledges with a NAS STATUS ACK message. The NAS then
informs the SG about the types of resources available for use by transmitting the
RESOURCE STATUS message through which it indicates interface information (in
maintenance, down or up) and resource information (number of modems or HDLC-
based logical channels available). This is also acknowledged by the SG with the
RESOURCE STATUS ACK message.
Us
e
r
l
i
nks
NAS SG SS7
NAS STATUS
NAS STATUS
ACK
RESOURCE STATUS
RESOURCE STATUS
ACK
Figure 8. Registration procedures
The NAS can use the RESOURCE STATUS message to register more resources
when more become available. However, at this stage the NAS and SG are ready to
support customer calls. A call setup with continuity check is shown in Figure 9.
NAS SG SS7
IAM
SERVICE
Loopback
SERVICE
ACK
COT
SETUP
CONNECT
Circuit ok
ANM
CONNECT
ACK
Figure 9. Call setup with continuity check
The figure shows the SG receiving an Initial Address Message (IAM) from the SS7
network requesting to set up a circuit and asking for a continuity check. The SG uses
the information from the IAM to form a SERVICE message and sends it to the NAS
with the Change Status field requesting for a continuity check. The NAS then marks
the circuit as busy and places it in loopback mode and replies with the SERVICE
ACK message to the SG. Once the continuity check is successful, the SS7 informs the
SG with a Continuity Test (COT) message, which causes the SG to send a SETUP
message to the NAS. The NAS determines the circuit is operational and the circuit has
been cut to the called party and hence issues a CONNECT message to the SG. This
causes the SG to send an Answer Message (ANM) to the SS7 network. The SG
network may optionally reply with a CONNECT ACK message.
6. Interworking H.323 and SS7
Another scheme for interworking involves H.323 and an SS7 Gateway. This level of
interworking is fairly basic, with the SS7 Gateway performing protocol translation,
correlating between H.323 and ISUP messages. This is shown in Figure 10 which
illustrates a possible scenario with the H.323 initiating call setup. The call setup can
obviously also be made in the opposite direction, in which case the IAM from the SS7
Exchange starts the operations between the H.323 Gatekeeper and the SS7 Gateway.
H.323 Gatekeeper SS7 SignalingGateway SS7 Exchange
H.225 SETUP
IAM
H.225 CALL PROC
ACM
H.225 ALERT
ANM
H.225 CONN
H.445 Operations
Figure 10. Call setup with H.323 protocols and ISUP
It is possible for the SG to initiate H.445 operations immediately after receiving the
H.225 SETUP message as well, which would reduce the delay between the
Gatekeeper and the SG after the ANM is received.
7. Proposal for an adaptation layer
An adaptation layer has also been proposed as an interworking scheme at the MTP-3
level to use IP as a transport layer for SS7 messages. This adaptation layer will
provide an encapsulation/decapsulation function using tunneling, and may be able to
map between MTP-3 point codes and IP addresses. The idea is to implement an IP
transport that will allow nodes without the full SS7 signaling resourcses to provide
ISUP connections that interface with ISUP switches, and to have access to services
that are part of the Intelligent Network. Figure 11 illustrates one possible approach
where the adaptation layer resides below MTP-3 as two sublayers: The Signaling
UDP/IP Adaptation Layer (SUAL), which implements UDP with some additional
enhancements for error checking, proper sequencing and retransmissions, and the
Signaling TCP Connection/IP Adaptation Layer (SCAL) which uses TCP, but is
scaled-down for faster connection services.
ASEs, OAM, IN/AINetc
ISDN User Part
TCAP
(ISUP)
SCCP
MTP-3
SUAL SCAL
UDP/TCP TCP
IP
Figure 11. The IP/SS7 protocol stack
The ideas proposed in this specification are still immature. However, the basic idea is
for the adaptation layer to emulate either MTP-3 or MTP-2.
8. Conclusions
The importance of SS7 interworking with IP and H.323 will inevitably increase with
the rise in usage of VoIP, especially with enterprises seeking a more integrated
approach to their telecomunications needs.
The current standardisation status still seems rather immature with many
specifications still being revised. However the foundational work that this paper has
discussed provides a good starting point which shows the multiple ways in which
such interworking can be accomplished.
9. References
1. Black,Uyless. Voice Over IP. Prentice Hall 2000 ISBN: 0-13-022463-4
2. Greene, Nancy. SS7-Internet Internetworking-Architectural Framework. Draft-
green-ss7-arch-frame-01.txt., 1998
3. Holdrege, Matt. Reliable Signaling Gateway Protocol (RSGP). Draft-ong-rsgp-
ss7-info-00.txt., 1998
4. Ma, Gene. H.323 Signaling and SS7 ISUP Gateway: Procedure Interworking.
Draft-ma-h323-isup-gateway00.txt., 1999
5. McGrew, Michael. Transport SS7 Signaling, Over IP. Draft-mcgrew-tss7s-00.txt.,
1998