vault backup: 2024-10-12 18:31:01
This commit is contained in:
parent
d5f416dfc0
commit
42c39a7780
7 changed files with 221 additions and 176 deletions
49
.obsidian/workspace.json
vendored
49
.obsidian/workspace.json
vendored
|
|
@ -4,37 +4,36 @@
|
||||||
"type": "split",
|
"type": "split",
|
||||||
"children": [
|
"children": [
|
||||||
{
|
{
|
||||||
"id": "7836cf4d439bcdf6",
|
"id": "708a5933e5de1e88",
|
||||||
"type": "tabs",
|
"type": "tabs",
|
||||||
"children": [
|
"children": [
|
||||||
{
|
{
|
||||||
"id": "8c353f1d24129115",
|
"id": "b95c6a3bd8dada7d",
|
||||||
"type": "leaf",
|
"type": "leaf",
|
||||||
"state": {
|
"state": {
|
||||||
"type": "pdf",
|
"type": "pdf",
|
||||||
"state": {
|
"state": {
|
||||||
"file": "Autonomous Networking/slides/2 RFID.pdf",
|
"file": "Autonomous Networking/slides/4 WSN2.pdf",
|
||||||
"page": 39,
|
"page": 67,
|
||||||
"left": -11,
|
"left": -22,
|
||||||
"top": 529,
|
"top": 319,
|
||||||
"zoom": 1.3447916666666668
|
"zoom": 0.6749999999999999
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
"id": "8f92d52482562d09",
|
"id": "deeefdea451fa477",
|
||||||
"type": "leaf",
|
"type": "leaf",
|
||||||
"state": {
|
"state": {
|
||||||
"type": "markdown",
|
"type": "image",
|
||||||
"state": {
|
"state": {
|
||||||
"file": "conflict-files-obsidian-git.md",
|
"file": "Autonomous Networking/images/Pasted image 20241012174130.png"
|
||||||
"mode": "source",
|
|
||||||
"source": false
|
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"currentTab": 1
|
"currentTab": 1,
|
||||||
|
"stacked": true
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"direction": "vertical"
|
"direction": "vertical"
|
||||||
|
|
@ -100,7 +99,7 @@
|
||||||
"state": {
|
"state": {
|
||||||
"type": "backlink",
|
"type": "backlink",
|
||||||
"state": {
|
"state": {
|
||||||
"file": "conflict-files-obsidian-git.md",
|
"file": "Autonomous Networking/images/Pasted image 20241012174130.png",
|
||||||
"collapseAll": false,
|
"collapseAll": false,
|
||||||
"extraContext": false,
|
"extraContext": false,
|
||||||
"sortOrder": "alphabetical",
|
"sortOrder": "alphabetical",
|
||||||
|
|
@ -117,7 +116,7 @@
|
||||||
"state": {
|
"state": {
|
||||||
"type": "outgoing-link",
|
"type": "outgoing-link",
|
||||||
"state": {
|
"state": {
|
||||||
"file": "conflict-files-obsidian-git.md",
|
"file": "Autonomous Networking/images/Pasted image 20241012174130.png",
|
||||||
"linksCollapsed": false,
|
"linksCollapsed": false,
|
||||||
"unlinkedCollapsed": true
|
"unlinkedCollapsed": true
|
||||||
}
|
}
|
||||||
|
|
@ -140,7 +139,7 @@
|
||||||
"state": {
|
"state": {
|
||||||
"type": "outline",
|
"type": "outline",
|
||||||
"state": {
|
"state": {
|
||||||
"file": "conflict-files-obsidian-git.md"
|
"file": "Autonomous Networking/images/Pasted image 20241012174130.png"
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
|
|
@ -174,10 +173,17 @@
|
||||||
"obsidian-git:Open Git source control": false
|
"obsidian-git:Open Git source control": false
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
"active": "8f92d52482562d09",
|
"active": "2b2245f56092006e",
|
||||||
"lastOpenFiles": [
|
"lastOpenFiles": [
|
||||||
"Autonomous Networking/slides/2 RFID.pdf",
|
"Autonomous Networking/notes/4 WSN Routing.md",
|
||||||
|
"Autonomous Networking/notes/3 WSN MAC.md",
|
||||||
|
"Autonomous Networking/slides/4 WSN2.pdf",
|
||||||
|
"Autonomous Networking/images/Pasted image 20241012182403.png",
|
||||||
|
"Autonomous Networking/images/Pasted image 20241012175224.png",
|
||||||
|
"Autonomous Networking/images/Pasted image 20241012174130.png",
|
||||||
|
"Autonomous Networking/slides/3 WSN.pdf",
|
||||||
"conflict-files-obsidian-git.md",
|
"conflict-files-obsidian-git.md",
|
||||||
|
"Autonomous Networking/slides/2 RFID.pdf",
|
||||||
"Foundation of data science/slides/notes 2.md",
|
"Foundation of data science/slides/notes 2.md",
|
||||||
"Foundation of data science/slides/Untitled.md",
|
"Foundation of data science/slides/Untitled.md",
|
||||||
"Foundation of data science/slides/FDS_intro_new.pdf",
|
"Foundation of data science/slides/FDS_intro_new.pdf",
|
||||||
|
|
@ -189,17 +195,10 @@
|
||||||
"Biometric Systems/final notes/2. Performance indexes.md",
|
"Biometric Systems/final notes/2. Performance indexes.md",
|
||||||
"BUCA/Queues.md",
|
"BUCA/Queues.md",
|
||||||
"BUCA",
|
"BUCA",
|
||||||
"Autonomous Networking/slides/4 WSN2.pdf",
|
|
||||||
"Autonomous Networking/slides/3 WSN.pdf",
|
|
||||||
"Autonomous Networking/notes/4 WSN pt. 2.md",
|
|
||||||
"Autonomous Networking/notes/3 WSN.md",
|
|
||||||
"Autonomous Networking/images/Pasted image 20241011191033.png",
|
"Autonomous Networking/images/Pasted image 20241011191033.png",
|
||||||
"Autonomous Networking/images/Pasted image 20241011182343.png",
|
"Autonomous Networking/images/Pasted image 20241011182343.png",
|
||||||
"Autonomous Networking/images/Pasted image 20241011182036.png",
|
"Autonomous Networking/images/Pasted image 20241011182036.png",
|
||||||
"Autonomous Networking/images/Pasted image 20241011182031.png",
|
"Autonomous Networking/images/Pasted image 20241011182031.png",
|
||||||
"Autonomous Networking/images/Pasted image 20241011180413.png",
|
|
||||||
"Autonomous Networking/images/Pasted image 20241011175026.png",
|
|
||||||
"Autonomous Networking/images/Pasted image 20241002235837.png",
|
|
||||||
"Autonomous Networking/notes/2 RFID.md",
|
"Autonomous Networking/notes/2 RFID.md",
|
||||||
"Autonomous Networking/images",
|
"Autonomous Networking/images",
|
||||||
"Autonomous Networking/notes",
|
"Autonomous Networking/notes",
|
||||||
|
|
|
||||||
BIN
Autonomous Networking/images/Pasted image 20241012174130.png
Normal file
BIN
Autonomous Networking/images/Pasted image 20241012174130.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 30 KiB |
BIN
Autonomous Networking/images/Pasted image 20241012175224.png
Normal file
BIN
Autonomous Networking/images/Pasted image 20241012175224.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 71 KiB |
BIN
Autonomous Networking/images/Pasted image 20241012182403.png
Normal file
BIN
Autonomous Networking/images/Pasted image 20241012182403.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 39 KiB |
|
|
@ -115,12 +115,12 @@ To address these issues, we use MAC protocols. We need a protocol suitable for w
|
||||||
- increases energy efficiency, aviding idle listening
|
- increases energy efficiency, aviding idle listening
|
||||||
- allows scalability, lower latency, fairness and better throughput
|
- allows scalability, lower latency, fairness and better throughput
|
||||||
|
|
||||||
##### Reasons of energy waste:
|
### Reasons of energy waste
|
||||||
- collisions
|
- Collision: they need to be discarded and retransmitted
|
||||||
- overhearing: a node receive packets destined to others
|
- Overhearing: node receiving packet destined to other nodes
|
||||||
- overhead caused by control-packets
|
- Overhead caused by control-packets
|
||||||
- idle listening
|
- Idle listening
|
||||||
- overemitting: transmitting before the destination node is ready
|
- Overemitting: destination not ready
|
||||||
|
|
||||||
#### Techniques for WSN MAC
|
#### Techniques for WSN MAC
|
||||||
- Contention based
|
- Contention based
|
||||||
|
|
@ -190,4 +190,65 @@ However, collisions are still possible as RTS packets can collide. But RTS packe
|
||||||
- CTS again contains duration field
|
- CTS again contains duration field
|
||||||
- all the stations receiving the CTS need to adjust their NAV
|
- all the stations receiving the CTS need to adjust their NAV
|
||||||
- sender sends data after SIFS
|
- sender sends data after SIFS
|
||||||
- receiver sends ACK after SIFS
|
- receiver sends ACK after SIFS
|
||||||
|
|
||||||
|
### Communication patterns
|
||||||
|
- **Broadcast**
|
||||||
|
- a broadcast pattern is generally used by a base station (sink) to transmit information to all sensor nodes of the network
|
||||||
|
- **Convergecast or data gathering (all/many to 1)**
|
||||||
|
- all or a group of sensors comunicate to the sink
|
||||||
|
- typically used to collect sensed data
|
||||||
|
|
||||||
|
## S-MAC protocol
|
||||||
|
S-MAC: Sleep MAC
|
||||||
|
|
||||||
|
As idle listening consumes significant energy (50-100% of the energy required for receiving), the solution is to periodic listen and sleep, with a listen duty cycle of about 10% (e.g. listen 200ms and sleep 2s).
|
||||||
|
|
||||||
|
![[Pasted image 20241011175026.png]]
|
||||||
|
|
||||||
|
- Duration of sleep and listen cycles are the same for all nodes
|
||||||
|
- All nodes are free to choose their own listen/sleep schedules
|
||||||
|
- to reduce control overhead, **neighbor nodes are syncronized together**
|
||||||
|
- neighboring nodes form **virtual clusters** so as to set up a common sleep schedule
|
||||||
|
- each node maintaines a table with neighbors’ schedule
|
||||||
|
- table entries are filled when the node receives sync packets
|
||||||
|
- SYNC packets are exchanged periodically to maintain schedule synchronization
|
||||||
|
- they are sent every SINCHRONYZATION PERIOD
|
||||||
|
- Receivers will adjust their timer counters immediately after they receive the SYNC packet
|
||||||
|
|
||||||
|
- If there are no neighbors, the node will chose a random schedule. These nodes will be called **synchronizers**, nodes who receive a schedule are called **followers**.
|
||||||
|
|
||||||
|
- In a large network we cannot guarantee that all nodes follow the same schedule
|
||||||
|
- node on the border will follow both schedules
|
||||||
|
- they need to broadcast packet twice, for schedule 1 and 2
|
||||||
|
![[Pasted image 20241011180413.png]]
|
||||||
|
|
||||||
|
|
||||||
|
#### Collision avoidance
|
||||||
|
- RTS/CTS with duration is used (so NAV is used for backoff)
|
||||||
|
- carrier sense before initiating a transmission
|
||||||
|
- neighbor nodes of both sender and receiver sleeps during transmission to save power
|
||||||
|
|
||||||
|
- listen time is divided into minislots
|
||||||
|
- sender selects a minislot to end carrier sense
|
||||||
|
- if channel is free it transmits SYNC in the next minislot
|
||||||
|
|
||||||
|
### S-MAC Performance evaluation
|
||||||
|
- Topology: Two-hop network with two sources and two sinks
|
||||||
|
- Sources periodically generate a sensing message which is divided into fragments
|
||||||
|
- Traffic load is changed by varying the inter-arrival period of the messages: (for inter-arrival period of 5s, a message is generated every 5s by each source. Here it varies between 1-10s)
|
||||||
|
![[Pasted image 20241011182036.png]]
|
||||||
|
|
||||||
|
- In each test, there are 10 messages generated on each source node
|
||||||
|
- Each message has 10 fragments, and each fragment has 40 bytes (200 data packets to be passed from sources to sinks)
|
||||||
|
- The total energy consumption of each node is measured for sending this fixed amount of data
|
||||||
|
![[Pasted image 20241011182343.png]]
|
||||||
|
|
||||||
|
- S-MAC consumes much less energy than 802.11-like protocol without sleeping
|
||||||
|
- At heavy load, idle listening rarely happens, energy savings from sleeping is very limited
|
||||||
|
- At light load, periodic sleeping plays a key role
|
||||||
|
|
||||||
|
Conclusions:
|
||||||
|
- A mainly static network is assumed
|
||||||
|
- Trades off latency for reduced energy consumption
|
||||||
|
- Redundant data is still sent with increased latency
|
||||||
129
Autonomous Networking/notes/4 WSN Routing.md
Normal file
129
Autonomous Networking/notes/4 WSN Routing.md
Normal file
|
|
@ -0,0 +1,129 @@
|
||||||
|
|
||||||
|
- routing technique is needed to establish multi-hop communication
|
||||||
|
- the routing strategy should ensure
|
||||||
|
- mminimun energy consumption
|
||||||
|
- maximization of the network lifetime
|
||||||
|
|
||||||
|
#### Ad Hoc Routing Protocols – Classification
|
||||||
|
- **network topology**
|
||||||
|
- flat
|
||||||
|
- hierarchical
|
||||||
|
- **which data is used to identify nodes**
|
||||||
|
- arbitrary identifier
|
||||||
|
- the position of a node
|
||||||
|
- can be used to assist in geographical routing problems to decide next hop
|
||||||
|
- scalable and suitable for sensor networks
|
||||||
|
|
||||||
|
##### Flat routing protocols
|
||||||
|
Three main categories
|
||||||
|
|
||||||
|
- Proactive protocols (table driven)
|
||||||
|
- always tries to keep routing data up-to-date
|
||||||
|
- active before tables are actually needed
|
||||||
|
- routes are always already known
|
||||||
|
- more bandwidth and energy usage
|
||||||
|
- Reactive protocols
|
||||||
|
- route determined only when needed
|
||||||
|
- operates on demand
|
||||||
|
- when a route is needed, a kind of global search is started
|
||||||
|
- causes delays if routes are not already cached
|
||||||
|
- Hybrid protocols
|
||||||
|
- combination of these behaviors
|
||||||
|
|
||||||
|
### Destination Sequence Distance Vector (DSDV)
|
||||||
|
- based on bellman-ford algorithm
|
||||||
|
- proactive protocol
|
||||||
|
- add aging information to avoid routing loops
|
||||||
|
- on topology change, send incremental route updates
|
||||||
|
- unstable route updates are delayed
|
||||||
|
|
||||||
|
![[Pasted image 20241011191033.png]]
|
||||||
|
|
||||||
|
- to avoid loops, DSDV adds a **sequence number** to each routing table entry which is periodically updated. Routes with higher sequence number are preferred
|
||||||
|
|
||||||
|
##### Reactive protocols
|
||||||
|
|
||||||
|
### Flooding
|
||||||
|
- copies of incoming packets are sent by every link except the one by which the packet is arrived
|
||||||
|
- generates a lot of superfluous traffic
|
||||||
|
- flooding is a reactive technique, and does not require costly topology maintenance and complex route discovery algorithms
|
||||||
|
|
||||||
|
Characteristics:
|
||||||
|
- derivery is guaranteed (e grazie al cazzo)
|
||||||
|
- one copy will arrive by the quickest possible route (wow)
|
||||||
|
|
||||||
|
Drawbacks:
|
||||||
|
- implosion: duplicated messages are broadcasted to the same node
|
||||||
|
- overlap: if two nodes share the same under observation region, both of them may sense the same stimuli at the same time. As a result, neighbor nodes receive duplicated messages
|
||||||
|
- resource blindness (no knowledge about the available resources)
|
||||||
|
- does not take into consideration all the available energy resources
|
||||||
|
- consumes a lot of energy
|
||||||
|
|
||||||
|
### Gossiping
|
||||||
|
- nodes send the incoming packages to a randomly selected neighbor
|
||||||
|
- avoids implosion, but it takes long to propagate the message
|
||||||
|
|
||||||
|
### Dynamic Source Routing (DSR)
|
||||||
|
- Source routing: Each data packet sent carries in its header the complete, ordered list of nodes through which the packet will pass
|
||||||
|
- The sender can select and control the routes used for its own packets and supports the use of multiple routes to any destination
|
||||||
|
- Including the route in the header of each packet, helps other nodes forwarding the packet to cache the routing information for future use
|
||||||
|
|
||||||
|
**DSR is composed by two main mechanism:**
|
||||||
|
- **Route Discovery**
|
||||||
|
- mechanism by which a node S obtains the route to a destination node D
|
||||||
|
- used only if S doesn't already know the route
|
||||||
|
- every request contains an unique ID and a route record
|
||||||
|
- S sends a broadcast Route Request packet
|
||||||
|
- every node broadcasts the packet (with the same ID) appending their own address to the route record
|
||||||
|
- when D receives the request, it sends a Route Reply back to the initiator S, with a copy of the route record
|
||||||
|
- more than a route can be returned, making the protocol more resistent to changes in network topology
|
||||||
|
- **Route Maintenance**
|
||||||
|
- mechanism by which a node S can detect (while sending a packet to D) if the network topology has changed and the route can't be used anymore
|
||||||
|
|
||||||
|
![[Pasted image 20241012174130.png]]
|
||||||
|
|
||||||
|
### Ad-hoc On Demand Distance Vector routing (AODV)
|
||||||
|
- a mix between DSR and DSDV
|
||||||
|
- nodes maintain routing tables
|
||||||
|
- sequence numbers added to handle stale caches (when routing info is too old)
|
||||||
|
- nodes remember from where a packet came and populate routing tables
|
||||||
|
|
||||||
|
We can see it as an improved DSDV, as it minimizes the number of required broadcast by creating routes on a demand basis.
|
||||||
|
- if the source node S does not have the route to D, S initiates a path discovery process to locate D
|
||||||
|
- the route request is broadcasted to the neighbors
|
||||||
|
- when a node receives a broadcast RREQ, it records in their table the address of the neighbor who sent the request
|
||||||
|
- when the destination or an intermediate node that can reach the destiation is reached, it replies with a route reply (RREP) packet back to the neighbor from which it first received the RREQ
|
||||||
|
- the RREQ is routed back along the reverse path
|
||||||
|
- nodes along the path updates their table
|
||||||
|
|
||||||
|
![[Pasted image 20241012175224.png]]
|
||||||
|
|
||||||
|
## Geographical routing
|
||||||
|
- routing tables contain information to which next hop a packet should be forwarded
|
||||||
|
- this can be explicitly constructed, or implicitly inferred from physical placement of nodes
|
||||||
|
- by knowing the position of nodes, we can send the packet to a neighbor in the right direction
|
||||||
|
- we can also do *geocasting*: sending to any node in a given area
|
||||||
|
- to map a node ID to the node position we might need a location service
|
||||||
|
|
||||||
|
Strategies
|
||||||
|
- **Most forward within range r**
|
||||||
|
- send to that neighbor that realizes the most forward progress towards destination, but staying in a range r (quello che stando nel range r si avvicina di più geograficamente parlando)
|
||||||
|
- **Nearest node with (any) forward progress**
|
||||||
|
- the opposite as the previous strategy
|
||||||
|
- minimizes transmission power
|
||||||
|
- **Directional routing**
|
||||||
|
- choose next hop that is angularly closest to destination (closest to the connecting line to destination)
|
||||||
|
- come se tracciassi una linea tra S e D e prendessi gli hop più vicini alla linea
|
||||||
|
- problem: might result in loops!
|
||||||
|
|
||||||
|
#### Dead ends problem
|
||||||
|
![[Pasted image 20241012182403.png]]
|
||||||
|
|
||||||
|
## Conclusion
|
||||||
|
- there are many other protocols
|
||||||
|
- the best solution depends on network characteristics
|
||||||
|
- mobility
|
||||||
|
- node capabilities
|
||||||
|
- geographic approach allows to save more energy
|
||||||
|
- proactive approach is fast, but involves overhead
|
||||||
|
- reactive approach generate much less overhead, but it is slower
|
||||||
|
|
@ -1,144 +0,0 @@
|
||||||
### Communication patterns
|
|
||||||
- **Broadcast**
|
|
||||||
- a broadcast pattern is generally used by a base station (sink) to transmit information to all sensor nodes of the network
|
|
||||||
- **Convergecast or data gathering (all/many to 1)**
|
|
||||||
- all or a group of sensors comunicate to the sink
|
|
||||||
- typically used to collect sensed data
|
|
||||||
|
|
||||||
We need to define a good MAC protocol for wireless sensor networks, the following attrivutes must be considered:
|
|
||||||
- energy efficiency
|
|
||||||
- scatability and adaptability to changes
|
|
||||||
Latency, throughput and bandwidth utilization may be secondary, but desirable.
|
|
||||||
|
|
||||||
### Reasons of energy waste
|
|
||||||
- Collision: they need to be discarded and retransmitted
|
|
||||||
- Overhearing: node receiving packet destined to other nodes
|
|
||||||
- Control-packet overhead
|
|
||||||
- Idle listening
|
|
||||||
- Overemitting: destination not ready
|
|
||||||
|
|
||||||
## S-MAC protocol
|
|
||||||
S-MAC: Sleep MAC
|
|
||||||
|
|
||||||
As idle listening consumes significant energy (50-100% of the energy required for receiving), the solution is to periodic listen and sleep, with a listen duty cycle of about 10% (e.g. listen 200ms and sleep 2s).
|
|
||||||
|
|
||||||
![[Pasted image 20241011175026.png]]
|
|
||||||
|
|
||||||
- Duration of sleep and listen cycles are the same for all nodes
|
|
||||||
- All nodes are free to choose their own listen/sleep schedules
|
|
||||||
- to reduce control overhead, **neighbor nodes are syncronized together**
|
|
||||||
- neighboring nodes form **virtual clusters** so as to set up a common sleep schedule
|
|
||||||
- each node maintaines a table with neighbors’ schedule
|
|
||||||
- table entries are filled when the node receives sync packets
|
|
||||||
- SYNC packets are exchanged periodically to maintain schedule synchronization
|
|
||||||
- they are sent every SINCHRONYZATION PERIOD
|
|
||||||
- Receivers will adjust their timer counters immediately after they receive the SYNC packet
|
|
||||||
|
|
||||||
- If there are no neighbors, the node will chose a random schedule. These nodes will be called **synchronizers**, nodes who receive a schedule are called **followers**.
|
|
||||||
|
|
||||||
- In a large network we cannot guarantee that all nodes follow the same schedule
|
|
||||||
- node on the border will follow both schedules
|
|
||||||
- they need to broadcast packet twice, for schedule 1 and 2
|
|
||||||
![[Pasted image 20241011180413.png]]
|
|
||||||
|
|
||||||
|
|
||||||
#### Collision avoidance
|
|
||||||
- RTS/CTS with duration is used (so NAV is used for backoff)
|
|
||||||
- carrier sense before initiating a transmission
|
|
||||||
- neighbor nodes of both sender and receiver sleeps during transmission to save power
|
|
||||||
|
|
||||||
- listen time is divided into minislots
|
|
||||||
- sender selects a minislot to end carrier sense
|
|
||||||
- if channel is free it transmits SYNC in the next minislot
|
|
||||||
|
|
||||||
### S-MAC Performance evaluation
|
|
||||||
- Topology: Two-hop network with two sources and two sinks
|
|
||||||
- Sources periodically generate a sensing message which is divided into fragments
|
|
||||||
- Traffic load is changed by varying the inter-arrival period of the messages: (for inter-arrival period of 5s, a message is generated every 5s by each source. Here it varies between 1-10s)
|
|
||||||
![[Pasted image 20241011182036.png]]
|
|
||||||
|
|
||||||
- In each test, there are 10 messages generated on each source node
|
|
||||||
- Each message has 10 fragments, and each fragment has 40 bytes (200 data packets to be passed from sources to sinks)
|
|
||||||
- The total energy consumption of each node is measured for sending this fixed amount of data
|
|
||||||
![[Pasted image 20241011182343.png]]
|
|
||||||
|
|
||||||
- S-MAC consumes much less energy than 802.11-like protocol without sleeping
|
|
||||||
- At heavy load, idle listening rarely happens, energy savings from sleeping is very limited
|
|
||||||
- At light load, periodic sleeping plays a key role
|
|
||||||
|
|
||||||
Conclusions:
|
|
||||||
- A mainly static network is assumed
|
|
||||||
- Trades off latency for reduced energy consumption
|
|
||||||
- Redundant data is still sent with increased latency
|
|
||||||
|
|
||||||
### Routing
|
|
||||||
- routing technique is needed to establish multi-hop communication
|
|
||||||
- the routing strategy should ensure
|
|
||||||
- mminimun energy consumption
|
|
||||||
- maximization of the network lifetime
|
|
||||||
|
|
||||||
#### Ad Hoc Routing Protocols – Classification
|
|
||||||
- **network topology**
|
|
||||||
- flat
|
|
||||||
- hierarchical
|
|
||||||
- **which data is used to identify nodes**
|
|
||||||
- arbitrary identifier
|
|
||||||
- the position of a node
|
|
||||||
- can be used to assist in geographical routing problems to decide next hop
|
|
||||||
- scalable and suitable for sensor networks
|
|
||||||
|
|
||||||
##### Flat routing protocols
|
|
||||||
Three main categories
|
|
||||||
|
|
||||||
- Proactive protocols (table driven)
|
|
||||||
- always tries to keep routing data up-to-date
|
|
||||||
- active before tables are actually needed
|
|
||||||
- routes are always already known
|
|
||||||
- more bandwidth and energy usage
|
|
||||||
- Reactive protocols
|
|
||||||
- route determined only when needed
|
|
||||||
- operates on demand
|
|
||||||
- when a route is needed, a kind of global search is started
|
|
||||||
- causes delays if routes are not already cached
|
|
||||||
- Hybrid protocols
|
|
||||||
- combination of these behaviors
|
|
||||||
|
|
||||||
### Destination Sequence Distance Vector (DSDV)
|
|
||||||
- based on bellman-ford algorithm
|
|
||||||
- proactive protocol
|
|
||||||
- add aging information to avoid routing loops
|
|
||||||
- on topology change, send incremental route updates
|
|
||||||
- unstable route updates are delayed
|
|
||||||
|
|
||||||
![[Pasted image 20241011191033.png]]
|
|
||||||
|
|
||||||
- to avoid loops, DSDV adds a **sequence number** to each routing table entry which is periodically updated. Routes with higher sequence number are preferred
|
|
||||||
|
|
||||||
##### Reactive protocols
|
|
||||||
|
|
||||||
### Flooding
|
|
||||||
- copies of incoming packets are sent by every link except the one by which the packet is arrived
|
|
||||||
- generates a lot of superfluous traffic
|
|
||||||
- flooding is a reactive technique, and does not require costly topology maintenance and complex route discovery algorithms
|
|
||||||
|
|
||||||
Characteristics:
|
|
||||||
- derivery is guaranteed (e grazie al cazzo)
|
|
||||||
- one copy will arrive by the quickest possible route (wow)
|
|
||||||
|
|
||||||
Drawbacks:
|
|
||||||
- implosion: duplicated messages are broadcasted to the same node
|
|
||||||
- overlap: if two nodes share the same under observation region, both of them may sense the same stimuli at the same time. As a result, neighbor nodes receive duplicated messages
|
|
||||||
- resource blindness (no knowledge about the available resources)
|
|
||||||
- does not take into consideration all the available energy resources
|
|
||||||
- consumes a lot of energy
|
|
||||||
|
|
||||||
### Gossiping
|
|
||||||
- nodes send the incoming packages to a randomly selected neighbor
|
|
||||||
- avoids implosion, but it takes long to propagate the message
|
|
||||||
|
|
||||||
### Dynamic Source Routing (DSR)
|
|
||||||
- Source routing: Each data packet sent carries in its header the complete, ordered list of nodes through which the packet will pass
|
|
||||||
- The sender can select and control the routes used for its own packets and supports the use of multiple routes to any destination
|
|
||||||
|
|
||||||
|
|
||||||
not finished yet
|
|
||||||
Loading…
Reference in a new issue