Message Transfer Part (MTP)

The Message Transfer Part (MTP) is part of the Signaling System 7 (SS7) used for communication in Public Switched Telephone Networks. MTP is responsible for reliable, unduplicated and in-sequence transport of SS7 messages between communication partners.

MTP is formally defined primarily in ITU-T recommendations Q.701Q.702Q.703Q.704 and Q.705. Tests for the MTP are specified in theITU-T recommendations Q.781 for MTP2 and in Q.782 for MTP3. These tests are used to validate the correct implementation of the MTP protocol.

Different countries use different variants of the MTP protocols. In North America, the formal standard followed is ANSI T1.111. In Europe, national MTP protocols are based on ETSI EN 300-008-1

The SS7 stack can be separated into four functional levels:

  • Level 1 is the Signalling Data Link Functional Level (Data Link Level).
  • Level 2 is the Signalling Link Functional Level (Link Level).
  • Level 3 is the Signalling Network Functional Level (Network Level).
  • Level 4 is the MTP User and consists of SCCPISUPTUP, or any other MTP User.

Level 1 through Level 3 comprise the MTP, and Level 4 the MTP userMTP Level 3 is sometimes abbreviated MTP3MTP Level 2MTP2. MTP and SCCP are together referred to as the Network Service Part (NSP).

There is no one-to-one mapping of MTP Levels 1 through 3 onto the OSI model. Instead, MTP provides the functionality of layers 12 and part of layer 3 in the OSI model. The part of layer 3 of the OSI model that MTP does not provide, is provided by SCCP or other Level 4 parts (MTP users).

Signalling Data Link Functional Level

MTP Level 1 is described in ITU-T Recommendation Q.702, and provides the Signalling Data Link functional level for narrowband signalling links. For broadband signalling links, ITU-T Recommendation Q.2110 or Q.2111 describe the signalling data link function.

MTP1 represents the physical layer. That is, the layer that is responsible for the connection of SS7 Signaling Points into the transmission network over which they communicate with each other. Primarily, this involves the conversion of messaging into electrical signal and the maintenance of the physical links through which these pass. In this way, it is analogous to the Layer 1 of ISDN or other, perhaps more familiar, protocols.

MTP1 normally uses a timeslot in an E-carrier or T-carrier.

Signalling Link Functional Level

MTP Level 2 is described in ITU-T Recommendation Q.703, and provides the Signalling Link functional level for narrowband signalling links. For broadband signalling links, ITU-T Recommendation Q.2140 and Q.2210 describe the signalling link function referred to as MTP3b. The signalling link functional level may also be provided using the SIGTRAN protocol M2PA described in RFC 4165.

MTP2 provides error detection and sequence checking, and retransmits unacknowledged messages. MTP2 uses packets called signal units to transmit SS7 messages. There are three types of signal units: Fill-in Signal Unit (FISU), Link Status Signal Unit (LSSU), Message Signal Unit (MSU).

Access to the signalling link functional level’s service interface can be provided over SCTP by the SIGTRAN protocol M2UA, described in RFC 3331.

MTP Level 2 is tested using the protocol tester and test specifications described in Q.755Q.755.1Q.780 and Q.781.

Signalling Network Functional Level

MTP Level 3 is described in ITU-T Recommendation Q.704, and provides the Signalling Network functional level for narrowband signalling links and, with only minor modifications described inITU-T Recommendation Q.2210, for broadband signalling links. The functions of MTP Level 3 may also be replaced with the Generic Signalling Transport Service described in ITU-T Recommendation Q.2150.0 as provided by MTP3b (Q.2150.1), SSCOP or SSCOPMCE (Q.2150.2) or SCTP (Q.2150.3). MTP Level 3 functions can also be provided by using the IETFSIGTRAN M3UA protocol, described in RFC 4666, in IPSP mode.

MTP3 provides routing functionality to transport signaling messages through the SS7 network to the requested endpoint. Each network element in the SS7 network has a unique address, thePoint Code (PC). Message routing is performed according to this address. A distinction is made between a Signaling Transfer Point (STP) which only performs MTP message routing functionalities and a Signaling End Point (SEP) which uses MTP to communicate with other SEPs (that is, telecom switches). MTP3 is also responsible for network management; when the availability of MTP2 data links changes, MTP3 establishes alternative links as required and propagates information about route availability through the network.

Access to the signalling network functional level’s service interface (as described in Q.701) can be provided over SCTP by the SIGTRAN protocol M3UA, described in RFC 4666.

MTP Level 3 is tested using the protocol tester and test specifications described in Q.755Q.755.1Q.780 and Q.782.

MTP Users

Level 4 consists of MTP Users. The remaining components of the SS7 stack are all directly, or indirectly, MTP Users. Some examples of parts at Level 4 are SCCPISUP and TUP.[7] The services provided to MTP Level 4 by the MTP (that is, MTP to MTP Users) is described in ITU-T Recommendation Q.701.


Reference :

Signalling Connection Control Part (SCCP) Protocol

The Signalling Connection Control Part (SCCP) is a network layer protocol that provides extended routingflow control, segmentation,connection-orientation, and error correction facilities in Signaling System 7 telecommunications networks. SCCP relies on the services of MTP for basic routing and error detection.

Routing facilities beyond MTP

Although MTP provides routing capabilities based upon the Point Code, SCCP allows routing using a Point Code and Subsystem number or a Global Title.

A Point Code is used to address a particular node on the network, whereas a Subsystem number addresses a specific application available on that node. SCCP employs a process called Global Title Translation to determine Point Codes from Global Titles so as to instruct MTP on where to route messages.

SCCP messages contain parameters which describe the type of addressing used, and how the message should be routed:

  • Address Indicator
    • Routing indicator
      • Route on Global Title
      • Route on Point Code/Subsystem Number
    • Global title indicator
      • No Global Title
      • Global Title includes Translation Type (TT), Numbering Plan Indicator (NPI) and Type of Number (TON)
      • Global Title includes Translation Type only
    • Subsystem indicator
      • Subsystem Number present
      • Subsystem Number not present
    • Point Code indicator
      • Point Code present
      • Point Code not present
  • Global Title
    • Address Indicator Coding
    • Address Indicator coded as national (the Address Indicator is treated as international if not specified)

Protocol classes

SCCP provides 5 classes of protocol to its applications:

  • Class 0: Basic connectionless.
  • Class 1: Sequenced connectionless.
  • Class 2: Basic connection-oriented.
  • Class 3: Flow control connection oriented.
  • Class 4: Error recovery and flow control connection oriented.

The connectionless protocol classes provide the capabilities needed to transfer one Network Service Data Unit (NSDU) in the “data” field of an XUDT, LUDT or UDT message. When one connectionless message is not sufficient to convey the user data contained in one NSDU, a segmenting/reassembly function for protocol classes 0 and 1 is provided. In this case, the SCCP at the originating node or in a relay node provides segmentation of the information into multiple segments prior to transfer in the “data” field of XUDT (or as a network option LUDT) messages. At the destination node, the NSDU is reassembled.

The connection-oriented protocol classes (protocol classes 2 and 3) provide the means to set up signalling connections in order to exchange a number of related NSDUs. The connection-oriented protocol classes also provide a segmenting and reassembling capability. If an NSDU is longer than 255 octets, it is split into multiple segments at the originating node, prior to transfer in the “data” field of DT messages. Each segment is less than or equal to 255 octets. At the destination node, the NSDU is reassembled.[3]

Class 0: Basic connectionless

The SCCP Class 0 protocol class is the most basic of the SCCP protocol classes. Network Service Data Units passed by higher layers to the SCCP in the originating node are delivered by the SCCP to higher layers in the destination node. They are transferred independently of each other. Therefore, they may be delivered to the SCCP user out-of-sequence. Thus, this protocol class corresponds to a pure connectionless network service. As a connectionless protocol, no network connection is established between the sender and the receiver.

Class 1: Sequenced connectionless

SCCP Class 1 builds on the capabilities of Class 0, with the addition of a sequence control parameter in the NSDU which allows the SCCP User to instruct the SCCP that a given stream of messages should be delivered in sequence. Therefore, Protocol Class 1 corresponds to an enhanced connectionless protocol with assurances of in-sequence delivery.

Class 2: Basic connection-oriented

SCCP Class 2 provides the facilities of Class 1, but also allows for an entity to establish a two-way dialog with another entity using SCCP.

Class 3: Flow control connection oriented

Class 3 service builds upon Class 2, but also allows for expedited (urgent) messages to be sent and received, and for errors in sequencing (segment re-assembly) to be detected and for SCCP to restart a connection should this occur.

Reference :

SIP Vs. SS7 Protocol

Signalling System No. 7 (SS7) is a set of telephony signaling protocols which are used to set up most of the world’s public switched telephone network telephone calls. The main purpose is to set up and tear down telephone calls. Other uses include number translation, local number portability, prepaid billing mechanisms, short message service (SMS), and a variety of other mass market services.

It is usually referenced as Signalling System No. 7 or Signalling System #7, or simply abbreviated to SS7. In North America it is often referred to asCCSS7, an abbreviation for Common Channel Signalling System 7. In some European countries, specifically the United Kingdom, it is sometimes called C7 (CCITT number 7) and is also known as number 7 and CCIS7 (Common Channel Interoffice Signaling 7). In Germany it is often called as N7 (Signalisierungssystem Nummer 7).

There is only one international SS7 protocol defined by ITU-T in its Q.700-series recommendations.[1] There are however, many national variants of the SS7 protocols. Most national variants are based on two widely deployed national variants as standardized by ANSI and ETSI, which are in turn based on the international protocol defined by ITU-T. Each national variant has its own unique characteristics. Some national variants with rather striking characteristics are the China (PRC) and Japan (TTC) national variants.

The Internet Engineering Task Force (IETF) has also defined level 2, 3, and 4 protocols that are compatible with SS7:

  • Message Transfer Part (MTP) level 2 (M2UA and M2PA)
  • Message Transfer Part (MTP) level 3 (M3UA)
  • Signalling Connection Control Part (SCCP) (SUA)

but use a Stream Control Transmission Protocol (SCTP) transport mechanism. This suite of protocols is called SIGTRAN.


The Session Initiation Protocol (SIP) allows phone calls and similar communication sessions to be made over the Internet, private data networks, or cellular networks. It defines the messages that are sent between parties (signaling) which govern establishment, termination, and other essential elements of a call (or, more generally, a session, hence the name).

SIP is an IETF-defined signaling protocol and is widely used for controlling communication sessions such as voice and video calls over Internet Protocol (IP). The protocol can be used for creating, modifying and terminating two-party (unicast) or multiparty (multicast) sessions. Sessions may consist of one or several media streams, such as voice or video data.

Other SIP applications include video conferencing, streaming multimedia distribution, instant messagingpresence informationfile transfer and online games[citation needed].

SIP is an application layer protocol designed to be independent of the underlying transport layer; it can run on Transmission Control Protocol (TCP),User Datagram Protocol (UDP), or Stream Control Transmission Protocol (SCTP). It is a text-based protocol, incorporating many elements of theHypertext Transfer Protocol (HTTP) and the Simple Mail Transfer Protocol (SMTP).


Reference :

Session Control Protocol (SCP)

Several heavily used Internet applications such as FTPGOPHER, and HTTP use a protocol model in which every transaction requires a separate TCP connection. Since clients normally issue multiple requests to the same server, this model is quite inefficient, as it incurs all the connection start up costs for every single request.

SCP is a simple protocol which lets a server and client have multiple conversations over a single TCP connection. The protocol is designed to be simple to implement, and is modelled after TCP.


SCP’s main service is dialogue control. This service allows either end of the connection to establish a virtual session over a single transport connection. SCP also allows a sender to indicate message boundaries, and allows a reciever to reject an incoming session.

Design goals

Unconfirmed service without negotiation.
SCP allows data to be sent with the session establishment; the recepient does not confirm successful connection establishment, but may reject unsuccessful attempts. This simplifies the design of the protocol, and removes the latency required for a confirmed operation.
Low overhead
SCP has a fixed overhead of 8 bytes per segment. This overhead is half the size of an IPNG address, and is only incurred once per segment, instead of once per packet.
Simple design
The session protocol should be simple enough to implement for a single application.

Protocol Description

Header Format:

Protocol Operation

Session ID allocation

Each session is allocated a session identifier. Session Identifiers below 1024 are reserved. Session IDs allocated by clients are even; those allocated by servers, odd.

Session establishment

A session is established by setting the SYN bit in the first message sent on that channel.

Graceful release

A session is ended by sending a message with the FIN bit set. Each end of a connection may be closed independently.

Disgraceful release

A session may be terminated by sending a message with the RST bit set. All pending data for that session should be discarded

Message boundaries

A message boundary is marked by sending a message with the PUSH bit set. The boundary is set at the final octet in this message, including that octet.


Reference :

Mobile Network Operators and the Cloud

Olafur Ingthorsson is an IT professional in Reykjavik, Iceland who writes about cloud computing at Cloud Computing Topics

I recently had an interesting discussion with a UK-based consultant about the role of mobile network operators (MNOs) in the cloud and how they would deal with the surging mobile traffic. The discussion also related to data centers, network interconnections and proximity of data.

This article is the first of two about our conversation and is a general description of how I see MNOs currently positioned to the cloud. The second article will be somewhat more technically inclined.

Telecoms are late entering the cloud domain

Companies bring different perspectives to cloud computing, depending on their market, location, jurisdiction, and industry. In addition, the “cloud” has a very open meaning and encompasses a variety of configurations, mainly public, private and hybrid clouds.

Generally it has been said that SMEs and startups are more inclined to go for public cloud services (web servers, storage, etc.), while larger companies move more cautiously and either prefer to establish a private cloud environment or a hybrid context. When it comes to software as a service (SaaS), it‘s clear that companies of all sizes are already moving a lot of services into the cloud, including CRM (Salesforce), email and office applications (Office365, Google Apps, etc). I believe this trend will continue. These services and some others that do not entail sensitive data have been successfully delivered cross-borders and continents, without even enterprise customers necessarily knowing the exact location of data or data centers origin.

When it comes to telecoms and data centers or cloud services, I think they are in a unique but fragile situation. Many telecoms already possess large and distributed data centers that have been used for hosting and colocation services for many years. However, compared to cloud services, these have generally been expensive, closed and slow in service provisioning. Most telecoms are late in entering the cloud ecosystem that already offers agility, self-service, pay-as-you-go and other cloud characteristics. However, there is also difference between geographical markets. For example, U.S. telecom providers like Verizon have been very keen on deploying enterprise-class cloud services, especially though their acquisition of Terremarkearlier this year.

Telecoms still have some important advantages, especially through existing, and often strong, customer relationship, billing expertise and customer services. All these are important for companies wanting to deploy cloud services in one way or another. Having said this, telecoms, through their existing customer relationship, can offer various bundling of cloud and telecom and/or network services making it still more feasible for customers to retain and expand their business with their telecom service provider. Also, industries that are moving cautiously to the cloud, including financial services and the health-sector, may be more likely to trust their current provider that can guarantee network performance and proximity of data.

When it comes to colocation services in particular, I believe these will gradually be replaced with “remote private cloud” services, like those Amazon and Rackspace are already offering. Companies can obtain a reserved infrastructure and extend their local network into a remote data center that can be accessed through secure and managed networks like MPLS via VPN, IPsec or similar. I am not fully aware how far telecoms have gone in offering remote private cloud services, assuming full web-based self-service and immediate access to infrastructure.

Mobile operators and the cloud

I personally do not think that mobile operators (MNOs) will be particularly strong in running data center based cloud applications and services. Their effort will mostly be gocused on the delivery of cloud service. through the core mobile network and the radio network itself.

However, to provide an improved service delivery, they may select to deploy managed network connections to any of the important cloud providers, but not rely totally upon Internet connections. Another issue is to “fetch” content that is being replicated and made accessible near to the end-user. This is already being done in increased manner through Content Delivery Networks like Akamai and Limelight Networks.

MNOs could possibly develop a strong proposition as cloud brokers, delivering selected cloud services and bundling with others services and billing – similar to telecoms perhaps. Although possible, this is not a straightforward approach, especially since the leading smartphone platform makers (Apple, Google) tend to shape the ecosystem according to their own strategy.  MNOs and telecoms are not exactly known for their agility and software prowess, compared to many others.

When it comes to LTE (long term evolution), the mobile network will have the ability to deliver cloud services better and faster with an increased bandwidth capacity of up to 100Mbit/s within each cell – and a pure IP-based traffic all the way to the handset. It should still not be forgotten that the bandwidth is a shared medium, so the service delivery can vary according to the number of users and usage pattern in each cell.

However, as the mobile core and radio network are domains of the MNOs, delivery and service quality can be managed up to a certain degree. Still, latency and congestion will continue to occur, but not necessarily within the mobile network, but perhaps somewhere in the backbone, such as in the Internet.

Backhaul in 4G mobile networks should not necessarily be a limiting factor, as LTE will mostly be restricted to cities and largely populated areas where network capacity and bandwidth are normally in abundance. As for proximity to cloud services, I believe these will increasingly be solved through CDNs as is already happening. Popular content is being replicated or cached to the edges, making it faster to deliver to end-users.

Reference :

The Profit Opportunities of Cloud Computing for Telecom Operators


Rising traffic volumes, falling incomes, the difficulties of managing facility investment and the increasingly complex needs of Business Continuity Planning are all examples of how the environment of Telecom Operators is changing. It is against this backdrop that many Operators have started to address the possibilities of Cloud-based business.
There have been many examples of Operators who have tentatively started free Cloud businesses, but are these really examples of a full Cloud business? Is it even possible to make money from Cloud businesses? These are common questions, and to answer them, Shinya Kukita of NEC replies:

Cloud services combine IT service provisioning capabilities with Network connectivity. A Cloud business has many advantages for Operators because they already possess the necessary tangible assets of IT and network capabilities, plus many relevant intangible assets such as a track record of trusted service, a large local customer base of SME with whom they are regularly in contact. Most importantly, they have the trust of their customers – nearly all customers view Operators as reliable, safe and secure enough to entrust them with valuable data.”

How Should Operators Take Advantage of their Strengths to Build a Profitable Business?

Ken Sugata responds:
“Operators provide telecommunication services, and are established entities in every country in which they operate (as well as being subject to each country’s local regulations). In the early days of Cloud Computing, when the ideal was for services to be globally homogeneous, Operators’ local presence and image were seen as a handicap, but it is now turning out to be quite the opposite. Operators should make their local or regional presence a key part of their Cloud business’ strategy. In particular, they should work together with local software vendors and expand their services from their SME and LME customer base in each market. One key area, as I see it, is for cloud applications to be customized for SMEs that have not heavily invested in IT up to now. These services should not simply be copies of general applications designed for the needs of large enterprises but take into account their business characteristics and conditions.”

Furthermore, a close eye should be kept on the trends in enterprise and Cloud services. For example, for large businesses, cloud-based general clerical software has come full circle but industry verticals, such as healthcare, education, retail and logistics are looking to reduce their investment in traditional IT solutions making them likely prospects as customers.

An Advantage of Cloud business is Synergy.

Cloud business is evolving to be more than just connecting IT resources and services. The next wave will address the specific needs of vertical industries such as healthcare, education, retail and government. This will result in increasing amounts of data being accumulated from outside the cloud, and the growing need to integrate services and processes will require a wider range of sensors and devices to be linked with an Operator’s Cloud.

Increasingly, Machine-to-machine (M2M) communications are coming to the forefront of services focused on vertical industries. This is a prime opportunity for Operators to both start and expand a Cloud business.