DOCSLIB.ORG

Fault-Tolerant Real-Time Architecture for Elderly Care

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Fault-Tolerant Real-Time Architecture for Elderly Care Fault-Tolerant Real-Time Architecture for Elderly Care DISSERTATION zur Erlangung des Grades eines Doktors der Ingenieurwissenschaften (Dr.-Ing.) vorgelegt von Dipl.-Inform. Michael-Christian Schmidt eingereicht bei der Naturwissenschaftlich-Technischen Fakultät der Universität Siegen Siegen 2020 Betreuer und erster Gutachter: Prof. Dr.-Ing. habil. Roman Obermaisser Universität Siegen Zweiter Gutachter: Prof. Dr.-Ing. habil. Marcin Grzegorzek Universität zu Lübeck Tag der mündlichen Prüfung: 08.12.2020 Gedruckt auf alterungsbeständigem holz- und säurefreiem Papier. Abstract The ongoing transition from traditional elderly care to the use of modern technologies from the field of Cyber Physical Systems (CPSs) results in new challenges for both industry and research. This shift is mainly motivated by the increasing share of elderly people in the population which is causing a notable shortage of nursing staff. With the availability of new technologies, the CPSs for elderly care are also enabling new fields of applications in the area of biomedicine and robotics. Use cases like the automatic injection of insulin and robotic assistance are prominent examples for these application fields. These new appli- cation fields impose new requirements on architectures in the field of elderly care, such as deterministic real-time behavior and dependability along with an open-world assumption in which dynamic changes within the composition of the system can occur at run-time. Likewise, the application of robotic systems in the field of elderly care introduces stringent real-time requirements to the whole CPS, affecting the integration of complex and het- erogeneous sensors, the control of actuators and the communication network. Moreover, the application of fault-tolerance and mixed-criticality techniques is required to establish a dependable CPS that is able to tolerate faults in order to prevent dangerous situations for human life. Furthermore, CPSs have to encompass different integration levels like the local network and the Internet in order to support services from professional stakeholders like medical services from caregivers or a doctor. The proposed architecture for elderly care takes into account the new emerging appli- cation fields in elderly care as well as the associated challenges, which are (1) real-time support, (2) dependability and (3) support of an open-world assumption while taking into account multiple integration levels and the heterogeneity of the underlying technologies. A review of state-of-the-art architectures for elderly care shows that there is no archi- tecture available at present that meets all these challenges. The proposed architecture addresses this gap by taking advantage of a broad range of well-known technologies and standards from the state-of-the-art like ISO/IEEE 11073 and Time Sensitive Networking (TSN) while further introducing new concepts and technologies, such as fault containment among containers for high-critical applications as well as real-time container-to-container communication with latencies and jitter in the low microsecond range. A huge challenge iii is further to address the open-world assumption while providing real-time guarantees and fault-tolerance. In particular, this puts further requirements to the real-time system like the capability of a dynamic rescheduling of real-time resources like the real-time network. This is addressed by the introduction of a service for the dynamic rescheduling of real- time communication resources that takes care about topology and service management, scheduling, configuration building and distribution of communication schedules. By this way, changes within the physical model (e.g. a new network switch or end system) and the logical model (e.g. a new service) are supported at run-time of the system. In the field of software architectures, the use of microservices has reached a strong tech- nical maturity in recent years. The proposed architecture is embracing this trend and introduces platform services as microservices. Finally, several proof-of-concept implemen- tations are presented and evaluated in different experiments ranging from a real scenario to experiments in a laboratory in order to show that the proposed architecture for elderly care is able to address the shift in traditional elderly care to the use of modern technologies from the field of CPSs. iv Zusammenfassung Der fortschreitende Wandel von einer traditionellen Altenpflege hin zum Einsatz moder- ner Technologien aus dem Bereich der Cyber Physical Systems (CPSs) führt zu neuen Herausforderungen für Industrie und Forschung. Dieser Wandel ist vor allem durch den zunehmenden Anteil älterer Menschen an der Bevölkerung begründet und führt bereits jetzt zu einem bemerkenswerten Mangel an Pflegepersonal. Mit der Verfügbarkeit neuer Technologien ermöglichen die CPSs auf den Gebiet der Altenpflege neue Anwendungsfelder im Bereich der Biomedizin und Robotik. Die automatische Verabreichung von Insulin oder die Roboterunterstützung im Bereich der Pflege sind prominente Beispiele für diese Anwen- dungsfelder. Diese neuen Anwendungsfelder stellen neue Anforderungen an Architekturen im Bereich der Altenpflege, wie z.B. deterministisches Echtzeitverhalten und Zuverlässig- keit. Diese müssen zusammen mit einer Open-World-Annahme gelöst werden, bei der dyna- mische Veränderungen innerhalb der Zusammensetzung des Systems zur Laufzeit auftreten können. Ebenso stellt der Einsatz von Robotersystemen im Bereich der Altenpflege stren- ge Echtzeitanforderungen an das gesamte CPS, welche sich auf die Integration komplexer und heterogener Sensoren, die Steuerung von Aktoren und das Kommunikationsnetzwerk auswirken. Darüber hinaus ist die Anwendung von Fehlertoleranz- und Mixed-Criticality- Techniken erforderlich, um gefährliche Situationen für den Menschen zu verhindern. Zudem muss das CPS verschiedene Integrationsebenen, wie das lokale Netzwerk und das Internet, berücksichtigten, um Dienstleistungen von professionellen Stakeholdern, wie medizinische Dienstleister oder Ärzte zu unterstützen. Die in dieser Arbeit vorgeschlagene Architektur berücksichtigt die neu entstehenden Anwendungsfelder in der Altenpflege, sowie die damit verbundenen Herausforderungen, nämlich (1) Echtzeit-Unterstützung, (2) Zuverlässigkeit und (3) Unterstützung einer Open- World-Annahme unter Berücksichtigung mehrerer Integrationsebenen und der Heteroge- nität der zugrunde liegenden Technologien. Ein Überblick über Architekturen für die Al- tenpflege im Stand der Technik zeigt, dass es derzeit keine Architektur gibt, welche allen Herausforderungen gerecht wird. Die vorgeschlagene Architektur schließt diese Lücke, in- dem sie sich eine breite Vielfalt bekannter Technologien und Standards aus dem Stand der Technik wie ISO/IEEE 11073 und Time Sensitive Networking (TSN) zunutze macht v und gleichzeitig neue Konzepte und Technologien einführt, wie z.B. Fehlereindämmung zwi- schen Containern für sicherheitskritische Anwendungen, sowie echtzeitfähige Container-zu- Container-Kommunikation mit Latenzen und Jitter im niedrigen Mikrosekundenbereich. Eine maßgebliche Herausforderung besteht weiterhin darin, die Open-World-Annahme zu unterstützen und gleichzeitig Echtzeitgarantien und Fehlertoleranz zu bieten. Dies stellt zu- sätzliche Anforderungen an das Echtzeitsystem, wie beispielsweise die Fähigkeit einer dyna- mischen Umplanung von Echtzeit-Ressourcen. Diesen Anforderungen wird bspw. durch die Einführung eines Dienstes für die dynamische Umplanung von Echtzeit-Kommunikations- ressourcen Rechnung getragen, welcher für Topologie- und Dienstmanagement, Zeitpla- nung, Konfigurationsbildung und Verteilung von Kommunikationsplänen verantwortlich ist. Auf diese Weise werden Änderungen innerhalb des physikalischen Modells (z.B. ein neuer Netzwerk-Switch oder ein neues Endgerät) und des logischen Modells (z.B. ein neu- er Dienst) zur Laufzeit des Systems unterstützt. Im Bereich der Software-Architekturen hat der Einsatz von Microservices in den letzten Jahren eine nennenswerte technische Reife erreicht. Die vorgeschlagene Architektur greift diesen Trend auf und führt Plattformdienste als Microservices ein. Schließlich werden meh- rere Proof-of-Concept-Implementierungen vorgestellt und in verschiedenen Experimenten, die von einem realen Szenario bis hin zu Experimenten im Labor reichen, evaluiert, um zu zeigen, dass die vorgeschlagene Architektur für die Altenpflege in der Lage ist, den Wandel in der traditionellen Altenpflege hin zur Nutzung moderner Technologien aus dem Bereich CPSs zu bewältigen. vi Acknowledgements The acquisition of new knowledge and skills has always been a personal goal of mine. Writing this dissertation is therefore a big step for me to get closer to this goal. The completion of this dissertation would not have been possible without the advice, feedback and encouragement of many persons. I would now like to take the opportunity to thank these people. First, I would like to express my deepest appreciation to my supervisor, Prof. Dr.-Ing. habil. Roman Obermaisser, for allowing me to pursue my research interests and for the possibility to write this dissertation. I am deeply indebted for his strong encouragement and advice during all phases of this dissertation. Further, I would like to thank Prof. Dr.-Ing. habil. Marcin Grzegorzek for his confidence in my work, his valuable constructive feedback and commitment as second reviewer of this dissertation. I must also thank Stefan Otterbach for our constructive discussions and his support in helping me to organize
Load more

Recommended publications
  • Linux Scheduler Documentation
    Linux Scheduler Documentation The kernel development community Jul 14, 2020 CONTENTS i ii CHAPTER ONE COMPLETIONS - “WAIT FOR COMPLETION”BARRIER APIS 1.1 Introduction: If you have one or more threads that must wait for some kernel activity to have reached a point or a specific state, completions can provide a race-free solution to this problem. Semantically they are somewhat like a pthread_barrier() and have similar use-cases. Completions are a code synchronization mechanism which is preferable to any misuse of locks/semaphores and busy-loops. Any time you think of using yield() or some quirky msleep(1) loop to allow something else to proceed, you probably want to look into using one of the wait_for_completion*() calls and complete() instead. The advantage of using completions is that they have a well defined, focused pur- pose which makes it very easy to see the intent of the code, but they also result in more efficient code as all threads can continue execution until the result isactually needed, and both the waiting and the signalling is highly efficient using low level scheduler sleep/wakeup facilities. Completions are built on top of the waitqueue and wakeup infrastructure of the Linux scheduler. The event the threads on the waitqueue are waiting for is reduced to a simple flag in ‘struct completion’, appropriately called “done”. As completions are scheduling related, the code can be found in ker- nel/sched/completion.c. 1.2 Usage: There are three main parts to using completions: • the initialization of the ‘struct completion’synchronization object • the waiting part through a call to one of the variants of wait_for_completion(), • the signaling side through a call to complete() or complete_all().
    [Show full text]
  • Advances in Mobile Cloud Computing and Big Data in the 5G Era Studies in Big Data
    Studies in Big Data 22 Constandinos X. Mavromoustakis George Mastorakis Ciprian Dobre Editors Advances in Mobile Cloud Computing and Big Data in the 5G Era Studies in Big Data Volume 22 Series editor Janusz Kacprzyk, Polish Academy of Sciences, Warsaw, Poland e-mail: [email protected] About this Series The series “Studies in Big Data” (SBD) publishes new developments and advances in the various areas of Big Data-quickly and with a high quality. The intent is to cover the theory, research, development, and applications of Big Data, as embedded in the fields of engineering, computer science, physics, economics and life sciences. The books of the series refer to the analysis and understanding of large, complex, and/or distributed data sets generated from recent digital sources coming from sensors or other physical instruments as well as simulations, crowd sourcing, social networks or other internet transactions, such as emails or video click streams and other. The series contains monographs, lecture notes and edited volumes in Big Data spanning the areas of computational intelligence incl. neural networks, evolutionary computation, soft computing, fuzzy systems, as well as artificial intelligence, data mining, modern statistics and Operations research, as well as self-organizing systems. Of particular value to both the contributors and the readership are the short publication timeframe and the world-wide distribution, which enable both wide and rapid dissemination of research output. More information about this series at http://www.springer.com/series/11970 Constandinos X. Mavromoustakis George Mastorakis ⋅ Ciprian Dobre Editors Advances in Mobile Cloud Computing and Big Data in the 5G Era 123 Editors Constandinos X.
    [Show full text]
  • On the Defectiveness of SCHED DEADLINE W.R.T. Tardiness and Afinities, and a Partial Fix Stephen Tang Luca Abeni James H
    On the Defectiveness of SCHED_DEADLINE w.r.t. Tardiness and Afinities, and a Partial Fix Stephen Tang Luca Abeni James H. Anderson [email protected] {sytang,anderson}@cs.unc.edu Scuola Superiore Sant’Anna University of North Carolina at Chapel Hill Pisa, Italy Chapel Hill, USA ABSTRACT create new DL tasks until existing DL tasks reduce their bandwidth SCHED_DEADLINE (DL for short) is an Earliest-Deadline-First consumption. Note that preventing over-utilization is only a neces- sary condition for guaranteeing that tasks meet deadlines. (EDF) scheduler included in the Linux kernel. A question motivated Instead of guaranteeing that deadlines will be met, AC satisfes by DL is how EDF should be implemented in the presence of CPU afnities to maintain optimal bounded tardiness guarantees. Recent two goals [3]. The frst goal is to provide performance guarantees. works have shown that under arbitrary afnities, DL does not main- Specifcally, AC guarantees to each DL task that its long-run con- tain such guarantees. Such works have also shown that repairing sumption of CPU bandwidth remains within a bounded margin DL to maintain these guarantees would likely require an impractical of error from a requested rate. The second goal is to avoid the overhaul of the existing code. In this work, we show that for the starvation of lower-priority non-DL workloads. Specifcally, AC special case where afnities are semi-partitioned, DL can be modi- guarantees that some user-specifed amount of CPU bandwidth fed to maintain tardiness guarantees with minor changes. We also will remain for the execution of non-DL workloads.
    [Show full text]
  • RTEMS C User Documentation Release 4.11.3 ©Copyright 2016, RTEMS Project (Built 15Th February 2018)
    RTEMS C User Documentation Release 4.11.3 ©Copyright 2016, RTEMS Project (built 15th February 2018) CONTENTS I RTEMS C User’s Guide1 1 Preface 5 2 Overview 9 2.1 Introduction...................................... 10 2.2 Real-time Application Systems............................ 11 2.3 Real-time Executive.................................. 12 2.4 RTEMS Application Architecture........................... 13 2.5 RTEMS Internal Architecture............................. 14 2.6 User Customization and Extensibility......................... 15 2.7 Portability....................................... 16 2.8 Memory Requirements................................. 17 2.9 Audience........................................ 18 2.10 Conventions...................................... 19 2.11 Manual Organization................................. 20 3 Key Concepts 23 3.1 Introduction...................................... 24 3.2 Objects......................................... 25 3.2.1 Object Names................................. 25 3.2.2 Object IDs................................... 25 3.2.2.1 Thirty-Two Object ID Format.................... 25 3.2.2.2 Sixteen Bit Object ID Format.................... 26 3.2.3 Object ID Description............................. 26 3.3 Communication and Synchronization........................ 27 3.4 Time.......................................... 28 3.5 Memory Management................................. 29 4 RTEMS Data Types 31 4.1 Introduction...................................... 32 4.2 List of Data Types..................................
    [Show full text]
  • Network Store: Exploring Slicing in Future 5G Networks
    Network Store: Exploring Slicing in Future 5G Networks Navid Nikaein*, Eryk Schillerx, Romain Favraud*y, Kostas Katsalis\, Donatos Stavropoulos\, Islam Alyafawix, Zhongliang Zhaox, Torsten Braunx, and Thanasis Korakis\ *EURECOM, yDCNS xUniversity of Bern fi[email protected] [email protected] \University of Thessaly {kkatsalis,dostavro,korakis}@uth.gr ABSTRACT coupling between control and data planes, state-full design, In this paper, we present a revolutionary vision of 5G net- and dependency to dedicated hardware. The exploitation works, in which SDN programs wireless network functions, of cloud technologies, Software-Define Networking (SDN) and where Mobile Network Operators (MNO), Enterprises, and Network-Function Virtualization (NFV), can provide and Over-The-Top (OTT) third parties are provided with the necessary tools to break-down the vertical system or- NFV-ready Network Store. The proposed Network Store ganization, into a set of horizontal micro-service network serves as a digital distribution platform of programmable architectures. These can be used to combine relevant net- Virtualized Network Functions (VNFs) that enable 5G ap- work functions together, assign the target performance pa- plication use-cases. Currently existing application stores, rameters, and map them onto infrastructure resources. such as Apple's App Store for iOS applications, Google's In this paper, we present the design of a 5G-ready archi- Play Store for Android, or Ubuntu's Software Center, deliver tecture and a NFV-based Network Store that can serve as applications to user specific software platforms. Our vision a digital distribution platform for 5G application use-cases. is to provide a digital marketplace, gathering 5G enabling The goal of the Network Store is to provide programmable Network Applications and Network Functions, written to run pieces of code that on-the-fly reserve required resources, de- on top of commodity cloud infrastructures, connected to re- ploy and run the necessary software components, configure mote radio heads (RRH).
    [Show full text]
  • Embedded Operating Systems
    7 Embedded Operating Systems Claudio Scordino1, Errico Guidieri1, Bruno Morelli1, Andrea Marongiu2,3, Giuseppe Tagliavini3 and Paolo Gai1 1Evidence SRL, Italy 2Swiss Federal Institute of Technology in Zurich (ETHZ), Switzerland 3University of Bologna, Italy In this chapter, we will provide a description of existing open-source operating systems (OSs) which have been analyzed with the objective of providing a porting for the reference architecture described in Chapter 2. Among the various possibilities, the ERIKA Enterprise RTOS (Real-Time Operating System) and Linux with preemption patches have been selected. A description of the porting effort on the reference architecture has also been provided. 7.1 Introduction In the past, OSs for high-performance computing (HPC) were based on custom-tailored solutions to fully exploit all performance opportunities of supercomputers. Nowadays, instead, HPC systems are being moved away from in-house OSs to more generic OS solutions like Linux. Such a trend can be observed in the TOP500 list [1] that includes the 500 most powerful supercomputers in the world, in which Linux dominates the competition. In fact, in around 20 years, Linux has been capable of conquering all the TOP500 list from scratch (for the first time in November 2017). Each manufacturer, however, still implements specific changes to the Linux OS to better exploit specific computer hardware features. This is especially true in the case of computing nodes in which lightweight kernels are used to speed up the computation. 173 174 Embedded Operating Systems Figure 7.1 Number of Linux-based supercomputers in the TOP500 list. Linux is a full-featured OS, originally designed to be used in server or desktop environments.
    [Show full text]
  • Red Hat Enterprise Linux for Real Time 8 Reference Guide
    Red Hat Enterprise Linux for Real Time 8 Reference Guide Core concepts and terminology for using RHEL for Real Time Last Updated: 2021-05-19 Red Hat Enterprise Linux for Real Time 8 Reference Guide Core concepts and terminology for using RHEL for Real Time Sujata Kurup Red Hat Customer Content Services [email protected] Jaroslav Klech Red Hat Customer Content Services Marie Doleželová Red Hat Customer Content Services Maxim Svistunov Red Hat Customer Content Services Radek Bíba Red Hat Customer Content Services David Ryan Red Hat Customer Content Services Cheryn Tan Red Hat Customer Content Services Lana Brindley Red Hat Customer Content Services Alison Young Red Hat Customer Content Services Legal Notice Copyright © 2021 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/ . In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries.
    [Show full text]
  • SCHED DEADLINE: a Real-Time CPU Scheduler for Linux Luca Abeni [email protected]
    SCHED DEADLINE: a real-time CPU scheduler for Linux Luca Abeni [email protected] TuToR 2017 Luca Abeni – 1 / 33 Scheduling Real-Time Tasks Introduction Real-Time Scheduling in cj cj+1 Linux fj dj fj+1 dj+1 Setting the Scheduling rj rj+1 Policy The Constant Bandwidth Server Consider a set of N real-time tasks SCHED DEADLINE Using Γ= {τ0,...τN−1} SCHED DEADLINE Scheduled on M CPUs Real-Time theory → lot of scheduling algorithms... ...But which ones are available on a commonly used OS? POSIX: fixed priorities Can be used to do RM, DM, etc... Multiple processors: DkC, etc... Linux also provides SCHED DEADLINE: resource TuToR 2017 reservations + EDF Luca Abeni – 2 / 33 Definitions Introduction Real-Time Scheduling in Real-time task τ : sequence of jobs Ji =(ri,ci,di) Linux Setting the Scheduling Policy Finishing time fi The Constant Bandwidth Server Goal: fi ≤ di SCHED DEADLINE Using ∀Ji, or control the amount of missed deadlines SCHED DEADLINE Schedule on multiple CPUS: partitioned or global Schedule in a general-purpose OS Open System (with online admission control) Presence of non real-time tasks (do not starve them!) TuToR 2017 Luca Abeni – 3 / 33 Using Fixed Priorities with POSIX Introduction Real-Time Scheduling in SCHED FIFO and SCHED RR use fixed priorities Linux Setting the Scheduling Policy They can be used for real-time tasks, to The Constant Bandwidth Server implement RM and DM SCHED DEADLINE Using Real-time tasks have priority over non real-time SCHED DEADLINE (SCHED OTHER) tasks The difference between
    [Show full text]
  • Block Devices and Volume Management in Linux
    Block devices and volume management in Linux Krzysztof Lichota [email protected] L i n u x b l o c k d e v i c e s l a y e r ● Linux block devices layer is pretty flexible and allows for some interesting features: – Pluggable I/O schedulers – I/O prioritizing (needs support from I/O scheduler) – Remapping of disk requests (Device Mapper) – RAID – Various tricks (multipath, fault injection) – I/O tracing (blktrace) s t r u c t b i o ● Basic block of I/O submission and completion ● Can represent large contiguous memory regions for I/O but also scattered regions ● Scattered regions can be passed directly to disks capable of scatter/gather ● bios can be split, merged with other requests by various levels of block layer (e.g. split by RAID, merged in disk driver with other disk requests) s t r u c t b i o f i e l d s ● bi_sector – start sector of I/O ● bi_size – size of I/O ● bi_bdev – device to which I/O is sent ● bi_flags – I/O flags ● bi_rw – read/write flags and priority ● bi_io_vec – memory scatter/gather vector ● bi_end_io - function called when I/O is completed ● bi_destructor – function called when bio is to be destroyed s t r u c t b i o u s a g e ● Allocate bio using bio_alloc() or similar function ● Fill in necessary fields (start, device, ...) ● Initialize bio vector ● Fill in end I/O function to be notified when bio completes ● Call submit_bio()/generic_make_request() ● Example: process_read() in dm-crypt O t h e r I / O s u b m i s s i o n f u n c t i o n s ● Older interfaces for submitting I/O are supported (but deprecated),
    [Show full text]
  • Proceedings Der Linux Audio Conference 2018
    Proceedings of the Linux Audio Conference 2018 June 7th - 10th, 2018 c-base, in partnership with the Electronic Studio at TU Berlin Berlin, Germany Published by Henrik von Coler Frank Neumann David Runge http://lac.linuxaudio.org/2018 All copyrights remain with the authors. This work is licensed under the Creatice Commons Licence CC BY-SA 4.0 Published online on the institutional repository of the TU Berlin: DOI 10.14279/depositonce-7046 https://doi.org/10.14279/depositonce-7046 Credits Layout: Frank Neumann Typesetting: LATEX and pdfLaTeX Logo Design: The Linuxaudio.org logo and its variations copyright Thorsten Wilms c 2006, imported into "LAC 2014" logo by Robin Gareus Thanks to: Martin Monperrus for his webpage "Creating proceedings from PDF files" ii Partners and Sponsors Linuxaudio.org Technische Universität Berlin c-base Spektrum CCC Video Operation Center MOD Devices HEDD Native Instruments Ableton iii iv Foreword Welcome everyone to LAC 2018 in Berlin! This is the 15th edition of the Linux Audio Conference, or LAC, the international conference with an informal, workshop-like atmosphere and a unique blend of scientific and technical papers, tutorials, sound installations and concerts centering on the free GNU/Linux oper- ating system and open source software for audio, multimedia and musical applications. We hope that you will enjoy the conference and have a pleasant stay in Berlin! Henrik von Coler Robin Gareus David Runge Daniel Swärd Heiko Weinen v vi Conference Organization Core Team Henrik von Coler Robin Gareus David Runge
    [Show full text]
  • Toward a Low-Latency and Cooperative Radio Access Network
    LATENCY, COOPERATION, AND CLOUD IN RADIO ACCESS NETWORK Navid Nikaein Thesis submitted to University of Nice in partial fulfilment for the award of the degree of Habilitation a` Diriger des Recherches 19 March 2015 AUTHOR’S ADDRESS: Navid Nikaein Eurecom Mobile Communication Department Campus SophiaTech 450 Route des Chappes 06410 Biot Sophia Antipolis – France Email: [email protected] URL: http://www.eurecom.fr/˜nikaeinn Forward This document is written as support to my French ”Habilitation a` diriger des recherches” (HDR) degree. Unlike a Ph.D. thesis, a HR thesis does not aim at providing a detailed description of a particular research problematic, but rather describes the various facets of responsibilities that I experienced as researcher and assistant professor since I obtained my Ph.D. My post-doctoral career started at Eurecom in January 2004, after having completed my Ph.D. entitled “Architecture and protocols for supporting routing and quality of service for mobile ad hoc networks” at Ecole´ Polytechnique Fed´ erale´ de Lausanne EPFL, Switzerland in September 2003. After the postdoc, I joined the founding team of a startup company in Sophia-Antipolis, France, working towards a range of intelligent wireless backhaul routing products for private and public networks. Four years later, I deliberately chose to join Eurecom as an assistant pro- fessor because of the experimental platform OpenAirInterface, which allowed me to work on practical aspects of wireless access network. This means working on aspects that are sometimes overlooked or not found interesting or even old fashioned by other researchers, or collecting and analyzing data from experiments to prove a concept or a point.
    [Show full text]
  • SCHED DEADLINE: It’S Alive!
    Title 44pt sentence case SCHED_DEADLINE: It’s Alive! Juri Lelli Affiliations 24pt sentence case ARM Ltd. 20pt sentence case ELC North America 17, Portland (OR) 02/21/2017 © ARM 2017 Title 40pt sentence case Agenda Bullets 24pt sentence case . Deadline scheduling (SCHED_DEADLINE) bullets 20pt sentence case . Why is development now happening (out of the blue?) . Bandwidth reclaiming . Frequency/CPU scaling of reservation parameters . Coupling with frequency selection . Group scheduling . Future 2 © ARM 2017 Text 54pt sentence case CHAPER 1 What and Why 3 © ARM 2017 Title 40pt sentence case Agenda Bullets 24pt sentence case . Deadline scheduling (SCHED_DEADLINE) bullets 20pt sentence case . Why is development now happening (out of the blue?) . Bandwidth reclaiming . Frequency/CPU scaling of reservation parameters . Coupling with frequency selection . Group scheduling . Future 4 © ARM 2017 Title 40pt sentence case Deadline scheduling (previously on ...) Bullets 24pt sentence case . mainline since v3.14 SCHED_RR SCHED_ bullets 20pt sentence case 30 March 2014 (~3y ago) SCHED_ IDLE DEADLINE SCHED_FIFO . it’s not only about deadlines SCHED_ . RT scheduling policy BATCH . explicit per-task latency constraints SCHED_ NORMAL . avoids starvation . enriches scheduler’s knowledge about QoS requirements . EDF + CBS . resource reservation mechanism deadline.c rt.c fair.c . temporal isolation . ELC16 presentation Linux scheduler https://goo.gl/OVspuI 5 © ARM 2017 Title 40pt sentence case Deadline scheduling (previously on ...) Bullets 24pt sentence case . mainline since v3.14 SCHED_RR SCHED_ bullets 20pt sentence case 30 March 2014 (~3y ago) SCHED_ IDLE DEADLINE SCHED_FIFO . it’s not only about deadlines SCHED_ . RT scheduling policy BATCH . explicit per-task latency constraints SCHED_ NORMAL . avoids starvation .
    [Show full text]