_____                   _                  _____            _____       _ 
  |     |___ _____ ___ _ _| |_ ___ ___ ___   |  _  |___ ___   | __  |___ _| |
  |   --| . |     | . | | |  _| -_|  _|_ -|  |     |  _| -_|  | __ -| .'| . |
  |_____|___|_|_|_|  _|___|_| |___|_| |___|  |__|__|_| |___|  |_____|__,|___|
  a newsletter by |_| j. b. crawford               home archive subscribe rss

>>> 2020-12-18 og mobile data

I promised that I would say a bit about mobile data terminals, and now here we are. This is an interesting topic to me for two reasons: first, it involves weird old digital radio and network protocols. Second, MDTs have weird intersection with both paging and cellular data, such that I would present them as being a "middle step" in the evolution from early mobile telephony (e.g. IMTS car phones) to our modern concept of cellular networks as being data-first (particularly VoLTE where voice is "over the top" of the data network).

To start with, what is a mobile data terminal (MDT)? An MDT is a device installed in a vehicle and used by a field worker to interact with central information services. Perhaps the best-known users of MDTs are police agencies, which typically use MDTs to allow officers in their vehicles to retrieve motor vehicle and law enforcement records, and sometimes also to write citations and reports in an online manner (meaning that they are filed in a computer system immediately, rather than at the end of the shift).

MDTs are not restricted to law enforcement, though. MDTs are also commonly used by utility companies such as gas and electric, where GIS features are particularly important to allow service technicians to view system diagrams and maps. They are also commonly used by public transit agencies, taxis, and other transportation companies, although these tend to be somewhat more specialized devices with more limited capabilities---for example, a common MDT in public transit scenarios is a device which reports position to dispatch, displays the route schedule to the driver, and allows the driver to send a small number of preset messages (e.g. "off schedule") to dispatch and see the response.

I'm more interested in the more "general purpose" MDTs which may, but do not necessarily, run a desktop operating system such as Windows. Today, MDT typically refers to a Toughbook or similar laptop computer which is equipped with an LTE modem (sometimes external) and can be locked into a dock which is hard mounted to the vehicle. Since most modern MDTs are just laptops, they can typically also be removed from the vehicle and used in a portable fashion, but that's a fairly new development.

There is also some slight terminology confusion to address before I get into the backstory: the term "mobile data computer" or MDC is essentially synonymous with MDT, and you may see it used instead in some cases. Handheld devices, on the other hand, are largely a Whole Different Thing.

MDTs were, for the most part, invented by Motorola. Early MDTs had vacuum fluorescent character displays, although they fairly quickly progressed to CRTs. The classic Motorola MDT has a full keyboard, but is also equipped with a number of "preset" buttons which send a given message to dispatch with a single press. Early MDTs ran special-purpose operating systems which were presumably very simple, and applications for them were largely custom-developed by Motorola or an integrator.

So how did these things actually communicate? MDTs were a fairly common tool of various municipal and utility agencies by the end of the 1970s, well before any kind of cellular data network. Indeed, they may be the first instance of a wide-area radio data network with more flexible capabilities than paging systems, and in many ways they worked with infrastructure that was ahead of its time---and also excessively expensive.

Various MDT data protocols have come and gone, but perhaps the earliest to be significantly capable and widespread is a Motorola system called MDC-4800 (Motorola tended to prefer the term MDC), introduced in 1980. The "4800" in the name is for 4800 bits per second, and the protocol, at a low level, is frequency-shift keying.

Typically, a Motorola MDT would be connected to a "Vehicular Radio Modem," although in early MDTs the VRM was not necessarily viewed as a separate product but rather part of the system. The VRM is essentially a VHF or UHF two-way radio which has the discriminator output connected to a packet modem. True to this description, many Motorola VRMs were closely based on contemporary VHF/UHF radio models.

MDC-4800 moved 256-byte packets and the protocol had support for packet reassembly into larger messages, although the messages were still fairly constrained in length. In many ways it is a clear ancestor to modern cellular data systems, being a packet-based radio data system intended for general purpose computer applications.

Where MDC-4800 gets particularly interesting, though, is in its applications. MDC-4800 was directly used by proprietary, semi-custom systems developed for various MDT users. Much of MDC-4800's ubiquity, though, came from a collaboration of Motorola and IBM. At the time, being the late '70s into the early '80s, IBM was in possession of a large fleet of service technicians who worked out of trucks, a substantial budget, and a limitless lust for solving problems with their computers. IBM began a partnership with Motorola to develop a futuristic computerized dispatch and communications system for their service technicians, which would be based on Motorola MDTs.

In the course of developing a solution for IBM, Motorola developed an integrated network system called DataTAC. DataTAC expanded on MDC-4800 to build a multi-subscriber data network operating in the 800MHz band, and Motorola partnered with various other organizations (mostly telcos) to establish DataTAC as a generally available service. In the US, the DataTAC service was known as ARDIS. ARDIS was widely used by MDT users of all stripes including municipal governments and businesses, but it could also support pagers and in a clear bridge to the modern era, early BlackBerry devices actually used ARDIS for messaging and email. ARDIS continued to operate as a commercial service into the late '90s and was upgraded to subsequent protocols to improve its speed and reliability.

DataTAC is often recognized as a "1G" cellular technology, for example by the Wikipedia categories. This is a bit confusing, though, as for the large part "1G" is synonymous with AMPS which was an analog, voice-only system. I believe that it is only from a modern perspective that DataTAC would be put in the same category as AMPS---the perspective that mobile telephony and data would become a unified service, which was not nearly so obvious in the '80s or even '90s when these were separate technologies offered by separate vendors as separate product lines, and generally seen as having completely separate applications. In a full-circle to my last message, it was pagers that seemed to "bridge the gap," as relatively sophisticated pagers can and did operate on the ARDIS network while still feeling like a "phone-ish" item.

ARDIS was later transitioned to using a protocol called RD-LAP, which was also developed by Motorola for MDT use. RD-LAP was similar to MDC-4800 in many ways except being faster, and so represented an evolutionary step rather than revolutionary. However, RD-LAP stands out for having had an impressively long lifespan, and while largely obsolete it is still seen today in various municipal agencies that have not found the budget to modernize. RD-LAP is capable of an impressive 19.2 kbps, which doesn't sound like much but was impressive for the time.

ARDIS was not alone in being an odd data service in an era largely seen as before mobile data. ARDIS had a contemporary in Mobitex, which was developed in Europe but also seen in the US. Mobitex was a centralized network with very similar capabilities to ARDIS, and was particularly popular for two-way pagers. Mobitex was also used by BlackBerry, and the fact that BlackBerries used Mobitex and ARDIS in various models, perhaps the first wide-area radio data protocols to exist, is a reminder of just how revolutionary the product once was, considering RIM's total lack of relevance today.

Mobitex also saw significant use for MDTs, although in the US it was less popular than ARDIS for this purpose. Mobitex seems to have been particularly popular for in-the-field credit card processing, although I would not be the least bit surprised if ARDIS credit card terminals were also made.

ARDIS and Mobitex represent an important early stage of modern cellular networks, but also show some significant differences from the cellular networks of today. Both systems were available as commercial services with nationwide networks but were also often deployed on a local scale, especially by municipal governments and, in some areas, state governments, for public safety and municipal utility use. This remains surprisingly common today in the case of municipal LTE (significant spectrum reserved for government use makes it surprisingly easy for municipalities to launch private LTE networks and many do so), but for the most part isn't something we think about any more, at least in the business world. A large part of the popularity of MDC-4800 and RD-LAP in particular is the fact that they could be deployed on existing business or municipal band VHF or UHF allocations, making them fairly easy to fit into an existing public safety or land mobile radio infrastructure.

About those VRMs, by the way: when Motorola began to offer VRM data modems as independent products, they sported a serial interface so that they could essentially be used as typical data modems by any arbitrary computer. This was the transformation from MDTs as dedicated special-purpose devices to MDTs as general-purpose computers that happen to have a data radio capability. Motorola themselves made a series of MDTs which were really just Windows computers in ruggedized enclosures with a touchscreen and a VRM.

Architecturally, MDT systems strongly showed their origins in the early ear of computing and the involvement of IBM in their evolution. Most of the software used on MDTs historically and in many cases to this day really just amounted to a textmode terminal that exchanged messages with a mainframe application, and often with an IBM ISPF-type user interface full of function keys and a "screen as message" metaphor[1].

MDTs and the data networks they used are an important but largely forgotten development in mobile networks... are there others? Of course, quite a number of them. One that I find interesting and worth pointing out is a technology that also took an approach of merging telephony together with land mobile radio technology: iDEN. Also developed by Motorola, iDEN was a cellular standard ("2G"-ish) that was directly derived from trunking radio technology. First available in '93, iDEN could carry phone calls much like AMPS (or more like digital AMPS) but also inherited many of the features of a trunking radio system, meaning that a group of iDEN users could have an ongoing push-to-talk connection to a "channel" much like a two-way radio. This was particularly popular with small businesses, which gained the convenience of two-way radio dispatch without the cost of the equipment---it was built into their phones.

iDEN is, of course, recognized by most under the name Nextel, the carrier which deployed a wide-scale iDEN network in the US. Nextel heavily advertised its PTT functionality not just to businesses but also to chatty consumers. Nextel television commercials and the distinctive Motorola roger beep are deeply burned into my brain from many hours of childhood cable television, and even as a kid I was pretty amazed by the PTT capability.

Nextel was of course merged with Sprint, and while the iDEN service continued to exist for some time it was not of great interest to Sprint and was officially terminated in 2013. This is actually rather sad to me, because modern cellular networks are surprisingly incapable of offering the quality of PTT service achieved by Nextel---modern PTT services are generally IP based and suffer from significant latency and reliability problems.

So let's try to come back to the idea that I brought up in the previous post, that commodification of technology also tends to eliminate special-purpose technologies which ultimately reduces the utility of technology to many use-cases. iDEN seems to me actually an exceptionally clear case of this: iDEN solved a specific problem in a very effective way, making something akin to two-way radio significantly more accessible to three-person plumbing companies and teenagers alike. Ultimately, though, iDEN was not able to compete with the far larger market share and rapidly improving data services of the GSM and CDMA/IS-2000 family of standards, and it seems that simple market forces destroyed it. Because the problem that iDEN solved well is actually a rather hard problem (reliable, real-time delivery of voice with minimal or no connection setup required, guaranteed bandwidth via traffic engineering being the big part IP fails to deliver), it's one that has in a large way gone from solved to unsolved in the last ten years. We have witnessed a regression of cellular technology, which is particularly prominent to me since I've developed an odd fascination with "Android radios" that are really just Android phones in a handheld radio format (with push-to-talk button) and that there aren't really many good ways to actually use.

What about the decline of Mobitex and ARDIS, though? To my knowledge Mobitex actually remains available in the US to this day, but I believe ARDIS fizzled out after Motorola divested the operation. I have a hard time shedding too many tears for these services, because since they were basically just packet-switched radio networks, modern cellular networks can outdo them on essentially all metrics. Mobitex and ARDIS were generally more reliable than modern cellular data, part of the reason they survived so long, but a lot of this realistically is just due to their low data rates and low subscriber counts. A Mobitex weighed down by a city worth of Instagram users would presumably collapse just as much as LTE does at the state fair.

It is, however, notable that many of these older technologies were quite amenable to being stood up by a government or company as a private network. That's something that isn't especially easy for a private company to achieve today, even if they for reason wanted to (I want to). Most radio data protocols that are available on an unlicensed basis or that it's reasonably easy to obtain licenses for are either low-speed or require directional antennas and short ranges. This is even true in the amateur radio world, although it's fairly clear there that progress has been held back by the FCC's archaic rules regarding data rates. I think that this essentially comes down to the strong competition between cellular carriers meaning that any bandwidth freed for broadband data applications ends up going for a high value at auction, not to Joe Schmuck who put in a license application. Perhaps we're better off anyway as shared networks (the cellular carriers) are presumably always going to be more economical... but given the reliability and customer relationship issues that mobile carriers often face it's not clear to me that the business world wouldn't have more interest in private networks if they were reasonably achievable.

Low-power unlicensed LTE does present one opportunity, and I'll let you know when I one day give in and buy a low-power LTE base station for my roof.

[1] By "screen as message" I refer to the interface design common among IBM and other mainframe applications, and formalized in various standards such as ISPF, in which the interface is screen-oriented rather than line-oriented---meaning that the mainframe paints an entire screen on the terminal, the user "edits" the screen by filling in form fields and etc, and the terminal sends the entire screen back and waits for a new one. I actually find this UI paradigm to be remarkably intuitive even in textmode (it is a direct parallel to "documents" and "forms") and regret that, largely due to simple technical limitations, the microcomputers that took over in the '90s mostly discarded this design in favor of a line-oriented command shell. Web applications are (or at least were, before SPAs) based on a very similar model which I think shows that it has some enduring value, but it's very hard to find any significant implementation in textmode today outside of a few Newt-based Linux tools which suffer from Newt's UX being, frankly, an absolute mess compared to IBM's carefully planned and researched UX conventions. Besides, most of us still have 12 function keys, might as well actually use them.