Series : Payments through Mobiles - Automated Clearing House

Source: http://www.mobilecommercedaily.com/qualcomm%E2%80%99s-firethorn-adds-thousands-of-financial-institutions-to-mobile-banking-platform/
March 1st, 2010
Vision: In times to come, Consumers will be able to send money to someone using our mobile phone address books containing email addresses and/or mobile phone numbers.
How does it happen now: - Currently for mobile payments, there is no user friendly way for consumers to send money to each other, other than PayPal, that is, which does not have complete coverage.
Automated Clearing House (ACH) is the most common way to transfer funds electronically in the U.S. Routing this transaction requires users to know the bank ID and account number, the numbers listed on the bottom of paper checks.Most Americans do not know their account number or even carry paper checks anymore. Plus, sharing these numbers is considered risky and invites identity theft.
The mobile payments industry needs a way to map a safe, commonly-known, easily-identifiable ID such as an email address or mobile phone number to arcane ACH bank account information. That looks like exactly what Firethorn and the carriers are doing.
Mr. Eads said that when Firethorn can map email addresses and phone numbers to bank accounts, it becomes the “big directory in the sky” that has been missing from mobile payments in the U.S.
Firethorn is building a database of mobile phone numbers, email addresses, ZIP codes and financial instituion login credentials, and believes that this is extremely valuable for both mobile payments and mobile marketing.

How are MVNO different from MNO

Source: http://en.wikipedia.org/wiki/Mobile_virtual_network_operator

A mobile virtual network operator (MVNO) is a company that provides mobile phone services but does not have its own licensed frequency allocation of radio spectrum, nor does it necessarily have all of the infrastructure required to provide mobile telephone service.
A company that does have frequency allocation(s) and all the required infrastructure to run an independent mobile network is known simply as a mobile network operator (MNO).
An MNO that does not have a frequency spectrum allocation in a particular geographical region may operate as an MVNO in that region.
MVNO is an entity or company that works independently of the mobile network operator and can set its own pricing structures, subject to the rates agreed with the MNO.
Some MVNO may own their own home location register, or HLR, which allows more flexibility and ownership of the subscriber's mobile phone number (MSISDN)—in this case, the MVNO appears as a roaming partner to other networks abroad, and as a network within its own region.
Some MVNOs run their own billing and customer care solutions known as business support systems (BSS). Many use an MVNE.

There is a distinction between MVNOs and service providers, who purchase wholesale mobile minutes and resell to end-users. Normally they do not have their own SIM cards and the services provided by service providers depend on the services of the hosting MNOs or MVNOs.
The first commercially successful MVNO in the UK was Virgin Mobile UK,[3] launched in the United Kingdom in 1999. Virgin replicated its UK success through its US operation Virgin Mobile USA, which was eventually acquired by Sprint Nextel for a total equity value of approximately USD$483 million.
Mobile operators and MVNOs
There are three primary motivations for mobile operators to allow MVNOs on their networks. These are generally:
Segmentation-driven strategies
mobile operators often find it difficult to succeed in all customer segments. MVNOs are a way to implement a more specific marketing mix, whether alone or with partners and they can help attack specific, targeted segments.
Network utilisation-driven strategies
Many mobile operators have capacity, product and segment needs–especially in new areas like 3G. An MVNO strategy can generate economies of scale for better network utilisation.
Product-driven strategies
MVNOs can help mobile operators target customers with specialised service requirements and get to customer niches that mobile operators cannot get to.
MVNO models mean lower operational costs for mobile operators (billing, sales, customer service, marketing), help fight churn, grow average revenue per user by providing new applications and tariff plans and also can help with difficult issues like how to deal with fixed-mobile convergence by allowing MVNOs to try out more experimental projects and applications. The opportunity for mobile operators to take advantage of MVNOs generally outweighs the competitive threat.
Understanding the MVNO value chain
Mobile network operator (MNO)
The traditional MNO is characterised by having their own mobile licence, their own mobile infrastructure and direct customer relationship to the end user. The MNO can handle Network Routing and will usually have roaming deals with foreign MNOs. The MNO can produce and distribute for example voice-minutes, SMS and MMS messaging and data traffic themselves. The MNO can typically handle customer service, invoicing and collect consumption data and handle handset management themselves. Additionally the MNO will usually handle marketing and sales to end users themselves.
Mobile network enabler (MNE)
An MNE is characterised by having their own mobile licence and own mobile infrastructure, but the MNE has - unlike the MNO - no direct customer relationship with the end user. It is therefore only an MNO that can establish themselves as an MNE. The MNE is capable of handling Network Routing themselves and the MNE will typically have roaming deals with foreign MNOs. The MNE is able to produce and distribute for example voice minutes, SMS and MMS messages and data traffic. The MNE will typically be able to handle customer relationship, customer billing and collection of consumption data and mobile handset management. The MNE will not handle marketing and sales to end-users, this is a task for the MNE's wholesale customers.The MNE handles the technical side of the business and often also handles areas like customer service and legal assistance for mobile providers without their own network.
Mobile virtual network enabler (MVNE)
MVNEs are characterised by neither having a mobile licence nor mobile infrastructure or any direct customer relationship with the end-users. The MVNE is capable of handling Network Routing and the MVNE has typically entered into roaming deals with foreign MNOs. The MVNE is not capable of producing and distributing for example voice minutes and data traffic, but the MVNE will typically be able to handle producing SMS and MMS messages. A typical MVNE will handle customer service, customer billing, collection of consumption data and mobile handset management. Additionally the MVNE will not handle marketing and sales to end-users, this is a task for the MVNE's wholesale customers. The MVNE functions as a middleman between the MNO and the mobile providers without their own networks. The MVNE handles the technical side and often also tasks like customer service and legal assistance for mobile providers without their own network.
Mobile virtual network operator (MVNO)
An MVNO is characterised by neither having their own mobile licence nor own mobile infrastructure, but the MVNO has the direct customer relationship with the end user. The MVNO is able to handle Network Routing themselves and will typically have entered into roaming deals with foreign MNOs. The MVNO is often able to produce and distribute for example voice minutes and data traffic, typically by tagging onto their existing fixed line operation, and the MVNO will typically be able to handle producing SMS and MMS messages. A typical MVNO will be able to handle customer service, customer billing and collection of consumption data and handset management. Furthermore the MVNO will usually handle marketing and sales to end-users them self.
Mobile shared spectrum enabler (MSSE)
The MSSE has no mobile infrastructure of its own, but is a technology provider that uses innovative hardware and software to enable MVNOs to create their own actual mini-networks, while preserving and enhancing the relationship between MVNO and MNO. Using its agreement with the MNO, and operating within the MNO's spectrum license, the MSSE helps the MVNO to deploy its own network of low-power base-stations into areas the MNO could not justify, using Pico- and Femto-cell technologies. There is no impact on the MNO's mainstream network and it can, if it chooses, extend the reach of the its network at no cost, while the MVNO can improve its profitability by offering specialist and niche mobile solutions.
Service provider (SP)
An SP has neither a mobile licence nor own mobile infrastructure, but the SP has the direct customer relationship with the end user. An SP is not able to handle Network Routing themselves and a SP will not enter into roaming deals with foreign MNOs. The SP is not able to produce and distribute for example voice minutes and data traffic and cannot produce SMS or MMS messages themselves. The SP will typically handle customer relationship, customer billing consumption data and handset management themselves. Additionally, the SP will typically handle their own marketing and sales to end-users.
Branded reseller (BR)
A BR has neither a mobile licence nor own mobile infrastructure, but has the direct customer relationship to end-users. The BR cannot handle Network Routing themselves and the BR will not enter into roaming deals with foreign MNOs. The BR cannot produce and distribute for example voice minutes and data traffic themselves and are not able to produce SMS or MMS messages. A typical BR will not handle customer service, customer billing or collection of consumption data and handset management themselves.The BR will primarily concentrate their activities around marketing and sales to end-users. The BRs' positive contribution to the value chain is (naturally) their "brand", but their distribution power will also be a central asset for many Branded Resellers.

Things to Know before setting up Connectivity in IT

1. Who/what will be accessing the network?
2. Where do users need access?
3. What applications will be used?
4. What devices will be used to access the applications?

The answers to these questions will guide IT decision-makers on type, location, and amount of connectivity, device support, and application
integration. It’s important to point out that companies don’t have to, and likely won’t, eliminate borders overnight. Instead, their networks will evolve
and gradually remove borders. By breaking a ‘borderless’ state into components, they can start by upgrading the performance of their network, add
wireless coverage where needed, and enhance security, laying the foundation for the eventual goal of having applications and the network interact.

Source: http://www.webtorials.com/main/resource/papers/cisco/paper156/borderless_infonectics.pdf

How CAMEL helps in establishing a VPN Call

How is VPN call established using CAMEL support.

The VPN service translates the dialled number into the public number associated with the destination subscriber, who belongs to the same VPN group as the calling subscriber. Hence,
subscribers of one VPN group, e.g. an enterprise, may call one another by GSM, by dialling the
PABX extension number.

In case (1), the CAMEL service connects the calling subscriber to a mobile VPN subscriber. The mobile VPN subscriber belongs to the same VPN group as the calling subscriber. The call is routed to the GMSC of the HPLMN operator, from where the call is routed to the VMSC, where the called subscriber currently resides.

In case (2), the calling subscriber is connected to an extension of the PABX at the company.

In example (3), the calling subscriber is connected to a VPN colleague in an office in the visited country.

In all three cases, the ISUP signalling may take the shortest possible path between the VMSC of the calling subscriber and the PSTN/PLMN of the called subscriber. In these examples, the VPN service may ensure that the called party receives the calling party’s VPN number on her display, instead of the calling party’s public number (Table 3.6).

On-net calls are calls between users of the same VPN group;

Off-net calls are calls from a user of a VPN group to a user outside the VPN group or vice versa.

Referring to the diagram below:

When the calling party (+31 6 516 34 567) dials 3341, the VPN service determines that this number belongs to a subscriber of the same VPN group. The VPN service translates the dialled
number into the public GSM number of the destination subscriber (+31 6 516 34 568). The VPN
service also provides an additional calling party number (3342) in CAP CON. The called subscriber receives 3342 on her display, instead of +31 6 516 34 567. Should the called VPN subscriber return the call, i.e. dial 3342, then the VPN service will connect the call to +31 6 516 34 567. If the calling subscriber dials an off-net number (e.g. +31 70 456 6782), then the VPN service allows the call to continue to the dialled destination, without affecting the routing of the call. VPN does not provide an additional calling party number, since the VPN number should not be presented to a called party that does not belong to the (same) VPN group.
When a call crosses an international boundary, it may occur that the calling party number or the
additional calling party number is not transported in the ISUP signalling link.
A VPN subscriber may receive an on-net call when she is roaming in a non-CAMEL network. In
that case, the VPN service for that called subscriber may remove the additional calling party number from the ISUP signalling flow. The rationale is that the called VPN subscriber might otherwise return a call to the displayed VPN number of the calling party. However, since the network where the called party is currently roaming does not support CAMEL, the VPN service does not have the capability to connect a call from that subscriber to a VPN destination.

Call Forwarding -- Early or Late

What is difference between Early and Late Call Forwarding? Here is a possible explanation ....
Cellular telephones have become increasingly prevalent in today's society. The cellular telephone makes use of a cellular network and traditional telephone networks to route calls using radio communication signals. Two types of cellular networks have evolved—Global Systems for Mobile communications (GSM) and American National Standards Institute-41 (ANSI-41) type networks. ANSI-41 is also sometimes referred to as IS 41 (TIA/EIA [Telecommunications Industry Association/Electronic Industries Association] Interim Standard 41).
The two types of cellular networks use message formats that are not completely compatible with one another as they are. Thus, if a mobile subscriber (MS) using cellular communication, roams from one type of network to another, the messages sent by the MS may not be understood by the network into which it roams unless some sort of conversion is performed. In order to allow roaming between “foreign” type networks, a signaling message converter, referred to herein as an IWU (InterWorking/interoperability Unit) operates to interconnect calling and called Mobile services Switching Centers (MSCs). The IWU passes signaling messages back and forth between network entities while converting the format of these messages such that the messages can be properly interpreted by the receiving MSC.
However, even with known signal message converters, GSM standards are inherently different from the ANSI-41 standards mentioned above. One of these differences is in the operation of “late call forwarding” or the action of the system when a call to a mobile subscriber (MS) cannot be terminated, i.e. connection completed, for any of several specific reasons like call collision, no page response of a page request sent to the called MS, and the like. A GSM system expects the terminating Mobile service Switching Center (MSC) to handle the call forwarding while an ANSI-41 system expects the originating or home MSC of the MS to handle the call forwarding.
As is known by those skilled in the art, call forwarding may occur when a call, to a given MS, cannot be terminated. The call forwarding can be “early” or “late”. Early call forwarding is defined as occurring when a contact with the MS has failed due to predetermined circumstances occurring while attempting to extend the call to another network. Late call forwarding is defined as occurring when call forwarding is initiated after the call has been extended to the last known “foreign” public land mobile network location and contact with the MS has failed due to predetermined circumstances.
In view of the above, it would be advantageous to have a converter mechanism that provides for late call forwarding from the originating MSC when a MS roams from an ANSI-41 network to a GSM network.

In summary, If call is forwarded by HPLMN then it is ECF if by VPLMN then it is LCF.

Source: http://www.freepatentsonline.com/6615037.html

Fibonacci in Nature

Fibonacci in nature
The rabbit breeding problem that caused Fibonacci to write about the sequence in Liber abaci may be unrealistic but the Fibonacci numbers really do appear in nature. For example, some plants branch in such a way that they always have a Fibonacci number of growing points. Flowers often have a Fibonacci number of petals, daisies can have 34, 55 or even as many as 89 petals!

Finally, next time you look at a sunflower, take the trouble to look at the arrangement of the seeds. They appear to be spiralling outwards both to the left and the right. There are a Fibonacci number of spirals! It seems that this arrangement keeps the seeds uniformly packed no matter how large the seed head.

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.