=Paper=
{{Paper
|id=Vol-3226/paper21
|storemode=property
|title=Membrane System as a Communication Interface between IoT Devices
|pdfUrl=https://ceur-ws.org/Vol-3226/paper21.pdf
|volume=Vol-3226
|authors=Šárka Vavrečková
|dblpUrl=https://dblp.org/rec/conf/itat/Vavreckova22
}}
==Membrane System as a Communication Interface between IoT Devices ==
https://ceur-ws.org/Vol-3226/paper21.pdf
Membrane System as a Communication Interface between
IoT Devices
Šárka Vavrečková1
1
Silesian University in Opava, Bezručovo nám. 13, Opava, Czech Republic
Abstract
Membrane systems can be used to describe transfer of objects between different 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.
Keywords
membrane systems, internet of things, protocol, membrane firewall
1. Introduction dent of each other and work in parallel. Parallel pro-
cessing can also be described using membrane systems,
Membrane computing is a framework of parallel dis- where the data transfer between devices can be modeled
tributed processing introduced by Gheorghe Pǎun in using evolution rules.
1998. Information about this paradigm is available in
The use of membranes or similar principles in the
[1, 2, 3], or the bibliography at http://ppage.psystems.eu/
IoT world has been considered for years. Villari et al.
[2022-06-08]. Membrane systems are based on the hier-
in [4] introduce the concept of “osmotic computing” as
archical structure of membranes in cells and can be used
a paradigm, the main purpose of which is to increase
to model distributed computing. Mathematical models
the accessibility of resources and services in a computer
of membrane systems have been called P Systems.
network (e.g. IoT network), including cloud services. The
Objects located in membranes pass between mem-
authors present the concept of micro-services gradually
branes according to defined rules, similar to how var-
migrating from the cloud (physically in large data cen-
ious substances are transferred between membranes in
ters) to the edge of the network (edge computing), i.e.
a biological cell. The system usually works in parallel
they are performed on devices in the internal network.
(depending on the selected mode).
The paradigm is motivated by procedures from biology
The Internet of Things (IoT) is a term that is very or chemistry, where solvent molecules pass through a
difficult to define. IoT devices are mostly small, incon- semi-permeable membrane into other regions in the en-
spicuous devices with simple functionality and low con- vironment with higher solute concentration (osmosis).
sumption, whose strength lies primarily in their intercon- The issue is further developed by the paper [5], which
nection. We talk about smart devices, but the smartness considers the way in which micro-services, in particular,
is in their interconnection and usage of the data obtained can migrate between the cloud and edge resources and
from these devices. focuses more on the Internet of Things. The authors of
IoT devices can be simple sensors detecting e.g. the [6] deploy micro-services in a hospital application. Datta
temperature, motion, humidity, light, or alarms, mecha- and Bonnet in [7] show the use of MELs in securing
nisms for handling lighting, opening or closing windows, connected “smart” cars and other similar devices.
or passive recipients of data (e.g. displays). It can be We follow up on paper [8], in which the concept of
more complex devices with multiple functionalities, com- using the P system as an interface to IoT devices is pre-
munication points, gateways to other network types, or sented. Here we slightly modify the concept, add new
common devices such as smartphones. We encounter types of objects corresponding to various kinds of mes-
IoT devices at home, in companies, hospitals, industry, sages in the IoT system, and strictly separate the different
agriculture, on streets,. . . functionalities of the system. We also discuss the possi-
In principle, IoT devices are computationally indepen- bility of implementing a simple firewall at the membrane
system level.
ITAT’22: Information technologies – Applications and Theory, Septem-
ber 23–27, 2022, Zuberec, Slovakia
$ sarka.vavreckova@fpf.slu.cz (.̌ Vavrečková)
© 2022 Copyright for this paper by its authors. Use permitted under Creative Commons License
Attribution 4.0 International (CC BY 4.0).
CEUR
Workshop
Proceedings
http://ceur-ws.org
ISSN 1613-0073
CEUR Workshop Proceedings (CEUR-WS.org)
2. Preliminaries Definition 2 ([11]). The Internet of Things (IoT) is a net-
work of various types of smart objects (so called things) and
2.1. Membrane Systems devices. The things are connected to the Internet and com-
municate with each other with minimum human interface.
We assume the reader to be familiar with the basics of
They are embedded with abilities as sensing, analyzing,
formal language theory and membrane computing. For
processing and self-management based on interoperable
further details, we refer to [9] and [3].
communication protocols and specific criteria. These smart
As mentioned above, the basis of membrane systems is
things should have unique identities and personalities.
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 ([2], [10]). Let 𝐻 be a set of labels. data. Publishers send data to the controller, not to sub-
A P System of a degree 𝑚, 𝑚 ≥ 1, is a construct scribers, they don’t need to know about the existence
of subscribers. Each node with the role of a subscriber
Π = (𝑉, 𝜇, 𝑤1 , . . . , 𝑤𝑚 , 𝑅1 , . . . , 𝑅𝑚 ) subscribes to particular types of data (often called topics)
to the controller, and the controller sends the requested
where:
data to all the subscribers interested in them. Sensors are
(i) 𝑉 is a nonempty alphabet, its elements are called examples of publishers (producers); actuators (simple mo-
objects, tors) or displays are examples of subscribers (consumers).
(ii) 𝜇 is a membrane structure consisting of 𝑚 mem- In practice, various higher-level protocols are used
branes, the membranes are labeled by the elements in IoT networks, such as MQTT, XMPP, CoAP, AMQP,
of 𝐻, or simply HTTP as in classic computer networks. Fur-
(iii) 𝑤𝑖 , 1 ≤ 𝑖 ≤ 𝑚, are strings representing multi- thermore, we will mainly follow the MQTT protocol, in
sets over 𝑉 associated with the region of the 𝑖-th terms of terminology, message types and communication
membrane in 𝜇, scheme.
(iv) 𝑅𝑖 , 1 ≤ 𝑖 ≤ 𝑚, are finite sets of evolution rules More details about IoT network communication mod-
associated with the region of the 𝑖-th membrane in els, including protocols, can be found in [12]. Very clear
𝜇; an evolution rule is a pair (𝑢, 𝑣), also written and brief introduction to MQTT messages is in [13].
𝑢 → 𝑣, where
• 𝑢 is a string over 𝑉 ,
• 𝑣{︀ = 𝑣 ′ or 𝑣 = 𝑣 ′ 𝛿, where 𝑣 ′ is a string over
3. Model of System
⃒ }︀
𝑎ℎ𝑒𝑟𝑒 , 𝑎𝑜𝑢𝑡 , 𝑎𝑖𝑛𝑗 𝑎 ∈ 𝑉, 1 ≤ 𝑗 ≤ 𝑚 , The given definition of the P System does not meet our
⃒
and 𝛿 is a special symbol ∈ / 𝑉 representing requirements: we need a slightly more dynamic structure,
dissolution of membrane. where it is possible to create new objects due to external
The objects can be transported by the evolution rules influences (e.g. to generate an object containing temper-
through membranes due to the targets out (to the parental ature data), to pass objects to a real device, but also to
membrane) or in (to the child membrane specified by the generate or delete rules. There are two possibilities:
index), or they remain in the original membrane (here). 1. We can modify the definition.
2. We can add an additional layer above the mem-
Details and examples can be found in [2] and [10].
brane structure, this layer will carry out the stated
tasks.
2.2. Internet of Things
The second option is more feasible for our purposes, how-
We can find a lot of definitions of the Internet of Things, ever, with the possibility to change the set of rules in
but none of them is fully descriptive. Their formulation membranes from outside (there is no need to change the
depends on the usage of such specific IoT structure. In definition of membrane system). The set of rules will
[11] there are several definitions taken from multiple be changed continuously, but the impact will only be a
sources. We can compose the following definition from change in the operation of the system, not collisions or
them: system errors.
The added control layer will be able to affect objects '
Controller (Server) $
and rules at each step of the computation. Figure 1
demonstrates the whole structure. The control layer is '
Comp1 $
'
Comp3 $
above the membrane structure, this layer communicates
𝑠(3, south.temp)
using a suitable protocol with other components: a local 𝑝(1, south.temp, 1, 34)
network and, indirectly, the Internet, the cloud. 𝑠(3, north.temp)
& %
& %
'
Comp2 $
'
Comp4 $
Cloud
𝑝(2, north.temp, 1, 18)
6
? 𝑠(2, time)
Devices - Regular & %
& %
Network 𝑐(4, doorbell, secure12345)
𝑝(1, south.temp, 1, 33)
6 6 6 6 6 6messages & %
??????
Control Layer Figure 2: Example of IoT Membrane Structure
6 6 6 6 6 6objects
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 gen-
erate 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 different 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 effect: 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. • 𝑐(ID, credentials) is sent to negotiate a connec-
tion to the controller. The sending component
3.1. Membrane Layer (with the present ID) can act as a publisher and/or
subscriber after the connection is established.
Figure 2 shows the membrane structure of an example
• 𝑡(ID) is sent by the component when terminating
IoT system with one controller and several components.
the connection.
• 𝑠(ID, topic) is used to order messages belonging Any 𝑐(. . . ) -
to a specific topic. It is received by the controller component Controller
and the sending component is put to subscribers 𝑡(. . . )
for the topic.
𝑠(. . . )
• 𝑢(ID, topic) is sent by the given subscriber to Controller Subscriber
unsubscribe from the given topic. 𝑢(. . . )
• 𝑝(ID, topic, retain, data) represents the “Publish”
𝑝(. . . ) - 𝑑(. . . ) -
message sent by the given publisher in the first Publisher Controller Subscriber
stage of the path, that is, from the membrane of
the publishing component to the controller. The Figure 3: Objects for the operations connect/disconnect, sub-
third parameter “retain” takes the value 0 or 1. scribe/unsubscribe, publish
The value 1 means that the data for the given topic
should be stored, and forwarded to a component
that sends order just after the publication of this
For the skin membrane (controller) we need the fol-
data.
lowing set of rules: for each publisher 𝑖 publishing in
• 𝑑(publisherID, subscriberID, topic, retain, data)
a topic 𝑡 with the retain value 𝑟
represents the same message, but in the second ⋃︀
stage. The controller creates this type of object 𝑝(𝑖, 𝑡, 𝑟, data) → 𝑠 𝑑(𝑖, 𝑠, 𝑡, 𝑟, data)ℎ𝑒𝑟𝑒
for each subscriber for the topic and adds the ∀(𝑡, 𝑠) ∈ subscriptionsDB
second parameter. 𝑑(𝑖, 𝑠, 𝑡, 𝑟, data) → 𝑑(𝑖, 𝑠, 𝑡, 𝑟, data)𝑖𝑛𝑠
∀ subscribers 𝑠
The objects 𝑐 and 𝑡 are intended for activation and de-
activation 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 create these rules again for all possible topics.
We need two types of objects for this operation because
Similarly, we need to transport other objects from the
we need to distinguish the two phases of the message
components 𝑖:
path (from the publisher to the controller and from the
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 correspond-
The 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.
Algorithm 1: Messages and corresponding objects Algorithm 2: Entities – properties
// Parental message/object with one common topic:
property, all messages have a sender: topic,
message: lastPublisher,
type, // publish, deliver,. . . lastValue; // last published data
ID; // ID of the source component order:
// Object generated by a publisher, going to the topic,
controller (the first phase of publishing message): subscriberID;
publish (child of: message): . . . . . . . . . . . . . . . . 𝑝 // Parental object for all entities:
topic, entity:
retain, // 0 or 1 ID, // identification number
data; membrane, // ref. to the corresp. membrane
// Object transformed by the controller, going to device; // ref. to the corresp. device
a subscriber (the second phase): component (child of: entity):
deliver (child of: publish): . . . . . . . . . . . . . . . . . 𝑑 turnedOn, // 0 (false) or 1 (true)
subscriberID; // Properties for publishing:
// Subscribing message with an order: publishTopic,
subscribe (child of: message): . . . . . . . . . . . . . . 𝑠 publishRetain, // 0 or 1
topic; // topic to subscribe // Property for subscribing:
topic[] orderedTopics;
// Unsubscribing message for some topic:
unsubscribe (child of: message): . . . . . . . . . . . 𝑢 controller (child of: entity):
topic; // topic to unsubscribe component[] components,
authenticator,
// Connection message for a component: topic[] topicsDB, // registered topics
connect (child of: message): . . . . . . . . . . . . . . . . 𝑐 order[] subscriptionsDB; // subscriptions
credentials; // e.g. username, password
// 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 transfor-
is 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-
tiple topics (orderedTopics). All components have their
3.3. Membrane Firewall
corresponding membranes inherited into the skin mem- A firewall is a traffic filter, i.e. it defines which communi-
brane. 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 traffic. 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 traffic. 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
Algorithm 3: Components – functions Algorithm 4: Controller – function
// An object received from the membrane: // An object received from the membrane:
function component.receiveObject(obj) function controller.receiveObject(obj)
begin begin
if obj.type = = 𝑑 then switch obj.type do
device^.processMessage(deliver, case c do
obj.publisherID, obj.topic, obj.retain, obj.data) ; if (authenticator.check(obj.ID,
end obj.credentials)) and
(device^.processMessage(connect,
// A message received from the device: obj.ID, obj.credentials)) then
function component.receiveMessage(mes) components[obj.ID].turnOn();
begin
case d do
switch mes.type do device^.processMessage(disconnect,
case connect do
obj.ID);
membrane^.createObject(c, mes.ID,
components[obj.ID].turnOff();
mes.credentials);
case s do
case disconnect do device^.processMessage(obj.ID, obj.topic);
membrane^.createObject(t, mes.ID); subscriptionsDB.add(obj.topic, obj.ID);
case subscribe do if topicsDB.retainSet(obj.topic) then
membrane^.createObject(s, mes.ID, membrane^.createObject(d,
mes.topic); topicsDB.lastPublisher(obj.topic),
case unsubscribe do obj.ID, obj.topic, 1,
membrane^.createObject(u, mes.ID, topicDB.lastValue(obj.topic));
mes.topic); case u do
case publish do subscriptionsDB.remove(obj.topic, obj.ID);
membrane^.createObject(p, mes.ID, device^.processMessage(obj.ID, obj.topic);
mes.topic, mes.retain, mes.data); case p do
end if obj.retain then
end topicsDB.storeData(obj.topic, obj.data);
else topicsDB.unsetRetain(obj.topic) ;
end
In the previous sections, we assumed that all compo- end
nents 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 receiving an object 𝑠 (subscription):
topics and certain components according to the specified
requirements. We can proceed in one of the following if firewall.allow(obj.ID, obj.topic) then
ways: membrane^.adjustRules_addSubscription(obj);
1. We intervene in the rule replacing object 𝑝 with
a set of objects 𝑑 inside the skin membrane. The The consequence is a modification of all the relevant rules
𝑑 object for a given subscriber and topic will or transforming the object 𝑝 with the given topic into sets
will not be generated. of objects 𝑑 (the object 𝑑 for the given subscriber and
2. We add or remove the rule transferring the object topic is added).
𝑑 into the membrane of the target component. In Furthermore, for disconnect messages, the given object
this case, it is advisable to create a deletion rule needs to be removed from the relevant rule. Therefore, if
for the given object. any rule transforming object 𝑝 to 𝑑 in the skin membrane
is applied, only such 𝑑 objects intended for any allowed
Whichever option we choose, the firewall does not de- communication are created.
lay traffic 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 evo-
lution 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 in-
the 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 Infor-
antine membrane, and rules for the skin membrane that mation Technologies - Applications and Theory
forward “suspicious” traffic 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 traffic. 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, Mem-
to 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 recommen-
network applications can be used as well. dations, Journal of Network and Computer Appli-
cations 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 Teleme-
References try Transport, Zurich University of Applied
Sciences, Zurich, 2017. doi:10.13140/RG.2.2.
[1] G. Păun, Membrane Computing: An Introduction, 13210.54721.
Springer, Heidelberg, 2002.
[2] G. Păun, G. Rozenberg, A guide to membrane com-
puting, Theor. Comp. Science 287 (2002) 73–100.
[3] G. Păun, G. Rozenberg, A. Salomaa, The Oxford
Handbook of Membrane Computing, Oxford Uni-
versity Press, New York, 2010.
[4] M. Villari, M. Fazio, S. Dustdar, O. Rana, R. Ran-
jan, Osmotic computing: A new paradigm for
edge/cloud integration, IEEE Cloud Computing
3 (2016) 76–83.
[5] V. Sharma, K. Srinivasan, D. N. K. Jayakody, O. Rana,
R. Kumar, Managing service-heterogeneity using
osmotic computing, in: International Conference
on Communication, Management and Information
Technology (ICCMIT 2017), Warsaw, Poland, 2017.
[6] A. Buzachis, D. Boruta, M. Villari, J. Spillner, Mod-
eling and emulation of an osmotic computing
ecosystem using osmotictoolkit, in: 2021 Aus-
tralasian Computer Science Week Multiconference,
ACSW ’21, Association for Computing Machinery,
New York, NY, USA, 2021. URL: https://doi.org/
10.1145/3437378.3444366. doi:10.1145/3437378.
3444366.
[7] S. K. Datta, C. Bonnet, Next-generation, data centric
and end-to-end iot architecture based on microser-
vices, in: IEEE International Conference on Con-