A New Home …

Hi, all.

I have moved my blog to a new home!

For those of you coming to this site, please click to the Aeris Communications web site home and you will see a link to my blog.

Click here to go to it directly!

The Apple iPhone 5 … with LTE! But Which Bands?


As you all probably know by now, the Apple iPhone 5 was introduced on September 12th. Many reviewers and sites have already commented extensively on the features of the new OS, the new large display, the “thinness”, etc.

However, there has been little discussion of the cellular bands and frequencies supported in the iPhone 5.

So, let’s spend some time on this topic.

Three iPhone 5 Models

As can be seen from the Apple iPhone 5 specifications, there are three models of the phone. Here are the cellular specifications under “Cellular and Wireless” for these models:

GSM model A1428

  • UMTS/HSPA+/DC-HSDPA (850, 900, 1900, 2100 MHz)
  • GSM/EDGE (850, 900, 1800, 1900 MHz)
  • LTE (Bands 4 and 17)

CDMA model A1429

  • CDMA EV-DO Rev. A and Rev. B (800, 1900, 2100 MHz)
  • UMTS/HSPA+/DC-HSDPA (850, 900, 1900, 2100 MHz)
  • GSM/EDGE (850, 900, 1800, 1900 MHz)
  • LTE (Bands 1, 3, 5, 13 and 25)

GSM model A1429

  • UMTS/HSPA+/DC-HSDPA (850, 900, 1900, 2100 MHz)
  • GSM/EDGE (850, 900, 1800, 1900 MHz)
  • LTE (Bands 1, 3 and 5)

Not surprisingly, the frequency bands supported for 2G and 3G are quite standard—this is not any different from Apple’s earlier products, or from products from other manufacturers.

However, the number of LTE bands supported in the iPhone 5 has increased from the iPad—this is definitely good news for customers!

Yet, there are some confusing decisions by Apple in regard to the LTE bands that were included, and using these phones in LTE mode in some non-US countries and Carriers may be difficult … or impossible.

Model Summary

Let’s summarize the cellular specifications of the three iPhone 5 models:

iPhone 5 Model UMTS / HSPA/
Rev. A &
Rev. B
LTE Band Carrier
GSM model A1428 850, 900, 1900, 2100 850, 900, 1800, 1900  — 4, 17 AT&T (US),
Bell, Rogers, Telus (Canada)
CDMA model A1429 850, 900, 1900, 2100 850, 900, 1800, 1900 800, 1900, 2100 1, 3, 5, 13, 25 Verizon (US),
Sprint (US),
KDDI (Japan)
GSM model A1429 850, 900, 1900, 2100 850, 900, 1800, 1900  — 1, 3, 5 Various

Relevant Bands

A table at the end of this post shows the LTE bands of interest for the rest of this discussion (for a full list, see my earlier posts here and here).

Good World-wide 2G and 3G Support

The 3G UMTS/HSPA/HSPA+/DC-HSDPA and 2G GSM/EDGE spectrum and protocol support is identical in all three models. These frequencies are supported by Carriers in most countries, so these three iPhone models should operate quite well in 2G and 3G mode everywhere.

The CDMA model A1429 also includes 2G/3G GSM protocols and frequencies—both Verizon and Sprint provide “World-Phone” capability in many of their handsets. So, no surprise here.

Different LTE Bands in the Two GSM Models

The two GSM models A1428 and A1429 support different LTE bands. The AT&T model A1428 supports LTE in Bands 4 and 17, and the International model A1429 supports LTE in Bands 1, 3 and 5.

I am a bit surprised that LTE support in Bands 1, 3 and 5 was not provided in the GSM model A1428, since that would have eliminated the need for the GSM model A1429.

This limits the countries where these two models can be deployed as LTE phones … the AT&T model A1428 can operate in LTE mode in Canada and some South American countries, but it cannot use LTE in Europe or Asia (where Band 4 is not yet deployed, and Band 17 is not possible). So, AT&T may not be able to offer LTE roaming to countries in Europe.

Why LTE in Band 1?

Most European Carriers have deployed 3G fairly extensively in Band 1, so this is not currently available for LTE, and may not be available for quite a while. This “future use” thinking by Apple seems unusual, particularly given the more likely (and sooner) deployments by Verizon in Band 4 (the FCC has approved their acquisition of the SpectrumCO AWS licenses) and Sprint in Band 26 (the ITU and FCC have approved the re-farmed iDEN spectrum for LTE and 1X Advanced). These  are not supported in the CDMA model A1429.

Band 3 Advantage for some Carriers

In some European countries, only one or two carriers have Band 3 DCS licenses at 1800MHz—they get an advantage. They can provide the iPhone 5 to their customer … their competition cannot.

There is a clear example of this issue in the UK. Vodafone and O2 do not have any DCS 1800MHz spectrum, since almost all the 1800MHz spectrum in the UK is owned by EverythingEverywhere. Thus Vodafone and O2 cannot offer the iPhone 5 to their customers as a 4G LTE handset.

Band 5 For Asian Carriers

Providing LTE support in Band 5 in the CDMA model A1429 was not strictly necessary—the US Carriers are not likely to free that old “Cellular” spectrum use with ANSI-2000 CDMA for quite a while. AT&T could free that spectrum from their 2G GSM use soon perhaps, but this band is not included in the GSM model A1428 for use with LTE.

However, there are some Asian Carriers who could deploy LTE in Band 5. In Japan, KDDI also offers CDMA service, so the inclusion of Band 5 in the CDMA model A1429 may be for that Carrier.

Missing LTE Bands in iPhone 5

Band 2

What about Band 2 PCS at 1900MHz (blocks A through F)? This is not supported in any of the iPhone 5 models for LTE. AT&T has started harvesting spectrum in the PCS bands, presumably for LTE, but none of the three iPhone 5 models support LTE in Band 2.

Since it is likely that this band will be cleared of 2G GSM by AT&T in major cities within the next two to three years, and certainly by January 1, 2017 in their entire footprint (as announced by AT&T), it would have seemed a prime candidate for LTE in any new handset design.

Sprint is likely to deploy LTE in unused PCS bands in some markets, and Verizon is also likely to free up EV-DO usage in their PCS bands in a few years after the 2G GSM shutdown.

Band 26

The Sprint iDEN Band 26 at 800MHz is not supported in any of the iPhone 5 models. This was a recent entry to the band plans for LTE, and probably did not get approved in time for this new design (or its chipset).

Of course, Sprint has not yet deployed LTE in Band 26, but they will do so soon, since the 800MHz in Band 26 is an excellent low-frequency competitor to the 700MHz bands deployed by Verizon, AT&T and others.

Band 41

The Clearwire planned deployment of LTE in Band 41 at 2.5GHz is not supported in any of the iPhone 5 models, although this may be moot since Clearwire has not yet deployed any LTE in that spectrum.

Furthermore, Clearwire is planning to deploy TDD LTE in that band. Although QUALCOMM and Clearwire have announced an agreement to support TDD LTE, this probably has not yet been added to current-generation LTE chipsets for handsets.

Band 12

The numerous small US Carriers who bought much of the 700MHz Lower A/B/C spectrum remain shut out from offering the iPhone 5 as an LTE handset—this Band 12 is not available in any of these models.

Since AT&T was successful in getting Band 17 (a subset of Band 12) separately approved by the ITU and the FCC, the lack of 700MHz interoperability makes it tough for small carriers to get sufficient attention from handset manufacturers.

A Few Final Observations

There are still two versions of the iPhone 5 for the US market—one for use on AT&T and one for use on Verizon/Sprint.

Thus, in the US, it is still not possible for a Verizon or Sprint customer to roam on AT&T, or for an AT&T customer to roam on Verizon or Sprint, regardless of whether they want to roam in LTE mode or 2G/3G modes (in the case of an AT&T customer wanting to roam on Verizon or Sprint).

And, if you want to change Carriers from AT&T to Verizon or Sprint, or vice-versa, you still need to change out the iPhone 5 device due to the separate LTE bands.

Maybe Apple should consider offering a trade-in plan on the iPhone 5 to allow moving from one Carrier to another! But given handset subsidy economics, this is very unlikely.

Ultimately, this lack of roaming between the major US Carriers is a disservice to consumers.

By the way, adding support for LTE in Bands 4 and 17 in the CDMA model A1429 would have made this roaming possible and potentially even simplified the number of Apple iPhone 5 models down to one! Yes, the CDMA and EV-DO support in the CDMA model A1429 would not have been used by AT&T customers, but the slight added cost for this would have have been accepted as a reasonable trade-off, if it enabled LTE roaming within the US.

For now, the Grand Unification of LTE as a common cellular protocol for handsets for all Carriers has yet to occur in the US—let alone the rest of the world. In my opinion, this may not happen till handset manufacturers make LTE-only cellular phones in the future.

Maybe the Apple iPhone 6 or iPhone 7 will get it right! Isn’t waiting for the next Apple product a popular national—perhaps global—pastime for everybody?🙂

What About M2M and LTE?

What has been released with multiple LTE band support in the iPhone 5 is an expensive smartphone for the consumer market. Radio modules with multiple bands for LTE are still a few years from production.

And, the radio module costs would be too high for any large-scale M2M application deployment. Ultimately this will change, but not for the next few years.

In my opinion, using LTE radio modules for most M2M Applications is still a number of years away from being a good decision.

What are your LTE plans for M2M deployments? I’d love to receive comments from people who are reading this post!

Copyright © 2012 Aeris Communications, Inc. and Syed Zaeem Hosain. All Rights Reserved.

As always, although I don’t specifically identify Trademarks in my posts, they are implied. For example, Apple, iPad, and iPhone are trademarks of Apple, Inc., registered in the US and other countries.

Relevant LTE Bands

The LTE bands of interest to the iPhone 5 discussion above (for a full list of all 35 bands, see my earlier posts here and here).

Band Up
Down high
Used by
1 1920 1980 2110 2170 IMT 2100 Some Asia, Europe, Japan
2 1850 1910 1930 1990 PCS US Carriers, Canada
Some South America
3 1710 1785 1805 1880 DCS Some Europe, Asia,
4 1710 1755 2110 2155 AWS AT&T, Verizon,
Canada, Some
South America
5 824 849 869 894 Cellular AT&T, Verizon, Some Asia
12 699 716 729 746 700 Lower A/B/C Small US Carriers
13 777 787 746 756 700 Upper C Verizon
17 704 716 734 746 700 Lower B/C AT&T
25 1850 1915 1930 1995 PCS G Sprint
26 814 849 859 894 iDEN Sprint
41 2496 2690 2496 2690 BRS Clearwire / (Sprint)

Keep Homes Secure This Summer With M2M Networks


Summer is the perfect time to pack up and get away for a fun family vacation, or a trip to the beach, and more people leave their homes during the summer than any other time of the year. Allianz Global Assistance USA notes that 57% of Americans will take a summer vacation this year—up 3% points from last year—and travel at least 100 miles away from home for more than a week.

But before families say Bon Voyage, they should be aware that summer is the optimal time for burglars to break into their homes—being away for an extended period provides ample opportunity for an empty home to be burglarized. According to the FBI, home break-ins are the most common threat to our homes, occurring in the US every 15.4 seconds, and burglary rates overall increase about 10% in the summer.

What can people do to stop the invasions? Of course, they can lock their doors and windows and ask their neighbors to keep an eye out for them. Unfortunately, common strategies such as Neighborhood Watch and target-hardening have had limited success in reducing these crimes.

So, how can home-owners be absolutely sure that their residences will be safe and secure while they are away? Or if an event does occur, how can the response to it be quick and effective? Since less than 15% of burglaries are ever cleared, returning home after a vacation to discover a home has been broken into—perhaps days earlier!—greatly reduces the chances of ever recovering any stolen items.

M2M Security Solutions

Machine-to-Machine (“M2M”) communications based security solutions can ease consumers’ worries about the safety of their homes. Indeed, wireless security Devices are an example of one of the earliest large-scale deployments of cellular M2M applications—Aeris’s very first Customer was an alarm Device manufacturer.

M2M security Devices capture the event, and transmit the data through the cellular network to an application server that can interpret the data into meaningful, actionable information.

For example, a home security device can detect a break-in (using door and window sensors), transmit that data using a wireless network to a remote server. The security application on the server can notify the home-owner, or provide the event information to monitoring service personnel who can contact police on behalf of the home-owner.

Many newer security Devices include video feeds to allow the home-owner or monitoring service to verify the break-in event. Due to a large increase in false alarms, and a reduction in the numbers of police officers due to the economy, such event verification is required by some cities and communities before police will be dispatched. These video images do not require high-resolution images, or high frame rates … as long as the event is verifiable (visible intruder, etc.), the dispatch is authorized.

M2M services can enable a wide range of monitoring and alarm notification options, enabling home-owners to check the status of their home via their smartphones while sunning on a beach.

Wireless Security Is Becoming The Norm

Older security systems relied on the availability of a traditional land-line telephone service to communicate alarms. However, there is an ever-increasing trend for people to only have cellular phones, without any Plain Old Telephone Service (“POTS”) in their homes. Today, an estimated 35% of cellular users in the USA do not have any land-line telephones in their homes, and this percentage is expected to increase.

Thus, wireless cellular M2M services are well suited for home security applications. The security Device can utilize a cellular radio that uses these M2M network services, independently from the service provider of the home-owner’s cellular handsets.

Aeris’s secure M2M network helps give homeowners peace of mind while on vacation. Because Aeris’s network was designed exclusively for machines, it does not carry consumer handset traffic, therefore delivering more predictable, reliable and secure communications. Not only is the Aeris network optimized for machine performance, it also offers the most robust set of APIs in the industry for guaranteed reliability in communication with remote Devices.

With connected home security devices and a secure M2M network, there is no reason for people to be concerned about leaving home to go on vacation or a special trip. They can stop worrying and get outside—summer is waiting!

What are your Comments?

Please post your comments. Thanks!

Copyright © 2012 Aeris Communications, Inc. and Syed Zaeem Hosain. All Rights Reserved.

“Aeris Explains Their M2M Solutions”


Recently, I recorded a video interview after a technical briefing with TMCnet.com. During this interview, I described Aeris and our M2M services and solutions.

I invite readers to view the video at this link.


What are your Comments?

Please post your comments. Thanks!

Copyright © 2012 Aeris Communications, Inc. and Syed Zaeem Hosain. All Rights Reserved.

Wireless IP for M2M Data—Best Practices (Part 2)

Last week, I continued a series on the best practices for M2M data transports and posted Part 1 on Wireless IP practices. Earlier posts have covered best practices for SMS.

This week is Part 2 in the series on Wireless IP best practices.

Best Practices for Wireless IP in M2M

This section continues the outline of practices that will maximize the benefits of using Wireless IP as an M2M data transport—for detailed assistance, please contact Aeris Sales Engineering.


We are often asked whether a Device should transmit User Datagram Protocol (“UDP”) packets or use Transmission Control Protocol (“TCP”) streaming sessions for M2M data transport.

The answer, not surprisingly, is: “It depends!

From the Internet Engineering Task Force (“IETF”) detailed definitions, let’s briefly describe these two protocols to understand why one may be better than the other for certain M2M data transmissions.

First, it is important to note that both UDP and TCP are used over an underlying IP connection.

User Datagram Protocol (“UDP”)

The UDP format was first defined in an IETF Request For Comment (“RFC”) specification, specifically RFC 768.

This protocol provides a procedure for applications programs to send messages to other programs with a minimum of protocol mechanism. This protocol is transaction-oriented, and delivery and duplicate protection are not guaranteed.

If an Application requires ordered, reliable delivery of streams of data, UDP is not the preferred protocol.

The format has lower overhead than TCP—i.e., fewer bytes are sent in the headers of the packets in UDP than TCP.

Transmission Control Protocol (“TCP”)

The TCP format was first defined in an IETF RFC specification, specifically RFC 761.

TCP is a connection-oriented, end-to-end reliable protocol and is intended for use as a highly reliable host-to-host protocol between hosts in IP networks, and especially in interconnected systems of such networks.

TCP requires that a connection be opened and managed for the duration of the IP data transmission. Within the protocol, transmitted and received packets are acknowledged by the Device and the servers.

The format has more overhead than UDP—i.e., more bytes are sent in the headers of the packets in TCP than UDP.

Which Protocol to Use?

In general, the choice of UDP vs. TCP must take into account:

  • The desired balance between the reliability of TCP and the lower cost of UDP, since UDP uses fewer bytes of overhead to transmit the same amount of application data.
  • The increased complexity of TCP, where the Module must open a data stream to a remote host where server programs await connections.
  • Careful design of TCP server programs to allow easy scaling as the number of deployed Devices is increased.
  • A desire for the acknowledgments provided by TCP sessions.

However, it is also important to note that using these two protocols is not mutually exclusive for a given M2M Application.

For some uses, a simple transmission of a UDP packet to a remote host may be quite sufficient—including using independent acknowledgment packets via UDP. If an acknowledgment is expected, but not received, either side can retry … intelligently (i.e., with limits on number of retries, variable delays between retries, etc.)

For other uses, even in the same Application, a Device may open a TCP connection to a server, and communicate with the higher reliability of a TCP streaming session to a program that accepts these connections and transmissions.

Often, the amount of data may require the use of TCP. For example, if an Application needs to transmit a large file (more than a few kilobytes), it is better to use TCP, since the consequences of an error during transmission via UDP could mean that the entire file might require a complete retransmission.

Data Encryption

Should transmitted data from an M2M Device be encrypted to enhance security? Let’s examine the perceived need.

While it is true that the radios in wireless cellular systems can be overheard—it is “radio” after all—the ANSI-2000 CDMA radio protocol is secure to all but the most serious of listeners. The vast majority of individual and entities do not have the expensive equipment, and are not capable of overhearing the spread spectrum “noisy” CDMA transmissions.

Furthermore, the “cellular” nature of the system also ensures that any listening to the radio in the Device will necessarily be localized—radio frequency (“RF”) transmissions from a particular Module do not travel more than a few miles in dense urban areas.

In the Aeris CDMA network, the network transmission of data is very secure. Once the Device transmission and data “leaves” the radio network, it is “received” at Aeris via Virtual Private Network (“VPN”) connections from the Carrier networks, and “sent” to the Customers systems via other VPN connections.

These VPN network connections are already encrypted and provide secure access.

Finally, content data encryption may require significant processor performance in the Module or Device to encode and decode data. This process might be beyond the capability of many M2M Application Devices.

Based on these issues, our experiences, and use of VPN’s where appropriate, Aeris does not recommend, or require, Application-level encryption of IP data to and from the Modules.

Regardless, we do not prevent Customers from encrypting the data if they want to do so!

What are your Comments?

Please post your comments. Thanks!

Copyright © 2012 Aeris Communications, Inc. and Syed Zaeem Hosain. All Rights Reserved.

Wireless IP for M2M Data—Best Practices (Part 1)

This week, I continue a series of posts on the best practices for M2M data transports (the previous post in this series was on SMS Data)—interspersed periodically with other topics.

Short Data Packets

Aeris’s original control channel MicroBurst® data transport was limited to 23 decimal digits (approximately 84 bits) of M2M Application data per packet transmission.

Today, SMS is limited to 140 eight-bit bytes (or 160 characters of seven-bits) of M2M Application data in every message packet transmission, in both GSM and CDMA cellular technologies.

While such short data packets are completely sufficient for many M2M Application data purposes, they may be limited for some use cases.

For example, after an alarm Device sends an SMS for a security event, it may need to open a video feed for alarm verification. Even if this is a slow frame-rate, black-and-white, and low-resolution video transmission, it may be too much data for SMS and needs another transport.

Wireless IP

Wireless Internet Protocol (“IP”) data transports are used when the amount of data to be sent per “event” is larger than an SMS message can contain.

In 2G GSM and CDMA cellular, the IP data transport technologies are “GPRS” and “1xRTT”. While these have slow data throughput rates compared to 3G and 4G cellular, they are quite sufficient for the IP transmission needs for most M2M Applications.

(Of course, readers of my blog know that 2G GSM and GPRS services are being shut down soon, so CDMA 1xRTT is the only current option for new M2M Devices.)

For higher transmission rate M2M Applications, devices can use 3G CDMA and GSM protocols, such as EV-DO and HSPA. Today, HSPA geographic coverage in the US does not match the EV-DO coverage.

EV-DO and HSPA radio modules are more expensive than GPRS and 1xRTT Modules, so they are only used when the higher transmission rates are required for a particular M2M Application.

Best Practices for Wireless IP in M2M

This section outlines practices that will maximize the benefits of using Wireless IP for M2M data transport—for detailed assistance, please contact Aeris Sales Engineering.

Wireless IP is Not the Same as Wired IP

First, it is important to recognize that Wireless IP data technologies are not really the same as Wired IP technologies.

A recent generation of software developers, who are used to working with DSL, Fiber and Cable IP services (along with Local Area IP Networks), have begun working on Wireless IP Devices. They sometimes attempt to apply Wired IP learnings and practices to Wireless IP implementations, and often go unexpectedly awry.

The typical issues these developers encounter are described in more detail in this post.

Wireless IP Radio Modules Are Modems

It is better to consider Wireless IP Radio Modules (“Modules”) as similar to old dial-up modems that used traditional telephone lines, rather than continuously-connected devices, used in DSL and Cable IP services for example.

(Note: even DSL and Cable units also perform the functional equivalent of “dial-up”, but these are usually set to “dial” immediately after power-on, and stay connected till power-off—acting as if they were connected via a physical wire to the Internet.)

To establish a session, the M2M firmware must initiate the cellular transmission from the Module using a “dial-string” … very similar to making a phone call with dial-up modems. The controller running the M2M Application code sends an AT command (for example, “ATDT #777”) to the Module over a serial or USB port.

Indeed, using “AT” commands with Modules is very similar to using AT commands (originally developed by Hayes Corporation) for traditional dial-up modems.

After receiving the “ATDT #777” command, the Module originates a call using the dialed digits “#777” to the Mobile Switching Center (“MSC”) that is serving the Device in the local cellular network. The MSC interprets the digits “#777” as a request to establish a data session and allows the process to continue.

The detailed mechanisms of establishing an IP session in Wireless IP technologies is unnecessary to describe here. Suffice it to say that the cellular systems have the necessary equipment, protocols, and communication mechanisms to make it all happen using the relevant cellular data standards.

Dueling PPP Stacks

Using a PPP session for IP data transmissions after “dialing in” using a Module, is just like using PPP on traditional dial-up modems on dial-up telephone lines!

In traditional dial-up modem connections, the computer that is connected to the modem uses a PPP stack to establish an IP session to the network and remote server. This is generally under the control of the computer, since the user can choose whether the dial-up modem connection is used for an IP data session or with a terminal emulation program for accessing the server.

Similarly, the Wireless Device must use a PPP stack for the IP data session to the cellular network. And, here is one potential source of trouble!

Many manufacturers provide an IP stack in the Module. However, Developers writing code for their M2M Applications sometimes add a separate IP stack to the firmware of their Devices.

When the Module establishes a cellular data session with the network, both stacks may attempt to set up PPP sessions!

This causes problems for Device operation on the network. The systems providing the end-point of the IP session may get confused and assign multiple IP addresses; they may disconnect only one session when the Module eventually terminates the session; the systems may reject both session attempts; etc.

Thus, if there are two IP stacks in the Device, software developers must cleanly ensure that only one attempts to establish the PPP session—the choice of whether the IP stack in the Module or the Application is used, is up to the developer.

IP Session Started by the Device

In cellular data technologies, the session is always initiated by the Module (of course, under control of the external M2M Application code)—the analogy to dial-up modem service holds true.

Thus, until such an IP session is started and connected, there isn’t any IP data path for a network system or server to send IP data to the Device. M2M Applications are generally designed with this concept in mind.

However, if the network or server needs to initiate the transmission of IP data to a Device, mechanisms called “Shoulder-Taps” must be used to cause the Device to start the actual session if it is not in a session. Typically, these shoulder-taps are Mobile-Terminated SMS (“MT-SMS”) messages sent to the Device.

(Aeris has alternative shoulder-tap mechanisms that reduce the cost of  using SMS for shoulder taps by more than 67%—please contact Aeris for more information.)

Send Content in MT-SMS Shoulder Taps

When an MT-SMS is used to “shoulder tap” a Device to initiate an IP data session, it is useful to send information to the Device in the SMS fields, rather than simply sending an empty MT-SMS (since the length of the SMS content generally does not change its cost).

For example, consider sending Absolute Time (perhaps the server time in “seconds past midnight UTC”) for the remote Device programming to make decisions about the time-validity of a command to take action.

Of course, remember to compensate for the [current] 15 second difference between Absolute Time UTC and CDMA time—the latter is based on Global Positioning System (“GPS”) time and, hence, does not correct for leap-seconds. This is even more relevant if the Device has an on-board GPS system from which it receives time data.

It may be useful to send the URL for the radio to connect to, or IP port number to use, or the protocol (such as whether the Device should open a TCP session, or send data via a UDP packet, or use an HTTP session).

Indeed, since the SMS capacity is 140 eight-bit bytes, or 160 seven-bit characters, all of the above content (including other information that is unique to the M2M Application) can be sent in a single MT-SMS shoulder tap.

Next Post In the Series

In the next post on this topic, I will cover UDP or TCP, data encryption, and other best practices for using Wireless IP for M2M Applications.

What are your Comments?

Please post your comments. Thanks!

Copyright © 2012 Aeris Communications, Inc. and Syed Zaeem Hosain. All Rights Reserved.

2G GSM & GPRS — The Shutdown Begins

I don’t know if you noticed it.

A few days ago, AT&T announced that it has started refarming (i.e, shutting down) its 2G GSM cellular services at 1900 MHz spectrum in the New York City area, for 3G and 4G services.

M2M Applications using 2G GSM and GPRS—such as Business and Residential Alarm units in large metropolitan markets—are going to be the first M2M services to be hit by this soon.

This event should not surprise anyone.

Regardless, as mentioned in my last post, this is also the start of an activity that has enormous cost implications for the M2M industry in the next year or two.

The GPRS Shutdown Was Inevitable

More than six years ago, when Aeris’ customers were reviewing options for new cellular technologies before the AMPS Sunset in 2008, I believed that a GSM (and, hence, GPRS & EDGE) shutdown was inevitable.

In presentations to our Customers, I stated the only uncertainty was the actual date when GSM and GPRS services would be unavailable in any given major market.

Spectrum Efficiency

The underlying encoding protocol of GSM is Time Division Multiple Access (“TDMA”). The spectrum efficiency (or how much bandwidth is used to transmit data) of TDMA simply is not as high as Code Division Multiple Access (“CDMA”).

Thus, GSM Carriers (like AT&T and T-Mobile) had to transition their 2G customers to more spectrum efficient technologies at some point. This would allow them to compete more effectively with CDMA Carriers (like Verizon, Sprint, US Cellular and Alltel).

To help our customers, I recommended that our AMPS Customers switch to CDMA to avoid another sunset too quickly—i.e., the GPRS Sunset that could occur within the product life-cycle of many M2M Applications.  Needless to say, those who switched to CDMA are very happy to have made that decision.

Lower GSM Radio Costs

However, at the time, the cost of GSM radios was too low to be ignored by a large portion of the overall M2M market—particularly by cost-conscious M2M Applications that needed low-cost radios.

This lower cost of GSM radios was due, in part, to:

  • Less complex cellular chipsets used in GSM than in CDMA (smaller chips cost less).
  • Large numbers of GSM handsets sold throughout the world (higher volume provides scaling cost reductions).

For example, the following information from GSM World in early 2009 shows that the deployed number of GSM units was greater than the other technologies combined:





CDMA2000 1X


CDMA2000 1xEV-DO


CDMA2000 1xEV-DO Rev. A


















While it is not clear how many of those GSM units were GPRS-capable, choosing to deploy 2G GPRS data units was an easy choice for some M2M Customers.  This substantially reduced the radio costs for their M2M Applications.

The T-Mobile Acquisition Failure

Last year, it became clear that AT&T did not have enough spectrum in many markets for their 3G and 4G network deployments. Over the previous few years, the introduction of smart-phones using 3G data had skyrocketed. As a result, their 3G networks have not kept up with increasing demand and load. AT&T attempted to acquire T-Mobile to obtain additional spectrum, but was unsuccessful.

During the discussion on the acquisition effort, AT&T executives made very clear statements regarding the impacts if the acquisition were denied. In her blog, Joan March, AT&T’s VP of Federal Regulatory stated what would happen:

First, AT&T would promptly shut down its 2G GSM network—a network that currently supports tens of millions of devices, including handsets for our pre-paid products that are particularly important to fixed and low income customers.  As a result, all those handsets would go dark and that customer base would be required to go purchase new mobile broadband (UMTS) handsets, which are generally more expensive.

In this news report, Kris Rinne, AT&T’s SVP of architecture and planning, underscored this same need at a GSM Association event. As the report put it:

Rinne’s logic was not completely flawed. As AT&T fills the 18 MHz it has set aside for 4G, it could fall back to its AWS spectrum. And then, if that band were to get full, it can leverage its PCS spectrum. But right now, AT&T is using those bands for its 2G and 3G networks. It will have to transition those customers to 4G before those airwaves could be reused, which can be a painful process. Rinne said, “We will have the opportunity to re-utilize this spectrum in the future.”


About two months ago, it was reported that AT&T began notifying its 2G GSM customers in New York City that their phones would need to be changed to devices operating on their more advanced networks.

This was a clear indicator of what was about to occur shortly.

The GPRS Sunset

And now, the moment is here. The GPRS Sunset has begun.

Without fanfare, and most importantly, without any FCC mandate guaranteeing 2G GSM service continuity through a date that is certain (or one that is far enough in the future to make it palatable). There will not be a five year 2G GSM sunset, similar to what was available for AMPS about a decade ago.

As the spectrum crisis worsens for AT&T, with the continued sale and deployment of high-usage data devices, such as smartphones and tablets, they must continue to refarm their 1900 MHz 2G GSM networks across the country.

Eventually, they will also need to refarm their 850 MHz spectrum. When this happens, this action will effectively shut down all their 2G services.

And, M2M Application Devices operating on AT&T in that market will go dark.

Can Customers Move Service to T-Mobile?

T-Mobile has stated that they have no current plans to shut 2G GSM.

Thus, moving the 2G GPRS units to operate on T-Mobile seems like an option. However, this requires replacing the SIM in the Device, since it is unlikely that AT&T would allow expensive roaming operation for low-ARPU M2M Devices to operate on a competing Carrier using an AT&T SIM.

Sending field technicians to “touch” the units to replace the SIM is an expensive action, if End-user customers cannot be expected to do the work.

Physical SIM or Device Swaps

In some cases, the SIM may be sealed inside Devices, or the Devices may be physically installed in relatively inaccessible places. This would require physical Device swaps instead of simpler SIM swaps.

T-Mobile and Other Coverage

Since T-Mobile does not have the coverage footprint of AT&T, changing service to T-mobile is not a solution for those units that are in markets not covered by T-Mobile.

Selecting another local GSM Carrier may not be an option, since the number of local contracts needed to maintain a nationwide M2M deployment would be impractical (and it would still require many SIM swaps!).

In other cases, the local GSM Carriers may not be able to provide GPRS data services at a price that would work for the Carrier or the M2M Customer.

In such markets, the 2G M2M Devices would necessarily cease to operate.

T-Mobile Futures for 2G Service

Furthermore, moving M2M service to T-Mobile is temporary at best.

T-Mobile has been focused on deploying HSPA+ in their available spectrum, and is planning to deploy LTE in the additional spectrum received from AT&T as a result of the failed acquisition attempt.

But, after this work is complete, they must also begin converting their network from 2G to 4G to remain competitive with the other Carriers.

Thus, within the next few years, T-Mobile will also need to start the process of stopping 2G services to re-use their spectrum for 4G services.

CDMA Remains the Answer

As I have often stated in the past five or six years, and our customers are more than happy to have done so, M2M Applications must use CDMA for service longevity. Until 4G LTE radio prices drop low enough to make it a viable option, this is the best approach.

We are now at a critical juncture for Customers on 2G GSM GPRS service—there is simply no time left for delaying any further.

Although this GPRS shutdown over the next year or two will be gradual for the Carriers (and it will not happen everywhere simultaneously), it will still occur at a speed that may be far too rapid for M2M Customers.

Please see my recent posts on spectrum (particularly from last week), to understand why it is important to begin deploying CDMA units as soon as possible … to avoid the Death of a Thousand GPRS Cuts.

What are your Comments?

Agreements? Disagreements? Please post your comments. Thanks!

Copyright © 2012 Aeris Communications, Inc. and Syed Zaeem Hosain. All Rights Reserved.

The Billion+ Dollar M2M Device Swap


At the International CTIA Wireless 2012 show, M2M Zone spoke with executives in the industry and held a panel session to get their inputs on 2G technology usage in M2M Applications. Rather than “concentrate solely” on how long 2G was going to be around, there was a question on whether M2M should skip 3G and go straight to 4G. The responses were mixed, with people on both sides of the fence.

Some stated that moving directly to 4G LTE was better, since the longevity of 3G was suspect (potentially being dropped as soon as five years from today). Indeed, for the past year, the Carrier focus has been to deploy 4G LTE rather than expand any coverage of 3G HSPA.

Others felt that the radio module price step from 2G GPRS to 3G HSPA/HSPA+ to 4G LTE would make an interim move to 3G— with a later move to 4G—more viable.

Current 2G GPRS Installed Base

In discussing the future of M2M cellular technology, an important issue was overlooked: the current, large installed base of 2G GPRS M2M Devices.

On GSM networks, these must be swapped out since the Carriers in the US are facing a spectrum crisis that will force them to re-farm 2G GSM spectrum for 4G LTE within the next two years.

But, requiring M2M Customers to replace their existing 2G GPRS Devices with 4G LTE Devices ignores business reality.

Let’s examine this issue in more depth.

New Devices and Spectrum Concerns

Carriers are focused on selling data-intensive Devices such as tablets and smartphones to their customers and the data usage is rising at a rate that the Carriers did not plan for. Consider also that studies have shown that tablets generate triple the data traffic of smartphones, and the difficulty that traditional Carriers are experiencing handling this data.

Thus, it is not surprising that cellular operators need to convert their deployed spectrum and networks to 4G LTE as soon as possible. This is particularly important for the 2G GSM Carriers who are limited by their spectrum holdings for 4G LTE in many markets.

To achieve this goal, these Carriers have to move any remaining 2G users—including M2M Applications and Devices—off their 2G networks.

2G Network Shutdown

Based on comments by Carrier executives (pre- and post- the T-Mobile acquisition attempt), it is very likely that 2G GPRS services will be shut down within the next two years in most major markets, and shortly after that, everywhere else in the country. This will allow handset and tablet manufacturers to provide new 4G LTE units on that spectrum for their customers.

Thus, the Carriers want their 2G M2M Customers to migrate to 3G or, preferably, 4G, in that two year interval.

However, moving current 2G GPRS Devices to just 3G HSPA/HSPA+ is not a viable business option for M2M Applications that need technology longevity, since the 3G HSPA/HSPA+ network will also be replaced with 4G LTE.

Small Customers

Let’s look at a relatively small Customer deployment of 2G GPRS Devices: an M2M Application with 10 thousand Devices in service.

With today’s 2G GSM module prices hovering around $12 to $15, 3G HSPA modules around $40, and 4G LTE modules around $125 to $150, there is a two to three times cost difference between a 2G module and a 3G module.

And a ten times cost difference between a 2G module and a 4G module!

Total Cost of Radios

Even assuming that we can ignore:

  • The cost of designing a new 3G or 4G Device (since the module command set, form factor, power requirement, etc., of a new module is likely to be different from existing 2G modules),
  • The ability to add any additional new 2G units (some Carriers already do not allow this), since the Customer may be busy swapping out their existing 2G Devices over the next two years.
  • The length of  time it takes to get a new Device designed, certified, and into production.
  • The total cost of building the new Devices, even when excluding the radio modules.
  • Etc.

… i.e., just the cost of the radio modules in these 10 thousand replacement Devices is high:

  • 2G: approximately $120k to $150k (the deployed “sunk” cost of existing units),
  • 3G: would be about $400k, and
  • 4G: would be about $1.25M to $1.5M.

Thus, replacing existing 2G GPRS Devices with new 3G or 4G Devices will be a huge cost burden for M2M Customers. Given the low Average Revenue Per Unit (“ARPU”) of M2M Applications, the margin from services may not be sufficient to cover the cost of Device replacements, especially if they are unable to pass these replacement costs through to their End-users.

Indeed, many of these Customers might still be attempting to reach or sustain profitability, and this burden may cause their business to fail.

During the last migration where Carriers forced their Customers to switch from Analog AMPS to Digital cellular—despite a 5 year “AMPS Sunset” period mandated by the FCC, a large portion of the market did not survive the transition.

A Medium Customer Case

If we consider a larger Customer who has a successful,  growing, and profitable, M2M business (let’s say 100 thousand M2M Devices), the radio replacement costs are even higher.

Assuming a lower module cost per unit (due to the higher volume), the module costs for:

  • 2G: approximately $1M to $1.3M (in deployed sunk cost for existing 2G units),
  • 3G: would be $3M to $3.5M, and
  • 4G: would be $10M to $12M.

While this larger M2M Customer might be able to absorb this hit, it may be difficult for them to generate any significant margin or profit during this transition period—even if they are able to get their End-user customers to tolerate and pay for Device replacement costs.

What About The M2M Industry as a Whole?

Let’s skip the large M2M Customers and look at all 2G GPRS M2M deployments as an industry whole.

About 4 to 5 million 2G GPRS Devices are currently deployed and operational in residential and business Alarms. This is a reasonable estimate based on the 750 thousand to 1 million Analog AMPS security Devices that were changed to 2G GPRS in 2007, just prior to the AMPS Sunset.

Further, if we include the large number of utility meter, oil and gas, agriculture and health care units, there are an estimated 11 to 12 million 2G GPRS M2M Devices in use in the US today. These numbers do not include any high-end tablets or smartphones, of course.

Conservatively assuming a total industry deployment of 10 million 2G GPRS Devices, the module costs become very high. Even with a quick drop in 3G HSPA module price (to a low $25 average) and 4G LTE module prices (analysts project an $85 to $90 LTE module price may be reached by 2014) in the next two years, the total module costs are:

  • 2G: approximately $150M (an estimated, conservative, sunk cost),
  • 3G: would cost approximately $250M, and
  • 4G: would cost between $850M to $900M.

If the 4G LTE module costs drop spread out over the next two years, rather than an unlikely sudden drop at the beginning of that interval, the last number above may be closer to $1B (this is ‘Billion with a B’) … possibly more.

Again, this is only the radio module costs … it does not include the other development and hardware costs inside the Device, etc.

Replacement Logistics and Costs

As an example, let’s look at the cost of replacing Devices in the field—i.e., a cost unrelated to the radio and hardware costs.

As we know, deploying new M2M Devices at the factory is easier than “touching” the deployed units for replacement and repair once they are in the field.

Thus, ignoring the fact that:

  • There may not be sufficient trained installers available for all the M2M Applications, and
  • The Device designs may not be ready, certified and in production well before the need arises,

… the travel charges, scheduling End-users, coordination with installers, etc. could be very high. Today, a conservative cost of a field swap ranges from $100 to $500 per Device.

Even assuming efficiencies (due to volume) allow a minimal $100 average cost, field replacing 10 million 2G GPRS Devices could be an additional $1B, or more.

Further, assuming a two year timetable, replacing 10 million Devices requires over 13,500 Devices to be replaced in the field every day, seven days a week, for the entire period … starting immediately!

Repeated M2M Industry Financial Shocks

Back in 2008, the M2M industry transitioned from Analog AMPS to Digital Cellular—using a 5 year AMPS Sunset period imposed on the cellular industry by the FCC. Many cost-conscious M2M Applications, such as in the Alarm industry, chose to switch to lower-cost 2G GPRS radios—against the advice of people like myself who recommended 2G ANSI-2000 CDMA for technology longevity.

These Applications, Customers and their End-users now have to deal with the current need to transition away from these 2G GPRS technologies.

This time, there isn’t a long sunset period mandated by a Federal body, that allows a graceful and controlled migration.

Even if my figures and estimates are off a little, the bottom line is that the need to change 10 million 2G GPRS Devices to 3G HSPA—let alone directly to 4G LTE—is going to cost the M2M industry more than a few Billion dollars in the next few years.

Since Carriers do not subsidize sales of M2M modules and Devices, this will be a direct cost to the M2M Customers and their End-user customers.

Further, if some Customers choose to migrate to 3G HSPA over the next two years (to save on module costs), and later change them again to 4G LTE a few years after that (incurring another round of costs), this will have a disastrous effect on the M2M industry as a whole.

Where Do We Go From Here?

It is clear that the cost of multiple technology migrations of the same End-user Devices in relatively short periods, is very financially difficult for 2G GPRS M2M Customers to deal with.

In the CDMA world, some Carriers in the US have committed to keeping ANSI-2000 CDMA 1xRTT data services available for a long time—some a decade or more.

Thus, a better technology migration strategy is to change the 2G GPRS Devices to 2G and 3G ANSI-2000 CDMA Devices over a longer three to four years instead of jumping directly to 4G LTE. This would provide:

  • The ability to continue selling CDMA M2M Devices for three to four years beyond that migration period (providing a good six to eight year device life-cycle for the End-users).
  • Breathing room and time to develop 4G LTE Devices and solutions during the next five to six years (enabling an easier transition when 4G LTE module prices have dropped close to today’s 3G levels—based on LTE handset and tablet sales growth during that interval).

Frankly, this is the safest strategy for all Customers using 2G GPRS technologies today—any other approach is extremely risky, in my opinion.

What are your Comments?

Agreements? Disagreements? Please post your comments. Thanks!

Copyright © 2012 Aeris Communications, Inc. and Syed Zaeem Hosain. All Rights Reserved.

Is Aeris’s CDMA Implementation Secure?

We are often asked the question: “Is CDMA secure?” … with an underlying ask: “Is Aeris’s CDMA service secure?

In this post, I will address the question of data security in the CDMA world, and what Aeris has done to improve this further for M2M Applications operating on our network.


But, before I start, here are some basic assumptions that I make about the M2M Devices:

  • They are using CDMA packet data services and Short Message Service (“SMS”) packets for data transmissions.
  • They are communicating with one, or more, Customer servers inside their private network.

Thus, the data security chain is from the Device to the Customer server systems.

Security by Design

The Aeris network is designed such that all network elements, including the M2M Devices, are protected from access outside Aeris to the maximum extent possible.

Security is further enhanced by segmenting the Aeris network by Customer accounts and further segmenting Customer accounts by Servicenames.

Using these Servicenames to separate traffic prevents inadvertent access from one Customer server (and the Devices) to another Customer server (and their devices) from inside the Aeris network.

The Elements in the Data Chain

These are the elements in the data transmission chain for 1xRTT, EV-DO and SMS:

  • CDMA Radio Access Network (“RAN”).
  • Aeris’s Carrier partner infrastructure.
  • Inter-Carrier network infrastructure.
  • Aeris’s internal network and infrastructure.
  • Aeris ↔ Customer data connection.

Each element in the chain has its own security features that is appropriate for its operation and function.

In the rest of this post, I will examine these elements in a bit more depth, specifically for understanding the support for data security at those elements.

CDMA Radio Access Network

This element of the chain provides the wireless communication path between the M2M Devices and the CDMA base stations (commonly called “towers”).

People often think that the radio interface is the weakest link in the chain, since it is, after all, a radio transmission. Thus, there is a belief that this radio transmission can be easily intercepted and decoded.

Fortunately, this is not true for CDMA networks—the protocol incorporates a robust authentication and encryption protocol that resists such problems.

Service Authentication

CDMA Devices have a  64-bit authentication key that generates a 128-bit Shared Secret Data (“SSD”) key value, a portion of which is sent to request access to the cellular network.

If the network element—specifically an Authentication Center (“AC”)—does not match the received value to its calculation of the key, the attempt to access the network is rejected and the Device does not receive any service.

Air Interface

Unlike the other common technologies—specifically, FDMA and TDMA—the Code Division Multiple Access (“CDMA”) protocol uses “codes” to combine the transmissions from all the Devices at a location into a single frequency channel (or spectrum).

In standard ANSI-2000 CDMA, this is a 1.25 MHz bandwidth channel—although depending on the density of the market, there may be multiple such channels providing service at a tower.

In the radio interface, the user data is multiplied by a pseudo-random noise (“PN”) sequence prior to actually transmitting the bits. The output of the multiplication is a new signal that is randomly “spread” over a frequency band (the 1.25 MHz channel) that is determined by the PN sequence length.

The receiving radios multiply the received data with the same synchronized PN sequence and extracts (or “despreads”) the original user data.

The CDMA system uses the unique code for the duration of a given data session or call, and avoids assigning the same code to other simultaneous sessions. Thus, multiple users can share a single radio channel.

Since there are over 4,400 billion code combinations available, it is very difficult to intercept a specific session’s PN sequence and decode the user data.

This technology is termed Direct-sequence Spread Spectrum and provides the necessary anti-jamming protections to make it a very secure radio transmission technology.

Carrier Partner Infrastructure

The Aeris network uses the Carrier infrastructure from the base station to the hand-off point to Aeris, although there may be multiple servers and systems in the path.

This includes the Carrier infrastructure elements, the Signaling System 7 (“SS7”) network for SMS data and cellular control information, as well as the Packet Data Support Node (“PDSN”) and Home Agent (“HA”) systems for the 1xRTT and EV-DO data traffic.

While these paths vary from each Carrier and base station, as a general rule, all the communication links are over private, dedicated lines, or over encrypted Virtual Private Network (“VPN”) connections.

Inter-Carrier Networks

The communication paths between Aeris and our Carrier partners, over which data and SMS messages flow, include the following:

  • SMS messaging services using private SS7 networks.
  • 1xRTT and EV-DO packet services using VPNs and private lines.

These communication paths are very secure—particularly the SS7 network that is designed to be secure and uses special protocols (ANSI-41) that are not available to the general public.

The telecommunications industry has standardized on SS7 for control and signal messages, as well as the transport of SMS data.

Aeris’s Internal Infrastructure

Aeris has several unique security features that are designed specifically for M2M applications.

The Aeris internal network uses only private IP addresses and all access points to the Internet are fully fire-walled. Aeris coordinates IP addressing to essentially extend the Customer’s network into Aeris using VPNs or private data lines.

Physical Location

The Aeris systems are physically located in Class 1 Colocation facilities—these are commercial sites with carefully controlled access (using retina scan and fingerprint scan technology) and protected by armed security guards.

Data Transport

In addition, each data transport service has its unique security features, as described below.

SMS messaging security features include:

  • Device validation via the Home Location Register (“HLR”) and Authentication Center (“AC”).
  • Delivery validation via MIN—Servicename matching.
  • Device-to-Device SMS packet blocking.

The Packet Data services security features include:

  • ANSI-2000 Mobile IP (“MIP”) authentication, using full 128 bit SSD information.
  • No Device-to-Device IP communications.
  • No Device-to-Internet IP communications, unless specifically requested by the Customer.
  • No endpoint server to other endpoint server access (i.e. into another Customer’s VPN).
  • No general access to the Internet for Customer Devices, unless specifically requested by the Customer.

Aeris ↔ Customer Connection

The last element is the connection between the Customer servers and the Aeris network systems.

Through proper configuration, the Aeris network becomes an extension of the Customer’s corporate network: Customers connect to the Aeris network via either a VPN or a dedicated line.

SMS data is transmitted to (and from) the Customer systems using the AerFrame Web Services interface (a standard XML/SOAP interface), or via SMS Peer-to-Peer Protocol (“SMPP”).

1xRTT and EV-DO packet services data is transmitted to the Customer via a TCP/IP or UDP/IP session (optionally, using additional IP stack client software like FTP).

Finally … Application Data Encryption

We are often asked—particularly during the Application design phase—whether data to and from the Devices should be encrypted or not.

We believe that the inherent security of the Aeris CDMA network relieves the Customer of the need to encrypt Application data.

The encryption can add additional data overhead to the data transmissions, increasing operating costs.

It also adds complexity to the development process, increasing development and debugging costs.

However, we do not restrict Customers from making this choice.

Thus, if the particular industry requirements of the Customer M2M Application demands encryption, or if the Customer decides that end-to-end data encryption is necessary, then they can certainly implement encryption in their data transmissions.

The Bottom Line

In general, Customer data transmitted in compliance with the Aeris network security protocols will not traverse an open connection on the Internet or an equivalent public network.

Thus, data sent via a CDMA network, including the Aeris CDMA network, is quite well protected and sufficiently secure for M2M Applications.

What are your Comments?

I ask all readers of this post to provide comments, or ask questions, about the topics covered in this post.

Copyright © 2012 Aeris Communications, Inc. and Syed Zaeem Hosain. All Rights Reserved.

Apple iPad is 4G … But Not In The UK!

The Apple iPad and “4G”

Some months ago (on the day of the first sales of the new iPad), I expressed a concern about people trying to move the new Apple iPad from AT&T to Verizon (or back) in this post on LTE spectrum fragmentation. The LTE implementations are different in these two units and Customers did not realize this until it was too late:

So, if you just ran out today and splurged on the latest third-generation Apple iPad for use with Verizon or AT&T (in the US), I hope that you stay happy with the Carrier you selected. Since you will not be able to move service to the other provider any time, now or later … not with the same unit, that is!

In April, in this follow-on post, I noted that the issue had indeed become a problem with iPad sales in Australia, and thought that the problem might worsen for them:

Other Countries and LTE at 700MHz

The problem is actually worse than described above for the Apple iPad in Australia. The two versions of the new iPad can only use the Verizon and AT&T 700MHz bands, respectively and separately … and these bands are not in use in any other country in the world today!

Unfortunately, I am not aware of any disclaimer wording in Apple web site stores in countries other than the US … the problem may get worse for them in the very near future.

Of course, this lack of use of the same two 700 MHz bands outside the US, and the addition of the disclaimer by Apple, was (and is) subject to change.

From Australia to Europe

Sure enough, Apple has discovered that this issue is something that is becoming a problem for them outside Australia too.

According to the news in this article, Apple has been barred from using the term “4G” in ads in the UK. Even though Apple went ahead and added a tiny disclaimer into their web site stores in the UK (and some other countries too, from what I understand), they did not entirely remove all references to 4G.

Not surprisingly, this disclaimer is proving to be be insufficient. Customers are either overlooking it, or more likely, complaining knowledgeably that the ads could still be misleading, since the current US versions of the iPad may never be usable in their countries. For example, in the UK, the 700 MHz bands used by Verizon (band 13) and AT&T (band 17) are used by local digital television transmissions, and are very unlikely to become available for LTE usage with the current iPad.

In other European countries, for example Sweden, customer complaints are starting to occur. The Swedish Consumer Agency may be launching an investigation into whether Apple’s advertising is misleading.

Is Apple at Fault?

Not really … we can’t really blame Apple too strongly for this situation, in my opinion. They needed LTE to provide fast network performance in the new iPad, and their choices were constrained by the LTE frequencies used in the US, and the chipsets and cellular radios available to them.

As mentioned above, the choice of 700 MHz Verizon or AT&T LTE in the current iPad means it is unlikely to ever work in LTE mode in the UK for example, since those bands are already in use for digital television broadcasts.

And I cannot expect Apple to provide many country-specific iPads today, for a variety of reasons:

  • It would be an impractical manufacturing, distribution and sales problem for the iPad.
  • Not all countries (and their Carriers) where the iPad is sold, have cleanly declared which of the available bands will be used for LTE.
  • Chipset and cellular radio manufacturers have not yet overcome constraints to use multiple LTE bands in the same units.
  • Carriers have not yet given the cellular radio and handset manufacturers the business freedom to make multi-Carrier units.

Until these problems are solved, any Device using LTE—iPad included—will not have LTE service outside the country and Carrier from whom the device was purchased.

Carriers and LTE Devices Are a Bit Different

For Carriers deploying LTE here in the US and other countries, the vast majority of Customers who have LTE units do not try to roam onto another Carriers footprint … yet! (This will change soon enough, as more LTE units are sold.)

Furthermore, the LTE smartphones being sold today are unique to each Carrier—the Customers do not expect to buy LTE units from AT&T to use on Verizon and vice-versa. Nor do they buy LTE devices from Vodafone in Europe to use on AT&T here in the US.

And, of course, purchasers of cellular service are generally aware of the limitations of cross-technology roaming. They have become knowledgeable about the inability to use CDMA units in GSM markets, and vice-versa.

When roaming into other Carriers, or into International markets, they also know that they may have to use 2G or 3G service (assuming that the phones are quad-band).

As long as the Customers have 4G in their home markets (or the Carriers are expected to eventually provide 4G in their home markets), these are acceptable limitations. Indeed, Customers are buying iPads in many US markets that do not yet have any LTE service … with the entirely reasonable expectation that it will be there in the next few years.

But The Apple iPad is Unique

Basically, Apple is pretty much the first large non-cellular handset entity to get caught up in this issue of spectrum fragmentation because of the global sales of the iPad—a product that is considered to be a data device … not a cellular smartphone sold by a local Carrier in that country.

And the difficulties with the iPad underscores what will happen when the oft-rumored iPhone 5 (presumed to have LTE) is released later this year as believed—Apple must restrict sales to the country where there is a Carrier available to provide service for the 4G LTE in those product versions.

Thus, I expect that the initial Apple iPhone 5 release will be restricted to the US for a while, since it will likely use the current-generation LTE chipsets that just support Verizon or AT&T (or, possibly, Sprint).

If and when other countries (like in Canada perhaps) deploy at those identical frequencies, the sales of the current iPad and next iPhone can be expanded to those markets.

And, this is a problem for Apple, since their global success with the non-LTE iPhones has been outstanding!

A Few Possible Solutions

New Multi-band Chipsets and Radios

Clearly, LTE chipset manufacturers will improve their designs and products to support multiple bands more easily and effectively … the only question is “When?”

It will take time for these new chipsets and radios to enter the market, and time for them to be incorporated into radios and new Devices. Since it takes many years to design and market chipsets, handsets, smart-phones, etc., this is not a quick solution.

And, unfortunately, this is not going to solve the short-term problem for Apple in the iPhone 5 that is expected this year.

Global Cooperation for a World-wide Common Band

To provide world-wide operation for 4G LTE, there will have to be global national cooperation to find a common band dedicated for International roaming purposes. And, agreements by the Carriers to support that frequency and deploy services.

It may be time for national governments to offer a free release for one wide band of common global spectrum, and allow multiple Carriers in each country to operate in that band. And require Carriers to support that common frequency band as a condition to use other, “local”, bands for LTE.

To provide a global roaming capability, that free of cost release of a common band, with some conditions (i.e., required LTE deployment) for the Carriers, would be a real benefit to the Customers. You heard this proposal here first, folks!

Unfortunately, given the current global economic climate, this is unlikely to happen—national governments are simply too enamored with the “revenue” that spectrum auctions can generate. And, there are some other practical concerns.

But it is not impossible.

What About M2M?

Multiple LTE Bands

The current estimate is that it will take 6 bands to support all the LTE deployments by US (and possibly Canadian) Carriers, and up to 10 to 12 bands to create a truly global LTE Device.

This is not likely to happen cost-effectively for M2M Modules and Applications for quite a long while, and may remain impractical for higher cost smart-phones too. The design problems and complexity of a multiple number of LTE bands in a radio will be tough to implement for quite a while.

Thus, as you can probably tell, I am still not hopeful that LTE will be usable by most M2M Applications for a number of years.

The longevity requirement—M2M Devices stay deployed for many, many years—means that some Customers may not be able, or willing, to risk large-scale volume LTE deployments today with a single Carrier in a single country, except for those few M2M Applications that need 4G speeds in those specific areas.

In time, multi-band chipsets and multi-band support by the M2M Module manufacturers will solve this problem.

Dedicated M2M Band … Fantasy?

Or we could fantasize that the global common frequency band mentioned above could be dedicated just for M2M Applications—that would solve the problem of large-scale M2M deployments on LTE, and gain rapid acceptance of LTE by the M2M industry too.

Since most M2M Devices do not send or receive a lot of data (i.e., unlike consumers), even a single 10 MHz allocation (for a 5 x 5 FDD LTE deployment) might be sufficient, without congestion, for a large number of M2M Devices, for a long time.

Given that the prediction is that there will be billions of M2M Devices by 2020 and beyond, maybe it is time to dedicate spectrum for M2M Applications!

What are your Comments?

Please send me your comments on the above post. Like I had mentioned in an earlier post, I would really like to hear from people who are deploying M2M Applications using LTE.

Copyright © 2012 Aeris Communications, Inc. and Syed Zaeem Hosain. All Rights Reserved.

As before, although I don’t specifically identify Trademarks in my posts, they are implied. For example, Apple, iPad, and iPhone are trademarks of Apple, Inc., registered in the US and other countries.

%d bloggers like this: