The transition from circuit based voice telephony network
to pure packet based voice telephony network requires huge
investment. It also requires setting of a parallel packet
voice telephony network components with definition of packet
network signalling protocols and packet network bearer transport
protocols and in addition, support for intelligent services
on packet network.
This paper defines a Packet-SS7 network.
This paper tries to explore the idea of modifying existing
SS7 network protocol and network architecture to support packet
voice services on it. It can also provide an easy transition
path from circuit voice network to pure packet voice network
Today's voice (and other media's as well) communication is
moving away from circuit switch connection to packet connections
for cost benefit, at the expense of voice quality on these
networks. Typical network architecture of voice over packet
network requires interworking function support at the edge
of these two networks. These interworking functions for signalling
and media interworking are supported by Voice over Packet
Gateways. One of the popular Gateways (or technologies) among
many is VoIP (voice over IP Network). During the transition
phase, since the local connectivity to network will remain
on PSTN ingress switches, the network architecture of a typical
gateway cloud on PDN network will look as shown in following
picture
A typical call with above network requires offload of voice
call from Ingress switch-1 to the gateway-1 and then the call
gets routed to gateway-3 using packet signalling(e.g. H.323)
and packet bearer protocols(e.g. RTP/RTCP) through PDN. Getway-3
routes the call back to Egress switch-3 and finally to subscriber.
2.1 Issues With GW Network
There are few issues with above call senario
Routing at GW-1 for call to SUB-B
Address Translation at GW-1.
Control of supplementary and intelligent services.
For all of the above issues there are solutions defined with
these networks,
Routing and address translation decision is taken either
at gateway-1, if it maintains the network routing database
and address translation tables.
Routing and address translation decision is taken by an
entity called Gatekeeper (GK), which holds the routing database
and translation database.
Routing and address translation is done through GW-1 or
through GK cloud by making a query to AIN network (over
SS7 network) entity, called SCP (service control point).
Control of supplementary services and intelligent services
is through GK or through SCP (over SS7 network).
Signalling may be through PDN is directly between GW-1
and GW-2.
Signalling may be controlled by GK cloud.
Above solution requires following entities in the Gateway
network
Gatekeeper Network
Connectivity to AIN network over SS7 or a parallel AIN
network support
Moreover this kind of network requires building parallel
telephony components.
For example
AIN components on PDN.
signalling paths or routes on PDN
signalling protocols on packet network
subscriber database for packet subscribers etc.
However this can be avoided, if we use the existing SS7 network
or PSTN network on SS7, for both packet signalling and packet
bearer communication. We will be discussing the architecture
of such network after we discuss in brief network architecture
SS7 network.
There are three alternatives for packet communication using
SS7 network infra-structure
Use existing SS7 infrastrucure(SS7 switches and other
nodes) for routing, supplementary services, intelligent
network functions. Use SS7 signalling trunks for signalling
and use SS7 bearer trunks for packet communication. Call
this PSA-1 (Packet SS7 Architecture-1).
Use existing SS7 infrastrucure(SS7 switches and other
nodes) for routing, supplementary services, intelligent
network functions. Use SS7 signalling trunks for signalling.
Provide PDN network connectivity to SS7 nodes for bearer
communication. Call this PSA-2 (Packet SS7 Architecture-2).
Mix of above two architectures, with SS7 nodes supporting
both kind of connectivities. Call this PSA-3 (Packet
SS7 Architecture-3).
We will discuss each of these architectures in details in
subsequent sections.
4.1 PSA-1
This architecture supports the services, signalling and packet
voice or bearer communication on the existing SS7 infrastructure.
The modifications required for this support is in following
modules
Call Control Function
Enhancement of ISUP protocol
Support for packet protocol on circuit connection.
Firmware to support media transcoding.
The architecture first will be discussed in view of interaction
between two adjacent SS7 switches and then will be further
extended to the network.
Figure 3 SS7 Voice Network
The above configuration contains two switches connected by
signalling trunks directly connecting these two switches and
also through an alternate-signalling path. N-voice circuits
connect these two switches, which directly maps to N-cics
between these two switches. However these N-circuits may have
few digital circuits on E1/T1s, few on satellite or may be
few on low speed links etc. So a typical call establishment
between these two switches requires selection of a CIC based
on the bearer channel requirement. Now consider another configuration
Figure 4 Packet SS7 Network Architecture-1
This configuration has divided N-voice circuits to two groups,
first group contains N-X voice circuits and the other group
contains X packet circiuts.
Packet circuits are the same digital voice circuits between
two switches but supports packet communication. To support
packet communication on these digital circuits, the two switches
connecting these circuits run HDLC protocol on these circuits.
The HDLC protocol however is not run on individual circuit
but on a group of circuit bundled together to make a packet-circuit
group. This grouping depends on the physical grouping of these
circuits, for example all circuits on an E1 trunk makes one
packet group.
5.1 Configuration of packet circuits
The two switches connecting these packet circuits needs to
assign cics for them. The number of CICs assigned can be more
than the number of circuits in these packet groups. A typical
configuration may assign cics in the range of 8-10 times the
number of physical circuits. This assignment is based on the
assumption that packet circuits can support more calls than
their physical number, for following reasons
Compressed voice on these circuits
Silence suppression results in less bandwidth requirements.
Replaying last received compensates lost voice packets.
5.2 Voice transport on packet circuits
Transport of voice on these packet circuit uses the mechanism
recommended for H.323 networks. The transport uses Real-Time
Transport Protocol (RTP) and Real-Time Transport Control Protocol
(RTCP). As the requirement from these protocol requires an
un-reliable lower layer transport channel, which in most of
the network is provided by UDP/IP protocol in the network.
The confguration suggested above does not require any routing
of packets at lower layer, since the connectivity is point
to point and the identification of call in RTP session will
be done by small ss7-packet header. So a typical RTP packet
will look like
HDLC HDR
SS7-PAC
HDR
RTP HDR
RTP
PAYLOAD
HDLC TRL
HDLC and RTP HDR are the standard headers, but SS7 header
will look like as shown in following picture (it is like a
routing label in SS7 message with CIC added).
OPC
DPC
CIC
5.3 Call Establishment on packet circuit
When two exchanges comes up they block all the packet circuits
till HDLC communication is established on them. After HDLC
channel is established, the circuits are unblocked and are
available to call control for allocation. At any time if the
HDLC communication goes away or channel is diconnected the
affected CICs are blocked by both the exchanges.
5.4 Support for H.245 signalling
Before RTP channel communication a typical packet network
signalling requires capabilities exchange between two nodes
to establish the characterstics of the voice communication
supported, for example the type of voice coding used, jitter
buffer parameters etc. This can be achieved by either assuming
a static configuration of these capabilities at both the
switches during the CICs initialisation or exchange of this
information during call establishment, i.e. the forward direction
capabilities parameters are send with IAM message by introducing
another parameter in IAM message
PARAMETER NAME= ISUP_FORW_CAPABILITY_SET
PARAMETER_LEN = X Bytes
PARAMETER CONTENTS as specified
in H.245 (ASN encoded)
Moreover to indicate that capability exchange is required
before call establishment, Nature_Of_Connection_Indicator
parameter in IAM is modified as
8
7
6
5
4
3
2
1
H
G
F
E
D
C
B
A
Bit F : Capability Exchange Required
Capability Exchange Not Required
Capability Exchange Required
If capability exchange is required the originating exchange
will wait for backward message which is defined as
A typical call establishment between two exchange will require
following steps
Exch-1 based on the subscriber profile and bearer channel
requirements from the access side will decide whether to
use packet circuits or voice circuits.
If there is no packet circuit available then Exch-1 can
select a voice circuit for the call.
Assume Exch-1 selects packet circuit.
Exch-1 selects a packet CIC.
Exch-1 based on the cic configuration decides to exchange
the capability set for the call.
Exch-1 generates an IAM with following parameter parameters
TMR (Transmission Medium Requirements): Voice Packet
Circuit
NOCI (Nature of Connection Indicator): Capability Exchange
Required
ISUP_FORW_CAP: Forward capability set
Exch-2 on deciding capability set generated message BCE
back to Exch-1
Both the exchanges set the RTP and RTCP protocol for this
cic.
After these message exchange, the call establishment is
like a normal ISUP call establishment.
After the complete call path is established RTP packets
are exchanged between these two exchanges for voice or bearer
communication.
RTCP is used to control the RTP sessions. It can also
be used to control the quality of service for RTP sessions.
If RTCP reports more packet loss, congestion and delays,
then either exchange can block few of the CICs to reduce
further traffic between them.
PSA-1 architecture discussed above involves only two exchanges.
The following configuration is assumed in the network for
packet communication across network.
Figure 5 Extension to PSA-1
The difference between this configuration and previous configuration
is that , a call establishment in this case requires signalling
information exchange between Exch-1, Exch-2 and Exch-3. Further
there will be two RTP sessions involved, one between Exch-1
and Exch-2 and other between Exch-2 and Exch-3. In addition
to all the fucntions as required for previous configuration,
this configuration requires RTP relay function at Exch-2.
RTP relay function requires terminating RTP protocol at one
end and relaying or switching RTP packets to other side. As
discussed earlier RTP exchange between two Exchanges carries
an SS7-PAC-HDR which contains routing label information. So
at the time of RTP session establishment on both sides RTP
relay function needs to maintain the routing label mapping
for both sides and during data transfer phase can use this
map table to switch RTP packets. RTP relaying requires changing
SS7-PAC-HDR and optionally requires changing RTP header.
Most of the media processing (echo cancellation etc.) related
functions can be done at the originating exhange or at terminatig
exchange, but they may optionally be done at realy nodes as
well. However few of these functions may be done at all nodes,
for example jitter management, packet loss compensation.
8.1 PSA-2
This network architecture uses existing SS7 infrastrucure(SS7
switches and other nodes) for routing, supplementary services,
intelligent network functions. It uses SS7 signalling trunks
for signalling. However it uses PDN network connectivity to
SS7 nodes for bearer packet communication.
Figure 6 Packet SS7 Architecture-2
In first of these configuration each of the switch is connected
PDN network for packet voice connectivity, which carries the
complete RTP/RTCP session on UDP/IP network. The CIC configuration
for this connectivity may use a different OPC/DPC combination,
other than OPC/DPC pairs for voice circuits or it may use
the same OPC/DPC pair. The number of CICs configured may depend
on the kind of network connectivity and bandwidth available.
This configuration supports a packet structure similar to
the one described earlier.
IP
UDP
SS7-PAC-HDR
RTP HDR
RTP Payload
This RTP communication however does not require establishment
of HDLC channel between two exchanges. RTCP in this configuration
can still be used for congestion control to block circuits
in case of high packet loss and congestion in the network.
This configuration still requires all the support as described
in PSA-1 for ISUP (TMR modification, NOCI modification, BEC
message support, Forward and Backward capability parameters).
8.2 A typical call establishment
A typical call establishment between two exchange will require
following steps
Exch-1 based on the subscriber profile and bearer channel
requirements from the access side will decide whether to
use packet circuits or voice circuits.
If there is no packet circuit available then Exch-1 can
select a voice circuit for the call.
Assume Exch-1 selects packet circuit.
Exch-1 selects a packet CIC.
Exch-1 based on the cic configuration decides to exchange
the capability set for the call.
Exch-1 generates an IAM with following parameter parameters
TMR (Transmission Medium Requirements): Voice Packet Circuit
NOCI (Nature of Connection Indicator): Capability Exchange
Required
SUP_FORW_CAP: Forward capability set
Exch-2 on deciding capability set generated message BCE
back to Exch-1. Capability exchange between two exchange
equires exchange of UDP ports for RTP/RTCP sessions.
Both the exchanges set the RTP and RTCP protocol for this
cic.
After these message exchange, the call establishment is
like a normal ISUP call establishment.
After the complete call path is established RTP packets
are exchanged between these two exchanges for voice or bearer
communication.
RTCP is used to control the RTP sessions. It can also
be used to control the quality of service for RTP sessions.
If RTCP reports more packet loss, congestion and delays,
then either Exch-2 can block few of the CICs to reduce further
traffic between them.
8.3 Modification to above configuration
Above configuration can be modified to support long PDN connectivity
as shown in following picture.
Figure 7 Modified PSA-2
In this configuration Switch-1 and Switch-3 are adjancent
switches for packet CICs and can have direct signalling and
packet bearer establishment. Rest of the procedures for call
establishment and bearer communication are similar to as defined
with previous configuration.
8.4 PSA-3
Architecture PSA-3 is combination of above two architecture
with signalling and packet bearer communication supported
as required for each of them.
Figure 8 Packet SS7 Architecture-3
This configuration supports packet circuit connections between
two switches directly and also through PDN.
Packet-SS7 architecture may provide a transition solution
from circuit network telephony to pure packet network telephony.
With the number of circuits X (packet voice circuits) increasing
with each telephony switch to finally N (total voice circuits),
ciruit switches can be converted to packet switches. Moreover
the architecture PSA-3 or PSA-2 may provide a smooth transition
from circuit telephony to packet telephony transition with
voice switches replaced by packet switches supporting packet
signalling protocols and packet bearer protocols.
