The Billion+ Dollar M2M Device Swap

Introduction

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.

Assumptions

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.

Is Aeris An MVNO?

Introduction

We are often asked the question: Is Aeris a Mobile Virtual Network Operator (“MVNO”)?

Let’s understand the acronym, how it applies, and look at some companies who are MVNO’s, to understand the answer to that question.

What is an MVNO?

So, what is a Mobile Virtual Network Operator or MVNO anyway?

First, “Mobile” is pretty clear. Companies who are MVNOs are conducting business in the mobile cellular industry. They offer devices such as phones, tablets, data cards, etc., to customers who need cellular service for voice and data.

Next, “Virtual” is the main distinction between an MVNO and a Mobile Network Operator (i.e., “MNO”)—more commonly known as a Carrier or Operator. An MVNO may look like an MNO to their customers, but MVNO’s do not own or operate the actual network  infrastructure to provide their services. This “Virtual” infrastructure is also where it gets messy for an MVNO, as its underlying Carrier’s billing and business rules may not align—causing an exponential rise in difficulty when trying to resolve a support request.

Finally, “Network Operator” represents the same usage as in the term MNO. I.e., an MVNO offers the same kind of cellular phone services (voice and data) as a Carrier (just under a different brand name).

In short, an MVNO offers an MNO’s (Carrier) cellular voice, SMS and data services to their own customers through a contractual agreement. These services are then rebranded under the MVNO’s name and the customer does business (service, support, bills, etc.) with the MVNO, not the underlying Carrier.

MVNO Can be Different from Reseller

An MVNO can be different from the older term “Reseller” in one important way: although the business, contractual and operational arrangements are very much the same, Resellers do not use their own brand name for the services offered to the Customers.

As a Reseller example, more than two decades ago, well before the Carriers ran their own local stores, I went to a company in the San Jose area (“Peacock Cellular” in San Jose, as I recall) to get my phone and cellular service set up.

This was a true Reseller business deal—Peacock Cellular sold me a phone and service on GTE Mobilnet (now part of Verizon Wireless). My cell-phone bills came from GTE Mobilnet … not Peacock Cellular!

Effectively, Peacock Cellular was an agent of GTE Mobilnet—reselling the services of that underlying Carrier, without rebranding those services in any way.

The Underlying Network

Since an MVNO is providing service using somebody else’s network, under a contracted agreement, there is no need for them to deploy any infrastructure elements for that network.

Thus, the networks, the systems, the connectivity, the numbers in the phone, etc., are generally owned and operated by the underlying Carrier.

In many cases, the Carriers also provide the cellular handsets that are sold by the MVNO, although this is an area where the larger MVNOs can provide a degree of separation from the underlying Carrier, via handset and service branding, and/or unique differentiation in the handsets themselves.

Most importantly, because the network is owned by the Carrier, the MVNO performance will always be the same as the performance of the underlying Carrier. Of course, this is true only as long as the Carrier does not limit the MVNO any further through specific contractual limitations (for example, reduced market and service areas, International dialing blocks, service data plans, pre-paid only services, etc.)

Summary

An MVNO:

• Is a mobile service operator that provides an underlying Carrier’s cellular voice, SMS and data services to its Customers.
• Markets the services under a different brand name, and possibly different billing and business rules, than the actual Carrier that owns the network.
• Does not own or operate the network infrastructure to provide those mobile cellular services.

Examples of MVNOs

I believe that the first company in the US to which the term MVNO can be correctly applied is Virgin MobileUSA. Virgin MobileUSA operates a cellular service business as an MVNO and the underlying Carrier is Sprint.

And, there are other MVNOs that have the same business model.

For example, Consumer Cellular is an MVNO on AT&T Wireless, Jitterbug (Great Call) is an MVNO on Verizon Wireless, and Mingo Wireless is an MVNO on Sprint—the list is fairly long in the US alone.

Not surprisingly, the list of MVNOs does change as businesses, and business arrangements, come and go.

For example, an MVNO effort by Disney was shut down as their Disney-branded cellular service simply did not catch on with their Customers, even though it had received critical and customer acclaim.

Why is Aeris Different?

Aeris Owns and Operates its CDMA Network

First and foremost, unlike an MVNO, Aeris owns and operates its network infrastructure for its CDMA M2M services. This includes all the cellular network infrastructure and service elements, as well as many other non-cellular systems and connectivity elements, in support of the CDMA M2M service.

Device number assignments are done by Aeris and stored in the systems owned and operated by Aeris—unlike MVNOs that use number assignments from the underlying Carrier, and which are stored in the Carrier network and billing systems.

Essentially, all Device presence, authentication, and operation on cellular networks are managed and controlled by Aeris network infrastructure elements in exactly the same way that a Device or handset from one Carrier operates in another carrier’s footprint via roaming connections and arrangements!

Indeed, operating our own network elements allows Aeris to provide innovative and unique solutions that are just not possible from MVNOs, and even Carriers.

Aeris Does Billing From Its Own Records

The accounting and billing of Device usage traffic are all done by Aeris’s billing systems and servers.

This means that Aeris does not rely on any billing services from anywhere else, unlike an MVNO that relies on core billing services from their underlying Carrier. The accounting data fed to the Aeris billing systems are from our own billing records from our own network systems.

Because Aeris has complete control of its billing system, Aeris is unmatched in its flexibility to provide customized billing, rate plans, and business rules for its Customers—and fully support them in-house. This has allowed several Aeris Customers to start, or stay in business, which was not possible with MVNOs and other Carriers.

Direct Customer Support

Aeris directly provides support to its Business Customers 24 hours a day, 7 days a week, 365 days a year.

Aeris is solely focused on M2M deployments with a support team that has direct visibility into how all the Devices are performing on the network. This enables Aeris to resolve Customer issues proactively at a speed that MVNOs and Carriers cannot match.

Since Aeris owns and operates our own network, the Network Support Engineers have access to systems and data that have been designed to provide extensive logging and monitoring functionality—optimized for M2M—that provide information well beyond what any other MVNO or Carrier can provide.

Access to these data and traffic tools are also available to Customers who can use the information for their own debugging and other purposes.

Additionally, the Device information (provisioning state, billing rate plans, network location, etc.) as well as the Traffic information (number of SMS messages sent, quantity of bytes used, etc.) are made available through XML/SOAP Application Programming Interfaces (“API”) and also through our human web portal called AerPort.

The Business Model

Fundamentally, Aeris is a one-stop-shop business for Customers who need IP data services, SMS, and voice for M2M Applications and Devices.

All functions and services are provided directly from Aeris, ranging from sales support, Device provisioning and activation, network operational support, assistance with Devices, etc.

This makes Aeris the easiest to work with for M2M deployments—unlike MVNOs, whose functions are confusingly split between them and the underlying Carrier. Aeris’s focus on M2M also gives us an advantage over the Carriers who focus on Consumer Devices, along with a list of other business services.

So … The Answer!

The answer to the question raised by the post tile is pretty simple: No, Aeris is not an MVNO for our CDMA Service.

Aeris can be considered a new type of CDMA Carrier, focused on M2M, with a Customer-focused approach that traditional Carriers and MVNOs just don’t provide.

Since Aeris is a Carrier directly involved in the complete M2M solution, it has the unique ability to create new, innovative solutions that are customized exactly for the Customer’s critical business needs.

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

Commander Data … Are You Awake?

Introduction

Many of you probably remember Commander Data, the android on the hit science-fiction television show “Star Trek: The Next Generation”, based on the original “Star Trek” series created by Gene Roddenberry.

If you were a fan of the series, you know about the location on Commander Data’s back that, when pressed, would cause him to “shut down”.

Of course, not everyone knew about this Master On/Off switch, but, on a few episodes, this Master On/Off switch was indeed used to de-activate him temporarily.

Particularly under conditions where Commander Data truly needed to be turned off.

Similarly, M2M Devices may need to be turned off when it makes sense—either temporarily or permanently.

Let me explain …

“How do you plan to remove units?”

In the mid 1990′s, when Aeris began discussions with Carriers to set up the roaming arrangements under which we offer network services, we met with Ameritech (now part of AT&T) in Chicago.

I was enthusiastically detailing our machine data services (before the acronym “M2M” even existed), and waxing about how our patented MicroBurst solution would enable a class of applications to send data to and from hosts for a variety of purposes.

A very experienced Director at Ameritech, Dick Gove, asked a question that I will treasure a long, long time: “How do you plan to remove units?”

I was quite taken aback and silent for a few seconds. Huhn? We wanted to add units month over month for ever-increasing service revenues … not remove them!

Runaway and Other Devices

I must have looked blank, because Dick elaborated further, “What if a unit is stolen? Or ‘runs away’ and transmits continuously? If a unit impacts the network in some way, can we disable it?”’

The light dawned!

Cellular data devices that may be connected to good sources of electrical power (unlike batteries in handsets that eventually lose power when left untended), could continue to transmit if the application firmware chooses to do so.

Or certainly register on the network when they are powered up—perhaps multiple times a day.

For example, a security Device could continue to transmit heartbeats on a regular basis (“I am alive and well” messages), even if the home owner or business decided to cancel their security service.

A vehicle could power up and the installed M2M Device in the vehicle could register on the cellular network and be ready to transmit … even if the owner had sold the car and no longer desired service.

We Needed a Solution

I promised Dick that I would come up with a solution to his “How do I disable a runaway unit?” concern, and return to present it to his satisfaction.

On my flight home, I realized that we needed to not only handle the scenario of runaway units, but also handle other potential issues, i.e., for more than just malfunctioning Devices:

• What if our Customer wanted to be able to remove all his units from service once the Application had run its course? Could we permanently disable their units?
• What if our Customer went out of business? How could we permanently remove their deployed units from the network?
• What if the application needed temporary disables? Could the Customer suspend the units for a period of time and ask us not to bill them?
• What if a Customer failed to pay their bills? Could Aeris turn off services at the Devices temporarily?
• The cost of “touching” a runaway Device to shut it down could be expensive! Could we prevent transmissions while we get technical resources to the Device site?

Clearly, the need for both temporary disables (i.e., one that could be re-enabled remotely) and permanent disables  was vital!

Sending technicians to remote locations to remove Devices from service is prohibitively expensive. Product recalls, or expecting End-customers to bring their units in for service/replacement, simply is not practical or possible in many cases … particularly for units that are deployed or mobile in the entire country (think of a long-haul trucking fleet application!).

The scenario where a unit could continue to stay on the network indefinitely—even if we wanted to take it out of service temporarily or permanently—was an issue we had to address.

Aeris Module Control Functions

Also on the flight, I thought about how we could modify the firmware in the cellular radio to allow us to disable units in the field.

And also to extend the concept of device disables further than Dick had asked for … to address the questions I raised above.

Aeris worked on a capability (now patented) that we incorporated into our radio modules that would allow Aeris and the Customer to temporarily disable Devices in the field.

As well as allow Aeris to permanently disable Devices so that they needed to be “returned to the factory” to be re-enabled for service.

These functionality had to be carefully designed to prevent accidental or deliberate, i.e., uncontrolled, invocation (imagine a Home Security device where the burglar can disable the cellular radio inside the unit too easily!)

These capabilities were added to our early release of our Aeris “Module Control Functions” inside the radio Modules, and we developed and released a set of new functions to our data Application Programming Interface (“API”) connections to our Customer host systems.

Life Cycle Management

As is very common with new product and new service and new technology development, we techies—particularly in start-up companies—can get all caught up in the excitement of what we are trying to do and forget about an important issue: Product Life Cycle Management!

This is not just an issue for Aeris.

In this day and age, where the general concern of product obsolescence and over-full landfills, green products, etc. is paramount, it is important to recognize that products do have an end-of-life.

In particular, when M2M cellular Devices reach their end-of-life, they must be carefully removed from service to avoid impacting the network.

Recovery of Number Resources

Resources, such as numbers inside the units, must be recovered for re-use.

Otherwise, we run the risk of problems, such as the exhaustion of Electronic Serial Numbers (“ESN”), that complicate cellular network operation.

Even though many ESNs in the world are not in use (old Analog AMPS and EIA-136 TDMA phones are gone, many older CDMA phones are no longer in service, etc.), the records are non-existent and incomplete—indeed, they cannot be updated because many companies have ceased doing business, etc.

Thus, old ESNs simply cannot be re-used.

Radio Disables and Removal

To avoid cellular presence on the network once a Device must be removed from service, power must be permanently removed from the unit.

Without the possibility of accidental power-up at any time in the future, since its numbers may have been re-used in another Device and confuse the operation of the new unit.

Other Good Reasons

Clearly, there are other reasons for making sure that the entire Product Life Cycle Management  is properly handled in all M2M Applications and a full discussion is beyond the scope of this post.

Furthermore, related to the topic of Life Cycle Management is the issue of Application Updates, but that is the subject of another future post too!

Regardless, I encourage readers to contact our Customer Sales Engineering department to learn more about this topic and the  capabilities that we provide our Customers to assist them with this very important aspect of their M2M Application deployments.

The End of the Story

By the way, when I returned to Ameritech to present our solution to the concern that Dick Gove had raised, he was very happy that we had addressed the topic beyond his original questions and concerns.

In a technical evaluation of Aeris vs. our competition, we were selected for deploying our MicroBurst data service on the Ameritech network!

And the rest is history.

P.S. Dick, I have not been able to track you down to thank you—even in this Google-enabled era—but I do want you to know that your inputs were vital to us. We implemented the capability … and once, we used it to remove a few thousand errant Devices that could have impacted our business very badly! Thanks much, Dick!

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

Mini PCIe … A Standard Form Factor for High-Speed Radios

Introduction

When cellular radio modules first became available for M2M Applications in the old Analog AMPS days, these did not use a standard form factor.

Each manufacturer designed their own circuit board, and implemented unique pin configurations, connectors, and data interface protocols for their Customer’s needs.

Over the years, the module form factors and interface protocols evolved and changed along with the chipsets and wireless technologies, but most manufacturers of M2M radios continued using their own new form factor design (although there were some inter-company efforts to standardize on a format).

Recently, the wireless radio industry has popularized a form factor: Mini PCI Express, also referred to as Mini PCIe, that is now a used for a variety of embedded radio applications.

This is now a common standard form factor for high-speed 3G and 4G radio modules as well, although not all embedded cellular radio manufacturers have begun providing modules using it.

Where to Get Detailed Specifications

For the electrical and physical specifications of Mini PCIe, the PCI Special Interest Group (“PCI-SIG”) has provided all the details at the PCI-SIG web site, but this requires membership (and annual dues) to get access to the full, formal specifications.

The module manufacturers also provide specifications with their products, of course.

Edge connectors to use with these Mini PCIe modules are available from companies like Molex and others.

Brief Discussion of Mini PCIe

Popularity of Mini PCIe

Mini PCIe has become very popular in the PC industry for use in laptops and tablets. This physical and electrical format is ideal for extending the PCI Express busses (used in desktops and servers) for space-constrained uses, and providing a high-speed path to the processor and memory.

Mini PCIe cards for a variety of short-range radio technologies, such as Bluetooth and WiFi short-range wireless embedded radios (including combo units with multiple technologies), are quite popular and commonly available—both directly from laptop manufacturers and as add-on components.

Types of Mini PCIe Cards

The ultra-portable and tablet market has also driven a need for two types of Mini PCIe cards: Full Mini PCIe and Half Mini PCIe. The connectors on both formats are identical, but the board length has been reduced in half for Half Mini PCIe.

This allows them to be used in even tighter, space-constrained applications—such as ultra-portable laptops and tablets—and many Bluetooth and WiFi Half Mini PCIe cards are commonly available. But this format is not as essential for many M2M Devices that are not space-constrained like tablets.

Thus, today, most cellular implementations are Full Mini PCIe, although there are Half Mini PCIe designs in the works—these are primarily intended for laptops and tablets where the higher cost of Half Mini PCIe radios can be more readily absorbed.

Antenna Connectors

In the Mini PCIe format, the antenna connectors on the boards are generally U.FL male connectors (these are surface-mount coaxial connectors from Hirose Electrical Group in Japan) designed to work up to 6GHz.

Some manufacturers may also use IPX connectors from Lighthorse Technologies. These are designed to be 100% compatible with the U.FL connectors from Hirose.

The location of the antenna connectors is next to the support holes (where screws should be used to hold down the Mini PCIe cards to the underlying circuit board). The cards may have multiple antenna connectors—either for diversity or Multiple-Input Multiple-Output (“MIMO”) antennas for 4G cellular technologies.

The signal connections to the antennas are done with mini coaxial cables—typically ranging from 0.81mm to 1.32mm in overall thickness.

Female U.FL connectors on typical antenna cables are designed for only a few insertions. These cables must be carefully inserted into the cards—without repetitive twisting and the like—to avoid connection and signal loss problems.

For M2M applications in high-vibration environments, it is important to design the enclosures to properly support the connections and cable attachments, so that they do not break or pop-off easily—embedded M2M Devices are expensive to service!

Signal Interface

In these cellular Mini PCIe cards, the interface is generally USB 2.0 High-Speed serial rather than the older RS-232 compatible serial (or, rather, the 5V CMOS equivalents of RS-232 serial).

Thus, all external controllers that run the actual M2M Application must use USB 2.0 to communicate with Mini PCIe radios.

Communication Protocol

With a few exceptions, of course, the modules are controlled using AT commands. While attempts have been made to standardize the actual AT commands, these are still unique to each manufacturer.

However, most will extend the 3GPP TS 27.007 “AT command set for User Equipment (UE)” specification that was developed many years ago. (Some will extend the earlier 3GPP TS 07.07 “AT command set for GSM Mobile Equipment (ME)” specification, but this is effectively obsolete as of 2003, so this is not as likely.)

Most importantly though, as mentioned, the specific modules implementations are usually extensions of the 3GPP AT command set, since the modules have unique capabilities that differ from manufacturer to manufacturer.

This means that the M2M Application developer must read and understand the specific commands of their module choice carefully—the same AT command may operate a bit differently in each manufacturers implementation!

Examples of Mini PCIe Cellular Modules

Here are just a few examples of embedded radio modules using the Mini PCIe form factor:

Franklin Wireless

M600C CDMA Module

M600 CDMA / WiMAX Module

Novatel Wireless

Expedite E396 CDMA / HSPA+ Module

Expedite E362 LTE / CDMA Module

Sierra Wireless

AirPrime MC5728V EV-DO Rev A module

AirPrime MC7750 LTE and EV-DO module

Pros and Cons of Mini PCIe

Pros

This is, after all, a standard! Each module manufacturer can provide a number of modules with different capabilities and technologies.

For example, Franklin Wireless (others have similar multiple product lineups) offers three Modules that differ only in the supported cellular technology:

• M600 for use with CDMA and WiMAX networks.
• M600C for use with CDMA networks only.
• M600W for use with WiMAX networks only (not shown in this post).

And they have similar M720 LTE/CDMA and M710 LTE/HSPA Modules in the works.

Each is plug-and-play into the Mini PCIe edge connector and mounting holes.

The location of the antenna connectors is interesting: the CDMA connectors on the single-technology M600C are identical to the location of the CDMA connectors on the dual-technology M600. Similarly, the location of the WiMAX antennas on the single-technology M600W are identical to the location of the WiMAX connectors on the dual-technology M600.

This allows Customers to design a single base circuit board that can operate using a variety of possible cellular modules—particularly from the same manufacturer, although the specific advantage of being able to use multiple sources is a distinct plus!

Of course, the AT command set used will differ from manufacturer to manufacturer, so programming changes will be needed in the M2M Application firmware. But at least the base hardware will not need significant changes—ideally none at all—when changing between manufacturers.

Cons

As far as I know (but could be wrong), Mini PCIe cellular modules have not as yet been extensively deployed in the M2M industry, i.e., outside the portable notebook, laptop and tablet markets.

The more rigorous environmental requirements (such as temperature ranges, vibration, etc.) of some M2M Applications may cause problems for the edge connectors or antenna connectors on these cards.

Automotive telematics applications also generally require wider temperature ranges than standard consumer products, although this is perhaps more of an issue for the radio modules rather than the physical/electrical form factor or edge connectors, etc. Special boards and connectors may be more easily designed for those harsher environmental requirements.

Regardless, I do think that the advantages of using a standard format more than outweigh these Cons, so I expect to see more Mini PCIe modules in the future, as well as more M2M Applications that use them. Any M2M Application user who is concerned about the harsher environment can work with the manufacturer of their choice to improve the capabilities and specifications of the radios.

What Do You Think?

I’d like to hear from developers who are using, or beginning to use, Mini PCIe cellular radio modules in their M2M Applications.

What are your experiences with the format? What additional Pros and Cons would you add? Is there anything in your experience with Mini PCIe that has caused you to select or change to another form factor?

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

Note: Although I don’t specifically identify Trademarks in my posts, they are implied. For example, Franklin Wireless, Novatel Wireless, Sierra Wireless, PCI, Mini PCI Express, Mini PCIe, PCI-SIG, etc., are Registered and Unregistered Trademarks of the respective holders.

More on LTE Spectrum Fragmentation

Introduction

Some weeks ago, I posted on the LTE spectrum fragmentation problem and its impact on M2M. As well as a comment to people who had purchased the new Apple iPad that uses LTE.

Since then, a few changes and interesting events have occurred.

Band 26 Approved

First, in the latest 3GPP Release 11 update in March of 2012, Band 26 was approved for use with LTE.

This means that Sprint can use their Nextel spectrum for LTE (or a combination of LTE and CDMA within that band, with appropriate guard-bands to avoid interference) once they have the approval from the Federal Communications Commission (“FCC”) to re-purpose the spectrum.

The table below identifies the latest bands available for LTE:

Band	Uplink low (MHz)	Uplink high (MHz)	Downlink low (MHz)	Downlink high (MHz)	Bandwidth (MHz)	FDL low – FUL low (MHz)
1	1920	1980	2110	2170	60	190
2	1850	1910	1930	1990	60	80
3	1710	1785	1805	1880	75	95
4	1710	1755	2110	2155	45	400
5	824	849	869	894	25	45
6	830	840	875	885	10	45
7	2500	2570	2620	2690	70	120
8	880	915	925	960	35	45
9	1749.9	1784.9	1844.9	1879.9	35	95
10	1710	1770	2110	2170	60	400
11	1427.9	1447.9	1475.9	1495.9	20	48
12	699	716	729	746	17	30
13	777	787	746	756	10	-31
14	788	798	758	768	10	-30
17	704	716	734	746	12	30
18	815	830	860	875	15	45
19	830	845	875	890	15	45
20	832	862	791	821	30	-41
21	1447.9	1462.9	1495.9	1510.9	15	48
22	3410	3490	3510	3590	80	100
23	2000	2020	2180	2200	20	180
24	1626.5	1660.5	1525	1559	34	-101.5
25	1850	1915	1930	1995	65	80
26	814	849	859	894	35	45
33	1900	1920	1900	1920	20	Tdd
34	2010	2025	2010	2025	15	Tdd
35	1850	1910	1850	1910	60	Tdd
36	1930	1990	1930	1990	60	Tdd
37	1910	1930	1910	1930	20	Tdd
38	2570	2620	2570	2620	50	Tdd
39	1880	1920	1880	1920	40	Tdd
40	2300	2400	2300	2400	100	Tdd
41	2496	2690	2496	2690	194	Tdd
42	3400	3600	3400	3600	200	Tdd
43	3600	3800	3600	3800	200	Tdd

That makes the count: 35 possible bands for LTE deployments world-wide!

Certainly, not every band will be used in every country, but:

• The US is likely to have the most bands in use in actual deployment.
• World-wide roaming with LTE handsets is likely to remain a problem for many years.

Current Service and Announcements in the US

A reminder, the announced LTE service bands are:

• Verizon: 700 MHz (different block/class from AT&T).
• AT&T: 700 MHz (different block/class from Verizon).
• MetroPCS: 1.7 GHz / 2.1 GHz.
• Sprint: 1.9 GHz Block G, 800 MHz.
• T-Mobile: 1.7 GHz / 2.1 GHz (if it can quickly and cleanly move HSPA+ users to 1.9 GHz).
• Clearwire: 2.5 GHz (TDD LTE).

Future Service Bands in the US

All these Carriers are likely to re-farm other spectrum (800 MHz, 1.9 GHz bands, etc.) to change to LTE in those frequencies over time. In the case of 1.9 MHz PCS, they also have different blocks available in different markets (remember that the original 1.9 GHz PCS band is split into 6 blocks: A through F).

For example:

• AT&T is likely to deploy LTE at 1.7 GHz / 2.1 GHz, and eventually convert their current 800 MHz / 1900 MHz GSM bands to LTE.
• Verizon is likely to convert their 800 MHz and 1.9 GHz CDMA to LTE, and also 1.7 GHz / 2.1 GHz that they might acquire from cable companies.
• Sprint is likely to deploy LTE at some unused 1.9 GHz PCS blocks (i.e., other than block G) in some markets.

Real-World LTE Fragmentation Issue

Australia and the New iPad

In that earlier post some weeks ago, I also said the following:

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!

And, sure enough, the LTE spectrum fragmentation problem has already occurred.

Apple iPad purchasers in Australia have discovered that their new tablets will not work in LTE mode on the Telstra cellular network! Since Telstra is currently the only provider of LTE services in Australia, the purchasers cannot get LTE service from other carriers.

Apple is offering full refunds to iPad purchasers in Australia due to this issue.

By the way, the Apple store site in Australia now has the following information:

Wi-Fi + 4G model: Keeps you connected to the Internet using a fast cellular data connection when Wi-Fi isn’t available. So you can stay connected when you’re commuting on the train, hanging out at the park, or looking for directions during a road trip. It’s available without a contract, and service is sold separately. See your carrier for rate plan information.

This product supports very fast cellular networks. It is not compatible with current Australian 4G LTE networks and WiMAX networks.

And the word “current” in their disclaimer may be premature—if Telstra is unable to ever deploy LTE at 700MHz (it will depend on the Australian spectrum regulators and availability), these new iPads may never work in Australia in LTE mode.

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!

(Note that Canadian Carriers are intending to deploy units at 700MHz, but it is not yet clear to me which blocks in 700MHz are available and which will be used by which Carrier when. My speculation is that Rogers will be compatible with AT&T, and  Bell Mobilite, Telus and others will be compatible with Verizon.)

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.

Consider M2M LTE Deployments Carefully!

If the best and the brightest engineers and marketers at Apple—one of the best and innovative technology companies in the world—can’t quite get it right … will you?

Of course, other than the marketing faux pas, I cannot blame Apple for the iPad problem in Australia—the availability of LTE radios, their commitment to the large US market, etc., drove the decisions behind this LTE band selection.

By the way, would you expect Apple to develop, certify, manufacture, and sell country-specific LTE versions of the iPad (two versions for the US was difficult enough)?

I certainly would not, and don’t think this will happen soon either. Certainly not till there is some harmonization of LTE spectrum world-wide (or a common available band is found and all Carriers agree to deploy equipment to use it) and cellular chip-sets are updated, etc., etc., etc.

It is just very unfortunate that LTE spectrum fragmentation is going to hurt Apple 4G LTE iPad sales outside the US in the short run though!

Like the Apple iPad, it is possible that short-range WiFi at 2.4GHz and 5GHz may be the common element in M2M deployments, even though the “islands of available service” problem may preclude wide-spread use for M2M Applications. But, this may give a new lease on life to the Muni WiFi efforts (more on that some other day) in denser urban deployments, or the Carriers may make WiFi an integral part of their services in urban areas.

So … what are your LTE plans for M2M deployments in the face of this uncertainty? 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.

Using SMS for M2M Data—Best Practices

Introduction

This week, I begin a series of posts on the best practices for M2M data transports—interspersed periodically with other topics.

Text Messaging

Clearly, most people are knowledgeable about what text messaging is, so I will not spend much time on that.

Suffice it to say that the service and capability was developed for digital cellular technologies, to send and receive text (up to 160 printable characters) from one cellular handset to another. In a “fire-and-forget” way similar to e-mail!

First, a description of the issues and concerns with using standard text messaging services for M2M data.

Early Issues

In early digital cellular, text messaging was not reliable.

Delivery success rates were well below 75% to 85% for most Carriers—particular when roaming where the messages were not delivered at all in some markets.

If the recipient handset was on a different Carrier, it was very likely that it would never receive the text messages! Without any notification of the lack of success.

Even when successful, delivery times ranged from about 15 to 30 seconds, to many minutes and hours … sometimes days after the text message was sent!

(We had one Customer that used to sent two duplicates—i.e., three “successful” transmissions—with another Carrier to ensure that at least one transmission would make it through, and even this was not a guarantee for success.)

Thus, text messaging developed a reputation for uncertainty that caused people to avoid using it for mission-critical M2M applications.

Improvements

In the past few years, Carriers have improved their networks to better support text messaging services. Success rates have increased, and the delivery times have improved.

But, even today, delivery times have “long tails”—where a number of messages take longer to be delivered than may be acceptable for some M2M Applications, although many messages do arrive promptly.

Combined with the increase in the number of consumer text messages sent, and the use of spam filters, message queues, and the lack of security (anybody can send a text message to a cellular handset), using standard text messaging services for M2M data can still be a concern.

My simplistic test as I wrote this post: sending five text messages from one handset to another (same nationwide cellular Carrier, same Market, [presumably] on the same set of nearby towers since the two CDMA handsets were sitting side-by-side, etc.) averaged 15 seconds. The shortest time was approximately 12 seconds and the longest was approximately 22 seconds.

Aeris’s SMS Transport for M2M

Early in its digital cellular service deployments, we recognized the need for providing a highly-reliable, rapid SMS transport for M2M Applications—both Mobile-Originated SMS (“MO-SMS”) and Mobile-Terminated SMS (“MT-SMS”) data.

High-Performance Objectives

Careful performance objectives were set for the Aeris SMS transport services—initially called SMSDirect™—to meet the requirements for M2M Applications:

• MT-SMS and MO-SMS delivery success rates well in excess of 95% (when measured with a delivery time of 12 seconds maximum to a radio that is powered on and ready to receive SMS).
• Notification of delivery success when the MT-SMS was delivered to the radio.
• Timely notification of delivery failures when the MT-SMS was not delivered.
• Detailed information on the reasons for any delivery failures.
• Allow 8-bit binary encoding of MO-SMS data, since that is a more natural fit for data gathered by controllers.
• Customers can only send/receive SMS to/from their own Devices, without allowing others to access them.
• Devices secured against external MT-SMS spam … protected from receiving MT-SMS from unknown sources.

Aeris met its design objectives quite handily and provides an SMS transport service that is used today by mission-critical M2M Applications.

In the Aeris system, the vast majority of MO-SMS and MT-SMS packets are sent and received from the Device to the host systems in under 6 seconds, with outstanding success (when the radio is on and able to receive the SMS, of course!)

No “Store-And-Forward” By Design

Aeris designed its SMS Center (“SMSC”) systems to not use “store-and-forward” for SMS packets—this is unlike the treatment accorded to consumer text messaging by Carriers.

Since the M2M Application transmission could be mission-critical, the SMS sent and received from the Devices must be transported rapidly—with very timely notification of delivery failures (for example, if the recipient Device is powered off).

Additionally, MT-SMS transmissions that initiate actions at the Device must not be delayed by a store-and-forward SMSC, since a late action may cause inadvertent problems when executed at an uncontrolled time in the future.

For example, a vehicle door unlock function that is delayed by many minutes or hours, or a security system enable that occurs many hours after it is wanted, can cause that M2M Application function to “fail”.

Best Practices for SMS in M2M

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

Use SMS For Short Content Transmissions

The capacity of each SMS transmission is 140 eight-bit bytes or 160 seven-bit characters. This is sufficient for many functions in M2M Applications—studies show that the majority of M2M messages are alert, notification, and location-based messages that average under 75 characters.

For these short transmissions, opening an IP session (i.e., using Packet-Radio services), transmitting the data to a server, and closing the session, is more inefficient than simply sending an SMS.

When transmitting from a moving vehicle, the MO-SMS transmission may also be sent with greater reliability than during a session-oriented TCP/IP connection to a server.

Consider Using Eight-bit Data In SMS

When using SMS transport services that allow eight-bit data (such as Aeris’s SMS data transport service), encode and send the data using eight-bit fields if the data is gathered from sensors and controllers where this is a natural data size.

Using eight-bit data also allows application-level encryption to protect the information better than sending open text characters in an SMS message. This may be important for some applications where an action taken by a Device in the field requires additional protection to prevent accidental, or deliberate, invocation.

Send Content in MT-SMS Shoulder Taps

Often, an MT-SMS is used as a “shoulder tap” for the remote Device to initiate an IP Packet-Radio session.

For shoulder taps, it is useful to send information to the radio in the SMS fields to provide a better experience rather than simply sending an empty MT-SMS (since the length of the SMS does not change the cost) .

For example, consider sending Absolute Time (perhaps host time in “seconds past midnight UTC”) for the remote Device 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—which 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 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 content that is unique to the M2M Application) could be sent in a shoulder tap MT-SMS.

Set Multiple Transmission Timers Correctly

In most radio modules, the frequency of MO-SMS packets, or frequency of MT-SMS packets, is limited by the capabilities of the radio processor or the cellular processing in the radio after receiving the data.

In general,  radios and handsets cannot receive messages too rapidly and the inter-message timing—particularly for MT-SMS packets—must be carefully selected.

I.e., when sending multiple MT-SMS messages to the same Device, appropriate delays must be inserted between messages to avoid delivery failures. (The same is true for MO-SMS messages from the Device, but these errors can be immediately noted by  controllers that can retry as needed.)

Although the Aeris AerFrame™ interface provides support for this (by rejecting requests that are made too quickly), this places an unnecessary burden on the interface, and the client and server. It is best to set these timers externally at the Customer host systems.

Empty the Radio SMS Buffers

In most radio modules, there is a finite buffer for the storage of received MT-SMS packets. If not emptied, these buffers can get full over time, preventing the radio from receiving more MT-SMS messages—sometimes without any warnings or notifications(!)—and confusing the program in the controller attached to the radios.

In some radios, receiving multiple MT-SMS messages without clearing the buffer can slow down the process of receiving new messages and can also slow down the process of retrieving these messages from the radio over the serial or USB port.

Thus, it is best if the external processor (that runs the M2M Application firmware) immediately clears the SMS buffers in the radios after retrieving the received MT-SMS packets.

Analyze the SMS Cause Codes

In the Aeris AerFrame interface, MT-SMS requests are sent by the Customer host systems using an XML/SOAP interface. After the message is delivered to the radio, an acknowledgement is sent to the host system.

If an MT-SMS delivery fails (for example, if the radio is turned off), the AerFrame interface returns an “SMS Cause Code” to the requesting system. This Cause Code provides significant and valuable detail for the reason for the failure.

The host system software for the M2M Application should analyze the returned Cause Code to make decisions about retries, etc. Currently, up to 25 Cause Codes are available, although not all occur with the same frequency—some are more common than others.

Simultaneous Voice and SMS

In ANSI-2000 CDMA cellular, an SMS transmission can be sent and received while a voice call is in progress. This allows the transmission of short MO-SMS data packets (and receipt of MT-SMS too) during a phone call.

M2M Applications should take advantage of this simultaneous transmission capability when possible.

For example, an Automotive Telematics application can update the car location, using an MT-SMS transmission containing GPS data, while a voice call to an operator or concierge service person is in progress! This could even be done on demand, by the operator sending an appropriately coded SMS transmission to the vehicle.

Just Use SMS!

The most important best practice advice is simply “Use SMS”!

Aeris’s SMS transport system is a very practical and viable method for sending and receiving M2M data from Devices, and well-suited for transmissions where the size, reliability and relative low-latency, matches the needs of many M2M Applications.

The bottom line is that SMS is a completely viable data transport method for M2M Applications, including for mission-critical functions when provided by companies like Aeris that have optimized it for M2M.

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

Provision vs. Activate … Benefitting M2M Customers

Introduction

Some weeks ago, I posted about Aeris’s Rapid Provisioning System that allows Customers to rapidly provision Devices for operation on the Aeris Network Services.

I briefly touched on the differences between “Provisioning” and “Activating”—today’s post will explain these in a bit more detail.

The “Why”!

M2M Devices require special handling and unique billing services that are not typical for consumer (and corporate) cellular handsets and data cards.

For example:

• Automated factory floor “On-Air” testing of Devices when manufactured.
• Sitting in shipping or distribution for uncertain (sometimes lengthy periods).

These require fast provisioning capability (as discussed in that earlier post) and, equally importantly, the need to separate “operate live on the air” from “receive monthly bills for services”.

When Aeris first offered M2M Network Services in the mid-1990’s, we recognized this requirement from our very first, high-volume Customer, who was selling business and residential security systems using our network services.

Automated Factory Floor Test

This Customer manufactured their Devices (including integrating the cellular radio from a radio supplier into their own security panel hardware) in Mexico, and tested the completed Devices at the factory, to confirm proper operation prior to boxing and packaging.

It was important to ensure that the installed units were functionally normally before they left the factory, since a later “manual” touch for faulty Devices was very expensive.

The manufacturing site in Mexico shipped the Devices to the Customer headquarters in the US, and from there they went into their multiple distribution channels.

Distribution Delays

One of these distribution channels sold the completed security Devices to security companies—the medium to large (national) monitored security service companies in the US and Canada.

Other channels sold the Devices to other security companies—such as small “Mom-and-Pop” monitored security service providers.

Thus, the period from final test to final installation varied, ranging from weeks to many months—sometimes more than a year.

The installation of the Devices in business and homes was done by field technicians who need to maximize the number of installed units per day—without calling in to “activate” service and/or waiting to test the Device for proper operation.

These early requirements are similar to the needs of current Customers in just about every M2M Application.

The “Details”!

To support the above requirements, Aeris needed to ensure that the processes were highly automated—under the control of the Customer—to eliminate human interaction, minimize time and reduce cost.

Device States

To address the requirements described above, Aeris created the concept of Device States:

• Initial
• Provisioned
• Active-Billed
• Cancelled
• Suspended

and the transition actions (manual—under the control of the Customer—and automatic) to move a Device between these states.

These actions (i.e., to move a Device) are invoked through the AerPort™ web portal, or via the XML/SOAP interfaces to the AerAdmin™ systems.

Some of the actions are also automatic—the state transitions occur when pre-defined operating conditions are met.

State Diagram

In this diagram (from our AerAdmin System Specification document):

the Device States are shown in Blue inside ovals and the State transition functions are shown with black arrows and Red text. Some of the automated actions are shown with black dotted arrows and Green text.

The “Provisioned” and “Active-Billed” States, and some of the transition actions are described below.

(For more detailed information on the other States and transition rules, current Customers can retrieve the AerAdmin System Specification document at the AerPort portal.)

Provisioned State

In the Provisioned state, a Device is capable of operating on the network and can transmit and receive data, but it is not expected to provide active normal service to, or generate revenue for, the Customer.

The Device does have a billing rate plan assigned to it, but it is not being actively billed by Aeris for monthly charges—however, the Customer may have transmission costs for services, using the assigned rate plan, that are charged if the Device is used in the Aeris network prior to being activated.

Essentially, in the Provisioned state, the Device is known to, and can operate in, the Aeris AerFrame™ systems, but is not yet in an Active-Billed state.

Active-Billed State

In the Active-Billed state, the Device is active and operating on the network as expected—delivering service to, and generating revenue for, the Customer.

This is the normal operational state for deployed Devices that are generating revenue for the Customer, and, thus, for Aeris.

A Device in the Active-Billed State has a rate plan assigned to it, and the Aeris billing system is generating detailed billing records from the data messages being transceived by the Device.

At the end of each billing period, the Aeris billing systems generate an invoice to the Customer, using the pricing arrangements contracted by the Customer .

Essentially, the Device is known to, and operating normally in, the Aeris AerFrame systems.

Transitions

Manual Transitions From Provisioned to Active-Billed

A Device in the Provisioned state can be moved to the Active-Billed State.

Using the AerPort portal, the Customer can select one or more Devices and activate them by selecting the specific function.

If the Customer systems are also designed to use the AerAdmin XML/SOAP interfaces, this activation can be performed by the Customer systems as part of another process (for example, when a security system is installed, the installer can invoke an automated process to start service).

Automatic Transitions From Provisioned to Active-Billed

A Device in the Provisioned state may be automatically moved to the Active-Billed state.

If the Device in the Provisioned state exceeds certain parameters (such as the number of SMS packets transceived, or IP data bytes transmitted, or the Device has been in the Provisioned state for more than a number of billing periods), it is automatically moved to the Active-Billed state by the Aeris systems.

The value of these parameters (for example, the specific number of kilobytes allowed in the Provisioned state) depends on the contractual agreement between the Customer and Aeris.

Summary

Our Customers needed to be able to separate the ability to “operate live on the network” when necessary, from “receive a monthly bill for services” when they received revenue for service.

We understood this requirement and provided systems to support this need effectively, since the low monthly revenue of typical M2M Applications makes it difficult for our Customers to absorb costs for Devices that might not be generating revenue for them.

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

LTE Spectrum Fragmentation … Problems For M2M?

Introduction

In a post in this blog some months back, I wrote on LTE spectrum usage and its impact on M2M deployment using LTE.

Since then, with more research (on radios, spectrum, etc.) I have become more concerned that this issue is going to have a very significant impact on M2M deployments in the future, and not just in the short-term future either!

Numerous people have commented about the problem with this fragmentation on LTE deployments, but the problem is even worse for M2M deployments.

The Available Bands

Let’s begin by looking at the bands that have been allocated by the ITU for cellular technologies in 3GPP Release 10 (all numbers are in MHz):

Band	Uplink low (MHz)	Uplink high (MHz)	Downlink low (MHz)	Downlink high (MHz)	Bandwidth (MHz)	FDL low – FUL low (MHz)
1	1920	1980	2110	2170	60	190
2	1850	1910	1930	1990	60	80
3	1710	1785	1805	1880	75	95
4	1710	1755	2110	2155	45	400
5	824	849	869	894	25	45
6	830	840	875	885	10	45
7	2500	2570	2620	2690	70	120
8	880	915	925	960	35	45
9	1749.9	1784.9	1844.9	1879.9	35	95
10	1710	1770	2110	2170	60	400
11	1427.9	1447.9	1475.9	1495.9	20	48
12	699	716	729	746	17	30
13	777	787	746	756	10	-31
14	788	798	758	768	10	-30
17	704	716	734	746	12	30
18	815	830	860	875	15	45
19	830	845	875	890	15	45
20	832	862	791	821	30	-41
21	1447.9	1462.9	1495.9	1510.9	15	48
22	3410	3490	3510	3590	80	100
23	2000	2020	2180	2200	20	180
24	1626.5	1660.5	1525	1559	34	-101.5
25	1850	1915	1930	1995	65	80
33	1900	1920	1900	1920	20	Tdd
34	2010	2025	2010	2025	15	Tdd
35	1850	1910	1850	1910	60	Tdd
36	1930	1990	1930	1990	60	Tdd
37	1910	1930	1910	1930	20	Tdd
38	2570	2620	2570	2620	50	Tdd
39	1880	1920	1880	1920	40	Tdd
40	2300	2400	2300	2400	100	Tdd
41	2496	2690	2496	2690	194	Tdd
42	3400	3600	3400	3600	200	Tdd
43	3600	3800	3600	3800	200	Tdd

Note: this list does not include the proposed Band 26 (IDEN 800 MHz spectrum used by Nextel prior to the Sprint acquisition). Sprint has proposed some portion of Band 26 for both ANSI-2000 CDMA and some for FDD LTE.

The list above is already showing 34 different spectrum bands!

And this is not counting the Sprint proposal for Band 26 … and others that may be in the early proposal stages.

Admittedly, not all of them will be used in any given single country, since that depends on the various regulatory bodies within each country. Some may never see services deployed in the US, since other entities are using them.

Certainly within each country, many bands are being considered, and used, for service deployment.

Many Bands Used/Planned

Unfortunately, the United States is likely to have the largest number of possible bands with LTE deployments.

Current Service and Announcements in the US

So far, services and announcements are:

• Verizon: 700 MHz (different block/class from AT&T).
• AT&T: 700 MHz (different block/class from Verizon).
• MetroPCS: 1.7 GHz / 2.1 GHz.
• Sprint: 1.9 GHz Block G, 800 MHz later (proposed Band 26).
• T-Mobile: 1.7 GHz /2.1 GHz (if it can quickly and cleanly move HSPA+ users to 1.9 GHz).
• Clearwire: 2.5 GHz (TDD LTE).

Future Service Bands in the US

Plus, all these Carriers are likely to re-farm other spectrum (800 MHz, 1.9 GHz bands, etc.) to change to LTE in those frequencies over time. In the case of 1.9 MHz PCS, they also have different blocks available in different markets (remember that the 1.9 GHz PCS band is split into 6 blocks: A through F).

For example:

• AT&T is likely to deploy LTE at 1.7 GHz / 2.1 GHz, and eventually convert their current 800 /1900 MHz GSM bands to LTE.
• Verizon is likely to convert their 800 MHz and 1.9 GHz CDMA to LTE, and also 1.7 / 2.1 GHz that they might acquire from cable companies.
• Sprint is likely to deploy LTE at some unused 1.9 GHz blocks in some markets.

International Deployments

And, if you include the bands that are planned for LTE deployment overseas, the spectrum fragmentation problem gets even worse. I will not go into any more details here—there are other people that have discussed the potential pitfalls quite well!

By some estimates, it would take a six-band radio to roam in the US and a twelve-band radio (at least!) to successfully roam Internationally (assuming that the business agreements are worked out, of course).

Spectrum Purchases

In the US, the large cellular operators have spent billions “purchasing” the spectrum at auctions run by the Federal Communications Commission (“FCC”) for the US Federal Government.

Of course, these large Carriers are the only people with the deep pockets who can afford to make these purchases: in the 700 MHz spectrum auctions, for example, Verizon paid $9.6 billion (plus more billions if you count their recent cable company spectrum purchases that are still facing approval), AT&T spent almost $7 billion (and many billions more for spectrum purchases from other entities), etc.

With the intention of deploying LTE in that spectrum.

Yes, there were some smaller markets which were won by the Tier 2 and Tier 3 Carriers. Unfortunately, they don’t have the financial and unit volume clout to get handsets from the traditional handset suppliers—particularly if the Tier 1’s flex their muscles a bit with the suppliers.

These small Carriers have asked the FCC to make and enforce rules to mandate interoperability across the entire 700 MHz allocations for example, but without success so far.

AT&T and Verizon have argued against such a mandate for interoperability. They say that the government has no authority to do this (why not?), and that there are technical reasons (what are they?) why such a mandate would slow down LTE deployment for them.

With today’s soft (i.e., programmable) radios—particularly in base station radio technologies—I find these arguments somewhat unacceptable. Indeed, recently, T-Mobile filed with the FCC to support a 700 MHz interoperability mandate, since the FCC is apparently considering such a rule.

Without the FCC taking positive action soon, LTE roaming in the United States is likely to be delayed for years.

(By the way, whatever happened to the concept of a lottery for some spectrum? Like was done for the old 800 MHz cellular bands years ago? it would be nice to see the FCC and the politicians return to that … even a little bit! I doubt it though … too much money there for the Federal government to not drool over it, I suppose.)

Impact on M2M

Multi-band Radios

Unless an LTE handset or radio can be used at more than one of these LTE bands and blocks—particularly for the ones in the US, it is likely that LTE roaming will be impossible for many years. This has clear implications for long-term M2M Application deployments using LTE, assuming that the M2M Application needs the LTE performance and speeds in the first place!

It would take a six-band LTE radio to roam in the US, and somewhere on the order of a twelve-band LTE radio to roam Internationally!

Assuming that all the business and roaming agreements were in place, of course.

With relatively expensive Smart Phones and handsets, this is likely to occur … in time. Although today, suppliers are not providing such six and twelve band chipsets—even if the handset manufacturers wanted to use them.

Please Don’t Forget the Antenna!

I have not seen this potentially tricky issue discussed by anybody yet!

Given the relatively complexity of LTE chipsets, the added cost of supporting many bands inside the radio, and even assuming that antennas (you would need multiple antennas inside the handset!) could be effectively designed to cover so many widely separated bands, this is likely to be an effort that will take quite a long time to solve.

Today’s LTE handsets could need five or six antennas: GPS, Bluetooth, WiFi (at 2.4 GHz or 5.0 GHz), Near Field Communications (“NFC”), and two antennas for LTE (for the MIMO antenna requirement)!

If a multi-band handset needs to operate at 700 MHz, 800 MHz, 1700 MHz, 1900 MHz, 2100 MHz, and 2500 MHz, adding good antennas—inside the volume-constrained thin handsets that are popular today (the emphasis is on maximizing battery size)—becomes quite difficult.

Some years ago, I was taken aback at Steve Job’s keynote on the Apple iPhone that had the external stainless-steel antennas touching the user’s hands (“Are you kidding me? That will not work out well!” … I was proven right within a few days!), but the multi-band LTE antenna problem is going to be far more of a headache.

At least, in M2M Applications, this might not be a physical space constraint, but the antenna cost could be significantly higher than what is used for 800 / 1900 MHz modules in M2M Devices today.

And … What about M2M Modules?

Supporting many bands will increase the Module cost some—not a massive amount, of course, but certainly some extra dollars to support multiple power amps, filters, and even multiple antenna connectors.

In M2M Applications, where companies expect to deploy large numbers of Devices, selecting more expensive multi-band radios may not be an option for quite a while.

And, until LTE is deployed everywhere in a given Carrier footprint (without LTE roaming available for some time), using multi-technology radios for a long time—perhaps much longer than multi-technology handsets stay available—is essential for M2M Applications.

When deploying on Verizon or Sprint or US Cellular, etc., the modules would need to be LTE-CDMA capable, and when deploying on AT&T, the modules would have to be LTE-HSPA capable.

The underlying assumption being that roaming could be achieved between Verizon, Sprint, US Cellular, etc. using ANSI-2000 CDMA mode, while still operating in LTE in the home footprint.

Of course, this leaves AT&T out of the above mix, since their “other” technology is HSPA (with EDGE and GPRS fallbacks today)—so they could only roam with T-Mobile, etc.

And, of course, needing dual-technology means that the LTE-CDMA modules will be a bit pricier for some time.

What about LTE-only Handsets and Modules?

Eventually, when the Carriers migrate to LTE-only handsets—relatively soon, I suspect, in the case of Verizon and AT&T—roaming between Carriers becomes impossible without multi-band LTE radios inside the handsets.

This “LTE-only” handset step (just like was done with ANSI-2000 CDMA handsets that did not include Analog AMPS … well before the AMPS Shutdown in February 2008) puts the Carriers into a better position to drop the “other” technology relatively quickly.

Considering moving an LTE handset between Carriers?

Forget it! After cellular service moved away from Analog AMPS, this became difficult enough with ANSI-136 TDMA and ANSI-95 CDMA deployments years ago. And with the GSM and CDMA separation, it pretty much became impossible.

Even when more than one Carrier deployed ANSI-2000 CDMA at 1.9 GHz in most markets, internal radio setups and configurations made it tough. Samsung, for example, shipped identical versions of some handsets like the SCH-i730: one for use on Verizon and one for use on Sprint!

For M2M deployments, Aeris learned how to make CDMA 800/1900 MHz modules move, over the air, between Carriers, without artificially blocking the capability. In fact, we tell our Customers that if they are truly dissatisfied with our M2M network services, we will help migrate their units, over the air if possible, to a Carrier of their choice!

With LTE, and the current crop of LTE Modules being developed for use at just one or two Carrier-specific LTE bands, this will be well-nigh impossible too. The Grand Unification, that LTE will bring all the Carriers back to using the same technology again (like they used to do with Analog AMPS in the US), is a false hope. Today and for more years to come.

Once a Customer selects a Carrier and radio, they may be with them for years. Given the longevity of M2M Devices once actually deployed in the field, selecting a service provider carefully, becomes a critical step.

With a polite nod to the late Mister Rogers (my apologies to International readers who may not understand the reference): “Kids, do you know how to say Monopoly”?

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!

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