MIKES 2007 First International Workshop on Microkernels for Embedded Systems

Total Page:16

File Type:pdf, Size:1020Kb

MIKES 2007 First International Workshop on Microkernels for Embedded Systems MIKES 2007 First International Workshop on Microkernels for Embedded Systems Editors: Ihor Kuz and Stefan M. Petters Program Committee Chair: Kevin Elphinstone National ICT Australia 223 Anzac Parade Kensington NSW 2052 Australia {firstname.lastname}@nicta.com.au Technical Report January 2007 ISSN 1833-9646 Copyright 2007 National ICT Australia. All rights reserved. The copyright of this collection is with National ICT Australia. The copyright of the individual articles remains with their authors. National ICT Australia is funded by the Australian Government's Department of Communications, Information Technology, and the Arts and the Australian Research Council through Backing Australia's Ability and the ICT Research Centre of Excellence programs. Table of Contents Forword…………………………………………………………………………………………………… 4 Formalizing Information Flow in a Haskell Hypervisor…………………………………… 5 Rebekah Leslie, Levent Erkok, and Flemming Andersen High-Performance Microkernels and Virtualisation on ARM and Segmented……. 11 Architectures Carl van Schaik and Gernot Heiser Automated Object Layout Optimization in a Portable Microkernel………………….. 22 Uwe Dannowski A Memory Allocation Model For An Embedded Microkernel…………………………… 29 Dhammika Elkaduwe, Philip Derrin, and Kevin Elphinstone L4-Based Real Virtual Machines: An API Proposal………………………………………… 36 Sebastian Biemueller and Uwe Dannowski A Declarative Approach to Extensible Interface Compilation…………………………… 43 Nicholas FitzRoy-Dale Evolution of the PikeOS Microkernel……………………………………………………………. 50 Robert Kaiser and Stephan Wagner Issues on Analysing L4 for its WCET…………………………………………………………… 58 Mohit Singal and Stefan M. Petters 3 Foreword The First International Workshop on MicroKernels for Embedded Systems was conceived to provide a forum for the discussion of issues in the application of microkernels in the embedded systems domain, including emerging problems, novel concepts, analysis approaches, and case studies. The workshop attracted submissions from both academia and industry. The submitted papers were peer reviewed by an expert program committee. I wish to express my gratitude to the members program committee who contributed their time to provide high quality reviews, which eased the job of selecting a quality program. The authors were given the opportunity to revise and re-submit final versions of their papers based on the reviews, and on the discussions that developed at the workshop. The papers contained herein are the final versions submitted after the workshop. I'd like to thank our guest speaker David Kleidermacher of Green Hills Software who provided an interesting overview of a successful commercial microkernel for embedded systems. I'd also like to thank the discussion panel: Gernot Heiser, National ICT Australia and UNSW; Timothy Roscoe, ETH, Zurich; Andrew Tanenbaum, Vrije Universiteit; and David Kleidermacher. The panel discussion proved lively, insightful, and entertaining for all present. I also wish to thanks Stefan M. Petters and Ihor Kuz, who did much of the organising of the event. Kevin Elphinstone Program Chair Program Committee Kevin Elphinstone, NICTA/UNSW, Australia (Chair) Andrew Tanenbaum, Vrije Universiteit, Amsterdam, Netherlands Gerwin Klein, NICTA/UNSW, Australia Hermann Haertig, TU Dresden, Germany Jonathan S. Shapiro, The Johns Hopkins University, USA Neil Audsley, University of York, UK Sebastian Schönberg, Intel, Hillsboro, USA Volkmar Uhlig, IBM Watson, USA 4 Formalizing Information Flow in a Haskell Hypervisor Rebekah Leslie Levent Erkok¨ and Flemming Andersen Portland State University Intel Corporation Abstract— Separation kernels are the holy grail of secure sys- separation for HHV becomes a more tenable goal than with tems, remaining elusive despite years of research into their design, other techniques. implementation, and analysis. Though separation kernel research In this paper, we concentrate on the formulation of correct- has achieved many successes, the disconnect between information flow theory and system implementation is a significant barrier to ness and security properties of the communication mechanisms further progress. In this paper, we show how a particular branch in HHV, because these are the source of all legal information of information flow theory, noninterference, can be utilized to flow in our design. We formally characterize the information formulate correctness and security properties of a microkernel- flow relationships induced by these communication primitives style hypervisor. Thus, we not only provide a first step towards using a notation based on higher-order logic, similar to the a formally verified separation kernel, but also reduce the gap between information flow theory and operating systems practice. P-logic programming logic for Haskell [8]. More importantly, we develop specification patterns for expressing correctness properties in terms of noninterference concepts. In defining I. INTRODUCTION these patterns, we take advantage of higher-order functions to extract common aspects of noninterference-style properties. Noninterference provides a concise and general way to For instance, we abstract over the kernel state and kernel formalize the information flow relationships between compo- operations so that we can instantiate the patterns in different nents of a system. A noninterference security policy specifies contexts and formulate assertions about particular operations which components, or domains, may not interfere with each in a generic way. Hence, our work provides a link between the other, where a domain u interferes with a domain v if v theory of noninterference and the actual practice of building can observe the effects of u’s execution [1]. The generality secure microkernels. of such policies makes them useful for capturing a wide We organize the remainder of the paper as follows. Section variety of security requirements, including separation. A key II describes the foundational concepts of HHV and outlines the benefit of noninterference is that there are existing frameworks communication mechanisms. Section III presents the system for reasoning about systems governed by a noninterference model used by our hypervisor. Section IV introduces the policy [1], [2], thus reducing the barriers to verifying such noninterference specification patterns that are the basis of our systems formally. property formulations. Section V defines the desired informa- Our interest in noninterference stems from our efforts to tion flow behavior of HHV, both as an informal specification develop a hypervisor with formally verified separation between and as a set of formal properties. We discuss related work in user-level processes. The design of our hypervisor is similar Section VI and present our conclusions in Section VII. to secure microkernel APIs such as seL4 [3] and L4sec [4], but we use the term hypervisor to emphasize our intent II. COMMUNICATION IN HHV to employ our system as a platform for secure, separate The fundamental abstractions in HHV are protection do- execution. Such an execution environment is an essential part mains—the basic unit of resource protection—and execution of many high assurance systems, and is increasingly important contexts—the unit of execution. A protection domain (PD) in light of recent hardware developments, such as multi- corresponds to an address space in other systems; an execution core platforms based on Intel°R Virtualization Technology and context (EC) corresponds to a thread. HHV is a migrating Intel°R Trusted Execution Technology [5]. thread system [9], so there is a single execution context per Following the approach of the Programatica [6] and seL4 [3] processor that moves between protection domains with the projects, we are writing a model of our hypervisor, called logical flow of control. HHV, in the functional language Haskell [7]. The mathematical Each EC contains a representation of the processor state— semantics and strong type system of Haskell make our model such as the general purpose registers and the instruction easier to reason about than a low-level implementation. By pointer—for the running domain. We store this hardware combining the use of a high-level functional language with context using a record type, called Context, which contains a the application of an existing reasoning framework, proving field for each hardware register. When a domain is not running, HHV preserves the processor state in a region of memory Levent Erkok¨ is now at Galois Connections, Inc. called the save/restore area (SRA). 5 Protection domains communicate through uni-directional by the portal masks. channels called portals.A portal traversal causes a context switch from the initiator of the traversal (the source domain) to saveContext :: Mask ! Context ! PDID ! Kernel () the target of the traversal (the destination domain), potentially computeTransfer :: Mask ! Context ! Context transferring a message from the source to the destination in loadContext :: Portal ! SRA ! Context the process. There are two modes of communication in HHV: computePass :: Mask ! Context ! Context ! Context direct data transfer via registers and indirect data transfer through shared resources, such as memory pages.1 In this Fig. 1. Functions for preserving domain state and performing a message transfer. These functions are used by the context switch operation to imple- paper, we focus on the information flow properties of direct ment the dynamic message-transfer semantics specified by the portal masks. data transfer, although we have also formally
Recommended publications
  • Real-Time, Safe and Certified OS
    Real-Time, Safe and Certified OS Roman Kapl <[email protected]> drivers, customer projects, development Tomas Martinec <[email protected]> testing and certification © SYSGO AG · INTERNAL 1 Introduction • PikeOS – real-time, safety certified OS • Desktop and Server vs. • Embedded • Real-Time • Safety-Critical • Certified • Differences • Scheduling • Resource management • Features • Development © SYSGO AG · INTERNAL 2 Certification • Testing • Analysis • Lot of time • Even more paper • Required for safety-critical systems • Trains • Airplanes © SYSGO AG · INTERNAL 3 PikeOS • Embedded, real-time, certified OS • ~150 people (not just engineers) • Rail • Avionics • Space • This presentation is not about PikeOS specifically © SYSGO AG · INTERNAL 4 PikeOS technical • Microkernel • Inspired by L4 • Memory protection (MMU) • More complex than FreeRTOS • Virtualization hypervisor • X86, ARM, SPARC, PowerPC • Eclipse IDE for development © SYSGO AG · INTERNAL 5 Personalities • General • POSIX • Linux • Domain specific • ARINC653 • PikeOS native • Other • Ada, RT JAVA, AUTOSAR, ITRON, RTEMS © SYSGO AG · INTERNAL 6 PikeOS Architecture App. App. App. App. App. App. Volume Syste m Provider Partition PikeOS Para-Virtualized HW Virtualized File System (Native, POSIX, Guest OS PikeOS Native ARINC653, ...) Guest OS Linux, Android Linux, Android Device Driver User Space / Partitions Syste m PikeOS System Software ExtensionSyste m Extension PikeOS Microkernel Kernel Space / Hypervisor Architecture Platform Kernel Level Support Package Support Package Driver SoC /
    [Show full text]
  • Sistemi Operativi Real-Time Marco Cesati Lezione R13 Sistemi Operativi Real-Time – II Schema Della Lezione
    Sistemi operativi real-time Marco Cesati Lezione R13 Sistemi operativi real-time – II Schema della lezione Caratteristiche comuni VxWorks LynxOS Sistemi embedded e real-time QNX eCos Windows Linux come RTOS 15 gennaio 2013 Marco Cesati Dipartimento di Ingegneria Civile e Ingegneria Informatica Università degli Studi di Roma Tor Vergata SERT’13 R13.1 Sistemi operativi Di cosa parliamo in questa lezione? real-time Marco Cesati In questa lezione descriviamo brevemente alcuni dei più diffusi sistemi operativi real-time Schema della lezione Caratteristiche comuni VxWorks LynxOS 1 Caratteristiche comuni degli RTOS QNX 2 VxWorks eCos 3 LynxOS Windows Linux come RTOS 4 QNX Neutrino 5 eCos 6 Windows Embedded CE 7 Linux come RTOS SERT’13 R13.2 Sistemi operativi Caratteristiche comuni dei principali RTOS real-time Marco Cesati Corrispondenza agli standard: generalmente le API sono proprietarie, ma gli RTOS offrono anche compatibilità (compliancy) o conformità (conformancy) allo standard Real-Time POSIX Modularità e Scalabilità: il kernel ha una dimensione Schema della lezione Caratteristiche comuni (footprint) ridotta e le sue funzionalità sono configurabili VxWorks Dimensione del codice: spesso basati su microkernel LynxOS QNX Velocità e Efficienza: basso overhead per cambi di eCos contesto, latenza delle interruzioni e primitive di Windows sincronizzazione Linux come RTOS Porzioni di codice non interrompibile: generalmente molto corte e di durata predicibile Gestione delle interruzioni “separata”: interrupt handler corto e predicibile, ISR lunga
    [Show full text]
  • Performance Study of Real-Time Operating Systems for Internet Of
    IET Software Research Article ISSN 1751-8806 Performance study of real-time operating Received on 11th April 2017 Revised 13th December 2017 systems for internet of things devices Accepted on 13th January 2018 E-First on 16th February 2018 doi: 10.1049/iet-sen.2017.0048 www.ietdl.org Rafael Raymundo Belleza1 , Edison Pignaton de Freitas1 1Institute of Informatics, Federal University of Rio Grande do Sul, Av. Bento Gonçalves, 9500, CP 15064, Porto Alegre CEP: 91501-970, Brazil E-mail: [email protected] Abstract: The development of constrained devices for the internet of things (IoT) presents lots of challenges to software developers who build applications on top of these devices. Many applications in this domain have severe non-functional requirements related to timing properties, which are important concerns that have to be handled. By using real-time operating systems (RTOSs), developers have greater productivity, as they provide native support for real-time properties handling. Some of the key points in the software development for IoT in these constrained devices, like task synchronisation and network communications, are already solved by this provided real-time support. However, different RTOSs offer different degrees of support to the different demanded real-time properties. Observing this aspect, this study presents a set of benchmark tests on the selected open source and proprietary RTOSs focused on the IoT. The benchmark results show that there is no clear winner, as each RTOS performs well at least on some criteria, but general conclusions can be drawn on the suitability of each of them according to their performance evaluation in the obtained results.
    [Show full text]
  • Microsoft and Wind River Are Currently in a "Dead Heat" For
    Microsoft and Wind River are currently in a "dead heat" for the top position in sales of embedded operating system software and toolkits, according to Stephen Balacco, embedded software analyst at Venture Development Corp. (VDC). In terms of the sale of real-time operating systems, on the other hand, Balacco said Wind River still maintains a "commanding market leadership position," but noted that Wind River has been "as challenged as any supplier in this market space over the last two years in the face of a slumping telecommunications industry, where they have been highly leveraged for sales, as well as [from] increased competition from royalty-free and Linux OS vendors making inroads." While not disclosing specific market share numbers publicly, VDC provided the following list indicating the market share position in terms of sales revenue, for the leading vendors in the embedded operating system market . 1. Microsoft 2. Wind River 3. Symbian 4. Palm 5. QNX 6. Enea Data 7. Green Hills Software 8. LynuxWorks 9. MontaVista Software 10. Accelerated Technology (Mentor Graphics) Included among key factors identified by VDC as impacting this market were . • Increased focus and emphasis on bundling integrated development solutions that minimize unnecessary and repetitive development and allow OEMs to focus on their core competencies in differentiating their product through the application; • Ability of OS vendors to adapt business models that are flexible in their pricing and terms and conditions in response to a changing set of market requirements spurred on by competitive market forces; and • A telecommunications market that continues to struggle has affected investments in new projects.
    [Show full text]
  • ADSP-BF537 EZ-KIT Lite® Evaluation System Manual
    ADSP-BF537 EZ-KIT Lite® Evaluation System Manual Revision 2.4, April 2008 Part Number 82-000865-01 Analog Devices, Inc. One Technology Way Norwood, Mass. 02062-9106 a Copyright Information ©2008 Analog Devices, Inc., ALL RIGHTS RESERVED. This document may not be reproduced in any form without prior, express written consent from Analog Devices, Inc. Printed in the USA. Limited Warranty The EZ-KIT Lite evaluation system is warranted against defects in materi- als and workmanship for a period of one year from the date of purchase from Analog Devices or from an authorized dealer. Disclaimer Analog Devices, Inc. reserves the right to change this product without prior notice. Information furnished by Analog Devices is believed to be accurate and reliable. However, no responsibility is assumed by Analog Devices for its use; nor for any infringement of patents or other rights of third parties which may result from its use. No license is granted by impli- cation or otherwise under the patent rights of Analog Devices, Inc. Trademark and Service Mark Notice The Analog Devices icon bar and logo, VisualDSP++, the VisualDSP++ logo, Blackfin, the Blackfin logo, the CROSSCORE logo, EZ-KIT Lite, and EZ-Extender are registered trademarks of Analog Devices, Inc. All other brand and product names are trademarks or service marks of their respective owners. Regulatory Compliance The ADSP-BF537 EZ-KIT Lite is designed to be used solely in a labora- tory environment. The board is not intended for use as a consumer end product or as a portion of a consumer end product. The board is an open system design which does not include a shielded enclosure and therefore may cause interference to other electrical devices in close proximity.
    [Show full text]
  • Security Target Pikeos Separation Kernel V4.2.2
    Security Target PikeOS Separation Kernel v4.2.2 Document ID Revision DOORS Baseline Date State 00101-8000-ST 20.6 N.A. 2018-10-10 App Author: Dominic Eschweiler SYSGO AG Am Pfaffenstein 14, D-55270 Klein-Winternheim Notice: The contents of this document are proprietary to SYSGO AG and shall not be disclosed, disseminated, copied, or used except for purposes expressly authorized in writing by SYSGO AG. Doc. ID: 00101-8000-ST Revision: 20.6 This page intentionally left blank Copyright 2018 Page 2 of 47 All rights reserved. SYSGO AG Doc. ID: 00101-8000-ST Revision: 20.6 This page intentionally left blank Copyright 2018 Page 3 of 47 All rights reserved. SYSGO AG Doc. ID: 00101-8000-ST Revision: 20.6 Table of Contents 1 Introduction .................................................................................................................... 6 1.1 Purpose of this Document ........................................................................................... 6 1.2 Document References ................................................................................................ 6 1.2.1 Applicable Documents......................................................................................... 6 1.2.2 Referenced Documents ....................................................................................... 6 1.3 Abbreviations and Acronyms ....................................................................................... 6 1.4 Terms and Definitions................................................................................................
    [Show full text]
  • Green Hills Software INTEGRITY-178B Separation Kernel, Comprising
    CCEVS APPROVED ASSURANCE CONTINUITY MAINTENANCE REPORT ASSURANCE CONTINUITY MAINTENANCE REPORT FOR TM Green Hills Software INTEGRITY-178B Separation Kernel, comprising: INTEGRITY-178B Real Time Operating System (RTOS), version IN-ISP448-0100-SK_LMFWPCD2_Rel running on JSF PCD System Processor CCA, version 437140-007 with PowerPC, version 7448 Maintenance Report Number: CCEVS-VR-VID10119-2008a Date of Activity: 31 July 2009 References: Common Criteria document CCIMB-2004-02-009 “Assurance Continuity: CCRA Requirements”, version 1.0, February 2004; Impact Analysis Report, “High Assurance Security Products GHS JSF Panoramic Cockpit Display Separation Kernel Security Impact Analysis, DO-ISP448-0100- SK_LMFWPCD2SIA” High Assurance Security Products GHS Assurance Maintenance Plan, IN-INNNNN- 0101-HASPAMP Documentation Updated: Green Hills Software INTEGRITY-178B Separation Kernel developer evidence Assurance Continuity Maintenance Report: The vendor for the Green Hills Software INTEGRITY-178B Separation Kernel Operating System, submitted an Impact Analysis Report (IAR) to CCEVS for approval on 09 July 2009. The IAR is intended to satisfy requirements outlined in Common Criteria document CCIMB-2004-02-009, “Assurance Continuity: CCRA Requirements”, version 1.0, February 2004. In accordance with those requirements, the IAR describes the changes made to the certified TOE and the security impact of the changes. Changes to TOE: This maintenance activity consists of a functional and hardware platform modification to the Green Hills Software (GHS)
    [Show full text]
  • Extensible Distributed Operating System for Reliable Control Systems
    194 Extensible Distributed Operating System for Reliable Control Systems Katsumi Maruyama, Kazuya Kodama, Soichiro Hidaka, Hiromichi Hashizume National Institute of Informatics, 2-1-2 Hitotsubashi, Chiyoda-ku, Tokyo, Japan Email:{maruyama,kazuya,hidaka,has}@nii.ac.jp Abstract small monitor-like OSs are used. However, these monitor- like OSs lack program protection mechanisms, and program Since most control systems software is hardware-related, development is difficult. real-time-oriented and complex, adaptable OSs which help Therefore, an extensible/adaptable OS for control sys- program productivity and maintainability improvement are tems is required . We are developing a new OS character- in strong demand. ized by: We are developing an adaptable and extensible OS based on micro-kernel and multi-server scheme: each server runs • Use of an efficient and flexible micro-kernel (L4-ka). • Multi-server based modular OS. (Each OS service is in a protected mode interacting only via messages, and implemented as individual user-level process.) could be added/extended/deleted easily. Since this OS is • Robustness. Only the micro-kernel runs in kernel highly modularized, inter-process messaging overhead is a mode and in kernel space. Other modules run in a pro- concern. Our implementation proved good efficiency and tected user space and mode. maintainability. • Hardware driver programs in user-level process. • Flexible distributed processing by global message passing. 1. Introduction This OS structure proved to enhance OS modularity and ease of programming. However, inter-process messaging Most systems, from large scale public telephone switch- overhead should be considered . We measured the overhead, ing systems to home electronics, are controlled by software, and the overhead was proved to be small enough.
    [Show full text]
  • Research Purpose Operating Systems – a Wide Survey
    GESJ: Computer Science and Telecommunications 2010|No.3(26) ISSN 1512-1232 RESEARCH PURPOSE OPERATING SYSTEMS – A WIDE SURVEY Pinaki Chakraborty School of Computer and Systems Sciences, Jawaharlal Nehru University, New Delhi – 110067, India. E-mail: [email protected] Abstract Operating systems constitute a class of vital software. A plethora of operating systems, of different types and developed by different manufacturers over the years, are available now. This paper concentrates on research purpose operating systems because many of them have high technological significance and they have been vividly documented in the research literature. Thirty-four academic and research purpose operating systems have been briefly reviewed in this paper. It was observed that the microkernel based architecture is being used widely to design research purpose operating systems. It was also noticed that object oriented operating systems are emerging as a promising option. Hence, the paper concludes by suggesting a study of the scope of microkernel based object oriented operating systems. Keywords: Operating system, research purpose operating system, object oriented operating system, microkernel 1. Introduction An operating system is a software that manages all the resources of a computer, both hardware and software, and provides an environment in which a user can execute programs in a convenient and efficient manner [1]. However, the principles and concepts used in the operating systems were not standardized in a day. In fact, operating systems have been evolving through the years [2]. There were no operating systems in the early computers. In those systems, every program required full hardware specification to execute correctly and perform each trivial task, and its own drivers for peripheral devices like card readers and line printers.
    [Show full text]
  • MILS Architectural Approach Supporting Trustworthiness of the Iiot Solutions
    MILS Architectural Approach Supporting Trustworthiness of the IIoT Solutions An Industrial Internet Consortium Whitepaper Rance J. DeLong (The Open Group); Ekaterina Rudina (Kaspersky) MILS Architectural Approach Context and Overview 1 Context and Overview ...................................................................................................... 4 1.1 Need for Trustworthy System Operation ............................................................................. 5 1.2 What is MILS today .............................................................................................................. 6 1.3 How MILS Addresses Safety ................................................................................................. 7 1.4 How MILS Addresses Security .............................................................................................. 8 1.5 How MILS Supports Reliability, Resilience, and Privacy ........................................................ 9 2 MILS Concepts .................................................................................................................. 9 2.1 Centralized vs Distributed Security Architecture .................................................................. 9 2.1.1 Domain Isolation .................................................................................................................................. 10 2.1.2 Isolation and Information Flow Control ............................................................................................... 11 2.1.3 Separation
    [Show full text]
  • Selection of a New Hardware and Software Platform for Railway Interlocking
    Selection of a new hardware and software platform for railway interlocking Arghya Kamal Bhattacharya School of Electrical Engineering Thesis submitted for examination for the degree of Master of Science in Technology. Espoo 27.04.2020 Supervisor Prof. Valeriy Vyatkin Advisor MSc. Tommi Kokkonen Copyright ⃝c 2020 Arghya Kamal Bhattacharya Aalto University, P.O. BOX 11000, 00076 AALTO www.aalto.fi Abstract of the master’s thesis Author Arghya Kamal Bhattacharya Title Selection of a new hardware and software platform for railway interlocking Degree programme Automation and Electrical Engineering Major Control, Robotics and Autonomous Systems Code of major ELEC3025 Supervisor Prof. Valeriy Vyatkin Advisor MSc. Tommi Kokkonen Date 27.04.2020 Number of pages 82+34 Language English Abstract The interlocking system is one of the main actors for safe railway transportation. In most cases, the whole system is supplied by a single vendor. The recent regulations from the European Union direct for an “open” architecture to invite new game changers and reduce life-cycle costs. The objective of the thesis is to propose an alternative platform that could replace a legacy interlocking system. In the thesis, various commercial off-the-shelf hardware and software products are studied which could be assembled to compose an alternative interlocking platform. The platform must be open enough to adapt to any changes in the constituent elements and abide by the proposed baselines of new standardization initiatives, such as ERTMS, EULYNX, and RCA. In this thesis, a comparative study is performed between these products based on hardware capacity, architecture, communication protocols, programming tools, security, railway certifications, life-cycle issues, etc.
    [Show full text]
  • Us 2019 / 0319868 A1
    US 20190319868A1 ( 19) United States (12 ) Patent Application Publication ( 10) Pub . No. : US 2019 /0319868 A1 Svennebring et al. ( 43 ) Pub . Date : Oct. 17 , 2019 ( 54 ) LINK PERFORMANCE PREDICTION (52 ) U . S . CI. TECHNOLOGIES CPC .. .. H04L 43/ 0882 (2013 . 01 ); H04W 24 /08 ( 2013 . 01 ) (71 ) Applicant : Intel Corporation , Santa Clara , CA (57 ) ABSTRACT (US ) Various systems and methods for determining and commu nicating Link Performance Predictions (LPPs ), such as in ( 72 ) Inventors : Jonas Svennebring , Sollentuna (SE ) ; connection with management of radio communication links, Antony Vance Jeyaraj, Bengaluru ( IN ) are discussed herein . The LPPs are predictions of future network behaviors /metrics ( e . g . , bandwidth , latency , capac (21 ) Appl . No. : 16 /452 , 352 ity , coverage holes , etc . ) . The LPPs are communicated to applications and /or network infrastructure, which allows the applications/ infrastructure to make operational decisions for ( 22 ) Filed : Jun . 25 , 2019 improved signaling / link resource utilization . In embodi ments , the link performance analysis is divided into multiple layers that determine their own link performance metrics, Publication Classification which are then fused together to make an LPP. Each layer (51 ) Int . Cl. runs different algorithms, and provides respective results to H04L 12 / 26 ( 2006 .01 ) an LPP layer /engine that fuses the results together to obtain H04W 24 / 08 (2006 .01 ) the LPP . Other embodiments are described and / or claimed . 700 Spatio - Temporal History Data Tx1 : C1 TIDE _ 1, DE _ 2 . .. Txt : C2 T2 DE _ 1 , DE _ 2 , . .. win Txs : C3 122 T : DE _ 1, DE _ 2 , .. TN DE _ 1 , DE _ 2 .. TxN : CN CELL LOAD MODEL 710 Real- Time Data 744 704 Patent Application Publication Oct.
    [Show full text]