**3. Centralized architectural pattern**

This architectural pattern is often used by manufacturing applications. It has been standar‐ dized by EPCglobal [2]. When a reader is near a tag (for instance, the blue mobile in Figure 1), it reads the tag's identifier or an identifier stored in the tag's data zone (its Electronic Product Code in the case of EPCglobal). This identifier is represented by the hexagon in Fig‐ ure 1. Then, the reader asks a server (ONS lookup service in the case of EPCglobal) which machine (EPC Manager in the case of EPCglobal) manages the avatar corresponding to the read identifier. When the server responds, the reader contacts this machine with the identifi‐ er of the tag. The machine queries its database and returns the avatar (for instance, the con‐ tents of the hexagon in the database in Figure 1).

**Figure 1.** Centralized architectural pattern

Next section gives examples of this architectural pattern.

### **3.1. Examples**

The final cost aspect is related to the reinitialization of all of the tags. This criterion concerns only applications which, during their lifetime, need sometimes to have each tag given a new initial value. For instance, this is the case of Paris public transportation system. Users are equipped with a transportation pass containing an RFID tag. At the beginning of a month, each user has to reload her pass (to refresh her access rights): in other words, the tag has to be reinitialized. Some RFID-based games also require tag reinitialization. Indeed, in the case of non-permanent games, users play during successive game sessions. Thus at the beginning

In this section, we have defined different aspects of three architecture attributes: (i) function‐ ality, (ii) scalability, and (iii) cost. These aspects are influenced by the use of RFID technolo‐ gy. We use them to compare the behavior of four RFID-based architectural patterns. We

This architectural pattern is often used by manufacturing applications. It has been standar‐ dized by EPCglobal [2]. When a reader is near a tag (for instance, the blue mobile in Figure 1), it reads the tag's identifier or an identifier stored in the tag's data zone (its Electronic Product Code in the case of EPCglobal). This identifier is represented by the hexagon in Fig‐ ure 1. Then, the reader asks a server (ONS lookup service in the case of EPCglobal) which machine (EPC Manager in the case of EPCglobal) manages the avatar corresponding to the read identifier. When the server responds, the reader contacts this machine with the identifi‐ er of the tag. The machine queries its database and returns the avatar (for instance, the con‐

of each session, all of the tags must be reinitialized.

30 Radio Frequency Identification from System to Applications

start by analyzing centralized architectural pattern.

**3. Centralized architectural pattern**

tents of the hexagon in the database in Figure 1).

**Figure 1.** Centralized architectural pattern

Aspire RFID is an Open Source middleware which is compliant to the specifications of EPC‐ global [8]. It proposes several examples of industrial applications for tracking goods.

Next paragraphs present products or prototypes developed according to centralized archi‐ tectural pattern, but without being compliant to EPCglobal.

*PAC-LAN* is a game prototype in which players are equipped with NFC mobile phones without any GPS capabilities [9]. Players must interact with NFC tags which have been dis‐ seminated throughout a neighborhood. In a central database, the identifier of each tag is as‐ sociated to geographical coordinates. When a player reads a tag, her mobile phone uses the UMTS network to contact the server with the tag's identifier. The server queries its database, finds the geographical coordinates, and broadcasts them to all of the players. An administra‐ tive application is provided to reset a game on the server. Such reset has an impact on all of the players' mobile phones.

[10] proposes an application so that visitors of an art exhibition can discover the paintings in another way. NFC tags are dispatched on the back of exposed paintings. Equipped with an NFC-enabled phone, the visitor puts her phone on spots of the paintings which intrigue her. Phone reads the identifier stored in the tag. Then, it contacts an uGASP server [11-12]. After consulting an internal database, this server indicates to the mobile phone what must be done: display a text, an image, or play an audio comment. Thus the author of the painting is able to communicate with the visitor.

*Via Mineralia* is a pervasive serious game which goal is to enrich the visit of a Freiberg museum [13]. In this game, the visitor uses a PDA equipped with an RFID reader. RFID tags (holding a unique identifier) are dispatched in the showcases which the museum wants to emphasize. When the PDA scans a tag, it sends an HTTP request (with tag's identifier) to a web server. To do so, the PDA uses a Wi-Fi network which covers the whole museum. The server answers to the PDA with multimedia information. The PDA displays them in a navigator.

*Touchatag* company (formerly Tikitag) sells NFC readers which can be connected to Win‐ dows or Mac-OS personal computers, and NFC tags dedicated to Touchatag [14]. A custom‐ er can then connect to http://www.touchatag.com web site, and define the reaction to be associated to the reading of one tag. When the NFC reader reads a tag, it contacts the Tou‐ chatag application which runs permanently on customer's personal computer. Then, via the Internet network to which the computer is connected, this application contacts a Touchatag service called *Application Correlation Service* (ACS). Touchatag application gives tag's identi‐ fier to ACS. Then, ACS queries Touchatag database to find reaction associated to the reading of this tag. It sends back this information to Touchatag application. The touchatag applica‐ tion reacts in the appropriate way. For instance, let's assume that the customer has specified the following action on Touchatag web site: when tag *r* with identifier *i* is put on the reader, customer wants her browser to access to Uniform Resource Locator (URL) of a web site *w*. 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 this URL *w*.

of the tags have to be reinitialized, a program is run on the server hosting the central data‐

Choosing the Right RFID-Based Architectural Pattern

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

33

This section has analyzed centralized architectural pattern according to the attributes pre‐ sented in section 2. This architectural pattern fulfills all aspects of functionality attribute. But this is achieved with the operational cost of a global network. Another disadvantage is a

Next section analyzes semi-distributed architectural pattern which compensates the re‐ quirement for a global computer network and reduces sensitivity to the number of si‐

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‐

base. It sets each avatar to its new value.

multaneous reads.

high sensitivity to the number of simultaneous read operations.

**4. Semi-distributed architectural pattern**

gated to the central database at the next synchronization.

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

*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 architectural pattern, but also a distributed one.

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

#### **3.2. Analysis**

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 architectural pattern may not be applicable for some applications.

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 of the tags have to be reinitialized, a program is run on the server hosting the central data‐ base. It sets each avatar to its new value.

This section has analyzed centralized architectural pattern according to the attributes pre‐ sented in section 2. This architectural pattern fulfills all aspects of functionality attribute. But this is achieved with the operational cost of a global network. Another disadvantage is a high sensitivity to the number of simultaneous read operations.

Next section analyzes semi-distributed architectural pattern which compensates the re‐ quirement for a global computer network and reduces sensitivity to the number of si‐ multaneous reads.
