**5. Distributed architectural pattern**

Next section presents an example of this architectural pattern.

34 Radio Frequency Identification from System to Applications

her database updates and downloads updates from other gardeners.

Now, let's analyze the semi-distributed architectural pattern.

synchronized themselves with the central database.

each device and the central database.

The unique example of use of such architectural pattern is Paris trees management applica‐ tion [5]. Each of the ninety-five thousand trees of Paris avenues is equipped with an RFID tag. Each gardener synchronizes her tablet PC with the central database before a new day of work. During her day of work, whenever a gardener does something to a tree, she identifies the tree thanks to its RFID tag: Her tablet PC modifies the avatar in the local database. Then, in the evening, she synchronizes her tablet PC with the central database. Thus she uploads

Concerning the functional attribute, the avatar of a read tag may be stale. Suppose users *U1* and *U2* synchronize their mobile device with the central database. Then *U1* modifies avatar of tag *r*. Thus she modifies her local copy of the database. When *U2* comes to tag *r*, as her device reads its local copy of the database, the returned value of the avatar is the value before *U1*'s modification: the read value is stale. Notice we can limit this issue by assigning sets of entities to each mobile device. For instance, in the case of the Paris trees management application, a supervisor can assign a set of trees to be taken care of during the day, to each of the gardeners. If all of these sets are apart, this issue cannot be observed anymore. About remote tags, by querying its local database, the device is able to read the avatar of a remote tag, even though there is no global network. But the read value can be stale. It will be again correct only when all of the mobile devices have

Concerning the scalability attribute, the maximum number of tags which can be handled by this architectural pattern is limited by the number of avatars which can be stored in the cen‐ tral database and in the local copy of this database. Let *Slocal* be the maximum size in bytes of the local database. The maximum number of tags is bounded by *min(Scentral/s,Slocal/s)*, which is likely to be *Slocal/s* as mobile devices do not have as much memory as servers. Notice that this bound can be increased to *Scentral/s* by assigning to each mobile only a subset of the central database. For instance, in the case of Paris trees management application, the mobile device of a gardener could receive only the avatars of the trees she will take care of during the day. About sensitivity to the number of simultaneous reads, this architectural pattern is not as sensitive as centralized architectural pattern. It does not need to query a server upon each RFID tag read. Nevertheless all of the readers must periodically synchronize themselves with the central database. As the synchronization time is proportional to the number of readers, it may reach unbearable values. This issue can be tackled by limiting the number of avatars copied on the local devices, thus reducing the volume of data transferred between

**4.1. Example**

**4.2. Analysis**

In distributed architectural pattern, the avatar of an RFID tag is stored inside the RAM of the tag (see Figure 3). Whenever a user is in contact with a tag, the reader works with the part of the RAM containing the avatar.

**Figure 3.** Distributed architectural pattern

Next section gives examples of this architectural pattern.

#### **5.1. Examples**

Nokia 6131 NFC phones are sold with three NFC tags. Each one triggers a different function on the telephone: One activates alarm function; another one plays a given music on the phone; the last one displays an NFC tutorial. To do so, the telephone reads the contents of the tag, this contents being coded as a Uniform Resource Identifier (URI) according to the NFC Forum's specifications of *Smarts Posters* [5,17-18]. When the phone is programmed to understand tags' contents formatted according to these specifications, these URIs can be used to tell the telephone to accomplish a given function like send an SMS, call a certain number, open a given web page, etc.

items with the item of another traveler. An alarm is thus triggered to warn the traveler

Choosing the Right RFID-Based Architectural Pattern

http://dx.doi.org/10.5772/54069

37

[22] proposes an academic system based on digital pheromones to find objects lost in a house. To do so, floor of the house is covered with RFID tags. An RFID reader is coupled with each house object. When user moves an object from point *A* to point *B*, the RFID reader associated with the object behaves like an ant which sets pheromones on the path it takes: The reader writes a digital pheromone (made of object identifier and timestamp of transit) in the RAM of each tag over which it goes. Notice that, like a natural pheromone which evapo‐ rates with time, whenever a reader finds no more room in the RAM of a tag (there are too many pheromones stored inside), the reader deletes the oldest pheromone from the tag. In case an object is lost, user takes a dedicated RFID reader and wanders around the house un‐ til she finds the digital pheromones of the object. Once she has located it, she follows the

*Roboswarn* is an (academic) application to position robots (equipped with NFC readers) in a physical space to accomplish a certain task [23]. NFC tags are dispatched in dedicated places of a room (for instance, near a hospital bed which these robots will have to push so that a cleaning robot can accomplish its task). Each tag is initialized with location of other tags in the room and the timestamp of last cleaning. When robots enter the room, they look for an NFC tag. As soon as one robot finds one, it reads the position of other tags and transmits them to other robots. The other robots go to the other tags. If timestamp of last cleaning is too old, robots push the hospital bed and then write new timestamp of cleaning. Otherwise,

*SALTO Systems* company is selling locks for electronic doors. The keys are NFC tags. To fa‐ cilitate the management of all locks and tags, this company has developed SALTO Virtual Network (SVN) [24]. Thanks to this system, Heathrow airport operator is able to manage 1000 standard electronic locks (NFC-controlled) and 37 hot spots. These spots are special locks connected to a global computer network. They can: 1) unlock an entry access on the whole site, 2) initialize an NFC key with the right to open given locks during the day, 3) blacklist some NFC keys, 4) recover data collected by the key during the working day of its user. Indeed, each time a person unlocks an electronic lock with her NFC key, the lock reads data stored on tag to check user permissions and the list of blacklisted tags. But, the elec‐ tronic lock also writes information like, for instance, the low charge of the battery powering the lock. Thus thanks to SVN, even though standard locks do not have access to a global computer network, they can receive information (e.g. list of blacklisted cards) and send in‐ formation (e.g. low charge of battery): Standard locks communicate thanks to the network

Based on all of these examples, next section analyzes distributed architectural pattern.

that one of her items is missing.

robots do nothing.

made of the users of the keys/tags.

pheromone trace until the place where the object was left.

In fact, it is thanks to this Smart Posters specification that any NFC phone can exploit Tou‐ chatag tags mentioned in section 3.1. Indeed, these tags contain not only an identifier used by Touchatag application, but also an URI. This URI is the URL of a Touchatag web server with a parameter containing the identifier of the tag. Thus when a user touches a Touchatag tag with her mobile phone, the phone reads the URL and then opens a browser with this URL. Touchatag web server is then contacted, via 3G or Wi-Fi, with the identifier *i*. Then, web server contacts ACS (see section 3.1) with *i*. In the case where *i* is associated with a web site *w*, URL of *w* is sent back to Touchatag web server. This server returns an html page con‐ taining a redirection towards *w*. Finally, the browser displays *w*. Notice that, in the case of a Touchatag tag read by a mobile phone, phone uses distributed architectural pattern to deter‐ mine the Touchatag web server to contact; but, the Touchatag web server uses centralized architectural pattern to translate the tag identifier into an action.

Once again, it is the Smart Posters specification which is used by *Connecthing* company to bring intelligence to mailboxes [19]. When a user scans a mailbox equipped with an NFC tag, her phone reads the URL stored on the tag (which contains an identifier corresponding to the physical location of the mailbox) and opens a browser to access this URL. This web page displays location of nearby mailboxes, the time at which postman takes the mail, etc.

*Navigo*, the Paris public transportation pass, is an example of an industrial application based on this architectural pattern, which does not use Smart Posters specification [20]. The 4.5 million Navigo pass users do not have an NFC reader. They are only given a pass which contains an NFC tag. With a vending machine, each user initializes her tag with the rights she buys to use the public transportation. Whenever she wants to use a public transporta‐ tion, she presents her pass in front of an NFC reader. Locally, the reader checks the rights stored in the tag's RAM and opens the gate, if the access is granted.

*Ubi-Check* is an academic application example of distributed architectural pattern [21]. An RFID tag is attached to each of a traveler's items. At the beginning of their travel, each tag is initialized with a value specific to the traveler. All of these RFID tags are read af‐ ter special points (e.g. after an airport security control). If an inconsistency is found among the read values, it means that, at some point, the traveler exchanged one of her items with the item of another traveler. An alarm is thus triggered to warn the traveler that one of her items is missing.

Next section gives examples of this architectural pattern.

36 Radio Frequency Identification from System to Applications

architectural pattern to translate the tag identifier into an action.

stored in the tag's RAM and opens the gate, if the access is granted.

number, open a given web page, etc.

Nokia 6131 NFC phones are sold with three NFC tags. Each one triggers a different function on the telephone: One activates alarm function; another one plays a given music on the phone; the last one displays an NFC tutorial. To do so, the telephone reads the contents of the tag, this contents being coded as a Uniform Resource Identifier (URI) according to the NFC Forum's specifications of *Smarts Posters* [5,17-18]. When the phone is programmed to understand tags' contents formatted according to these specifications, these URIs can be used to tell the telephone to accomplish a given function like send an SMS, call a certain

In fact, it is thanks to this Smart Posters specification that any NFC phone can exploit Tou‐ chatag tags mentioned in section 3.1. Indeed, these tags contain not only an identifier used by Touchatag application, but also an URI. This URI is the URL of a Touchatag web server with a parameter containing the identifier of the tag. Thus when a user touches a Touchatag tag with her mobile phone, the phone reads the URL and then opens a browser with this URL. Touchatag web server is then contacted, via 3G or Wi-Fi, with the identifier *i*. Then, web server contacts ACS (see section 3.1) with *i*. In the case where *i* is associated with a web site *w*, URL of *w* is sent back to Touchatag web server. This server returns an html page con‐ taining a redirection towards *w*. Finally, the browser displays *w*. Notice that, in the case of a Touchatag tag read by a mobile phone, phone uses distributed architectural pattern to deter‐ mine the Touchatag web server to contact; but, the Touchatag web server uses centralized

Once again, it is the Smart Posters specification which is used by *Connecthing* company to bring intelligence to mailboxes [19]. When a user scans a mailbox equipped with an NFC tag, her phone reads the URL stored on the tag (which contains an identifier corresponding to the physical location of the mailbox) and opens a browser to access this URL. This web page displays location of nearby mailboxes, the time at which postman takes the mail, etc.

*Navigo*, the Paris public transportation pass, is an example of an industrial application based on this architectural pattern, which does not use Smart Posters specification [20]. The 4.5 million Navigo pass users do not have an NFC reader. They are only given a pass which contains an NFC tag. With a vending machine, each user initializes her tag with the rights she buys to use the public transportation. Whenever she wants to use a public transporta‐ tion, she presents her pass in front of an NFC reader. Locally, the reader checks the rights

*Ubi-Check* is an academic application example of distributed architectural pattern [21]. An RFID tag is attached to each of a traveler's items. At the beginning of their travel, each tag is initialized with a value specific to the traveler. All of these RFID tags are read af‐ ter special points (e.g. after an airport security control). If an inconsistency is found among the read values, it means that, at some point, the traveler exchanged one of her

**5.1. Examples**

[22] proposes an academic system based on digital pheromones to find objects lost in a house. To do so, floor of the house is covered with RFID tags. An RFID reader is coupled with each house object. When user moves an object from point *A* to point *B*, the RFID reader associated with the object behaves like an ant which sets pheromones on the path it takes: The reader writes a digital pheromone (made of object identifier and timestamp of transit) in the RAM of each tag over which it goes. Notice that, like a natural pheromone which evapo‐ rates with time, whenever a reader finds no more room in the RAM of a tag (there are too many pheromones stored inside), the reader deletes the oldest pheromone from the tag. In case an object is lost, user takes a dedicated RFID reader and wanders around the house un‐ til she finds the digital pheromones of the object. Once she has located it, she follows the pheromone trace until the place where the object was left.

*Roboswarn* is an (academic) application to position robots (equipped with NFC readers) in a physical space to accomplish a certain task [23]. NFC tags are dispatched in dedicated places of a room (for instance, near a hospital bed which these robots will have to push so that a cleaning robot can accomplish its task). Each tag is initialized with location of other tags in the room and the timestamp of last cleaning. When robots enter the room, they look for an NFC tag. As soon as one robot finds one, it reads the position of other tags and transmits them to other robots. The other robots go to the other tags. If timestamp of last cleaning is too old, robots push the hospital bed and then write new timestamp of cleaning. Otherwise, robots do nothing.

*SALTO Systems* company is selling locks for electronic doors. The keys are NFC tags. To fa‐ cilitate the management of all locks and tags, this company has developed SALTO Virtual Network (SVN) [24]. Thanks to this system, Heathrow airport operator is able to manage 1000 standard electronic locks (NFC-controlled) and 37 hot spots. These spots are special locks connected to a global computer network. They can: 1) unlock an entry access on the whole site, 2) initialize an NFC key with the right to open given locks during the day, 3) blacklist some NFC keys, 4) recover data collected by the key during the working day of its user. Indeed, each time a person unlocks an electronic lock with her NFC key, the lock reads data stored on tag to check user permissions and the list of blacklisted tags. But, the elec‐ tronic lock also writes information like, for instance, the low charge of the battery powering the lock. Thus thanks to SVN, even though standard locks do not have access to a global computer network, they can receive information (e.g. list of blacklisted cards) and send in‐ formation (e.g. low charge of battery): Standard locks communicate thanks to the network made of the users of the keys/tags.

Based on all of these examples, next section analyzes distributed architectural pattern.

### **5.2. Analysis**

Concerning the functional attribute, as the avatar is written and read only in the RAM of the tag, there is no staleness issue of locally read tags. However, it is impossible to know the avatar of a remote tag.

plication environment holds a local copy of all of the avatars (see Figure 4). Moreover they hold a vector clock (see Figure 5). Each element of this vector clock is a number correspond‐ ing to the last version of the avatar which the tag or the device has learnt about (this is why [25] gives the name *version number* to this number). When a mobile device comes to a tag and modifies the avatar of the tag, this mobile increments the element of the vector clock (stored on the tag and inside its own memory) corresponding to the avatar of this tag. Whenever a mobile device meets a tag (respectively another device), the device and the tag (respectively the other device) compare their respective view of the avatars, by comparing their vector clocks values. Doing so, each of them learns from the other one the latest news

Choosing the Right RFID-Based Architectural Pattern

http://dx.doi.org/10.5772/54069

39

(which they are aware of) about all of the avatars.

**Figure 4.** RFID-based distributed shared memory architectural pattern

Concerning the scalability attribute, there is no limit on the number of tags in the application environment. Moreover, such distributed architectural pattern is not sensitive at all to the number of simultaneous read operations (all of the operations are done locally).

Concerning the cost attribute, the reader does not need any global network to access to the avatar of the RFID tag. On the other hand, RAM is required on each tag. Its size must be at least the size of the avatar. This means that the avatar cannot contain too much information (e.g. MIFARE tags can offer up to 4 Kbytes of RAM, with 3440 bytes of net storage capacity). When a new tag is introduced in the system, only two operations are required: (i) the tag is linked to the physical entity; and (ii) the avatar of this entity is initialized in the RAM. About the reinitialization of the tags, it is application-dependant. Some applications require that a dedicated user goes through all of the tags to reinitialize them. In the case of Navigo pass, users are in charge of bringing their pass to a vending machine. This leads to long waiting lines at the beginning of a month, when users must initialize their rights for this month. This is why Navigo operator carries out experiments where users can initialize their tag using a dedicated NFC reader connected to their personal computer. To avoid reinitialization costs, some RFID-based distributed applications put in place special mechanisms. These mecha‐ nisms take into account elapsed time in order to automatically reset data. In Roboswarm ap‐ plication (see section 5.1), there is no need to reset the timestamp to trigger a new cleaning of a room. Each robot is aware of a deterioration level. Thus if the timestamp plus this dete‐ rioration level is greater than current time, it means that the room needs some cleaning again. With application for pheromone-based object tracking (see section 5.1), although tags have limited RAM capabilities, there is still no need to have a periodic session initialization which would clean up outdated pheromones. Each pheromone is written on a tag with a timestamp. Thus when the device attached to the roaming object meets a tag, it cleans up pheromones which have a too old timestamp, before writing the dedicated pheromone.

This section has analyzed distributed architectural pattern according to the attributes pre‐ sented in section 2. This architectural pattern does not require any global computer network. And it is not sensitive to the number of simultaneous read operations. Nevertheless it faces a functional issue: it is not possible to get the avatar of a remote tag.

Next section analyzes RFID-based DSM which tackles this issue.

### **6. RFID-based distributed shared memory architectural pattern**

RFID-based distributed shared memory (RFID-based DSM) mixes the qualities of semi-dis‐ tributed architectural pattern and distributed architectural pattern [7]. The avatar of an RFID tag is stored in the RAM of the tag. In addition, each tag and each mobile device of the ap‐ plication environment holds a local copy of all of the avatars (see Figure 4). Moreover they hold a vector clock (see Figure 5). Each element of this vector clock is a number correspond‐ ing to the last version of the avatar which the tag or the device has learnt about (this is why [25] gives the name *version number* to this number). When a mobile device comes to a tag and modifies the avatar of the tag, this mobile increments the element of the vector clock (stored on the tag and inside its own memory) corresponding to the avatar of this tag. Whenever a mobile device meets a tag (respectively another device), the device and the tag (respectively the other device) compare their respective view of the avatars, by comparing their vector clocks values. Doing so, each of them learns from the other one the latest news (which they are aware of) about all of the avatars.

**5.2. Analysis**

avatar of a remote tag.

38 Radio Frequency Identification from System to Applications

Concerning the functional attribute, as the avatar is written and read only in the RAM of the tag, there is no staleness issue of locally read tags. However, it is impossible to know the

Concerning the scalability attribute, there is no limit on the number of tags in the application environment. Moreover, such distributed architectural pattern is not sensitive at all to the

Concerning the cost attribute, the reader does not need any global network to access to the avatar of the RFID tag. On the other hand, RAM is required on each tag. Its size must be at least the size of the avatar. This means that the avatar cannot contain too much information (e.g. MIFARE tags can offer up to 4 Kbytes of RAM, with 3440 bytes of net storage capacity). When a new tag is introduced in the system, only two operations are required: (i) the tag is linked to the physical entity; and (ii) the avatar of this entity is initialized in the RAM. About the reinitialization of the tags, it is application-dependant. Some applications require that a dedicated user goes through all of the tags to reinitialize them. In the case of Navigo pass, users are in charge of bringing their pass to a vending machine. This leads to long waiting lines at the beginning of a month, when users must initialize their rights for this month. This is why Navigo operator carries out experiments where users can initialize their tag using a dedicated NFC reader connected to their personal computer. To avoid reinitialization costs, some RFID-based distributed applications put in place special mechanisms. These mecha‐ nisms take into account elapsed time in order to automatically reset data. In Roboswarm ap‐ plication (see section 5.1), there is no need to reset the timestamp to trigger a new cleaning of a room. Each robot is aware of a deterioration level. Thus if the timestamp plus this dete‐ rioration level is greater than current time, it means that the room needs some cleaning again. With application for pheromone-based object tracking (see section 5.1), although tags have limited RAM capabilities, there is still no need to have a periodic session initialization which would clean up outdated pheromones. Each pheromone is written on a tag with a timestamp. Thus when the device attached to the roaming object meets a tag, it cleans up pheromones which have a too old timestamp, before writing the dedicated pheromone.

This section has analyzed distributed architectural pattern according to the attributes pre‐ sented in section 2. This architectural pattern does not require any global computer network. And it is not sensitive to the number of simultaneous read operations. Nevertheless it faces a

RFID-based distributed shared memory (RFID-based DSM) mixes the qualities of semi-dis‐ tributed architectural pattern and distributed architectural pattern [7]. The avatar of an RFID tag is stored in the RAM of the tag. In addition, each tag and each mobile device of the ap‐

functional issue: it is not possible to get the avatar of a remote tag. Next section analyzes RFID-based DSM which tackles this issue.

**6. RFID-based distributed shared memory architectural pattern**

number of simultaneous read operations (all of the operations are done locally).

**Figure 4.** RFID-based distributed shared memory architectural pattern

environment. Let *L* be the length of an element of the vector clock. Then the maximum number of tags is bounded by *Stag/(s + L)*. Let's compare this bound to the bound of semi-distributed architectural pattern. For the latter pattern, the numerator is expressed in terms of Gigabytes. However it is expressed in terms of Kilobytes in the case of a tag's RAM. The maximum number of tags for RFID-based DSM architectural pattern is at least one million times lower than the maximum number for semi-distributed architec‐ tural pattern. About sensitivity to the number of simultaneous reads, RFID-based DSM requires that all mobile devices synchronize with a dedicated machine: RFID-based DSM

Choosing the Right RFID-Based Architectural Pattern

http://dx.doi.org/10.5772/54069

41

Concerning the cost attribute, in RFID-based DSM architectural pattern, the reader does not need any global network to access to the avatar of the RFID tag. Nevertheless RAM is re‐ quired on each tag. Its size must be at least the size of the avatar times the number of tags in the environment (so that a tag can hold a local copy of all avatars). This means that the ava‐ tar can contain even less information than in the case of distributed architectural pattern.

When a new tag is introduced in the system, four operations are required: (i) the tag is linked to the physical entity; (ii) the avatar of this entity is created and initialized in *DBinit*, the database used to (re)initialize the local copy on each mobile (*DBinit* is stored on a dedicated machine which can be one of the mobiles); (iii) a link between the tag identi‐ fier and this avatar is created in *DBinit*; and (iv) all of the elements of the tag's vector

When tags must be reinitialized, a program *Pinit* is executed on the machine hosting *DBinit*. This program computes the initial value *VCinit* of the vector clock for this session, so that each element of *VCinit* is greater, thus more recent, than all the vector clock elements in the mobiles. To do so, *Pinit* can use two methods. The first method is twofold: (i) get the vector clocks of all of the mobiles; and (ii) compute the maximum value. This first method does not require additional memory on each tag, but requires additional communication between the mobiles and the dedicated machine. This method works because the vector clock of a tag evolves only when a tag is in contact of a mobile. Thus there is always at least one mobile device which is aware of the values stored in the vector clock of a tag: *Pinit* does not need to be aware of the vector clock values stored on the tags. The second method supposes that each vector clock element is made of two fields: a "session identifier" field and a "tick in this session" field. Thus *Pinit* has only to increase the session number and set all "tick in this ses‐ sion" fields to zero. This second method requires additional memory on each tag, but no ad‐ ditional communication between the mobiles and the machine running *Pinit*. The choice of the method is application dependant. Once one of the two methods has been applied, the dedicated machine synchronizes each mobile device by sending the contents of *DBinit* and *VCinit* to the device. Afterwards, whenever a mobile device is in contact with an uninitialized RFID tag for this session, as the mobile device vector clock is greater than the tag vector clock, the mobile device initializes the tag. In other words, RFID-based DSM architectural pattern takes advantage of the fact that application users will go to tags, to initialize them: This pattern uses the communication network made by application users, instead of using a

is as sensitive as semi-distributed architectural pattern.

clock are initialized to zero.

global computer network.

**Figure 5.** Data of RFID-based distributed shared memory

Next section presents an example of this architectural pattern.

#### **6.1. Example**

*Plug: Secrets of the museum*, an (academic) pervasive game [26] developed in the context of the *PLUG* research project [27], is the unique example of use of RFID-based DSM ar‐ chitectural pattern. In this game, 48 virtual playing cards represent objects of French Mu‐ seum of Arts and Crafts (*Musée des arts et métiers*). These cards are dealt between 16 NFC tags (1 card per MIFARE tag, each of them being equipped with 1 KB of RAM) and 8 mobile phones (4 cards per Nokia 6131 NFC mobile). The players' goal is to collect cards of the same family on her mobile. To do so, players use their mobile to swap a card with a tag or another mobile.

Next section analyzes RFID-based DSM architectural pattern.

#### **6.2. Analysis**

Concerning the functional attribute, whenever a mobile device comes near a tag, there are two possibilities. Either the tag has been already initialized; in that case, as the avatar is stor‐ ed on the tag, the value read on the tag is the most up-to-date. Or, the tag has not been al‐ ready initialized; in that case, the first task of the mobile device is to initialize the tag; so that the value read on the tag after this initialization is also the most up-to-date value. Thus there is no staleness issue for avatar of locally read tag. Moreover, a mobile device holds a local copy of all avatars. Thus by querying this local copy, the device is able to answer to queries concerning a remote tag. However this local copy may not be up-to-date: There is a staleness issue for avatar of remotely read tag.

Concerning the scalability attribute, the maximum number of tags is limited by the size of the RAM of the tags. This architectural pattern stores copies of the avatar of all of tags and a vector clock. Let *Stag* be the lowest size of the RAM of the tags present in the environment. Let *L* be the length of an element of the vector clock. Then the maximum number of tags is bounded by *Stag/(s + L)*. Let's compare this bound to the bound of semi-distributed architectural pattern. For the latter pattern, the numerator is expressed in terms of Gigabytes. However it is expressed in terms of Kilobytes in the case of a tag's RAM. The maximum number of tags for RFID-based DSM architectural pattern is at least one million times lower than the maximum number for semi-distributed architec‐ tural pattern. About sensitivity to the number of simultaneous reads, RFID-based DSM requires that all mobile devices synchronize with a dedicated machine: RFID-based DSM is as sensitive as semi-distributed architectural pattern.

Concerning the cost attribute, in RFID-based DSM architectural pattern, the reader does not need any global network to access to the avatar of the RFID tag. Nevertheless RAM is re‐ quired on each tag. Its size must be at least the size of the avatar times the number of tags in the environment (so that a tag can hold a local copy of all avatars). This means that the ava‐ tar can contain even less information than in the case of distributed architectural pattern.

**Figure 5.** Data of RFID-based distributed shared memory

40 Radio Frequency Identification from System to Applications

**6.1. Example**

**6.2. Analysis**

with a tag or another mobile.

issue for avatar of remotely read tag.

Next section presents an example of this architectural pattern.

Next section analyzes RFID-based DSM architectural pattern.

*Plug: Secrets of the museum*, an (academic) pervasive game [26] developed in the context of the *PLUG* research project [27], is the unique example of use of RFID-based DSM ar‐ chitectural pattern. In this game, 48 virtual playing cards represent objects of French Mu‐ seum of Arts and Crafts (*Musée des arts et métiers*). These cards are dealt between 16 NFC tags (1 card per MIFARE tag, each of them being equipped with 1 KB of RAM) and 8 mobile phones (4 cards per Nokia 6131 NFC mobile). The players' goal is to collect cards of the same family on her mobile. To do so, players use their mobile to swap a card

Concerning the functional attribute, whenever a mobile device comes near a tag, there are two possibilities. Either the tag has been already initialized; in that case, as the avatar is stor‐ ed on the tag, the value read on the tag is the most up-to-date. Or, the tag has not been al‐ ready initialized; in that case, the first task of the mobile device is to initialize the tag; so that the value read on the tag after this initialization is also the most up-to-date value. Thus there is no staleness issue for avatar of locally read tag. Moreover, a mobile device holds a local copy of all avatars. Thus by querying this local copy, the device is able to answer to queries concerning a remote tag. However this local copy may not be up-to-date: There is a staleness

Concerning the scalability attribute, the maximum number of tags is limited by the size of the RAM of the tags. This architectural pattern stores copies of the avatar of all of tags and a vector clock. Let *Stag* be the lowest size of the RAM of the tags present in the When a new tag is introduced in the system, four operations are required: (i) the tag is linked to the physical entity; (ii) the avatar of this entity is created and initialized in *DBinit*, the database used to (re)initialize the local copy on each mobile (*DBinit* is stored on a dedicated machine which can be one of the mobiles); (iii) a link between the tag identi‐ fier and this avatar is created in *DBinit*; and (iv) all of the elements of the tag's vector clock are initialized to zero.

When tags must be reinitialized, a program *Pinit* is executed on the machine hosting *DBinit*. This program computes the initial value *VCinit* of the vector clock for this session, so that each element of *VCinit* is greater, thus more recent, than all the vector clock elements in the mobiles. To do so, *Pinit* can use two methods. The first method is twofold: (i) get the vector clocks of all of the mobiles; and (ii) compute the maximum value. This first method does not require additional memory on each tag, but requires additional communication between the mobiles and the dedicated machine. This method works because the vector clock of a tag evolves only when a tag is in contact of a mobile. Thus there is always at least one mobile device which is aware of the values stored in the vector clock of a tag: *Pinit* does not need to be aware of the vector clock values stored on the tags. The second method supposes that each vector clock element is made of two fields: a "session identifier" field and a "tick in this session" field. Thus *Pinit* has only to increase the session number and set all "tick in this ses‐ sion" fields to zero. This second method requires additional memory on each tag, but no ad‐ ditional communication between the mobiles and the machine running *Pinit*. The choice of the method is application dependant. Once one of the two methods has been applied, the dedicated machine synchronizes each mobile device by sending the contents of *DBinit* and *VCinit* to the device. Afterwards, whenever a mobile device is in contact with an uninitialized RFID tag for this session, as the mobile device vector clock is greater than the tag vector clock, the mobile device initializes the tag. In other words, RFID-based DSM architectural pattern takes advantage of the fact that application users will go to tags, to initialize them: This pattern uses the communication network made by application users, instead of using a global computer network.

This section has analyzed RFID-based DSM architectural pattern according to the attributes presented in section 2. This architectural pattern does not require any global computer net‐ work. And it does not experience the issue of staleness of an avatar of a read tag. Moreover it is possible to query the avatar of a remote tag. Nevertheless this architectural pattern ex‐ periences staleness issues when accessing to avatar of a remote tag. And there is a scalability issue in terms of maximum number of tags which can be handled.

If there can be RAM on tags, the maximum number of tags must be determined. If it is com‐ patible with RFID-based DSM architectural pattern limitations, then this pattern should be chosen (as it is the least limited pattern for the functionality attribute). Otherwise the system architect should choose distributed architectural pattern (if there must be no staleness issue for read tags) or semi-distributed architectural pattern (if the cost of reinitializing tags is an important factor). Notice that the mixing of distributed architectural pattern and RFIDbased DSM may be an interesting alternative. On each tag, we can store its avatar and the vector clock element corresponding to this avatar. Each mobile device holds a copy of all avatars and a full vector clock. By applying RFID-based DSM procedures, we get a solution for the limited maximum number of tags in RFID-based DSM. And in the same time, we solve distributed architectural pattern limitations (as we can query avatar of remote tags

Choosing the Right RFID-Based Architectural Pattern

http://dx.doi.org/10.5772/54069

43

To illustrate the use of these guidelines, let's consider the choice of the architectural pattern

Each tag costs about 0.10 euro (respectively 1.50 euro) if it has 0 KB (respectively 1 KB with 752 bytes of net storage capacity, *Stag*=752 bytes) of RAM. The avatar of a tag is the virtual card "contained" in the tag. There is a maximum of 16 cards in the game. Thus the avatar is coded as a byte value (*s*=1 byte). Concerning the vector clock, the project uses the synchroni‐ zation method requiring a session identifier. To have an ever-increasing value, "session identifier" field stores the initialization time. This time is the difference, measured in milli‐ seconds, between the session initialization time and midnight, January 1st, 1970 UTC. This storage requires 8 bytes per tag. Moreover, each tag holds the "tick in this session" field of

This field is coded as a short (*L*=2 bytes). It represents a real-time clock, formatted as the number of seconds since the beginning of the game session (A session lasts less than 2 hours: there is no risk of overflow). This clock is the time known by the tag of the last up‐ date of the avatar of another tag. It takes about 20 minutes to attach each of the 16 tags to their correct location, so an average of 75 seconds per tag. Linking the tag and the avatar takes about 5 seconds per tag. Initializing the avatar is done in a few milliseconds by an ini‐ tialization program. For reinitializing tags, synchronizing all of the 8 mobiles with a dedicat‐ ed machine takes about 1 minute, that is an average of 4 seconds per tag. Notice that synchronization is based on NFC peer-to-peer communication. The project could have saved

synchronization time if it has used Bluetooth®, but it would have used more battery.

If the project is going to use centralized or semi-centralized architectural pattern, it will use a dedicated machine for hosting the central database. This machine will be equipped with a 500 gigabytes disk (*Scentral*=500 GB). In the case of the semi-distributed architectural pattern, the project will use half of the micro-SD memory of each mobile phone to host the local copy of the database (*Slocal*=1 GB). If the project is going to use centralized architectural pattern, each mobile will have to be equipped with a SIM card giving access to a UMTS data plan. This will cost 15 euros per mobile per month. If the project is going to use distributed archi‐ tectural pattern, it will take 13 minutes to go by all of the 16 tags to reinitialize them, so an

for the RFID-based game *Plug: Secrets of the museum* presented in section 6.1.

and we reduce the high cost of tag reinitialization).

each avatar stored in the tag.

average of 49 seconds per tag.

By synthesizing the conclusions observed for the different architectural patterns, the next section provides guidelines for choosing the most adequate pattern for a given application.
