final report, skuolla internet caf e

Final Report, Skuolla Internet Cafe

Anders LindgrenSwedish Institute of Computer [email protected]

1 Introduction

The goal of the Skuolla Internet Cafe project was to deploy a Delay TolerantNetworking (DTN) system in the Skuolla area of the Padjelanta national parkin Swedish Lapland during the annual reindeer calf marking in the summer of2011. This area is very remote and does not have access to traditional commu-nication infrastructure. Thus, special technology is required to provide networkconnectivity. In addition to providing basic connectivity, the project also tar-getted providing useful applications to the users. By doing this, the projectwanted to enhance the experience for the reindeer herders and their familiesand allow them to stay more connected with the outside world during this time.The system was deployed in Skuolla for approximately one week (July 10-15,2011).

Previously, the EU FP7 project N4C and the Vinnova funded project SaamiNetwork Connectivity (SNC) have worked with the same group of people todesign and build a DTN system for that region to provide communication op-portunities. In this project we build on the work and experience that existfrom those projects, and also brings in competence about a new networkingparadigm known as Information Centric Networking (ICN) from the EU FP7project SAIL. In this project, we extend the previous work and also considerhow the concepts of DTN and ICN can be combined to enhance network per-formance and user satisfaction. In addition to the email and web access servicesthat could be run over the system previously, we also designed two new applica-tions; one video distribution application, and one social networking applicationallowing users to access Facebook over the DTN.

The rest of this report is structured as follows. In Section 2, we providea short summary of the technical work done in the project and the most im-portant overall results. In this section we will not go into any details on thedifferent components of the technical system. Section 3 discusses the adminis-trative details of the project and outlines changes to the original project plan,project staffing, and resource usage. This is followed by a description of ourdissemination activities. After that, Section 5 will provide a more detailed tech-nical overview of the system and finally Section 6 will evaluate the project anddiscuss the lessons we have learned.

1

2 Summary of Technical Results 2

2 Summary of Technical Results

In section 5, we will give a more details description of the technical aspects ofthe different parts of the system that we have developed and deployed. Here,we will provide a short summary of the most important technical results.

In general, we consider the project to have been successful. We were ableto successfully deploy the planned system and operate it during the reindeercalf marking week and allow real users to use it for communication. Softwarefor email and web access over a DTN developed in the N4C project was de-ployed as part of this. As some project partners have been integral parts of thedevelopment of that software, this was quite straightforward to set up.

The required software for the video distribution system described in theproject plan was designed and implemented. It worked fine in the lab envi-ronment, but we could observe some problems in the real deployment due toenvironmental factors and bugs in other software that was not obvious in lesschallenged settings. While that was a setback, we have ideas for how to usethis experience to improve the system for future deployments to avoid suchproblems.

We also decided to implement an extra service for the users by building aFacebook over DTN gateway that allows users to access their Facebook infor-mation and post updates over the DTN connection. This service worked fineand was very popular among the users (especially the younger ones).

3 Administrative Details

3.1 Detours from original project plan

The project mostly followed its original project plan with only minor changes.One of the biggest differences from the project plan is that we have developed

and provided one extra service (the fbDTN system for Facebook access) to theusers in addition to those outlined in the project plan. Given previous requestsfor such a system and the fact that this ended up being the most popular serviceamong the users makes us believe that this was a good addition to the project.This did however of course require additional development work, which lead tohigher labour costs, but that could be compensated for by reduced costs in otherareas as discussed in more detail in Section 3.3.

According to the project plan, we were supposed to organize meetings witha representative of SVT to discuss challenges and thoughts regarding new formsof distribution networks for media content. As we participated in workshop or-ganized by the SAIL project (where Bengt Ahlgren was one of the co-organizers)on regulatory issues for new networks and SVT was one of the participating or-ganizations, we did not consider it meaningful to plan a separate meeting withthe SVT representative to discuss very similar issues.

3 Administrative Details 3

3.2 Staffing

3.2.1 SICS

From SICS, the following people participated in the project:

• Anders Lindgren

• Bengt Ahlgren

• Mahesh Bogadi

Anders Lindgren and Bengt Ahlgren are permanent researchers at SICS,and Mahesh Bogadi was contracted to perform development work to create theDTVideo video distribution system.

As this project was carried out in parallell the the EU FP7 SAIL project,the labour costs for Bengt Ahlgren and some of the cost for Anders Lindgrenwas covered by SICS’s SAIL project budget.

3.2.2 Tolerant Networking Limited (TN)

From Tolerant Networking Limited, the following people participated in theproject:

• Stephen Farrell

• Kerry Hartnett

• Aidan Lynch

• Alex McMahon

As this project was carried out in parallell the the EU FP7 SAIL project,all the labour costs for TN representative was covered by their SAIL projectbudget.

3.2.3 Tannak AB

All practical arrangements in the area of deployment as well as other contactswith local companies and organisations (such as the helicopter company andthe Saami village) was subcontracted to the local company Tannak AB. In thisproject, Tannak AB was represented by Karin Kuoljok and Susanne Spik.

3.3 Resource usage

Overall, we were able to stay on the project budget in terms of project expenses.In more detail, there was however less money than budgeted spent on travel, sub-stinence, and equipment, while the software development cost ended up slightlymore expensive than budgeted (mainly due to the fact that the fbDTN systemwas developed in addition to DTVideo that was part of the original project

4 Dissemination 4

plan – the development for the fbDTN system was done by Anders Lindgren,and that cost does not completely fit within the budget of this project, but theexcess cost for that development is covered by the EU FP7 SAIL project).

Budget OutcomeTravel costs and subsistence 78000 18280Helicopter flights 17000 27352Tannak subcontracting 75000 74500Equipment 30000 25484SICS Programmer (Mahesh Bogadi) 148000 148000SICS Research Leader (Anders Lindgren) 50000 104384Total 398000 398000

4 Dissemination

One important aspect of the project is to not only test a DTN system in thefield, but also spread the knowledge gained from the deployment to others, bothin the research community, to others wanting to deploy a similar system, andto potential end users. In this section, we provide an overview of the differentdissemination activities that has taken place so far as well as plans for futuredissemination of project results.

4.1 Publications and Presentations

The following publications and presentations of project results have taken placeso far:

• Demo of fbDTN system presented (and demo abstract published in pro-ceedings1) by Anders Lindgren at the 6th ACM MobiCom Workshop onChallenged Networks (CHANTS 2011) in Las Vegas, USA.

• Demo of fbDTN system presented by Anders Lindgren at the 3rd ExtremeConference on Communication (ExtremeCom 2011) in Manaus, Brazil.

• Presentation of DTN system deployment by Aidan Lynch at the 3rd Ex-treme Conference on Communication (ExtremeCom 2011) in Manaus,Brazil.

• Presentation of DTN system deployment by Bengt Ahlgren and StephenFarrell at the 3rd General Meeting of the SAIL FP7 EU project in Pader-born, Germany.

• Anders Lindgren is presenting a one-day tutorial on DTNs at an eventorganized by the Computer Society of Sri Lanka in cooperation with IFIPWG 6.9 (Communication Systems for Developing Countries) in Colombo,Sri Lanka on November 3, 2011. The deployment done in this project willdescribed as a case study.

1 The poster shown during the demo presentation is included in this report as Appendix A

4 Dissemination 5

Based on the experiences from the project outlined in this report, we planto publish a more thorough paper on the deployed system and the tests done.Potential venues for such a publication could be ExtremeCom 2012, CHANTS2012, or some other suitable conference, workshop, or journal/magazine.

Many possible uses of the DTVideo application would involve letting usersaccess recent news broadcasts or other types of current TV programmes or otherpopular content. Such content might often have some legal access rights thatare not well adapted to this type of distribution where content is stored forlonger periods of time at different nodes in the network. Anders Lindgren andBengt Ahlgren participated in a workshop held at the .SE offices where suchregulatory issues were discussed and how different players view these new typesof information-centric networks. Attendants to this workshop included peoplefrom regulatory bodies such as PTS and content creators such as SVT. (Thisworkshop was organized by the SAIL project, so it should not be consideredan outcome of this project, but the discussions there were beneficial for thequestions we are considering here.)

4.2 Software Releases

The bundle protocol query (BPQ) extension block [1] was implemented as anextension to the existing DTN2 implementation of the Bundle Protocol [2]. Thecode has already been made available to a third party upon request (a researcherat a US university), and it will in the near future be integrated into the mainrelease of DTN2 so that it is easily accessible to anyone who wants to use it.

The software developed at SICS for the DTVideo system and the fbDTNFacebook gateway still have some additional features that we would like toexplore and add before making a general public release of the code. Our policyis however such that if anyone is interested in using the code, if they contactus, we will work with them to provide them with a useful snapshot of the code(along with documentation on how to use it and suggestions on how to adaptit to their particular system).

4.3 Media Coverage

Anders Lindgren has been contacted by a reporter from IDG News who is inter-ested in writing a story about the fbDTN system for one of the IDG publications.The interview has not happened yet, but should take place shortly.

4.4 Local Population

In addition to the more tangible and easily countable dissemination activitiessuch as publications and software releases, a very important means of spreadingknowledge about the project and this type of communication system is throughthe users that were active in the deployed system. This is also one importantreason for deploying a live system in a real scenario with real users instead ofonly doing more easily controlled lab experiments.

5 Technical Details 6

Since we continued working with a group of users where at least a subset ofthe users have used previous incarnations of our system (as deployed by the N4Cproject), they were aware of the availability of the system and the possibilityto send and receive emails and read some web content. Not all potential userscould however be assumed to be familiar with the system, and we also had newservices available that had not been deployed previous years. Thus, a user guide(included as Appendix B to this report) was made available online ahead of timeto the users. This explains the main characteristics of the system and how touse it. It also provides links to allow users to register for accounts in our systemfor access to the email and Facebook services. In addition to this user guide, wehad end user devices available in our tent “Internet caf” where we could explainthe system to interested users and let them use it for themselves.

The possibility to access Facebook newsfeeds and post status updates andphotos turned out to be a very popular new addition to the offered services –in particular some of the younger users visited daily to check for new updates.

Our contact with the end users was done mainly through our project part-ner Tannak AB which is owned by Susanne Spik and Karin Kuoljok, two of thereindeer herders in the Sirges Saami village. They provide us with a good under-standing of the local conditions, but the project also aids in raising the technicalknowledge level within Tannak (which works on providing smart technical so-lutions for reindeer herders and other people living under similar conditions).Indirectly, this may be beneficial for future operations and business of this smallenterprise.

5 Technical Details

In this section we will provide a more detailed overview of the system setup,and then describe some of the different subsystems that we have built.

5.1 System Setup

Figure 1 shows a map of the region where the system was deployed. Points A andB on the map are located in Ritsem, the closet you can get to Skuolla on a normalroad, and also where the communication infrastructure ends. A gateway isdeployed here, colocated with the helicopter platform. This gateway can connectto the GSM tower that is located in Ritsem and get a data connection over GPRSto the Internet. This is our main route onto the Internet. The gateway also runsthe DTN2 implementation of the Bundle Protocol. For sending and receivingbundles to/from the disconnected part of the network, the gateway uses WiFito communicate with data mules that travel back and forth to Skuolla with thehelicopters, picking up and dropping off bundles as it goes along. The maincamp site where the reindeer herders live during the calf marking week is inSkuolla at point C on the map. At this location, what is known as a villagerouter is deployed. This acts as a DTN endpoint and router (for bundles that aredestined to some other endpoint) and can receive bundles from the data mules.


Fig. 1: Map of the area where the system was deployed. A: Ritsem GSM tower.B: Fiskflyg helicopter platform in Ritsem. C: Skuolla camp site. D:Skuolla hill-top gateway. E: Lovtak. Saami camp visited, but no deploy-ment there this year.

The village router also provides a WiFi network for users to connect to, as wellas a web server that provides the user interface to some of the applications andservices that are offered to the users. This enables users to connect and use theservices with any WiFi-capable device (such as a smart-phone) and does notrequire everyone to have DTN aware software on their end devices.

The camp-site location is in a valley, so it is in a radio shadow behindmountains and is not able to communicate directly with any GSM infrastructure.In addition to the data mule path, we also enable another communication path


to the Internet by deploying a node at point D on the map. This point is locatedat the top of a hill that is close to the camp site and that has line of sight to theGSM cellular tower in Ritsem. The village router can connect to this gatewaythrough a line-of-sight WiFi link (using a high-gain antenna), and the gatewayin turn can connect to the GSM network through a directional antenna. Asdevices are battery-powered, it is not likely that both the village router and thegateway on the hill will be able to always be turned on at the same time, anddepending on weather conditions, both the WiFi link and the GSM link canbe flaky, and even when the GSM link is available, its bandwidth will be verylow. Thus, it is still important that the gateway runs a DTN2 implementationso that bundles can be sent there when that link is available to later on betransferred over the GSM link when that becomes available.

TCD

Data Mule –eeePC

n4cmule-1 10.125.14.17

n4cmule-2 10.125.14.18

n4cmule-3 10.125.14.19

RITSEM

Gateway-2User access to Wireless

SSID “n4cvillage”

10.125.14.xxx

SAIL end points :Dasher 10.125.14.20

Roudolf 10.125.14.21

P142 10.125.14.22

Skuolla Router< 50kms >Data MuleBasil :134.226.36.138

Sybil –dtn interface

gateway:192.168.1.102

SAIL Network Option 1 ( without router Bridge )Internet

3G

IP 10.125.14.12

IP 10.125.14.11VPN

n4cgateway-2

10.125.14.11

VPN (Tap0) 192.168.1.153

Village Router: n4crouter-1

AP: 10.125.14.12

Omni – ssid n4cvillage wlan0

Direction: 10.125.17.12 to

n4cgateway - wlan1

DHCP 10.125.14.xxx for clients

n4cgateway -1

3g directional to Ritsem

VPN (Tap0) 192.168.1.152

Wifi AP directional to village

SSID:n4cgateway

The Hill

Gateway-1

3G

SICS tv box

IP 10.125.17.12Change interfaces tolook for n4cgateway and IF to wlan1 to 10.125.17.12

IP 10.125.14.12

IP 10.125.17.10

internet

VPN

Fig. 2: Conceptual system overview.

Figure 2 shows a more conceptual view of the system and its different com-ponents as described above. This figure also shows which components of thesystem that is running on machines in the connected Internet. There is oneDTN machine that is located at Trinity College Dublin (TCD) in Ireland thatsupports the email and web access applications. Another machine is locatedat SICS in Sweden which runs the necessary daemons to support the DTVideoand fbDTN applications. For logging purposes, all traffic is sent through the


machine at TCD. Thus, a Bundle Protocol link is set up between the DTNgateways in the field and the machine at TCD, and a link is also set up betweenthe machine at SICS and the machine at TCD so that traffic going to and fromthe SICS machine can be routed through TCD.

As the nodes in Skuolla are deployed where there is fixed power infrastruc-ture, these nodes must be battery power. To ensure that the nodes can runfor a longer period of time, we also had solar panels connected to each of thesenodes to charge the batteries when sufficient sunlight was available.

5.2 Software

On the nodes deployed as described in the previous section, we run a combina-tion of software that was already available as well as software that was developedwithin this project.

5.2.1 Registration web site

Some of the services offered requires some actions to be taken while you arestill connected to the Internet. It is recommended that an email account iscreated before going into the DTN as that will allow you to set up forwardingof existing email accounts to that account and will allow you to transfer youraddress book to our system so that you do not have to remember the emailaddresses for everyone you wish to communicate with. For users who wish touse our Facebook over DTN gateway, it is required that they set up an accountwith that system and authorizes it to access their Facebook profile while theystill have a low-latency Internet connection as otherwise that system will notwork.

5.2.2 DTN2 - Bundle Protocol and BPQ

Communication in DTNs use what is known as the Bundle Protocol for ad-dressing, encapsulation, and end-to-end connectivity of nodes. In the deployedsystem we use the freely available DTN2 reference implementation of the BundleProtocol architecture. The Bundle Protocol Query (BPQ) extension block is aproposed extension to the Bundle Protocol that combines DTNs and ICNs andallows requested named content to be cached in the network so that future re-quests for the same content can be more efficiently served. The BPQ extensionhas been implemented within the realms of this project and the SAIL projectas part of the DTN2 code.

5.2.3 Email and Web Access

Giving end users the possibility to send and receive emails and access different(semi-static) web sites is important. This had already been done for DTNsystem in the previous N4C project, so we do not develop new software for thisin this project, but use the existing software.


5.2.4 DTVideo – Delay Tolerant Video Distribution

A large portion of Internet traffic today consists of video content in the formsof YouTube videos, streaming TV content, and downloadable video clips. It islikely that users in a remote community will also be interested in viewing thisvideo content – in particular content like the most recent news broadcast orsome other content that can not be preloaded while at a well-connected point.The problems with this kind of content is that the content size is very big, whichleads to lots of system resources being used to retrieve it. The problem getseven worse when multiple users in the same region download the same piece ofpopular content and waste lots of resources by transmitting the same bits ofdata multiple times. Since it is very common that many users wants to accessthe same content (e.g., the latest news broadcast or a new viral YouTube video),we saw the potential to leverage the benefits of Information Centric Networking(ICN) in conjunction with DTNs by making intermediate nodes aware of thename of the content that is being requested and allowing them to cache thecontent and later serve subsequent requests from their local cache. Thus, wehave developed and implemented DTVideo, a video distribution service overDTNs that make use of the BPQ extension to the Bundle Protocol to leveragecaching in the network. In this section we describe the DTVideo system in moredetail.

!"#$%&'()$

*(+,(+$-./$!"#$

012(314$

-./$

531+($

67(+$

%&'()$7)8+9($

Fig. 3: DTVideo system overview

Video Source The system needs a video source that generates the contentto be distributed. This can be a static video library, recorded versions of tvprograms, or user generated content (for a service similar to YouTube). Thisvideo source updates the list of available video programs at the video server asnew content become available.

Video Server / BPQ Request Responder The video server operates in thesame connected domain (preferrably on the same host) as the video source – inmost configurations, this would mean that the video server is connected to theInternet.

The DTN2 daemon on the video server must be aware of the BPQ extensionblock. The video server runs a program that listens for incoming requests for aspecific endpoint identifier (EID). When a request arrives, it consults its localdatabase of video content, and if a program with the requested name is available,


it is sent back to the requesting EID (with the BPQ block set to indicate thatthis is a response for that particular name).

Intermediate DTN Nodes Not all nodes in the DTN between the video sourceand the end user need to be aware of the BPQ extension. The nodes that areBPQ compatible will participate in the caching and querying of video bundles,but one of the benefits of using an extension block for BPQ is that nodes thatdoes not have this functionality can just ignore the extension block and forwardthe bundle towards its destination. Thus, not all nodes in an existing networkhave to be upgraded to deploy this, but only those where caching is believed tobe extra beneficial.

BPQ DTN Gateway The main way for users to interact with the DTVideoservice is through a web interface, run at each node that want to be able to usethe service. In the main screen of the user interface, the user can see a list ofvideo programs that are available in the system. As new programs are madeavailable at the video server, this list will be automatically updated (of coursewith some slight delay). The user interface shows if the video is just availablein the system, if it has already been requested, but the response for it is stillpending, or if is already locally available for viewing. If the video file is locallyavailable, the user can launch a video player to watch the program. If it hasn’tbeen requested yet, the user can issue a equest for that program. When the userdoes this, the software described above is launched that creates a BPQ requestand send that bundle to the video server.

5.2.5 fbDTN – Facebook over DTN

In previous DTN deployments within the N4C and SNC projects, one of themost requested services among younger users was the ability to use social net-working services such as Facebook. There has been previous work on buildingsocial networking systems specifically designed for opportunistic networks. Suchsystems have benefits in that they can make use of the local context availablethrough the contacts between mobile nodes. However, most users do not onlywant to have this social network of only people that are in the same geographicregion that make up a particular DTN – they want to be able to access thecontent of contacts from their full global social network such as Twitter orFacebook.

Therefore, we decided to design and implement fbDTN, a Facebook over DTNgateway that allows users to access the most important functions of Facebookover a DTN network. This is done using the Facebook Graph API that providesan interface for third-party applications to retrieve information from and inter-act with Facebook on behalf of a certain user. This is done in a secure manneras the API does not require the user to divulge her Facebook password to theoperator of the gateway. Our system enables users to read their news feed, poststatus updates and photos, and comment and like the posts of other people.


!"#$%!"#$

&'()*')($

+,()-,.$

%!"#$

!"#$

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

1,(,2,0)$ /0)*$

Fig. 4: fbDTN system overview

The system consists of three main parts, shown in the system overview inFigure 4: 1) A system for creating user accounts and authorizing our appli-cation to access Facebook information on behalf of that user. 2) A gatewayresiding in the DTN (the village router in the specific deployment made in thisproject). This provides a user interface to the user, sends requests for news-feed snapshots and processes the responses and sends requests to post statusupdates, photos, and comments. 3) An Internet connected Facebook gateway(the Internet gateway in the rest of the document) that is also connected to theDTN. This processes and authenticates requests coming in from the DTN andhandles interactions with the actual Facebook servers. All the DTN nodes inthe system run the DTN2 implementation of the Bundle Protocol.

Authentication and Authorization The first step in using fbDTN is to set upan account on our system in order to be able to authenticate and authorizethe user later on. A user is likely to not want to give her Facebook passwordto an operator of a gateway like this. This is not necessary as the FacebookGraph API uses the OAuth system for authentication. This allows a user toauthorize fbDTN to perform certain required actions (such as reading the user’snewsfeed and post items to her wall) on her behalf. After the user has beenauthenticated and has given this authorization, an OAuth token is issued tofbDTN that stores this in a database in a trusted server. This is the onlylocation the OAuth token is ever stored. This is more secure than for the userto have to give her Facebook password as the OAuth token can be revoked atany time for this specific application. In addition to creating this token, theuser is asked to give a new password that will be used to identify the user in thefbDTN system – this is recommended to be a different password than the user’sFacebook password. As this entire process requires interaction with Facebook’sservers in order to verify the identity of the user and to create the OAuth token,the user account must be created while Internet connectivity is still available.

Internet Gateway The Internet gateway runs a daemon that listens for in-coming bundles and processes them to see what kind of request it is. It thenconnects to the MySQL database containing the OAuth tokens and retrievesthe correct one (given that email address and password match), which is usedto perform the action requested by the user. If this action requires a response(such as a request for a newsfeed snapshot), a new bundle is created and sent


back to the node (EID) that sent the request.

DTN Gateway at Village Router The village router runs a daemon that lis-tens for incoming bundles. Currently such bundles will all contain newsfeedsnapshots, but as more functionality is added, there could be other contentcoming in. The daemon parses the incoming bundles and places the encryptednewsfeed snapshots in their appropriate locations as well as updates the neces-sary indices that the web interface need to list the available content. The userinterface is a web site powered by php scripts that allows the user to show thenewsfeed snapshots as well as sending off requests over the DTN to the Internetconnected gateway.

Fig. 5: fbDTN screenshots. Left: Main page. Right: Newsfeed snapshot.

The main user interface to the Facebook gateway is a web interface that isbeing run at the village router. An example of the web interface the user seeswhen logging in is shown in Figure 5 and the user has the following options,allowing her to access the most important functionality of Facebook:Post Status Update or PhotoThe user is able to post a “status message” to her Facebook profile by enteringthe new status message on the main page and submitting. Similarly, the usercan also choose to upload a photo to her wall, including a descriptive caption. Arequest is created and sent over the DTN to the Internet gateway that confirmsthe password, fetches the OAuth token from the database and post the requesteditem to the user’s profile.Request Newsfeed SnapshotThe most vital function for most Facebook users is the ability to read thenewsfeed that shows recent actions of your friends. fbDTN allows the userto request that a snapshot of the newsfeed is sent to the village router. Abundle with this request is sent to the Internet gateway which authenticates the

6 Evaluation and Lessons Learned 14

user, connects to Facebook and downloads the most recent entries in the user’snewsfeed (with a timestamp of when the data was fetched from Facebook). Thenumber of entries downloaded at each snapshot is configurable, and if desired,could also be given as an option to the user. This snapshot is encrypted and sentback over the DTN to the requesting user. As the feed snapshot is encrypted,only the correct user will be able to decrypt and read the feed, which is importantfor privacy.

In addition to requesting newsfeed snapshots manually, fbDTN also givesthe option to “subscribe” to newsfeed snapshots. With this option, the Internetgateway will periodically generate newsfeed snapshots and send to the user.Thus, the user can get updated versions of the newsfeed without explicitlyhaving to request it.View Newsfeed SnapshotsIf some newsfeed snapshots have already been requested and delivered, theywill be listed at the bottom of the page with the timestamp of when they wereretrieved from Facebook. Clicking a newsfeed snapshot decrypts it and shows itto the user. This interface shows the posts available in this snapshot, includingwho posted them, any comments that have been made to the posts, and a list ofwho “likes” a certain post. The user is here given the option to post a commenton any of the posts or to “like” a post. If the user wants to do so, the process ofpublishing that comment or like is similar for that of posting a status update.

6 Evaluation and Lessons Learned

In this section, we will discuss our experiences from the project. We will high-light the features of the system and deployment that worked well as well asthose that had problems. We consider which lessons we can learn from thisexperience and how future deployments can be improved

Since TCD was one of the partners of the N4C project, the TN/TCD peoplealready had good experience in building real-life DTN systems. For the SICSresearchers, it was however very beneficial to get some additional hands-onexperience from building and deploying the system.

6.1 Software

One novelty of the system in this year’s deployment over previous years wasthe DTVideo system for distributing video programs in the network, whichalso works as a test case for seeing how the BPQ extension to the BundleProtocol works with bringing the concepts of DTN and ICN together. Duringthe deployment period, video content was correctly generated at the video serverand the list of available programs was updated at the remote devices that weredeployed in Skuolla. Using the system in a lab environment, we were able toconfirm that the BPQ concept works and that content is cached in the networkso that subsequent request for the same content does not have to traverse theentire network back to the source but can be served locally instead. In the real


deployment we did however encounter some problems with the distribution ofthe bundles containing video content. The system worked correctly and bothrequests and responses were sent accordingly, but since the video bundles areof large size, there was a problem with transmitting them over the GPRS linkthat was available to connect our system to the Internet. This caused lots offragmentation of bundles and subsequent delivery problems. In Section 6.4, wediscuss some possibilities for improving this in future deployments.

The decision to build a gateway for allowing users to access Facebook overthe DTN system turned out to be a great success. Out of the applications thatwe provided to the users, the fbDTN gateway was by far the most popular onethat brought new interested users to our system. The users were delighted thatthey were able to read their newsfeed and post updates and photos about whatthey were doing for their friends in other places to see.

6.2 Networking

As mentioned in the previous section, we ran into problems for the DTVideo sys-tem when large video bundles were fragmented due to a bad GPRS link. Whilefragmentation is usually not desirable, it shouldn’t have to affect performanceas much as it did in this case. This is due to the fact that the DTN2 implemen-tation of the Bundle Protocol that we use does not handle fragmentation verywell. For future deployments, it might be worthwhile looking into possibilitiesto improve the fragmentation handling of the Bundle Protocol implementationused.

We had decided to use the DTLSR routing protocol to get bundles totheir correct destinations in the network. While this had worked in the pre-deployment tests, it seems that DTLSR is not really suitable for this type ofsystem as it requires to much global state to be maintained. Once the prob-lems with DTLSR had been identified, we were able to set up static routing inthe system to solve this problems and ensure that bundles would be deliveredproperly so that the system could operate correctly. Static routing is howeverobviously not optimal either as it lacks flexibility if the network configurationchanges (which becomes a greater problem as the network grows in size). An-other problem that we noticed with the routing stems from the fact that therewas two different disjoint paths that bundles could take from the village routerin Skuolla to the Internet gateway in Dublin - either through the GSM relay onthe top of the hill or via a data mule on a helicopter to the GSM relay in Ritsem.As at most one copy of each bundle is simultaenously present in the network,this causes a performance problem if transmission of the bundle is started alongone of those paths (so that it is no longer present at the village router) and thenthe second path becomes available (that might have provided a better way ofdelivering the bundle), but cannot be used as the bundle is already in transitover the other link. We see a need for a routing protocol that allows for limitedreplication of bundles when that can improve performance. If such a protocolis used, it is also important that the protocol has a way of purging the replicasfrom the network once one copy is delivered in order to avoid wasting system re-


sources. It would be interesting to test a routing protocols such as PRoPHETv2or something similar (that includes replication and ACKs to remove deliveredbundles from queues in the network) to see how that would perform in thissystem.

6.3 Environmental Issues

One problem that we ran into that was hard to counteract was the weather.During a large portion of the deployment, there was rather inclement weatherin the Skuolla area. This caused two problems for the project.

First of all, as our equipment is solar powered, we ran into power issuesand some units ran out of battery power. We did have a diesel generator thatwe could use as a backup to charge batteries (but that required carrying thebatteries up and down the hill for charging). As the weather in the area can notbe expected to be very reliable, we are considering alternative solutions to thisproblem. One such solution could include the use of wind power (in particularat the location on the top of the hill as that location was very windy).

Secondly, the bad weather also had an adverse effect on the potential usersof the system. When it is raining, people tend to focus on their work, and spendmost of their free time in their own tents. On the other hand, when the weatheris nice, people are more likely to socialize and visit other people in their tents,and thus more people would also have been likely to visit our Internet cafe.

6.4 Ideas for future deployments

While we are happy with the outcome of this project, we still envision potentialimprovements that could be done to the system. Thus, we hope to be ableto continue the development of the system developed in this project and dosubsequent deployments to test it again.

In the future, we hope to be able to further work on the combination ofDTN and ICN technologies. A few first steps in that direction involves usingthe ni:// naming scheme that is currently being developed for naming thecontent objects in the network. This would allow our system to interoperatewith other ICN networks that use the same naming scheme. We are also lookinginto the possibilities of interfacing the different components of our system to amodular router for ICNs that is currently being developed by NEC to make iteasier to add new components and also reuse components created by others.

To increase the effective bandwidth and make it easier to transfer large-sizebundles (to get around the problem of bundle fragmentation), we want to havedata mules on the daily bus that goes between the helicopter landing pointin Ritsem and the city of Gallivare, where a reliable high-bandwidth Internetconnection is available. This would allow large-size bundles to be sent over thisroute and be quickly downloaded (or uploaded) at the well-connected point, andthen transferred by the bus the rest of the way. This will of course also requirea routing protocol that can select different paths for bundles of different size

7 Appendices 17

(and/or priority), as the use of the GPRS link is likely still more efficient forsmaller bundles.

With the Facebook over DTN gateway, we showed how it is possible to usethe public API of such a service to go from something that is highly interactiveand dynamic to something that provides most of the desired service, but canstill be supported over a DTN. This work can however still considered to beat an early stage, as there is some functionality that is offered by the “real”Facebook that is not supported by our system. We plan to extend this gatewayby adding more of the functionality offered by Facebook. Among the moreimportant additions that we plan to do soon are the ability to read and senddirect messages. As there are similar public APIs for the social networkingservices Twitter and Google+, we are also considering integrating support forthose platforms into our system.

7 Appendices

• Appendix A: Poster fbDTN

• Appendix B: User guide

References

[1] S. Farrell, A. Lynch, D. Kutscher, and A. Lindgren. Bundle protocol queryextension block. Technical Report draft-farrell-dtnrg-bpq-00, IRTF, Nov.2010.

[2] K. L. Scott and S. Burleigh. Bundle protocol specification. Technical ReportRFC5050, IRTF, Nov. 2007.

final report, skuolla internet caf e

Documents