This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
activities [2017/10/26 10:20] mustafaelnainay |
activities [2017/10/26 10:28] (current) mustafaelnainay |
||
---|---|---|---|
Line 22: | Line 22: | ||
stages of the project. | stages of the project. | ||
+ | ---- | ||
==== CRC Hardware ==== | ==== CRC Hardware ==== | ||
=== Nodes === | === Nodes === | ||
Line 51: | Line 52: | ||
exposure to the newly learned concepts. | exposure to the newly learned concepts. | ||
+ | ---- | ||
==== CRC Software ==== | ==== CRC Software ==== | ||
Line 88: | Line 90: | ||
- | ===== Building small scale ORBIT testbed replica using ORBIT software modules ===== | + | ===== CRC Phase I Novel Features ===== |
+ | ==== Isolated Multiple Concurrent Users ==== | ||
+ | One of the new features in CRC is its ability to have multiple concurrent users access its resources while | ||
+ | guaranteeing no interference. Other testbeds, e.g. [[http://www.orbit-lab.org/|ORBIT]], give exclusive access to a group of their nodes to a single user regardless of his needs. NITOS enables simultaneous users but relies on the | ||
+ | integrity of users to commit to their reserved frequencies. To be capable to accommodate concurrent | ||
+ | users two challenges exist: the first is limiting each user to his reserved nodes and preventing him from | ||
+ | unauthorized access either by mistake or deliberately. The second challenge is to enforce frequency | ||
+ | assignments. As the wireless medium, unlike wired, is of broadcast nature, two users conducting | ||
+ | experiments on the same frequency can compromise the integrity of each other’s work. Thus, ensuring | ||
+ | that users work on their allocated band is important. NITOS handles only the first challenge. CRC, on | ||
+ | the other hand, handles both challenges, making it truly support concurrent experimentation by different | ||
+ | users. | ||
- | ==== Short Description ==== | + | ==== Enforcing Frequency Assignment ==== |
+ | Each user while reserving nodes is required to reserve frequencies. Confining each user to his reserved | ||
+ | spectrum can be done by monitoring for frequency violations. Once a violation is detected, the offending | ||
+ | user can be forced out of the testbed and perhaps have his account suspended. The approach we took | ||
+ | at CRC to detect such violations is a software based approach. | ||
+ | Three wireless interfaces exist currently at CRC; USRP, RTL-SDR, and WiFi. The RTL-SDR is a | ||
+ | receiver only, so, it does not cause interference. The WiFi standard enables multiple users to share | ||
+ | the same channel and monitoring its frequency usage can be performed through the operating system. | ||
+ | This makes the major source for interference is the USRP, which will be our focus when dealing with | ||
+ | frequency isolation. The USRP available at CRC communicates with the virtual machines through USB | ||
+ | using packets with a predefined structure. By sniffing these packets from the physical nodes, we can | ||
+ | tell what frequency band is being used and hence detect violations. | ||
- | ==== Resources ==== | + | ==== Testbed Nodes Virtualization ==== |
- | [[https://drive.google.com/open?id=0B0-0d_WzArTUZHQ2RDIweDRjNW8&authuser=0]] | + | Virtualization of nodes is common in wired testbeds and has been used to extend the scale of experiments |
+ | in wired networks, e.g. in [[https://www.emulab.net/|Emulab]]. None of the existing wireless testbeds uses node virtualization. | ||
+ | The smallest unit to be reserved in these testbeds is the physical node. This is explained by | ||
+ | the following; in wired networks, virtualization of network resources like interfaces and links is possible | ||
+ | without jeopardizing integrity of results due to the controlled nature of wires. In wireless communication, | ||
+ | although some work has been done on the virtualization of WiFi, reliable virtualization of SDR | ||
+ | peripherals, which are physical layer devices, is difficult. At CRC, testbed nodes are virtualized based | ||
+ | on interfaces; each physical node runs three virtual machines and each virtual machine is assigned one of the three interfaces. Hence, this setup allows multiple simultaneous users, who need different | ||
+ | interfaces, to use the same physical machine. | ||
+ | ==== Topology Control using Gains ==== | ||
+ | Some wireless experiments depend on the existence of a specified topology between the nodes. For | ||
+ | example, some cognitive radio scenarios require certain connectivity between the nodes. Changing the | ||
+ | transmitter power and the amplification at the receiver by changing the transmit and receive gains of | ||
+ | the nodes can be used to realize a given topology. Selecting suitable nodes and finding suitable values | ||
+ | for the gains using trial and error is a time consuming process. In CRC, we developed a system, that | ||
+ | given a desired topology, will find values of the transmit and receive gains for the nodes to achieve the | ||
+ | desired topology. | ||
- | ---- | + | ==== Storage Efficient Disk Imaging System ==== |
+ | The users’ images are always derived from the base image provided by the administrators of CRC | ||
+ | which is stored on the server. Users may perform some changes on the image and then save it back | ||
+ | to the storage server using [[https://www.cs.utah.edu/flux/papers/frisbee-usenix03-base.html|Frisbee]]. The drawback of Frisbee is that it stores the entire disk image | ||
+ | which leads to having duplicate data. To avoid this, we use a proven data duplication software which | ||
+ | is [[https://www.usenix.org/legacy/events/fast02/quinlan/quinlan_html/|Venti archival storage system]]. Venti is a block level storage system, it identifies duplicate blocks | ||
+ | and avoids data duplication. Our work was on the integration of Venti and Frisbee to get the benefits of | ||
+ | both; Venti avoids duplication, while Frisbee enables fast and scalable image transfer. | ||
- | |||
- | |||
- | ===== Studying the Software Defined Networking and possibilities to integrate into CRC testbed ===== | ||
- | |||
- | ==== Short Description ==== | ||
- | A document describing how to include SDN in the CRC testbed and possible research directions. | ||
- | ==== Team ==== | ||
- | |||
- | |||
- | ==== Resources ==== | ||
- | [[https://drive.google.com/open?id=0B0-0d_WzArTUQnpCcDRaQUNMb2M&authuser=0]] | ||
---- | ---- | ||
- | ===== Survey portals of other testbeds and plan CRC portal ===== | ||
- | |||
- | ==== Short Description ==== | ||
- | |||
- | ==== Team ==== | ||
- | |||
- | ==== Resources ==== | ||
- | |||
- | ---- | ||
- | |||
- | |||
- | |||
- | ===== Study the interference model of the SmartCI research building ===== | ||
- | |||
- | ==== Short Description ==== | ||
- | |||
- | ==== Team ==== | ||
- | |||
- | ==== Resources ==== | ||
- | |||
- | ---- | ||
- | |||
- | |||
- | |||
- | ===== Study the suitable testbed nodes positions inside the research building ===== | ||
- | |||
- | ==== Short Description ==== | ||
- | |||
- | ==== Team ==== | ||
- | |||
- | ==== Resources ==== | ||
- | |||
- | ---- | ||
- | |||
- | |||
- | |||
- | ===== How to use flack in GENI experimentation ===== | ||
- | |||
- | ==== Short Description ==== | ||
- | An introductory presentation to the GENI testbed, and how to use the flack software in setting an experiment | ||
- | |||
- | ==== Team ==== | ||
- | |||
- | ==== Resources ==== | ||
- | About GENI testbed | ||
- | https://drive.google.com/open?id=0B5q_HJKGbI38aDZCaFJNOC1MZnM&authuser=1 | ||
- | |||
- | Using Flack | ||
- | https://drive.google.com/open?id=0B5q_HJKGbI38TGtiWmM5UWN1Z0k&authuser=1 |