**4. Semi-distributed architectural pattern**

Then, when customer puts tag *r* on the reader, Touchatag application contacts ACS with identifier *i*. ACS replies with URL of *w*. Then, Touchatag application opens a browser with

*Skylanders* is a video game developed by *Activision* company [15]. It requires the use of plas‐ tic figures. These figures contain an NFC tag. When a player puts her figure on top of a "Portal of Power" (actually, an NFC tag reader), the video game reads the identifier stored in the NFC tag. Then, the game contacts a server to get the information concerning the char‐ acter which must be displayed: The figure becomes alive on the screen. Notice that, accord‐ ing to [16], information is also stored inside the tag: Thus the game can work without using a global network to contact a server. This means that Skylanders not only uses a centralized

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

Concerning the functional attribute, any transponder which wants to modify the avatar of a tag does so by sending a modification message to the server. Thus the server is always aware of the last update done on any avatar. As a reader always queries the central database to know the avatar of a tag, it is not possible that the read value is stale. Moreover, knowing a tag identifier, a reader is able to query the server to know the avatar associated to this identifier: the reader is able to know the avatar of a remote tag. As a mobile device queries the server to know the avatar of a remote tag, it is sure that the returned value is not stale.

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. Let *s* be the average size in bytes of an avatar. Let *Scentral* be the maximum size in bytes of the database. We neglect the storage of the link between tag identifiers and ava‐ tars in the database. Moreover, we neglect the overhead due to the storage of data in the da‐ tabase. Then, the maximum number of tags is bounded by *Scentral/s*. About sensitivity to the number of simultaneous reads, this architectural pattern is restrained by its centralized na‐ ture. The server holding the ONS lookup service may become a bottleneck. Moreover, the different servers of avatars may not return avatar values fast enough. Of course, it is possi‐ ble to increase the number of servers. But that makes the hardware architecture more com‐ plex and more costly (from an installation and a management point of view). Thus this

Concerning the cost attribute, the reader must always be in contact with the server holding the ONS lookup service and the servers of avatars: a global network is required. On the oth‐ er hand, this architectural pattern only needs to read an identifier on the tag. And this iden‐ tifier can be stored in ROM as it is never modified: no RAM is required on the tags. When a new tag is introduced in the system, three operations are required: (i) the tag is linked to the physical entity; (ii) the avatar of this entity is initialized in the central database; and (iii) a link between the tag identifier and this avatar is created into the central database. When all

architectural pattern may not be applicable for some applications.

this URL *w*.

**3.2. Analysis**

architectural pattern, but also a distributed one.

32 Radio Frequency Identification from System to Applications

In semi-distributed architectural pattern, mobile RFID-enabled devices (PDAs, mobile phones, etc.) are periodically synchronized with a central database holding all of the avatars (see Figure 2). Then, human operators carry the mobile devices near the entities to which the tags are associated. When a device comes close to an entity, the device reads the identifier of the entity's tag. By querying its local copy of the central database, the device is able to find the avatar of this entity. Any modification of an avatar is done on the local copy. It is propa‐ gated to the central database at the next synchronization.

**Figure 2.** Semi-distributed architectural pattern

Next section presents an example of this architectural pattern.

#### **4.1. Example**

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 her database updates and downloads updates from other gardeners.

Concerning the cost attribute, the mobile RFID-enabled devices only need an access to the server hosting the central database during synchronization phase. At that moment, devices are probably near the central database: A Wi-Fi network may be used. Otherwise it is the local database which is queried. Thus no global communication network is required around the working area. Moreover, as in centralized architectural pattern, there is no need for RAM on the tags. When a new tag is inserted in the system, the procedure to be applied is the same as in the centralized architectural pattern. When all of the tags have to be reinitial‐ ized, a program is run on the server hosting the central database. It sets each avatar to its new value. However, the reinitialization of the tags will be effective only when all mobile

Choosing the Right RFID-Based Architectural Pattern

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

35

This section has analyzed semi-distributed architectural pattern according to the attributes presented in section 2. This architectural pattern does not require any global network and has a medium sensitivity to the number of simultaneous tag reads. Nevertheless it faces a

Next section analyzes the distributed architectural pattern which tackles the sensitivity and

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

functional issue concerning the staleness of avatar read on a local (or remote) tag.

devices will get synchronized with the central database.

**5. Distributed architectural pattern**

the RAM containing the avatar.

**Figure 3.** Distributed architectural pattern

staleness issues.

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

#### **4.2. Analysis**

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 synchronized themselves with the central database.

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 each device and the central database.

Concerning the cost attribute, the mobile RFID-enabled devices only need an access to the server hosting the central database during synchronization phase. At that moment, devices are probably near the central database: A Wi-Fi network may be used. Otherwise it is the local database which is queried. Thus no global communication network is required around the working area. Moreover, as in centralized architectural pattern, there is no need for RAM on the tags. When a new tag is inserted in the system, the procedure to be applied is the same as in the centralized architectural pattern. When all of the tags have to be reinitial‐ ized, a program is run on the server hosting the central database. It sets each avatar to its new value. However, the reinitialization of the tags will be effective only when all mobile devices will get synchronized with the central database.

This section has analyzed semi-distributed architectural pattern according to the attributes presented in section 2. This architectural pattern does not require any global network and has a medium sensitivity to the number of simultaneous tag reads. Nevertheless it faces a functional issue concerning the staleness of avatar read on a local (or remote) tag.

Next section analyzes the distributed architectural pattern which tackles the sensitivity and staleness issues.
