IOT

Gateways provide networking between the internet and the smart devices. However they are not always necessary, e.g in Cloud based or mesh based applications.

consists of all necessary hard- and software components for an application

software suite or cloud service that monitors and manages iot systems or applications

horizontal: general purpose (often provided by cloud providers)

vertical: domain specific (often with better analytics support for their specific area)

devices have minimal capabilites

gateways take over part of the cloud functionalities and often communicate with each other

supported by cloud providers

devices have minimal capabilites

gateways (if existing) only offer cross cutting functionality

everything else is done in the cloud

devices take over most functionalities themselves

often communicate with each other directly

gateways and cloud act as a fallback if anything

data item sizes

inefficient content encoding

huge overhead, difficult parsing

not optimised for energy saving

large buffers needed

dedicated end-point addressing

pull vs push

Internet Protocol

widely adopted

backbone of the internet

exisiting hardware is specialised for ip

1. Application layer proxy

   • dedicated protocol stacks (Zigbee, BLE)

   • proxy stores data locally and makes it available via standard internet protocols

   • proxy is usually the iot gateway

2. IP router

   • use IP directly on Smart Things

   • each thing is a host on the internet

   • router MAY be combined or MAY replace Iot gateway

1. PHY

   • lowest layer

   • manages physical transmission of bits via a physical medium (electricity, light, rf)

   • defines characteristics of the physical medium

2. MAC

   • second layer

   • manages access to a shared physical medium

   • implements protocols that handle media access control, addressing, data frame creation etc.

     
     

Pros:

• 16 bit allows for reasonable many devices

• designed for small payloads => large address takes away valuable space

• reduced overhead => power efficiency

• simplicity and compatibility

Cons:

• Limited acess space

• lack of global uniqueness

• address collisions

• difficult integration with growing ipv6 adoption

predefined time structure

organizes data transmission

devides time into fixed-length intervals

beacon is a frame that serves as a timing reference

coordinator sends out superframe with timing information

devices use this information to align their transmissions

1. Active Period

   a. Contention Access Period (CAP):

   • devides can contend for access to the channel using CSMA/CA

   b. contention free period:

   • optional

   • important devices get garantueed time slots for their transmission

2. inactive period

   • time between two consecutive beacons where the channel is inactive

   • devices that dont have any data to transmit can enter low power state to conserve energy

Carrier Sense Multiple Access with Collision Avoidance

1. Carrier Sense:

   • Before transmitting a device listens if the channel is free otherwise it waits until its free

2. Collision Avoidance

   • before sending a device performs a virtual carrier sensing

   • it sends out a request to send packet to the destination

   • destination responds with clear to send packet

3. Backoff mechanism

   • even after rts-cts exchange a random amount of time is being waited so that the probability of a different device choosing the same time slot becomes even smaller

• used in time sensitive applications

• time is divided into discrete slots

1. Time Slot Synchronization

   • devices are synchronized to a common time reference (PAN Coordinator with superframe structure)

2. contention period

   • devices wait for channel to go idle so they can start transmitting

3. Backoff mechanism

   • if channel is busy devices wait for random backoff time to reduce probability of collision

4. virtual carrier sense with rts-cts handshake

5. if device gains control of the channel it starts to transmit at the start of the next channel

1. A set of available communication channels is defined

2. the transmitter and receiver agree on a hopping sequence (often generated by pseude random algorithms)

3. both devices synchronize their hopping sequence

4. when transmitting data the devices hop from one frequency channel to another

TDMA = Time Division Multiple Access

• channel gets whole frequency spectrum but only for a small amount of time

FDMA = Frequency Division Multiple Access

• channel gets one specififc frequency band for the whole time

1. Randomization

   • the backoff window is chosen at random so it might be very low

   • if the channel becomes idle before the time passed transmission can start anyway

   • retransmission limit

     • if limit is reached device waits for the next possible opportunity which can lead to short overall delays

Network consists of cells

Each cell has a very powerful fixed location transciever (cell tower)

Together all cells span a huge geographical area#

cell towers are connected to a core network

core network handles complicated stuff like routing, security etc

1. Standalone in GSM Band

   • NB-IoT gets one 200kHz GSM Channel

2. LTE Guard Band Channel

   • NB-IoT gets one channel in LTE Guard band

   • Doesnt affect LTE capacity

   • unused spectrum

3. Inside the LTE channel

   • Time-share a resource with an LTE carrier

   • highly flexible

Multiple logical channels are mapped to multiple physical channels by time and frequency multiplexing

1. Frequency Multiplexing

   • distinguish between up and down link

2. Time Multiplexing

   • distinguish between different channels

1. Signaling Channels

   • used for control data

2. Data channels

   • used for user data

UE needs to find a cell when powered on for the first time

1. UE listens on broadcast channel to receive cell information from eNB (cell tower)

2. checks if cell is joinable

3. compares signal quality and strength

4. if quality above a threshhold UE joins cell

   • choose best one if multiple are found

short data transmissions => switching between cells while transmitting is not necessary or possible

if serving cell becomes to weak ue searches for new one as if it joins for the first time

UE not always a full member of a cell

UE becomes active only if needed

otherwise UE is idle

• no radio resources but synchronized and tracked by cell

• ue keeps network informed about location via Tracking Area Updates and monitors for page messages

• Gateway buffers incoming data for UE

Uplink:

1. Via Data Channel

   1. UE signals eNB, requesting access to data chennel

   2. enB assigns time slots in data channel to UE

   3. UE starts sending in assigned time slots

   4. connection is closed, slots freed

2. Via control channel

   1. UE builds up an RRC connection to eNB via control channel to get access to data channel

   2. message can be piggybacked on connection establishment messages

      
      

Downlink:

1. eNB sends paging signal into cell

2. Paging signal can contain multiple UEs for which messages are there

3. UE can then setup data channel to receive data (both versions as in Uplink)

Multiple cells identified by one tracking area identifier

If UE selects new cell with same TAI (Tracking area identifier) as previous cell => no update required

If new cell has different TAI => inform MME (core network) by sending tracking area update

If UE needs to be paged page request is sent to all cells within the ast updated tracking area

to receive a message UE only needs to listen to paging signals

Paging is done only at specific times

• 1.28s paging window at beginn of each 10.24s hyper frame

eDRX lets UE specify number of hyper frames it wants to sleep

messages for UE are buffered in core network

one step further

Power saving mode:

• UE goes to sleep indefinitely

• cant be reached or paged

• when it awakes it transmits and stays in receive mode for 4 idle frames

NB-IOT reuses LTE core network -> fully IP-Based => direct support for IP

UEs that are not powerful enough for full fletched IP need middle layer

1. IEEE 802.15.4 has a maximum MTU of 127 bytes but IPv6 need at least 1280

   • 6LowPan allows fragmentation below IPv6

2. Limited configuration

   • manual configuration (ip address zuweisung) not suitable for billions of devices

   • ipv6 provides basic autoconfiguration but does not take 16 bit addresses into account

3. Large header overhead

   • takes away most of the payload size available in 802.15.4 frame

• ip packet encapsulation with different encapsulation header stacks

• multiple headers can appear in one encapsulation header stack

Order:

1. Mesh addressing header

2. Broadcast header

3. fragmentation header

4. compression dispatch header

Allows host to assign itself a local link IPv6 address (no routing)

no dhcp needed => no table of assigned ip addresses maintained => stateless

based on 16 or 64 bit addresses

if a fragment is lost the whole packet is dropped and not retransmitted

if the order of the fragments changes due to transmission problems it can be rearranged thanks to the datagram offset

it does not replace ip fragmentation but it merely supports it

whenever possible other options should be used like header compression because fragmentation increases overhead and in unreliable environments it increases the risk of packet loss

1. Format Identifier

   • HC1 uses a 3 bit FID to indicate that it is Type 1 compression => 000

2. Stateless or Stateful mode

   • Stateless:

     • in this mode each compressed packet is independent of the previous

     • all necessary information for decompression is contained in each packet

   • Stateful:

     • decompression depends on context information between sender and receiver

     • suitable for stateful protocols like tcp

3. Most IPv6 header fields can be derived

   • only hop limit must be transmitted in full

   • if assumptions arent met => transmit as uncompressed field right after compressed part

     • best case: Header reduced from 40 bytes down to 2 bytes

     • wors case: uncompressed header

• compresses higher layer protocol headers

  • available for UDP, TCP, ICMP

• HC2 compression immediately follows HC1 encoding field (before uncompressed fields)

  
  

• HC2 can reduce UDP header overhead to 4 Byte (down from 8 Byte) for a total of 6 Bytes instead of 48 (HC1+HC2)

IPHC = IP Header Compression

adds ability to compress global and multicast addresses

new compression scheme for next headers

best case: compresses IPv6 header to 2 Byte just like HC1

for routed messages: compresses header down to 6 byte instead of 34 bytes like hc1

Publish / subscribe messaging protocol for Machine 2 Machine communication

based on tcp

logical star topology

Message Queuing Telemetry Transport

MQTT packets can contain a set of properties

• e.g metadata

• arbitrary UTF-8 string key-value pairs

• can encode any kind of metadata

• similar to HTTP header concept

Topics are human readable strings

clients publish and subscribe to topics

messages are only forwarded to clients that subscribed to the topic

Wildcard +:

• matches any SINGlE directory name

Wildcard #:

• matches any number of directories of any name

Wildcards cannot be used to publish

Sending topic string in every message leads to large overhead

=> replace topic with integer id

sender can cerate topic alias y sending publish message with topic string and topic alias value

receiver store topic string and alias

only topic alias is sent afterwards

client side load balancing

multiple clients subscribe to same topic and receive messages in a circle

signalled by leading $share

client can ask broker for a persistent session on join

broker queues messages while client is offline and sends queued messages to client when it reconnects

not specified if client never reconnects

mqtt5 introduces message expiry => publisher specifies for how long a message should be stored by broker (default for ever)

requester sends request with a response topic and optionally correlation data to identify which request belongs to what response

requester then subscribes to response topic

responder receives message through normal subscription then publishes response to response topic including the correlation data

client can request to retain a message by setting the retain flag

broker saves message and publishes it to each client that subscribes to the topic

next retain message overwrites the previous

can be used to notify about last valid measurement or about device specific properties

Clients can disconnect gracefully and ungracefully

Last will and testament message is stored by the broker and published after a watchdog fires if connection to client is lost

if the client disconnects gracefully the message wont be sent

1. QOS 0

   • message may be lost

   • example: sensor reading

2. QOS 1

   • message assured to arrive at least once

   • example appliance activation command

3. QOS 2

   • message assured to arrive exactly once

   • example: billing system

subscribers can downgrade delivered qos level but cant upgrade to a higher qos than the publisher sent the message

1. Stream compression

2. Update protocols

   • reduce number of sent messages

     • saves network traffic

     • reduces energy consumption

   • applicable for data that changes continuously, not discrete data

• basic approach

• send update every x seconds

• how to find good update frequency

  • f_min = 1 / (acc/v_max)

• might lead to unnecessary updates if acutal speed is lower than max speed

• send update message as late as possible

  • only send if dist(m1, m2) >= acc

• goal is to achieve max sleep time

• Δt = (acc-dist(m0, mt)) / v_max

• only send update if

• tsleep > max(t_sleep_min, d_m)

• sleep times may become very small close to acc threshold

• IDEA: compare energy consumption of immediate sending vs waiting for another turn

• future energy consumption is unknown

  • Next Fix Heuristic:

    • sending an update and sleeping = Eupd = (E_update+E_sense)/t_sleep_0

    • Sleeping without sending E_no_update = E_sense / t_sleep_t

    • Send if E_upd < E_no_update

  • Predicted Movement:

    • assumes linear movement

    • extends next fix by taking into account predicted future movement to determin expected energy consumption of whole cycle

    • sending update starts new cycle

    • not sending continues current cycle

      
      

• Predict future state of a remote entity based on its current state

• use predicated state locally

1. Send current state and expected update function for each data source

2. each data sink (device) calculates state for itself locally

3. periodically compare actual with calculated state

   • possibly with a new update function

Good for simple movements

Large overhead for complex update functions

• needs to be balanced with message reduction

Difficult to select best update function

• minimize loss function

  • different loss functions can be deployed

    • e.g Mean Square Error

  • most well known learning algo: backpropagation with gradient descent

• adapt weights to difference between computed and expected result

  
  

• reduced latency

• increased privacy

• reduced data transfers

• increased reliability

• reduce amount of computations

• reduce cost of each computation

• reduce memory footprint

=> pruning and quantisation

1. Pruning

   • remove all weights that arent important

2. Quantisation

   • reduce number of bits to represent numbers

1. Remove all weights below a certain threshold

2. retrain pruned network

3. prune again

Repeat until network is sufficiently small

=> can introduce huge errors into the network

=> just because weight is small doesnt mean its impact is small

• need to consider introduced error when removing the weight

• compute impact of each weight on the training loss using a higher order derivation

• impact is called weight saliency

• low saliency weights are removed

  • remaining weights are tuned

• repeat until sufficiently small and accurate

• Using fewer bits to represent values

• optimal bit depth depends on application and hardware

• mixed precision network combines multiple bit depth accross the different layers

• replace floating point numbers with fixed point numbers

• use 1 bit for number representation

• normal network can be converted after training

• normal network can be converted step wise during training

• instead of complex multiplications calculations can be replaced by logic gates

  • insanely fast on fpga

  • extremely low memory footprint