**7. Guidelines for choosing the right RFID-based architectural pattern**

Table 1 synthesizes the analysis of the different aspects of the architecture attributes made on all of the architectural patterns. In this table, values which are in italic correspond to as‐ pects which are a limitation for this architectural pattern.

If the application requires the best level for all aspects of functionality attribute, then the centralized architectural pattern must be chosen. It is the only architectural pattern which experiences no issues within the functionality attribute. But this pattern has an operational cost due to the requirement for a global network. And this pattern is highly sensitive to the number of simultaneous reads.


**Table 1.** Comparison of the RFID-based architectural patterns (italic values signal a limit for this architectural pattern)

If one of these last two issues is a problem, the system architect must consider the three oth‐ er architectural patterns. Semi-distributed architectural pattern must be chosen if RFID tags cannot host RAM. This constraint may be due to cost motivations, but also technical con‐ straints (use of low-frequency tags, see section 2).

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 and we reduce the high cost of tag reinitialization).

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

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.

Table 1 synthesizes the analysis of the different aspects of the architecture attributes made on all of the architectural patterns. In this table, values which are in italic correspond to as‐

If the application requires the best level for all aspects of functionality attribute, then the centralized architectural pattern must be chosen. It is the only architectural pattern which experiences no issues within the functionality attribute. But this pattern has an operational cost due to the requirement for a global network. And this pattern is highly sensitive to the

Staleness of locally read tag No *Yes* No No Avatar of remote tag Yes Yes *No* Yes Staleness of remote read tag No *Yes* n.a. *Yes* Maximum number of tags Scentral/s Slocal/s Infinite *Stag/(s+L)*

Sensitivity to number of simultaneous reads *High* Medium None Medium

physical entity

**Table 1.** Comparison of the RFID-based architectural patterns (italic values signal a limit for this architectural pattern)

If one of these last two issues is a problem, the system architect must consider the three oth‐ er architectural patterns. Semi-distributed architectural pattern must be chosen if RFID tags cannot host RAM. This constraint may be due to cost motivations, but also technical con‐

Cost of reinit. Tags (most costly operation) Reinit. Database Sync. Database *Go to all tags* Sync. database

Network required *Yes* No No No RAM required on tag No No *Yes Yes*

> Link tag to physical entity

**Central**. **Semi-distr. Distributed RDSM**

Link tag to physical entity

Link tag to physical entity

**7. Guidelines for choosing the right RFID-based architectural pattern**

issue in terms of maximum number of tags which can be handled.

42 Radio Frequency Identification from System to Applications

pects which are a limitation for this architectural pattern.

Cost of introducing a tag (most costly operation) Link tag to

straints (use of low-frequency tags, see section 2).

number of simultaneous reads.

To illustrate the use of these guidelines, let's consider the choice of the architectural pattern for the RFID-based game *Plug: Secrets of the museum* presented in section 6.1.

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 each avatar stored in the tag.

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 average of 49 seconds per tag.

We apply these numeric values to table 1. Table 2 synthesizes the results. In this table, values which are in italic correspond to criteria which are a limitation for this architec‐ tural pattern.

**Author details**

Address all correspondence to: Michel.Simatic@telecom-sudparis.eu

[1] Bass L., Clements P., and Kazman R., Software Architecture in Practice, 2nd Edition.

Choosing the Right RFID-Based Architectural Pattern

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

45

[2] Armenio F., Barthel H., Burstein L., Dietrich P., Duker J., Garrett J., Hogan B., Ryaboy O., Sarma S., Schmidt J., Suen K., Traub K., and Williams J., "The EPCglobal architec‐

[3] Gonzalez L., RFID: Stakes for the enterprise! (in French). Afnor Editions, October

[4] Roussos G. and Kostakos V., "RFID in pervasive computing: State-of-the-art and out‐

[5] ITR Manager.com, "City of Paris is taking care of its trees with RFID tags (in French)," http://www.itrmanager.com/articles/59758/59758.html (last access in July

[6] "Smart Poster Record Type Definition, Technical specification SPR 1.1," NFC Forum,

[7] Simatic M., "RFID-based replicated distributed memory for mobile applications," in Proceedings of the 1st International Conference on Mobile Computing, Applications,

[8] Aspire RFID: OW2 Aspire RFID: an RFID suite for SMEs. Available at http://

[9] Rashid O., Bamford W., Coulton P., Edwards R., and Scheible J., "PAC-LAN: mixedreality gaming with RFID-enabled mobile phones," Computers in Entertainment,

[10] Haberman O., Pellerin R., Gressier-Soudan E. et Haberman U. (2009). RFID painting demonstration. In Natkin S. and Dupire J., éditeurs : Entertainment Computing - ICEC 2009, volume 5709 de Lecture Notes in Computer Science, pages 286-287.

and Services (Mobicase 2009), San Diego, USA. ICST, October 2009.

wiki.aspire.ow2.org (last access in July 2012), 2011.

vol. 4, no. 4, pp. 4–20, October–December 2006.

Springer Berlin / Heidelberg.

Addison-Wesley Professional, April 2003, ISBN-13: 978-0-321-15495-8.

ture framework," GS1 EPCglobal, Tech. Rep. Version 1.2, September 2007.

look," Pervasive Mob. Comput., vol. 5, no. 1, pp. 110–131, February 2009.

INF Department, Télécom Sud Paris, Évry, France

2008, ISBN-13 978-2-12-465153-5.

2012), December 2006.

2006.

Michel Simatic

**References**

Centralized architectural pattern requires a global network which costs 120 euros per month. The museum which hosts the game considers it is too expensive. We have to turn to one of the other architectural patterns. As the game must manage 16 tags and as the RFIDbased DSM can handle a maximum of 248 tags (as *s*=1 byte), we can choose this architectural pattern. However, if s had been 250 bytes, this pattern could have handled only 4 tags: It would not have fitted. As there must be no issue about avatar of read tags (the game would not be fun), we would have chosen distributed architectural pattern (or combination of dis‐ tributed and RFID-based DSM patterns, in order to reduce the costs of reinitializing tags).
