---
tags: Master, Simulation
---

# GeRaF Project


## Project Info

`Performance evaluation` project tackling some interesting problem. ($50\%$ of the final mark)

**Delivery:**
- `Code`
- `Presentation` ($10$-$15$ minutes)
- 10-15 pages
- **all members should present** project at the same time
- **expect feedback and questions** during and after presentation
- A short `report` to be formatted according to the IEEE template ([TEMPLATE](https://www.overleaf.com/latex/templates/ieee-conference-template/grfzhhncsfqn))
1. **Abstract** (~10 lines): paper and results summary
2. **Introduction:** explain the context, the problem, what you do that is novel and distinctive
3. **Related work:** list and describe a few references that did `similar work` as yours, or works/protocols that you wish to compare against
4. **Problem Definition:** `define` what you are doing, include reasoning
- explain the `assumptions`
- explain the way the system is `modeled`, and why
5. **Results:**
- present your outcomes orderly, showing `graphs`, `tables`, and/or `tools`
- `readability` check: labels, legends, annotations, number formatting
6. **Conclusion:** summarizing work and results

**Objectives:**
- implement and simulate the `multihop performance` of the GeRaF protocol
- check what happens in `different conditions`
- (density of the nodes per unit area, of the packet generation rate, ...)
- Is a **geographic protocol:** does it ever happen that a packet cannot be forwarded any more? How often?

**Additional objectives:**
- try `non-uniform` deployments
- implement and test a `mechanism to recover` from the cases where packets «get stuck»
- more realistic communication model based on `packet capture`:
- collisions among multiple packets do not destroy all packets, but rather only those for which the **Signal-toInterference-and-Noise Ratio** is below a given `threshold`

**Reference Papers:**
- [Geographic Random Forwarding (GeRaF) for ad hoc and sensor networks: multihop performance](https://www.ics.uci.edu/~ucrec/pubs/upload/385_Zorzi2005.pdf)
- [A detailed simulation study of geographic random forwarding (GERAF) in wireless sensor networks](https://www.researchgate.net/publication/4229019_A_detailed_simulation_study_of_geographic_random_forwarding_GERAF_in_wireless_sensor_networks)

## Questions
- ~~USE NS-3 ??~~
- range of node transmission: uniform
- "shape" of node area:
- square is fine
- what to do on boundaries
- random source and target
- use Signal-to-interference-plus-noise ratio instead of CSMA-CA

**consiglio:**
- 1 traffico poisson come paper
- burst di pacchetti: carrier sense prima di trasmettere

**try non-uniform**
- try with perlin noise or something similar
- try with non-uniform: exponential? 1 or more normal distributions?..
- change range based on regions? some regions with low range (due to trees or buildings), some with high range?

**try balancing load on same-region nodes:**
- on multiple nodes available, choose the less-used one:
this should balance the load on all nodes of that region

**handle "stuck message":**
- try semi-broadcast?
- try side-send?
- if node fails to deliver (stuck), penality applies (more sleep?) or sends back a "failed mission" message, so that previous node chooses that one less likely
- if a node fails to deliver (stuck), it avoids CTS-ing the requester node for a few times (because it is probably the same path)

**Packet ID:** what ID to assign when relay generates a packet? Relays do not know about other packets ID.
- Should use a `string` encapsulating sufficient info about packet so it can be distinguished.

**try everything (especially the "stuck" solutions) with realistic loads:**
- **same source-sink for several packets: therefore having memory of path / of "stuck nodes" helps a lot**


SENDER ENDING => sleep

## When relay becomes free (not busy anymore):
- receives start of packet, read that is not for itself
- receives RTS of late region
- no RTS/COL/PKT for a while:
WHEN TO RESERVE?:
- receives RTS
- receives COL
- receives PKT for itself

**NODES go back to sleep at end of PKT, not at start**, v2 could send a pre-PKT message declaring the chosen receiver

## Metrics
- packet success.. rate
- energy efficiency / awake time over sleep
- uniformity (heatmaps?)
- packet latence (end-to-end and/or per-hop)