DOCSLIB.ORG

Introduction to Tizen Platform

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

1 12 전공핵심실습1:운영체제론 Lecture 5. System Call Sungkyunkwan University Embedded Software Lab. Dongkun Shin Embedded Software Lab. 2 Contents 12 • Interrupt • System Call • Practice 1. Tizen App Calling a System Call • Practice 2. Making a New System Call • Practice 3. Tizen App Calling the New System Call Embedded Software Lab. 3 Interrupts 12 • Interrupt (signal) – an event that alters the sequence of instructions executed by a processor • Exception – by CPU control unit while executing instructions only after terminating the executing – By programming error – By anomalous condition ex. Divided by zero, Page Fault Embedded Software Lab. 4 The Role of Interrupt Signal 12 • When the Interrupt signal arrives at Kernel CPU must stop what it’s currently doing, and switch to new activity. – 1) Save the current value of the program counter(eip, cs) in Kernel mode stack. – 2) Place an address related to the interrupt type into the program counter. Interrupt User signal arrives User PC Save old PC Kernel PC Kernel Memory representation when interrupt signal arrives Embedded Software Lab. 5 System Call 12 • System Call – interface between user mode process and H/W device ex. brk, open, close, read, write • Advantages of System Call – Freeing users from studying low-level programming of H/W – Increasing system security – Making programs more portable Embedded Software Lab. 6 System Call vs. POSIX API 12 User Application System Call • malloc(), free() return value` – An explicit request to the kernel C POSIX Library (ex. stdlib.h) made via a S/W interrupt syscall(45, brk_num) return value – Belong to kernel System Call Interface ex. brk, open, close, read, write sys_brk(brk_num) return value Kernel • cf. POSIX API – Common functions defined for compatibility between OSes. – It can be used on every UNIX-compatible OSes. • Linux, Darwin(OS X), Cygwin(Windows), Contiki, Nuttx, Minix, … • Reference: https://en.wikipedia.org/wiki/C_POSIX_library – glibc: a C POSIX Library in Linux ex. malloc(), calloc(), free(), fopen(), fread(), fwrite() Embedded Software Lab. 7 Parameter Passing 12 • Parameters are passed by using CPU registers 1. Write in the CPU registers before issuing the system call 2. Kernel copy the parameters in CPU registers onto the Kernel Mode stack before invoking the system call service routine • Reason – Working with two stacks at the same time is complex – Make the structure of the system call handler similar to that of exception handler • Constraints – The length of each parameter cannot exceed the length of a register – The number of parameters must not exceed 6 Embedded Software Lab. 8 Practice 1. Tizen App Calling a System Call 12 1. Download SystemCallApp on your Ubuntu shell 1. $ git clone https://github.com/SKKU-ESLAB-Tizen/SystemCallApp Embedded Software Lab. 9 Practice 1. Tizen App Calling a System Call 12 2. Call “gettimeofday” system call – Location (App): src/gettimeofday_syscall.c Embedded Software Lab. 10 Practice 2. Making a New System Call 12 1. System call function declaration – Location (Kernel): include/linux/syscalls.h (Line 850) asmlinkage long sys_seccomp(unsigned int op, unsigned int flags, const char__user *uargs); asmlinkage long sys_print_hello(int value); #endif Embedded Software Lab. 11 Practice 2. Making a New System Call 12 2. Make a system call function – Location (Kernel): kernel/printhello.c (New File) #include <linux/linkage.h> #include <linux/kernel.h> asmlinkage long sys_print_hello(int value) { const int answer = 10; printk(KERN_EMERG "Hello world: %d\n", value); if(value == answer) { return 1; // answer } else { return -1; // error } } Embedded Software Lab. 12 Practice 2. Making a New System Call 12 3. Add the source code to Makefile – Location (Kernel): kernel/Makefile (Line 13) obj-y = fork.o exec_domain.o panic.o \ cpu.o exit.o itimer.o time.o softirq.o resource.o \ sysctl.o sysctl_binary.o capability.o ptrace.o timer.o user.o \ signal.o sys.o kmod.o workqueue.o pid.o task_work.o \ extable.o params.o posix-timers.o \ kthread.o sys_ni.o posix-cpu-timers.o \ hrtimer.o nsproxy.o \ notifier.o ksysfs.o cred.o \ async.o range.o groups.o smpboot.o printhello.o Embedded Software Lab. 13 Practice 2. Making a New System Call 12 4. Allocate a number to the system call – Location (Kernel): arch/arm/kernel/calls.S (Line 394) …/* 380 */ CALL(sys_ni_syscall) CALL(sys_ni_syscall) CALL(sys_ni_syscall) CALL(sys_seccomp) CALL(sys_print_hello) #ifndef syscalls_counted .equ syscalls_padding, ((NR_syscalls + 3) & ~3) - NR_syscalls – Location (Kernel): arch/arm/include/asm/unistd.h (Line 18) #include <uapi/asm/unistd.h> #define __NR_syscalls (388) #define __ARM_NR_cmpxchg (__ARM_NR_BASE+0x00fff0) Embedded Software Lab. 14 Practice 3. Calling the New System Call 12 2. Call “printhello” system call – Location (App): src/printhello_syscall.c Embedded Software Lab..
Recommended publications
  • AMNESIA 33: How TCP/IP Stacks Breed Critical Vulnerabilities in Iot

    AMNESIA 33: How TCP/IP Stacks Breed Critical Vulnerabilities in Iot

    AMNESIA:33 | RESEARCH REPORT How TCP/IP Stacks Breed Critical Vulnerabilities in IoT, OT and IT Devices Published by Forescout Research Labs Written by Daniel dos Santos, Stanislav Dashevskyi, Jos Wetzels and Amine Amri RESEARCH REPORT | AMNESIA:33 Contents 1. Executive summary 4 2. About Project Memoria 5 3. AMNESIA:33 – a security analysis of open source TCP/IP stacks 7 3.1. Why focus on open source TCP/IP stacks? 7 3.2. Which open source stacks, exactly? 7 3.3. 33 new findings 9 4. A comparison with similar studies 14 4.1. Which components are typically flawed? 16 4.2. What are the most common vulnerability types? 17 4.3. Common anti-patterns 22 4.4. What about exploitability? 29 4.5. What is the actual danger? 32 5. Estimating the reach of AMNESIA:33 34 5.1. Where you can see AMNESIA:33 – the modern supply chain 34 5.2. The challenge – identifying and patching affected devices 36 5.3. Facing the challenge – estimating numbers 37 5.3.1. How many vendors 39 5.3.2. What device types 39 5.3.3. How many device units 40 6. An attack scenario 41 6.1. Other possible attack scenarios 44 7. Effective IoT risk mitigation 45 8. Conclusion 46 FORESCOUT RESEARCH LABS RESEARCH REPORT | AMNESIA:33 A note on vulnerability disclosure We would like to thank the CERT Coordination Center, the ICS-CERT, the German Federal Office for Information Security (BSI) and the JPCERT Coordination Center for their help in coordinating the disclosure of the AMNESIA:33 vulnerabilities.
  • Performance Study of Real-Time Operating Systems for Internet Of

    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.
  • Concurrent Cilk: Lazy Promotion from Tasks to Threads in C/C++

    Concurrent Cilk: Lazy Promotion from Tasks to Threads in C/C++

    Concurrent Cilk: Lazy Promotion from Tasks to Threads in C/C++ Christopher S. Zakian, Timothy A. K. Zakian Abhishek Kulkarni, Buddhika Chamith, and Ryan R. Newton Indiana University - Bloomington, fczakian, tzakian, adkulkar, budkahaw, [email protected] Abstract. Library and language support for scheduling non-blocking tasks has greatly improved, as have lightweight (user) threading packages. How- ever, there is a significant gap between the two developments. In previous work|and in today's software packages|lightweight thread creation incurs much larger overheads than tasking libraries, even on tasks that end up never blocking. This limitation can be removed. To that end, we describe an extension to the Intel Cilk Plus runtime system, Concurrent Cilk, where tasks are lazily promoted to threads. Concurrent Cilk removes the overhead of thread creation on threads which end up calling no blocking operations, and is the first system to do so for C/C++ with legacy support (standard calling conventions and stack representations). We demonstrate that Concurrent Cilk adds negligible overhead to existing Cilk programs, while its promoted threads remain more efficient than OS threads in terms of context-switch overhead and blocking communication. Further, it enables development of blocking data structures that create non-fork-join dependence graphs|which can expose more parallelism, and better supports data-driven computations waiting on results from remote devices. 1 Introduction Both task-parallelism [1, 11, 13, 15] and lightweight threading [20] libraries have become popular for different kinds of applications. The key difference between a task and a thread is that threads may block|for example when performing IO|and then resume again.
  • A Tutorial on Performance Evaluation and Validation Methodology for Low-Power and Lossy Networks

    A Tutorial on Performance Evaluation and Validation Methodology for Low-Power and Lossy Networks

    A Tutorial on Performance Evaluation and Validation Methodology for Low-Power and Lossy Networks Kosmas Kritsis, Georgios Papadopoulos, Antoine Gallais, Periklis Chatzimisios, Fabrice Theoleyre To cite this version: Kosmas Kritsis, Georgios Papadopoulos, Antoine Gallais, Periklis Chatzimisios, Fabrice Theoleyre. A Tutorial on Performance Evaluation and Validation Methodology for Low-Power and Lossy Networks. Communications Surveys and Tutorials, IEEE Communications Society, Institute of Electrical and Electronics Engineers, 2018, 20 (3), pp.1799 - 1825. 10.1109/COMST.2018.2820810. hal-01886690 HAL Id: hal-01886690 https://hal.archives-ouvertes.fr/hal-01886690 Submitted on 23 Apr 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. 1 A Tutorial on Performance Evaluation and Validation Methodology for Low-Power and Lossy Networks Kosmas Kritsis, Georgios Z. Papadopoulos, Member, IEEE, Antoine Gallais, Periklis Chatzimisios, Senior Member, IEEE, and Fabrice Theoleyre,´ Senior Member, IEEE, Abstract—Envisioned communication densities in Internet of may be used for counting the number of vehicles, such to Things (IoT) applications are increasing continuously. Because control optimally the street traffic lights and to reduce the these wireless devices are often battery powered, we need waiting time [3]. specific energy efficient (low-power) solutions.
  • User's Manual

    User's Manual

    rBOX610 Linux Software User’s Manual Disclaimers This manual has been carefully checked and believed to contain accurate information. Axiomtek Co., Ltd. assumes no responsibility for any infringements of patents or any third party’s rights, and any liability arising from such use. Axiomtek does not warrant or assume any legal liability or responsibility for the accuracy, completeness or usefulness of any information in this document. Axiomtek does not make any commitment to update the information in this manual. Axiomtek reserves the right to change or revise this document and/or product at any time without notice. No part of this document may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of Axiomtek Co., Ltd. Trademarks Acknowledgments Axiomtek is a trademark of Axiomtek Co., Ltd. ® Windows is a trademark of Microsoft Corporation. Other brand names and trademarks are the properties and registered brands of their respective owners. Copyright 2014 Axiomtek Co., Ltd. All Rights Reserved February 2014, Version A2 Printed in Taiwan ii Table of Contents Disclaimers ..................................................................................................... ii Chapter 1 Introduction ............................................. 1 1.1 Specifications ...................................................................................... 2 Chapter 2 Getting Started ......................................
  • A Comparative Study Between Operating Systems (Os) for the Internet of Things (Iot)

    A Comparative Study Between Operating Systems (Os) for the Internet of Things (Iot)

    VOLUME 5 NO 4, 2017 A Comparative Study Between Operating Systems (Os) for the Internet of Things (IoT) Aberbach Hicham, Adil Jeghal, Abdelouahed Sabrim, Hamid Tairi LIIAN, Department of Mathematic & Computer Sciences, Sciences School, Sidi Mohammed Ben Abdellah University, [email protected], [email protected], [email protected], [email protected] ABSTRACT Abstract : We describe The Internet of Things (IoT) as a network of physical objects or "things" embedded with electronics, software, sensors, and network connectivity, which enables these objects to collect and exchange data in real time with the outside world. It therefore assumes an operating system (OS) which is considered as an unavoidable point for good communication between all devices “objects”. For this purpose, this paper presents a comparative study between the popular known operating systems for internet of things . In a first step we will define in detail the advantages and disadvantages of each one , then another part of Interpretation is developed, in order to analyze the specific requirements that an OS should satisfy to be used and determine the most appropriate .This work will solve the problem of choice of operating system suitable for the Internet of things in order to incorporate it within our research team. Keywords: Internet of things , network, physical object ,sensors,operating system. 1 Introduction The Internet of Things (IoT) is the vision of interconnecting objects, users and entities “objects”. Much, if not most, of the billions of intelligent devices on the Internet will be embedded systems equipped with an Operating Systems (OS) which is a system programs that manage computer resources whether tangible resources (like memory, storage, network, input/output etc.) or intangible resources (like running other computer programs as processes, providing logical ports for different network connections etc.), So it is the most important program that runs on a computer[1].
  • Contiki – a Lightweight and Flexible Operating System for Tiny Networked Sensors

    Contiki – a Lightweight and Flexible Operating System for Tiny Networked Sensors

    Contiki – a Lightweight and Flexible Operating System for Tiny Networked Sensors Adam Dunkels, Björn Grönvall, Thiemo Voigt Swedish Institute of Computer Science IEEE EmNetS-I, 16 November 2004 Sensor OS trade-offs: static vs dynamic event-driven vs multi-threaded What we have done ● Contiki – an OS for sensor network nodes ● Ported Contiki to a number of platforms ● MSP430, AVR, HC12, Z80, 6502, x86, ... ● Simulation environment for BSD/Linux/Windows ● Built a few applications for experimental network deployments Contributions ● Dynamic loading of programs ● Selective reprogramming ● Static vs dynamic linking ● Concurrency management mechanisms ● Events vs threads ● Trade-offs: preemption, size Contiki design target ● “Mote”-class device ● 10-100 kilobytes of code ROM ● 1-10 kilobytes of RAM ● Communication (radio) ● ESB from FU Berlin ● MSP430, 2k RAM, 60k ROM Contiki size (bytes) Module Code MSP430 Code AVR RAM Kernel 810 1044 10 + e + p Program loader 658 - 8 Multi-threading library 582 678 8 + s Timer library 60 90 0 Memory manager 170 226 0 Event log replicator 1656 1934 200 µIP TCP/IP stack 4146 5218 18 + b Run-time reprogramming and loadable programs Reprogramming sensor nodes ● Software development for sensor nets ● Need to reprogram many nodes quite often ● Utilize radio for reprogramming ● Radio inherently broadcast ● Reprogram many nodes at once ● Much faster than firmware download via cable or programming adapter ● Reprogram deployed networks Traditional systems: entire system a monolithic binary ● Most systems statically
  • Embedded Operating Systems

    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.
  • Cg 2015 Huong Vu Thanh

    Cg 2015 Huong Vu Thanh

    c 2015 Huong Vu Thanh Luu OPTIMIZING I/O PERFORMANCE FOR HIGH PERFORMANCE COMPUTING APPLICATIONS: FROM AUTO-TUNING TO A FEEDBACK-DRIVEN APPROACH BY HUONG VU THANH LUU DISSERTATION Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Science in the Graduate College of the University of Illinois at Urbana-Champaign, 2015 Urbana, Illinois Doctoral Committee: Professor Marianne Winslett, Chair Professor William Gropp, Director of Research Professor Marc Snir Dr Robert Ross, Argonne National Laboratory ABSTRACT The 2014 TOP500 supercomputer list includes over 40 deployed petascale systems, and the high performance computing (HPC) community is working toward developing the first exaflop system by 2023. Scientific applications on such large-scale computers often read and write a lot of data. With such rapid growth in computing power and data intensity, I/O continues to be a challenging factor in determining the overall performance of HPC applications. We address the problem of optimizing I/O performance for HPC applica- tions by firstly examining the I/O behavior of thousands of supercomputing applications. We analyzed the high-level I/O logs of over a million jobs rep- resenting a combined total of six years of I/O behavior across three leading high-performance computing platforms. Our analysis provides a broad por- trait of the state of HPC I/O usage. We proposed a simple and e↵ective analysis and visualization procedure to help scientists who do not have I/O expertise to quickly locate the bottlenecks and inefficiencies in their I/O ap- proach. We proposed several filtering criteria for system administrators to find application candidates that are consuming system I/O resources ineffi- ciently.
  • RIOT, the Friendly Operating System for The

    RIOT, the Friendly Operating System for The

    The friendly operating system for the IoT by Thomas Eichinger (on behalf of the RIOT community) OpenIoT Summit NA 2017 Why? How? What is RIOT? Why? How? What is RIOT? Why a software platform for the IoT? ● Linux, Arduino, … bare metal? ● But as IoT software evolves … ○ More complex pieces e.g. an IP network stack ○ Evolution of application logic ● … non-portable IoT software slows innovation ○ 90% of IoT software should be hardware-independent → this is achievable with a good software platform (but not if you develop bare metal) Why a software platform for the IoT? ✓ faster innovation by spreading IoT software dev. costs ✓ long-term IoT software robustness & security ✓ trust, transparency & protection of IoT users’ privacy ✓ less garbage with less IoT device lock-down Why? How? What is RIOT? How to achieve our goals? Experience (e.g. with Linux) points towards ● Open source Indirect business models ● Free core Geopolitical neutrality ● Driven by a grassroot community Main Challenges of an OS in IoT Low-end IoT device resource constraints ● Kernel performance ● System-level interoperability ● Network-level interoperability ● Trust SW platform on low-end IoT devices ● The good news: ○ No need for advanced GUI (a simple shell is sufficient) ○ No need for high throughput performance (kbit/s) ○ No need to support dozens of concurrent applications ● The bad news: ○ kBytes of memory! ○ Typically no MMU! ○ Extreme energy efficency must be built in! SW platform on low-end IoT devices ● Contiki ● mbedOS (ARM) ● ● Zephyr (Intel) ● TinyOS ● LiteOS (Huawei) ● myNewt ● … ● FreeRTOS ● and closed source alternatives Reference: O. Hahm et al. "Operating Systems for Low-End Devices in the Internet of Things: A survey," IEEE Internet of Things Journal, 2016.
  • Internet of Things (Iot) Operating Systems Management: Opportunities, Challenges, and Solution

    Internet of Things (Iot) Operating Systems Management: Opportunities, Challenges, and Solution

    sensors Editorial Internet of Things (IoT) Operating Systems Management: Opportunities, Challenges, and Solution Yousaf Bin Zikria 1, Sung Won Kim 1,*, Oliver Hahm 2, Muhammad Khalil Afzal 3 and Mohammed Y. Aalsalem 4 1 Department of Information and Communication Engineering, Yeungnam University, 280 Daehak-Ro, Gyeongsan, Gyeongbuk 38541, Korea; [email protected] 2 Zühlke Group, Eschborn, 65760 Hessen, Germany; [email protected] 3 Department of Computer Science, COMSATS University Islamabad, Wah Campus, Wah Cantt 47010, Pakistan; [email protected] 4 Department of Computer Networks, Jazan University, Jazan 45142, Saudi Arabia; [email protected] * Correspondence: [email protected]; Tel.: +82-53-810-4742 Received: 9 April 2019; Accepted: 11 April 2019; Published: 15 April 2019 Abstract: Internet of Things (IoT) is rapidly growing and contributing drastically to improve the quality of life. Immense technological innovations and growth is a key factor in IoT advancements. Readily available low cost IoT hardware is essential for continuous adaptation of IoT. Advancements in IoT Operating System (OS) to support these newly developed IoT hardware along with the recent standards and techniques for all the communication layers are the way forward. The variety of IoT OS availability demands to support interoperability that requires to follow standard set of rules for development and protocol functionalities to support heterogeneous deployment scenarios. IoT requires to be intelligent to self-adapt according to the network conditions. In this paper, we present brief overview of different IoT OSs, supported hardware, and future research directions. Therein, we provide overview of the accepted papers in our Special Issue on IoT OS management: opportunities, challenges, and solution.
  • A Random Priority Based Scheduling Strategy for Wireless Sensor Networks Using Contiki

    A Random Priority Based Scheduling Strategy for Wireless Sensor Networks Using Contiki

    A Random Priority based Scheduling Strategy for Wireless Sensor Networks using Contiki Sajid M. Sheikh, Riaan Wolhuter and Herman A. Engelbrecht Department of Electrical and Electronic Engineering, University of Stellenbosch, Private Bag X1, Matieland, 7602, South Africa Keywords: Contiki, MAC, IEEE802.15.4, Priority Scheduling, Sensor Networks. Abstract: In recent years, wireless sensor networks (WSNs) have experienced a number of implementations in various implementations which include smart home networks, smart grids, smart medical monitoring, telemetry networks and many more. The Contiki operating system for wireless sensor networks which utilises carrier sense multiple access with collision avoidance (CSMA/CA) does not provide differentiated services to data of different priorities and treats all data with equal priority. Many sensor nodes in a network are responsible not only for sending their sensed data, but also forwarding data from other nodes to the destination. In this paper we propose a novel priority data differentiation medium access control (MAC) strategy to provide differentiated services called Random Weighted Scheduling (RWS). The strategy was implemented and tested on the FIT IoT-lab testbed. The strategy shows a reduction in packet loss compared to the default CSMA/CA scheduling strategy in IEEE802.15.4 WSNs when carrying data of different priority levels. 1 INTRODUCTION have a higher priority than normal data in a network (Koubaa et al., 2006). CSMA/CA treats all data with Wireless Sensor Networking (WSN) is one of the equal priority in a first in first out (FIFO) manner. main driving forces of the Internet of Things (IoT). In this paper we propose a novel scheduling WSN have been deployed in a number of different strategy that has been developed under the Contiki environments which include smart home networks, operating system and implemented and tested on the smart health, smart transport, smart educations and FIT IoT-lab testbed.