## 2 Related Works  
### Previous Single Plane IoT System  
The dual plane architecture is applied to the single plane IoT system developed in our previous research [3; 4]. For this reason, we will describe the single plane IoT system before introducing the dual plane architecture. The single plane IoT system conforms to the oneM2M (one Machine-to-Machine) protocol, which is an international communication protocol standard for IoT systems [5], and consists of four types of components: AE (Application Entities), MN-CSE (Middle Nodes-Common Service Entities), IN-CSE (Infrastructure Nodes-Common Service Entities) and IN-AE (Infrastructure Nodes-Application Entities). An AE is a program installed in IoT user devices, and its main purposes are to measure or sense its user's data and to send them to the MN-CSE. An MN-CSE acts as a gateway for traffic control and/or protocol conversion and conducts communications between AEs and IN-CSE. An IN-CSE functions as a monitoring or management server in the IoT system and gathers AEs data through MN-CSEs. An IN-AE can access a user's data by accessing the IN-CSE node via an IoT network. Three types of PHDs (Personal Health Devices)--Medication dispenser [6], Pulse oximeter [7] and Activity monitor [8]--were used as AEs in our previous studies and are also used in this paper. These PHDs conform to the ISO/IEEE 11073 protocol, an international standard for PHDs [9]. The CSE (MN-CSE and IN-CSE), which is the main part of the IoT system, consists of a Network Manager, a Message Manager, and a Resource Manager. The Network Manager deals with communications between AEs and an IN-CSE. The Message Manager analyzes the incoming messages and converts the ISO/IEEE 11073 protocol messages into the oneM2M protocol and vice versa. The Resource Manager manages resource trees in which the information of every object the IoT system manages is stored. Figure 1 shows the previously proposed single plane IoT system and the internal structure of the CSE. The communication procedures between AEs and the MN-CSE are divided into four phases: association, configuration, operation and disassociation phases [10]. During the association phase, PHDs and the MN-CSE establish a communication session using an AARQ (Association Request) and AARE (Association Response) messages. During the configuration phase, PHDs send their device configurations using a PRST (Presentation) message with an MDC_NOTI_CONFIG event type. In the operation phase, the measurement messages are transferred from the AEs to the MS-CSE using PRST messages with an MDC_NOTI_SCAN_REPORT event type. Finally, the disassociation phase is for disassociating a communication session between a PHD and the MN-CSE. In this phase, an RLRQ (Association Release Request) and RLRE (Association Release Response) message are exchanged. The traditional network applications, as well as the CSE in the single plane IoT system, have some shortcomings from both a message processing perspective and an architectural perspective [11; 12; 13]. The shortcomings caused by using kernel network stack in a packet processing perspective are as follows:  
* The CSE creates communication sockets using some system calls to receive and send messages. In this way, an incoming message is copied several times to the memory for the user-space network application (i.e., CSE), and the copy operations increase the overall system workloads. * The CSE receives an incoming message after processing by the kernel network stack, the design of which is quite complex, making this a time-consuming step that causes performance degradation. Figure 1: Structure of the Internet of Things (IoT) system and the Common Service Entities (CSE). * The CSE receives notice on an incoming new message by a kernel's interrupt mechanism. That is, an interrupt occurs whenever a new message arrives in the system, and frequent interrupts can be problematic for an IoT system, as it should provide continuous and real-time services.