Membrane systems can be used to describe transfer of objects between diferent locations (membranes) and their eventual transformation. Network transmission protocols provide something similar, especially the transfer of data. In this paper, we describe the use of a membrane system for modeling data transmission between IoT devices, while it is possible to take this model as a generalization of the transmission operation transferable to other protocols or to various programming languages. The paper also discusses the possibility of using rules of the membrane system to create a simple firewall.
dent of each other and work in parallel. Parallel processing can also be described using membrane systems, where the data transfer between devices can be modeled using evolution rules.
Definition 2 ([11]). The Internet of Things (IoT) is a network of various types of smart objects (so called things) and devices. The things are connected to the Internet and communicate with each other with minimum human interface.
They are embedded with abilities as sensing, analyzing, processing and self-management based on interoperable communication protocols and specific criteria. These smart things should have unique identities and personalities.
We assume the reader to be familiar with the basics of
formal language theory and membrane computing. For
further details, we refer to [9] and [
As mentioned above, the basis of membrane systems is
a membrane structure. A membrane can contain objects
and/or nested membranes. The main membrane contains There are several common communication models
all the other membranes, we call it the “skin membrane”. (or communication patterns) used in IoT networks, the
Objects can be handled using evolution rules. Figure 2 model Publisher-Subscriber is quite common because it
shows a membrane system with one skin membrane and is closer to the needs of IoT than other models. There
four nested membranes. Almost all membranes contain are three types of components: publishers produce data,
at least one object (objects can be usually simply denoted subscribers consume and process data, and the controller
by letters, but here we use more complex objects with (often called broker or server, depending on the specific
various parameters). protocol) as the central point of the network mediates
Definition 1 ([
In practice, various higher-level protocols are used in IoT networks, such as MQTT, XMPP, CoAP, AMQP, or simply HTTP as in classic computer networks. Furthermore, we will mainly follow the MQTT protocol, in terms of terminology, message types and communication scheme.
More details about IoT network communication models, including protocols, can be found in [12]. Very clear and brief introduction to MQTT messages is in [13]. (i) is a nonempty alphabet, its elements are called
objects, (ii) is a membrane structure consisting of membranes, the membranes are labeled by the elements of , (iii) , 1 ≤ ≤ , are strings representing multisets over associated with the region of the -th membrane in , (iv) , 1 ≤ ≤ , are finite sets of evolution rules associated with the region of the -th membrane in ; an evolution rule is a pair (, ), also written → , where • is a string over , • = ′ or = ′ , where ′ is a string over ︀{ ℎ, , ⃒⃒ ∈ , 1 ≤ ≤ }︀ , and is a special symbol ∈/ representing dissolution of membrane.
The objects can be transported by the evolution rules through membranes due to the targets out (to the parental membrane) or in (to the child membrane specified by the index), or they remain in the original membrane ( here).
We can find a lot of definitions of the Internet of Things, but none of them is fully descriptive. Their formulation depends on the usage of such specific IoT structure. In [11] there are several definitions taken from multiple sources. We can compose the following definition from them: The given definition of the P System does not meet our requirements: we need a slightly more dynamic structure, where it is possible to create new objects due to external influences (e.g. to generate an object containing temperature data), to pass objects to a real device, but also to generate or delete rules. There are two possibilities:
The second option is more feasible for our purposes, however, with the possibility to change the set of rules in membranes from outside (there is no need to change the definition of membrane system). The set of rules will be changed continuously, but the impact will only be a change in the operation of the system, not collisions or system errors.
Devices 6 6 6 6 6 6messages ? ? ? ? ? ?
Control Layer 6 6 6 6 6 6objects ? ? ? ? ? ?
Cloud 6 ? Regular Network
Controller (Server) ' 'Comp1
(1, south.temp, 1, 34) & 'Comp2
(2, time) & (2, north.temp, 1, 18) (1, south.temp, 1, 33) &
The added control layer will be able to afect objects and rules at each step of the computation. Figure 1 demonstrates the whole structure. The control layer is above the membrane structure, this layer communicates using a suitable protocol with other components: a local network and, indirectly, the Internet, the cloud. • (ID, credentials) is sent to negotiate a connection to the controller. The sending component (with the present ID) can act as a publisher and/or subscriber after the connection is established. • (ID) is sent by the component when terminating
the connection.
The components Comp1 and Comp2 are thermometers, Membrane Layer the first one on the south side of a house and the second one on the north side of a house (see the names of the Figure 1: Communication Architecture topics to which they contribute). Both thermometers generate temperature data at regular intervals, which means
The membrane layer contains a P System with a mem- that the object appears regularly in the corresponding brane structure, objects and rules as prescribed by the membranes. In the next step, this object is transferred to definition. The only change from the definition is the the outer membrane using a rule. addition of semantics. The objects contain semantic infor- The length of the interval is set on the given device, it mation (e.g. the identifier of the sending membrane, the can be diferent on each device. In our case, the object published data, the credentials when connecting). The for the first component is generated in each step of the rules only take this information into account in their no- membrane system operation; the second component has tation; the semantic information is not changed by rules, a bit longer interval. only transited, or a new object with semantic information Comp2 is a more sophisticated device that can also is created. display time, it sent an order to synchronize the time
The control layer keeps the state of the P System (ref- data (however, there is no component in the system yet erences to membranes and rules) and other information that would serve as a publisher for the given topic). – topics, subscriptions etc. And it makes interventions Comp3 is a display that has just been activated and it to the membrane layer (adding new objects, picking up is sending an order for data of the first two components some other objects etc.). (temperature topics).
Each device communicates with one assigned compo- The fourth component is being activated – an object nent from the control layer, and each component is con- has appeared in the skin membrane environment for nected to one assigned membrane from the membrane connecting this membrane to the system (activating the layer. The devices do not communicate directly with corresponding device). According to the semantic data each other, nor do the components, only the membranes of the object, it may be a doorbell. forward objects to each other. In Figure 2 we can see several objects in various mem
The separation of the data transfer itself into the mem- branes. Each of the objects also has properties. The brane layer has another positive efect: it is not necessary objects passing through membranes represent messages for all devices to use the same protocol and provide data sent between components. We use the following types with the same meta-information, the control layer can of objects in our system: perform reconciliation.
The objects and are intended for activation and deactivation of components. In the real world, this means For each component , topic and retain value : establishing a session between a component and the con- (, , , data) → (, , , data) troller (, connect) and terminating the session (). When These rules can also exist for the topics in which the establishing a session, the component authenticates itself component does not publish because the object on the (must pass credentials). left side of the rule appears in the membrane only when
The object is intended for ordering a subscription to the component starts publishing data to the topic. a selected topic, and the object serves to unsubscribe.
Both objects need the sender’s ID, and contains the For each component and each topic topic name to subscribe. (, ) → (, )
The objects and are used for the publish operation.
We need two types of objects for this operation because We create these rules again for all possible topics. we need to distinguish the two phases of the message Similarly, we need to transport other objects from the path (from the publisher to the controller and from the components : controller to the subscriber). In the second phase, the sub- (, credentials) → (, credentials) scriberID property is added to the object. The properties () → () of and correspond to the publish message type: the (, ) → (, ) for all possible topics sender’s ID (publisherID), the topic to contribute. One of the properties is the “retain” value that determines 3.2. Control Layer whether the published data should be stored for newly connected subscribers, not just forwarded to current sub- The role of the control layer is to mediate communication scribers. And of course the data. For we need one between the membrane system and devices. additional property, the target (subscriberID). If a device sends the message to establish a connection The use of the denoted objects is shown in Figure 3. with the controller, the control layer creates an object Let us define the evolution rules for each membrane. with the device index and credentials in the correspondThe rules are used to transport objects between mem- ing membrane. If a device produces data and sends the branes. “produce” message, the control layer creates an object
Assume that the controller has a database (denoted with the appropriate parameters in the corresponding as subscriptionsDB) of all subscribers for each topic. For membrane. The procedure is similar when any other simplicity, we represent the mentioned database as a set message occurs. of ordered pairs (topic, subscriber). Each topic can have If an object indicating a message for the corresponding multiple subscribers and each subscriber can subscribe device appears in a membrane, the control layer reacts to multiple topics. again: it removes the object from the membrane and passes the relevant message to the given device.
∀ subscribers
// Parental message/object with one common
property, all messages have a sender: message: type, // publish, deliver,. . .
ID; // ID of the source component // Object generated by a publisher, going to the
controller (the first phase of publishing message): publish (child of: message): . . . . . . . . . . . . . . . . topic, retain, // 0 or 1 data; // Object transformed by the controller, going to
a subscriber (the second phase): deliver (child of: publish): . . . . . . . . . . . . . . . . .
subscriberID; // Subscribing message with an order: subscribe (child of: message): . . . . . . . . . . . . . .
topic; // topic to subscribe // Unsubscribing message for some topic: unsubscribe (child of: message): . . . . . . . . . . .
topic; // topic to unsubscribe // Connection message for a component: connect (child of: message): . . . . . . . . . . . . . . . . credentials; // e.g. username, password topic: topic, lastPublisher, lastValue; // last published data order: topic, subscriberID; // Parental object for all entities: entity:
ID, // identification number membrane, // ref. to the corresp. membrane device; // ref. to the corresp. device component (child of: entity): turnedOn, // 0 (false) or 1 (true) // Properties for publishing: publishTopic, publishRetain, // 0 or 1 // Property for subscribing: topic[] orderedTopics; controller (child of: entity): component[] components, authenticator, topic[] topicsDB, // registered topics order[] subscriptionsDB; // subscriptions // Disconnection message for a component: disconnect (child of: message) . . . . . . . . . . . . . membranes) and the message form (for devices). For the publish message, if the protocol used by the given device does not provide working with topics, we can use the
The control layer does not deal with the forwarding of property publishTopic. messages or the transfer of objects, the membrane system In contrast, the controller does not perform transforis in charge of these operations. mations, but works with databases whose list can be seen
All the messages sent between components and their in Algorithm 2. If the controller device itself does not corresponding objects are shown in Algorithm 1. Each provide authentication, the control layer can do it. For message/object has its sender, so all messages (objects) new subscriptions, it is possible to use the retain property, have the property ID (sender’s ID) inherited from the par- and we can also add additional functionality if required. ent message/object “message”. Other properties depend The transformation between the objects and is on the type of message/object. made inside the membrane layer using the appropriate
Algorithm 2 shows the properties of the controller and rule, not inside the control layer. individual components. Each component can publish into one topic (publishTopic) and subscribe data to mul- 3.3. Membrane Firewall tiple topics (orderedTopics). All components have their corresponding membranes inherited into the skin mem- A firewall is a trafic filter, i.e. it defines which communibrane. cation is allowed and which is not. In our system, we can
The controller registers topics that can be subscribed to implement the firewall at any layer, it depends on where (topicsDB), and all current subscriptions (subscriptionsDB). we want it to interfere with trafic. Putting the firewall in The corresponding membrane is the skin membrane. the membrane layer has the advantage that the firewall
In Algorithm 3 and 4 we can find the functions of is harder to detect for a potential attacker and we have the components and the controller. The components as access to all trafic. However, we need the possibility to the part of the control layer only perform the transfor- interfere with the evolution rules of membranes. mation between representation in the object form (for // An object received from the membrane: function component.receiveObject(obj) begin if obj.type = = then device^.processMessage(deliver, obj.publisherID, obj.topic, obj.retain, obj.data) ; end // A message received from the device: function component.receiveMessage(mes) begin switch mes.type do case connect do membrane^.createObject(c, mes.ID, mes.credentials); case disconnect do membrane^.createObject(t, mes.ID); case subscribe do membrane^.createObject(s, mes.ID, mes.topic); case unsubscribe do membrane^.createObject(u, mes.ID, mes.topic); case publish do membrane^.createObject(p, mes.ID, mes.topic, mes.retain, mes.data); end end
In the previous sections, we assumed that all components can publish in any topic and can subscribe to any topic. Thus, a natural implementation of a firewall can simply be to restrict the set of evolution rules for certain topics and certain components according to the specified requirements. We can proceed in one of the following ways: 1. We intervene in the rule replacing object with a set of objects inside the skin membrane. The object for a given subscriber and topic will or will not be generated. 2. We add or remove the rule transferring the object into the membrane of the target component. In this case, it is advisable to create a deletion rule for the given object.
// An object received from the membrane: function controller.receiveObject(obj) begin switch obj.type do case c do if (authenticator.check(obj.ID, obj.credentials)) and (device^.processMessage(connect, obj.ID, obj.credentials)) then
components[obj.ID].turnOn(); case d do device^.processMessage(disconnect, obj.ID); components[obj.ID].turnOf(); case s do device^.processMessage(obj.ID, obj.topic); subscriptionsDB.add(obj.topic, obj.ID); if topicsDB.retainSet(obj.topic) then membrane^.createObject(d, topicsDB.lastPublisher(obj.topic), obj.ID, obj.topic, 1, topicDB.lastValue(obj.topic)); case u do subscriptionsDB.remove(obj.topic, obj.ID); device^.processMessage(obj.ID, obj.topic); case p do if obj.retain then topicsDB.storeData(obj.topic, obj.data); else topicsDB.unsetRetain(obj.topic) ; end end receiving an object (subscription): if firewall.allow(obj.ID, obj.topic) then
membrane^.adjustRules_addSubscription(obj); The consequence is a modification of all the relevant rules transforming the object with the given topic into sets of objects (the object for the given subscriber and topic is added).
Furthermore, for disconnect messages, the given object needs to be removed from the relevant rule. Therefore, if any rule transforming object to in the skin membrane is applied, only such objects intended for any allowed communication are created. Whichever option we choose, the firewall does not delay trafic in any way. The published object is either transferred, ignored or deleted, always within one rule.
Suppose we choose the first option. 4. Discussion
The firewall must also be managed by adjusting evolution rules. We can provide this functionality in the In this paper, we comply with the message types and control layer. The controller contains a database with set- overall functionality of the MQTT protocol, but only tings for the firewall, according to which it reacts when in a simplified way. The mentioned protocol actually uses other types of messages (including confirmations), sumer Electronics – Asia (ICCE-Asia), 2018, pp. 206– which of course can also be implemented as objects in 212. doi:10.1109/ICCE-ASIA.2018.8552135. membranes. Unfortunately, there is not enough space for [8] S. Vavreckova, Modeling communication in inthe complete modeling of this communication. ternet of things network using membranes, in:
The proposed firewall could be enriched with a quar- CEUR Proceedings of the 21st Conference Inforantine membrane, and rules for the skin membrane that mation Technologies - Applications and Theory forward “suspicious” trafic to the quarantine membrane. (ITAT 2021), 2021, pp. 195–201. A supervisor could regularly check this membrane and [9] J. E. Hopcroft, J. D. Ullman, Introduction to would gain an overview of risky trafic. Automata Theory, Languages and Computation,
The goal of this paper is to use a mechanism indepen- Addison-Wesley, 1979. dent of, although inspired by, specific existing protocols [10] N. Busi, Causality in membrane systems, Memto propose communication between IoT devices. A mem- brane Computing (2007) 160–171. brane system was used as a basis, which can be further [11] W. Kassab, K. A. Darabkh, A–z survey of internet elaborated: there are programming languages for imple- of things: Architectures, protocols, applications, menting membrane systems, and other languages for recent advances, future directions and recommennetwork applications can be used as well. dations, Journal of Network and Computer Applications 163 (2020). URL: https://doi.org/10.1016/j. jnca.2020.102663.
Acknowledgments [12] J. Dizdarević, F. Carpio, A. Jukan, X. Masip-Bruin, A survey of communication protocols for internet This work was supported by the project no. of things and related challenges of fog and cloud CZ.02.2.69/0.0/0.0/18_054/0014696, “Development computing integration, Association for Computing of R&D capacities of the Silesian University in Opava”, Machinery 51 (2019). URL: https://doi.org/10.1145/ co-funded by the European Union.
3292674. doi:10.1145/3292674. [13] P. R. Egli, MQTT – Message Queueing TelemeReferences try Transport, Zurich University of Applied Sciences, Zurich, 2017. doi:10.13140/RG.2.2. 13210.54721.