Internet of Things 2018/2019

Size: px

Start display at page:

Download "Internet of Things 2018/2019"

Gregory Mathews
5 years ago
Views:

1 Internet of Things 2018/2019 Resource Management for Dependable IoT Tanir Ozcelebi John Carpenter,

2 What does resource management entail? Guiding questions What are the components of dependability? Dependability metrics Faults, errors and failures in the IoT application context What are the components of an IoT dependability framework? How does it work? Improving dependability via resource management and adaptation. 2

3 Resources (application context) Resource (definition): Anything that is needed for an application to run failure-free. R is a resource for application A means that A fails in the absence or scarcity of R. The resource R can be in many forms (e.g. computational hardware resources, network QoS, sensors, energy, physical space, people, data, any form of input to A, ). Failure (definition): An application is said to be in a failure state if it does not satisfy its specifications. May be due to lack of resources. Resource management (definition): The process of planning and governing the usage and allocation of available resources. E.g. for efficiency E.g. for avoiding failure states of target applications. 3

4 For comparison: Resource management (RM) of a computer by an OS OS resource management: It organizes sharing of hardware resources among processes and users to maximize performance. Examples: CPU scheduling, memory allocation, etc. PROCESSES RUNNING OS Performance (example metrics): allowed degree of multiprogramming size of process(es) number of computations per second (per process) average, max response times. HARDWARE 4

5 RM in networks In the context of networks, RM mechanisms are considered mainly to improve Quality of Service (QoS) aspects. = dependable operation. QoS: collective effect of service performance, which determines the degree of satisfaction of a user of the service. (ITU-T) User: any entity that utilizes the network for communication. Service: a set of functions offered to a user. Quality: wrt, e.g., packet delivery, throughput, delay, jitter etc. RM example: Congestion control If the network resources are correctly allocated, congestion can be avoided. 1. Buffer space in switches and routers 2. Bit rates of individual flows 5

6 A taxonomy of network RM mechanisms Router-centric vs. Host-centric Address problem from either inside or outside a network Router-centric: Routers decide upon packet dropping. Host-centric: End host observes the network, adjusts behavior accordingly. Reservation-based (ReB) vs. Feedback-based (FB) ReB: an end host asks for a certain amount of resources at the time of the flow establishment FB: an end host adjusts its sending rate according to the feedback from the receiving host either explicit or implicit feedback Window-based (WB) vs. Rate-based (RaB) WB: mostly in combination with FB RaB: mostly in combination with ReB 6

7 Evaluation concerns for network RM Q1: Which network RM mechanism is good? It depends on the requirements. Q2: What are the requirements? Resources must be allocated effectively (and fairly), with respect to a subset of flow characteristics. 7

8 IoT challenge IP applications are designed to run despite lack of guarantees wrt flow characteristics. Higher layer protocols (e.g. TCP for reliability) in combination with overprovisioning typically do the job. IoT applications must survive similar conditions. In addition: They can have very complex communication schemes. They utilize (also) resource constrained devices and networks. While availability of resources for running the TCP/IP stack, or availability of memory to maintain a reasonable history (state information, past data) are not concerns for the Internet world, these are serious concerns for the IoT world. It must strive to converge to the best reachable state, where the best is determined according to a set of metrics. A natural desire for optimal operation due to resource constraints. 8

Example: Witte Dame GGZ IoT lighting (in 10 weeks) Photos: Thomas vd Werff 43

RM addresses devices, services, applications and business cases:

Map lamps to controllers, give control to higher level controller in the

Physical space as a resource: Find employee patterns and use it to manage the

9 Example: Witte Dame GGZ IoT lighting (in 10 weeks) Photos: Thomas vd Werff 43 users, >1000 IoT devices (sensors, controllers, lamps). RM addresses devices, services, applications and business cases: Computational, network res.: E.g. Map lamps to controllers, give control to higher level controller in the hierarchy when a controller fails ( time-to-light as a constraint). Physical space as a resource: Find employee patterns and use it to manage the space. Energy as a resource: Switch between light scenes to minimize energy usage. Lamp as a resource: To be shared between multiple users / controllers. à conflicts! 9

10 IoT devices, services, applications 10

11 IoT devices, services, applications IoT Application IoT Application App. comp. 1 App. component 2 IoT Application IoT Service IoT Service IoT Service IoT Service System comp. IoT Device System component(s) IoT Network IoT Device IoT D. IoT D. IoT D. IoT Device IoT D. 11

12 IoT devices, services, applications 12

13 Against failure of IoT applications: Dependability Reliability Defined by mean time to failure (MTTF) of the application. For a long observation duration: Availability Probability (portion of the total time) that the application is up and running, satisfying its specification. Note that: Safety and security are also part of dependability, but are less relevant for RM. An application can have high reliability and low availability. E.g. fail every 1 year, take 10 months to recover. An application can have high availability and low reliability. E.g. fail every 10 days and take 10 seconds to recover. 13

14 Fault, error, failure (general) Definition (Failure): A directly observable state where the operation of an entity does not satisfy its specifications. Definition (Error): An incorrect unobservable (at least not directly observable) internal state, which may or may not lead to a failure. Definition (Fault): An incorrect external state, which may cause the error condition that may lead to a failure. Fault tolerance: The ability to avoid failure states in the presence of the fault. Relation between them: Fault Error Failure Dashed arrows because left-hand side does not imply the right-hand side. 14

Example: Dependability of an application Sensing module DATA_CONSUMER_1 Receiving buffer SENSOR_1 Transmitting buffer IoT data processing DATA_CONSUMER_2

15 Example: Dependability of an application Sensing module DATA_CONSUMER_1 Receiving buffer SENSOR_1 Transmitting buffer IoT data processing DATA_CONSUMER_2 DATA_CONSUMER_N SENSOR_2 Specification: Data processing on each consumer device processes all data collected by one of the sensors periodically (period: T). 15

16 Resources needed by Hardware resources (of DATA_CONSUMER_1) Computational (memory, CPU), energy, radio A data producer (SENSOR_1) Communication with it. Data to process Periodically available input. 16

17 Failure, error, fault in Failure example: No data is processed after >T secs. Error examples (incorrect internal states): Buffer underflows (sensor or consumer side) Buffer overflows (sensor or consumer side) Faults that may lead to those errors: Bandwidth variations (e.g. signal interference) Sensing module failure (BEWARE!) 17

18 Example: Application failure due to connectivity fault APPLICATION LEVEL BEWARE: It is all relative! If the specification were instead about connectivity (link state), we would be talking about connectivity failures (not faults). 18

19 Proactive dependability framework for IoT (via RM) 19

User s feedback (evaluation) may be required to map between system states (which can be monitored) and

20 Detecting / predicting failures Application state (whether it satisfies the specifications or not, to what degree) may be difficult to check automatically at runtime. User s feedback (evaluation) may be required to map between system states (which can be monitored) and application states. APPLICATION LEVEL Time series analysis to predict failures. System states Failure Application states Failure Normal Normal 20

21 (Self-)healing Moving the application from a failure state to a normal state, e.g. by allocating more resources to it. Also: Going to a state that is further away from failure (less likely to fail in the future). Self-healing: Without human intervention at runtime. System states Failure Application states Failure Normal Normal 21

Main stages of self-healing at runtime Monitoring the IoT system Sensor readings, communication statistics, resource monitoring data etc. Artificial intelligence (e.g. based on learning, other computational methods).

22 Main stages of self-healing at runtime Monitoring the IoT system Sensor readings, communication statistics, resource monitoring data etc. Artificial intelligence (e.g. based on learning, other computational methods). Build a model (algorithm) that decides which states of the system correspond to operation of the IoT application within specs. Fault/failure detection/prediction at runtime. Outliers (e.g. due to measurement errors) vs real failures. Adaptation / resource reallocation Dynamically change the application behavior and resource allocation to steer towards a safe/safer state. Safe/normal state: within specs, an acceptable tradeoff point between quality and dependability. Self-healing: System autonomously trying to avoid and exit failure states. 22

23 Example: PIR sensor as a resource 23

24 System states Application states Failure Failure Computed based on message statistics (hop count, latency). How we compute this is not important for this lecture. Normal Computational trust Normal The graph shows a computational rating of L9 for red PIR1 and for blue PIR2 over time. 24

25 System states Application states Failure Failure Normal Computational trust Normal The graph shows a computational rating of L9 for red PIR1 and for blue PIR2 over time. 25

26 System states Application states Failure Failure Normal Computational trust Normal The graph shows a computational rating of L9 for red PIR1 and for blue PIR2 over time. 26

27 System states Application states Failure Failure Normal Computational trust Normal The graph shows a computational rating of L9 for red PIR1 and for blue PIR2 over time. 27

28 System states Application states Failure Failure Normal Computational trust Normal The graph shows a computational rating of L9 for red PIR1 and for blue PIR2 over time. 28

29 Computational trust The graph shows a computational rating of L9 for red PIR1 and for blue PIR2 over time. 29

30 Computational trust 30

31 What does resource management entail? Guiding questions What are the components of dependability? Dependability metrics Faults, errors and failures in the IoT application context What are the components of an IoT dependability framework? How does it work? Improving dependability via resource management and adaptation. 31

Chapter 6 Congestion Control and Resource Allocation

Chapter 6 Congestion Control and Resource Allocation Overview of Congestion Control and Resource Allocation Problem: How to effectively and fairly allocate resources among a collection of competing users?