SecIoTComm: An Actor-Based Model and Framework for Secure IoT Communication

Internet of Things (IoT) ecosystems are becoming increasingly ubiquitous and heterogeneous, adding extra layers of complexity to secure communication and resource allocation. IoT computing resources are often located at the network edge and distributed across many heterogeneous sensors, actuators, and controller devices. This makes it challenging to provide the proper security mechanisms to IoT ecosystems in terms of manageability and maintainability. In an IoT ecosystem, computational resources are naturally distributed and shareable among their constituency, which creates an opportunity to distribute heavy tasks to them. However, resource allocation in IoT requires secure and complex communication and coordination mechanisms, which existing ones do not adequately support. In this paper, we present Secure Actor-based Model for IoT Communication (SecIoTComm), a model for representing secure IoT communication. SecIoTComm aims to represent secure IoT communication properties and design and implement novel mechanisms to improve their programmability and performance. SecIoTComm separates the communication and computation concerns, achieving design modularity in building IoT ecosystems. First, this paper presents the syntax and operational semantics of SecIoTComm. Then, we present an IoT framework implementing the key concepts of the model. Finally, we evaluate the developed framework using various performance and scalability metrics.


Introduction
The Internet of Things (IoT) creates opportunities for the provision of data-driven services in many shapes and forms [1][2][3]. For instance, consider a remote patient monitoring IoT system serving physicians who need to monitor their patients' health conditions. Another example in the agricultural sector is a livestock-monitoring IoT system that utilizes in situ sensors mounted on a livestock farm to collect data regarding cattle's location, well-being, and health. This information would help farmers identify diseased animals so that they can be separated from the herd, thereby preventing the spread of diseases [4].
The IoT ecosystem is an engineered system that integrates computational algorithms with physical sensing components and processes. The computational algorithms coordinate and communicate with sensors that monitor cyber and physical indicators, along with actuators that modify the cyber and physical environment [5]. Such intelligent systems use sensors to connect all distributed intelligence in the environment to gain a more in-depth knowledge of the environment, enabling more accurate actions and tasks. Such an IoT ecosystem can scale to billions of end devices (i.e., sensors and actuators) connected to gateways, which act as the aggregation points for a group of sensors and actuators to coordinate the connectivity of these devices to each other and an external network [6].

Related Work
Although there are some technologies focused on IoT systems [2,6,10,11], there is relatively limited foundational work. This is in part because of the lack of precise understanding, specification, and analysis of such systems, and consequently, there is limited platform support for programming them.
The programming required for offering a new sensor-based system can be significant if started from scratch. However, there is an opportunity created by the similarity in the patterns of communication required for such IoT systems, where contextual data offered by a number of contributors become the basis for the system. This pattern of communication was originally defined in [12] as multi-origin communication. Multi-origin coordination mechanisms can be provided on a platform over which such class of services could be implemented relatively easily.
Ahmed et al. interpreted and implemented these mechanisms for the domain of crowd-sourced services [13,14] by implementing CSSWare, a middleware which provides a set of domain-specific mechanisms to support initiating and managing services. Having CSSWare as a platform, all that a service designer needs to do to launch a new service is to identify a constituency of potential contributors and to provide a few lines of servicespecific code for specifying the nature of contributions and for aggregating them when they arrive.
In [15], Agha presented a coordination model for large-scale distributed actor systems. The developed model allows actors to adapt the underlying communication mechanisms to support such systems. The author presented a scoped semantics for the proposed coordination model, named synchronization model, based on various declarative synchronization constraints. Similarly, in [16], Frølund presented another coordination approach, allowing the coordination of distributed application components in the form of abstract and reusable coordination constraints. Christian J. et al. [17] presented ActorSpace, a new programming paradigm to provide a communication model in the form of actor context for pattern matching on certain actor attributes to enable communication to certain enabled groups defined by the patterns.
Interactors [18], which is the most relevant work to our model, is a model for representing complex communication in distributed systems. Interactors aims to separate the communication concerns from functional concerns of such systems, whereas communication is represented as self-driven and can dynamically change as per communication needs. The authors presented the syntax and operational semantics of multicast, which is a richer form of communication pattern, as a feasible solution for implementing complex types of communications in actor-based systems. Prokopec et al. [19] proposed Reactive, a model to simplify the composition of communication protocols using first-class channels and event A composition of n communication configurations Figure 1 illustrates an example scenario for the interaction between IoT devices. A rectangle represents an AS's boundary, representing a single IoT device. Each device has a set of ports using which it could communicate with other devices in the IoT ecosystem. The figure also illustrates the components of IoT devices in our model. White circles are input ports, black circles are output ports, and the lines with arrows represent message flows. Actor Systems (AS 1 . . . AS 3 ) are IoT gateways collecting sensor data from environmental via various heterogeneous sensors. AS 4 can be a local data logger on the network edge, used for aggregating sensor feeds data for local data processing before sending the aggregate to the cloud. AS 5 is a user device that consumes the services provided by the local server on the network edge. SecIoTComm configuration helps in studying the properties of secure IoT systems in depth at runtime. We formally define SecIoTComm configuration k, which is a snapshot of the actor system from an idealized observer, capturing an instantaneous global state of the system as a 6-tuple as follows: A|C|S|M|α|µ| where A is a finite set of computations; C is a finite set of communication; S is a finite set of security configuration; M is a finite set of messages m in the communication layer; α is a mapping of actor addresses to their behaviors (actor map); µ represents transient, buffered, or floating message in the system; and χ are the external actors.
A message m has two parts: message content v and recipient a, represented as a ⇐ v. A, C, and χ are represented in our model as sets of actor addresses, whereas A = Dom(a) and ρ ⊂ A. The following two constrains must hold: where FV is a free variable of α(a). The receptionist of k is n i=1 ip i where ip i is the ith input port of k and n is the number of such ports in k.

Computation Definition
We define the IoT computation, A, as a reduction process with a finite set of labeled transitions, T, represented as a triple-tuple: where I is a set of actors in their initial computation states modeled as input ports (inports) or ip, and O is a set of actors in their final computation states modeled as output ports (outports) or op that are ready to create a secure communication with other actors i ∈ I hosted in other actor systems. Communication is initiated from the outports of one AS to the inports of another one. inports and outports represent the computing actors in the communicating ASs. For simplicity, we refer to any computing actor in our model as computation; hence, ip ∈ A ∧ op ∈ A.

Communication Definition
Communication, C c , is represented by a standalone channel created by a computation to enable secure communication among IoT devices. We model IoT communications as: where C is a finite set of communications modeled as actors, and J is a mapping of communication to the computation of the form (c, ip, op), where c is the actual communication, ip is the target of the communication, and op is the origin of the communication. Note that the target is the same as inport, (ip), of the recipient actor system, and op is the outport of the source actor system.

Security Definition
Security, S, is defined as a set of security primitives accessible by the interacting actors in a given IoT ecosystem. It is used to secure its computations and communications. An instantaneous snapshot of all security mechanisms in the IoT system is called security configuration, which is represented as: where G is the set of security primitives and X is the mapping of security primitives to computation. Each mapping of security primitive to computations is of the form (a, k s ), where a is the computing actor that applies the security primitive k s ∈ G to communications.

SecIoTComm Operational Semantics
The SecIoTComm configuration evolves due to state changes of the hosted actors, which leads to a transition in configurations. The actor state can be one of the following: • Idle-uninitialized, (a ) a a newly created actor a by an actor a but uninitialized. • Idle-initialized, (a , b) a a newly created actor a by an actor a initialized to a behavior b.

•
Busy, (a , e) a actor a is busy evaluating an expression e.
An actor transition can either be one of the two categories below: The transition relation on an actor configuration determines the future configuration. A labeled transition relation → on configuration defines a set of computations of an actor configuration. Computations are reductions of expressions. Hence, transitions are a reduction process. The same rules apply to transitions and reductions, as they are synonymous.
We represent an actor expression as e, which can be a value expression or non-value expression e = v. A value expression is an expression, v, in its reduced form; hence, a non-value expression is decomposed into a reduction context R filled with redex (reducible expression), that is: where R is the reduction context, and r is the redex We represent a transition rule by λ

Actor System Initialization
The Actor System creates a new actor actor and returns the actor name, as described by this transition rule: where create_a() is a redex for actor creation, which creates the top guardian actor of the actor system. The Actor System then initializes the behaviors of the freshly created actors with the name a to b and returns its behavior, as described by the following transition rule:

Receiving a Message through ip ∈ A c
A computation ,ip, that is triggered when an actor receives a message m of the form v ⇒ a can perform one of the following actions by applying the received message to its current behavior: (i) Perform a multi-step computation; (ii) Create a communication; (iii) Store the result of a computation.
Formally, a message receipt by any actor can be described by the following transition rule: Below, we described the transition rules of the two cases of message receipt and their behavior: (i) Message receipt by a computation Message can be received on i ∈ I of C a , as follows: Message can be received on o ∈ I of C a , as follows:

A Computation Creates a Communication
A computation creates a communication as an independent entity with a separate communication logic to carry out its communication logic, as follows:

A Communication Receives a Message
A communication can receive a message from another communication or computation. In both cases, the message is applied to its current behavior, as follows:

A Communication Sends a Message
A communication can send a message to another communication or computation. The first case models actor routing, while the second case models a response or an acknowledgment. The latter case generates a message that is sent in the communication channel towards its destination, as described below:

Secure Communication
Secure communication is initiated between two or more Actor Systems such that k s ∈ G = null, where k s is the security configuration for this communication. The following equations represent the process of initiating a secure communication between Actor Systems: (19) where m is the message that initiates the security configuration and con f is the created security configuration. Secure communication is established between Actor Systems when a computation actor hosted in the sender Actor System sends a message m to a communication c to retrieve a security configuration con f . This process is formally represented as: where m = h ← con f .
Once the security configuration is retrieved from the device memory, it is immediately applied to the existing communication, as follows: (21)

Composition Semantics and Communication Patterns in SecIoTComm
We define communication compositionally. In other words, simpler communication can be composed to create more complex ones by applying a set of composition rules. A communication connects to other communications using input and output ports. Messages can be received by a communication at its input ports and can be sent out to other communications from its output ports. An external observer can only see the input ports and the output ports of the final composed communication.
The composition of two communications k 1 and k 2 is represented as The remainder of this section presents the semantics of communication composition. We abstract away from the representation of communication internal messages because we are only concerned about the coming together of communications.

Input Convergence Composition
Input convergence composition can be used to implement a one-to-many communication pattern in SecIoTComm. We define one-to-many communication as a type of communication involving a single actor from an actor system AS 1 communicating to n number of actors in another system AS 2 .
As shown in Figure 2, the input convergence composition takes two parameters as input: a target set D of computing actors and a behavior b informing the source computing actor about the number of communication to create. The newly created communication actors make the different targets of the source computing actor their targets and inherit the original behavior of the source computing actor. Then, the source computing actor changes its behavior to the new provided behavior, which forwards its messages to different communication actors who already know its targets. This can be represented formally as follows: where D is the set of recipients (targets) to be composed, b is the new behavior that is passed as a parameter to the composition, and S is a set of all sources of communication. Note that D and S are computing actors and each member of D communicates with all members of S. C new is the set of new communications created using the create_a() redex of actor creation to carry out the communication. {i = 0 n} is the range of i values, and S is a security configuration. N is the total sum of sources and targets. The actor map of the composition is obtained by including the actor map of the new communications in the complete map of the computations in the system, which consists of sources and targets.

Output Convergence Composition
Output convergence composition can be used for many-to-one communication patterns [5]. We define many-to-one communication as communication involving many senders (actors) hosted in a source actor system AS 1 targeting one recipient hosted on another actor system AS 2 .
As shown in Figure 3, the output convergence composition takes three parameters: a set of sources (senders) S, a behavior b, and one destination d. The set of sources informs the composition of the number of new communications to create, represented by a directional line with an arrow showing the direction of communication. This can be represented formally as follows:

Complementary Composition
Given two or more SecIoTComm configurations, k 1 and k 2 , many-to-many communication between k 1 and k 2 involves multiple computing actors on k 1 communicating with multiple computing actor on k 2 via complex communication patterns. This can be formally represented as: As shown in Figure 4, the complimentary composition takes one parameter: a group set G in the form of m j=1 (ip j , op j , b j ). Below is the formal representation of the complimentary composition of n communications:

Port-Binding Composition
Port binding is a general-purpose composition that merges the outputs ports of one actor system (or composition) with the inputs ports of another actor system or composition. To compose two actor systems configurations k 1 and k 2 , we provide a set of triples for port-to-port binding whose entries are of the form (op i , ip j , b), where op i is the ith output port of k 1 , ip j is the jth input port of k 2 to be merged, and b is the provided behavior.
As shown in Figure 5, the port-to-port composition of n communication can be formally described as: where C new = m j=1 C j is the set of new communications created that connects the output ports of k 1 to the input ports of k 2 . J new = m j=1 J j is the associated new mapping of communications to computations. The actor map of the port binding composition is generated by adding the map of the newly created communication to the composite map of the participating actor system. The set of messages becomes the composite messages of the two composed configurations k 1 and k 2 . ρ is the receptionists and equivalent to the inports (ip) of the actor system.

SecIoTComm Implementation Framework
The design of the implemented framework builds on the domain-specific mechanisms for SecIoTComm described in the previous sections. Specifically, we built a set of programming constructs implemented in a framework to support the programmability of IoT secure systems. We prototyped the distributed framework as an actor system. The distributed run-time system for the proposed framework is organized with parts executing on the IoT end-devices at the sensing side and remote servers on the platform side. Figure 6 illustrates the system design of the SecIoTComm implementation framework. Our prototype used four Raspberry Pi devices, a set of various sensors, and a MacBook server to represent the remote server. The IoT sensors represent the sensor data sources. Each Raspberry Pi device and the MacBook server hosts an actor system, which holds the security configurations.
Each Raspberry Pi 4 device is equipped with a 1.5GHz Quad-core Cortex-A72 (ARM v8) 64-bit SoC, 8GB LPDDR4-3200 SD-RAM, 5.0 GHz IEEE 802.11ac wireless, Bluetooth 5.0, and BLE Gigabit Ethernet, running Raspbian OS. We also used one MacBook laptop with an M2 GPU (8-core) processor and 16GB of RAM. The other security components, such as IoT protocols, communications, and computations, are represented by individual actors. We used Scala version 2.1.3 with Akka version 2.6.19 running on JVM 1.8. We set the minimum and the maximum number of active threads in the pool of threads, called parallelism-min and parallelism-max, to 8 and 64, respectively. The parallelism factor is set to 8. The SecIoTComm framework is implemented using Akka [9], an open-source toolkit for building actor-based concurrent applications using the Scala programming language. Akka can be used to create highly concurrent, distributed, and fault-tolerant applications which can span across multiple processor cores and networks. Akka provides a high-level abstraction to low-level synchronization mechanisms of multi-threaded applications by hiding them from programmers, allowing them to focus on application-specific details.
We used several routing, clustering, and networking features embodied in Akka to realize the network architecture of the SecIoTComm framework. SecIoTComm communication is established through actor messages between JVMs residing on each Actor System hosted on each Raspberry Pi. Communication among JVMs is encrypted using the developed security configuration via the mTLS (mutual Transport Layer Security) protocol.

Key Generation and Secure Communication
We used two Java tools, keytool and pwgen, for the generation of security keys and passwords used in the security configurations, respectively. Security keys are generated by specifying the parameters of the keys such as alias, algorithm, keysize, validity, etc. Security keys are one of two types: private and public. As shown in Figure 7, private keys are unique, self-signed, and stored in a password-protected keystore in the device's memory. It is used for exchanging encrypted messages among ActorSystems via asymmetric encryption. Public keys are stored in a password-protected truststore in the device's memory and contain many public keys of other devices in the framework's trusted list. Figure 8 shows the keystore of Actorsystem3 (as3) that contains actorsystem1 (as1) and actorsys-tem2 (as2) as trustee devices.
Additionally, the framework poses the following security features: • Immutable messages: Messages are constructed using case classes in Scala, so any malicious party cannot mutate them. • Immutable State: We used Actors' property of immutability state as a layer of security on actor computation.  Figure 9 illustrates the class diagram of the framework running on Raspberry Pi devices. Actor is a top-level actor class that implements a receive method for changing the actor's behavior when receiving a new message. The Behavior class implements the security functionalities of the framework, including: (i) the retrieve(key) function, used to retrieve the associated security configuration of a public key; (ii) the encrypt (key, target) function, used to encrypt the target configuration given a private key; (iii) the delegate (m, target) function, which sends a delegation task to another actor in the ActorSystem; and record(content), used to store a security configuration. Computation class extends the Actor and Behavior classes. It implements the computational functionalities of the framework.   ., t1, t2, t3, and t4). Events can be classified as computation, communication, or actor creation event. As shown in the figure, the execution time of a computation depends on the length of its computational sequence. When an ip actor carries out a computation, it becomes in the busy state during which it cannot process any other messages until the current state becomes idle. The computation time, t i , ranges from 0 to <∞ for non-value expressions. An (ip) actor becomes (op) after the execution of a computation.

Runtime Event Diagram of the SecIoTComm Framework
When an ActorSystem wants to communicate with another ActorSystem, the (op) actors of the former initiate the communication process by establishing a communication channel using a predefined security configuration. The communicated actor message, along with its metadata, is received by the inport of the target ActorSystem. The execution time of the message is represented by t < ∞.
Communication in SecIoTComm is asynchronous as a computation op creates a finite number of communication actors to carry out multiple communication concurrently. Computation, on the other hand, is concurrent for different ports. Ports ip 1 and ip 2 belonging to the same ActorSystem can carry out computation concurrently with execution time t 1 and t 2 , respectively. Distributed computation is defined by task delegation, where an (ip 1 ) actor sends a computational task to (ip 3 ) on another ActorSystem to carry out a certain computation and send back the result.

Evaluation
This section presents our experimental evaluation of the SecIoTComm framework for performance and scalability. We compared the performance of two cipher suites encryption algorithms running on the top of our framework: TLS_DHE_RSA_W ITH_AES_128_GCM _SH A256 and TLS_ECDHE_RSA_W ITH_AES_128_GC_SH A256. Both cipher suites are recommended by the Internet Standard security (RFC 7525) for IoT systems. Our study evaluated various key sizes from 512 bits up to 4096 bits. We observed the impact of changing the key size on memory consumption and CPU computational cycles. Figure 11 shows the CPU and memory utilization of Raspberry Pi 1 in the idle JVM state when having a fresh security configuration in place. The idle JVM state of a Raspberry Pi device happens when no active functionalities are running on the device, such as communication, computation, or security-related activities. As shown in the figure, the total CPU and memory utilization after initializing the security configurations are negligible overheads at the idle JVM state. Figure 11. The CPU and memory utilization of the Raspberry Pi device in the idle JVM state. Figures 12-19 show the CPU and memory utilization of Raspberry Pi 1 and 2 devices when using different cipher suites with various key sizes. The spike in CPU initialization at the first 25 seconds of the experiment resulted from the overheads of initiating the TCP communication (e.g., three-way handshake process).

Figure 12.
The CPU and memory utilization of the Raspberry Pi device using TLS_DHE R SA_W ITH A ES_128_GCM_SH A256, keysize = 512. The CPU and memory utilization of the Raspberry Pi device using TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, keysize = 1024. Figure 12 shows the CPU and memory utilization when using the SHA256 encryption standard with keysize 512 bits in Galois-Counter mode. We observed improvement in the peak CPU consumption overhead caused by TLS handshake from 170% to 160%. The handshake duration and average CPU consumption after handshake completion remain the same at approximately 23 s and 5%, respectively. The memory overhead for this configuration is about 40Mb. The memory usage remains comparably the same for Figures 12-14. Figure 13 shows the impact of doubling the keysize from 512 to 1024 bits on the performance. As shown in the figure, the CPU consumption's peak is pushed from 160% to 165%, while the handshake duration and average memory utilization remain the same. The memory overhead for this configuration is 35 Mb. Figure 14.
The CPU and memory utilization of the Raspberry Pi device using TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, keysize = 2048.

Figure 15.
The CPU and memory utilization of the Raspberry Pi device using TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, keysize = 4096.

Figure 16.
The CPU and memory utilization of the Raspberry Pi device using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, keysize = 2048.

Figure 17.
The CPU and memory utilization of the Raspberry Pi device using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, keysize = 512. Figure 14 shows the Raspberry Pi device in the active state of communication using Transport Layer Protocol (TLS), Diffie-Hellman Ephemeral (DHE), and Rivest Shamir Adleman algorithm (RSA) for the exchange of cipher suites, authentication, and creating and exchanging session keys. Advanced Encryption Standard AES is used for encryption and Secure Hash Algorithm 256 (SHA256) for integrity check. SecIoTComm framework uses distributed authenticated encryption, where the handshake process is distributed between IoT devices involved in communication.
As shown in Figure 14, the TLS handshake occurs in the first 23 s of the experiment. The TLS handshake increases the CPU consumption up to 170%. Such overhead drops to about 5% on average during the remaining time of the experiment. The overall memory overhead is 37 Mb. Comparing the average CPU and memory overhead illustrated in Figure 14 with the idle state displayed in Figure 12, we can conclude that the SecIoTComm framework is lightweight and suitable for resource-constrained IoT devices.  The CPU and memory utilization of the Raspberry Pi device using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, keysize = 4096.
In Figure 15, the keysize is doubled again to 4096 bits, while keeping all other experiment's parameters the same. The TLS handshake increases the peak CPU utilization to 196% within the first 30 s of the experiment. Upon completing the TLS handshake process, the average CPU utilization remained similar to Figure 14. The overall memory overhead was 40 Mb.
In Figure 16, we evaluated the performance using Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) protocol for key exchange, Rivest Shamir Adleman algorithm (RSA) for message authentication, Advanced Encryption Standard in Galois-Counter mode for encryption, and Secure Hash Algorithm 256 (SHA256) hash for integrity check.
We observed that the CPU and memory utilization are similar to the Diffie-Hellman Ephemeral (DHE) key exchange scheme used in the previous three experiments (Figures 13-15); however, the ECDHE variant reduces the computation cost. The peak CPU utilization during TLS handshake was measured to be 164% during the first 25 s of the experiment. After completing the TLS handshake process, the average CPU utilization was 5%, and the overall memory overhead was 30 Mb.
In Figure 17, we evaluated the performance using ECDHE, RSA, and SHA256 using a keysize of 512. The peak CPU utilization during TLS handshake was measured to be 155% during the first 25 s of the experiment. After completing the TLS handshake process, the average CPU utilization was 5%, and the overall memory overhead was 35 Mb.
In Figure 18, we evaluated the performance using ECDHE, RSA, and SHA256 using a keysize of 1024 bits. The peak CPU utilization during TLS handshake was measured to be 163% during the first 25 s of the experiment. After completing the TLS handshake process, the average CPU utilization was 5%, and the overall memory overhead was 45 Mb.
In Figure 19, we evaluated the performance using ECDHE, RSA, and SHA256 using a keysize of 4024 bits. The peak CPU utilization during the TLS handshake was measured to be 183% during the first 25 s of the experiment. After completing the TLS handshake process, the average CPU utilization was 5%, and the overall memory overhead was 50 Mb. Tables 2 and 3 summarize the results of the performance of the DHE and ECDHE experiments with different key sizes, respectively.

Scalability
We ran a set of experiments to determine the impact of changing the number of actors on computational CPU utilization at the gateway. The number of actors determines the number of sensors a gateway can support, where each actor manages that sensor's communication, processing, and storage need.
In the first experiment, we used one actor to perform all computations. Then, we gradually doubled the number of actors in the following experiments. As shown in Figure 20, as the number of actors used in the computations increases, the average CPU consumption increases until reaching 5000 actors. As we increase the number of actors in the communication layer to 5, 10, 50, 100, 500, and 1000 simultaneous actor communications, the average CPU utilization reaches up to 5%, 6%, 10%, 15%, 21%, and 25%, respectively. This shows the scalability of a single Raspberry Pi device running the SecIoTComm framework.
At the point of using 5000 actors, we could not observe apparent differences in CPU utilization. This may be justified by the extra overheads of initiating the actors and communication delay. These results suggest that having a large number of actors is not necessary to improve the overall performance of intensive computations. Therefore, programmers must find an equilibrium between the number of actors and CPU cycles required to perform the calculations.

Computational Task Delegation
We implemented a fine-grained resource coordination and control mechanism through our framework's computational task delegation feature. Computational task delegation enables IoT devices to discover and utilize the computational resources of other devices in the network. Computational task delegation is implemented using inports (ip) and outports (op) actors. Tasks messages are received through ips actors, executed, and sent out through ops actors. An op actor creates communication with a designated behavior appropriate for its communication of three types: one-to-one, one-to-many, and many-toone communications. Figure 21 shows the effect of delegating a computationally intensive task from a Raspberry Pi device to a remote server (i.e., MacBook) on the network. The communicated task is to compute the fib(x), where x is a large integer value. As shown in the figure, the total CPU time for computing fib(x) is decreased by a factor of 5 after delegating the task of computing the Fibonacci of 50 to a more powerful server.

Conclusions
In the paper, we presented Secure-Actor-based Model for IoT Communication (SecIoT-Comm), a model and framework for representing secure IoT communication. SecIoTComm model defines IoT communication compositionally, where we presented a set of composition rules for constructing complex communication by composing simpler ones. We also presented the operational semantics for SecIoTComm, which are defined by a transition relation on SecIoTComm configuration. We also presented the design of a framework implementing the SecIoTComm model, which can be used to easily create complex secure IoT communication. Finally, we conducted several sets of experiments to evaluate the performance and scalability of the framework.
Work is ongoing in multiple directions. First, we would like to study important properties of secure IoT communication, focusing on equivalence. Second, we are looking at building programming constructs implemented in a platform to support the task delegation algorithm without manually setting up the communication infrastructure.