vault backup: 2024-10-12 17:16:29
|
@ -1,8 +1,15 @@
|
||||||
{
|
{
|
||||||
|
<<<<<<< HEAD
|
||||||
|
"display": false,
|
||||||
|
"blockDisplay": false,
|
||||||
|
"blockMenuIcon": false,
|
||||||
|
"blockKeyboardIcon": false,
|
||||||
|
=======
|
||||||
"display": true,
|
"display": true,
|
||||||
"blockDisplay": true,
|
"blockDisplay": true,
|
||||||
"blockMenuIcon": true,
|
"blockMenuIcon": true,
|
||||||
"blockKeyboardIcon": true,
|
"blockKeyboardIcon": true,
|
||||||
|
>>>>>>> origin/main
|
||||||
"inlineDisplay": false,
|
"inlineDisplay": false,
|
||||||
"inlineMenuIcon": false,
|
"inlineMenuIcon": false,
|
||||||
"inlineKeyboardIcon": false
|
"inlineKeyboardIcon": false
|
||||||
|
|
70
.obsidian/workspace.json
vendored
|
@ -15,13 +15,26 @@
|
||||||
"state": {
|
"state": {
|
||||||
"file": "Autonomous Networking/slides/2 RFID.pdf",
|
"file": "Autonomous Networking/slides/2 RFID.pdf",
|
||||||
"page": 39,
|
"page": 39,
|
||||||
"left": -36,
|
"left": -11,
|
||||||
"top": 525,
|
"top": 529,
|
||||||
"zoom": 0.4114583333333333
|
"zoom": 1.3447916666666668
|
||||||
|
}
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "8f92d52482562d09",
|
||||||
|
"type": "leaf",
|
||||||
|
"state": {
|
||||||
|
"type": "markdown",
|
||||||
|
"state": {
|
||||||
|
"file": "conflict-files-obsidian-git.md",
|
||||||
|
"mode": "source",
|
||||||
|
"source": false
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
]
|
],
|
||||||
|
"currentTab": 1
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"direction": "vertical"
|
"direction": "vertical"
|
||||||
|
@ -87,7 +100,7 @@
|
||||||
"state": {
|
"state": {
|
||||||
"type": "backlink",
|
"type": "backlink",
|
||||||
"state": {
|
"state": {
|
||||||
"file": "Autonomous Networking/slides/2 RFID.pdf",
|
"file": "conflict-files-obsidian-git.md",
|
||||||
"collapseAll": false,
|
"collapseAll": false,
|
||||||
"extraContext": false,
|
"extraContext": false,
|
||||||
"sortOrder": "alphabetical",
|
"sortOrder": "alphabetical",
|
||||||
|
@ -104,7 +117,7 @@
|
||||||
"state": {
|
"state": {
|
||||||
"type": "outgoing-link",
|
"type": "outgoing-link",
|
||||||
"state": {
|
"state": {
|
||||||
"file": "Autonomous Networking/slides/2 RFID.pdf",
|
"file": "conflict-files-obsidian-git.md",
|
||||||
"linksCollapsed": false,
|
"linksCollapsed": false,
|
||||||
"unlinkedCollapsed": true
|
"unlinkedCollapsed": true
|
||||||
}
|
}
|
||||||
|
@ -127,7 +140,7 @@
|
||||||
"state": {
|
"state": {
|
||||||
"type": "outline",
|
"type": "outline",
|
||||||
"state": {
|
"state": {
|
||||||
"file": "Autonomous Networking/slides/2 RFID.pdf"
|
"file": "conflict-files-obsidian-git.md"
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
|
@ -161,32 +174,39 @@
|
||||||
"obsidian-git:Open Git source control": false
|
"obsidian-git:Open Git source control": false
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
"active": "8c353f1d24129115",
|
"active": "8f92d52482562d09",
|
||||||
"lastOpenFiles": [
|
"lastOpenFiles": [
|
||||||
"Autonomous Networking/notes/2 RFID.md",
|
|
||||||
"Autonomous Networking/slides/2 RFID.pdf",
|
"Autonomous Networking/slides/2 RFID.pdf",
|
||||||
"Autonomous Networking/images/Pasted image 20240928134852.png",
|
"conflict-files-obsidian-git.md",
|
||||||
"Autonomous Networking/images/Pasted image 20240928140723.png",
|
"Foundation of data science/slides/notes 2.md",
|
||||||
"Autonomous Networking/images/Pasted image 20240928193321.png",
|
"Foundation of data science/slides/Untitled.md",
|
||||||
|
"Foundation of data science/slides/FDS_intro_new.pdf",
|
||||||
|
"Foundation of data science/slides",
|
||||||
|
"Foundation of data science",
|
||||||
|
"Biometric Systems/images/Pasted image 20241002181936.png",
|
||||||
|
"Biometric Systems/images/Pasted image 20241002181932.png",
|
||||||
|
"Biometric Systems/images/Pasted image 20241002135922.png",
|
||||||
|
"Biometric Systems/final notes/2. Performance indexes.md",
|
||||||
|
"BUCA/Queues.md",
|
||||||
|
"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 20241011182343.png",
|
||||||
|
"Autonomous Networking/images/Pasted image 20241011182036.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/images",
|
"Autonomous Networking/images",
|
||||||
"Autonomous Networking/images/Pasted image 20240928143319.png",
|
|
||||||
"Autonomous Networking/images/Pasted image 20240928193303.png",
|
|
||||||
"Autonomous Networking/images/Pasted image 20240928193208.png",
|
|
||||||
"Autonomous Networking/images/Pasted image 20240928191316.png",
|
|
||||||
"Autonomous Networking/images/Pasted image 20240928183123.png",
|
|
||||||
"Autonomous Networking/images/Pasted image 20240928181424.png",
|
|
||||||
"Autonomous Networking/images/Pasted image 20240928181304.png",
|
|
||||||
"Autonomous Networking/notes",
|
"Autonomous Networking/notes",
|
||||||
"Autonomous Networking/slides",
|
"Autonomous Networking/slides",
|
||||||
"Autonomous Networking",
|
|
||||||
"Biometric Systems/final notes/1. Introduction.md",
|
"Biometric Systems/final notes/1. Introduction.md",
|
||||||
"LICENSE",
|
|
||||||
"Biometric Systems/slides/LEZIONE1_Introduzione.pdf",
|
|
||||||
"Biometric Systems/slides/lezione1 notes.md",
|
"Biometric Systems/slides/lezione1 notes.md",
|
||||||
"Biometric Systems/images",
|
|
||||||
"Biometric Systems/slides/LEZIONE2_Indici_di_prestazione.pdf",
|
|
||||||
"prova per obsidian.md",
|
"prova per obsidian.md",
|
||||||
"Biometric Systems/final notes",
|
|
||||||
"Senza nome.canvas"
|
"Senza nome.canvas"
|
||||||
]
|
]
|
||||||
}
|
}
|
BIN
Autonomous Networking/images/Pasted image 20241002114133.png
Normal file
After Width: | Height: | Size: 65 KiB |
BIN
Autonomous Networking/images/Pasted image 20241002233803.png
Normal file
After Width: | Height: | Size: 76 KiB |
BIN
Autonomous Networking/images/Pasted image 20241002234319.png
Normal file
After Width: | Height: | Size: 50 KiB |
BIN
Autonomous Networking/images/Pasted image 20241002235016.png
Normal file
After Width: | Height: | Size: 96 KiB |
BIN
Autonomous Networking/images/Pasted image 20241002235259.png
Normal file
After Width: | Height: | Size: 52 KiB |
BIN
Autonomous Networking/images/Pasted image 20241002235555.png
Normal file
After Width: | Height: | Size: 52 KiB |
BIN
Autonomous Networking/images/Pasted image 20241002235837.png
Normal file
After Width: | Height: | Size: 41 KiB |
BIN
Autonomous Networking/images/Pasted image 20241011175026.png
Normal file
After Width: | Height: | Size: 7.1 KiB |
BIN
Autonomous Networking/images/Pasted image 20241011180413.png
Normal file
After Width: | Height: | Size: 21 KiB |
BIN
Autonomous Networking/images/Pasted image 20241011182031.png
Normal file
After Width: | Height: | Size: 42 KiB |
BIN
Autonomous Networking/images/Pasted image 20241011182036.png
Normal file
After Width: | Height: | Size: 42 KiB |
BIN
Autonomous Networking/images/Pasted image 20241011182343.png
Normal file
After Width: | Height: | Size: 69 KiB |
BIN
Autonomous Networking/images/Pasted image 20241011191033.png
Normal file
After Width: | Height: | Size: 103 KiB |
193
Autonomous Networking/notes/3 WSN.md
Normal file
|
@ -0,0 +1,193 @@
|
||||||
|
The main difference between an RFID network and a WSN is that nodes:
|
||||||
|
- are battery powered
|
||||||
|
- can sense the environment
|
||||||
|
- can listen to the channel (carrier sense) and transmit spontaneously
|
||||||
|
- can make more complex computation
|
||||||
|
- can send packets to other nodes (e.g. for multi-hop communication)
|
||||||
|
|
||||||
|
#### Roles of partecipants in WSN
|
||||||
|
- Sources of data: measure data, report them somewhere
|
||||||
|
- Sinks of data: interested in receiving data from WSN
|
||||||
|
- Actors/actuators: control some devices based on data
|
||||||
|
|
||||||
|
#### Deployiment options
|
||||||
|
- Random deployiment
|
||||||
|
- dropped from an aircraft
|
||||||
|
- usually uniform random distribution for nodes over finite area is assumed
|
||||||
|
- Regular deployment
|
||||||
|
- wel planned, fixed
|
||||||
|
- not necessarily geometric structure, but that is often a convenient assumption
|
||||||
|
- Mobile sensor nodes
|
||||||
|
- Can move to compensate for deployment shortcomings
|
||||||
|
- Can be passively moved by some external force (wind, water)
|
||||||
|
- Can actively seek out "interesting" areas
|
||||||
|
#### Characteristics of WSN
|
||||||
|
- Scalability
|
||||||
|
- they need to support **large number of nodes**
|
||||||
|
- performance should not degrade with increasing number of nodes
|
||||||
|
- Wide range of densities (very application dependent)
|
||||||
|
- Limited resources for each device
|
||||||
|
- low amount of energy
|
||||||
|
- low cost, size and weight
|
||||||
|
- nodes may not have a global ID (e.g. an IP)
|
||||||
|
- Mostly static topology
|
||||||
|
|
||||||
|
- Service in WSN (not simply moving bits like traditional networks)
|
||||||
|
- in-network processing
|
||||||
|
- provide answers
|
||||||
|
- comunication is triggered by events
|
||||||
|
- asymmetric flow of information (from sensors to sink)
|
||||||
|
- QoS
|
||||||
|
- traditional metrics do not apply
|
||||||
|
- Fault tollerance
|
||||||
|
- be robust against node failure
|
||||||
|
- running out of energy, physical destruct
|
||||||
|
- Lifetime
|
||||||
|
- the network should fulfill as long as possible
|
||||||
|
- lifetime of individual nodes relatively unimportant
|
||||||
|
- but if a critical node dies, the network dies
|
||||||
|
- Programmability
|
||||||
|
- being able to re-program nodes on-field, to improve flexibility
|
||||||
|
- Maintainability
|
||||||
|
- WSN has to adapt to changes
|
||||||
|
|
||||||
|
#### Typical Adopted Mechanisms
|
||||||
|
- Multi-hop wireless communication
|
||||||
|
- Energy-efficient operation (both for computation, sensing, actuation)
|
||||||
|
- Self-configuration
|
||||||
|
- Collaboration & in-network processing
|
||||||
|
- the nodes in the network collaborate towards a joint goal
|
||||||
|
- pre-processing the data before sending it to the sink, to improve efficiency
|
||||||
|
|
||||||
|
#### Mechanism to meet requirements
|
||||||
|
- Data centric networking
|
||||||
|
- focussing network design on data, not on node identifiers
|
||||||
|
- Locality
|
||||||
|
- do things locally as far as possible
|
||||||
|
- Exploit tradeoffs
|
||||||
|
- e.g between invested energy and accuracy
|
||||||
|
|
||||||
|
> [!PDF|yellow] [[3 WSN.pdf#page=29&color=yellow|3 WSN, p.29]]
|
||||||
|
> > WSN: reasoning of existence
|
||||||
|
>
|
||||||
|
> collect, couple, provide, establish
|
||||||
|
#### Main sensor node components
|
||||||
|
- antenna and RF transceiver
|
||||||
|
- memory unit
|
||||||
|
- CPU
|
||||||
|
- sensor unit (i.e. thermostat)
|
||||||
|
- power source (typ. battery)
|
||||||
|
- operating system
|
||||||
|
- TinyOS
|
||||||
|
|
||||||
|
sensing, processing and networking is all done by the sensor node.
|
||||||
|
|
||||||
|
#### WSN vs conventional networks
|
||||||
|
|
||||||
|
| **Conventional networks** | **WSN** |
|
||||||
|
| ------------------------------------------------------------------- | --------------------------------------------------------- |
|
||||||
|
| general purpose design | serving a single application or a bouquet of applications |
|
||||||
|
| network performance and latency | energy is the primary challenge |
|
||||||
|
| devices and networks operate in controlled / mild environments | unattended, harsh conditions & hostile environments |
|
||||||
|
| global knowledge is feasible and centralized management is possible | localized decisions - no support by central entity |
|
||||||
|
#### Wireless signal issues
|
||||||
|
- **Attenuation**: the strength of the signal decreases rapidly over distance
|
||||||
|
- **Multi-path propagation**:
|
||||||
|
- when a radio wave encounter an obstacle, all or part of the wave is reflected, with a loss of power
|
||||||
|
- a source signal can arrive, to successive reflections, to reach a station through multiple paths
|
||||||
|
- **Interference:**
|
||||||
|
- from the same source (multi-path propagation): signal arrives multiple time
|
||||||
|
- from multiple sources: more stations transmit simultaneously
|
||||||
|
|
||||||
|
We use **SNR** to measure the ratio of good to bad signal (signal to noise). Higher is better.
|
||||||
|
|
||||||
|
> [!PDF|yellow] [[3 WSN.pdf#page=49&selection=77,0,77,15&color=yellow|3 WSN, p.49]]
|
||||||
|
> > Synchronization
|
||||||
|
>
|
||||||
|
> nodes have clocks but they may not be synchronized!
|
||||||
|
|
||||||
|
To address these issues, we use MAC protocols. We need a protocol suitable for wireless networks, which emphasize energy-efficient operation.
|
||||||
|
|
||||||
|
##### MAC protocols:
|
||||||
|
- controls how the shared medium is used by different devices
|
||||||
|
- controls when to send a packet and when to listen for a packet
|
||||||
|
- avoids collisions, reducing retransmissions
|
||||||
|
- increases energy efficiency, aviding idle listening
|
||||||
|
- allows scalability, lower latency, fairness and better throughput
|
||||||
|
|
||||||
|
##### Reasons of energy waste:
|
||||||
|
- collisions
|
||||||
|
- overhearing: a node receive packets destined to others
|
||||||
|
- overhead caused by control-packets
|
||||||
|
- idle listening
|
||||||
|
- overemitting: transmitting before the destination node is ready
|
||||||
|
|
||||||
|
#### Techniques for WSN MAC
|
||||||
|
- Contention based
|
||||||
|
- on-demand allocation for those that have frames for transmission
|
||||||
|
- sensing the carrier before transmitting
|
||||||
|
- scalable, no center authority
|
||||||
|
- idle listening / interference / collisions / traffic fluctutations -> higher energy consumption
|
||||||
|
- hidden/exposed terminal problem
|
||||||
|
- Scheduled based:
|
||||||
|
- schedule that specifies when, and for how long, each node may transmit over the shared medium
|
||||||
|
- energy efficient
|
||||||
|
- interference, collisions are not a problem
|
||||||
|
- synchronization is a problem
|
||||||
|
- there is a central authority
|
||||||
|
### CSMA/CA
|
||||||
|
In wireless network we cannot detect collisions and interrupt an ongoing transmission. But we can try to avoid them as much as possible.
|
||||||
|
|
||||||
|
|
||||||
|
![[Pasted image 20241002114133.png]]
|
||||||
|
|
||||||
|
Contention window is random, so hopefully only a node starts transmitting at the same time. The backoff clock is randomly chosen between [0, CW-1], where CW represents a contention window.
|
||||||
|
|
||||||
|
The first station whose clock expires starts transmission. Other terminals sense the new transmission and freeze their clocks to be restarted after the completion of the current transmission in the next contention period. Length of backoff time is exponentially increased (doubled) as the station goes through successive retransmissions.
|
||||||
|
|
||||||
|
![[Pasted image 20241002234319.png]]
|
||||||
|
|
||||||
|
By using different IFS sizes, we can prioritize some packets.
|
||||||
|
- SIFS is used for immediate responses (ACK, CTS, polling response)
|
||||||
|
- PIFS (Point coordination function IFS): medium priority, for real time services, is SIFS + 1 time slot
|
||||||
|
- DIFS (Distributed coordination funcion IFS): lowest priority, for async data service, is SIFS + 2 time slots
|
||||||
|
|
||||||
|
#### DFC CSMA/CA with ACK
|
||||||
|
- stations has to wait for DIFS before sending data
|
||||||
|
- receiver ACKs immediately (after waiting for SIFS) if the packet was received correctly (CRC is valid)
|
||||||
|
- ACK is transmitted without sensing the medium
|
||||||
|
- if ACK is lost, retransmission will be done
|
||||||
|
|
||||||
|
![[Pasted image 20241002235016.png]]
|
||||||
|
|
||||||
|
|
||||||
|
#### Problems
|
||||||
|
- Hidden terminal
|
||||||
|
- Exposed terminal
|
||||||
|
|
||||||
|
We fix both of them with RTS/CTS:
|
||||||
|
- transmitter sends an RTS (request to send) after medium has benn idle for time interval more than DIFS
|
||||||
|
- receiver responds with CTS (clear to send) after medium has been idle for SIFS
|
||||||
|
- data is transmitted
|
||||||
|
- RTS/CTS is used for **reserving channel** for data transmission so that the collision can only occur in control message.
|
||||||
|
![[Pasted image 20241002235259.png]]
|
||||||
|
|
||||||
|
Both of the problems are solved!
|
||||||
|
|
||||||
|
However, collisions are still possible as RTS packets can collide. But RTS packets are small, RTS collisions are not as bad as data collisions.
|
||||||
|
|
||||||
|
### Network Allocation Vector (NAV)
|
||||||
|
- provides *Virtual Carrier sensing*
|
||||||
|
- most 802.11 frames carry a duration field
|
||||||
|
- transmitter sets the NAV to the time for which it expects to use the medium
|
||||||
|
- other stations starts counting down from NAV to 0
|
||||||
|
- If NAV > 1, transmission is delayed. When NAV = 0, carrier is sensed.
|
||||||
|
|
||||||
|
![[Pasted image 20241002235837.png]]
|
||||||
|
|
||||||
|
##### CSMA/CA with RTS/CTS (NAV)
|
||||||
|
- receiver receives RTS and sends CTS after SIFS
|
||||||
|
- CTS again contains duration field
|
||||||
|
- all the stations receiving the CTS need to adjust their NAV
|
||||||
|
- sender sends data after SIFS
|
||||||
|
- receiver sends ACK after SIFS
|
144
Autonomous Networking/notes/4 WSN pt. 2.md
Normal file
|
@ -0,0 +1,144 @@
|
||||||
|
### 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
|
BIN
Autonomous Networking/slides/3 WSN.pdf
Normal file
BIN
Autonomous Networking/slides/4 WSN2.pdf
Normal file
56
BUCA/Queues.md
Normal file
|
@ -0,0 +1,56 @@
|
||||||
|
Challenges
|
||||||
|
- Atomicity
|
||||||
|
- you write to the queue first
|
||||||
|
- you write to the db first
|
||||||
|
- we need a transaction!
|
||||||
|
- Idempotence
|
||||||
|
- we need locking mechanism on the queue, to avoid multiple process to process the same element
|
||||||
|
- solution: replay protection (lastUpdate in the db), but still I have the problem of multiple process reading the same element
|
||||||
|
|
||||||
|
## Data replication
|
||||||
|
- Waiting for all replicas
|
||||||
|
- definitely slower
|
||||||
|
- safer for the data
|
||||||
|
- Waiting only for the primary replica
|
||||||
|
- faster but...
|
||||||
|
- replica may fail
|
||||||
|
- not getting always the same value
|
||||||
|
- ok for maybe Instagram feed, but not for e-mails
|
||||||
|
|
||||||
|
## Paxos
|
||||||
|
Paxos overview:
|
||||||
|
- partecipnats are: Writers & Replicas
|
||||||
|
- 2 phase protocol:
|
||||||
|
- **prepare** reserves right to supply value, and robs other
|
||||||
|
- **accepts** supplies the value **v**
|
||||||
|
- replicas are stateful
|
||||||
|
- communication is ordered by "proposal number" **n**
|
||||||
|
- uses "viral propagation"
|
||||||
|
|
||||||
|
#### Algorithm
|
||||||
|
- Prepare phase
|
||||||
|
- Success if replica hasn't prepared a higher proposal
|
||||||
|
- Fail otherwise
|
||||||
|
- Success with value if we have accepted another value (viral property)
|
||||||
|
|
||||||
|
Majority succeded -> Go to Accept Phase
|
||||||
|
|
||||||
|
- Accept phase
|
||||||
|
- Success only if replica hasn't Prepared a higher proposal (same is ok)
|
||||||
|
|
||||||
|
### Mesh
|
||||||
|
- full mesh
|
||||||
|
- subsetting: not every node connected to every other node: in case of a query of death, only connected nodes will fail
|
||||||
|
- proxying: adding a layer of proxies (load balancers), that use a lookup service to route the request
|
||||||
|
|
||||||
|
### Strong stickiness
|
||||||
|
Some applications like chat, online game servers, video calls ecc. need a very strong stickiness.
|
||||||
|
In these cases, we may not want to use consistent hashing. Maybe we can use it to pick a server and then stick with it.
|
||||||
|
|
||||||
|
Also, it can happen that some users are not able to reach a specific server, but other does.
|
||||||
|
Using leases might be a solution.
|
||||||
|
|
||||||
|
- Request from Alice
|
||||||
|
- lookup server response is cached
|
||||||
|
- we have a failure
|
||||||
|
- we call Set to change the server, but the call stalls until the lease expires. Also, the lookup server might be able to still reach the server and renew the lease
|
136
Biometric Systems/final notes/2. Performance indexes.md
Normal file
|
@ -0,0 +1,136 @@
|
||||||
|
#### Problems of biometric systems:
|
||||||
|
- wide intra-class variations
|
||||||
|
- maybe different facial expression, different light, different view point...
|
||||||
|
- very small inter-class variations
|
||||||
|
- two different person very similar (i.e. twins)
|
||||||
|
|
||||||
|
- possible spoofing attacks, in different moments
|
||||||
|
![[Pasted image 20241002181936.png]]
|
||||||
|
|
||||||
|
- [non universality](LEZIONE2_Indici_di_prestazione.pdf#page=6&selection=0,10,0,26&color=yellow|LEZIONE2_Indici_di_prestazione, p.6)
|
||||||
|
- e.g. people with no voice, people with cataract, people with poor fingerprints...
|
||||||
|
|
||||||
|
Most difficult traits to exploit:
|
||||||
|
- retina fundus
|
||||||
|
- behavioral traits (i.e. way of walking)
|
||||||
|
- handwriting
|
||||||
|
|
||||||
|
### [What to compare?](LEZIONE2_Indici_di_prestazione.pdf#page=8&selection=0,10,0,26&color=yellow|LEZIONE2_Indici_di_prestazione, p.8)
|
||||||
|
- **Sample
|
||||||
|
- raw captured data
|
||||||
|
- **Hand-crafted features**
|
||||||
|
- manually engineered by the data scientist and extracted from samples
|
||||||
|
- can also be substituted with **embeddings**: features automatically extracted by deep architectures
|
||||||
|
- **Template**
|
||||||
|
- collection of features extracted from the row data, examples:
|
||||||
|
- a histogram representing the frequencies of relevant values in the image (e.g. greylevel values)
|
||||||
|
- a vector of values each representing a relevant measure (e.g. Bertillon measures)
|
||||||
|
- time series of acceleration values (one per axis)
|
||||||
|
- a set of triplets as for relevant fingerprint points representing the coordinates of the points and the direction of the tangent to the ridge in that point.
|
||||||
|
|
||||||
|
|
||||||
|
> [!PDF|red] [[LEZIONE2_Indici_di_prestazione.pdf#page=8&selection=11,1,14,16&color=red|LEZIONE2_Indici_di_prestazione, p.8]]
|
||||||
|
> > Hand-crafted features
|
||||||
|
>
|
||||||
|
> not the template of the entire biometric system.
|
||||||
|
|
||||||
|
|
||||||
|
### Comparing templates
|
||||||
|
- Euclidian distance
|
||||||
|
- Cosine similarity
|
||||||
|
- cosine of the angle between two vectors
|
||||||
|
- affected also by the direction of the vectors
|
||||||
|
- Pearson correlation (for histograms or sets of points)
|
||||||
|
- statistical measure that evaluates the **linear relationship** between two variables. It tells you whether an increase or decrease in one variable tends to correspond with an increase or decrease in another, and how strong that relationship is (ChatGPT)
|
||||||
|
- Bhattacharyya distance (histograms)
|
||||||
|
- measure of the similarity (or dissimilarity) between two probability distributions
|
||||||
|
- the Bhattacharyya distance can compare feature distributions between two different classes (e.g., color histograms of objects)
|
||||||
|
|
||||||
|
> [!PDF|yellow] [[LEZIONE2_Indici_di_prestazione.pdf#page=10&selection=3,1,4,21&color=yellow|LEZIONE2_Indici_di_prestazione, p.10]]
|
||||||
|
> > (Pearson) Correlation
|
||||||
|
>
|
||||||
|
> how signals are similar to eachother. Often used to compare fingerprints, by computing the correlation between two fingerprints.
|
||||||
|
|
||||||
|
For time series we have to address an issue: temporal sequences may vary in speed or timing, e.g. in two repetitions of a walking sequence, there might be differences in walking speed between repetitions, but the spatial path of limbs remain highly similar.
|
||||||
|
Another example could be audio recordings, same voice but different speed.
|
||||||
|
|
||||||
|
Dynamic Time Warping allows for "warping" of the time axis, meaning it can stretch or compress sections of the sequences to achieve the best possible alignment. This is useful when parts of one sequence are faster or slower than the corresponding parts in the other sequence.
|
||||||
|
|
||||||
|
|
||||||
|
![[Pasted image 20241002135922.png]]
|
||||||
|
|
||||||
|
each point is paired with the most convenient one. It's not necessarily that points corresponds to the same instant in time.
|
||||||
|
|
||||||
|
##### Comparing the results of submitting a template to a Deep Learning model
|
||||||
|
- if using deep learning we should use the architecture to extract the embeddings (for both gallery and probe templates): we can delete the classification layer in order to get the embeddings that the architecture would use for the final classification.
|
||||||
|
- mbeddings can be compard as they were vectors of hand-crafted features.
|
||||||
|
|
||||||
|
### Possible errors: verification
|
||||||
|
- Genuine Match (GM, GA): the claimed identity is true and subject is accepted
|
||||||
|
- False Rejection (FR, FNM, type I error): claimed identity is true but the subjet is rejected
|
||||||
|
- Genuine Reject (GR, GNM): an impostor is rejected
|
||||||
|
- False Acceptance (FA, FM, type II error): an impostor is accepted :/
|
||||||
|
|
||||||
|
It's important to define a good threshold.
|
||||||
|
If too high we will get a lot of false acceptance. If too low we will get a lot of false rejection!
|
||||||
|
|
||||||
|
When computing rates:
|
||||||
|
- **False Rejection Rate (FRR)** is the number of FR divided by the number of GM+FR.
|
||||||
|
- in fact, GM and FR have the same denominator and sum up to 1.
|
||||||
|
- **False Acceptance Rate** is the number of FA divided by total number of impostor attempts (FA + GR)
|
||||||
|
- **Equal Error Rate** is the value at a specific threshold, where FAR and FRR are the same value.
|
||||||
|
- **Detection Error Trade-off:** a plot that shows the **trade-off** between the **FAR** and **FRR** at different threshold settings of a system
|
||||||
|
- **Receiving Operating Curve:** a plot that shows the True Positive Rate (TPR) (also called **Sensitivity**) against the False Positive Rate (FPR) (1 - Specificity) at various threshold settings.
|
||||||
|
|
||||||
|
Key Differences Between ROC and DET Curves:
|
||||||
|
- **ROC Curve**: Focuses on the **true positives** and **false positives**, showing the ability to discriminate between classes (genuine vs impostor).
|
||||||
|
- **DET Curve**: Focuses on the **false rejection rate (FRR)** and **false acceptance rate (FAR)**, helping to analyze trade-offs between security and usability in verification systems.
|
||||||
|
|
||||||
|
Two synthetic metrics for instance could be ERR and area below ROC curve.
|
||||||
|
|
||||||
|
(we might have more templates for the same person to address inter-class variation.
|
||||||
|
Of course templates should be different, not computed i.e. by frames of the same video, as some of them could be blurred and close frames are exactly the same!)
|
||||||
|
|
||||||
|
> [!PDF|yellow] [[LEZIONE2_Indici_di_prestazione.pdf#page=20&selection=119,0,119,4&color=yellow|LEZIONE2_Indici_di_prestazione, p.20]]
|
||||||
|
> > When
|
||||||
|
>
|
||||||
|
> in false acceptance we can have two possible scenarios
|
||||||
|
> - pj does not belong to the gallery (most trivial)
|
||||||
|
> - pj belongs to an enrolled subject but the probe claimed another identity, not the real one.
|
||||||
|
|
||||||
|
What if ERR in two systems is the same, but the curves are different?
|
||||||
|
|
||||||
|
We can use ROC curve or DET curve.
|
||||||
|
For ROC, we can compute the area below the curve and use it as a metric, the higher the better.
|
||||||
|
|
||||||
|
#### Possible errors: identificaiton - open set
|
||||||
|
In an open set identification task, the system determines if the individual's biometric signature matches a signature of someone in the gallery.
|
||||||
|
The individual **does not make** and identity claim.
|
||||||
|
- More possible error situations, depending on the matcher and on the threshold
|
||||||
|
- A problem may occur if the system returns more possible candidates below the threshold. Who is the right one?
|
||||||
|
> [!PDF|yellow] [[LEZIONE2_Indici_di_prestazione.pdf#page=27&selection=0,8,9,8&color=yellow|LEZIONE2_Indici_di_prestazione, p.27]]
|
||||||
|
> > Possible errors: identification – open set
|
||||||
|
>
|
||||||
|
>
|
||||||
|
|
||||||
|
correct detect and identify rate = rate over which the correct individual has the identified score and so is identified correctly.
|
||||||
|
|
||||||
|
false alarm rate = rate over which unenrolled users are identified as another user in the db.
|
||||||
|
|
||||||
|
We compute that by testing the system with lots of probes belonging to set Pg if enrolled or set Pn if not.
|
||||||
|
|
||||||
|
|
||||||
|
We define
|
||||||
|
- rango(pj) = the position in the list where the first template for the correct identity is returned
|
||||||
|
- DIR (at rank k) (Detection and Identication Rate (at rank k)): the probability of correct identification at rank k (the correct subject is returned at position k)
|
||||||
|
- The rate between the number of individuals correctly recognized at rank k and the number of probes belonging to individuals in PG
|
||||||
|
- If identification does NOT happen at rank 1, we have a False Reject.
|
||||||
|
- FRR or more specifically FNIR (False Reject Rate or False Negative Identification Rate): the probability of false reject expressed as 1 - DIR (at rank 1)
|
||||||
|
|
||||||
|
- FAR or more specifically FPIR (False Acceptance Rate or False Positive Identification Rate) or False Alarm Rate (Watch List): the probability of false acceptance/alarm
|
||||||
|
- The rate between the nuber of impostor recognized by error and the total number of impostors in PN
|
||||||
|
|
||||||
|
|
||||||
|
#### Closed set
|
||||||
|
We don't have thresholds!
|
||||||
|
The only possible error is that the correct identity does not appear at rank 1.
|
BIN
Biometric Systems/images/Pasted image 20241002135922.png
Normal file
After Width: | Height: | Size: 37 KiB |
BIN
Biometric Systems/images/Pasted image 20241002181932.png
Normal file
After Width: | Height: | Size: 143 KiB |
BIN
Biometric Systems/images/Pasted image 20241002181936.png
Normal file
After Width: | Height: | Size: 143 KiB |
BIN
Foundation of data science/slides/FDS_intro_new.pdf
Normal file
12
Foundation of data science/slides/Untitled.md
Normal file
|
@ -0,0 +1,12 @@
|
||||||
|
$$f[[m,n]+[m^{\prime},n^{\prime}]]=f\left\lbrack m+m^{\prime},n+n^{\prime}\right\rbrack=f\left\lbrack m,n\right\rbrack+f\left\lbrack m^{\prime},n^{\prime}\right\rbrack
|
||||||
|
|
||||||
|
|
||||||
|
$$
|
||||||
|
$$\sum_{k,l}{I[(m+m')-k,(n+n')-l]g[k,l]}=\sum_{k,l}{I[m-k,n-l]g[k,l]}+\sum_{k,l}{I[m'-k,n'-l]g[k,l]}$$
|
||||||
|
|
||||||
|
$$\sum_{k,l}{I[(m+m')-k,(n+n')-l]g[k,l]}=\sum_{k,l}{I[m-k,n-l]g[k,l] + I[m'-k,n'-l]g[k,l]}$$
|
||||||
|
|
||||||
|
$$\sum_{k,l}{I[(m+m')-k,(n+n')-l]g[k,l]}=\sum_{k,l}{(I[m-k,n-l] + I[m'-k,n'-l])g[k,l]}$$
|
||||||
|
|
||||||
|
$$\sum_{k,l}{I[(m+m')-k,(n+n')-l]g[k,l]}=\sum_{k,l}{I[(m+m')-k,(n+n')-l]g[k,l]}$$
|
||||||
|
|
47
Foundation of data science/slides/notes 2.md
Normal file
|
@ -0,0 +1,47 @@
|
||||||
|
#### Object recognition
|
||||||
|
Different types of recognition
|
||||||
|
- object identification
|
||||||
|
- object classification
|
||||||
|
|
||||||
|
##### Which level is right for Object Classes?
|
||||||
|
- Basic-Level Categories
|
||||||
|
|
||||||
|
###### Challenges
|
||||||
|
- multi-view: different view points
|
||||||
|
- multi-class: different types of the same object (different car models)
|
||||||
|
- varying illumination
|
||||||
|
- ecc
|
||||||
|
|
||||||
|
### Filtering basics
|
||||||
|
- Linear filtering
|
||||||
|
- Gaussian filtering
|
||||||
|
- Multi scale image representation
|
||||||
|
- gaussian pyramid
|
||||||
|
- edge detection
|
||||||
|
- recognition using line drawings
|
||||||
|
- image derivatives (1st and 2nd order)
|
||||||
|
- object instance identification using color histograms
|
||||||
|
- performing evaluation
|
||||||
|
|
||||||
|
probabilità dadi
|
||||||
|
$Px(5) = 1/6$
|
||||||
|
$Py(5) = 1/6$
|
||||||
|
$Px+y(5) = ?$
|
||||||
|
|
||||||
|
We can count the possible cases
|
||||||
|
total cases: $6*6=36$
|
||||||
|
|
||||||
|
|
||||||
|
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
|
||||||
|
| --- | --- | --- | --- | --- | --- | --- |
|
||||||
|
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
|
||||||
|
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
|
||||||
|
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
|
||||||
|
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
|
||||||
|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|
||||||
|
| | 1 | 2 | 3 | 4 | 5 | 6 |
|
||||||
|
|
||||||
|
possible cases: $P(3)P(1)+P(2)P(2)+P(1)P(3)$
|
||||||
|
|
||||||
|
|
||||||
|
$P[x*y](S) = $
|