<<

. 112
( 132 .)



>>

AMR_SID
APM
RRC/RANAP Direct Transfer
CODEC: AMR_12.2
ALERTING
NAS Synchronisation
Indicator=2


Figure 8.27 CODEC negotiation
548 IP TELEPHONY FOR UMTS RELEASE 4


without any loss of service. BICC was designed from the ground up to be fully compatible
with ISUP, allowing for simpler migration from a GSM circuit switched core to an IP
or ATM core network. 3GPP recommendations for the use of BICC are based on ITU-T
recommendations but de¬ne a number of extensions. In particular, 3GPP de¬nes its own
set of UMTS bearer control procedures (TS29.232), with appropriate extensions for mobile
data calls, control of user-part protocols and tandem-free operation.




8.9 SIGTRAN PROTOCOL

Signalling transfer (sigtran) is documented by the IETF under RFC 2719. It de¬nes an
architecture for transporting signalling packets over an IP network rather than a switched
circuit network (SCN). It is designed to support current signalling messages, such as those
used in SS7, transparently. In UMTS R4 networks with an IP core, sigtran can be used
to transport BICC messages across the core network between MSC servers. In fact, for
R4 three options for SS7 transport are speci¬ed as possible in 29.202: conventional MTP,
AAL5/ATM and sigtran. In UMTS R5 and beyond as the network moves to an All-IP
architecture, sigtran is used as transport for all SS7 messages.
SS7 over IP is an alternative to SS7 call control (as is SIP) whereby the SS7 messages
are carried over IP rather than the traditional message transport. The transport for SS7
has traditionally been handled by a three-layer protocol stack called the message transfer
part (MTP). MTP is composed of three layers: MTP-1, equivalent to the OSI physical
layer, MTP-2 for datalink control and ¬nally MTP-3, which performs the function of
the OSI network layer. Since many data networks have already been built which support
IP, the possibility of using these networks to carry voice traf¬c with SS7 signalling
becomes attractive. To provide the transport mechanism, two extra layers are required,
the MTP3 user adaptation layer (M3UA) and the stream control transmission protocol
(SCTP; RFC 2960). These adaptation layers will offer services to support the SCCP which
is currently used within the SS7 stack over MTP3. The SCCP should be unaware that the
underlying transport network is IP and not MTP. It is assumed that these two layers will
be carried over an existing IP network. As discussed in Section 3.7, telecommunications
networks are designed to offer very reliable signalling and have a great deal of redundancy
built in. To carry this signalling over an IP network reliably also requires that the IP
network is a well-engineered network and has redundant links and redundant signalling
points throughout.



8.9.1 MTP3 user adaptation layer (M3UA)

This protocol (RFC 3332) allows an SS7 application server residing on an IP network
(e.g. MSC server, HLR, etc.) to communicate with entities residing on an SS7 network.
As well as this, M3UA allows SS7 messages to be passed point-to-point between SS7
servers on the IP network. This use of M3UA is illustrated in Figure 8.28.
8.9 SIGTRAN PROTOCOL 549


HLR
MAP
SCCP
M3UA
SCTP ISUP/
ISUP ISUP
MAP
IP
SCCP SCCP SCCP
IP SS7
M3UA M3UA M3UA MTP3 MTP3
network network
SCTP SCTP SCTP MTP2 MTP2
IP IP IP MTP1 MTP1
MSC GMSC Signalling
SSP
server server gateway

Figure 8.28 M3UA service


Version Reserved Message class Message type
(8 bits) = 1 (8 bits) (8 bits) (8 bits)

Message length


Figure 8.29 M3UA common header

Messages generated at signalling end points on the SS7 network (e.g. IAM for call
setup) are forwarded via the signalling gateway using the M3UA service to SS7 application
servers residing on the IP network (e.g. HLR, GMSC server, etc). The M3UA layer also
allows the IP servers to send SS7 messages directly to each other.
Figure 8.29 shows the common header used for all M3UA packets. The current version
number is 1. M3UA messages are split into six different classes (all other message class
values are currently reserved). Within each class the 8-bit type ¬eld distinguishes between
different messages. The length ¬eld indicates the length of the whole message in bytes
including the common header.
The M3UA message classes are de¬ned as follows:

• Management messages (class 0): used to signal M3UA error conditions and other
M3UA events between M3UA peers.
• Transfer messages (class 1): used to move SS7 payload between M3UA peers. Only
one message type de¬ned, payload data.
• SS7 signalling network management (SSNM) messages (class 2): used to indicate the
status of the SS7 network. For example, the destination unavailable message indicates
that a message could not be routed to an SS7 end point.
• ASP state maintenance (ASPSM) messages (class 3): indicate the service status of appli-
cation servers, for example the HLR or an MSC. Example messages for this class are
ASP Up to indicate a server has come online, and ASP Down to indicate an ASP is
currently out of service.
550 IP TELEPHONY FOR UMTS RELEASE 4


• ASP traf¬c maintenance (ASPTM) messages (Class 4): indicates the routing status for
various ASPs on the network. For example, the ASP active message indicates to a
remote M3UA peer that it is ready to process signalling traf¬c for a particular appli-
cation server.
• Routing key management (RKM) messages (Class 9): allows routing key binding to be
managed remotely. For example, an ASP which has been allocated a given destination
point code (DPC) can then register this point code with the local signalling gateway
using the registration request message


8.9.1.1 Message routing with M3UA
The addressing schemes used in IP and SS7 are quite different (SS7 uses a three-level
address called a point code instead of IP addresses). The M3UA provides routing for
SS7 messages across the IP network. Messages in M3UA are forwarded depending on a
routing key, which consists of one or more of a number of parameters. Here are some
examples:

• a DPC
• originating point code (OPC)
• SCCP subsystem number (SSN; de¬nes which SS7 database to access), also used in
UMTS to distinguish RANAP and RNSAP.

So, for example, a routing key could be de¬ned based on DPC, DPC and OPC, or
DPC and SSN. None of these examples is mandatory and the choice of routing key use
is implementation dependent.
When the message is passed from the higher layers down to the M3UA layer, the
routing key is examined against the entries in the message distribution table (similar to
an IP routing table). If a routing key is found, the message will be forwarded to the
associated IP address found in the table. It is possible for the destination of a routing key
to resolve to a number of servers, which is used in the case of load sharing or backup. The
M3UA layer in this case may forward the messages on a load-sharing basis (e.g. round
robin scheduling), or may use one of the servers as the main server, with the second
acting as backup.
If the routing key is not found, M3UA can be con¬gured to forward the message to a
default address. In the above example the servers on the IP network could be con¬gured
with a default route to the signalling gateway for all unknown routing keys.
The entries in the message distribution table can be con¬gured statically by a manage-
ment interface at the server or signalling gateway, or dynamically using M3UA routing
key registration messages. The M3UA routing key registration procedure works as fol-
lows. The M3UA entity at the application server sends a routing key registration key
request to the M3UA peer (usually residing at the signalling gateway) indicating which
routing key to use for this server. The routing key must contain a DPC but can also
contain other keying information as described before. The M3UA peer will reply with a
registration response indicating success or failure for the registration.
8.9 SIGTRAN PROTOCOL 551


In summary, M3UA will provides the same functionality as the SS7 MTP3 transparently
over an IP network. It can be used to transport any SS7 protocols including BICC, ISUP
and UMTS-speci¬c protocols such as RANAP.


8.9.2 Streaming control transport protocol (SCTP)
As outlined in RFC 2960, the streaming control transport protocol has been designed to
transport PSTN signalling over an IP network. It is a reliable transport protocol which
resides on top of IP and is used by M3UA for transport across the IP network. Like TCP,
SCTP requires a call establishment phase, referred to as handshaking, before transfer of
data can commence. For many years the Internet has relied on TCP (RFC 793) to provide
reliable transfer and UDP (RFC 768) to provide unreliable, unacknowledged transfer of
data. Both of these protocols are lacking in functionality for many new applications such
as transporting SS7 signalling and this is the reason for the introduction of this new
transport protocol.
Although it is essentially designed for transporting PSTN signalling it is possible that
SCTP may be used in many other applications. The word stream is used to refer to a
sequence of messages that are required to be delivered in sequenced order to an applica-
tion. Messages that are not in the same stream do not need to preserve this message order.
While one stream of messages can be blocked, due to the loss of a packet, for example,
another stream can continue to be delivered to the application. In contrast, a TCP stream
is simply a sequence of bytes.
TCP is the standard connection-oriented transport protocol used on the Internet. It
provides reliability, preservation of order, ¬‚ow and congestion control for the data that it
transfers. Data transferred is acknowledged as a byte stream; there is no inherent way for
messages to be acknowledged individually or for the receiver to know where the message
boundaries lie. This is a problem for signalling protocols such as SS7 where each message
needs to be handled individually at the far end.
SCTP acknowledges messages rather than individual bytes, which is useful for passing
messages that can be received out of order as it does not suffer from head of line blocking
associated with TCP. If a single TCP byte is lost, the whole stream is held up while a
retransmission is performed. By acknowledging messages, only the message that has the
lost byte will be held up; other messages can be passed to the application without delay.
As discussed, SS7 networks are extremely reliable, and to maintain this robustness
within an IP network SCTP introduces multi-homing. During the initialization phase,
each of the end points exchanges a list of IP addresses through which the end point can
be reached and also from which SCTP packets may be sent. A primary address is also
chosen, which will be the source address used for normal sending of SCTP packets. This
multi-homing only deals with hosts which have multiple IP addresses and/or multiple
interfaces. These end points must be able to pass the received messages to the SCTP-user
port. Multi-homing in SCTP does not include the use of multiple end points such as
clustering or virtual router redundancy protocol (VRRP), where an end point can switch
over to an alternative end point in the case of a failure of the original end point. As
illustrated in Figure 8.30, a single port number is employed across the entire address list
at an end point for a speci¬c session.
552 IP TELEPHONY FOR UMTS RELEASE 4




Network 1

15.6.4.30 10.1.1.90


Interface 1 Interface 1
SCTP SCTP
87.6.5.10 16.8.1.60
transport transport
service service
Network 2
Interface 2 Interface 2
25.9.3.40 23.4.5.70


Interface 3 Interface 3



Network 3


Network 4




Figure 8.30 SCTP multi-homing

Like TCP, SCTP has a rate adaptive mechanism which will increase or decrease the
data transfer across the network according to the prevailing load conditions. It is also
designed to cooperate with TCP sessions using the same bandwidth.


8.9.2.1 SCTP security
It is well publicized that TCP is relatively vulnerable to denial of service attacks and also
IP is an insecure transport protocol. SCTP introduces a veri¬cation tag which ensures the
sender of a packet is authenticated. A cookie mechanism is also utilized, which helps in
the prevention of denial of service attacks. If strong security and integrity protection are
required it is suggested that IPSec be utilized.



8.10 SUMMARY
In Release 4 of UMTS, the network™s core architecture evolves from the GSM TDM tech-
nology to a packet (or cell) switched core network using IP or ATM. R4 also introduces
the use of the softswitch architecture where call and bearer control are separated. This not
only provides for improved scalability and reliability but also allows for greater support
for the control of multimedia streams through the use of protocols such as MEGACO
and SDP. This evolution of UMTS re¬‚ects some of the trends that are currently prevalent
in the ¬xed-line telecommunications industry, where network operators have for a while
FURTHER READING 553


being looking at softswitches, VoIP and voice over ATM to reduce costs and improve
scalability.
To bridge the gap between the traditional SS7-based call control and the new packet

<<

. 112
( 132 .)



>>