CubeSat Torrent: Torrent Like Distributed

Communications For CubeSat Satellite Clusters

Obulapathi N. Challa, Dr. Janise McNair
University of Florida, Gainesville, FL 32611
[email protected], [email protected]

AbstractCubeSat is a pico satellite weighing one kilogram,

measuring one liter in volume and is used primarily for space research. Low data rate communication limits the use of CubeSats
for missions like imaging and remote sensing. In this paper we
study how power, volume and geometry constraints of a CubeSat
satellite cripple CubeSat communications and introduce CubeSat
Torrent, a Torrent like distributed communication system, for
CubeSat clusters. CubeSat Torrent aims to increase the downlink
and uplink speeds of large les by distributing pieces of the les
to CubeSats in the cluster and downloading different pieces of
the les simultaneously from different CubeSats. The proposed
system proved, through simulation experiments, to substantially
improve the download and upload times of large les by a factor
of about the size of cluster. Future work will include Distributed
File System and Distributed Processing Framework for CubeSat
clusters to store large amounts of data and do large scale data
processing.
Index TermsCubeSat Communications, Distributed communication, Torrent, Satellite Communication Protocols.

I. I NTRODUCTION
A CubeSat is a miniaturized satellite primarily used for
university space research. A typical CubeSat has dimensions
of 10x10x10 cm3 , volume of exactly one litre, weighs no
more than one kilogram and is built using commercial offthe-shelf components. CubeSats are launched into low earth
orbits (LEO) using a common deployment system called PolyPicoSatellite Orbital Deployer (P-POD). P-PODs, mounted to
a launch vehicle, carry CubeSats into orbit and deploy them
once the proper signal is received from the launch vehicle.
Stringent weight, volume, power and geometry constraints
severely limit processing, storage and communication capabilities of individual CubeSats. Because of geometry and
weight constraints, CubeSats typically use monopole, dipole
and turnstile antennas. Owing to these constraints, a typical
CubeSat has about 25 MIPS @ 25 MHz processing capability,
128 KB RAM, 1 GB ash memory and data rate of 9.8 kbps.
Low speed data communication is one of the major bottlenecks
for CubeSat missions that require uplinking or downlinking
of large amount of data like images or videos. For emerging
missions like remote sensing, communication bottleneck poses
a bigger threat as the connectivity with ground station will be
very limited, intermittent and comes at a very high price.
We studied communication protocols that are being used
for CubeSats communication like AX.25 and CubeSat Space
Protocol (CSP). All these protocols are point-to-point and
does not support any form of distributed communications
for faster downloading of large data les like images or

978-1-4673-3/12/$31.00 2013 IEEE

videos. Currently there are no protocols for downloading

data from CubeSat clusters in a distributed fashion. So we
designed CubeSat Torremt based on Torrent communication
protocol to perform distributed communications to serve the
bandwidth needs for emerging CubeSat missions. This paper
proposes CubeSat Torrent(CST), using which communication
resources can be pooled among CubeSats in a cluster to
speedup missions that require downlinking or uplinking of
large amounts of data like images and videos. In this paper, we
present summary of CubeSat communications, advantages of
distributed satellite systems, architecture of CubeSat clusters
and design and simulation of CubeSat Torrent.
II. S URVEY OF C UBESAT COMMUNICATIONS
Communication subsystem is one of the crucial subsystems
of CubeSat. A CubeSat which cannot communicate is as good
as space junk. However, a survey of CubeSats launched so far
shows that not much progress has been achieved in this area.
Primary criterion in most cases for designing of communication system of the CubeSats has been, Being able to ping the
CubeSat, receive short control commands from ground station
and transfer very small amounts of data back to the ground
station intermittently[1][2]. For transmitting voice, images
or videos, in reasonable amount of time, current data speeds
are not sufcient. Below we present an overview of CubeSat
communication transceiver, communication protocols and a
brief summary of communication capabilities of cubesats so
far launched and data downloads achieved to give a perspective
of state of art CubeSat communications.
A. CubeSat Communication Subsystem
The three possibilities for selecting a CubeSat communications subsystem are:
Space rated commercial-off-the-shelf (COTS) transceiver,
Modied terrestrial COTS transceiver and
Custom built transceiver.
Below is a brief description of the above congurations and
the corresponding challenges.
1) Space rated COTS transceiver: Using space rated COTS
transceiver like MHX 2400 DP, Stensat, Libertad-1, AstroDev,
ISIS etc., simplies the design of the CubeSat. These modules
can be typically be interfaced using AT commands through
serial data and they can perform packetization, error checking,
and retransmission in case of failed transmissions. These
modules are very pricey and the protocols used by these

modules are proprietary and hence require radio equipment

by same vendor at the ground station end. Lack of standardization among the space rated COTS transceiver manufacturers
prevented deployment of large-scale CubeSat networks.
2) Modied terrestrial COTS transceiver: Some CubeSats
used COTS transceivers built for terrestrial use. These COTS
transceivers had several problems, the most serious being overheating due to lack of air to cool down the power ampliers.
Since they were not built specically for CubeSats in mind,
they need signicant number of hacks to make them t to
CubeSat in form and functionality. Hacks include changing
the frame timings, removing and adding components, drilling
mounting holes.
3) Custom built transceiver: Custom built transceiver modules allow students to exercise better control and full customization of the communication subsystem to suit needs of
that particular mission in terms of power, size, speed etc., Even
though success rate is less, these modules are necessary for
experimentation to test new protocols and hardware.
III. C UBE S AT C OMMUNICATION P ROTOCOLS
Majority of the CubeSats use AX.25 as their communication
protocol stack. Some CubeSats use custom protocols. Other
than AX.25, CubeSat Space Protocol (CSP) is the only other
protocol that made decent ground in CubeSat communications.
So far, there are no application layer protocols or standards
similar to ftp or http for CubeSats. This is another major hurdle
for building large scale CubeSat networks. Following is a brief
overview of the features and limitations of AX.25 and CSP.
A. AX.25
AX.25 for Amateur Radio Networks is the equivalent of
Ethernet and TCP/IP stack for computer networks. AX.25 is a
data link layer protocol derived from the X.25 protocol suite.
AX.25 occupies the rst, second, and sometimes the third
layers of the OSI networking model. Most often AX.25 is
used for point-to-point links between CubeSats and ground
stations, without any additional network layers. It is responsible for transferring data packets from source to destination and
detecting errors introduced by the communications channel[3].
Following are a few limitations of AX.25:
1) Lack of support for forward error correction (FEC).
2) Lack of support for automatic data compression.
3) Limited bandwidth links.
4) Hard limits like 6 character limit on call sign.
5) Lack of explicit port.
6) Overhead due to to headers.
B. CubeSat Space Protocol
CubeSat Space Protocol (CSP) is a network-layer delivery protocol designed for CubeSat Networks. 32-bit header
contains transport and network-layer information. It is implemented in GNU C and is targeted to run on 8 bit and 32 bit
microprocessor based embedded systems like FreeRTOS and
Linux[4]. Some interesting features of CSP include:
1) Simple API similar to Berkeley sockets.

2) Support for transparent forwarding of packets over

spacelink.
3) Support for both connection oriented and connectionless
operation.
4) ICMP like service supporting ping and buffer status.
5) Support for inter-process communication between subsystems through loopback interface.
6) Security features like data encryption using XTEA (eXtended TEA) in CTR mode and authentication using
HMAC-SHA1.
C. Summary of CubeSat data speeds and data downloads
Here is a table summarizing the data speeds and data
downloads of CubeSat communication systems.
TABLE I
C UBE S AT DATA SPEEDS AND DATA DOWNLOADS

CubeSat
Speed
Power
Modulation
Frequency
Total download

Min
CanX1
1200 bps
350 mW
AFSK
437.47 MHz
320 KB

Max
AeroCube2
38.4kbps
500 mW
GMSK
437.475 MHz
6.77 MB

Typical value
Various
9600 bps
500 mW
FSK
433, 900 MHz
05 - 5 MB

Typical characteristics of a CubeSat communication subsystem can be summarized as: data rate is 9600 baud, power
rating 500mW with an efciency of about 25% and a total
download of 12MB has been achieved so far using 13 satellites
for a period of 5 years. As one can see, communications is a
major bottlenecks for emerging CubeSat missions like remote
sensing, video, imaging etc., which require large amount
of data downlinking. In the following section, we explain
architecture of CubeSat clusters and present CubeSat Torrent,
using which we can download images and videos about 20 30 times faster.
IV. D ISTRIBUTED S ATELLITE S YSTEMS
There is shift of paradigm in space industry from monolithic
one-of-a-kind, large instrument spacecraft to small and cheap
spacecraft. Space industry is moving towards faster, cheaper,
better CubeSats which offer to accomplish more in less time,
with less money. As more and more CubeSats are launched, it
is becoming apparent that some space research needs are better
met by a group of small satellites, rather than by a single large
satellite. This is akin to the paradigm shift that happened in
the computer industry: shift of focus from large, expensive
mainframes to using smaller, cheaper, more adaptable sets of
distributed computers for solving challenging problems[5][6].
A. Some of the benets of distributed satellite systems are
1)
2)
3)
4)
5)
6)

Higher temporal and spatial resolution.

Higher availability.
Graceful degradation in case of failures.
Low cost and low manufacture time.
Gradual deployment instead of single deployment.
Low cost of launching.

B. Along with advantages, distributed satellites offer several

challenges which can be summarized as follows
1) Orbits at different altitudes.
2) Optimal control strategies for position and attitude of
the specic system components.
3) Activities of heterogeneous sensors.
4) Flow of information and storage in the system.
C. Categorization of distributed satellite systems
Distributed satellite systems can be categorized into three
classes: Constellation, Formation Flying and Swarm / Cluster.
Below is a brief description of these classes [5][6].
1) Constellation: Several satellites ying in similar orbits
are organized in time and space to coordinate ground coverage,
without on-board control of their relative positions is called a
Constellation. Each one of them are individually controlled
from ground control stations. Examples: Iridium, Teledesic
etc.,
2) Flying Formation: Multiple satellites with closed-loop
control on-board with a coordinated motion control based on
their relative positions to preserve the topology is called a
Flying Formation. Several spacecrafts perform the function of
a single, large, virtual instrument. Examples: TICS, F6 and
Orbital Express.
3) Swarm or Cluster: A distributed system of similar
spacecraft cooperating to achieve a joint goal without xed
absolute or relative positions is called a cluster. Each member
determines and controls relative positions to the other satellites.
Of these classes, CubeSat clusters offer a very promising
approach to solve several challenging problems.
V. C UBE S AT C LUSTERS
A CubeSat cluster is a distributed system of CubeSats
cooperating to achieve a joint goal without xed absolute
or relative positions. Typical CubeSat cluster radius is about
10 km and can contains about 20 to 50 CubeSats. CubeSat
cluster consists of a single master and multiple slave nodes.
Slaves are typical 1U CubeSats (10x10x10 cm3 ) whereas
master is a 2U (2 CubeSats joined together) or 3U (3 CubeSats
joined together) CubeSat with better processing, sensing ,
storage and communication capabilities.
A. Inter cluster communication, synchronization, and relative
position and orientation:
CubeSats are connected to each other through a high speed,
low power backbone network. High gain directed antennas
like patch are used for inter cluster communication. RelNav
demonstrated a spacecraft subsystem that will enable a ock
of satellites to operate as a coordinated cluster with ability
for coherent sensing[7][8]. Such subsystems provide following
services for coordinated space ight:
1) 10 Mbps inter-satellite communication link for data
exchange between CubeSats
2) Relative position and orientation for formation ight
3) Cluster synchronization and timing for coordinated operations and coherent measurements

B. CubeSat to earth communication:

CubeSat geometry prohibits use of complex antennas. As
a result, CubeSats are connected to ground stations through
simple antennas like monopole or dipole. Coupled with tight
power constraints and distances of order 600 - 800 KM, this
resulted in low speed links to connect to ground station.
Typical CubeSat to ground station speed is about 9.8 kbps.
C. Architecture of a CubeSat cluster
The four modules of CubeSat cluster are:
1) Master node,
2) Slave nodes,
3) Ground stations and,
4) Central server.

Fig. 1.

CubeSat Cluster

The four modules of CubeSat cluster and the connections

between them are depicted in Fig. 1. Here is a brief explanation
of the CubeSat cluster architecture presented in Fig. 1. Master
node will be situated approximately at the center of the
CubeSat cluster. Surrounding the master node are the slave
nodes which typically are standard 1U CubeSats. Master
has better sensing, processing and communication capabilities
than slaves. CubeSats are connected to each other through
reliable, directional, low power and high speed links which are
indicated by using solid lines. Connections between CubeSats
and ground stations, depicted using dashed lines are high
power, low speed, unreliable links. Each CubeSat is connected
to a ground station and all ground stations are connected to
a central server that issues commands and plays the role of
data repository for the system. For backup, there will be two
or three shadow masters, which takeover the role of master in
case the current master fails.
VI. C UBE S AT T ORRENT
A. Master and slave nodes
The master node plays the role of tracker for CubeSat cluster. It maintains the list of CubeSats that are participating in the
system. Since it is equipped with better sensing, processing,
and communication hardware, it is the default source for the
data like images or videos. It is the coordinator for the cluster
and primary node to receive mission commands from ground

stations. It stores all the metadata associated with mission.

Metadata consists of ids of all the CubeSats in the cluster,
chunk ids, state of chunk (downloaded, in progress, yet to
be downloaded), etc., All this data is logged and frequently
backed up to non-volatile ash memory. Primary role of slaves
is to downlink the chunks assigned to them by master.
B. Ground stations
Ground station or amateur radio station is an installation that
enables communication with CubeSat satellite. It contains high
gain directional antennas like yagis or parabolic dish antennas,
communication equipment like modems and computers to
send, capture and analyse the data received. There are several
types of amateur radio stations including xed ground stations,
mobile stations, space stations, and temporary eld stations.
Most of the radio stations are established to provide an
educational and recreational purposes for providing technical
expertise, skills and volunteer manning to promote attendance
by the public, communications education for the public. Role
of a ground station is to downlink chunks from slave nodes
and forward them to the central server.
C. Central server
Central server issues commands to master CubeSat through
ground stations and stores all the downlinked data from cluster.
Once all the chunks are downloaded to the central server, it
stitches them back into original le.
D. Downlinking and uplinking a le
Master node plays the role of tracker. It keeps track of all
the slave nodes in the cluster and their available downlink and
uplink capacity. When a ground station sends a le downlink
request to master, master will split the le into large number of
xed size blocks called chunks. Master gives each slave node
a different chuck. Slave nodes downlink the chunk given to
them by connecting to the best possible ground stations. Upon
successful completion of task, slave noties master and master
assigns the slave a new chunk to downlink. While this process
is going on, the master downlinks the metadata containing the
chunk identiers, 32 bit CRC of chunk and the slave node
identiers that are assigned to downlink them. As soon as a
chunk is downloaded to a ground station, it is forwarded to
the central server. Central server stitches all the chunks into
original le. A le is uplinked to a Cubesat cluster in a similar
fashion.
VII. FAULT TOLERANCE , FAILURES , GRANULARITY LOAD
BALANCING AND TAIL EFFECT

A. Fault tolerance
CubeSat Torrent is designed to be tolerant to temporary
and permanent CubeSat failures and its performance degrades
gracefully with machine or link failures. Failures are the
norm rather than an exception. A cluster can contain up to
hundred nodes and is connected, with roughly about same
number of ground stations, through long distance wireless
links. The quantity and quality of the links virtually guarantee

that some links break intermittently and are not functional at

any given time and some will not recover from their failures.
Problems can be caused by application bugs, operating system
bugs, failures of memory, connectors and networking. Such
failures can result in an unavailable system or can lead to data
corruption. Therefore, constant monitoring, error detection,
fault tolerance, and automatic recovery must be a part of the
system. We discuss how we meet these challenges and how
we have built the system to diagnose problems when they
inevitably occur.
B. Master failure
Master writes periodic checkpoints of all the master data
structures. If the master task dies, a new copy will be started
from the last checkpointed state. Master node represents the
single point of failure for the CubeSat Torrent. However,
given that there is only a single master, its failure is unlikely;
therefore our current implementation aborts the the mission if
the master fails. If a master cannot recover from error, shadow
master takes over the cluster. In case of failure of master, slaves
will ping the master periodically until a new master assumes
the leader role for Cluster.
C. Slave failure
The master pings every slave periodically. If there is no
response from a slave within a certain amount of time, master
marks the slave as failed. Downlink task assigned to the
slave is reset back to its initial idle state, and therefore
become eligible for downlinking on other slave. If a slave
loses connection with ground station, it retries with same or
different ground station. If it cannot connect to any ground
station within a certain amount of time, it signals failure to
master. Master marks the slave as a temporary failed node and
reschedules the downlinking job assigned to the failed slave
to another slave. CubeSat Torrent is resilient to slave failures.
D. Task granularity
Master divides the le to be downloaded into C chunks.
Ideally, C should be much larger than the number of slave
machines. Having each slave perform many different tasks
improves dynamic load balancing, and also speeds up recovery
when a slave fails. However, as C increases, so does the
amount of metadata that needs to be stored and downlinked
by master. Metadata costs approximately one byte of data per
chunk. In practice, we can choose C so that each chunk is
about 16kB.
E. Tail effect and backup downloads
Some nodes takes unusually long time to downlink / uplink
a chunk. These nodes are called stragglers. There can be
several reasons for this like a bad antenna, cache failures,
scheduling of intensive background tasks, very low speed link,
etc., To mitigate the risk of slowdown of downlinking or
uplinking of a le by stragglers, CubeSat Torrent uses backup
downloads. When a le downlink or uplink operation is close
to completion, the master schedules backup downlinking tasks

for the remaining in-progress chunks. The chunk is marked as

downlinked whenever either the primary or the backup slave
nishes downlinking. Backup downloads take about 5% more
bandwidth resources and speed up the total downlinking time
by roughly about 30%.
VIII. S IMULATIONS
For simulating CubeSat Torrent, we developed CubeSat
Network (CubeNet) framework using Python programming
language. We simulated CubeSat Torrent on a CubeSat cluster
consisting of one master, two shadow masters, 5 - 25 slaves
and 5 - 25 ground stations. Each CubeSat has processing
power of 25 MIPS @ 25 MHz, storage of 1 Gb and ground
communication data speed 9.8 kbps. CubeSats in cluster are
connected to each other through 10 Mbps high speed intercluster communication links.
We simulated master CubeSat downlinking large les to
central server through slave nodes. Master splits the le into
chunks of size 16 kb each and distributes them to slaves. Slaves
simultaneously downlink the le to ground stations. Ground
stations forward the chunks to central server. Central server
stiches the chunks into original le. We varied the CubeSat
cluster size to study how the downlinking speed varies. We
measured several measurements which are explained in detail
below.
A. Cluster size vs downlinking speed
Table II shows the variation of downlink speed and speed up
with variation of cluster size. For small clusters (cluster sizes
< 5) the overhead is large and the efciency is about 75%.
For cluster sizes of order 25, efciency is about 90%. And it
is evident that CubeSat Torrent speeds up le downlinking by
a factor of 20 for cluster sizes of 25. The resulting savings
in time are described below in Table III. Note that with
symmetric links, downlinking and uplinking speeds are same
and so, uplinking results are not shown.
TABLE II
C LUSTER SIZE VS DOWNLINKING SPEED
Cluster Size
5
10
15
20
25

Speed limit
48 kbps
96 kbps
144 kbps
192 kbps
240 kbps

Observed speed
36 kbps
81 kbps
124 kbps
166 kbps
208 kbps

Speed up
3.75
8.39
12.91
17.29
21.67

B. File size vs downlink time

Table III shows savings in time for a CubeSat cluster of
size 25, as a result of the speed up, for downlinking large
les. Using CubeSat Torrent, a le of size 100 Mb can be
downlinked in about 10 mins compared to 2 hr and 45 mins
while using a single CubeSat. For gigabyte sized les, the
time saving will be in order of days. These results imply that
imaging and remote sensing missions can be performed in
real time and missions that require videos can be performed
with a latency of few hours. This is a signicant improvement

compared to hours of latency for imaging missions and days of

latency for video missions while using an individual CubeSats.
TABLE III
F ILE SIZE VS DOWNLINK TIME
File Size
100 Mb
200 Mb
500 Mb
1 Gb
2 Gb
5 Gb

Lower limit
8 min
16 min
40 min
1 hr 20 min
2 hr 40 min
6 hr 40 min

Downlink time
9 min 36 sec
18 min 34 secs
45 min 12 secs
1 hr 28 min
2 hr 52 min
7 hr 4 min

Time saved
2 hr 44 min
5 hr 28 min
13 hr 42 min
1 day, 3.5 hrs
2 days, 7 hrs
5 days, 17.5 hrs

If downloading of all chunks gets completed by same time

and inter-cluster communication delay is almost negligible,
then system will be 100 % efcient. But different completion
times for downloading chunks, failed downlinks due to link
breaks and inter-cluster communication limit the efciency of
system to about 90% of theoretical limit.
C. Metadata
Metadata consists of ids of all the CubeSats in the cluster,
chunk ids and their states, etc., Metadata overhead had a
xed component and a variable component. Fixed overhead
involves the information about cluster like master and slave
ids and route information. Variable information includes chunk
ids, CubeSats assigned to downlink them, and their states
(downloaded, downloading, yet to be downloaded). Results
agree with our theory that there is a xed overhead for
maintaining the cluster information and variable overhead,
which includes information about chunks, increases linearly
with the le size (number of chunks). Following table depicts
the variation of metadata with variation in le size for a cluster
size of 25.
TABLE IV
F ILE S IZE VS M ETADATA
File Size
100 Mb
200 Mb
500 Mb
1 Gb
2 Gb
5 Gb

Metadata
7.5 kb
14.5 kb
35.31 kb
68.75 kb
135 kb
330 kb

IX. C ONCLUSION
CubeSat Torrent demonstrates the essential qualities for supporting large-scale data downloads and uploads for CubeSat
clusters. It treats link and system failures as common rather
than expectation and is optimized for downlinking and uplinking huge les. Our system provides fault tolerance by constant
monitoring, replicating crucial data structures, and fast and
automatic recovery. Additionally, we use checksumming to
detect data corruption for each chunk.
Proposed design delivers high aggregate throughput which
is required for variety of missions. We achieve this by separating metadata, which is communicated by the master, and data,

which passes directly from slaves to ground stations. Single

master simplies design and with backup masters this design
is fault tolerant.
We simulated CubeSat Torrent using CubeNet, a Python
CubeSat network simulator. Our simulation results indicate
that Cubesat Torrent, with cluster sizes in range of 5 - 25
CubeSats, enables 4 - 22 times faster (compared to a single
CubeSat) downloading of images and videos. All this speed
is achieved by consuming only about 30% more power for
inter-cluster communication and almost negligible memory
overhead (< 0.01%) to store metadata. It can speed up
CubeSat missions like imaging and remote sensing by factor
of 20x and make them near realtime.
X. F UTURE W ORK
Future work will include work on Laser Communication
Subsystem for low power, high speed inter-cluster communication to improve power efciency and increase the scalability
of CubeSat Torrent. We are also working on a Distributed File
System and a Distributed Processing Framework for CubeSat
clusters for storing large amounts of data and doing large scale
data processing.
XI. ACKNOWLEDGEMENTS
This work was supported by the NSF Division of Electrical,
Communications and Cyber Systems (ECCS), Integrative, Hybrid and Complex Systems (IHCS) Program, Grant #0901706.

XII. R EFERENCES
[1] K. L. Bryan Klofas, Jason Anderson, A survey of
cubesat communication systems, in CubeSat Developers Conference, November 2008.
[2] Paul Muri, Obulapathi N.Challa, Dr. Janise McNair,
Enhancing Small Satellite Communication Through
Effective Antenna System Design, in Military Communications Conference, 2010. MILCOM 2010.
[3] AX.25
Version
2.2
Available
at
http://www.tapr.org/pub ax25.html.
[4] CubeSat
Space
Protocol
Available
at
http://code.google.com/p/cubesat-space-protocol/
[5] F. Ankersen (ed.) (2008), Proceedings 3rd International
Symposium on Formation Flying, Missions and Technologies, ESA SP-654, Noordwijk.
[6] Schilling, K.; , Earth observation by distributed networks of small satellites, Instrumentation, Communications, Information Technology, and Biomedical Engineering (ICICI-BME), 2009 International Conference on
, vol., no., pp.1-3, 23-25 Nov. 2009.
[7] RelNav: Relative Navigation, Timing & Data Communications for CubeSat Clusters. Available at
http://www.tethers.com/SpecSheets/RelNavSheet.pdf.
[8] R. Scrofano, P.R. Anderson, J.P. Seidel,J.D. Train, G.H.
Wang, L.R. Abramowitz, J.A. Bannister, D. Borgeson,
Space-based local area network, Military Communications Conference, 2009. MILCOM 2009. IEEE , vol.,
no., pp.1-7, 18-21 Oct. 2009.