SMSC (short message service center)

SMSC  (short message service center)

When a user sends a text message (SMS message) to another user, the message gets stored in the SMSC (short message service center) which delivers it to the destination user when they are available. This is a store and forward option.

An SMS center (SMSC) is responsible for handling the SMS operations of a wireless network.

1. When an SMS message is sent from a mobile phone, it will reach an SMS center first.
2. The SMS center then forwards the SMS message towards the destination.
3. The main duty of an SMSC is to route SMS messages and regulate the process. If the recipient is unavailable (for example, when the mobile phone is switched off), the SMSC will store the SMS message.
4. It will forward the SMS message when the recipient is available.

I. Validity Period of an SMS Message - An SMS message is stored temporarily in the SMS center if the recipient mobile phone is offline. It is possible to specify a cutoff period after which the SMS message will be deleted from the SMS center. Once deleted, the SMS message will no longer be available for dispatch to the recipient mobile phone (even if it becomes online).

II. Message Status Reports - The SMS sender needs to set a flag in the SMS message to notify the SMS center that he wants the status report about the delivery of this SMS message. This status report is sent to the SMS sender in the form of an SMS....

The Short Message Service is realised by the use of the Mobile Application Part (MAP) of the SS#7 protocol, with Short Message protocol elements being transported across the network as fields within the MAP messages.^[1] These MAP messages may be transported using 'traditional' TDM based signalling, or over IP using SIGTRAN and an appropriate adaptation layer. The Short Message protocol itself is defined by 3GPP TS 23.040 for the Short Message Service - Point to Point (SMS-PP),^[2] and 3GPP TS 23.041 for the Cell Broadcast Service (CBS).^[3]

Four MAP procedures are defined for the control of the Short Message Service:^[1]

• Mobile Originated (MO) short message service transfer;
• Mobile Terminated (MT) short message service transfer;
• Short message alert procedure;
• Short message waiting data set procedure.

Contents  [hide] 1 MO short message service transfer 2 MT short message service transfer 3 Failed short message delivery 4 MAP Transport Protocols 5 Notes 6 References

[edit]MO short message service transfer

Call flow for the Mobile Originated short message service

The diagram to the right depicts a simplified call flow for a successful submission of a mobile originated short message.^[1]

When the subscriber sends a short message, the handset sends the text message over the air interface to theVMSC/SGSN. Along with the actual text of the short message, the destination address of the SM and the address of the Short Message Service Centre (SMSC) are included, the latter taken from the handset's configuration stored on the SIM card.^[4]

Regardless of the air interface technology, the VMSC/SGSN invokes the MAP service package MAP_MO_FORWARD_SHORT_MESSAGE to send the text to the Interworking MSC of the Service Centre whose address was provided by the handset. This service sends the mo-ForwardSM^a[›] MAP operation to the SMSC identified in the SM Submission from the handset, embedded within a Transaction Capabilities Application Part(TCAP) message, and transported over the core network using the Signalling Connection Control Part (SCCP).^[1]

The Interworking MSC of the SMSC, on receipt of the MAP mo-ForwardSM message, passes the SMS-PP^[2]Application Protocol Data Unit (APDU) containing the text message to the actual Service Centre (SC) of the SMSC for storing, and subsequent 'forwarding' (delivery) to the destination address and the SC returns an acknowledgement indicating success or failure. On receipt of this submission status from the Service Centre, the Interworking MSC will send an appropriate indication back to the VMSC/SGSN of the sending subscriber. The message submission status is then forwarded, over the air interface, to the subscriber's handset.^[4]b[›]

[edit]MT short message service transfer

Call flow for the Mobile Terminated short message service

The figure to the right depicts a call flow for Mobile Terminated short message delivery.^[1] For the sake of simplicity, some of the interactions between the VMSC and VLR, and VMSC and Handset, have been omitted, and only the case when SMS home routing is not in use is shown.

When the SMSC determines it needs to attempt to deliver a short message to its destination, it will send the SMS-PP APDU containing the text message, the 'B-Party' (destination phone number) and other details to the Gateway MSC (GMSC) logical component on the SMSC.^[2] The GMSC, on receipt of this short message, needs to discover the location of the B-Party in order to be able to correctly deliver the text to the recipient (the term Gateway MSC, in this context, indicating an MSC that is obtaining routing information from the Home Location Register (HLR)). To do this, the GMSC invokes the MAP service package MAP_SEND_ROUTING_INFO_FOR_SM, which sends a sendRoutingInfoForSM (SRI-for-SM) MAP message to the destination number's HLR, requesting their present location. This SRI-for-SM message may be sent to an HLR in the same network as the SMSC, or via an interconnect to an HLR in a foreign PLMN, depending on which network the destination subscriber belongs to.

The HLR performs a database lookup to retrieve the B-Party's current location, and returns it in an acknowledgement message to the SMSC's GMSC entity. The current location may be the MSC address the subscriber is currently roaming on, the SGSN address, or both. The HLR may also return a failure, if it considers the destination to be unavailable for short messaging; see the Failed short message delivery section below.

Having obtained the routing information from the HLR, the GMSC will attempt to deliver the short message to its recipient. This is done by invoking the MAP_MT_FORWARD_SHORT_MESSAGE service, which sends a MAP mt-ForwardSM^c[›] message to the address returned by the HLR, regardless of whether it is an MSC (Circuit Switched SMS delivery) or an SGSN (Packet Switched SMS delivery).

The VMSC will request the information needed for it to deliver the Short Message to its recipient by sending a Send_Info_for_MT_SMS message to the VLR. The VLR will then instigate a page request, or subscriber search, for the destination subscriber's Mobile Subscriber ISDN Number (MSISDN), and return the result to the VMSC. Since a typical deployment sees the VLR being co-located with the MSC, this message flow is usually internal to the platform.^d[›] Should the page or search for the subscriber fail, the VLR will indicate the failure cause to the VMSC which will abort the Short Message delivery procedure and return the failure to the SMSC (see the Failed short message delivery section below). If the page of the handset was successful, the VMSC will then send to the SMSC indicating successful delivery. The GMSC component of the SMSC passes the result of the delivery attempt to the Service Centre. In the case of successful delivery, the delivered text message will be removed from the Store and Forward Engine (SFE) and, if requested, a delivery report sent to the text originator.^[2] If the delivery failed, the SMSC invokes a retry procedure to periodically make further attempts at delivery; additionally, it may register with the HLR to receive a notification when the B-Party becomes available for short message delivery in the future (see the Failed short message delivery section below).

[edit]Failed short message delivery

When the VMSC/SGSN indicates a short message delivery failure, the SMSC may send a message to the HLR, using the MAP_REPORT_SM_DELIVERY_STATUS procedure, indicating the reason for the delivery failure and requesting that the SMSC be put on a list of service centres wanting to be notified when the destination party becomes available again. The HLR will set a flag against the destination account, indicating that it is unavailable for short message delivery, and store the SMSC's address in the Message Waiting Data (MWD) list for the destination party. Valid flags are Mobile Not Reachable Flag (MNRF), Memory Capacity Exceeded Flag (MCEF) and Mobile Not Reachable for GPRS (MNRG). The HLR will now start responding to SRI-for-SM requests with a failure, indicating the failure reason, and will automatically add the requesting SMSC's address to the MWD list for the destination party. (However if the SRI-for-SM message has priority flag set then the HLR will reply with VLR address if available)

The HLR may be informed of a subscriber becoming available for short message delivery in several ways:

• Where the subscriber has been detached from the network, a reattach will trigger a Location Update to the HLR.
• Where the subscriber has been out of coverage, but not fully detached from the network, on coming back into coverage it will respond to page requests from the Visitor Location Register (VLR). The VLR will then send a Ready-for-SM (mobile present) message to the HLR.
• Where the MS has had its memory full, and the subscriber deletes some texts, a Ready-for-SM (memory available) message is sent from the VMSC/VLR to the HLR.

Upon receipt of an indication that the destination party is now ready to receive short messages, the HLR sends an AlertSC MAP message to each of the SMSCs registered in the MWD list for the subscriber, causing the SMSC to start the Short Message delivery process again, from the beginning.^[1]

Additionally, the SMSC will go into a retry schedule, attempting to periodically deliver the SM without getting an alert. The retry schedule interval will depend on the original failure cause - transient network failures will result in short retry schedule, whereas out of coverage will typically result in a longer schedule.-

[edit]MAP Transport Protocols

While the MAP 3GPP specifications make some effort to divorce MAP from the layer that transports it, the typical transport is via TCAP which in turn is via SCCP/MTP[1-3] and/or SIGTRAN protocols (SUA, M3UA etc.).

A MAP_OPEN construct therefore is directly related to a TCAP_BEGIN with a MAP application context, a MAP_CLOSE is a TCAP_END.

If a message is being delivered using MAP phase 2 or higher, and over MTP rather than SIGTRAN then the maximum MTP PDU size may cause the sender to instigate segmented message sending. This process is not related to concatenation, but simply means that the transaction with the MSC/SMSC/SGSN involves more steps than usual. The recommended way^[1] is an empty TCAP_BEGIN, followed by the MAP content within a TCAP_CONTINUE, and completing with a TCAP_END. The TCAP_BEGIN has TCAP related information that would otherwise cause the limit to be exceeded due to the additional fields added by MAP phase 2. The exact point that segmentation is required is dependent on factors such as the length of the addresses but is mainly dependent on the message length itself. 7 bit alphabet messages that are 140 characters or greater are typically subject to the MAP segmentation procedure.

This segmentation procedure is also increasingly followed, and optionally enforced, by carriers to avoid SMS spoofing impacting their customers. This works because the sending party must receive the responses in order to send a message and so their originating address must be correct.

[edit]Notes

^ a: In MAP Phase 1, there was no segregation of operation code for Mobile Originated and Mobile Terminated SMS messages, just a generic ForwardSM operation.
^ b: A success indication in these contexts is only a notification that the SM has been submitted to the Service Centre, and does not mean successful delivery to the ultimate destination of the text message.
^ c: Although MAP (phase 2 onwards) specifies a separate operation for mobile terminated short message delivery, often the mo-ForwardSM operation is used instead. Where this is the case, mobile originated and terminated messages are distinguished by the inclusion, in the TCAP dialogue portion, of an appropriate Application Context (AC). The relevant ACs are shortMessageMO-RelayContext and shortMessageMT-RelayContext. This use of a single operation code enables simple backwards compatibility with MAP phase 1 networks, which do not have separate operations for MO and MT short messages.
^ d: These messages are not used by an SGSN.

For more information please contact : sandip@routesms.com
Website: www.routesms.com

SMS , Text Messages to Keep Parents updated on kids performance through SMS

<---Parents to be updated on kids performance through SMS!---> The school authorities have introduced the SMS system wherein parents will be informed about their child's activities and other issues on their cell phones through text messaging. A database of students of the primary wing has also prepared for the purpose. Discussing the endeavour, Indu Sharma, primary section in charge said, "Sending circular causes wastage of paper. We have to provide information to parents on various issues and sometimes student forget to convey information to their guardians. As such, we thought of informing them through text messaging." So we are bound to send the written information and sometimes even such an exigency appears that it takes lot of time to phone every parent so we prepared the data base of students and have started sending messages to the students. Indu said during the recent rainfall which lashed the city, all roads were blocked and the authorities had to announce a holiday. As such, the need for such a facility arises. "We can inform parents well in advance about any emergency situation. It's a fast way of communication,' Indu said. Meanwhile, another school to follow suit is Sacred Heart Convent School, Sarabha Nagar, which started the practice last year. Text messages are sent to parents of students missing school, classes or examinations. Meanwhile, parents have hailed the decision. Pankaj Khurana, father of a class IX student said, "Students are quite young to understand what is right and wrong for them. If parents are informed well in time, they can easily counsel their children and keep a on them." Talking on similar lines, another parent said, "The move is highly appreciable. Parents cannot go to the school everyday to keep a check on their children. It is great that they will be updated on various issues happening in the schools."

For more information please contact : sandip@routesms.com
Website: www.routesms.com

Web via Mobile

40 Million Indians access web via mobile--> Indian internet users are vehemently using their mobiles to keep themselves connected to Internet. Thirty-eight million Indians use their handsets to browse the web. The number of people using their mobile handsets to access the web is now over four times those using a PC. The findings based on a report of the Telecommunications Regulatory Authority of India (TRAI) also stated that even as net connections fell in the year 2007, the number of people accessing the web on their cellphones increased from16 million to cross the 38 million mark. This included both CDMA and GSM users logging on to the Internet to surf, check email etc, among whom the number of 'active' Internet users in India currently stands at 32.2 million. The average usage per week on the traditional web stood at 2.4 days. Access using Mobile web surprisingly stood slightly higher at 2.7 days per week. A report on mobile expansion by the Centre for Telecoms Research (CTR), London said that mobile phone connections in India will reach 600 million in five years time as handsets and tariffs become more affordable for the urban population. The report is made on the backdrop of the assumption that within the next five years, urban populations of India will reach high levels of mobile phone saturation, to the extent where many phone users will have two or more handset connections. A large portion of this growth will arise from pre-paid connections, driven by the increasing affordability of handsets and tariffs amongst India's lower middle classes. D. Shivakumar, Managing Director of Nokia India said, "The average usage of the web on the PC per week stood at 2.4 days, while the use of mobile web surprisingly stood slightly higher at 2.7 days per week."

For more information please contact : sandip@routesms.com
Website: www.routesms.com

Mobile Financial Services

Mobile Financial Services" New High Margin Revenue Streams The proliferation of mobile phones globally together with the de-regulation of the financial services market has provided new opportunities for trusted brands. Suddenly companies with millions of customers and broad distribution channels, be they mobile operators, retailers or on-line brands, have an opportunity to participate in the high margins of financial services, previously enjoyed by banks and associated financial services companies. However, with this comes steep a learning curve, change management issues and severe penalties by financial services authorities for negligence. A number of questions need to be addressed. How can we understand the regulatory minefield including Knowing Your Customer (KYC), Anti-Money Laundering (AML), Countering the Financing of Terrorism (CFT)? How can employees, distribution channels and customers be educated on these new products? What services will our customer base want and why?Mobile Financial Services has built a set of technology and service capabilities to address these challenges and provide end to end solutions to add value in our business to business delivery mode.
For more information please contact : sandip@routesms.com

Website: www.routesms.com

SMS Spoofing

SMS spoofing The GSM industry has identified a number of potential fraud attacks on mobile operators that are caused by abuse of SMS messaging services. The most serious of these threats is SMS Spoofing. SMS Spoofing occurs when a fraudster manipulates address information in order to impersonate a user that has roamed onto a foreign network and is submitting messages to the home network. Frequently, these messages are addressed to destinations outside the home network – with the home SMSC essentially being “hijacked” to send messages into other networks. The only 100%-sure way of detecting and blocking spoofed messages is to screen incoming mobile originated messages to verify that the sender is a valid subscriber and that the message is coming from a valid and correct location. This can be implemented by adding an intelligent routing function to the network that can query originating subscriber details from the HLR before the message is submitted for delivery. This kind of intelligent routing function is beyond the capabilities of legacy messaging infrastructure.

For more information please contact : sandip@routesms.com

Website: www.routesms.com

WAP

Protocol design lessons from WAP The original WAP was a simple platform for access to web-like WML services and e-mail using mobile phones in Europe and the SE Asian regions and continues today with a considerable user base. The later versions of WAP were primarily for the United States region and was designed for a different requirement - to enable full web XHTML access using mobile devices with a higher specification and cost, and with a higher degree of software complexity. There has been considerable discussion about whether the WAP protocol design was appropriate. Some have suggested that the bandwidth-sparing simple interface of Gopher would be a better match for mobile phones and Personal digital assistants (PDAs).[19] The initial design of WAP was specifically aimed at protocol independence across a range of different protocols (SMS, IP over PPP over a circuit switched bearer, IP over GPRS, etc). This has led to a protocol considerably more complex than an approach directly over IP might have caused. Most controversial, especially for many from the IP side, was the design of WAP over IP. WAP's transmission layer protocol, WTP, uses its own retransmission mechanisms over UDP to attempt to solve the problem of the inadequacy of TCP over high packet loss networks. WAP 2.0 WAP 2.0 released in 2002 is a re-engineering of WAP using a cut-down version of XHTML with end-to-end HTTP (i.e., dropping the gateway and custom protocol suite used to communicate with it). A WAP gateway can be used in conjunction with WAP 2.0; however, in this scenario, it is used as a standard proxy server. The WAP gateway's role would then shift from one of translation to adding additional information to each request. This would be configured by the operator and could include telephone numbers, location, billing information, and handset information. XHTML Mobile Profile (XHTML MP), the markup language defined in WAP 2.0, is made to work in mobile devices. It is a subset of XHTML and a superset of XHTML Basic. A version of cascading style sheets (CSS) called WAP CSS is supported by XHTML MP. The WAP Forum was founded in 1997. The forum’s main aim was to bring together the various wireless technologies by a standardised protocol. In 2002 the WAP Forum was consolidated (along with many other forums of the industry) into OMA (Open Mobile Alliance), which covers virtually everything in future development of wireless data services.WAP 1.X The WAP 1.0 standard was released in April 1998 and described a complete software stack for mobile internet access.WAP version 1.1 was released in 1999.[5]. WAP 1.2, the final update of the 1.X series was released in June 2000.[6]. The most important addition in version 1.2 was WAP push.WAP Push WAP Push Process WAP Push has been incorporated into the pecification to allow WAP content to be pushed to the mobile handset with minimum user intervention. A WAP Push is basically a specially encoded message which includes a link to a WAP address.WAP Push is specified on top of WDP; as such, it can be delivered over any WDP-supported bearer, such as GPRS or SMS.[9] In most GSM networks there are a wide range of modified processors, but GPRS activation from the network is not generally supported, so WAP Push messages have to be delivered on top of the SMS bearer.On receiving a WAP Push, a WAP 1.2 or later enabled handset will automatically give the user the option to access the WAP content. This is also known as WAP Push SI (Service Indication).The network entity that processes WAP Pushes and delivers them over an IP or SMS Bearer is known as a Push Proxy Gateway (PPG). For More Information contact us @ sandip@routesms.com Visit  us : www.routesms.com

MMS

Multimedia Messaging Service, or MMS, is a telecommunications standard for sending messages that include multimedia objects (images, audio, video, rich text). MMS is an extension of the SMS standard, allowing longer message lengths and using WAP to display the content. Its most popular use is sending photographs from camera-equipped handsets, although it is also popular as a method of delivering ringtones as well. The standard is developed by the Open Mobile Alliance (OMA), although during development it was part of the 3GPP and WAP groups.MMS messages are delivered in a fashion almost identical to SMS, but any multimedia content is first encoded and inserted into a text message in a fashion similar to sending a MIME e-mail. MMS defines a subset of MIME content formats in the MMS Message Encapsulation specification. The message is then forwarded to the carrier's MMS store and forward server, the "MMS relay". If the receiver is on another carrier, the relay forwards the message to the recipient's carrier using the Internet.[1] Once it reaches the correct MMS relay for the receiver, the content is extracted and sent to a temporary storage server (often the same process as the relay) with an HTTP front-end. An SMS "control message" containing the URL of the content is then sent to the recipient's handset to trigger the receiver's WAP browser to open and receive the content from the embedded URL. Several other messages are exchanged to indicate status of the delivery attempt.[2] Some installations also include a conversion service that will attempt to modify the multimedia content into a format suitable for the receiver. This is known as "content adaptation". E-mail and web-based gateways to the MMS (and SMS) system are common. On the reception side, the content servers can typically receive service requests both from WAP and normal HTTP browsers, so delivery via the web is simple. For sending from external sources to handsets, most carriers allow MIME encoded message to be sent to the receiver's phone number with a special domain.
For More information contact us at : sandip@routesms.com

SMS

SMS History SMS was an accidental success that took nearly everyone in the mobile industry by surprise. Few people predicted that this hard of use service would take off. There was hardly any promotion for or mention of SMS by network operators until after SMS started to be a success. SMS advertising went from showing business people in suits entering text messages to bright pink and yellow advertisements aimed at the youth markets that adopted SMS. SMS was the triumph of the consumer - every generation needs a technology that it can adopt as its own to communicate with - and the text generation took up SMS. Paradoxically, it was because SMS was so very difficult to use that the young people said that they were going to overcome the man machine interface and other issues and use the service anyway. The fact that the entry barriers to learning the service were so high were an advantage because it meant that parents and teachers and other adult authority figures were unlikely, unable and unwilling to use the service. A whole new alphabet emerged because SMS messages took a long time to enter and were quite abrupt as people attempted to say as much as possible with as few keystrokes. Abbreviations such as 'C U L8er' for 'See you later' sprung up for timesaving and coolness. The use of smileys to reduce the abruptness of the medium and to help indicate the mood of the person in a way that was difficult with just text became popular. The introduction of prepay mobile tariffs in which people could pay for their airtime in advance and thereby control their mobile phone expenditure was the catalyst that accelerated the take up of SMS. The network operators were unable technically to bill prepay customers for the SMS they were using because the links between the prepay platform and the billing system and the SMS Centers were not in place. The network operators responded with silence- the prepay literature did not mention SMS at all even though the prepay phones supported the service. One thing that is certain is that in these days with the Internet revolution to spread information, the young people will identify loopholes like this. And they did. Suddenly, millions more SMS messages were being sent- with some individual mobile phone subscriptions accounting for thousands of SMS per month alone as they set up automated message generators. Network operators worked with their platform suppliers to try and sort this out and implement charging for SMS for prepay customers. Meanwhile SMS incubated and spread and people were using it because it cost nothing whereas carrying out the same transaction using voice clearly did cost. Eventually after a few months the network operators finally got their act together and managed to implement SMS charging for prepay users- such that they could decrement the prepay credit by the cost of an SMS message.

Introduction to SMS and SMS Messaging Services The Short Message Service (SMS), as defined within the GSM digital mobile phone standard that is popular in Europe, the Middle East, Asia, Africa and some parts of North America, has several unique features: A single SMS can be up to 160 characters of text in length. Those 160 characters can comprise of words or numbers or an alphanumeric combination. Non-text based SMS' (for example, in binary format) are also supported. SMS is a store and forward service, in other words, SMS' are not sent directly from sender to recipient, but always via an SMS Center instead. Each mobile telephone network that supports SMS has one or more messaging centers to handle and manage the short messages. SMS features confirmation of message delivery. This means that unlike paging, users do not simply send an SMS 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 SMS has been delivered or not. SMS' can be sent and received simultaneously with GSM 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 SMS' 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 original SMS system was developed as part of the GSM family of standards, able to deliver messages of up to 160 characters. At the time, 2G GSM was in the process of evolving into the 2.5G GPRS of roughly double the performance. A short 160 character limit no longer made sense, so the "Third-Generation Partnership Program" (3GPP) proposed extending the existing SMS standard to allow messages of any length. Additionally, they proposed adding MIME support for file attachments, and real multimedia support. However, modifying display systems to handle any sort of media format was a more difficult problem, so 3GPP partnered with the WAP standards process to produce MMS. Since then, MMS has been deployed worldwide and across both GSM/GPRS and networks. The first commercial MMS launched worldwide was in March 2002 by Telenor, in Norway, using Acision infrastructure. MMS remains part of the 3G networks as well and will almost certainly be retained in the 4G networks currently being developed. Both 3GPP and 3rd Generation Partnership Project 2 3GPP2 have delegated the development of the Stage 3 Technical Realizations to the Open Mobile Alliance OMA, a standards organization focused on specifications for the mobile wireless networks.There are some interesting challenges with MMS that do not exist with SMS: Handset configuration can cause problems sending and receiving MMS messages. * Content adaptation: Multimedia content created by one brand of MMS phone may not be entirely compatible with the capabilities of the recipients' MMS phone. In the MMS architecture, the recipient MMSC is responsible for providing for content adaptation (e.g., image resizing, audio codec transcoding, etc.), if this feature is enabled by the mobile network operator. When content adaptation is supported by a network operator, its MMS subscribers enjoy compatibility with a larger network of MMS users than would otherwise be available. * Distribution lists: Current MMS specifications do not include distribution lists nor methods by which large numbers of recipients can be conveniently addressed, particularly by content providers, called Value-added service providers (VASPs) in 3GPP. Since most SMSC vendors have adopted FTP as an ad-hoc method by which large distribution lists are transferred to the SMSC prior to being used in a bulk-messaging SMS submission, it is expected that MMSC vendors will also adopt FTP. * Bulk messaging: The flow of peer-to-peer MMS messaging involves several over-the-air transactions that become inefficient when MMS is used to send messages to large numbers of subscribers, as is typically the case for VASPs. For example, when one MMS message is submitted to a very large number of recipients, it is possible to receive a delivery report and read-reply report for each and every recipient. Future MMS specification work is likely to optimize and reduce the transactional overhead for the bulk-messaging case. * Handset Configuration: Unlike SMS, MMS requires a number of handset parameters to be set. Poor handset configuration is often blamed as the first point of failure for many users. Service settings are sometimes preconfigured on the handset, but mobile operators are now looking at new device management technologies as a means of delivering the necessary settings for data services (MMS, WAP, etc.) via over-the-air programming (OTA).

For more Information Contact us on : sandip@routesms.com or vist www.routesms.com

Voice SMS comes with added value

Mobile VAS in India“.Here are key excerpts: Subscriber base: * Population: 1.112 billion * Fixed Subs : 39.41 million (Oct 2007) * Mobile Subs : 217.14 million (Oct 2007) * Internet Subs : 9.22 million (Jun 2007) * Broadband Subs :2.67 million (Sept 2007) Of the mobile subscribers: * Prepaid connection comprise 85% of total subscriber base (expected to increase to 90%); and over 95% of new additions. * By the end of 2010, the mobile teledensity will be almost 44% with 497 mn subscribers (driven by semi-urban and rural areas) VAS in India:Past, Present and Future * VAS constitutes 7% of of total telecom revenue for Indian operators. * SMS consituted 55% of VAS revenue in 2006 [P2P/A2P/P2A, A = Application, P=Person), the growth was majorly driven by reality shows like Indian Idol/Kelloggs/KBC etc. * Digital music (including CRBT and ringtones) constitutes 35% of VAS revenue. * CAGR of 44% (2007 – 2010), VAS revenues will reach USD 2,744 mn (926mn $ by 2007): This is dependent on several factors like regulatory (e.g. number portability) and non-regulatory factors. o Growth acceleration will begin in 2009, as various challenges are overcome, size of mature user base increases, and telco focus on high end user VAS heightens * Bollywood and Cricket is the killer content - though no significant investment has gone beyond developing local apps or even content/services. * Revenue share between telcos & content providers / aggregators is 70:30, substantially more skewed in favor of telco than in other countries - further aggravated by lack of payment mechanisms. * SMS/IVR/Music downloads/Internet Apps/Search will see an upsurge; limited growth of UGC and mCommerce * Almost half of Indians use ULCH (Ultra Low Cost Handsets) Entities in VAS Value chain * Content/Application Owner - cos. like saregama/mauj/Rajshri who develop coyrighted content * Aggregator - aggregates content like games/wallpapers/ringtones and distributes it to suit customer needs [players : mauj, hungama mobile, indiatimes mobile etc] * software developer – develops applications (like payment/games/middleware etc.) for mobile VAS [players - mchek/July systems/webaroo/affle etc] * Technology Enabler – provides the platform that plugs into telco networks and acts like a bridge between aggregator and telcos [players include OnMobile, cellnext. mauj etc] Operators still dominate the revenue sharing arrangement in VAS [Of the amount paid by end users, 60-70% is kept by operator, aggregator gets 20-25% and content app/owner gets 10-15% of the revenue] Challenges: * Lack of content localization * Shortage of spectrum * Slow adoption of GPRS mobiles (only 6.1 mn GPRS users compared to 200 mn overall subs) Future VAS trends: * Location Based Services * Mobile Music update will increase with better bandwidth * Migration to 3G will result in increased ARPU * Local content is on the rise – regional/rural IVR seen as a major opportunity (see our earlier coverage of Ubona) * Mobile commerce doesn not look too promising (India is still a cash and cheque country) * IVR will see large scale adoption, especially in rural areas. * Mobile E-Mail will primarily be driven by enterprises * Stocks on mobile will see an uptake The current state of VAS can be candidly summed in one sentence “Novelty of VAS on mobile is short-lived and innovation is the key to success which means technology companies like will have to increase their investments into R&D”What’s your take?

SMS as a Tool to Find out Polling Booth - Short Code 5676729

IT is not apathy but cluelessness about the location of polling stations that is, in many cases, the cause of low voter turnout. Often the eager voter sets out to play his part in the democratic process but ends up returning home in a huff, having wasted precious time trying to find the polling booth and finally giving up in exasperation. This is going to be history in the seven Assembly segments of the Secunderabad Lok Sabha constituency as voters can now easily locate the polling booths in a matter of seconds through mobile solutions by just sending either an SMS message or through Internet. This unique mobile solution concept has been developed by Hyderabad Metropolitan Development Authority (HMDA) Metropolitan Commissioner KS Jawahar Reddy who is also the Returning Officer for the Secunderabad Lok Sabha constituency. The proposal will be submitted to Chief Electoral Officer (CEO) IV Subba Rao for approval. Once it is approved, it will be introduced in the Secunderabad Lok Sabha election to be held on April 16. What is more important is that this is the first time in the state that general elections are being held after delimitation and voters would find difficulty in locating the polling booths. Explaining about its functioning, Jawahar Reddy said that there was a complete data base of Secunderabad Lok Sabha fed with them that includes names of the persons with all Electoral Photo Identity Cards (EPICs) with numbers, house addresses and polling stations and other relevant information. A voter who wanted to know the exact location of the polling station, has to just send an SMS by typing a short code (will be announced in a few days) and number 5676729 along with EPIC card number. Within a few seconds, the voter will receive a message with detailed address of the polling station. Those who do not have the EPIC card, the other alternative is to type their house number. They are also planning to host similar service through Internet. A new website is being created for this purpose. A private software company , Gray Logic, is providing mobile solutions to them.