Using Kansei - Basics

1. Overview
2. Creating a Login

3. Creating executables

   3.1 XSM platform files
    3.2 Enabling programs to log data
    3.3 Writing Stargate programs that listen to motes
4. Creating a Slice

1. Overview

Kansei provides a testbed infrastructure to conduct experiments with Extreme Scale Motes (XSMs), Stargates, TelosBs and iMote2s. The current topology of the components are as follows:

• 96 Extreme Scale Stargates (XSS) in a 12 X 8 topology with uniform separation of 4ft.The stargates are connected using both wired and wireless Ethernet.The wired Ethernet is used to program all the components in the testbed from a central server.
• 96 Extreme Scale Motes (XSM) hooked individually onto the 96 Extreme Scale Stargates (XSS) in a 12 X 8 topology with uniform separation of 4ft. (At max power level all nodes are reachable)  
• 384 TelosBs arranged in a topology of  24 X 16 with 2 feet uniform separation. The telosBs have a 3db attenuator attached to their antennas. With the attenuator at the lowest (legal) power level for the CC2420 radio, the reliable range is 3 feet (i.e 1 hop) and at the highest power level the range covers the entire testbed (i.e all 384 nodes are reachable).  
• 96 Intel imote2s arranged in a 12 X 8 topology (currently under deployment) with 4 feet uniform separation. 

The Kansei project is headed by Anish Arora

To schedule an experiment on the testbed, one has to do the following:

• Upload the executables for the sensor nodes/Stargates to Kansei
• Create a slice which will represent the research throughout the experiment life cycle
• Create a experiment resource specification that specifies which set of sensor motes/Stargates on which the experiment is to be run on
• Configure the slice by specifing which executable should be run on which array as well as the time-span to run the experiment
• Start the experiment using the Dash Board and get the results after the experiment is completed using the Dash Board

Access to the Kansei testbed is provided free of cost for the betterment of the research community. Hence in order for the best usage of the resources, do not schedule long experiments unless absolutely necessary. Also if you are a first time user or if you are running a particular experiment for the first time, start with a small set of nodes and move to a bigger set once you are getting the results you expected.

We also expect the users to site the testbed, if they use the data gerenated from Kansei for any publication.

2. Creating a Login

To start using Kansei, you will first need to create a login by sending an email containing your information to Mukundan Sridharan. When you login into the Kansei Testbed Web-interface, you will be first taken to the testbed status page. The "Testbed Status" tab/page displays experiments that have completed recently, currently running or scheduled to run in future. For experiments that are completed there is a link to retrieve experiment output and the logs.

3. Creating executable files

Kansei is designed to be platfrom independent, i.e., Kansei can program its sensor motes with executables/programs created by any platform for that particular hardware. However in order to provide logging and data injection features we need to be Kansei needs to be aware of there platforms. Currently, Kansei supports TinyOs-1.x on XSMs. On TelosB motes we support TinyOs-1.x, TinyOs-2.x and Contiki (support limited, please contant administrator). Stargates are arm-linux platforms and can run any standard arm-executables and shell/perl scripts. Stargates can also execute Emstar based applications. To compile executables for XSM, use the following procedure.

3.1 Creating an executable for XSM:

If $tinyos-dir is your tinyOSdirectory

1. cd $tinyos-dir/tos/platform

2. download platform_xsm.tgz in this directory and extract it

3. cd $tinyos-dir/tos/sensorboard

4. download sensorboard_xsm.tgz in this directory and extract it

5. cd $tinyos-dir/tools/make

6. download xsm.target in this directory

Your should be able to compile for the 'xsm' target now.

3.2 Enabling Data Logging:

If you are running a XSM or a TelosB experiment the kansei automatically starts a serial forwarder 'asfd' process to log the packets sent over the Uart by the XSM or the Telos application. The asfd runs on port 9001 for the XSM experiment and runs on port 9 (eg., if mote ID is 101, it runs on port 9101) for the Telos experiment. Writing packets to the UART in the tinyos program, will log the data on the Stargate. The data that is logged from each XSM/telos is zipped and available for retrieval at the end of the experiment. Ensure that data is actually being sent on the serial port by testing locally using a PC/Stargate connected to a mote before uploading the file on to Kansei.

>3.3 Writing Stargate programs that "listen" to motes;

If you are running a Stargate application along with the mote application, you can connect to the 'asfd' process on the appropriate port to get the packets online. For a sample program on how to connect to the asfd process look at the 'sflisten' application under the tools/src/sf directory under your TinyOS installation. 

4. Creating a Slice

A slice is the logical representative of a user in the GENI context. A user, defined by the login username can be assositated multiple slices. The concept of slice is used throughout the scheduling, monitoring, and result retrieval process of an experiment. Before one can schedule an experiment in our testbed, one has to create a slice that will carry the authentication and authorization attributes of the user. A researcher creates a slice here. From this point on, the notion of a researcher/user will be substituted by slice she have just created.

5.Scheduling Experiments

Now that we have compiled the executables for the experiment, it's time to upload the file, create a experiment resource specification, and configure the slice. Follow

• If the executables to be used are the same as an previous experiment, one can skip step 5.1 Uploading files to Kansei.
• If the set of motes to use is the same as an previous experiment, one can skip step 5.2 Creating a experiment resource specification.
• Otherwise, please follow the two steps.

5.1 Uploading files to Kansei:

1. XSM executable: This is the .srec file resulting from compiling using TinyOS and is used for programming the XSM.
2. TelosB executable: This is the .exe file resulting from compiling using TinyOS and is used for programming the TelosB.
3. Binary file: This file runs on the tier-2 Stargate device. This file can be arm-stargate executable, a shell script or perl script.
4. Tier 3 PC executable: These files meant to be run on tier-3 pc. These files can be any standard Linux X86 executable or script.
5. Support Files: These are just any files that are needed by your uploaded apps, and are uploaded along with the apps.

At the bottom of the page is a form for uploading your file. After you upload your file, you should now see the file displayed on the files page.

5.2 Creating an experiment resource specification:

5.3 Configuring the experiment:

• First choose an experiment resource specification, whch determines the set of nodes to be configured
• Select the date and start time for the experiment execution (you may want to check the status page to make sure there are no overlaps with other experiments). 
• Enter your name and contact information in the name field and a helpful description of the experiment For example, "this is a XSM only experiment with no radio messages" OR "this is a xsm radio application using frequency 431MHz".
• Select experiment parameters such as how long you want the experiment to execute, which group of nodes you want it to execute on. 
• Select the XSM/Telos/Stargate executable from the drop down menu that you just uploaded. Leave the Erase XSM/Telos on upload box checked.
• You would typically need to check the set XSM ids box. This assigns unique ids to the XSMs. The current scheme for addressing assigns the id of the stargate to the XSM (eg. a XSM attached to stargate 50 will be programmed with id 50) The only exception is to add an offset to the node ids. This is to enable certain special conditions, e.g. base stations have (id > 1000) so now you can create a separate experiment for base station nodes with offset 1000.

• If your stargate or tier 3 experiment creates any output files other than the default output files (namely datalog.txt), you need to enter them under the retrieve text box. It should be a list delimited semicolon.

5.4 Starting,Stopping and Retriving experiment data using Dash Board:

6. Kansei execution and policies/semantics:

Currently, Kansei scheduling does not enforce any priorities among users so experiments are scheduled on a first-come-first-served basis. XSMs and TelosBs are only capable of running one experiment at a time at the moment. Users scheduling experiments with conflicting time will receive warning during the scheduling process and the experiment won't be scheduled.

We also ask that users test their programs locally for obvious bugs before uploading them to Kansei. If the program is expected to log data, users should make sure that data is being written on UART by testing locally before uploading to Kansei.

7. Health Monitor

This page reports on the health status of the nodes in the test bed. It displays the statistics for number of Stargates down over the last 24 hours and over the last month. It also displays a list of Stargates that down in the last scan. If these Stargates are part of a group, which is used for scheduling experiments, then these Stargates will be skipped while scheduling, but the experiments themselves will be scheduled. So it is important that you check this page before you create your group or schedule experiments.

8. Bugs

For a list of known bugs and for submitting new bugs click here

9. Support

Support is provided via an email group. Click here for more details