«• NITOS aims to provide a Video Framework to support: • Monitoring and capturing real time video streams • QoS for video streaming in ...»
The user submits his experiment to OMF.
OMF configures the testbed and begins the
OMF collects the experiment results in a database.
All of the wireless nodes are equipped
with Logitech C120 USB web-cameras.
• NITOS aims to provide a Video Framework to support:
• Monitoring and capturing real time video streams
• QoS for video streaming in wireless networks
• Cooperation protocol for reliable multicast video streams • Easily configuration of coding/decoding transmitted frames One-to-one wireless video transmission in a multi-hop environment (one video transmitter, remote video player) One-to-many wireless video transmission in a multi-hop environment (one video broadcasting transmitter, multiple receiversplayers) Many-to-one wireless video transmission… (multiple video transmitters, one receiverserver) Develop cooperative scenarios (enable relays) Change the access mechanism (and generate scenarios that are not based on contention, e.g.
synchronized transmission among neighbors in the broadcasting – cooperative mode) Filter the packets in any of the relays (forward part of the video, based on the video coding) Develop application layer FEC Each node of NITOS is equipped with a Temperature & Humidity USB Sensor THUM (Temperature and Humidity Monitor) NITOS provides its users with the ability to run experiments using the temperature and humidity sensors (online) or even access real sensor records by using the NITOS Sensors Toolkit (offline).
The filesystem provided for sensor experiments contains scripts that help the user easily setup an experiment, just by providing the reserved sensor IDs, the measurement period and the total number of measurements that will be recorded.
Moreover, each user can use OMF to transfer the measurements taken during his reservation period to the NITOS measurements database for posterior processing.
Using the Sensors Toolkit the user can get a graphical representation of each measurement set stored in NITOS database.
Various statistical measures are extracted from the corresponding records, such as average humidity and temperature values per sensor or per measurement round.
One important feature that the toolkit provides is the correlation matrix tool that provides an indication of how much the measurements of each sensor is correlated with each other.
Currently we are experimenting with the integration of the spatial
correlation among the sensors in the:
• Channel access mechanism of sensor networks.
• In-network Data Aggregation schemes
in order to reduce:
• levels of contention • redundant data transmissions • overall energy consumption We have developed power metering scheme that give us energy measurements of a building We develop a software framework that will let us store the power consumption data in a local database and depict in graphs any consumption period selected by the user In the facilities of CERTH in Volos we have installed a CurrentCost Power Meter, which is used to measure total energy consumption.
The receiver is connected via USB to a PC.
The PC sends, through the internet, the power meter data to the cloud service of Google Powermeter.
USB Internet The data collected in the cloud can then be seen on a web browser or a smartphone.
The whole framework is based on Open Source software We use Ruby language to receive and parse the consumption data from the power metering devices MySQL is used in order to store the data locally without the need of web power metering storage services We have also developed ZigBee plugs and switches in order to be able to measure separately the consumption of electric appliances in a building At the same time we are building a framework in order to be able to remotely switch ON and OFF any electric appliance Presence sensors will be in charge of automatically switching off any electric appliance that could be forgotten ON.
These plugs are inserted between wall plugs and appliances.
They can be scheduled to turn off during a chosen period of time or if the consumption is below a pre-specified threshold to save standby energy consumption Implementing wireless MAC protocols using open source drivers (Intro)
‘C’ – Pointers, Functions, Structures • Recompiling the Linux Kernel • Tools – Make, Iwconfig, Wlanconfig •
Network Drivers The basic functions used in these drivers involve • transmission, reception, rate adaptation etc..
Implementing wireless MAC protocols using open source drivers Some basic commands Iwconfig – to list the various network • interface available Wlanconfig – Create or Destroy a wifi • interface Implementing wireless MAC protocols using open source drivers What are the rules ?
Device driver, unlike other c programs does • not have function calls such as main() What ? How do I execute my code then ?
• Similar to main module, driver has two • modules one to initialize the driver, another to destroy it.
Many times the kernel calls certain functions • when it needs to do some specific tasks Implementing wireless MAC protocols using open source drivers Suppose I want to send a ping from A to B • I can send it by WiFi, LAN or Bluetooth. I • choose to send it by WiFi Kernel is main(), it says I will call function • hardstart_xmit() only.
Driver, typecasts this request to point to one • of its function inside using function pointers.
Figure below explains this • Implementing wireless MAC protocols using open source drivers
How do I go about debugging the code ?
• Usually, in normal ‘c’, I use printf to print • variable to find out what actually happens.
Okie.. Rule here is use printk() instead of • printf().
It is the same syntax, just the driver • equivalent of printf.
Implementing wireless MAC protocols using open source drivers Say with network driver, we recognize as • many functions as possible and begin exploring them Any network driver should send and receive • data. So in driver, there are specific functions defined to do that. Say if I want to modify one of them. Just limit yourself there Same way specialized functions are • dedicated to setting configs etc… In driver focus on function of your interest • and forget the rest of the code Implementing wireless MAC protocols using open source drivers • Just to mention, main() module in the driver has the name module_init(). It is also similar to constructor in c++.
• Same way module_exit() is the destructor • Kernel calls these functions automatically in order to load and delete a module from main memory • Often these functions have information on what all to initialize when the driver gets started and what all to delete when the driver gets unloaded Implementing wireless MAC protocols using open source drivers • Generally functions in the device driver have some arguments which are data buffer coming from the upper layers • These upper layer buffer are filled with information such as TCP/IP packet field,data fields in case of networking • Once these functions get over they give back the control to the kernel. Often these functions return some return types informing about the status of the transmitted message Implementing wireless MAC protocols using open source drivers Loading and unloading the driver Loading and unloading driver into kernel is a • sequence of procedures that has to be followed by every driver Kernel defines certain function calls that • could be used to sophisticate this process When the driver gets loaded, it has to • allocate some memory space for itself to exist within the kernel Thus the driver has to request for this space • from the kernel.
Implementing wireless MAC protocols using open source drivers Implementing wireless MAC protocols using open source drivers What exactly happens when I use internet with my WiFi device ?
Request to deliver packets arrives from the • upper layer, user send this.
This packet is then fragmented into smaller • chunks each of size specified by the fragment value This is then encapsulated with TCP/IP • information by the network layer Kernel appends this packet with Ethernet • information, namely source, destination and packet type as obtained by the ARP table Implementing wireless MAC protocols using open source drivers What exactly happens when I use internet with my WiFi device ?
Till this point, this packet is only a Ethernet • packet that can be send over by wire to a hub, however, it is being forwarded to the wifi interface This is obtained by the wifi driver, which • converts these Ethernet packets to WiFi packets as specified by the IEEE standards All through this process, Sk_buff is used by • the kernel to keep track of the packet headers Implementing wireless MAC protocols using open source drivers Packet Transmission What is a Skb ?
• Skb, popularly called as sk_buff, is the • kernel buffer which stores information of each packet like its data,TCP HEADER,IP HEADER etc..
This header is transferred from the upper • layer through every layer in the OSI Model of the linux kernel In each layer, it will be appended with that • layer header and sent to the layer below it Implementing wireless MAC protocols using open source drivers Packet Transmission (Contd.) With the new MAC header of type 802.11 • the packet is ready to be sent out Normally what follows is a device specific • function such as ath_tx_start() in case of Atheros drivers This function is responsible for setting the • transmission rates of the packets which are sent out.
Implementing wireless MAC protocols using open source drivers Packet Transmission (Contd.) This function also decides on the QoS of the • packet based on various flags set by the user Power control is being defined here • Specialized functions to compute ICV lengths, • encrypting the payload etc.. are defined and called within this function With these procedures, packet is placed in the • queue and a transmit interrupt is raised Implementing wireless MAC protocols using open source drivers Packet Reception Ah.. The packet is in air. How do I capture it • with other computer This could be a little trickier than transmission, • because of the fact that one needs to allocate memory space in the kernel to copy this information and send it to the upper layer Reception of packet is generally interrupt driven, • though there are cases when polling may be used.
Implementing wireless MAC protocols using open source drivers Packet Reception(Contd.) Often the hardware, when it receives a packet, • checks to see if the packet is addressed to itself of if the packet is broadcast.
If yes, it raises a interrupt to the driver.
• It may be noted that, in promiscuous mode, • device accepts all packets Driver executes the appropriate interrupt • handler routine, which calls the receive function Implementing wireless MAC protocols using open source drivers Packet Reception(Contd.) Receive function does the work of ripping • the packet header and passing this packet to the upper layer This function is also responsible for • recording the statistics information about the packets received Every packet entering this function goes • through a series of check for validating the packet Implementing wireless MAC protocols using open source drivers Packet Reception(Contd.) When this is called the 802.11 stack input • function which removes the MAC header of the packet and substitutes with a Ethernet header This packet is further check for a valid • sequence number to identify if these packets are duplicate packets Duplicate packets are discarded as these are • noting but mere retries of the same packet Implementing wireless MAC protocols using open source drivers The LOG-BOOK Like every operation, network drivers also • record history of the packets transmitted for 2 reasons This is definitely a source of information to the • user on how many packets where sent.
On the other hand, this information is very much • useful in the rate adaptation algorithm that will be used in the driver for adjusting the rate Struct by name net_device_stats contains fields • that can count the number of packets received, packet byte length etc..
References http://www.ibm.com/ developerworks/library/l-linux-kernel/ index.html?ca=dnw-827 Network drivers ( O'reilly Publications), chapter 17
INTRODUCTIONTO OMF AND OML
University of Thessaly and Polytechnic Ins7tute of NYU Overview • OMF stands
cOntrol and Management Framework • It is a soGware framework dedicated
– The eﬃcient management of testbed resources by the testbed administrators – Providing a clear and easy way for an experimenter to deﬁne an experiment, execute it and collect its results • Ini7ally developed at Winlab, Rutgers to run the ORBIT wireless testbed • Currently, NICTA (Sydney) is responsible for maintaining and further developing OMF, with help and contribu7ons from others (Winlab, Nitlab, …) OMF Overview Architecture – Components (I) • Aggregate Manager (AM):
manages an aggregate of resources, providing services such
– Reboo7ng resources, turning them on/oﬀ – Providing a list of resources – Adding/removing resources – Installing soGware images on resources – Providing access to measurements stored in experiment databases Architecture – Components (II) • Experiment Controller (EC):