Facts about IN and CAMEL

Source: Book - Camel Intelligent Networks for the GSM, GPRS and UMTS Networks by Rogier Noldus

Intelligent networks (IN) is a technique that augments digital telecommunication networks with a method to lift the control over CS calls to a higher-layer control platform. These digital networks, which are based on signalling principles defined by ISUP, may include networks such as the integrated service digital network (ISDN), the public switched telephone network (PSTN) and the PLMN. Applying IN to any of these networks has in common that call establishment is intercepted at a designated node in the network. Control over the call is handed over to a control platform. The control platform determines how the establishment of this call shall continue.

What is CAMEL: Customized Applications for Mobile networks Enhanced Logic

CAMEL Services:

• Calling Name Presentation: The ability to provide the name of the calling party to the called party, allowing the called party to decide how to handle the call (e.g. the subscriber decides either to answer the call or let it go to voice mail). CAMEL is used to query a database that contains name information, which allows for a network-based service rather than programming the GSM phone to recognize caller names.
• Prepay and Account Spending Limit (ASL): Prepay and ASL utilize CAMEL to allow for metering usage on a prepaid basis and post-paid basis respectively. ASL has applications for those markets that are not debit based or credit-challenged but rather want to just manage usage. Markets include parental controls and corporate resource management.
• Incoming Call Management (ICM): CAMEL is leveraged to manage call termination attempts to customize subscriber’s inbound calling experience. The subscriber can decide how inbound calls will be automatically managed. Features include automatic call handling (example: route all calls except boss to voice mail for the next hour) fixed-to-mobile convergence capabilities such as routing to mobile when a fixed network number is called.
• Virtual Private Network (VPN): CAMEL enables a mobile VPN that replicates PBX-like
  dialling in a mobile environment. For example, this (typically) group-based feature allows one to hit the digits “2706” and then SEND to actually place a call to Gerry Christensen at 650-798-2706.
• Call Redirect Services (CRS): CAMEL is utilized to provide a variety of CRS services including redirecting international roamers to their own customer care when they dial “611”
• Location-based Services (LBS): CAMEL has been used in the United States to support FCC
  mandates for wireless emergency calling (e.g. dialling 9-1-1) from a mobile phone. CAMEL
  thus allows for call control, information to be passed to databases, call assistance for routing
  to a Public Safety Answer Point, and for query of LBS infrastructure such as the Gateway
  Mobile Location Center (GMLC) for more precise positioning data based on A-GPS or TDOA. Commercial (non-regulatory) LBS applications are emerging that will rely on CAMEL based directory services and location-based search and information.
  

CAMEL also enables hybrid applications that allow for both voice and data interaction.
CAMEL enables a simple and standard user interface for the end-user to engage in wireless data including SMS, MMS, and WAP.

CAMEL services may also be office-based, which means that any mobile phone user may use
the service, whether in their home system or while roaming, without pre-subscription. CAMEL
application triggering is based on events recognized by the Mobile Switching Center (MSC) rather
than relying on communication and instruction from the HLR/VLR to arm a trigger detection point.

HTTP Interface for SMS - An Introduction

This section is only applicable to lab applications and the test application with a required feature license.
The HTTP interface in the test set provides an industry standard interface for interfacing the base station simulation capability of the test set with necessary external components for verifying SMS capability in a mobile station. The HTTP implementation in the test set also provides SMS routing capability, simulating a simple Short Message Service Center (SMSC).

Introduction to HTTP
HTTP is the client/server based protocol used to deliver virtually all files and data on the World Wide Web. If you'd like a more detailed description of HTTP protocol, refer to Internet RFCs `HTTP/1.0 - RFC 1945' and `HTTP/1.1 - RFC 2616', which can be downloaded from http://www.rfc-editor.org/rfc.php.
When you use HTTP in a web browser, you enter the "address" for the web page you wish to view. These addresses can be generalized into the following format:

In this example, the web browser is the HTTP client and it uses the information in this address to open a connection to an HTTP server and send a request.

"http://" is the protocol specifier, telling the browser what protocol to use for the request.
is the IP address of the server.
is the port number on which to communicate with the server. The default port for HTTP is 80.
provides information to the server on the location of the resource that's being requested and can also be used to provide information to the resource.

HTTP Interface for SMS verification
The test set acts as both a server and a client, depending on which operation it is performing.

The test set as the server:
If you have a PC and your test set connected to a network or directly connected together, you can open a web browser (client) and send a request to the test set using the test set's IP address and a correctly configured request URL. For example, you might send the following from the web browser if your test set's IP address was 111.111.111.112.



NOTE
It is not necessary to specify a port number because the test set uses 80, which is the default port for HTTP.

Sending the URL causes an SMS message to arrive at the mobile station attached to the test set's RF port. This message contains the text "hello".
The test set acts as the server for mobile terminated SMS messages. While this is a simple example, this same information is necessary to configure an SMS Gateway or proprietary software for interfacing with the test set via HTTP.
For configuration information see:

HTTP Interface Configuration for Mobile Terminated SMS .

The test set as the client:
SMS messages originating from the mobile station attached to the test set are sent out the test set's LAN port as HTTP requests to the IP address for the intended receiving entity.
For configuration information see:

HTTP Interface Configuration for Mobile Originated SMS

Related Topics

HTTP Interface Configuration for Mobile Terminated SMS
HTTP Interface Configuration for Mobile Originated SMS
HTTP SMS Router Web-based Configuration Interface

Source: http://wireless.agilent.com/rfcomms/refdocs/gsmgprs/gprsla_gen_bse_sms_http_interface.php

SMSC interface with ESME

SMSC Issues
http://www.nowsms.com/discus/messages/1/247.html

Following discussion shows how SMSC can be integrated with ESME through HTTP as well as SMPP interface.

http://www.telecomspace.com/forum/index.php?topic=851.0

NMS Troubleshooting links

Some important links for NMS Configurations

http://www.dialogic.com/den/forums/p/5509/22253.aspx#22253

SMS versus WAP

SMS is the short messaging service for GSM. It is also present on most other digital cellular networks and tends to operate in a similar fashion on each network. SMS enables 2-way short messages to be sent between GSM subscribers. Using gateways, it is also possible to interchange messages with other systems such as Internet email, the web etc. So, SMS is essentially a messaging transport service to enable reliable 2-way messaging.

WAP on the other hand is a "protocol set" aboard which various services can be delivered. Like any protocol, it states how devices can be made compatible ("speak the same language") in order to exchange information. Since SMS is a means for information to be transported, two devices could use SMS to exchange WAP-compliant data.

As well as being a transport service, SMS also has a protocol. However, as mentioned earlier, the SMS protocol is really only concerned with reliable 2-way messaging and so it is restricted to basic functionality. In protocol terms, this means a very basic command set such as "Send Message" and "Receive Message". Clearly for anything more sophisticated, this protocol is very limited. However, there's nothing to stop another protocol being added on top with more commands that just get sent using the Send and Receive of SMS. This is what WAP does.

So why does WAP do this? Well, to use the mobile phone to converse with any information-delivery system (such as the web or a database), the method of delivery needs to be tailored to the limitations of the phone - mainly the small text-only display, and the restrictive keyboard and navigation keys. So a part of WAP is concerned with sensible data formatting and navigation appropriate to these limitations. However, sending data over mobile air interfaces poses problems with delays and slow links. These can be overcome to an extent by optimizing the way in which the protocol is mapped to the interface (such as the SMS carrier or an ordinary GSM data call). Another part of WAP is concerned with efficient protocol transport.

So is SMS still needed after WAP? The answer is yes. Firstly there are many applications that simply do not need WAP. The simple send and receive primitives of SMS are sufficient. Also, there is often no need, or no context, to maintain an ongoing (connected) communications session over SMS and so SMS tends to get used in a connectionless mode, like sending a letter or an email - whereby immediate, or even any, response is not required (though it may be desirable at times).

Many SMS messages are alerts of one kind or another, used to notify the recipient of an event. These types of messages usually require follow-on action other than sending a reply using SMS. In these circumstances, SMS is sufficient and there is no need to move to WAP.

Secondly, WAP is not widely available yet and there are millions of phones that can handle SMS but not WAP. These will stay in circulation for some time.

WAP is particularly useful for interactive services on the handset. Interactive services can be realized using native SMS, but this is not as elegant as WAP. Using WAP, the user can be prompted for information and guided along the interactivity path, whereas while using only SMS, the user has to remember how to respond with any preset commands.

So, do we need SMS or WAP or both? The answer is both are needed and they have different uses and applications. SMS is particularly good for pushing out information to mobile phone users. In particular, Xsonic InTouch monitors a variety of data sources within the Microsoft Exchange messaging server and pushes out alerts, such as "new email from...", "appointment at..." etc. Xsonic DataNow also generates alerts from any data changes that occur within an SQL Server database.

Alerts can be followed up by a variety of actions. These may include SMS replies of one form or another. Additionally, SMS can be used to pull data from a database. This feature gets used in Xsonic InTouch to pull contact details from a user's personal contacts folder in the Exchange database. In this way a mobile worker could get the fax number of a customer, their address, home phone number etc. For many of these types of applications, the quick alert or prompt/pull operations of SMS are ideal. Indeed, an advantage of SMS is that it is quick.

The advantage of WAP is that it enables greater interactivity with the data source. This would be useful, for example in any operation that is multi-paged in nature (such as navigating through a hierarchy). Traversing an email Inbox is one such application. With Xsonic InTouch, a WAP phone could be used to receive SMS alerts (e.g. calendar reminders, email notification etc.) and the user could then elect to respond with short SMS commands and get a quick reply, or they could elect to connect to the server via a secure remote access point and navigate through the various Exchange folders.

SMS and WAP are different entities and are often complimentary. A well designed application would exploit the essential characteristics of SMS and WAP to suit the end-user requirements. For fast alert or quick-shot pull systems, SMS is a good solution. For any communications requiring ongoing interaction with a hierarchical data source, WAP is a good solution. Sometimes, both solutions can be used to get the best of both worlds.

SMS Faqs

SMS FAQ

What is SMS?

Short Message Service (SMS) is the ability to send and receive short alphanumeric messages to and from mobile telephones. SMS can also be used as a transport for binary payloads and to implement the WAP stack on top of the SMSC bear. SMS was created as part of the GSM Phase 1 standard.

Why use SMS?

SMS allows users to directly transmit messages to each other without the use of an operator (it is, however, necessary to have the underlying operator controlled wireless service). The first user can send a message to a mobile unit, via a direct connect computer. The SMS protocol of messaging is also "smarter" then standard paging. SMS is a store and forward method therefore, if the end user is not available, the mobile unit is powered off, or the unit is outside a service area, when the unit comes back on line the message will appear. A SMS message can also be sent "certified," where it will notify the message originator of the end user's receipt of the message.

How would you send an SMS Message over the Internet?

The front-end would simply be a section for the message (limit) and a destination address (mobile number). Then, based on your architecture, a lower layer would have to create the correct message based on the request or the message is generate server side. In the case of an end-user sending a message to a mobile unit, it would be a SMS-DELIVER message. Then entire message would then be "encapsulated" in a TCP/IP message and send to the appropriate Short Message Service Centre (SMSC). The MSC would then remove the TCP/IP layer from the message and process the message as if it were generated locally by an operator.



What are some other uses for SMS?

Voice/Fax Notifications

Delivery of Replacement Ringtones, Operator Logos and Group Graphics
Mobile users will select features or options for their phone (ideally from a web site). They enter their mobile number and the feature is sent to their phone via SMS message in a matter of seconds. The user then has the option to select and save or to delete.

Unified Messaging
Using a single interface, unified messaging users are able to access all forms of messages (voice mail, email, fax) from a single point.

Direct communication
End users can send and receive SMS messages without the use of an operator.

Does SMS support all languages?

SMS is able to support any language, but that language is dependent more on how the handset is configured than anything else. Every region supports different languages and each software build for every phone is different. In the Americas, phones typically support English, Spanish, and Portuguese. In Europe it is vastly different.

What are the two types of SMS?

Point-to-Point and Point-to-Omnipoint (cell broadcast)

What is Point-to-Point?

Point-to-Point uses a dedicated link between the network and the mobile station allowing bidirectional messaging without operator interaction.

What is the maximum length of a Point-to-Point short message?

Two-way data transport = 140 Octet Data Payload Supports Either: 140 bytes for binary data transport (PDU format) 160 characters for text messaging transport (7-bit ASCII).

What are the two types of Point-to-Point messages?

Mobile originated (MO) and Mobile terminated (MT).

What is SM-MT (short message - mobile terminated)?
SM-MT denotes the capability of the GSM system to send a message from the SC to an MS where the message is either received, or, if the recipient device is unavailable, stored for later delivery. A delivery report or failure report is then sent back to the SC. These messages may be input to the Service center by other mobile users (via a mobile originated short message) or by a variety of other sources, e.g. speech, telex, or facsimile.

What is SM-MO (short message - mobile originated)?

SM-MO denotes the capability of the GSM system to send a message from an M to an SME via an SC and to provide information to the MS about the delivery or failure of that message. These messages may be destined for other mobile users, or for subscribers on a fixed network.

What are the specific types of Point-to-Point messages?

SMS-DELIVER: sending a short message from the SC to the MS.
SMS-DELIVER-REPORT: replying with an error cause.
SMS-SUBMIT: sending a short message from the MS to the SC.
SMS-SUBMIT-REPORT: reply with an error cause.
SMS-STATUS-REPORT: sending a status report from the SC to the MS.
SMS-COMMAND: sending a command from the MS to the SC.

What is Point-to-Omnipoint?

Point-to-Omnipoint, or Cell Broadcast, sends messages to predetermined cell broadcast areas. Unlike Point-to-Point messaging, Cell Broadcast does not use a dedicated link. The network operator is where all messages originate and the recipients include all users within a given cell, area, or network. Also unlike Point-to-Point, CB messages do not provide any assurance that the message was recieved.

What is the maximum length of a Point-to-Omnipoint short message?

A Point-to-Omnipoint short message is a maximum of 93 charaters (82 octets) in length.

Where is it determined which MSs will receive which CB messages?

At the origination and termination points. At the origination point, the sender (or network operator) broadcasts messages on certain "channels". The sender indicates the frequency and duration of transmission. At the termination point, the user selects which "channels" will be displayed on his mobile station. If the MS is switched on and idle, it is able to identify and ignore re-broadcasts of messages that have already been received.

How do mobiles know to display only those messages desired by the MS user?

CB messages are assigned message classes that categorize the type of information contained in the message.

What are the error conditions that can return to an SC from an MS?

Unknown subscriber: message is rejected because there is no directory number for the mobile subscriber (GSM 09.02).
Teleservice not provisioned: message is rejected because the recipient MS has no SMS subscription (GSM 09.02).
Call barred: message is rejected due to barring of the MS (see GSM 09.02, description of the Barring supplementary service, GSM 02.04 and 03.11, and description of Operator Determined Barring, GSM 02.41 and 03.15).
Facility not supported: the message is rejected due to no provision of the SMS in the VPLMN (GSM 09.02).
Absent subscriber: The message is rejected because there was no paging response (GSM 04.08), the IMSI record is marked detached (GSM 09.02), or the MS is subject to roaming restrictions (GSM 09.02).
MS busy for MT SMS: The message is rejected because of congestion encountered at the visited MSC.
SMS lower layers capabilities not provisioned: message rejected due to MS not being able to support the SMS. The short message transfer attempt is rejected either due to information contained in the class-mark, or the MSC not being able to establish connection at SAPI (GSM 04.08 and 09.02).
Error in MS: message rejected due to an error occurring within the MS at reception of a short message (lack of memory or protocol error).
Illegal subscriber: message rejected because of failed authentication.
Illegal equipment: message rejected because the MS was black-listed.
System failure: message rejected due to network or protocol failure.
Memory capacity exceeded: message rejected because the MS doesn't have enough memory.
How can SMS be used to program phones?

Nokia has created a new protocol called Smart Messages which sends configuration messages to mobile phone units with header definitions stating that the message is a configuration message. These Smart Messages make use of the SMS protocol.

What are the classes of SM-MT (mobile terminated) messages?

Classes identify the message's importance as well as the location where it should be stored. There are 4 message classes.
Class 0: Indicates that this message is to be displayed on the MS immediately and a message delivery report is to be sent back to the SC. The message does not have to be saved in the MS or on the SIM card (unless selected to do so by the mobile user).
Class 1: Indicates that this message is to be stored in the MS memory or the SIM card (depending on memory availability).
Class 2: This message class is Phase 2 specific and carries SIM card data. The SIM card data must be successfully transferred prior to sending acknowledgement to the SC. An error message will be sent to the SC if this transmission is not possible.
Class 3: Indicates that this message will be forwarded from the receiving entity to an external device. The delivery acknowledgement will be sent to the SC regardless of whether or not the message was forwarded to the external device.

SMS -- an introduction

The Short Message Service (SMS) allows text messages to be sent and received to and from mobile telephones. The text can comprise words or numbers or an alphanumeric combination. SMS was created as part of the GSM Phase 1 standard. The first short message is believed to have been sent in December 1992 from a PC to a mobile phone on the Vodafone GSM network in the UK. Each short message is up to 160 characters in length when Latin alphabets are used, and 70 characters in length when non-Latin alphabets such as Arabic and Chinese are used.

There is no doubting the success of SMS. The market in Europe alone had reached over three billion short messages per month as of December 1999, despite little in proactive marketing by network operators and phone manufacturers. Key market drivers over the next two years, such as the Wireless Application Protocol (WAP), will continue this growth path.

Typical uses of SMS include notifying a mobile phone owner of a voicemail message, alerting a salesperson of an inquiry and telling a driver the address of the next pickup.

SMS TECHNOLOGY

SMS is essentially similar to paging, but SMS messages do not require the mobile phone to be active and within range, as they will be held for a number of days until the phone is active and within range. SMS messages are transmitted within the same cell or to anyone with roaming capability. They can also be sent to digital phones from a web site equipped with a PC Link or from one digital phone to another. An SMS gateway is a web site that lets you enter an SMS message to someone within the cell served by that gateway or acts as an international gateway for users with roaming capability.

The SMS is a store and forward service. In other words, short messages are not sent directly from sender to recipient, but via an SMS Center. Each mobile telephone network that supports SMS has one or more messaging centers to handle and manage the short messages.

The SMS features confirmation of message delivery. This means that, unlike paging, users do not simply send a short message and trust and hope that it gets delivered. Instead the sender of the short message can receive a return message back notifying them whether the short message has been delivered or not.

Short messages can be sent and received simultaneously with GSM (Global System for Mobile Communications) voice, data and fax calls. This is possible because whereas voice, data and fax calls take over a dedicated radio channel for the duration of the call, short messages travel over and above the radio channel using the signaling path. As such, users of SMS rarely, if ever, get a busy or engaged signal as they can do during peak network usage times.

Ways of sending multiple short messages are available. SMS concatenation (stringing several short messages together) and SMS compression (getting more than 160 characters of information within a single short message) have been defined and incorporated in the GSM SMS standards.

The network operator needs to purchase its first generation SMS Center as part of the network commissioning plan. The initial SMS Center may simply be a voice mail platform module or a stand-alone SMS Center. It is not possible to make the SMS available without an SMS Center since all short messages pass through the SMS Center.

RECENT SMS DEVELOPMENTS

Because simple person-to-person messaging is such an important component of total SMS traffic volumes, anything that simplifies message generation is an important enabler of SMS. Predictive text input algorithms significantly reduce the number of key strokes that need to be made to input a message. T9, from Tegic, anticipates which word the user is trying to generate. Widespread incorporation of such algorithms into the installed base of mobile phones will typically lead to an average uplift in SMS traffic of 25% per enabled user. These predictive text algorithms support multiple languages.

The introduction of standardised protocols such as SIM Application Toolkit and the Wireless Application Protocol (WAP) contribute to an increase in messaging usage by providing a standard service development and deployment environment for application developers and business partners. These protocols also make it easier for users to reply to and otherwise access messaging services through custom menus on the phone. While these protocols are only a means to an end and not new messaging destinations or services, they are likely to lead to a 10-15% uplift in total SMS volumes.

The introduction of more user-friendly terminals contributes to increases in messaging usage. Terminals such as smart phones make it easier for users to originate, reply to and otherwise access messaging services through the provision of a QWERTY keyboard, rather than the limited keypad on standard mobile phones.

References:

http://mobilecommunicationsfacts.blogspot.com/

http://wireless.agilent.com/rfcomms/refdocs/wcdma/wcdma_gen_bse_sms_mt.php

SMPP -- an insight

Introduction

SMPP stands for Short Message Peer to Peer Protocol SMPP is used to send and receive messages from and to GSM, UMTS, iDEN,CDMA and TDMA cell phones.
The protocol is a level-7 TCP/IP protocol, which allows fast deliver of SMS messages.
Using the SMPP protocol instead of sending messages using a GSM modem has the following advantages:

• The SMPP protocol is TCP/IP based, GSM hardware is not required;
• Users can send SMS to a simple shortcode, this is not possible when sending to a GSM phone;
• High throughput ( up to 200 msgs/second);
• Alphanumeric sender address can be assigned.

Applications

SMPP can be used for the following applications:

• Sending Voicemail alerts to mobile users;
• Sending SMS notifications to mobile users, for instance when a server is down, or to notify students that a lesson is cancelled;
• Information services : sending stock exchanges, traffic jam alerts or weather forecasts;
• Voting, process votes from mobile users (Requesting music on the radio;
• MMS notifications, when users pay for ringtones and Java applications, the download location is send by a MMS notification or WAP Push message;
• Telemetry applications.

Connections

SMPP is used by clients to connected to a SMSC (Short Message Service Centre). In SMPP terms, the client is called ESME (Extended Short Message Entity). SMSC's can also exchange data using a SMPP connection.

Messages Send to a SMSC are called MT (Mobile Terminated) messages, because they are sent to a mobile phone. Messages received from a SMSC are called MO (Mobile Originated) messages, because they were sent from a mobile phone.

When an ESME establishes a connection using SMPP, this can be done in three modes: Transmitter, the ESME can only submit messages to the SMSC; Receiver, the ESME can only receive messages or delivery reports from the SMSC; Transceiver, the EMSE can bot send and receive messages to and from the SMSC.

SMPP PDU's

The TCP packets between the ESME and the SMSC are called PDU's (Protocol Data Units). The following types of PDU's are used in SMPP connections:

Session Management PDU’s Connecting, disconnection and connection keep alive. Message Submission PDU’s Submitting messages to a mobile phone. Message Delivery PDU’s Delivery of messages to the SMPP client. Ancillary Operations PDU’s Message query, cancel and replacement. The following SMPP PDU's are used the most: bind_transmitter / bind_receiver / bind_transceiver Used to connect the client with the SMSC, in SMPP sessions a ‘system ID’ and password are used for authentication. submit_sm Used to submit a single message from the client to the SMSC ( MT ). This packet contains the sender and recipient address, message body and some optional parameters. deliver_sm When a messages has to be delivered to the client this packet is used ( MO ). It contains information about the sender of the message and the message body. This PDU is also used to send delivery reports to the ESME. query_sm To query the state of a previously sent message, this command is used. You need a message reference to query a message. Most provider require you to use delivery reports instead of querying the messages all the time. enquire_link This packet is sent once in every x minutes to check if the connection is still alive. If not, the connection is terminated. This packet is also used to keep dial-up connections alive ( for instance ISDN ). The most used timeout for SMPP connections is one minute. unbind Used to end the session and disconnect the TCP/IP connection. Connection examples Sending Messages Receiving Messages SMPP optional parameters To extend the SMPP protocol with extra parameters, TLV parameters, also called optional parameters were introduced in the SMPP protocol since version 3.4: TLV’s are used to make the existing PDU’s more efficient; TLV’s are used to enhance existing PDU’s with new features; TLV Stands for Tag-Length-Value field; TLV’s are supported in SMPP version 3.4 and higher. Some commonly used TLV's are: message_payload TLV Used to encode large messages. The submit_sm PDU can be used to messages up to 255 chars only. This PDU improves performance, for instance: when you need to send a message containing 315 characters you only have to send one packet instead of two. This doubles the throughput. sar_msg_ref_num, sar_segment_seqnum, sar_total_segments TLV’s Segmentation And Reassembly. These TLV’s are used to send a long message in multiple parts. sar_msg_ref_num - Reference of the concatenated message. sar_segment_seqnum - ID of the current segment. sar_total_segments - Total number of segments. Please note that not all SMPP providers implement all TLV parameters.

Following link has information on SMPP: http://code.google.com/p/jsmpp/

USSD Gateway -- some insight

What is a USSD Gateway?

A USSD Gateway routes USSD messages from the signaling network to service applications and back. "USSD gateway" and "USSD center" are synonyms.

USSD Gateway is based upon the ability of the delivery agent or the source to send and receive USSD messages. As USSD is a session-based protocol unlike its siblings (SMS and MMS), therefore, the session needs to be allocated to each and every interaction.

[edit] Difference between USSD and other Gateways

The difference between USSD Gateways and other kinds of gateways is that USSD Gateways require to know what session is going on. Also, put in the locator (it locates where the MS (Mobile Station) is currently), and you have a highly dynamic session – based protocol.

[edit] Modular Operation

1. Session Module : As per directions from the SS7 (Signaling System 7) protocol stack’s MAP (Mobile Application Part), it receives and sends out session IDs from the session ID pool, and maintains and destroys the sessions.
2. MAP layer: Mobile Application Part is present both on the server and on the MS. Details can be found in other articles on Wikipedia and other popular internet and hard sources.
3. Gateway: A Gateway will wait for messages from the MAP layer and work to route these messages into SMPP protocol which is then delivered to the server applications. This is the most important operation, and this is the reason why USSDs are primarily used, as it helps to directly connect users to applications like bill checking and others.
4. Locator: This tries to find out the current cell and relays it to the Gateway. Then the messages are routed using Routing Numbers.
5. Home Location Register: This is the home zone where the given cell phone’s number is registered in the database. This is different from the Visitor Location Register which is where the user is roaming.

Typical Applications:

• Balance Check: The user can send a Process unStructured Supplementary request (PSSR) to the home zone which will forward this, under guidance from the Gateway, to the correct application. Then, the application sends an acknowledgement via USSD Gateway, HLR etc, known as PSSR response back to the user. Balance Notification at the end of charged call can also be given using Unstructured Supplementary Service Notify (USSN) message.
• Voice Chat: Using the same process as above, one can use voice chat. This is highly useful when VoIP enabled phones are not available.
• Advertising: The application can advertise their product using USSD which is more non-invasive than telemarketing.
• Roaming: This has huge advantages while roaming. This is because USSD services are well available in roaming networks and all the USSD messages are directed towards the subscriber's Home Network itself, thus, same set of services that are available in home network can be given in visited network too, giving subscribers a Virtual Home Environment (VHE).

Apart from PSSR and USSN, there is another method called Unstructured Supplementary Service Request (USSR) message that initiates a session by USSD Gateway to a Mobile User. This message can be used in conjunction with USSR initiated session to provide session based services like Menu services through USSD. Also, in the earlier phases of MAP (Mobile Application Part), PSSR message was called PSSD (PSS Data).

USSD -- a nice tutorial

To get the most out of your mobile device, it is handy to know more about USSD – which stands for Unstructured Supplementary Service Data.

This is a protocol which is used by Mobile Phone operators in their core network and manufactureres on their mobile devices.

The below tutorial will hopefully introduce you to some interesting hint's trick's and tips for Mobile Devices both on and off the Vodafone Network.

So How Does It Work?

A USSD message is sent directly to the users home network. Hence a user can still potentially obtain certain home services when roaming abroad. The message does not actually tie up the traffic plane. It is sent on the Stand-alone Dedicated Control Channel (SDCCH), thus no expensive radio resources are consumed while sending. If there is already a call in progress the message is sent via the Fast Association Control Channel (FACCH), again leaving valuable circuit switched and packet switched radio resources untouched.

The best analogy for USSD and SMS in mobile networks, is Telnet and E-mail in IP networks.

Why Is It So Good?

It is session based, hence it has good real time behaviour unlike SMS. It is understood by all GSM networks and handsets. It is not resource hungry. Version two even supports a dialogue enabling a menu to be displayed on a device. It works accross networks.

What Is It Used For?

It's used for services like pre-pay in most networks. Vodafone utilise USSD for debugging, pre-pay services, ussd call back, caller ID, voice mail services (which are being deprecated), call forwarding services, dual line, multi SIM and many more.

Why Should A Developer Be Bothered In Learning This And The Commands?

It could potentialy be used for helping to test and verify parts of the network. Information delivered from a service could be use as part of another service.

How Do I Use It?

It's very easy to use. All commands start with astrix () and/or a hash (#) then a number then an astrix () and/or hash (#). The user then sends the string as if dialing a number. The mobile device interprets this as a USSD command and sends via the control channel to the operators central database known as a HLR (Home Location Register). From here it can be routed to an IN node such as a USSD Gateway. Show Me A Cool Example.

The most well know USSD command is probably:

*#147#

Try typing this into your phone and sending, You should be returned a message with the last person who dialed you, a time and date like:

077666999000 13:54 19FEB08

This is stored in the network even when your phone is not in service, or out of coverage.

layoutElementContent.uuid: 50637309-0e3d-43f2-973c-adc73a9befa7 Document Name BV_MOBILE_DEVICES_TUTORIAL_INTRODUCTION Document UUID 43c75a69-4738-4b5e-807b-43c1f4119846

To get the most out of your mobile device, it is handy to know more about USSD – which stands for Unstructured Supplementary Service Data.

This is a protocol which is used by Mobile Phone operators in their core network and manufactureres on their mobile devices.

The below tutorial will hopefully introduce you to some interesting hint's trick's and tips for Mobile Devices both on and off the Vodafone Network.

layoutElementContent.uuid: e2dbbda3-f0a8-4f51-945e-0ce7dac33b52 Document Name BV_MOBILE_DEVICES_TUTORIAL_USSD_NEWS Document UUID 455163ef-dc25-477b-915b-fe4e0bad0cd9

USSD Voice Alert Commands

Vodafone UK are currently in the process of rolling out the new Voice Mail system. This will mean an improved service for Vodafone customers allowing a better interactive voice setup of your own voice mail account.

This will impact the common USSD commands for controlling your voice mail such as the *#121#. These commands will no longer work after the switch over. However, you will have an improved set of voice menu options to control all this functionality.

Vodafone UK will be soft launching the new service, so no exact date is given yet for when this will happen. green info icon

The list of deprecated USSD commands for voice mail are given below:

Clear Conditional Diverts

*#1210#

Set Conditional Diverts

*#1211#

Set Unconditional Diverts

*#1212#

Clear Unconditional Diverts

*#1213#

Set Voice notification

*#1217#

Set SMS notification

*#1218#

Set alert and deliver notification

*#1219#

layoutElementContent.uuid: 0487df81-5471-4159-8620-930a5b7351a0 Document Name BV_MOBILE_DEVICES_TUTORIAL_USSD_CODES Document UUID f8831fcf-3671-41ec-99fe-81097a045825

Core Network USSD Messages

The USSD messages contained here all relate to obtaining network specific information to the mobile from the core network. There is an exception, which is the USSD command to obtain your IMEI code! We hope developers may find this information useful and look forward to feedback from the community

Get the mobile number of the device

This sends a request into the core network to obtain what it thinks is the MSISDN number registered to the SIM card. It can be quite useful in determining the MSISDN number of a connected divice if you hapen to be testing multiple devices.

There are two flavours of this. One which returns the MSISDN from the HLR, and the other from the BSC.

MSISDN From HLR

The Message *#100#

The response: 077666999000

MSISDN From BSC

The Message *#100*#

The response: "077666999000" , TS11

Get the HLR number the device is registered with

This asks the Home Location Register (HLR) that the SIM is registered with to send it's ID number. It is mostly only useful to engineers testing the core network.

Please note this is an example, the actual number returned for your device will probably be different

HLR Number Device Is Registered with

The Message *#101#

The response: 1hlrc1 0003 0122

Get the VLR number the device is registered with

This asks the Visited Location Register (VLR) that the SIM is registered with to send it's ID number. It is mostly only useful to engineers testing the core network.

Please note this is an example, the actual number returned for your device will probably be different

VLR Number Device Is Registered with

The Message *#102#

The response: 447785012100 VF-Fleet

Get the Network Time

This asks the mobile network to report it's local time. It is mostly only useful to engineers testing the core network.

Network Time

The Message *#103#

The response: 21-FEB-2008 12:43

Get the MLR number the device is registered with

This asks the Message Location Register (MLR) that the SIM is registered to send it's ID number. It is mostly only useful to engineers testing the core network.

Please note this is an example, the actual number returned for your device will probably be different

MLR Number Device Is Registered with

The Message *#104#

The response: 447990100706 VF-GMLRI

Get CS and PS services information the device is registered with

This asks the core network that the SIM is registered to for information on it's registed state to SGSN and VLR. This includes registered times and ID's. It is mostly only useful to engineers testing the core network.

Please note this is an example, the actual number returned for your device will probably be different

CS and PS Registration Info

The Message *#105#

The response: CS:447785012100 VF-Fleet
REGISTERED 21-FEB-2008 08:02:10
PS:447785012610 SGSNMS1
REGISTERED 21-FEB-2008 10:08:09

Get the IMEI of device.

This asks the mobile device to return the International Mobile Subscriber Identity Number (IMEI). It is mostly only useful to engineers testing the core network and or mobile devices.

Please note this is an example, the actual number returned for your device will be different

IMEI Info The Message *#06#

The response: 350257006231189

layoutElementContent.uuid: 664efac6-b8ed-4ee5-b0ec-164726f8c680 Document Name BV_MOBILE_DEVICES_TUTORIAL_USSD_CODES_LAST_CALLER Document UUID 10f4a166-cb53-4965-929c-1f19d91b9348

USSD Messages for Last Caller

This USSD messages is used to retrieve the last caller to the your mobile.

The command is useful as it will return the last dialed number to your mobile even when it's switched off or not in network coverage.

Last Caller

The Message *#147#
The response: 077666999000 16:28 21FEB08

USSD Messages for Nokia Bluetooth

This USSD messages is used to retrieve the Bluetooth MAC address from Nokia mobile devices.

The command can be useful for developers when they quickly require the MAC address during testing.Please note, the value returned on your device will be different.

Bluetooth MAC address

The Message *#2820#
The response: Bluetooth device
address: 001c9a1faea5

SS7 Configuration Help Links

http://www.nmscommunications.com/manuals/6464-22/default.htm

http://www.protocols.com/pbook/ss7.htm

http://www.linkbit.com/uiplus/

MAP Specifications:

http://www.3gpp.org/ftp/Specs/html-info/0902.htm

ANSI to ITUT Point Code Converstion Schematic

Generally, there are two standards for Point Code - ITU 14 bits (3-8-3) and ANSI 24 bits (8-8-8). For each of the two standards, Point Code can be presented in three formats: decimal, binary, and hex. Google had pointed me to telecomdesk.com that provides a convenient web-based tool for format conversion.
However, what I actually need to do was: convert an ANSI Point Code (8-8-8) into ITU Point Code (3-8-3). For example, let say the given ANSI PC was 8-2-10, how am I going to find out the value in ITU standard? I had searched the Internet for quite some time but just cannot find a clue. Eventually, I came to the following idea:
1) 8-2-14 ==> 00001000 00000010 000011102) Take the 4 right-msb for each segment ==> 1000 0010 11103) Group the bits together and pad with two 0s ==> 001000001011104) Arrange those bits into 3-8-3 format ==> 001 00000101 1105) 001 00000101 010 ==> 1-5-6
Result: 1-5-6

Call Control XML (CCXML) - An overview

What is CCXML?

Traditionally, Call Control has required interaction with and understanding of telephony API's which often change from one platform to another.

CCXML is the "Call Control eXtensible Markup Language". It is an XML based language that can control the setup, monitoring, and tear down of phone calls. CCXML allows the industry to leverage the strength of Web platforms and technologies to intelligently control calls on and off the telephone network. Additionally, CCXML will create a high-level industry standard for Call Control that can run over any telephony platform.

Why not build Call Control into VoiceXML?

VoiceXML was never designed to support advanced Call Control features - it was designed to be a dialog control language and it does that quite well. While VoiceXML does support basic Call Control features via the tag, those features are in fact too basic for many telephony applications. Because of this limitation, vendors looked at adding Call Control to VoiceXML using several different approaches. Some companies added robust Call Control support by extending VoiceXML while others created their own Call Control languages such as CallXML from Voxeo. While these solutions provided enhanced Call Control support they were incompatible with each other and did not address all of the Call Control scenarios reviewed by the W3C.

VoiceXML controls the presentation of media inside of calls. It uses a model based on forms and transactions that occur in a linear fashion - a model that works very well for user driven voice interfaces. Call Control uses a model based on events and commands that can occur at any time. The fundamental differences in these models made it very difficult - if not impossible - to deliver robust Call Control inside of VoiceXML itself.

Additionally, many W3C members and telephone industry leaders wanted a language that could be used outside of VoiceXML itself. While only some phone calls require automated voice interaction, every phone call requires Call Control. As a result, CCXML could end up being used and supported by everything from PBXs to the telephone switches that run the phone network itself. Many of these telephony platforms have no need or support for the things VoiceXML itself can do.

What does CCXML allow you to do?

There are a number of features that VoiceXML currently can't supply that CCXML will:

• Support for multi-party conferencing, plus more advanced conference and audio control. Any telephone conferencing application requires such features.
  
  
• The ability to give each active line in a voice application its own dedicated VoiceXML interpreter. Currently, many VoiceXML platforms initiate a second call or "call leg" to transfer a call from an automated VoiceXML platform to another telephone user. The second leg of a transferred call on these platforms lacks a VoiceXML interpreter of its own, limiting the scope of possible applications that can occur on that second leg.
  
  
• Sophisticated multiple-call handling and control, including the ability to place outgoing calls at any time, initiated outside of the VoiceXML platform.
  
  
• Handling for richer and more asynchronous events. Advanced telephony operations involve substantial signaling, status events, and message-passing. VoiceXML does not currently have a way to integrate these asynchronous "external" events into its event-processing model.
  
  
• An ability to receive events and messages from systems outside of the CCXML or VoiceXML platform. Interaction with an outside call center platform, calls started asynchronously from the VoiceXML platform, and communication between multiple "clustered" VoiceXML or CCXML platforms all require event interaction from one platform to another.

CCXML allows developers to write advanced applications that require these features. Examples of such applications include

• "Follow me, Find me" applications that find the person you are trying to call by dialing their cell phone, home phone, and office phone in parallel.
  
  
• Call center applications that intelligently gather information from the caller and then pass that information on to the call center agent.

The W3C Voice Browser Working Group decided to tackle Call Control and came up with a set of comprehensive requirements that address the Call Control needs of almost all voice applications. After reviewing those requirements several proposals were submitted. CCXML is the result of those proposals.

What does CCXML bring to VoiceXML?

CCXML adds robust Call Control support to VoiceXML. However CCXML could also be used with other dialog systems such as a traditional IVR (Interactive Voice Response) platforms created before VoiceXML was available.

One critical thing to understand is that CCXML is not a media/dialog language like VoiceXML. It only provides support to move calls around and connect them to dialog resources. CCXML does not provide any dialog resources on its own. (Note: A dialog resource is anything that interacts with a caller via voice, such as a VoiceXML platform or even a second caller at another location.)

What does CCXML look like?

Let's create a CCXML application. The following example was written on the Voxeo CCXML platform implementation. You can access Voxeo CCXML platform for free by signing up at http://evolution.voxeo.com.

The First Step

Lets start with the equivalent of a hello world application that conditionally answers the phone based on your caller id, plays a VoiceXML dialog and then hangs up. Being able to conditionally answer a call is one of the new features that CCXML brings to VoiceXML applications.

To start off we create a XML tag and a tag for the document. These are required in all CCXML documents.

Event Handlers

CCXML is based on a state machine model.

In general, a state machine is any program that stores the status of something at a given time and can operate on input (ie: telephony events) to change the state of the "machine" and can optionally cause an action to occur. State machines are used to develop and describe specific device or program interactions.

To summarize, a state machine can be described as:

• An initial state or record
• A set of possible input events
• A set of new states that may result from the input
• A set of possible actions or output events that result from a new state
  

In their book Real-time Object-oriented Modeling, Bran Selic & Garth Gullekson view a state machine as:

• A set of states
• A description of the initial state
• A set of input events
• A set of output events
• A function that maps states and input to output
• A function that maps states and inputs to states called a state "transition"

There are a number of ways to represent state machines, from simple tables, to C switch and case statements, to graphical design tools. CCXML uses XML tags to represent the state machine which will control one or more telephone calls.

The CCXML tag contains all the event handlers, or "transitions" for our call-control application. In CCXML you write an event handler for your application and then the handlers transition tags will receive all the matching events that occur during a call.

We Are Now Connected

Next we add a tag for the call that we just answered. We are looking for the "connection.CONNECTION_CONNECTED" event. This event will only come into the CCXML platform once the call has been connected.

Running a Dialog

Let's start a VoiceXML dialog script from the connected call event handler on the call we are connected to. We do this with the tag and by specifying the URL source of the VoiceXML document we want to run. Once we do this the CCXML platform will connect the call to a VoiceXML resource and play the script to the caller.

Here is the content of hello.vxml:

1.0//EN' 'http://voicexml.nuance.com/dtd/nuancevoicexml-1-2.dtd' >

  

     
        Hello World.
        
     
   

Ending a Dialog

We now add the tag to catch the event that indicates the VoiceXML dialog has ended. We do this by catching the "dialog.exit" event.

Disconnecting

Next we add the tag to the dialog exit handler to disconnect the caller from the CCXML platform. We will also write to the log using Voxeo's tag.

Ending the Call

We are almost done with our first CCXML script. We only need to add some clean up code to exit the CCXML interrupter. We do this by adding a tag to catch the "call.CALL_INVALID" event:

The End Is Nigh

Finally we add a handler for the call_invalid event that occurs when a call ends, including an tag to leave the CCXML platform:

IVR - an insight

1. IVR Platforms

   IVR platforms are the "server and operating system" hardware and software platforms on which IVR solutions run.

   IVR platforms at a minimum provide the ability to play and record prompts and gather touch-tone input. IVR platforms may also offer the ability to recognize spoken input from callers (voice recognition), translate text into spoken output for callers (text-to-speech), and transfer IVR calls to any telephone or call center agent.

2. IVR Applications

   IVR applications are programs that control and respond to calls on the IVR platform. IVR applications can either be developed by an enterprise, by an IVR development shop, or by companies that offer canned IVR applications.

   IVR applications direct the IVR platform to prompt callers, gather input, and transfer callers to other phones. IVR applications also call on existing back-end database and application servers to retrieve records and information required during the course of a call.

3. Back-end servers

   Back-end servers are existing enterprise servers on which the required customer or corporate data can be found.

   Back-end servers can include databases, mainframes, Java or other application servers, and third party information services and solutions.

4. Telephony Infrastructure

   Telephony infrastructure includes telephone lines, call switching equipment, and call center Automatic Call Distributors (ACDs).

   Telephone lines for IVR can be standard analog lines, digital T1, or digital ISDN lines. These lines are connected on one side to the IVR platform and, on the other, to call switching equipment including Telco switches, Voice over IP gateways, and corporate PBX's; or in some cases, directly to call centers via an ACD.

5. IVR Experts

   IVR Experts include employees and consultants who know IVR technology and challenges well.

   Ideally, IVR teams should include one or more members who have experience with IVR integration, configuration, reliability and redundancy, application development, and IVR solution deployment management.

Call Forwarding in SIP

This article arises from a problem we face today as how does SIP stack take care of Call Forwarding.

Suppose A is calling B and B wants to enable Call Forwarding to Caller C.

Our main issue is: Whether SIP stack at A would come to know that the call has been forwarded from B to C or would it be transparent for stack running on A.

Some basics:

Call Forwarding lets you forward your incoming wireless calls to another phone number. Airtime charges, plus any applicable long distance and/or roaming charges, are incurred for calls forwarded via the wireless network.

With Call Forwarding activated:

• You can continue to make outgoing calls from your telephone. Incoming calls will be forwarded.
• When the telephone number to which your calls are being forwarded is busy, callers to your number will receive a busy signal.
• To change the number to which your calls are forwarded, deactivate the feature. Then, follow the activation instructions to enter the new number.

Our problem got resolved from the tutorial on http://www.tech-invite.com/Ti-sip-service-7.html
It clearly indicates that

1. A signaling message would be sent to client, i.e. 181, Call is being forwarded.
   
2. No response message is sent from the client side to the proxy for this 181 message.
3. Rest of the signaling messages received by the client are same, i.e. 180 Ringing, 200 Okay.
   

Hence, Call forwarding at the destination does not really matter to the originating client from protocol signaling aspects.

DTMF Tones

Refer to this article to know what is DTMF and how to generate these tones.

http://www.mathworks.com/products/signal/demos.html?file=/products/demos/shipping/signal/dtmfdemo.html

Changing ulimit in linux

For each ulimit variable, there are actually two limits: a soft limit and a hard limit.

A normal user can adjust the soft limit freely in the range of 0....
A normal user can adjust the hard limit too, but can only decrease it. You must be root to increase the hard limit from its default value.

To see the hard limit values, run "ulimit -H -a".

The limit values are inherited from the parent process to the child process: you could add the command to increase the hard limit to the sshd startup script, so that sshd and all sessions started through it will inherit the increased hard limit. After that, you should be able to increase the soft limit as a normal user.

Alternatively, some Linux distributions have PAM modules (pam_limit.so) that can adjust the limit values at login time, if configured to do so.

Also following can be tried to know the current limits:

sysctl -a|grep fs.file-max

if the parameter is >= 16384 than you can set like this other wise you need to change the kernel parameter.

IN Architecture -- an insight

Q1 Name functional entities in INAP architecture ?

A1 INAP has following functional entities:

• Call Control Function (CCF)
• Service Switching Function (SSF)
• Service Control Function (SCF)
• Service Resource Function (SRF)

Q2 What functional entities are implemented on which physical entities?
A2 The functional entities mentioned above can be implemented in one or more network elements, called physical entities.

• Service Control Point (SCP) can implement SCF
• Service Switching Point (SSP) can implement CCF and SSF
• Intelligent Peripheral (IP) can implement SRF
  

Q3 In which entity the interaction between ISUP and INAP take place?
A3 The interaction between ISUP and INAP takes place in the CCF and SSF.

Q4 What is the basic principle behind providing Intelligent Services using ISUP controlled basic architecture?
A4 The following main subjects have to be considered in this area:

• detection point processing in the CCF
• receipt of INAP operations in the SSF.

Q5 What is a detection Point?
A5 The Detection Points (DPs) indicate Points in Calls (PICs) at which transfer of control can occur. If a DP is recognized an operation from the SSF to the SCF will be sent. Thus the communication towards the SCP is performed.
The provision of Detection Points (DPs) is required in the ISUP basic call handling in order to access IN functionality and to allow IN service logic influence the processing of IN calls.

Interview Questions on Telecom

This blog would try to capture different questions and answers which make us understand the concepts of telecom.

In beginning, I would post topics related to wireless technologies. And I would like if people like you give comments and make this content more rich and meaningful as we go ahead.

Thanks,
Sachin Gupta