---
# System prepended metadata

title: GeRaF Project
tags: [' Simulation', Master]

---

---
tags: Master, Simulation
---

# GeRaF Project

![](https://i.imgur.com/MPIz2sf.png)

## 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**

![](https://i.imgur.com/Vuvnv5B.png)
![](https://i.imgur.com/Rwmo44k.png)
![](https://i.imgur.com/0ubNWMv.png)
![](https://i.imgur.com/DqJoi3X.png)

![](https://i.imgur.com/xVAWY0T.png)
![](https://i.imgur.com/0XNvJ0D.png)
![SENDER](https://i.imgur.com/8TxJ7P5.png)
SENDER ENDING => sleep
![RECEIVER](https://i.imgur.com/XtLFj1Z.png)


## 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)









