SensorNet Simulation Assignments by wh69
From Ece
- Return to the assignments submission page or the Sensor Networks homepage.
Contents |
Simulation 1
Simulation task located here.
SimPy and Discrete-Event Simulation A
Given the resulting data, the best allocation of resources is between 6-14 aisles. The number of active aisles will vary depending on peak periods during the day, but to provide minimal wait times while maintaining a low cost overhead for cashiers, 6 aisles open would be the optimal minimum during non-peak hours. Going below 6 aisles introduces the risk of long wait times for customers.
Simulation file: MarketA_wh69.py
Data results: marketA_wh69_results.tar.gz
SimPy and Discrete-Event Simulation B
After looking at the raw data, minimal wait time assuming a fixed cost on cashiers occurs when approximately 20% of active aisles are express aisles with an item limit of 15 items. This figure is a rough estimation based upon the dataset, meaning I have some missing data that I did not see until 16 hours later after the simulation finished.
Provided we go with our previous recommendations of 6-14 aisles to be active at various times of the day, 20% at the high end of the range will give 3 active express aisles, which will cut down on average wait times. So with this figure, the recommendation of 1-3 express aisles should be utilized to relieve some of the longer wait times.
One item I need to mention when looking at the CSV data files, the data order is number of total aisles, number of express aisles, express aisle item limit, average number of items, average wait time per 8 runs, and maximum wait time per 8 runs.
Simulation file: MarketB_wh69.py
Data results: marketB_wh69_results.tar.gz
Sensor Network Simulation 0
Example execution:
python simulation.py 1000 +hw0_wh69
In order to achieve an average of 5-8 neighbor, an area size of 300x300 was used for the simulation parameters. Adjusting node size by an order of magnitude did not increase the probability of every node having 5-8 neighbors, so I do not know how much that variable needs to be tweaked in order to see a significant change in the simulation results.
Simulation file(s): programs.py simulator.py
Data results: snetsim0_wh69_results.tar.gz
Simulation 2
Simulation task located here.
Simulation file(s): programs.py simulator.py
Sensor Network Simulation 2A
Example execution:
python simulation.py 500 hw2a_wh69 > hw2a_wh69.txt
Data results: sim2a_results.tar.gz
Sensor Network Simulation 2B
Example execution:
python simulation.py 500 hw2b_wh69 > hw2b_wh69.txt
Results:
Originating node: 61
Most distant node: 480
Program arrival: t=231.0 timesteps
Hops: 46
Path: [61, 39, 63, 86, 64, 41, 19, 43, 44, 67, 66, 88, 112, 113, 114, 137, 136, 159, 160, 184, 207, 206,
205, 227, 249, 250, 272, 273, 296, 297, 298, 276, 299, 321, 343, 367, 390, 413, 414, 437, 459,
482, 458, 436, 435, 457]
Data results: sim2b_results.tar.gz
Sensor Network Simulation 2C
Example execution:
python simulation.py 500 hw2c_wh69 > hw2c_wh69.txt
Please note that within programs.py, a declaration is made to have hw2c_wh69 automatically start the program on two distinct nodes. Declaring hw2c_wh69 twice on the command line is not necessary because of this modification within programs.py
From the results, the program originated on nodes 61 and 155.
Originating node: 61 Most distant node: 49 Program arrival: t=173.0 timesteps Hops: 26 Path: [61, 60, 59, 83, 84, 85, 62, 40, 41, 39, 15, 37, 36, 12, 11, 10, 9, 31, 7, 6, 5, 4, 3, 2, 26, 50]
Originating node: 155
Most distant node: 415
Program arrival: t=221.0 timesteps
Hops: 40
Path: [155, 178, 201, 224, 247, 270, 248, 271, 294, 316, 340, 339, 361, 337, 336, 359, 335, 357, 379, 402,
425, 401, 377, 400, 399, 423, 445, 468, 467, 466, 465, 489, 488, 487, 464, 463, 485, 484, 461, 438]
Data results: sim2c_results.tar.gz
Sensor Network Simulation 2D
Example execution:
python simulation.py 500 hw2d_wh69 > hw2d_wh69.txt
The sleep delay for this program is chosen at random using the random.randint() method with a range of [1,20]. By varying the sleep delay in this manner, the communication graph dramatically changed compared to the graph generated in Sensor Network Simulation 2A. The output from the terminal window verified that the program spread to every node with the modified sleep delay.
Data results: sim2d_results.tar.gz
Simulation 3
Simulation task located here.
Simulation file(s): programs.py simulator.py
General Background
Geographic Hash Table (GHT) is a data-centric storage system designed for sensor networks. The premise of GHT is to provide a distributed storage system across the nodes in a sensor network and querying data by geographic location only interpreted from the hash of the query.
When a node requests some data, it will send a properly formed query using a modified version of GPSR. The original version of GPSR requires that a packet knows a specific node location for its eventual destination. GHT removes that restriction, so the packet routes to some empty space where an event occurred. Once a packet reaches close to that empty space using the greedy portion of GPSR, the protocol will switch to perimeter mode that will forward packets around the perimeter of the desired space until the node closest to the space is found, or the packet has traversed a cycle around the perimeter.
Implementation
My general thoughts on implementing the GHT protocol is a two-fold task. Task one is to translate query -> hash -> geographic coordiates. Task two is to implement the GPSR protocol to route the packet to the destination. For the first task, SHA-1 is chosen for the hash function for my implementation. SHA-1 was chosen because it is available in python's hashlib, and I am familiar with it.
My plan for implementation is to work on two different coordinate planes: physical location plane and hash plane. The physical location plane is your typical (x, y) coordinates that can be extracted from a Node's public attributes in the simulator. The hash coordinate plane is used for the query, and the coordinates are determined by the first 4 bytes of the hashed query. Eventually, the 4 bytes translate into (x, y) coordinates on the hash plane by using the first 2 bytes as the x-value and the last 2 bytes as the y-value.
Node neighbors are determined by the physical coordinate plane, but packet routing with GPSR uses the hash coordinate plane. In order to determine which node neighbor to forward the packet, node neighbors physical location translate into a hash coordinate plane by hashing the physical locations and performing the same interpretation as above. This thought of using two separate planes has some consequences since physically the distance may not necessarily be the shortest distance, but logically they are close.
Sensor Network Simulation 3A
Currently has a partial implementation of GPSR with a planarization algorithm for the network.
Not fully implemented according to tasking.
Example execution:
python simulation.py 500 hw3a_wh69 > hw3a_wh69.txt
Sensor Network Simulation 3B
Did not make it this far.
References
- B. Karp, Geographic Routing for Wireless Networks, Ph.D. Dissertation, Harvard University, Cambridge, MA, October 2000.
- S. Ratnasamy, B. Karp, S. Shenker, D. Estrin, R. Govindan, L. Yin, and F. Yu, "Data-Centric Storage in Sensornets with GHT, a Geographic Hash Table." Mobile Networks and Applications, Vol. 8,No. 4, 2003.
Project: Key Distribution Applied to Geographic Routing
Proposal
Currently, the MSU Wireless Sensor Network (WSN) Simulator does not incorporate any security methods to provide security assurances in the areas of confidentiality, availability, integrity, and accountability. Because WSNs constantly transmit data back and forth between nodes and/or base stations, eavesdroppers can intercept the data. If the transmitted data is not sensitive, then eavesdropping is not a large issue. On the other hand, eavesdropping sensitive data becomes a very large issue. This project will focus on the confidentiality aspect by implementing a key distribution scheme while keeping in mind other issues related to WSNs. These issues include storage and computation power. The goal of this project is to show that data can be protected using symmetric cryptography and applied to geographic routing to provide assurance in confidentiality.
Deliverables
Presentation: key_distribution_greedy_project.ppt
Simulation requirements: Python Cryptography Toolkit
Simulation file(s) (zip format): wh69_ece8990_project.zip
Execution command:
python simulator.py 1000 crypto
