Adding Wireless Communication Capability to Embedded Systems

How practical is it to use the airwaves as a communications medium for embedded systems? The author describes his experience developing a packet radio protocol stack for a single-board computer and the issues involved with integrating wireless communications into embedded systems.

Modern microcontrollers offer more capability than is often used in a typical embedded system application. Normally, processor capacity is applied to data gathering and control functions such as sensing temperature, controlling motors, or driving other physical interfaces. Communications capability is usually a secondary consideration resulting in applications that donıt really work together if they communicate at all. For this reason, many of todayıs products donıt team up and share a workload or exchange information. Future microcontroller-based products will have the smarts to operate as a collective whole by taking advantage of a variety of communication technologies. One technology gaining popularity is wireless data communications. Mobitex wireless data is a mobile radio system used for a variety of applications. Available in more than 6,000 U.S. cities and 33 countries worldwide, it is an international standard for packet switched messaging and data interchange. In this article, I show how wireless data capability can be incorporated into an embedded system by looking at the Mobitex system and exploring the design and usage of Mobitex interface software intended to be highly portable across many microcontroller platforms. The focus is on the software design and system integration aspects rather than radio frequency application and theory.

THE MOBITEX NETWORK

The original concept was the design of a mobile alarm system used by field personnel of the Swedish telephone company. Mobitex has evolved into a widespread public mobile radio service in use in over 83 countries around the world. Standardization of all Mobitex networks and compatibility of network features is ensured by the Mobitex Operators Association (MOA). MOA is an independent organization that publishes an open standard document known as the Mobitex Interface Specification. The standard defines the following specifications in great detail:

• The interface between radio modems and mobile terminals
  
• The over-the-air protocol between radio modems and base stations
  
• The network level protocol and packet format
  
• The interface between fixed terminals and the network
  
• Application services
  
  

Under Mobitex, packet switching is a very efficient way to transfer data. In packet switching, no end-to-end connection is established. Instead, a packet of data is transferred between successive nodes until it reaches its final destination. In circuit switched systems, a circuit must be set up between the two endpoints. When a circuit switched system is used over shared radio channels, no other traffic can be put on the channel during the setup phase, which is one reason why packet switched data is more efficient for wireless data communication over shared radio channels.

RAM Mobile Data USA Limited Partnership operates a Mobitex network with an over-the-air speed of 8K bits per second in the 900MHz frequency range. Coverage extends to over 7,000 cities and towns. RAM also provides standard interfaces for customer fixed host connectivity through a variety of protocols including TCP/IP, LU2, X.25, POS, and AT.

The RAM Mobitex network is illustrated in Figure 1. The network is made of the following components:

• Mobile Data Terminal--Typically a PC or other device used to run the end-user application.
  
• Radio Modem or Adapter--Connects the mobile terminal to the network via RF protocol. Uses the MASC protocol to maintain a connection to the Mobile Data Terminal.
  
• Base Station--Manages all of the radio communications in a given area or cell of the network. Two frequencies are used for each channel, one for transmitting and one for receiving. Handles traffic routing, roaming, subscriber registration, and protocol handling for all users in a given cell.
  
• Regional Switch--Connected between the main exchange and the base stations. Joins a set of base stations into a subnet.
  
• Main Exchange--The top-most switching node in the network. Routes packet traffic between the regional switches.
  
• Network Control Center--Used by the system personnel to supervise, configure, control, manage and operate the entire Mobitex system.
  
  

The structure is hierarchical and contains five levels: mobiles, base stations, local switches, regional switches, and the network control center. The system turns around messages between customers at the lowest common network node, ensuring quick response time and reducing traffic in the network. Only packets with destinations at the farthest service area must propagate to the highest level.

Customer fixed or non-mobile host connections are made at the local switch level, and any carrier can be used for the land line connection. Fixed-host connections can be made through gateways that translate Mobitex to customer protocols such as TCP/IP or SNA. As an alternative to using a gateway, host software can be used for building Mobitex awareness into applications. Many third-party vendors provide host Mobitex software for platforms ranging from IBM mainframes and Unix systems to PCs.

Other Mobitex terminology used in this article include: Mobitex Access Number (MAN), a seven-digit number that makes up a subscriberıs address; Mobitex Asynchronous Communications (MASC), the protocol between the PC and the radio modem; and Mobitex Packet (MPAK), which refers to the format of the network packets.

THE MOBITEX PROTOCOL

Applications designed to interface with Mobitex networks may use many protocols. The two required for interfacing between a mobile terminal and radio modem are: MASC and MPAK (Mobitex Packet).

MASC operates on top of the RS-232 physical layer and provides a reliable data link connection between the terminal and radio modem. MASC formats the data into frames with sequence numbers and error detection capability. Information about the status of the radio, base station coverage, and battery strength is available from the MASC layer. MASC requires a handshake between the radio modem and terminal at least every 30 seconds during periods of inactivity to maintain the connection.

All messages are sent through the network in packets called MPAKs that contain up to 512 bytes of user data coded as ASCII text or binary data. Each MPAK contains addressing information, network data, and user data. Messages longer than 512 bytes must be sent in multiple MPAKs. The source and destination addresses, or MAN numbers, must be specified in the MPAK for delivery. To broadcast messages to multiple users, destinations can be lists of MAN numbers or group MAN numbers. In any case, the system will only send a single copy of the packet over the air.

If the destination mobile user is not currently active on the network, an optional store and forward feature has the network retain the message and deliver it the next time the mobile user is active on the network.

Other optional features supported by the network include: positive acknowledgment of messages, personal user logins, and a battery saving mode for mobile terminals. Packet overhead incurred by the network amounts to only eight bytes.

Because MASC provides the link layer necessary to send and receive MPAKs between a radio modem and a terminal, MPAKs are encapsulated in MASC frames. When it is time to send the MPAK over the radio link, the MPAK is removed from the MASC frame and sent using the over-the-air radio link layer protocol to ensure proper reception by the base station. I will not go into the radio link protocol. I make the assumption that once the radio modem has the MPAK, and if the mobile is in coverage, the base station will receive the MPAK correctly.

Now that I've described the wireless network and the protocols, it should be clear that for a device to communicate wirelessly, it must be able to send and receive data from a Mobitex radio modem over a serial link and implement the MASC and MPAK protocols. The remainder of this article describes the design elements and portability aspects of Mobitex interface software, a wireless data application implemented with the software, and general design considerations for wireless applications.

MOBITEX INTERFACE TECHNOLOGY

RAM Mobile Data has developed Mobitex interface software designed to make it relatively easy to build wireless applications. The software is written in ANSI C and designed to be ported to many hardware platforms including embedded microcontrollers. Highly modular, the interface software allows Mobitex configurations ranging from full functionality to the minimal subset necessary for network communications. Two levels of configurability are provided. Compiler time constants eliminate code and data during the compile phase, and because functional areas are partitioned into separate source code files, memory requirements are further reduced by linking in only necessary functions.

The interface software is made up of three modules: an operating system interface that contains interfaces to system resources, a MASC module that contains the MASC protocol implementation, and an MPAK that implements the MPAK network protocol. All three modules work together to present a complete Mobitex interface to application designers without placing high demands on system resources. Each module is described in the following and illustrated in Figure 2.

• Operating system interface--Contains interfaces to systems resources including timers, memory, queues, process dispatching, system configuration, and communication ports
  
• MASC module--Implements the MASC protocol by handling the communication dialog between the radio modem and the computer
  
• MPAK module--Implements the MPAK protocol including the packet dialogs between the mobile computer and the network
  
  

Because the serial port is accessed exclusively through interfaces in the OS Interface module, it corresponds to layer 1 or the physical layer of the OSI seven layer model. MASC maps into link layer or level 2 of OSI since it provides a data channel between two adjacent nodes of the network. By providing reliable end-to-end services, the MPAK module is at the network or level 3 of the OSI model. The interface software modules also correspond to the OSI model in the way the data is passed across the layers. A higher layer registers with a lower layer for services. When an event occurs that is of interest to a higher layer, the lower layer will provide an indication to the higher layer by executing a callback function specified during registration. For example, MPAK registers with MASC to receive packets that arrive at the radio modem. When a packet is available, MASC calls the receive packet function that was provided by MPAK during registration. Similarly, MASC registers with the OS interface to receive characters when they come into the serial port. Upon arrival of data at the communications port, OS interface functions try to assemble a complete data frame before passing an indication to MASC.

Wireless data applications written on top of the MPAK layer follow the same procedure. These applications register for packets with the MPAK layer and are invoked when the packets of interest are received. Applications can also register for MASC events. For example, users of wireless data applications need to be aware of when they are in coverage and the radio signal strength at any given time, so they can decide when to send or expect data. Because MASC is the interface to the radio and is the provider of such information, applications can register directly with MASC to receive notification of coverage status changes or when signal strength value crosses a given threshold. Applications can also avail themselves of services in the operating system module. If a periodic timer is needed, the application can register to be interrupted at regular intervals to poll for a certain event or perform some housekeeping. Therefore, unlike the OSI seven-layer model, a higher layer process using the Mobitex interface software is not limited to the services of the next lower layer. It can make use of interfaces that reside in all three lower layer modules.

The service interface to all three modules follows the same pattern: a higher layer registers with a lower layer with an API call that specifies the event of interest and a function to be called when the event occurs. Registration information is maintained by each layer in queues, and when the event is triggered, the queue is scanned to determine who should be informed of the event. This mechanism can be abstracted and generalized in all layers. In software design, whenever a concept can be generalized, code savings can be realized by developing a reusable framework that implements the generic functions. In this case, each Mobitex interface module can be abstracted into two discrete components. The first component contains the entry points or registration functions for users of the layer. Action functions that are used internally within the layer make up the second component. The entry functions "present" the layer to the outside world by exposing the service definition and facilitating data flow across the layer. The action functions are the internals of the layer and are users of entry functions of other layers. Action functions are also responsible for delivering indications to upper layers or users of the entry functions. Figure 3 illustrates the structure of the service and user layers.

Finite state machines are almost always used for implementing communication protocols because they provide a framework for correlating input data with actions. Both the MASC, MPAK, and portions of the operating system interface are structured as finite state machines. Again, a generic framework is used for implementation to reduce the code size. The finite state machine framework consists of a set of states and a set of transition functions that drive the machine though different protocol phases based on input events. States are represented in a table and corresponding function pointers reference the transition functions. An entry function maintains the current state, passes input events and invokes the transition functions.

In the Mobitex interface software, finite state machines are coupled with the service model previously described to implement the MASC and MPAK protocols. Registration requests translate to events and are put on a deferred event queue. The dispatch machine retrieves the next event from the queue and invokes the machine responsible for handling the event or request. Real-time events such as characters received or timers firing are treated the same way. Each queue element contains the ID of the machine and data parameters specific to the event that will be passed to the machine. The dispatcher maintains a table containing machine entry functions, a machine ID. The event structure and finite state machine table is defined by the following structure definitions:

A machine can register with the dispatcher by providing a machine entry function, a machine ID, and an initial state. The event queuing function and dispatcher is implemented by the following code:

The EventDispatch function can be called during idle time and will perform a unit of work. Entry functions are implemented by queuing an event for each request and then returning an in-progress indicator to the caller. Action functions are called by the machine entry functions and carry out the state transitions necessary to complete the request. For example, if the user requests coverage status from the MASC module, the coverage status entry function is called, which will queue the request and then return. Eventually the action function associated with coverage status is called by the MASC machine. The action function will then construct the necessary command and send it to the radio modem. When the radio modem responds, the response is queued by the serial port interrupt handler in the operating system interface module. The MASC machine will then complete the request by taking the response and passing it back to the original requester by calling the requesterıs callback or completion function.

The Mobitex interface software has minimal impact on the system CPU because the majority of the protocol work is triggered by the dispatch function, which is completely controlled by the application. Both the serial communications and timer interrupt handlers perform minimal work queuing requests to the deferred event queue. The queuing operation involves only a single address write to append the request. The serial communications interrupt handler must buffer every character that comes into the serial port and call the OS interface function to assemble a frame. In the timer interrupt service routine, a queue must be scanned for expired timers. But since the timer queue is maintained in sorted order in memory, the search time is minimal.

PORTING ISSUES

When looking at the target platform under consideration for running the Mobitex interface software, the processor must be capable of handling interrupts from a real-time clock and a communication port. The communication port must be RS-232 capable with at least send, receive, and ground signals. Memory requirements depend on the exact Mobitex features that are needed and range from 70K of code and 10K of data for full Mobitex features, to 40K of code and 8K of data for a minimal feature set. Flash RAM can be used for code memory and static constant data.

To port the Mobitex interface software to a microcontroller, native functions must be written for dynamic memory allocation and deallocation, receiving and sending characters via the serial communications port on an interrupt basis, and a timer interrupt that will get control at least every 500ms.

Memory allocation and deallocation can be directly implemented by native malloc and free function calls usually supplied with the run time library of the C compiler. The OS Interface module keeps careful track of all memory allocations. All locations are maintained on an independent linked list to ensure that memory is returned to the system when it is no longer needed.

Serial communication functions are not as generic as memory functionsıthey must be interrupt driven and capable of reading and writing characters from an RS-232 port. The following are the communications interrupt routines for a 68332 processor:

ServiceInputChar supplies characters to the MASC module by buffering up BUFF_SIZE characters as they are received and then calling the OS interface function, OSIntCommProc, to process the buffer. The buffer size should be no larger than the smallest MASC frame that requires a response (four bytes). Otherwise the radio modem will wait forever because the buffer will never be processed--it will be sitting in the input buffer waiting for more characters to arrive.

OSIntCommProc assembles the received bytes into a complete frame. When a complete frame has been received, OSIntCommProc queues the frame on a receive queue and then queues an event on the deferred event queue for the MASC module. When the MASC action function that handles received frame gets called it will fetch the frame from the receive queue and process it.

The send character function is symmetrical to the ServeInputChar routine except that it maintains an output buffer and writes it out to the UART when it is full. After the buffer is sent, an output completion event is queued on the deferred event queue to indicate to the MASC layer that a frame was sent. The buffer size for the send character function should be no larger than the smallest frame to be sent.

Timer services provided by the OS interface module are driven by a 500ms timer. The timer interrupt service routine must call TimerProc to maintain the timer request queues.

The MASC and MPAK modules call the OS interface functions exclusively, so no porting is needed. It usually takes less than one day to get the Mobitex interface software running on a new platform.

Listing 1 demonstrates the use of the MPAK layer by reflecting back to the sender any packet that is received. All calls return immediately with an in-progress return code. Final completion is always indicated by invoking the supplied callback function.

APPLICATION DESIGN CONSIDERATIONS

Because of the high latency and connection intermittency associated with wireless data networks, existing applications based on wired technology must be re-worked for wireless. Applications that set up virtual circuits and stream data end-to-end must be redesigned to follow the connectionless model where data is partitioned into individual units and sent out as packets. Because packet drivers that will run TCP/IP-based applications transparently over wireless are available, it is often assumed that no changes to the application are required. This assumption leads to disastrous results because transport protocols such as TCP conduct a three-way handshake during the connection phase, which uses the round-trip packet time to calculate time-out values. On a wireless network the round-trip time grows excessively large and eventually times out on most TCP/IP protocol stacks. Similar scenarios occur with IPX protocols. You canıt assume just because the transport is available and the protocol stack will function, that the application will run wireless without modification. There is work underway to improve this situation by providing protocol optimization over wireless transparently to the protocol stack. Two methods include spoofing the transport layer by eliminating protocol handshake phases and other traffic intensive dialogs, and using very aggressive data compression schemes. But, wireless awareness to the application is still strongly recommended.

There are other considerations as well. If the data is private, encryption schemes must be used because everyone has free access to the airwaves and the data could be easily intercepted. Data compression should be used end-to-end to minimize packet sizes, reduce cost, and conserve the airlink. Dialogs between applications should be structured in such a way that multiple commands can be sent to be operated on. For example, a client process should include a login string and several commands to be processed by the server process, rather than sending the login string and waiting for a response before sending commands. The concept of a user agent is now becoming popular for wireless applications. User agents are resident processes on large hosts or server computers and are pre-programmed with libraries of agent scripts. The mobile client sends small high-level commands to the agent who carries out the request by executing a stored procedure that performs many commands on the host on behalf of the mobile. The idea is to minimize the over-the-air dialog by making the agent very smart. This process is done by including decision-making logic and only sending complete information back to the mobile.

Applications should also take into account that wireless links are constantly changing. In a vehicle mounted system, the mobile could go in and out of signal coverage as the vehicle moves across the cell. Intelligent send and receive retry algorithms should be used, which take into account the coverage state, and should not attempt a retry until the signal is strong enough to ensure good reception or transmission. Feedback should be given to the user. In some cases users should be included in the retry decision. Users will have a good idea of the coverage at a given location, and the combination battery level and signal strength can be used to conserve or optimize power usage. A good test for wireless applications is to stress the application at a fringe area of coverage to see how it reacts to the transitions. Finally, applications should always give the user the capability to silence the radio at any time to prevent radio interference with other more critical systems such as medical devices or construction site equipment.

AFTERTHOUGHTS

Wireless data communications technology offers the embedded system designer the capability to add sophisticated communications functions without the need for wires or cabling. The technology is now widely accepted. Reliable network infrastructures are in place and development tools are available.

Roy Tarantino is a consulting engineer with RAM Mobile Data. At RAM he develops connectivity tools for RAM's wireless Mobitex network. Prior to RAM, Roy was active in many projects including the development of embedded medical device software, network management tools, cellular infrastructure planning, and firmware development for a combination pager, mobile phone, and two way radio. He holds an MS degree in Engineering and Computer Science from Stevens Institute of Technology and can be reached at rtarantino@ram.com.