Condroid KTH Summer CSD 2011 - Final Report

!

!"#$%&'()*'+&
,('-"*#&./0&

2011
!"#$%&'()%*+(,%+-%"( !"#$%&'(&#*&.(
& (
&
Lan Sun (lansun@kth.se), 15 ECTS (((((/#*&.(*01(2"#$%&'(#30%"(
Hervé Ntareme
Qing An (qinga@kth.se), 15 ECTS
/#4&#*&.(
Michel Hognerud
Jun Gao (jungao@kth.se), 15 ECTS
/.*+25#0(
Laili Aidi (aidi@kth.se), 18 ECTS
Björn Pehrson!
Yasir Ali (yasireal@kth.se), 15 ECTS

SUMMER CSD

Condroid Final Report V1.0
!

Revision History

Version Date Responsible Change
V1.0 2011-10-12 Laili Aidi Initial version of the document

2

!

Contents

Contents.....................................................................................................................................................3
Summary....................................................................................................................................................5
Acknowledgment.......................................................................................................................................6
1. Introduction and Background ...............................................................................................................7
1.1. Introduction ................................................................................................................................................................ 7
1.2. Background ................................................................................................................................................................. 7
2. Project Goals..........................................................................................................................................9
2.1. Technical Goals.......................................................................................................................................................... 9
2.2. Business Goals............................................................................................................................................................ 9
3. Methodology........................................................................................................................................ 10
3.1. Project Management................................................................................................................................................10
3.2. Software Development ...........................................................................................................................................13
3.3. Human Resources ....................................................................................................................................................17
3.4. Hardware Resources ................................................................................................................................................19
4.3 Space Resources ........................................................................................................................................................20
4. System Architecture & Design ............................................................................................................ 21
4.1. Remote Management...............................................................................................................................................21
4.2. WSN/DTN Gateway ..............................................................................................................................................22
5. Project Deliverables ............................................................................................................................. 24
5.1. General Deliverables ...............................................................................................................................................24
5.2. Technical Deliverables ............................................................................................................................................27
5.3. Business Deliverables ..............................................................................................................................................31
6. Unique Contributions.......................................................................................................................... 32
6.2. WSN/DTN Gateway ..............................................................................................................................................32
6.3. Business Analysis .....................................................................................................................................................33
7. Future Works ....................................................................................................................................... 34
7.2. WSN/DTN Gateway ..............................................................................................................................................35

3

!

8. Conclusion ........................................................................................................................................... 37
9. Reference ............................................................................................................................................. 38

4

!

Summary

This document contains the final report of Condroid Summer CSD 2011 project.

5

!

Acknowledgment

Our first experience in CSD project at Telecommunication System Laboratory (KTH/ICT/TSLab) has been
successful. We want to thank to the support of the management, consulting experts, staffs, Summer CSD
teaching team, coach and co-coaches for their support and cooperation, and wish to acknowledge all of them.
Here, we wish to make special mentions of the following:

First, we are thankful to our project Champion, Professor Björn Perhson, who provided us the opportunity to
experience the industrial and real life challenge in academic multi flavor environments. He expressed his trust
and gave chance to explore our hidden capabilities, while continuously provided his guidelines and advices. We
are wholeheartedly thankful to him for giving us his valuable time, attention and systematic way to complete all
of our objectives.

We must make special mention to our co-coaches and consultants: Mr. Michel Hognerud; Ms. My Andenberg,
as without her consistent supervision, especially for the project management, it would be impossible for us to
achieve our entire objectives; Mr. Robert Olsson and Mr. Bernt Sundström, for their guidance in the technical
hardware issues faced during the project; Mr. Bruce Zamaere and Mr. Pehr Soderman, for their kindness in
helping us out from unpredictable technical storm; Mr. Voravit Tanyingnyong, for providing access to the
equipments that made us could keep continue our research.

Moreover, we would like to acknowledge the efforts made by developers and researchers in Android, IOIO,
Voyage OS, DTNRG, DTN2, SunSPOT, Bytewalla 1, Bytewalla 2, Bytewalla 3, and Bytewalla 4 team, who
have designed such a great protocol, platform and application which enable us to did our work.

The last, we express our gratitude to our main coach Mr. Hervé Ntareme, who provided us with a strong
foundation, continuously assisted in various problems encountered during the project, helped us in keeping our
moral high, and open the opportunity to present the results of this project.

6

!

1. Introduction and Background
1.1. Introduction
The ConDroid CSD project aim to develop Remote Management software for android cell phone, which
make it enable to communicate with the network equipments that situated far away in the isolated area. This
research software would make it possible to configure and monitor the network equipments (exp. Optical
amplifier and or WiFi repeater) through some possible available connections (short message, dialing, and or
Internet). This project also intend to implement a flexible WTN/DTN Gateway, which makes it able to collect
data from the isolated WSN motes, stores them in a database and make them available via DTN or other
possible available connections.

1.2. Background
The network might contain several equipments that situated far away from the city and/or isolated and
make it difficult to be reached. At the mean time, there is requirement to be able to access, gather the necessary
data, configure and monitor these devices in order to assure that the network run properly. Somali Research
and Education Network (SomaliREN) is a non-profit and non-governmental academic network for Somali
Higher Education Institutions [1]. There is intra-city network in Hargeisa city, which connects Gollis
University, Hargeisa University and SomaliREN NOC, and inter-city network, which is a long distance
connection of about 100km between the SomaliREN NOC and Amood University in Borama city. This
network might use WiFi repeater(s) and/or Optical amplifier(s) in the middle of the connection, which is
difficult to be reached regularly by the administrator or technician.
Moreover, there is also requirement to connect the Wireless Sensor Network (WSN) Gateway to the
Internet using Delay Tolerant Networking Technology (DTN) solution [2]. The DTN, as an approach to
computer network architecture, aim to solve the technical issues in heterogeneous networks that may lack
continuous Internet network connectivity. The WSN consists of spatially distributed autonomous sensor
motes, which is deployed to monitor physical or environmental conditions. The WSN motes connected to the
WSN Gateway, which governs network aspects, collects the information received from nodes, and provides an
interface between the sensor network and the external network infrastructure.
A common challenge of requirements mentioned above is to connecting these network equipments (Wi-Fi
Repeater and or Optical amplifier) and network infrastructure (WSN Gateway) to the outside world, especially
in environments lacking continuous Internet network connectivity or placed in extreme terrestrial area. In this
project, we explored the possibility to use any available links in order to provide a flexible Remote Management

7

!

feature for the isolated network equipment. On the other hand, the Condroid team also reseached a design of
WSN/DTN Gateway [4], and then implement it to the isolated WSN infrastructure and make the data able to
be accessed trough Bytewalla, the DTN approach implementation on Android smart phone [5, 6, 7, 8].

8

!

2. Project Goals
2.1. Technical Goals
The main goal of Condroid project is to analyze, design, implement, and test the working system of [9]:
1. The Remote Management application in android platform, to support and troubleshoot the network
equipments (exp. WiFi Repeater and Optical amplifier).
2. The WSN/DTN Gateway, an embedded system, interfacing the WSN to the world using DTN approach

2.2. Business Goals
Beside the main goal mentioned above, we also provide a comprehensive Business analysis of Remote
Management. This application would be an exiting new business idea with huge potential market. Therefore,
even tough with minimal human resource, we tried to make first step in taking this application into the market
in order to move the idea from the research in laboratory to the real people life, which consist [10, 11]:
• SWOT (Analysis and Strategy)
• Business Model (Product, Customer Interface, Infrastructure Management, Financial Aspect)
• Business Plan (Business Idea, Marketing Strategy, Financial, Risk Management)

No business can run without a plan, and a good plan cannot run without establishing goal setting, and
the goals only can be set if we know the boundaries within the area. Therefore, in this preliminary research, we
decided to focus to understand these aspects and define necessary strategy to tackle it. Thus, we can say the
Business analysis that we have done above, basic structural approach in implementing the Remote management
application into the target market.

9

!

3. Methodology
3.1. Project Management
The purposes of project management are to planning, organizing, and managing the available resources
to achieve the successful completion of specific project goals and objectives. Since they are complicated, we
were not completely sure in advance what exactly tasks we have to handle and which kinds of problems we
confront in the development process. In this condition, we need a dynamic working environtment model,
therefore, the project management model that we used in our project was the Scrum Agile model [12], both
implemented in software development and Business analysis process, which is as shown in the diagram below

Figure 1. ConDroid Project Management Methodology [9]

In the Scrum Agile model, there are 3 core roles available [12]:
• Product owner.
The Project manager is responsible as product owner within the team that gather the problems, which is
defined in Burn-down list, and then decide the priority of it that should be confronted within each sprint
period and add them to the product backlog.
• Scrum master.
The Scrum master plays the role as facilitator, who helps to remove the impediments to the ability of the team
to deliver goals. In our project, the Scrum master also in charge to keep monitoring that the scrum
methodology tools (Scum Back-Log) is consistently used and implemented by every team member.
• Team member
The Team is the main part in this methodology, which responsible for delivering the product, within specific
sprint period.

10

!

A product backlog, which is a high-level list that is maintained throughout the entire project, is made
and because it is open and can be edited by anyone, we can add new problems into the product backlog when
necessary. Then according to the product backlog, we make sprint backlog for every sprint period. As our
project consist of master students that works with half work-hour (15 – 18 ECTS), thus our Sprint period was
typically consist of 5 days a week and 4 hours per day. The Sprint methodology was done with “hard-core”
implementation, in order to manage to associate with internal and external factors, where both of them were
important to reach achieve the results, as defined below:
1. External coordination
The external coordination was done in order to touch with champion and coaches who required to be
informed about the project progress and constantly gave help and support via below several activities:
• Progress Report meeting
Progress report meeting was done every Monday, starting from 14.30, where all the team project manager
discuss and report to the champion and the coaches about the working processes, results and challenges
of the past week. This meeting played an important role in keeping the work up to date, as it gave us a
chance to communicate and collect advice directly from champion and the coaches.

• Weekly Report
Meanwhile, we also submitted weekly progress report in every week during the project, which be
referenced during the Progress Report meeting. This weekly progress reports were used to make
champion, coaches and others aware with progress of the team and also contain the time sheet of the
individual team member.

• Time sheet
Each team member was committed to keep writing the time sheet in every working day in Condroid
project. These time sheets then were verified, compiled and attached by Project Manager in the Weekly
Report.

2. Internal coordination
The Internal coordination within the team was done using mailing list (csd-android-app-
group@googlegroups.com), messenger, and any other accessible approaches, so the team member can keep
communicate and update each other about the progress of the project. Apart from that, this coordination also
consist of 3 internal meetings in every Sprint period, that were done consistently during the project period in

11

!

highly efficient way (typically 15-20 minutes), as described below [12]:
• Sprint Planning meeting
This meeting was done at the beginning of each sprint period, typically every Monday 16.00, with agenda:
- Reanalyze and make detail task in the sprint backlog that the team must address in the current sprint,
- Prepare the Sprint Backlog that details the time estimation it take to do the tasks based on the
responsible team member ability and availibility,
- Identify and communicate how much of the tasks are likely to be done during the current sprint, with
the total work hour for each team member should range between 20 hours – 30 hours / week.

• Sprint Retrospective meeting
This meeting was done at the middle of each sprint period, typically every Wednesday 16.00, with agenda
to review the task that has completed and not completed, and discuss the problem during the past 2 days.
This meeting was also purposed to analyze the problem, if it effect the achievement targets that have been
specify in sprint backlog or not and the necessary reaction on it.

• Sprint Review meeting
This meeting was done at the end of sprint period, typically every Friday 1600, with agenda to reflect the
past sprint, add new things to the product backlog, make general task that be candidate task in the sprint
backlog for the next sprint. In this way we always make continuous process that lead to improvement and
working incrementation.

We have proved, that this concept successfully lead us into our targeted achievement as team can work
on the software development and business analysis based on the sprint backlog on one certain sprint period
and then continued the next new sprint until we completely achieve the goals

12

!

3.2. Software Development
Inside the frame of Scrum Agile methodology, the Software development approach we used both in
Remote Management and WSN/DTN Gateway is Iterative approach, as illustrated in Figure 2 below.

Figure 2. ConDroid Software Development Approach

• Problem Definition
Before starting the real work, we need to clearly know the problem in the area. Thus, we did research in
specific task in order to understand the boundary and opportunity in the next phase. For example, in the
Remote management task, we have came to understand that there is ‘no-phone-root’ requirement in the
implementation, as this approach complicated enough to be implemented in the real life by the user and
increase the chance of hardware failure. Meanwhile, in the WSN/DTN Gateway, we especially have came to
understand the aspect of embedded system, including the importance of efficiency and flexibility of the
approach, in term of power usage, connectivity constraint, etc.
After understand the global problem, we researched the possible alternatives to implement the system,
what available technology exist in this area, what are their limitations, the suitable approaches (including
software and hardware) for that specific purpose, and also each advantages and disadvantages of them in
various aspects. Our major research including [13, 14]:

13

!

1. Remote Management
- Approach (Android NDK, SDK)
- Connection Solution (Bluetooth, Audio Jack, USB)
- Serial Level (TTL, RS232)
- Serial Converter Board (ADB & ADK compatible Boards)
- Compatibility Issue
- WiFI Repeater & Optical Amplifier
2. WSN/DTN Gateway
- Existing Bytewalla projects (Bytewalla 1 - 4)
- Embedded OSs (Voyage, Bifrost)
- ALIX Board
- DTN2
- WSN platforms (TinyOS, Contiki, SunSPOT)
- Web-page platforms (Phyton, PHP, JSP)
- Core-Engine programming languages (Java or C/C++)

• Analysis
After recognized the problem and the opportunity in the specific area, we identified the most possible
and efficient ways to implement each of the specific systems and then made our decision. In this phase we also
identified the team strength relate to the specific tasks. We analyzed the complexity of these both tasks still can
be handled by our available 4 software engineers, thus we then splinted the responsibility among them into 2
sub-teams, which are Remote Management team and WSN/DTN team, each of the team consist of 2 software
Engineers. The result of this phase are consist research documents, System Architecture & Requirement for
both Remote Management and WSN/DTN Gateway [13, 14, 15, 16]:
There are 2 Serial Converter boards we considered, Seed Studio and IOIO. The Seed Studio provide
Arduino-compatible board that supports the ADK firmware, that has 4 TTL serial ports and has backward
capability to Microbridge firmware, so It can support the ADB as well. The IOIO that work with ADB, has 4
TTL serial ports and beta support to ADK firmware, so it can work with the Open-Access API. The other
boards are not considered due to limitation of its features (No RS232 / TTL interface availability, lack of
technical documentation and support, or too expensive). In order to use this board, we need additional TTL-
to-RS232 converter as the network equipments we intend to read has RS232 port, not TTL port.

14

!

2. WSN/DTN Gateway
We decided to extend the pilot project that has been implemented before in this area [42], which is the
Automatic Data Login for SunSPOT (ADLS), work based on web-page platform, and implemented the down
layer as Core-Engine in order to achieve the requirement. This decision was made in order to minimalize the
change that need to be done in the further implementation step, thus it can save our time while still keeping the
quality of the system as priority. This extended Web-page platform then control the whole WSN/DTN
Gateway on top of Core-Engine platform, and also at the same time, provide the graphical user interface and
interaction feature. Meanwhile, we decided to keep using the SunSPOT platform as the WSN, due to the
reason that they are suitable enough to simulate the system and considering the availability of this hardware in
TSLab. The Voyage OS was chosen as the bottom-ware layer of the system, due to its simplicity and
robustness aspect when it is implemented in the embedded system environment.

• Design
After made our decision, we then specified the Software Architecture, possible features that can be
implemented, and how the user interacts with the system using graphical user interface and interaction, both in
Remote Management and WSN/DTN Gateway [17, 18, 19].

• Development
As each Remote Management and WSN/DTN Gateway task has been clearly defined, analyzed and
designed, thus the step during the development phase consists of Software skeleton development, Software
graphical user interface (GUI) and interaction development, the core-engine development and
network/software configuration. The tools, software, and programming languages used in this phase are listed
below:
- Android SDK [20]. Android OS provides operating system, middleware and applications for mobile
devices. We use various APIs from Android SDK in the Android phones to make them support for the
project goals.
- Java development kit (JDK) [21]. The Android code is based on Java programming language thus we use
JDK to develop and debug the code
- Subversion (SVN) [22], is used to store the source code, handle version control and keep the history of
revisions.
- Eclipse [23], is used as IDE (Integrated development environment) as Google supports the Android

15

!

development using this IDE as its Android Development plug-in, called Android development Tools
(ADT) [24].
- Android Emulator [25], provided by Android SDK is used to debug and test the code before it is installed
in the real phone.
- IOIOLib [26], is an Android library, which enables the Android application to control the IOIO board
over ADB [27]
2. WSN/DTN Gateway
- Voyage OS [28], is light version of Debian linux OS distribution that is best run on the embedded
platforms.
- DTN2 [29], is protocol in computer network architecture that address the technical issues in network with
lack continuous connectivity
- Oracle Berkeley DB [30], is light embeddable storage engine that provides local database.
- SunSPOT SDK [31], is Sun Java Runtime Environment to develop application for SunSPOT Mote and
Base Station.
- PHP [32], is Hypertext Preprocessor and Server-side HTML embedded scripting language, used to
develop WSN/DTN Gateway web-based UI for management and configuration.
- MySQL [33], is an Open source Relational database management system (RDBMS), used to poll the WSN
mote data in WSN/DTN Gateway
- Apache [34]. Apache is an HTTP Server, used to deliver WSN/DTN Gateway web-based content
- Apache Ant [35], is java library and command-line tool to build Java application.
- DNSMAQ [36], is lightweight DNS forwarder and DHCP server, used in WSN/DTN Gateway
implementation
- Java development kit (JDK) [21]. The Core-Engine of WSN/DTN Gateway work based on java, thus we
use JDK to develop and debug the code
- Subversion (SVN) [22], is used to store the source code, handle version control and keep the history of
revisions.
- Netbeans [37], is used as IDE (Integrated development environment) in this task as SunSPOT SDK
provide fully compatibility with this IDE

• Deployment
After finishing the development phase, each of the team entered the deployment phase where the
implementation of the code and configuration were done. The result of this phase is the detail of Installation

16

!

Guide and User Manual document, both for Remote Management Application and WSN/DTN Gateway
Core-Engine [38, 39].

• Verification
After passing the deployment phase, each of the team entered the verification test. The verification tests
were also done partially during the development phase, however this phase is consist of complete integration
verification test for both Remote Management Application and WSN/DTN Gateway in its complete system,
based on the system architecture that has been identify in previous phase. The result of this phase is the detail
of Verification test document of Remote Management Application and Verification test document of
WSN/DTN Gateway [40, 41]. It is also possible for the team member to go back to Analyze, Development
and or Deployment phase, as mostly some bugs are still exist and also found in this phase.
In the Remote Management verification test, we faced the hardware availability boundary, where we could
not get the proper RS-232 male-to-male cable, which is needed to connect the RS-232 to TTL converter board
with the Optical Amplifier, thus we did integrated verification test of the Remote Management application with
the WSN/DTN Gateway. In this Verification test, we successfully proved the concepts work properly and
integrated the Remote Management application with the WSN/DTN Gateway system, where the Remote
Management application controls the WSN/DTN Gateway.

• Documentation
After passed the Verification test, we reviewed all the technical documentations that we have made into
final version and made necessary improvement. The documentations were make in every phase, step by step,
every time we passed each phase, because the documentation result of each process would possibly to be detail
enough when it is done directly after the each process finish. And also, this is important in order to optimize
the work, as our team is small and it is important to do the work in advance rather than to put the entire
workloads at the end. The technical documentation that was made specifically during this phase is the code
documentation, both for Remote Management application and WSN/DTN Core-Engine applications [43, 44].

3.3. Human Resources
Our project team is the smallest team in both of CSD summer batch and fall batch, in term of the
number of team member and the number of working hour. We consist of 5 master students with backgrounds
relative to the tasks required for the project, which 4 members commit to 15 ECTS and 1 member commit to
18 ECTS. Thus, the total numbers of work hours dedicated to the projects are: 2080 hours, range in 20 weeks

17

!

workday. We also faced several team re-consolidations during the beginning of the project where 1 student was
re-allocated to the other project, followed by unification between our team with other team (SomaliREN),
before Champion decided the new team became too big enough, and then we got splitted again with 4 team
members. Soon after that, we got new student join to the project, which made the project consist of 5 team
members again. This dynamization made the Condroid team was struggle to balance the situation and working
environment for a while, while the other team has entered their balance phase and did the real work.
However, we successfully passed that challenges and also became understand that, it is not fully a matter
if we are small team, because the key in making the project successful is management. We were aware that, an
efficiently managed small team could produce better results than badly managed big team. Hence, we splitted
our team into several parts of responsibilities, after carefully calculating each of team member capability and
interest, as show in figure below:

Figure 3. Condroid Organization Diagram [9]

18

!

3.4. Hardware Resources
Several network equipments and other devices were needed for simulating and verification purpose. The
hardware resources, which were required in this project, are mentioned below:
• Android Phone
The Android phone is used as the environment where the application runs on top of its platform. The
requirement of this android phone is specify in the table below:
Table 1. Android Phone Requirement
Specification Requirement
Operating System Android 1.4 and newer
Phone Memory 256 MB
SD Card 512 MB
I/O Interface USB or Micro USB
Other SIM Card with sufficient amount for SMS communication

• Serial Connection equipments
The serial connection equipments are used to connect the phone with the network equipment and to
translate the signal. The requirement of the serial Connection equipments used in the project is specify in the
table below:
Table 2. Serial Connection Requirement
USB-to-Serial Converter Board IOIO Board
RS232-to-TTL Converter Board Male/Female RS232 interface
USB Cable USB-to-Micro USB/Mini USB
(Depend on the USB interface in Android phone)

• Network Equipment
The network equipment is used to test and simulation the real working environment of the system where
the Remote Management application be deployed. This network equipment could be WiFi Repeater, Optical
Amplifier or even ALIX board, as both of them has Serial interface port. As mentioned earlier, in this project
we have verified the Remote Management application work by testing it with ALIX board, where it control the
WSN/DTN Gateway.

19

!

2. WSN/DTN Gateway.
• ALIX Board
The ALIX board is used as the environment where the WSN/DTN Gateway platform be installed on top
of it, including the bottom-were, middle-ware and upper-ware (Core-Engine and Web-page admin). The
requirement of the ALIX board used in the project is specify in the table below:
Table 3. ALIX Board Requirement
Storage Minimum 4GB CF
RAM 236 MB
I/O Interface USB, DB9 RS232 Serial Port
Network Interface • Ethernet 10/100
• Wi-Fi compatible with IEEE802.11 b/g with Antenna

• WSN Hardware
The WSN Hardware is used as the media that sensing the environment, collect, and pass this data to the
WSN/DTN Gateway. The requirement of the WSN Hardware used in the project is specify in the table
below:
Table 4. ALIX Board Requirement
Sensor SunSPOT Mote
Base station SunSPOT Base station or Mote that is set as Base station

4.3 Space Resources
In order to establish the project requirements, all the team members need to work together in a room with
enough space for 5 persons, where hardware resources were also placed. Starting from June 23, 2011 we got a
room to work in 8321, Floor 8 – KTH, Forum Building, with locker that has adequate security facility and a
lock door to secure the hardware resources.

20

!

4. System Architecture & Design
4.1. Remote Management
The architecture of the Remote Management in its complete system is illustrated in the figure below:

Figure 4. Remote Management System Architecture [15]

The figure above shows that the administrator is far away from the network equipments (which could be WiFi
repeater, optical amplifier, WSN/DTN Gateway, etc). The ConDroid Remote Management application
provides both local control approach (Minicom or HiperTerminal-like console) and remote approach for
administrator to manage the network equipments using android cell phones through short message, and with
extended feature it also possible to communicate and control the hardware using dialing or the Internet
connection.

21

!

4.2. WSN/DTN Gateway
The architecture of the WSN/DTN Gateway in its complete system is illustrated in the figure below:

Figure 5. WSN/DTN Gateway System Architecture [16]

The figure above shows the WSNs deployed in remote area with no Internet connectivity (Village network).
The sensors in each network continuously broadcast the sensor data, and the Base station passes the data it
receives from the sensor within its area to the WSN/DTN Gateway, which then log this data in the database.
The WSN/DTN Gateway is also equipped with WiFi Access point, which makes it enable to be reached by the
user both for accessing the data directly through its Web-base interface or for tapping the bundle sensor data.
Using the WSN/DTN Gateway Web-base interface, user can see these sensor data in the table format, analyze
it using graph, or even download it. The WSN/DTN Gateway also continuously generate the sensor data in
specific range of time into DTN bundle, so these bundles ready to be forwarded to any DTN node within the

22

!

range of the WiFi AP of the WSN/DTN Gateway. The DTN bundle generation also possible to be triggered
by user using the Web-based Interface. The Bytewalla phone plays the role as the postman of these sensor
bundle, that carry these data and forward it to another DTN node until this bundle reach the destination in the
City Network, either trough cellular network or direct link (WiFi Access Point) of the City WSN/DTN
Gateway. After the sensor bundle received in the City WSN/DTN Gateway, it then possible to be accessed by
the user using the same Web-base Interface platform that is deployed in Village WSN/DTN Gateway. The
Village WSN/DTN Gateway implement data compression to the sensor data before it is sent as DTN bundle
in order to optimize the resource, where the City WSN/DTN Gateway then un-compress it again when
receives this DTN bundle.

23

!

5. Project Deliverables
5.1. General Deliverables
1. Project Plan
The project plan contains the detail contract between team member and teaching team, and records the
plan that was followed throughout the project. The latest version of this document can be found in
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/ConDroid%20Project%20Team%20V.1.7.pdf

2. Project Name and Logo
The unique project name and logo is important to define the project and unify the team member. Thus we
have spent some time to define the name, which is Condroid, means Connection/Communication over
Android; and the logo for our project, which is the Android robot with magic wound in its hand. This concept
then was proposed to the Champion and Coaches, and the implementation of it can be found in every element
of the project, including documents, website, video, presentation slides, etc.

3. Project Website
Condroid project website is based on CMS, which has been maintained during the project phase, and can
be found in this link http://csd.xen.ssvl.kth.se/csdlive/content/android

4. Mid-Term Workshop Presentation
The Mid-Term Workshop presentation was done in August 29, 2011. The Mid-term workshop
presentations of Condroid can be found in:
• Part 1
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/PART%201%20-
%20Project%20Presentation_1.pdf
• Part 2
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/PART%202%20-
%20Project%20Presentation_1.pdf
One of our team members also has presented the work of this project before the Mid-Term workshop, at
the 3rd DAAD Summer Academy on Wireless Communication 2011, conducted in Technische Universität
Ilmenau, Germany. The presentation file can be found in
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/Presentation%20Condroid%20-
%203rd%20DAAD%20Summer%20Academy%20in%20Wireless%20Communication%202011.pdf

24

!

5. Mid-Term Peer-Review
Peer Review to CARENET team, another project team of CSD Summer 2012, was also done during Mid-
Term Workshop.
• The latest Peer Review document to CARENET team can be found in
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/Peer%20Review%20for%20CareNET%20
V1.1.pdf.
• The Peer Review presentation slide of CARENET team can be found in
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/Peer%20Review%20Presentation.pdf

6. Final Workshop Presentation
The Final Workshop presentation was done in October 13, 2011. The Final workshop presentations of
Condroid can be found in:
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/Condroid%20Final%20Presentation%20File_0.
pdf

7. Press Release
The Press Release preached the project achievements has been made, and can be found in
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/Condroid%20Press%20Release_1.pdf

8. Project Video & Social Channels
Condroid team has made several videos during the project:
• Final Video, describes the achievement of the project, can be found in
http://csd.xen.ssvl.kth.se/csdlive/content/final-deliverables-3
• 2 Technical Videos, describes the preliminary achievement in Remote Management and WSN/DTN
Gateway, which was made and presented during the Mid-Term workshop to the new CSD Fall 2011
students. These technical videos can be found in http://csd.xen.ssvl.kth.se/csdlive/content/mid-term-
deliverables
All these progress of the Condroid project also have been uploaded to another social channel in order to
spread the ideas and achievements. The Condroid project social channel for video can be found in
http://www.youtube.com/user/condroid2011 The Condroid project social network channel can be found in
http://twitter.com/#!/condroidcsd2011

25

!

9. Project Poster
Condroid exhibition Poster in PDF format was printed in A1-format and displayed at the final exhibition. This
poster can be found in http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/A1%20-
%20CONDROID%20Summer%20CSD%202011%20Poster.jpg_0.pdf

10. Final Exhibition
The Final Exhibition of Summer CSD 2011 was held on October 14, 2011, starting at 10.00 to 14.00 at
Forum Restaurant Lobby. During this Exhibition, Condroid team presented both Remote Management
application and WSN/DTN Gateway prototype, and discussed our achievement with the attending guesses, as
same as showed the idea using the Project Video and Press released sheets that were printed and spreadt during
the exhibition day.

11. Lesson Learned & Individual Contribution
Lesson Learned & Individual Contribution of Condroid team can be found in
http://csd.xen.ssvl.kth.se/csdlive/content/final-deliverables-3

12. Final Report
The Condroid Final Report can be found in http://csd.xen.ssvl.kth.se/csdlive/content/final-deliverables-
3

13. Weekly Report
The Weekly Reports records and describes each week working progress of the project and attached with
individual time sheet of each team member. All the Weekly Reports of Condroid team can be found in
http://csd.xen.ssvl.kth.se/csdlive/content/progress-reports-8

26

!

5.2. Technical Deliverables
A. Remote Management
1. System Analysis and Design
• Remote Management Set up procedure
This document describes the complete procedure that we followed to set up the Remote Management
application. The latest version of this document can be found in
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/ConDroid%20Remote%20Management%20S
et%20up%20Procedure%20V1.1.pdf

• Remote Management System Architecture and Requirement
This document describes the System Architecture and System Requirement of the Remote Management
as remote interface for WiFi Repeater and Optical Amplifier. The latest version of this document can be
found in
ystem%20Architecture%20&%20System%20Requirement%20V1.3_1.pdf

• Remote Management Feature & GUI Design
This document describes the Feature and GUI design of the Remote Management Application. The
latest version of this document can be found in
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/ConDroid%20Remote%20Management%20F
eature%20Design%20V1.1_0.pdf

2. System Development
• USB-To-Serial Converter Board for Android Procurement
This document describes the detail of purchasing the USB-to-Serial Converter board and TTL-to-RS232
Converter cable to set up, develop and testing the Remote Management system. The latest version of this
document can be found in
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/Serial%20Converter%20Board%20Purchasing
%20Information%20V1.2_0.pdf

27

!

• WIFI Repeater Procurement & Research
This document describes the WiFi Repeater procurement proposal for SomaliREN long distance link
between SomaliREN NOC in Hargeisa City and Amoud University in Borama City. The latest version of this
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/WiFi%20Repeater%20Procurement%20&%2
0Research%20Document%20V1.1_0.pdf

• Remote Management Software Architecture
This document describes the detail of the Remote Management software design. The latest version of
this document can be found in
oftware%20Architecture%20V1.1_0.pdf

3. System Deployment & Testing
• Remote Management System Verification Test Report
This document describes the Verification test of the remote management application, which was done
during Week 40 – Week 41, October 3, 2011 to October 12, 2011. The latest version of this
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/Remote%20Managemetn%20Verification%20
Test%20Report%20V1.0.pdf

• Remote Management Installation Guide & User Manual
This document describes the detail of Remote Management Installation Guide & User Manual. The
latest version of this document can be found in
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/Condroid%20Installation%20guide%20and%
20user%20manual%20V1.0.pdf

• Source Code and application file
The source code and application file (APK) of the Remote Management application that can be found in
http://csd.xen.ssvl.kth.se/csdlive/content/remote-management-system-deployment-testing

28

!

• Code Documentations
The Code documentation of the Remote Management application that can be found in
http://csd.xen.ssvl.kth.se/csdlive/content/remote-management-system-deployment-testing

B. WSN/DTN Gateway
1. System Analysis and Design
• WSN/DTN Gateway Set up procedure
This document describes the complete procedure that we followed to set up an integrated WSN and
DTN environment using specific configured WSN/DTN Gateway and existing Bytewalla. The latest version
of this document can be found in http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/WSN-
DTN%20Gateway%20Set%20up%20Procedure%20V1.1.pdf
• WSN/DTN Gateway System Architecture and Requirement
This document describes the System Architecture and System Requirement of WSN/DTN Gateway.
The latest version of this document can be found in http://csd.xen.ssvl.kth.se/csdlive/content/wsndtn-
gateway-system-analysis-design

2. System Development
• Voyage OS & DTN2 on ALIX Board Installation Guide
This document describes the Voyage OS and DTN installation procedure in the ALIX Board machine
in order to set up WSN/DTN Gateway. The Document also describes the DTN configuration procedure of
the WSN/DTN Gateway for Static route and Dynamic route mode, so it can communicate with existing
Bytewalla environment (Bytewalla 1 – Bytewalla 4). The latest version of this document can be found in
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/Voyage%20-%20DTN2%20Installation%20-
%20Configuration%20Guide%20V1.4_0.pdf

• WSN/DTN Gateway Middleware on Voyage OS Installation & Configuration Guide
This document describes the WSN Middleware installation procedure in the Voyage OS on top of ALIX
Board workstation in order to set up WSN/DTN Gateway. The latest version of this document can be found
in http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/WSN%20Middleware%20Installation%20-
%20Configuration%20Guide%20V1.2.pdf

29

!

• Bash Shell script for automatic DTN installation
This bash script can be used to do the installation of DTN2 & Middleware service of WSN/DTN
Gateway in Voyage OS environment. This script can be found in
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/dtn.txt

3. System Deployment & Testing
• Bytewalla Verification Test Report
This document describes the Verification test of the existing Bytewalla environment, which was done
during Week 33, August 16, 2011 to August 18, 2011. The latest version of this document can be found in
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/Bytewalla%20Verification%20Test%20Report
%20V1.3_0.pdf

• WSN/DTN Verification Test Report
This document describes the Verification test of the WSN/DTN Gateway, which was done during
Week 40 – Week 41, October 3, 2011 to October 13, 2011. The latest version of this document can be found
in
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/WSN:DTN%20Verification%20Test%20Rep
ort%20V1.0_0.pdf

• Source Code and application files
The source code and application file (Jar) of the WSN/DTN Gateway web-page admin, Core-Engine
Sender, Core-Engine Receiver and SPOT applications that can be found in
http://csd.xen.ssvl.kth.se/csdlive/content/wsndtn-gateway-system-deployment-testing

• Code Documentations
These Code documentations contain the java docs of the Core-Engine Sender; Core-Engine Receiver
and SPOT applications used in WSN/DTN Gateway system can be found in
http://csd.xen.ssvl.kth.se/csdlive/content/wsndtn-gateway-system-deployment-testing

30

!

• WSN/DTN Gateway Engine Installation Guide & User Manual
This document describes the WSN/DTN Gateway Engine Installation Guide & User Manual, which
cover WSN/DTN Core-Engine Sender, WSN/DTN Core-Engine Receiver, WSN Core-Engine SPOT and
WSN/DTN Webpage Admin. The latest version of this document can be found in
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/WSN:DTN%20Gateway%20Engine%20User
%20Manual%20&%20Installation%20Guide%20V1.1_0.pdf

5.3. Business Deliverables
• Remote Management Business Model
This document describes the business model for Condroid Remote Management application, based on
“the business model ontology” written by Alexander Osterwalder. The latest version of this document can be
found in
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/Condroid%20Remote%20Management%20Ap
p%20-%20Business%20Model%20v1.0_0.pdf

• Remote Management SWOT Analysis
This document describes the SWOT and SWOT strategy for Condroid Remote Management application.
The latest version of this document can be found in
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/swot%20document%20cover%20template.pdf

• Remote Management Business Plan
This document describes the Business Plan for Condroid Remote Management application, including
marketing strategy, financial aspect, and Risk Management. The latest version of this document can be found in
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/business%20planv1.0.pdf

31

!

6. Unique Contributions
Condroid project has successfully developed revolutionary solutions to connect the isolated network
equipment and remote infrastructure to the outside world. The sections below describe our analysis for the
unique contributions of each specific achievement in this project.

The Condroid Remote Management application is the first application that implement both UART
connection to the network equipment that result on “Minicom-like” application, at the same time provide the
external communication channel to the outside world. In this pilot project we have implemented the SMS
module as one of the control channel, where the concept can be extended easily to dialing and Internet
connection. This research software makes it possible to configure and monitor the network equipment through
available connections. The approach that we have chosen (ADB and IOIO board), make the implementation
become cheap and simple to be deployed, even to be done by none technical user.

Condroid project also has successfully implemented a flexible WTN/DTN Gateway, an innovative
solution that combining the Delay Tolerant Network (DTN) approach into the Wireless Sensor Network
(WSN). This solution is intended to solve the technical issues in carrying the data from the spatially distributed
autonomous WSN motes to the outside world. The WSN motes are deployed to monitor physical or
environmental conditions, connected to a WSN Gateway, which collects the information received from nodes,
stores them in a database. The Gateway also provides interfaces between the sensor network and the external
network infrastructure, by making make them available via WiFi link and DTN.
Based on the best of our knowledge, this is the first implementation where the WSN is combined with the
DTN approach, on top of embedded OS environment. Combined with the Bytewalla, the first implementation
of DTN in Android platform and mobile phone, this can be considered as revolutionary concept that would be
valuable to be implemented in remote and challenging environment, for example in developing country, where
the network connectivity is limited.

32

!

6.3. Business Analysis
Apart from the technical tasks, we also provide the Business analysis of the Remote Management
application. As what has been mentioned above, this Business analysis can be the first step to bring the Remote
Management application into the real life and society, thus added the value of its provide services. It
conceptualizes the Condroid Remote Management end product and its value proposition for the end customer
in a scientific and structured manner, and elaborates methods and channels to reach customer.
Moreover, a comprehensive risk analysis along with the mitigation strategies is also conducted. The mobile
phone is less power consuming compared to other devices, using this Remote Management application in
mobile phone and connect it with RS232 cable, the network equipment can easily provide the mobile phone
with power supply. As the android market increasing dramatically during the past two years, mobile application
based on Android platform is expanding greatly, and the mobile phone is easy to bring and much cheaper
compare to laptop. Since the market of android is expanding greatly, the advantage of developing the
application based on android phone become obvious.

33

!

7. Future Works
According to the Verification result of Remote Management application [40], we can clearly see the application
can execute the command properly both for local control using ‘Minicom console-like’ UI and SMS
communication feature. However, there are still some issues rise and it is necessary to add several modules in
order to improve the features of Remote Management Application. The modules or aspects in Remote
Management implementation that we think need to be added or considered in the future works are:
1. Short-Cut implementation
The “short-cut” implementation should be added in future work, especially in the implementation of SMS
communication feature, both for command and respond. As SMS is suitable for short message, thus it is
important to make communication between the application and user short as possible and achieve the same
result. For example, user only need to send some code trough SMS to the application, then the application
should able to translate this code into specific command which already been defined by user before, and then
application should also able to send back the respond from the system with specific code (FAIL or SUCCESS)
as what already been defined by user as well. Now this module is part of unfinished functionalities in the
Remote Management application. Thus it is necessary to be achieved in order to provide a fully functioned
module.
2. Dialing Communication Feature
The dialing module would be necessary to be added as another communication feature. As the SMS
feature is fully provided by GSM and CDMA network, and this application work based on assumption that it
work on top of the cellular network service, thus there is no reason to not add this feature to the application.
This also becomes necessary if user need another choice rather than SMS to communicate with the application.
The dialing communication feature would make user need to type less command, but also only useful if user
required less respond from the application, and it only fully works based on Short-Cut implementation.
3. Internet Communication Feature
Even tough the Internet access is not always available in every cellular network, and this application is
originally addressed to be placed in the remote and isolated area, but this communication feature would also
add the value of the application. The Internet communication would provide user fully ‘SSH-like’ experience to
the equipment even they actually communicate through bridge device, which is a mobile phone. The
implementation of Internet communication would also open a lot of flexibilities to the user using the
application and it would be necessary if the equipment is placed in the area that has Internet access (GPRS, 3G,
etc).

34

!

4. SNMP enable-agent
Implementation of SNMP in Android would be the next interesting challenge that should be counted if
the application has the Internet communication feature. As the Remote Management application is used to
manage and control the equipment, thus SNMP is suitable to be used as management protocol, because of its
simplicity. The SNMP that we recommend to be added is SNMP version 3 as it has security feature. The
SNMP-enable agent implementation in the application would make this application has fully complete feature,
both in term of flexibility in the communication and security.
5. Minor Bug Fixing
There are still some minor bugs exist, which found during the verification and need to be fixed. Some
improvement in the code is also need to be added in order to optimize the code.

Based on the verification elements that have been done to the WSN/DTN Gateway [41], we can conclude that
the concept in this system is feasible to be deployed in real-life scenario, and the platform that has been
deployed meet the requirement to make the system run. However, there are still some issues rise and it is
necessary to add several modules in order to improve the features of this WSN/DTN gateway. The modules or
aspects in WSN/DTN Gateway implementation that we think need to be added or considered in the future
works are:
1. User privileges & Security implementation:
The WSN/DTN Web-base Admin platform provides fully control to the WSN/DTN Core-Engine.
Thus, it is necessary to have different user accounts, such as administrator and common user, which required
secure authentication to access system. The administrator should also able to manage user account, such as
granting or revoking the access of common user.
2. Flexible & controlled scheduler data distribution
The time range of scheduler data distribution is specified by hard code in Core-Engine Sender application
(every 1 minute). Thus it would be better if user can also specify (change) this number, depend on the needs
during implementation.
3. File naming concept limitation
Core-Engine applications was built based on assumption that the time arrival between each file bundle is
long enough that make the WSN/DTN Gateway city (Receiver) still has time to un-compress the file and read
the data inside it. Thus, the name of the file bundle is fix (wsndtndata), so the WSN/DTN Gateway city
(Receiver) able to recognize this is the WSN data file. But in real life scenario, it is possible that this assumption

35

!

fail, which makes the old file to be overwritten by the new file before it is finish to be read, thus the data inside
is unable to be stored in WSN/DTN Gateway city (Receiver) database.
4. Black-hole fixing in Bytewalla:
The Bytewalla is act as post-man application for the DTN bundle sent from the WSN/DTN Gateway
Village (Sender) to WSN/DTN Gateway City (Receiver) in fully integration scenario. Thus, it is important to
make this application stable and guarantee the presence of the bundle in its database. Currently, we have found
that some bundles missing when they have been passed to the Bytewalla, especially when the DTN daemon
stop working and need the application to close (crash). This would make the data completely missing and never
be received by the WSN/DTN Gateway City (Receiver). The Bytewalla application (Bytewalla 3 and Bytewalla
4) also sometime not stable, especially when it is run in Android Tatoo.
5. DTN deployment bug in Voyage OS
We also found, the DTN2 proPHET routing implementation in Voyage OS was not table yet; sometime
DTN cannot discover the link to the other DTN node (simply, they do not recognize if the link is up or not),
event if they are directly connected with Ethernet link. We also found the DTN file receiver (dtncp) sometime
crash, and it makes the DTN daemon also crash, this would be dangerous if it happens during the automatic
DTN set up in WSN/DTN Core-Engine, as it can be detected by the application, because java unable to
monitor the DTN daemon that is running in the service.
6. SunSPOT deployment bug in Voyage OS
The SunSPOT application also require multicast enabled in order to be able to run, and this is not enabled
by default in Voyage OS, thus it is important to check at least 1 interface in the WSN/DTN Gateway has been
multicast enabled, so application can run (in this environment, we set it in wlan0 interface). And as mentioned
earlier, The SunSPOT application unable to open socket connection to the Base station mote connected to the
USB port of ALIX board. Even when we have tried to use un-used ports, the Core-Engine Sender still gets IO
exception regarding this socket connection. This is the most important issue that is needed to be solved in
future work.

36

!

8. Conclusion
The Condroid project has achieve all of it goals, and at the same time accomplished its secondary goal,
which is the Business Analysis of Remote Management application. These all achievements were made in
effective and efficient manner, with limited human resources. All of its primary goals are the pilot project in its
area and in KTH environment, where the team faced more challenge in conducting the research.
The first primary goal involves the introduction of Remote Management application implementation in
android platform. The Condroid team has made comprehensive research and came to the most less cost and
simple solution to the deployment of the product in real life scenario. The other primary goal implements the
first WSN/DTN integration result as the gateway for the sensor data, that make the data gathered by the
remote sensor network infrastructure can be accessed by the outside world.
The comprehensive business aspect of Remote Management as secondary goal was also covered within
the project time line. It involves a scientific approach in the generation of the business model, as well as
preliminary business plan, which encompasses the business aspects, varying from Products value proposition to
customer interface in structured manner. A detailed insight is provided, pertaining to Business aspects and
procedures of Remote Management application, which can be easily to be adopted by the local mobile
operator.
Indeed, all the team members are very excited about the successful deployments of both achievement in
Remote Management and WSN/DTN Gateway, and we are very optimist the concepts would be successful
and feasible to be implemented in real life, thus adding the value to society and people life’s. Some of the team
members also expressed their interest and commitment to write scientific papers relate to the implementation
of Remote Management and/or WSN/DTN Gateway.

37

!

9. Reference
[1] “SomaliREN”.
http://www.SomaliREN.org/index.php?option=com_content&view=article&id=8:who-
weare&catid=1:about-us&Itemid=9 Last visited - October 2011
[2] “WSN/DTN Gateway: Design of an embedded system interfacing a Wireless Sensor Network to the
world via a Delay Tolerant Network” https://www.tslab.ssvl.kth.se/thesis/node/1381
[3] “Android SDK” http://developer.android.com/sdk/index.html Last visited - October 2011
[4] Marco ZENNARO, Hervé NTAREME and Antoine BAGULA. “On the design of a flexible gateway
for Wireless Sensor Networks”. http://m4d.humanit.org/2008/images/stories/pdf/papers/a17-
zennaro.pdf Last visited - September, 2011
[5] “Bytewalla 1: Implementation of Delay Tolerant Networks on the Android platform”.
http://www.tslab.ssvl.kth.se/csd/projects/092106/ Last visited – October 2011.
[6] “Security in Delay Tolerant Networks (DTN) for Android Platform - Bytewalla II”,
http://www.tslab.ssvl.kth.se/csd/projects/1011248/ Last visited – October 2011.
[7] “Bytewalla 3”, http://www.tslab.ssvl.kth.se/csd/projects/1031352 Last visited - October, 2011
[8] “Bytewalla 4: Implementation of Delay Tolerant Networks on the Android platform”.
https://www.tslab.ssvl.kth.se/thesis/node/1382 Last visited - October 2011
[9] “Condroid Project Plan”
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/ConDroid%20Project%20Team%20V.1.
7.pdf Last visited - October 2011
[10] “Condroid Remote Management Business model”
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/Condroid%20Remote%20Management%
20App%20-%20Business%20Model%20v1.0_0.pdf Last visited – October, 2011
[11] “Condroid Remote Management Business Plan”
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/business%20planv1.0.pdf Last visited –
October, 2011
[12] “Scrum (development)” http://en.wikipedia.org/wiki/Scrum_(development) last visited - October 2011.
[13] “Condroid Weekly report – Week 26”
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/ConDroid%20Team%20Weekly%20Rep
ort%20-%20Week%2026.pdf Last visited - October 2011.

38

!

[14] “Condroid Weekly report – Week 27”
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/ConDroid%20Team%20Weekly%20Rep
ort%20-%20Week%2027.pdf Last visited - October 2011.
[15] “Remote Management System Architecture & Requirement”
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/ConDroid%20Remote%20Management
%20System%20Architecture%20&%20System%20Requirement%20V1.3_1.pdf Last visited - October
2011.
[16] “WSN/DTN Gateway System Architecture & Requirement”
http://csd.xen.ssvl.kth.se/csdlive/content/wsndtn-gateway-system-analysis-design Last visited -
October 2011.
[17] “Remote Management Software Architecture”
%20Software%20Architecture%20V1.1_0.pdf Last visited - October 2011.
[18] “Remote Management Features & GUI design”
%20Feature%20Design%20V1.1_0.pdf Last visited - October 2011.
[19] “WSN/DTN Gateway Software Architecture” http://csd.xen.ssvl.kth.se/csdlive/content/wsndtn-
gateway-system-development Last visited - October 2011.
[20] “Android SDK” http://developer.android.com/sdk/index.html Last visited - October 2011
[21] “Java development kit (JDK)” http://www.oracle.com/technetwork/java/javase/overview/index.html
Last visited - October 2011.
[22] “Subversion (SVN)” http://subversion.tigris.org/ Last visited - October 2011.
[23] “Eclipse” http://www.eclipse.org/ Last visited - October 2011.
[24] “Android Development Tools (ADT)” http://developer.android.com/sdk/eclipse-adt.html Last visited
- October 2011
[25] “Android Emulator” http://developer.android.com/guide/developing/tools/emulator.html Last visited
- October 2011.
[26] “IOIOLib” https://github.com/ytai/ioio/wiki/IOIOLib-Basics Last visited - October 2011
[27] ADB http://developer.android.com/guide/developing/tools/adb.html Last visited - October 2011
[28] VoyageOS http://linux.voyage.hk/ Last visited - October 2011
[29] DTN2 http://www.dtnrg.org/docs/code/DTN2/doc/manual/intro.html Last visited - October 2011

39

!

[30] Oracle Berkeley DB http://www.oracle.com/technetwork/database/berkeleydb/overview/index.html
Last visited - October 2011
[31] SunSPOT SDK http://www.sunspotworld.com/index.html Last visited - October 2011
[32] PHP http://www.php.net/ Last visited - October 2011
[33] MySQL http://www.mysql.com/products/ Last visited - October 2011
[34] Apache http://httpd.apache.org/ Last visited - October 2011
[35] Apache Ant http://ant.apache.org/ Last visited - October 2011
[36] DNSMASQ http://thekelleys.org.uk/dnsmasq/doc.html Last visited - October 2011
[37] “Netbeans” http://netbeans.org/ Last visited - October 2011
[38] “Remote Management Installation Guide and User Manual”
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/Condroid%20Installation%20guide%20a
nd%20user%20manual%20V1.0.pdf Last visited - October 2011
[39] “WSN/DTN Gateway Engine Installation Guide and User Manual”
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/WSN:DTN%20Gateway%20Engine%20
User%20Manual%20&%20Installation%20Guide%20V1.1_0.pdf Last visited - October 2011
[40] “Remote Management Verification Test Report”
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/Remote%20Managemetn%20Verification
%20Test%20Report%20V1.0.pdf Last visited - October 2011
[41] “WSN/DTN Gateway Verification Rest Report”
http://csd.xen.ssvl.kth.se/csdlive/sites/default/files/projects/WSN:DTN%20Verification%20Test%20
Report%20V1.0_0.pdf Last visited - October 2011
[42] Marco Zennaro, Hervé Ntareme, Antoine Bagula. “On the design of a flexible gateway for Wireless
Sensor Networks” http://www.isk.kth.se/~ntareme/On-the-design-of-a-flexible-gateway-for-Wireless-
Sensor-Networks.pdf Last visited - October 2011
[43] Condroid Remote Management Code Documentation
http://csd.xen.ssvl.kth.se/csdlive/content/remote-management-system-development Last visited -
October 2011
[44] WSN/DTN Gateway Engine Code Documentations
http://csd.xen.ssvl.kth.se/csdlive/content/wsndtn-gateway-system-development Last visited - October
2011

40

Condroid KTH Summer CSD 2011 - Final Report

Recommandé

Recommandé

Contenu connexe

Similaire à Condroid KTH Summer CSD 2011 - Final Report

Similaire à Condroid KTH Summer CSD 2011 - Final Report (20)

Plus de Laili Aidi

Plus de Laili Aidi (20)

Dernier

Dernier (20)

Condroid KTH Summer CSD 2011 - Final Report