TCAP

The following topics provide an overview of TCAP and how it is used to provide enhanced network services:

• Generic service interface
• Role of TCAP in call control
• TCAP within the SS7 protocol stack
• Transaction and component sublayers

Generic Service Interface

TCAP is designed to be generic to accommodate the needs of a wide variety of different services. Some common services that use TCAP include number translation services, such as Enhanced 800 Service and Local Number Portability (LNP). Other examples of TCAP users are Custom Local Area Signaling Services (CLASS), Mobile Wireless, and Advanced Intelligent Network (AIN) services. Figure below shows how TCAP uses standardized components as the basic building blocks for services across network nodes.

Figure: Standardized Components Used to Create a Generic Interface

Most TCAP services can be viewed as a dialogue of questions and answers. A switch needs additional information that is associated with call processing, or with a particular service that causes it to send a TCAP query that requests the needed information. As shown in Figure below, the answer returns in a TCAP response, which provides the necessary information, and normal call processing or feature processing can resume. The query for information can be sent to a Service Control Point (SCP) or to another SSP, depending on the type of service and the information required. The SCP is an SS7-capable database that provides a centralized point of information retrieval. It typically handles number translation services, such as toll-free and LPN; however, SCPs are also used for a number of additional IN/AIN services.

Figure: Simple Query and Response

Role of TCAP in Call Control

TCAP is used to provide information to SSPs. This information is often used to enable successful call completion, but TCAP is not involved in the actual call-setup procedures. This interaction between the service information provided by TCAP and the circuit-related protocol that performs the call setup occurs at the application level, not at the SS7 protocol layer.

TCAP Within the SS7 Protocol Stack

As shown in Figure below, TCAP is at level 4 of the SS7 protocol stack. It depends upon the SCCP's transport services because TCAP itself does not contain any transport information. First, SCCP must establish communication between services before TCAP data can be delivered to the application layer. Refer to Chapter 9, "Signaling Connection Control Part (SCCP)," for more information on SCCP's transport services. TCAP interfaces to the application layer protocols above it, such as the ITU Intelligent Network Application Part (INAP), ANSI AIN, and ANSI-41 Mobile Switching to provide service-related information in a generic format. The application layer that passes information down to be encapsulated within TCAP is known as a Transaction Capability User (TC-User). The terms application, service, and TC-User are used interchangeably.

Figure: TCAP Within the SS7 Stack

SS7

SS7 is a signaling network and protocol that is used to bring telecommunications networks to life. Calls, roaming and messaging, and converged voice/data services, call Waiting, are few of the vast number of services that SS7 is used in the communications network.

There are many combinations of protocol stacks. It depends on whether SS7 is used for cellular-specific services or intelligent network services, whether transportation is over IP or is controlling broadband ATM networks instead of time-division multiplexing (TDM) networks, and so forth. SS7 stack is comprised of following protocols.

• Message Transfer Parts (MTP 1, 2, and 3)
• Signaling Connection Control Part (SCCP)
• Transaction Capabilities Application Part (TCAP)
• Telephony User Part (TUP)
• ISDN User Part (ISUP)

ss7 Stack

MTP

This comprises the functions to transport information from one Service Point to another. The MTP transfers the signaling message, in the correct sequence, without loss or duplication, between the Service Points that make up the SS7 network.

MTP3

MTP3 performs two functions:

• Signaling Message Handling (SMH)— Delivers incoming messages to their intended User Part and routes outgoing messages toward their destination.

• Signaling Network Management (SNM)— Monitors linksets and route sets, providing status to network nodes so that traffic can be rerouted when necessary.

TUP and ISUP

TUP and ISUP sit on top of MTP to provide circuit-related signaling to set up, maintain, and tear down calls.

SCCP

The addition of the SCCP provides a more flexible means of routing and provides mechanisms to transfer data over the SS7 network. Such additional features are used to support noncircuit-related signaling, which is mostly used to interact with databases (SCPs).

Enhanced routing is called global title (GT) routing. It keeps SPs from having overly large routing tables that would be difficult to provision and maintain.

TCAP

TCAP allows applications to communicate with each other (over the SS7 network) using agreed-upon data elements. These data elements are called components. Components can be viewed as instructions sent between applications.

Sigtran Stack

The SIGTRAN Stacks implements the full power of SS7 Application Programming Interface's (API's) allowing unlimited user applications to seamlessly communicate between the legacy and Next Generation Networks (NGN). It provides a client signaling stack in an IP-based Next Generation Network element that enables it to communicate over IP network using SIGTRAN defined architecture.

With the SIGTRAN stack, consumers are free to choose from several of the defined SIGTRAN protocol layers. Each layer has its own unique characteristics that make it applicable to a given situation.

For each, the SS7 stack is substituted at one of its well-defined layers with a packet transport replacement. By moving up to higher layers higher in the stack, more of the legacy SS7 concepts can be eliminated and replaced with flexible packet and IP protocol routing capabilities. Because SIGTRAN is an industry standard, it allows customers to interoperate in a multi-vendor environment.

The key components in the SIGTRAN achitecture are as follows:

• MGC–Media Gateway Controller, responsible for mediating call control (between the SG and MG) and controlling access from the IP world to/from the PSTN.
• SG–Signaling Gateway, responsible for interfacing to the SS7 network and passing signaling messages to the IP nodes.
• MG–Media Gateway, responsible for packetization of voice traffic and transmitting the traffic towards the destination.
• IP SCP – an IP-enabled Service Control Point (SCP). This exists wholly within the IP network, but is addressable from the SS7 network.
• IP Phone–generically referred to as a “terminal.”

Sigtran Architecture

Sigtran Protocol Stack

USSD Gateway

USSD gateway stands for Unstructured Supplementary Service Data Gateway which is simply a router, which routes USSD messages from the signaling network to service applications and back. It's also identified as a signalling node which has it's own internal point code as well as own global title.

USSD is a session based protocol used by GSM cellular telephones to communicate with the service provider's computers

USSD uses Signaling channels to transmit bi-directional data between the mobile and the application defined by the operator

USSD messages are used for many things such as

• Notifying
• WAP browsing
• Providing menus
• Activating a mobile service
• Configuring a subscriber quickly and directly
• Location based content services

The network architecture of the USSD Gateway is as follows

There are many advanages of USSD services when compared to the sibling service SMS

• Innovative solution - Menu based
• Immediate push and pull service
• Ease of use for the subscriber
• Easy to validate to the operator
• Longer message length then SMS
• Easy extension possibility
• Can be used by 99.99% of the mobiles which exist for today
• Does not require any modifications to the SIM

In USSD services there are short cuts as well. Rather than accessing a service using for an exampe *500#, and then browsing through the menu, someone may be able to access the ultimate service intended to use directly by, *500*3*2*86568855487*9700*123#. This is another advantage of USSD services where a knowledged user would be capable of performing the task faster.

For USSD implementations, there are two ways possible. That is via SS7 technology or using Sigtran. The pros and cons differ in each case

SS7

Advantages:

• The bandwidth is guaranteed ensuring optimal quality of service
• All operator equipment is reputed to be MTP (standard) compatible

Disadvantages:

• The platform must be hosted near the operator's equipment (STP or HLR)
• SS7 cards expensive to buy
• The bandwidth is limited to a few dozen COC of 64Kb/s

Sigtran

Advantages

• Flexibility and the possibility of having the Gateway away from the operator's site, directly with the Service Provider via a secure VPN network.
• No costly cards
• The platform can be hosted on a site far from the operator's equipment
• The bandwidth is no longer limited but can reach hundreds of Mbit/s
• Items may be connected in stars and not point to point, allowing direct virtual connection and eliminating certain limitations of network items.
• A multinational operator may see their various national networks as a large scale intranet and pool their network equipment.
• The redundancy of the equipment is transparent, several pieces of equipment may have the same address and share the load invisibly for the transmitter.
• Just one SCTP packet can contain several messages ? less routing cost

Disadvantages

• The bandwidth is not as guaranteed
• All equipment is not yet compatible with Sigtran
• Troubleshooting is more complex - IP path and by the number of messages in a frame

Commonly used techniques for User Interface Design

Many technology improvements rely upon the User Interface just to make sure that everything that the technology could offer is visible through the User Interface. Any superior technology will not be applied unless it is used with the practical context, that is via a UI. The key acceptance feature is the UI which gives it a valuable position in software engineering life cycle. For greatest efficiency and cost effectiveness, this working relationship should be maintained from the start of a project to its rollout. Following are set of features in which develpers make common mistakes.

1. Interface Elements on demand

This feature is basically reduce number of buttons or options user can see on the screen. Same options can be provided to user only when it is needed. This will ensures the neatness of the system and well structred.

2. Specialized, required content

Interface should be designed in such a way that, the best, most approprite element for the moment is used. Basically for an "on", "off" switch there is no point of providing with boolen True/False value. Calendar would be useless unless a calendar can be popped up.

3. Disabling pressed buttons

This is another common mistake where users can go wrong. Simply the idea is, user should be aware about the current condigion.

4. Shadow around model windows

Highlighting model windown would give the oppertunity of highlighting the window from the background with the feeling that it's a seperate screen for the viewers who used the interface.

5. Empty states leading your way

It is to writing erasable text inside empty states, text boxes in order to improve the awareness of the user about the content of the system. E.g.: Facebook "What's on your mind"

6. Hyperlinks

It is always adviced to keep the hyperlinks as it is since it might come in very handy when it comes to furthur reference.

7. Space for extendability

One of the most common problem that the developers are facing when it comes to the UI issues is that change of requirements would end up in a place where they will have to work everything from the begining. To avoid this problem, space should be kept for extendability and furthur changes.

Avove mentioned techniques are only some from a whole lot and there are many more things to be considered in User Interface design especially including the user acceptance testing part because that would be the ultimate place where it would be checked.

SMS Elements

Short message service comprised of seven elements which helps Service Center in receiving and sending Short messages in accordance with the standards. These are common set of standards agreed by the mobile phone manufacturers and the same set of standards are used by the Service centers as well. Any equipment other than a mobile phone such as a GSM modem should adhear to these standards if they want to send SMS.

Following is a list of those elements

Validity-Period;

Service-Centre-Time-Stamp;

Protocol-Identifier;

More-Messages-to-Send;

Priority;

Messages-Waiting;

Alert-SC

Validity period

Validity period is the element which is decided by the Short Messaging entity and inserted in the SMS-SUBMIT which is to be sent to the Short Message Service Center (SMSC). This value let SMSC decide how long the message should be kept on retrying to send to the intended receipient if not delivered. If SMSC has a default validiy period less than the value specified by the SME, then the parameter "Tp-Validity-Period" is overwritten to avoid the infinity waiting of message in SC.

Service center time stamp

Time stamp is the service element which is inserted by the SMSC in the SMS-Deliver message which is sent to the receipient. It gives an idea to the receiver the arrival time of the message to the SMSC. The parameter "TP-Service-Centre-Time-Stamp"should also be adjusted in accordance with the receivers time zone difference and a count which is of 15 minutes intervals is used for this.

E.g. GTA +5.30= 330 minutes, 330/15=22, so GTA +5.30 is indicated by the code 22.

Protocol identifier

Protocol identifier is the element in which the protocol used by a higher layer is identified at transfer layer. It includes in all of the following message types. SMS-SUBMIT, SMS-SUBMIT-REPORT for RP-ACK, SMS-DELIVER DELIVER, SMS-DELIVER-REPORT for RP-ACK, SMS_STATUS_REPORT and SMS-COMMAND TP-Protocol-Identifier (TP-PID).

More messages to send

This is the parmeter used in SMS-DELIVER to indicate the Mobile Station by the Service Center that there are more messages waiting in the SC to be sent to the MS. TP-More-Messages-to-Send (TP-MMS) is the paramer name and this is a boolen value which indicates the true/ false situation of the more messages are there or not. If not --> 0 and if yes --> 1.

Priority

Priority is the paramer entered by the Sc or the MS to indicate the priority of delivering the message. A message is not attempted continuously to send if it is not an priority SM. If a non priority SM doesn't get delivered due to the absense of the mobile station, it is informed to the HLR asking to notify SC once the MS become available. But for priority SMs it is being continuously attempted to send the message by the SC itself.

Message waiting

In the above explined delvery procedure of non priority messages, HLR neeeded to be informed that there is a message waiting in the SMSC to be sent to a particular reciepient. The service element used for this task is Messages-Waiting-Indication (MWI) and it comprises of Messages-Waiting-Data (MWD), the Mobile-station-Not-Reachable-for-GPRS (MNRG), the Mobile-Station-Not-Reachable-Flag (MNRF), the Mobile-Not-Reachable-Reason (MNRR) and the Mobile-Station-Memory-Capacity-Exceeded-Flag (MCEF) located in the HLR; the Mobile-station-Not Reachable-for-

GPRS (MNRG) located in the SGSN, and the Mobile-Station-Not-Reachable-Flag (MNRF) located in the VLR.

Alert SC

Alert SC is the element used by HLR to inform SC that the availability of the mobkile stations which were unavailble before due to:

1. Delivery attempt has failed because the MS is not reachable or because the MS memory capacity was exceeded; and

2. Not recognized by the PLMN:

a) to have resumed operation (e.g. to have responded to a paging request); or

b) to have memory newly available (which implies that the mobile is reachable).

DRBD - Distributed Replicated Block Device

DRBD stands for Distributed Replicated Block Device which actually means nothing shared but replicated in simple terms. Block devices may be hard disks, partitions or logical drives. DRBD is a part of the Lisog open source stack initiative which is an German not for profit organization which was found to each other.

DRBD is a distributed storage system for GNU/Linux platform and it is consist of

• Kernal module
• User space management applications
• Shell scripts

Normally DRBD is used in high availability clusters and very much similar to RAID1 set up, except that DRBD runs over a network.

Raid 1 has following features

• Creates an exact copy or mirror of a set of data on two or more disks
• Good when read performance and reliability are more important than data storage capacity
• Really good for reliability. E.g. Two idential disks drive with 5% probability that a disk would fail then the the total probability of system failing is (0.05)^2 = 0.0025, that is 0.25%.

What DRBD does
Mirroring
Works on the top of the block device, i.e hard disk partitions or virtual machines logical volumes
Mirror each and every data block wirtten to a disk
DRBD mirrors data

• In real time - Continuous replication
• Transparently - With applications knowing that data are stored more then one computer
• Synchronously or asynchronously
• Synchronous - Writing would be completed after all the replications are completed
• Asynchronous - Writing would be completed once the local data store is updated, but before the peers are updated

Data Accessability
File accessability in the file system

Feature list

• May be used to add redundancy to existing deployments
• Fully synchronous, memory synchronous or asynchronous modes of operation
• Masking of local IO errors
• Shared secret to authenticate the peer upon connect
• Bandwidth of background resynchronization tunable
• Automatic recovery after node, network, or disk failures
• Efficient resynchronization, only blocks that were modified during the outage of a node.
• Short resynchronization time after the crash of an active node, independent of the device size.
• Automatic detection of the most up-to-date data after complete failure
• Integration scripts for use with Heartbeat
• Dual primary support for use with GFS/OCFS2
• Configurable handler scripts for various DRBD events
• Online data verification
• Optional data digests to verify the data transfer over the network
• Integration scripts for use with Xen
• Usable on LVM's logical volumes. Usable as physical volume for LVM
• Integration scripts for LVM to automatically take a snapshot before a node becomes the target of a resynchronization
• Dependencies to serialize resynchronization, in case of default all devices in parallel
• Heartbeat integration to outdate peers with broken replication links, avoids switchovers to stale data
• Many tuning parameters allow to optimize DRBD for specific machines, networking hardware, and storage subsystem
• Integration scripts for use with RedHat Cluster
• Existing file systems can be integrated into new DRBD setups without the need of copying
• Support for a third, off-site node for disaster recovery
• Support for compression of the bitmap exchange
• Support for floating peers in drbdadm
• Feature complete OCF Heartbeat/Pacemeker resource agent
• Resource level fencing script, using Pacemaker's constraints
• Supports TCP/IP over Ethernet, SuperSockets over Dolphin NICs and SDP over Infiniband

SMS Email Inter-working

SMS to email and email to SMS conversion is a popular concept which is available as for the current condition. This was first developed as an application which is built on top of the SMSC. Any text message or email is sent to the application and application handled the logic thereafter.

But as with the increasing trend of use of this service it has come to a level where this service is included in the SMSC itself rather than using it in a seperate application. Including the service in the SMSC will provide some advantages rather than having it as an application. The time spent on

To start connection between SMSC and applicaiton

The connection handling, authorizing procedures

Complex acknowledgement processes

can be eliminated by integrating the service inside the SMSC.

There are some basic things that should be taken care in the process of providing a successful service.

1. Basic format

There should be basic format where users using this service must adhear to in order to perform successful conversion between sms and electronic mail. There would be two seperate formats for MO flow and MT flow

E.g.

MO - ]

MT - ]

In the above examples MO represents the text to email conversion whereas in MT it represents the email to text conversion

Some features like Carbon Copy wont be supported in this formats since it would restrict the capacity of the messages

Subject, real name of the sender, optional control flags and message concatenations would be treated as optional features.

Unlike in usual emails, name should be entered manually by the user.

]#[##]#

Subject of the email also should be inserted according to the format like in following examples

]() or ]###

Optinal controller flags are also available to use the features like email signatures, predefined texts etc. The important thing to remember is all the optional controller flags are pre defined and would depend on the email service provider.

TP-Message-Refernce

The TP-Message-Reference field gives an integer representation of a reference number of the SMS-SUBMIT or SMS-COMMAND submitted to the SC by the MS. The MS increments TP-Message-Reference by 1 for each SMS-SUBMIT or SMS-COMMAND being submitted. The value to be used for each SMS-SUBMIT is obtained by reading the Last-Used-TP-MR value from the SMS Status data field in the SIM card and incrementing this value by 1. After each SMS-SUBMIT has been submitted to the network, the Last-Used-TP-MR value in the SIM is updated with the TP-MR that was used in the SMS-SUBMIT operation. The reference number may possess values in the range 0 to 255. The value in the TP-MR assigned by the MS is the same value which is received at the SC.

In the case where no response or an RP-ERROR with an appropriate cause value is received in response to an SMS-SUBMIT, then the MS shall automatically repeat the SMS-SUBMIT but must use the same -MR value and set the TP-RD bit to 1. The number of times the MS automatically repeats the SMS-SUBMIT shall be in the range 1 to 3 but the precise number is an implementation matter. The automatic repeat mechanism should be capable of being disabled through MMI.

If all automatic attempts fail, the user shall be informed. The failed message shall be stored in the mobile in such a way that the user can request a retransmission using the same

TP-MR value, without the need to re-enter any information. Such storage need only be provided for a single failed message, i.e. the one most recently attempted.

The SC should discard an SMS-SUBMIT which has the TP-RD bit set to a 1 and which has the same TP-MR value as the previous SMS-SUBMIT received from the same originating address. In the case of a discarded SMS-SUBMIT, the SC should respond with an RP-ERROR, in which case the RP-ERROR shall include a SMS-SUBMIT-REPORT with TP-FCS indicating “SM Rejected – Duplicate SM”. In some cases, for backward compatibility with earlier phases and versions of this specification, the SC may be configured to respond with an RP-ACK.

The SMS-STATUS-REPORT also contains a TP-Message-Reference field. The value sent to the MS shall be the same as the TP-Message-Reference value generated by the MS in the earlier SMS-SUBMIT or SMS-COMMAND to which the status report relates.