From: Adam Rifkin (adam@KnowNow.com)
Date: Fri Aug 18 2000 - 22:17:03 PDT
"It is almost impossible to overstate the importance of SMS as a bearer
for data and therefore the need for operators to deliver a robust,
mature, stable and scaleable SMS service, the faster the better."
> SMS: Can Networks Handle The Explosive Growth?
> by Steven van Zanen, Product Manager SMSC, CMG Telecommunications
> Traffic levels have already turned the exponential corner and this is
> before WAP and m-commerce have taken off. Operators therefore need a
> comprehensive SMS strategy in order to avoid missing this unique
> WAP and the Wireless Internet may make the headlines, but right now SMS
> is driving the wireless data revolution. GSM Association predicts a
> doubling of SMS traffic before the end of this year to a total of 10
> billion messages.
> SMS traffic is a high-margin revenue source for network operators.
> Tariffs vary, but if one takes a very conservative average, then 10
> billion messages will generate over two billion dollars of income.
> D2 Mannesmann now caters for more than 400 million short messages a
> month, compared with 323 million for the whole of 1998! However, the
> best is still to come as 3G networks will experience even higher SMS
> throughputs, possibly over 20,000 messages a second.
> SMS is a near-perfect bearer for wireless information services. If you
> want a stock price, real-time football scores, or airline departure
> times, then a 160-character message does the job. Moreover, this
> information can be accessed using regular mobile phones.
> Be Ready for Anything
> In the past market research consistently underestimated the demand for
> GSM services. Today's growth projections may again turn out to be very
> This add up to three rather obvious conclusions: One, operators need to
> develop a comprehensive strategy. Increasing capacity incrementally
> seems the easy option, but when traffic levels go on rising and growth
> becomes exponential it quickly becomes impractical and expensive. Loads
> cannot be balanced when a dozen or more SMSCs are employed and software
> upgrades can take several weeks to implement. This means that the total
> cost of ownership increases, especially when more and more systems are
> added to accommodate increased traffic.
> Two, the SMSC should never be a bottleneck. Operators who compromise on
> capacity run the risk of having their network choke due to increasing
> traffic levels and if the quality of service falls subscribers will
> And finally the solution should be mature and proven to be stable,
> scalable and future proof. The SMSC must be ready for high-speed SS7 and
> other developments such as GPRS, and 3G.
> Two kinds of bottleneck
> SMSC's that can only deliver a few hundred short messages/second are
> obviously bottlenecks. Operators who started out with low-performance
> systems can either make a major upgrade to a high-performance system
> (1500 Msg/sec or more) or they can increase throughput by the addition
> of more stand-alone systems.
> When such a system also has a single point a failure then a number of
> subscribers will have no service during failure. These problems are
> compounded when additional low performing stand-alone systems are
> added. CMG's solutions are fault tolerant redundant systems that exceed
> the high demands of network operators.
> The second 'bottleneck' is self-imposed. Operators are limited by their
> current infrastructure capacity for SMS messages and may need to
> increase their SS7 capacity so that a High performance SMSC will run at
> an optimal level. In general this bottleneck has been found to be 1000
> msg/sec. Interestingly this has led to the erroneous perception that an
> SMSC does not need to exceed this figure.
> If this were the case, then one would question the reasons why seven of
> the world's largest GSM operators have elected to use the Highest
> performing SMSC available (CMG HP SMSC supports 2500 msg/sec). It also
> ignores the important fact that the industry is working hard on
> standards that will enable higher speeds to be reached over SS7
> How do you measure performance?
> Now data throughput has become a business critical issue operators need
> to take a very careful look at the way performance is measured; what
> assumptions does the tendering vendor make about the way the SMSC will
> perform on Operator's live network?
> CMG believes that in the absence of industry benchmarks, operators need
> to ask any SMSC vendor a number of questions, the most obvious being
> their actual definition of a Short Message.
> One would assume that this refers to a message sent from one party to
> another, but a performance figure may be based on 'map' messages. These
> are the internal messages sent between the SMSC and MSC, e.g. they are
> used to establish the location of the called party. A 'real' message can
> have four 'map' messages that the SMSC has to handle, but this is a
> dubious way of defining performance.
> Another question that needs to be asked is the way messages are
> stored. The store and forward mechanism is an integral part of the SMSC
> architecture, but the storage medium differs between vendors. Thus,
> either hard disk or solid-state memory can be employed. The latter is
> indeed fast but it is also volatile, so there is a serious danger that
> messages will be lost in the event of a crash.
> At CMG all SMSC stability and performance tests are performed under full
> store and forward capabilities, using actual customer traffic profiles
> that are replicated in a laboratory environment.
> SMS going forward
> CMG will deploy SMS over high-speed SS7 and is also actively involved in
> the development of solutions involving Gigabit Ethernet, SS7 over IP and
> At the end of this year a scalable SMS Prepaid solution that easily
> keeps up with CMG's 2500 msg/sec SMSC and allows for differentiated
> charging will be released.
> Synergistic links with WAP
> SMS offers a global footprint and global roaming. It is robust,
> scaleable and incorporates a store-and-forward mechanism, which makes it
> perfect for push.
> GPRS will not be operational until 2001 and the market will have to
> invest in new devices before this market sector can take off. This means
> that WAP information services will (in the near future) be delivered
> over SMS or a circuit-switched link. SMS is close to the delivery model
> of GPRS, but there is some confusion about the ability of this service
> to deliver a steady stream of content.
> There is a network delay of about seven seconds between the SMSC and the
> subscriber's mobile and this would be an issue if a concatenated series
> of messages were delivered in the regular way. CMG's delivery mechanism,
> however, is based on a synergistic link between the WAP Service BrokerTM
> and the SMSC. This allows for the delivery of a fast, smooth,
> uninterrupted flow of short messages to the subscriber's mobile.
> The wireless data revolution that is about to take off is based on
> standards such as WAP, the entry of the computing industry, smart phones
> and wireless PDAs, and packet-switched services. The latter will enable
> mobile IP and end-to-end solutions. However, the perception that the
> market has to wait for a new bearer service is not correct. SMS is ideal
> for many applications this robust, proven service is already in place;
> and SMS has unique features such as the store-and-forward mechanism.
> SMS is therefore kick-starting the revolution and in future it will
> complement GPRS and 3G services. Thus, it is almost impossible to
> overstate the importance of SMS as a bearer for data and therefore the
> need for operators to deliver a robust, mature, stable and scaleable SMS
> service, the faster the better.
Beware of performance issues with .NET's SOAP-based distributed communications. SOAP essentially means XML over HTTP. HTTP is not a high-performance data protocol, and XML implies an XML parsing layer, which implies more compute overhead. The combination of both could significantly reduce transaction rates relative to alternative messaging/communications channels. XML is a very rich, robust metalanguage for messaging, and HTTP is very portable and avoids many firewall issues. But if transaction rates are a priority for you, keep your options open. -- Jim Farley, "Microsoft .NET vs J2EE: How Do They Stack Up?", http://java.oreilly.com/news/farley_0800.html
This archive was generated by hypermail 2b29 : Sat Aug 19 2000 - 00:21:04 PDT