RETURN

by ROY TARANTINO

Adding Wireless Communication

Capability to Embedded Systems
odern
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 dont really work
together if they communicate at all.
For this reason, many of todays products dont 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.

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.

THE MOBITEX NETWORK

he 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

TR2

T
38 EMBEDDED SYSTEMS PROGRAMMING

FEBRUARY 1996

Under Mobitex,
packet switching
is a very efficient
way to transfer
data. In packet
switching, no endto-end connection
is established.
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 TerminalTypically 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 StationManages 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 SwitchConnected between the main exchange and the
base stations. Joins a set of base stations into a subnet.
Main ExchangeThe top-most
switching node in the network.
Routes packet traffic between the
regional switches.
Network Control CenterUsed 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 net-

FEBRUARY 1996 EMBEDDED SYSTEMS PROGRAMMING 39

work 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 subscribers 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
pplications 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 RS232 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 Ive 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.
FEBRUARY 1996 EMBEDDED SYSTEMS PROGRAMMING 41

Wireless
MOBITEX INTERFACE TECHNOLOGY
AM 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 moduleImplements the
MASC protocol by handling the
communication dialog between the
radio modem and the computer
MPAK moduleImplements 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

42 EMBEDDED SYSTEMS PROGRAMMING

FEBRUARY 1996

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

FIGURE 1
A basic Mobitex system.

Regional
Switch
(MHX)

Local
Switch
(MQX)

Local
Switch
(MQX)
Subnet

Subnet

Local
Switch
(MQX)
Subnet

FEBRUARY 1996 EMBEDDED SYSTEMS PROGRAMMING 43

Wireless Communication
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.
FIGURE 2
Mobitex Interface Software Modules.

Wireless Application
MPAK Module
MASC Module

Operating System Interface

System Resources: Timer,

Comm. Port, Memory

44 EMBEDDED SYSTEMS PROGRAMMING

FEBRUARY 1996

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. Realtime 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:
typedef struct
{
DLINK DataLink;
/* Pointer to next deferred event */
MACHINE_ENT *Machine;
/* Destination machine */
void
*Param;
/* Data to be passed */
USHORT Event;
/* Associated event number */
} DEFERRED_EVENT;

typedef struct
{
FSM_ID
MachID;
/* ID number of machine */
VOID_FPTR MachEntry;
/* Address of machine entry function */
} MACHINE_ENT;
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:
/*
Queue an event for machine execution.
*/
RetCode EventDefer(FSM_ID MachID, ushort
event, void *param)
{
MACHINE_ENT *LookupMachine(FSM_ID);
MACHINE_ENT *Machine =
LookupMachine(MachID);
DEFERRED_EVENT DeferredEvent;
RetCode AppendList( LIST list, void
*ListElem);
if (Machine == NULL_MACHINE)
{
/* Not found, return error */
return (MACHINE_NOT_FOUND);
}
DeferredEvent.Machine = Machine;
DeferredEvent.Event = event;
DeferredEvent.Param = param;
return (AppendList(DeferredEventList,
&DeferredEvent);
}
/*
Execute the next event on the deferred
event queue.
*/
void DispatchEvent()
{
DEFERRED_EVENT DeferredEvent
MACHINE_ENT *Machine;
DeferredEvent = (DEFERRED_EVENT *)
ListRemoveHead(DeferredEventList);
if (DeferredEvent != NULL_EVENT)
{
FEBRUARY 1996 EMBEDDED SYSTEMS PROGRAMMING 45

Wireless Communication
Machine = DeferredEvent->Machine;
Machine->MachEntry(DeferredEvent->Event,
DeferredEvent->Param);
MemFree(DeferredEvent);
}
else
{
/* No work to do. */
}
}
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 requesters
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

46 EMBEDDED SYSTEMS PROGRAMMING

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
hen 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:

/*
Mobitex Interface Software Character
Interrupt Routine
FEBRUARY 1996

Uses the 68332 Time Processor Unit (TPU)

Uart Function
*/
#define UARTDATAREG
0xf04
void ServiceInputChar(void)
{
/* Get the character from the UART memory
mapped area */
InputBuff[InputCount++] = 0xff & *((uspv)
(IMBASE +
(UARTDATAREG +(TPU_INPUT_CHAN<<1))));
if (inputCount >= BUFF_SIZE)
{
OSIntCommProc(InputBuff, InputCount);
InputCount = 0;
}
TPUClearInterrupt(TPU_INPUT_CHANNEL);
}
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 processedit 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 inprogress return code. Final completion
is always indicated by invoking the
supplied callback function.
APPLICATION DESIGN
CONSIDERATIONS
ecause 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-toend 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 cant 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.

FIGURE 3
The service layer framework.

User Layer
User Functions

Function calls

Callbacks

Indications

Entry Functions
(Exposed Interface)

Action Functions (Layer Internals)

Queued
Event

Queued
Event

Queued
Event

Deferred Event Queue

Service Layer

FEBRUARY 1996 EMBEDDED SYSTEMS PROGRAMMING 47

Wireless Communication
LISTING 1
Simple Mobitex Interface Software
Test Program.
*/
Wait for a packet, when one comes in reflect it
back to the sender.
*/
#include <stdio.h>
#include <string.h>

#include "mpakuser.h"
int my_state=0;
MPAK_STATS StatsData;
MACH_HNDL hMachine;
char mpakbuf[512];
main()
{
RQST_ID Request;

REG_HNDL RegHdl, RegStats;

void MyCompletionFunctions (WORD, RET_CODE,
RQST_ID,
void *, LEN_TYPE);
RET_CODE MyRcvFunction (int, REG_HNDL, PKT_TYPE,
void *, LEN_TYPE);
long rc;
/* 1. Initialize the OS Int and MPAK Modules. */
printf("main: calling OsIntInit()\n");
OsIntInit();
printf("main: calling Mpak_Init()\n");
rc = Mpak_Init(&hMachine, &Request,
(VOID_FUNC_PTR) MyCompletionFunctions);
if (rc != REQUEST_PENDING)
{
printf("Mpak_Init failed\n");
exit(1);
}
printf("waiting for INIT_CPLT...\n");
while(my_state != MPAK_INIT_CPLT)
; /* Do some other work */
/* 2. Register for all packets. */
rc = Mpak_DataRegister(hMachine, &Request,
&RegHdl,
(RC_FUNC_PTR) MyRcvFunction, MPAK_REG_ANY,
HPID_ANY, MAN_ANY, MAN_ANY);
if (rc != REQUEST_PENDING)
{
printf("Mpak_DataRegister failed\n");
exit(1);
}
/* 3. Enable the MPAK Layer. */
rc = Mpak_Enable(hMachine, &Request);
if (rc != REQUEST_PENDING)
{
printf("Mpak_Enable failed\n");
exit(1);
}
printf("waiting for ENABLE_CPLT...\n");
while(my_state != MPAK_ENABLE_CPLT)
; /* Do some other work */
/* 4. Now wait for a packet. */
printf("Waiting for incoming packets:\n");
while (1)
; /* Do some other work */
} /* end of main */
void MyCompletionFunction (WORD IndType, RET_CODE
Status,

48 EMBEDDED SYSTEMS PROGRAMMING

FEBRUARY 1996

LISTING 1 (CONTINUED)
mpakbuf[2] = mpakbuf[5];
RQST_ID RqstID, void *data, LEN_TYPE
length)
{
printf("main: in MyCompletionFunctions ");
switch(IndType)
{
case MPAK_INIT_CPLT:
printf("status=%s\n",
(Status==SUCCESS)?"SUCCESS":"FAILED");
my_state=MPAK_INIT_CPLT;
break;
case MPAK_ENABLE_CPLT:
printf("status=%s\n",
(Status==SUCCESS)?"SUCCESS":"FAILED");
my_state=MPAK_ENABLE_CPLT;
break;
case MPAK_DATA_REG_CPLT:
printf("status=%s\n",
(Status==SUCCESS)?"SUCCESS":"FAILED");
my_state=MPAK_DATA_REG_CPLT;
break;
case MPAK_SEND_CPLT:
printf("status=%s\n",
(Status==SUCCESS)?"SUCCESS":"FAILED");
my_state=MPAK_SEND_CPLT;
break;
}
}

RET_CODE MyRcvFunction (int ind_type, REG_HNDL

hreg,
PKT_TYPE pkt_type, void *pbuf, LEN_TYPE
len)
{
RQST_ID Request;
MAN_TYPE SrcMan , CharToMan();
int mpak_len;
RET_CODE rc;
if (ind_type == MPAK_RECV_DATA_IND)
{
printf("MyRcvFunction: MPAK_RECV_DATA_IND len=%d
PKT_TYPE=%d\n",
len, pkt_type);
SrcMan = CharToMan ((char *) pbuf);
printf("source man =%ld\n", SrcMan);
printf("Packet:\n");
hexout(pbuf, len);
memcpy(mpakbuf, pbuf, len);
mpakbuf[0] = mpakbuf[3];
mpakbuf[1] = mpakbuf[4];

ManToChar((MAN_TYPE) SrcMan, &mpakbuf[3]);

mpak_len = len;
mpakbuf[MPAK_TYP_OFFSET] = MPAK_TYP_DATA;
mpakbuf[TRAFFIC_STATE_OFFSET] = 0;
printf("Sending %d bytes tp %ld\n",
mpak_len, SrcMan);
Mpak_SendData (hMachine, &Request,
mpakbuf, mpak_len);
}
else
printf("my_recvd_func: unknown ind
type:%d\n", ind_type);
return(ACCEPT_RELEASE_MPAK);
}

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 endto-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 preprogrammed 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
FEBRUARY 1996 EMBEDDED SYSTEMS PROGRAMMING 49

Wireless
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
ireless 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.

50 EMBEDDED SYSTEMS PROGRAMMING

FEBRUARY 1996