ISPC03_Graphical_modeling

Getting graphical in wireless 3G designs
Michael Woodward
RadioScape Inc
15849 North 71
st
Street
Scottsdale, AZ, USA
+1 480 281 1827
mike.woodward@radioscape.com
ABSTRACT
Wireless system projects are becoming increasingly difficult to
deliver. Complexity is increasing on two fronts, through the
complexity of the underlying standards and the market
requirements for devices to do more (e.g. to be multi-mode). This
complexity is adding greatly to both time to market and project
risk. Computer simulation of communications systems is
becoming increasingly prevalent to help de-risk these projects.
This paper will argue that ‘traditional’ object-oriented software
development techniques are not, by themselves, suitable for the
development of wireless system models. We will discuss a
different approach to simulation, which we term graphical
modeling, that offers substantial benefits to developers involved
in creating wireless system models.
Categories and Subject Descriptors
D.2.2 [Design tools and techniques]: Computer Aided Software
Engineering (CASE)
General Terms
Algorithms, Design, Economics.
Keywords
Graphical modeling, wireless system design.
1. INTRODUCTION
Since the early uses of computer modeling 1950’s [1] it has
become increasingly widespread in many industries [2]. The first
uses of modeling were driven by the needs of the scientific
community who were interested in investigating the properties of
systems they couldn’t directly or conveniently investigate in any
other way. Commercial interest in simulation technology started
in the 1960’s [2] when companies realized it offered them a way
of modeling the properties of products or prospective products so
reducing the need for expenditure on physical testing and
development.
A typical commercial use of simulation technology is found in the
vehicle industry. Many different types of simulation are
performed here, but we will briefly discuss one usage: crash
testing [see for example 3]. Crash testing is an important and
legally required part of the development of vehicles, but it is also
very expensive. It is well known that re-engineering of any project
late in the design stage greatly increases costs, and physically
crash testing vehicles must, by definition, take place late in the
development process. In this case, the attraction of computer
modeling is the ability to simulate vehicle crashes while the
vehicle is still on the drawing board, to enable the vehicle to pass
the real crash tests in fewer attempts. To put the point plainly,
simulation enables vehicle designers to answer the question “will
it work?” much more cheaply.
2. MODELING WIRELESS SYSTEMS
Wireless development projects have become increasingly
sophisticated as the complexity of the underlying standards has
increased. Unfortunately, at the same time market requirements
have also increased the need for handsets to do more, e.g. to be
multi-mode. In the wireless world, the crash test equivalent is the
product prototype, but given the highly competitive nature of the
market, time to market is crucial. The increased complexity not
only affects time to market, but increases project risk as well. Just
as in the vehicle industry there is a need to answer the question,
“will it work?” as early as possible.
Computer simulation offers an answer to the “will it work?”
question, but also offers the prospect of quickly and cheaply
examining different design choices. Simulation can therefore help
both reduce project risk and time to market.
Given the importance of simulation, it’s important that models are
implemented in the most advantageous way. We will look briefly
at the traditional way of model development and describe a more
sophisticated form of modeling that offers many benefits
3. MODELING IN COMPUTER
LANGUAGES
The most obvious choice for many wireless engineers faced with
the task of developing models for communications systems is to
turn to languages such as C, C++, or even FORTRAN. Here the
development of a software model is seen as just another software
project and will probably proceed in the same fashion. We will
look briefly at how such a model might be developed using
‘ordinary’ software development technologies and we shall show
why these software development techniques may lead to inflexible
models.
Modern object oriented development typically follows an iterative
and incremental development process [see for example 4]. The
idea here is to produce an orderly development that reduces
project risk. However, even with these recent advances, the
emphasis is still on design upfront, for example with Rational’s
process, something like 80% of the design work is expected to
occur in the early stages of development [4]. By contrast
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee.
International Signal Processing Conference ’03, March 31-April
3, 2003, Dallas, Texas.
Copyright 2003 RadioScape 1-00000-000-0/00/0000…$5.00.

communications systems models need to evolve as different
architectures are investigated, for example we may wish to
simulate different receiver architectures under different channel
conditions.
Design problems occur in communications simulations because
developers often do not make the crucial distinction between the
design of the simulation infrastructure and the design of the
system to be simulated. The simulation infrastructure design
covers items such as system control, data output (graphs), timing,
data passing etc. The design of the system to be simulated covers
things like the channel coding, spreading, scrambling, and rake
receivers etc. By failing to separate these two tasks, developers
can create models that are inflexible. As traditional software
development has an emphasis on up-front design, this can lead to
early design decisions causing problems later in model usage. An
example may make the point.
A developer (under time pressure) has been asked to create a
system that models a simple 3G transmitter-receiver architecture.
The system is for a single user and is to include spreading and
scrambling and an AWGN channel. A typical UML design for
such a system is shown below.
Figure 1. A UML diagram for a simple communication system
model.
The next iteration in the design cycle calls for the developer to
add more users, different spreading and scrambling setting for
some of the users, and an option to add a multipath channel in
addition to, or instead of, the AWGN channel. Naively it might be
hoped that these changes would simply be additive, but the reality
is that even in well-designed systems, new requirements such as
these will cause changes to take place in the simulation
infrastructure, for example the GUI and data display functions
may have to be completely re-designed. So the addition of extra
functionality causes an impact throughout the entire system, even
in a reasonably well-designed one, increasing development time
and cost.
There is a worse problem hiding here for developers working
under time and cost pressure. Creating models involves a lot of
non-simulation work. In our example above, a simple 3G model
was required, but the model developers had to spend time
developing GUIs, graphs and model infrastructure. None of these
things are core to the aims of delivering the model, but have to be
developed, debugged and maintained.
One solution might be for developers to design the model
infrastructure and buy in components for graphing and GUIs etc.
But it would be better still if they could buy the model
infrastructure, graphics and GUIs all in the same package, leaving
them free to focus on the development of the simulation
algorithms. This is where graphical modeling comes in.
4. GRAPHICAL MODELING
The best way to describe graphical modeling is to proceed by way
of an example. Figure 2 shows a simple graphical model of the
same system from Figure 1 implemented in the graphical
modeling tool Simulink from The Mathworks [5]. A crucial
difference here from UML is that these Simulink blocks represent
executable code rather than a design abstraction, so ‘under’ the
scrambling block is scrambling code etc. Figure 2 is the model
and is ‘run’ as shown, we are in effect producing an executable
design.
Figure 2. A simple communication system model in Simulink.
The blocks are connected via lines that represent the transfer of
data, and at run time, the graphical modeling system uses this
connection information to route data between blocks. Once model
execution is started, data is fed to blocks by the model
infrastructure. The blocks take this data input, perform their
operation (e.g. spreading) and output their data back to the tool
infrastructure.
Crucially, graphically modeling makes a clear distinction between
tool infrastructure and model system implementation. The tool
infrastructure is the responsibility of the tool vendor, whereas the
system (or block) implementation is the responsibility of the user.
Once the user adopts the tool API, the tool will manage all of the
infrastructure issues, leaving the user free to concentrate on model
development.
Because each of the blocks are de-coupled from one another and
they all follow the tool vendor API, significant changes to the
model design can be implemented without the need for a re-
compile. For example, in the above system, the user could swap
the order of the spreading and scrambling block without re-
compiling, in fact without leaving the graphical modeling
environment. If the model of Figure 2 is to be extended to include
multiple users and multipath effects as before, the changes are

only the addition of the new blocks, the tool infrastructure means
that we do not have to make any changes to our existing blocks
(i.e. the spreader, scrambler and AWGN blocks remain the same).
Because the connections between blocks are highly visible in the
model (and not in a design that may well be out of date), extra
graphs etc. can be added almost trivially. This represents a
significant increase in productivity.
The common API creates an opportunity for another cost and time
saving with the use of 3rd
party blocks to perform some of the
tasks that model developers might otherwise have to spend time
developing. Good examples here are graphics blocks. Typically
graphical modeling tools come with a number of data display
blocks that the user can simply plug into their models and use,
again without a compilation. 3rd
party blocks are available for
many graphical modeling environments, with Simulink having a
particularly large number of such blocks, e.g. a communications
blockset, a DSP blockset, and an extensive 3G blockset [6] all
readily available. In the extreme, users may just use pre-existing
blocks for all their modeling needs, therefore greatly shrinking
model development time. Block developers can spread the block
development cost over several customers, and a wider user
community should result in more reliable blocks. Customers can
therefore purchase blocks much more cheaply than developing
them, with the knowledge that the purchased blocks are likely to
have been through much more rigorous testing than internal
developments are ever likely to be.
Because blocks are a visual representation of underling code, it is
a relatively trivial matter to create block libraries for model
development. As an example we might conceive a CDMA 2000
library that included channel coding, spreading, and channel
model blocks. Modeling a CDMA 2000 system would then
consist of the selection of the appropriate blocks from a library,
adding in some graphical display blocks from a 3rd
party library,
and wiring them together. Individual models can be saved
separately, so enabling a whole range of possible architectures to
be investigated quickly.
5. GRAPHICAL MODELING PROBLEMS
As with any new approach in computing, there are costs in
changing to graphical modeling, however some of these costs are
more myth than reality.
The first hurdle to be overcome is learning the API. Learning
graphical modeling APIs is no different from learning APIs for
operating systems or other software packages. There is a certain
amount of difficulty and time investment that must be made
before the technology can be successfully used. However it is our
experience that the costs of learning the API can be recouped over
the lifetime of the very first models to be developed. An
intelligent approach to block design suggests that the graphical
modeling code be separated from the block algorithm code, e.g.
an implementation of a turbo decoder block should decouple the
turbo decoder code from the graphical modeling API code. This
means that, in principle at least, the turbo decoder code could be
used elsewhere for other purposes.
The speed of graphical models is often held up as a reason why
models built in C or C++ are superior. To some extent this is a
valid argument. The graphical modeling environment does add an
overheard, albeit a small one. There is a finite cost in allowing the
environment to pass data between blocks. More serious graphical
modeling slow downs occur when interpreted languages are used
to write blocks. One tool in particular has an extremely powerful
interpreted language built-in. Developers can use this language to
develop their own blocks and make use of all the built-in
mathematical functions. However interpreted languages are
always slower to execute than compiled code. A fairer comparison
to make is between visual modeling blocks written in C or C++
and models written wholly in C or C++ (for example). In these
cases, graphical modeling is not significantly slower.
Perhaps the most serious hurdle to overcome is a conceptual one.
Graphical modeling requires a significant shift in thinking, and
also involves a reliance on 3rd
party code. This cultural shift in
thinking will inevitably take time, but may accelerate as more
communications engineers are exposed to graphical modeling
tools at university and during training courses. Reliance on 3rd
party blocks can be a leap of faith for some development
organizations used to developing everything themselves, but once
the leap is made, the cost saving involved may ensure there is no
return to developing everything in house.
6. CONCLUSION
This paper has briefly reviewed the use of computer simulation in
industries outside of communications and we have discussed why
simulation is useful for wireless designer. We have shown why
traditional software development techniques may not be
appropriate for model development and shown how graphical
modeling offers a better way forward.
7. REFERENCES
[1] Turing A.M., The Chemical Basis of Morphogenesis,
Philosophical Transactions of the Royal Society B
(London), 237, 37-72, 1952
[2] Kreutzer W., System simulation: Programming styles
and languages, Addison-Wesley, Sydney, 1986
[3] McHenry R.R., Segal D.J., Delays, N.J, Computer
Simulation of Single Vehicle Accidents, Society of
Automotive Engineers Transactions, 1968
[4] See the articles on the Rational Unified Process on
www.rational.com
[5] www.mathworks.com
[6] www.radiolab3g.com

ISPC03_Graphical_modeling

More Related Content

What's hot (15)

Viewers also liked (14)

Similar to ISPC03_Graphical_modeling (20)

ISPC03_Graphical_modeling