Provisioning

In telecommunicationprovisioning is the process of preparing and equipping a network to allow it to provide (new) services to its users. In NS/EP telecommunications services, “provisioning”equates to “initiation” and includes altering the state of an existing priority service or capability.[1]

Network provisioning or service mediation are terms referring to provisioning of the customer’s services to the network elements, mostly used in the telecommunication industry. It requires the existence of networking equipment and depends on network planning and design.

In a modern signal infrastructure employing information technology at all levels, there is no distinction possible between telecommunications services and “higher level” infrastructure. Accordingly, provisioning configures any required systems, provides users with access to data and technology resources, and refers to all enterprise-level information resource management involved.

From a management perspective, it is typically managed by a CIO, and necessarily involves human resources and IT departments cooperating to:

  • give users access to data repositories or grant authorization to systems, network applications and databases based on a unique user identity, and
  • appropriate for their use of hardware resources, such as computers, mobile phones and pagers.

As its most central responsibility, the provisioning process monitors access rights and privileges to ensure the security of an enterprise’s resources and user privacy. As a secondary responsibility, it ensures compliance and minimizes the vulnerability of systems to penetration and abuse. As a tertiary responsibility, it tries to reduce the amount of custom configuration usingboot image control and other methods that radically reduce the number of different configurations involved.

“Provisioning” often appears in the context of virtualizationorchestrationutility computingcloud computing, and open configuration concepts and projects. For instance, the OASIS Provisioning Services Technical Committee (PSTC) defines an XML-based framework for exchanging user, resource, and service provisioning information, e.g. SPML (Service Provisioning Markup Language) for “managing the provisioning and allocation of identity information and system resources within and between organizations”.

Once provisioned, the process of SysOpping ensures that services are maintained to the expected standards. Provisioning thus refers only to the setup or startup part of the service operation, and SysOpping to the ongoing responsibility.

Network provisioning

The services which are assigned to the customer in the customer relationship management (CRM) have to be provisioned on the network element which is enabling the service and allows the customer to actually use the service. The relation between a service configured in the CRM and a service on the network elements is not necessarily a 1:1 relation. Some services can be enabled by more than one network element, e.g. the Microsoft Media Server (mms://) service.

During the provisioning, the service mediation device translates the service and the corresponding parameters of the service to one or more services/parameters on the network elements involved. The algorithm used to translate a system service into network services is called provisioning logic.

Electronic invoice feeds from your carriers can be automatically downloaded directly into the core of the telecom expense management (TEM) software and it will immediately conduct an audit of each single line item charge all the way down to the User Support and Operations Center (USOC) level. The provisioning software will capture each circuit number provided by all of your carriers and if bills outside of the contracted rate an exception rule will trigger a red flag and notify the pre-established staff member to review the billing error.

Server provisioning

Server provisioning is a set of actions to prepare a server with appropriate systems, data and software, and make it ready for network operation. Typical tasks when provisioning a server are: select a server from a pool of available servers, load the appropriate software (operating systemdevice driversmiddleware, and applications), appropriately customize and configure the system and the software to create or change a boot image for this server, and then change its parameters, such as IP addressIP Gateway to find associated network and storage resources (sometimes separated as resource provisioning) to audit the system. By auditing the system, you ensure OVAL compliance with limit vulnerability, ensure compliance, or install patches. After these actions, you restart the system and load the new software. This makes the system ready for operation. Typically an internet service provider (ISP) or Network Operations Center will perform these tasks to a well-defined set of parameters, for example, a boot image that the organization has approved and which uses software it has license to. Many instances of such a boot image create a virtualdedicated host.

There are many software products available to automate the provisioning of servers, services and end-user devices. Examples: HP Server Automation, IBM Tivoli Provisioning Manager, Redhat Kickstart, xCAT, HP Insight CMU, etc. Middleware and applications can be installed either when the operating system is installed or afterwards by using an Application Service Automation tool. Further questions are addressed in academia such as when provisioning should be issued and how many servers are needed in multi-tier,[2] or multi-service applications.[3]

In cloud computing servers may be provisioned via a web user interface or an application programming interface. One of the unique things about cloud computing is how rapidly and easily this can be done. Monitoring software can be used to trigger automatic provisioning when existing resources become too heavily stressed.[4]

In short, server provisioning configures servers based on resource requirements. The use of a hardware or software component (e.g. single/dual processor, RAM, HDD, RAID controller, a number of LAN cards, applications, OS, etc.) depends on the functionality of the server, such as ISP, virtualization, NOS, or voice processing. Server redundancy depends on the availability of servers in the organization. Critical applications have less downtime when using cluster servers, RAID, or a mirroring system.

Service used by most larger scale centers in part to avoid this. Additional resource provisioning may be done per service.[5]

User provisioning

Further information: User provisioning software

User provisioning refers to the creation, maintenance and deactivation of user objects and user attributes, as they exist in one or more systems, directories or applications, in response to automated or interactive business processes. User provisioning software may include one or more of the following processes: change propagation, self-service workflow, consolidated user administration, delegated user administration, and federated change control. User objects may represent employees, contractors, vendors, partners, customers or other recipients of a service. Services may include electronic mail, inclusion in a published user directory, access to a database, access to a network or mainframe, etc. User provisioning is a type of identity managementsoftware, particularly useful within organizations, where users may be represented by multiple objects on multiple systems.

Self-service provisioning for cloud computing services

On-demand self-service is described by the National Institute of Standards and Technology (NIST) as an essential characteristic of Cloud computing.[6] The self-service nature of cloud computing lets end users obtain and remove cloud services―including applications, the infrastructure supporting the applications,[7] and configuration―[8] themselves without requiring the assistance of an IT staff member.[9] Cloud users can obtain cloud services through a cloud service catalog or a self-service portal.[10] Because business users can obtain and configure cloud services themselves, this means IT staff can be more productive and gives them more time to manage cloud infrastructures.[11]

Mobile subscriber provisioning

This refers to the setting up of new services, such as GPRSMMS and Instant Messaging for an existing subscriber of a mobile phone network, and any gateways to standard Internet chat or mailservices. The network operator typically sends these settings to the subscriber’s handset using SMS or WAP as mobile operating systems accept.

A typical example of provisioning is the BlackBerry services. A mobile user who is using voice services wishes to switch to BlackBerry services as his emails and data is very crucial for him to carry, his BlackBerry services are “provisioned” and thus he is able to stay connected through push emails and other features of BlackBerry services.

Device Management players such as Sicap ensures that end-users benefit from plug and play data services, whatever device they are using. Such a platform automatically detects devices in the network and sends them settings for immediate and continued usability. The process is fully automated, keeps history of used devices and sends setting only to subscriber devices which were not previously set. Sicap DMC ( Device Management Centre ) achieves this by filtering IMEI/IMSI pairs. Some operators ( see example from Vimpelcom Group subsidiary Kartel) report DM activity of 50 over-the-air settings update files per second.

Mobile content provisioning

This refers to delivering mobile content, such as mobile internet to a mobile phone, agnostic of the features of said device. These may include operating system type and versions, Java version, browser version, screen form factors, audio capabilities, language settings and a plethora of other characteristics. As of April 2006, an estimated 5000 permutations are relevant. Mobile content provisioning facilitates a common user experience, though delivered on widely different handsets.

Internet access provisioning

When getting a user / customer online, beyond user provisioning and network provisioning, the client system must be configured. This process may includes many steps, depending on the connection technology in question (DSL, Cable, Fibre, etc.). The possible steps are:

  • modem configuration
  • authentication with network
  • install drivers
  • setup Wireless LAN
  • secure operating system (primarily for Windows only)
  • configure browser provider-specifics
  • e-mail provisioning (create mailboxes and aliases)
  • e-mail configuration in client systems
  • install additional support software
  • install add-on packages purchased by the customer
  • etc.

There are four approaches to provisioning an internet access:

  • Hand out manuals. Manuals are a great help for experienced users, but inexperienced users will need to call the support hotline several times until all internet services are accessible. Every unintended change in the configuration, by user mistake or due to a software error, results in additional calls.
  • On-site setup by a technician. Sending a technician on-site is the most reliable approach from the provider’s point of view, as the person ensures that the internet access is working, before leaving the customer’s premises. This advantage comes at high costs – either for the provider or the customer, depending on the business model. Furthermore it is inconvenient for customers, as they have to wait until they get an installation appointment and because they need to take a day off from work. For repairing an internet connection on-site or phone support will be needed again.
  • Server-side remote setup. Server-side modem configuration uses a protocol called TR-069. It is widely established and reliable. At the current stage it can only be used for modem configuration. Protocol extensions are discussed, but not yet practically implemented, particularly because most client devices and applications do not support them yet. All other steps of the provisioning process are left to the user, typically causing lots of rather long calls to the support hotline.
  • Installation CD. Also called a “client-side self-service installation” CD, it can cover the entire process from modem configuration to setting up client applications, including home networking devices. The software typically acts autonomously, i.e. it doesn’t need an online connection and an expensive backend infrastructure. During such an installation process the software usually also install diagnosis and self-repair applications that support customers in case of problems, avoiding costly hotline calls. Such client-side applications also open completely new possibilities for marketing, cross- and up-selling. Such solutions come from highly specialised companies or directly from the provider’s development department.

Reference : http://en.wikipedia.org/wiki/Provisioning

Global Title (GT) Translation

Global Title (GT) is an address used in the SCCP protocol for routing signaling messages on telecommunications networks. In theory, a global title is a unique address which refers to only one destination, though in practice destinations can change over time.

The Global Title is similar in purpose on the PSTN to the host name on the internet. In design, however, global titles are quite different. The structure is usually hierarchical, the value can be of variable length, and is not necessarily a wholly numeric value—though it often is for issues of backwards compatibility and association with regular telephone numbers.

Structure of the global title value

The structure of a global title for ITU-T applications is officially defined in ITU-T Recommendation Q.713, and further extended in the supporting numbering plan standards. Other national variants of Signalling Connection Control Part (SCCP), such as the American National Standards Institute variant specified in ANSI T1.112/2000, define their own format for the Global Title. The value of a global title is a sequence of attributes which modify the address value. To summarize:

Global Title Format

A global title can be in a variety of formats, most of which are each defined in separate standards. The format parameter indicates which of the available formats are in use. Each format can include any of the subsequent parameters.

Numbering Plan Indicator

The Numbering Plan Indicator (NPI) describes which numbering plan will be used for the global title. The numbering plan chosen will aid the routing system in determining the correct network system to direct the message.

Type of Number

The Type of Number (TON) or Nature of Address Indicator (NAI) parameter, which is of relevance to E.164 (regular telephone) numbers for example, indicates the scope of the address value, such as whether it is an international number (i.e. including the country code), a “national” or domestic number (i.e. without country code), and other formats such as “local” format (e.g. in the U.S., without an area code).

Translation Type

The translation type (TT) parameter is used in a network to indicate the preferred method of global title analysis (see below). Normally in European networks, this parameter is set to 0 (the default) value. In North American mobile networks, different translation types are used for analysis of the IMSI and for messages between telephone systems. This parameter is valuable in complex routing problems, where the same number has to be routed differently depending on the circumstances, such as those introduced by number portability resolution.

Global title translation

Global title translation is the SS7 equivalent to IP routing. Translation examines the destination address (e.g. the number being called) and decides how to identify it over the telephone network. This process can include global title analysis, which is the act of looking up the number and finding a result address, and global title modification.

It is possible for the result of Global Title Translation to be Route on SSN. This means that, instead of the Global Title routing, lower level MTP routing will be used for this message from this point on. Equivalently, in a system using SS7 over IP (for example, SIGTRAN), the result from Global Title Translation may be to a route to an IP server, though the exact details depend greatly on which variant of SS7 over IP is being used.[1]

Global Title Analysis

Global Title Analysis together with Global Title Translation. The situation in this case is somewhat complicated by the additional parameters possible in the global title. Each set of parameter values (TT=0 NP=E.164, TON=INT) can be treated separately from each other one (TT=0 NP=E.214, TON=INT). This means that, instead of one single table, we potentially need a separate table for each possible set of values.

The variable length of the global title makes certain optimisations that can be used in IP routing are not so easy to use here. The number analysis of a Global Title is most often done in a tree structure. This allows reasonably efficient analysis to any depth which is chosen.

In the end, global title analysis gives some result. The exact possibilities vary from system to system, is sometimes called an “action” or is integrated into the analysis table.

The destination would typically be given as a signalling point code in an MTP network, but could also be an IP system if we are using SS7 over IP[2]

Routing Structure

The most commonly used numbering plans for global title routing are E.164 and E.214 (although E.212 is also common in America). These simply look like telephone numbers. That is to say, in the most common, international, variant there is a country code at the start of the number and a Network Code immediately following the country code. Beyond that is the subscriber number ormobile subscriber identity number, though even that may be divided into sections. This structure allows for the use of hierarchical routing.

  • international SCCP gateways know which systems handle each of the other countries
  • the international SCCP gateway belonging to each country knows which SCCP gateways handle each network
  • the SCCP gateway of each network knows the networks own internal structure

In America, the limitations of the North American Number Plan mean that the destination country is not immediately obvious from the called party address. However, the fact that there is unified administration means that this can be overcome by having complete analysis at every point where it is needed.

Global Title Modification

In Global Title Translation it is quite normal that at some point the Global Title will have to be changed. This happens, for example, as GSM mobility management messages enter and leave networks in America. In America, typically most routing of mobility management messages for all mobile networks is done using the E.212 (IMSI) number. In international networks, E.214 is always used.

At the boundary incoming toward America (this can mean the Signaling Transfer Point at the edge of the American operator’s network), numbers routed from European networks are converted from E.214 numbers into E.212 numbers. In the outgoing direction, from America toward the rest of the world, are converted from E.212 numbers into E.214 numbers.

Global Title Routing in Mobile Networks

In mobile networks, there are database queries such as “how can I tell if this subscriber is really who he says he is” (MAP_Send_Authentication_Info) which have to be routed back to the database which holds the subscriber’s information (the HLR, or in this case, the AUC).

Unfortunately, at the time the subscriber first arrives, we don’t know which HLR is the subscriber’s HLR. For this reason, the queries have to be routed on the subscriber’s identity (IMSI) is used to generate the called party address in the message. How this is done depends whether we are in world area 1 (North America) or somewhere else.

There are three types of GT in use in mobile networks known as E.164 (MSISDN), E.212(IMSI) and E.214(MGT):[3]

  • E.164(MSISDN) = CC+NDC+SN, e.g. 91-98-71405178
  • E.212(IMSI) = MCC+MNC+MSIN, e.g. 404-68-6600620186 (MTNL delhi)
  • E.214(MGT) = combination of E.212 and E.164 (Exact combination is defined in the operators IR21 document)

Mobile Global Title Routing (Except North America)

Everywhere in the world, except North America, the subscriber’s IMSI is converted to a Mobile Global Title (MGT) E.214 number. See the entry about the IMSI for more details. The E.214 number has a structure which is similar to the E.164 number, and, except in a mobile network it can be routed identically. This means that the same routing tables can be used for both and means considerably reduced administrative overhead in maintaining the tables.

Once a signalling message with an E.214 number enters a mobile network in its own country, the routing is dependent on the operator of that mobile network. In networks without number portability, it is normal that the MSIN has a structure and that, by analysing the first few digits we can further route the message to the right element.

IMSI Routing (North America)

In World Area 1 (corresponding to North America) ANSI SCCP is in use. In this case, due to North American standards, the routing of mobility related messages must be done with the E.212 number directly. This has the advantage that in it is easier to identify to which country messages should be routed based on the mobile country code. The design of the North American Number Plan means that there is not a separate country code for each country in North America. Working with E.214 numbers would not be an insurmountable challenge, as can be seen from the fact that routing of phone calls using E.164 numbers is normal, but it would mean adding full E.164 routing tables to signalling transfer points where it has never been needed before.

That is the simplest way to search the destination.

Routing of mobility messages on the ANSI / ITU Boundary

Where a signalling message travels from North America to the rest of the world or from the rest of the world to North America, there must be a conversion done from E.212 based global title toE.214 based global title. This conversion is reasonably simple, well defined and fully reversible. The conversion is not totally simple since each individual network must be listed.

Recommendation E.214 has been interpreted as suggesting that the analysis of the Mobile Country Code (MCC) and Mobile Network Code (MNC) should be done separately. The relationship between the MNC and the Network Code (NC), however, varies from country to country as does the length of the MNC (two or three digits). This means that the analysis of the MNC is dependent on the analysis of the MCC, or alternatively that the analysis must be done for all five or six digits at once (which is how it is done in practise across at least five separate switch vendors).

Examples

Outbound from America:

Please note the truncation of the number by one digit since E.214 numbers, as with E.164 numbers, have a maximum length of 15 digits.

Inbound toward America:

Reference : http://en.wikipedia.org/wiki/Global_Title_Translation

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 : http://en.wikipedia.org/wiki/Message_Transfer_Part

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 : http://en.wikipedia.org/wiki/Signalling_Connection_Control_Part

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.

AND

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 :
http://en.wikipedia.org/wiki/Signalling_System_No._7
http://en.wikipedia.org/wiki/Session_Initiation_Protocol

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.

Services

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 : http://www.w3.org/Protocols/HTTP-NG/http-ng-scp.html

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 : http://www.datacenterknowledge.com/archives/2011/10/31/mobile-network-operators-and-the-cloud/